Kto odpowiada za wykrycie incydentu — podział ról między IT, dostawcą i zarządem

W rozmowach o bezpieczeństwie regularnie pojawia się zdanie, że po podpisaniu umowy z dostawcą temat jest zamknięty. Przekonanie to nie wynika z niedbałości, lecz z analogii do innych obszarów, w których outsourcing rzeczywiście zdejmuje z organizacji ciężar operacyjny i znaczną część ryzyka.

Analogia zawodzi, ponieważ w obszarze bezpieczeństwa i zgodności regulacje adresują obowiązek do podmiotu, a nie do wykonawcy czynności. Organ nadzoru nie prowadzi postępowania wobec dostawcy usługi monitorowania, lecz wobec podmiotu, który miał obowiązek zapewnić określony poziom zabezpieczeń.

Skutkiem tego nieporozumienia jest luka pojawiająca się w najgorszym możliwym miejscu. Organizacja zakłada, że ktoś patrzy, dostawca robi dokładnie to, do czego zobowiązała go umowa, a różnica między jednym a drugim ujawnia się dopiero podczas zdarzenia.

Podobny mechanizm działa wewnątrz organizacji, między działami. Bezpieczeństwo bywa uznawane za sprawę zespołu informatycznego, ten zaś traktuje je jako element zarządzania ryzykiem, czyli obszar zarządczy. Luka powstaje dokładnie w miejscu, w którym obie strony patrzą na siebie nawzajem.

Warto dodać, że przekonanie to bywa wzmacniane przez sposób, w jaki usługi bezpieczeństwa są sprzedawane. Język ofert mówi o przejęciu odpowiedzialności, choć załączona do nich umowa mówi o świadczeniu określonych czynności w określonych godzinach. Rozbieżność między tymi dwoma dokumentami jest punktem wyjścia całej tej rozmowy.

Skala nieporozumienia bywa widoczna już przy pierwszym pytaniu kontrolnym. Wystarczy zapytać, kto po stronie organizacji przeczytał ostatni raport dostawcy i jakie wnioski z niego wyciągnięto. Odpowiedź brzmiąca, że raporty przychodzą regularnie, jest w istocie odpowiedzią, że nikt ich nie czyta.

Większość sporów o role wynika z używania jednego słowa w trzech różnych znaczeniach. Rozdzielenie ich porządkuje rozmowę szybciej niż jakakolwiek macierz kompetencji.

Pierwsze znaczenie to odpowiedzialność za wykonanie: kto faktycznie wykonuje czynność, patrzy na sygnał, aktualizuje regułę, przegląda uprawnienia. To jedyny poziom, który w całości daje się powierzyć na zewnątrz.

Drugie to odpowiedzialność za nadzór: kto sprawdza, czy czynność została wykonana i czy została wykonana dobrze. Ten poziom można wesprzeć z zewnątrz, ale nie można go w całości oddać wykonawcy, ponieważ oznaczałoby to ocenianie własnej pracy.

Trzecie to odpowiedzialność wobec otoczenia: kto odpowiada przed regulatorem, klientem i sądem. Ten poziom nie podlega przeniesieniu żadną umową — umowa może jedynie regulować rozliczenia między stronami po fakcie.

Rozdzielenie to ma bezpośrednie przełożenie na sposób opisania ról w dokumentacji. Zamiast jednej rubryki z nazwą stanowiska powstają trzy, a puste miejsce w kolumnie nadzoru staje się widoczne od razu. W praktyce to właśnie ta kolumna bywa najczęściej niewypełniona.

Nowsze regulacje dotyczące cyberbezpieczeństwa wprost adresują obowiązki do organu zarządzającego, zamiast pozostawiać je w warstwie technicznej. Kierownictwo zatwierdza środki zarządzania ryzykiem, nadzoruje ich wdrożenie i ma obowiązek odbycia szkolenia pozwalającego te kwestie ocenić.

