Μετρήσαμε κάθε περιορισμό του OSCAL 1.2.2. Και τους 348.

Κάθε validator OSCAL ισχυρίζεται ότι «επικυρώνει OSCAL». Σχεδόν κανένας δεν μπορεί να σας πει τι σημαίνει αυτή η πρόταση.

Τα μοντέλα OSCAL του NIST είναι γραμμένα σε Metaschema – οκτώ ριζικές μονάδες συν κοινές εισαγωγές, χιλιάδες γραμμές XML που ορίζουν όχι μόνο τη μορφή των εγγράφων αλλά και τη σημασιολογία τους: επιτρεπόμενα λεξιλόγια τιμών, κανόνες μοναδικότητας, ευρετήρια διασταυρούμενων αναφορών, απαιτήσεις πληθικότητας. Ένα JSON Schema πιάνει τη μορφή. Η σημασιολογία είναι εκεί όπου τα έγγραφα συμμόρφωσης πραγματικά στραβώνουν – και εκεί όπου το «επικυρώνουμε OSCAL» γίνεται σιωπηρά «επικυρώνουμε ένα μέρος του OSCAL, δεν είμαστε σίγουροι ποιο».

Θέλαμε να είμαστε σίγουροι ποιο. Γι' αυτό χτίσαμε τον validator μας όπως θα ελέγχατε ένα σύστημα: ξεκινάμε από τις πηγές, απαριθμούμε τα πάντα και λογοδοτούμε για κάθε μεμονωμένο στοιχείο.

Καρφώνοντας το πρότυπο μέχρι το τελευταίο byte

Η πρώτη απόφαση ήταν η σημαντική: η αυθεντία είναι οι πηγές του NIST – όχι η υλοποίηση αναφοράς. Καρφώσαμε το usnistgov/OSCAL στο commit 21403b4a… (v1.2.2), αποθηκεύσαμε κάθε byte του Metaschema ακριβώς, με hashes SHA-256, και αντιμετωπίσαμε το σεβάσμιο Java OSCAL CLI ως αυτό που πραγματικά είναι: ένα μέτρο σύγκρισης προς εξέταση, όχι μια αλήθεια προς αντιγραφή. (Ενσωματώνει bindings του OSCAL 1.2.1, μεταξύ άλλων – μπορεί να επεξεργάζεται έγγραφα 1.2.2, αλλά δεν μιλά 1.2.2.)

Στη συνέχεια απογράψαμε λεξικά κάθε εμφάνιση περιορισμού στις καρφωμένες πηγές. Όχι τύπους περιορισμών – εμφανίσεις, που προσδιορίζονται από αρχείο και γραμμή, ώστε δύο περιορισμοί που τυχαίνει να μοιράζονται ένα ID να μη συγχωνεύονται ποτέ σε έναν. Το σύνολο έφτασε τους 348.

Αποδεικνύοντας καθέναν

Για κάθε εμφάνιση, το build μας πρέπει να διατηρεί ακριβώς μία από τρεις ετυμηγορίες, κάτι που επιβάλλεται από έναν generator ο οποίος επαναϋπολογίζει το καθολικό σε κάθε εκτέλεση:

• Αποδεδειγμένα επιβαλλόμενοι (303): μια δοκιμή ακριβής ως προς την εμφάνιση οδηγεί τον πραγματικό evaluator πάνω σε ένα ελάχιστο έγγραφο και βεβαιώνει ότι αξιολογήθηκε αυτή η συγκεκριμένη εμφάνιση αρχείου και γραμμής. Το AST της δοκιμής επαληθεύεται μηχανικά – το υποκείμενο πρέπει να εκτελείται ακριβώς μία φορά, το αποτέλεσμά του πρέπει να ρέει σε ακριβώς ένα assertion – και το αρχείο δοκιμής μαζί με τις μεταβατικές εισαγωγές του είναι καρφωμένα με hash. Αλλάξτε τον evaluator και τα τεκμήρια γίνονται παρωχημένα έως ότου παραχθούν εκ νέου.
• Επιβαλλόμενοι από το σχήμα (1): αποδεδειγμένα καλυπτόμενος από το JSON Schema της έκδοσης.
• Εξαιρεμένοι με αιτιολόγηση (44): ρητά εκτός, ο καθένας με γραπτό, επανεξετάσιμο λόγο.

