generated from coulomb/repo-seed
2235 lines
48 KiB
Markdown
2235 lines
48 KiB
Markdown
# InfoTechCanon Security Model
|
|
|
|
**Short Name:** `ITC-SEC`
|
|
**Document Status:** Seed Standard Release Candidate 1
|
|
**Version:** RC1-seed
|
|
**Date:** 2026-05-22
|
|
**Repository Context:** `info-tech-canon`
|
|
**Document Type:** InfoTechCanon Domain Standard
|
|
**Intended Audience:** Security architects, platform engineers, DevSecOps teams, service owners, risk managers, governance designers, incident responders, vulnerability managers, detection engineers, software assurance teams, access-control designers, knowledge-system builders, and agentic tooling.
|
|
|
|
---
|
|
|
|
# 1. Purpose
|
|
|
|
The **InfoTechCanon Security Model** defines a canonical seed model for representing cybersecurity posture, threats, weaknesses, vulnerabilities, exposures, findings, attack paths, mitigations, detections, incidents, response, recovery, and security assurance across information-processing systems.
|
|
|
|
It exists to connect security knowledge to the rest of InfoTechCanon without duplicating governance, access control, landscape, organization, task, or tagging semantics.
|
|
|
|
This standard provides:
|
|
|
|
- a canonical vocabulary for security entities,
|
|
- a distinction between threat, weakness, vulnerability, exposure, finding, risk, incident, and control,
|
|
- security-specific mappings to external frameworks and taxonomies,
|
|
- support for vulnerability management and threat-informed defense,
|
|
- support for detection, response, and recovery,
|
|
- support for software and platform security posture,
|
|
- support for security findings and remediation tasks,
|
|
- support for attack-path and exposure modeling,
|
|
- support for security evidence and assurance,
|
|
- profile hooks for concrete implementation contexts,
|
|
- and retrieval-friendly structure for humans, agents, and markdown-based infospaces.
|
|
|
|
---
|
|
|
|
# 2. Position in InfoTechCanon
|
|
|
|
The Security Model is a **domain standard** within InfoTechCanon.
|
|
|
|
It depends on the existing seed standards as follows:
|
|
|
|
```text
|
|
Landscape = systems, services, resources, data, endpoints, runtime, networks.
|
|
Organization = actors, owners, responders, teams, responsibilities.
|
|
Governance = policies, controls, control objectives, risk, exception, evidence.
|
|
Task = remediation, investigation, response, review, and hardening work.
|
|
Tagging = classification of findings, assets, vulnerabilities, and evidence.
|
|
Access Control = authorization, permissions, privileges, grants, decisions, and sessions.
|
|
Security = threats, weaknesses, vulnerabilities, exposure, attack paths,
|
|
incidents, detection, response, recovery, and posture.
|
|
```
|
|
|
|
```text
|
|
InfoTechCanon
|
|
├── InfoTechCanonCore
|
|
├── InfoTechCanonLandscapeModel
|
|
├── InfoTechCanonOrganizationModel
|
|
├── InfoTechCanonGovernanceModel
|
|
├── InfoTechCanonTaskModel
|
|
├── InfoTechCanonTaggingStandard
|
|
├── InfoTechCanonAccessControlModel
|
|
├── InfoTechCanonSecurityModel <-- this standard
|
|
├── InfoTechCanonDataModel
|
|
├── InfoTechCanonDevSecOpsModel
|
|
├── InfoTechCanonNetworkModel
|
|
├── InfoTechCanonObservabilityModel
|
|
├── InfoTechCanonPatternLanguage
|
|
└── Application Profiles
|
|
```
|
|
|
|
---
|
|
|
|
# 3. Boundary with Adjacent Standards
|
|
|
|
## 3.1 Boundary with Governance
|
|
|
|
The Governance Model owns:
|
|
|
|
```text
|
|
Policy
|
|
Rule
|
|
ControlObjective
|
|
Control
|
|
Risk
|
|
Exception
|
|
Evidence
|
|
Audit
|
|
Assurance
|
|
ComplianceRequirement
|
|
Decision
|
|
Approval
|
|
Review
|
|
```
|
|
|
|
The Security Model owns:
|
|
|
|
```text
|
|
Threat
|
|
ThreatActor
|
|
AttackTechnique
|
|
Weakness
|
|
Vulnerability
|
|
Exposure
|
|
SecurityFinding
|
|
SecurityIncident
|
|
AttackPath
|
|
Mitigation
|
|
Detection
|
|
SecuritySignal
|
|
SecurityPosture
|
|
SecurityAssuranceSignal
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Governance defines the rule, control, risk, exception, evidence, and assurance structure.
|
|
Security defines the adversarial, defensive, vulnerability, incident, detection, and posture semantics.
|
|
```
|
|
|
|
## 3.2 Boundary with Access Control
|
|
|
|
The Access Control Model owns:
|
|
|
|
```text
|
|
Subject
|
|
Principal
|
|
Permission
|
|
Privilege
|
|
Entitlement
|
|
Grant
|
|
AuthorizationDecision
|
|
AccessSession
|
|
AccessReview
|
|
BreakGlassAccess
|
|
AgentAccess
|
|
```
|
|
|
|
The Security Model may analyze these as security-relevant.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
ExcessAccess is an AccessFinding and may also be a SecurityFinding.
|
|
PrivilegeEscalationPath is a Security AttackPath involving AccessControl entities.
|
|
CredentialMisuse is a SecurityIncident involving AccessSession and CredentialReference.
|
|
```
|
|
|
|
## 3.3 Boundary with Landscape
|
|
|
|
The Landscape Model owns:
|
|
|
|
```text
|
|
Service
|
|
ApplicationService
|
|
SoftwareComponent
|
|
Repository
|
|
Artifact
|
|
RuntimeResource
|
|
NetworkEndpoint
|
|
Dataset
|
|
Environment
|
|
NetworkPath
|
|
ObservabilitySignal
|
|
```
|
|
|
|
Security applies to those entities.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Vulnerability affects Artifact
|
|
Exposure affects Endpoint
|
|
AttackPath traverses NetworkPath
|
|
SecurityIncident affects Service
|
|
Mitigation applies_to RuntimeResource
|
|
```
|
|
|
|
## 3.4 Boundary with Task
|
|
|
|
The Task Model owns work semantics.
|
|
|
|
Security creates or references tasks such as:
|
|
|
|
```text
|
|
RemediationTask
|
|
IncidentTask
|
|
InvestigationTask
|
|
HardeningTask
|
|
ReviewTask
|
|
ApprovalTask
|
|
SecurityExceptionTask
|
|
```
|
|
|
|
## 3.5 Boundary with DevSecOps
|
|
|
|
The DevSecOps Model should own delivery pipeline, build, release, artifact, SBOM, attestation, and deployment semantics.
|
|
|
|
The Security Model owns security interpretation of those entities.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
SCAFinding affects Artifact
|
|
SBOMEvidence supports VulnerabilityAssessment
|
|
PolicyGate enforces SecurityControlImplementation
|
|
UnsignedArtifact is SecurityFinding
|
|
```
|
|
|
|
---
|
|
|
|
# 4. Research Basis and External Alignment
|
|
|
|
This seed standard draws on multiple security knowledge bodies.
|
|
|
|
## 4.1 NIST Cybersecurity Framework 2.0
|
|
|
|
NIST CSF 2.0 organizes cybersecurity outcomes into six high-level functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Security Model uses these as a useful security lifecycle mapping target while leaving general governance semantics to the Governance Model.
|
|
|
|
## 4.2 MITRE ATT&CK
|
|
|
|
MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations. It is a strong mapping target for threat-informed defense, detection coverage, adversary behavior, attack techniques, and mitigations.
|
|
|
|
## 4.3 CVE, CWE, CVSS, and EPSS
|
|
|
|
CVE provides common identifiers for publicly known information-security vulnerabilities. CWE provides common software and hardware weakness types. CVSS communicates vulnerability characteristics and severity, while EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days.
|
|
|
|
The Security Model must distinguish:
|
|
|
|
```text
|
|
Weakness -> class of flaw or error pattern.
|
|
Vulnerability -> specific exploitable flaw or exposure.
|
|
Severity -> technical impact characteristics.
|
|
Exploit likelihood -> probability or evidence of exploitation.
|
|
Risk -> context-specific uncertainty or exposure relative to objectives.
|
|
```
|
|
|
|
## 4.4 OWASP ASVS and SAMM
|
|
|
|
OWASP ASVS provides a basis for testing web application technical security controls and secure development requirements. OWASP SAMM provides an open framework for formulating and improving a software security strategy. These are important mapping and assimilation targets for application security and software assurance.
|
|
|
|
## 4.5 Security Operations and Incident Response
|
|
|
|
Security operations practice distinguishes signals, detections, alerts, incidents, investigations, containment, eradication, recovery, lessons learned, and evidence.
|
|
|
|
## 4.6 Attack Graphs and Exposure Management
|
|
|
|
Modern exposure management and attack-path analysis combine vulnerabilities, misconfigurations, identity permissions, network reachability, data sensitivity, and runtime context to prioritize security work.
|
|
|
|
---
|
|
|
|
# 5. Seed Standard Design Stance
|
|
|
|
This standard is a **seed standard**, not a full security program manual.
|
|
|
|
It shall:
|
|
|
|
1. define canonical security semantics,
|
|
2. distinguish security from governance and access control,
|
|
3. support vulnerability, weakness, exposure, finding, and risk separation,
|
|
4. support threat-informed defense and attack-path modeling,
|
|
5. support detection, incident, response, and recovery concepts,
|
|
6. support software, platform, cloud, network, identity, data, and operational security,
|
|
7. support human and agentic security contexts,
|
|
8. map to external taxonomies without becoming subordinate to them,
|
|
9. remain markdown-first and agent-retrievable,
|
|
10. and support future assimilation of security standards, frameworks, products, and research.
|
|
|
|
---
|
|
|
|
# 6. Scope
|
|
|
|
## 6.1 In Scope
|
|
|
|
This standard covers canonical representation of:
|
|
|
|
- security posture,
|
|
- security domains,
|
|
- assets as security-relevant landscape references,
|
|
- threat actors,
|
|
- threat events,
|
|
- attack techniques,
|
|
- attack patterns,
|
|
- attack paths,
|
|
- weaknesses,
|
|
- vulnerabilities,
|
|
- exposures,
|
|
- misconfigurations,
|
|
- security findings,
|
|
- security signals,
|
|
- detections,
|
|
- alerts,
|
|
- incidents,
|
|
- investigations,
|
|
- containment,
|
|
- eradication,
|
|
- recovery,
|
|
- mitigations,
|
|
- compensating security measures,
|
|
- exploitability,
|
|
- severity,
|
|
- exploit likelihood,
|
|
- asset criticality reference,
|
|
- security impact,
|
|
- blast radius,
|
|
- security evidence,
|
|
- security assurance signals,
|
|
- security exceptions as governance references,
|
|
- remediation references,
|
|
- and security mappings.
|
|
|
|
## 6.2 Out of Scope
|
|
|
|
This standard does not fully define:
|
|
|
|
- general governance policy and control theory,
|
|
- full legal and regulatory compliance,
|
|
- complete access-control implementation,
|
|
- complete incident-response playbooks,
|
|
- complete malware analysis,
|
|
- full cryptographic protocol design,
|
|
- detailed secure coding standards,
|
|
- complete cloud provider security models,
|
|
- complete SIEM query languages,
|
|
- or all security product schemas.
|
|
|
|
Those may be mapped, assimilated, profiled, or handled by adjacent standards.
|
|
|
|
---
|
|
|
|
# 7. Normative Language
|
|
|
|
The following terms are used normatively:
|
|
|
|
- **SHALL** indicates a mandatory rule for conformance.
|
|
- **SHOULD** indicates a recommended practice.
|
|
- **MAY** indicates an optional capability.
|
|
- **MUST NOT** indicates a prohibited practice.
|
|
- **SEED** marks a concept defined provisionally here but open to later refinement.
|
|
- **EXTRACT** marks a concept that may later move to a more specialized standard.
|
|
|
|
---
|
|
|
|
# 8. Core Principles
|
|
|
|
## 8.1 Security Is Contextual
|
|
|
|
A vulnerability, exposure, or finding becomes important through context:
|
|
|
|
```text
|
|
affected asset
|
|
reachable path
|
|
exploitability
|
|
data sensitivity
|
|
privilege
|
|
business criticality
|
|
active exploitation
|
|
compensating controls
|
|
```
|
|
|
|
## 8.2 Vulnerability Is Not Risk
|
|
|
|
A vulnerability is a flaw or exposure that may be exploitable.
|
|
|
|
Risk is uncertainty or exposure relative to objectives and context.
|
|
|
|
## 8.3 Weakness Is Not Vulnerability
|
|
|
|
A weakness is a class of design, implementation, configuration, or hardware flaw.
|
|
|
|
A vulnerability is a specific instance that may be exploited.
|
|
|
|
## 8.4 Finding Is Not Always Vulnerability
|
|
|
|
A finding may indicate:
|
|
|
|
```text
|
|
vulnerability
|
|
misconfiguration
|
|
policy violation
|
|
weak control
|
|
suspicious activity
|
|
excess access
|
|
exposed service
|
|
missing evidence
|
|
```
|
|
|
|
## 8.5 Exposure Is First-Class
|
|
|
|
A system may be at risk not only because it has a CVE, but because an asset is reachable, discoverable, misconfigured, overprivileged, or connected to sensitive data.
|
|
|
|
## 8.6 Detection and Response Are Part of Posture
|
|
|
|
Security posture includes not only prevention, but also detection, response, recovery, and assurance.
|
|
|
|
## 8.7 Security Claims Need Evidence
|
|
|
|
Important security claims SHOULD reference evidence, source, timestamp, confidence, and scope.
|
|
|
|
## 8.8 External Taxonomies Are Mapped, Not Obeyed
|
|
|
|
The Security Model MAY map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, ISO 27001, CIS, cloud provider controls, and product schemas.
|
|
|
|
It MUST NOT subordinate its internal semantics to any single external framework.
|
|
|
|
---
|
|
|
|
# 9. Canonical Seed Metadata
|
|
|
|
Every security artifact SHOULD support structured metadata.
|
|
|
|
Recommended front matter:
|
|
|
|
```yaml
|
|
---
|
|
id: itc-sec:Vulnerability
|
|
type: concept
|
|
standard: InfoTechCanonSecurityModel
|
|
standard_version: RC1-seed
|
|
status: candidate
|
|
canonical_owner: InfoTechCanonSecurityModel
|
|
preferred_label: Vulnerability
|
|
related:
|
|
- itc-sec:Weakness
|
|
- itc-sec:Exposure
|
|
- itc-sec:SecurityFinding
|
|
- itc-gov:Risk
|
|
mappings:
|
|
- itc-map:vulnerability-to-cve
|
|
---
|
|
```
|
|
|
|
Recommended artifact statuses:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 10. Root Security Taxonomy
|
|
|
|
```text
|
|
SecurityEntity
|
|
├── SecurityScopeEntity
|
|
│ ├── SecurityDomain
|
|
│ ├── SecurityBoundary
|
|
│ ├── SecurityZoneReference
|
|
│ ├── ProtectedAssetReference
|
|
│ └── SecurityPosture
|
|
├── ThreatEntity
|
|
│ ├── Threat
|
|
│ ├── ThreatActor
|
|
│ ├── ThreatEvent
|
|
│ ├── AttackTechnique
|
|
│ ├── AttackPattern
|
|
│ ├── Tactic
|
|
│ ├── CampaignReference
|
|
│ └── AdversaryCapability
|
|
├── WeaknessVulnerabilityEntity
|
|
│ ├── Weakness
|
|
│ ├── Vulnerability
|
|
│ ├── Exposure
|
|
│ ├── Misconfiguration
|
|
│ ├── Exploit
|
|
│ ├── Exploitability
|
|
│ ├── Severity
|
|
│ └── ExploitLikelihood
|
|
├── FindingEntity
|
|
│ ├── SecurityFinding
|
|
│ ├── VulnerabilityFinding
|
|
│ ├── MisconfigurationFinding
|
|
│ ├── ExposureFinding
|
|
│ ├── IdentityFinding
|
|
│ ├── DataSecurityFinding
|
|
│ ├── SupplyChainFinding
|
|
│ └── ControlWeaknessFinding
|
|
├── AttackPathEntity
|
|
│ ├── AttackPath
|
|
│ ├── AttackStep
|
|
│ ├── AttackPrecondition
|
|
│ ├── AttackImpact
|
|
│ ├── BlastRadius
|
|
│ └── ChokePoint
|
|
├── DefenseEntity
|
|
│ ├── Mitigation
|
|
│ ├── SecurityMeasure
|
|
│ ├── HardeningMeasure
|
|
│ ├── CompensatingMeasure
|
|
│ ├── DetectionRule
|
|
│ ├── DetectionCoverage
|
|
│ └── SecurityControlImplementationReference
|
|
├── DetectionResponseEntity
|
|
│ ├── SecuritySignal
|
|
│ ├── Detection
|
|
│ ├── Alert
|
|
│ ├── SecurityIncident
|
|
│ ├── Investigation
|
|
│ ├── Containment
|
|
│ ├── Eradication
|
|
│ ├── Recovery
|
|
│ └── LessonLearned
|
|
└── AssuranceEntity
|
|
├── SecurityEvidence
|
|
├── SecurityAssessment
|
|
├── PenTestFinding
|
|
├── SecurityReview
|
|
├── SecurityExceptionReference
|
|
├── SecurityAttestation
|
|
└── SecurityPostureScore
|
|
```
|
|
|
|
---
|
|
|
|
# 11. Core Concepts
|
|
|
|
## 11.1 SecurityEntity
|
|
|
|
A **SecurityEntity** is any identifiable concept used to represent security posture, adversarial behavior, defensive measures, vulnerabilities, incidents, findings, exposure, detection, response, or assurance.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Optional attributes:
|
|
|
|
```yaml
|
|
owner:
|
|
steward:
|
|
security_domain:
|
|
affected_scope:
|
|
source_confidence:
|
|
valid_from:
|
|
valid_to:
|
|
tags:
|
|
external_references:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.2 SecurityDomain
|
|
|
|
A **SecurityDomain** is a scoped area of security concern.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
application security
|
|
cloud security
|
|
identity security
|
|
data security
|
|
network security
|
|
endpoint security
|
|
supply-chain security
|
|
platform security
|
|
operational security
|
|
physical security
|
|
AI/agent security
|
|
```
|
|
|
|
---
|
|
|
|
## 11.3 SecurityBoundary
|
|
|
|
A **SecurityBoundary** is a boundary across which trust, control, responsibility, policy, or exposure changes.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
tenant boundary
|
|
network zone boundary
|
|
trust boundary
|
|
identity domain boundary
|
|
runtime namespace boundary
|
|
data classification boundary
|
|
external integration boundary
|
|
```
|
|
|
|
---
|
|
|
|
## 11.4 ProtectedAssetReference
|
|
|
|
A **ProtectedAssetReference** points to a Landscape entity that requires security consideration.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
service
|
|
repository
|
|
artifact
|
|
workload
|
|
endpoint
|
|
dataset
|
|
secret
|
|
identity
|
|
network segment
|
|
pipeline
|
|
environment
|
|
```
|
|
|
|
---
|
|
|
|
## 11.5 SecurityPosture
|
|
|
|
**SecurityPosture** is the assessed security condition of an asset, service, domain, environment, or organization.
|
|
|
|
Posture may derive from:
|
|
|
|
```text
|
|
open findings
|
|
control effectiveness
|
|
exposure
|
|
vulnerability state
|
|
attack-path analysis
|
|
incident history
|
|
security reviews
|
|
patch state
|
|
detection coverage
|
|
access posture
|
|
configuration state
|
|
```
|
|
|
|
---
|
|
|
|
## 11.6 Threat
|
|
|
|
A **Threat** is a potential cause of unwanted security impact.
|
|
|
|
Threat may arise from:
|
|
|
|
```text
|
|
adversary
|
|
accident
|
|
misuse
|
|
system failure
|
|
supply-chain dependency
|
|
insider
|
|
automation error
|
|
environmental condition
|
|
```
|
|
|
|
---
|
|
|
|
## 11.7 ThreatActor
|
|
|
|
A **ThreatActor** is an actor or group that may intentionally cause security harm.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
criminal group
|
|
state-sponsored actor
|
|
malicious insider
|
|
opportunistic attacker
|
|
hacktivist
|
|
automated botnet
|
|
```
|
|
|
|
---
|
|
|
|
## 11.8 ThreatEvent
|
|
|
|
A **ThreatEvent** is an occurrence or attempted occurrence of adversarial or harmful activity.
|
|
|
|
---
|
|
|
|
## 11.9 Tactic
|
|
|
|
A **Tactic** is an adversary goal or phase of attack behavior.
|
|
|
|
This concept maps naturally to MITRE ATT&CK tactics.
|
|
|
|
---
|
|
|
|
## 11.10 AttackTechnique
|
|
|
|
An **AttackTechnique** is a method used to achieve an adversary tactic or security objective.
|
|
|
|
This concept maps naturally to MITRE ATT&CK techniques.
|
|
|
|
---
|
|
|
|
## 11.11 AttackPattern
|
|
|
|
An **AttackPattern** is a reusable pattern describing how an attack may be carried out.
|
|
|
|
This may map to CAPEC, ATT&CK, or internal threat models.
|
|
|
|
---
|
|
|
|
## 11.12 Weakness
|
|
|
|
A **Weakness** is a class of flaw or error pattern in design, implementation, configuration, process, hardware, or architecture.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
improper input validation
|
|
missing authentication
|
|
hardcoded credentials
|
|
insecure default configuration
|
|
insufficient logging
|
|
excess privilege
|
|
```
|
|
|
|
This concept maps to CWE where appropriate.
|
|
|
|
---
|
|
|
|
## 11.13 Vulnerability
|
|
|
|
A **Vulnerability** is a specific weakness, flaw, or exposure that may be exploited to violate security expectations.
|
|
|
|
Vulnerability records may reference:
|
|
|
|
```text
|
|
CVE
|
|
affected artifact
|
|
affected version
|
|
affected configuration
|
|
severity
|
|
exploitability
|
|
exploit evidence
|
|
fix version
|
|
workaround
|
|
```
|
|
|
|
---
|
|
|
|
## 11.14 Exposure
|
|
|
|
An **Exposure** is a condition that increases the possibility of discovery, access, exploitation, data compromise, or impact.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
publicly reachable endpoint
|
|
open management port
|
|
exposed secret
|
|
overly broad network path
|
|
internet-facing vulnerable service
|
|
excessive identity privilege
|
|
public storage bucket
|
|
```
|
|
|
|
Exposure may exist without a CVE.
|
|
|
|
---
|
|
|
|
## 11.15 Misconfiguration
|
|
|
|
A **Misconfiguration** is a configuration state that violates security expectation, policy, baseline, or safe design.
|
|
|
|
---
|
|
|
|
## 11.16 Exploit
|
|
|
|
An **Exploit** is code, technique, procedure, or method that uses a vulnerability, weakness, or exposure to cause security impact.
|
|
|
|
---
|
|
|
|
## 11.17 Exploitability
|
|
|
|
**Exploitability** is the practical ability to exploit a vulnerability or weakness in context.
|
|
|
|
Exploitability may depend on:
|
|
|
|
```text
|
|
network reachability
|
|
authentication requirement
|
|
privileges required
|
|
user interaction
|
|
known exploit availability
|
|
configuration
|
|
runtime condition
|
|
environment
|
|
```
|
|
|
|
---
|
|
|
|
## 11.18 Severity
|
|
|
|
**Severity** is a measure of technical or potential impact characteristics.
|
|
|
|
Severity is not the same as risk.
|
|
|
|
---
|
|
|
|
## 11.19 ExploitLikelihood
|
|
|
|
**ExploitLikelihood** is the estimated probability or plausibility that a vulnerability or exposure will be exploited.
|
|
|
|
This concept may map to EPSS or internal threat intelligence.
|
|
|
|
---
|
|
|
|
## 11.20 SecurityFinding
|
|
|
|
A **SecurityFinding** is an observed security-relevant issue, weakness, vulnerability, misconfiguration, exposure, violation, detection result, or assessment result.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
finding_type:
|
|
affected_entity:
|
|
severity:
|
|
confidence:
|
|
source:
|
|
first_seen:
|
|
last_seen:
|
|
status:
|
|
evidence:
|
|
recommended_action:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.21 VulnerabilityFinding
|
|
|
|
A **VulnerabilityFinding** is a finding that reports a vulnerability affecting an asset, artifact, dependency, configuration, or service.
|
|
|
|
---
|
|
|
|
## 11.22 MisconfigurationFinding
|
|
|
|
A **MisconfigurationFinding** is a finding that reports a security-relevant configuration problem.
|
|
|
|
---
|
|
|
|
## 11.23 ExposureFinding
|
|
|
|
An **ExposureFinding** is a finding that reports a reachable, discoverable, overexposed, or inappropriately public asset or path.
|
|
|
|
---
|
|
|
|
## 11.24 IdentityFinding
|
|
|
|
An **IdentityFinding** is a finding involving accounts, permissions, privileges, credentials, service accounts, sessions, or identity relationships.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
stale access
|
|
orphaned account
|
|
excess privilege
|
|
unused admin role
|
|
credential exposed
|
|
weak MFA coverage
|
|
privilege escalation path
|
|
```
|
|
|
|
---
|
|
|
|
## 11.25 DataSecurityFinding
|
|
|
|
A **DataSecurityFinding** is a finding involving sensitive data, classification, residency, retention, leakage, access, or processing exposure.
|
|
|
|
---
|
|
|
|
## 11.26 SupplyChainFinding
|
|
|
|
A **SupplyChainFinding** is a finding involving dependencies, packages, artifacts, repositories, pipelines, SBOMs, provenance, signatures, build systems, or external suppliers.
|
|
|
|
---
|
|
|
|
## 11.27 AttackPath
|
|
|
|
An **AttackPath** is a sequence of conditions, relationships, weaknesses, privileges, exposures, and actions that could allow an attacker to reach a target or cause impact.
|
|
|
|
---
|
|
|
|
## 11.28 AttackStep
|
|
|
|
An **AttackStep** is one step in an attack path.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
phish user
|
|
obtain token
|
|
access repository
|
|
modify workflow
|
|
build malicious artifact
|
|
deploy to production
|
|
exfiltrate data
|
|
```
|
|
|
|
---
|
|
|
|
## 11.29 AttackPrecondition
|
|
|
|
An **AttackPrecondition** is a condition required for an attack step or path.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
network reachability
|
|
valid credentials
|
|
missing MFA
|
|
vulnerable package version
|
|
public endpoint
|
|
write access to repository
|
|
```
|
|
|
|
---
|
|
|
|
## 11.30 AttackImpact
|
|
|
|
**AttackImpact** is the security consequence of a successful attack.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
data exfiltration
|
|
service disruption
|
|
privilege escalation
|
|
code execution
|
|
persistence
|
|
lateral movement
|
|
integrity loss
|
|
supply-chain compromise
|
|
```
|
|
|
|
---
|
|
|
|
## 11.31 BlastRadius
|
|
|
|
**BlastRadius** is the scope of assets, services, users, tenants, data, or obligations potentially affected by a security event or attack path.
|
|
|
|
---
|
|
|
|
## 11.32 ChokePoint
|
|
|
|
A **ChokePoint** is a point in an attack path where mitigation, monitoring, segmentation, control, or detection can significantly reduce attack feasibility or impact.
|
|
|
|
---
|
|
|
|
## 11.33 Mitigation
|
|
|
|
A **Mitigation** is an action, control, configuration, patch, design change, detection, process, or compensating measure that reduces security risk, exposure, exploitability, likelihood, or impact.
|
|
|
|
---
|
|
|
|
## 11.34 SecurityMeasure
|
|
|
|
A **SecurityMeasure** is a defensive measure used to protect, detect, respond, or recover.
|
|
|
|
Security measures may implement Governance controls.
|
|
|
|
---
|
|
|
|
## 11.35 HardeningMeasure
|
|
|
|
A **HardeningMeasure** is a security measure that reduces attack surface or strengthens configuration.
|
|
|
|
---
|
|
|
|
## 11.36 CompensatingMeasure
|
|
|
|
A **CompensatingMeasure** is a security measure used when a preferred control or mitigation is unavailable, delayed, or waived.
|
|
|
|
---
|
|
|
|
## 11.37 DetectionRule
|
|
|
|
A **DetectionRule** is logic intended to detect suspicious, malicious, noncompliant, or security-relevant behavior.
|
|
|
|
---
|
|
|
|
## 11.38 DetectionCoverage
|
|
|
|
**DetectionCoverage** describes which threats, techniques, assets, or attack paths are covered by detection rules, telemetry, or monitoring.
|
|
|
|
---
|
|
|
|
## 11.39 SecuritySignal
|
|
|
|
A **SecuritySignal** is a telemetry-derived or assessment-derived signal relevant to security.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
suspicious login
|
|
unexpected network connection
|
|
new vulnerable dependency
|
|
privilege change
|
|
malware detection
|
|
policy violation
|
|
secret exposure
|
|
```
|
|
|
|
---
|
|
|
|
## 11.40 Detection
|
|
|
|
A **Detection** is a recognized security signal or correlation that may indicate a threat, weakness, violation, or incident.
|
|
|
|
---
|
|
|
|
## 11.41 Alert
|
|
|
|
An **Alert** is a notification generated by detection or monitoring logic that may require triage.
|
|
|
|
---
|
|
|
|
## 11.42 SecurityIncident
|
|
|
|
A **SecurityIncident** is an event or set of events that has compromised, or may compromise, confidentiality, integrity, availability, safety, privacy, trust, or compliance.
|
|
|
|
---
|
|
|
|
## 11.43 Investigation
|
|
|
|
An **Investigation** is work performed to determine the nature, scope, cause, impact, and response needs of a security signal, alert, finding, or incident.
|
|
|
|
---
|
|
|
|
## 11.44 Containment
|
|
|
|
**Containment** is action taken to limit the spread, persistence, or impact of an active or suspected security incident.
|
|
|
|
---
|
|
|
|
## 11.45 Eradication
|
|
|
|
**Eradication** is action taken to remove the cause, mechanism, malware, persistence, account compromise, or vulnerability enabling an incident.
|
|
|
|
---
|
|
|
|
## 11.46 Recovery
|
|
|
|
**Recovery** is action taken to restore safe, trusted, and acceptable operation after a security incident.
|
|
|
|
---
|
|
|
|
## 11.47 LessonLearned
|
|
|
|
A **LessonLearned** is knowledge extracted from a security incident, finding, test, audit, or failure.
|
|
|
|
Lessons may create governance changes, tasks, controls, detections, or standards updates.
|
|
|
|
---
|
|
|
|
## 11.48 SecurityEvidence
|
|
|
|
**SecurityEvidence** is evidence supporting a security finding, assessment, incident, detection, mitigation, review, or assurance claim.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
scan result
|
|
log event
|
|
trace
|
|
packet capture
|
|
screenshot
|
|
SBOM
|
|
attestation
|
|
configuration snapshot
|
|
forensic image reference
|
|
signed review
|
|
```
|
|
|
|
---
|
|
|
|
## 11.49 SecurityAssessment
|
|
|
|
A **SecurityAssessment** is an evaluation of security posture, controls, architecture, code, configuration, exposure, or operation.
|
|
|
|
---
|
|
|
|
## 11.50 PenTestFinding
|
|
|
|
A **PenTestFinding** is a security finding produced by penetration testing or adversarial simulation.
|
|
|
|
---
|
|
|
|
## 11.51 SecurityReview
|
|
|
|
A **SecurityReview** is a review of design, code, configuration, architecture, policy, release, access, data, or operational practice from a security perspective.
|
|
|
|
---
|
|
|
|
## 11.52 SecurityPostureScore
|
|
|
|
A **SecurityPostureScore** is a derived metric summarizing security posture for a scope.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
SecurityPostureScore SHOULD be traceable to underlying findings, controls,
|
|
evidence, risk assumptions, and weighting model.
|
|
```
|
|
|
|
---
|
|
|
|
# 12. Core Relationship Vocabulary
|
|
|
|
Recommended root relationship types:
|
|
|
|
```text
|
|
affects
|
|
exposes
|
|
weakens
|
|
exploits
|
|
targets
|
|
threatens
|
|
uses_technique
|
|
maps_to_tactic
|
|
causes
|
|
enables
|
|
requires_precondition
|
|
traverses
|
|
leads_to
|
|
mitigates
|
|
detects
|
|
protects
|
|
contains
|
|
eradicates
|
|
recovers
|
|
evidenced_by
|
|
generated_by
|
|
reported_by
|
|
triaged_by
|
|
assigned_to
|
|
remediated_by
|
|
accepted_by
|
|
waived_by
|
|
compensated_by
|
|
maps_to
|
|
```
|
|
|
|
Relationship records SHOULD support:
|
|
|
|
```yaml
|
|
id:
|
|
relationship_type:
|
|
source_entity:
|
|
target_entity:
|
|
scope:
|
|
valid_from:
|
|
valid_to:
|
|
source_system:
|
|
confidence:
|
|
evidence:
|
|
rationale:
|
|
```
|
|
|
|
---
|
|
|
|
# 13. Security State Models
|
|
|
|
## 13.1 Finding States
|
|
|
|
```text
|
|
new
|
|
triaged
|
|
confirmed
|
|
false_positive
|
|
accepted
|
|
remediation_planned
|
|
remediation_in_progress
|
|
mitigated
|
|
remediated
|
|
verified
|
|
closed
|
|
reopened
|
|
```
|
|
|
|
## 13.2 Vulnerability States
|
|
|
|
```text
|
|
identified
|
|
affected
|
|
not_affected
|
|
under_investigation
|
|
fix_available
|
|
workaround_available
|
|
patched
|
|
mitigated
|
|
accepted
|
|
closed
|
|
```
|
|
|
|
## 13.3 Incident States
|
|
|
|
```text
|
|
detected
|
|
triaged
|
|
investigating
|
|
contained
|
|
eradication_in_progress
|
|
recovery_in_progress
|
|
recovered
|
|
post_incident_review
|
|
closed
|
|
```
|
|
|
|
## 13.4 Detection States
|
|
|
|
```text
|
|
candidate
|
|
active
|
|
tuning
|
|
suppressed
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
## 13.5 Mitigation States
|
|
|
|
```text
|
|
proposed
|
|
approved
|
|
implemented
|
|
partially_implemented
|
|
validated
|
|
ineffective
|
|
superseded
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 14. Security Patterns
|
|
|
|
## 14.1 Pattern: Finding-to-Remediation Trace
|
|
|
|
**Context:** Security tools produce findings.
|
|
|
|
**Problem:** Findings do not automatically become resolved security improvements.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
SecurityFinding
|
|
-> Risk / Severity / Exploitability Assessment
|
|
-> RemediationTask
|
|
-> Mitigation
|
|
-> Evidence
|
|
-> Verification
|
|
-> Closure
|
|
```
|
|
|
|
---
|
|
|
|
## 14.2 Pattern: Vulnerability Context Enrichment
|
|
|
|
**Context:** A scanner reports a CVE.
|
|
|
|
**Problem:** CVE severity alone is not enough to prioritize remediation.
|
|
|
|
**Solution:** Enrich vulnerability findings with:
|
|
|
|
```text
|
|
affected asset
|
|
runtime use
|
|
internet exposure
|
|
known exploit
|
|
EPSS or exploit likelihood
|
|
business criticality
|
|
data sensitivity
|
|
reachable path
|
|
compensating controls
|
|
fix availability
|
|
```
|
|
|
|
---
|
|
|
|
## 14.3 Pattern: Exposure Without CVE
|
|
|
|
**Context:** A system is exposed or misconfigured but has no known CVE.
|
|
|
|
**Problem:** Vulnerability-only programs miss security-relevant exposure.
|
|
|
|
**Solution:** Model ExposureFinding and MisconfigurationFinding separately from VulnerabilityFinding.
|
|
|
|
---
|
|
|
|
## 14.4 Pattern: Attack Path to Choke Point
|
|
|
|
**Context:** Many findings exist, and not all can be fixed immediately.
|
|
|
|
**Problem:** Remediation priority is unclear.
|
|
|
|
**Solution:** Model attack paths and identify choke points where mitigation reduces multiple paths or large blast radius.
|
|
|
|
---
|
|
|
|
## 14.5 Pattern: Detection Coverage Map
|
|
|
|
**Context:** A team wants threat-informed defense.
|
|
|
|
**Problem:** Detections are not linked to adversary techniques or protected assets.
|
|
|
|
**Solution:** Map DetectionRules to AttackTechniques, SecuritySignals, and ProtectedAssetReferences.
|
|
|
|
---
|
|
|
|
## 14.6 Pattern: Security Exception with Compensating Measure
|
|
|
|
**Context:** A finding or control gap cannot be fixed immediately.
|
|
|
|
**Problem:** Informal acceptance hides risk.
|
|
|
|
**Solution:** Use Governance Exception with explicit security context, compensating measure, expiry, review, and evidence.
|
|
|
|
---
|
|
|
|
## 14.7 Pattern: Incident-to-Lesson Loop
|
|
|
|
**Context:** An incident is resolved.
|
|
|
|
**Problem:** The same failure pattern recurs.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
SecurityIncident
|
|
-> Investigation
|
|
-> Root Cause / Contributing Conditions
|
|
-> LessonLearned
|
|
-> Governance Change / Security Measure / Task / Detection
|
|
```
|
|
|
|
---
|
|
|
|
## 14.8 Pattern: Supply Chain Finding Trace
|
|
|
|
**Context:** A dependency, build, artifact, or provenance issue is discovered.
|
|
|
|
**Problem:** Security teams cannot connect the issue to runtime impact.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
SupplyChainFinding
|
|
-> Dependency / Artifact / SBOM
|
|
-> DeploymentRecord
|
|
-> RuntimeWorkload
|
|
-> Service
|
|
-> RemediationTask
|
|
```
|
|
|
|
---
|
|
|
|
## 14.9 Pattern: Identity Exposure Path
|
|
|
|
**Context:** Permissions, credentials, and relationships create security exposure.
|
|
|
|
**Problem:** Identity risk is invisible when access data is isolated.
|
|
|
|
**Solution:** Combine Access Control entities with Security attack path and finding concepts.
|
|
|
|
---
|
|
|
|
# 15. Security Profiles
|
|
|
|
## 15.1 Profile Format
|
|
|
|
A Security Profile SHALL declare:
|
|
|
|
```yaml
|
|
id:
|
|
profile_name:
|
|
status:
|
|
implements:
|
|
- InfoTechCanonSecurityModel
|
|
target_context:
|
|
included_concepts:
|
|
required_relationships:
|
|
required_metadata:
|
|
state_model:
|
|
source_of_truth_rules:
|
|
mapping_files:
|
|
validation_rules:
|
|
examples:
|
|
known_deviations:
|
|
```
|
|
|
|
---
|
|
|
|
## 15.2 Seed Profile: Small SaaS Security Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Provide a minimal security model for a small SaaS platform moving toward production readiness.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
SecurityDomain
|
|
ProtectedAssetReference
|
|
SecurityFinding
|
|
VulnerabilityFinding
|
|
MisconfigurationFinding
|
|
ExposureFinding
|
|
Mitigation
|
|
SecurityIncident
|
|
SecurityEvidence
|
|
SecurityReview
|
|
SecurityPosture
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
SecurityFinding affects ProtectedAssetReference
|
|
VulnerabilityFinding maps_to CVE where available
|
|
MisconfigurationFinding violates SecurityExpectation
|
|
ExposureFinding exposes Endpoint
|
|
Mitigation mitigates SecurityFinding
|
|
SecurityIncident affects Service
|
|
SecurityEvidence evidences SecurityFinding
|
|
RemediationTask remediates SecurityFinding
|
|
```
|
|
|
|
---
|
|
|
|
## 15.3 Seed Profile: Vulnerability Management Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent vulnerability findings from scanners, advisories, SBOM analysis, and runtime context.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Vulnerability
|
|
Weakness
|
|
VulnerabilityFinding
|
|
AffectedComponent
|
|
Severity
|
|
ExploitLikelihood
|
|
Exploitability
|
|
FixVersion
|
|
Workaround
|
|
Mitigation
|
|
RemediationTask
|
|
VerificationEvidence
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
VulnerabilityFinding affects Artifact
|
|
Vulnerability maps_to CVE
|
|
Weakness maps_to CWE
|
|
Severity maps_to CVSS
|
|
ExploitLikelihood maps_to EPSS
|
|
RemediationTask fixes VulnerabilityFinding
|
|
Evidence verifies Remediation
|
|
```
|
|
|
|
---
|
|
|
|
## 15.4 Seed Profile: Threat-Informed Defense Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map adversary tactics, techniques, detections, and mitigations.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
ThreatActor
|
|
Tactic
|
|
AttackTechnique
|
|
DetectionRule
|
|
DetectionCoverage
|
|
Mitigation
|
|
SecuritySignal
|
|
Alert
|
|
Investigation
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
ThreatActor uses_technique AttackTechnique
|
|
AttackTechnique maps_to Tactic
|
|
DetectionRule detects AttackTechnique
|
|
Mitigation mitigates AttackTechnique
|
|
Alert generated_by DetectionRule
|
|
Investigation investigates Alert
|
|
```
|
|
|
|
---
|
|
|
|
## 15.5 Seed Profile: Application Security Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent application security requirements, findings, reviews, and assurance.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
ApplicationSecurityRequirementReference
|
|
SecurityReview
|
|
CodeSecurityFinding
|
|
DependencyFinding
|
|
AuthenticationFinding
|
|
AuthorizationFinding
|
|
InputValidationFinding
|
|
DataProtectionFinding
|
|
SecurityTestEvidence
|
|
```
|
|
|
|
Mapping targets:
|
|
|
|
```text
|
|
OWASP ASVS
|
|
OWASP Top 10
|
|
OWASP SAMM
|
|
CWE
|
|
SAST / DAST / SCA tool schemas
|
|
```
|
|
|
|
---
|
|
|
|
## 15.6 Seed Profile: Supply Chain Security Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent security posture across dependencies, builds, artifacts, SBOMs, provenance, signatures, and deployments.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
SupplyChainFinding
|
|
DependencyFinding
|
|
ArtifactFinding
|
|
ProvenanceFinding
|
|
SignatureFinding
|
|
SBOMEvidence
|
|
AttestationEvidence
|
|
BuildSystemExposure
|
|
RepositoryExposure
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
SupplyChainFinding affects Artifact
|
|
SupplyChainFinding evidenced_by SBOM
|
|
Artifact deployed_to RuntimeWorkload
|
|
RuntimeWorkload part_of Service
|
|
Mitigation applies_to Pipeline
|
|
```
|
|
|
|
---
|
|
|
|
## 15.7 Seed Profile: Identity Security Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent identity and access related security findings and attack paths.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
IdentityFinding
|
|
CredentialExposure
|
|
ExcessPrivilegeFinding
|
|
OrphanedAccountFinding
|
|
StaleAccessFinding
|
|
PrivilegeEscalationPath
|
|
AgentAccessFinding
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
IdentityFinding affects Principal
|
|
CredentialExposure exposes CredentialReference
|
|
PrivilegeEscalationPath traverses AccessGrant
|
|
ExcessPrivilegeFinding remediated_by AccessRemediationTask
|
|
```
|
|
|
|
---
|
|
|
|
## 15.8 Seed Profile: Security Incident Response Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent security incident lifecycle and response work.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
SecuritySignal
|
|
Detection
|
|
Alert
|
|
SecurityIncident
|
|
Investigation
|
|
Containment
|
|
Eradication
|
|
Recovery
|
|
LessonLearned
|
|
IncidentEvidence
|
|
PostIncidentReview
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
Alert triggers Investigation
|
|
Investigation confirms SecurityIncident
|
|
Containment contains SecurityIncident
|
|
Eradication eradicates Cause
|
|
Recovery restores Service
|
|
LessonLearned creates Task
|
|
PostIncidentReview reviews SecurityIncident
|
|
```
|
|
|
|
---
|
|
|
|
# 16. Mapping Model for the Security Standard
|
|
|
|
Mappings relate InfoTechCanon security concepts to external standards, frameworks, taxonomies, and products.
|
|
|
|
## 16.1 Mapping Types
|
|
|
|
Recommended mapping types:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
toolEquivalent
|
|
```
|
|
|
|
## 16.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
id: itc-map:vulnerability-to-cve
|
|
source_concept: itc-sec:Vulnerability
|
|
target_body: CVE
|
|
target_version: "current"
|
|
target_concept: CVE Record / CVE Identifier
|
|
mapping_type: closeMatch
|
|
scope:
|
|
- publicly known vulnerabilities and exposures
|
|
not_valid_for:
|
|
- internal-only misconfigurations
|
|
- generic weakness classes
|
|
- findings without public vulnerability identifier
|
|
rationale: >
|
|
CVE identifies publicly known vulnerabilities and exposures, while InfoTechCanon
|
|
Vulnerability also covers internally identified vulnerabilities that may not have a CVE.
|
|
confidence: high
|
|
status: candidate
|
|
owner: InfoTechCanonSecurityModel
|
|
```
|
|
|
|
## 16.3 Seed Mapping Targets
|
|
|
|
The Security Model SHOULD maintain mappings to:
|
|
|
|
```text
|
|
NIST CSF 2.0
|
|
MITRE ATT&CK
|
|
MITRE CAPEC
|
|
CVE
|
|
CWE
|
|
CVSS v4.0
|
|
EPSS
|
|
CISA KEV
|
|
OWASP ASVS
|
|
OWASP SAMM
|
|
OWASP Top 10
|
|
ISO/IEC 27001 / 27002
|
|
CIS Controls
|
|
CSA Cloud Controls Matrix
|
|
SLSA
|
|
SPDX / CycloneDX security and vulnerability data
|
|
OpenSSF Scorecard
|
|
OSV
|
|
GitHub Security Advisories
|
|
SIEM / detection rule formats
|
|
Cloud security posture management schemas
|
|
Container and Kubernetes security benchmarks
|
|
```
|
|
|
|
---
|
|
|
|
# 17. Assimilation Hooks
|
|
|
|
The Security Model SHALL be able to receive new security standards, frameworks, tools, products, and research through the InfoTechCanon assimilation process.
|
|
|
|
## 17.1 Assimilation Triggers
|
|
|
|
Assimilation may be triggered by:
|
|
|
|
```text
|
|
new security framework
|
|
new vulnerability taxonomy
|
|
new threat intelligence source
|
|
new scanner schema
|
|
new incident-response model
|
|
new application-security standard
|
|
new supply-chain security standard
|
|
new cloud security benchmark
|
|
new security product integration
|
|
new recurring security classification conflict
|
|
```
|
|
|
|
## 17.2 Security Assimilation Output
|
|
|
|
A security assimilation SHOULD produce:
|
|
|
|
```text
|
|
source summary
|
|
extracted security concepts
|
|
concept comparison matrix
|
|
gap list
|
|
conflict list
|
|
mapping file
|
|
candidate new concepts
|
|
candidate relationship changes
|
|
candidate pattern changes
|
|
candidate profile changes
|
|
open questions
|
|
```
|
|
|
|
## 17.3 Recommended First Assimilation Candidates
|
|
|
|
```text
|
|
NIST CSF 2.0
|
|
MITRE ATT&CK
|
|
CVE / CWE / CVSS / EPSS
|
|
OWASP ASVS
|
|
OWASP SAMM
|
|
CIS Controls
|
|
ISO/IEC 27001 Annex A
|
|
SLSA
|
|
OpenSSF Scorecard
|
|
Kubernetes CIS Benchmark
|
|
```
|
|
|
|
---
|
|
|
|
# 18. Integration with Other InfoTechCanon Standards
|
|
|
|
## 18.1 Governance Model
|
|
|
|
Security imports governance concepts for:
|
|
|
|
```text
|
|
policy
|
|
control objective
|
|
control
|
|
risk
|
|
exception
|
|
evidence
|
|
assurance
|
|
review
|
|
audit
|
|
compliance requirement
|
|
```
|
|
|
|
## 18.2 Access Control Model
|
|
|
|
Security imports access concepts for:
|
|
|
|
```text
|
|
principal
|
|
permission
|
|
privilege
|
|
grant
|
|
access session
|
|
access review
|
|
authorization decision
|
|
break-glass access
|
|
agent access
|
|
```
|
|
|
|
## 18.3 Landscape Model
|
|
|
|
Security applies to landscape concepts such as:
|
|
|
|
```text
|
|
service
|
|
repository
|
|
artifact
|
|
pipeline
|
|
runtime resource
|
|
endpoint
|
|
network path
|
|
dataset
|
|
environment
|
|
platform
|
|
tenant
|
|
```
|
|
|
|
## 18.4 Task Model
|
|
|
|
Security creates or references tasks such as:
|
|
|
|
```text
|
|
remediation task
|
|
incident task
|
|
investigation task
|
|
security review task
|
|
hardening task
|
|
verification task
|
|
```
|
|
|
|
## 18.5 Tagging Standard
|
|
|
|
Security uses tags for:
|
|
|
|
```text
|
|
severity
|
|
security domain
|
|
finding type
|
|
threat technique
|
|
exposure type
|
|
remediation priority
|
|
assurance status
|
|
```
|
|
|
|
Tags must not replace findings, risks, controls, or evidence.
|
|
|
|
## 18.6 DevSecOps Model
|
|
|
|
Security imports DevSecOps concepts for:
|
|
|
|
```text
|
|
repository
|
|
commit
|
|
pipeline run
|
|
artifact
|
|
SBOM
|
|
attestation
|
|
release
|
|
deployment
|
|
policy gate
|
|
```
|
|
|
|
---
|
|
|
|
# 19. Canon Interface Card Usage
|
|
|
|
Subsystems that implement or produce security knowledge SHOULD publish a Canon Interface Card.
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
subsystem: vulnerability-scanner-importer
|
|
implements:
|
|
- InfoTechCanonSecurityModel
|
|
- VulnerabilityManagementProfile
|
|
produces:
|
|
- VulnerabilityFinding
|
|
- Severity
|
|
- Exploitability
|
|
- SecurityEvidence
|
|
consumes:
|
|
- Artifact
|
|
- RuntimeWorkload
|
|
- Repository
|
|
- SBOM
|
|
relations:
|
|
- VulnerabilityFinding affects Artifact
|
|
- VulnerabilityFinding maps_to CVE
|
|
- RemediationTask fixes VulnerabilityFinding
|
|
source_of_truth:
|
|
scanner_results: scanner
|
|
known_deviations:
|
|
- exploit likelihood is not provided by scanner
|
|
- runtime reachability must be enriched from landscape model
|
|
```
|
|
|
|
---
|
|
|
|
# 20. Retrieval Requirements
|
|
|
|
The Security Model is designed for markdown-based infospaces.
|
|
|
|
## 20.1 Required Retrieval Properties
|
|
|
|
Every major concept SHOULD provide:
|
|
|
|
- stable heading,
|
|
- stable identifier,
|
|
- short definition,
|
|
- longer explanation,
|
|
- examples,
|
|
- distinction notes,
|
|
- relationship examples,
|
|
- mapping hooks,
|
|
- profile references,
|
|
- and common mistakes.
|
|
|
|
## 20.2 Agent Brief
|
|
|
|
A mature Security Model SHOULD include an `agent-brief.md` file with:
|
|
|
|
```text
|
|
purpose
|
|
scope
|
|
owned concepts
|
|
imported concepts
|
|
core distinctions
|
|
do / do not rules
|
|
relationship patterns
|
|
minimal examples
|
|
common mistakes
|
|
profile list
|
|
mapping list
|
|
```
|
|
|
|
## 20.3 Indexes
|
|
|
|
The security information space SHOULD provide indexes by:
|
|
|
|
```text
|
|
concept
|
|
relationship
|
|
security domain
|
|
finding type
|
|
threat technique
|
|
vulnerability identifier
|
|
weakness identifier
|
|
affected asset
|
|
mitigation
|
|
incident state
|
|
profile
|
|
pattern
|
|
mapping target
|
|
status
|
|
source system
|
|
```
|
|
|
|
---
|
|
|
|
# 21. Conformance Levels
|
|
|
|
## 21.1 Reference-Conformant
|
|
|
|
A document or system is reference-conformant if it uses Security Model terminology consistently but does not implement structured metadata or validation rules.
|
|
|
|
## 21.2 Metadata-Conformant
|
|
|
|
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
|
|
|
|
## 21.3 Relationship-Conformant
|
|
|
|
A system is relationship-conformant if it represents findings, vulnerabilities, exposures, mitigations, attack paths, incidents, detections, and evidence as explicit relationships.
|
|
|
|
## 21.4 Evidence-Conformant
|
|
|
|
A system is evidence-conformant if security claims, findings, incident states, and mitigations can be linked to evidence.
|
|
|
|
## 21.5 Context-Conformant
|
|
|
|
A system is context-conformant if security prioritization can reference affected assets, exposure, exploitability, criticality, compensating controls, and remediation state.
|
|
|
|
## 21.6 Profile-Conformant
|
|
|
|
A system is profile-conformant if it implements a declared Security Profile and passes its validation rules.
|
|
|
|
## 21.7 Assimilation-Conformant
|
|
|
|
A system or repository is assimilation-conformant if it can accept external security concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
|
|
|
|
---
|
|
|
|
# 22. Validation Rules
|
|
|
|
Initial validation rules:
|
|
|
|
```text
|
|
VAL-SEC-001: Weakness, Vulnerability, Exposure, Finding, and Risk SHOULD be modeled as distinct concepts.
|
|
|
|
VAL-SEC-002: VulnerabilityFinding SHOULD identify affected asset, source, severity or equivalent rating, confidence, and status when available.
|
|
|
|
VAL-SEC-003: CVE identifiers SHOULD be modeled as external mappings or references, not as the internal definition of Vulnerability.
|
|
|
|
VAL-SEC-004: CWE identifiers SHOULD map to Weakness, not Vulnerability.
|
|
|
|
VAL-SEC-005: CVSS or equivalent severity SHOULD NOT be treated as contextual risk without enrichment.
|
|
|
|
VAL-SEC-006: ExploitLikelihood SHOULD be modeled separately from Severity.
|
|
|
|
VAL-SEC-007: ExposureFinding SHOULD be allowed even when no CVE exists.
|
|
|
|
VAL-SEC-008: SecurityFinding SHOULD reference evidence or source system.
|
|
|
|
VAL-SEC-009: SecurityFinding SHOULD reference affected Landscape entity where possible.
|
|
|
|
VAL-SEC-010: RemediationTask SHOULD reference the finding or condition it remediates.
|
|
|
|
VAL-SEC-011: Security exceptions SHOULD reference Governance Exception or Waiver concepts.
|
|
|
|
VAL-SEC-012: AttackPath SHOULD include at least one affected asset, precondition, or attack step.
|
|
|
|
VAL-SEC-013: DetectionRule SHOULD reference the signal, technique, asset, or condition it is intended to detect.
|
|
|
|
VAL-SEC-014: SecurityIncident SHOULD reference affected service, asset, or scope when known.
|
|
|
|
VAL-SEC-015: SecurityPostureScore SHOULD be traceable to underlying evidence, findings, controls, or assumptions.
|
|
|
|
VAL-SEC-016: Imported external security concepts SHOULD be represented through mapping records rather than silently reused.
|
|
|
|
VAL-SEC-017: Profiles MUST NOT redefine canonical concepts. They may constrain them.
|
|
|
|
VAL-SEC-018: Tags MUST NOT replace security findings, risks, controls, or evidence.
|
|
```
|
|
|
|
---
|
|
|
|
# 23. Anti-Patterns
|
|
|
|
## 23.1 CVE Equals Risk
|
|
|
|
Treating a CVE score as complete risk without considering context.
|
|
|
|
## 23.2 Scanner Output as Truth
|
|
|
|
Assuming tool findings are complete, correct, and context-aware without evidence, confidence, or validation.
|
|
|
|
## 23.3 Finding Without Asset
|
|
|
|
Recording findings that cannot be connected to affected systems, artifacts, services, or data.
|
|
|
|
## 23.4 Severity as Priority
|
|
|
|
Using severity alone for remediation priority.
|
|
|
|
## 23.5 Vulnerability-Only Security
|
|
|
|
Ignoring exposure, misconfiguration, identity risk, detection gaps, and attack paths.
|
|
|
|
## 23.6 Permanent Risk Acceptance
|
|
|
|
Accepting security risk without scope, rationale, authority, compensating measure, expiry, or review.
|
|
|
|
## 23.7 Detection Without Coverage
|
|
|
|
Creating detection rules without mapping them to assets, techniques, signals, or threats.
|
|
|
|
## 23.8 Incident Without Lessons
|
|
|
|
Closing incidents without lessons learned, remediation, governance updates, or detection improvements.
|
|
|
|
## 23.9 Security Tags as Findings
|
|
|
|
Using labels such as `security` or `critical` without actual finding, risk, or evidence records.
|
|
|
|
## 23.10 Framework Subordination
|
|
|
|
Bending the internal model around one framework, scanner, or vendor schema.
|
|
|
|
---
|
|
|
|
# 24. Initial Repository Placement
|
|
|
|
Recommended repository layout:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
security/
|
|
InfoTechCanonSecurityModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
standards/security/InfoTechCanonSecurityModel.md
|
|
standards/security/agent-brief.md
|
|
standards/security/concepts/threat.md
|
|
standards/security/concepts/weakness.md
|
|
standards/security/concepts/vulnerability.md
|
|
standards/security/concepts/exposure.md
|
|
standards/security/concepts/security-finding.md
|
|
standards/security/concepts/attack-path.md
|
|
standards/security/concepts/mitigation.md
|
|
standards/security/concepts/security-incident.md
|
|
standards/security/patterns/finding-to-remediation-trace.md
|
|
standards/security/patterns/vulnerability-context-enrichment.md
|
|
standards/security/patterns/attack-path-to-choke-point.md
|
|
standards/security/profiles/small-saas-security-profile.md
|
|
standards/security/profiles/vulnerability-management-profile.md
|
|
standards/security/profiles/threat-informed-defense-profile.md
|
|
standards/security/profiles/supply-chain-security-profile.md
|
|
standards/security/mappings/nist-csf.yaml
|
|
standards/security/mappings/mitre-attack.yaml
|
|
standards/security/mappings/cve-cwe-cvss-epss.yaml
|
|
standards/security/mappings/owasp.yaml
|
|
```
|
|
|
|
---
|
|
|
|
# 25. Roadmap
|
|
|
|
## Phase 1: Seed Stabilization
|
|
|
|
- Establish this standard as `InfoTechCanonSecurityModel`.
|
|
- Add seed concepts, relationship vocabulary, patterns, and profiles.
|
|
- Define validation rules.
|
|
- Align with Governance, Access Control, Landscape, Task, and Tagging.
|
|
|
|
## Phase 2: First Assimilations
|
|
|
|
Recommended first assimilations:
|
|
|
|
```text
|
|
NIST CSF 2.0
|
|
MITRE ATT&CK
|
|
CVE / CWE / CVSS / EPSS
|
|
OWASP ASVS
|
|
OWASP SAMM
|
|
CIS Controls
|
|
ISO/IEC 27001 Annex A
|
|
SLSA
|
|
OpenSSF Scorecard
|
|
Kubernetes CIS Benchmark
|
|
```
|
|
|
|
## Phase 3: Profile Maturation
|
|
|
|
- Mature Small SaaS Security Profile.
|
|
- Mature Vulnerability Management Profile.
|
|
- Mature Threat-Informed Defense Profile.
|
|
- Mature Application Security Profile.
|
|
- Mature Supply Chain Security Profile.
|
|
- Mature Identity Security Profile.
|
|
- Mature Incident Response Profile.
|
|
|
|
## Phase 4: Tooling Integration
|
|
|
|
- Generate concept indexes.
|
|
- Generate agent brief.
|
|
- Create machine-readable YAML/JSON exports.
|
|
- Add validation scripts.
|
|
- Integrate scanner results, SBOMs, runtime context, access reviews, observability, and task systems.
|
|
|
|
## Phase 5: Security Intelligence Loop
|
|
|
|
- Connect findings to remediation tasks.
|
|
- Connect incidents to lessons learned.
|
|
- Connect attack paths to landscape graph.
|
|
- Connect security posture to governance risk and assurance.
|
|
- Connect detection coverage to threat techniques and observability signals.
|
|
|
|
---
|
|
|
|
# 26. Summary
|
|
|
|
The InfoTechCanon Security Model is the seed standard for representing cybersecurity posture, threat, vulnerability, exposure, finding, attack path, detection, incident, response, recovery, mitigation, and assurance semantics.
|
|
|
|
Its most important commitments are:
|
|
|
|
```text
|
|
Separate weakness, vulnerability, exposure, finding, risk, and incident.
|
|
|
|
Treat security context as essential for prioritization.
|
|
|
|
Model attack paths and exposure, not only CVEs.
|
|
|
|
Link findings to affected assets, evidence, remediation, mitigation, and verification.
|
|
|
|
Map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, and other frameworks
|
|
without surrendering internal semantic autonomy.
|
|
|
|
Import governance, access-control, task, tagging, and landscape concepts
|
|
instead of redefining them.
|
|
|
|
Use profiles to make the model practical for vulnerability management,
|
|
threat-informed defense, application security, supply-chain security,
|
|
identity security, and incident response.
|
|
```
|
|
|
|
This makes the Security Model a core seed for production readiness, security posture management, DevSecOps assurance, incident response, risk-informed prioritization, and agent-supported security operations.
|