Udowodnić zgodność w czasie, a nie jeden raz

Technik włącza MFA na koncie Microsoft 365 klienta, robi zrzut ekranu i odkłada go do zbioru dowodów. Osiem miesięcy później ubezpieczyciel cybernetyczny klienta — albo jego audytor ISO 27001 — żąda dowodu, że MFA było włączone nieprzerwanie od ostatniego odnowienia. Zrzut tego nie dowodzi. Dowodzi jedynie, że w chwili, w której go wykonano, ustawienie było włączone.

To najczęstsza rozbieżność między tym, co dowodem nazywa technik, a tym, co dowodem nazywa audytor — i kosztuje dokładnie w chwili, w której się ją odkrywa, czyli w trakcie audytu.

Co audytor nazywa dowodem?#

Datowaną obserwację, powtarzaną w czasie, która pokazuje, że zabezpieczenie utrzymało się przez cały objęty okres — a nie jednorazowe oświadczenie, że działało w danym momencie. Norma ISO/IEC 27001:2022 formalizuje to w punkcie 9.1: organizacja musi monitorować i mierzyć skuteczność swoich zabezpieczeń oraz zachowywać udokumentowane informacje jako dowód wyników — a nie jako dowód, że technik kiedyś sprawdził ustawienie.

Dla technika dowód odpowiada na pytanie „czy jest włączone”. Dla audytora odpowiada na pytanie „czy było włączone przez cały przeglądany okres i skąd to wiadomo, skoro nikt nie sprawdzał tego każdego dnia”.

Zawód audytora rozdziela te dwa pytania od dawna, a samo słownictwo bywa przydatne nawet wtedy, gdy nigdy nie przechodzą Państwo żadnej certyfikacji. Z jednej strony jest dowód projektu: zabezpieczenie istnieje, jest skonfigurowane tak, jak przewiduje to polityka, i ktoś potrafi pokazać to na ekranie. Z drugiej strony jest dowód skuteczności operacyjnej: zabezpieczenie rzeczywiście wywoływało oczekiwany skutek, bez niewyjaśnionych przerw, przez cały przeglądany okres. Zrzut ekranu odpowiada na pierwsze pytanie i pozostawia drugie całkowicie otwarte. To dokładnie ta sama różnica, co między raportem atestacyjnym odnoszącym się do jednej chwili a raportem obejmującym okres — i to o ten drugi ubezpieczyciel albo klient z sektora regulowanego zawsze w końcu poprosi.

Rozróżnienie ma praktyczne następstwo, które warto sobie uświadomić, zanim wymusi je czyjeś pytanie. Dowód projektu można wytworzyć w każdej chwili, także po fakcie, bo opisuje stan bieżący. Dowodu skuteczności operacyjnej nie da się wytworzyć później w żaden uczciwy sposób: albo powstawał na bieżąco, dzień po dniu, albo nie powstanie już nigdy. Wszystko, co następuje dalej, jest konsekwencją tego jednego zdania.

Dlaczego jednorazowe zaświadczenie nigdy nie wystarcza?#

Ponieważ nie mówi nic o tym, co działo się przed dniem jego wystawienia ani po nim. Audyt certyfikacyjny ISO 27001 albo kontrola prowadzona przez organ właściwy do spraw cyberbezpieczeństwa w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa obejmuje okres — zwykle miniony rok — a nie moment audytu. Pojedyncze zaświadczenie, choćby najbardziej rzetelne w chwili podpisania, obejmuje dosłownie jeden dzień z trzystu sześćdziesięciu pięciu.

Ryzyko nie polega nawet na nieuczciwości. Polega na tym, że jednorazowe zaświadczenie zebrane tuż przed audytem opisuje dokładnie najmniej reprezentatywny okres roku: ten, w którym wszyscy właśnie sprawdzili i poprawili to, co poprawione nie było.

