Vulnerability Management Best Practices

Vulnerability Management Best Practices

The Need for Effective Vulnerability Management

We aim to make our users familiar with the best practices of Vulnerability Management, and more specifically, how one can go about managing its environment.

More computers, more software, and faster development cycles lead to more vulnerabilities. The security and IT teams are put under immense pressure to tackle the growing number of vulnerabilities with the same old tools that can’t keep up with the requirements.

Organizations used to have tools for the sole purpose of assessing their assets for vulnerabilities. The assessments were conducted on a periodic basis and inundated the security personnel with huge loads of vulnerabilities, some of which were completely irrelevant. The vulnerabilities had to be researched and reported back to the IT department for further remediation. The complexity of the process led to a situation where a lot of vulnerabilities were left completely unattended, putting organizations at major risk.

Traditionally, companies separated the responsibilities of the security team from the ones of the IT team. But as we progress, and the need for quick remediation becomes more important, we find a growing overlap between the security and IT teams’ responsibilities.

Communicating the urgency of patching vulnerabilities is not always that simple…

 

 

Figure 1: Communication Issues

New technologies emerged to bridge that gap and allow the security team to solve the whole problem, end-to-end, in a seamless manner. Today’s gold standard is for the security team to oversee all vulnerability management processes from a single platform.

Figure 2: Growth in CVEs discovered over the years (by NVD)

 

Core Principles of Effective Vulnerability Management

Vulnerability Management Objectives

The objectives that guide us in defining a VM process:

• Reduce the number of vulnerabilities in the organization
• Decrease the time vulnerabilities exist in the organization
• Generate clear insights for the relevant stakeholders

Discover

In order to find vulnerabilities, we have to understand where the vulnerabilities exist. Therefore, a comprehensive inventory management is necessary to keep an up-to-date view of the organization’s assets:

• What assets exist in the organization?
• What devices exist in the organization?
• What OSes do the assets run?
• What software is installed on the assets?
• How are the assets grouped in the organization?
• Which assets are more important according to their business value?

Once these questions are answered, the environment will be considered mapped.

Figure 3: Get Discovery information

 

Figure 4: Organization overview

 

Analyze

Once the environment is mapped out, it’s time to run a Vulnerability Assessment. Attackers don’t wait for us to assess our systems; therefore, it is critical to use a platform that allows you to continuously monitor your most sensitive infrastructure.

In order to provide the most comprehensive coverage of the vulnerabilities found in the environment, it’s important to not only look for known vulnerabilities, but also analyze the software and find weaknesses within it, which make it more susceptible to exploitation.

Vulnerability assessment should consist of the following elements:

• An analysis of known vulnerabilities, namely CVEs found in the software
• Detect Zero-Days in the software to find unreported vulnerabilities

Figure 5: Application CVEs

 

Figure 6: Application Binary Analysis

Prioritize

This is when the security staff has to go through a hundred-pages vulnerabilities report with lots of data but very little value. Prioritizing vulnerabilities has become just as important as finding them due to the sheer number of vulnerabilities organizations have to face nowadays.

The security analyst followed a standardized procedure, using the CVSS score to evaluate the risk level of the vulnerabilities. The CVSS score is based on the impact of a particular vulnerability and its exploitability. But vulnerabilities don’t exist in a vacuum. The environment the vulnerabilities are in plays a critical role in determining the risk they pose to the organization. Factoring in the environmental aspects of the vulnerability is essential for gaining accurate insights to the actual risk level of the vulnerability.

Prioritizing risk by merely using the CVSS score might have been adequate in the past, but with the growing number of vulnerabilities, organizations can’t afford false positives and inaccuracies that incur costs.

"In effect, the CVSS score blurs the distinction between practical and theoretical risk," the report says. "Relying exclusively on the CVSS score leads to a higher volume of 'critical' vulnerabilities to sort through -- and less ability to effectively prioritize the highest risk vulnerabilities." ZDNet

Let’s take an app, say Internet Explorer. It may have a Remote Code Execution vulnerability with CVSS score of 9.8, but if the asset never runs the application, it can't be exploited.

Remediating such vulnerabilities is like putting the safety belt on when the car is parked. The belt is only effective if the car is moving. Instead, the IT team should focus on fixing vulnerabilities which have a high probability of being exploited.

The only way to tell the app is never used is by monitoring the app’s activity and analyzing it in real time.

