5 Best Practices to Automate Your Vulnerability Management Process

Executing a well-run vulnerability management program is essential to protecting against data breaches and ensuring the availability of your IT infrastructure. Most of us are already familiar with the impact that data breaches can have on organizations and the fact that unpatched vulnerabilities increase the likelihood of breaches if the vulnerabilities are being exploited in the wild. The Equifax data breach that originated from an unpatched Apache Struts vulnerability is just one example of this.

The challenges to executing a well-run vulnerability management program continue to increase as the pool of vulnerabilities grows and as the time to patch these vulnerabilities before they are exploited is reduced. To address these challenges and improve your security posture, it is essential that you automate key elements of your vulnerability management program.

Best Practice 1: Automate tasks that disrupt as few people as possible

Most organizations already have a team of people responsible for prioritizing vulnerabilities and a team of people responsible for remediating or mitigating these vulnerabilities within predefined timeframes. Usually, the remediation and mitigation teams are significantly larger than the team responsible for prioritizing vulnerabilities. For this reason, it usually makes sense to start with automating the tasks of the vulnerability management team while introducing as few of changes to the teams remediating and mitigating vulnerabilities as possible.

For example, many IT teams are currently using a dedicated ticketing system to manage their tickets and associated workflows and would prefer to continue to do so. They would rather deal with the systems that they know and have standardized on for all their tickets. For this reason, it is essential that the vulnerability management tool you select be able to create tickets with desired grouping algorithms in these external ticketing engines. It is not sufficient to create a single ticket per vulnerability instance in these other tools because there will simply be too many tickets. Rather, tickets should be created using a vulnerability grouping algorithm that approximates how the vulnerabilities will be patched or mitigated, such as by vulnerability by operating system and by BU or geographic location. 

Once created, the vulnerability management system should be able to synchronize with these external ticketing systems to know when a ticket has been remediated and or closed in these external systems so that it can either trigger a rescan or send a notification to initiate a rescan to confirm the vulnerabilities were successfully remediated.

Similar to tickets, the broader and deeper a vulnerability management tool has integrations with other systems used by the various stakeholders of the vulnerability management process such as CMDBs, vulnerability scanners, threat feeds, and risk management tools, the fewer number of people will be impacted by automating vulnerability management.

Best Practice 2: Ensure your vulnerability management system can deliver information without requiring users to log in

This is a broad requirement that impacts many areas, some of which are mentioned below. Cutting across all these areas is the essential requirement that users should not have to remember to log on to the vulnerability management system for critical tasks to occur. If this is required, then it is likely that some critical findings will be overlooked or not remediated or mitigated as rapidly as they otherwise would be.

To be able to execute upon this best practice, a vulnerability management system must possess multiple capabilities that include the following:

• Ability to create tickets with the appropriate due dates in one or more ticketing systems at the same time and in accordance to rules that govern which ticketing system should be used and how vulnerabilities should be grouped within each system.
• Ability to include additional supplemental information that the remediation teams require be present in the ticket such as details on vulnerability ID, title, solution, description, port, protocol, first seen, last seen in a usable format whether as additional fields of the ticket or as a CSV file.
• Ability to tie each vulnerability instance to an owner so that this person can receive notifications and reminders.
• Ability to look up each vulnerability owner’s manager and second-level manager in an appropriate HR system to send escalations to for overdue remediations.
• Ability to schedule reports to be sent by email or to be placed in a network folder.

Best Practice 3: Automate vulnerability prioritization by means of risk scoring

As with all remediation and mitigation activities, prioritization should be based on the risk to the organization. Calculating the risk of a specific vulnerability on a specific asset considers the impact and likelihood of that vulnerability being exploited on that asset. 

Some factors that influence the impact of a specific vulnerability being exploited on a specific asset include:

• The criticality of an asset to the organization in terms of Confidentiality, Integrity, and Availability. 
• Whether the asset is in scope for PCI or another standard
• The number of other systems that are dependent upon that system, such as Active Directory, which is used to manage multiple other systems 
• Whether certain compensating controls like encryption may be in place 

Some factors that influence the likelihood of a specific vulnerability on a specific asset include:

• Whether there is a known exploit
• Whether threats are leveraging the exploit
• The degree of complexity of the attack
• Whether the attack can be conducted remotely, through an adjacent network or must be done locally on the asset
• Whether user interaction is required for exploitation
• Whether the asset is Internet-facing or is removed from the Internet by one or more firewalls
• Whether one or more compensating controls are in place that lessen the likelihood of an attack, such as blocking specific ports on a firewall and network segmentation

While it is possible to simply use CVSS Base scores or vulnerability severity as determined by scanner, these metrics don’t consider all the above factors and may result in an incorrect prioritization. For this reason, Gartner predicts by 2022, organizations using a risk-based vulnerability management methodology and process will suffer 80% fewer breaches.

It is simply not possible to do this type of risk-based analysis for all vulnerabilities on all assets without automation. Therefore, it is essential to adopt a vulnerability management system that supports automated calculation of risk scores. 

Best Practice 4: Provide transparency into results, reminders, and escalations 

The way to make people accountable is to provide views of open vulnerabilities, open tickets, and KPIs by owner up through the management chain. Email notifications, reminders and escalations drive further accountability. 

Dashboards for each level of management are used to report the key metrics and KPIs. Examples of KPIs that are useful to measure include:  

• Average Time to Remediation, which can be calculated as the average number of days to close tickets
• SLA Compliance – % of tickets fixed prior to due date.

Email notifications, reminders and escalations drive further accountability by ensuring that tickets, especially tickets past their SLA date, get the proper attention from both their owners and management. Examples of notification, reminders, and escalations that may make sense to send include the following:

• Notification for newly generated tickets
• Notification to provide weekly review of outstanding tickets
• Reminder of tickets due in a week
• Reminder of tickets that have reached their due date
• Reminder of tickets a week past their due date 
• Reminder of tickets 2 weeks past their due date
• Reminder of tickets 3 weeks past their due date
• Reminder for tickets 4 weeks past their due date
• Escalation to the owner’s first-level manager of tickets 2 weeks past their due date
• Escalation to the owner’s first and second-level managers of tickets 4 weeks past their due dates

Best Practice 5: Choose a system that can accommodate changing needs and growth

It is important to adopt a vulnerability management system that is flexible so that it can grow with your organization as it improves its vulnerability management-related processes. Examples of important areas that should be able to be readily adapted include the following:

• Adding new fields to various objects within the UI, such as assets, vulnerabilities, and threats
• Adding new data sources
• Adding new fields from existing data sources
• Adding new notifications, reminders, and escalations
• Adding or changing fields in existing notifications, reminders, and escalations
• Adding or modifying workflows
• Modifying risk calculations 

Scalability of a vulnerability management platform is essential so that it can accommodate both a greater number of assets and vulnerabilities and new tasks for existing data. As the scope of your automated vulnerability management program increases, you will need to add assets to the system. It’s also important to be able to accommodate additional functions that you may want to perform within your vulnerability management program. For example, the more metrics you want to trend, the greater the load on computing resources. Similarly, generating additional reports and integrating with additional data sources requires additional computing resources.

How to Implement Vulnerability Management Best Practices

Adding automation to your organization’s vulnerability management program will provide your organization with multiple benefits like increased accuracy when prioritizing vulnerabilities, reducing the chance of human errors, increased compliance with SLAs, and greater efficiency of your vulnerability management team. The right vulnerability management software can help with ensuring that your vulnerability management program adheres with the best practices that we’ve discussed.