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

 

The MFA Illusion

Identity is the new firewall

Attackers no longer need your password. They don't even need to break your MFA. They just need to sit between you and a login screen.

        TL/DR

• Your end users are likely providing their credentials and access on a regular basis and may be unaware it is even happening
• Unless you have some form of identity threat protection, you are flying blind
• Make a plan to get off passwords and especially towards phish-resistant MFA - NOW
• Automate remediation actions in your identity provider for real-time protection
• Enable Continuous Access Evaluation or other measures to reduce token replay risks

For over 25 years multi-factor authentication was the silver bullet. "Enable MFA” was what we all preached and the first time I saw an RSA fob I was sure this would solve everything.  OK, that was a long time ago, and I had much less gray hair. This was also back in the day where almost all cybersecurity was focused on “the firewall” as our security saviour, then IPS and so on, and so on.

So to prevent identity threats, perhaps the dumbest idea of all came into all of our requirements, well just change the password every 90 days AND use MFA, and then you are certainly good.  Also make your password really strong, and don’t allow anyone to re-use them AND use MFA - OK, now you are really good.

Today, attackers don't need to steal your password at all. They just need to intercept the session after you successfully authenticate - credentials, MFA code, and all. This technique, known as Adversary-in-the-Middle (AiTM) has grown into a primary vector responsible for some of the largest corporate breaches of recent years. And the uncomfortable truth is that most organizations are still running MFA that offers zero protection against it.

Identity is our new “firewall” in most cases and may be the only thing standing between your organization’s data and an attacker.

Understanding the Adversary-in-the-Middle Attack

A traditional phishing attack aims to steal credentials. The attacker sends a fake login page, the victim types their password, and the attacker captures it. MFA broke this model and even with the password, the attacker lacked the second factor that expired before it could be reused.

AiTM attacks do not try to steal credentials, but instead proxy the entire authentication process in real time.

AITM ATTACK FLOW — REAL-TIME SESSION HIJACKING VICTIM(Employee) → ATTACKER'SPROXY SERVER → LEGITIMATESERVICE (M365) The attacker does not break MFA — they let the victim complete it, then steal the resulting authenticated session cookie.

The victim receives a phishing email pointing to a convincing lookalike domain or an organization you have been in contact with already, and hey they are just sharing a file with you, so what could be the harm.  Click, go ahead, you know you want to.

They click and see a pixel-perfect Microsoft login page, and enter their credentials. The proxy server forwards these to Microsoft in the background. Microsoft responds with an MFA challenge. The proxy displays this to the victim. The victim completes the MFA and the proxy relays that response to Microsoft. Microsoft, satisfied, issues an authenticated session cookie. The proxy captures that cookie. The attacker now holds a valid, authenticated session and can access the victim's account without ever knowing their password or their MFA secret.

THREAT LANDSCAPE Why AiTM Has Become the Attack of Choice Several converging factors have made AiTM the dominant enterprise credential threat: →  Commoditized toolkits lower the barrier — no deep technical skill required →  Traditional MFA adoption has made pure credential theft less valuable, pushing attackers upstream →  Session cookies have long lifetimes; one stolen cookie can provide persistent access for days or weeks →  Cloud services (Microsoft 365, Google Workspace, Okta, Salesforce) are high-value targets with unified access to vast data →  Conditional access policies often don't re-evaluate mid-session, allowing lateral movement once inside →  Business Email Compromise (BEC) fraud — redirecting wire transfers — can be executed directly from stolen sessions

Why Conventional MFA Fails

Conventional MFA methods remain highly effective against bulk credential attacks, password spraying, and unsophisticated phishing. The problem is that they were never designed to resist a real-time proxy interception. The codes they generate (TOTP codes, SMS OTPs, push notifications) are possession factors that prove nothing about the connection through which they travel.

When a user approves a push notification, they are confirming: "I intend to authenticate." They are not confirming: "I am authenticating directly to Microsoft, via a connection I trust, to a server whose identity has been cryptographically verified." That distinction is everything.

What Makes Authentication Truly Phish-Resistant

The term "phish-resistant MFA" has a precise technical meaning, and it centers on a single concept: origin binding. A phish-resistant authentication method cryptographically ties the authentication response to the specific origin (the domain and server) that the user's browser is communicating with. If that origin is not the legitimate service, the authentication simply fails. A proxy server sitting in the middle will never receive a valid authentication token, because the browser will refuse to generate one for an unrecognized origin.

This is the fundamental innovation of the FIDO2 standard and its consumer-facing implementation, passkeys. When a user registers a FIDO2 credential with login.microsoft.com, that credential is mathematically bound to that exact origin. An AiTM proxy operating at microsoftonline-secure.net will receive nothing usable, the browser will not generate a valid authentication response for the wrong domain.

How to move forward

Transitioning to phish-resistant MFA is not an easy change, but moving users away from passwords will be a security change they will definitely welcome, unless you end-users really enjoy changing their passwords.

Phase 1: Prioritize

Not every user and every system presents equal risk. Begin by identifying your highest-value targets: privileged administrators, finance personnel with payment authority, executives, and any account with confidential data access. These accounts should receive phish-resistant MFA and more restricted Conditional Access Policies.

Enable automated remediation, because it is not possible to manually manage identity threats at the speed end-users are providing their passwords in AiTM attacks. MS Defender for Identity and Crowdstrike’s ITP are great examples and are really quite good at detecting anomalous login activity.

Phase 2: Deploy FIDO2 / Passkeys

Microsoft Entra ID, Google Workspace, Okta, and Ping Identity all support FIDO2 authentication. MS EntraID with MS Authenticator is an especially good example for any MS shop. Hardware security keys (YubiKey, Google Titan) remain the gold standard for those who need it all and don’t mind hardware deployment. Platform passkeys built into Windows Hello, macOS, iOS, and Android provide FIDO2-grade security for the general workforce without requiring physical hardware distribution.

