I think it goes without saying that there is a problem when it comes to vulnerability management. Period.
From a recent event there was a simple question asked amongst a group of Information Security professionals, most had never met or spoken before. We are all from different companies, parts of the country, different countries and so on. Anyway, the question was, “Is your company successful with vulnerability management?”, and to raise your hand if so. Now this room is not shy, nor are we inexperienced but not one person raised their hand.
This prompted me to start thinking of ways in which we can tackle this problem with a few simple steps. I mean you can hire an analyst or two that focuses on vulnerability management and this can really be a full time job – trust me – but that doesn’t solve the underlying problem. I am aware of complications such as cost, compatibility, disruptions and so on – but this is to just get the points out there and give some insight and ideas to what I feel could help the process for an organisation.
I think one of the most important things to have as a given, and within any organisation, is to have an up to date Asset Inventory that is maintained as well as a network diagram. This is much easier said than done, I get that, but it is crucial for so many reasons and not just for vulnerability management. Having a fully updated and “operational” asset inventory will help you identify information about assets that you would not normally know, but also helps you pinpoint things such as the location, when it was purchased (some hardware is replaced every 3 years in companies), who currently has it, network/subnet, and so on. We as security professionals can leverage this to point vulnerability scanners at it as well as addressing asset management. Incident handlers/responders can also gain a lot of value from this. Authorised external parties will most likely require this – the situation and reasoning will obviously change but it will assist the process. Examples could be auditors/compliance, pen-testers, incident responders etc.
I have a few things in mind which may help you when it comes to vulnerability management and how you can improve your process, or even start. These are only a few pointers but if you have any other crucial ones, please do reach out to me and I will include it and credit you.
Having started with a pre-requisite, let’s start. So firstly, I would recommend you ensure your estate is in a healthy state. This can include checking your estate for any updates or patches that are required on hardware/software (you may manage this centrally), making sure that anything that is not needed is not being used (ports, software, hardware), any or all critical assets are identified and are not being overlooked, if you have previous scan results then go over these and identify some fixes from this, and so on.
A further recommendation off the back of maintaining a healthy estate is to look at your Operating Systems (OS). You can find information out about OS versions via multiple ways such as PowerShell, Nmap, software etc.
Before running your vulnerability scanners to find present vulnerabilities, start by upgrading your systems to the latest operating system where possible. Windows 7 is now End of Life (EOL) as of January 14th 2020 so could now be a greater risk of being insecure. Furthermore, outdated OS is bound to have multiple vulnerabilities as a given and could in fact be wasting your time when an OS upgrade could fix many of these. Don’t get me wrong, some systems are going to be legacy for many reasons but ask the questions to try and find out if they can be upgraded or further secured. This is your job as a security professional.
Building a process is something else I would highly recommend you build in to your organisation. This will subsequently outline all requirements for the vulnerability management life-cycle, a cycle that takes you through identifying the vulnerabilities with risk acceptance all the way to remediating them. Stages include identification, classifying, prioritising and mitigating/remediating. Your policy can include things about the scope, i.e the assets to be scanned, the timings of scans (usually out of working hours so not to disrupt normal operations), the vulnerability scanner/tool to use (keep this updated too!), the type of scan you will run against the targets, credentialed (authenticated) scans or not, who is to manage the vulnerabilities and risks, when to apply the patches etc. etc.
Following on from the timings of the scan within the policy, I would recommend short patch cycles. Patch cycles include getting the updated vulnerabilities from your vendor, i.e your scanner being updated, scanning your network, identifying the vulnerabilities, deploy the patches to fix the gap so not to allow it to be susceptible to exploit, and then do testing to ensure it has fixed.
Doing this allows you to keep on top of your estate as well as assisting you in staying safe. New vulnerabilities are coming out that frequent these days that it is imperative to stay ahead. By having a shorter patch cycle you are taking a better approach to managing your estate as opposed to doing this cycle every x months.
Although you may have a vulnerability scanner, you may not have used different ones. Trialing different tools may actually be beneficial to you as they may be more suited to the environment you are working in. For my dissertation paper at University, I compared the top vulnerability scanners against each other looking at a cost perspective. I opted to use Nessus, Nexpose, OpenVAS and Nmap. From the testing, I took the results of each scan and evaluated how the vulnerability scanners classified their findings. The results were extremely interesting as well. As of writing the dissertation, Nessus was considered the market leader and the go-to scanner. The results showed that each scanner found different vulnerabilities, classified them differently (i.e one classified as Critical, the other was Low), the time to complete the scans were different, network traffic generated was fluctuating and so on.
This leads us on to my next pointer. I have found it beneficial to look at all results as opposed to just critical and high. Some organisations only want critical/high reporting but that leaves them open to the other areas which they’re ignoring. When I have been looking through some “low” classifications from a Nessus output, I have come across vulnerabilities that were susceptible to exploits, such as outdated versions and was then able to use this against the target system. But by ignoring these, you may not see them. Just a disclaimer, this was performed on a test environment so I could validate the “low” classification. The pointer to take away from this is to not ignore the lower end results and to go through all results. This could be a task for your vulnerability analyst to do.
Kind of a related point to the above is the importance to triage vulnerabilities so not to miss anything. It pays to be thorough albeit can be a bit boring trawling through the lists, but finding that diamond in the rough will be rewarding and potentially high impacting.
If you do have any previous vulnerability scan results, these can come in handy to identify any previous vulnerabilities. You should run a scan to allow you to compare these against one another to see if you are still vulnerable or if you have patched a hole. It can also help you identify assets. It is important to check the scope to gain more accurate comparisons because if 3/4 of the hosts are no longer active, you won’t have much information to go off. In addition, if you’ve swapped scanner and have results from a predecessor, these can be helpful to also identify any gaps or progress.
Lastly, you could outsource your vulnerability management or scanning to a 3rd party. This could include managed patching, or even SOC. Managed patching will look at updates from the vendor and triage them to ensure they are relevant and required and then roll them out to your hosts to apply the fix. A SOC will also do vulnerability stuff from a scanning perspective, and sometimes reporting, but if you do this then you should really work with them in order to get the patches applied. I would recommend you have a dedicated contact to work through these identified vulnerabilities otherwise it is just a waste of time and the numbers are not going to change within each cycle and the reporting becomes redundant to an extent.
Moral of the post, don’t let this stuff become distant. Keep on top of it and actively work towards a safe environment as well as allowing it to become routine. There are multiple options available for this, there’s many resources out there publicly, and more importantly I hope the tips within this blog are helpful to some extent. Most will probably seem self explanatory and understandable, but it doesn’t mean they’re present! Having understanding is very different from the actions we take.
All feedback is welcomed and I hope to hear from you. If you have any questions or concerns, or pointers then please do reach out to me.
Dan
Steel Cyber Security 