Χωρίς λογοδοσία: μηδέν.

Αυτή η τελευταία κατηγορία – οι εξαιρέσεις – ήταν εκεί όπου τα πράγματα έγιναν ενδιαφέροντα.

Το πρότυπο έχει bugs

Όταν ελέγχετε 348 περιορισμούς έναν προς έναν, βρίσκετε πράγματα. Τρεις από τις εξαιρέσεις μας είναι ελαττώματα στις ίδιες τις πηγές του NIST:

• Ένας ορφανός περιορισμός. Η γραμμή 657 του oscal_mapping-common_metaschema.xml περιορίζει ένα flag που ορίζεται πέντε γραμμές νωρίτερα – και στη συνέχεια δεν αναφέρεται πουθενά. Κανένα έγγραφο που μπορεί να υπάρξει δεν φέρει αυτό το flag. Ο περιορισμός είναι μη ικανοποιήσιμος.
• Ένα αδύνατο κατηγόρημα. Ένας κανόνας για ονόματα prop του inventory-item εφαρμόζεται μόνο όταν το @type είναι software, hardware ή service – όμως το inventory-item δεν δηλώνει καθόλου flag type. (Ο γείτονάς του, το asset-id, είναι και αυτό σχολιασμένο στην πηγή.) Το κατηγόρημα δεν μπορεί ποτέ να ταιριάξει.
• Περιορισμοί μέσα σε σχόλια. Πέντε εμφανίσεις περιορισμών βρίσκονται μέσα σε μπλοκ σχολίων – συμπεριλαμβανομένου ενός ολόκληρου λεξιλογίου τιμών για το with-child-controls του profile. Ένας άνθρωπος που διαβάζει την πηγή τους βλέπει· το μεταγλωττισμένο σχήμα δεν τους επιβάλλει ποτέ. Και τα τρία ευρήματα έχουν αναφερθεί upstream: usnistgov/OSCAL#2254, #2255, #2256.

Και ο έλεγχος έκοψε και προς τις δύο κατευθύνσεις: ο δικός μας evaluator είχε ένα bug όπου οι περιορισμοί που στοχεύουν flags (όπως οι επιτρεπόμενες τιμές του action/@type) μεταγλωττίζονταν στην απογραφή αλλά σιωπηρά δεν ενεργοποιούνταν ποτέ. Δεν το βρήκαμε από τύχη – η πύλη κλεισίματος αρνήθηκε να δεχτεί τεκμήρια για αυτές τις δύο εμφανίσεις, που είναι ακριβώς ο τρόπος αστοχίας που όλο το σύστημα έχει σχεδιαστεί να αποκαλύπτει.

Μετά εκτελέσαμε πραγματικά τη σύγκριση

Ο ισχυρισμός ότι «η υλοποίηση αναφοράς χάνει πράγματα» μόνο από επιθεώρηση της πηγής είναι ακριβώς το είδος του αναπόδεικτου ισχυρισμού που αυτό το έργο υπάρχει για να εξαλείψει. Γι' αυτό κατεβάσαμε το Java OSCAL CLI 3.2.0 από το Maven Central, επαληθεύσαμε το hash του και εκτελέσαμε και τους δύο validators πάνω σε μια οικογένεια fixtures της οποίας τα βασικά έγγραφα περνούν καθαρά και στις δύο πλευρές – ώστε κάθε διαφωνία να αποδίδεται σε μία εισαγόμενη αλλαγή.

Το OSCAL 1.2.2 άλλαξε ακριβώς δύο περιορισμούς πέρα από τις αλλαγές έκδοσης (και οι δύο στο μοντέλο SSP). Το Java CLI – που ενσωματώνει bindings του 1.2.1 – βρίσκεται στη λάθος πλευρά κάθε παρατηρήσιμης συνέπειας:

• Ένα SSP με έναν ξεκρέμαστο σύνδεσμο στοιχείου rel="validation" παραβιάζει το 1.2.2. Java: έγκυρο, exit 0.
• Ένα SSP με έναν ξεκρέμαστο σύνδεσμο rel="validated-by" είναι εντάξει σύμφωνα με το 1.2.2 (ο περιορισμός διαγράφηκε). Java: άκυρο.
• Ένα responsible-role χωρίς το προαιρετικό party-uuid είναι εντάξει σύμφωνα με το 1.2.2 – το NIST πρόσθεσε το κατηγόρημα ειδικά για να το διορθώσει. Η Java βγάζει σφάλμα με, κατά λέξη, Key reference [null] not found.