Jest jeszcze powód czysto mechaniczny i za pierwszym razem zaskakuje on wielu dostawców. Audytor nie czyta całego okresu od początku do końca: on próbkuje. Wybiera daty wewnątrz przeglądanego okresu — często nie uprzedzając, które to będą — i żąda dowodu stanu zabezpieczenia właśnie w tych dniach. Jeżeli Państwa dokumentacja zawiera wyłącznie zrzut z dnia poprzedzającego audyt, każda wylosowana data jest dziurą. Nie da się jej zasypać po fakcie: konsola zarządzania pokazuje stan dzisiejszy, a nie stan z 14 marca. Odczyt z 14 marca albo powstał tamtego dnia, albo nie istnieje.

Właśnie ta nieodwracalność zmienia charakter całego zadania. Zbieranie dowodów nie jest czynnością przygotowawczą, którą da się zaplanować na tydzień przed audytem obok reszty przygotowań. Jest czynnością eksploatacyjną, która musi już trwać w chwili, gdy ktokolwiek zaczyna myśleć o audycie — i to niezależnie od tego, czy audyt w ogóle się odbędzie.

Jak ustawienie bezpieczeństwa rozjeżdża się, choć nikt nie zrobił tego celowo?#

Przez normalne używanie systemu, nie przez czyjś błąd. Użytkownik zostaje zablokowany poza swoim kontem, technik w piątkowy wieczór tymczasowo wyłącza MFA, żeby go odblokować, i w poniedziałek nikt nie pamięta, by je z powrotem włączyć. Aktualizacja konsoli zarządzania przywraca zasadę grupy do wartości domyślnej. Nowe urządzenie trafia do parku, zanim zostanie do niego zastosowana polityka zgodności. Reguła bezpieczeństwa obejmuje grupę użytkowników, której skład zmienia się wraz z przyjęciami i odejściami, a nikt nie synchronizuje ponownie jej zakresu.

Każde z tych zdarzeń z osobna jest błahe. Zsumowane na przestrzeni dwunastu miesięcy, na dziesiątkach kont i w kilku narzędziach, dają dokładnie to, czego obawia się audytor: zabezpieczenie, które było prawdziwe w dniu, w którym je sprawdzono, i które od trzech miesięcy prawdziwe już nie jest, a nikt tego nie zauważył.

Kosztowna w tych dryfach nie jest ich waga, lecz ich dyskrecja. Żaden z nich nie uruchamia alarmu, ponieważ żaden nie jest awarią: system działa dokładnie tak, jak mu polecono. Zestawione obok siebie, wszystkie mają tę samą sygnaturę.

Kolumna po prawej jest jedyną, która odpowiada na pytanie audytora. Pozostałe trzy opisują stan dzisiejszy, co jest użyteczne w eksploatacji, ale bezwartościowe jako dowód.

Warto zauważyć, że we wszystkich pięciu wierszach konsola nie kłamie. Pokazuje rzetelnie to, co ma pokazywać: obecną konfigurację. Problem polega na tym, że pytanie audytora nie dotyczy obecnej konfiguracji, a narzędzie, które przechowuje wyłącznie stan bieżący, nie jest w stanie odpowiedzieć na nie w żadnych okolicznościach — nie dlatego, że jest źle skonfigurowane, lecz dlatego, że nie do tego służy.

Co musi mieć dowód, żeby wytrzymał audyt?#

Pięć własności, i żadna z nich nie jest opcjonalna: bez którejkolwiek dokumentacja przewraca się na kolejnym pytaniu. Regułę, która je streszcza, da się zapisać w jednym zdaniu — brak odczytu jest brakiem dowodu, a nie dowodem korzystnym.

Dowód bez daty nie dowodzi niczego o okresie. Dowód nadpisany przez kolejny — pulpit pokazujący wyłącznie ostatni odczyt — gubi ślad chwili, w której zabezpieczenie przestało się utrzymywać, a to właśnie tej informacji szuka audytor. I dzień bez pomiaru nigdy nie może być domyślnie liczony jako dzień zgodny, ponieważ pierwszy audytor, który to zauważy, podważy całą resztę dokumentacji, łącznie z tymi jej częściami, które były rzetelne.

Własność najczęściej pomijana to mianownik. Zdanie „park jest zgodny” brzmi mocniej niż „zgodnych jest 51 z 53 stacji”, a jest od niego znacznie słabsze, bo nie da się go zakwestionować ani potwierdzić. Wskaźnik procentowy bez populacji, na której go policzono, można podnieść, nie poprawiając niczego — wystarczy zawęzić zakres pomiaru. Audytor, który zna ten mechanizm, zapyta o mianownik przed procentem.

