blog

Vulnerability management the impact of the new CISA directive 22-01

CISA 22-01 Mandate resolution timeline for vulnerabilities

Vulnerability management has been lagging a bit behind, but recent, the US government has ramped up several regulations. 

Vulnerability resolution time and prioritization of specific vulnerabilities have driven much-needed changes in this field. 

Since 2021, with the appointment of a new director, the U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) has been making a name for itself with big moves like its new “Hack DHS” bug bounty program and the creation of a cybersecurity advisory committee made up of industry representatives.

July 2021 CISA “Cyber actors continue to exploit publicly known—and often dated—software vulnerabilities,” 

CISA has introduced CISA directive 22-01 that takes more drastic action on the vulnerabilities that need to be addressed. 

Now the policy does not mandate resolution time but is strict on executing a plan for internal vulnerability management procedures.

a. Establish a process for ongoing remediation of vulnerabilities that CISA identifies, through inclusion in the CISA-managed catalogue of known exploited vulnerabilities, as carrying significant risk to the federal enterprise within a timeframe set by CISA under this directive;

Without tracking those metrics is difficult to know which asset is falling behind patching or resolution. 

This resolution follows the previous order by the White House on software security and supply chain management. Executive order on Improving the Nation’s Cybersecurity. 

This binding operational directive (BOD) is mandatory for all U.S. “federal civilian agencies” to solve the problem and reduce U.S. government exposure to today’s swarm of vulnerabilities.

The challenge is that CISA directive does not specify context or risk vulnerability resolution. It just mentions the resolution plan.

The common vulnerability actions are specified in the KEV repository (known exploited vulnerabilities). https://cisa.gov/known-exploited-vulnerabilities 

The smart teams are already focusing on prioritizing vulnerabilities with resolution time technologies like EPSS and other Cyber Threat intelligence to focus on the more exploitable vulnerabilities.

Relax. In this post, we’ll cover everything you need to know about CISA directive 22-01, with some guidelines on prioritising vulnerabilities and keeping the focus on team burnout and compliance.

What Does CISA Directive 22-01 Say?

What Does CISA Directive 22-01 Say?

CISA was formed in 2018 to “lead the national effort to understand, manage, and reduce risk to our cyber and physical infrastructure.” CISA focuses on collaboration and disclosing which vulnerabilities are more exploitable under the KEV; nonetheless, the procedures under which the new vulnerabilities are integrated and deprioritized are obscure. 

This latest BOD is an add-on to the earlier BOD 19-02, which called for an increased effort toward vulnerability remediation: “[I]t is more critical than ever for federal agencies to rapidly remediate vulnerabilities that otherwise could allow malicious actors to compromise federal networks through exploitable, externally-facing systems.”

The BoD is also known as “Reducing the Significant Risk of Known Exploited Vulnerabilities” and is the first CISA attempt to tackle prioritization under the mostly exploitable Vulnerabilities. 

Is the high exploitation factor the only factor you should consider when analysing which vulnerabilities to fix? 

Is one of the elements, but not the only one; some examples to consider are:

Probability of exploitation

  • The severity of a vulnerability (CVE, CWE, CVSS and CWSS)
  • The locality of an asset, also known as Context
  • Exploitability of a vulnerability, based on the availability of Proof of concept or code snippet
  • Probability of an attacker targeting the vulnerability
  • Active exploitation of the vulnerability from threat actors groups 
  • Discussion on Twitter, Linkedin, Reddit and other forums
  • The freshness of vulnerability (in the first 40 days, vulnerabilities are exploited/targeted more frequently) 

Nonetheless, the BOD 19-02 only focuses on the known exploited vulnerabilities. catalog of about 300 “known vulnerabilities,”. BOD 19-02 and 20-02 are a move forward with more due diligence when handling high-risk vulnerabilities and putting some governance around resolution time. 

Companies that do business with the U.S. government need to remediate any listed vulnerabilities by the corresponding due dates (which are set according to the date the vulnerability was discovered and its severity). 

CISA plans to update this list from time to time as due dates pass and new vulnerabilities emerge.

Additionally, all compliant organizations must report their progress to CISA as they work toward these deadlines.

Organizations failing to comply by the due dates listed will presumably face administrative penalties and potentially lose important U.S. government contracts. But the repercussions go much further—and could affect you no matter your industry.

