Priority Patch All Apple and Android Devices, and MOVEit Applications; Have Legal Counsel Review EU US Data Privacy Review Court Agreement

Applying these patches should be a no-brainer. They fix currently exploited vulnerabilities, and Apple's "Rapid Security Response Updates" are specifically designed to be easy to apply. Should take less than five minutes per device. It does require a reboot, but the reboot is just a "regular" quick reboot and not the more lengthy reboot used by the larger operating system updates.

Apple released updates for iOS/iPadOS 16.5.1, macOS 13.4.1 and Safari 16.5.2 to address CVE-2023-37450 which are actively being exploited. Apple will be releasing new versions of the updates to iOS/iPadOS 16.5.1 and macOS Ventura as the update causes some web sites to to not display properly. If you're having issues, the rapid update can be removed through the settings app on macOS/iOS/iPadOS, and using the about the OS menu, remove the update. A restart is required.

I always recommend people keep automatic updates running, but I also find it inconsistent or delayed sometimes. If you are reading this and are security conscious, force the upgrade as it may not have already occurred.

Apple introduced Rapid Security Response updates in May of this year to address critical vulnerabilities. This is the second time they’ve used this update process. The updates are compact and quick to install. Given reports that the vulnerability is actively being exploited, download and install today.

“The flaw is being actively exploited” = Patch now !!

Just like the Apple update above, this update fixes a number of actively exploited vulnerabilities. Unlike the Apple update, if and when you will be able to apply these patches will depend on the device you have and in some cases your carrier.

While these updates are readily available for Google devices, others will have to wait for their OEM's to release their versions. The good news is that the process is pretty quick for supported devices. As an enterprise, regardless of your ability to push Android updates, make sure that you are actively managing the lifecycle of Android devices, replacing them before the support window expires, typically two years for general updates plus one year of security updates.You many want to standardize on an OEM that best aligns with your standard lifecycle model. As carriers can introduce delays to Android updates regression testing their value-added components, as they should, you may want to investigate options to reduce that, such as purchasing unlocked devices from the OEM rather than the carrier.

Can’t forget that Android also has an update cycle. The main difference is with the underlying hardware. If you can upgrade, do so. We are all still patiently waiting to see when Android will be either mainline Linux Kernel or the patching cycle will be decentralized from drivers.

The monthly Security Bulletin contains four critical vulnerabilities, three of which are actively being exploited. My question: should Google consider a similar response to that of Apple in releasing out-of-band patches to address vulnerabilities that are being exploited? There are pluses and minuses to the approach but at least the patches are quickly made available to address active exploits. Regardless, Android users should download and install the updates today.

Consider the difference in time to, and convenience of, repair when choosing between iOS and Android. For enterprise use, this choice trumps the choice and price of hardware.

In the July Service Pack release, Progress Software admitted something surprising: “In response to recent customer feedback, we are formalizing a regular Service Pack program for MOVEit products, including MOVEit Transfer and MOVEit Automation.” Almost 20 years after Microsoft moved to monthly patching, Progress Software (who sells several software products with “Secure” in the name) just began to see the need for regular, predictable patch releases?? So, one lesson learned: ask about patch release practices in all RFPs for software. Since most of the discovered vulnerabilities in MOVEit are well known OWASP top 10 vulnerabilities, also a reminder to include questions/evaluation criteria around code testing done prior to shipping code.

If you still have MOVEit, time for patching, once more with feeling. There is good news: Progress has updated their practices to provide monthly updates. In today's climate, make sure that you have a defined update interval, monthly/quarterly/etc., from your providers, as a demonstration they are taking a proactive rather than reactive stance on product security.

It’s been a lousy couple months for Progress Software. These and previous critical vulnerabilities highlight a lack of attention to secure software development principles within the company. I suspect that the company is addressing this development gap, but it will take time. The question is, will users stick with them while they institute secure coding practices across their product lines?

Expect to see more MOVEit bugs since people know the software exists now and is a big target. There are more than likely other vendors that fit this profile, and I suspect these ransomware actors are now looking at those.

While this agreement may calm the nerves of businesses transferring personal data outside of the EU to US based companies, I have no doubt that similar to Privacy Shield and Safe Harbor before that, this agreement will be challenged and found not to be adequate. At the core here is the lack of US privacy laws that protect the rights of individuals who do not have recourse to US courts.

Not much changed here, outside of adding a “data protection review court” - additional challenges by privacy advocates are likely. Have your Chief Legal Counsel take a look to determine what legal actions will be necessary if one of your customers triggers a data protection review action.

The short version is you need to come up to EU standards for data protection to participate. Likely the hardest will be deleting data when no longer needed, not hanging onto it for a rainy day. You want a comprehensive plan here rather than a separate set of rules for EU data to reduce the chance of error. Think back to situations where you've adopted the most restrictive set of requirements as that meant all others were met and you only had to implement one set of controls.

Purging data that is no longer needed is simply good practice. Consider a policy that requires special authorization for retention beyond three years.

HCA seems to be doing a solid job of communicating 5 days after discovering the breach, but they didn’t notice it until sensitive data was released in a public forum. No details out, but odds are a cloud storage configuration issue could be the root cause. Good item to use to justify checking/updating all your cloud services configurations to one of many available secure baselines.

HCA is an exception within the healthcare sector in that they communicated the data breach within five days of becoming aware. While we have scant details on how the theft occurred, ‘dollars to donuts’ the likely culprit will be a cloud misconfiguration. Take the time to revisit each external storage location and configure to a known security standard, such as the CIS foundation benchmarks.

This is about third-party risk. Make sure you're only providing them the data elements needed for their function, have a clear understanding of how that information is handled and protected, then make sure the incident response plan has appropriate contacts. While your contract analyst needs to know about an incident, your incident response team is probably a better first step, and better situated to respond.

This is the case of an insider abusing the trust conveyed to them. This sort of attack is difficult to defend against as the perpetrator, by default, has certain access. Companies should use this as a case study and institute lessons learned as part of their insider threat program.

Providing VPN access to ICS/SCADA systems, rather than exposing them to the Internet is still the right answer. What that entails is allowing only authorized remote access systems. There are services (LogMeIn, VNC, etc.) that can create access paths, using hosted or cloud services, which you need to keep an eye out for, optimally using a default deny stance which ensures due process is required to implement them.

Water treatment is infrastructure. Mis-operation is obviously high risk. Any connection of controls to the public networks adds to that risk. Care must be taken that any such connections are made only by management.

Make sure that you're on version 115; you may still be back on 102.13 if you're running ESR. Talk to your folks about getting 115 out due to the security issues it resolves, five of which are rated as high. Then go check out the new feature: the setting can be enabled by going to about:config and setting "extensions.quarantinedDomains.enabled" to true, and then editing the "extensions.quarantinedDomains.list" which has the blocked domains.

This is a good move by Mozilla. Evil addons and extensions in any browser can be an excellent way for attackers to compromise your systems. They would be able to read authentication material and masquerade as you. Be careful what extensions you load in your browser, and keep that list to a minimum.