Spočítali sme každé obmedzenie v OSCAL 1.2.2. Všetkých 348.

Každý validátor OSCAL tvrdí, že „validuje OSCAL“. Takmer žiadny z nich vám nedokáže povedať, čo táto veta znamená.

Modely OSCAL od NIST sú napísané v Metaschema: osem koreňových modulov plus zdieľané importy, tisíce riadkov XML, ktoré definujú nielen tvar dokumentu, ale aj jeho sémantiku: povolené slovníky hodnôt, pravidlá jedinečnosti, indexy krížových odkazov, požiadavky na kardinalitu. JSON Schema zachytí tvar. Sémantika je však miesto, kde sa dokumenty o súlade skutočne pokazia, a kde sa z „validujeme OSCAL“ potichu stáva „validujeme časť OSCAL, nie sme si istí ktorú“.

My sme si chceli byť istí, ktorú časť. Preto sme náš validátor vybudovali tak, ako by ste auditovali systém: začať od zdrojov, všetko vymenovať a zodpovedať sa za každú jednu položku.

Ukotvenie normy na úroveň bajtov

Prvé rozhodnutie bolo to najdôležitejšie: autoritou sú zdroje NIST, nie referenčná implementácia. Repozitár usnistgov/OSCAL sme ukotvili na commite 21403b4a… (v1.2.2), každú Metaschema sme bajtovo presne uložili do cache s hashmi SHA-256 a ctihodné Java OSCAL CLI sme považovali za to, čím skutočne je: za porovnávací nástroj, ktorý treba podrobiť krížovému výsluchu, nie za pravdu, ktorú treba kopírovať. (Okrem iného obsahuje väzby na OSCAL 1.2.1: dokumenty 1.2.2 dokáže spracovať, ale 1.2.2 nehovorí.)

Potom sme lexikálne zinventarizovali každý výskyt obmedzenia v ukotvených zdrojoch. Nie typy obmedzení, ale výskyty, identifikované súborom a riadkom, aby sa dve obmedzenia, ktoré náhodou zdieľajú ID, nikdy nezlúčili do jedného. Napočítali sme ich 348.

Preukázanie každého z nich

Pre každý výskyt musí náš build mať práve jeden z troch verdiktov, čo vynucuje generátor, ktorý pri každom behu prepočíta účtovnú knihu:

• Preukázateľne vynútené (303): test presný na úroveň výskytu spustí skutočný evaluátor nad minimálnym dokumentom a overí, že bol vyhodnotený práve tento výskyt v danom súbore a riadku. AST testu je strojovo overený (testovaný subjekt sa musí vykonať práve raz a jeho výsledok musí smerovať práve do jedného overenia) a testovací súbor spolu s jeho tranzitívnymi importmi je ukotvený hashom. Keď zmeníte evaluátor, dôkaz zastará, kým sa znovu neodvodí.
• Vynútené schémou (1): preukázateľne pokryté vydanou JSON Schema.
• Vylúčené so zdôvodnením (44): explicitne vyňaté, každé s písomným, preskúmateľným dôvodom.

Nezohľadnené: nula.

Práve posledná skupina, teda výluky, sa ukázala ako zaujímavá.

Norma má chyby

Keď kontrolujete 348 obmedzení jedno po druhom, nájdete veci. Tri z našich výluk sú chyby v samotných zdrojoch NIST:

• Osirelé obmedzenie. oscal_mapping-common_metaschema.xml na riadku 657 obmedzuje flag, ktorý je definovaný o päť riadkov skôr a potom naň už nič neodkazuje. Žiadny dokument, ktorý môže existovať, tento flag nenesie. Obmedzenie je nesplniteľné.
• Nemožný predikát. Pravidlo pre názvy vlastností inventory-item sa uplatňuje iba vtedy, keď je @type software, hardware alebo service, ale inventory-item žiadny flag type vôbec nedeklaruje. (Jeho sused, asset-id, je v zdroji sám zakomentovaný.) Predikát sa nikdy nemôže zhodovať.
• Obmedzenia v komentároch. Päť výskytov obmedzení sa nachádza v blokoch komentárov vrátane celého slovníka hodnôt pre profil with-child-controls. Človek, ktorý číta zdroj, ich vidí; skompilovaná schéma ich nikdy nevynucuje. Všetky tri zistenia sme nahlásili upstream: usnistgov/OSCAL#2254, #2255, #2256.

