Vulnerability Management

Table of Contents

• Vulnerability Management
  • Table of Contents
  • Goals of threat and vulnerability management
    • Goals
  • Requirements
    • Functional Requirements
    • Non-functional Requirements
  • The Proces
    • Identify vulnerabilities and misconfigurations
    • Classify vulnerabilities and misconfigurations
    • Resolving vulnerabilities and misconfigurations
    • Reporting
  • Exception Handling
    • Vulnerabilities and misconfigurations can’t get resolved
    • The number of vulnerabilities/misconfigurations increases
    • The number of vulnerabilities and misconfigurations is to high
  • Domain Model
    • Domain objects
    • Domain model
  • Technology
    • Azure Security Center
    • Defender for Endpoint
    • Vidara

Goals of threat and vulnerability management

Threat and vulnerability management is the process of identifying, classifying, and resolving misconfigurations and vulnerabilities. In cyber security, a vulnerability is a weakness which can be exploited by a cyber-attack to gain unauthorized access to or perform unauthorized actions on a computer system. Vulnerabilities can allow attackers to run code, access a system’s memory, install malware, and steal, destroy or modify sensitive data.

To exploit a vulnerability an attacker must be able to connect to the computer system. Vulnerabilities can be exploited by a variety of methods including SQL injection, buffer overflows, cross-site scripting (XSS) and open-source exploit kits that look for known vulnerabilities and security weaknesses in web applications.

A misconfiguration is a setting that is set and will make the IT environment vulnerable. An example of a misconfiguration can be: “a firewall rule that opens port 3389 on a public IP address”. Open misconfigurations become dangerous when legitimate services are exploited through security vulnerabilities or malicious services are introduced to a system via malware or social engineering, attackers can use these services in conjunction with misconfigurations to gain unauthorized access to sensitive data.

Threat and Vulnerability management is proactive, seeking to close the security gaps that exist before they are taken advantage of. When not treated well, misconfigurations and vulnerabilities will increase the risk and chance of getting attacked.

Goals

This service has the following goals:

• Reduce the chance of getting attacked by resolving misconfigurations. This will make it harder or even impossible to exploit vulnerabilities.
• Reduce the risk of getting attacked by resolving known vulnerabilities.
• Reduce the impact of an attack by resolving misconfigurations and vulnerabilities. This will make it harder or even impossible to traverse trough the IT network.
• Reduce the number of alerts generated by various security products. By resolving vulnerabilities and misconfigurations, sensors are less likely to trigger, because actors are not able to execute actions that will trigger them.
• Report on the risks found in an IT environment

Requirements

This part of the process description describes the requirements on which the proces should be compliant. For this business service, there are functional and non-functional requirements described.

Functional Requirements

Functional requirements are requirements that describe the functionality of this business service. The following requirements have been defined:

• On a per period basis, the customer (or IT-operating partner of the customer) should receive a request to resolve a set of vulnerabilities in the upcoming patch-management execution.
• The number of vulnerabilities requested to mitigate per patch-management cycle should be configurable per tenant.
• Per period the vulnerabilities and misconfigurations with the highest severity will be part of the request.
• Service users (e.g., the MDR team) should be able to add vulnerabilities that need to be patched to the mitigation request. This is helpful in situations where an incident happens on a vulnerability would normally not be part of the upcoming mitigation request.

Non-functional Requirements

Non-functional requirements are requirements that do not add any functionality but define service attributes such as performance, scalability, security, etc.

• The business service should be designed in such a way that the services can run fully automated; meaning the recurring effort of humans should be kept to a minimum.
• Performance of the service should be measured to address performance related issues or enhance performance.

The Proces

The threat and vulnerability management process can be broken down in the following steps:

• Identifying vulnerabilities and misconfigurations
• Classifying/evaluating vulnerabilities and misconfigurations
• Resolving vulnerabilities and misconfigurations
• Reporting on vulnerabilities and misconfigurations (gaining insight in the risks found in the IT environment)

The process will run with an interval (e.g., once in two weeks). Identified misconfigurations and vulnerabilities that are classified as “needs remediation” will get remediated in this run (iteration) of the process. The process will work with an interval as there is a dependency on the patch management and change management process. These dependent processes might run manually.

Below a diagram of the flow of this process is described.

Identify vulnerabilities and misconfigurations

The first part of the threat and vulnerability management process is identifying the vulnerabilities and misconfigurations. This identification process is executed through smart vulnerability and misconfiguration scanners. Misconfigurations could also be reported trough the Incident Management Process.

The result of these scanners should at least include:

• The CVS score of the vulnerability
• The severity of the misconfiguration or vulnerability

The results of this identification process will be stored as risk items in Vidara. These risk items can be used to track and automate the TVM process

Classify vulnerabilities and misconfigurations

In this phase of the process misconfigurations and vulnerabilities will get classified. The goal of this step is to distinguish between vulnerabilities that need to be resolved in this iteration, and vulnerabilities that do not need action in this iteration.

Depending on the capacity of the patch management process, a certain amount the vulnerabilities and misconfigurations with the highest risk will get classified as “Needs remediation”. The risk will be determined based on the CVS score, severity, and context of the customer. The capacity of the patch management process can be different per customer.

The mix of vulnerabilities and misconfigurations can be configured. Per customer the number of vulnerabilities and misconfigurations that needs to be resolved per iteration of this process, can be configured.