Μετά ένα που δεν έχει καθόλου σχέση με απόκλιση εκδόσεων: ένας κατάλογος του οποίου το action στα μεταδεδομένα δηλώνει "type": "invented-type" – κάτι που απαγορεύεται στη γραμμή 877 του Metaschema μεταδεδομένων τόσο στο 1.2.2 όσο και στις πηγές 1.2.1 που ενσωματώνει η Java. Η Java το δηλώνει έγκυρο, σε JSON και XML. Ο περιορισμός στοχεύει ένα flag· οι περιορισμοί που στοχεύουν flags και σιωπηρά δεν ενεργοποιούνται είναι ακριβώς η κατηγορία bug που έπιασε η πύλη πληρότητάς μας στον δικό μας evaluator. Η υλοποίηση αναφοράς έχει την ίδια κατηγορία bug – και καμία πύλη κλεισίματος για να το πιάσει. Το αναφέραμε upstream ως metaschema-framework/oscal-cli#279. (Χαρτογραφήσαμε την κατηγορία μηχανικά: ακριβώς 2 από τις 200 εμφανίσεις allowed-values στοχεύουν flags και το μόνο μέλος επιπέδου σφάλματος είναι αυτό που δοκιμάσαμε ζωντανά. Δεν μένει τίποτα αδοκίμαστο.)

Και η στιγμή της ειλικρίνειας, επειδή η εκτέλεση έκοψε και προς τις δύο κατευθύνσεις: ο validator μας απέρριψε τον ίδιο τον κατάλογο SP 800-53 rev5 του NIST. Είκοσι σφάλματα, όλα ένα ελάττωμα – ο evaluator ευρετηρίων μας αντιμετώπιζε ένα ελλείπον προαιρετικό πεδίο κλειδιού ως παραβίαση, ενώ η προδιαγραφή Metaschema λέει ότι πρόκειται για κλειδί null. Η Java δέχτηκε το αρχείο· εμείς κάναμε λάθος· το διορθώσαμε την ίδια μέρα και το 800-53 επικυρώνεται καθαρά. Η εκτέλεση έπιασε αργότερα και ένα δεύτερο: συνεχίζαμε να επιβάλλουμε το λεξιλόγιο τύπων action του OSCAL ακόμη και όταν το action/@system δήλωνε ένα προσαρμοσμένο URI – ακριβώς την τμηματοποίηση ανά οργανισμό που ζητούν οι ίδιες οι παρατηρήσεις του NIST. Διορθώθηκε και αυτό. Ένας διαφορικός μηχανισμός δοκιμών που βρίσκει μόνο τα bugs της άλλης πλευράς δεν είναι μηχανισμός δοκιμών, είναι μάρκετινγκ.

(Επίσης στην κατηγορία «και οι δύο πλευρές»: κανένας resolver δεν επικύρωνε σημασιολογικά τη δική του έξοδο. Το resolve-profile της Java γράφει πρόθυμα έναν κατάλογο που το ίδιο το validate της Java στη συνέχεια απορρίπτει – και ο δικός μας έκανε το ίδιο, με πύλη σχήματος αλλά χωρίς σημασιολογική πύλη. Ο δικός μας πλέον αρνείται να γράψει σημασιολογικά άκυρες επιλύσεις· η Java εξακολουθεί να μην μπορεί, επειδή το κλείσιμο αυτού του κενού απαιτεί ένα σημασιολογικό επίπεδο που εμπιστεύεστε.)

Επικύρωση του γράφου, όχι μόνο του αρχείου

Το δεύτερο πράγμα που λείπει από τα υπάρχοντα εργαλεία: τα έγγραφα OSCAL δεν ζουν μόνα τους. Ένα assessment result εισάγει ένα assessment plan, το οποίο εισάγει ένα SSP, το οποίο εισάγει ένα profile, το οποίο επιλύεται απέναντι σε καταλόγους. Η τεκμηρίωση των μοντέλων είναι γεμάτη σχέσεις που κανένας validator μεμονωμένων αρχείων δεν μπορεί να ελέγξει – «ο στόχος αυτού του ευρήματος πρέπει να επιλύεται σε μια δήλωση της βάσης αναφοράς», «αυτό το POA&M πρέπει να προσδιορίζει το σύστημά του».

