Mēs saskaitījām katru ierobežojumu OSCAL 1.2.2. Visus 348.

Katrs OSCAL validators apgalvo, ka „validē OSCAL”. Gandrīz neviens no tiem nevar pateikt, ko šis teikums nozīmē.

NIST OSCAL modeļi ir veidoti Metaschema valodā: astoņi saknes moduļi un kopīgi importi, tūkstošiem XML rindu, kas definē ne tikai dokumenta formu, bet arī semantiku: atļauto vērtību vārdnīcas, unikalitātes noteikumus, savstarpējo atsauču indeksus, kardinalitātes prasības. JSON Schema notver formu. Taču tieši semantikā atbilstības dokumenti patiesībā kļūdās, un tieši tur „mēs validējam OSCAL” klusi pārvēršas par „mēs validējam daļu OSCAL, neesam pārliecināti, kuru”.

Mēs vēlējāmies būt pārliecināti, kuru daļu. Tāpēc izveidojām savu validatoru tā, kā auditētu sistēmu: sākot no avotiem, uzskaitot visu un atskaitoties par katru atsevišķu vienību.

Standarta piesaiste baitiem

Pirmais lēmums bija vissvarīgākais: autoritāte ir NIST avoti, nevis atsauces implementācija. Mēs piesaistījām usnistgov/OSCAL commit 21403b4a… (v1.2.2), saglabājām kešatmiņā katru Metaschema baitu precīzi ar SHA-256 jaucējvērtībām un uztvērām cienījamo Java OSCAL CLI par to, kas tas patiesībā ir: salīdzināmo objektu, ko pratināt, nevis patiesību, ko kopēt. (Piemēram, tas ietver OSCAL 1.2.1 sasaistes: tas var apstrādāt 1.2.2 dokumentus, bet nevar runāt 1.2.2 valodā.)

Pēc tam mēs leksiski inventarizējām katru ierobežojuma gadījumu piesaistītajos avotos. Nevis ierobežojumu tipus, bet gadījumus, kas identificēti pēc faila un rindas, lai divi ierobežojumi, kuriem nejauši ir vienāds ID, nekad nesaplūstu vienā. Skaits bija 348.

Katra gadījuma pierādīšana

Katram gadījumam mūsu būvējumā jābūt tieši vienam no trim spriedumiem, ko nodrošina ģenerators, kurš katrā palaišanas reizē no jauna aprēķina uzskaites žurnālu:

• Pierādīti īstenoti (303): gadījumam precīzi atbilstošs tests darbina reālo novērtētāju ar minimālu dokumentu un apliecina, ka tika novērtēts tieši šis faila un rindas gadījums. Testa AST ir mašīnverificēts: pārbaudāmajam subjektam jāizpildās tieši vienreiz, tā rezultātam jānonāk tieši vienā apgalvojumā, un testa fails kopā ar tā tranzitīvajiem importiem ir piesaistīts ar jaucējvērtību. Ja maina novērtētāju, pierādījumi noveco, līdz tie tiek atvasināti no jauna.
• Īstenoti ar shēmu (1): pierādāmi aptverti ar laidiena JSON Schema.
• Izslēgti ar pamatojumu (44): skaidri izslēgti, katrs ar rakstisku, pārskatāmu iemeslu.

Neuzskaitīti: nulle.

Tieši pēdējā grupā, izslēgumos, kļuva interesanti.

Standartā ir kļūdas

Pārbaudot 348 ierobežojumus vienu pēc otra, atrodas dažādas lietas. Trīs no mūsu izslēgumiem ir defekti pašos NIST avotos:

• Bāreņa ierobežojums. oscal_mapping-common_metaschema.xml 657. rindā ierobežo karogu, kas definēts piecas rindas iepriekš un pēc tam nekur netiek izmantots. Neviens iespējams dokuments šo karogu nesatur. Ierobežojums nav izpildāms.
• Neiespējams predikāts. Noteikums inventory-item prop nosaukumiem attiecas tikai tad, ja @type ir software, hardware vai service, taču inventory-item vispār nedeklarē type karogu. (Tā kaimiņš asset-id pats avotā ir izkomentēts.) Predikāts nekad nevar atbilst.
• Ierobežojumi komentāros. Pieci ierobežojumu gadījumi atrodas komentāru blokos, ieskaitot veselu vērtību vārdnīcu profila with-child-controls elementam. Cilvēks, kas lasa avotu, tos redz; kompilētā shēma tos nekad neīsteno. Par visiem trim konstatējumiem ir ziņots augšupējam projektam: usnistgov/OSCAL#2254, #2255, #2256.

