Kenna: RISK-BASED VULNERABILITY MANAGEMENT

456

Why You Should Consider More Than CVSS
As previously mentioned, one typical method of sorting and prioritising which vulnerabilities to fix first is patching vulnerabilities that have a CVSS score in a specific range. However, using CVSS scores to rank vulnerabilities has some built-in issues. It’s a static scoring method, to start. Prior to any exploits being written against them, the majority of the vulnerabilities on MITRE’s Common Vulnerabilities and Exposures (CVE) list are given a CVSS score within a few weeks of their discovery. As a result, they are scored based on their initial assessment of their potential for exploitation and are rarely, if ever, updated.
The lack of any context in CVSS is another significant problem. In other words, the scores are created using the code itself, and and the possibility of abusing it. The prevalence of the vulnerability in actual network environments, the availability of exploits against them, or any other contextual information necessary for the security analyst to fully comprehend the level of risk are not taken into account. A CVE is given a low CVSS score if the initial evaluation of that CVE finds that it poses a low risk. The CVSS score will remain at its initial low level even if dozens of exploits are published against it months later, some of which may even result in hundreds of successful security events.

We are all aware of how challenging vulnerability management is. Yet why? And how can security, IT, and DevOps be made simpler for everyone?

This guide offers a method to help teams concentrate on what really matters in order to make vulnerability management, well, more manageable. to use their time wisely and effectively and to produce tangible results that can be measured as compensation for their efforts. Adopting a risk-based approach to vulnerability management is crucial in this situation. We’ll walk you through six essential steps to get you started with a risk-based vulnerability management programme in the paragraphs that follow. But first, let’s examine some of the drawbacks of conventional methods, which aid in explaining why vulnerability management is frequently so challenging. Overwhelming Vulnerabilities Exist, and Millions of vulnerabilities exist in the average enterprise, and they are continually being discovered (Figure 1) This poses a standard conundrum for the majority of organisations: There is an endless supply of work and not enough people to complete it all. The task quickly becomes overwhelming, and it is likely impossible to ever catch up when this enormous amount is combined with the well-known cybersecurity staffing shortages and the fact that the average organisation can only remediate one out of every ten vulnerabilities in their environment in any given month. The fact that security goals sometimes conflict with business goals is another problem that organisations frequently face with vulnerability management. IT and DevOps teams frequently work on mission-critical or revenue-generating applications and services as part of their “day jobs.” Giving someone a list of 10,000 vulnerabilities without any context is at best demotivating. Many times, The burden falls on the asset owners to identify which vulnerabilities related to the device or application fall under their purview, and then to establish a timeline for remediation based on whether the vulnerability is rated as high, medium, or low priority by the Common Vulnerability Scoring System (CVSS), the scoring provided by the vulnerability scanner, or the outcomes of the application security test. It’s a time-consuming process that’s frequently done manually with little understanding of the degree of risk the vulnerability poses to the organisation. To help asset owners understand why fixing a specific vulnerability quickly is crucial and why some vulnerabilities can wait until they have time to fit remediation into their regular work schedules, context is required. The truth is that any one of these countless flaws has the potential to be exploited with some level of impact—might be high, might be low, but one thing is for sure: nobody can fix them all. Because of this, it’s crucial to understand which vulnerabilities are actually at risk of being exploited and which ones are not. Fortunately, data is available to assist, and as a result, you don’t need to fix all of them right away. Statistics show that only 2–5% of vulnerabilities (more specifically, CVEs) are actively exploited in the wild. This means that your security and IT teams can prioritise just the vulnerabilities that pose the greatest risk by deprioritizing the majority of your vulnerabilities. The real issue is how to find these riskiest of vulnerabilities so that you can fix them at the right time.

7 Reasons Why Risk-Based is Superior to Other Vulnerability Management Strategies

1 You can’t remediate everything, and don’t need to, but can remediate the riskiest stuff

2 Not all assets or applications are created equal

3 You can get the full picture from multiple feeds and tools

4 You can take advantage of automation

5 You get the ability to report to management on something they actually care about—risk

6 It avoids being distracted by the hype around high-profile breaches

7 A risk-based approach increases collaboration among all teams

Companies can effectively manage the appropriate level of risk for their operations with Kenna Security. By providing clear prioritisation based on real-time threat intelligence and recommendations applied to each customer’s unique environment across infrastructure, applications, and IoT, our modern vulnerability management model eliminates the friction between Security and IT teams regarding what to patch.