Vulnerability remediation plan and do You Need to Comply with CISA Directive 22-01?

The answer is probably yes at a certain point in time. With UK and USA ties strengthening and CISA opening a new office in the UK there is a high chance that the NCSC will start mandating the same form of regulatory compliance. 

The short answer to this question is you probably don’t unless you’re working for the U.S. government. But in reality, you probably shouldn’t ignore it, either.

According to CISA, this BOD 22-01 “applies to all software and hardware found on federal information systems managed on agency premises or hosted by third parties on an agency’s behalf.” This includes the federal and executive branch departments and agencies of the United States.

But the U.S. government is also strongly recommending this standard even for private businesses, as is clear from CISA director Jen Easterly’s tweet: “The BOD applies to federal civilian agencies; however, ALL organizations should adopt this Directive and prioritize mitigating vulnerabilities listed on our public catalogue, which are being actively used to exploit public and private organizations.”

The Tweet makes sense but also highlights the focus and overwhelm on any exploitable vulnerability regardless of where it is. A less likely vulnerability not on the CISA list or cloud misconfiguration might be as dangerous, if not more dangerous, depending on where it manifests. 

Nonetheless, this regulation is a step forward to focus on what’s more important to fix first. 

  • The vulnerability exploited in the wild is real. Even if you are not doing business with the US government, one of those vulnerabilities will likely be exploited. 
  • You may need to comply soon. Other governments and large enterprises will likely follow CISA’s lead and make complying with BOD 22-01 or similar standards mandatory for doing business with them. This might include NCSC and other Cyber essential regulations in the UK
  • Prioritization of Exploitability is not the only factor: prioritizing based on exploitability alone is not the only factor, and the list is static. The risk of vulnerabilities is dynamic and changes over time see Vulnerability Prioritization Blog here 

Even if you don’t have to comply, you definitely should. And it may be simpler than you think.

How can you prioritize vulnerabilities and prevent burnout from CISA Directive 22-01?

The U.S. government has put BOD 22-01 in place because today’s businesses are struggling to keep up. The reason is simple, there is no contextual monitoring of vulnerabilities and teams are stretched. 

This regulation takes us a step further in due diligence and prioritization for Vulnerabilities.

According to a CISA report, “Focusing scarce cyber defence resources on patching those vulnerabilities that cyber actors most often use offers the potential of bolstering network security while impeding our adversaries’ operations.” 

Patching is the first line of defence, but don’t forget other vulnerabilities and misconfiguration comes in place. 

That’s easier said than done. Patching, remediating vulnerability at scale and deciding which vulnerability to fix first can be difficult, regardless of the mandated compliance. 

CISA also has new Cybersecurity Incident and Vulnerability Response Playbooks, explaining, “Existing patch and asset management tools are critical and can be used to automate the detection process for most vulnerabilities.” 

Threat intelligence and automation can greatly help in fixing vulnerabilities. 

It also introduces the concept of Business criticality in vulnerability remediation. 

Risk and remediation are probably the best tools to select which vulnerability to solve. 

Risk = Probability (Likelihood of exploitation, Locality)  * Severity * Impact 

For more details on leveraging risk-based contextualization and prioritization to tackle CISA KEV mandated and other vulnerabilities and misconfiguration, refer to WHY PRIORITIZE VULNERABILITY? A CASE FOR RISK AND CONTEXTUAL-BASED PRIORITIZATION FOR APPLICATION SECURITY AND CLOUD SECURITY

Phoenix Security has introduced auto-tagging and automatic selection of KEV-mandated CISA vulnerabilities. 

Leveraging threat intelligence and business impact assessment also easy to prioritize automatically the vulnerabilities that matter most. 

In other words, automation and intelligent patching are crucial to meet evolving modern regulatory standards like CISA’s BOD 22-01.


Get a demo today: https://staging-appsecphoenixcom.kinsta.cloud/demo/ 

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Explore the interplay between the MITRE ATT&CK framework and EPSS for effective vulnerability management. Learn how these tools help predict and prioritize cyber threats, with deep dives into the most and least exploited techniques. Stay ahead in cybersecurity with Phoenix’s advanced analysis.
Francesco Cipollone

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.