Loendasime OSCAL 1.2.2 iga piirangu. Neid on kokku 348.

Iga OSCAL-i validaator väidab, et ta „valideerib OSCAL-i“. Peaaegu ükski neist ei oska öelda, mida see lause tähendab.

NIST-i OSCAL-i mudelid on kirjutatud Metaschemas – kaheksa juurmoodulit pluss ühised impordid, tuhandeid ridu XML-i, mis määratlevad mitte ainult dokumendi kuju, vaid ka semantika: lubatud väärtuste sõnavarad, unikaalsusreeglid, ristviidete indeksid, kardinaalsusnõuded. JSON Schema tabab kuju. Semantika on aga koht, kus vastavusdokumendid tegelikult valesti lähevad – ja kus „me valideerime OSCAL-i“ muutub vaikselt lauseks „me valideerime osa OSCAL-ist, me pole kindlad, millist osa“.

Meie tahtsime kindlalt teada, millist osa. Seega ehitasime oma validaatori nii, nagu auditeeritakse süsteemi: alustada lähtefailidest, loetleda kõik üles ja arvestada iga üksikut elementi.

Standardi fikseerimine baidi täpsusega

Esimene otsus oli kõige olulisem: autoriteet on NIST-i lähtefailid, mitte viiteimplementatsioon. Fikseerisime usnistgov/OSCAL kommitil 21403b4a… (v1.2.2), salvestasime iga Metaschema baidi täpsusega SHA-256 räsidega vahemällu ja käsitlesime auväärset Java OSCAL CLI-d selle järgi, mis see tegelikult on: võrdlusalus, mida ristküsitleda, mitte tõde, mida kopeerida. (Muu hulgas sisaldab see OSCAL 1.2.1 sidumisi – see suudab 1.2.2 dokumente töödelda, kuid ei oska rääkida 1.2.2 keelt.)

Seejärel inventeerisime leksikaalselt fikseeritud lähtefailide iga piiranguesinemise. Mitte piirangu tüüpe, vaid esinemisi, mis on tuvastatud faili ja rea järgi, nii et kaks piirangut, millel juhtumisi on sama ID, ei sulandu kunagi üheks. Kokku tuli 348.

Igaühe tõendamine

Iga esinemise kohta peab meie build hoidma täpselt üht kolmest otsusest; seda jõustab generaator, mis arvutab registri igal käivitusel uuesti:

• Tõendatult jõustatud (303): esinemistäpne test käitab päris hindajat minimaalsel dokumendil ja kinnitab, et hinnati just seda faili ja rea esinemist. Testi AST on masinkontrollitud – testitav peab käivituma täpselt üks kord, selle tulemus peab jõudma täpselt ühte väitesse – ning testifail koos selle transitiivsete importidega on räsiga fikseeritud. Muutke hindajat ja tõend aegub, kuni see on uuesti tuletatud.
• Skeemiga jõustatud (1): tõendatavalt kaetud väljalaske JSON Schemaga.
• Põhjendusega välistatud (44): selgesõnaliselt välja jäetud, igaühel kirjalik ja ülevaadatav põhjendus.

Arvestamata: null.

Just see viimane rühm – välistused – osutus huvitavaks.

Standardis on vead

Kui kontrollite 348 piirangut ükshaaval, leiate asju. Kolm meie välistust on vead NIST-i lähtefailides endis:

• Orvuks jäänud piirang. oscal_mapping-common_metaschema.xml rida 657 piirab lippu, mis on määratletud viis rida varem – ja millele seejärel mitte miski ei viita. Ükski olemas olla võiv dokument seda lippu ei kanna. Piirangut on võimatu täita.
• Võimatu predikaat. inventory-item omaduste nimede reegel kehtib ainult siis, kui @type on software, hardware või service – kuid inventory-item ei deklareeri üldse type lippu. (Selle naaber asset-id on lähtefailis ise välja kommenteeritud.) Predikaat ei saa kunagi sobituda.
• Piirangud kommentaaride sees. Viis piiranguesinemist asuvad kommentaariplokkide sees – sealhulgas terve väärtuste sõnavara profiili with-child-controls jaoks. Lähtefaili lugev inimene näeb neid; kompileeritud skeem ei jõusta neid kunagi. Kõigist kolmest leiust on teatatud ülesvoolu: usnistgov/OSCAL#2254, #2255, #2256.

