Pechową dwunastkę* otworzy nam problem braku wiedzy. Wybór tego czynnika jako pierwszego wydaje się być oczywistym, a przy tym trywialnym wyborem. Gdy nie ma wiedzy, można co najwyżej mieć szczęście, cała reszta przypadków to wypadki, te znane i te ukrywane. Tutaj wszelkie oczywistości się kończą i poszukiwanie źródła problemu, zgodnie z wspomnianą zasadą wymaga wiedzy.
Na potrzeby tej formy, krótkiej i zwięzłej skoncentrujmy się na trzech przypadkach:
Prawdopodobnie większość z czytających tego bloga osób jest w stanie podać czy z własnego doświadczenia, czy zasłyszanych opowieści wiele przykładów tych błędów.
Ponownie odniosę się do najgłośniejszego incydentu z 2018 roku, włamania do Equifax, po wykorzystaniu niezałatanej luki w Apache Struts. Incydent wykryto po ponad 75 dniach, a można było praktycznie w ciągu jednego dnia. Ruch kierowany przez zaatakowany serwer webowy był poddawany inspekcji metodą przechwytywania ruchu szyfrowanego (HTTPS interception), dla którego krytyczny jest status certyfikatów używanych przez narzędzie realizujące inspekcję. W tym wypadku nieaktualny certyfikat (oraz idąc dalej, nieaktualne informacje o stanach certyfikatów oraz brak właściwego treningu operatorów technologii) doprowadził do wyłączenia inspekcji ruchu, tym samym nie pozwalając wykryć włamania. Po 75 dniach, gdy zorientowano się, że certyfikat nie jest aktualny i naprawie sytuacji, inspekcja została wznowiona co pozwoliło wykryć nieautoryzowany dostęp do wewnętrznych zasobów. Szczegóły można znaleźć między innymi tutaj.
Jak przeciwdziałać takim problemom?
Ustalić proces aktualizacji dokumentacji do stanu faktycznego – ta strategia, choć kosztowna, pozwala skrócić czas odpowiedzi na incydent i znacznie zredukować ilość incydentów poprzez dostęp osób realizujących operację do aktualnej dokumentacji, odzwierciedlającej bieżącą sytuację środowiska.
Wykonywać zadania do których zostaliśmy przeszkoleni – często występują sytuacje, gdy dla nowego produktu, lub zaktualizowanej technologii nie stosuje się szkolenia personelu stawiając go przed wyzwaniem, swoistym testem jego profesjonalizmu i zdolności rozwiązywania problemów. Ta krótkowzroczna oszczędność prowadzi do eksperymentowania, budowania hipotez o funkcjonowaniu technologii w oparciu o wiedzę z innych rozwiązań lub wersji, co prowadzi bezpośrednio do nieprofesjonalnego, opartego na próbach i zgadywaniu używania lub zarządzania nową technologią oraz nieuchronnego incydentu.
Nie próbować pomóc, jeśli nie wiemy jak to zrobić skutecznie – kluczowe jest tutaj „wiedzieć jak” co nie oznacza teoretycznej wiedzy, tylko praktykę. Prawdopodobnie, mając wystarczająco dużo czasu, dostęp do instrukcji, poradników i np. instruktażu na YouTube można poprawnie skonfigurować czy przywrócić dowolną technologię. Niestety rzeczywistość jest inna: niecierpliwa, zestresowana i pozbawiona drugiej szansy. Wiesz albo nie, czyli potrafisz lub nie próbuj. Obowiązuje tutaj zasada podobna jak w medycynie – po pierwsze nie szkodzić.
Na koniec zostawiłem najsilniejszą praktykę zaradczą – Jeśli nie wiesz – zapytaj! To trywialne i powszechnie znane rozwiązanie, zaskakująco często stosowane jest na końcu, błędnie przyjmowane jako porażka. Świadomość swoich ograniczeń, jest prawdziwą miarą profesjonalizmu zawodowego. Podobnie jak mierzenie sił na zamiary. Ta praktyka nie dotyczy tylko i wyłącznie problemu „wiem – nie wiem”, ale przede wszystkim upewnia Cię, że angażujesz się w sytuację którą rozumiesz, znasz jej bieżący stan.
W inicjatywie Kultury Bezpieczeństwa opracowaliśmy zestaw kompetencji, których rozwój pomaga sprawnie przeciwdziałać negatywnym efektom pechowej dwunastki poprzez usprawnienie bezpiecznej postawy.
Dla problemu braku informacji, polecam rozwijać kompetencje:
?Ochroń – znajomość ograniczeń technologii,
?Wykryj – znajomość stanu normalnego procesów i zdolność wykrywania anomalii,
?Szacunek – ograniczone zaufanie do siebie i innych ludzi oraz umiejętność rozpoznawania wpływu emocji na swoje decyzje,
?Rozwaga – zdolność przewidywania skutków swoich czynności.
Pełen program rozwoju własnej postawy bezpiecznej znaleźć można na blogu inicjatywy kultury bezpieczeństwa i w sieciach społecznościowych oraz YouTube.
Zdanie do przekazania innym i zapamiętania: „Jeśli nie wiesz – zapytaj!”
Artur Marek Maciąg
Inicjatywa Kultury Bezpieczeństwa, doświadczony ekspert i pasjonat bezpieczeństwa informacji.
* Pechowa Dwunastka to dwanaście czynników błędów ludzkich, które występując w pewnych okolicznościach praktycznie materializują incydent bezpieczeństwa.
Lista tych czynników jest następująca:
Kolejne artykuły naszego bloga poświęcamy analizie każdego z tych czynników w kontekście bezpieczeństwa teleinformatycznego i nie tylko.
Pechowa Dwunastka: Czy jesteś słabym ogniwem bezpieczeństwa informacji?
Koniec roku jest często okazją do podsumowań i przemyśleń co się udało (a co nie), zrealizować ze swoich zarówno biznesowych jak i osobistych planów. To też czas na ocenę zmian na rynkach, choć główna taka analiza przypada na okres, zamknięcia roku fiskalnego. Dla krajobrazu zagrożeń technologii informatycznych, czy tez „cyber”, podsumowania dostępne są już teraz, razem z szacunkami na przyszły rok. Zainteresowanych takimi informacjami odsyłam tutaj oraz tutaj. Nikogo nie powinno dziwić, że statystycznie liczba incydentów raportowanych w roku 2018 jest znacząco większa niż w latach wcześniejszych. Dzieje się tak czy to z uwagi na eksploatację sprawdzonych schematów przestępczych, dających coraz to większe zyski atakującemu, czy to lepszego raportowania, po części wynikającego z powstających jak grzyby po deszczu przepisów i regulacji. Taki mamy klimat i trzeba jakoś sobie radzić.
To co się dzieje w okolicy i w środowisku w którym zarabiamy i odpoczywamy to jedno, drugie, dużo ciekawsze dla nas osobiście – to czy mamy osobisty wkład w te statystyki. Rzeczywistość bywa brutalna a praktyka nie pozostawia złudzeń. Nawet ekspert od bezpieczeństwa informacji popełni raz w roku błąd który jest przyczyną potencjalnego incydentu bezpieczeństwa. Czasami jest to kwestia takiego samego hasła używanego w kilku miejscach, w tym służbowych i prywatnych. Czasami to pendrive na szybko wciśnięty w służbowe urządzenie, czy prywatny telefon z danymi (np. adresowymi) firmowymi. A czasami to konkretne i poważne „wykroczenia” jak praca zabrana do domu, czy to na służbowym laptopie podpinanym do nieznanych sieci, czy też mailem, bądź na niezarejestrowanym nośniku.
Czy to w ogóle ma znaczenie? Jeśli incydent się nie „zmaterializował” i jakoś się tym razem udało, to czy należy się tematem przejmować? Tak. Zdecydowanie. Raporty podsumowujące to zjawisko w szczegółach, w tym ten tutaj, nie pozostawiają złudzeń. Zdecydowana większość incydentów bezpieczeństwa występuje z uwagi na niepożądane zachowania ludzi. Co zatem można zrobić, by uchronić swój biznes i zredukować swoje przyszłe ryzykowne zachowania? Jakie postanowienia noworoczne mają sens aby zmniejszyć szansę wystąpienia błędu ludzkiego, który może zostać wykorzystany przez przestępców, w tym tych działających w cyberprzestrzeni?
Tym tekstem rozpoczynam serię artykułów poświęconych analizie typowych przyczyn błędów ludzkich. Źródłem tego materiału są poważne badania zrealizowane przez, ale i na zamówienie amerykańskich i kanadyjskich organizacji nadzorujących lotnictwo i wypadki lotnicze. Jak się okazuje, czy to lotnictwo, czy cyberprzestrzeń, wszędzie tam gdzie jest człowiek – popełnia te same błędy. I choć konsekwencje jeszcze dzisiaj są mniej bolesne i poważne dla błędów w cyberprzestrzeni, ten stan rzeczy zmienia się szybciej niż możemy przewidzieć. Już dzisiaj zdalnie sterowany cyfrowy rozrusznik serca może stanowić śmiertelne zagrożenie i okazję do żądań okupu ze strony przestępcy. Podobnie samochód, czy linia produkcyjna, której zabezpieczenia ktoś zdalnie deaktywuje narażając życie i zdrowie pracowników.
Wspomniane badania określane są listą Brudnej Dwunastki. W naszym kraju, nadaliśmy jej bardziej swojską nazwę Pechowej Dwunastki, głównie z uwagi na nasz powszechny zwyczaj usprawiedliwiania swoich porażek „pechem”. Od stycznia, miesiąc po miesiącu omawiać będziemy na łamach tego bloga kolejne czynniki, które samodzielnie stanowią jedynie zagrożenie, jednak w kumulacji, praktycznie materializują incydent. Każdą z kategorii omówimy w kontekście technologii i interakcji ludzi z jej użyciem. Poruszymy dostępne, realne przykłady incydentów i zrobimy projekcję na nowe technologie.
Lista czynników błędów ludzkich jest następująca:
I jak? Interesujące?
O tym, jak istotne jest zrozumienie wpływu tych czynników na bezpieczeństwo technologiczne Twojej firmy może świadczyć analiza mega wycieku informacji z Equifax (2017 rok). Raport udostępniony kilka dni temu wskazuje jako bezpośrednią przyczynę brak aktualizacji systemów informatycznych na znaną podatność w środowisku Apache Struts. Pośrednią przyczyną, wskazaną przez eksperta od analizy zachowań ludzkich w kontekście bezpieczeństwa systemów informatycznych, były konflikty personalne kierownictwa firmy i w ich efekcie wydłużenie linii raportowania CSO, oraz umieszczenie go w obszarze obsługi prawnej. Choć sytuacja konfliktu personalnego została rozwiązana tym sprawnym ruchem menadżerskim, dużo wcześniej przed atakiem i samym problemem podatności, miała ona istotny wpływ na operacyjną efektywność między innymi procesu łatania podatności, co umożliwiło włamanie.
Ten przykład pokazuje, że bezpieczeństwo systemów informatycznych, jest krytycznie zależne od ludzi, od tego czy, oraz jakie błędy popełniają a także czy się na nich uczą czy nie…
Do zobaczenia w styczniu 2019 roku.
Przy okazji warto wziąć sobie do serca jedną z porad Instytutu SANS dotyczącą zabezpieczenia urządzeń mobilnych przed nieautoryzowanym dostępem, oraz zaszyfrowanie ich zawartości. Okazuje się, że zgodne ze wspomnianym wcześniej raportem ponad 100 razy więcej urządzeń zostanie zgubionych niż faktycznie ktoś się na nie włamie. Pilnujcie zatem swoich urządzeń z danymi osobistymi i firmowymi podczas szampańskiej zabawy!
Spokojnego końca starego roku!
Artur Marek Maciąg
Inicjatywa Kultury Bezpieczeństwa, doświadczony expert i pasjonat bezpieczeństwa informacji.
W niniejszym artykule podzielimy się swoimi doświadczeniami z wykonywanych zawodowo procesów obsługi incydentów. Przedstawimy krajobraz, na jaki zwykle możemy natknąć się w organizacji bezpośrednio po wykryciu incydentu. Pokażemy przykłady błędnych działań, które są wtedy podejmowane, oraz takich, które powinny zostać podjęte.
Stare komputerowe porzekadło mówi, że administratorzy IT dzielą się na takich, którzy robią kopie zapasowe i na takich, którzy je będą robić. Na gruncie bezpieczeństwa IT można by powiedzieć, że firmy dzielą się na takie, które wykonują (zazwyczaj zlecają) testy bezpieczeństwa i takie, które kiedyś to zrobią. Należałoby tu też uczciwie zaznaczyć, że wykonane testy bezpieczeństwa (i oczywiście wdrożenie po nich poprawek) nie gwarantują, że do żadnego incydentu nie dojdzie. Takie działania po prostu wyeliminują szerokie spektrum zagrożeń technicznych, ale wciąż będzie mogło dojść do incydentu, którego źródłem będą metody socjotechniczne, np. phishing.
W każdym zatem wypadku warto na incydent być przygotowanym. Po pierwsze dlatego, że incydent wystąpi nagle, bez ostrzeżenia i prawdopodobnie w najmniej oczekiwanym przez organizację momencie (tu warto wtrącić, że atakujący z reguły najbardziej aktywni są w okolicach wolnych od pracy dni). Z jednej więc strony mamy niespodziewaną informację, że intruz kontroluje w jakimś stopniu naszą infrastrukturę, z drugiej nie wiemy właściwie w jakim zakresie i jakie ma zamiary. Nie wiemy, czy przerwał swoje działania czy może właśnie wyprowadza bądź niszczy nasze dane.
Można by się pokusić o porównanie włamania cybernetycznego z włamaniem fizycznym do lokalu bądź budynku i to drugie okaże się dla ofiary bardziej komfortowe, jakkolwiek by to nie brzmiało. Stwierdzić, że złodzieja nie ma w lokalu jest relatywnie łatwo i można to zrobić we własnym zakresie (teoretycznie, w praktyce zalecamy pomoc Policji). Nie nastręczy też większych problemów ustalenie jakich dóbr w lokalu ubyło i jakie zostały zniszczone. Zupełnie inaczej sprawy się mają w wypadku ataku IT, bo po pierwsze system komputerowy jest daleko bardziej skomplikowany niż mieszkanie a po drugie zawłaszczenia dóbr cyfrowych z reguły zwyczajnie nie widać. Wszystko to każdy administrator systemu czuje intuicyjne, ale ta wiedza niekoniecznie pomaga w działaniach. Ta świadomość oraz presja czasu ze strony przełożonych, współpracowników czy klientów mogą przekładać się (i przekładają się) na nieprzemyślane działania.
Najczęstszym działaniem w tego rodzaju okolicznościach jest odłączenie systemu komputerowego od zasilania, co jest kardynalnym błędem. Wyłączenie zasilania jest rozwiązaniem typowo chwilowym, które co prawda pozwoli przerwać atak, ale jednocześnie bardzo skutecznie zatrze jego ślady. Dla jasności powiedzmy, że tzw. grzeczne zamknięcie systemu (ang. shutdown) nie jest tu bardziej korzystne – a zapewne może i mniej. Dlaczego tak jest? W ulotnej pamięci operacyjnej komputera przechowywane są najważniejsze z punktu dalszego dochodzenia okoliczności ataku informacje: zainfekowane procesy systemowe, własne procesy atakujących czy informacje o otwartych połączeniach sieciowych. Zainfekowany komputer należy zatem odłączyć od sieci informatycznej – najpewniej jest wyciągnąć wtyczkę Ethernet z gniazdka. Dzięki temu definitywnie zostanie przerwana komunikacja pomiędzy maszyną a atakującym: więcej danych komputera nie opuści i nie zostaną też przekazane kolejne instrukcje z zewnątrz. To nam wystarczy.
No dobrze, a co jeśli zaatakuje nas nie człowiek, a skrypt, pokroju szyfrujących Wannacry czy CryptoLockera? Po odłączeniu komputera od sieci należy go zahibernować. Hibernacja (na szczęscie dostępna w każdym systeme rodziny Windows, ulubionej przez szkodliwe szyfratory), spowoduje, że szyfrowanie zostanie przerwane, a znajdujące się w pamięci operacyjnej dane (klucze szyfrujące), które mogą pomóc w deszyfracji danych przez specjalistę nie znikną z naszego zasięgu.
Przestrzeganie przedstawionych prostych zasady samo w sobie w ogromnym stopniu ułatwi proces późniejszego łagodzenia skutków incydentu teleinformatycznego. Należy jednak pamiętać, iż organizacja powinna wypracować na swój użytek bardziej złożone procedury reakcji na incydent bezpieczeństwa, które będą uwzględniały specyfikę danego środowiska, np. krytyczności i zależności systemów komputerowych czy kompetencje pracowników. Istnieją też różne kategorie incydentów i w ślad za nimi warto mieć różne warianty postępowań.
Od niedawna dużą rolę odgrywa też wszechobecne RODO – na zgłoszenie incydentu z udziałem danych osobowych mamy 72h, czyli 3 doby. W praktyce to nie jest wiele czasu, żeby choć wstępnie zapanować nad poincydentalnym chaosem i ocenić, czy faktycznie doszło do naruszenia ochrony danych osobowych. Procedury na taką okoliczność mogą okazać się zbawienne. Warto o tym pamiętać.