A audit fungoval oboma smermi: náš vlastný evaluátor mal chybu, pri ktorej sa obmedzenia zamerané na flagy (napríklad povolené hodnoty action/@type) skompilovali do inventára, ale potichu sa nikdy nespustili. Nenašli sme ju náhodou: brána uzáveru odmietla prijať dôkazy pre tieto dva výskyty, čo je presne ten spôsob zlyhania, ktorý má celý systém odhaľovať.

Potom sme naozaj spustili porovnanie

Tvrdiť, že „referenčná implementácia niečo prehliada“, len na základe kontroly zdrojov, je presne ten druh nepreukázaného tvrdenia, s ktorým tento projekt chce skoncovať. Preto sme stiahli Java OSCAL CLI 3.2.0 z Maven Central, overili jeho hash a spustili oba validátory nad rodinou testovacích dokumentov, ktorých základné dokumenty bez problémov prechádzajú na oboch stranách, takže každý nesúlad možno pripísať jednej vloženej zmene.

OSCAL 1.2.2 zmenil okrem zvýšenia verzií presne dve obmedzenia (obe v modeli SSP). Java CLI, ktoré obsahuje väzby na 1.2.1, je pri každom pozorovateľnom dôsledku na nesprávnej strane:

• SSP s visiacim odkazom na komponent rel="validation" porušuje 1.2.2. Java: platné, exit 0.
• SSP s visiacim odkazom rel="validated-by" je podľa 1.2.2 v poriadku (obmedzenie bolo odstránené). Java: neplatné.
• responsible-role bez voliteľného party-uuid je podľa 1.2.2 v poriadku; NIST pridal predikát práve na opravu tohto prípadu. Java skončí chybou, doslova Key reference [null] not found.

Potom jeden prípad, ktorý s rozdielom verzií vôbec nesúvisí: katalóg, ktorého metadáta action deklarujú "type": "invented-type", čo je zakázané na riadku 877 metadátovej Metaschema v 1.2.2 aj v zdrojoch 1.2.1, ktoré Java obsahuje. Java ho vyhlási za platný, v JSON aj v XML. Obmedzenie je zamerané na flag; obmedzenia zamerané na flagy, ktoré sa potichu nespúšťajú, sú presne tou triedou chýb, ktorú naša brána úplnosti zachytila v našom vlastnom evaluátore. Referenčná implementácia má rovnakú triedu chyby, a žiadnu bránu uzáveru, ktorá by ju zachytila. Nahlásili sme ju upstream ako metaschema-framework/oscal-cli#279. (Triedu sme zmapovali mechanicky: presne 2 z 200 výskytov allowed-values sú zamerané na flagy a jediný člen s úrovňou chyby je ten, ktorý sme otestovali naživo. Žiadny neotestovaný zvyšok.)

A teraz úprimnosť, pretože beh fungoval oboma smermi: náš validátor odmietol vlastný katalóg NIST SP 800-53 rev5. Dvadsať chýb, všetky z jednej príčiny: náš evaluátor indexov považoval chýbajúce voliteľné pole kľúča za porušenie, hoci špecifikácia Metaschema hovorí, že ide o nulový kľúč. Java súbor prijala; mýlili sme sa my; opravili sme to ešte v ten istý deň a 800-53 sa teraz validuje bez chýb. Beh neskôr zachytil aj druhú chybu: slovník typov akcií OSCAL sme naďalej vynucovali, aj keď action/@system deklaroval vlastné URI, čo je presne tá segmentácia podľa organizácie, ktorú požadujú poznámky samotného NIST. Tiež opravené. Diferenciálny testovací nástroj, ktorý vždy nájde iba chyby druhej strany, nie je testovací nástroj, ale marketing.

