Vulnerable vs. Exploitable: Why These Are Different and Why it Matters
While at first blush, these two concepts sound pretty similar, the differences are extremely important. Read on to learn what they are, and how to defend against them.
Join the DZone community and get the full member experience.Join For Free
Pop quiz: What's the difference between vulnerable and exploitable?
As we've written before, a vulnerability is a weakness in a software system. And an exploit is an attack that leverages that vulnerability. So while vulnerable means there is theoretically a way to exploit something (i.e., a vulnerability exists), exploitable means that there is a definite path to doing so in the wild. Naturally, attackers want to find weaknesses that are actually exploitable. As a defender, being vulnerable isn't great, but you should be especially worried about being exploitable.
There are a few main reasons why something that is theoretically vulnerable is not actually exploitable:
- There may be insufficient public information to enable attackers to exploit the vulnerability.
- Doing so may require prior authentication or local system access that the attacker does not have.
- Existing security controls may make it hard to attack.
Below, we'll explain why this matters and how you can use it to improve your security posture.
Vulnerable vs. Exploitable: Why It Matters
Understanding the difference between vulnerable and exploitable can help you as a defender prioritize what to do. Knowing the difference can empower you to use your time to protect against vulnerabilities that are actually dangerous to your business (i.e., exploitable), and thus keep your systems safer.
If you are taking basic security precautions, then many vulnerabilities will not be exploitable for your organization. For example, if you have employed AWS best practices to your workloads, then they are probably not at risk to the extent that someone running a looser ship might find theirs to be. Performing an audit of your environment will help to identify areas where you are and are not meeting these types of guidelines so you can quickly fill in the gaps.
This alone can go a long way towards reducing your exposure to known and unknown vulnerabilities and make it that much harder for attackers to be successful when vulnerabilities become exploits.
Build a Vulnerability Management Program
In addition to auditing where you stand today relative to best practices, you should implement a robust vulnerability management program. You need a way to systematically identify new vulnerabilities and identify which ones are exploitable for your unique organization. You also want to be able to rank severity so you can focus your resources on issues where you can have the biggest impact.
How can you tell whether a vulnerability is exploitable? When a new vulnerability is published, exploitability complexity, as well as active or known exploits, are some of the factors that are used to determine the vulnerability scoring, which will help you determine how severe it is. Then you can decide whether and when to take corrective action.
Ideally, you should be using a security platform that can continuously and automatically assess installed packages that contain known vulnerabilities on each system respectively. These should be cross-referenced against common vulnerabilities and exposures (CVEs) and the National Vulnerability Database. Keep in mind that this is not something that someone can do by hand, given that more than two million CVEs have been identified at this time.
Prioritization Over Perfectionism
There is no such thing as perfect security, so there's no sense making perfect the enemy of good when it comes to security. Instead, focus on continuously improving your security, focusing on becoming just a little bit more secure every day. Being realistic about what is vulnerable and what is actually exploitable can help you do this, since it will allow you to carefully funnel your resources toward the most critical areas. This is a key step to take on your cloud security maturity journey.
Published at DZone with permission of Anthony Alves, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.