Poza mapowaniami krzyżowymi w arkuszach kalkulacyjnych

Organizacje rzadko działają w ramach jednolitych ram cyberbezpieczeństwa.

Dostawca SaaS może potrzebować ISO 27001 dla swojego systemu zarządzania bezpieczeństwem informacji, SOC 2, aby spełnić oczekiwania klientów, RODO w zakresie obowiązków związanych z prywatnością oraz NIS2 ze względu na swój sektor lub bazę klientów. Dostawca obronności może być zmuszony do jednoczesnego rozważenia NIST SP 800-171, CMMC, wymagań umownych i istniejących kontroli opartych na ISO.

Problem w tym, że te frameworki nie są całkowicie niezależne. Często proszą organizacje o wykonanie podobnych działań, stosując inną terminologię, struktury i poziomy szczegółowości.

W tym miejscu przydatne staje się mapowanie krzyżowe ram.

Jednak zidentyfikowanie podobnych wymagań to dopiero początek. Aby mapowanie krzyżowe było niezawodne, nadawało się do ponownego wykorzystania i nadawało się do automatyzacji, organizacje muszą także wiedzieć, skąd wzięła się relacja, jak silna jest, do jakich wersji frameworku ma zastosowanie i gdzie pozostają istotne luki.

Dwie inicjatywy NIST są szczególnie istotne dla tego wyzwania: Krajowy program informacyjny w Internecie, lepiej znany jako OLIR i Model mapowania sterowania OSCAL.

Odnoszą się do różnych części tego samego problemu.

Dlaczego zgodność z wieloma platformami powoduje niepotrzebną pracę

Tradycyjne programy zgodności są często zorganizowane wokół indywidualnych ram.

Jeden arkusz kalkulacyjny zawiera kontrole ISO 27001. Inny śledzi wymagania NIS2. Trzeci jest utrzymywany na potrzeby kwestionariusza klienta lub zbliżającego się audytu SOC 2. Dowody, zasady, opisy kontroli i uwagi dotyczące implementacji są kopiowane między nimi.

Ułatwia to traktowanie każdego nowego frameworka jako zupełnie nowego programu zgodności.

Mapowanie krzyżowe identyfikuje wspólne lub nakładające się wymagania, aby w stosownych przypadkach można było ponownie wykorzystać istniejące kontrole i dowody, takie jak zasady, dzienniki, zrzuty ekranu i procedury. Praktyczne korzyści wykraczają poza ograniczenie powielania pracy. Mapowanie krzyżowe może również usprawnić przygotowanie audytu, raportowanie, widoczność ryzyka i zdolność reagowania na zmiany regulacyjne.

Najcenniejszym wynikiem często nie jest samo nakładanie się, ale delta.

Proces reagowania na incydenty może wspierać wymagania norm ISO 27001, SOC 2 i NIS2. Nie oznacza to jednak, że wymagania są identyczne. Jedne ramy mogą wymagać określonych ram czasowych raportowania, inne mogą koncentrować się na obowiązkach związanych z zarządzaniem, a jeszcze inne mogą wymagać określonych dowodów podczas badania.

Użyteczne mapowanie musi zatem odpowiedzieć na dwa pytania:

1. Co można ponownie wykorzystać?
2. Czego jeszcze brakuje?

To rozróżnienie oddziela wiarygodne mapowanie krzyżowe od prostej tabeli rzekomo równoważnych mechanizmów kontrolnych.

Co to jest OLIR?

OLIR oznacza Online Informative Reference i jest częścią Narodowego Programu Informacyjnych Referencji Online NIST.

Program umożliwia ekspertom merytorycznym opisywanie relacji pomiędzy elementami ich własnych standardów, ram, produktów lub wytycznych a elementami obsługiwanych dokumentów NIST. Te dokumenty NIST nazywane są dokumentami głównymi i mogą obejmować publikacje takie jak NIST Cybersecurity Framework, NIST SP 800-53 lub NIST AI Risk Management Framework.

OLIR może na przykład połączyć wymaganie ze struktury branżowej z podkategorią NIST CSF 2.0.

OLIR oferuje więcej niż tylko strukturę arkusza kalkulacyjnego. Zapewnia:

• Standaryzowane podejście do wyrażania twierdzeń mapowania
• Szablony obsługiwanych dokumentów centralnych NIST
• Metadane dotyczące organizacji składającej i mapowanych dokumentów
• Scentralizowany katalog publiczny
• Wstępne i ostateczne statusy publikacji
• Proces przeglądu publicznego
• Informacja o tym, czy mapowanie zostało utworzone przez właściciela dokumentu, czy przez osobę trzecią

