Czym jest SZBI? Jak powiązać bezpieczeństwo z decyzjami biznesowymi

Praca w obszarze bezpieczeństwa może sprawiać wrażenie intensywnej, a mimo to nie być skoordynowana. Inżynierowie instalują poprawki, HR obsługuje odejścia, dział zakupów ocenia dostawców, a kierownictwo zatwierdza wyjątki. System zarządzania bezpieczeństwem informacji łączy te działania ze wspólnymi celami i jawnym procesem decyzyjnym.

Dla prezesa zarządu ważne pytanie nie brzmi, czy firma ma wystarczająco dużo dokumentów dotyczących bezpieczeństwa. Brzmi ono: czy kierownictwo potrafi wyjaśnić, co wymaga ochrony, które ryzyka mają znaczenie, kto za co odpowiada i dlaczego obecny poziom ochrony jest akceptowalny. SZBI sprawia, że odpowiedzi na te pytania są powtarzalne, także gdy firma się zmienia.

Czym faktycznie zarządza SZBI

System zarządzania bezpieczeństwem informacji to organizacyjny system zarządzania ryzykami w obszarze bezpieczeństwa informacji. Obejmuje obowiązki, polityki, procesy, zasoby, zabezpieczenia i ocenę. Oprogramowanie może go wspierać, ale nie jest tym systemem. Biblioteka dokumentów może go opisywać, ale same dokumenty nie dowodzą, że działa.

Jego celem jest ochrona trzech właściwości informacji:

• Poufność: informacje są dostępne wyłącznie dla upoważnionych osób i systemów.
• Integralność: informacje pozostają dokładne, kompletne i chronione przed niewłaściwą zmianą.
• Dostępność: upoważnieni użytkownicy mogą uzyskać informacje i korzystać z usług wspierających wtedy, gdy tego potrzebują.

Te właściwości przekładają się na kwestie biznesowe. Ujawnione dane klientów mogą podważyć zaufanie i rodzić obowiązki prawne. Błędne dyspozycje płatnicze mogą spowodować straty finansowe. Niedostępna platforma wsparcia może uniemożliwić firmie wywiązanie się ze zobowiązań wobec klientów.

ISO/IEC 27001 zawiera uznane wymagania dla SZBI o określonym zakresie. Rozdziały 4–10 dotyczą kontekstu organizacji, przywództwa, planowania, wsparcia, działań operacyjnych, oceny efektów działania i doskonalenia. Organizacja może zbudować i prowadzić SZBI, zanim zacznie ubiegać się o certyfikację.

System zarządzania zapewnia powiązanie między pojedynczymi zabezpieczeniami a decyzjami biznesowymi. Kopia zapasowa jest zabezpieczeniem. Decyzja, co musi dać się odtworzyć, sfinansowanie zdolności odtwarzania, jej testowanie i reagowanie na nieudane testy to praca w ramach systemu zarządzania.

Dlaczego kierownictwo potrzebuje tych powiązań

Decyzje dotyczące bezpieczeństwa już teraz zapadają w całej firmie, niezależnie od tego, czy nazywa się to SZBI. Ktoś wybiera dostawcę SaaS, zatwierdza dostęp uprzywilejowany, akceptuje opóźnioną poprawkę lub zobowiązuje się wobec klienta do określonego czasu odtworzenia. Bez wspólnego procesu decyzje te mogą opierać się na różnych założeniach, a nikt nie odpowiada za ich łączny skutek.

SZBI daje kierownictwu podstawę do ustalania priorytetów przy ograniczonych zasobach. Pomaga też zespołom odpowiadać na pytania klientów na podstawie utrzymywanych zapisów, zamiast odtwarzać swoje praktyki przy każdym przeglądzie sprzedażowym. Nie gwarantuje to pomyślnego wyniku postępowania zakupowego, ale sprawia, że stojące za nim twierdzenia są lepiej udokumentowane.

Powiązania powinny odpowiadać na praktyczne pytania:

Te powiązania mają szczególne znaczenie w okresie wzrostu. Nieformalne praktyki, które działają, gdy wszyscy się znają, stają się zawodne, gdy pojawiają się nowe zespoły, lokalizacje, dostawcy i zobowiązania wobec klientów.

Określ zakres odzwierciedlający działalność firmy

Zacznij od kontekstu biznesowego, a nie od listy zabezpieczeń. Zidentyfikuj usługi świadczone przez organizację, wykorzystywane przez nie informacje, zainteresowane strony i ich wymagania oraz wewnętrzne i zewnętrzne warunki wpływające na bezpieczeństwo.