Un audits darbojās abos virzienos: mūsu pašu novērtētājā bija kļūda, kuras dēļ ierobežojumi, kas vērsti uz karogiem (piemēram, action/@type atļautās vērtības), tika iekļauti inventārā, taču klusi nekad neiedarbojās. Mēs to neatradām nejauši: noslēguma kontrolpunkts atteicās pieņemt pierādījumus šiem diviem gadījumiem, un tieši šo kļūmes veidu visa sistēma ir paredzēta atklāt.

Pēc tam mēs patiešām veicām salīdzinājumu

Apgalvot, ka „atsauces implementācija kaut ko palaiž garām”, balstoties tikai uz avotu pārbaudi, ir tieši tāds nepierādīts apgalvojums, kādu šis projekts ir radīts izskaust. Tāpēc mēs lejupielādējām Java OSCAL CLI 3.2.0 no Maven Central, pārbaudījām tā jaucējvērtību un palaidām abus validatorus ar testa datu kopu, kuras bāzes dokumenti bez kļūdām iziet validāciju abās pusēs, lai katru nesakritību varētu attiecināt uz vienu ievadītu izmaiņu.

OSCAL 1.2.2 papildus versiju numuru maiņai izmainīja tieši divus ierobežojumus (abus SSP modelī). Java CLI, kas ietver 1.2.1 sasaistes, ir nepareizajā pusē katrai novērojamai sekai:

• SSP ar karājošos rel="validation" komponenta saiti pārkāpj 1.2.2. Java: derīgs, izejas kods 0.
• SSP ar karājošos rel="validated-by" saiti saskaņā ar 1.2.2 ir kārtībā (ierobežojums tika dzēsts). Java: nederīgs.
• responsible-role bez neobligātā party-uuid saskaņā ar 1.2.2 ir kārtībā; NIST pievienoja predikātu tieši tāpēc, lai to labotu. Java atgriež kļūdu, burtiski Key reference [null] not found.

Tad viens gadījums, kas vispār nav saistīts ar versiju nobīdi: katalogs, kura metadatu action deklarē "type": "invented-type", kas aizliegts metadatu Metaschema 877. rindā gan 1.2.2, gan Java ietvertajos 1.2.1 avotos. Java to atzīst par derīgu gan JSON, gan XML formātā. Ierobežojums vērsts uz karogu; uz karogiem vērstu ierobežojumu klusa neiedarbošanās ir tieši tā kļūdu klase, ko mūsu pilnīguma kontrolpunkts notvēra mūsu pašu novērtētājā. Atsauces implementācijā ir tās pašas klases kļūda, bet nav noslēguma kontrolpunkta, kas to notvertu. Mēs par to ziņojām augšupējam projektam kā metaschema-framework/oscal-cli#279. (Mēs šo klasi kartējām mehāniski: tieši 2 no 200 atļauto vērtību gadījumiem ir vērsti uz karogiem, un vienīgais kļūdas līmeņa elements ir tas, ko mēs pārbaudījām reālā testā. Nepārbaudīta atlikuma nav.)

Un godīguma moments, jo tests darbojās abos virzienos: mūsu validators noraidīja paša NIST SP 800-53 rev5 katalogu. Divdesmit kļūdas, visas viena defekta dēļ: mūsu indeksu novērtētājs uzskatīja trūkstošu neobligātu atslēgas lauku par pārkāpumu, lai gan Metaschema specifikācija nosaka, ka tā ir null atslēga. Java failu pieņēma; mēs kļūdījāmies; mēs to izlabojām tajā pašā dienā, un 800-53 tiek validēts bez kļūdām. Vēlāk tests notvēra vēl vienu: mēs turpinājām īstenot OSCAL action-type vārdnīcu pat tad, ja action/@system deklarēja pielāgotu URI, tieši tādu organizācijas līmeņa segmentāciju, kādu prasa paša NIST piezīmes. Arī izlabots. Salīdzinošā testēšanas vide, kas vienmēr atrod tikai otras puses kļūdas, nav testēšanas vide, tas ir mārketings.