Konstrukcja ta jest celowa i wynika z obserwacji, że decyzje o zasobach zapadają na poziomie zarządczym, a skutki ich braku ujawniają się na poziomie technicznym. Przypisanie obowiązku wyłącznie zespołowi IT prowadziło do sytuacji, w której osoba odpowiedzialna nie dysponowała środkami do jego wykonania.

Praktycznym skutkiem jest to, że dokumentacja bezpieczeństwa musi zawierać ślad decyzji kierownictwa. Zatwierdzona analiza ryzyka, przyjęta polityka, świadoma akceptacja ryzyka pozostałego — to są dowody wykonania obowiązku, a nie formalność.

Z tego wynika też wskazówka dotycząca języka. Materiały przedstawiane zarządowi muszą pozwalać na podjęcie decyzji osobie nietechnicznej. Raport, którego zarząd nie rozumie, nie jest dowodem sprawowania nadzoru, choćby był merytorycznie doskonały.

Warto również zadbać o ślad samego posiedzenia. Zapis w protokole, że zarząd zapoznał się z oceną ryzyka i podjął określone decyzje, jest dokumentem o innej wadze niż prezentacja przesłana pocztą elektroniczną. Przy ocenie wykonania obowiązku liczy się dowód rozpatrzenia sprawy, nie fakt jej zakomunikowania.

Zespół odpowiedzialny za utrzymanie systemów jest naturalnym wykonawcą znacznej części czynności związanych z bezpieczeństwem. Ma dostęp, zna środowisko i to on wprowadza zmiany w konfiguracji.

Jego podstawowym celem jest jednak dostępność usług, a cel ten bywa w bezpośrednim konflikcie z celami bezpieczeństwa. Wyłączenie podatnego systemu, wymuszenie ponownego uwierzytelnienia czy wprowadzenie restrykcyjnej reguły to działania obniżające dostępność w krótkim okresie.

Konflikt ten nie jest wadą zespołu ani przejawem złej woli, lecz naturalną konsekwencją przypisanych celów. Rozwiązuje się go nie apelem o współpracę, lecz rozdzieleniem ról: ktoś inny powinien oceniać ryzyko i rekomendować działanie, a ktoś inny je wykonywać.

W mniejszych organizacjach pełne rozdzielenie bywa niewykonalne kadrowo. Wtedy rozwiązaniem jest zapewnienie oceny z zewnątrz — okresowego, niezależnego spojrzenia na to, czy przyjęte kompromisy między dostępnością a bezpieczeństwem są nadal uzasadnione.

Pomocne bywa również nazwanie tego konfliktu wprost w dokumentacji. Zapis wskazujący, że rekomendacja pochodzi z jednego źródła, a decyzja o jej wdrożeniu należy do innego, zdejmuje z zespołu utrzymaniowego ciężar rozstrzygania sporu, w którym z natury rzeczy jest stroną.

Dostawca monitorowania odpowiada za to, do czego zobowiązał się w umowie: obserwację uzgodnionych źródeł, rozpoznanie zdarzeń określonego typu i przekazanie informacji w uzgodnionym czasie. Jest to rola wykonawcza i w tym zakresie w pełni przenoszalna.

Poza tym zakresem dostawca nie odpowiada za nic, i jest to stan normalny, nie uchybienie. Nie odpowiada za systemy nieobjęte umową, za zdarzenia typu, którego nie uzgodniono, ani za skutki tego, że organizacja nie odebrała przekazanej informacji.

Z perspektywy organizacji istotne jest więc nie tyle zaufanie do dostawcy, ile znajomość granic jego zobowiązania. Największe luki powstają nie tam, gdzie dostawca pracuje źle, lecz tam, gdzie obie strony założyły, że dana czynność należy do drugiej.

Osobną kwestią jest to, kto po stronie organizacji rozmawia z dostawcą na poziomie merytorycznym. Jeżeli nie ma nikogo, kto potrafi ocenić jakość jego pracy, nadzór sprowadza się do przyjmowania raportów i potwierdzania, że usługa jest świadczona.

