Chapter 12: Reporting and Communication

Question 1

Vulnerability Management Reporting

Answer 1

Vulnerability management requires ongoing reporting to responsible parties, like system admins, security staff, and auditors or others who are responsible for ongoing / point-in-time compliance efforts

Reports typically include a number of common elements:
* Vulnerabilities, including information like CVE number, name, description, and information about the vulnerability itself
* A list of affected hosts with IPs and hostname if it was able to be resolved or is available to the scanner
* A risk score that provides a qualitative measure of the severity of the risk in the context of the org and system, device, or service (NOT A CVSS)
* Mitigation options including patches, updates, and workarounds
* Information about recurrence—if the vulnerability has reappeared, this is often a sign that something has gone wrong and needs to be flagged for investigation
* Prioritization information that will help determine what work needs to be done first—often rlies on risk scores, CVSS, and org policies

Reports are often created in an automated fashion since they’re recurring and can reach significant lengths for larger orgs or complex environments

Question 2

Stakeholder Identification and Communication

Answer 2

Vulnerability management reporting requires knowing who the proper stakeholders are for the systems and services covered

Need to ensure that communication provides the appropriate information to each stakeholder in a timely manner as well

Think of stakeholders in a few categories:

Technical Stakeholders
* They need information about vulnerabilities, remediation and mitigation options, and prioritization information to allow them to do the work required in the proper order or importance

Security, Audit, and Compliance Stakeholders
* They need a view of the overall vulnerability stance of the org, as well as information about recurring vulnerabilities and other trends that can point to new or ongoing problems

Security Management and Oversight Systems
* These ingest vulnerability information to provide additional context for security operations, and need security reporting information in standardized forms on an automated basis through APIs or other interfaces

Executive or Leadership Staff
* They provide oversight and are responsible for the org’s overall performance and security, and they need dashboards of ongoing vulnerability remediation practices and efforts

Question 3

Compliance Reports

Answer 3

Vulnerability management systems often have specialized reports designed to provide compliance information aligned to common compliance targets ike the PCI standard

Compliance reporting should be conducted on a regular basis and aligned to reporting requirements outlined in the standard itself

They may need to be provided to a certifying body or simply retained as proof of ongoing compliance with standards

Question 4

Action Plans

Answer 4

While a major part of vulnerability management is simply installing pathces to remediate vulnerabilities, you need to be aware of the following action plans as well:
* Configuration Management
* Patching
* Compensationg Controls
* Awareness, Education, and Training
* Changing Business Requirements

Question 5

Configuration Management

Answer 5

Simply configuring services and apps to not expose potentially vulnerable ports, removing or changing default configurations, and hardening systems and services is an important step in vulnerability management

That means that the following are common parts of vulnerability management action plans:
* Configuration management
* Use of configuration management tools
* Defining baseline configurations

Question 6

Patching

Answer 6

Action plans for patching need to take business processes and requirements into account

Since patching can require service outages in some environments and situations, it needs to be clearly planned and communicated

Patching may also need testing before being done in product environments—they can’t be asumed to be perfect and can cause new issues

Question 7

Compensating Controls

Answer 7

In cases where compensating controls are put in place, it will need to be documented

The configuration and vulnerability management systems in use will need to have notees or flags set to ensure that the vulnerability isn’t reported moving forward (since it now has compensating controls on it)

Many orgs set review periods for compensating controls, like if a patch isn’t available, is flawed, or can’t be installed for business reasons
* Once the need for compensating controls have been addressed, orgs will remove them and move forward

Question 8

Awareness, Education, and Training

Answer 8

Vulnerability management practices require employee awareness to be effective

This requires that training, education, and awareness efforts are ongoing in the org for all relevant staff members

Question 9

Changing Business Requirements

Answer 9

Org requirements and needs will change over time, but vulnerability management may also require an org to modify its practices

Changing business requirements is less frequent, but a crucial part of vulnerability management action plans

Question 10

Vulnerability Management Metrics and KPIs

Answer 10

Trends
* Focus on the number of vulnerabilities, their severity or risk, and the time to remediate
* Issues with recurrence are also frequent targets of reports, although recurrence should be low or zero in most orgs

