What is your Thread Model for Vulnerabilities?

Security teams often compare findings across tools and wonder why the same issue receives different risk ratings. The answer is: different risk models, measure different things and so impose different weightings on factors.

Workflow: Assessing Vulnerability Risk

1. Identify the root cause
   Determine the underlying weakness by reviewing the technical details of the finding, understanding the affected component and version, and using a baseline severity such as the Common Vulnerability Scoring System (CVSS) or a vendor‑provided score.

2. Assess exploitability
   Evaluate whether the vulnerability can realistically be exploited by checking for publicly available exploit code (Proof of Concept), verifying whether it appears in the Known Exploited Vulnerabilities (KEV) catalog, assessing the maturity of available exploits, and determining whether an attacker can reach the vulnerable component.

3. Apply system context
   Consider how the system is deployed by evaluating whether it is internet‑facing or internal, the sensitivity of the data it processes, the type and number of users it serves, and the operational controls in place such as a Web Application Firewall (WAF), Multi‑Factor Authentication (MFA), network segmentation, endpoint detection and response (EDR), or enhanced monitoring.

4. Derive a contextual risk rating
   Combine the likelihood of exploitation with the potential impact on data, operations, and business processes to produce a risk rating that reflects the actual conditions of your environment rather than a generic severity score.

5. Record the reasoning behind the rating
   Document the assumptions, relevant controls, and contextual factors that influenced the rating so that future assessments remain consistent and transparent.

Workflow: Acting on Vulnerabilities

1. Verify the vulnerability
   Confirm that the finding is real, determine whether your specific system and version are affected, and understand the technical root cause of the issue.

2. Check exploitability
   Determine whether the vulnerability can be exploited in practice by reviewing public exploit code (Proof of Concept), checking if it appears in the Known Exploited Vulnerabilities (KEV) catalog, assessing exploit maturity, and verifying whether the vulnerable component is reachable from an attacker’s position.

3. Assess exposure and impact
   Evaluate how the system is deployed: whether it is internet-facing or internal, the sensitivity of the data it processes, the number and type of users it serves, and the operational or business impact if the system is compromised.

4. Apply temporary protections
   Reduce immediate risk by applying short-term controls such as Web Application Firewall (WAF) rules, Multi-Factor Authentication (MFA) enforcement, network segmentation, firewall restrictions, disabling vulnerable features, or increasing logging and monitoring to detect exploitation attempts.

5. Apply permanent remediation
   Eliminate the vulnerability by applying vendor patches, upgrading affected components, replacing vulnerable libraries, or refactoring the relevant code to remove the underlying weakness.

6. Reassess after remediation
   Confirm that the vulnerability is no longer exploitable and verify that the system operates correctly after the fix.

Sensitive Infrastructure: Military‑Grade Risk Thinking

Critical infrastructure (energy, transport, healthcare, finance, government) often adopts military‑inspired frameworks that emphasize resilience, redundancy, and adversarial thinking.

High-level Protection Concepts

Critical infrastructure such as energy, transportation, healthcare, finance, and government systems often adopts military‑inspired security principles because these environments must remain operational even under active attack. The focus is not only on preventing compromise but on ensuring that essential functions continue despite failures, intrusions, or disruptions.

Core Principles

Defense in Depth
Critical systems rely on multiple independent layers of protection across the network, host, application, and identity layers so that a single failure does not expose the entire environment.

Zero Trust
Every request is authenticated, authorized, and logged, and no user or system is implicitly trusted, regardless of network location or previous access.

Least Privilege
Systems and users receive only the minimum access required to perform their tasks, reducing the impact of compromised accounts or misconfigurations.

Segmentation and Isolation
High‑value assets are separated from general networks through strict segmentation and isolation to limit the blast radius of any intrusion.

Mission Assurance
Security decisions prioritize the continuity of essential operations, ensuring that critical services remain functional even when parts of the system are degraded or compromised.

Redundancy and Failover
Key components are duplicated and designed to fail over seamlessly so that the system can continue operating during outages, attacks, or hardware failures.

Adversarial Mindset
Security planning assumes a capable and persistent attacker with time, resources, and intent, and designs controls to withstand targeted and sustained attempts to breach the system.

Established Frameworks

Organizations often reference structured models such as NIST 800‑53 and NIST 800‑82 for industrial control systems, the MITRE ATT&CK framework for adversary behavior analysis, the Department of Defense Cybersecurity Maturity Model Certification (CMMC), and the NIST Cybersecurity Framework for lifecycle‑based security planning.

Additional Design, Plan and Action Principles

KISS (Keep It Simple, Stupid)
Systems should be designed as simply as possible to reduce complexity, lower failure rates, and minimize attack surface.

DRY (Don’t Repeat Yourself)
Avoid duplicated logic and configuration to reduce inconsistencies and prevent security drift across environments.

PoLP (Principle of Least Privilege)
Every user, service, and component receives only the minimum permissions required to operate.

RBAC / ABAC (Role‑Based Access Control / Attribute‑Based Access Control)
Access is granted based on defined roles or attributes, ensuring consistent and auditable authorization.

CIA Triad (Confidentiality, Integrity, Availability)
A foundational security model used in both military and enterprise environments to evaluate the impact of threats.

AAA (Authentication, Authorization, Accounting)
A core operational model for controlling and auditing access to systems and networks.

Fail‑Secure / Fail‑Safe
Systems must fail in a controlled manner: fail‑secure for security‑critical components, fail‑safe for safety‑critical ones.

Chaos Engineering
Intentionally introduce controlled failures to validate resilience and operational readiness under stress.

Immutable Infrastructure
Systems are replaced rather than modified, reducing configuration drift and eliminating unknown states.

Zero Trust Architecture
No implicit trust; every request is verified, regardless of network location or previous authentication.

Red Team / Blue Team / Purple Team
Structured adversarial testing (red), defensive operations (blue), and collaborative improvement (purple).

OODA Loop (Observe, Orient, Decide, Act)
A military decision‑making model used to react quickly and adaptively to evolving threats.

Kill Chain / ATT&CK Mapping
Break down attacker behavior into stages to identify where defenses can disrupt or detect activity.

SPOF Avoidance (Single Point of Failure)
Design systems so that no single component can cause a full outage or compromise.

Defense in Depth
Multiple independent layers of security controls to prevent a single failure from exposing the system.

Separation of Duties
Critical actions require multiple independent roles to reduce insider risk and operational mistakes.

Secure by Default / Secure by Design
Systems start with hardened configurations and require explicit action to reduce security, not the other way around.

References

National Vulnerability Database https://nvd.nist.gov

Vulnerability Calculator https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

MITRE CVE Program
https://cwe.mitre.org

CVSS (FIRST)
https://www.first.org/cvss

OWASP Top 10
https://owasp.org/www-project-top-ten