Whatever assets you happen to control, you want to be sure that they’re secure. Even if your system is lucky enough to be based in Sweden – the country with the lowest malware infection rates in the world – it needs vigilant protection.
The uncomfortable truth is that there are innumerable threats out there, and more companies than ever are being targeted by cybercriminals.
Common Vulnerabilities and Exposures (CVEs) proliferate, and cyber-security is a hotbed of danger. For this reason, you need to identify your weakest points – you need vulnerability management.
While machine learning – for instance, databricks MLOps – is starting to make inroads into vulnerability management, there are certain steps that you should be taking to beef up your program. We’ll assess these in turn, but let’s start with a definition.
What is Vulnerability Management?
Whether you are responsible for hardware, software or personnel, you need to be sure of your security measures. You need to know what the threats are so that you can tackle them effectively and quickly, not least because to leave threats unchallenged is expensive.
So although it can be costly to implement these processes, it can be far more pricey in the long run not to. There are a number of different processes you can use to ascertain threats and their risk to your assets.
One such process is the Common Vulnerability Scoring System (CVSS), which is an open framework detailing the characteristics and seriousness of threats to all kinds of software, from customer experience management software to database retrieval routines.
CVSS works with a scoring system, with marks out of 10 denoting severity. 9 and above are critical, 4 and below are considered low severity.
We’ll return to CVSS shortly, when we look at its work with triage. For the moment though, we’ll see briefly what information it gives re vulnerabilities. It can provide the following information:
- Base metrics – this is a depiction of constant threats and vulnerabilities.
- Temporal metrics – this is a depiction of threats and vulnerabilities that change over time, but stay constant across user environments.
- Environmental metrics – this is a depiction of threats and vulnerabilities that depend on the user environment and user behavior.
This can be used in conjunction with a range of penetration testers using automated tools to identify vulnerabilities across products and services.
Technical and non-technical information is produced enabling an understanding of the situation by staff with both technical and non-technical backgrounds. Diagnostics can then begin
A common finding at this stage is a paralysis in the face of an array of threats and vulnerabilities. This is why vulnerability triage is required.
What is Vulnerability Triage?
Just as in a medical situation, vulnerability triage is all about deciding on what needs remedying now and separating it from the cases that aren’t quite as time critical. In the cyber-security arena, this means separating out the largest, most dangerous and most imminent threats from the medium to low risk threats.
Vulnerability triage is intended to combat the two common reactions to vulnerability assessment. Reaction one is characterized by a tendency to file the results of the assessment away until there’s more time available. After all, you’re busy right now and you can always make time later, right? Not necessarily. And meanwhile, those threats are still there and might grow in intensity.
Reaction two is where the decision is made to deal with the problems right away, but the individual makes the mistake of methodically working through the list from top to bottom in chronological order, rather than rationally assessing which needs dealing with first.
Quite often what happens here is that enthusiasm for the task diminishes as the operation wears on, which means that some of the threats at the bottom of the list may end up unremedied, even though they may be the most dangerous.
First Step: Get Your Team Together
Vulnerability triage should be undertaken by a team with expertise in data analytics, IT management, cyber security risk and general business risk. So, choose its team members wisely, as they’re going to have a lot of responsibility on their shoulders. Your Vulnerability Triage Group (VTG) will be what stands between your business and profound danger.
Second Step: Plan
The importance of planning is paramount. It can be tempting to launch straight into firefighting mode, but this can be inefficient and result in the wrong threats being targeted first.
Planning means being proactive – this is important, as to be purely reactive is to fail to provide good vulnerability management. Planning separates threats into three different groups:
Fix
Establish what you’re going to tackle first. Describe what fixes you’re going to put in place to protect the Confidentiality, Integrity and Availability (CIA) of the organization’s systems.
Acknowledge
For those risks that you’re downgrading, you need to detail them and describe why they aren’t such an imminent threat. They’re to be kept on file so that they can be returned to when necessary.
Be careful with this group. If you place a threat here that then turns out to be severe enough to need immediate fixing, you’ll need to be able to furnish stakeholders with the reasons why you put it in the Acknowledge class. So, ensure you have recorded full background to any decision making.
Investigate
This is for when the VTG isn’t altogether sure if the threat is sufficiently imminent or severe to warrant immediate remedy. Occasionally, even with the best talent on hand, there has to be a recognition that the data is inconclusive.
For this reason, an investigation to fill in the knowledge gaps is necessary. A completion date can be allocated at this stage, with the intention being that the investigation will decide if the threat should go in the Fix or Acknowledge pile.
Third Step: What Goes Where?
So, you have your groupings. You now come to the meat of the task: you have to decide what threat goes into which group.
Start by looking at the vulnerability that’s been identified. Firstly, how likely is the vulnerability to be leveraged? Secondly, what’s the damage that could be done? It’s very similar to any risk assessment: likelihood of risk occurring multiplied by the severity of the possible outcome.
This is where you need to deploy as broad a vision as possible. Think about the shape of the system and all its touch points regarding other systems. Here, having a thoroughly heterogenous VTG can really pay off. The wider the frame of expertise in the group, the more vulnerabilities can be recognized and brought to the table.
Certain questions should be asked, such as ‘does the system hold critical data?’, ‘what can the attacker gain access to?’, ’which mainframe modernization strategy is wrongly applied?’, ‘how readily can the system gain awareness of any incursion?’, ‘who is responsible for the asset?’ and ‘who is responsible for the remedy?’.
Further questions can then be leveled, including ‘how long will the fix take?’, ‘do we need assistance from another body?’ and ‘is there anything we can do to temporarily mitigate the concern while the final fix is being worked on?’.
Step 4: CVSS in Triage
We’ve seen how CVSS is used in initial threat detection. It can also prove extremely useful in triaging those threats.
The most straightforward way to use CVSS is to take the basic metrics and decide on threat level just using those.
However, the drawback here is that basic metrics don’t take into account any countermeasures that the system already has in place. For this reason, the information pouring out of this data pipeline may give a skewed picture of the situation, and you may end up rushing to defeat a threat that’s not actually that critical.
This is why it makes a good deal of sense to get a custom CVSS score. This is done by also utilizing the temporal and environmental metrics. Once these are all in place, you’ll have a much more detailed and accurate picture of the vulnerability landscape.
However, there’s a problem here too. To factor temporal and environmental factors in can be an enormously laborious and time-consuming task, especially in a large and/or complex organization. This will occupy your VTG for an inordinate period and stop the individuals applying themselves to other areas of endeavor.
As an alternative solution, one could seek to identify all the vulnerabilities that are specific just to the system’s critical components.
This can be where Operational Support Systems (OSS) professionals can lend a hand in that they’ll have information on system critical points. They may for instance have access to different types of test cases in software testing that could furnish you with exactly the information you need.
Step 5: Triage Filters
CVSS is by no means the only tool at your disposal. Just as with convolutional neural network layers, wherein a combination of information sources is used, it can be sensible to combine a CVSS basic metric sweep with a filter. Let’s have a look at two of them.
Attack Vector Filter
The attack vector description determines the exact circumstances in which the vulnerability can be exploited. It can be:
- Network – internet-based remote threat, perhaps from the most innocuous source, eg a free image service.
- Adjacent – has to be geographically (eg via Bluetooth) or closed-system (eg within a VPN) linked. It could be accessed via a database, so it’s worth running a vulnerability check here. If it’s an open source program eg apache kudu performance in this area can be checked with the originators.
- Local – threat via keyboard or other interaction with the user interface.
- Physical – threat via insertion of physical device, eg USB stick.
How does this help? Well, if your system uses, for instance, cloud call center software involving no physical interactions via USB etc, then you can filter this attack vector out. This will remove a substantial number of CVEs from the CVSS picture and you can then just concentrate on the threats that remain.
Configuration Filter
This simply means that if your system is not using the particular component that has been identified as severely vulnerable, you can filter this out. Just one word of caution: make sure that this remains the same over temporal and environmental factors, otherwise you’ll be opening the system up to threat at other times and in other uses.
Other filters exist, including Platform Filters, Hardware Architecture Filters and Status Filters, and are worth investigating for the increased power they give to your triaging, as are many of the latest cybersecurity technologies that come in all the time.
However, if you’ve asked all the relevant questions and used all the tools you can lay your hands on and you are still struggling, whether because of time pressures or just a lack of all the requisite information, there are some shortcuts you can apply.
Step 6: Time for Shortcuts
The UK National Cyber Security Centre (NCSC) has been kind enough to supply a list of four priorities one can use for a quick result vulnerability triage. Threats should be dealt with in this order:
- Priority 1: Internet services and standard web applications that have vulnerabilities that are open to attack with no user interaction.
- Priority 2: Niche and tailor-made web applications that have vulnerabilities that are open to attack with no user interaction.
- Priority 3: Vulnerabilities that are potentially internet-wide and open to attack with minimal user interaction.
- Priority 4: Vulnerabilities that are potentially internet-wide and open to attack with significant user interaction.
Step 5: Admit Defeat?
Never. You really don’t want to end up in a chart like this.
OK, sometimes, one has to accept that a system is too vulnerable to attack for the ideal fix to be implemented. Or it might be that there aren’t sufficient funds available to remedy the problem properly. When this happens, you can’t just walk away, so what do you do?
What you do is introduce what are known as compensating controls. These contain or hamstring the risk to an acceptable level. Then make sure that it’s documented thoroughly enough so that everyone is aware of the problem and what to do to avoid its worst aspects.
Not perfect, but at least it’s a way forward, to keep things going until a root and branch upgrade is possible.
Conclusion
Triage can be slow, painful, forensic work. But it is hugely important, and growing more so with every new threat that emerges, along with development in systems such as artificial neural networks types of which can be full of CVEs.
To stay on top of the burgeoning dangers to your system, you need to establish a robust and organically evolving vulnerability management approach that can deal with the most pressing cases with the greatest urgency.
The biggest takeaways here are two-fold. Remain vigilant, of course. And be communicative. A lot of your problems may have already popped up elsewhere, so solutions and shortcuts might be available to you. You might also check in with OSS and any other relevant communities from time to time, as it’s good to keep in touch.
About the Author
Pohan Lin – Senior Web Marketing and Localizations Manager
Pohan Lin is the Senior Web Marketing and Localizations Manager at Databricks, a global Data and AI provider connecting the features of Pyspark machine learning. With over 18 years of experience in web marketing, online SaaS business, and ecommerce growth. Pohan is passionate about innovation and is dedicated to communicating the significant impact data has in marketing. Pohan has also written in BigCommerce and Voilanorbert.
