Megszámoltuk az OSCAL 1.2.2 összes megkötését. Mind a 348-at.

Minden OSCAL-validátor azt állítja, hogy „validálja az OSCAL-t”. Szinte egyik sem tudja megmondani, mit jelent ez a mondat.

A NIST OSCAL-modelljei Metaschemában készülnek: nyolc gyökérmodul és közös importok, több ezer sornyi XML, amely nemcsak a dokumentum alakját, hanem a szemantikáját is meghatározza: megengedett értékkészleteket, egyediségi szabályokat, kereszthivatkozási indexeket, kardinalitási követelményeket. Egy JSON Schema elkapja az alakot. A megfelelési dokumentumok azonban valójában a szemantikánál csúsznak el, és itt válik csendben a „validáljuk az OSCAL-t” állításból az, hogy „az OSCAL egy részét validáljuk, de nem tudjuk biztosan, melyiket”.

Mi biztosan tudni akartuk, melyik részét. Ezért úgy építettük meg a validátorunkat, ahogyan egy rendszert auditálnánk: a forrásokból indultunk ki, mindent számba vettünk, és minden egyes tétellel elszámoltunk.

A szabvány bájtpontos rögzítése

Az első döntés volt a legfontosabb: a mérvadók a NIST-források, nem a referencia-implementáció. A usnistgov/OSCAL tárolót a 21403b4a… commitnál (v1.2.2) rögzítettük, minden Metaschema-bájtot bájtpontosan, SHA-256-hashekkel gyorsítótáraztunk, és a nagy múltú Java OSCAL CLI-t annak tekintettük, ami valójában: összehasonlítási alapnak, amelyet keresztkérdések alá vetünk, nem pedig másolandó igazságnak. (Többek között OSCAL 1.2.1-es kötéseket tartalmaz: fel tudja dolgozni az 1.2.2-es dokumentumokat, de nem beszéli az 1.2.2-t.)

Ezután lexikálisan leltárba vettük a rögzített forrásokban szereplő összes megkötés-előfordulást. Nem a megkötéstípusokat, hanem az előfordulásokat, fájl és sor szerint azonosítva, hogy két megkötés, amelynek véletlenül azonos az azonosítója, soha ne olvadjon össze. Az eredmény: 348.

Mindegyik bizonyítása

Minden előfordulásra a buildünknek pontosan egy verdiktet kell tartalmaznia a három közül, amit egy generátor kényszerít ki, amely minden futáskor újraszámolja a főkönyvet:

• Bizonyítottan kikényszerítve (303): egy előfordulás-pontos teszt a valódi kiértékelőt futtatja egy minimális dokumentumon, és azt ellenőrzi, hogy ez a fájl-és-sor előfordulás kiértékelésre került. A teszt AST-jét gép ellenőrzi: a vizsgált elemnek pontosan egyszer kell lefutnia, eredményének pontosan egy ellenőrzésbe kell befolynia, a tesztfájl és tranzitív importjai pedig hash-sel rögzítettek. Ha a kiértékelő megváltozik, a bizonyíték elavul, amíg újra elő nem állítják.
• Séma által kikényszerítve (1): bizonyíthatóan lefedi a kiadási JSON Schema.
• Indoklással kizárva (44): kifejezetten kívül esik, mindegyik írásos, felülvizsgálható indoklással.

El nem számolt: nulla.

Az utolsó csoport, a kizárások, volt az, ahol a dolog érdekessé vált.

A szabványban is vannak hibák

Ha 348 megkötést egyenként ellenőriz, talál dolgokat. Kizárásaink közül három magukban a NIST-forrásokban lévő hiba:

• Árva megkötés. Az oscal_mapping-common_metaschema.xml 657. sora egy olyan flaget köt meg, amelyet öt sorral korábban definiálnak, de azután semmi sem hivatkozik rá. Egyetlen lehetséges dokumentum sem hordozza ezt a flaget. A megkötés kielégíthetetlen.
• Lehetetlen predikátum. Az inventory-item prop-neveire vonatkozó szabály csak akkor érvényes, ha a @type értéke software, hardware vagy service, az inventory-item azonban egyáltalán nem deklarál type flaget. (A szomszédja, az asset-id, maga is ki van kommentezve a forrásban.) A predikátum soha nem illeszkedhet.
• Megkötések kommentekben. Öt megkötés-előfordulás kommentblokkokban található, köztük egy teljes értékkészlet a profil with-child-controls eleméhez. Egy ember, aki a forrást olvassa, látja őket; a lefordított séma soha nem kényszeríti ki őket. Mindhárom megállapítást jeleztük a fejlesztőknek: usnistgov/OSCAL#2254, #2255, #2256.