Jak konkretnie wygląda odczyt dowodowy?#

Jak jeden wiersz na pomiar, a nie jak dokument. Poniżej minimalna postać serii nadającej się do wykorzystania dla jednego zabezpieczenia — wymuszenia MFA na kontach Microsoft 365 jednego klienta — na przestrzeni kilku dni.

Sześć wierszy, a cała historia jest już czytelna. Czternastego marca jedno konto wypadło z zakresu MFA. Piętnastego zbieranie nie zadziałało — i wiersz to mówi, zamiast po cichu powtórzyć wartość z dnia poprzedniego. Szesnastego powstało nowe konto, co wyjaśnia, dlaczego mianownik rośnie z 52 do 53 i dlaczego pokrycie spada jeszcze niżej, mimo że nikogo dodatkowo nie wyłączono. Siedemnastego różnica zostaje usunięta.

Zrzut ekranu wykonany 17 marca pokazałby 100% i byłby całkowicie rzetelny. Wymazałby jednocześnie trzy poprzedzające dni, w tym ten, w którym zbieranie nie zadziałało — czyli jedyny punkt dokumentacji, o którego wyjaśnienie poprosi Państwa sumienny audytor.

Wiersz z 15 marca zasługuje na osobną uwagę, bo to on odróżnia serię odczytów od raportu. Kusi, żeby go pominąć: wygląda jak usterka narzędzia, a nie jak fakt dotyczący bezpieczeństwa klienta. Pominięcie go zmieniłoby jednak charakter całego zbioru — z zapisu tego, co zmierzono, w zapis tego, co udało się zmierzyć, a to dwie różne rzeczy. Zbiór, który przemilcza własne braki, przestaje być weryfikowalny dokładnie w tym punkcie, w którym audytor zacznie go sprawdzać.

Co audytor robi z serią datowanych odczytów?#

Trzy rzeczy, w tej kolejności, i lepiej mieć je przewidziane. Najpierw sprawdza mianownik: skąd bierze się liczba 52, jak konstruowany jest zakres i co by się stało, gdyby jakaś stacja nie figurowała w żadnej ewidencji. Wskaźnik zgodności liczony na populacji, którą sami Państwo dobierają, nie ma waloru dowodowego, i to jest pierwsza rzecz, jaką testuje doświadczony audytor.

Następnie próbkuje. Bierze dwie albo trzy daty z okresu i prosi, żeby odnaleźć u źródła stan, o którym mówi Państwa odczyt. Jeżeli wiersz z 14 marca mówi 51 na 52, audytor chce wiedzieć, którego konta brakowało i dlaczego. Seria odczytów, która nie pozwala zejść do szczegółu, nie przechodzi tego etapu.

Na koniec ogląda dziury i spadki — i tu intuicja wielu dostawców działa na opak. Krzywa na poziomie 100% przez trzysta sześćdziesiąt pięć dni, bez jednego zagłębienia, nie budzi zaufania: sugeruje, że pomiar niewiele mierzy. Seria, która pokazuje spadek 14 marca, jego przyczynę i usunięcie 17 marca, opisuje działający mechanizm nadzoru. Norma ISO/IEC 27001 przewiduje ten przypadek wprost w punkcie 10.2: stwierdzona niezgodność musi zostać podjęta, jej przyczyny zbadane, a działanie korygujące zachowane jako udokumentowana informacja. Udokumentowana i usunięta rozbieżność jest elementem zgodności, a nie przyznaniem się do winy.

Problemem nigdy nie jest rozbieżność. Problemem jest rozbieżność, którą odkrywa się w trakcie audytu, ponieważ nikt nie prowadził pomiaru.

Które zabezpieczenia da się odczytywać automatycznie, a których nie da się nigdy?#

Tylko część, i lepiej powiedzieć to wprost, niż pozwolić uwierzyć, że narzędzie zastępuje nadzór. Zabezpieczenia, których stan żyje w odpytywalnej konsoli, da się odczytywać w sposób ciągły; te, które opierają się na ludzkiej czynności albo na dokumencie, dowodzi się inaczej i nie istnieje dla nich żadna uczciwa automatyzacja.

