CompTIA CySA+ CS0-004 — Reporting & Communication

• False Positive Rate: Percentage of alerts that are not real incidents. High false positive rate degrades analyst effectiveness through alert fatigue. Reduced by tuning detection rules, using contextual enrichment, building allowlists.
• False Negative Rate: Percentage of real incidents that generated no alert. More dangerous than false positives — means actual attacks are being missed. Reduced by improving detection coverage and rules.
• SLA compliance rate: Percentage of vulnerabilities remediated within the organization's defined SLA windows (e.g., critical vulnerabilities patched within 30 days). Key metric for vulnerability management program effectiveness.
• Mean Time to Patch (MTTP): Average time from patch release to deployment across the environment. A long MTTP increases the organization's exposure window after a CVE is published.
• Vulnerability recurrence rate: How often the same vulnerability reappears after remediation. High recurrence indicates broken remediation processes (patching not propagating to all instances, root cause not addressed).

Inhibitors are factors that prevent or delay patching/remediating a known vulnerability. When a vulnerability cannot be remediated, a compensating control should be applied.

• Memorandum of Understanding (MOU) / Service Level Agreement (SLA): Contractual agreements with vendors or shared service providers may restrict unauthorized changes to shared systems. The organization cannot patch the system without vendor approval or coordinated maintenance windows.
• Organizational governance / Change Management: The change advisory board (CAB) process requires formal approval before changes to production systems. Emergency patches may require expedited change requests. Governance is a legitimate inhibitor, not a failure — it prevents unauthorized changes.
• Business process interruption: The system cannot be taken offline to patch because it supports a critical business process (manufacturing, hospital patient monitoring, financial trading). Patching must be scheduled during planned maintenance windows.
• Degrading functionality: The available patch may break dependent applications, APIs, or hardware drivers. Testing in a staging environment before production deployment is required, which takes time.
• Legacy / end-of-life systems: Vendor no longer provides patches (e.g., Windows Server 2008, unsupported embedded OS). Options: network isolation, additional monitoring, virtual patching via WAF/IPS, migration planning.
• Third-party dependence: The organization depends on a vendor to provide an updated version before the vulnerability can be addressed. The vendor's timeline is outside the organization's control.
• Compensating controls when patching is not possible: Network segmentation/isolation, virtual patching (WAF/IPS rules), enhanced monitoring, additional access controls, disabling unnecessary features.

Vulnerability Report components:

• Executive summary — business risk framing, no CVSS scores in executive section, financial/operational impact language
• Scope and methodology — what was scanned, what type of scan (credentialed/external), scanning tool used
• Findings — per-vulnerability: name, CVE, CVSS base score, affected assets, risk context (is it internet-facing? exploitable?), recommended remediation
• Prioritized remediation plan — organized by risk (not just CVSS), with SLA deadlines by severity tier
• Trend data — how does this compare to prior scans? Are vulnerability counts improving?

IR Report components:

• Incident summary — what happened, when detected, when contained, systems affected, data involved
• Timeline — chronological sequence of events from initial compromise to full recovery
• Technical findings — IOCs, TTPs observed, attacker methodology
• Containment/eradication actions — what was done and when
• Root cause — confirmed underlying cause
• Impact assessment — business impact, data affected, regulatory obligations triggered
• Lessons learned and recommendations — process/control improvements

• Translate technical findings to business risk: Executives care about financial impact, legal liability, regulatory consequences, operational disruption, and reputational damage — not CVSS scores. "CVSS 9.8 critical RCE in the ERP system" becomes "An attacker could gain full control of our order management system, potentially causing revenue loss, regulatory fines, and customer data exposure."
• Risk language: Frame findings as risk to business objectives. Use risk quantification where possible (expected loss, probability × impact). Support resource requests (headcount, budget, tools) with specific risk reduction justification.
• Executive dashboards: High-level metrics over time — vulnerability count trends, SLA compliance rate, MTTD/MTTR trends, open critical vulnerabilities, incidents by severity. Visual (charts/graphs), not tables of CVEs.
• Escalation paths: Know when to escalate: confirmed ransomware → immediate CISO notification. Data breach → legal, compliance, and C-suite. Nation-state indicators → executive leadership and potentially law enforcement. Establish escalation criteria in the IRP before incidents occur.
• Inhibitors communication: When reporting a vulnerability that cannot currently be remediated, document: the vulnerability, the inhibitor (why it can't be patched), the compensating controls applied, the residual risk level, and management's risk acceptance decision with signature.

• GDPR (General Data Protection Regulation) — EU:
  • 72-hour notification rule: Organizations must notify the supervisory authority (e.g., ICO in the UK, CNIL in France) within 72 hours of becoming aware of a personal data breach — or explain why notification is delayed.
  • Notification to affected individuals: required "without undue delay" if the breach is likely to result in high risk to their rights and freedoms (e.g., financial harm, discrimination, identity theft).
  • Applies to: any organization processing EU residents' personal data, regardless of where the organization is based.
• HIPAA (Health Insurance Portability and Accountability Act) — US:
  • 60-day notification rule: Covered entities must notify affected individuals within 60 days of discovering a breach of unsecured Protected Health Information (PHI).
  • HHS notification (500+ affected in same state): Notify HHS immediately (within 60 days); HHS posts these on the public "Breach Portal" (commonly called the "Wall of Shame").
  • HHS notification (fewer than 500): Submit to HHS annually, within 60 days after the calendar year ends.
  • Business Associates must notify the covered entity "without unreasonable delay" and within 60 days.
  • Media notification: if 500+ individuals in a state or jurisdiction are affected, also notify prominent media outlets.
• PCI DSS (Payment Card Industry Data Security Standard):
  • Breaches involving cardholder data must be reported to the card brands (Visa, Mastercard) and the acquiring bank immediately.
  • Annual compliance attestation via SAQ (Self-Assessment Questionnaire) for smaller merchants or QSA (Qualified Security Assessor) Report on Compliance (ROC) for larger merchants.
• Law enforcement referral: Organizations may (and sometimes must) notify law enforcement (FBI, CISA) for nation-state attacks, ransomware (FBI recommends reporting), or financial crimes (Secret Service). Legal counsel should advise on when notification is obligatory vs. optional.

• 5 Whys: Iterative technique — ask "why" five times to drill through symptoms to the root cause. Example: Why did the breach occur? → Unpatched vulnerability exploited. Why was it unpatched? → It was missed in last scan. Why was it missed? → Scanner had incomplete credentials for that segment. Why did credentials fail? → Account password changed by IT but not updated in the scanner. Why wasn't the update tracked? → No documented process for scanner credential management. Root cause: process gap in scanner maintenance. Solution: document and assign scanner credential ownership.
• Fishbone / Ishikawa Diagram: Visual tool that maps contributing causes into categories radiating from the "head" (the problem). Common categories for security incidents: People (lack of training, insufficient staffing), Process (missing procedures, inadequate review), Technology (legacy system, misconfiguration), Environment (third-party, supply chain). Used when multiple contributing factors need to be organized and communicated visually.
• RCA report output: Statement of the incident → confirmed root cause → contributing factors → corrective actions (owner, due date, verification method) → process improvements to prevent recurrence.
• Goal of RCA: Prevent recurrence by fixing the underlying cause, not just the symptom. RCA is blameless — it focuses on process and system failures, not on individuals. "The vulnerability scanner lacked proper credential management" not "the analyst failed to update the password."