Luźny komentarz: Co uczy nas incydent z CrowdStrike? Czy Microsoft wprowadzi rygorystyczne wymagania dla kodu działającego w jądrze systemu?

Wadliwa aktualizacja systemu CrowdStrike doprowadziła do awarii niemal 8,5 miliona urządzeń z systemem operacyjnym Windows – szacuje Microsoft.

Chociaż to i tak mniej niż 1 procent wszystkich urządzeń z Windows, to Microsoft zapowiedział, iż Windows powinien być lepiej zabezpieczony przed podobnymi awariami. Może się to skończyć tym, iż Microsoft wprowadzi dodatkowe wymagania dla deweloperów oprogramowania, którzy korzystają z uprawnień na poziomie jądra systemowego. Na razie jest mało prawdopodobne, aby Microsoft poszedł teraz drogą Apple i wprowadził całkowity zakaz uruchamiania kodu na poziomie jądra, ponieważ wiążą go umowy – w Europie system operacyjny Windows musi zapewniać takie same uprawnienia innym produktom bezpieczeństwa, jakie posiada Microsoft Defender. Komentarze, iż Microsoft Defender będzie w uprzywilejowanej pozycji są na razie nietrafione, aczkolwiek nie można tego całkowicie wykluczyć.

Większość systemu w Windows jest zwykle ograniczona do uprawnień użytkownika, dlatego szkodliwy kod (z tymi samymi uprawnieniami) nie może wyrządzić większej szkody. Co innego oprogramowanie z dostępem do trybu jądra, które może spowodować globalną awarię.

CrowdStrike nie było w stanie uszkodzić komputerów z macOS i Linux, ponieważ Apple nie daje producentom systemu dostępu do jądra. W systemie macOS, Apple umożliwia dostęp do krytycznych obszarów poprzez rozszerzenia systemowe, które mimo wszystko działają w przestrzeni użytkownika, a nie na poziomie jądra. Oto przykład modułów możliwych do konfiguracji i nadawania uprawnień:

Błędy na poziomie jądra

Cóż… Awarie, taka jak ta, mogą unieruchomić system operacyjny, a choćby miliony systemów operacyjnych jedną, wadliwą aktualizacją:

Rozważmy teoretycznie, jakie plusy oraz minusy daje uruchamianie kodu w lub poza jądrem:

1. Działanie systemu bezpieczeństwa wyłącznie poza jądrem może zmniejszyć ryzyko podobnych awarii, ale…
2. Brak dostępu do jądra byłoby wielkim ograniczeniem dla dostawców zabezpieczeń, produkty byłyby mniej skuteczne w przypadku detekcji rootkitów i malware atakującego sektory startowe MBR lub UEFI.
3. Działanie w jądrze daje więcej informacji zwrotnych na temat tego, co dzieje się w systemie – moduły ochronne mogą wyprzedzać złośliwe oprogramowanie zanim wyrządzi ono jakieś szkody.
4. Kod, który działa w jądrze i staje się niepodpisany lub traci ważność certyfikatu (wygasa lub zostaje wycofany) stwarza wysokie ryzyko wystąpienia awarii.

Zatrzymując się przy punkcie nr 2:

Oprogramowanie bezpieczeństwa spowodowało poważną awarię o globalnych konsekwencjach. Coś, co działa w trybie jądra, wprowadza prędzej czy później niestabilność systemu. W przypadku CrowdStrike stało się to później. Wydaje się też, iż tego typu rozwiązanie bezpieczeństwa i tak może być nieskuteczne. Spójrzmy na tak zwane warunki korzystania z systemu CrowdStrike w punkcie 6.2:

Teoretycznie poleganie na tej architekturze cyberbezpieczeństwa, która zależy od ciągłych aktualizacji modułu dla jądra systemu, będzie w dłuższym terminie nieskuteczne. Dodatkowo jak zaufać dostawcy, który nie daje żadnych gwarancji walki ze złośliwym oprogramowaniem?

Kto odpowiada za katastrofę?

