Mi az OSCAL?

Miért adatprobléma a megfelelés

A biztonsági követelmények ma is többnyire folyó szövegben élnek: a katalógusok PDF-ként, a biztonsági tervek Word-dokumentumként, az értékelési megállapítások jelentésként. A folyó szöveg rugalmas, de ennek ára van. Ugyanazt a követelményt különböző olvasók eltérően értelmezik, a kereszthivatkozások minden új verzióval elromlanak, és minden elemzés másolással, beillesztéssel és táblázatok kézi karbantartásával kezdődik.

Pontosan ezt a problémát kezeli az OSCAL. Az Open Security Controls Assessment Language a NIST vezetésével, a FedRAMP-pel és egy nemzetközi közösséggel együtt fejlesztett nyílt szabvány. Az OSCAL strukturált adatként írja le a biztonsági követelményeket, azok megvalósítását és értékelését – JSON, XML és YAML formátumban.

• A követelmények oldalszámok és címsorok helyett stabil azonosítókat kapnak
• A követelmény, a megvalósítás és a bizonyíték közötti kapcsolatok kifejezetté válnak
• Az eszközök validálni, összehasonlítani és átalakítani tudják a tartalmat

A nyolc dokumentummodell

Az OSCAL nem egyetlen fájlformátum, hanem egymásra épülő dokumentummodellek családja. Ha megérti a rétegeket, bármely OSCAL-dokumentumban eligazodik.

Kontrollréteg: katalógus és profil

A katalógus követelményeket határoz meg, például a NIST SP 800-53 kontrolljait vagy egy nemzeti szabvány moduljait. A profil ezekből választ, igazít és kombinál: egy nagy katalógusból egy adott felhasználási eset konkrét követelménykészlete lesz, például egy felhőszolgáltatásokra vonatkozó alapkonfiguráció.

Megvalósítási réteg: komponensdefiníció és rendszerbiztonsági terv

A komponensdefiníció azt írja le, hogyan teljesítheti egy termék vagy szolgáltatás a követelményeket – sok rendszerben újrafelhasználható módon. A rendszerbiztonsági terv (SSP) ezután egy konkrét rendszerre dokumentálja, mely követelmények alkalmazandók, és hogyan valósítják meg őket ténylegesen.

Értékelési réteg: terv, eredmények és nyitott tételek

Az értékelési terv meghatározza, mit és hogyan tesztelnek. Az értékelési eredmények strukturáltan rögzítik a megfigyeléseket, a megállapításokat és a kockázatokat. Az intézkedési terv és mérföldkövek (POA&M) a nyitott tételeket felelősökkel és határidőkkel kezeli – adatként, nem mellékletként.

Az OSCAL 1.2 ezekre építve hozta be a megfeleltetési gyűjteményt. Ez különböző katalógusok követelményei közötti kapcsolatokat ír le, például egy nemzetközi szabvány és egy nemzeti keretrendszer között. Így maguk a keretrendszerek közötti megfeleltetések is géppel olvashatóvá válnak.

Kik használják ma az OSCAL-t

Az OSCAL már régen kinőtte kutatási gyökereit. A FedRAMP, az amerikai felhőengedélyezési program, eltávolodik a Word- és Excel-csomagoktól, és strukturált, géppel olvasható engedélyezési adatokat követel meg – ezt a váltást részletesen bemutatjuk A FedRAMP géppel olvashatóvá válik című cikkünkben.

Németország is döntött: a BSI a Stand-der-Technik-Bibliothek tartalmát – beleértve az IT-Grundschutz++ katalógust – OSCAL-katalógusként teszi közzé XML, JSON és YAML formátumban. A BSI indoklása üdítően pragmatikus: az OSCAL nemzetközileg bevált, egy nemzeti különformátum pedig kerülőút lenne. Hogy ez mit jelent a Grundschutz-csapatok számára, arról az IT-Grundschutz++-ról és az OSCAL-ról szóló cikkünkben írunk.

• FedRAMP: a géppel olvasható engedélyezési csomagok felváltják a dokumentumsablonokat
• BSI: az IT-Grundschutz++ OSCAL-katalógusként jelenik meg a GitHubon
• Közösség: a megjelenítők, validátorok, könyvtárak és platformok egy irányba tartanak

Hogyan kezdenek hozzá a csapatok a gyakorlatban

Az OSCAL-lal való ismerkedésnek nem kell projektnek lennie. Jó első lépés, ha megnéz és validál egy valódi dokumentumot – például egy katalógust a NIST repositoryjából vagy egy saját exportot.

Ingyenes OSCAL Validatorunkkal bármely OSCAL JSON-dokumentumot közvetlenül a böngészőben ellenőrizhet a hivatalos sémák alapján, feltöltés és regisztráció nélkül. Ha mélyebbre szeretne menni, OSCAL Toolkitünk nyílt TypeScript-könyvtárat kínál OSCAL-dokumentumok betöltéséhez, validálásához és átalakításához.

Ettől a ponttól az OSCAL főként a munkamodell kérdésévé válik: mely katalógusok és profilok vonatkoznak ránk? Honnan származnak az SSP tartalmai és a bizonyítékok? A Secani az alapoktól OSCAL-natív módon épül – így a csapatok nemcsak importálni tudják a strukturált megfelelési adatokat, hanem ténylegesen dolgozni is tudnak bennük.