Warto też pamiętać, że dostawca zna wyłącznie tę część środowiska, którą mu pokazano. Zmiany wprowadzane po stronie organizacji — nowy system, zmiana architektury, przejęcie innej spółki — pozostają poza jego obrazem, dopóki ktoś ich nie zgłosi. Obowiązek zgłaszania takich zmian należy do organizacji i powinien być komuś przypisany.

Uczestnikiem pomijanym w tych rozmowach najczęściej jest właściciel procesu, czyli osoba odpowiadająca za obszar działalności wspierany przez dany system. Tymczasem to on dysponuje wiedzą przesądzającą o ocenie zdarzenia.

Tylko właściciel procesu potrafi powiedzieć, czy niedostępność systemu przez określony czas zatrzymuje działalność, czy jest niedogodnością. Tylko on wie, czy operacja wykonana w nietypowej porze jest elementem procedury, czy anomalią. Bez tej wiedzy ocena zdarzenia opiera się na przesłankach technicznych, które bywają mylące.

Włączenie właścicieli procesów do rozmowy o bezpieczeństwie zmienia również charakter decyzji o ryzyku. Przestaje ona być decyzją techniczną, a staje się decyzją o akceptowalnym poziomie zakłócenia działalności — czyli decyzją, którą właściciel procesu podejmuje na co dzień w innych obszarach.

Praktycznym krokiem jest przypisanie właściciela do każdego systemu w inwentaryzacji. Brak tego przypisania jest zwykle pierwszą przeszkodą przy ustalaniu priorytetów, ponieważ nie ma kogo zapytać o wagę zasobu.

Przypisanie to warto potwierdzić u samego zainteresowanego. Właściciel wskazany w tabeli, który o swojej roli nie wie, jest zapisem formalnym bez skutku praktycznego — a takich zapisów w dokumentacji bezpieczeństwa bywa więcej, niż wynikałoby to z jej wyglądu.

Część zdarzeń uruchamia obowiązki wykraczające poza obszar techniczny. Naruszenie ochrony danych osobowych prowadzi do odrębnej ścieżki, z własnym adresatem, własnym zakresem informacji i własnym terminem.

Rola inspektora ochrony danych lub działu prawnego polega tu na ocenie, czy zdarzenie tę ścieżkę uruchamia, oraz na przygotowaniu zgłoszenia. Ocena ta wymaga informacji technicznej, ale sama nie jest oceną techniczną.

Z podziału tego wynika konkretny wymóg wobec procedury: musi ona zawierać punkt, w którym zdarzenie trafia do oceny pod kątem danych osobowych, oraz wskazywać, kto tę ocenę przeprowadza. Brak takiego punktu prowadzi do sytuacji, w której obie ścieżki czekają na siebie nawzajem.

Dodatkowym elementem bywa komunikacja zewnętrzna. Decyzja o tym, co i kiedy powiedzieć klientom oraz mediom, należy do kierownictwa i powinna być przygotowana wcześniej, a nie formułowana w trakcie zdarzenia przez osobę, która akurat odebrała telefon.

Klasyfikacja zdarzenia jako poważnego uruchamia obowiązki wobec organu, więc jest decyzją o skutkach prawnych. Z tego powodu należy do organizacji, nawet jeżeli materiał do jej podjęcia dostarcza dostawca zewnętrzny.

Rozdzielenie to bywa źródłem nieporozumień w praktyce. Dostawca ocenia zdarzenie w kategoriach technicznych i przypisuje mu priorytet operacyjny, co nie jest tożsame z oceną, czy spełnione zostały przesłanki regulacyjne. Dwie różne skale bywają mylone, zwłaszcza gdy obie używają słowa krytyczny.

Praktycznym rozwiązaniem jest wskazanie po stronie organizacji osoby uprawnionej do klasyfikacji wraz z zastępstwem oraz wyposażenie jej w progi opisane w kategoriach biznesowych. Decyzja podejmowana bez progów, pod presją czasu, bywa później trudna do obrony.

