coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
info-tech-canon/seeds/InfoTechCanonSecurityModel_RC1_seed.md

48 KiB
Executable File
Raw Permalink Blame History

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:

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.

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:

Policy
Rule
ControlObjective
Control
Risk
Exception
Evidence
Audit
Assurance
ComplianceRequirement
Decision
Approval
Review

The Security Model owns:

Threat
ThreatActor
AttackTechnique
Weakness
Vulnerability
Exposure
SecurityFinding
SecurityIncident
AttackPath
Mitigation
Detection
SecuritySignal
SecurityPosture
SecurityAssuranceSignal

Boundary rule:

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:

Subject
Principal
Permission
Privilege
Entitlement
Grant
AuthorizationDecision
AccessSession
AccessReview
BreakGlassAccess
AgentAccess

The Security Model may analyze these as security-relevant.

Examples:

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:

Service
ApplicationService
SoftwareComponent
Repository
Artifact
RuntimeResource
NetworkEndpoint
Dataset
Environment
NetworkPath
ObservabilitySignal

Security applies to those entities.

Examples:

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:

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:

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:

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:

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:

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:

---
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:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

10. Root Security Taxonomy

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:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:

Optional attributes:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

SecurityPostureScore SHOULD be traceable to underlying findings, controls,
evidence, risk assumptions, and weighting model.

12. Core Relationship Vocabulary

Recommended root relationship types:

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:

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

new
triaged
confirmed
false_positive
accepted
remediation_planned
remediation_in_progress
mitigated
remediated
verified
closed
reopened

13.2 Vulnerability States

identified
affected
not_affected
under_investigation
fix_available
workaround_available
patched
mitigated
accepted
closed

13.3 Incident States

detected
triaged
investigating
contained
eradication_in_progress
recovery_in_progress
recovered
post_incident_review
closed

13.4 Detection States

candidate
active
tuning
suppressed
deprecated
retired

13.5 Mitigation States

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:

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:

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:

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:

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:

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:

Provide a minimal security model for a small SaaS platform moving toward production readiness.

Included concepts:

SecurityDomain
ProtectedAssetReference
SecurityFinding
VulnerabilityFinding
MisconfigurationFinding
ExposureFinding
Mitigation
SecurityIncident
SecurityEvidence
SecurityReview
SecurityPosture

Required relationships:

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:

Represent vulnerability findings from scanners, advisories, SBOM analysis, and runtime context.

Included concepts:

Vulnerability
Weakness
VulnerabilityFinding
AffectedComponent
Severity
ExploitLikelihood
Exploitability
FixVersion
Workaround
Mitigation
RemediationTask
VerificationEvidence

Required relationships:

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:

Map adversary tactics, techniques, detections, and mitigations.

Included concepts:

ThreatActor
Tactic
AttackTechnique
DetectionRule
DetectionCoverage
Mitigation
SecuritySignal
Alert
Investigation

Required relationships:

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:

Represent application security requirements, findings, reviews, and assurance.

Included concepts:

ApplicationSecurityRequirementReference
SecurityReview
CodeSecurityFinding
DependencyFinding
AuthenticationFinding
AuthorizationFinding
InputValidationFinding
DataProtectionFinding
SecurityTestEvidence

Mapping targets:

OWASP ASVS
OWASP Top 10
OWASP SAMM
CWE
SAST / DAST / SCA tool schemas

15.6 Seed Profile: Supply Chain Security Profile

Purpose:

Represent security posture across dependencies, builds, artifacts, SBOMs, provenance, signatures, and deployments.

Included concepts:

SupplyChainFinding
DependencyFinding
ArtifactFinding
ProvenanceFinding
SignatureFinding
SBOMEvidence
AttestationEvidence
BuildSystemExposure
RepositoryExposure

Required relationships:

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:

Represent identity and access related security findings and attack paths.

Included concepts:

IdentityFinding
CredentialExposure
ExcessPrivilegeFinding
OrphanedAccountFinding
StaleAccessFinding
PrivilegeEscalationPath
AgentAccessFinding

Required relationships:

IdentityFinding affects Principal
CredentialExposure exposes CredentialReference
PrivilegeEscalationPath traverses AccessGrant
ExcessPrivilegeFinding remediated_by AccessRemediationTask

15.8 Seed Profile: Security Incident Response Profile

Purpose:

Represent security incident lifecycle and response work.

Included concepts:

SecuritySignal
Detection
Alert
SecurityIncident
Investigation
Containment
Eradication
Recovery
LessonLearned
IncidentEvidence
PostIncidentReview

Required relationships:

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:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent

16.2 Mapping Record

Example:

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:

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:

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:

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

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:

policy
control objective
control
risk
exception
evidence
assurance
review
audit
compliance requirement

18.2 Access Control Model

Security imports access concepts for:

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:

service
repository
artifact
pipeline
runtime resource
endpoint
network path
dataset
environment
platform
tenant

18.4 Task Model

Security creates or references tasks such as:

remediation task
incident task
investigation task
security review task
hardening task
verification task

18.5 Tagging Standard

Security uses tags for:

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:

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:

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:

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:

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:

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:

info-tech-canon/
  standards/
    security/
      InfoTechCanonSecurityModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

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:

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:

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.

Reference in New Issue View Git Blame Copy Permalink