Kas ir OSCAL?

Kāpēc atbilstība ir datu problēma

Drošības prasības joprojām lielākoties pastāv prozas veidā: katalogi kā PDF faili, drošības plāni kā Word dokumenti, novērtējuma konstatējumi kā ziņojumi. Proza ir elastīga, taču tai ir sava cena. Vienu un to pašu prasību dažādi lasītāji interpretē atšķirīgi, savstarpējās atsauces sabojājas ar katru jaunu versiju, un katra analīze sākas ar kopēšanu, ielīmēšanu un izklājlapu manuālu uzturēšanu.

Tieši šo problēmu risina OSCAL. Open Security Controls Assessment Language ir atvērts standarts, ko vada NIST un kas izstrādāts kopā ar FedRAMP un starptautisku kopienu. OSCAL apraksta drošības prasības, to ieviešanu un novērtēšanu kā strukturētus datus – pieejamus JSON, XML un YAML formātā.

• Prasības iegūst stabilus identifikatorus lappušu numuru un virsrakstu vietā
• Sakarības starp prasību, ieviešanu un pierādījumiem kļūst skaidri izteiktas
• Rīki var saturu validēt, salīdzināt un pārveidot

Astoņi dokumentu modeļi

OSCAL nav viens faila formāts, bet gan viens uz otra balstītu dokumentu modeļu kopums. Kad izprotat šos slāņus, varat orientēties jebkurā OSCAL dokumentā.

Kontroļu slānis: katalogs un profils

Katalogs definē prasības, piemēram, NIST SP 800-53 kontroles vai nacionāla standarta moduļus. Profils no tā izvēlas, pielāgo un apvieno: liels katalogs kļūst par konkrētu prasību kopumu vienam lietojuma gadījumam, piemēram, bāzes līmeni mākoņpakalpojumiem.

Ieviešanas slānis: komponenta definīcija un sistēmas drošības plāns

Komponenta definīcija apraksta, kā produkts vai pakalpojums var izpildīt prasības – atkārtoti izmantojami daudzās sistēmās. Sistēmas drošības plāns (SSP) pēc tam vienai konkrētai sistēmai dokumentē, kuras prasības ir piemērojamas un kā tās tur faktiski ir ieviestas.

Novērtēšanas slānis: plāns, rezultāti un atklātie jautājumi

Novērtēšanas plāns nosaka, kas un kā tiek pārbaudīts. Novērtējuma rezultāti strukturēti fiksē novērojumus, konstatējumus un riskus. Rīcības plāns un atskaites punkti (POA&M) pārvalda atklātos jautājumus ar atbildīgajiem un termiņiem – kā datus, nevis kā pielikumu.

OSCAL 1.2 papildus ieviesa kartējumu kolekciju (mapping collection). Tā apraksta sakarības starp dažādu katalogu prasībām, piemēram, starp starptautisku standartu un nacionālu ietvaru. Arī pašas ietvaru savstarpējās atbilstības tabulas kļūst mašīnlasāmas.

Kas šodien izmanto OSCAL

OSCAL jau sen ir pāraudzis savas pētnieciskās saknes. FedRAMP, ASV mākoņpakalpojumu autorizācijas programma, atsakās no Word un Excel paketēm un pieprasa strukturētus, mašīnlasāmus autorizācijas datus – šo pārmaiņu sīkāk aprakstām rakstā FedRAMP kļūst mašīnlasāms.

Arī Vācija ir izdarījusi savu izvēli: BSI publicē savas Stand-der-Technik-Bibliothek saturu – tostarp IT-Grundschutz++ katalogu – kā OSCAL katalogus XML, JSON un YAML formātā. BSI pamatojums ir patīkami pragmatisks: OSCAL ir starptautiski nostiprinājies, un nacionāls īpašs formāts būtu apkārtceļš. Ko tas nozīmē Grundschutz komandām, aplūkojam rakstā par IT-Grundschutz++ un OSCAL.

• FedRAMP: mašīnlasāmas autorizācijas paketes aizstāj dokumentu veidnes
• BSI: IT-Grundschutz++ tiek publicēts kā OSCAL katalogs vietnē GitHub
• Kopiena: skatītāji, validatori, bibliotēkas un platformas tuvinās cits citam

Kā komandas sāk praksē

Iepazīšanās ar OSCAL nav obligāti jāpārvērš projektā. Labs pirmais solis ir aplūkot reālu dokumentu un to validēt – piemēram, katalogu no NIST repozitorija vai paša eksportu.

Ar mūsu bezmaksas OSCAL Validator varat pārbaudīt jebkuru OSCAL JSON dokumentu pret oficiālajām shēmām tieši pārlūkprogrammā, bez augšupielādes un bez reģistrācijas. Ja vēlaties iedziļināties, mūsu OSCAL Toolkit piedāvā atvērtu TypeScript bibliotēku OSCAL dokumentu ielādei, validēšanai un pārveidošanai.

No šī brīža OSCAL galvenokārt kļūst par jūsu darba modeļa jautājumu: kuri katalogi un profili attiecas uz mums? No kurienes nāk SSP saturs un pierādījumi? Secani jau no paša sākuma ir veidots kā OSCAL-native risinājums – lai komandas varētu ne tikai importēt strukturētus atbilstības datus, bet arī faktiski ar tiem strādāt.