OSCAL-Integration

mjEdit unterstützt den vollständigen OSCAL v1.2.1-Standard mit spezialisierten Editoren für jeden Dokumenttyp.

Alle 8 OSCAL-Dokumenttypen

Das OOP-Prinzip: Komponenten als Klassen, Inventar als Instanzen

mjEdit bildet die OSCAL-Architektur intuitiv ab – angelehnt an objektorientierte Programmierung:

Komponente = Klasse (Blueprint)

"Apache HTTP Server" – Typ: Software, Beschreibung: Webserver

Inventar-Item = Instanz (konkretes Asset)

"Apache 2.4.58 auf Server web-01" – IP: 192.168.1.10, FQDN: web-01.example.com

Im SSP-Tab wird ein Inventar-Item-Dialog geöffnet, im Tab „Komponenten" werden die zugehörigen Software-/Hardware-Bausteine per Multi-Select verknüpft. mjEdit erzeugt automatisch die implemented-components-Referenz mit component-uuid.

Automatische OSCAL-Dokumentketten

Sie müssen Dokumente nicht einzeln erstellen. mjEdit kann die gesamte Compliance-Kette automatisch generieren:

( Katalog (BSI/NIST) → Profil ) → System Security Plan → Assessment Plan → Assessment Results → POA&M

Jeder Schritt übernimmt UUID-Referenzen automatisch, setzt Metadata (Title, Version, last-modified) korrekt und validiert gegen das OSCAL v1.2.1 Schema.

Evidenz-Workflow mit Status-Tracking: SSP → AP → AR

Der Nachweis, dass ein geplanter Beleg tatsächlich geprüft wurde, ist der Kern jeder Auditierbarkeit – und der fehleranfälligste Punkt in der Praxis. mjEdit macht diesen Workflow explizit sichtbar: Drei prominente Tree-Knoten verbinden den System Security Plan, den Assessment Plan und die Assessment Results zu einer lückenlosen Evidenzkette.

Drei Dokumente – drei dedizierte Tree-Knoten

Beim Öffnen eines Assessment-Results lädt mjEdit den verknüpften Assessment Plan automatisch über import-ap.href und gleicht die geplanten Evidenzen aus dem AP-back-matter gegen alle observation.relevant-evidence[].href-Anker im AR ab. Das Ergebnis ist sofort sichtbar: Wie viele der X geplanten Belege wurden bereits dokumentiert?

Ein-Klick-Observation für ausstehende Belege

Statt eine Observation manuell aufzubauen, genügt ein Rechtsklick auf einen ⏳-Knoten im AR-Tab:

„📋 Observation für diese Evidenz erstellen"

mjEdit erzeugt eine vollständige, OSCAL v1.2.1-konforme Observation – mit UUID, collected-Zeitstempel, methods: ["EXAMINE"] und dem schemakonformen Anker:

"relevant-evidence": [
  {
    "href": "#<uuid-der-ap-ressource>",
    "description": "Beleg aus AP-Planung"
  }
]

Optional setzt mjEdit props[name=evidence-source, value=ap] als Herkunftsmarkierung.

Warum ist das so wertvoll?

• Keine Lücken mehr: Das Audit-Team sieht sofort, welche der geplanten Belege noch nicht dokumentiert wurden – ohne manuelle Listen oder Tabellen.
• Automatische OSCAL-Konformität: Die generierten Observations folgen exakt dem NIST-OSCAL-v1.2.1-Schema – relevant-evidence.href als #uuid-Anker ist schemakonform und werkzeugübergreifend verarbeitbar.
• Vollständige Nachvollziehbarkeit: Die Kette SSP (Anforderung) → AP (Planung) → AR (Nachweis) ist direkt aus der Dateistruktur ableitbar – ohne proprietäre Datenbank.
• Cross-Document-Linking: mjEdit lädt den AP beim Öffnen des AR automatisch nach und zeigt den aktuellen Prüfstand in Echtzeit.

Batch-Generierung für Server-Landschaften per KI mittels MCP-Protokoll

Mit oscal_generate_batch_tailored_chain wird für eine Server-Landschaft – z. B. aus 8 Servern – eine komplette Dokumentkette pro System erzeugt:

• 8 Server → 8 Unterverzeichnisse (benannt nach system_id)
• je 6 OSCAL-Dokumente: Profil → Component-Definition → SSP → Assessment Plan → Assessment Results → POA&M
• = 48 validierte Dokumente in einem Aufruf

Pro Server (target) lassen sich u. a. festlegen: System-ID, Name, Beschreibung, Plattform/OS, server-spezifische Control-Auswahl (Tailoring), Schutzniveau (sensitivity_level), Rollen, Parties, Komponenten-Definition, Assessment-Actions sowie inventory_items mit Hostname, FQDN, IPv4/IPv6- und MAC-Adressen. Gemeinsame Felder (shared_roles, shared_parties, shared_sensitivity_level) gelten für alle Systeme und können pro Target überschrieben werden.

Schema-Validierung auf drei Ebenen