Top 10 Lists
* Help identify the biggest threats, most common vulnerabilities, and similar items useful for focusing organizational resources
* Don’t just rely on top 10 lists though, because the number is arbitrary and more than 10 critical items can exist

Critical Vulnerabilities
* Vulnerabilities that are likely to result in exploit and that could have significant impact
* If your org relies on the CVSS standard, a 9.0 to 10.0 is a critical vulnerability
* Mesuring the number of critical vulnerabilities in an org and the time for them to be patched can be important to understand how well the most critical vulnerabilities are being handled

Zero-Days
* Measuring zero-day response is challenging since it relies on vendors and others to release patches, or for orgs to identify and implement compensating controls

Service Level Objectives (SLO)
* Specific metrics like time to remediate or patch
* Set by an org, or defined as part of an SLA with a vendor or service
* Measuring whether SLOs have been met and where gaps exist is a common element of SLA management

Question 11

Inhibitors to Remediation

Answer 11

There are a number of reasons that vulnerabilities may not be patched or resolved quickly:

MOU
* May have performance or uptime targets that might not be met if systems or services need to be taken offline for patchine
* May specify a support org or other limitations on who can work with a system or if patches can be installed at all
* Common for embedded and specialized systems that may be sensitive to OS and software changes

SLA
* Can have terms that influence performance targets
* May drive orgs to delay patching to ensure uptime or other metrics are met

Organizational Governance
* Can slow down patching either through business process requirements or because of validation processes

Business Process Interruption
* Many modern systems are designed to allow patching by using load balancing and other techniques, but not all systems or services can be patched without requiring downtimw
* Causes worries about interruption

Degrading Functionality
* A patch might disable a service or modify it, or disable older protocols, which breaks connectivity or integration with other systems and devices

Legacy Systems
* May not have any patches available, so compensating controls could be the only option
* If compensating controls can’t fully remedy the vulneraiblity, you must make risk-driven choices about the vulnerabilities vs the need for the system or service

Proprietary Systems
* Similar to legacy systems, may not have patches available or may have specific requirements placed on them by vendors
* May not be able to uninstall specific patch or update versions and retain vendor support
* Could create conflict between vulnerability management policies and functional or business requirements

Question 12

Stakeholder Identification and Communication

Answer 12

Ensuring that proper parties have the right information at the right times during an incident requires you know who your key stakeholders are—EX:
* Incident responders
* Technical staff (system admins, devs, etc)
* Management
* Legal
* Comms and Marketing
* External stakeholders (customers, service providers, LEO, external legal counsel, government agencies, etc)

Question 13

Incident Declaration and Escalation

Answer 13

When an incident is detected and analysis begins, comms processes also start:
1. IoC that lead the org to investigate the incident need to be communicated to incident responders
2. Incident responders need to make a determination of whether the IoC point to an incident or false positive
3. If incident is declared, then the org’s incident response process and comms plan is activated—this is the incident declaration step and is followed by containment, eradication, and recovery

NOTE: Remember that comms happen at all stages of the process—always be aware of who needs to know what’s happening, what detail they need, and when they need to receive that information

Question 14

Incident Communications

Answer 14

NIST 800-61 contains the requirements and guidelines for external communications and information sharing, including:
* What should be shared
* Who it should be shared with
* When it should be shared
* Over what channels it should be shared

The guide describes a number of external orgs that are commonly involved in incident communications

Question 15

Legal

Answer 15

Legal counesl may be involved in incident communications for a variety of reasons:
* Internal counsel may be asked to consult or be engaged in incident response processes to provide legal advice, particularly if sensitive data, compliance, or HR is involved
* External counsel may be engaged if the org beleives it may face legal action, or for specialized advice related to the incident

NOTE: Involving legal is usually a decision vs an automatic part of incident response—determine when and why counsel would be engaged and establish relationships with counsel prior to needing them

Question 16

PR

Answer 16

There are two topics to know that are central to PR and incident response comms:

Customer Communications
* One of the most important and complex parts of incident response comms
* Notifying customers about data exposures or other issues can be critical to retaining their trust, but it can also have negative impacts on the incident response process
* Difficult to provide useful information during a response process since investigations are ongoing and initial assumptions may prove incorrect
* Determine what your overall practice for customer comms is, who’s responsible, what’s communicated, and when will informaton be made available