Kolumna po prawej nie jest półśrodkiem: to ten sam wymóg zastosowany do dowodów innego rodzaju. Niedatowany protokół przeglądu uprawnień ma dokładnie tę samą wadę, co niedatowany zrzut ekranu z konsoli.

Wniosek praktyczny jest taki, że automatyzacja zmienia koszt zbierania dowodów, ale nie zmienia jego zakresu. Zabezpieczenia z górnej części tabeli przestają kosztować czas, bo odczytują się same; zabezpieczenia z dolnej części kosztują dokładnie tyle samo, co przedtem, i to one decydują o tym, czy dokumentacja jest kompletna. Dostawca, który zautomatyzował cztery pierwsze wiersze i uznał sprawę za zamkniętą, ma szybszy dostęp do połowy odpowiedzi, a nie komplet dowodów.

Co zbierać w sposób ciągły, zamiast odtwarzać to w chwili audytu?#

Regularne odczyty techniczne każdego zabezpieczenia, które da się zweryfikować automatycznie — wymuszone MFA, pomyślnie wykonana kopia zapasowa, obecny agent ochrony stacji roboczych, aktualne poprawki — przechowywane pojedynczo, a nie agregowane w jeden wskaźnik, który zaciera historię. Praktyczną różnicę łatwo sformułować: zamiast raz w roku odpowiadać „tak, MFA jest włączone”, mogą Państwo odpowiedzieć „MFA było wymuszone na co najmniej 95% stacji roboczych przez 91 z ostatnich 92 dni”, wraz z datą dnia, w którym wskaźnik spadł, i tym, co się tego dnia wydarzyło.

Druga odpowiedź jest weryfikowalna. Pierwsza nie jest — wymaga od audytora, by uwierzył Państwu na słowo, co nie jest ani jego rolą, ani Państwa rolą, by go o to prosić.

To samo rozumowanie dotyczy decyzji, a nie tylko pomiarów. Rejestr zgodności, który pokazuje wyłącznie swój stan bieżący, ma wadę pulpitu: nie mówi, kiedy dany wpis przeszedł ze statusu „niezgodne” do „zgodne”. Historia zachowująca stary status, nowy status i datę przełączenia odpowiada na pytanie, które audytor zadaje systematycznie — od jak dawna ta rozbieżność jest otwarta i co przez ten czas zrobiono.

Jak długo należy przechowywać te odczyty?#

Co najmniej przez okres objęty audytem, a w praktyce dłużej. Okres przeglądany w audycie ISO 27001 to zwykle miniony rok, ale długość cyklu certyfikacyjnego i dokładna zawartość audytów nadzoru zależą od schematu stosowanego przez jednostkę certyfikującą: to u niej trzeba pytać o okres do pokrycia, a nie w artykule na blogu. Po stronie ubezpieczeniowej pytanie wraca przy odnowieniu, czyli co roku, i dotyczy dwunastu poprzedzających miesięcy.

Praktyczna reguła, która chroni przed pomyłką: niech Państwo przechowują o jeden pełny okres więcej, niż wynosi to, o co proszą dziś. Dokumentacja, która zaczyna się dokładnie w dniu rozpoczęcia audytu, sprawia wrażenie — często niesprawiedliwe — skompletowanej na tę okazję. I niech Państwo zachowują odczyty w postaci, w jakiej powstały, wraz z ich pierwotnym znacznikiem czasu: eksport przerobiony, przeliczony albo przeformatowany w chwili audytu traci dokładnie tę własność, która czyniła z niego dowód.

Na tej zasadzie opiera się moduł ciągłego dryfu w Vigicap: każdy odczyt konektora jest zachowywany, nigdy nadpisywany, co pozwala przedstawić datowane pokrycie takie jak przytoczone wyżej, zamiast pojedynczego zrzutu ekranu. Rejestr zgodności działa według tej samej reguły: każda zmiana statusu celu zachowuje status stary, nowy i jego datę, zamiast zastępować wartość poprzednią.