Automatische OSCAL-Dokumenten-Heilung

OSCAL-Dokumente entstehen heute aus vielen Quellen: NIST-Beispielen, BSI-Konvertern, KI-Pipelines, älteren Generatoren oder manueller Bearbeitung in einem beliebigen JSON-Editor. Die Folge sind in der Praxis schemawidrige oder veraltete Strukturen – z. B. verbotene Felder wie description auf Statement-Ebene im SSP, fehlende Pflichtfelder wie import-ap im Assessment-Result, Datetime-Werte ohne Zeitzonen-Suffix oder NIST-Pre-1.2.1-Container wie system-interconnections.

mjEdit löst dieses Problem mit einer dokumenttyp-spezifischen, idempotenten Heilungslogik, die jeweils beim Öffnen und beim Speichern automatisch aufgerufen wird:

Warum ist das wichtig?

• Verlustfrei: Inhalte werden migriert, nicht gelöscht. Text aus verbotenen Feldern wandert in semantisch passende Zielstrukturen.
• Idempotent: Mehrfaches Öffnen und Speichern erzeugt identische Ergebnisse.
• Konsistente Validierung: Da die Heilung sowohl beim Open als auch beim Save (und vor jeder manuellen Validierung) läuft, sieht der Validator exakt das, was später in der Datei steht.
• Statistiken im Log: Jede Save-Operation protokolliert, wie viele Felder migriert wurden (z. B. statement_descriptions_migrated: 3, legacy_system_interconnections_migrated: 2).
• Round-Trip-fähig: Migrierte Inhalte erscheinen beim nächsten Öffnen wieder im passenden Dialog.

Empfehlung für „erbliche" OSCAL-Dateien: Ein OSCAL-Dokument aus einem fremden Tool oder einem alten Bestand muss nicht mühsam manuell schema-fix gemacht werden. Einmal in mjEdit öffnen, einmal speichern – fertig. Beim nächsten Schema-Lauf ist es OSCAL v1.2.1-konform.

Vorinstallierte Compliance-Frameworks

• BSI IT-Grundschutz++ (2.128 Controls)
• NIST SP 800-53 (468 Controls)
• BSI-Kriterienkatalog C5 nach Christop Puppe (noch in Arbeit)
• BSI-Kriterienkatalog 200-x Kompendium 2023 nach Christop Puppe (noch in Arbeit)

Mapping-Collection — Offline-KI-gestützt

Das Mapping-Tab ist eines der herausragenden Alleinstellungsmerkmale von mjEdit: Controls aus zwei OSCAL-Dokumenten (Source ↔ Target) werden systematisch aufeinander abgebildet – z. B. NIST SP 800-53 ↔ BSI IT-Grundschutz, C5 ↔ ISO 27001 oder BSI 200-x Kompendium 2023 ↔ BSI IT-Grundschutz++.

Warum ist das so wertvoll?

Ein manuelles Mapping zwischen zwei umfangreichen Control-Katalogen ist eine der zeitaufwändigsten und fehleranfälligsten Aufgaben in der Compliance-Arbeit:

• Ein vollständiges Mapping zwischen z. B. NIST SP 800-53 (468 Controls) und BSI IT-Grundschutz++ (2.128 Controls) bedeutet im Worst Case fast eine Million Paar-Vergleiche – pro Vergleich Lesen, Verstehen, Bewerten, Dokumentieren.
• Ohne Werkzeug rechnet man pro Mapping-Projekt mit mehreren Personenwochen bis -monaten; mit mjEdit + KI-Vorschlägen reduziert sich der Aufwand auf wenige Tage – die Person bewertet nur noch die KI-Vorschläge statt das Rad neu zu erfinden.
• Das Ergebnis ist maschinenlesbar (OSCAL JSON), schema-validiert, versionierbar und über Jahre wiederverwendbar – kein Excel-Friedhof mehr.

Wie arbeitet die KI – und was heißt „offline"?

Die KI-Funktionen laufen vollständig lokal in mjEdit. Es wird ein quelloffenes, multilinguales Sentence-Transformer-Modell (paraphrase-multilingual-MiniLM-L12-v2) verwendet, das beim ersten Aufruf einmalig auf den Rechner geladen und danach offline genutzt wird.

Datenschutz first: Kein Control-Text, kein Katalog und kein Mapping-Vorschlag verlässt jemals den Rechner. Keine Cloud, kein API-Key, keine Token-Kosten – damit auch für hochregulierte Bereiche (BSI, Behörden, KRITIS) einsetzbar.

Auto-Suggest mit vier Methoden

mjEdit bietet im Mapping-Editor einen Knopf „Vorschläge erzeugen". Die Methode lässt sich pro Lauf einstellen:

Zusätzlich:

• Auto-Akzeptanz-Toggle: Vorschläge oberhalb der konfigurierbaren Schwelle (Standard 0,4) werden direkt übernommen – die Person prüft nur noch Grenzfälle.
• Sprachübergreifend: Source auf Deutsch, Target auf Englisch? Das Embedding-Modell beherrscht Cross-Language-Semantik nativ.
• Bulk-Operationen, Schema-Validierung, Markdown-Export für Reviews und Reports.