(Arī sadaļā „abas puses”: neviens no atrisinātājiem semantiski nevalidēja savu izvadi. Java resolve-profile labprāt uzrakstīs katalogu, ko paša Java validate pēc tam noraidīs, un mūsējais darīja to pašu: pārbaudīja shēmu, bet ne semantiku. Mūsējais tagad atsakās rakstīt semantiski nederīgus atrisinājumus; Java joprojām to nespēj, jo šīs spraugas aizvēršanai nepieciešams semantiskais slānis, kuram uzticaties.)

Validēt grafu, ne tikai failu

Otra lieta, kas trūkst esošajos rīkos: OSCAL dokumenti nepastāv atsevišķi. Novērtējuma rezultāts importē novērtējuma plānu, kas importē SSP, kas importē profilu, kas tiek atrisināts pret katalogiem. Modeļa dokumentācija ir pilna ar saistībām, kuras neviens viena faila validators nevar pārbaudīt: „šī konstatējuma mērķim jāatrisinās par paziņojumu bāzes līnijā”, „šim POA&M jāidentificē sava sistēma”.

Tāpēc mēs izveidojām starpdokumentu validāciju, kas patiešām atrisina šīs saites. Palūdziet tai pārbaudīt SSP, un tā atrisina importēto bāzes līniju cauri pilnam (specifikācijas projektā aprakstītajam) profilu atrisināšanas konveijeram līdz pat katalogiem, aprēķina izvēlēto kontroļu kopu un paziņo:

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

Ar vienu būtisku dizaina noteikumu: šīs saistību pārbaudes ir dokumentēta prozas teksta interpretācijas, un mēs tās tā arī uztveram: pēc noklusējuma izslēgtas, brīdinājumi, nevis kļūdas, katra lauka atrisināšanas tvērums piesaistīts tā avota rindai, un viss, kas ir tikai secināms, ir izslēgts pēc nosaukuma. Kur standarts izvairās no viennozīmīga formulējuma, validatoram nevajadzētu blefot. (Mūsu iecienītākais piemērs: POA&M specifikācija nosaka, ka nepieciešams SSP imports vai system-id: „Var būt abi.” Tāpēc mēs brīdinām tikai tad, ja nav neviena. Nekāda izdomāta izslēdzošā VAI.)

Kāpēc TypeScript?

Tāpēc, ka dokumenti dzīvo pārlūkos, bezservera funkcijās, CLI un datubāzēs, un mēs vēlējāmies vienu validatoru tajos visos, nevis JVM blakusprocesu katram no tiem. Validatori ir iepriekš kompilēti Ajv autonomie moduļi: vienkāršs ģenerēts JavaScript, nulle shēmu kompilācijas izpildlaikā, baitu līmenī stabila izvade. Tas pats kods, kas darbina mūsu validācijas virsmas, bez izmaiņām darbojas jūsu pārlūka cilnē un mūsu CLI. Un determinisms nav tikai darbības ērtība: tieši tas vispār padara iespējamus ar jaucējvērtībām piesaistītus pierādījumus.

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

Kur tas mūs noved

• Pilns OSCAL 1.1.2 → 1.2.2 atbalsts, 1.2.2 dabīgā semantika
• Pilnīga profilu atrisināšana saskaņā ar specifikācijas projektu, ar slēgtas kļūmes apstrādi visam, ko projekts atstāj nedefinētu, un atrisinātāju, kas atsakās rakstīt semantiski nederīgu izvadi
• Visa Java CLI ar OSCAL saistītā funkcionalitāte, kā arī grafa validācija, kuras tam nekad nav bijis (validate --resolve-imports --interpretive all)
• Un apgalvojums, ko varat auditēt: 348/348 ierobežojumu gadījumi uzskaitīti mašīnlasāmā uzskaites žurnālā, ko mūsu CI no jauna aprēķina katrā commit

Pilns tehniskais ziņojums (autoritātes modelis, pilnīguma noslēgums, salīdzinošo rezultātu tabula un tas, ko mēs apzināti neapgalvojam) atrodams validatora dokumentācijā. Validators atrodas privātā sagatavošanas vidē pirms atvērtā pirmkoda laidiena; mitinātā validācijas API jau šodien nodrošina shēmas līmeni, un semantiskais slānis sekos.