Resolving vulnerabilities and misconfigurations

In this part of the process, misconfigurations and vulnerabilities will get mitigated. The technical activities of mitigating vulnerabilities and misconfigurations are however not part of the threat and vulnerability management service. The customer (or their operating company) is responsible for planning and executing the mitigation activities. This is most likely done through a patch management process.

Wortell MDR has a good overview of the IT infrastructure of the customer but no in-dept knowledge of the customer infrastructure. Resolving vulnerabilities and misconfigurations could led to malfunctioning applications and will have an impact on the business continuity of the customer. Therefore, executing the technical activities isn’t part of the threat and vulnerability service.

As part of this phase, all vulnerabilities and misconfigurations that have been classified as “Needs remediation” will get summarized in a vulnerability remediation request. This request will get send to the customer technical contacts.

Reporting

On a periodic basis, Wortell will make a threat and vulnerability management report available. Aside from reporting on the vulnerabilities and misconfigurations found, this report will also show trends. These trends can help with validating if a customer is still on track in reducing the risks that are introduced by vulnerabilities and misconfigurations.

Exception Handling

Exception handling is the process of responding to the occurrence of exceptions (failures) of the service. Exceptions require special processing of the business service. The following exceptions have been identified on forehand:

Vulnerabilities and misconfigurations can’t get resolved

It might be that for a couple of iterations of the vulnerability management process the same vulnerability is addressed. To resolve this issue, one of the below actions should get executed:

• Investigation and assistance in patch management with support of Wortell Enterprise Security Projects
• Put the vulnerability/misconfiguration on the ignore list so it won’t be identified in the next iteration. This is not the preferred way to solve this solution as this will have impact on the security of the IT infrastructure. It can however be an solution for situations where a machine can’t be patched or configured (e.g. there is a dependency on older hardware/software which will not work with the vulnerability patch).

The number of vulnerabilities/misconfigurations increases

The threat and vulnerability management process is designed to lower the number of vulnerabilities in the IT environment. If the number of vulnerabilities or misconfigurations still increases, there might be something wrong. In this case the following actions can be executed:

• The customer/tenant owner needs to get informed about this exception. Various technical reasons are possible that will result in an increasing number of vulnerabilities or misconfigurations (e.g., an old image with vulnerabilities in it is used or a ARM template with a misconfiguration in it gets deployed).

The number of vulnerabilities and misconfigurations is to high

The threat and vulnerability management process works in iterations. For each iteration a set of vulnerabilities and misconfigurations is requested to resolve. If the number of vulnerabilities/misconfigurations requested to resolve is too high, the following actions can get executed:

• Lower the numbers of misconfigurations and vulnerabilities that need to get resolved per iteration.

Domain Model

This chapter will describe the domain model of the threat and vulnerability service. A domain model is a conceptual model of the domain that incorporates both behavior and data. A domain model consists of objects and relations between those objects.

Domain objects

The following objects have been identified as part of this business service:

• Misconfiguration
• Vulnerability
• Riskitem
• Remediation request
• Tenant configuration
• Tenant
• Customer

Domain model

Below is a schematic view of the domain model displayed. The goal of this domain model is to describe the relations between business objects.

Technology

Threat and vulnerability management requires excellent tooling to function well. The amount of software and infrastructure used at customers does not allow for a manual threat and misconfiguration scan. This part of the service description describes the tools that are required to run this business service.

Azure Security Center

Azure Security Center is a unified infrastructure security management system that strengthens the security posture of your data centers, and provides advanced threat protection across your hybrid workloads in the cloud - whether they’re in Azure or not - as well as on premises.

Keeping your resources safe is a joint effort between your cloud provider, Azure, and you, the customer. You have to make sure your workloads are secure as you move to the cloud, and at the same time, when you move to IaaS (infrastructure as a service) there is more customer responsibility than there was in PaaS (platform as a service), and SaaS (software as a service). Azure Security Center provides you the tools needed to harden your network, secure your services, and make sure you’re on top of your security posture.

Azure Security Center will be used to scan for misconfigurations and vulnerabilities in cloud (Azure) related resources.

Defender for Endpoint

Threat and vulnerability management is built in into Defender for Endpoints. It is real time, and cloud powered. It’s fully integrated with Microsoft endpoint security stack, the Microsoft Intelligent Security Graph, and the application analytics knowledge base.

Discover vulnerabilities and misconfigurations in real time with sensors, and without the need of agents or periodic scans. It prioritizes vulnerabilities based on the threat landscape, detections in your organization, sensitive information on vulnerable devices, and business context.

Defender for endpoints will be used as vulnerability scanner for endpoints (on premise or in the cloud).

Vidara

Vidara is a security platform created by Wortell. This platform will support Wortell in their security operations. In order to execute threat and vulnerability management, Vidara will get a risk management module. Risks can either be a vulnerability or a misconfiguration.

Vidara will connect with Azure Security Center and Defender for Endpoints to collect identified misconfigurations and vulnerabilities (risks) in the customer environment. On a periodic basis a set of risks will get bundled in a remediation request. This remediation request will get send to the technical contacts at the customer. The technical contacts can fulfill the remediation request as part of their patch management process.

Vidara will automate the threat and vulnerability management processes where possible and will make sure TVM data is accessible for incident responders.