Ja audit lõikas mõlemat pidi: meie enda hindajas oli viga, mille tõttu lippudele suunatud piirangud (näiteks action/@type lubatud väärtused) kompileeriti inventari, kuid ei käivitunud kunagi, ilma et sellest märku antaks. Me ei leidnud seda juhuslikult – sulundivärav keeldus nende kahe esinemise tõendeid vastu võtmast, mis on täpselt see tõrkeviis, mille paljastamiseks kogu süsteem on loodud.

Seejärel tegime päris võrdluse

Väide „viiteimplementatsioon jätab asju vahele“ üksnes lähtefailide uurimise põhjal on täpselt selline tõendamata väide, mille kaotamiseks see projekt on olemas. Seega laadisime Maven Centralist alla Java OSCAL CLI 3.2.0, kontrollisime selle räsi ja käitasime mõlemat validaatorit testandmete perekonnal, mille lähtedokumendid läbivad kontrolli puhtalt mõlemal poolel – nii et iga lahknevuse saab omistada ühele sisestatud muudatusele.

OSCAL 1.2.2 muutis lisaks versiooninumbrite tõstmisele täpselt kahte piirangut (mõlemad SSP mudelis). Java CLI – mis sisaldab 1.2.1 sidumisi – on iga jälgitava tagajärje puhul valel poolel:

• SSP, millel on rippuv rel="validation" komponendilink, rikub versiooni 1.2.2. Java: kehtiv, väljumiskood 0.
• SSP, millel on rippuv rel="validated-by" link, on 1.2.2 järgi korras (piirang kustutati). Java: kehtetu.
• responsible-role ilma valikulise party-uuid-ta on 1.2.2 järgi korras – NIST lisas predikaadi spetsiaalselt selle parandamiseks. Java annab vea sõna-sõnalt Key reference [null] not found.

Seejärel üks, mis ei puuduta üldse versioonide nihet: kataloog, mille metaandmete action deklareerib "type": "invented-type" – keelatud metaandmete Metaschema real 877 nii 1.2.2-s kui ka Javasse põimitud 1.2.1 lähtefailides. Java kuulutab selle kehtivaks nii JSON-is kui ka XML-is. Piirang on suunatud lipule; lippudele suunatud piirangute vaikne mittekäivitumine on täpselt see veaklass, mille meie täielikkuse värav meie enda hindajas tabas. Viiteimplementatsioonis on sama klassi viga – ja pole sulundiväravat, mis selle tabaks. Teatasime sellest ülesvoolu: metaschema-framework/oscal-cli#279. (Kaardistasime klassi mehaaniliselt: 200 lubatud väärtuste esinemisest on lippudele suunatud täpselt 2 ja ainus veataseme liige on see, mida me reaalajas testisime. Testimata jääki pole.)

Ja ausushetk, sest käivitus lõikas mõlemat pidi: meie validaator lükkas tagasi NIST-i enda SP 800-53 rev5 kataloogi. Kakskümmend viga, kõik üks defekt – meie indeksihindaja käsitles puuduvat valikulist võtmevälja rikkumisena, kuigi Metaschema spetsifikatsioon ütleb, et see on null-võti. Java aktsepteeris faili; meie eksisime; parandasime selle samal päeval ja 800-53 valideerub puhtalt. Hiljem tabas käivitus teisegi: jõustasime jätkuvalt OSCAL-i toimingutüüpide sõnavara ka siis, kui action/@system deklareeris kohandatud URI – täpselt sellise organisatsioonipõhise segmenteerimise, mida NIST-i enda märkused nõuavad. Samuti parandatud. Võrdlusraamistik, mis leiab alati ainult teise poole vigu, ei ole raamistik, vaid turundus.

