Policzyliśmy wszystkie ograniczenia w OSCAL 1.2.2. Wszystkie 348 z nich.

Każdy walidator OSCAL twierdzi, że „waliduje OSCAL”. Prawie żaden z nich nie jest w stanie powiedzieć, co oznacza to zdanie.

Modele OSCAL NIST są tworzone w Metaschema – osiem modułów głównych plus współdzielone importy, tysiące linii XML, które definiują nie tylko kształt dokumentu, ale semantykę: słowniki dozwolonych wartości, reguły unikalności, indeksy odsyłaczy, wymagania liczności. Schemat JSON łapie kształt. Semantyka polega na tym, że dokumenty dotyczące zgodności faktycznie popełniają błędy – i tam, gdzie „walidujemy OSCAL” po cichu zamienia się w „weryfikujemy część OSCAL, nie jesteśmy pewni, która część”.

Chcieliśmy mieć pewność, która część. Dlatego zbudowaliśmy nasz walidator w taki sam sposób, w jaki audytuje się system: zacznij od źródeł, wylicz wszystko i uwzględnij każdy pojedynczy element.

Przypinanie standardu do bajtów

Pierwsza decyzja była ważna: źródła NIST są autorytetem – a nie implementacją referencyjną. Przypięliśmy usnistgov/OSCAL przy zatwierdzeniu 21403b4a… (v1.2.2), buforował każdy bajt Metaschema z dokładnością do bajtów SHA-256 i traktował czcigodny Java OSCAL CLI takim, jakim jest w rzeczywistości: komparatorem do sprawdzania krzyżowego, a nie prawdą do kopiowania. (Po pierwsze, zawiera powiązania OSCAL 1.2.1 – może przetwarzać dokumenty 1.2.2, ale nie może mówić 1.2.2.)

Następnie leksykalnie zinwentaryzowaliśmy każde wystąpienie ograniczenia w przypiętych źródłach. Nie typy ograniczeń — wystąpienia identyfikowane przez plik i linię, więc dwa ograniczenia, które mają ten sam identyfikator, nigdy nie łączą się w jedno. Liczba wyniosła 348.

Udowodnienie każdego

W przypadku każdego wystąpienia nasza kompilacja musi zawierać dokładnie jeden z trzech werdyktów, wymuszony przez generator, który przelicza księgę przy każdym uruchomieniu:

• Udowodnione wyegzekwowanie (303): test dokładnego wystąpienia prowadzi prawdziwego oceniającego do minimalnego dokumentu i stwierdza, że ​​to wystąpienie pliku i wiersza zostało ocenione. AST testu jest weryfikowane maszynowo – temat musi zostać wykonany dokładnie raz, jego wynik musi wiązać się z dokładnie jedną asercją – a plik testowy wraz z importami przechodnimi są przypinane. Zmień osobę oceniającą, a dowody staną się nieaktualne do czasu ponownego ich uzyskania.
• Wymuszone schematem (1): prawdopodobnie objęte schematem JSON wersji.
• Wyłączone z uzasadnieniem (44): wyraźnie pominięte, każde z pisemnym i możliwym do sprawdzenia powodem.

Nieuwzględnione: zero.

W tym ostatnim segmencie – wykluczeniach – zrobiło się interesująco.

Standard zawiera błędy

Kiedy sprawdzasz 348 ograniczeń jedno po drugim, znajdujesz różne rzeczy. Trzy z naszych wyłączeń to wady samych źródeł NIST:

• Osierocone ograniczenie. oscal_mapping-common_metaschema.xml linia 657 ogranicza flagę, która jest zdefiniowana pięć linii wcześniej – i do której nigdy nic się nie odwołuje. Żaden dokument, który może istnieć, nie ma tej flagi. Ograniczenie jest nie do spełnienia.
• Orzeczenie niemożliwe. Reguła dla inventory-item nazwy właściwości mają zastosowanie tylko wtedy, gdy @type Jest software, hardware, Lub service - Ale inventory-item deklaruje, że nie type flaga w ogóle. (Jego sąsiad, asset-id, jest skomentowany w źródle.) Predykat nigdy nie może się zgadzać.
• Ograniczenia w komentarzach. W blokach komentarzy znajduje się pięć wystąpień ograniczeń – łącznie z całym słownikiem wartości dla profilu with-child-controls. Widzi je człowiek czytający źródło; skompilowany schemat nigdy ich nie wymusza. Wszystkie trzy ustalenia są zgłaszane na wyższym szczeblu łańcucha dostaw: usnistgov/OSCAL#2254, #2255, #2256.

