OSSTM v3, część pierwsza - defincje

Nie będę udawał - pisze to głównie dla siebie. Tak, by napisawszy jeszcze lepiej zrozumieć i usystematyzować. Taki sposób, by angielski ponad dwustu stronicowy podręcznik rozumieć, a nie znać na pamięć. Jednocześnie - być może komuś się przyda ta wiedza. Zwłaszcza, że to OS.

OSSTM

Czyli Open Source Security Testing Methodology (Manual) to podręcznik opisujący metodę przeprowadzania testów bezpieczeństwa. Podkreślam, że nie chodzi tutaj o pentesty, podręcznik etycznego hakiera, ani manual do metasploita. To podręcznik, który opisuje sposób weryfikacji bezpieczeństwa środowiska informatycznego (z naciskiem na ataki z zewnątrz).

Semantyka

W języku angielskim występują dwa słowa, które tłumaczone na polski mają takie samo brzmienie - safety i security. Oba ta słowa w OSSTMM występują i mają inne znaczenie. Różnica polega na tym, że safety (ja będę tłumaczył na bezpieczeństwo) to stan, w którym zagrożenia lub jego skutki są znane i kontrolowane (controlled). Kontrolowane natomiast znaczy, że organizacja jest przygotowana na wystąpienie zagrożenia (czy to przez zabezpieczenia, przeniesienie ryzyka [ubezpieczenie itd.] czy jego akceptację).

Security ja tłumacze na zabezpieczenia. Czyli... zabezpieczenia sensu stricte. Dla pewności - to elementy separujące między aktywami i zagrożeniami lub ich eliminacja (aktywów i zagrożeń).

Po co mi metodologia?

Nie będę odkrywczy - po co wymyślać koło na nowo, skoro można sięgnąć po gotowe i przeznaczone do sięgania po nie? Na dodatek otrzymujemy pełny sposób by wiarygodnie (a przez wiarygodnie mam na myśli poziom akceptowany przez znaczną część organizacji, które tematem się zajmują) ocenić poziom bezpieczeństwa.

Definicje

Powierzchnia ataku

Attack surface - luka w separacji lub procesie kontroli, dla której istnieje wektor ataku.

Wektor ataku

Attack vector - podatny kierunek (sposób) interakcji. Przykład - wystawiamy do internetu serwer, do którego dostać można się tylko przez SSH. Powierzchnia ataku to właśnie SSH. Wektorem ataku będzie exploit na starego deamona, ale także atak brute force. Oczywiście tylko wtedy, gdy deamon faktycznie będzie podatny na exploit, a hasło nie będzie odpowiednie lub (co bardzo istotne) nie będziemy przygotowani (nie będziemy kontrolować) na sytuację utraty kontroli nad serwerem przez kompromitację SSH.

Kontrola

Controlls - zabezpieczenie przeciw zagrożeniom lub na wypadek udanego ataku. OSSTMM podaje ciekawy przykład sklepu. Jeśli wybuchnie pożar w magazynie, to kontrolujemy tę okoliczność, gdy towar jest ubezpieczony, mimo, że ubezpieczenie nie obroni nas przed pożarem. O kontrolingu więcej w dalszej części.

Ograniczenia

Limitations - wszystkie luki i słabości w zabezpieczeniach. Te zaś dzielimy na zaobserwowane i zweryfikowane.

Operacyjność

Operations - operacyjność to brak zabezpieczeń spowodowany koniecznością ich zniesienia. Na przykład w sytuacji, gdy prowadzimy serwis WWW nie będziemy blokować portu 80.

Idealne bezpieczeństwo

Perfect Security - idealny balans między bezpieczeństwem i kontrolingiem a ograniczeniami i operacyjnością.

Porowatość

Porosity - właściwość zabezpieczenia polegająca na rozluźnieniu zasad zabezpieczeń. Na przykład - firewall pozwala na przepuszczenia pakietów HTTP przez port 80, ale żadnych innych.

Więcej o zabezpieczeniach, kontroli i ograniczeniach

Mając już ten krótki słownik pojęć można przyjrzeć się dokładniej najważniejszym zagadnieniom. Przede wszystkim o zabezpieczeniach, kontroli jaką można przez nie uzyskać i ograniczeniom, jakie mogą mieć.

Zabezpieczenia

Zabezpieczenia są pochodną separacji. OSSTMM wyróżnia trzy podstawowe sposoby stworzenia separacji:

• Fizyczna lub logiczna bariera między zagrożeniem a zasobem (firewall, DMZ etc.)
• Przemiana zagrożenia w stan niegroźny (ignorowanie pakietów SYN przez serwery DNS)
• Zniszczenie zagrożenia (programy antywirusowe etc)

W sytuacji idealnej jesteśmy w stanie stworzyć taką separację, która w 100% zapewnia bezpieczeństwo zasobu (odcięcie zasobu od internetu, zapewnienie bezpiecznej fizycznej zapory itd.). Jednak sytuacje idealne nie istnieją, dlatego bardzo często musimy robić dziury w separacji (aby zachować operacyjność). Te właśnie dziury określane są jako porowatość. Przeprowadzając analizę bezpieczeństwa zgodne z OSSTMM tester powinien znać wszystkie porowatości lub umieć je zidentyfikować.

Dygresja - powtórzę się, ale warto. OSSTMM nie jest poradnikiem młodego hakera. Nie znajdziecie w nim nic, co nauczy Was jak sprawdzić, czy podatność istnieje, czy nie. OSSTMM uczy, jak ocenić fakt istnienia lub nieistnienia podatności. Metasploit jest naprawdę krok wcześniej.

Porowatość powinny wynikać zawsze z operacyjności. W przeciwnym wypadku zaliczyć je należy do ograniczeń. Tester w procesie analizy powinien zakwalifikować każdą porowatość (każdego pora:) ), do jednej z trzech kategorii, które definiują jej zadania w operacyjności. Te kategorie to:

• Widoczność (visibility) - naiwne jest twierdzenie, że security by obscurity jest naiwne. Nie może być oczywiście jedynym elementem zabezpieczeń, ale każdy wie, że to okazja czyni złodzieja. Nieznane (niewidoczne dla atakującego) zasoby są dopóty bezpieczne, póki nie zostaną odkryte.
• Dostęp (access) - Operacyjność w ogromnej większości przypadków wymaga dostępu do zasobu, inaczej mówiąc sposobów interakcji z zasobem. Na przykład webaplikacja sięgająca (porowatość) do bazy danych (zasób)
• Zaufanie (trust) - Zaufanie to najgorsze słowo, jakie mogło mi przyjść do głowy, ale nie potrafię chyba użyć lepszego. To po prostu każda zależność między zasobem, a czynnikiem zewnętrznym, zapewniająca swobodny dostęp do zasobu (na przykład VLAN, z którego jest dostęp przez RDP/SSH do sieci produkcyjnej)

Reasumując zabezpieczenia separują między zagrożeniami a zasobami, każda porowatość zmniejsza bezpieczeństwo i należy do (wynikają z konieczności) widoczności, dostępności lub zaufania.

Kontrola

Kontrolowane zagrożenia przestają być zagrożeniami. Skąd jednak mieć pewność, że zabezpieczyliśmy się przed wszystkimi zagrożeniami, więc je kontrolujemy? Szanse są mimo wszystko marne. Na szczęście, można zrobić więcej, niż biernie czekać na wydarzenia i reagować. Można działać proaktywnie. Przede wszystkim trzeba umieć powiedzieć co jest zasobem i jaka jest konieczna operacyjność zasobu. Gdy ograniczymy te dane do wiadomych, będziemy mogli się skupić na ich obronie (w przeciwieństwie do obrony PRZED nieznaną listą zagrożeń).

Po drugie trzeba brać pod uwagę prawdopodobieństwo. Raczej jest nikła szansa, by w znajdująca się w Polsce kolokacja mogła podlec uszkodzeniu z powodu trzęsienia ziemi, więc nie trzeba specjalnie dbać (kontrolować) o ten aspekt. Z drugiej strony znane mi są przypadki rezygnacji ze świetnie zapowiadającej się serwerowni, która znajdował się na trasie lądowań samolotów. Wtedy sytuacja była kontrolowana. Sytuacja nieczęsta, którą można było przewidzieć, a nie została poprawnie skontrolowana? Serwerownia znajdująca się w pobliży magistrali pociągowej uczęszczanej przez składy towarowe i awaria macierzy, spowodowana przez drgania podłoża. O ryzyku więcej przy okazji ograniczeń.

OSSTMM wyróżnia dwie klasy kontroli:

[list] [item] Klasa A - kontrola interakcji

• Autoryzacja (Authentication)- w zasadzie połączenie identyfikacji i autoryzacji. Czyli weryfikacja nawiązującego interakcje z zasobem pod względem posiadania odpowiednich uprawnień.
• Ubezpieczenie (Indemnification) - podany wcześniej przykład z płonącym magazynem nie wyczerpuje tego punktu. Ubezpieczenie to także każde widoczne ostrzeżenie przed interakcją z zasobem, umowa SLA z dostawcą usług lub umowa ze stroną zewnętrzną
• Redundancja (Resilience) - odporność zabezpieczeń na awarię, błąd, uszkodzenie
• Ograniczenia (Subjugation) - zapewnienie, że interakcja następuje tylko zgodnie ze zdefiniowanym przez właściciela zasoby procesem. Autorzy OSSTMM zwracają w tym punkcie uwagę na fakt, że ta kontrola zmniejsza dowolność interakcji, ale także zmniejsza odpowiedzialność po stronie nawiązujących interakcję.
• Dostępność (Continuity) - odporność zasobu na awarię, błąd, uszkodzenie, która zapewnia ciągłość interakcji.

[/item][item] Klasa B - kontrola procesów ochrony

