Benjamin Admin
b0435f9885
Schema-Papier statt capabilities.json (User-Entscheidung). Befund: die 8 SHARED_CAPABILITY- Cluster zerfallen in Typ-1 (technische Capabilities: mfa/tls/code_signing/session/anomaly) und Typ-2 (Sicherheitsziele: attack_surface_min/software_integrity = die #4-Gaps). Empfehlung Modell C: Capability = EINZIGE neue Klasse; Sicherheitsziele = CORE Legal Obligations (CORE/DOMAIN existiert bereits). Kanten-Graph (realized_by/specializes/...). guidance_basis gehört konzeptionell an die Capability. 4 Entscheidungen offen (User). #5b Materialisierung GEGATED auf Modell-Annahme — keine Daten verschoben. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
204 lines
12 KiB
Markdown
204 lines
12 KiB
Markdown
# Capability Model v1 — Objektarten & Beziehungstypen (Schema-Papier, NICHT materialisiert)
|
||
|
||
Status: **OFFEN / Entscheidung erforderlich (2026-06-26).** Dies ist Schritt **#5a** (Papier).
|
||
Schritt **#5b** (Materialisierung: `capabilities.json`, Migration, Obligation→Capability-Links,
|
||
Guidance-Mapping, Runtime) ist **GEGATED** auf die Annahme dieses Papiers. **Es wurde noch keine
|
||
Zeile Daten verschoben.**
|
||
|
||
Baut auf [legal_obligation_layer_v1.md](legal_obligation_layer_v1.md),
|
||
[obligation_registry_v1.md](obligation_registry_v1.md) und dem Cross-Domain-Review
|
||
(`obligations/cross_domain_relationships.json`, Commit `ed31fdc0`).
|
||
|
||
---
|
||
|
||
## 0. Warum ein Papier statt `capabilities.json`
|
||
|
||
Die Plattform hat drei empirische Architektur-Sprünge gemacht:
|
||
1. **Control ≠ Wissensobjekt** → Legal Obligation (sofort implementiert, datenbestätigt).
|
||
2. **Procedure ist eigenständig** (implementiert: `cra_procedures.json`).
|
||
3. **Capabilities tauchen domänenübergreifend wieder auf** (Cross-Domain-Review).
|
||
|
||
(1) und (2) waren breit datenbelegt → sofort umgesetzt. Bei (3) ist die **Objektart selbst noch
|
||
nicht definiert.** Wir wissen NICHT genau, was eine Capability ist. Materialisieren wir jetzt,
|
||
riskieren wir, in drei Wochen festzustellen: „Attack Surface war gar keine Capability" → Umbau.
|
||
|
||
---
|
||
|
||
## 1. Der Auslöser: die 8 „Capabilities" sind NICHT eine Objektart
|
||
|
||
Der Cross-Domain-Review fand 16 `SHARED_CAPABILITY`-Paare → 8 Cluster. Bei Inspektion zerfallen
|
||
sie in **zwei verschiedene Objektarten**:
|
||
|
||
| Cluster (Opus-Benennung) | Art | Begründung |
|
||
|---|---|---|
|
||
| `mfa` | **Capability** | implementierbar als Funktion |
|
||
| `session_management` | **Capability** | implementierbar |
|
||
| `transport_encryption` (tls/mutual_tls/cert) | **Capability** | implementierbar (vom Klassifikator fein gesplittet → 1 Capability) |
|
||
| `code_signing` | **Capability** | implementierbar |
|
||
| `anomaly_detection` | **Capability** | implementierbar |
|
||
| `access_control` | **Ziel** (schwach) | abstraktes Ziel, kein Baustein — eher OVERLAP (siehe Konsolidierung) |
|
||
|
||
Dazu die **zwei Gap-„Obligations" aus Handoff #4** (NIST SI-7/CM-7 waren breiter als jeder
|
||
einzelne Treffer):
|
||
|
||
| Kandidat | Art | Begründung |
|
||
|---|---|---|
|
||
| `software_integrity_protection` (SI-7) | **Sicherheitsziel** | wird NICHT direkt gebaut; erreicht durch code_signing + hash_verification + secure_boot |
|
||
| `attack_surface_minimization` (CM-7) | **Sicherheitsziel** | erreicht durch least_functionality + Port-Deaktivierung + Interface-Reduktion |
|
||
|
||
**Kernbeobachtung (User):** Es gibt **Typ 1 — technische Fähigkeiten** (implementierbar) und
|
||
**Typ 2 — Sicherheitsziele** (nicht direkt implementierbar, durch mehrere Capabilities erreicht).
|
||
Sie in eine `capabilities.json` zu werfen wäre der Fehler.
|
||
|
||
```
|
||
Integrity Protection (Ziel) Access Protection (Ziel)
|
||
↑ erreicht durch ↑ erreicht durch
|
||
code_signing · hash_verification · mfa · session_management ·
|
||
secure_boot (Capabilities) credential_storage (Capabilities)
|
||
```
|
||
|
||
Das erklärt rückwirkend auch das **systematische Synth-Über-Tiering** (Auth 14→6, Remote 14→5):
|
||
das LLM mischte ziel-nahe Obligations mit fähigkeits-nahen Mechanismen, weil die Modellsprache
|
||
die Ebenen nicht trennte.
|
||
|
||
---
|
||
|
||
## 2. Kandidat-Objektarten
|
||
|
||
| Objektart | Definition | Diskriminator-Test |
|
||
|---|---|---|
|
||
| **Regulation** | Rechtsakt (CRA, NIS2, DSGVO, MaschVO) | „Ist es ein Gesetz/VO?" |
|
||
| **Legal Obligation** | rechtlich verankerte Pflicht. **CORE** (abstrakt, oft = Sicherheitsziel) ⊇ **DOMAIN** (spezialisiert) — die CORE/DOMAIN-Achse existiert bereits (portability). | „Steht das so (sinngemäß) im Recht? Kann ein Prüfer FEHLT/ERFÜLLT sagen?" |
|
||
| **Capability** *(NEU)* | implementierbare, **regulierungs-agnostische** technische Funktion, als Einheit baubar & testbar | „Kann ein Hersteller GENAU DAS bauen/konfigurieren?" → ja |
|
||
| **Procedure** | wiederholbarer operativer Prozess, der eine Capability ausbringt/erhält (bereits modelliert) | „Ist es eine Tätigkeit/ein Ablauf?" |
|
||
| **Control** | testbare Prüfanweisung | „Kann man es prüfen (pass/fail)?" |
|
||
| **Evidence** | Nachweis-Artefakt (Audit-Log, SBOM, Release Notes) | „Ist es ein Beleg-Dokument/Datum?" |
|
||
| **Guidance** *(quer)* | externe Empfehlung WIE (NIST/OWASP/ENISA/BSI). **Nicht-bindend.** | „Beschreibt es eine empfohlene Umsetzung, kein Primärrecht?" |
|
||
|
||
---
|
||
|
||
## 3. DER ZENTRALE KNACKPUNKT: Ist „Security Objective" eine eigene Klasse?
|
||
|
||
### Modell A — flach (Objektive = Obligations)
|
||
```
|
||
Regulation → Legal Obligation → Capability → Procedure → Control → Evidence
|
||
```
|
||
Sicherheitsziele sind einfach **CORE Legal Obligations**; domänen-scoped Pflichten sind DOMAIN-
|
||
Obligations, die per `specializes` an die CORE hängen.
|
||
|
||
### Modell B — mit eigener Security-Objective-Klasse
|
||
```
|
||
Regulation → Legal Obligation → Security Objective → Capability → Procedure → Control → Evidence
|
||
```
|
||
|
||
### Modell C — hybrid (Capability als einzige neue Klasse) ← **EMPFEHLUNG**
|
||
```
|
||
Regulation → Legal Obligation (CORE ⊇ DOMAIN) --realized_by--> Capability → Procedure → Control → Evidence
|
||
▲ ▲
|
||
└── specializes (DOMAIN→CORE) └── described_by ── Guidance (NIST/OWASP/…)
|
||
```
|
||
|
||
**Empfehlung: Modell C.** Begründung aus den Daten:
|
||
- Die „Sicherheitsziele" (`software_integrity_protection`, `attack_surface_minimization`, CIA,
|
||
access-protection) **SIND im CRA bindende Pflichten** (Annex I (2)(a–m) ist Primärrecht). Ein
|
||
Sicherheitsziel ist also eine **CORE Legal Obligation**, kein neuer Objekttyp.
|
||
- Die **CORE/DOMAIN-Achse existiert schon** (portability_core ⊇ health/data_act). `attack_surface_
|
||
minimization` (CORE) ⊇ `remote_access_attack_surface_min` (DOMAIN) ist exakt dasselbe Muster.
|
||
→ keine neue Klasse, nur konsequente Nutzung des Vorhandenen.
|
||
- **Genau EINE** wirklich neue Klasse (**Capability**) ist sparsam und niedrig-risiko.
|
||
- Modell B verdoppelt die normative Ebene (Obligation vs Objective), die im CRA 1:1 zusammenfällt
|
||
→ Klasse, die niemand sauber befüllt.
|
||
|
||
**Konsequenz für die #4-Gap:** `software_integrity_protection` + `attack_surface_minimization`
|
||
werden als **CORE Legal Obligations** angelegt (nicht als Capabilities), und die domänen-scoped
|
||
Treffer (`signed_update_integrity`, `remote_access_attack_surface_min`) `specializes` → CORE.
|
||
NIST SI-7/CM-7 mappen dann `primary_implementation` auf die CORE.
|
||
|
||
**Offen für den User:** Modell C akzeptieren? Oder ist die regulierungs-AGNOSTISCHE Vereinheitlichung
|
||
(eine „confidentiality" über CRA+NIS2+ISO) so wertvoll, dass „Security Objective" doch eine eigene
|
||
Klasse verdient (Modell B)? Das ist die einzige wirklich offene Architekturentscheidung.
|
||
|
||
---
|
||
|
||
## 4. Beziehungstypen — das Modell ist ein GRAPH, keine flache Ebene
|
||
|
||
Der Review fand **vier distinkte Cross-Domain-Strukturrelationen** (nicht eine):
|
||
`SUPPORTED_BY` 23 · `SHARED_CAPABILITY` 16 · `SHARED_EVIDENCE` 7 · `SHARED_PROCEDURE` 5 (+ 1 Merge).
|
||
Das ist kein Baum. Vorgeschlagenes gerichtetes Kanten-Vokabular:
|
||
|
||
| Kante | von → nach | aus Review-Relation |
|
||
|---|---|---|
|
||
| `specializes` | DOMAIN-Obligation → CORE-Obligation | (SUPPORTED_BY, Spezialfall) |
|
||
| `contributes_to` | Obligation → Obligation | (SUPPORTED_BY, Beitrag) |
|
||
| `realized_by` | Obligation → Capability | (SHARED_CAPABILITY ⇒ 2 Obl. teilen 1 Capability) |
|
||
| `deployed_via` | Capability → Procedure | (SHARED_PROCEDURE) |
|
||
| `verified_by` | Procedure/Capability → Control | — |
|
||
| `produces` | Procedure → Evidence | (SHARED_EVIDENCE ⇒ 2 Obl. teilen 1 Nachweis) |
|
||
| `described_by` | Capability → Guidance | (guidance_basis) |
|
||
| `same_as` | Obligation ↔ Obligation | (SAME_OBLIGATION, Merge) |
|
||
|
||
`SHARED_CAPABILITY`/`SHARED_EVIDENCE`/`SHARED_PROCEDURE` sind also **keine Obligation-Obligation-
|
||
Kanten**, sondern Belege, dass zwei Obligations **denselben Knoten einer tieferen Ebene** teilen
|
||
(Capability / Evidence / Procedure). Genau das ist der Mehrwert gegenüber „sieht ähnlich aus".
|
||
|
||
---
|
||
|
||
## 5. Die 8 offenen Fragen (Antwort + Tradeoff)
|
||
|
||
1. **Was ist eine Capability?** Eine implementierbare, regulierungs-agnostische technische Funktion,
|
||
als Einheit baubar/konfigurierbar/testbar (MFA, TLS, Code Signing, Session-Mgmt, Anomaly-Detection).
|
||
2. **Unterschied zur Obligation?** Obligation = rechtliche Pflicht (WAS das Recht verlangt, regulierungs-
|
||
verankert, normativ). Capability = technisches Mittel (WIE man sie erfüllt, agnostisch). n:m.
|
||
3. **Unterschied zum Security Objective?** Ziel = erwünschter Sicherheitszustand (CIA, attack-surface-min);
|
||
Capability = Mittel dorthin. **Empfehlung (Modell C):** das Ziel ist eine CORE Obligation, kein
|
||
eigener Typ → Unterschied reduziert sich auf Obligation(abstrakt) vs Capability(Mittel).
|
||
4. **Wann Guidance?** Wenn es eine **nicht-bindende externe Empfehlung zur Umsetzung** ist (NIST AC-12,
|
||
OWASP ASVS V6). Hängt an der **Capability** (meist) bzw. Procedure — NIE als `legal_basis` einer
|
||
LEGAL_MINIMUM-Obligation (Primärrecht-Regel bleibt).
|
||
5. **Wann Procedure?** Wenn es ein **wiederholbarer operativer Ablauf** ist, der eine Capability
|
||
ausbringt/erhält (MFA konfigurieren, Schlüssel rotieren, Patch-Zyklus fahren).
|
||
6. **Capability → mehrere Obligations?** **JA, belegt:** `mfa` erfüllt 6 Obligations (auth+remote),
|
||
`code_signing` 2 (auth+updates). n:m.
|
||
7. **Obligation → mehrere Capabilities?** **JA, belegt:** access-protection ← mfa + session_management
|
||
+ credential_storage. n:m.
|
||
8. **Wo hängen NIST/OWASP/ENISA/BSI?** Primär an der **Capability** (sie beschreiben deren Umsetzung),
|
||
teils an Procedure. **Das erklärt, warum die über-getierten BP-Obligations `guidance_basis` trugen:
|
||
sie waren in Wahrheit Capabilities.** Sauberer Sitz von `guidance_basis` = Capability.
|
||
|
||
---
|
||
|
||
## 6. Worked Examples (4 Domänen, echte IDs)
|
||
|
||
**Authentication** — `user_authentication_required` (Obl, CORE: access-protection)
|
||
`--realized_by-->` { `mfa`, `session_management`, `credential_storage` } (Capabilities)
|
||
`--described_by-->` NIST IA-2 / OWASP ASVS V6 (Guidance).
|
||
|
||
**Updates** — `provide_security_updates` (Obl, LEGAL_MINIMUM) `--realized_by-->`
|
||
{ `code_signing` (= signed_update_integrity-Capability), `automatic_update_delivery`, `rollback` }
|
||
— exakt die `capability_candidate`-Marker aus `cra_updates.json`.
|
||
|
||
**Remote Access** — CORE `attack_surface_minimization` (NEU, = CM-7-Ziel) `⊇ specializes ⊇`
|
||
`remote_access_attack_surface_min` (DOMAIN) `--realized_by-->` { `least_functionality`, `port_disabling` }.
|
||
|
||
**SBOM** — Sonderfall: die SBOM-Familie ist im Cross-Review der **Evidence-/Procedure-Input** für
|
||
`vuln_identification_inventory` (5× SUPPORTED_BY-Hub), weniger Capability. → bestätigt, dass nicht
|
||
jede Domäne primär Capabilities beisteuert; manche liefern **Evidence**. Stützt den Graph-Charakter.
|
||
|
||
---
|
||
|
||
## 7. Entscheidung, die ich vom User brauche (vor #5b)
|
||
|
||
1. **Modell C** (Capability = einzige neue Klasse; Sicherheitsziele = CORE-Obligations) — akzeptiert?
|
||
Oder Modell B (Security Objective als eigene Klasse für regulierungs-agnostische Vereinheitlichung)?
|
||
2. **Kanten-Vokabular** aus §4 — so einfrieren?
|
||
3. **`guidance_basis` wandert konzeptionell an die Capability** — einverstanden? (Bricht nichts sofort;
|
||
die Obligations behalten den Verweis bis #5b.)
|
||
4. Erst danach **#5b**: `capabilities.json` (capability_id, fulfills_obligations[] via `realized_by`,
|
||
guidance_basis hochgezogen), die 2 CORE-Gap-Obligations, der Merge (`vuln_remediation_patching` ≈
|
||
`provide_security_updates`), und die 2 Remote-Grenzfälle final tiern.
|
||
|
||
## 8. Bewusst NICHT in #5a (gegated)
|
||
|
||
Keine `capabilities.json`, keine Migration, kein Obligation-Rewrite, kein Guidance-Move, kein Runtime.
|
||
Erst Modell-Annahme, dann Daten. „Erst das Schema, dann verschieben."
|