NIST rozróżnia trzy style mapowania OLIR: mapowania pojęciowe, mapowania relacji oparte na teorii zbiorów i pomocnicze mapowania relacji.

W szczegółowych mapowaniach krzyżowych zgodności szczególnie przydatne są relacje oparte na teorii zbiorów. Zamiast jedynie stwierdzać, że dwa wymagania są powiązane, mogą określać, czy jedno jest równe drugiemu, jest jego podzbiorem, nadzbiorem lub częściowo się z nim pokrywa.

Dlatego OLIR zapewnia dwie rzeczy, których brakuje wielu wewnętrznym projektom mapowania: wykrywalną treść mapowania i strukturę zarządzania wokół tej treści.

Co to jest model mapowania sterowania OSCAL?

OSCAL, język oceny Open Security Controls, zapewnia czytelne maszynowo modele do reprezentowania katalogów kontroli, profili, planów bezpieczeństwa systemu, planów oceny, wyników oceny i powiązanych informacji o zgodności.

Model mapowania kontroli OSCAL rozszerza ten ekosystem, zapewniając uporządkowaną reprezentację relacji pomiędzy kontrolami i elementami kontroli z różnych źródeł dokumentacyjnych.

W odróżnieniu od opisowego mapowania krzyżowego model zaprojektowano do przetwarzania przez oprogramowanie. Może być zapisany w formacie JSON, YAML lub XML i mapować mechanizmy kontrolne albo pojedyncze deklaracje kontroli z katalogów i profili OSCAL.

Typy relacji obejmują:

• equal-to
• equivalent-to
• subset-of
• superset-of
• intersects-with
• no-relationship

Model może również opisywać, czy mapowanie opierało się na podobieństwie składniowym, znaczeniu semantycznym czy wyniku funkcjonalnym.

Ma to znaczenie, ponieważ dwa wymagania mogą wyglądać podobnie, a jednocześnie dawać różne wyniki operacyjne. I odwrotnie, wymagania używające zupełnie innego języka mogą nadal spełniać prawie tę samą funkcję bezpieczeństwa.

Model może dodatkowo rejestrować pochodzenie, strony odpowiedzialne, status, poziom pewności, zakres, luki oraz to, czy mapowanie utworzono ręcznie, automatycznie czy w procesie hybrydowym. Dzięki temu nadaje się nie tylko do prezentowania mapowań krzyżowych, lecz także do automatycznej analizy luk, analizy wpływu zmian, walidacji i ponownego wykorzystania w procesach zgodności.

OLIR i OSCAL nie są podejściami konkurencyjnymi

Kuszące jest pytanie, czy organizacja powinna używać modelu mapowania kontroli OLIR, czy OSCAL.

W praktyce rozwiązują różne problemy.

OLIR to przede wszystkim program, katalog, proces składania i źródło twierdzeń mapowania. Pomaga organizacjom znajdować i publikować mapowania obejmujące dokumenty główne NIST.

Model mapowania sterowania OSCAL jest modelem danych technicznych. Określa, w jaki sposób relacje mapowania mogą być przechowywane, wymieniane, sprawdzane i przetwarzane w systemie.

OLIR może poinformować platformę, że ekspert lub organizacja stwierdziła określony związek. OSCAL może uczynić tę relację częścią większego, dającego się obliczyć systemu zgodności.

OSCAL ma również bardziej ogólny zakres. Kolekcja mapowania OSCAL może łączyć dowolne odpowiednie katalogi lub profile OSCAL. Nie ogranicza się to do relacji obejmujących dokument centralny NIST.

Oznacza to, że organizacja może używać OSCAL do reprezentowania bezpośrednich relacji, takich jak:

• BSI IT-Grundschutz zgodnie z ISO 27001
• NIS2 zgodnie z ISO 27001
• DORA do biblioteki kontroli wewnętrznej
• Specyficzne wymagania klienta dotyczące istniejących kontroli organizacyjnych

Mapowania te niekoniecznie kwalifikowałyby się jako oficjalne zgłoszenia OLIR, ale nadal mogłyby wykorzystywać porównywalne koncepcje relacji i być spójnie przechowywane w systemie OSCAL.

Jak te dwie rzeczy mogą ze sobą współpracować

Praktyczna implementacja mogłaby traktować OLIR jako jedno z kilku zewnętrznych źródeł mapowania, a OSCAL jako kanoniczną reprezentację wewnętrzną.

