7.2 Risk Visibility, Reporting, and Threat Intelligence

Visibility is how residual risk stays honest

Knowledge area 3.1 does not end when someone picks mitigate. The outline's visibility and reporting examples — risk register, sharing threat intelligence, indicators of Compromise (IOC), Common Vulnerability Scoring System (CVSS), socialization, and the MITRE ATT&CK model — are how operations keep residual risk visible after the meeting. An SSCP who can quote the four treatments but never updates the register from SIEM and tickets is flying without instruments.

Domain 3 is still 15% of the SSCP exam. Later knowledge areas cover assessments, platform monitoring, and analysis. This section is the glue: findings and intel become named risks that owners can treat.

The risk register

A risk register is the living inventory of identified risks. It is not a scan export and not a slide that is retyped once a year. Each row is a risk statement you could defend to an auditor or a clinical director.

Do not put every CVSS Medium from a weekly scan on the executive register. Aggregate: "unpatched clinical imaging fleet, 14 hosts, vendor-constrained, residual Medium after isolation, owner: imaging informatics, review in 30 days." Put the CVE list in the vulnerability-management queue (knowledge area 3.3). The register holds the business risk those CVEs create.

A register that only IT security can see is a private diary. A register that lists 2,000 unowned Highs is noise. Both fail visibility.

Socialization

Socialization is the work of making residual risk understood by the people who must treat it — asset owners, clinical engineering, legal, the CISO, sometimes the board. It is not dumping a comma-separated CVSS file into a shared drive.

Operational socialization:

• Translate. "CVSS 9.8, attack vector network" becomes "an internet-facing login could be taken over without a password if we do not patch this week."
• Use the owner's units: missed MRI slots, warehouse hours, card-brand contract risk.
• Time-box the decision. Tolerance might say a clinical residual above Medium escalates within five days.
• Record who heard it. A hallway chat is not evidence that the owner accepted residual risk.
• Repeat after treatment. Isolation of the MRI is not done until the owner sees the new residual and the monitoring that will detect a reconnect.

Exam trap: the analyst who "reported" a finding in a ticket that the asset owner never saw. Reporting without socialization is incomplete visibility.

Sharing threat intelligence

Threat intelligence is evidence-based knowledge about existing or emerging threats that can inform decisions. For SSCP operators it arrives as sector bulletins, vendor advisories, government alerts, and peer sharing — not as a movie-plot briefing.

Sharing has rules:

• Information Sharing and Analysis Centers (ISACs) and similar communities (health, financial, multi-state) are the usual sector channels. You consume and, when policy allows, contribute.
• Traffic Light Protocol (TLP) marks how far a report may travel. TLP:RED stays with the named recipients. TLP:AMBER stays inside the organization on a need-to-know basis (TLP 2.0 also defines AMBER+STRICT). TLP:GREEN can go to the community. TLP:CLEAR (formerly WHITE) is shareable publicly. Breaking TLP can burn a source and violate contracts.
• Structured sharing often uses STIX content over TAXII transports. You do not need to parse the XML on the exam; you need to know intel can be machine-ingested into a SIEM or threat platform.
• Strip victim identifiers and patient or customer personal data before you share. Intel sharing is not a breach dump.

Intel that never leaves the threat-intel mailbox is not visibility. Intel that is pasted into Slack with no TLP is not professionalism.

Indicators of Compromise

An indicator of Compromise (IOC) is an artifact that suggests a system has been breached or is under attack: file hashes, IP addresses, domains, URLs, mutex names, certificate serials, sometimes mailbox rules. IOCs are tactical and perishable. Attackers rotate infrastructure. Yesterday's command-and-control address is today's false positive.

What SSCPs do with IOCs:

• Hunt and block: SIEM lookups, firewall and DNS denials, endpoint detection queries.
• Ticket what matches, with context — a hash on a jump host is not the same as the same hash on a sandbox.
• Expire them. An IOC watchlist with no review date becomes noise.
• Do not confuse an IOC match with a closed risk. Blocking one IP does not treat the unpatched MRI that invited the operator in.

For AI-enabled systems, visibility can include suspicious query patterns, unexplained model drift, or inference endpoints talking to new destinations. Those are still indicators feeding the same register, not a separate magic category. ISC2 does not publish a unique SSCP scoring table for model drift; treat it as "something that should be visible if you operate machine-learning endpoints."

CVSS is severity, not risk

