Integrate Vulnerability Data for Analysis and Remediation
Learning Objectives
After completing this unit, you’ll be able to:
- Describe a vulnerability assessment analyst's role in integrating data sources for analysis.
- Detail how a vulnerability assessment analyst develops a risk-based approach to remediation.
- Identify how vulnerability assessment analysts work with application and system remediation owners.
Integrate Sources of Vulnerability Data
You’ve scanned for vulnerabilities, and now it’s time to consolidate and prioritize your vulnerability finding for remediation based on the business impact. As a vulnerability analyst, part of your job is to correlate all vulnerability data across your organization into a single view (usually in a vulnerability management dashboard) so you can identify, prioritize, and fix vulnerabilities faster.
Let’s take a look at some of the data sources that you should integrate.
Data Source |
Uses |
|---|---|
|
Scanner Data
|
You use past and present scan results about your target system’s vulnerabilities. |
|
Penetration Test Findings
|
You use these to determine how an adversary could potentially exploit a vulnerability and compromise your data. |
|
Asset Management
|
You integrate vulnerability data with your asset management system to add context such as which business units own the system vulnerabilities and what critical systems are impacted. |
|
Threat Intelligence (open source or internal feeds)
|
You consider this data to determine what types of threat actors may be interested in targeting the vulnerability, and whether any other relevant threat trends are happening now. |
|
Organizational Governance, Risk, and Compliance
|
You assess whether any of these vulnerabilities could have compliance implications, and consider your organization’s governance and risk policies in the remediation process. |
|
Change Management Processes
|
You take into account what processes are required and what other parties are impacted when implementing patches or configuration changes. You also consider whether a change introduces any new vulnerabilities. |
|
Auto-generated Ticketing Systems (Jira, ServiceNow, and so on)
|
You use these systems to help you track the remediation workflow. |
|
Analytics Tools (Python, Tableau, R, Apache Spark, and so forth)
|
You leverage these types of analytics tools to identify patterns, trends, and anomalies of vulnerability data in a visual format. |
Develop a Risk-Based Approach to Remediation
Let’s follow along with Jani, a vulnerability assessment analyst at a nonprofit. He has integrated scanner, asset management, threat intelligence, and other data for analysis. Next he will evaluate and consider possible risks to help contextualize the findings from his vulnerability assessment.
Jani’s scanning tool produces scores of host and other vulnerabilities with severity ratings. He then adds his organization’s business and infrastructure context to derive meaningful and actionable information about business risk. This helps him prioritize vulnerability remediation efforts. It also helps him support the organization’s risk assessment and risk-based decision making. He knows that the ultimate goal is to recognize any weaknesses in systems that could allow access to cyber invaders.
The Vulnerability Management Balancing Act
Determining how to prioritize vulnerabilities is a balancing act. Jani completes this task in coordination with the affected system and remediation owners. He knows that assigning the wrong priority to a finding is a double-edged sword: If it’s too high, it means time, money, and resources are wasted on a nonurgent fix, and if it’s too low, it means he’s not giving the proper attention a finding deserves, thus potentially increasing the overall risk that the vulnerability will be exploited.
To avoid inflating the severity of a vulnerability, Jani verifies which attack scenarios are actually relevant to the specific context. He analyzes the likelihood that an attacker could exploit the vulnerability, and the likely impact to the organization if an attacker was able to compromise a system and steal, alter, or destroy its data.
Jani uses this information to adjust the assessment of how severe the vulnerability is. He also balances security best practices with what is realistic for the remediation team to implement, commensurate with his organization's risk posture. For example, if a fix requires a large amount of time and resources for a relatively small improvement in the system’s security posture, it may make sense to deploy limited development resources elsewhere to focus on higher impact vulnerabilities.
When analyzing which vulnerabilities to remediate first, Jani prioritizes them based on a defined rule set. He generally starts by fixing the easy-to-remediate vulnerabilities with known exploits. He then extends his program to risk-based prioritization.
Jani prioritizes vulnerabilities based on risk by considering whether the vulnerability threatens an important system and any downstream dependencies. Examples include:
- Systems dealing with access control or data protection
- Cloud infrastructure with virtual private network (VPN) access to the organization’s network
- Applications or databases in production
Think About the Big Picture
Jani considers not just individual systems, but also the attack path to high-risk assets. He knows that attackers can chain together multiple vulnerabilities to move through his organization’s environment. He also considers not just individual vulnerabilities, but patterns. For example, how many assets are affected by a given vulnerability? Are any of these assets critical or important?
Finally, he considers whether existing controls provide a layer of protection against the vulnerability. However, he knows that just because a control exists does not mean the system is 100% secure. He knows it’s important to weigh the criticality of the system against existing protections to determine which vulnerability could expose his organization to serious risk.
Time Is of the Essence
Once Jani has prioritized the vulnerabilities, he next sets timelines and thresholds for remediation by severity, commensurate with his organization's risk management program. The timelines outlined below are examples and should not be taken as set in stone.
- Critical: 7 days
- High: 2 weeks
- Medium: 1 month
- Low: Patch-driven updates
Don’t ignore older vulnerabilities. Breaches often exploit a long-present vulnerability that should have been remediated.
Assign Vulnerabilities and Work with Remediation Owners
Once Jani has prioritized vulnerabilities for remediation using a risk-based approach, it's time to form a plan for remediation. He knows he doesn’t need to shoulder the burden of remediation alone. As a vulnerability analyst, it’s his job to work with the people who have the skills and knowledge to remediate the vulnerabilities. He knows that the technology remediation owner is often a different person from the application owner as listed in the system of record.
Jani works with the remediation owner to provide them with clear and actionable remediation advice. Examples of remediations include introducing new security procedures, measures, or tools, patching, or removing a device or application from the network. He helps remediation owners prioritize and consider what type of remediation makes sense in each situation.
Once they have decided upon the best course of action, it's time to track the remediation. Jani reviews plans to remediate vulnerabilities and integrates his vulnerability management system with his ticketing system, Jira. He knows automated ticketing makes it much easier to assign and track remediations.
Exceptions
Sometimes vulnerabilities can’t be remediated in a timely manner, which makes it necessary to put an exception in place. When putting in place exceptions, Jani gets approval from the risk owner (normally the person who is financially responsible for the system). He knows that the exception should never be viewed as the end goal, but rather as a way to document risk until he finds a more permanent solution. In practice, this is called a risk acceptance and the risk should be reviewed regularly until closed.
Some reasons to use exceptions are as follows.
- There may be compensating controls in place to reduce the risk.
- There is no available fix for the risk at the moment.
- The remediation could affect service availability or service contracts.
When documenting exceptions, Jani converts technical risk into business risk, so his leadership in charge understands the impact to the business if this vulnerability is exploited. He knows that exceptions can be delayed but should not be put off forever. He reviews exceptions at a regular cadence to determine if a mitigation is available. Once an exception is granted, if a method to eliminate or reduce the vulnerability becomes available, the vulnerability should be remediated from that point provided there are no adverse impacts to other critical systems.
Scan and Scan Again
The final step of vulnerability remediation is to scan again to validate that the remediation has been implemented. Jani rescans his organization’s systems to validate remedial actions and ensure compliance with security policy and regulatory requirements. Since IT environments are in constant flux due to software updates, system configuration changes, and other factors, he knows he should assess and scan for vulnerabilities regularly to ensure no new vulnerabilities have been introduced. A vulnerability assessment analyst’s work is never done! Hooray, job security!
Now you understand more about how to integrate data, prioritize vulnerability for remediation, and manage exceptions. Lastly, let’s turn to how to track and report on vulnerability metrics.
Resources