Risk Scores Are Inputs, Not Decisions

Security teams often use published severity systems to communicate characteristics of vulnerabilities.

One well-known example is CVSS.

A severity score can be useful. It is not your entire risk decision.

Severity describes characteristics under a model

A published score may incorporate concepts such as:

• attack vector;
• complexity;
• required privileges;
• user interaction;
• impacts to confidentiality, integrity, and availability.

Those properties help compare technical severity.

But the score may not know:

• whether your system is exposed;
• whether the vulnerable component is reachable in your architecture;
• whether compensating controls exist;
• whether the asset is critical;
• whether the function is even enabled;
• whether exploitation is observed in your environment;
• whether a fix will break mission-critical function.

So:

TECHNICAL SEVERITY
       +
LOCAL CONTEXT
       +
CONTROL EVIDENCE
       +
MISSION IMPACT
       +
UNCERTAINTY
       ↓
PRIORITY DECISION

High severity can be low local exposure

Fictional example:

component: old training web server
severity: high in published advisory
local state: powered-off disposable VM, isolated, not part of required function

Remediation may still be appropriate before the lab is reused, but it may not outrank an active privileged-access problem on a required system.

Moderate severity can be high local risk

Fictional example:

weakness: incorrect authorization role mapping
technical severity label: moderate in internal rubric
local context: affects required admin function and shared data integrity
active exposure: yes
existing preventive control: missing

This may deserve immediate attention.

Exploit availability is not permission to test

Public proof-of-concept code or reports may affect risk assessment because they can change how plausible exploitation is for a real organization.

That does not authorize students to run exploit code against systems.

In CS1337, use:

• advisory descriptions;
• vendor guidance;
• supplied synthetic evidence;
• safe version/inventory data; and
• isolated teacher-approved demonstrations if explicitly provided.

Risk analysis and offensive execution are different activities.

Remediation also has risk

A patch or configuration change can create:

• compatibility failure;
• downtime;
• data migration problem;
• performance regression;
• new dependency;
• rollback complexity.

That does not mean “do nothing.” It means remediation should be planned and tested.

Activity: severity vs local priority

For each pair, choose which you would address first in the fictional Northstar environment and justify it.

Pair A

Finding 1: high-severity library in an offline archived VM not currently used
Finding 2: ordinary account currently has admin role on active status system

Pair B

Finding 1: certificate on public required status service expires tomorrow
Finding 2: moderate software issue in a non-required internal lab tool

Pair C

Finding 1: backup software outdated but latest restore test succeeded yesterday
Finding 2: current backup job reports success but restore has never been tested

There is room for justified disagreement. The quality of reasoning matters.

Use evidence fields in the risk register

Add:

external severity/source
local exposure evidence
asset criticality
control evidence
remediation deadline/constraint
verification test

Do not hide behind one number.

Patch status needs verification

After remediation, do not close the finding because someone typed “patched.”

Verify:

• intended version/config state;
• required function;
• original exposure/weakness condition;
• monitoring/telemetry; and
• rollback record if something failed.

The risk record should reference evidence.

Exceptions should expire

Sometimes remediation cannot happen immediately.

A defensible exception contains:

• owner;
• reason;
• risk statement;
• compensating control;
• verification of that control;
• expiration/review date; and
• planned remediation.

“Accepted forever because changing it is hard” is not a strong risk decision.

Extend your Risk and Remediation Register

For each finding, add:

external severity if available
why local risk differs or agrees
remediation option
change risk
compensating control if delayed
review/expiration date
verification evidence needed

Lesson 3 turns those rows into a prioritized plan.