Contextual execution properties, like App Usage, may include:

• Networking Activity - open ports, packets sent and received
• Process Privileges - which user runs the process
• App Usage - when the apps run and how long

Better Understanding of the Environment = Less Vulnerabilities

 

Figure 7: Contextual execution properties - xTags

The prioritization should be based on the risk of the vulnerabilities (e.g CVSS score), the vulnerabilities’ environment, and external sources that complete the picture (e.g exploit-db, darknet forums). The prioritization engine should take the data from the different sources and evaluate software and asset risk level. Prioritization reduces the number of vulnerabilities that should be addressed, allowing you to focus on patching the most critical vulnerabilities.

Figure 8: App Risk Map

Remediate

So you end up with a list of the most critical apps instead of thousands of CVE vulnerabilities. But how are you going to fix them? At this point back in the day, the security professionals’ job was done. Patching software was in the realm of the IT department.

In order to decrease the time vulnerabilities exist, solutions should provide not only the information about them but also remediation capabilities. Remediation may come in many forms, but its goal is to reduce the risk associated with a vulnerability.

The most common form of remediation is patching. Patches are effective for vulnerability remediation because they are tailored for them. But from the time of the disclosure until a patch is released, there’s a significant period where the organization is at risk. Organizations are hesitant to run the risk of discontinuing their operations due to changes in the software as well as the requirement of some of the patches for a reboot. Patches are an essential part of the solution, but they are not sufficient for full coverage.

Remediation should be done using patches as well as other forms of protection, such as in-memory protection technologies, which provide the flexibility to protect any software from malicious attacks without having to change the production software or restart any servers.

By applying Patchless Protection™, mission-critical infrastructure can be safe without applying vendor-made patches.

Figure 9: View of the most critical patches

 

Figure 10: In-memory protection of software with no vendor patches available

We remediate better, but can we remediate more?

The IT team has better things to do than spending the second Tuesday of every month patching security updates. That’s where automation kicks in—outsource the pain of having to find the vulnerabilities in all software, evaluate the risk they pose to the organization, and remediate them.

Why automation is the way forward:

• Reduce the number of people required for Vulnerability Management
• Reduce the vulnerability mitigation time
• Not leaving critical vulnerabilities unattended

Automation is key in facing the growing complexity of the vulnerability management process and reducing the manpower required for accomplishing VM related tasks.

Figure 11: Decrease in the costs of VM facilitated by automation

 

Generate Insights

Organizations need to know they are safe. Therefore, every security solution must provide means to communicate its insights clearly to the stakeholders. The insights may come in many shapes and forms, depending on the stakeholder.

For the C-Suite executives, the required insights are an overview of the security posture of the organization, which can be a report reviewing the highest priority risks as well as actions that took place to remediate risks in a specific time frame.

The security team’s requirements may vary depending on the systems the organization uses to manage their security data. Means of communicating the insights include:

• Dashboard overview of the organization’s vulnerabilities
• Reports for the security team - vulnerabilities, inventory, prioritization, remediation etc.
• Regulatory compliance reports
• SIEM integration
• API integration
• Mail notifications

These means of communication allow the security team as well as the management to stay updated on the organization’s security status.

Figure 12: Summary Report

Bringing it all together

Vulnerability Management is a continuous process that entails gathering data from different sources, evaluating risk posed by vulnerabilities, and reducing the risk by applying remediation techniques. The organizational landscape changes as the assets of the organization scatter and more computers and software are added in.

An effective Risk Based Vulnerability Management solution should provide the tools to find more vulnerabilities and keep the number of critical vulnerabilities as low as possible while allowing for the remediation of the critical vulnerabilities wherever they are, whether on-premise, cloud, or at home.

Figure 13: Vulnerability Management Phases

 

A Vulnerability Management Procedure

Overview of the process

This procedure will outline the steps that should be implemented to facilitate the Vulnerability Management process. The procedure is modular and can be restructured based on specific organizational policies and requirements.

Choosing the stakeholders for the VM process

Decide who are the relevant stakeholders for the process and what are their responsibilities.

• Who are the stakeholders - security team/ IT department / higher management / asset owners?
• Who is in charge of executing each phase?
• Who should approve each phase?
• To whom should each phase be reported?

Choosing a Threat Model

Depending on the organization’s threat model, there are different approaches for remediating vulnerabilities.

