Vad är OSCAL?

Varför efterlevnad är ett dataproblem

Säkerhetskrav finns fortfarande mest i löptext: kataloger som PDF-filer, säkerhetsplaner som Word-dokument, bedömningsresultat som rapporter. Löptext är flexibel, men det har ett pris. Samma krav tolkas olika av olika läsare, korshänvisningar går sönder vid varje ny version och varje analys börjar med att kopiera, klistra in och manuellt underhålla kalkylblad.

Det är precis det problemet OSCAL tar itu med. Open Security Controls Assessment Language är en öppen standard som leds av NIST och utvecklas tillsammans med FedRAMP och en internationell gemenskap. OSCAL beskriver säkerhetskrav, hur de genomförs och hur de bedöms som strukturerade data – tillgängliga i JSON, XML och YAML.

• Kraven får stabila identifierare i stället för sidnummer och rubriker
• Sambanden mellan krav, genomförande och underlag blir uttryckliga
• Verktyg kan validera, jämföra och omvandla innehållet

De åtta dokumentmodellerna

OSCAL är inte ett enskilt filformat utan en familj av dokumentmodeller som bygger på varandra. När du väl förstår skikten hittar du rätt i vilket OSCAL-dokument som helst.

Kontrollskiktet: katalog och profil

En katalog definierar krav, till exempel kontrollerna i NIST SP 800-53 eller modulerna i en nationell standard. En profil väljer ut, anpassar och kombinerar: en stor katalog blir den konkreta kravuppsättningen för ett användningsfall, till exempel en baslinje för molntjänster.

Genomförandeskiktet: komponentdefinition och systemsäkerhetsplan

En komponentdefinition beskriver hur en produkt eller tjänst kan uppfylla krav – återanvändbar i många system. Systemsäkerhetsplanen (SSP) dokumenterar sedan, för ett konkret system, vilka krav som gäller och hur de faktiskt genomförs där.

Bedömningsskiktet: plan, resultat och öppna punkter

Bedömningsplanen (assessment plan) definierar vad som ska testas och hur. Bedömningsresultaten (assessment results) fångar observationer, fynd och risker på ett strukturerat sätt. Åtgärdsplanen med milstolpar (POA&M) hanterar öppna punkter med ägare och tidsfrister – som data, inte som en bilaga.

OSCAL 1.2 lade dessutom till mappningssamlingen (mapping collection). Den beskriver samband mellan krav i olika kataloger, till exempel mellan en internationell standard och ett nationellt ramverk. Själva korsreferenserna mellan ramverk blir därmed maskinläsbara.

Vem använder OSCAL i dag

OSCAL har sedan länge vuxit ur sina forskningsrötter. FedRAMP, det amerikanska programmet för godkännande av molntjänster, går bort från paket i Word och Excel och kräver strukturerade, maskinläsbara godkännandeuppgifter – en förändring som vi beskriver utförligt i FedRAMP blir maskinläsbart.

Även Tyskland har fattat sitt beslut: BSI publicerar innehållet i sitt Stand-der-Technik-Bibliothek – inklusive IT-Grundschutz++-katalogen – som OSCAL-kataloger i XML, JSON och YAML. BSI:s resonemang är uppfriskande pragmatiskt: OSCAL är internationellt etablerat, och ett nationellt specialformat skulle vara en omväg. Vad det innebär för team som arbetar med Grundschutz tar vi upp i vårt inlägg om IT-Grundschutz++ och OSCAL.

• FedRAMP: maskinläsbara godkännandepaket ersätter dokumentmallar
• BSI: IT-Grundschutz++ levereras som en OSCAL-katalog på GitHub
• Gemenskapen: visningsprogram, validerare, bibliotek och plattformar närmar sig varandra

Hur team kommer igång i praktiken

Att komma igång med OSCAL behöver inte vara ett projekt. Ett bra första steg är att titta på ett verkligt dokument och validera det – till exempel en katalog från NIST:s kodförråd eller en egen export.

Med vår kostnadsfria OSCAL Validator kan du kontrollera vilket OSCAL JSON-dokument som helst mot de officiella schemana direkt i webbläsaren, utan uppladdning och utan registrering. Om du vill gå djupare erbjuder vårt OSCAL Toolkit ett öppet TypeScript-bibliotek för att läsa in, validera och omvandla OSCAL-dokument.

Därefter blir OSCAL främst en fråga om er arbetsmodell: vilka kataloger och profiler gäller för oss? Var kommer innehållet i SSP:n och underlagen ifrån? Secani är byggt OSCAL-nativt från grunden – så att team inte bara kan importera strukturerade efterlevnadsdata utan faktiskt arbeta i dem.