Az audit pedig mindkét irányba vágott: a saját kiértékelőnkben volt egy hiba, amelynek következtében a flageket célzó megkötések (például az action/@type megengedett értékei) bekerültek a leltárba, de csendben soha nem futottak le. Nem szerencsével találtuk meg: a lezárási kapu nem fogadta el a bizonyítékot erre a két előfordulásra, és pontosan ez az a hibamód, amelynek feltárására az egész rendszer készült.

Aztán ténylegesen lefuttattuk az összehasonlítást

Pusztán a forrás vizsgálata alapján azt állítani, hogy „a referencia-implementáció elszalaszt dolgokat”, pontosan az a fajta bizonyítatlan kijelentés, amelynek felszámolására ez a projekt létrejött. Ezért letöltöttük a Java OSCAL CLI 3.2.0-t a Maven Centralról, ellenőriztük a hash-ét, és mindkét validátort lefuttattuk egy olyan tesztdokumentum-családon, amelynek alapdokumentumai mindkét oldalon hibátlanul átmennek, így minden eltérés egyetlen beinjektált változásnak tulajdonítható.

Az OSCAL 1.2.2 a verziószám-emeléseken túl pontosan két megkötést változtatott meg (mindkettőt az SSP-modellben). Az 1.2.1-es kötéseket tartalmazó Java CLI minden megfigyelhető következménynél a rossz oldalon áll:

• Egy SSP, amelyben egy lógó rel="validation" komponenslink van, sérti az 1.2.2-t. Java: érvényes, exit 0.
• Egy SSP, amelyben egy lógó rel="validated-by" link van, az 1.2.2 szerint rendben van (a megkötést törölték). Java: érvénytelen.
• Egy responsible-role az opcionális party-uuid nélkül az 1.2.2 szerint rendben van; a NIST kifejezetten ennek javítására vezette be a predikátumot. A Java szó szerint ezzel a hibával áll le: Key reference [null] not found.

Aztán egy olyan eset, amely egyáltalán nem a verzióeltérésről szól: egy katalógus, amelynek metaadataiban egy action a "type": "invented-type" értéket deklarálja, ami a metadata-Metaschema 877. sora szerint tiltott, mind az 1.2.2-ben, mind a Java által beágyazott 1.2.1-es forrásokban. A Java érvényesnek nyilvánítja, JSON-ban és XML-ben is. A megkötés egy flaget céloz; a flaget célzó megkötések csendes kimaradása pontosan az a hibaosztály, amelyet a teljességi kapunk a saját kiértékelőnkben elkapott. A referencia-implementációban ugyanez a hibaosztály van jelen, és nincs lezárási kapu, amely elkapná. Jeleztük a fejlesztőknek: metaschema-framework/oscal-cli#279. (A hibaosztályt gépiesen feltérképeztük: a 200 allowed-values előfordulásból pontosan 2 céloz flaget, és az egyetlen hiba súlyosságú tag az, amelyet élőben teszteltünk. Nincs teszteletlen maradék.)

És az őszinteség pillanata, mert a futtatás mindkét irányba vágott: a validátorunk elutasította a NIST saját SP 800-53 rev5 katalógusát. Húsz hiba, mind egyetlen defektusból: az indexkiértékelőnk egy hiányzó opcionális kulcsmezőt szabálysértésként kezelt, holott a Metaschema-specifikáció szerint ez null kulcs. A Java elfogadta a fájlt; mi tévedtünk; még aznap javítottuk, és a 800-53 azóta hibátlanul validál. A futtatás később egy másodikat is elkapott: akkor is kikényszerítettük az OSCAL action-type értékkészletét, amikor az action/@system egyéni URI-t deklarált, pedig a NIST saját megjegyzései éppen ezt a szervezetenkénti szegmentálást írják elő. Ezt is javítottuk. Az a differenciális tesztkörnyezet, amely mindig csak a másik oldal hibáit találja meg, nem tesztkörnyezet, hanem marketing.