W komentarzach od CISO ze świata da się przeczytać, iż dostawcy cyberbezpieczeństwa powinni audytować swoje oprogramowanie przez niezależne strony trzecie, jak i kod open source swoich produktów, aby budować do siebie zaufanie. Ponadto na szefach ds. bezpieczeństwa spoczywa odpowiedzialność za ochronę infrastruktury przedsiębiorstwa. Nie uważam, aby teraz wszyscy CISO powinni przeprowadzać audyt i tworzyć plan wycofania systemu z organizacji oraz informować zarząd o potencjalnych zagrożeniach, ale co mogą zrobić, o ile działa ono w trybie jądra i może doprowadzić do podobnej sytuacji?

Przykład CrowdStrike warto brać pod uwagę tworząc jakiekolwiek procedury na temat krytycznych usług, które są NIEZBĘDNE do funkcjonowania organizacji. W przeciwnym wypadku ignorowanie takiej „podatności” może kiedyś doprowadzić do poważnych awarii, w konsekwencji naruszeń danych, awarii systemu, znacznych strat finansowych, wizerunkowych.

W Polsce jeszcze nie tak bardzo, ale akcjonariusze spółek mogą oczekiwać od CISO wzięcia odpowiedzialności cywilnej lub karnej za zaistniałą katastrofę. Za granicą CISO za incydenty odpowiadają osobiście wskutek rządowych regulacji nałożonych na duże firmy. Po wprowadzeniu GDPR (RODO) za naruszenia ochrony danych osobowych odpowiedzialność ponosi przede wszystkim organizacja, ale w przypadku zaniedbań można pociągnąć do odpowiedzialności cywilnej lub karnej osoby zajmujące najważniejsze stanowiska, w tym CISO.

W USA odpowiedzialność CISO jest bardziej rozbudowana, co wynika z licznych przepisów federalnych i stanowych dotyczących ochrony danych. Przykłady takich ustaw to California Consumer Privacy Act (CCPA) czy Health Insurance Portability and Accountability Act (HIPAA). W USA coraz częściej pojawiają się przypadki, w których CISO są bezpośrednio pociągani do odpowiedzialności za naruszenia bezpieczeństwa, szczególnie jeżeli można wykazać, iż nie dołożyli należytej staranności w swoich działaniach.

I tak np.:

• Joseph Sullivan, były dyrektor ds. bezpieczeństwa w Uberze (były, ponieważ został zwolniony), został oskarżony o ukrywanie wycieku danych 57 milionów użytkowników i kierowców Ubera. Sąd skazał go na 3 lata w zawieszeniu oraz 50 tys. dolarów grzywny.
• W 2017 roku doszło do masowego naruszenia danych w firmie Equifax, gdzie wyciekły dane osobowe ponad 147 milionów osób. Była CISO została skrytykowana za zarządzanie incydentem, a sama firma zapłaciła wielomilionowe kary.
• W 2018 roku British Airways stało się ofiarą cyberataku, który spowodował wyciek danych osobowych setek tysięcy klientów. Firma została ukarana karą w wysokości 20 milionów funtów, jednak odpowiedzialność indywidualna CISO była również przedmiotem dyskusji. Ostatecznie nie pociągnięto nikogo do odpowiedzialności karnej.
• W Polsce Bank Millennium został ukarany grzywną w wysokości 80 tysięcy euro za niepowiadomienie o naruszeniu danych osobowych odpowiednich organów i osób poszkodowanych.
• Santander Bank Polska otrzymał karę w wysokości 1,4 miliona złotych za niewłaściwe zgłoszenie naruszenia ochrony danych osobowych, co również mogło być związane z błędami na poziomie zarządzania bezpieczeństwem informacji.
  
  

Przypadki te pokazują, iż chociaż kary nałożono na instytucje, to pokazują one także, jak ważna jest rola CISO i jakie mogą być konsekwencje w przypadku zaniedbań na tym stanowisku – szefowie ds. bezpieczeństwa mogą zostać pociągnięci do odpowiedzialności cywilnej lub karnej za brak odpowiedniego zarządzania ryzykiem.