# 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.