Vulnerability Response - Functional Insights<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } What is a Vulnerability? A vulnerability is a weakness or flaw in a system, software, or network that can be exploited by a threat actor, such as a hacker, to gain unauthorized access or cause damage. Vulnerabilities can exist in various forms, including software bugs, configuration issues, or gaps in security policies. Explanation: Imagine your house: Vulnerability: This is like leaving a window open in your house. If a window is left open, a burglar could potentially enter your house through that window. In the context of computers and networks: Vulnerability: It's a weak spot in your software, hardware, or security setup that hackers can exploit to get into your system or steal your data. Examples: Software Bugs: A mistake in the coding of a program that allows hackers to gain control of your computer.Outdated Software: Using old versions of software that have known security flaws that hackers can easily exploit.Weak Passwords: Simple or commonly used passwords that are easy for hackers to guess.Unsecured Wi-Fi: A Wi-Fi network without a password or with a weak password that anyone nearby can connect to and potentially access your personal information. Importance of Addressing Vulnerabilities Prevent Data Breaches: Protect sensitive information from being stolen.Maintain Trust: Ensure customers and users trust that their data is secure.Avoid Financial Loss: Prevent financial losses due to theft or damage caused by cyber-attacks.Comply with Regulations: Meet legal and regulatory requirements for data protection and security. What is Vulnerability Response(VR) ? Vulnerability response refers to the processes and actions taken by an organization to identify, assess, prioritize, and mitigate security vulnerabilities in their systems and applications. This is a critical aspect of cybersecurity management that aims to prevent attackers from exploiting weaknesses in software or hardware. Real-Time Scenario: WannaCry Ransomware Attack A prominent example of vulnerability response in action is the response to the WannaCry ransomware attack in May 2017. Background: Incident: The WannaCry ransomware attack affected hundreds of thousands of computers worldwide. The malware encrypted files on infected computers and demanded ransom payments in Bitcoin to decrypt them.Vulnerability: The attack exploited a critical vulnerability in Microsoft Windows, known as EternalBlue, which was initially discovered by the National Security Agency (NSA) and later leaked by the Shadow Brokers hacker group. VR Process Explained: Identification: The EternalBlue vulnerability (CVE-2017-0144) was identified and reported to Microsoft, who released a security patch (MS17-010) in March 2017, two months before the WannaCry attack.Assessment: Organizations needed to assess the criticality of the vulnerability.EternalBlue was a critical vulnerability because it allowed remote code execution, enabling attackers to take control of affected systems.Prioritization: Given the severity of the vulnerability, it was prioritized for immediate patching. However, many organizations did not apply the patch in time, leaving them exposed when the WannaCry attack occurred.Mitigation: After the outbreak of WannaCry, organizations had to quickly respond to mitigate the impact. This includes Applying the Patch, Isolating Infected Machines and Restoring from Backups. Applying the Patch: Ensuring that the MS17-010 patch was applied to all affected systems.Isolating Infected Machines: Disconnecting infected systems from the network to prevent further spread.Restoring from Backups: Recovering affected data from backups, if available, to avoid paying the ransom. VR is a vital component of an organization's cybersecurity strategy. The WannaCry incident demonstrates how critical timely patching and effective vulnerability management are in preventing exploitation and mitigating the impact of security threats. By learning from such real-world examples, organizations can strengthen their defenses and improve their resilience against future attacks. Vulnerability Response in an Enterprise: Vulnerability scanning and assessment tools are used by organizations to identify and manage risks posed to their environment. As these tools identify vulnerabilities, this translates to threats posed to the organization. Potential risks the organization be relying on, Reliance on outdated software or misconfigured systemsUnsecured network protocolsDependency on flawed third-party software librariesPoor or inconsistent system administration hygieneBaseline system images that are not hardened Security Teams commonly face challenges in processing and handling the information generated from their vulnerability scanning and assessment tools, specifically around managing a high volume of identified vulnerabilities and crafting actionable response efforts to mitigate the risks that identified vulnerabilities pose to their organization. Challenges with the Vulnerability data: Which identified vulnerabilities should be reviewed first?What do these identified vulnerabilities mean to our organization?Who should be accountable for and own identified risks?Who should be hands-on working to resolve/mitigate these?How do we effectively reduce identified vulnerabilities with the resources we have?What are the potential unintended outcomes of mitigating identified vulnerabilities?What process do we follow to remediate vulnerabilities and track steps taken, follow-up activities?How do we know if we are progressing in reducing our risk posture? ServiceNow Vulnerability Response: ServiceNow Vulnerability Response aims to help both the security teams challenged with handling massive amounts of vulnerability data and the operations teams that own the remediation of these vulnerabilities. Vulnerability Response integrates with leading third-party vulnerability scanning and assessment tools to provide value to security and operations/remediation owner teams. As identified vulnerabilities are brought into ServiceNow, they are correlated with third-party references, organized into actionable tasks, risk-scored with business context, prioritized and assigned to appropriate Teams. Using information from the ServiceNow Configuration Management Database (CMDB), Security Teams can leverage business context to understand better the risk identified vulnerabilities pose to their organization. Why ServiceNow Vulnerability Response? ServiceNow's Vulnerability Response (VR) product stands out in the market due to its unique integration capabilities, automation, and scalability within the broader ServiceNow ecosystem.Here's why it is often chosen over other products: 1. Integration with IT Workflows Seamless Integration with ServiceNow Platform: Since it's built within the ServiceNow ecosystem, VR integrates natively with other ServiceNow modules like IT Service Management (ITSM), Security Incident Response (SIR), and IT Operations Management (ITOM). This allows for end-to-end automation and streamlining of IT and security processes.Single Pane of Glass: IT and security teams can manage vulnerabilities alongside incidents, changes, and configuration items (CIs), avoiding silos. 2. Automation and Orchestration Automated Prioritization: VR automatically prioritizes vulnerabilities based on risk factors such as exploitability, business impact, and severity, allowing teams to focus on critical issues.Orchestration with Playbooks: It enables automated workflows for patching and remediation by triggering actions across integrated tools like endpoint management systems and patching platforms. 3. Risk-Based Approach Risk Scoring: ServiceNow VR considers the criticality of affected assets and their business impact, providing a risk-based approach to vulnerability management rather than focusing solely on technical severity.Contextual Insights: It enriches vulnerabilities with contextual data from CMDB (Configuration Management Database), giving more meaningful insights for decision-making. 4. Third-Party Integrations Broad Integration Ecosystem: ServiceNow VR integrates with popular vulnerability scanners like Qualys, Tenable, and Rapid7, as well as endpoint management tools and other security solutions.API Support: It supports APIs for custom integrations, making it highly adaptable to existing tech stacks. 5.Unified Reporting and Analytics Advanced Reporting: Centralized dashboards provide detailed insights into vulnerability trends, remediation progress, and compliance status.Audit and Compliance: It helps organizations track remediation activities for audits and regulatory requirements. Vulnerability Response Personas: VR users classified into two, Vulnerability Analyst and Remediation Owner. Vulnerability Analyst (VA): Monitor vulnerabilities and make decisions about when to initiate remediation processes. VA primarily uses the Vulnerability Manager Workspace to monitor and decide. Remediation Owner(RO): Complete the remediation tasks necessary to fix vulnerabilities, or submit exception requests. RO primarily uses the Remediation Owner Workspace to work on Remediation Tasks. BASIC TERMINOLOGIES IN VR EXPLAINED: National Vulnerability Database Entry(sn_vul_nvd_entry): NVD is a U.S. government-managed repository that provides comprehensive information about known software vulnerabilities. It is a part of the National Institute of Standards and Technology (NIST) and is closely associated with the Common Vulnerabilities and Exposures (CVE) program. Key Features: Central Repository for CVEs: NVD serves as the authoritative source for all publicly disclosed vulnerabilities cataloged in the CVE List. Each CVE has a unique identifier and detailed metadata. Enhanced Metadata: While the CVE List provides a basic description of a vulnerability, NVD enhances it with additional information such as CVSS Scores: Vulnerability severity ratings based on the Common Vulnerability Scoring System.Vulnerability Type: Categories like buffer overflow, SQL injection, etc.Affected Software: Details of impacted products and versions.References: Links to patches, advisories, or other relevant sources. Sample record of NVD Entry: NOTE: This table extends Vulnerability Entry(sn_vul_entry) Third Party Vulnerability Entry:(sn_vul_third_party_entry) Documented vulnerability from a third-party source. This is a data entry point for vulnerabilities that are imported from third-party tools such as Qualys, Tenable, or Rapid7. It is used to manage vulnerabilities originating from third-party systems, tools, or feeds. This allows to integrate and process data from external sources like vulnerability scanners or threat intelligence feeds. Sample record of Third Party Vulnerability Entry: NOTE: This table as well extends Vulnerability Entry(sn_vul_entry) like NVD Entry Configuration Item: A Configuration Item (CI) is a logical or physical resource in the ServiceNow CMDB. Configuration items represent a device, application, or service that an organization employs. Within ServiceNow, specific tasks and activities are usually related to a specific Configuration Item. A change request to install a software patch onto a database server – is an example of a task related to a specific CI. The database server would have a CI record in ServiceNow's CMDB, where this record would generally contain supporting information about the database server. Supporting information found on CIs may include who the CI is owned by, supported by, paid for by, assigned to, located, etc. Additionally, CIs in the ServiceNow CMDB can have relationships with other CIs. This relationship can shed light onto what other devices, infrastructures, applications or business services a particular CI relates to, is dependent on, is supported by, etc. A web application server may depend on a load balancer and a web application firewall – where each system is unique CIs in the ServiceNow CMDB. All of these CIs may, in turn, collectively support a business service from a top-level view, such as email. Sample record of Configuration item: Detection:(sn_vul_detection) A Detection represents the most granular level finding in Vulnerability Response. A Vulnerable Item will have a Detection for each finding reported by the Vulnerability Scanner. Detection records are the easiest way to see the 1:1 correspondence between Scanner results and ServiceNow data. A Vulnerable item could have more than one detection if: The same vulnerability is found on multiple ports/protocols on a CI orThere are multiple proofs of the finding Third-party vulnerability scanners detect vulnerabilities in different ways. Vulnerable item – Detections relationship Detections have a many-to-one relationship with vulnerable items. Sample record of Detection: Vulnerable Item:(sn_vul_vulnerable_item) Identified vulnerabilities from vulnerability scanning/assessment tools are brought into ServiceNow to create Vulnerable Items. A Vulnerable Item (VI), represents a [Vulnerability] found on a [Configuration Item] The [Vulnerability] is a finding from a particular third-party vendor (Rapid7, Qualys, Tenable, etc.)The [Configuration Item] is the asset in the ServiceNow CMDB that the vulnerability was found on. Sample record of Vulnerable item: Remediation Task:(sn_vul_vulnerability) A Remediation Task (RT), is a single unit of work, representing a collection of similar Vulnerable Items assigned to the same group for remediation. Remediation Tasks can be created automatically as scan findings are imported, using Remediation Task Rules. Consider that in most enterprise environments, large volumes of similar findings/detections from vulnerability scanners can often be mitigated by a handful of specific activities. These activities are usually performed by certain teams that may be responsible for handling similar types of findings/detections – based on the affected Configuration Items (CIs), the nature of the vulnerability that was found, and other criteria. These groupings of similar Vulnerable Items are called Remediation Tasks. Why do we create Remediation Tasks? Create Remediation Tasks to group together vulnerable items that can be remediated by the same owner, on similar Configuration Items, with the same solution, and within the same time period. Remediation Tasks allow Vulnerability Analysts to organize the work that needs to be done without overwhelming Remediation Owners. They also reduce the number of actions a Remediation Owner needs to take by grouping Vulnerable Items that can be acted on in bulk. When do we create Remediation Tasks? The best time to create Remediation Tasks is when a Remediation Effort is created or when a new subset of Vulnerable Items within a Remediation Effort needs to be assigned to a Remediation Owner. Usually, this aligns with the periodicity of new vulnerability scans. How often do we create Remediation Tasks? Remediation Tasks should be created each time new scan findings are imported when the findings are ready to be fixed in a Remediation Effort. Use Remediation Task Rules for subsets of vulnerable items where you are certain the assignment is correct, and you need more granular control over grouping. Use grouping on Remediation Effort creation for larger categories of vulnerabilities, where grouping by Assignment, Configuration Item, and Vulnerability is sufficient. Sample record of Remediation task: Watch Topic:(sn_vul_watch_topic) Watch Topics display a visual representation of the vulnerabilities we are interested to remediate. They can be created to reflect the common categories of vulnerabilities your processes address, and ad-hoc to investigate a new initiative or emerging threat. We can use Watch Topics to monitor remediation progress, investigate areas that need remediation efforts, and create remediation efforts to initiate remediation task work. Why do we create Watch Topics? Watch Topics allow you to: Monitor the number of vulnerable items and the progress of vulnerability remediation.Edit or delete existing watch topics and create new watch topics.Create remediation efforts and automatically hand off remediation tasks to IT teams for only the vulnerabilities you want to be fixed. Create a Watch Topic for any slice of vulnerabilities that you think might require identification, analysis, or remediation efforts, so that you can report on them, investigate when they might be ready for remediation, and initiate remediation efforts. When do we create Watch Topics? Watch Topics can be created at any time, to investigate and monitor a subset of Vulnerabilities. Since Watch Topics are also used to create Remediation Efforts, the most useful Watch Topics capture vulnerabilities that you want to work on during the same timeframe: Create Watch Topics to align with your vulnerabilities classifications and remediation targets.Create Watch Topics to visualize the impact of a new vulnerability, asset segment, or patching/update effort, that might require action. Sample record of Watch topic: Remediation Effort:(sn_vul_remediation_effort) A Remediation Effort (RE) is a collection of Remediation Tasks and Vulnerable Items to be resolved over a certain time period. Remediation Efforts are created from Watch Topics.When a Remediation Effort is created from a Watch Topic, all active Vulnerable Items matching the WT which are not in another RE will be added to the new RE. Why do we create Remediation Efforts? Remediation Efforts are created when the Vulnerable Items in a Watch Topic are ready to be fixed. Creating a Remediation Effort gives you a task-management layer across Remediation Tasks for all owners, so that you can assign work, track progress, and manage remediation activities. When do we create Remediation Efforts? The best time to create Remediation Efforts is shortly after the completion of a new vulnerability scan. Allow some time to import scan findings, analyze the findings, and determine the best Watch Topics to action from the latest scan results. Sample record of Remediation Effort: Core functionalities of Vulnerability Response: Vulnerable Item Assignment: Ownership of Vulnerable items are shown in the Assignment fields: Assignment groupAssigned to Assignment Rules are used to automatically determine assignments for Vulnerable Items, often using data available in the CMDB. These rules are flexible, and often specifically adapted for accurate assignment based on your organization's policy and workflow needs. The goal of Assignment Rules is to set the "Assignment group" value for a given Vulnerable Item (i.e. the appropriate remediation team). Multiple Assignment Rules are often needed. Each has a condition which determines when it is applied, and all assignment rules are run in order – the first condition to match the Vulnerable Item determines the assignment. VR Assignment Rules Flow: Product doc reference: Assignment Rules Sample record of VR Assignment Rule: Vulnerable Item Grouping by Remediation Task Rules: Remediation Task Rules are used to control the way that certain Vulnerable Items are automatically associated with Remediation Tasks, based on conditions and multiple levels of field value keys. The Remediation Task Rules use CI information from Vulnerable Items, as well as the Assignment group and Assigned to values from configured Vulnerable Item Assignment Rules, to determine the which Team a Remediation Task should be assigned to. Remediation Task Rules leverage attributes on the Vulnerable Item to match with existing open Remediation Task or create new Remediation Tasks when appropriate. These attributes can be fields on the Vulnerable Item, on the Vulnerable Item's CI as well as on the Vulnerable Item's Vulnerability such as: Vulnerability IDConfiguration Item (CI) Operating SystemCI Business CriticalityVulnerability CategoryEtc. Remediation Task Rules Flow: Product doc reference: Remediation Task Rules Sample record of Remediation Task Rule: Remediation Target Rules of Vulnerability Response: Remediation target rules define the expected time frame for remediating vulnerable items (VI), much like SLAs provide a time frame for remediating the vulnerability itself. For example, if an asset contains PCI data (credit card data) then the vulnerability on that item needs to be fixed within 30 days according to PCI DSS. Product doc reference: Remediation Target Rules Sample record of Remediation target rule: Remediation Classification groups and rules: Product doc reference: Vulnerability Classification Rules Sample record of Classification group and rules: Vulnerability Calculators and Risk score Calculation: Vulnerability calculator is a pre-defined formula to calculate a target field when certain criteria are met. Vulnerability calculators are built to prioritize and rate the impact of vulnerable items based on any criteria by using condition filters. Each calculator contains a list of calculator rules, with a condition determining when to apply it. When the calculator is run, the condition for each calculator rule is evaluated in order, and the first matching calculator rule is used. The base system calculator Default Risk Calculator contains the rule Default Risk Rule, a specialized vulnerability calculator rule called a Risk Rule. It calculates Risk Score based on multiple values: Vulnerability severityExploit informationCriticalityExternal exposure of the CI with the vulnerabilityEPSS scores Product doc reference: Vulnerability Response Calculators Sample record of Default Vulnerability calculators and its rules: Sample Default Calculator: Sample Default Risk rule contained in a Vulnerability Calculator: Vulnerability Response remediation task and vulnerable item states: With the Vulnerability Response application, you can use the state model to see the status of a remediation task, at any given time. Knowing how each state relates to and affects each other helps you to determine when and how to remediate your vulnerable items (VIs). Comprehensive VR State flow in Remediation Task (RT): This flow explains how the RT state can be transitioned across its states while remediating the vulnerability and how the RT states can be rolled to previous states based on different scenarios that a Remediation owner encounters, State Transition in RT interpreted in multiple scenarios: 1.Simple state transition in RT: 2.State Transition in RT when Change request is needed to Fix vulnerability: 3.State transition in RT when Exception is Requested and when the request is Approved: 4.State transition in RT when Exception is Requested and when the request is Rejected: Product doc reference: Vulnerability Response State Flow State transition between Detections, Vulnerable Items and Remediation tasks: How Remediation task and Vulnerability Item state affect each other ? State Precedence in order of High to Low is given below, Deferred > Resolved > Awaiting Implementation > Under Investigation > Open For example we have Vulnerable items VIT-X and VIT-Y, belong to a Remediation task RT-ABC, state transition happens as below, >When VIT-X and VIT-Y are not altered individually, they have the same state as RT-ABC > If for example, RT-ABC moves from Open to Awaiting Implementation, VIT-X and VIT-Y that belongs to RT-ABC, moves to "Awaiting Implementation" (State precedence order is considered here) >If RT-ABC moves to "Deferred" state, the VIT-X and VIT-Y in RT-ABC, moves to "Deferred" state >VITs match the same state as of the Remediation task if VITs are not updated individually and with these exceptions, If RT-ABC is closed and its Resolution is set to Cancelled/Fixed with Exception, VIT-X and VIT-Y takes the state of the RT-ABC If VIT-X or VIT-T is Closed/Fixed(updated by Scanner or import), and then if RT-ABC change its state, VIT-X and VIT-Y remains in Closed state. >VIT states modified individually on VIT-X or VIT-Y for example if they are set to Deferred or Closed separately, state of these VITs does not match with the state of the RT-ABC, but there is an exception to it where if VIT-X and VIT-Y are in Closed/Fixed state, the RT-ABC state is set to Closed/Fixed automatically Product doc reference: Remediation tasks and vulnerable item states Exception Management Overview: When we cannot remediate a vulnerability or cannot comply with the published vulnerability management or security standard or guideline, in such scenario, we can request an exception. Exception management entails the requesting, reviewing, approving, or rejecting exceptions to a vulnerable item (VI) or remediation task (RT) that cannot be remediated according to the policy. Life cycle of an exception: Exception Rules Flow: Exception rules for Vulnerability Response enable you to automate the deferral process for vulnerable items (VIs). Request an exception for the vulnerable items (VIs) that can't be remediated or deferred immediately, by identifying the impacted vulnerabilities, configuration items (CIs), or VIs. Exception Management approval Flow: This flow depicts how the Exception is approved at two approval levels and how the VI/VG states are progressed in the process. Sample Record of Exception rule: False Positive Overview: A false positive is a condition wherein the scanner reports that a vulnerability exists in the system, but in reality there is no vulnerability. There can be multiple reasons like incorrect classification, improper logic or algorithm in the scanner. The remediation owner can mark vulnerable items (VIs) or remediation tasks (RTs) as false positives. Exclusion rules of Vulnerability Response: Exclusion rules are essential for filtering detections during the ingestion process in Vulnerability Response. They help manage vulnerabilities effectively by: Excluding low severity vulnerabilities that don't need immediate action.Prioritizing critical VITs for remediation.Reducing processing time by excluding certain detections. Sample Record of Exclusion rule: