W poprzednim wpisie przedstawiłem perspektywę klasycznego bezpiecznika, z działu bezpieczeństwa IT (czy cyberbezpieczeństwa, itd.), który odpowiada za klasyczny model zarządzania bezpieczeństwem w firmie, poprzez polityki, standardy, okresowe przeglądy, listy wymagań, skanery podatności, audyty i akceptacje.
Obiecałem też, że przedstawię jakich ryzyk dla firmy taki bezpiecznik nie widzi. No to zaczynamy. A zaczniemy od przedstawienia właściwej taksonomii ryzyka, raz - bym ja się nie pogubił w tym co napisze, a dwa - aby czytelnicy też mieli jasny przekaz. Wiem, niektórzy zaczną ziewać.. ale, ile razy wam się zdarzyło ostatnio powiedzieć o “ryzyku zakażenia się wirusem”, zamiast o szansie czy prawdopodobieństwie zakażenia się wirusem? Czy, wracając na nasze podwórko - o szansie kompromitacji jakiejś aplikacji? Jest różnica, prawda? I tak ma być.
Po co?
Do czego nam są potrzebne w ogóle te ryzyka? Do tego aby zredukować “szarą mgłę niepewności” i doprowadzić do oszacowania potencjalnych strat w sposób policzalny, na podstawie obserwacji i zebranej informacji (informacji wg matematycznej definicji Shannona). A więc, nie policzalny tak, że: 3 x LOW, 2 x MEDIUM, 1x HIGH - czy innej wydumanej skali porządkowej, tylko w sposób policzalny (najlepiej w $$$ czy osobodniach, itd.) bo to pozwoli po prostu podjąć właściwą albo właściwszą decyzję zarządczą. Czy też pozwoli na dokładniejsze wnioskowanie z obserwacji audytowych.
Poniżej, przedstawię definicje (pewnie, jest wiele ich odmian, w zależności od metodyk, przyjętych taksonomii, czy profilowania zagrożeń w różnych gałęziach przemysłu, gospodarki, itd.). Nie przedstawiam ich po to by tu zrobić show, tylko po to aby uzmysłowić jak nielogicznie czasem stosujemy te pojęcia.
Pojęcia podstawowe
Zagrożenia, podatności, ryzyka .. terminy często, nieprawidłowo używane zamiennie. Najczęściej mylimy zagrożenia z ryzykami, bądź podatności z ryzykami (mówiąc, że “podatności stanowią ryzyko”, chociaż słyszałem też, że “podatność niesie zagrożenie”). Otóż nie, podatności nie “stanowią żadnego ryzyka”, dopóki nie zdamy sobie sprawy jakie zagrożenia mogą oddziaływać na taką podatność i jakie mogą być konsekwencje takiego oddziaływania. Słowem - informacja, że w systemie X jest podatność Y, “wyceniona” wg CVSS v3 na HIGH - naprawdę nie jest informacją, na podstawie której możemy właściwie wycenić jakiekolwiek ryzyko i w ciągu 30 sekund “ekspercko” z powagą rzec, że “tak, ta podatność to ryzyko HIGH”. Czy powiemy kiedykolwiek, że “moja czaszka, mająca bardzo ograniczoną wytrzymałość mechaniczną, powoduje że jestem chodzącym ryzykiem HIGH?” :) Czy biegamy w tytanowym kasku bez względu na okoliczności? :)
Zagrożenia
- Zagrożenie - Są to dynamicznie zmieniające się okoliczności i zdarzenia w bliższym i dalszym otoczeniu danego obiektu, czy grupy obiektów, które w sposób losowy, bądź intencjonalny mogą oddziaływać na nasze obiekty, powodując straty w tych obiektach. Zagrożenia w bezpieczeństwie mają zidentyfikowane atrybuty (dla łatwiejszego i jednoznacznego opisu i dalszych analiz) i są to:
- zdarzenia materializacji zagrożeń (jakieś zdarzenie w czasie musi wystąpić, aby uznać, że zagrożenie faktycznie istnieje,
- nośniki/aktorzy zagrożeń (żeby zdarzenie nastąpiło, ktoś lub coś musi je do naszego obiektu przynieść, słowem - coś/ktoś musi mu zagrozić),
- profil zagrożeń (albo inaczej intencje z powodu których, ktoś/coś nam grozi, ale częściej ktoś):
- Motywy,
- Główny cel działania,
- Preferowane obiekty ataku,
- Zdolności do działania i umiejętności,
- Tolerancja na ryzyko (liczy się, czy się nie liczy ze stratami własnymi),
- tolerancja na zniszczenia uboczne (np. w działaniach wojennych - straty ludności cywilnej)
Przykład 1: co jest a co nie jest zagrożeniem:
- APT - jak sama nazwa wskazuje z j. angielskiego Advanced Persistent Threat - nie jest to jednak zagrożenie. To już jest atrybut zagrożenia - scenariusz zdarzenia, zdefiniowany przez aktorów i ich intencje (profil). Prościej - forma ataku.
- DDoS - nie, to nie zagrożenie, to już też forma ataku, która może być przeprowadzona przez kogoś, bądź zrealizowana nieintencjonalnie, np. przez źle funkcjonujące komponenty naszego środowiska IT.
- Zorganizowana przestępczość - tak, to jest zagrożenie, które po właściwym opisaniu profilu, aktorów i analizy zdarzeń w przeszłości, pozwoli nam ocenić, jakie szkody może nam przynieść w danym czasie, z jakimś prawdopodobieństwem.
- Wewnętrzny użytkownik uprzywilejowany - tak, to też stanowi zagrożenie, tylko na miłość boską! nie lećcie od razu i nie strzelajcie do adminów! :)
- Zewnętrzny użytkownik ale nieuprzywilejowany - to też zagrożenie, tak, wiem co czują admini.. szczególnie forów internetowych..
Podatności
- Podatność spadek odporności na zagrożenia spowodowany albo przez rosnącą listę zagrożeń (pojawienie się nowych nieprzewidzianych zagrożeń) albo przez intensyfikację bieżących zagrożeń (nie tylko jedna grupa hakerska ma nas na celowniku, ale jest ich już całe stado, bądź też nasz firma trafiła na czarną listę rządu Chin Ludowych) albo spadek jakości zabezpieczeń obiektu (tu ukłon: taadaam! brak okresowego patchowania! ale nie tylko). Nie muszę zaznaczać, że to wszystko dzieje sie w czasie, a więc ma charakter dynamiczny.
Przykład 2: aby właściwie ocenić podatność, prawdopodobieństwo wystąpienia straty i oszacować samą stratę, należy zidentyfikować właściwy kontekst - czyli właściwie sprofilować i ocenić zagrożenie. Nie wszystko jest 0-dayem, czyli czymś co ma określone i oszacowane zagrożenie i zidentyfikowaną podatność, a także częstość wystąpienia i prawdopodobnie jakieś skutki, które można ekstrapolować na własne środowisko.
- Jest sobie baza danych służąca do przechowywania jakichś porządkowych metadanych jakiegoś komponentu IT. Dostawca tego komponentu dostarczył całość z tą bazą w wersji 1.2.3. Skaner podatności poprzez agenta na hoście wykrył, że baza w tej wersji ma podatność ocenioną wg CVSS v3 na MEDIUM. Łatać! Zakrzyknął z dzikim entuzjazmem nasz bezpiecznik. Nie, no moment - my wszystko fersztejen, ale gdzie jest zagrożenie? Nie ważne! Łatać, w tabelce jest wyraźnie: “MEDIUM - Łatać!”. I teraz jest tak - spędziwszy dwa osobodni na rozpracowanie wewnętrznych bebechów tego komponentu i ocenę co się stanie jak podbijemy wersje z 1.2.3 na 1.5.7, chociaż dostawca wyraźnie napisał w dokumentacji produktu, że ta funkcjonalność, która jest podatna nie jest wykorzystywana w ogóle, dlatego nie leci w koszty i nie podbija wersji, ani nie zaleca. Następne dwa osobodni spędziłem na dyskusjach, że potencjalny złoczyńca najpierw musiałby wbić na roota, tylko po to żeby dostać się do bazy na użytkowniku usługowym (nieuprzywilejowanym) i tylko po to by ściągnąć sobie jakieś metadane do layoutu UIa czegoś tam. A jak już wbiłby na roota (właściwe mechanizmy kontrolne zaimplementowane) to naprawdę bezpieka miałaby znacznie większy problem niż moje metadane. Wtedy zdałem sobie sprawę, że właśnie przynieśliśmy firmie stratę w postaci 4 osobodni, tylko dlatego że bezpieczeństwo w swoim raporcie z podatności nie odniosło się do właściwego kontekstu. Ok, być może są to koszta wpisane w proces zarządzania podatnościami, z jakąś analizą ROSI w tle (he,he, he). Samo istnienie podatności nie implikuje straty ..czy szansy na stratę, bo nie mamy jej jak oszacować! - a więc ryzyka.
c.d.n. (obiecuję dojść w następnym odcinku do meritum). :)