Kontrola zadziałała w obie strony: nasz własny ewaluator napotkał błąd polegający na tym, że ograniczenia dotyczące flag (takich jak dozwolone wartości action/@type) wkompilowano do ekwipunku, ale po cichu nigdy nie odpalono. Nie znaleźliśmy tego przez szczęście – brama zamykająca nie przyjęła dowodów na te dwa zdarzenia, a to jest właśnie tryb awarii, który cały system ma ujawniać.

Następnie przeprowadziliśmy porównanie w rzeczywistości

Twierdzenie, że „realizacja referencyjna pomija pewne rzeczy” na podstawie samej inspekcji źródła, jest dokładnie tym rodzajem niepotwierdzonego twierdzenia, że ​​ten projekt ma zabić. Pobraliśmy więc Java OSCAL CLI 3.2.0 z Maven Central, zweryfikowaliśmy go pod kątem skrótu i ​​sprawdziliśmy oba walidatory na rodzinie urządzeń, których dokumenty bazowe przekazują czysto po obie stronach – więc każdą niezgodę można przypisać jednej wprowadzonej zmianie.

OSCAL 1.2.2 zmienił dokładnie dwa ograniczenia poza zmianami wersji (oba w modelu SSP). Interfejs CLI Java – który zawiera powiązania 1.2.1 – znajduje się po złej stronie wszelkich zauważalnych konsekwencji:

• SSP z wiszącym elementem rel="validation" łącze komponentu narusza 1.2.2. Java: poprawne, wyjdź 0.
• SSP z wiszącym elementem rel="validated-by" link jest w porządku w wersji 1.2.2 (ograniczenie zostało usunięte). Java: nieprawidłowy.
• A responsible-role bez opcjonalnego party-uuid jest w porządku w wersji 1.2.2 – NIST dodał predykat specjalnie, aby to naprawić. Błędy Java z, dosłownie, Key reference [null] not found.

Następnie taki, który w ogóle nie dotyczy przekrzywienia wersji: katalog, którego metadata action deklaruje "type": "invented-type" – zabronione w linii 877 metadanych Metaschema zarówno w źródłach 1.2.2, jak i 1.2.1, w których osadzona jest Java. Java deklaruje, że jest prawidłowy w JSON i XML. Ograniczenie dotyczy flagi; ograniczenia ukierunkowane na flagi, które po cichu nie uruchamiają się, to dokładnie ta klasa błędów, którą nasza bramka kompletności wyłapała w naszym własnym ewaluatorze. Implementacja referencyjna zawiera błędy tej samej klasy – i nie ma bramki zamykającej, która mogłaby je wyłapać. Zgłosiliśmy to w górę rzeki jako metaschema-framework/oscal-cli#279. (Zmapowaliśmy klasę mechanicznie: dokładnie 2 z 200 docelowych flag wystąpień o dozwolonych wartościach, a jedynym członkiem klasy błędów jest ten, który przetestowaliśmy na żywo. Brak nieprzetestowanych pozostałości.)

I zwyciężyła szczerość, ponieważ analiza zadziałała w obie strony: nasz walidator odrzucił własny katalog NIST SP 800-53 rev5. Dwadzieścia błędów, wszystkie jeden defekt — nasz oceniający indeks potraktował brakujące opcjonalne pole klucza jako naruszenie, gdy specyfikacja Metaschema mówi, że jest to klucz zerowy. Java zaakceptowała plik; myliliśmy się; naprawiliśmy to tego samego dnia, a 800-53 potwierdza czystość. Później w tym biegu pojawił się drugi: nadal egzekwowaliśmy słownictwo OSCAL dotyczące typu akcji, nawet gdy action/@system zadeklarowany niestandardowy URI – dokładna segmentacja według organizacji, jakiej wymagają własne uwagi NIST. Również naprawiono. Wiązka mechanizmu różnicowego, która zawsze wykrywa błędy drugiej strony, nie jest wiązką, tylko marketingiem.

