Dealing with cyber-attacks, data breaches and other cyber security issues is something most organisations don’t generally take lightly.
Many businesses react only when they have a problem, there is a better way – by using risk based vulnerability management.
What is Risk Based Vulnerability Management?
As part of your security strategy, alongside scanning for infrastructure vulnerabilities it is equally important to scan for application vulnerabilities.
In an ideal world scanning for application vulnerabilities becomes an intrinsic part of the software development lifecycle. The objective being, that no security vulnerability ever gets into a software release. Organisations can at the same time assess their security strengths and identify infrastructure threats.
Much as this sounds obvious, we need to discuss “risk” and detail how it fits with vulnerability management. But, before we do that I want to explain a little more about vulnerability management.
Explaining vulnerability management
Vulnerability management is an integral part of maintaining your organisation’s computer and network security. It entails scanning your IT infrastructure or software applications to locate and address known software vulnerabilities.
So, the risk is if you have a known vulnerability and it can be easily exploited it will be taken advantage of by cyber criminals.
When a vulnerability is located it may need an installation of a patch, a change in network security policy or software reconfiguration.
It is also valuable to educate users on best practices to prevent security vulnerabilities.
A vulnerability scanner undertakes to identify, classify, and prioritise, the vulnerabilities that are uncovered. You then need additional manual processes to work out what to fix (remediate) and how to get that work done. The reality is that “doing something about it” can be a difficult task to manage and is full of compromises.
Ponemon’s “Cost of a Data Breach Report 2020” (commissioned by IBM) reveals the average cost of a data breach. Down from $3.92 million in 2019 to $3.86 million this year. The cost was less for mature companies, higher for firms that had ineffective security automation and incident response processes.
Categorising risk and vulnerability
If you scan any given server it’s not uncommon to generate a list of 100+ vulnerability issues.
Of that 100 they would typically fall into the following rough categories:
- Absolutely must fix it now
- Get it scheduled for a fix within 30 days
- Would love to fix it, but some other technology prevents us. For example an application vendor has not certified the new platform.
- There is no fix available
- Should fix it, but just don’t have the time or resources
So how do you decide which issues that your scanner has found, fall into each of the categories above?
It would make sense to do the most risky ones first. And this is what drives the “risk” misconception.
Your scanner will find and report on multiple “bad issues”, scoring as a 9 out of 10, or perhaps a 1 out of 10.
Most security teams would see the score as a measure of “risk”. It is risk, but only in the technical sense, not the business one.
If for example your business has customer credit card data, and data on the allocation of car parking spaces at the office, they have different values. Both are subsets of data, and held in a secure system, and after discovering a vulnerability – both are just as easy to exploit technically.
However, the consequences of an unauthorized party getting access to one is far more serious than the other. So, we know which scenario has the priority to address based on business risk.
With Risk Based Vulnerability Management you need to apply both technical and business risk to set the priorities.
It is almost impossible to jump directly to a fully risk based approach.
Most companies apply a security process as outlined below in the following stages:
- Vulnerability Assessments
- Vulnerability Management
- Risk based vulnerability management
We will discuss each of the above 3 steps in more detail below.
1. Vulnerability Assessment
Undertaking a scan for potential vulnerabilities in software such as Microsoft Windows, Apache Web Server and Adobe Acrobat Reader. Also scanning hardware such as firewalls, routers, switches and servers, producing a list of what is wrong and what needs to be fixed.
An organisation would then typically load that data into an Excel spreadsheet, allocate the necessary tasks to the patching team and hope that things get remediated (fixed).
At this stage there is already a baseline view of the security maturity uncovered by the scan.
Typically the assessment would be repeated at regular intervals measured in months.
If you have limited resources then this is a great start to uncover what vulnerabilities.
As you narrow that scanning interval you start to move to the next step in the process.
S4 Applications recommendation for vulnerability assessment:
The Tenable Nessus Pro platform provides a single snapshot of all the assets that you have on your network. For each asset it will identify the associated security issues (CVEs) that are present. Each vulnerability discovered is given a CVSS score to aid technical prioritisation.
The product can scan all the things that you would expect (workstations and servers) plus a range of other devices like network equipment and IoT devices.
Nessus Pro is trusted by more than 30,000 organisations worldwide as one of the most widely deployed security technologies on the planet – and the gold standard for vulnerability assessment.
Check out the Tenable platform here or request a demonstration here.
2. Vulnerability management
Running vulnerability assessments and remediation is vulnerability management. Continually tracking performance and running some form of SLA (service level agreement) with the patching teams.
The “regular intervals” and how comprehensive the “SLA” are, is the key factor here.
Most companies have a “regular interval” of weekly.
The SLA then facilitates a deeper conversation. The patching team cannot immediately fix everything (or ever fix everything for that matter), so what should they focus on? This is typically the severity of the vulnerability (known as the Common Vulnerability Scoring System or CVSS score).
By regularly scanning the environment an organisation can continuously identify new vulnerabilities known as Common Vulnerabilities and Exposures or CVEs. These can be found amongst their software, hardware (such as firewalls, routers, switches and servers) and the network.
Scans can be run on any number of assets, versions of files and behaviour. For example, a patching team may agree to fix all level 9 scores and above within 2 weeks and all level 8 and above in 4 weeks.
Assessing risk
As discussed above, using just the technical risk (the CVSS score) is not ideal, but it is a start.
An organisation needs to understand the timeframe that a patching team need to be able to patch within.
Using the insights from vulnerability management, the task is to build a secure infrastructure and come up with a more effective way to measure and present a risk score.
Vendors have started to try and add more data into their tools by adding what they call risk. Tenable, for example, have added the VPR score (Vulnerability Priority Rating) to a vulnerability assessment.
The VPR is better than CVSS because it includes some threat intel which it adds into the calculation.
So, if an exploit is actively being used then a CVSS score of 7 may be increased to a VPR of 8. Conversely, if there is a CVSS 8, but nobody, anywhere has a working exploit then the VPR could be 7. This has nothing to do with your business, but is better than CVSS alone.
S4 Applications recommendation for vulnerability management:
Tenable.io or Tenable.SC provide actionable and accurate data to identify, investigate, and prioritise the remediation of vulnerabilities and misconfigurations in your IT infrastructure. Available as a cloud-delivered solution or on-premise..
Read more about Tenable here and request a demo here.
Invicti offers a web application vulnerability scanner that makes it easy for security teams to pinpoint critical issues and assess the potential outcome.
The application explains the errors that are causing the vulnerabilities so that a security team can address them.
3. Risk based vulnerability management
If you want to be able to assess vulnerabilities and business risk, then you need to gather a lot of information. You can start with a little information and then build up what you can gather over time. The more business information that you have, the easier it is to create an effective risk score.
The information that you need usually comes in the following properties:
- Vulnerability
- Server
- Application
It is worth discussing each one in a little more detail:
1. Vulnerability Properties
A scanning tool will gather the data on your vulnerability properties including the CVSS. If you are a Tenable user then you will also be able to access the VPR score. If you are subscribing to a Threat Intelligence feed this too provides great information about vulnerabilities.
Vulnerability property data is normally sourced from feeds and subscriptions .
2. Server Properties
Server information it can be in your Microsoft AD, or other similar directories, held in CMDBs or possibly saved and available in an Excel file.
If the machine has a public IP address then it is probably accessible from the Internet, and server names can provide useful information such as a location (STK for Stockholm, DUB for Dublin etc.).
Getting the operating system (OS type) and version is also very useful. Your scanner can probably work this out for you, or again might be available in a database.
Depending on your business sector and security posture, the physical server access conditions may differ, as some companies have more secure data centres than others.
3. Application Properties
This is often the most difficult information to gather, because it has to come exclusively from your own organisation. To start you’ll need to create a list of the applications, and which servers form part of those applications, so that you can see the overall structure.
You’ll then need to set up “flags” to understand what a particular application contains.
The following would be common flags to be able to identify what is contained:
- PII – personally identifiable information, i.e. subject to GDPR
- Medical information – different regulations
- Financial information – yet another regulation PCI-DSS
- Faces the internet
- Critical business function – say from 5 (core finance) to 1 (car parking)
- Sensitive information that would be valuable to your competitors, or be embarrassing if made public.
Apart from servers and workstations, you also need to check the network firewall, proxy server, load balancer etc.
You’ll need all of the above gathered information to come up with a unique risk score, for every vulnerability, on every server. It may sound simple, but has great importance – so I will reiterate, you need to take the 20+ pieces of information above, and produce a single number; the business risk score.
You also need to allow for some of the issues in the underlying data, mainly the CVSS score.
More on the CVSS SCore
The Common Vulnerability Scoring System (CVSS) is an open industry standard for assessing the severity of security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, calculated based on a formula that depends on several metrics that approximate ease of exploit and the impact of exploit. Scores range from 0 to 10, with 10 being the most severe.
There was recently a vulnerability with a CVSS score in the 9s (i.e. very bad, see CVE-2020-10713), but to take advantage of it, you needed local access, i.e. the ability to log into the machine. The thing is, if someone has already logged onto the machine, you have a lot of other issues to worry about too and this is just one of them.
So whilst a 9 by definition is a high score (there is a documented formula for how CVSS numbers are derived), there are other situations that should take priority, i.e. RCE (Remote Code Execution) issues where someone can run code on a server remotely (this is what underpinned WannaCry and similar).
When bringing all of the information together you also want a reasonable distribution of issues throughout your scoring range.
So, if you use a score of 1 to 100, then you want a manageable number of items in the 95+ range. There is no point in having 20% of your issues in the 95+ category.
S4 Applications recommendation for risk based vulnerability management:
A comprehensive platform for cyber risk analysis and remediation for an Enterprise organisation would be Brinqa. Brinqa helps transform threat data into insights that empower an organisation’s approach to remaining secure.
Brinqa prioritises assets, vulnerabilities, and incidents based on their impact and value to the business. Automating the Vulnerability Management process, as a tool it streamlines the “scan for vulnerabilities -> prioritise -> create tickets for remediation” process so that humans focus on dealing with exceptions, not the process.
Read more about risk based vulnerability management with our Brinqa case studies, learn more about Brinqa or contact S4 Applications to request a demo.
For the SME organisation, Acunetix finds what other scanners don’t, assessing the severity of the issue, giving you immediately actionable insights.
Focusing on business risk is the answer
Depending on your level of vulnerability maturity, S4 Applications has a range of solutions.
From Brinqa, Invicti and Tenable all can help prevent unauthorised attacks and protect business continuity and reputation.
Contact us to set up a 1:1 consultation or to book a demonstration.
If you want to learn more about security maturity read: Assess your security Posture with our Security Maturity Model.