(Aj do kategórie „obe strany“: ani jeden resolver sémanticky nevalidoval svoj vlastný výstup. resolve-profile v Jave pokojne zapíše katalóg, ktorý potom vlastné validate v Jave odmietne, a ten náš robil to isté: kontroloval schému, ale nie sémantiku. Ten náš teraz odmieta zapisovať sémanticky neplatné rozlíšenia; Java to stále nedokáže, pretože uzavretie tejto diery si vyžaduje sémantickú vrstvu, ktorej dôverujete.)

Validácia grafu, nielen súboru

Druhá vec, ktorá existujúcim nástrojom chýba: dokumenty OSCAL nežijú osamote. Výsledok posúdenia importuje plán posúdenia, ktorý importuje SSP, ktorý importuje profil, ktorý sa rozlišuje voči katalógom. Dokumentácia modelov je plná vzťahov, ktoré žiadny validátor jedného súboru nedokáže skontrolovať: „cieľ tohto zistenia sa musí rozlíšiť na vyhlásenie v baseline“, „tento POA&M musí identifikovať svoj systém“.

Preto sme vybudovali validáciu naprieč dokumentmi, ktorá tieto hrany naozaj rozlišuje. Požiadajte ju o kontrolu SSP a ona rozlíši importovanú baseline cez úplný pipeline rozlíšenia profilov (podľa návrhu špecifikácie) až po katalógy, vypočíta vybranú množinu opatrení a povie vám:

{
  "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'"
}

S jedným kľúčovým pravidlom návrhu: tieto kontroly vzťahov sú interpretáciami zdokumentovaného textu a tak s nimi aj zaobchádzame. Sú predvolene vypnuté, sú to upozornenia, nie chyby, rozsah rozlíšenia každého poľa je ukotvený na jeho zdrojový riadok a všetko, čo je len odvoditeľné, je menovite vylúčené. Tam, kde sa norma vyjadruje opatrne, by validátor nemal blufovať. (Náš obľúbený príklad: špecifikácia POA&M hovorí, že sa vyžaduje import SSP alebo system-id, „Both may be present.“ Preto upozorňujeme iba vtedy, keď neexistuje ani jedno. Žiadne vymyslené výlučné alebo.)

Prečo TypeScript?

Pretože dokumenty žijú v prehliadačoch, serverless funkciách, CLI a databázach, a my sme chceli vo všetkých z nich jeden validátor, nie JVM sidecar vedľa každého. Validátory sú predkompilované samostatné moduly Ajv: čistý generovaný JavaScript, nulová kompilácia schém za behu, bajtovo stabilný výstup. Ten istý kód, ktorý poháňa naše validačné rozhrania, beží bez zmeny vo vašej karte prehliadača aj v našom CLI. A determinizmus nie je len prevádzková vymoženosť: práve vďaka nemu sú dôkazy ukotvené hashom vôbec možné.

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

Kam to smeruje

• Úplná podpora OSCAL 1.1.2 → 1.2.2, natívna sémantika 1.2.2
• Kompletné rozlíšenie profilov podľa návrhu špecifikácie s fail-closed zaobchádzaním so všetkým, čo návrh ponecháva nedefinované, a resolver, ktorý odmieta zapisovať sémanticky neplatný výstup
• Celé rozhranie Java CLI týkajúce sa OSCAL plus validácia grafu, ktorú nikdy nemalo (validate --resolve-imports --interpretive all)
• A tvrdenie, ktoré môžete auditovať: 348/348 výskytov obmedzení zohľadnených v strojovo čitateľnej účtovnej knihe, ktorú naše CI prepočíta pri každom commite

Úplná technická správa (model autority, uzáver úplnosti, tabuľka dôkazov z diferenciálneho porovnania a to, čo zámerne netvrdíme) sa nachádza v dokumentácii validátora. Validátor je v súkromnom testovacom prostredí pred vydaním ako open source; hostované validačné API dnes sprístupňuje úroveň schémy a sémantická vrstva bude nasledovať.