SCOR - About

Framing overview entries for the SCOR MISP Framing. One value per real galaxy (four reference, two informative) plus a top-level Framing overview and a contribution-process entry. Descriptor only; the six real galaxies carry the working vocabulary.

Authors

Authors and/or Contributors
H4CK32N4U75®

SCOR MISP Framing Overview

Top-level overview of the SCOR MISP Framing.

Why the Framing exists. METEORSTORM is the only published threat-model framework whose Primary Capability Environment layer captures all five operational environments in a single taxonomy: Terrestrial, Aquatic, Aerial, Orbital, and Deep Space. Every other major catalog covers a slice, SPARTA and SPACE-SHIELD focus on the space segment, MITRE ATT&CK and CAPEC focus on enterprise IT/cyber, D3FEND on defensive countermeasures, EMB3D on embedded devices, FiGHT on 5G, ATLAS on AI/ML, the CSA matrices on cloud governance, NIST SP 800-160 on systems security engineering, NIST SP 800-53 on the control library, but none of them cover all five environments together. METEORSTORM unifies all five under one data model so a SCOR Platform Professional reasoning about a single converged platform does not have to translate between four or five disconnected vocabularies. The METEORSTORM taxonomy gives one shared set of tags; SCOR ships the rich knowledge objects (canonical definitions, structured relationships, analytic-catalog cross-references) that attach to those tags and make them actionable.

What ships. Six galaxies in two tiers. Four reference galaxies define the controlled vocabulary (TENs, Exposure Domains, Detection Signatures, Resilience Measures). Two informative galaxies illustrate the model in use (Incidents, Attack Paths).

Normalization bridge. SCOR normalizes thirteen external frameworks into the METEORSTORM Analytic Layer: MITRE ATT&CK, MITRE FiGHT, MITRE ATLAS, MITRE D3FEND, MITRE EMB3D, MITRE CAPEC, Aerospace SPARTA, ESA SPACE-SHIELD, CSA AI Controls Matrix (AICM), CSA Cloud Controls Matrix (CCM), CSA Shared Security Responsibility Model (SSRM), NIST SP 800-160 Volumes 1 and 2, NIST SP 800-53. Each entry in scor-resilience-measures carries a framework-mappings metadata field that records the equivalent control in each of these catalogs, so a single SCOR measure becomes the common reference point for controls expressed in many vocabularies. See the SCOR Resilience Measures overview entry for the full normalization table.

How relationships work. The six SCOR relation types (TOE, TDM, TRE, exposure-domain, detected-by, mitigated-by) are drawn by SCOR Platform Professionals in MISP at investigation time. Structural exception: incidents and attack paths carry TOE related[] links back to the TENs they instantiate, with the per-scenario ETEN string in the relation tags.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000001 which can be used as unique global reference for SCOR MISP Framing Overview in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
role	framing-overview

SCOR TENs (reference)

Reference galaxy of the 30 Taxonomic Element Nomenclatures from METEORSTORM Quick Guide §8, across the five layers: PCE (5), SEG (10), SVC (3), AST (6), AN (6).

Vocabulary distinction (TEN vs ETEN). A TEN is a stable template identifying the TYPE of an element. It uses LAYER-TAG-LABEL form with dashes, for example SEG-GR-Ground or AST-SW-Software or PCE-OR-Orbital. The 30 TENs are fixed by METEORSTORM Quick Guide §8 and do not change. An ETEN is what a SCOR Platform Professional produces by enumerating a TEN on a specific platform: select the TEN, append an ordinal, and supply a per-platform description. ETENs use LAYER:TAG:LABEL:ORDINAL form with colons.

Worked example. The TEN SEG-GR-Ground identifies the ground segment as a type. On a specific platform, an analyst might enumerate three instantiations: SEG:GR:Ground:01 ("Primary ground control operator workstation"), SEG:GR:Ground:02 ("Secondary mission planning console"), SEG:GR:Ground:03 ("Telemetry processing server cluster"). Each ETEN is unique to that platform; the parent TEN stays the same.