Osoba ta powinna mieć również mandat do uruchomienia procedury bez uzyskiwania zgody wyższego szczebla. Wymóg konsultacji przed pierwszym zgłoszeniem jest w praktyce równoznaczny z opóźnieniem, ponieważ zdarzenia rzadko wybierają godziny, w których zarząd jest dostępny.

Warto również zapisać, że w razie wątpliwości zdarzenie klasyfikuje się wyżej. Koszt zgłoszenia zdarzenia, które okazało się mniej istotne, jest nieporównanie niższy od kosztu uchybienia terminowi.

Zasada ta wymaga jednak wsparcia kierownictwa wyrażonego wcześniej i na piśmie. Osoba, która obawia się, że zostanie rozliczona z niepotrzebnego zgłoszenia, będzie zwlekać — i będzie to zachowanie racjonalne w układzie, w jakim ją postawiono.

Każda organizacja funkcjonuje z pewnym poziomem ryzyka nieusuniętego, ponieważ usunięcie wszystkiego nie jest ani możliwe, ani ekonomicznie uzasadnione. Różnica przebiega między ryzykiem zaakceptowanym świadomie a ryzykiem, którego nikt nie zauważył.

Akceptacja wymaga trzech elementów: opisu ryzyka w kategoriach skutku dla działalności, wskazania kosztu jego ograniczenia oraz podpisu osoby uprawnionej do podjęcia takiej decyzji. Bez trzeciego elementu jest to notatka, nie decyzja.

Zapis akceptacji ma wartość również dla zespołu technicznego, choć bywa odbierany jako biurokracja. Chroni go przed sytuacją, w której po zdarzeniu okazuje się, że decyzję o niewdrożeniu zabezpieczenia podjął ktoś, kto tego nie pamięta.

Akceptacja powinna mieć także termin ważności. Ryzyko przyjęte jako akceptowalne dwa lata temu, przy innym profilu działalności i innej skali zagrożenia, wymaga ponownego rozważenia, a nie milczącego przedłużenia.

Przy okazji przeglądu warto sprawdzić, czy założenia leżące u podstaw akceptacji są nadal prawdziwe. Ryzyko przyjęte dlatego, że dany system miał zostać wycofany w ciągu roku, wygląda inaczej po trzech latach jego dalszej eksploatacji.

Powszechnym układem w mniejszych organizacjach jest powierzenie tej samej osobie lub temu samemu dostawcy zarówno wykonania zabezpieczeń, jak i oceny ich skuteczności. Rozwiązanie to jest tańsze i wygodne operacyjnie, ma jednak wbudowaną wadę.

Ocena własnej pracy rzadko bywa surowa i nie jest to kwestia uczciwości, lecz perspektywy. Osoba, która projektowała rozwiązanie, ocenia je przez pryzmat założeń, które sama przyjęła, i nie ma powodu tych założeń kwestionować.

Skutek widać w dokumentacji: raporty z przeglądów, w których od lat nie odnotowano istotnego uchybienia, przy jednoczesnym braku zmian w środowisku, który by to tłumaczył. Jest to sygnał do zewnętrznej weryfikacji, a nie dowód dojrzałości.

Rozwiązaniem nie musi być rozbudowa zespołu. Wystarczy, że ocena pochodzi od podmiotu, który nie wykonywał ocenianych prac i nie sprzedaje narzędzi mających je naprawić.

Ten sam warunek dotyczy oceny dostawców. Podmiot rekomendujący wybór usługodawcy i jednocześnie pobierający od niego wynagrodzenie prowizyjne nie jest w stanie wydać oceny niezależnej, niezależnie od własnych intencji. Pytanie o model wynagrodzenia doradcy jest więc pytaniem merytorycznym, a nie nietaktem.

Większość dokumentów opisujących role jest napisana z perspektywy dnia roboczego i przestaje działać dokładnie wtedy, gdy jest potrzebna. Zdarzenia nie respektują godzin pracy, a znaczna ich część ujawnia się wieczorem lub w dni wolne.

