Co je OSCAL?

Proč je compliance datový problém

Bezpečnostní požadavky dodnes žijí převážně v prozaickém textu: katalogy jako PDF, bezpečnostní plány jako dokumenty Word, zjištění z posouzení jako zprávy. Text je flexibilní, má to však svou cenu. Tentýž požadavek si různí čtenáři vykládají různě, křížové odkazy se s každou novou verzí rozbíjejí a každá analýza začíná kopírováním, vkládáním a ruční údržbou tabulek.

Právě tento problém OSCAL řeší. Open Security Controls Assessment Language je otevřený standard vedený institutem NIST a vyvíjený společně s programem FedRAMP a mezinárodní komunitou. OSCAL popisuje bezpečnostní požadavky, jejich implementaci a jejich posouzení jako strukturovaná data – dostupná ve formátech JSON, XML a YAML.

• Požadavky získávají stabilní identifikátory místo čísel stránek a nadpisů
• Vztahy mezi požadavkem, implementací a důkazem se stávají explicitními
• Nástroje mohou obsah validovat, porovnávat a transformovat

Osm modelů dokumentů

OSCAL není jediný formát souboru, ale rodina modelů dokumentů, které na sebe navazují. Jakmile porozumíte jednotlivým vrstvám, vyznáte se v jakémkoli dokumentu OSCAL.

Vrstva opatření: katalog a profil

Katalog definuje požadavky, například opatření NIST SP 800-53 nebo moduly národního standardu. Profil z něj vybírá, přizpůsobuje a kombinuje: z rozsáhlého katalogu se stane konkrétní sada požadavků pro jeden případ užití, například základní úroveň pro cloudové služby.

Vrstva implementace: definice komponenty a bezpečnostní plán systému

Definice komponenty popisuje, jak může produkt nebo služba splnit požadavky – opakovaně použitelně napříč mnoha systémy. Bezpečnostní plán systému (SSP) pak pro jeden konkrétní systém dokumentuje, které požadavky se na něj vztahují a jak jsou v něm skutečně zavedeny.

Vrstva posouzení: plán, výsledky a otevřené body

Plán posouzení definuje, co se bude testovat a jak. Výsledky posouzení strukturovaně zachycují pozorování, zjištění a rizika. Plán opatření a milníků (POA&M) spravuje otevřené body s vlastníky a termíny – jako data, nikoli jako přílohu.

OSCAL 1.2 navíc přidal kolekci mapování (mapping collection). Ta popisuje vztahy mezi požadavky různých katalogů, například mezi mezinárodní normou a národním rámcem. Strojově čitelnými se tak stávají i samotná mapování mezi rámci.

Kdo dnes OSCAL používá

OSCAL už dávno přerostl své výzkumné kořeny. FedRAMP, americký program autorizace cloudových služeb, opouští balíčky ve Wordu a Excelu a vyžaduje strukturovaná, strojově čitelná autorizační data – tento posun podrobně popisujeme v článku FedRAMP přechází na strojově čitelné balíčky.

Rozhodlo se i Německo: BSI zveřejňuje obsah své knihovny Stand-der-Technik-Bibliothek – včetně katalogu IT-Grundschutz++ – jako katalogy OSCAL ve formátech XML, JSON a YAML. Zdůvodnění BSI je osvěžujícím způsobem pragmatické: OSCAL je mezinárodně zavedený a národní zvláštní formát by byl oklikou. Co to znamená pro týmy pracující s Grundschutz, rozebíráme v článku o IT-Grundschutz++ a OSCAL.

• FedRAMP: strojově čitelné autorizační balíčky nahrazují šablony dokumentů
• BSI: IT-Grundschutz++ vychází jako katalog OSCAL na GitHubu
• Komunita: prohlížeče, validátory, knihovny a platformy se sbližují

Jak týmy v praxi začínají

Začátek s OSCAL nemusí být projektem. Dobrým prvním krokem je podívat se na skutečný dokument a validovat ho – například katalog z repozitáře NIST nebo vlastní export.

S naším bezplatným OSCAL Validatorem můžete jakýkoli dokument OSCAL ve formátu JSON ověřit vůči oficiálním schématům přímo v prohlížeči, bez nahrávání a bez registrace. Pokud chcete jít hlouběji, náš OSCAL Toolkit nabízí otevřenou knihovnu v TypeScriptu pro načítání, validaci a transformaci dokumentů OSCAL.

Od té chvíle se OSCAL stává především otázkou vašeho pracovního modelu: které katalogy a profily se na nás vztahují? Odkud pocházejí obsah SSP a důkazy? Secani je od základu postaveno nativně na OSCAL – takže týmy mohou strukturovaná data pro compliance nejen importovat, ale v nich i skutečně pracovat.