Po wycieku z Medyc: 5 pytań, które zarząd powinien zadać swojemu dostawcy oprogramowania
Po raz kolejny miał miejsce wyciek danych Polek i Polaków. Czy to powód do obaw firm o własne systemy?
Podatność stara jak świat, czyli SQL injection, została wykorzystana do kradzieży danych z bazy systemu Medyc produkowanego przez Qbusoft. Naturalnie rodzi to obawy o bezpieczeństwo wykorzystywanych przez nas systemów IT. Szczególnie tych od zewnętrznych dostawców, jak systemy ERP i CRM.
Czy jest czego się bać?
Do odpowiedzialności za ten i poprzedni wyciek danych medycznych (MyDr) przyznaje się ktoś (lub grupa) pod pseudonimem "fingerprint".
Fingerprint wydał jednak oświadczenie, że nie sprzedaje danych, a swoimi działaniami chce zwrócić uwagę na kruchość zabezpieczeń europejskich systemów. Nie zmienia to jednak faktu, że w taki sposób mogą działać też inni, z mniej szlachetnymi celami.
Co ciekawe, Fingerprint twierdzi, że odsyła kontakty chętnych na zakup danych do polskich służb.
Skąd wiedzieć, czy jesteśmy bezpieczni - pytania
Z zasady nigdy nie wiesz na pewno, dopóki nie jest po fakcie. Natomiast jest kilka rzeczy, które można zrobić wcześniej. Poniżej spisuję listę 5 pytań, które każdy zarząd powinien zadać sobie oraz dostawcom zewnętrznego oprogramowania.
Pytanie 1: Co stanie się z produkcją, jeśli system od dostawcy ulegnie awarii na 24, 48 i 72 godziny?
Czy operacyjne działanie firmy jest uzależnione od systemu z zewnątrz? Czy możemy ufać, że dostawca nie zaburzy jego działania w złej wierze? Albo, co bardziej prawdopodobne, co stanie się w przypadku zwykłej awarii, błędu podczas aktualizacji albo ataku ransomware?
W firmach produkcyjnych, budowlanych czy logistycznych system ERP, CRM, WMS lub MES często jest elementem krytycznej infrastruktury. Jego niedostępność może oznaczać nie tylko brak dostępu do danych, ale realne problemy z realizacją zamówień, planowaniem produkcji czy obsługą klientów.
Dlatego warto zapytać dostawcę nie tylko o to, czy system ma działać, ale przede wszystkim: jak długo może nie działać i co wtedy robimy?
Czy mamy procedurę awaryjną? Czy możemy pracować ręcznie? Czy mamy dostęp do ostatniej kopii danych? Jak szybko dostawca jest w stanie przywrócić usługę?
To są pytania o ciągłość działania, a nie tylko o bezpieczeństwo IT.
Pytanie 2: Co naprawdę wiemy o naszych dostawcach IT i fizycznej lokalizacji przechowywania danych?
Kupując system ERP czy CRM, często patrzymy przede wszystkim na funkcjonalność. Czy system robi to, czego potrzebujemy? Czy integruje się z naszymi procesami? Ile kosztuje?
Bezpieczeństwo infrastruktury schodzi gdzieś na dalszy plan.
Warto jednak wiedzieć, gdzie faktycznie znajdują się nasze dane. Czy są przechowywane na serwerach dostawcy? W chmurze? W jakim kraju? Kto administruje infrastrukturą? Czy dostawca korzysta z kolejnych podwykonawców?
I przede wszystkim: co dzieje się z naszymi danymi, jeśli dostawca przestanie istnieć, zakończymy współpracę albo jego infrastruktura zostanie zaatakowana?
Nie chodzi o to, żeby zarząd znał techniczne szczegóły infrastruktury. Chodzi o to, żeby wiedział, komu powierzamy dane firmy i jakie mamy gwarancje ich odzyskania.
Pytanie 3: Jak wygląda proces udzielania i odbierania dostępu pracowników do poszczególnych części systemów?
To jedno z tych pytań, które wydaje się banalne, dopóki nie okaże się, że były pracownik nadal ma dostęp do systemu.
Warto sprawdzić, czy dostępy są nadawane zgodnie z konkretną rolą i zakresem obowiązków. Czy pracownik działu handlowego naprawdę potrzebuje dostępu do danych produkcyjnych? Czy administrator dostawcy ma stały dostęp do systemu, czy tylko wtedy, kiedy jest to konieczne?
I co dzieje się w momencie zmiany stanowiska albo odejścia pracownika?
Dobrą praktyką jest zasada najmniejszych niezbędnych uprawnień. Użytkownik powinien mieć dostęp tylko do tych danych i funkcji, których rzeczywiście potrzebuje i nic więcej.
Warto również wiedzieć, czy działania administratorów są rejestrowane. Jeżeli ktoś ma możliwość zmiany danych, konfiguracji systemu czy nadawania uprawnień, powinniśmy móc później sprawdzić, kto i kiedy wykonał daną operację.
Pytanie 4: Poza disaster recovery, czy jesteśmy przygotowani na ewentualny cyberatak?
Backup i disaster recovery to bardzo ważne elementy bezpieczeństwa, ale nie są magiczną tarczą chroniącą przed cyberatakiem.
Warto więc zadać dostawcy trochę trudniejsze pytanie: co się stanie, jeśli ktoś rzeczywiście włamie się do systemu?
Jak wygląda proces wykrycia i obsługi incydentu? Kto zostanie poinformowany? Jak szybko? Czy system można odizolować? Czy backupy są również zabezpieczone przed usunięciem lub zaszyfrowaniem przez atakującego?
I jeszcze jedna ważna kwestia - czy procedury były kiedykolwiek testowane?
Bo można mieć świetnie wyglądający dokument opisujący disaster recovery, ale dopiero jego praktyczne przetestowanie pokazuje, czy firma rzeczywiście jest w stanie wrócić do działania po poważnym incydencie.
Pytanie 5: Skąd dostawca wie, że w jego kodzie nie ma takich dziur jak w Medyc?
Wszystkie poprzednie pytania dotyczą tego, co dzieje się wokół systemu. Wyciek z Medyc nie wynikał jednak z awarii serwera ani z nadmiarowych uprawnień pracownika. Wynikał z błędu w samym kodzie aplikacji.
SQL injection to sytuacja, w której aplikacja traktuje dane wpisane przez użytkownika jak fragment polecenia dla bazy danych. Zamiast nazwiska można wtedy „wpisać” instrukcję, która wyciągnie całą tabelę. Ochrona przed tym jest znana od dekad i nie wymaga żadnej wyrafinowanej technologii. Wymaga natomiast tego, żeby ktoś kod przejrzał i przetestował pod kątem bezpieczeństwa.
Możemy mieć perfekcyjne backupy, dobrze poukładane uprawnienia i przetestowany plan disaster recovery, a mimo to stracić całą bazę przez jedno pole w formularzu.
Dlatego warto zapytać dostawcę: jak sprawdzacie bezpieczeństwo tego, co piszecie?
Czy system przechodzi regularne testy penetracyjne? Czy robi je niezależna firma, a nie sam dostawca? Czy możemy zobaczyć raport albo chociaż jego podsumowanie? Czy kod jest przeglądany przez innych programistów przed wdrożeniem? Czy dostawca korzysta z narzędzi, które automatycznie wyłapują znane podatności?
I równie ważne: jak szybko reaguje, kiedy podatność zostanie znaleziona? Ile czasu mija od wykrycia krytycznego błędu do wdrożenia poprawki u klienta? Czy istnieje sposób, żeby osoba z zewnątrz mogła zgłosić znaleziony problem, zanim zrobi to ktoś inny?
Dostawca, który poważnie traktuje bezpieczeństwo, odpowie na te pytania bez problemu. Jeśli zamiast konkretów słyszymy ogólniki, to też jest odpowiedź.
Bonus: A co z czynnikiem ludzkim?
Bezpieczeństwo systemów to jedno. Człowiek pozostaje jednak jednym z kluczowych elementów całego łańcucha bezpieczeństwa.
Możemy mieć dobrze skonfigurowany firewall, szyfrowanie, backupy i wielopoziomowe zabezpieczenia, a mimo tego jeden klik w odpowiednio przygotowany e-mail może wystarczyć, żeby rozpocząć cały incydent.
Czy pracownicy wiedzą, jak rozpoznać phishing i próby socjotechniczne? Czy wiedzą, co zrobić, kiedy otrzymają podejrzaną wiadomość? Czy wiemy, kto ma dostęp do krytycznych danych? I czy uprawnienia są regularnie weryfikowane, szczególnie po zmianie stanowiska lub odejściu pracownika?
W bezpieczeństwie nie chodzi więc tylko o to, czy mamy zabezpieczenia. Chodzi również o to, czy wiemy, jak zachowa się organizacja, kiedy ktoś spróbuje je ominąć.
Jeśli tematy, które poruszyłem, Cię zainteresowały, rozważ zaobserwowanie moich social mediów, aby nie przegapić kolejnych wpisów.
Źródła:
