Most security assessments only includes CVE’s and known vulnerabilities but many fail to address the true potential security risks. And this will create a big problem for your organization.

The problem starts because most organizations only wants to have a security analysis based on know-existent vulnerabilities, like a “tell me what KB to patch”, but this approach is not good and fails to protect you in two ways:

1. You are not resilient enough for 0-days attacks and undetected vulnerabilities
2. You will be focused on patching instead of creating meaningful policies that can help you more…

Patching instead of policies…

Well.. Patching itself is a good policy, but specific patch management is a very dangerous game. I would never recommend to install some specific KB to fix a vulnerability found in a report, but… why?

First and foremost, most security assessments, specially black box, are constrained in time, resources and access, and they will only identify a subset of known vulnerabilities, and no, does not matter if you have hired the best hacker, even the best will going to miss many things.

so, you will be asking me now: why are we hiring vulnerability assessments, penetration testings, and so…

The answer is quite simple:

To understand the main issues in your security policy

A meaningful security assessment can help you to create a meaningful security policy that includes periodic updates, strong password management, access controls, and many other things that may be useful for you (and you may not require to test for 6 months to discover what you require).

The security policy and the APT…

When your system misses a patch, your system is obviously out of date and with potential vulnerabilities, but it’s more dangerous than that… savvy external hackers will identify this and will try to take advantage of the policy failure all over the network and over the time, including in places out of the assessment scope.

So, if your security policy is to check the vulnerabilities every 6 months and apply the identified patches in the next 6 months, this will tell the APT the following thing:

• There is a patching gap is an indicator that some window of time could be used for exploitation (the first 6 months)
• And… most probably there are still many vulnerabilities in place…

So, there is no easy answer to this, because many can’t handle an have an aggressive update schedule. but creating a meaningful/resilient security policy can help very much (even you have not installed the patch)…

Not every fixed vulnerability have a CVE

If you thing that if you are free of CVE, you are ok… I have some bad news…

do you know that when someone develop a software, many of the bugs are not cataloged as security vulnerabilities? Many bugs are reported (and fixed) as stability bugs, and in many times the development team will fail to see that there is a potential security threat there…

Those bugs are used to be fixed in non-security related updates, and if we don’t have a proper update policy, those security issues will be accumulating over time and will be ready to be exploited.

and there is no way to avoid this confusion in development without skyrocketing the development costs… But I believe that there is no way to avoid this confusion (specially in 3rd party and opensource software).

My recommendation: stick to the last, and create a meaningful policy and also contemplate 0-days…

0-days are not uncommon

At this point, many basic security testing are capable of identifying what you are required to improve in your own policy… And applying this to the whole organization will make some success against unidentified vulnerabilities.

And if you want to hire the best testing to document all the unidentified vulnerabilities, I will tell you that 0 days are not uncommon, so… there is no way to identify ALL the vulnerabilities…

But don’t worry, there is hope, many times in my career I had to successfully repeal attacks with 0 days, and the strategy was very simple:

• Meaningful Logs: helps you to understand how the system was exploited and learn from it.
• Identify the risk and relevance: The risk management is not a CVE, identify those systems that comply and those that don’t comply with our security policy, and assign a relevance/risk level.
• Pivot Pivot and Pivot: Try to understand all the possible pivots that may be used by an adversary and try to restrict them.
• Expecting them (the zero days): Never underestimate your adversary… Once you admit that even you are in the bleeding edge you may be vulnerable you are able to understand the importance of ->
• Having security layers (Onion Strategy): Security layers is the nightmare for a successful attack, it may require to combine and chain several exploits, and it will represent a very hard challenge for the adversary. Our bet is that the hacker will stuck and we will be able to catch him before the maze is resolved.
• Reducing the attack surface: if you can understand about hidden risks about 0-days and missed vulnerabilities (even if you patched everything), then, you should work on reducing the attack surface… bigger the attack surface, bigger the probability of a 0-day/missed vulnerability…

And this should be the beginning of a meaningful security policy, but remember, this has to be adapted and complemented by a policy focused security testing!

Be creative!