The Common Vulnerability Scoring System (CVSS) is a vendor-neutral way to express the technical severity of a vulnerability, typically as a base score from 0.0 to 10.0 with qualitative labels (for example, Low, Medium, High, Critical). Base metrics describe how the flaw is exploited and how it affects confidentiality, integrity, and availability. Temporal and environmental metrics exist to adjust for exploit maturity and your deployment; many scanners still lead with the base score.

CVSS versions (v3.1 is still widely printed on scanner output; v4.0 is the current specification from FIRST) can differ in labels and metrics. SSCP does not publish that you must compute a vector string by hand. Remember the operational rule: CVSS is not organizational risk.

Scenario: CVSS 9.8 versus a business-critical isolated asset

A weekly scan reports:

• CVSS 9.8 on a lab printer that is air-gapped except for a physically controlled USB workflow.
• CVSS 6.5 (Medium) on the internet-facing EHR patient portal, where exploit code is circulating in your H-ISAC feed.

A junior analyst wants the printer in this week's executive register because "9.8 is Critical" and wants to defer the EHR finding because "6.5 is only Medium." That ranking is backwards for business risk.

Score risk with asset criticality, exposure (internet versus air-gap), existing controls, threat intelligence (active exploitation in your sector), and safety or privacy impact. The EHR Medium may be High residual and due this week. The printer 9.8 may be Low residual and belong in the lab's patch queue, not the board pack. You can still record the 9.8 so it is not forgotten if someone bridges the printer "just for a firmware update."

Environmental scoring, if you use it, is how CVSS can reflect isolation. Until you apply it, never sort the hospital by base score and call that a risk assessment.

MITRE ATT&CK

MITRE ATT&CK is a knowledge base of adversary tactics (the adversary's technical goals, such as credential access or lateral movement) and techniques (how those goals are achieved). It is a common language for intel reports, detection engineering, and purple-team coverage. It is not a CVSS competitor and not a risk score.

SSCP uses:

• Map a bulletin ("this ransomware uses stolen VPN accounts, then dumps LSASS") to techniques you can actually detect or prevent.
• Ask coverage questions: do we log those events? Is there a SIEM use case? Would the MRI VLAN even produce this telemetry?
• Feed gaps to the register: "no detection for valid-accounts on clinical VPN" is a risk scenario, not an ATT&CK trivia card.

You do not need to memorize every technique ID for the exam. You do need to reject options that treat ATT&CK as a patch priority or as a replacement for impact assessment.

How SSCPs feed SIEM and tickets into the register

This is the operational loop the outline is pointing at when it lists register, intel, IOCs, CVSS, socialization, and ATT&CK together.

1. Collect. Scans, SIEM use cases, incident tickets, vendor intel, ISAC IOCs, ATT&CK-mapped hunts.
2. Cluster. Recurring events on the same asset class are one risk, not 90 tickets. Three months of "vendor constraint" closures on the MRI subnet is a single residual-risk story.
3. Enrich. Add CVSS and CVE for the technical record, ATT&CK for behavior, intel for likelihood ("this sector is being hit now"), and business impact for the owner.
4. Write or update a register row. Owner, inherent, residual, treatment, review date. Link the tickets; do not replace the register with the ticket system.
5. Socialize. The imaging director and CISO see residual in clinical language before the next patch window.
6. Monitor the treatment. If isolation is the control, alert when the MRI MAC address appears on a general VLAN. That alert is evidence, not a new surprise.

Scenario: tickets that never become a risk

A SIEM use case fires weekly on the unpatched MRI subnet. Operations closes each ticket as "vendor constraint." After twelve closures, an auditor asks where residual risk is accepted. If the register has no row, nobody accepted anything. Closing a ticket is not risk acceptance. The SSCP rolls the pattern into a named entry, keeps the compensating controls on a review clock, and stops pretending the queue is a treatment.

Do not invert the loop either: one noisy signature is not forty board-level risks. Visibility fails from both hiding and flooding.

How to attack a CAT item on visibility and intel

1. Ask whether the stem needs a register update, a detection, a share, or a ranking.
2. Treat CVSS as severity; rank with exposure and criticality.
3. Treat IOCs as short-lived hunt/block data; treat ATT&CK as behavior coverage.
4. Honor TLP when sharing.
5. Promote recurring SIEM or ticket patterns into owned residual risk, not into deleted rules or silent ticket closures.