CISA BOD 26-04: Prioritizing Security Updates Based on Risk

 On June 10th CISA released its Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk.The Directive is targeted at Federal Civilian Executive Branch agencies and replaces CVSS-score-based deadlines with KEV based tiered remediation timelines of 3, 14, or 60 days.

The criteria for the tiering is:

• Asset Exposure: Is the vulnerable asset publicly exposed?
• KEV Status: Is the vulnerability, as identified by a common vulnerabilities and exposures identifier (CVE ID), on CISA’s Known Exploited Vulnerabilities Catalog?
• Exploit Automation: Is an adversary able to automate all the steps necessary to exploit the vulnerability?
• Technical Impact: Does an adversary gain partial control or total control of the vulnerable asset after exploitation of the vulnerability?

We've known for some time now that the CVSS score is a poor way of prioritizing patching.  There is no risk calculation, the base score is skewed towards the higher numbers, and the sheer number of them per month is impossible for most organizations to safely test and deploy.

The NVD shows 4160 vulnerabilities per month in 2025 and over 32,000 released this year already (1).   The KEV list looks small in comparison, but there are currently over 1600 entries in the KEV list with an average of around 20 additions per month.

While this is a move in the right direction, it still doesn't answer the underlying problem of agencies being able to patch within the three-day cycle. A lot of agencies are just not staffed for it, and who wants to be responsible for bringing down production and causing a monetary loss if one of these goes wrong.

For years I've advocated for a risk-based patching approach, taking into consideration factors like:

1. Is the exploit in the wild
2. Is the exploit being actively used
3. Is the asset exposed publicly or near a trust boundary
4. The assets' criticality
5. What does the attack path look like and does the system have a wide or deep attack path to other assets or administrative accounts/systems, critical systems, etc.
6. How does the vulnerability’s risk compare to other risks such as configuration risks, open services, etc.

7. What is the blast radius if the vulnerability is exploited

And in case you're not already scared, now we have the additional threat of AI models developing vulnerabilities even more rapidly and chaining vulnerabilities together. 

So what can we do now?

Any organization’s strategy (whether under this directive or not) for  managing vulnerabilities is going to depend largely on their specific requirements and landscape, but in general - and my opinion.

• Get comfortable auto-patching workstations, with regular reboots
• Assess vulnerabilities as close to real-time as possible, not just weekly/monthly
• Auto-patch browsers
• Manage apps and browser extensions and reduce and consolidate
• Know your assets and your attack surface, especially public facing
• Implement configuration standards and harden systems
• Constantly re-prioritize your truly “Critical” issues to address if you are falling behind
• Keep authentication and access in the mix to reduce your attack surface
• Start from the publicly accessible assets and assets on the edge of any trust boundaries
• Ensure management knows the risks and tradeoffs and why it is important-quantify the risk if possible
• Use AI defensively to constantly assess vulnerabilities or patch-if possible

Verizon data breach report

Verizon Small Business Services released a study of more than 500 data breaches that they were consulted in from 2004 to 2007 entitled 2008 DATA BREACH INVESTIGATIONS REPORT. Whether you can take the findings in here to be an accurate barometer of the state of information security or not is up to you, but I am much more impressed with this report, that anything else I have seen over the last several years. The sample size is a little small, and I have some concern over the source, since I didn’t even know Verizon did this type of consulting. So I am either out of touch, or other people in similar size organizations don’t know this fact either. They did report that 26% of the companies in the survey had at least 1001 employees. The actual segment states 1001-10,000, but since that is a little broad, I will go with my previous assessment and assume most of them are on the low end of this range.
What this report tells us about the state of Information security is that what we are doing, and where we are spending our money is not working, and that although you can write all of the policies you want, you had better make damn sure someone is reading them and following them. Now for my rambling thoughts and highlights of the report.

The report covered a period of 2004 to 2007 and covers 500 incidents. Of course these are only public incidents, and are only incidents where Verizon was involved, so all assumptions are made knowing that this may or may not be representative of the population as a whole.

26% were at organizations from 1001-10,000 employees
22% had 101-1,000 employees, and 30% had 11 to 100 employees

73% of the cases involved external parties as the source of the attack, 39% were the result of partners, and 18% was the result of an insider. The numbers are somewhat skewed in that some cases were a combination of those three leading to a number higher than 100%. I would assume from that that 30% of the cases involved a combination of all three, if my logic and math is correct here. This seems to go against everything we have always heard about insiders causing the largest percentage of losses. I still believe this may hold true and is not reflected in a large number of reports because there is no evidence of insiders performing these breaches, and the companies may not even be aware of them. The more interesting statistic is the high number of breaches due to partners, and when the report looked at the number of records compromised with the probability of compromise, the partners were the biggest risk here, although closely followed by internal employees - 73 to 67 respectively. So we need to have more controls, contractual obligations and monitoring around partners, but the internal threat, when you look at the numbers of records compromised is still a big threat. When the report calculated the number of records compromised form external sources it was dramatically lower than for internal employees (30,000 vs. 187,500). And what was the source of the internal breaches you may ask. 50% of the breaches were caused by IT admins. For the partner breaches, the report stated

“Partner-side information assets and connections were compromised and used by an external entity to attack the victim’s systems in 57 percent of breaches involving a business partner. Though not a willing accomplice, the partner’s lax security practices—often outside the victim’s control—undeniably allow such attacks to take place.”

What is needed here is controls and monitoring of partners, but how much of this will be effective? Making them change their passwords every x days wouldn’t have helped (see previous entry on this from 7/15), and perhaps monitoring wouldn’t have caught this either. What about serious liability statements in the contract with monetary penalties? If vendors are on the hook for not only their losses, but yours as well, might we be able to prevent some of these? Another interesting statistic is that in 16% of the cases where partners were the source of the breach, the deliberate, malicious actions of remote IT administrators were the cause.

One of the most interesting results from the report for me is in figure 12.which illustrates patch availability at the time of the breach. In 71% of the cases, a patch was available for more than a year, and in none of the cases reviewed was there a breach where a patch was available for less than a month. In only 4% of the cases was a patch available for 1 to 3 months. So all of the meetings on the second Wednesday of the month to review the recent Microsoft patch releases are a waste of time, and we should instead be focusing on whether patches are being applied or not across the board. A simple calculation of vulnerability to host ratio will suffice here, and the number should be decreasing over time.

Another stat of note is the review of common attack pathways. In 42% of the breaches, remote access and control was the cause of the breach, and Internet facing systems were the pathway in 24% of the cases, so we again seem to be spending money and time on the wrong thing here. Simply changing vendor default passwords would have most likely prevented most of these attacks.

So once these companies were attacked it took 63% of them months to discover the breach, and 70% of the breaches were reported to them by third-parties, employees ranked second at finding them (12%), event monitoring (4%) and third-party audit (1%). Interestingly enough in 82% of the cases, the victim had the information to detect the breach, but weren’t monitoring the events carefully enough to find them. This tells me that we need to spend more money on security awareness, and develop the monitoring as well as the collection of logs. I would like to know how many of those companies had expensive SIM products in place.

So what can we glean from this report.

1. We need to spend more on basic controls and procedures, and make sure they are being followed
2. We need to make sure employees know where and how to report suspicious activity because it is cheaper than monitoring events and three times as effective
3. If you do collect logs – have some automation in place to alert you
4. Patch as much as you can across the board regardless of when the patch came out
5. Watch your partner connections
6. Know where the data is (66% had breaches of data they didn’t know was on the system)
7. Ensure procedures and policies are being followedMonitor IT admin activity and ensure background checks are performed