Suskaičiavome kiekvieną OSCAL 1.2.2 apribojimą. Visus 348.

Kiekvienas OSCAL validatorius teigia, kad „validuoja OSCAL“. Beveik nė vienas negali pasakyti, ką šis sakinys reiškia.

NIST OSCAL modeliai aprašyti Metaschema kalba – aštuoni šakniniai moduliai ir bendri importai, tūkstančiai XML eilučių, apibrėžiančių ne tik dokumento formą, bet ir semantiką: leistinų reikšmių žodynus, unikalumo taisykles, kryžminių nuorodų indeksus, kardinalumo reikalavimus. JSON Schema patikrina formą. Tačiau būtent semantikoje atitikties dokumentuose iš tikrųjų atsiranda klaidų – ir būtent čia „mes validuojame OSCAL“ tyliai virsta „mes validuojame dalį OSCAL, tiksliai nežinome kurią“.

Mes norėjome tiksliai žinoti kurią. Todėl validatorių kūrėme taip, kaip audituotume sistemą: pradėjome nuo šaltinių, viską išvardijome ir atsiskaitėme už kiekvieną elementą.

Standarto fiksavimas baitų tikslumu

Pirmasis sprendimas buvo svarbiausias: autoritetas yra NIST šaltiniai, o ne etaloninė realizacija. Užfiksavome usnistgov/OSCAL ties commit 21403b4a… (v1.2.2), kiekvieną Metaschema failą talpykloje išsaugojome baitų tikslumu su SHA-256 maišos reikšmėmis, o garbingą Java OSCAL CLI vertinome tuo, kuo ji iš tikrųjų yra: palyginimo įrankiu, kurį reikia kryžmiškai patikrinti, o ne tiesa, kurią reikia kopijuoti. (Pirmiausia, ji turi įtrauktas OSCAL 1.2.1 sąsajas – ji gali apdoroti 1.2.2 dokumentus, tačiau negali kalbėti 1.2.2 kalba.)

Tada leksiškai inventorizavome kiekvieną apribojimo atvejį užfiksuotuose šaltiniuose. Ne apribojimų tipus, o atvejus, identifikuojamus pagal failą ir eilutę, kad du apribojimai, kurių ID atsitiktinai sutampa, niekada nesusilietų į vieną. Jų suskaičiavome 348.

Kiekvieno įrodymas

Kiekvienam atvejui mūsų kūrimo procesas turi turėti lygiai vieną iš trijų verdiktų; tai užtikrina generatorius, kuris kiekvieno paleidimo metu iš naujo apskaičiuoja žurnalą:

• Įrodytai užtikrinamas (303): atvejo tikslumo testas paleidžia tikrąjį vertintuvą su minimaliu dokumentu ir patvirtina, kad buvo įvertintas būtent šis failo ir eilutės atvejis. Testo AST tikrinamas mašiniškai – tikrinamasis objektas turi būti įvykdytas lygiai vieną kartą, jo rezultatas turi patekti į lygiai vieną teiginį – o testo failas ir jo tranzityvūs importai užfiksuojami maišos reikšmėmis. Pakeiskite vertintuvą, ir įrodymai pasensta, kol bus išvesti iš naujo.
• Užtikrinamas schemos (1): įrodomai padengtas leidimo JSON Schema.
• Pašalintas su pagrindimu (44): aiškiai neįtrauktas, kiekvienam pateikta rašytinė, peržiūrima priežastis.

Neapskaityta: nulis.

Būtent paskutinė grupė – pašalinimai – pasirodė įdomiausia.

Standartas turi klaidų

Kai 348 apribojimus tikrinate po vieną, kai ką randate. Trys mūsų pašalinimai yra pačių NIST šaltinių defektai:

• Našlaitis apribojimas. oscal_mapping-common_metaschema.xml 657 eilutė apriboja vėliavėlę, apibrėžtą penkiomis eilutėmis anksčiau, – į kurią vėliau niekas nenurodo. Joks galimas dokumentas šios vėliavėlės neturi. Apribojimo neįmanoma įvykdyti.
• Neįmanomas predikatas. Taisyklė inventory-item savybių pavadinimams taikoma tik tada, kai @type yra software, hardware arba service, – tačiau inventory-item iš viso neapibrėžia type vėliavėlės. (Jo kaimynas asset-id šaltinyje pats yra užkomentuotas.) Predikatas niekada negali sutapti.
• Apribojimai komentaruose. Penki apribojimų atvejai yra komentarų blokuose – įskaitant visą profilio with-child-controls reikšmių žodyną. Šaltinį skaitantis žmogus juos mato; sukompiliuota schema jų niekada neužtikrina. Apie visus tris radinius pranešta šaltinio projektui: usnistgov/OSCAL#2254, #2255, #2256.