Zakres wyznacza granicę SZBI. Powinien wskazywać objęte działania, jednostki organizacyjne, w stosownych przypadkach lokalizacje, technologię oraz styki z innymi częściami firmy. Użyteczny pierwszy zakres może obejmować produkt dla klientów i operacje związane z jego dostarczaniem, a nie każdą działalność firmy.

Skoncentrowany zakres nie może jednak ignorować zależności. Jeżeli HR rozpoczyna proces odejścia pracowników mających dostęp do produktu, ten styk ma znaczenie. Jeżeli usługę hostuje dostawca chmury, outsourcing nie sprawia, że zależność znika. Jeżeli dział wsparcia eksportuje informacje o klientach, proces eksportu należy do analizy.

Napisz deklarację zakresu, a następnie zweryfikuj ją trzema pytaniami:

• Czy klient zrozumiałby, co jest objęte zakresem, a co nie?
• Czy uwzględniliśmy zależności niezbędne do ochrony objętej usługi?
• Czy wskazani właściciele są w stanie utrzymywać system w tej granicy?

Rozpoczęcie od małego zakresu to praktyczna rekomendacja, a nie zgoda na wyznaczenie mylącej granicy. Jasny zakres z odpowiedzialnymi właścicielami jest mocniejszy niż obszerny rejestr, którego nikt nie aktualizuje. Rozszerzaj go świadomie, gdy uzasadniają to nowe usługi lub zależności.

Przypisuj decyzje, a nie tylko zadania

Najwyższe kierownictwo musi zapewniać ukierunkowanie i wsparcie dla SZBI zgodnego z ISO 27001. Delegowanie koordynacji na lidera ds. bezpieczeństwa nie przenosi odpowiedzialności kierownictwa za priorytety, zasoby i akceptowalne ryzyko.

Rozdziel obowiązki, które często łączy się w zakresie zadań jednej osoby:

Mała firma może przypisać kilka obowiązków jednej osobie. Nadal powinna jednak wskazać, w jakiej roli ta osoba występuje i gdzie potrzebna jest niezależna weryfikacja, zwłaszcza w przypadku audytu wewnętrznego.

Określ progi eskalacji. Lider zespołu może zatwierdzić krótkotrwały wyjątek operacyjny w uzgodnionych granicach; ryzyko zagrażające kluczowym zobowiązaniom wobec klientów może wymagać zatwierdzenia przez zarząd. Zapisz uzasadnienie, warunki, datę wygaśnięcia i wyzwalacz przeglądu. Formuła „zaakceptowane przez kierownictwo” nie wystarcza, jeżeli nikt nie potrafi wskazać osoby decydującej ani zaakceptowanej ekspozycji.

Przekształć ocenę ryzyka w proces ustalania priorytetów

Ocena ryzyka powinna opisywać prawdopodobne scenariusze, a nie tylko wymieniać aktywa lub słabości. „Baza danych klientów” to aktywo. „Przejęte konto administratora umożliwia masowe wyprowadzenie danych klientów” to scenariusz ryzyka z przyczyną i skutkiem.

Ustal udokumentowaną metodę oceny i kryteria akceptacji ryzyka. ISO 27001 nie wymaga jednej konkretnej formuły punktacji. W praktyce warto zdefiniować kategorie prawdopodobieństwa i skutków językiem zrozumiałym dla decydentów, uwzględniając zakłócenia operacyjne, straty finansowe, konsekwencje umowne oraz, w stosownych przypadkach, szkody dla osób fizycznych.

Dla każdego istotnego scenariusza zapisz:

• Usługę, informacje i zależności, których dotyczy.
• Zagrożenie lub zdarzenie oraz istotne podatności.
• Istniejące zabezpieczenia i ich znane ograniczenia.
• Prawdopodobieństwo, skutki i wynikający z nich priorytet.
• Właściciela ryzyka i proponowane postępowanie.

Postępowanie z ryzykiem może polegać na ograniczeniu ekspozycji za pomocą zabezpieczeń, unikaniu danej działalności, dzieleniu się częścią ryzyka za pośrednictwem umów lub ubezpieczeń albo akceptacji ryzyka w ramach zatwierdzonych kryteriów. Ubezpieczenie nie przywraca utraconych informacji, a umowa z dostawcą nie znosi obowiązków organizacji.

