Vulnerability assessments usually involve using automated tools such as Nessus or Qualys to carry out a passive scan of an organisation’s systems. The process produces a list of security gaps and ranks them in order of risk. It gives an organisation clear data to guide the process of deciding which issues to prioritise first based on budget, available resources, or likelihood of the threat.
If forewarned is forearmed, then the value of a vulnerability assessment is that it identifies weaknesses in your systems proactively. It’s different to a penetration test which not only finds security gaps but actively exploits them to replicate the damage a malicious attacker could do without the repercussions.
Why check for vulnerabilities?
Lately, we’re seeing organisations carry out vulnerability assessments, or get an independent provider to do it for them, much more frequently. I think there are two reasons for this. One is the increasing adoption of the ISO 27001 information security standard. We advise organisations that want to get certified or stay compliant to check for vulnerabilities at least twice a year and perform a penetration test at least once a year.
The second driver is – surprise, surprise – GDPR. Growing numbers of businesses and public sector agencies are now aware that they need to protect data. Checking for weak points can help them put safeguards in place to avoid breaches. In the event of a breach, an organisation may avoid heavier penalties if it can prove to the regulator that it has been carrying out vulnerability assessments and doing their due diligence. On the other hand, the authorities won’t look too kindly on breach victims that were running old operating systems with no security controls or patching mechanisms in place.
What to fix
I carry out vulnerability assessments every week, and many of the risks I find are very common. Many of them fall into the categories of medium or high risk. For example, many websites still use old versions of SSL or TLS for encrypting data transfers. Some people might assume that a brochure website doesn’t need this level of protection, but I think that’s a mistake. Even a static page may have a function that calls another function that talks to the database or another application. This is a relatively easy issue to fix, and it addresses a potentially large security hole.
Even for a brochure website, it’s worth doing this upgrade since it’s a big gain for relatively little effort. Implementing TLS carries little cost and eliminates a lot of potential weaknesses. Since SSL was deprecated, it’s a matter of changing to TLS 1.1 or 1.2 which in some cases is as simple as checking a box.
To upgrade or not to upgrade
Another common issue that vulnerability assessments will uncover is out of date software like Apache or OpenSSH. (I recently found one site using a five-year-old version of OpenSSH!) As with the risks I referred to above, fixing them is often a matter of clicking the ‘update’ button in the application.
Whether an organisation updates or not will depend on its attitude to risk. Some choose not to do so because they are concerned about affecting their production environment. Or, they might not have time and resources to test the stability of an application on the new version. I would always argue in favour of acting, but at the very least, a vulnerability assessment will highlight areas that you can rank in order of priority.
The length of time it takes to conduct the assessment will vary. It’s not necessarily as simple a calculation as adding up the number of IP addresses to check. I’ve seen three IP addresses take four hours to scan. It also depends what software the organisation uses, and whether it’s patched or unpatched.
Taking action afterwards
Let’s say the testing lasts a day. Writing the report then involves taking the findings from the automated scanning tool and translating that into language that will allow a client to weigh up its business risk. Some companies take the report and fix the issues that it covers. Some use it as a talking point with their software development teams, to make them aware of certain vulnerabilities. Best practice advises that those organisations run an assessment a few months later to check that any fixes they implemented were successful.
However, I’ve also seen the opposite, where I have carried out monthly vulnerability checks and the client chooses not to fix the issues that the report raises. That goes to the heart of security: making decisions based on the level of risk you’re prepared to bear. Good security practice suggests looking for weak points in your security before someone with malicious intentions does it for you.
The post The value in vulnerability assessments: closing gaps to improve security appeared first on BH Consulting.