What vulnerabilities were malicious actors focused on in 2022?
A look at the CISA 2022 Top Routinely Exploited Vulnerabilities Report and how to protect yourself moving forward
One of the best ways to mitigate risk and insulate your organization from malicious actors is to understand where they’re focusing their time and attention as well as leveraging recommended practices to avoid becoming a victim.
That’s why we’re taking a look at the recently published CISA 2022 Top Routinely Exploited Vulnerabilities report.
The report details the Common Vulnerabilities and Exposures (CVE’s) routinely and frequently exploited by malicious actors in 2022 and their associated Common Weakness and Enumerations (CWE’s).
Key Findings
While the report provides a list of the top routinely exploited vulnerabilities, we won’t spend much time there, as the intent of this article isn’t to hyper focus on any specific vendor or product but instead to focus on the recommended broad mitigations and practices that help mitigate risk from malicious actors activities.
That said, below is a great image from my friend Patrick Garrity of Nucleus Security which visualizes the top 42 vulnerabilities per the report across the various vendors and their associated products and is a quick way to summarize the findings.
A quick look at these findings should come as a surprise to no one who has been watching the industry closely, in terms of headlines, exploitation and common offenders when it comes to exploitation. Microsoft of course had nearly 3x as many as the second runner up, and they also tend to hold the top spot on the CISA Known Exploited Vulnerability (KEV) catalog.
In fact, they are in the headlines the past weeks due to a widespread incident involving malicious actors from China and vulnerabilities in Microsoft Exchange that were exploited and impacted industry along with Government, leading Sen. Ron Wyden to pen a letter to CISA and the Attorney General, asking that actions be taken against Microsoft for “negligent cybersecurity practices”.
We now have seen the Department of Homeland Security (DHS) come out and announce last week that the newly formed Cyber Safety Review Board (CSRB), which is made up of various cybersecurity experts and leaders will conduct a review of the recent incident along with broader concerns around identity and cloud computing due to its widespread systemic risk. This will make it their third investigation, with the first being on Log4j and the second being on the cyber crime group Lapsus$.
All that aside, as I mentioned, this article isn’t focused on pointing fingers at any particular vendors or products, and instead is aimed at looking at the specific recommendations in the CISA publication for mitigations aimed at both vendors, developers and end user organizations, so lets shift there.
Mitigations - Vendors and Developers
In the context of software vulnerabilities and software supply chain security, vendors and developers represent suppliers, and as echoed in sources such as the Cyber EO, and recently published National Cybersecurity Strategy (NCS), are best positioned to address vulnerabilities, so let’s hope they heed these recommendations, although it is worth noting sources such as CISA and the CSRB are not regulatory authorities, so these are recommendations, not requirements, unless of course you’re a software supplier selling to the Federal government, and under the purview of publications such as OMB memos 22-18 and 23-16, which we have previously discussed in depth here and here respectively.
The CISA publication recommends vendors and developers take some key steps, which are:
Identify repeatedly exploited classes of vulnerabilities.
The theme here is to ensure that common occurring CVE’s as well as frequently exploited ones are given proper emphasis to drive them down and potentially eliminate them altogether.
Ensure business leaders are responsible for security.
This one is a huge one in my opinion because it emphasizes a reality that many of in cyber have known for a long time, which is cybersecurity does not own the risk. We are here to equip the business to make risk informed decisions, and the business is the ultimate risk owner.
Of course, this reality doesn’t stop entities such as the CISO from taking the fall and being fired when an incident occurs, regardless of if they did their due diligence, informed the business of the risk and the business pressed on anyways.
Perhaps this is why we continue to hear calls for cybersecurity in the board room, but I digress - all of this aside, the business owns the risk and is accountable for security, and must take measures to eliminate classes of repeat vulnerabilities if possible.
Follow the Secure Software Development Framework (SSDF).
If you are developing software and digital products and aren’t familiar with the SSDF by now, you should be. SSDF is a publication from NIST that cross-maps to various industry sources such as OWASP SAMM, BSIMM and others that deal with secure software development. We discussed SSDF extensively in a previous article, which can be found here.
It comes as no surprise to see CISA and the Government endorse and advocate for SSDF here, given they are already pushing for software suppliers selling to the Federal government to self-attest to following SSDF practices and despite being used in the Government context, SSDF is a great resource for companies developing software and products in the commercial space as well. CISA emphasizes a subset of SSDF practices in particular, which are:
Using memory safe programming languages (e.g. Rust).
Exercising due diligence when selecting software components such as libraries and modules, which is a nod for organizations to be responsible for the OSS components they integrate into their products and software.
Utilizing secure development team practices such as peer code reviews, secure coding standard and security awareness and training among developers.
Establishing a Vulnerability Disclosure Program (VDR).
Utilizing SAST and DAST tools to analyze product source code and eliminate vulnerabilities.
Configuring production-ready products to have secure settings as a default, which is a specific call out in the CISA “Secure-by-Design/Default” publication, which we discussed in a previous article here.
Ensuring publicized vulnerabilities/CVE’s have a proper CWE field identified so the root cause of the vulnerability due to security and design flaws can be addressed.
End-User Organizations
In the context of software supply chain security, End-User Organizations represent downstream customers and consumers. These may be enterprise organizations, SMB’s or even individuals although the guidance is aimed at primarily formal organizations.
The guidance breaks down recommendations for end-user organizations into sub-categories, so we will do the same.
Vulnerability and Configuration Management
Update software, operating systems, applications, and firmware on IT network assets in a timely manner.
This one should come as no surprise to anyone working in cybersecurity, as it is a longstanding best-practice. However, the guidance does emphasize activities such as prioritizing Known Exploited Vulnerabilities (citing the CISA KEV), and specifically emphasizes prioritizing the vulnerabilities this report laid out in the earlier sections that we captured in the image.
It also recommends prioritizing based on organizational environmental factors, such as Internet facing assets, as well as implementing mitigating controls if a patch isn’t available or can’t be applied immediately.
If software is end-of-life or no longer supported from a vendor, organizations should look to modernize their environments, although this is often easier said than done, with legacy systems existing long after support has ended, especially in some communities such as the DoD and Critical Infrastructure which traditionally have longer tech refresh cycles.
Routinely perform automated asset discovery
Here we have another longstanding cybersecurity best practice, cited in sources such as the CIS Critical Security Controls with Hardware/Software Asset Inventory being among the top cited controls for years but being on organizations have long struggled with.
The emphasis here on automation is key, as performing these activities manually is error prone and often impractical in the modern dynamic, ephemeral nature of cloud computing and cloud-native technologies such as SaaS, Kubernetes/Containers, and API’s.
Implement a robust patch management process
One of cybersecurity practitioners favorite roles is being responsible for patch management (I kid, it is a never ending grind due to constantly emerging vulnerabilities, software updates and patching cycles).
That said, it is a necessary evil and one that if not prioritized could leave organizations ripe for exploitation with outdated software with known vulnerabilities sitting in their environments, which is often the case, as pointed out by industry experts such as Cyentia Institute who found an average organization only has the capacity and capability to remediate 1 out of 10 vulnerabilities in their environment within a given month, meaning the vulnerability backlog continues to grow exponentially as organizations fail to tame it. The below image is discussed in a post from Wade Baker, Ph.D. of Cyentia here.
One key recommendation also emphasized here by CISA is for organizations to consider outsourcing services to mature, reputable Cloud Service Providers (CSP)’s and Managed Service Providers (MSP)’s if they are unable to perform rapid scanning and patching of internet-facing systems themselves.
This of course represents a double edged sword, because on one hand it enables organizations to outsource responsibilities to CSP’s under the cloud Shared Responsibility Model and instead focus on their own core competencies and delivery value to stakeholders, but it of course also presents its own unique risks, especially as malicious actors increasingly target CSP’s and MSP’s due to their concentrated target rich nature - remember how we opened this article discussing a recent incident that impacted industry and government alike, all via a CSP.
We’re also seeing sources such as The Atlantic Council, Cyberspace Solarium Commission and others point out that CSP’s are becoming “too big to fail” and represent systemic risks to the broader digital ecosystem due to the widespread dependencies that SMB’s, Enterprises, Governments and broader society have on them.
Document secure baseline configurations for all IT/OT components
This one recognizes the role of secure configurations and baselines, given how often not just vulnerabilities but misconfigurations and insecure configurations play a role in exploitation by malicious actors, especially in the cloud, where it is often stated that through 2025, 95%+ of cloud security incidents will be due to customer misconfigurations.
Perform regular secure system backups
As any organization that has fallen victim to ransomware knows, having good known backups is absolutely critical. CISA recommends backing up not just system storage by also device configurations for restoration and storing the copies off the network in physical secure locations and most importantly, actually testing the integrity and restoration capabilities of those backups regularly. The last thing you want is to not test and then end up needing the backups only to find out they don’t function as desired.
Maintain an updated cybersecurity incident response plan (IRP)
Rounding out the vulnerability and configuration management section for end user organizations is the recommendation to have an IRP in place. Much like backups, this is not something that just should be shelf-ware but actually be exercised and tested on a regular basis.
While organizations often opt for tabletop exercises which are often hypothetical subjective thought exercises, we’re increasingly seeing a push for security chaos engineering, as championed by leaders such as Kelly Shortridge, who wrote a book on the topic titled “Security Chaos Engineering: Sustaining Resilience in Software and Systems” which emphasizes moving beyond talk and actually testing the resilience of our systems and organizations, including the ability to respond to incidents.
Identity and Access Management (IAM)
Moving beyond vulnerabilities and configuration the next section is IAM. The importance of IAM cannot be emphasized enough, especially as we shift from a legacy network perimeter-based approach to cybersecurity to one that is identity and data-centric. The notable cloud security incident with Microsoft Azure that we opened the article with involved the compromise of the underpinnings of cloud identity in Microsoft Azure’s cloud service offering. Recommendations include:
Enforcing phishing-resistant multi-factor authentication (MFA)
This one is increasingly gaining traction, being emphasized in emerging guidance like the Federal Zero Trust strategy as well as CISA’s Zero Trust Maturity Model (ZTMM). This often involves moving beyond SMS-based MFA and utilizing options such as Yubikeys, which prevent low-level malicious activity that can undermine MFA implementations using tactics such as SIM swapping.
Enforce MFA on all VPN connections
This one seems like an odd recommendation, given we’re seen VPN technologies phased out for more modern approaches such as Software Defined Perimeter (SDP) and so on. That said, CISA’s guidance recommends enforcing MFA on VPN connections for remote employees and if MFA isn’t supported at a minimum enforcing a strong UN/PW requirement.
Regularly review, validate, or remove privileged accounts
Implementing least-privileged principles is one thing, however it isn’t uncommon for dormant privileged accounts to sit vacant, long after employees move on to another business unit, role, or leave the organization altogether. These vacant/dormant privileged accounts represent ripe targets for malicious actors to compromise and abuse. This applies in cloud environments such as IaaS or SaaS as well.
Configure access control under the principle of least privilege
Here again we have a longstanding security best-practice recommended however, as anyone who has worked in large complex dynamic environments know, doing this at-scale and sustaining longstanding least-privilege access control can be challenging.
That said, given sources such as the Verizon DBIR routinely cite compromised credentials near the top of the list of attack vectors, it is clear that overly privileged accounts represent a significant threat that malicious actors can use to compromise environments and often move laterally to wreak havoc. CISA provides this resource for additional guidance on implementing MFA.
Protecting Controls and Architecture
In this next section we see key recommendations around internet-facing network devices, implementing a Zero Trust Network Architecture (ZTNA) and the role of Continuous Monitoring (ConMon), to identify not if, but when something goes awry.
Properly configure and secure internet-facing network devices
We’ve discussed in this article as well as elsewhere how malicious actors prioritize internet-facing devices, and you should too from the defensive perspective. Malicious actors routinely use tools such as Shodan to scan for internet-facing devices with known vulnerabilities to exploit.
Recommendations here include disabling unused ports and protocols which limits the attack surface, encrypting traffic and implementing governance around the use of commonly exploited network services and scripting applications, all of which can be leveraged by attackers.
Implement Zero Trust Network Architectures (ZTNA)
This recommendation should come as a surprise to absolutely no one in the cybersecurity community, as we see the push for Zero Trust from sources such as the Cyber EO, Federal and DoD Zero Trust strategies, and from industry organizations such as Cloud Security Alliance (CSA).
ZTNA helps block lateral movement, mitigate the blast radius of incidents and removes implicit trust. These concepts on the surface seem easy but in large complex constantly changing environments with a myriad of tools, business units and stakeholders, it is increasingly daunting.
For those looking to learn more about ZT I recommend sources such as “Zero Trust: An Enterprise Guide” by Jason Garbis and Jerry Chapman and for a novel-esque approach similar to the DevOps “Phoenix Project” I recommend George Finney’s “Project Zero Trust: A Story about a Strategy for Aligning Security and the Business”.
Continuously monitor the attack surface
There’s a longstanding phrase in cybersecurity which is “it’s not a matter of if, but when”, and this points out that nearly all organizations operating in our digital reality will inevitably fall victim to malicious cyber activities.
This is where the role of Continuous Monitoring (ConMon) comes into play, and I am not talking about the legacy compliance paperwork ConMon of annually monitoring paper-based controls, but near real-time technical telemetry from your systems and environments that can alert you to potentially malicious activity.
CISA recommends resources such as endpoint detection and response (EDR) and aggregating alerts and logs to tools such as security information and event management (SIEM)’s. They also recommend implementing tools such as web application firewalls and network protocol analyzers to both monitor and block malicious activity to web applications and perform packet-level analysis to get insights into malicious network level traffic.
Supply Chain Security
Last but not least, one of my favorite topics, and one I wrote a book on titled “Software Transparency: Supply Chain Security in an Era of a Software-Driven Society”, is the section on Supply Chain Security. Unfortunately it does come last in the guidance and is the lightest section, but nonetheless, I am glad to see it listed. Let’s take a look at the recommendations here.
Reduce third-party applications and unique system/application builds
This one, like all of the other end-user specific recommendations ties to a “Cross-Sector Cybersecurity Performance Goals March 2023” document from CISA. This particular recommendation deals with implementing administrative or automated processes before installing new software, libraries or components.
However, as most who have worked in modern software development environments know, it is incredibly difficult to centrally govern this activity across scale across hundreds or thousands of developers and development teams without grinding productivity to a halt.
Luckily, new vendors are emerging to help Developers select vetted/secure OSS components for example, such as Endor Labs and others. These leaders are helping enable secure OSS consumption by empowering developers to understand the risks of the OSS components they ingest and integrate into their products or services, which ultimately get to downstream consumers or utilized in internal applications and software. Providing context such as known vulnerabilities, licensing concerns, outdated/unmaintained software and other leading OSS risks to developers helps mitigate toil and also address pervasive software supply chain concerns. This sort of control is often cited in other software supply chain guidance such as that from Microsoft and OWASP as well.
Ensure contracts require vendors or third party software/service providers to provide notification of security incidents and vulnerabilities in a risk informed time frame and also provide SBOM’s for all products to enhance vulnerability monitoring.
This recommendation ties to others such as ensuring vendors have a vulnerability disclosure program (VDP) in place and are actively communicating with downstream consumers regarding incidents and vulnerabilities, as this positions consumers to understand their current risk landscape and ongoing malicious activity.
I’ve written extensively about SBOM’s and their various formats in articles such as this one at CSO Online and for those looking to learn more about SBOM, I recommend resources from CISA and NTIA, which help lead SBOM efforts for the Government.
SBOM’s are essentially ingredient labels/lists of nested components in software and applications that suppliers can produce and provide to consumers so there is transparency around the components and their associated risks.
While these artifacts are increasingly being required in Federal/DoD environments, we’re seeing tremendous SBOM traction in industry as well through sources such as The Linux Foundation, OpenSSF and OWASP and their CycloneDX project.
Ask your software providers to discuss their secure by design program
CISA recommends end-user organizations ask software suppliers to discuss their “Secure-by-Design/Default” programs and provide information how the vendors are working to remove entire classes of vulnerabilities and to set secure default settings.
While I love the thought process here, given the Secure-by-Design/Default” effort is just recently reinvigorated by CISA, I imagine most vendors won’t have a formal program in place and will be caught flat footed with these sort of inquiries aside from perhaps the most robust and mature suppliers in the market. Also as I have touched in articles such as “Cybersecurity First Principles & Shouting Into the Void” and “The Elusive Built-in not Bolted on”, although the concept of “Secure-by-Design” has origins dating over 50 years back to The Ware Report, the concept has never seen full blown adoption by industry since most software suppliers are driven by market incentives such as profit, speed to market, market share and maximizing ROI, rather than maximizing the security and safety of products.
We’re unlikely to see these principles fully adopted by industry until either market incentives change, or regulatory pressures force broad changes. Given many consider cybersecurity to be a market failure that won’t resolve itself voluntarily, it is unlikely we see it occur until regulatory changes force it to.
Now What?
My hope with authoring this article is that both software suppliers (e.g. Developers/Vendors) and end-user organizations (e.g. software consumers/customers) can use these recommendations to bolster their security hygiene and mitigate the potential risk to their organizations, operations and stakeholders. Insights such as these from CISA are valuable because it shows you what malicious actors are most focused on, and as security practitioners and defenders, we should also focus our time on where the malicious actors are focusing theirs.
Yet another great write to, Chris!