Γι' αυτό χτίσαμε επικύρωση μεταξύ εγγράφων που επιλύει πραγματικά αυτές τις ακμές. Ζητήστε της να ελέγξει ένα SSP και επιλύει την εισαγόμενη βάση αναφοράς μέσω της πλήρους διαδικασίας επίλυσης profile (κατά το σχέδιο προδιαγραφής) μέχρι τους καταλόγους, υπολογίζει το επιλεγμένο σύνολο μέτρων ελέγχου και σας λέει:

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

Με έναν κρίσιμο κανόνα σχεδιασμού: αυτοί οι έλεγχοι σχέσεων είναι ερμηνείες τεκμηριωμένου κειμένου και τους αντιμετωπίζουμε ως τέτοιες – απενεργοποιημένοι από προεπιλογή, προειδοποιήσεις και όχι σφάλματα, με το εύρος επίλυσης κάθε πεδίου καρφωμένο στη γραμμή πηγής του, και οτιδήποτε απλώς συναγόμενο εξαιρείται ονομαστικά. Όπου το πρότυπο αφήνει περιθώρια, ένας validator δεν πρέπει να μπλοφάρει. (Το αγαπημένο μας παράδειγμα: η προδιαγραφή POA&M λέει ότι απαιτείται εισαγωγή SSP ή system-id – «Both may be present». Έτσι προειδοποιούμε μόνο όταν δεν υπάρχει κανένα από τα δύο. Κανένα επινοημένο αποκλειστικό ή.)

Γιατί TypeScript;

Επειδή τα έγγραφα ζουν σε προγράμματα περιήγησης, serverless functions, CLIs και βάσεις δεδομένων – και θέλαμε έναν validator σε όλα αυτά, όχι ένα JVM sidecar δίπλα στο καθένα. Οι validators είναι προμεταγλωττισμένες αυτόνομες μονάδες Ajv: απλή παραγόμενη JavaScript, μηδενική μεταγλώττιση σχημάτων κατά τον χρόνο εκτέλεσης, έξοδος σταθερή σε επίπεδο byte. Ο ίδιος κώδικας που τροφοδοτεί τις επιφάνειες επικύρωσής μας εκτελείται αμετάβλητος στην καρτέλα του προγράμματος περιήγησής σας και στο CLI μας. Και ο ντετερμινισμός δεν είναι απλώς μια λειτουργική ευκολία – είναι αυτό που καθιστά καθόλου δυνατά τα τεκμήρια καρφωμένα με hash.

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

Πού καταλήγει αυτό

• Πλήρης υποστήριξη OSCAL 1.1.2 → 1.2.2, με εγγενή σημασιολογία 1.2.2
• Πλήρης επίλυση profile σύμφωνα με το σχέδιο προδιαγραφής, με χειρισμό fail-closed για ό,τι αφήνει αόριστο το σχέδιο – και έναν resolver που αρνείται να γράψει σημασιολογικά άκυρη έξοδο
• Ολόκληρη η επιφάνεια του Java CLI που αφορά το OSCAL, συν την επικύρωση γράφου που ποτέ δεν είχε (validate --resolve-imports --interpretive all)
• Και ένας ισχυρισμός που μπορείτε να ελέγξετε: λογοδοσία για 348/348 εμφανίσεις περιορισμών, σε ένα μηχαναγνώσιμο καθολικό που το CI μας επαναϋπολογίζει σε κάθε commit

Η πλήρης τεχνική αναφορά – μοντέλο αυθεντίας, κλείσιμο πληρότητας, ο πίνακας αποδείξεων της διαφορικής σύγκρισης και όσα σκόπιμα δεν ισχυριζόμαστε – βρίσκεται στην τεκμηρίωση του validator. Ο validator βρίσκεται σε ιδιωτικό staging ενόψει μιας κυκλοφορίας ανοιχτού κώδικα· το φιλοξενούμενο API επικύρωσης εκθέτει σήμερα το επίπεδο σχήματος, με το σημασιολογικό επίπεδο να ακολουθεί.