(Samuti kategoorias „mõlemad pooled“: kumbki lahendaja ei valideerinud oma väljundit semantiliselt. Java resolve-profile kirjutab rõõmuga kataloogi, mille Java enda validate seejärel tagasi lükkab – ja meie oma tegi sama, skeemiväravaga, kuid ilma semantikaväravata. Meie oma keeldub nüüd semantiliselt kehtetuid lahendusi kirjutamast; Java ei saa seda endiselt teha, sest selle augu sulgemine nõuab semantilist kihti, mida usaldate.)

Graafi valideerimine, mitte ainult faili

Teine asi, mis olemasolevatest tööriistadest puudub: OSCAL-i dokumendid ei ela üksi. Hindamistulemus impordib hindamiskava, mis impordib SSP, mis impordib profiili, mis lahendatakse kataloogide alusel. Mudeli dokumentatsioon on täis seoseid, mida ükski ühe faili validaator ei saa kontrollida – „selle leiu sihtmärk peab lahenduma lähtetaseme väiteks“, „see POA&M peab tuvastama oma süsteemi“.

Seega ehitasime dokumendiülese valideerimise, mis need servad päriselt lahendab. Paluge sellel SSP-d kontrollida ja see lahendab imporditud lähtetaseme läbi täieliku (spetsifikatsiooni mustandi kohase) profiililahenduse ahela kuni kataloogideni, arvutab valitud kontrollimeetmete kogumi ja ütleb teile:

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

Ühe olulise disainireegliga: need seosekontrollid on dokumenteeritud proosa tõlgendused ja me käsitleme neid sellistena – vaikimisi välja lülitatud, hoiatused, mitte vead, iga välja lahendusulatus on fikseeritud selle lähtereale ning kõik, mis on vaid tuletatav, on nimeliselt välja jäetud. Kus standard jätab ukse lahti, ei tohiks validaator blufida. (Meie lemmiknäide: POA&M-i spetsifikatsioon ütleb, et vaja on SSP importi või system-id-d – „Both may be present.“ Seega hoiatame ainult siis, kui kumbagi pole. Ei mingit väljamõeldud välistavat või-d.)

Miks TypeScript?

Sest dokumendid elavad brauserites, serverivabades funktsioonides, CLI-des ja andmebaasides – ja me tahtsime neis kõigis üht validaatorit, mitte JVM-i kõrvalteenust igaühe kõrval. Validaatorid on eelkompileeritud Ajv standalone-moodulid: tavaline genereeritud JavaScript, null skeemikompileerimist käitusajal, baidistabiilne väljund. Sama kood, mis toetab meie valideerimisliideseid, töötab muutmata kujul nii teie brauseri vahekaardil kui ka meie CLI-s. Ja determinism ei ole ainult käitusmugavus – just see teeb räsiga fikseeritud tõendid üldse võimalikuks.

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

Kuhu see jõuab

• Täielik OSCAL 1.1.2 → 1.2.2 tugi, 1.2.2-põhine semantika
• Täielik profiililahendus spetsifikatsiooni mustandi järgi, kus kõike, mida mustand jätab määratlemata, käsitletakse turvaliselt keeldudes – ja lahendaja, mis keeldub semantiliselt kehtetut väljundit kirjutamast
• Java CLI kogu OSCAL-iga seotud funktsionaalsus pluss graafi valideerimine, mida sellel kunagi polnud (validate --resolve-imports --interpretive all)
• Ja väide, mida saate auditeerida: 348/348 piiranguesinemist arvestatud masinloetavas registris, mille meie CI iga kommitiga uuesti arvutab

Täielik tehniline aruanne – autoriteedimudel, täielikkuse sulund, võrdluse tulemuste tabel ja see, mida me teadlikult ei väida – asub validaatori dokumentatsioonis. Validaator on enne avatud lähtekoodiga väljalaset privaatses testkeskkonnas; hostitud valideerimise API pakub juba täna skeemitaset ning semantiline kiht järgneb.