Breaches are occurring at a record pace, botnets are consuming IoT devices and bandwidth, and the cloud is becoming a de-facto standard for many companies. Vulnerabilities are often found at the intersection of all three of these trends, so vulnerability and risk management has never been a greater or more critical challenge for organizations.
Vulnerabilities come in all shapes and sizes but one thing that stays constant – at least in computer security - is that a vulnerability is a weakness which allows an attacker to reduce a system’s information assurance. It is the intersection where a system is susceptible to a flaw; whether an attacker can access that flaw; and whether an attacker can exploit that flaw within the system. For F5, it means an issue that results in a confidentiality, integrity, or availability impact of an F5 device by an unauthorized source. Something that affects the critical F5 system functions - like passing traffic.
You may be familiar with CVE or Common Vulnerabilities and Exposures. This is a dictionary of publicly known information security vulnerabilities and exposures. Each vulnerability or exposure gets a name or CVE ID and allows organizations to reference it in a public way. It enables data exchange between security products and provides a baseline index point for evaluating coverage of tools and services. MITRE is the organization that assigns CVEs. There are also CVE Numbering Authorities (CNA). Instead of sending a vulnerability to MITRE for numbering, a CNA gets a block of numbers and can assign IDs as needed. The total CVE IDs is around 79,398.
Most organizations are concerned about CVEs and the potential risk if one is present in their environment. This is obviously growing with the daily barrage of hacks, breaches and information leaks. Organizations can uncover vulnerabilities from scanner results; from media coverage like Heartbleed, Shellshock, Poodle and others; or from the various security related standards, compliance or internal processes. The key is that scanning results need to be verified for false positives, hyped vulnerabilities might not be as critical as the headline claims and what the CVE might mean for your compliance or internal management.
For F5, we keep a close eye on any 3rd party code that might be used in our systems. OpenSSL, BIND or MySQL are examples. For any software, there may be bugs or researcher’s reports or even non-CVE vulnerabilities that could compromise the system. Organizations need to understand the applicability, impact and mitigation available.
Simply put: Am I affected? How bad is it? What can I do?
For Impact, there are a couple ways to decide how bad it is. First, you can look at the severity of the vulnerability - is it low, medium, high or critical. You can also see if there is a Common Vulnerability Scoring System (CVSS) score tied to the vulnerability. The CVSS score can give you a gauge to the overall risk. To go a bit deeper, you can look at the CVSS Vector.
There are 3 sections to the CVSS. There are the constant base metrics covering the exploitability of the issue, the impact that it may have and the scope that it is in. There are the temporal metrics, which may change over time, giving the color commentary of the issue. And there are the environmental metrics which look at the specific, individual environment and how that is impacted. Areas explored here include things like the attack vector and complexity; whether elevated privileges are required or any user interaction along with the scope and how it affects the confidentiality, integrity and availability of the system. One can use the CVSS calculator to help determine a vector score. With a few selections you can get a base, temporal and environmental score to get an overall view of the severity. With this, you can get an understanding as to how to handle the vulnerability. Every organization has different levels of risk based on their unique situation. The vulnerability base score may have a critical listing yet based on your environmental score, the severity and risk may be nil.
Lastly, the Mitigation taken is not an exact science and truly depends on the issue and the organization’s situation. Mitigation is not necessarily prevention. For example, compensating controls, such as restricting root level access might mean that a vulnerability simply isn’t exploitable without a privileged account.
Vulnerability management and information security is about managing risk. Risk analysis, risk management, risk mitigation and what that risk means to the business. Patching a vulnerability can introduce other risks, so the old refrain of “patch your $#!+” is not the panacea we’re often led to believe. Risk is not limited to the severity of the vulnerability alone, but also to the required vector for exploiting that vulnerability where it exists within a specific organization’s infrastructure.
It’s important to understand your risk and focus on the important pieces.