Think Tank ds. bezpieczeństwa: odzyskaj utracone zaufanie, pracując mądrzej

W typowym przedsiębiorstwie podział odpowiedzialności jest skodyfikowany: Zespół IT zarządza systemami IT, a zespół ds. bezpieczeństwa obsługuje systemy bezpieczeństwa. Może nie być żadnego ryzyka, iż ​​systemy bezpieczeństwa wpłyną na systemy IT, dopóki narzędzia bezpieczeństwa nie będą działać na urządzeniach użytkowników końcowych, serwerach i jako aktywne elementy w sieci (administratorzy zapór zgodzą się ze mną, otrzymują wiele nieuzasadnionych skarg od zespołów IT, iż „zapora spowalnia działanie”).

Wśród narzędzi bezpieczeństwa, które mogą mieć potencjalny wpływ na zarządzane systemy IT, znajdują się sterowniki antymalware typu kernel-hooked. W miarę jak cyberaktorzy zagrożeń udoskonalają swoje ataki, tak samo udoskonalają się możliwości narzędzi antymalware. Aby skutecznie wykonywać swoją funkcję, mają one uprzywilejowany dostęp do głębszych poziomów systemów operacyjnych i aplikacji. To właśnie tam pojawiają się problemy techniczne, odpowiedzialności i zarządzania incydentami. Aby je rozwiązać, zespoły IT i bezpieczeństwa muszą współpracować, a nie działać przeciwko sobie.

Weź narzędzie bezpieczeństwa, które wymaga systemu (agenta/usługi/sterownika jądra) do uruchomienia w zarządzanych przez IT systemach, niezależnie od tego, czy są to komputery użytkowników końcowych, czy serwery. Zespół ds. bezpieczeństwa nie może i nie powinien żądać, aby zespół IT zainstalował wspomniane oprogramowanie w swoich systemach, ślepo ufając zespołowi ds. bezpieczeństwa, iż ​​„to oprogramowanie jest bezpieczne”.

Zamiast tego zespół IT powinien nalegać na prawidłowe uzasadnienie i testowanie wpływu na wydajność. Należy przeprowadzić ocenę, w jaki sposób te narzędzia, zarządzane przez zespół ds. bezpieczeństwa, wpływają na zespół IT. Cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO) umowa pomiędzy zespołem IT a resztą firmy.

Niestety, z mojego doświadczenia i analizy największego jak dotąd incydentu informatycznego spowodowanego przez firmę ochroniarską wynika, iż ​​wiele przedsiębiorstw, choćby z regulowanych branż, nie podjęło się tego zadania.

Być może pamiętasz te firmy, które choćby kilka dni później CrowdStrike rozpowszechnił błędną aktualizację kanału i wydali poprawkę kilka godzin później, nie byli w stanie wznowić normalnej pracy. Weź Linie lotnicze Delta na przykład. Podczas gdy wszystkie inne linie lotnicze w USA przywróciły swoje operacje w ciągu dwóch dni od udostępnienia poprawki, Delta nie była w stanie działać przez pięć dni. Zgodnie z wpisem na blogu CrowdStrike, winę za brak przywrócenia we właściwym czasie ponoszą zespoły IT i bezpieczeństwa CrowdStrike.

Choć nie opowiadam się za zmniejszeniem części winy po stronie CrowdStrike, twierdzę, iż brak wznowienia działalności po udostępnieniu poprawki świadczy o porażce zespołów IT i bezpieczeństwa w dotkniętych problemem organizacjach.

Podstawowym celem zespołu IT jest dostarczanie wartości biznesowej poprzez zapewnienie dostępności niezbędnych systemów IT i ich działania w ramach uzgodnionych parametrów, podczas gdy podstawowym celem zespołu ds. bezpieczeństwa jest zmniejszenie prawdopodobieństwa istotnego wpływu spowodowanego zdarzeniem cybernetycznym. CrowdStrike nie był zdarzeniem cybernetycznym; był zdarzeniem IT spowodowanym przez dostawcę zabezpieczeń. Podobne zdarzenia zdarzają się co roku z powodu błędów Microsoftu.

Nieuchronnie brak przygotowania do przywrócenia normalnego funkcjonowania w ramach uzgodnionych RTO i RPO niszczy reputację zespołu IT i zespołu ds. bezpieczeństwa w oczach dyrektorów innych funkcji biznesowych.

Trudno odzyskać utracone zaufanie i reputację. Jako branża musimy wyciągnąć z tego wnioski i pracować mądrzej.

Oto trzy wnioski, jakie można wyciągnąć z tego wydarzenia, które zmieniło epokę:

• Skup się na testowaniu odzyskiwania w oparciu o uzgodnione RTO i RPO. Zespoły ds. bezpieczeństwa powinny nalegać, aby zespół IT przeprowadził testowanie odzyskiwania obejmujące scenariusze, w których narzędzie bezpieczeństwa sprawia, iż ​​system operacyjny jest niemożliwy do uruchomienia.
• Dyrektorzy ds. informatyki i dyrektorzy ds. bezpieczeństwa informacji powinni wspólnie rozmawiać z pozostałymi członkami kadry kierowniczej i wyjaśniać potrzebę stosowania specjalistycznych narzędzi bezpieczeństwa, a także zapewniać, iż testowane odzyskiwanie danych mieści się w uzgodnionych parametrach (np. RTO i RPO).
• Skontaktuj się z działem prawnym i zaopatrzenia firmy, aby przejrzeć umowy z dostawcami systemów bezpieczeństwa i zidentyfikować nieuczciwe korzyści, jakie dostawcy zawarli w umowach w odniesieniu do odszkodowań z tytułu błędów w świadczeniu usług.