Odróżniaj ryzyko bieżące od ryzyka szczątkowego po postępowaniu. Nie obniżaj oceny tylko dlatego, że zaplanowano zadanie. Oceń ryzyko ponownie po wdrożeniu i uzyskaniu odpowiednich dowodów działania. Uzyskaj zatwierdzenie planu postępowania z ryzykiem i akceptację ryzyka szczątkowego przez osobę mającą określone uprawnienia.

Operacyjny rejestr ryzyka powinien pozostać zapisem decyzji: co się zmieniło, dlaczego wybrano dane postępowanie i kiedy ocena wymaga przeglądu.

Dobierz zabezpieczenia i wyjaśnij ich zastosowanie

Zabezpieczenia to środki służące modyfikowaniu ryzyka. Obejmują zabezpieczenia techniczne, takie jak uwierzytelnianie wieloskładnikowe, procesy organizacyjne, takie jak przeglądy dostawców, środki dotyczące ludzi, takie jak szkolenia, oraz fizyczną ochronę urządzeń i pomieszczeń.

Załącznik A do ISO/IEC 27001:2022 zawiera 93 zabezpieczenia referencyjne: 37 organizacyjnych, 8 osobowych, 14 fizycznych i 34 technologiczne. Dobór opiera się na ryzyku; organizacja nie wdraża automatycznie każdego zabezpieczenia. ISO/IEC 27002 zawiera wytyczne wdrożeniowe, a nie odrębne wymaganie certyfikacyjne dla SZBI.

W przypadku ISO 27001 określ zabezpieczenia niezbędne do postępowania z ryzykiem i porównaj je z Załącznikiem A, aby sprawdzić, czy nie pominięto żadnego niezbędnego zabezpieczenia. Zabezpieczenia mogą być też niezbędne ze względu na wymagania prawne lub umowne i nie muszą ograniczać się do Załącznika A.

Deklaracja stosowania zawiera niezbędne zabezpieczenia, uzasadnienie ich uwzględnienia, status wdrożenia oraz uzasadnienie wyłączenia zabezpieczeń z Załącznika A. Różni się od planu postępowania z ryzykiem: pierwsza wyjaśnia zestaw mających zastosowanie zabezpieczeń, drugi działania potrzebne do postępowania z ryzykami. Tę strukturę odniesienia omawia przewodnik po zabezpieczeniach z Załącznika A.

Dla każdego wybranego zabezpieczenia określ właściciela, zamierzony rezultat, sposób działania i dowody, które wykażą skuteczność. „Wdrożono kontrolę dostępu” jest mniej użyteczne niż jawny proces obejmujący zatwierdzanie, nadawanie, przegląd i odbieranie uprawnień.

Polityki powinny ustanawiać zasady, których ludzie mogą przestrzegać. Procedury powinny wyjaśniać sposób wykonania. Żadne z nich nie powinny obiecywać przeglądów ani ograniczeń technicznych, których organizacja nie jest w stanie faktycznie utrzymać.

Wbuduj dowody w codzienne działanie

Dowody powinny powstawać w trakcie wykonywania pracy, a nie przez odtwarzanie historii przed audytem. Przegląd dostępu może dać datowaną listę użytkowników, decyzje osób weryfikujących, zgłoszenia usunięcia i potwierdzenie, że zmiany nastąpiły. Ćwiczenie odtworzeniowe może dać warunki testu, wyniki, zaobserwowane ograniczenia i działania następcze.

Zrzut ekranu może pokazywać ustawienie w jednym momencie. Nie musi dowodzić, że ustawienie obejmuje każdy właściwy system lub pozostawało skuteczne przez cały okres. Osoby weryfikujące powinny badać zakres, datę, źródło, kompletność i to, jaki wniosek dowód faktycznie potwierdza.

Praktyczny zestaw dowodów SZBI obejmuje:

Nie każdy wiersz wymaga osobnego dokumentu. Mała organizacja może łączyć zapisy, o ile zachowana jest przejrzystość i identyfikowalność. Chroń same dowody: eksporty użytkowników, zapisy incydentów i zrzuty ekranu mogą zawierać wrażliwe informacje i powinny podlegać odpowiednim zasadom dostępu i przechowywania.

Przykład: platforma obsługi klienta

