Vulnerability Management Programme

S4 Applications Cyber Security Vulnerability Management Programme

Vulnerability Management Programme

S4 Applications can help your business review its ability to protect assets and respond to cyber threats.

The objective of our Vulnerability Management Programme is to provide insights on how to measure and improve security. The resources that manage security in an organisation span multiple teams, use various tools, and have different objectives and targets.

The vulnerability management programme is the glue that holds and brings together the process across the different teams and the technology applied from ticketing to patching to vulnerability scanning.

To state the obvious, the act of listing vulnerabilities does not improve security. It’s only when actions are taken to remediate (or mitigate) those vulnerabilities, that security improves.

Security issues in this context mean CVEs identified by scanners, application issues flagged by DAST tools or “use after free” type errors found by SAST tools. We also mean configuration issues like open AWS S3 buckets, but not physical ones like walking past a security guard or tail-gating an employee.

Where to start?

To get the most out of your own vulnerability management we have broken the programme down into four pillars of success.

Those pillars are as follows:

Integration of Data Sources
Prioritisation of Security Issues
Automation of the Process
Visualisation and Reporting

These pillars will help identify the automated processes, responsibilities, priorities and integration needed to ensure nothing gets missed.

The 4 pillars of our Vulnerability Management Progamme

Pillar 1 - Integration of Data Sources

The Challenge

Have you ever been asked “how good is our security?” This is not an easy question to answer because security is not just one thing it’s many, interrelated “variables”.

To assess security posture an organisation must collate data across different sources, integrate it, and standardise metrics. When done, you can look at a business application (say ERP) and see:

Issues reported by DAST – a Dynamic Application Security Testing tool
Source code issues spotted by SAST – a Static Application Security Testing tool
Infrastructure issues spotted by network scanners
Pen-test issues

Metrics mean that you can assess and answer “better or worse” questions. You can add to this assessment by breaking it down by any arbitrary unit (application, location, business unit etc.). Standardising metrics is a very complex task, as it is difficult to state that a 7 out of 10 from one system rating is the same as a 7/10 in another system. Read our blog on Vulnerability Management Programme and data integration

Different Data Sources

Most organisations have lots of different data sources that can be grouped into different layers:

Network layer

Because this data is always changing it makes sense to look regularly and with several different, overlapping tools. You’ll probably want to bring together data from say NMAP, an LDAP directory, and a CMDB into one place, so that you can view the full picture of an asset.

Operating System Layer

Every device accessing the network will have an operating system, with a version and its own set of issues. Each of those operating systems, plus the software issues inherent with it, need to be recorded.

Application Layer

Across your assets you’ll have identified business applications that are either in-house built or bought in. If they are in-house then your company will need to provide the fixes, for bought in, the vendor should provide them. The process of getting the fix may be different, but finding it is typically the same and involves a mixture of:

DAST tools – web application scanners like Acunetix and Invicti
SAST tools – source code scanning tools
Bug bounty portals – places like Hacker One where you can pay for every security issue found in your applications
Penetration testing – tools like Core Impact allow you to find exploitable issues within your applications and infrastructure

Virtualisation

This category can cover AWS / Azure / GCP policies and permissions (open S3 bucket anyone?), to analysing Docker containers, to VM Ware images. All of the relevant data needs to be collected and analysed.

Users

Information about employees, what assets they control (workstation, phone) and their security profiles within different applications all need to be assessed, found across multiple databases.

You may also find our blog: 8 best practice steps for vulnerability management an interesting read as it explains the full vulnerability management process.

Ticketing Systems

Once you have the details, and understand the situation, you’ll want to enter information into a ticketing system to be able to trigger an action. How you do this is discussed in more detail within our Automation section.

Pillar 2 - Prioritisation of Security Issues

Vulnerability maturity

Unfortunately, organisations will always face security issues. So, the most effective thing to do is fix the worst ones first. And there is the challenge, which are the “worst ones”?

Why Prioritise?

Ideally you would fix all security issues, but you cannot; by prioritising your threats, you get the maximum increases in security for the least effort. There are a number of reasons why you can’t fix everything:

Limited resources / not enough time to do the work
Upgrading one piece of software (say Java) would then take another piece of software out of its supported environment
No fix is available

Read our blog on Vulnerability Management Programme and security prioritisation

Managing Risk

Some say:

Risk = Probability of something happening x $ cost of the impact

Whilst correct, it is impractical because both items are almost impossible to measure. Instead of thinking only of the cost, think of the relative level of risk. Consider a bank, they may not be able to put monetary figures on the above, but they can put the following systems in order of importance:

On-line banking
Products a customer has in the customer database
Staff holiday information
Branch opening times

By asking questions like “is the system subject to PCI-DSS” or “does the system hold personally identifiable information”, the bank is able to assess the risk more effectively. And focus efforts in the right place.

It is all about the context to set a priority

Is the security issue on an Internet facing server or on a test network? It’s the context that drives the risk. Context includes:

Properties of the security issue – a network scanner like Nessus will give you a CVSS score from 1 to 10.
What threat intel is already available on the CVE vulnerability?
Properties of the machine – is this an internet facing machine?
Properties of the application / service it provides?

Changes over time

Bluekeep was a security issue that Microsoft found in their Remote Desktop Protocol back in 2019. As soon as Microsoft released the patch, all the security researchers, both white hat and black hat, started to try and exploit it. There was an initial delay of a few months while exploits were developed. The exploits then became widely available, and used. As the machines were parched, the bad guys moved onto the next thing. The risk of this item affecting your organisation went through a curve, from low, to medium and high, then back to medium. You need a way of dealing with this in your calculation.

