The CISOs often ask “How vulnerable are we?” when presented with vulnerability metrics and reports. As the head of a security team, are you prepared to answer that question? The answer to that question often lies in the relationship between vulnerability and exploitability. All exploitable vulnerabilities are, of course, vulnerabilities. But when a vulnerability isn’t marked “exploitable,” what does that mean? The most accurate answer would be that an exploitation hasn’t been discovered yet, but the vulnerability still has the potential to be exploited Let’s clear up some terminology.
In computer security, a “vulnerability” is a weakness in the steps that are taken to secure a system that may allow unauthorized access to privileged data. In the simplest form, a misconfiguration of file level permissions can grant unauthorized users access to a file, folder, application, or service. In a more complex example, unpatched versions of SMB on Windows hosts allow attackers to bypass authentication and execute code remotely as demonstrated by the WannaCry ransomware.
The term “exploit” is commonly used to describe software that has been developed to attack an asset by taking advantage of a vulnerability. The objective of many exploits is to gain control of an asset. For example, a successful exploit of a database vulnerability can provide an attacker with the means to collect or exfiltrate all the records from that database, resulting in a data breach. Exploits are also developed to attack a vulnerability in order to gain remote administrative privileges on a host.
Security researchers know that to truly test and understand the nature of exploiting a vulnerability, an exploit framework is needed. An exploit framework is an abstraction in which the foundation of the software provides the generic functionality, and users can write code modules to perform specific tasks. For example, the developers of Metasploit, Core Impact and several others created exploit frameworks to leverage common attack techniques and delivery methods, while the users create the actual exploits. These exploit frameworks can be used by inexperienced attackers to create an attack that may look sophisticated because most of the difficult work has been created by the framework. For example, once you understand how to leverage the exploit framework to exploit a buffer overflow, replicating the attack seems trivial. The industry is seeing a rise in malware code that appears to have been developed using the various exploit frameworks as they become more popular.
Regardless of your approach to mitigating risks identified by programs that are meant to identify systems that are more vulnerable and exploitable than other systems. – by applying patches, configuring mitigation controls, or hardening operating systems – the first step is to clearly qualify the risks into actionable tasks and deliverables.
Tenable and the Center for Internet Security sponsored a separate research project that found that only 55% of organizations enforce secure configuration standards for laptops, workstations and servers. That leaves a lot of systems with potentially unnecessarily open ports and services, weak or default passwords, overly broad user rights and other configuration weaknesses.
According to the CIS Controls, the next step is to securely configure (harden) the authorized hardware and software of your mobile devices, laptops, workstations and servers. The CIS is not alone in this recommendation – other security frameworks and compliance standards echo the importance of securely configuring your systems as well.
Like the proverbial chain, security is only as strong as the weakest layer of the stack.
Even if you follow strict configuration management and provision secure “golden” images, you should still audit configurations frequently to identify the inevitable configuration drift that occurs as configurations are manually modified. Additionally, you should securely configure the entire stack, not just the operating system – especially for internet-facing servers. Don’t ignore virtualization, cloud infrastructure, container platforms, containers, web servers and database servers. Like the proverbial chain, security is only as strong as the weakest layer of the stack. You can get started with configuration standards available from multiple sources. The CIS publishes more than three dozen Benchmarks, DISA publishes a number of Security Technical Implementation Guides (STIGs), and many vendors publish their own guidelines. You may need to tailor the standards to your organization’s specific requirements. The key is to get started!
Juha Piispa, Moonsoft