Beispiele für Mapping-Treffer

Konkreter Use Case: BSI 200-x Kompendium 2023 → BSI IT-Grundschutz++

Aufgabenstellung: „Wie können die Inhalte des bestehenden BSI-IT-Grundschutz-Kompendiums 2023 für den neuen Grundschutz++ einfließen? Welche Inhalte welcher Bausteine sollten in welche Praktiken vom Grundschutz++ übernommen werden – und wo entstehen Lücken?"

Mit mjEdit lässt sich diese Frage in einem klar strukturierten 9-Schritt-Prozess beantworten:

1. Aufgabenstellung präzisieren

Source = BSI 200-x Kompendium 2023 (Bausteine), Target = BSI IT-Grundschutz++ (Praktiken). Geltungsbereich (z. B. nur die Bausteine ORP.* und OPS.*), Schutzbedarfsklassen und Sprachausrichtung festlegen.

2. Source-Katalog zuschneiden

Das vollständige Kompendium 2023 wird in mjEdit als OSCAL-Katalog geöffnet. Über den Katalog-Editor werden Bereiche, die nicht in den Vergleich einfließen sollen (z. B. veraltete Bausteine), markiert.

3. Source-Profil erstellen → resolven → zugeschnittenen Katalog ableiten

• Im Profil-Editor wird ein Source-Profil erstellt: include-controls für die relevanten Bausteine, add-Modifikationen für Anmerkungen/Ergänzungen aus der eigenen Organisation.
• Per Profile-Resolution entsteht ein aufgelöstes Profil (alle Vererbungen, Tailoring-Regeln und Modifikationen sind ausgewertet).
• Daraus wird mit einem Klick ein zugeschnittener Source-Katalog als eigenständige catalog.json exportiert – die saubere Vergleichs-Basis für das Mapping.

4. Target-Katalog zuschneiden

Analog wird der Grundschutz++ Katalog (2.128 Controls) geöffnet und auf den relevanten Praktik-Umfang gefiltert (z. B. nur die Praktiken passend zum Geltungsbereich aus Schritt 1).

5. Target-Profil erstellen → resolven → zugeschnittenen Katalog ableiten

Wie Schritt 3, nur für das Target. Das aufgelöste Target-Profil sorgt dafür, dass Anmerkungen, organisationsspezifische Parameter und Ergänzungen sauber im zugeschnittenen Target-Katalog landen.

6. Mapping-Datei erstellen

Datei → Neu → OSCAL Mapping Collection. Die leere Mapping-Collection bekommt zwei resource-Einträge mit relativen href-Pfaden zu den beiden zugeschnittenen Katalogen aus Schritt 3 und 5.

7. Source- und Target-Katalog im Mapping-Tab auswählen

Im Mapping-Tab werden beide Kataloge geladen. mjEdit zeigt links die Source-Controls, rechts die Target-Controls, in der Mitte die Mapping-Tabelle mit Spalten für Methode, Begründung (matching-rationale), Beziehung (equivalent, subset-of, superset-of, intersects-with) und Statement-Vorschau.

8. Das automatische Mapping

Methode auto auswählen, Schwelle z. B. auf 0,5 setzen, „Vorschläge erzeugen" drücken. mjEdit durchläuft pro Source-Control die Kaskade Semantic → Functional → Syntactic und schreibt für jedes Pärchen den besten Treffer mitsamt Score und Methode in die Tabelle. Mit aktivierter Auto-Akzeptanz wandern Treffer über Schwelle direkt in die Mapping-Collection; alles darunter landet in der Reviewspalte.

Bei z. B. 250 Source- × 350 Target-Controls werden so 87.500 Pärchen-Bewertungen in wenigen Minuten erledigt – ein Aufwand, der manuell nicht leistbar wäre.

9. Ergebnis verwenden – Reports & Folgeartefakte generieren

Aus der fertigen Mapping-Collection lassen sich per Klick automatisch ableiten:

• Resolved Profile (Tailoring auf Basis des Mappings)
• SSP-Vorschlag (System Security Plan mit übernommenen Implementierungen)
• Cross-Reference-Bericht (Markdown/CSV: welcher Source-Control deckt welchen Target-Control)
• Gap-Analyse (welche Target-Praktiken sind durch keine Source abgedeckt → Handlungsbedarf)
• Component-Definition-Stub (wiederverwendbare Komponente mit Mapping-Referenzen)
• POA&M-Stub (für jede Lücke ein Eintrag mit Maßnahmen-Vorschlag)

Welchen Nutzen ziehen die einzelnen Rollen aus dem Mapping?

Kurz: aus einer mehrmonatigen manuellen Excel-Tabelle wird ein reproduzierbarer, KI-gestützter, schema-validierter Workflow von wenigen Tagen – mit prüfbaren Folgeartefakten für die gesamte Compliance-Kette.