Weźmy przykładową firmę programistyczną zatrudniającą 30 osób, która korzysta z platformy wsparcia klienta w modelu SaaS. Załóżmy, że platforma przechowuje imiona i nazwiska klientów, dane kontaktowe, historie zgłoszeń i sporadycznie załączniki diagnostyczne. Pracownicy korzystają z indywidualnych kont, aplikację hostuje zewnętrzny dostawca, a niektóre zgłoszenia są eksportowane w celu rozwiązywania problemów. Są to założenia przykładu, a nie zalecany model firmy.

Zakres SZBI obejmuje obsługę klienta i jej zależności: tożsamość pracowników, dostawcę SaaS, dostęp z urządzeń końcowych, eksporty, przechowywanie i rozwiązania odtworzeniowe. Kierownik działu wsparcia jest właścicielem usługi; IT obsługuje kontrolę dostępu; dział zakupów koordynuje przegląd dostawcy; kierownictwo zatwierdza ryzyka przekraczające delegowane uprawnienia.

Wstępna ocena identyfikuje trzy scenariusze:

Załóżmy, że uzgodnienie kont wykazuje, iż były pracownik nadal ma dostęp. Działaniem natychmiastowym jest odebranie dostępu i ocena, czy konto zostało niewłaściwie wykorzystane. Działaniem w ramach systemu zarządzania jest ustalenie, dlaczego odebranie dostępu zawiodło. Być może HR powiadomił IT, ale aplikacji wsparcia brakowało na liście kontrolnej odejść.

Działanie korygujące aktualizuje następnie inwentarz aplikacji, dodaje platformę wsparcia do procesu odejścia, przypisuje odpowiedzialność za potwierdzenie i sprawdza kolejne odejścia. Samo zamknięcie zgłoszenia usunięcia dostępu rozwiązałoby bieżący problem, nie usuwając jego przyczyny.

Załóżmy teraz, że dostawca SaaS zmienia listę podwykonawców przetwarzania. Właściciel relacji z dostawcą ocenia zmianę pod kątem wymagań umownych, bezpieczeństwa i właściwych wymagań dotyczących prywatności. Zapisuje, czy wpływa ona na postępowanie z danymi, zależności lub zaakceptowane ryzyko oraz czy potrzebna jest ocena specjalisty. Zmiana ma właściciela i ścieżkę przeglądu, zamiast pozostać nieprzeczytana we wspólnej skrzynce pocztowej.

Kierownictwo otrzymuje nierozstrzygnięte decyzje: czy sfinansować solidniejsze rozwiązanie zapasowe, ograniczyć ilość informacji zbieranych w załącznikach, czy zaakceptować określoną pozostałą ekspozycję. Tak właśnie SZBI łączy ustalenia operacyjne z wyborami biznesowymi.

Utrzymuj rytm, który pozwala wykrywać zmiany

Planuj przeglądy zgodnie z ryzykiem, częstotliwością zmian i obowiązkami. Cotygodniowy przegląd luk w początkowej fazie wdrożenia i okresowy przegląd zarządzania mogą być praktycznymi wyborami, ale nie są to uniwersalne interwały narzucone przez ISO 27001. Norma wymaga audytów wewnętrznych i przeglądów zarządzania w zaplanowanych odstępach czasu.

Dodaj wyzwalacze zdarzeniowe: incydenty, duże wydania, przejęcia, zmiany dostawców, nowe obowiązki prawne, istotne zobowiązania wobec klientów i ustalenia z audytów. Sam kalendarz przeoczy ważne zmiany zachodzące między zaplanowanymi spotkaniami.

Monitorowanie sprawdza, czy zabezpieczenia i cele działają zgodnie z zamierzeniami. Audyt wewnętrzny ocenia, czy SZBI jest zgodny z wymaganiami oraz skutecznie wdrożony i utrzymywany. Przegląd zarządzania ocenia przydatność, adekwatność i skuteczność systemu oraz prowadzi do decyzji o zmianach i zasobach. Działania te wzajemnie się zasilają, ale nie są zamienne.

Kierownictwo powinno otrzymywać informacje gotowe do podjęcia decyzji: istotne ryzyka, zaległe działania, powtarzające się niepowodzenia, ustalenia z audytów, zmieniające się wymagania i ograniczenia zasobów. Liczenie ukończonych zadań bez badania rezultatów może ukrywać słabe wyniki. Przydatne miary omawia przewodnik po wskaźnikach SZBI.

Zarządzanie incydentami również należy do tego cyklu. Zdefiniuj ścieżki zgłaszania, kryteria oceny, obowiązki w zakresie reagowania, uprawnienia do komunikacji i rozwiązania odtworzeniowe. Testuj ścieżki kontaktu i podejmowanie decyzji w ramach ćwiczeń. Oceniaj mające zastosowanie obowiązki powiadamiania, zamiast zakładać, że jeden termin obejmuje każdy incydent.