Undeniably, passkeys are difficult in most consumer aspects, and their ability to work on another device or within an app (even if they are shared in a password manager) makes them difficult when not used in a corporate environment.  However, the days of passwords and non phish resistant MFA solutions are gone in the corporate world and if you are not actively monitoring identity threats in your environment, you are missing how many users are falling victim to AiTM threats every week.

Phase 3: Eliminate Weaker Fallbacks

Phish-resistant MFA delivers no protection if users can fall back to a simple password or SMS OTP. Conditional access policies must be configured to enforce phish-resistant methods for protected resources, no exceptions, no fallback to legacy MFA.

Phase 4: Layer Complementary Controls

Phish-resistant MFA addresses authentication but does not stop all authentication threats. Short session token lifetimes forcing frequent re-authentication; continuous access evaluation that revokes sessions on anomalous signals; and most importantly, ensuring only managed devices can authenticate to your organizational domain where possible.

Proposed amendments to FAR - Attention GSA'ers

DoD, GSA and NASA are proposing to amend the FAR with a new subpart and contract clause for anyone contracting with Uncle Sam or handling government data.  The changes would require contractors or organizations handling government data to take certain information security measures and these would be contractually required.

Written comments are due on or before October 23rd, and the FAR case is 2011-020.

"Basic safeguarding" of data includes such items as:

• Use of public computers
• Intrusion protection
• Transmitting of electronic information
• Physical and electronic barriers

According to the proposed rule, basic protection measures are "first-level information technology security measures used to deter unauthorized disclosure, loss, or compromise."

It is interesting to note that although these should already be included under FISMA it also pertains to the use of COTS products.  Anyone contracting with Uncle Sam should keep abreast of the changes and provide comments.

http://www.gpo.gov/fdsys/pkg/FR-2012-08-24/pdf/2012-20881.pdf

District Court Rules Online Video Streaming Subject to VPPA Restrictions

I believe the word "DUH" is needed here

District Court Rules Online Video Streaming Subject to VPPA Restrictions

Thought for the day

Optimists look at a glass of water filled 50% and say it is half full
Pessimists look at the same glass as half empty

A security person looks at the glass and says "how do I know this is water and not some deadly chemical"

Chris Cunningham (just now)

Cookie Guidance from the UK ICO

In 2002 the European Directive 2002/58/EC laid the ground work for the protection of privacy for electronic communications. This was amended in 2009 by directive 2009/136/EC commonly referred to as the “cookie rule”. This directive required governments in the EU to implement these changes in their own laws by May 25, 2011. The UK ICO allowed for a “lead in period” of one year, and that year is now up. On May 25th, The UK ICO published their recommendations on the directive and how the UK ICO views the issues and requirements in the directive, as well as some insight into how enforcement actions may take place within the UK. This is a valuable resource for organizations operating websites in the UK.



As should be anticipated, any cookies that are not strictly necessary or any cookies that handle sensitive data should get extra attention, since you can be assured the DPAs will be paying special attention to them. This is an area where explicit consent should be obtained.

A couple of items from the guidance should be noted by any organizations using cookies on their websites, especially cookies that track users actions across multiple sessions.


• Explicit consent is not a requirement in all cases


• Users on the site should be conspicuously advised of the use of cookies on the site, and their choices on allowing the cookies.


• Exceptions for a cookie being “strictly necessary” should be sued very narrowly


• Make the use of third party cookies very clear to the end-user

How a carrot and a stick relate to US privacy legislation

Yesterday, the Obama Administration released their latest efforts to effect real privacy standards and legislation in what they are calling the Consumer Privacy Bill of Rights. The paper, entitled Consumer Data Privacy in a Networked World outlines several measures that will drag the US, kicking and screaming, into the development of a real privacy standard that will rival the European and OECD standards and directives.
The plan is broken down into several areas. First, there is a Consumer Privacy Bill of Rights that is similar to the OECD Privacy Principles, albeit unnecessarily complicated and duplicative. Secondly, the Bill of Rights would be implemented in Codes of Conduct that industry would need to develop in concert with the government’s “assistance”. Thirdly, the FTC would be the enforcer of these codes of conduct similar to their current role. Lastly, the plan calls for a Federal breach notification standard and calls for enforceable federal legislation that would enable mutual recognition by other countries. To date, Congress has failed miserably in every attempt to enact Federal data privacy legislation, so I applaud the Administration for trying the carrot approach, since the stick has not been effective.

Consumer Privacy Bill of Rights

The Obama Administration is hoping that even if Congress does not implement Federal legislation, that this will be the starting point for industry discussion and a beginning of privacy standards that can be used by businesses and industries. The Bill of rights is similar to the OECD standards and includes:

•Individual Control
•Transparency
•Respect for Context
•Security
•Access and Accuracy
•Focused Collection
•Accountability

Codes of Conduct

The plan calls for companies and groups to develop these codes of conduct in cooperation with the FTC and the National Telecommunications and Information Administration (NTIA). The enforcement powers would most likely be given to the FTC under Section 5 off the FTC Act, similar to how the FTC now brings actions against organizations for unfair and deceptive trade practices. Any Federal legislation resulting from this should preempt any state laws to the extent they are inconsistent with the Federal law.

Time will tell if the plan will advance privacy legislation and improve consumer protection, but it is already an improvement of anything we have seen come down from Capitol Hill – which is nothing. If this indeed moves forward, the next step will be gaining recognition by the EU, but forgive me if I don’t hold my breath on this just yet.

More to come on this topic as it develops.