Data center: Ashburn, VA

Telegram Chat : MBHH_x86

Email Us: Help@mobilehackerforhire.com

Mobile Hacker For Hire

3 Lessons Learned in Vulnerability Management

Table of Contents

As we pass the first anniversary of the Log4j vulnerability disclosure, it’s a timely reminder that when a vulnerability is serious, it deserves our utmost attention. Organizations taking vulnerability disclosure more seriously is a net positive for the industry, especially because patching is so vital for basic cyber hygiene and accountability.

But, when a vulnerability is overblown or overpromoted, it can misguide the security community and distract from other more serious incidents — or cause other serious problems, like alert fatigue.

As public vulnerability disclosure becomes more commonplace for researchers, vendors, and the broader security community, the question of “when to panic or not panic?” is important. Here are some key lessons for approaching vulnerability management.

1. Distinguish Between Noise and Necessity

For security experts and the media alike, it’s imperative to determine when something is critical and when an issue might be overblown. According to research, the Log4j vulnerability Log4Shell could potentially impact 72% of organizations, and it was coined an “endemic vulnerability” by the US Cybersecurity and Infrastructure Security Agency.

Months later, the Text4Shell vulnerability was disclosed. Media and researchers alike wondered if it was “the next Log4Shell.” But the vulnerability was proven to have a much lower impact and was much less severe.

This is one example of a gray area between ensuring something is well-broadcast and its actual impact. Being able to make this distinction can help prevent alert fatigue, which has been associated with security staff burnout and is costly to a company due to direct expenditures spent responding to these alerts, including initial triage.

In another case, if a vulnerability is originally thought to be more severe, it could be overblown. For example, a vulnerability in OpenSSL disclosed in December generated significant attention due to the ubiquity of OpenSSL inside many products to enable Transport Layer Security (TLS).

This one may have been overhyped because of the last significant vulnerability in the software in 2014: Heartbleed. Given this past, when it was announced that the new vulnerability’s severity level was critical, people were understandably concerned.

But the hype around the latest OpenSSL vulnerability turned out to be kind of a non-event. At the time of release, the two CVEs (common vulnerabilities and exposures) were downgraded from critical to high. This hype wound up being a distraction because it actually led to a more complicated ConnectWise vulnerability being under-covered. The ConnectWise vulnerability had the potential to be more harmful and impact nearly 5,000 servers.

2. Communicate and Mitigate Risk

Communicating risk will always have to be a collaborative effort because it happens in so many channels. Organizations post on their own websites and forums, the government issues bulletins, and the InfoSec community is particularly active on social media — researchers sometimes “scoop” vendors before they can release details about the vulnerability or mitigations themselves.

Often, there exists an educational gap between deeply technical security researchers and IT professionals and the broader business community. This disconnect results in organizations not knowing the right steps to take when a vulnerability is publicly disclosed.

3. Follow the Data

The Common Vulnerability Scoring System provides a qualitative measure of the severity of cybersecurity vulnerabilities, and ratings can range from 0 to 10. It is one resource that can help us compare the vulnerability at hand to the rate of “noise” in the community. Leaning on data and hard numbers can help ensure we’re paying attention to what really matters.

There are other risk-scoring models to help organizations prioritize vulnerabilities. To address the specific needs of cyber-insurance underwriting, Coalition offers the Coalition Exploit Scoring System (CESS) to help organizations prioritize vulnerability mitigation. CESS is powered by a set of machine learning models that assign severity scores to vulnerabilities based on multiple features — the description, social mentions, incident data, honeypot exploitation, and similarity to previous vulnerabilities — and measures the potential, or how likely it is, that attackers will actually exploit the CVE. This way, organizations can prioritize responses and resources according to their threat level.

Think of the CESS score as a percentile regarding severity and likelihood of exploitation. Our threshold of deeming an exploit “critical” is 0.7 or 70%. For example, CESS ranked the new OpenSSL vulnerability as 0.66 in our percentile scale, with a 1.0 being 100%. Our threshold for significance to notify policyholders is 0.7 or 70%. This slight 0.4 decile difference is actually really helpful in understanding the thousands of vulnerabilities that exist and helps cut through the noise of the hundreds publicized daily. Coalition uses CESS to prioritize which vulnerabilities policyholders should address first based on a two-pronged data approach: which vulnerabilities are the most severe and which are most likely to be exploited. Other security organizations will likely implement similar data-driven risk-scoring systems.

How Vendors Fit In

Vendors have a role to play in ensuring customers have a trusted source, whether communicating vulnerability severity scores or providing a balanced perspective with clear mitigation advice and updates. Vulnerability management is twofold, and the onus to resolve issues is just as much on the vendor side to communicate them properly as on the organization side to patch them efficiently.

All organizations have a responsibility when it comes to incident response and vulnerability management. Spending time educating on the technicality of how a vulnerability works and the potential exposure around technologies vulnerabilities often target can go a long way in seeing trouble before it starts.

Not everything is the “next Heartbleed” or “next Log4shell,” but having the right resources in place can ensure we are ready for new security challenges without being distracted by the newest shiny object.

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!