Where ETENs appear. scor-incidents and scor-attack-paths cluster values carry TOE related[] links back to the parent TEN UUIDs in scor-tens, with the per-scenario ETEN string in the relation tags (formatted as scor:eten="LAYER:TAG:LABEL:ORDINAL"). This anchors each instance to the template it instantiates without baking analyst judgment into the cluster JSON.

File pair: galaxies/scor-tens.json and clusters/scor-tens.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000005 which can be used as unique global reference for SCOR TENs (reference) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
galaxy	scor-tens
role	reference-galaxy

SCOR Exposure Domains (reference)

Reference galaxy for the five exposure domains of METEORSTORM Quick Guide Table 2.2 (Kinetic, Non-kinetic, Electronic Warfare (EW), Cyber Warfare, Other (environmental)), applied orthogonally to the SCOR layer schema. File pair: galaxies/scor-exposure-domain.json and clusters/scor-exposure-domain.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000006 which can be used as unique global reference for SCOR Exposure Domains (reference) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
galaxy	scor-exposure-domain
role	reference-galaxy

SCOR Detection Signatures (reference)

Reference galaxy for AN-DET values. Each detection signature carries a mandatory METEORSTORM layer mapping (PCE/SEG/SVC/AST) in metadata and embeds a full-template RootA YAML rule in meta.roota whose UUID equals the cluster value UUID. SCOR Platform Professionals draw TDM relationships to the TEN clusters the signature is designed to observe. File pair: galaxies/scor-detection-signatures.json and clusters/scor-detection-signatures.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000007 which can be used as unique global reference for SCOR Detection Signatures (reference) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
galaxy	scor-detection-signatures
role	reference-galaxy

SCOR Resilience Measures (reference)

Reference galaxy for AN-RES values. Each measure lists TRE candidates (the TENs it protects) and records equivalent controls from external frameworks via the framework-mappings metadata field. This is the Framing's normalization bridge: a single SCOR measure becomes the common reference point for controls expressed in many vocabularies.

The thirteen frameworks normalized into the METEORSTORM Analytic Layer, with the publisher and the benefit of normalization for each:

• MITRE ATT&CK, The MITRE Corporation (https://attack.mitre.org). The globally adopted catalog of adversary tactics, techniques, and procedures across enterprise, cloud, mobile, and industrial control system environments. Normalizing ATT&CK into the METEORSTORM Analytic Layer gives defenders a stable lexicon for adversary behavior that every partner organization already speaks, so Attack Path (AN-ATT-Attack Path) and Threat (AN-THR-Threat) entries sourced from ATT&CK are portable across teams and tools with no translation cost.

• MITRE FiGHT, The MITRE Corporation, with the U.S. DoD 5G Cross-Functional Team (https://fight.mitre.org). A purpose-built threat model for 5G telecommunications networks spanning the radio interface, core network, and service layer. Normalizing FiGHT lets METEORSTORM carry 5G-specific adversary knowledge against link- and ground-segment services that rely on 5G infrastructure, without requiring defenders to maintain a separate 5G-only lane in their tooling.

• MITRE ATLAS, The MITRE Corporation (https://atlas.mitre.org). Adversary tactics, techniques, and case studies targeting AI and machine learning systems, including data poisoning, model evasion, prompt injection, and adversarial input manipulation. Normalizing ATLAS gives the Analytic Layer a stable vocabulary for AI/ML adversary behavior, so AI-facing AN-ATT-Attack Path and AN-THR entries carry the same threat language that AI security teams already use. (Where these entries attach in the service layer depends on how the affected AI workloads are enumerated as ETENs on the platform under analysis; the canonical 30-TEN catalog from METEORSTORM Quick Guide section 8 governs available service-layer TENs.)

• MITRE D3FEND, The MITRE Corporation, funded by the NSA (https://d3fend.mitre.org). A structured knowledge graph of cybersecurity countermeasures and defensive techniques mapped against offensive TTPs. Normalizing D3FEND gives Detection Signature (AN-DET-Detection Signature) and Resilience Measure (AN-RES-Resilience Measure) entries a shared vocabulary for defender actions, so that a defensive control enumerated by one team is immediately recognizable and actionable to another.

• MITRE EMB3D, The MITRE Corporation (https://emb3d.mitre.org). An emerging threat model cataloging cyber threats to embedded devices (the firmware, bootloaders, and microcontrollers underneath complex platforms) with mapped mitigations. Normalizing EMB3D is what lets METEORSTORM reach beneath flight software into the firmware-layer assets (AST-FW-Firmware) where space, drone, and embedded platforms are increasingly targeted.

• MITRE CAPEC, The MITRE Corporation, originally sponsored by the U.S. Department of Homeland Security (https://capec.mitre.org). The Common Attack Pattern Enumeration and Classification catalog, describing how attacks are executed at an abstract, reusable pattern level across software and systems. Normalizing CAPEC supplies METEORSTORM with the generalized attack-pattern language that complements the more tactical ATT&CK catalog, useful for Attack Path entries whose underlying mechanism is a well-known software pattern rather than a specific adversary TTP.

• Aerospace SPARTA, The Aerospace Corporation (https://sparta.aerospace.org). The Space Attack Research and Tactic Analysis framework, the first matrix purpose-built for spacecraft and space systems, cataloging adversary TTPs across reconnaissance, initial access, execution, persistence, and impact. Normalizing SPARTA gives the Analytic Layer the space-specific adversary vocabulary that no enterprise-focused framework fully captures, and is the canonical source for AN-ATT entries attached to space-segment assets.

• ESA SPACE-SHIELD, European Space Agency (ESA), via the Space Security Operations Centre at ESEC Redu (https://spaceshield.esa.int). The Space Attacks and Countermeasures Engineering Shield, delivering an ATT&CK-aligned knowledge base tailored to the space segment and communication links. Normalizing SPACE-SHIELD complements SPARTA by bringing the European space community's perspective into the same analytic entry, so that trans-Atlantic partner organizations can share space-threat intelligence in a single vocabulary.

• CSA AI Controls Matrix (AICM), Cloud Security Alliance (CSA) (https://cloudsecurityalliance.org/artifacts/ai-controls-matrix). A vendor-agnostic control framework for securely developing, operating, and governing cloud-based AI systems, mapped to ISO 42001, ISO 27001, and NIST AI RMF. Normalizing AICM is what lets METEORSTORM enumerate AI-governance controls as Resilience Measure (AN-RES-Resilience Measure) entries that are already crosswalked to the major audit standards, eliminating duplicate control-mapping work.

• CSA Cloud Controls Matrix (CCM), Cloud Security Alliance (CSA) (https://cloudsecurityalliance.org/research/cloud-controls-matrix). The de facto standard for cloud security assurance, comprising control objectives across security domains and crosswalked to ISO 27001, NIST, PCI, and other leading standards. Normalizing CCM lets cloud-segment AN-RES entries carry the same control vocabulary that enterprise security teams already use, so mission-assurance analytics roll up cleanly into existing cloud governance reporting.

• CSA Shared Security Responsibility Model (SSRM), Cloud Security Alliance (CSA) (https://cloudsecurityalliance.org/research/working-groups/shared-security-responsibility-model). The canonical model defining where security responsibility sits between cloud service providers and cloud service consumers across IaaS, PaaS, and SaaS. Normalizing SSRM is essential for multi-operator space and ground architectures; it gives analytic entries a defensible way to enumerate which party owns a given control, preventing the gaps that emerge when responsibility is ambiguous across the stack.

• NIST SP 800-160 Volumes 1 and 2, U.S. National Institute of Standards and Technology (NIST) (https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final). Systems security engineering and cyber resiliency engineering frameworks providing principled guidance for building trustworthy, survivable systems. Normalizing SP 800-160 is the methodological anchor for Resilience Measure (AN-RES-Resilience Measure) entries; the Anticipate - Withstand - Recover - Adapt goals from Volume 2 are the engineering definition behind what AN-RES-Resilience Measure exists to capture.

• NIST SP 800-53, U.S. National Institute of Standards and Technology (NIST) (https://csrc.nist.gov/projects/risk-management/sp800-53-controls). The comprehensive catalog of security and privacy controls for federal information systems and organizations: the reference control library the U.S. government and countless commercial programs build against. Normalizing SP 800-53 means Resilience Measure (AN-RES-Resilience Measure) entries can reference the exact control identifiers that appear in an organization's System Security Plan, closing the loop between threat-informed analytics and compliance-driven engineering.

How it is used. SCOR Platform Professionals draw TRE relationships in MISP from each measure to the TEN clusters it is intended to protect. The framework-mappings field provides the cross-walk so an organization running SPARTA, a different organization running CSA CCM, a third organization running NIST SP 800-53, and a fourth running ESA SPACE-SHIELD can all point at the same SCOR measure as the canonical reference.

File pair: galaxies/scor-resilience-measures.json and clusters/scor-resilience-measures.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000002 which can be used as unique global reference for SCOR Resilience Measures (reference) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
frameworks-normalized	['MITRE ATT&CK', 'MITRE FiGHT', 'MITRE ATLAS', 'MITRE D3FEND', 'MITRE EMB3D', 'MITRE CAPEC', 'Aerospace SPARTA', 'ESA SPACE-SHIELD', 'CSA AI Controls Matrix (AICM)', 'CSA Cloud Controls Matrix (CCM)', 'CSA Shared Security Responsibility Model (SSRM)', 'NIST SP 800-160 Volumes 1 and 2', 'NIST SP 800-53']
galaxy	scor-resilience-measures
role	reference-galaxy

SCOR Incidents (informative)

Informative galaxy of known incidents relevant to converged platforms, primarily for upskilling SCOR Platform Professionals. Each incident carries a confidence score 1-10 and a written basis in metadata, and ships a TOE related[] array back to the parent TEN UUID(s) in scor-tens with the per-scenario ETEN string in the relation tags (reference anchoring to the TEN galaxy). SCOR Incidents are reviewed and published by certified SCOR Platform Professionals within the SCORP2 community. File pair: galaxies/scor-incidents.json and clusters/scor-incidents.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000008 which can be used as unique global reference for SCOR Incidents (informative) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
galaxy	scor-incidents
role	informative-galaxy

SCOR Attack Paths (informative)

Informative galaxy of attack paths through converged platforms. Each path records initial access, lateral movement, and intended target in metadata, lists TOE candidates as reference notes, and ships a TOE related[] array back to the parent TEN UUID(s) in scor-tens with the per-scenario ETEN string in the relation tags (reference anchoring to the TEN galaxy). SCOR Attack Paths are reviewed and published by certified SCOR Platform Professionals within the SCORP2 community. File pair: galaxies/scor-attack-paths.json and clusters/scor-attack-paths.json.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000003 which can be used as unique global reference for SCOR Attack Paths (informative) in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
galaxy	scor-attack-paths
role	informative-galaxy

Contributing to the SCOR MISP Framing

How public contributions to the SCOR MISP Framing are accepted. The Framing operates under a closed-commit governance model: only SCORP2 community members commit to the repository. Anyone may contribute content through the intake channel published by the SCORP2 community, and accepted public contributions are committed by a community member with attribution to the original contributor. Submissions to SCOR Incidents and SCOR Attack Paths are reviewed and published by certified SCOR Platform Professionals within the SCORP2 community. Contributions must conform to the normative reference for their galaxy (see the Framing reference document Section 7.4 for Detection Signatures). Contact the steward at william.o.ferguson@hkn.space for the current intake channel.

Internal MISP references

UUID a7f8f3a2-8a73-489f-9c5b-000000000004 which can be used as unique global reference for Contributing to the SCOR MISP Framing in MISP communities and other software using the MISP galaxy

Associated metadata

Metadata key	Value
role	framing-process