• Focus on risk level - remediate most critical vulnerabilities first
• Focus on assets - remediate vulnerabilities in the most critical/sensitive/vulnerable assets first
• Focus on software - remediate threats in the most critical applications according to their business value
• Focus on attackers - remediate based on prior information of what vulnerabilities hackers may attempt to exploit

Any mix of the above strategies can be used to address the threats in the most effective way for a specific organization. The procedure is subject to change based on the threat model chosen.

What should be considered when choosing the right threat model for your organization:

• Organization size
• Integrations with other security systems
• Existing patching policies
• Regulatory requirements
• SLA of the systems

Determine the risk tolerance of the organization

The relevant stakeholders from the organization should decide and understand the level of risk the organization can tolerate to its business continuity as well as the confidentiality of its data:

• How long vulnerabilities with different risk levels can exist
• What is the business impact for potential downtime, and how to build patching windows accordingly

Vulnerability Remediation Process Guidelines

Planning Phase

1. Choose the stakeholders for the process
2. Choose a Threat Model
3. Determine the time frame for remediation of vulnerabilities according to their risk levels
4. Determine the downtime allowed for specific assets according to the organization’s policy
5. Decide the frequency at which the vulnerabilities will be reviewed, depending on the size of the organization and its policy (daily/weekly/monthly etc.)

Environment Setup Phase

1. Add all the inventory to the dashboard
2. Create asset groups for management purposes. Such groups can be based on:

• Risk
• Risk level of the applications
• Risk level of the assets
• Business impact - based on business value and sensitivity of the assets
• Organizational units
• Physical locations - branches
• Departments of the organization
• Existing OUs in a domain
• Other
• Computers that run specific applications/OSes
• Group with a specific role - development/production servers etc.
• Group for a specific purpose - pre-prod testing etc.
• Status of the assets

Initial Assessment Phase

The first time vulnerabilities are remediated. The initial assessment and remediation will baseline the threats to the organization on a low threshold, which will allow for the continuous remediation of novel threats.

1. Find the highest risk software or most critical OS security updates. Filter by either the software or asset according to the threat model chosen.
2. Get relevant remediation for the vulnerabilities.
3. Refer to the Pre-Prod appendix.
4. Apply the relevant remediation.
5. Refer to the Validation appendix.

Continuous Remediation Phase

Ongoing remediation of vulnerabilities throughout the organization’s systems. When new vulnerabilities are detected, apply the recommended form of remediation. Automation can be used to facilitate the continuous remediation process.

1. Review the VM platform and find vulnerabilities in third-party applications and operating systems.
2. See relevant vulnerabilities on the platform and review the risk they pose to the organization.
3. Get relevant remediation for the vulnerabilities. Decide on the form of remediation in accordance with the organization’s policy.
4. Refer to the Pre-Prod appendix.
5. Apply the relevant remediation.
6. Refer to the Validation appendix.

Organizational Changes

Upon major organizational changes, which may include the addition of a significant number of new assets or software to the existing inventory, we advise to review the changes via a Vulnerability Management Platform and begin the process from the start.

Summary

Vulnerability Management changes constantly, and it’s important to keep abreast of the latest developments and methodologies. This procedure offers a structured approach to the process, and involves monitoring the different phases more closely to sustain a strong security posture long-term.

Because of the security challenges organizations face nowadays, it’s important to offload as much of the process as possible to vulnerability management platforms that facilitate the most efficient remediation of vulnerabilities.

Do you want to consult with us on the best approach for your VM program?

Let us know in the comments below.

Figure 14: VM Diagram

Pre-Prod Testing Appendix

Create an asset group to check a specific remediation in your environment in a controlled manner before deploying it to the rest of the organization.

1. Create an asset group that includes computers for patch testing purposes. Make sure the unpatched version is installed on these computers.
2. Run the patch installation on these computers. Make sure if a patch requires a reboot, the system is rebooted.
3. Check that the patch does not affect the functionality of the system.

Validation Appendix

Verify the remediation succeeded.

1. Review the remediation result logs from a dashboard or report. Check if the remediation was applied to all computers.
2. Make sure if the patch requires a reboot that the relevant computers were rebooted.
3. Review the remediation results. Make sure the risk level of the software decreases.

 

LIVE! On Security Weekly

Gilad and Roi join the show to discuss vulnerability management best practices: