Nie zaczynaj od kolejnego narzędzia. Zacznij od tego, co może zatrzymać Twój biznes
Po naszym webinarze „System jest dostawcy. Ryzyko zostaje u placówki” zostało mi w głowie jedno pytanie: czy ten materiał nie był przypadkiem zbyt prosty?
Nie pokazywaliśmy żadnego magicznego urządzenia, które rozwiązuje problem bezpieczeństwa, ani narzędzia, które po wdrożeniu zmienia wszystkie kontrolki na zielone. Dużo mówiliśmy za to o zależnościach, dostępie, uprawnieniach, ciągłości działania i o tym, co właściwie wydarzy się w organizacji, kiedy któryś z kluczowych systemów przestanie działać.
Im dłużej o tym myślę, tym bardziej jestem przekonana, że właśnie od tego powinna zaczynać większość organizacji.
Cyberbezpieczeństwo ma problem z wizerunkiem
Lubimy, kiedy wygląda skomplikowanie. Dashboard pełen alertów, SOC pracujący całą dobę, architektura z dziesiątkami strzałek i nazwy technologii, których połowa zarządu nie rozumie, ale które brzmią wystarczająco poważnie, żeby znaleźć się w budżecie.
Analiza ryzyka wypada przy tym dość blado. Pytanie „co się stanie, jeśli jutro rano nie będzie działał system rejestracji?” nie brzmi tak imponująco jak nowe rozwiązanie bezpieczeństwa.
Tyle że odpowiedź na to pierwsze pytanie może mieć dla placówki znacznie większe znaczenie.
Placówka nie działa dzięki temu, że ma system informatyczny. Działa dlatego, że pacjent może się zarejestrować, recepcja może znaleźć jego dane, lekarz może wykonać swoją pracę, laboratorium może przesłać wynik, a cały proces przebiega bez większych zakłóceń.
Technologia jest gdzieś pod spodem. Dopóki działa, prawie nikt się nad nią nie zastanawia. Dopiero awaria pokazuje, jak mocno proces biznesowy i system informatyczny są ze sobą związane.
System może być dostawcy. Problem bardzo szybko staje się Twój
To było właściwie sedno całego webinaru.
Możemy korzystać z zewnętrznego systemu rejestracji, oprogramowania medycznego, chmury, aplikacji, laboratorium czy platformy do komunikacji. Możemy nie posiadać infrastruktury, nie mieć dostępu do kodu i nie wiedzieć, na jakich dokładnie serwerach działa usługa.
Kiedy jednak ta usługa przestaje działać, pacjent nie dzwoni do producenta systemu. Dzwoni do placówki.
Recepcja nie może powiedzieć, że to incydent dostawcy i dlatego placówki nie dotyczy. Problem bardzo szybko staje się operacyjny: ktoś nie może się zarejestrować, ktoś nie ma dostępu do potrzebnych danych, pracownik nie wie, czy ma czekać, działać ręcznie, czy informować pacjentów o odwołaniu wizyt.
Dlatego tak istotne jest nie tylko pytanie, jak zapobiegać incydentom, ale też co organizacja zrobi, jeśli któregoś z nich nie uda się uniknąć.
Od czego zacząć, jeśli nie masz rozbudowanego zespołu bezpieczeństwa?
Wcale nie od zakupu kolejnego rozwiązania.
Na początku znacznie więcej może dać rozmowa z ludźmi, którzy rzeczywiście znają codzienną pracę organizacji. Nie tylko z IT, ale również z recepcją, administracją, osobami odpowiedzialnymi za finanse, właścicielami procesów czy kierownikami poszczególnych obszarów.
Warto wspólnie ustalić, które systemy rzeczywiście zatrzymałyby pracę, gdyby przestały działać na kilka godzin, od jakich dostawców zależą kluczowe procesy i kto ma dostęp administracyjny do najważniejszych środowisk. Trzeba też wiedzieć, jak wygląda praca awaryjna, kto kontaktuje się z dostawcą, jak przebiega eskalacja i czy po incydencie zostają dane pozwalające ustalić, co właściwie się wydarzyło.
To jeszcze nie jest pełna analiza ryzyka, ale bardzo dobry początek. Po takiej rozmowie często wychodzą problemy, które wcześniej pozostawały niewidoczne: jedyny kontakt do dostawcy ma osoba, która nie zawsze jest dostępna, procedura awaryjna istnieje, ale zna ją tylko kierownik, backup jest wykonywany, ale nikt od dawna nie sprawdzał jego odtworzenia, a konto założone kilka lat wcześniej nadal ma szerokie uprawnienia.
I właśnie wtedy analiza ryzyka przestaje być dokumentem, a zaczyna być rozmową o tym, jak naprawdę działa organizacja.
Dobra analiza ryzyka nie powinna kończyć się na kolorowej tabelce
Samo hasło „analiza ryzyka” brzmi jak coś przygotowywanego dla audytora. Prawdopodobieństwo trzy, wpływ cztery, ryzyko dwanaście, komórka zmienia kolor i temat można uznać za zamknięty.
Z punktu widzenia osoby zarządzającej organizacją liczba 12 niewiele jednak wyjaśnia.
Dużo bardziej użyteczne jest pytanie, co dokładnie wydarzy się u nas, jeśli dany scenariusz rzeczywiście się zrealizuje. Jeżeli rano nie działa system, warto wiedzieć, czy recepcja może dalej przyjmować pacjentów, do jakich danych zachowuje dostęp, jak długo organizacja może funkcjonować bez rozwiązania podstawowego i kto podejmuje decyzję o przejściu na tryb awaryjny.
W ten sposób ryzyko zaczyna mieć konkretny wymiar. Nie jest już abstrakcyjną wartością, ale odpowiedzią na pytanie, w którym momencie problem techniczny zacznie wpływać na operacje, finanse, jakość obsługi czy reputację placówki.
Następny krok: sprawdzić, czy nasze założenia są prawdziwe
I tutaj pojawia się miejsce na testy techniczne.
Organizacja może być przekonana, że jej systemy są odpowiednio rozdzielone, konto dostawcy ma ograniczone uprawnienia, a publiczna aplikacja nie daje żadnej drogi do bardziej wrażliwych danych. Takie założenia mogą być prawdziwe, ale dopóki nie zostaną zweryfikowane, pozostają tylko założeniami.
Dlatego pentest ma największą wartość wtedy, kiedy nie jest zamawiany po prostu po to, żeby „zrobić pentest”. Znacznie więcej daje postawienie konkretnego pytania: czy przejęcie tej aplikacji może prowadzić do danych pacjentów, czy konto zewnętrznego dostawcy pozwala dotrzeć dalej, niż zakładaliśmy, albo czy błąd w jednym systemie może wpływać na drugi, istotniejszy proces.
Wtedy raport nie jest tylko listą podatności. Staje się sposobem na sprawdzenie, czy scenariusze, o których rozmawialiśmy podczas analizy ryzyka, rzeczywiście są możliwe.
Pentest, który dotyczy biznesu, daje więcej niż lista podatności
Raport techniczny musi zawierać informacje o podatnościach, ich znaczeniu i sposobie naprawy. To oczywiste. Dla organizacji często jeszcze ważniejsza jest jednak odpowiedź na pytanie, co ktoś rzeczywiście mógłby zrobić z wykorzystaniem znalezionego błędu.
Jeżeli tester dostał się do danych, do których nie powinien mieć dostępu, wiemy już coś istotnego o rzeczywistym poziomie ochrony. Jeżeli z jednego konta udało się przejść do kolejnego systemu, dostajemy informację o uprawnieniach i architekturze. Jeżeli podatność w publicznie dostępnej aplikacji pozwala wpłynąć na proces krytyczny dla działalności, mamy gotowy scenariusz ryzyka.
I wtedy warto zrobić coś więcej niż tylko poprawić błąd.
Trzeba zastanowić się, czy taki incydent zostałby zauważony, kto dostałby alert, jakie konto należałoby zablokować, jakie dane sprawdzić i czy organizacja potrafiłaby dalej działać podczas usuwania problemu. W ten sposób techniczny test zaczyna wspierać nie tylko bezpieczeństwo aplikacji, ale również odporność całego procesu.
Nie trzeba testować wszystkiego naraz
Jednym z częstszych błędów jest przekonanie, że wartościowy pentest musi od razu obejmować ogromną część organizacji. Nie zawsze ma to sens.
Jeżeli dopiero porządkujemy bezpieczeństwo, lepiej wybrać jeden proces, który ma realne znaczenie dla działalności. Może to być rejestracja pacjentów, portal pacjenta, aplikacja mobilna, API, panel administracyjny, dostęp wykorzystywany przez dostawcę, integracja z laboratorium albo system płatności.
Zamiast próbować odpowiedzieć na bardzo szerokie pytanie „czy jesteśmy bezpieczni?”, lepiej sprawdzić, co musiałoby się wydarzyć, żeby ten konkretny proces przestał działać albo żeby ktoś uzyskał dostęp do danych, których nie powinien zobaczyć.
Taki zakres daje znacznie bardziej użyteczną odpowiedź, bo można ją później przełożyć na konkretne decyzje po stronie organizacji.
Co zrobić po analizie i teście?
Najważniejsze jest to, żeby nie zatrzymać się na diagnozie.
Jeżeli już wiemy, gdzie znajduje się problem i jaki scenariusz jest dla organizacji istotny, można dobrać właściwe działania. W jednym przypadku będzie to ograniczenie uprawnień albo zmiana konfiguracji, w innym uporządkowanie dostępu dostawcy, sprawdzenie odtwarzania kopii zapasowej czy poprawienie segmentacji.
Czasami problem okaże się przede wszystkim organizacyjny. Wtedy większą wartość przyniesie przygotowanie procedury awaryjnej, wskazanie osób odpowiedzialnych za eskalację, uzupełnienie kontaktów po stronie dostawcy albo ustalenie, jakie informacje powinny być przekazywane podczas incydentu.
Może się też okazać, że brakuje monitoringu albo logów potrzebnych do późniejszej analizy. Innym razem najważniejsze będzie przeszkolenie pracowników, żeby wiedzieli, jak działać podczas awarii.
Nie ma jednej odpowiedzi dla wszystkich. Właśnie dlatego sensowna kolejność ma znaczenie: najpierw trzeba wiedzieć, czego się obawiamy i gdzie naprawdę leży ryzyko, a dopiero później dobierać zabezpieczenia.
Duży dostawca nie zwalnia z myślenia o własnej odporności
W relacjach z dostawcami jest jeszcze jedna pułapka.
Im większa firma, tym łatwiej założyć, że „oni na pewno mają to dobrze zabezpieczone”. Być może mają. Tylko że bezpieczeństwo dostawcy i odporność naszej organizacji nie są tym samym.
Dostawca może mieć świetnie zabezpieczoną infrastrukturę, a my nadal możemy mieć zbyt szerokie uprawnienia na własnym koncie. Może posiadać certyfikaty, procedury i całodobowy SOC, a nasza recepcja może nie wiedzieć, jak pracować podczas kilkugodzinnej awarii. Może też zgodnie z umową przywrócić usługę w określonym czasie, który z jego perspektywy jest rozsądny, ale dla placówki oznacza poważny problem operacyjny.
Dlatego nie wystarczy pytać, czy dostawca jest bezpieczny. Trzeba rozumieć, jak bardzo organizacja jest od niego zależna i co wydarzy się po naszej stronie, kiedy coś pójdzie nie tak.
Gdybym miała wskazać pierwszy krok
Nie zaczynałabym od zakupu rozwiązania ani od pisania kilkudziesięciu procedur.
Wzięłabym jeden proces, bez którego organizacja naprawdę nie chce zostać jutro rano, i rozłożyła go na części. Sprawdziłabym, jakie systemy są do niego potrzebne, którzy ludzie biorą w nim udział, od jakich dostawców zależy, gdzie znajdują się dane i jakie konta lub integracje mają największe znaczenie.
Dopiero wtedy zadałabym pytanie, co może przestać działać i jakie będą tego konsekwencje. Jeśli odpowiedź pokaże, że największą niewiadomą jest kwestia techniczna, można ją zweryfikować pentestem. Jeśli problemem jest brak procedury, trzeba ją przygotować. Jeżeli największe ryzyko wynika z relacji z dostawcą, trzeba przejrzeć umowę, zakres odpowiedzialności i sposób eskalacji.
Taka kolejność jest dużo ważniejsza niż liczba wdrożonych narzędzi.
Chcesz przejść przez to u siebie?
Do webinaru przygotowaliśmy prostą kartę dla placówki, która pomaga przejść przez najważniejsze pytania dotyczące zależności od dostawców, ciągłości działania i reakcji na incydent. Możesz wykorzystać ją jako punkt wyjścia do rozmowy wewnątrz swojej organizacji.
Bezpieczeństwo nie zaczyna się od pytania „co kupić?”
Znacznie lepszym początkiem są pytania o to, co może zatrzymać działalność, jak bardzo taki scenariusz zaboli organizację i czy ludzie będą wiedzieli, co zrobić, kiedy już się wydarzy.
Dopiero na tej podstawie można sensownie rozmawiać o narzędziach, procedurach, pentestach, monitoringu czy wymaganiach wobec dostawców.
W innym przypadku bardzo łatwo wydać dużo pieniędzy na bezpieczeństwo i nadal nie być przygotowanym na zdarzenie, które rzeczywiście zatrzyma biznes.
I chyba to jest najważniejsza rzecz, którą chciałabym zostawić po naszym webinarze.
Nie trzeba od razu robić wszystkiego. Trzeba wiedzieć, od czego zacząć.