Dyrektor IT w firmie zatrudniającej kilkaset osób dostaje z zarządu polecenie w jednym zdaniu: „skoro nie stać nas na własny zespół bezpieczeństwa, kupmy tę usługę SOC”. Polecenie brzmi rozsądnie i zwykle takie jest. Kłopot zaczyna się kilka miesięcy później, o drugiej w nocy, gdy analityk dostawcy widzi w logach uwierzytelnienie administratora domeny z adresu, którego nigdy tam nie było, i dzwoni pod numer dyżurny podany w umowie. Po drugiej stronie odbiera człowiek, który nie ma uprawnienia, żeby cokolwiek wyłączyć.
Ten tekst nie porównuje kosztów budowy własnego centrum operacji bezpieczeństwa z ceną usługi — to osobny temat, rozpisany w analizie kosztów modelu własnego i zarządzanego. Tutaj interesuje nas pytanie, które w ofertach pojawia się najrzadziej, a rozstrzyga o wartości całej usługi: co zostaje po Twojej stronie, gdy już kupisz SOC. Punktem odniesienia jest NIST SP 800-61r3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management (kwiecień 2025) — dokument, który opisuje obsługę incydentu jako funkcję organizacji, a nie jako produkt, oraz dyrektywa (UE) 2022/2555 (NIS2), która przy okazji outsourcingu robi rzecz nieoczywistą: czyni Twojego dostawcę elementem Twojego łańcucha dostaw.
Co właściwie kupujesz, zamawiając SOC jako usługę?
Kupujesz zdolność obsługi zdarzeń: ludzi na zmianach, narzędzia do korelacji, procedurę i czas pracy. Nie kupujesz funkcji reagowania na incydenty jako całości, bo ta funkcja obejmuje także decyzje, kompetencje prawne i wiedzę o firmie, których żaden dostawca nie ma i mieć nie może.
NIST SP 800-61r3 stawia to jasno, wymieniając trzy sposoby obsadzenia roli osoby obsługującej incydent: własny zespół, umowa z podmiotem zewnętrznym — w dokumencie wprost wskazano tu powierzenie centrum operacji bezpieczeństwa dostawcy usług bezpieczeństwa zarządzanych — oraz wsparcie dostępne na żądanie, na przykład od spółki matki, partnera biznesowego albo organu ścigania. Dokument dodaje, że wiele organizacji łączy te drogi: obsługuje podstawowe zdarzenia własnymi siłami, a po zasoby zewnętrzne sięga przy wybranych kategoriach incydentów.
Dla firmy średniej wielkości praktyczna konsekwencja jest taka, że zamówienie usługi rozdziela funkcję na dwie części o różnych właścicielach. Dostawca dostaje część obserwacyjną i analityczną. Ty zostajesz z częścią decyzyjną, kontekstową i regulacyjną. Jeżeli umowa opisuje tylko pierwszą, druga nie znika — po prostu nie ma właściciela, a to najgorszy możliwy stan.
Druga rzecz, którą warto rozstrzygnąć na wejściu, to zakres obserwacji i godziny. Określenie „całodobowo” pokrywa co najmniej trzy różne układy: analityk na zmianie nocnej, dyżur pod telefonem z czasem dojścia do stanowiska oraz automatyczna korelacja, przy której człowiek pojawia się dopiero rano. Każdy z nich bywa uczciwie nazywany usługą całodobową i każdy inaczej wygląda o trzeciej w nocy. Pytanie, które to rozstrzyga, jest jedno: kto i gdzie siedzi w chwili, gdy przychodzi zdarzenie o najwyższym priorytecie. Ten tekst rozstrzyga, jak wybrać i skontraktować taki układ; ile każdy z nich kosztuje w czasie wykrycia, rozpisujemy osobno w artykule o tym, jak skrócić czas wykrycia incydentu (MTTD).
Trzecia rzecz to źródła danych, bo to one wyznaczają granicę widzenia. Usługa obserwuje wyłącznie to, co do niej dociera: logi z systemu tożsamości, poczty, stacji roboczych, urządzeń brzegowych, aplikacji krytycznych. Każde z tych źródeł ma swoją cenę wdrożenia — nie zawsze pieniężną, częściej w postaci pracy Twojego zespołu przy konfiguracji i utrzymaniu przesyłania. Oferta, która nie wymienia źródeł z nazwy, opisuje zakres, którego nie da się sprawdzić.
Dlatego pierwsza rzecz do ustalenia przy czytaniu oferty nie dotyczy technologii, tylko czasowników. Czy dostawca „informuje”, czy „reaguje”? Czy „rekomenduje odcięcie”, czy „odcina”? Czy „przygotowuje materiał do zgłoszenia”, czy „zgłasza”? Trzy pary czasowników, trzy zupełnie różne usługi i trzy różne poziomy Twojej pracy własnej po wdrożeniu.
Ramka — trzy pytania, które warto zadać przed podpisaniem
- Co dokładnie dzieje się między wykryciem a kontaktem z moją firmą — kto klasyfikuje zdarzenie i według czyich kryteriów?
- Które działania powstrzymujące dostawca wykona sam, a przy których czeka na moją zgodę?
- Kto po mojej stronie jest adresatem telefonu w nocy i jakie ma uprawnienie decyzyjne?
Dlaczego pytanie „własny SOC czy usługa” jest dla firmy średniej źle postawione?
Bo zakłada, że wybierasz między dwoma kompletnymi rozwiązaniami, podczas gdy w rzeczywistości wybierasz linię podziału wewnątrz jednej funkcji. Nawet skrajnie szeroka usługa zostawia po Twojej stronie zestaw obowiązków, których przekazać się nie da — a bardzo oszczędny model wewnętrzny i tak wymaga zewnętrznego wsparcia przy poważnym incydencie.
NIST SP 800-61r3 opisuje układ z dostawcą jako „a shared responsibility model in which the organization transfers some of its responsibilities to a provider”, czyli model współdzielonej odpowiedzialności, w którym organizacja przekazuje dostawcy część swoich obowiązków. Dokument dodaje zdanie, które warto przeczytać dwa razy: „These responsibilities should be clearly defined in a contract, and the incident response team should be aware of the division of responsibilities, including information flows, coordination, and authority to act on behalf of the organization” (NIST SP 800-61r3, sekcja 2.2). Po polsku: obowiązki te powinny być jasno określone w umowie, a zespół obsługi incydentów ma znać podział ról, w tym przepływy informacji, zasady koordynacji oraz uprawnienie do działania w imieniu organizacji.
Zwróć uwagę na ostatni element. „Uprawnienie do działania w imieniu organizacji” nie jest formułą prawniczą dorzuconą dla porządku — to jedyna rzecz, która w środku nocy odróżnia usługę od abonamentu na powiadomienia. Jeżeli w umowie jej nie ma, dostawca będzie dzwonił i czekał, a czas będzie płynął.
Dwa pokrewne rozstrzygnięcia rozpisaliśmy osobno, żeby nie dublować treści. Jeżeli szukasz rachunku ekonomicznego obu modeli, właściwym tekstem jest analiza soc-wlasny-vs-managed-analiza-kosztow — tam znajdziesz rozbicie pozycji kosztowych, tutaj świadomie nie podajemy żadnych widełek cenowych. Jeżeli natomiast masz już system klasy SIEM i zastanawiasz się, czy usługa jest dla niego dopełnieniem, czy zamiennikiem, ten wątek prowadzi tekst dlaczego-siem-bez-soc-nie-dziala, który patrzy na to samo rozwidlenie od strony narzędzia. Oba teksty i ten artykuł opisują tę samą decyzję z trzech różnych stron: kosztu, narzędzia i odpowiedzialności.
Które obowiązki zostają po Twojej stronie, nawet gdy kupisz pełną usługę?
Zostaje pięć grup, a każda ma inne uzasadnienie. Pierwsza to decyzje o dużym skutku. NIST SP 800-61r3, opisując role w obsłudze incydentu, przypisuje kierownictwu organizacji nadzór nad reagowaniem i przydział środków, dodając, że kierownictwo może mieć prawo decyzji o działaniach o dużym skutku — jako przykłady wymienia wyłączenie albo odtworzenie krytycznych usług. Dostawca może te decyzje przygotować i uzasadnić. Podjąć ich za Ciebie nie może, bo nie ponosi ich skutków biznesowych.
Druga grupa to wiedza o firmie. Ten sam dokument wymienia wśród ról właścicieli aktywów — systemów, danych i procesów biznesowych — jako osoby mające cenną wiedzę o priorytetach reagowania i odtwarzania, które trzeba na bieżąco informować o stanie prac. Dostawca zna Twoje logi. Nie wie, że wstrzymanie jednej aplikacji zatrzyma wysyłkę z magazynu, a wstrzymanie innej tylko opóźni raport miesięczny.
Trzecia to obowiązki wobec otoczenia regulacyjnego i prawnego. NIST wyodrębnia tu rolę prawników, którzy przeglądają umowy z dostawcami technologii i innymi podmiotami pod kątem konsekwencji dla obsługi incydentów, oraz rolę komunikacji z mediami. W polskich realiach dochodzi obowiązek zgłoszeniowy z NIS2, do którego wracamy w osobnej sekcji.
Czwarta grupa to wykonanie zmian technicznych. NIST wymienia wśród ról specjalistów technologii — architektów, inżynierów i administratorów systemów, sieci i chmury oraz programistów — jako osoby uczestniczące w reagowaniu i odtwarzaniu. To po Twojej stronie ktoś zainstaluje poprawkę, przebuduje serwer i zmieni konfigurację reguły na zaporze. Dostawca SOC może wskazać, co zrobić, i potwierdzić, że zadziałało; nie zastąpi zespołu utrzymania, a w firmie średniej wielkości ten zespół jest zwykle tym samym zespołem, który prowadzi helpdesk.
Piąta grupa jest najczęściej pomijana w ofertach: kadry i bezpieczeństwo fizyczne. NIST wymienia praktyki kadrowe — weryfikację przed zatrudnieniem, wdrożenie i odejście pracownika, zmianę stanowiska — oraz sytuację, w której pracownik jest podejrzany o celowe spowodowanie incydentu. Dokument wskazuje też, że część incydentów przebiega przez naruszenie bezpieczeństwa fizycznego, a zespół obsługi może potrzebować dostępu do pomieszczeń. Żadnej z tych rzeczy nie da się kupić razem z monitorowaniem.
Jak rozpisać macierz odpowiedzialności między firmą a dostawcą?
Najprościej tabelą, w której trzecia kolumna jest ważniejsza od dwóch pierwszych. Kolumny „dostawca” i „my” wypełnia się łatwo i zwykle zgodnie z ofertą. Dopiero kolumna „co się dzieje, jeśli nikt się nie umówi” pokazuje, gdzie w umowie jest dziura — bo obowiązek bez właściciela nie znika, tylko wraca do Ciebie w najgorszym momencie.
| Czynność | Kto wykonuje wg typowej oferty | Co musi zostać po Twojej stronie | Skutek braku ustalenia |
|---|---|---|---|
| Zbieranie i korelacja zdarzeń | dostawca | wskazanie źródeł logów i utrzymanie ich ciągłości | usługa monitoruje wycinek środowiska, a raport wygląda spokojnie |
| Klasyfikacja zdarzenia jako incydentu | dostawca wg własnych kryteriów | zatwierdzenie kryteriów i progów istotności dla Twojego biznesu | incydent klasy „wysoki” u dostawcy bywa nieistotny u Ciebie i odwrotnie |
| Powstrzymanie ataku (odcięcie konta, izolacja stacji) | zależy od umowy | pisemne uprawnienie i jego granice | analityk dzwoni i czeka; czas płynie |
| Decyzja o wyłączeniu usługi produkcyjnej | nigdy dostawca | wskazany decydent dyżurny z uprawnieniem | decyzja zapada rano, po zakończeniu ataku |
| Zgłoszenie do organu właściwego | nigdy dostawca | proces zgłoszeniowy i osoba odpowiedzialna | termin z NIS2 biegnie niezależnie od tego, czy ktoś o nim pamięta |
| Powiadomienie klientów i partnerów | nigdy dostawca | gotowy scenariusz komunikacji | komunikat powstaje pod presją, bez zatwierdzenia prawnego |
| Odtworzenie systemu z kopii | zwykle Twój zespół lub dostawca IT | uzgodnienie kolejności odtwarzania | dwa zespoły odtwarzają w odwrotnej kolejności zależności |
| Ustalenie przyczyny źródłowej | dostawca | udostępnienie kontekstu zmian i wdrożeń | analiza kończy się na „nieznany wektor” |
| Wnioski i zmiana konfiguracji po incydencie | wspólnie | właściciel zmiany i termin | ten sam incydent wraca za kwartał |
| Monitorowanie samego dostawcy | nikt, jeśli się nie umówisz | przegląd jego dostępów i działań | patrz sekcja o łańcuchu dostaw |
Tabelę warto wypełnić przed wyborem dostawcy, a potem przyłożyć do każdej oferty jako sito. Oferta, która wypełnia pierwszą kolumnę bogato, a trzecią zostawia pustą, nie jest tańsza — jest po prostu niedokończona, a resztę pracy wykonasz sam, tyle że bez planu.
Kto podejmuje decyzję o odcięciu systemu w środku nocy?
Ktoś, kogo wskazujesz z imienia i nazwiska, z zastępcą, i komu dajesz pisemne uprawnienie. To zdanie brzmi banalnie, dopóki nie zestawi się go z tym, jak wygląda większość wdrożeń: numer dyżurny prowadzi do całodobowego helpdesku IT, a helpdesk nie ma prawa zatrzymać niczego, co jest w produkcji.
NIST SP 800-61r3 traktuje ten punkt jako element umowy, nie jako kwestię organizacyjną. Wśród ograniczeń, które umowa powinna nakładać na dostawcę, wymienia wprost podejmowanie i wykonywanie decyzji operacyjnych — jako przykład podaje natychmiastowe wyłączenie określonych usług w celu powstrzymania incydentu. Innymi słowy: to uprawnienie albo jest dostawcy przyznane na piśmie, albo mu odebrane. Trzeciej możliwości nie ma, a jej brak w umowie oznacza domyślnie „nie wolno”.
Praktyczne rozwiązanie, które sprawdza się w firmach bez własnego zespołu bezpieczeństwa, to wstępna autoryzacja wąskiego katalogu działań. Nie „dostawca może wszystko” i nie „dostawca nie może nic”, tylko lista: zablokowanie konta użytkownika — tak, bez pytania; izolacja stacji roboczej od sieci — tak, z powiadomieniem; zablokowanie konta administracyjnego — po kontakcie z decydentem; wyłączenie systemu produkcyjnego — nigdy bez decyzji po Twojej stronie. Cztery poziomy wystarczą, a każdy z nich musi mieć w umowie własne zdanie.
Druga rzecz do ustalenia to okno czasowe. Jeżeli decydent dyżurny nie odbiera, co dzieje się dalej? Umowa powinna odpowiadać na to pytanie liczbą minut i ścieżką eskalacji, a nie sformułowaniem „dostawca podejmie próbę kontaktu”. Z naszych wdrożeń wynika, że to właśnie ten zapis — a nie zakres monitorowania i nie klasa narzędzi — najczęściej decyduje o tym, czy usługa realnie skróciła czas trwania incydentu, czy tylko go udokumentowała.
Ramka — cztery poziomy autoryzacji działań powstrzymujących
- Poziom 1 — dostawca działa sam, informuje po fakcie: blokada konta użytkownika, unieważnienie sesji, blokada adresu na brzegu sieci.
- Poziom 2 — dostawca działa sam, informuje natychmiast: izolacja pojedynczej stacji roboczej od sieci.
- Poziom 3 — po kontakcie z decydentem dyżurnym: blokada konta uprzywilejowanego, odcięcie segmentu sieci.
- Poziom 4 — wyłącznie decyzja po Twojej stronie: zatrzymanie systemu produkcyjnego, odtworzenie środowiska, powiadomienie zewnętrzne.
Ostatni element tej sekcji dotyczy zapisu. Każda decyzja podjęta w trakcie incydentu — także decyzja o niepodejmowaniu działania — powinna trafić do jednego, wspólnego dla obu stron rejestru, z czasem, autorem i uzasadnieniem. To nie jest formalność: przy sprawozdaniu końcowym dla organu i przy rozliczeniu z zarządem rekonstrukcja osi czasu z pamięci dwóch zespołów pracujących w nocy jest zadaniem, którego nikt nie wykonuje dobrze. Rejestr prowadzony na bieżąco przez dostawcę, z Twoim dostępem do zapisu, kosztuje w umowie jedno zdanie.
Kto zgłasza incydent do organu i dlaczego dostawca tego za Ciebie nie zrobi?
Zgłasza podmiot objęty obowiązkiem, czyli Twoja firma. Dyrektywa (UE) 2022/2555 (NIS2) nakłada obowiązki zgłoszeniowe w art. 23 na podmioty kluczowe i ważne, a nie na ich usługodawców. Harmonogram jest trzystopniowy: wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiadomości o poważnym incydencie, zgłoszenie incydentu w ciągu 72 godzin oraz sprawozdanie końcowe w ciągu miesiąca od zgłoszenia.
Dostawca SOC jest przy tym obowiązku bardzo przydatny i zupełnie nieodpowiedzialny — w sensie prawnym, nie potocznym. Przydatny, bo dysponuje materiałem faktograficznym: czasem pierwszego zaobserwowania, zakresem dotkniętych systemów, wstępną oceną wektora. Nieodpowiedzialny, bo art. 20 NIS2 lokuje odpowiedzialność za zarządzanie ryzykiem w cyberbezpieczeństwie w organach zarządzających podmiotu — to one zatwierdzają środki i nadzorują ich wdrażanie, i to na nich dyrektywa przewiduje odpowiedzialność za naruszenie tych obowiązków.
Wniosek operacyjny jest prosty i rzadko wyciągany na etapie zakupu. W umowie na usługę SOC powinien znaleźć się zapis o terminie i formacie przekazania materiału do zgłoszenia, liczonym tak, żeby zostawiał Twojemu zespołowi czas na decyzję. Jeżeli dostawca zobowiązuje się dostarczyć opis incydentu „niezwłocznie”, a Ty masz dobę na wczesne ostrzeżenie, to ryzyko przesunięcia terminu jest w całości Twoje.
Osobnym ustaleniem jest to, kto ocenia, czy incydent w ogóle przekroczył próg istotności. Art. 23 ust. 3 dyrektywy uznaje incydent za poważny, gdy spowodował lub może spowodować dotkliwe zakłócenie operacyjne usług lub straty finansowe dla danego podmiotu, albo gdy wpłynął lub może wpłynąć na inne osoby fizyczne lub prawne, powodując znaczne szkody majątkowe i niemajątkowe. Żadne z tych kryteriów nie jest techniczne — wszystkie odwołują się do skutku biznesowego, którego dostawca SOC nie zna. Ocena progu jest więc zadaniem Twojej firmy, wykonywanym na materiale dostarczonym przez dostawcę, i warto mieć na nią gotowy, zapisany sposób postępowania zamiast improwizacji w dobie incydentu.
Warto też z góry rozstrzygnąć, kto redaguje treść zgłoszenia. Materiał techniczny od dostawcy i zgłoszenie do organu to dwa różne dokumenty pisane w dwóch różnych językach. Firmy, które tego nie rozdzieliły, zwykle odkrywają różnicę w dobie, w której mają najmniej czasu.
Czego dostawca nie dowie się o Twojej firmie, jeśli mu tego nie powiesz?
Nie dowie się niczego, co nie zostawia śladu w logach — a to właśnie ta wiedza odróżnia alert od incydentu. Dostawca widzi, że konto svc-integracja zaczęło o trzeciej w nocy czytać zasób, którego wcześniej nie czytało. Nie wie, czy to nowy proces wdrożony wczoraj przez integratora, czy początek eksfiltracji.
Materiał, który trzeba przekazać na starcie usługi, jest skończony i daje się rozpisać w jednym dokumencie. Tworzy go inwentarz systemów z właścicielem biznesowym każdego z nich, mapa zależności („co przestanie działać, jeśli zatrzymamy X”), kalendarz okien serwisowych i wdrożeń, lista kont technicznych z uzasadnieniem ich istnienia, wykaz dostawców mających zdalny dostęp oraz opis sezonowości biznesu. Bez ostatniego punktu dostawca będzie eskalował wzmożony ruch w szczycie sprzedażowym jako anomalię, a w kolejnym sezonie przestanie, bo nauczył się go ignorować — i wtedy przeoczy prawdziwy.
Ten sam materiał trzeba utrzymywać, nie tylko przekazać. NIST SP 800-61r3 traktuje właścicieli aktywów jako stałych uczestników procesu, których należy na bieżąco informować o stanie reagowania i odtwarzania, a nie jako jednorazowe źródło danych wejściowych. W praktyce oznacza to jeden przegląd kwartalny: co doszło, co zniknęło, komu zmienił się zakres obowiązków.
Osobnego potraktowania wymagają usługi kupione poza działem IT. W firmie zatrudniającej kilkaset osób niemal zawsze istnieje kilka aplikacji w modelu abonamentowym, które dział marketingu, kadr albo sprzedaży uruchomił samodzielnie i które przechowują dane realnie istotne dla firmy. Z punktu widzenia dostawcy SOC te systemy nie istnieją, dopóki ktoś ich nie wskaże i nie doprowadzi z nich logów. Przegląd faktur kartą firmową bywa w tym miejscu skuteczniejszym narzędziem inwentaryzacji niż skan sieci.
Jest tu również element, o którym oferty milczą, a który w firmach produkcyjnych i logistycznych bywa decydujący: środowisko technologii operacyjnej. Sterowniki, panele operatorskie i sieci przemysłowe rzadko mieszczą się w standardowym zakresie usługi, a jeszcze rzadziej wolno na nich wykonać typowe działanie powstrzymujące. Jeżeli masz taką część infrastruktury, musi ona być w umowie opisana osobno — razem z zakazem automatycznej izolacji.
Czego wymagać w umowie, żeby usługa dała się rozliczyć?
Sześciu rzeczy, z których żadna nie dotyczy technologii. Pierwsza to podział ról opisany w poprzednich sekcjach, wraz z „uprawnieniem do działania w imieniu organizacji” i jego granicami. Druga to przepływy informacji i zasady koordynacji — NIST wymienia je jednym tchem z podziałem obowiązków, bo bez nich podział jest deklaracją.
Trzecia to obowiązek ujawniania. Profil NIST SP 800-61r3 dla ram CSF 2.0 w podkategorii GV.SC-05, dotyczącej wymagań wobec łańcucha dostaw ujmowanych w umowach, zaleca objęcie nimi skuteczności zabezpieczeń oraz ujawniania podatności, zagrożeń i incydentów wraz z wymianą informacji. Przełożone na język umowy: dostawca informuje Cię o incydentach u siebie, nie tylko o incydentach u Ciebie.
Czwarta to ograniczenia. Ten sam dokument wskazuje, że umowa powinna określać, czego dostawcy robić nie wolno — wymienia tu udostępnianie zanonimizowanych informacji o incydencie innym klientom oraz podejmowanie decyzji operacyjnych. Pierwsze bywa dla Ciebie korzystne, bo dostawca korelujący zdarzenia między klientami wykrywa szybciej niż pojedyncza organizacja; NIST odnotowuje to wprost jako zaletę modelu usługowego. Ale to Ty decydujesz, w jakiej postaci Twoje dane wchodzą do tej korelacji.
Piąta to dowody dla audytora. Raport miesięczny, który zawiera liczbę obsłużonych zgłoszeń i nic poza tym, nie jest dowodem na nic. Użyteczny zestaw to: rejestr zdarzeń z klasyfikacją, historia spraw z osią czasu, lista reguł detekcyjnych działających w Twoim środowisku wraz z datą ostatniej zmiany oraz zapis testów ścieżki eskalacji. Ostatni punkt jest testowalny — i powinien być testowany co najmniej raz na kwartał, ćwiczeniem bez uprzedzenia.
Szósta to prawo do sprawdzenia. Przy usłudze, w której dostawca ma dostęp uprzywilejowany do Twoich systemów, prawo do audytu i do testu ścieżki reagowania nie jest przywilejem — jest jedynym sposobem, żeby stwierdzić, że usługa działa, zanim stwierdzi to atakujący.
Jednego w tej umowie nie należy przyjmować na słowo: czasów reakcji. Parametry czasowe mają wartość wtedy, gdy są zapisane razem z definicją momentu startu, katalogiem wyłączeń i konsekwencją niedotrzymania. Liczba w materiale marketingowym, bez tych trzech elementów, nie jest zobowiązaniem. Nasze doświadczenie wdrożeniowe pokazuje, że rozmowa o definicji momentu startu bywa trudniejsza niż rozmowa o samej liczbie — i to ona pokazuje, jak dostawca rozumie własną usługę.
Dlaczego dostawca SOC sam staje się elementem Twojego łańcucha dostaw?
Bo tak stanowi dyrektywa, i bo tak wynika z faktów technicznych. Art. 21 ust. 2 lit. d dyrektywy (UE) 2022/2555 wymienia wśród minimalnych środków zarządzania ryzykiem bezpieczeństwo łańcucha dostaw, w tym aspekty związane z bezpieczeństwem dotyczące stosunków między podmiotem a jego bezpośrednimi dostawcami lub usługodawcami. Dostawca SOC jest bezpośrednim usługodawcą w najbardziej dosłownym sensie: ma dostęp do Twoich logów, często do Twoich systemów, a w modelu z działaniem powstrzymującym — także do Twoich konsol administracyjnych.
NIST SP 800-61r3 nazywa to ryzyko wprost. Dostawcy usług często mają uprzywilejowany dostęp do systemów organizacji i mogą mieć również dostęp do jej danych wrażliwych; dlatego ryzyko wynikające ze złośliwego działania osób wewnątrz dostawcy albo z jego własnego naruszenia należy rozważyć i zaadresować. Jako narzędzia dokument wskazuje umowy o zachowaniu poufności i klauzule umowne.
Co więcej, profil tego dokumentu dla ram CSF 2.0 przypisuje podkategorii DE.CM-06 — monitorowaniu działań i usług zewnętrznych dostawców pod kątem potencjalnie niekorzystnych zdarzeń — priorytet wysoki, a więc ten sam, który mają podstawowe kategorie wykrywania. W zaleceniu do tej podkategorii wymieniono „remote and on-site administration and maintenance activities that providers perform on organizational systems” (zdalne i lokalne czynności administracyjne oraz utrzymaniowe wykonywane przez dostawców na systemach organizacji), a także odstępstwa od oczekiwanego zachowania usług.
Dla firmy średniej wielkości oznacza to zadanie, które na pierwszy rzut oka wygląda absurdalnie: musisz monitorować własny SOC. Nie chodzi o drugi zespół analityków. Chodzi o trzy mechanizmy: rejestr kont dostawcy z przeglądem przy każdej zmianie składu jego zespołu, logowanie sesji administracyjnych po Twojej stronie (a nie wyłącznie po jego) oraz kwartalny przegląd, czy zakres dostępów nadal odpowiada zakresowi usługi. Żaden z tych mechanizmów nie wymaga nowego narzędzia — wymaga wpisania do umowy i do kalendarza.
Do tego dochodzi łańcuch dostaw samego dostawcy. Usługa SOC rzadko jest w całości wykonywana przez jeden podmiot: platforma korelacyjna bywa cudza, zmiana nocna bywa realizowana z innego kraju, a analiza złośliwego oprogramowania bywa zlecana dalej. Umowa powinna nakładać obowiązek ujawnienia takich podwykonawców i informowania o ich zmianie, bo Twój obowiązek z art. 21 ust. 2 lit. d dotyczy relacji z bezpośrednim usługodawcą — ale ryzyko, które przez tę relację wpływa, ma dłuższą drogę. Pytanie, od którego warto zacząć, brzmi: z jakiej jurysdykcji i przez jakie konto ktoś faktycznie loguje się do mojej konsoli.
Podkategoria GV.SC-08 tego samego profilu dokłada element, o którym łatwo zapomnieć: dostawcy i inne podmioty trzecie mają być włączeni w planowanie, reagowanie i odtwarzanie po incydencie. To znaczy, że ćwiczenie sprawdzające plan reagowania bez udziału dostawcy SOC sprawdza plan, którego w rzeczywistości nie ma.
Jak zaplanować wyjście z usługi, zanim ją zamówisz?
Zapisując cztery rzeczy w umowie, którą właśnie podpisujesz — nie w aneksie, który podpiszesz w dniu wypowiedzenia. Profil NIST SP 800-61r3 dla ram CSF 2.0 wskazuje na to w podkategorii GV.SC-10, wymagającej, by plany zarządzania ryzykiem łańcucha dostaw obejmowały działania następujące po zakończeniu partnerstwa lub umowy o świadczenie usług.
Pierwsza rzecz to dane. Logi zebrane w czasie trwania usługi, historia spraw z osią czasu i podjętymi działaniami, wyniki analiz — wszystko to jest dowodem, którego możesz potrzebować długo po zakończeniu współpracy, choćby wobec regulatora albo w sporze. Umowa musi określać format wydania i termin, a format „dostęp do portalu przez 30 dni od rozwiązania” nie jest wydaniem danych.
Druga to reguły detekcyjne powstałe dla Twojego środowiska. To obszar, w którym interesy stron są rozbieżne i lepiej rozstrzygnąć to na początku: reguła opisująca Twoje procesy biznesowe jest bliższa Twojej własności niż know-how dostawcy, ale bez zapisu w umowie odejdzie razem z nim.
Trzecia to okres przejściowy. Przekazanie usługi między dostawcami albo do zespołu wewnętrznego wymaga równoległego monitorowania, bo inaczej powstaje okno bez obserwacji — a to jest dokładnie ten moment, w którym atakujący nie musi być szczególnie zdolny, żeby wejść niezauważenie.
Czwarta to usunięcie danych po stronie dostawcy, z potwierdzeniem. Bez tego zapisu Twoje logi zostają na cudzej infrastrukturze na czas nieokreślony, a Ty tracisz nad nimi kontrolę, zachowując za nie odpowiedzialność.
Jaki zakres ochrony jest realistyczny dla firmy bez własnego zespołu bezpieczeństwa?
Taki, który odpowiada faktycznej dojrzałości organizacji, a nie deklaracjom w ofercie. Dobrym punktem odniesienia jest podział na grupy wdrożeniowe w CIS Critical Security Controls. Grupa pierwsza (IG1) jest opisana jako podstawowa higiena cyberbezpieczeństwa i obejmuje zestaw 56 zabezpieczeń; typowe przedsiębiorstwo z tej grupy jest małe lub średnie i dysponuje ograniczonymi kompetencjami w zakresie IT i bezpieczeństwa. Grupa druga (IG2) dokłada kolejnych 74 zabezpieczeń, a jej typowe przedsiębiorstwo CIS opisuje słowami „an IG2 enterprise employs individuals who are responsible for managing and protecting IT infrastructure” (zatrudnia osoby odpowiedzialne za zarządzanie infrastrukturą IT i jej ochronę).
To rozróżnienie ma bezpośrednie przełożenie na zakup usługi SOC. Monitorowanie nie tworzy zabezpieczeń — obserwuje te, które istnieją. Jeżeli w środowisku brakuje inwentaryzacji zasobów, kontroli kont uprzywilejowanych i kopii zapasowych sprawdzanych odtworzeniem, to usługa SOC dostarczy Ci rzetelnej wiedzy o tym, jak wygląda atak w organizacji bez tych zabezpieczeń. Wiedza będzie prawdziwa. Będzie też spóźniona.
Praktyczna kolejność dla firmy zatrudniającej kilkaset osób jest zwykle taka: najpierw domknąć podstawową higienę z pierwszej grupy wdrożeniowej, równolegle uruchomić usługę w wąskim, dobrze opisanym zakresie (tożsamość, poczta, stacje robocze, brzeg sieci), a rozszerzanie zakresu wiązać z dojrzałością kolejnych obszarów. Odwrotna kolejność — szeroki zakres monitorowania na niedojrzałym środowisku — produkuje strumień zgłoszeń, na które nikt nie ma jak zareagować, i kończy się wyciszaniem reguł.
Kolejność nie musi przy tym oznaczać zwłoki. Domykanie podstawowej higieny i uruchamianie wąskiego zakresu usługi da się prowadzić równolegle, jeżeli z góry ustalisz, które zabezpieczenie musi być gotowe przed włączeniem którego źródła logów. Reguła kciuka, która sprawdza się w praktyce: źródło wchodzi do monitorowania dopiero wtedy, gdy ma ustalonego właściciela i opisany sposób reakcji na najczęstszy alert z tego źródła. Bez tych dwóch rzeczy dokładasz strumień zgłoszeń, a nie zdolność wykrywania.
Warto też uczciwie powiedzieć, czego usługa nie zmienia. Nie zmienia tego, że ktoś musi łatać systemy, prowadzić rejestr zmian i odbierać telefon. Zmienia to, kto patrzy i kto klasyfikuje — a to w firmie bez własnego zespołu bezpieczeństwa jest zmianą wystarczająco dużą, żeby ją kupić. Pod warunkiem że kupuje się ją świadomie.
Kiedy model usługowy nie ma sensu — i jak to sprawdzić przed podpisaniem?
Wtedy, gdy któryś z warunków brzegowych jest niespełniony w sposób, którego umowa nie naprawi. Poniższa tabela zbiera sygnały, które warto przejść przed decyzją — każdy z nich da się sprawdzić w ciągu jednego popołudnia, bez udziału dostawcy.
| Sygnał do sprawdzenia | Jak sprawdzić | Co oznacza wynik negatywny | Co zrobić zamiast podpisania |
|---|---|---|---|
| Istnieje aktualny inwentarz systemów z właścicielem biznesowym | poproś o listę i sprawdź datę ostatniej zmiany | dostawca będzie monitorował wycinek, którego nikt nie potrafi opisać | odtworzyć inwentarz; to warunek, nie etap |
| Jest wskazany decydent dyżurny z uprawnieniem do zatrzymania usługi | zapytaj, kto podjął ostatnią taką decyzję i kiedy | usługa skończy się na powiadomieniach | wyznaczyć rolę i zapisać jej granice |
| Da się odebrać telefon poza godzinami pracy | wykonaj próbne połączenie w sobotę | koszt usługi nocnej kupuje czas, którego nie wykorzystasz | zacząć od zakresu w godzinach pracy |
| Logi z kluczowych systemów są kompletne i mają retencję | sprawdź jeden system pod kątem luk w ostatnim kwartale | detekcja będzie pozorna | uporządkować źródła przed uruchomieniem usługi |
| Prawo i umowy dopuszczają wyniesienie danych do dostawcy | przegląd z działem prawnym i z umowami z klientami | ryzyko regulacyjne przewyższa korzyść | model lokalny albo zakres ograniczony |
| Środowisko nie jest w większości technologią operacyjną | policz udział systemów przemysłowych | typowa usługa nie obejmie rdzenia Twojego ryzyka | usługa wyspecjalizowana, osobny zakres |
| Firma jest gotowa utrzymywać kontekst biznesowy | ustal, kto odpowie za kwartalny przegląd | jakość detekcji spadnie po kilku miesiącach | przypisać rolę przed startem |
Jeżeli wszystkie siedem wierszy wypada pozytywnie, model usługowy jest dla firmy średniej wielkości rozwiązaniem racjonalnym — i zwykle jedynym osiągalnym. Jeżeli negatywnie wypadają wiersze pierwszy, drugi i czwarty, podpisanie umowy nie jest złą decyzją, tylko przedwczesną: kupujesz obserwację środowiska, którego nie opisałeś, i zdolność reagowania, której nie masz komu przekazać.
Ramka — jedno zdanie, które warto zapisać w notatce z decyzji
Usługa SOC przenosi na dostawcę patrzenie i klasyfikowanie. Decyzję, kontekst i obowiązek wobec regulatora zostawia u Ciebie — i to od jakości tych trzech elementów, a nie od zakresu monitorowania, zależy, czy pierwszy poważny incydent skończy się raportem, czy postojem.
Jeżeli chcesz zestawić powyższe kryteria z konkretnym zakresem usługi, opis naszego monitorowania bezpieczeństwa w modelu SOC 24/7 pokazuje, gdzie w tej macierzy przebiega linia podziału po naszej stronie — łącznie z tym, co pozostaje po stronie klienta. Warto przyłożyć do niego tę samą tabelę, którą przykładasz do każdej innej oferty; jeżeli któraś kolumna zostanie pusta, to jest właśnie pytanie do zadania na spotkaniu.