• Niezaprzeczalność (Non-repudiation) - zapewnienie, że w czasie trwania interakcji nie zmieni się rola strony interakcji.
• Poufność (Confidentiality) - zapewnienie, że zasoby ujawnione lub wymienione przez strony interakcji są znane tylko tym stronom.
• Prywatność (Privacy) - zapewnienie, że sposoby interakcji znane są tylko stroną interakcji
• Integralność (Integrity) - zapewnienie, że strony interakcji wiedzą o zmianach w zasobach. Inaczej mówiąc, że dane wymieniane między autoryzowanymi użytkownikami zasobów a zasobem nie ulegają zmianie przez osoby trzecie.
• Alarm (alarm) - kontrola podejmowania interakcji z zasobem (na przykład informacje o aktualnie zalogowanych użytkownikach i log autoryzacji)

[/item][/list]

OSSTMM wskazuje trzy aspekty (mało oryginalnie zresztą) wskazuje trzy aspekty, które powinny być chronione:

• Poufność (Confidentiality) - którą zapewnia kontrolowanie Poufności i Prywatności (klasa B) oraz Autoryzacja i Redundancja (klasa A)
• Integralność(Integrity) - którą zapewnia kontrolowanie Integralności, Niezaprzeczalności (klasa B) oraz Ograniczenie (klasa A)
• Dostępność (Availability) - którą zapewnia kontrolowanie Dostępności i Alarmu (klasa B) oraz Ubezpieczenia (klasa A)

Zasada słabego zamka czyli trudna sztuka wyboru

Zasada słabego zamka związana jest z odpowiedzią na pytanie czy lepiej mieć słaby zamek w drzwiach, czy w ogóle go nie mieć? Wyobraźmy sobie drzwi, które chronią nasz cenny zasób. W drzwi możemy wstawić od wewnątrz solidny rygiel. Jednak jak wtedy podjąć interakcje z zewnętrzną stroną? W przypadku, gdy operacyjność wymaga, by drzwi można było otwierać od zewnątrz? Okazuje się wtedy, że w drzwiach wydrążyć należy łoże na zamek, co wpływa na odporność drzwi. Zakładając jednak tani i słaby zamek narażamy się na sytuację, że ktoś nieuprawniony dostanie się do naszego zasobu. Co gorsza - może się dostać do niego nie tylko przełamując siłowo drzwi, ale także wykorzystując nieskomplikowany system zapadek w zamku. Wtedy nawet nie będziemy wiedzieć, że coś się właściwie stało. Można oczywiście założyć, że zasób ten nie będzie interesował osoby posiadające odpowiednią wiedzę by stworzyć wytrych. Z drugiej strony, zamek w drzwiach może budzić zainteresowanie tym, co jest za nimi. Pytanie wciąż pozostaje bez ostatecznej odpowiedzi. Choć popsuty zamek to dobry sygnał o włamaniu...

Jak to się ma do kontroli? Trzeba pamiętać, że dodanie metody kontroli zwiększa powierzchnię ataku (wydrążenie łoża). Trzeba także pamiętać, że dobrze jest prowadzić księgę wejść i wyjść(Klasa B - Alarm). Być może zamiast dodawać zamek w drzwiach, należy zastanowić się nad tym, czy na pewno jest to konieczne?

Ograniczenia

OSSTMM zrezygnował z używania pojęcia RYZYKO i nie bierze go pod uwagę przy analizie bezpieczeństwa. To dość drastyczne podejście, bo częstokroć spotkałem się z tłumaczeniem, że skoro dotychczas się coś nie wydarzyło, to po co zabezpieczać się przed tym. Ryzyko jest pochodną prawdopodobieństwa, a to ostatnie zmienia się w czasie gwałtownie, zależy od środowiska, zasięgu działania, zasobów, dostępnych zagrożeń i innych czynników. Dlatego OSSTMM używa pojęcia ograniczenia, by wykazać niedociągnięcia zabezpieczeń, zamiast patrzeć na sprawę od strony zagrożeń.

Wyróżniono 5 ograniczeń:

• Podatność (Vulnerability) - luka lub błąd gdy autoryzowana strona nie może nawiązać interakcji z zasobem lub nieautoryzowana strona może nawiązać interakcje, która wymaga autoryzacji lub gdy nieautoryzowana strona może ukryć zasób lub swoje działania.
• Słabości (Weakness) - zmniejszenie poziomu interakcyjnych operacji kontroli (klasa A)
• Problem/Dolegliwość (Concern) - zmniejszenie poziomu pięciu operacji kontroli procesu (klasa B)
• Ujawnienie (Exposure) - luka lub błąd, która powoduje bezpośrednią lub pośrednią widoczność zasobów poza wybranymi kanałami
• Anomalia (Anomaly) - niezidentyfikowany i nieznany element, który nie został skontrolowany i nie może być przypisany do żadnych elementów kontroli.

Podsumowanie

Narobiło się tego... oj, narobiło. A jesteśmy dopiero na samym początku, czubek góry lodowej. W następnej części (oby jak najszybciej...) już więcej z praktyki, innymi słowy - rozdział drugi - What you need to do. Mam nadzieję, że mimo wszystko ktoś poza mną to przeczyta.

Linkownia

ISECOM - twórcy OSSTMM Podręcznik w języku angielskim

PS. Wszystkie focie pochodzą z Open Source Security Testing Methodology Manual.