Po incydencie lub niezgodności rozwiąż bieżący problem, zbadaj przyczyny, wdróż działanie korygujące i oceń jego skuteczność. Powtarzające się ustalenia są powodem do ponownego przemyślenia projektu procesu lub zasobów, a nie do powtarzania tego samego przypomnienia.

Oddziel SZBI, certyfikację i obowiązki prawne

SZBI to system, który prowadzi organizacja. ISO 27001 to norma, według której system ten może zostać oceniony. Certyfikat wydaje niezależna jednostka certyfikująca, a nie ISO ani Secani, i dotyczy on określonego zakresu.

Certyfikacja może być użytecznym mechanizmem zapewnienia, gdy wymagają jej klienci lub inni interesariusze. Nie dowodzi jednak, że objęta jest każda działalność firmy, że każde zabezpieczenie zawsze działa ani że incydenty nie mogą się zdarzyć. Sprawdzaj zakres i status, zamiast traktować certyfikat jako gwarancję bezpieczeństwa całej firmy.

Stosowanie przepisów prawa wymaga odrębnej analizy. Art. 32 RODO wymaga odpowiednich środków technicznych i organizacyjnych dostosowanych do istotnych ryzyk. NIS2 reguluje nadzór kierownictwa, środki zarządzania ryzykiem i zgłaszanie incydentów przez objęte podmioty za pośrednictwem przepisów krajowych.

SZBI może porządkować dowody i obowiązki wspierające realizację takich wymogów, ale certyfikacja nie przesądza o zgodności z RODO ani NIS2. Nie jest też prawdą, że SZBI nigdy nie może być wymagany prawem: należy sprawdzić mające zastosowanie przepisy krajowe lub sektorowe.

Unikaj trzech przewidywalnych błędów wdrożeniowych

Przyjmowanie szablonów bez zmian. Szablony mogą zapewnić strukturę, ale właściciele muszą zweryfikować każde zobowiązanie w odniesieniu do rzeczywistej praktyki. Polityka wymagająca przeglądów, których nikt nie przeprowadza, tworzy niezarządzaną lukę.

Wyznaczanie granicy, której nikt nie jest w stanie utrzymać. Ambitny inwentarz nie jest użyteczny, jeśli odpowiedzialność i zależności są niejasne. Zacznij od granicy usługi, której da się bronić, a następnie rozszerzaj ją według jawnego planu.

Traktowanie certyfikacji jako mety. System musi działać dalej mimo zmian personelu, zmian dostawców, incydentów i nowych produktów. Planuj budżet na działanie, przeglądy i doskonalenie, a nie tylko na początkową dokumentację.

Powiązanym ostrzeżeniem jest automatyzacja bez przeglądu. Automatycznie zbierane zapisy i podsumowania generowane przez AI mogą wspierać pracę, ale to ludzie nadal muszą ocenić istotność, zbadać luki i zatwierdzić wnioski.

Nadaj pierwszej decyzji kierownictwa konkretny kształt

Wybierz jedną reprezentatywną usługę i poproś jej właściciela o przygotowanie deklaracji zakresu, mapy zależności, wstępnych scenariuszy ryzyka, obecnych zabezpieczeń i nierozstrzygniętych decyzji. Uzgodnijcie, kto może akceptować ryzyko, jakie zasoby są dostępne i kiedy postęp zostanie poddany przeglądowi. Tworzy to wykonalny punkt wyjścia bez udawania, że cała organizacja jest już objęta systemem.

Model przestrzeni roboczej Secani wspiera ten sposób pracy przez modelowanie usług i wspierających je obiektów docelowych, łączenie dowodów z wymaganiami, zabezpieczeniami i decyzjami oraz przypisywanie właścicieli i odpowiedzialności za przegląd. Zespoły mogą przekształcać brakujące dowody lub niejasną odpowiedzialność w zadania. Sugestie przygotowane z pomocą AI pozostają wersjami roboczymi do przeglądu przez człowieka, a źródła i zatwierdzenia pozostają identyfikowalne.

Następna rozmowa kierownictwa powinna więc być konkretna: którą usługę chronimy najpierw, jaka ekspozycja wymaga decyzji już teraz i jakie dowody pokażą, że ta decyzja przyniosła efekt?