Media
* Media comms should align with your org’s existing practices and policies for media interaction and information
* NIST recommends appointing a single point of contact for media + a backup

Additional media recommendations include:
* Establish procedures for briefing the media with a focus on addressing the sensitivity of incident-related information
* Maintain an incident response status document or statement to ensure consistency and timliness of media comms
* Prepare staff for media contact and request for information
* Hold practice sessions for incident responsers as part of IR exercises

Question 17

Regulatory Reporting

Answer 17

Many orgs have regulatory obligations that require comms based on law

EX: Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA)
* Requires that substantial cyber incidents that are likely to result in “demonstrable harm to the national security interests, foreign relations, or economy of the US or to the public confidence, civil liberties, or public health and safety of the people of the US” be reported to the CISA (cybersecurity infrastructure security agency) within 72 hours
* And that ransomware payment be reported no later than 24 hours after the payment is made

Question 18

Law Enforcement

Answer 18

Cybersecurity incidents might be criminal in nature, or they may involve threat actors that are beyond an org’s ability to counter (like nation-state)

When that happens, orgs may want to involve law enforcement, or law enforcement may want to be involved when an incident appears to be criminal in nature

Question 19

RCA

Answer 19

Root Cause Analysis

The incident must be well understood and documented, timelines will need to be built, and other issues and secondary causes need to be documented

The RCA process can be difficult, and there are four steps:
1. Identify the problems and events that occurred as part of the incident, and describe them as well as possible
2. Establish a timeframe of events—this helps determine what happened, and in what order, to help identiy the root cause
3. Differentiate between each of the events and casual factors—in short, determine which casue is a root cause, which are results of the root cause, and which are casual factors or events that contributed to the event but aren’t the root
4. Document the RCA, often with the use of a diagram or chart

Question 20

Incident Response Metrics and KPIs

Answer 20

There are four measures to consider through incident response:

Mean Time to Detect
* How long it took from the initial event that resulted in an incident to when it was detected
* Requires forensic analysis to determine accurately, but can be a meaningful measure for orgs that are seeking to determine if their detection capabilities are suited to the threats they face

Mean Time to Respond
* Measures the time from detection to assessing the event as an incident and activating the process
* Important to differentiate that from mean time to remediate, as remediation can vary based on the size and complexity of the incident

Mean Time to Remediate
* Requires more nuanced communciation and explanation than a simple number on a report
* May benefit from granular reporting that describes the types of incidents as well as their impact and scope
* Complex to provide a concrete measure because each incident’s size, scope, and complexity will all influence the mean time to remediate

Alert Volume
* Less frequently used because it’s difficult to ascribe meaning to a given volume
* It might mean orgs haven’t properly tuned their alerts, the org has a few effective alerts, or orgs have an effective detection system with tuned alerts that return only critical results
* Seen as a flawed KPI because of this
* More useful metric is whether alerts occured for incidents and resulted in the IR process activating, or if incidents were discovered in other ways (meaning alerts aren’t properly configured to detect incidents)

Question 21

Incident Response Reporting

Answer 21

IR reports help orgs communicate about incidents and also serve as a means of ensuring consistency in response, analysis, and tracking over time

Depending on the complexity of the incident and organizational need, reports may be relatively shorts summaries, or they may have in-depth detail

You need to konw the following IR report components for the exam:

Executive Summary
* Most reports start with this, and it provides a short, clearly written explanantion of the incident, its impact, and its current state or resolution

Narrative
* The narrative provided must describe who, what, when, where, and why

Recommendations
* Often based on lessons learned, including documenting what went well, what could be improved, and what corrective actions are needed to be taken

Timeline
* Included to outline what happened and when
* Timelines help establish areas for improvement by pointing out when actions weren’t accomplished in a timely manner or where there was a lag in response
* They can also point out attacker methodologies and other useful information about the processes and techniques used during the incident by both attackers and defenders

Impact Assessment
* Helps orgs understand what the outcome of an incident was and what issues may need to be resolved
* May include financial, reputational, or other damages

Scope
* Describes what systems, services, and other elements of the org were impacted by the incident

Evidence
* Often attached as an appendix
* May also be summarized as part of the report, where it provides helpful contextual information about the incident