Auditas kirto į abi puses: mūsų pačių vertintuve buvo klaida, dėl kurios vėliavėles veikiantys apribojimai (pavyzdžiui, leistinos action/@type reikšmės) buvo sukompiliuojami į inventorių, bet tyliai niekada nesuveikdavo. Radome ją ne atsitiktinai – uždarumo vartai atsisakė priimti įrodymus šiems dviem atvejams, o tai ir yra būtent tas gedimo scenarijus, kurį visa sistema sukurta atskleisti.

Tada iš tikrųjų atlikome palyginimą

Teigti, kad „etaloninė realizacija kai ką praleidžia“, remiantis vien šaltinio peržiūra, yra būtent toks neįrodytas teiginys, kurį šis projektas skirtas panaikinti. Todėl atsisiuntėme Java OSCAL CLI 3.2.0 iš Maven Central, patikrinome maišos reikšmę ir abu validatorius paleidome su testinių dokumentų šeima, kurios baziniai dokumentai be klaidų praeina abiejose pusėse, – taigi kiekvieną nesutapimą galima priskirti vienam įterptam pakeitimui.

Be versijų numerių pakeitimų, OSCAL 1.2.2 pakeitė lygiai du apribojimus (abu SSP modelyje). Java CLI, turinti įtrauktas 1.2.1 sąsajas, kiekvienos pastebimos pasekmės atveju yra neteisingoje pusėje:

• SSP su kabančia rel="validation" komponento nuoroda pažeidžia 1.2.2. Java: galiojantis, išėjimo kodas 0.
• SSP su kabančia rel="validated-by" nuoroda pagal 1.2.2 yra tinkamas (apribojimas buvo panaikintas). Java: negaliojantis.
• responsible-role be neprivalomo party-uuid pagal 1.2.2 yra tinkamas – NIST predikatą pridėjo būtent tam, kad tai ištaisytų. Java pateikia klaidą, pažodžiui: Key reference [null] not found.

Toliau – atvejis, visai nesusijęs su versijų neatitikimu: katalogas, kurio metaduomenų action deklaruoja "type": "invented-type" – tai draudžiama metaduomenų Metaschema 877 eilutėje tiek 1.2.2, tiek 1.2.1 šaltiniuose, kuriuos įtraukia Java. Java jį laiko galiojančiu tiek JSON, tiek XML formatu. Apribojimas taikomas vėliavėlei; tyliai nesuveikiantys vėliavėlėms taikomi apribojimai yra būtent ta klaidų klasė, kurią mūsų išsamumo vartai aptiko mūsų pačių vertintuve. Etaloninė realizacija turi tos pačios klasės klaidą – ir neturi uždarumo vartų, kurie ją aptiktų. Apie tai pranešėme šaltinio projektui: metaschema-framework/oscal-cli#279. (Klasę išanalizavome mechaniškai: lygiai 2 iš 200 allowed-values atvejų taikomi vėliavėlėms, o vienintelis klaidos lygio narys yra tas, kurį patikrinome tiesiogiai. Nepatikrinto likučio nėra.)

O dabar sąžiningumo akimirka, nes palyginimas kirto į abi puses: mūsų validatorius atmetė paties NIST SP 800-53 rev5 katalogą. Dvidešimt klaidų, visos dėl vieno defekto – mūsų indekso vertintuvas trūkstamą neprivalomą rakto lauką laikė pažeidimu, nors Metaschema specifikacijoje sakoma, kad tai yra null raktas. Java failą priėmė; klydome mes; ištaisėme tą pačią dieną, ir 800-53 validuojamas be klaidų. Vėliau palyginimas aptiko dar vieną: toliau taikėme OSCAL action-type žodyną net tada, kai action/@system deklaravo pasirinktinį URI – būtent tą kiekvienos organizacijos segmentavimą, kurio reikalaujama paties NIST pastabose. Taip pat ištaisyta. Diferencinio testavimo priemonė, kuri visada randa tik kitos pusės klaidas, nėra testavimo priemonė – tai rinkodara.

