| | JULY - 2023ENTERPRISE SECURITY8IN MY OPINIONIN MY OPINIONMore than 20 years ago, David Mann and Steven Christey proposed the idea of a Common Vulnerability Enumeration (CVE) in their seminal work, Towards a Common Enumeration of Vulnerabilities (1998). When the CVE was adopted by MITRE shortly thereafter, the meaning changed slightly to: "Common Vulnerabilities and Exposures." This shift NAVIGATING THE STORM OF CVESBy Yonesy Núñez, Chief Information Security Officer, Jack Henryin nomenclature has a powerful lesson to teach us about vulnerability management decades later. Namely, not all bugs are created equal, nor does every bug render a system the same level of "vulnerable." In fact, flaws without a corresponding threat are not a vulnerability at all; they are technically just an exposure (as was passionately articulated to the MITRE committee by self-described pedant, Gene Safford, years ago).In 1998, there were a few hundred vulnerabilities assigned a CVE. In 2021, the volume of disclosed vulnerabilities is surging by comparison: nearly 20,000 unique bugs were discovered in a single year. Not to mention, the modern enterprise has other vulnerability data to contend with as well such as the data from penetration tests, application security tools, open-source dependency graphs, etc. This data doesn't even come with a CVE to help track it, but it competes for your remediation team's finite attention, nonetheless.Patching every bug is logistically impossible for most organizations. And even if it is operationally feasible, it's still likely inappropriate and cost-prohibitive. It may sound noble to try to remediate each deficiency, but the reality is only a very small percentage of all vulnerabilities will ever be adopted by threat actors and used in a real-world cyber-attack (approximately 2 percent). The wasted effort of remediating all vulnerabilities presents an opportunity cost to the business, not to mention, remediation may introduce the risk of system instability.Pinpointing which vulnerabilities carry substantial risk and thus deserve prompt remediation may seem daunting at first, but it's a relatively straightforward data science problem. Let's briefly discuss what kinds of factors best predict when a vulnerability will be weaponized.First, it's best to start with a strong foundation. Consider the intrinsic attributes of the vulnerability itself--Is it remote exploitable? Does the exploit require user interaction? Does the impact extend beyond the scope of the vulnerable component? etc. Next, evaluate the maturity of proof-of-concept exploits for the vulnerability--Are the technical details of the bug known? Is there a working script to detonate the vulnerability on common repos like Github or ExploitDB? How much effort would it take the publicly available resources and craft those into a bonafide exploit suitable to be used in a real-world incursion? What Yonesy Núñez
< Page 7 | Page 9 >