Mapowania OLIR
Mapowania BSI lub regulacyjne
Mapowania dostarczone przez wydawców
Mapowania utworzone przez ekspertów
Mapowania właściwe dla klientów
Sugestie mapowań wygenerowane przez AI
                ↓
      Import i normalizacja
                ↓
   Uzgodnienie standardów i wersji
                ↓
     Kolekcje mapowań OSCAL
                ↓
     Przegląd, zatwierdzenie i pewność
                ↓
Analiza luk, ponowne użycie dowodów i analiza wpływu

Podczas importowania OLIR platforma identyfikuje dokument referencyjny i dokument centralny, porównuje ich identyfikatory elementów z odpowiednimi katalogami OSCAL i tłumaczy każdą relację na wpis mapowania OSCAL.

Oryginalny OLIR powinien pozostać dołączony jako pochodzenie. Użytkownicy powinni mieć możliwość zobaczenia:

• Kto stworzył mapowanie
• Które wersje zostały porównane
• Określa, czy wydawca jest właścicielem któregokolwiek źródła
• Czy mapowanie jest wersją roboczą, czy ostateczną
• Jaka metoda mapowania została zastosowana
• Czy zostało to sprawdzone wewnętrznie

Dzięki temu mapowania są identyfikowalne i nie można ich traktować jako uniwersalnych faktów.

Mapowanie krzyżowe nie powinno stać się ślepą równoważnością

Automatyzacja stwarza ryzyko, że organizacje zaczną traktować mapowania jako dowód, że jedno wdrożenie automatycznie spełnia wszystkie powiązane wymagania.

Wniosek ten rzadko jest uzasadniony.

Mapowanie krzyżowe opisuje relacje między wymaganiami. Nie dowodzi automatycznie, że organizacja skutecznie wdrożyła te wymagania.

Dowody mogą również nadawać się do ponownego wykorzystania, choć nie są wystarczające. Zasady tworzenia kopii zapasowych mogą obsługiwać kilka struktur, ale jedna struktura może dodatkowo wymagać testów przywracania, zdefiniowanych celów odzyskiwania, określonych okresów przechowywania lub dowodów przeglądu kierownictwa.

Niezawodne mapowanie krzyżowe wymaga zatem:

• Tam, gdzie to możliwe, szczegółowość na poziomie instrukcji
• Jawne wersje frameworka
• Udokumentowane typy relacji
• Opisy luk
• Pochodzenie
• Poziomy zaufania
• Przegląd ludzki pod kątem konsekwencji decyzji

Relacje pochodne wymagają szczególnej ostrożności. OLIR może generować pochodne mapowania relacji między dwoma dokumentami referencyjnymi, porównując ich powiązania ze wspólnym dokumentem głównym NIST. NIST opisuje je jako nieautorytatywne punkty wyjścia, a nie zweryfikowane bezpośrednie mapowania krzyżowe.

Mogą przyspieszyć analizę, ale powinny generować zadania przeglądu, a nie automatyczne oświadczenia o zgodności.

Od statycznych mapowań krzyżowych do infrastruktury zgodności wielokrotnego użytku

Praktyczny argument za mapowaniem krzyżowym jest przekonujący: organizacje nie powinny wielokrotnie tworzyć tych samych kontroli, gromadzić tych samych dowodów i utrzymywać odrębnych programów zgodności dla każdego frameworka. Scentralizowane repozytorium i skalowalna automatyzacja mogą ograniczyć powielanie prac i sprawić, że luki będą bardziej widoczne.

Następnym krokiem jest nadanie tym mapowaniom przenośnej, wersjonowanej i czytelnej maszynowo postaci.

OLIR może zapewnić istniejącą wiedzę na temat mapowania, zarządzanie publikacjami i drogę do wniesienia nowego mapowania zorientowanego na NIST. Model mapowania kontroli OSCAL może przekształcić te relacje w ustrukturyzowane obiekty, które narzędzia zgodności mogą weryfikować, wysyłać zapytania, rozszerzać i łączyć z szerszymi przepływami pracy związanymi z oceną.

W Secani postrzegamy OSCAL jako kanoniczną podstawę techniczną. OLIR nie jest modelem konkurencyjnym, ale cennym źródłem, które może go wzbogacić.

Długoterminowa szansa jest większa niż pokazanie, że dwie kontrole się nakładają. Polega na utworzeniu zaufanej warstwy mapowania, która pokazuje, co można ponownie wykorzystać, co pozostaje odkryte, dlaczego istnieje relacja, kto ją zatwierdził i jak aktualizacja struktury wpływa na pozostałą część programu zgodności.

W ten sposób mapowanie krzyżowe przenosi się ze zbioru arkuszy kalkulacyjnych do infrastruktury zgodności wielokrotnego użytku.