Prioritize Patching Apple OSes; Open Source Components Often Behind on Patched Versions; Restart Chrome Browsers to Fix Another Critical Vulnerability

Apple patched these flaws with its January updates, but did not disclose these flaws until last week. Last week, Apple updated the related advisories declaring that they patched these vulnerabilities.

The more time (i.e. decades) you spend in the industry watching things like this the more you are not shocked when mitigations are broken. Pointer Authentication was very much a game changer in exploit mitigation on this platform. Side stepping it to introduce a new class of bugs is fascinating and not surprising. Maybe what is surprising is that the technique was circling around for 4 years before this type of article came out. It is a patched set of bugs and you should keep your phones updated.

These exploits are mitigated in iOS/iPadOS 16.3 and macOS 13.2. If you are still allowing devices to stay on iOS 15 or earlier it’s time to update. Note that updates to these new OS versions may require hardware replacements, so check your compatibility, keeping in mind getting new x86 Apple desktops is problematic.

In the ancient days [1990s and earlier] you could look at the number of hours spent finding the next bug in a piece of software over time and see a knee in the curve – the point where it could be considered stable/secure enough to release. Of course, that was when new versions of software came out yearly or less, and complexity of code was much lower overall. There really are no more knees in the software risk curve – using software means and will always mean continual patching to reduce risk. That’s why browsers and cloud services update themselves so frequently.

An example of security researchers properly disclosing a class of vulnerabilities to the software vendor. The result: affected software reviewed, software changes made, patch released, and researchers given appropriate credit for finding the class of vulnerabilities. Kudos to Trellix security researchers.

As I understand it, this class of vulnerability can be exploited only by rogue applications, not from the user or network interfaces. Do I have that right?

Google Chrome does a good job applying patches automatically, as long as you restart Google Chrome regularly. Try to make it a habit to restart Google Chrome once a day.

The use after free bug is taken advantage of by attacker’s leveraging the user prompt options to trick them into clicking a prompt taking them to a malicious site. Your layer 7 controls mitigate this risk to a certain extent, and given the other nine fixes in this release, you’re going to want to deploy this update.

‘Use after free’ is a remote code execution bug and should be patched immediately. The really good news is that Google greatly simplified the patch management process for Chrome, now mirrored by all major browser vendors. It’s as simple as closing and reopening the browser.

When you read this report (the non-redacted part you can read) it really points out to me that the process that is required for the DoD commands to say “Risks are acceptable using this FedRAMP certified cloud service” is overly complex. Yes, the commands did not look at the additional 47 requirements DoD adds over FedRAMP, but are those necessary for real world risks? I’d like to see this OIG report trigger a DoD review of that.

Part of participating in FedRAMP is disclosure of weaknesses and remediation plans. Access to this information is granted as part of the overall process to access the CSOs’ FedRAMP package, and permanent access is granted when an ATO is issued. The trick is making sure that the information is reviewed on a periodic basis to ensure the risk level hasn’t changed. While the CSOs’ are highly motivated to maintain their FedRAMP status, they, like the rest of us, have changes in security posture you need to keep an eye on just as you would systems in your own shop. This is really easy to overlook or skip, particularly with enormous pressure on agencies to move to the cloud, which will consume your security and implementation teams, so you may need to hire for this specific task to assure it happens.

The USG and other Governments will be slow to fully adopt the cloud and probably a lagging item will be how to Audit and secure these networks. Many commercial enterprises (if not most) struggle with this. Hopefully with this level of oversight this can start to be corrected.

This advisory is probably one of the more concerning ones. With so many Exchange issues it would make sense to focus on AV, but how many admins are willing to claw back exclusions? A tool would be helpful from the AV vendors if it were possible.

This is a step in the right direction for those of us hanging onto local Exchange deployments. Go through the update from Microsoft (link below) and make sure you have the minimum number of areas excluded from scans. Also verify you need to continue local instances of Exchange, and the plans to retire them.

At the root of this recommendation is the fact that many Exchange servers remain unpatched worldwide allowing adversaries to exploit. I’m sorry but there is no other way around it, if you’re going to have effective cyber defense, you have to have a timely patch management process.

Echoing my comment on the new class of privilege elevation flaw in Apple operating systems, open source components and libraries are often built into applications without the any level of QA or contractual scrutiny that commercial code gets – or at least gets sometimes…

As the report points out, this is increasingly becoming a problem—open-source components not being regularly updated as part of the codebase. Adherence to DevSecOps best practices can help solve this risk. Separately, I do wonder what affect generative AI software development will have on this trend. Will it result in an increase, a decrease, or no effect to poor coding practices.

The trick with hosted services is understanding which security settings are your responsibility and making sure they are configured properly, not just initially but also you need to monitor these for changes. Services such as Azure include tools to make this easier, but you need to enable them. Some of you are saying “what if the service provider makes an error” - understanding what the risks are and how they set and monitor their controls has to be part of the service acceptance/authorization process. That is also where you setup incident response/communication and consequences. Without that in place you won’t know what/who or how needed to discover root causes.

Improper configuration of cloud resources is a preventable problem. The Center for Internet Security publishes a variety of security benchmarks (Microsoft Exchange in this case) that contain security configuration recommendations that improves the security posture of cloud resources. Commercial tools exist that both assess and remediate against these security benchmarks. Use them.

Hopefully you’re saying “that is so last week, we’re good.” A change in state like this trips my trust but verify alarm - make sure the update really happened, or agreed upon mitigations are there. If you had pushback, now is the time to escalate and make sure you can detect (and remediate) compromises.

Unless I'm missing a key piece of information such as somehow the FortiNAC is tied to a firewall, I can't see why anyone would put this thing on the internet. I'm fairly sure that FortiNAC (which I believe was Bradford NAC?) as well as FortiWeb where not designed to be on the open internet. There should be no reason for this. Yes, patch, but more expressly none of your management interfaces should be internet facing.

Not much new, and no prioritization in this long list of security things to do. By far the most likely incident a home user will get hit by is a phishing scam obtaining their reusable passwords. Moving to MFA is buried in a short paragraph 7 pages in, long after a technically dense and longer section about WPA2/3 – when WiFi compromise of a home network (which requires physical proximity) is much lower risk. Curiously, it recommends I move to a “modern” operating system and browser – even I’m not sure that means, though I’m guessing latest version of Windows vs. moving to something more modern than Windows? I don’t recommend pointing non-IT savvy users to this guidance.

This is unfortunately the perfect example of why people still struggle with cybersecurity: we are making it far too complex for them. This document, designed by geeks for geeks, is nine pages of jargon filled complexity that I even got overwhelmed by. If you want people creating a secure home network, give them a single, one-page handout with five easy steps, no more. Something they can read in two minutes. Is this perfect? Nope. Is it doable? Absolutely. When you make the average home owner read seven pages to get to MFA, you are doing something wrong.

This guidance is straight forward and easy to read. It includes references to support their recommendations. If you don’t have guidance for remote workers on securing their home workspace, or if you’re looking for guidance in response to questions from friends, family and neighbors, here is something you can give them and use to support changes you need made.

This advice is about the LAN and is of most interest to SOHO users. Any advice to home users that exceeds one page is not helpful. I concur with John Pescatore that a preference for strong authentication should be at the top of any such advice. However, not all applications that the home user uses will offer such an option. Therefore, the number two entry should be to use a different strong password for each application. For most users the number of applications will indicate the use of a password manager, number three. Reconcile all out of band confirmations might make a good number four. I think these four measures are reasonably convenient and efficient as to achieve such a level of risk as to make most additional measures inefficient; I await your number five.