(Szintén a „mindkét oldal” rovatba tartozik: egyik feloldó sem validálta szemantikailag a saját kimenetét. A Java resolve-profile gond nélkül kiír egy katalógust, amelyet aztán a Java saját validate parancsa elutasít, és a miénk is ugyanezt tette: sémakapuval, de szemantikai kapu nélkül. A miénk most már nem hajlandó szemantikailag érvénytelen feloldásokat kiírni; a Java még mindig nem képes erre, mert ennek a résnek a bezárásához megbízható szemantikai réteg kell.)

A gráf validálása, nem csak a fájlé

A második dolog, ami a meglévő eszközökből hiányzik: az OSCAL-dokumentumok nem önmagukban léteznek. Egy értékelési eredmény importál egy értékelési tervet, amely importál egy SSP-t, amely importál egy profilt, amely katalógusokra oldódik fel. A modell dokumentációja tele van olyan kapcsolatokkal, amelyeket egyetlen egyfájlos validátor sem tud ellenőrizni: „ennek a megállapításnak a célpontja az alapkövetelmény-rendszer egy állítására kell, hogy feloldódjon”, „ennek a POA&M-nek azonosítania kell a rendszerét”.

Ezért olyan dokumentumokon átívelő validálást építettünk, amely ezeket az éleket ténylegesen feloldja. Ha egy SSP ellenőrzését kéri, feloldja az importált alapkövetelmény-rendszert a teljes (tervezet-specifikáció szerinti) profilfeloldási folyamaton keresztül egészen a katalógusokig, kiszámítja a kiválasztott kontrollkészletet, és közli Önnel:

{
  "ruleId": "SSP-003.b",
  "severity": "warning",
  "path": "/…/implemented-requirements/1/control-id",
  "message": "implemented control 'ac-99' is not supplied by the resolved import-profile 'file:///…/baseline.json'"
}

Egy döntő tervezési szabállyal: ezek a kapcsolati ellenőrzések dokumentált szöveges leírások értelmezései, és ennek megfelelően is kezeljük őket: alapértelmezetten ki vannak kapcsolva, figyelmeztetések és nem hibák, minden mező feloldási hatóköre a forrássorához van rögzítve, és mindent, ami csupán kikövetkeztethető, név szerint kizárunk. Ahol a szabvány óvatoskodik, ott egy validátornak nem szabad blöffölnie. (Kedvenc példánk: a POA&M-specifikáció szerint SSP-import vagy system-id szükséges, „Both may be present.” Ezért csak akkor figyelmeztetünk, ha egyik sem létezik. Nincs kitalált kizáró vagy.)

Miért TypeScript?

Mert a dokumentumok böngészőkben, szervermentes függvényekben, CLI-kben és adatbázisokban élnek, és mi egyetlen validátort akartunk mindegyikben, nem pedig mindegyik mellé egy JVM-oldalkocsit. A validátorok előre lefordított önálló Ajv-modulok: egyszerű generált JavaScript, futásidejű sémafordítás nélkül, bájtstabil kimenettel. Ugyanaz a kód, amely a validálási felületeinket működteti, változatlanul fut az Ön böngészőlapján és a CLI-nkben. A determinizmus pedig nem csupán üzemeltetési kényelem: ez teszi egyáltalán lehetővé a hash-sel rögzített bizonyítékokat.

import { createDiagnosticsOscalProcessor } from "@secani/oscal/diagnostics";
const result = createDiagnosticsOscalProcessor({ maxIssues: 50 }).validate(doc);

Hol tartunk

• Teljes 1.1.2 → 1.2.2 OSCAL-támogatás, 1.2.2-natív szemantikával
• Teljes profilfeloldás a tervezet-specifikáció szerint, mindazok biztonságos, elutasító (fail-closed) kezelésével, amit a tervezet nem definiál, valamint egy feloldó, amely nem hajlandó szemantikailag érvénytelen kimenetet kiírni
• A Java CLI teljes OSCAL-felülete, kiegészítve azzal a gráfvalidálással, amely abból mindig is hiányzott (validate --resolve-imports --interpretive all)
• És egy auditálható állítás: 348/348 megkötés-előfordulás elszámolva, egy géppel olvasható főkönyvben, amelyet a CI-unk minden commitnál újraszámol

A teljes műszaki jelentés (a mérvadósági modell, a teljességi lezárás, a differenciális eredmények táblázata, és amit szándékosan nem állítunk) a validátor dokumentációjában található. A validátor egy nyílt forráskódú kiadást megelőzően zárt előkészítő környezetben fut; a hosztolt validálási API már ma elérhetővé teszi a sémaszintet, a szemantikai réteg később következik.