(Zamieszczone również w kategorii „obie strony”: żaden z programów rozpoznawania nazw nie sprawdzał semantycznie swoich wyników. Jawa resolve-profile z radością napiszę katalog będący własnością Java validate następnie odrzuca – i nasz zrobił to samo, bramkowany schematem, ale nie semantyką. Nasz teraz odmawia pisania uchwał nieważnych semantycznie; Java nadal nie może, ponieważ zamknięcie tej dziury wymaga zaufanej warstwy semantycznej.)

Walidacja wykresu, a nie tylko pliku

Druga rzecz, której brakuje w istniejącym narzędziu: dokumenty OSCAL nie żyją same. Wynik oceny importuje plan oceny, który importuje SSP, który importuje profil, który jest porównywany z katalogami. Dokumentacja modelu jest pełna relacji, których żaden jednoplikowy walidator nie jest w stanie sprawdzić – „cel tego ustalenia musi zostać przekształcony w instrukcję w linii bazowej”, „ten POA&M musi identyfikować swój system”.

Dlatego stworzyliśmy weryfikację między dokumentami, która naprawdę rozwiązuje te problemy. Poproś go o sprawdzenie SSP, a on rozwiąże zaimportowaną linię bazową poprzez pełny potok rozpoznawania profili (w wersji roboczej) aż do katalogów, obliczy wybrany zestaw kontrolny i poinformuje Cię:

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

Z jedną kluczową zasadą projektowania: te kontrole relacji są interpretacjami udokumentowanej prozy i tak je traktujemy – domyślnie wyłączone, ostrzeżenia, a nie błędy, zakres rozdzielczości każdego pola przypięty do linii źródłowej i wszystko, co jest jedynie wywnioskowane wykluczone z nazwy. Tam, gdzie stosuje się standardowe zabezpieczenia, walidator nie powinien blefować. (Nasz ulubiony przykład: specyfikacja POA&M mówi, że wymagany jest import SSP lub identyfikator systemowy – „Obydwa mogą być obecne”. Dlatego ostrzegamy tylko wtedy, gdy żadne nie istnieje. Nie wymyślono wyłączności-lub.)

Dlaczego TypeScript?

Ponieważ dokumenty znajdują się w przeglądarkach, funkcjach bezserwerowych, interfejsach CLI i bazach danych – a chcieliśmy mieć jeden walidator w każdym z nich, a nie przyczepkę JVM obok każdego. Walidatorami są prekompilowane, samodzielne moduły Ajv: zwykły generowany JavaScript, kompilacja schematu o zerowym czasie wykonywania, wyjście stabilne w bajtach. Ten sam kod, który obsługuje nasze powierzchnie walidacyjne, działa niezmieniony na karcie przeglądarki i w naszym interfejsie wiersza polecenia. A determinizm to nie tylko fanaberia operacyjna – to właśnie dzięki niemu w ogóle możliwe są dowody przypięte hashem.

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

Gdzie to ląduje

• Pełna obsługa OSCAL 1.1.2 → 1.2.2, semantyka natywna 1.2.2
• Pełna rozdzielczość profilu zgodnie ze specyfikacją wersji roboczej, z zamkniętą obsługą wszystkiego, co wersja robocza pozostawia niezdefiniowaną – i funkcją rozpoznawania nazw, która odmawia zapisywania semantycznie nieprawidłowych danych wyjściowych
• Cała powierzchnia interfejsu Java CLI skierowana do OSCAL plus walidacja wykresu, której nigdy nie miała (validate --resolve-imports --interpretive all)
• Oraz roszczenie, które możesz sprawdzić: 348/348 uwzględniono wystąpienia ograniczeń w czytelnej maszynowo księdze, nasz CI przelicza przy każdym zatwierdzeniu

Pełny raport techniczny – model autorytetu, zamknięcie kompletności, tabela wpływów różnicowych i to, czego celowo nie twierdzimy – żyje w dokumentacja walidatora. Walidator znajduje się w fazie prywatnej przed wydaniem oprogramowania typu open source; the hostowany interfejs API walidacji eksponuje dzisiejszy poziom schematu, a następnie warstwę semantyczną.