FBI Publishes Guidance for SEC Reporting; Apple Addresses 43 Security Issues; President's Cup Cybersecurity Competition

The SEC has been using the same definition of a “material event” for over 20 years now – no publicly traded company can complain that is not clear enough. No word yet on how the FBI plans to assure that using email for disclosure delay requests that are chock-full of sensitive information will be done safely and securely – it cries out for the use of encryption and strong authentication.

Four business days is pretty generous considering your other regulators may have shorter timelines of 72 or 48 hours. Regardless of the reporting interval, you may consider the disclosure detrimental to your business. In this case the FBI is giving an option to delay, but not eliminate, the 8k filing, but you have to engage them immediately upon determination you need to file the 8K. The good news is that the SEC hasn't changed the definition of a "material" breach in a long time. While you're looking at, and updating your SEC reporting requirements, make sure the information on reporting as required by any other regulators is current, to include knowing what and how to file/report, how the information is protected, and who in your management needs to be onboard.

Basically, notify us immediately ‘upon determination,’ but within the four-day window, otherwise request denied. The questions the FBI is asking are all reasonable: the who- what- when- where-and-how sort that one asks when trying to determine what happened. The onus is still on the victim to determine what constitutes a ‘material’ breach and whether to notify, but it’s clear, the government wants to be alerted as soon as possible. From my lens, that’s not a bad thing.

This update fixes two already exploited vulnerabilities in older iOS/macOS versions. Apple already released a special security update last week addressing these two issues in current versions, but noted that the vulnerability was only exploited in iOS 16. Another notable vulnerability addressed is a weakness in Bluetooth pairing that allows adversaries to inject keystrokes if Bluetooth keyboards are used.

This includes the expected updates to iOS 16 after the 11/30 release of 17.1.2, these updates are addressing additional flaws beyond WebKit. Quick breakdown of addressed CVES: iOS/iPadOS 17.2: 12, iOS/iPadOS 16.7.3: 8, watchOS 10.2: 9, Safari 17.2: 2, macOS 14.2: 39, macOS 13.6.: 17. You should be able to push updates with your MDM today. Since mobile devices remain a prime target, and we're often more distracted during this holiday time of year, do your users a favor and get these deployed. Note the updates to iOS 16 include fixes for flaws which are being actively exploited in the wild. The fixes for iOS 17 include addressing a Siri flaw which allows someone with physical access to use Siri to reveal sensitive information, as well as similar issues with the Accounts and AVEVideoEncoder services.

Essentially this leverages a weakness in the autofill process on Android, typically leveraging a malicious application. Google has published guidance for password manager developers to use to prevent exploiting of WebView. Keeper, LastPass and 1Password have implemented fixes to prevent the exploit. In addition to making sure you've got the most current version of your password manager, make sure that you're only downloading applications from the Google Play annd/or Corporate App Stores.

Autofill is a double-edged sword. It creates efficiencies for the user for many tasks but if not coded correctly, can leak data. That is the case here. For this vulnerability to be successful requires that a malicious app be installed on the user’s device, not impossible, but also, not a given. If you can install a malicious app, then the device is already compromised. Otherwise, you must go through the vetting process to get the app into the Google Play Store. I see this as a low-risk vulnerability.

When I first looked at this, I thought the issue was specific to the Mac. No, these are fixes for your Confluence Data Center and Server, as well as the Mac specific companion app. Even if you're using their hosted service, the companion would be on your local Mac systems and all versions up to 2.0.0 are affected. The Windows version is not affected. The good news is this app automatically updates during runtime, so you simply need to scan to verify the updates are in place. Given the rate of fixes from Atlassian these days, and that their flaws are actively targeted, it's a good opportunity to see if you can leverage their hosted versions instead to lessen your support burden.

The last few months have been bad for Atlassian and the quality of its software development processes. Time for them to revisit every software quality assurance process with an eye towards improvement. That said, given that the vulnerabilities can lead to remote code execution, IT staff should patch immediately.

This is an interesting supply chain issue, but difficult to exploit outside the supply chain. An attacker would have to convince the victim to install a specific boot logo. On the other hand, exploitation may bypass some firmware protection mechanism as the firmware's executable code is not altered until the boot image is loaded.

Interesting twist here is the exploits are not platform specific, equally working on Intel and ARM systems, but rather UEFI/IBV version specific as they are leveraging flaws in the specific image parsers embedded in the firmware. At core is that the image parsing libraries don't change frequently, so they likely include unpatched flaws which can be used to bypass Secure Boot, Intel Boot Guard, and other endpoint protections. The flaw leverages images either on the EFI System Partition, or embedded in the unsigned portions of firmware updates. BIOS updates from AMI, Insyde, Phoenix, Lenovo and others are expected this week. The mitigation is to deploy (vetted) updated firmware, and make sure that services such as Secure Boot, Intel Boot Guard, Intel BIOS Guard and similar protections are enabled.

The information (names, addresses, Social Security numbers, driver’s license/state ID numbers, passport numbers, financial account information, employment-related health insurance and medical information) appeared in April on the leak site for the Cactus Ransomware gang. This gang emerged in March and is focused on exploiting vulnerabilities in Virtual Private Network appliances to get a foothold in corporate networks. The Cactus ransomware is being actively tracked by Dragos which reports it's appearing in multiple attacks on industrial entities they are tracking.

An all-too-common result from a ransomware attack, data exfiltrated affecting many users and employees. Given that this is not the first cyber event that Americold has had to deal with, it does call into question the effectiveness of their cybersecurity program.

This appears to be a side-effect of attackers going after the Unitronics PLC flaw (CVE-2023-6448), versus specifically targeting the Irish water utility. If you have any Unitronics PLCs or HMIs, make sure that default passwords are changed, updates are applied, and they are not exposed to the Internet.

Continued fallout from the exploitation of Unitronics PLCs. We know the root cause, product shipped with a default administrative password. A question to ponder, should the vendor, Unitronics, be held liable for shipping a product with a known security weakness.

One assumes that the government used the public networks to "identify" the vulnerable devices. Most of them were never suitable for connection to the public networks.

There really isn't a good way to put the Open Source Software (OSS) genie back in the bottle. Instead, make sure that you're tracking updates for OSS products in your enterprise and keeping them updated. When choosing an OSS package versus a commercial one, make sure that you include the mortgage of tracking and updating, as well as risks of volunteer maintenance/response to discovered flaws in your decision-making process. Make sure that you're always getting the genuine OSS product, and you're doing code/security review/checking wherever practical.

As a primer on open-source software history and risks, its flows well. The major takeaway, open-source software is basically everywhere, and one should invest in a vulnerability management program. Bottom line: organizations will have to manage the risk imposed by open-source software as it does for other software providers as part of its supply chain risk management.

Guidance and warnings to the healthcare sector seem to fall on deaf ears. Open source software is the least of their problems and should be the last to be fixed. The industries fundamental problem is exposure to the public networks. Proper isolation would hide most of this software from the public networks.