Użyteczny zapis odpowiada na cztery pytania: kto podejmuje decyzję, kto go zastępuje, jakim kanałem należy tę osobę powiadomić i w jakim czasie oczekuje się odpowiedzi. Zapis bez zastępstwa jest zapisem połowicznym.

Drugim wymogiem jest dostępność samego dokumentu. Procedura umieszczona wyłącznie w systemie, który może być niedostępny podczas zdarzenia, nie spełnia swojej funkcji. Kopia poza infrastrukturą organizacji jest elementem podstawowym, nie nadmiarowym.

Trzecim jest sprawdzenie. Podział ról, który nie został przećwiczony na uzgodnionym scenariuszu, pozostaje hipotezą — a ćwiczenie zwykle ujawnia braki w ciągu pierwszego kwadransa.

Ćwiczenie nie wymaga angażowania środowiska produkcyjnego ani udziału całej organizacji. Wystarczy spotkanie kilku osób wskazanych w procedurze i jeden scenariusz przeprowadzony krok po kroku, z pytaniem po każdym kroku, kto teraz co robi i skąd wie, że ma to zrobić.

Poniższe usterki powtarzają się niezależnie od wielkości organizacji i branży. Łączy je to, że żadna nie jest widoczna w codziennej pracy — ujawniają się wyłącznie podczas zdarzenia albo kontroli.

Warto przejrzeć tę listę pod kątem własnej organizacji, ponieważ usunięcie większości z nich nie wymaga nakładów, lecz jednej decyzji i jednego zapisu w dokumencie.

Typowa luka nie dotyczy wykonania, lecz nadzoru. Organizacja ma zespół utrzymaniowy i bywa, że ma dostawcę monitorowania, natomiast nie ma nikogo, kto oceniałby całość i rozmawiał o niej z kierownictwem w kategoriach ryzyka.

Zatrudnienie osoby na tym poziomie bywa nieproporcjonalne do skali organizacji, zwłaszcza gdy potrzeba dotyczy kilku dni w miesiącu. W takich sytuacjach stosuje się model, w którym funkcję nadzorczą pełni doradca zewnętrzny w ustalonym wymiarze.

Rozwiązanie to ma sens pod jednym warunkiem: podmiot sprawujący nadzór nie może być jednocześnie wykonawcą ocenianych prac ani dostawcą narzędzi. Inaczej odtwarza się dokładnie ten konflikt interesu, który miało usunąć.

Nasza rola mieści się w tym poziomie. Prowadzimy nadzór nad obszarem bezpieczeństwa, oceniamy pracę dostawców i przygotowujemy materiały dla kierownictwa. Nie prowadzimy monitorowania całodobowego ani obsługi technicznej incydentów, więc ocena pracy podmiotów, które je świadczą, nie jest obciążona własnym interesem.

Uporządkowanie podziału ról nie wymaga projektu ani nakładów technologicznych. Zaczyna się od zestawienia stanu faktycznego, a nie od projektowania stanu docelowego.

Pierwszym krokiem jest wypisanie czynności faktycznie wykonywanych w obszarze bezpieczeństwa i przypisanie do każdej z nich imienia i nazwiska. Czynności bez przypisania są luką, czynności przypisane do wszystkich są luką ukrytą.

Drugim jest rozdzielenie każdej pozycji na trzy poziomy opisane wcześniej: kto wykonuje, kto nadzoruje, kto odpowiada wobec otoczenia. Zbieżność wykonawcy i nadzorcy w jednej osobie wskazuje miejsca wymagające korekty.

Trzecim jest sprawdzenie całości na jednym scenariuszu. Ćwiczenie przy stole, przeprowadzone w kilka godzin, ujawnia więcej niż przegląd dokumentacji, ponieważ pyta nie o to, co jest zapisane, lecz o to, co zrobiłaby konkretna osoba o konkretnej porze.

Wnioski z ćwiczenia warto zapisać w tym samym dokumencie co podział ról, wraz z terminem usunięcia stwierdzonych braków. Ćwiczenie bez takiego zapisu zostaje w pamięci uczestników przez kilka tygodni, a następnie znika razem z pierwszą zmianą kadrową.