Mythos Redux (AKA the Patch Tsunami)

Last week, Anthropic published a blog article that provided the industry with an update on Project Glasswing, their initiative to provide major commercial and open source software providers with a preview of Mythos, their newest AI model. In the article, they share what they’ve learned from the initial usage of Mythos internally and by their partners, putting this activity in the context of industry best practices for vulnerability disclosure.

In the weeks since Mythos and Glasswing were announced, there has been a great deal of skepticism and analysis, with a vocal set of commenters expressing their belief that Mythos’ advanced capabilities were, er, mythical, and that the entire initiative was a brilliantly executed marketing ploy. As I wrote at the time, the degree to which Mythos is hype actually doesn’t matter. (What does matter is that AI’s vulnerability discovery and weaponization capabilities are only getting better, Mythos hype or not.)

In any case, I imagine that Anthropic’s statistic-heavy blog posting last week was not a coincidence, and that the metrics were included specifically to quiet the naysayers. I have my doubts that they’ll be successful, but the most important thing is that as enterprise security leaders, we do need to be prepared for a patch tsunami. For example, the Anthropic blog states “The latest Palo Alto Networks release included over five times as many patches as usual. Microsoft has reported that the number of new patches they’ll release will “continue trending larger for some time.” And Oracle is finding and fixing vulnerabilities across its products and cloud multiple times faster than before”. 

Time to Get Ready

We need to take this at face value, and get our enterprises ready. Further, it’s really important for us to drill down to specifically how this will translate to tasks and activities, because frankly, the way that Anthropic talks about this is incomplete and a bit disappointing. In their blog, they state “Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it’s limited by how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI.” 

This glosses over the reality for every enterprise on the planet, which is that there is significant work involved in staging, testing, and deploying these patches into an enterprise environment. Even more so, a patch is not always a “patch”. We have to look at the different types of software updates (AKA patches) and understand how they get processed and deployed inside of enterprises. Because that’s often spread across multiple different teams and requires coordination and prioritization. Not every patch is as easy as a mobile phone operating system one-click update.

Let’s break down software updates into a simple taxonomy, to help us organize our thinking:

• Mobile Operating Systems
• Desktop Operating Systems
• Server Operating Systems
• Network Infrastructure
• Security Infrastructure
• Application Infrastructure
• Commercial Software (COTS)
• Custom Software

Each of these is going to have different processes, teams, levels of effort, and risks associated with applying updates. And enterprises need to be prepared for increased volume and frequency for all of them, as well as some additional implications that I’ll touch on at the conclusion of this posting. 

But first, let’s explore the different categories in our list, and the patching implications of each. 

• Mobile Operating Systems
• Desktop Operating Systems
• Server Operating Systems

The three classes of Operating Systems are in fact, the simplest of all, even though they are the biggest from a sheer numerical perspective. Even in an organization of, say, 5,000 users, there will still only be two (possibly three) types of desktop operating systems, and only two varieties for mobile and server. This reduces the complexity of the process, although the scale presents some challenges. It’s important to ensure that your enterprise’s visibility into your IT estate is as complete as possible, so that there aren’t any unknown stragglers that inadvertently don’t get upgraded. 

Note that you’re going to need to take a firmer line on upgrading. If you have known legacy systems that are no longer supported, proactively work with the appropriate stakeholders to begin executing on upgrades. For those rare systems that cannot be upgraded, which is more common in OT than in IT, you will need to take countermeasures such as more precise network segmentation (more on this below).

• Network Infrastructure
• Security Infrastructure
• Application Infrastructure

These three will require coordination, and potential downtime for parts of your environment. Start planning now, and work to create or update a test environment where you can apply these updates to non-production systems, for validation and practice.

• Commercial Software (COTS)

In some ways, these will be one of the easier classes of updates, since the vendors will be responsible for packaging and testing the updates. You should, of course, validate these updates as well in your own environment. If you don’t have a non-production lab for your important COTS systems, this is a great opportunity to work with your vendor to get it set up. You shouldn’t have to pay a significant licensing fee for this; some vendors will provide this for free, while others will charge a nominal amount.

• Custom Software

This is the biggie, and often the highest risk for enterprises. You need to expect that a significant minority, if not an outright majority, of the open source and commercial libraries used by your custom applications will be updated. Of course, these will be released as updates to the libraries, rather than a pre-packaged “patch.” Which means that your teams will bear full responsibility for updating, building, testing, and deploying the updated software that utilizes those libraries. If your developers do not have a clear and updated inventory, and a reliable way to build your software, this needs to be an urgent priority. If your custom applications rely on older versions of open source libraries, this needs to be even more urgent. It’s quite likely that open source libraries will only update their latest versions, so if there are changes to APIs or other dependencies, your developers will need to perform some non-trivial work to get things updated. (Of course, they can rely on AI to help, but will still need to test things properly). This work will be unexpected and therefore unplanned for, so be prepared for some pushback and negotiation with application owners. In some cases, deferring updates and applying stricter network segmentation (see below) is going to be a reasonable compromise.

What Else To Expect 

We need to be prepared not only for an increase in the frequency and magnitude of application and library updates, but also some changes from our software vendors. Specifically, you should expect that vendors will tighten up the “tail” of older versions of their software that they support and actively patch. Each different version that needs to be supported and updated by the vendor incurs a direct cost to them, requiring the allocation of people and time. And if the number of vulnerabilities significantly increases, we need to expect that the most likely implication is that fewer versions will be supported. So take inventory of your COTS systems, and collaborate with your application owners to assess whether they’re on the latest version. If not, proactively begin executing on a plan to update. This will make things easier for you when the inevitable patches appear, but are only available for newer versions.

Resilience Through Zero Trust Principles

Finally, this is a great opportunity to prioritize network segmentation following Zero Trust principles of default deny. Many, if not most enterprises are going to have to adjust their internal calculus of which systems and which vulnerabilities to prioritize and patch. Given limited resources, there will likely need to be a change in expectations (e.g. SLAs) for severity and patch timelines. By moving systems off the traditional flat network and into a microsegmented environment protected by dynamic access policies, you’ll be significantly reducing the risk of unpatched systems, as well as making yourself more resilient to the inevitable (!) unpatched zero-days that are coming. As we wrote about recently, every vulnerability is essentially an “allow” access policy.

Don’t Panic, But Do Get To Work

The impending patch tsunami may feel like a doomsday scenario. It’s not, but it should be a wake-up call to improve your organization’s visibility and process maturity. This is going to take some hard work, and will divert time and attention from other tasks. There’s no getting around that. But remember – and reinforce for the teams involved – that every step you take to get accurate information about the systems in your environment, every update to build processes and automations, and every process improvement will pay dividends many times over. And every system that you move behind a Zero Trust Policy Enforcement Point becomes much, much less vulnerable to both known and unknown exploits, and improves your overall maturity and resilience.

---

Want to learn more? Read about our Zero Trust Blueprint, a reliable pathway for enterprises to execute on this information security strategy. Sign up for your free 30-minute briefing here.