Reasonable Distribution

There is no point in having all vulnerabilities at 99 out of 100, you need to get a reasonable distribution of risk. The graphs below are the same vulnerability data, once represented using just CVSS score, the other using all business metrics to prioritise.

As you can see, the first one is much easier for all teams to deal with. The second graph basically means that everything is urgent, which is something that an organisation just cannot easily deal with.

Pillar 3 - Automation of the Process

The Vision

It is probably worth stating the “vision” of where most organisations want to be, and then filling in the details on how to get there.

In the diagram below the objective is that all of the steps are automated. The actual work gets carried out on the “remediate” stage, this is where a ticket triggers an action. The rest should “just happen”.

In the real world, we want to monitor the process and ensure progress is being made, but other than that everything else is automated.

For the flow to work, the process has to be clearly defined and agreed upon.

Read our blog on Vulnerability Management Programme and automating processes

Process is key to automation

If you want to automate and standardise things, then you need to have a clearly defined set of rules on how things happen.

The process should define how you measure the severity of a security issue, how it gets fixed and time frame, along with the interactions between teams.

In talking through the above mapping, it makes most sense to start with the “Scan” stage.

Scan

Here you get a source of data relating to security issues, a vulnerability scan which states “machine X has CVE Y”. The same logic applies to applications, to containers with security issues, to miss-configured AWS buckets etc.

As long as you have scan data and it tells you “Asset X has problem Y” then you can move onto the next stage.

Prioritise

Once the data has been prioritised in terms of how critical the security issue is it should be moved on to the next stage.

Create Ticket

Now that we have issues, we need to create tickets to get them fixed with an integrated ticketing system. Using a filter to focus on those with the highest priority.

You should create tickets for all items, even those without an available fix, dealing with the absence of a fix as part of the risk process.

When tickets are created, they typically want to be aggregated, often by solution. This typically varies by data source.

Once tickets have been created, they will end up going down one of two routes, remediate or accept risk.

Remediate

Assign a ticket, and a time window to perform the task.

Once done the ticket is tagged as “Remediated pending verification”.

The act of doing this could trigger a re-scan of the particular issue, or the ticket could wait until the next scheduled scan.

Accept Risk

Not all security issues can be fixed.

If an item is not going to be fixed, then a separate risk acceptance process has to be started, where the business reviews the issues, associated risks and any mitigations available. Items can then be added onto a risk register and reviewed regularly based on severity.

Scan

This is the same step as above, but this time when the scan data arrives, it needs to be compared and reviewed against the previous data set.

If the issue still exists then any tickets need moving back to the remediation teams with an appropriate status.

Close Ticket

In the event that a security issue is no-longer in the data set, then that element of the aggregate ticket can be closed.

If everything on the ticket has been closed then the entire ticket can be closed.

Prioritise

Jump to the Prioritise box above

Thoughts on the process

Apart from acting upon the ticket, everything else can be automated.

The data flow from start to finish doesn’t require human interaction. Yes, there are some metrics to adjust, like the priority at which a ticket gets created, or how long the remediation team has to fix a security issue with a 90+ score, but this is occasional tuning, not on-going effort.

The above steps are a simplified model, we have a separate blog on the full 8 step model that we recommend you read.

Pillar 4 - Visualisation and Reporting

Why use dashboards?

A common thread across enterprise organisations is that they want to be able to visualise their security posture.

With the average server having 100 vulnerabilities of varying severity, and an enterprise having as many as 10,000 servers, that makes 1 million vulnerabilities. If you then add 50,000 workstations, that is a huge information flow to manage.

With the massive volumes of data being processed it needs a dashboard to visualise the priorities and critical issues.

At S4Applications we like to use 3 tests to assess whether a dashboard is up to the job:

Obvious – I can look at my car dashboard, and in 1 second get the many pieces of information I need. Speed, revs, petrol etc. a red oil light means “stop everything and investigate now”. Vulnerability dashboards should be the same.
Relevant – the right information to the right person.
Active – if I require more information I can click through to drill down to the next level of detail.

Read our blog on Vulnerability Management Programme and using dashboards.

A CISO dashboard

We find the CISO role is interested in the direction of travel (tracking things getting better or worse) and lifting overall company performance.

We have a screenshot of a sample dashboard that we put together for one customer.

The Vulnerability Team dashboard

These operational teams swing from worrying about trends (just like their boss), to firefighting emergencies like Eternal Blue (Wannacry).

We have a screenshot of a sample dashboard that we put together for one customer.

Patching Team dashboard

This really is all about operational data, what needs to be done, when and how. By adding metrics for comparison, it can lift the team’s performance on getting things done.

We have a screenshot of a sample dashboard that we put together for one customer.

Next Steps

If you are interested in seeing a product that could help with any or all of the above 4 pillars, then we would love to talk with you about Brinqa. Brinqa is an enterprise scale tool, deployed throughout this region, to large coroprates and SMEs alike.

To learn more about our products and their key features talk to an expert at S4 Applications. We can work in partnership with your business to take you to the next level of maturity.

Where to start?

S4 Applications can help your business review its ability to protect assets and respond to cyber threats.

Use our Cyber Security Maturity Assessment Model to assess your current security posture, attack surface, and existing plans and solutions. In simple terms, where does your security strategy stand? What are your biggest risks? What are your regulatory and compliance obligations? Where should you focus your efforts? What are your aspirations?

Vulnerability Management Programme