(Taip pat priskirtina prie „abiejų pusių“: nė vienas sprendiklis semantiškai nevalidavo savo išvesties. Java resolve-profile mielai įrašys katalogą, kurį paties Java validate vėliau atmes, – ir mūsiškis darė tą patį: tikrino schemą, bet ne semantiką. Mūsiškis dabar atsisako įrašyti semantiškai negaliojančius sprendimus; Java vis dar negali, nes šiai spragai uždaryti reikia semantinio sluoksnio, kuriuo pasitikite.)

Validuojamas grafas, o ne tik failas

Antras dalykas, kurio trūksta esamiems įrankiams: OSCAL dokumentai negyvena atskirai. Vertinimo rezultatas importuoja vertinimo planą, kuris importuoja SSP, kuris importuoja profilį, kuris išsprendžiamas pagal katalogus. Modelio dokumentacijoje gausu ryšių, kurių negali patikrinti joks vieno failo validatorius: „šios išvados taikinys turi būti išsprendžiamas į teiginį bazinėje konfigūracijoje“, „šis POA&M turi identifikuoti savo sistemą“.

Todėl sukūrėme tarpdokumentinį validavimą, kuris šias jungtis iš tikrųjų išsprendžia. Paprašykite jo patikrinti SSP, ir jis importuotą bazinę konfigūraciją per visą (specifikacijos projekto) profilio sprendimo konvejerį išsprendžia iki katalogų, apskaičiuoja pasirinktą kontrolės priemonių rinkinį ir praneša:

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

Su viena esmine projektavimo taisykle: šie ryšių patikrinimai yra dokumentuoto teksto interpretacijos, ir taip juos ir traktuojame – pagal numatytuosius nustatymus išjungti, įspėjimai, o ne klaidos, kiekvieno lauko sprendimo apimtis susieta su jo šaltinio eilute, o viskas, kas tik numanoma, pašalinta įvardijant. Kai standartas išsisukinėja, validatorius neturėtų blefuoti. (Mūsų mėgstamiausias pavyzdys: POA&M specifikacijoje sakoma, kad reikalingas SSP importas arba system-id – „Both may be present.“ Todėl įspėjame tik tada, kai nėra nė vieno. Jokio išgalvoto griežtojo „arba“.)

Kodėl TypeScript?

Todėl, kad dokumentai gyvena naršyklėse, serverless funkcijose, CLI ir duomenų bazėse – o mes norėjome vieno validatoriaus visose jose, o ne JVM pagalbinio proceso šalia kiekvienos. Validatoriai yra iš anksto sukompiliuoti Ajv standalone moduliai: paprastas sugeneruotas JavaScript, jokio schemų kompiliavimo vykdymo metu, baitų tikslumu stabili išvestis. Tas pats kodas, kuris veikia mūsų validavimo paviršiuose, nepakeistas veikia jūsų naršyklės skirtuke ir mūsų CLI. O determinizmas nėra tik eksploatavimo patogumas – būtent jis apskritai įgalina maišos reikšmėmis užfiksuotus įrodymus.

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

Kur tai mus atveda

• Visapusiškas OSCAL 1.1.2 → 1.2.2 palaikymas, natūrali 1.2.2 semantika
• Išsamus profilių sprendimas pagal specifikacijos projektą, saugiai užsiveriantis visais atvejais, kurių projektas neapibrėžia, – ir sprendiklis, atsisakantis įrašyti semantiškai negaliojančią išvestį
• Visas Java CLI su OSCAL susijęs funkcionalumas, ir dar grafo validavimas, kurio ji niekada neturėjo (validate --resolve-imports --interpretive all)
• Ir teiginys, kurį galite audituoti: atsiskaityta už 348/348 apribojimų atvejus mašininiu būdu nuskaitomame žurnale, kurį mūsų CI perskaičiuoja kiekvieno commit metu

Visa techninė ataskaita – autoriteto modelis, išsamumo uždarumas, diferencinių rezultatų lentelė ir tai, ko sąmoningai neteigiame, – pateikiama validatoriaus dokumentacijoje. Validatorius yra privačioje parengiamojoje aplinkoje prieš atvirojo kodo leidimą; talpinama validavimo API šiandien teikia schemos lygmenį, o semantinis sluoksnis bus pridėtas vėliau.