Czego uczą metodologie testów penetracyjnych (cz.3.)

05 grudnia 2013, 19:22 | Teksty | komentarzy 8
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.
W poprzednich częściach artykułu zidentyfikowaliśmy fazy testów penetracyjnych (Czego uczą metodologie testów penetracyjnych, cz. 1.) oraz poznaliśmy najpopularniejsze metodologie pomagające w przeprowadzeniu tych testów (Czego uczą metodologie testów penetracyjnych  cz. 2.).

Sprawdźmy teraz, jakie jeszcze standardy mogą przydać się w pracy pentestera, aby móc odpowiedzieć na pytanie, czy pentesterzy (w odróżnieniu od audytorów) powinni szczegółowo poznawać wszystkie opisane tu normy oraz metodologie.

 

Inne metodologie i standardy

1. Information Systems Security Assessment Framework (ISSAF)

Ten projekt jest tworzony w duchu Open Source. ISSAF jest szczegółowo zdefiniowaną metodologią, którą można porównać do OSSTMM. Dokument ISSAF skupia się równie mocno na technicznym oraz kierowniczo-biznesowym aspekcie testów bezpieczeństwa. Nie jest to dokument opisujący ściśle testy penetracyjne – tutaj nacisk kładziony jest na proces, a nie jednorazowe wydarzenie.

Wadą ISSAF jest stosunkowa mała aktualność oraz mniejsza swoboda działania, w porównaniu do wcześniej opisywanych standardów.

Więcej informacji o frameworku ISSAF można znaleźć na stronie organizacji tworzącej standard.

2. EC-Council Licensed Penetration Tester methodology (LPT)

Jest to standard opracowany i licencjonowany przez EC-Council, które jest znaną instytucją certyfikującą inżynierów bezpieczeństwa. Dostęp do metodologii jest możliwy po uzyskaniu certyfikacji LPT, która wymaga między innymi certyfikatów CEH oraz ECSA.

Metodologia LPT jest więc dostępna dla bardzo wąskiego kręgu specjalistów. Doceniając markę oraz poziom szkoleń EC-Council można założyć, że jest to dobrze zdefiniowana praktyka przystosowana konkretnie do testów penetracyjnych.

Elementy tej metodologii można poznać m.in. przygotowując się do egzaminu Certified Ethical Hacker (CEH) – pod patronatem sekuraka.

3. OWASP Application Security Verification Standard Project (OWASP ASVS)

Ten projekt organizacji OWASP przedstawia wymagania stawiane bezpiecznym aplikacjom internetowym. W dokumencie ASVS istnieje kilka poziomów, które jednoznacznie określają, w jaki sposób powinny być implementowane, testowane oraz dokumentowane specyficzne komponenty web aplikacji.

ASVS jest w praktyce audytem, który można przeprowadzić w systemach hostujących aplikacje internetowe. Trzeba zaznaczyć, że dokument jest stosunkowo wysokopoziomowy i nie wgłębia się zbytnio w sposoby implementacji czy weryfikacji komponentów. Umożliwia to stosunkowo dużą swobodę podczas planowania działań audytowych.

Standard OWASP do weryfikacji bezpieczeństwa web aplikacji nie powinien odstraszać pentesterów swoją formą. Został napisany zwięźle i klarownie. W krótkim czasie można poznać nie tylko ciekawe podejście do weryfikacji bezpieczeństwa, ale również zapoznać się z potężnym narzędziem do określania poziom zaufania do badanej aplikacji internetowej. Trzeba pamiętać, że celem ASVS nie jest znajdywanie podatności, ale sprawdzenie dobrych praktyk, które przekładają się na wytwarzanie bezpiecznego oprogramowania.

W momencie pisania artykułu na stronach organizacji OWASP dostępna była druga, odświeżona wersja dokumentu w wersji beta (2013 r.). W witrynie OWASP dotyczącej ASVS można odnaleźć również starszą wersję dokumentu, także w języku polskim.

4. Penetration Testing Framework (PTF)

PTF odróżnia się od wszystkich wcześniej opisanych dokumentów tym, że nie jest ani standardem, ani metodologią — Penetration Testing Framework jest kompendium pentestera. PTF zawiera najważniejsze informacje dotyczące każdego etapu testu penetracyjnego: porty, usługi, exploity, topowe narzędzie pentesterskie, w tym ich cel, składnię i przykłady użycia.

Wszystkie informacje zawarte są na pojedynczej stronie internetowej, co pozwala szybko wyszukiwać konkretne komendy i porady. Nie jest to dokument dla początkujących pentesterów, którzy nie mają doświadczenia w narzędziach, ale zdecydowanie można stać się pewnego rodzaju inspiracją do działań podejmowanych podczas testów bezpieczeństwa.

5. OWASP TOP 10 Project oraz SANS 20 Critical Security Controls

Są to dwie listy najpopularniejszych błędów oraz zagrożeń, które zostały opisane przez organizację OWASP oraz instytut SANS.

Pierwsza lista, OWASP TOP 10, opisuje najczęściej występujące błędy bezpieczeństwa w aplikacjach internetowych. Dokument organizacji OWASP, aktualizowany ostatni raz w 2013 roku, pokazuje naturę zagrożeń, prawdopodobieństwo wykrycia oraz wpływ zagrożenia na bezpieczeństwo web aplikacji. OWASP pokazuje przykładowe wektory ataku oraz opisuje, w jaki sposób przygotować się do uchronienia się przed danym zagrożeniem.

OWASP TOP 10 bardzo dobrze współgra z innymi dokumentami organizacji, takimi jak np. Testing Guide czy ASVS.

SANS Critical Security Controls opisuje najpoważniejsze kategorie zagrożeń oprogramowania. Instytut SANS podszedł do swojej listy zdecydowanie bardziej szczegółowo niż OWASP. Dokument tworzony jest przez specjalistów bezpieczeństwa z instytutów badawczych oraz uczelni na podstawie badań prawdziwych systemów. Jest to lista tworzona z podejściem tzw. Lessons Learnt, sprawiającym, że nie jest to wyłącznie projekt czysto teoretyczny (podobnie zresztą jak OWASP TOP 10).

Celem listy SANS jest zabezpieczenie najważniejszych obszarów przedsiębiorstwa przez wdrożenie odpowiednik metodyk, dobrych praktyk, automatów czy monitoringu. Wszystko to po to, aby jak najszybciej, z małym nakładem środków, znacznie zredukować szansę ataku oraz koszty ewentualnej naprawy.

Podejście takie jest realizowane przez dokładny opis kolejnych zagrożeń, do których przypisane są zalecenia dotyczące ochrony. Mogą to być zarówno zalecenia tzw. Quick Wins, pozwalające w bardzo krótkim czasie ochronić kluczowe elementy organizacji, jak i Advanced sub-controls pokazujące, jak przy użyciu najnowszych technologii zapewnić kompleksową ochronę.

Warto poznać oba dokumenty — są one efektem wieloletnich badań wielu specjalistów, przez co stanowią dobrą referencję np. w raportach.

6. Wytyczne NIST

NIST opracował dokument NIST PUB 800-115 – Technical Guide to Information Security Testing and Assessment opisujący sposób, w jaki instytucje mogą podchodzić do zarządzania ryzykiem związanym z testowaniem bezpieczeństwa.

Zdefiniowano w nim fazy testów bezpieczeństwa oraz przedstawiono sposoby wykrywania podatności. W dokumencie opisywane są również wektory ataku, a nawet proponowane są narzędzia, które przydadzą się podczas testów.

Publikacja NIST zakresem przypomina OWASP Testing Guide, jest jednak napisana dużo dokładniej i z większą starannością. Niestety dokumenty NIST są rzadko uaktualniane, ale opis wykonywanych czynności w dokumencie nie powinien się zdezaktualizować.

7. Certyfikacje i normy

Zarówno audyt, test penetracyjny czy chociażby proces zarządzania bezpieczeństwem, może być oparty o międzynarodowe normy i standardy. Standardami, które często stanowią „podkładkę” pod inne metodologie lub wymagania, są m.in.:

  • PCI-DSS v2.0 (Payment Card Industry Data Security Standard) — dotyczy zapewniania bezpieczeństwa systemom, które przetwarzają środki płatnicze przy wykorzystaniu kart płatniczych. Kontrola prowadzona jest w zakresie bezpieczeństwa sieci, ochrony danych, zarządzania historią płatności, szczegółowej kontroli dostępu oraz monitoringu. Instytucje akceptujące transakcje kartami płatniczymi oraz centra autoryzacyjne mogą mieć narzucone wymaganie pozytywnego audytu tej normy;
  • ISO/IEC 27001 (Information Security Management Systems) — standaryzacja zarządzania bezpieczeństwem informacji w systemach teleinformacyjnych. Definiuje obszary, takie jak polityka bezpieczeństwa, bezpieczeństwo fizyczne, ciągłość działania, zarządzanie incydentami bezpieczeństwa czy kontrola dostępu;
  • ISO/IEC 27002 (Code of Practice for Information Security Management) — rozwinięcie poprzedniej normy o element monitoringu, wdrożeń systemów oraz utrzymania tzw. Systemu Zarządzania Bezpieczeństwem Informacji;
  • ISO/IEC 27005 (Information Security Risk Management) — dotyczy usystematyzowania procesów związanych z zarządzaniem ryzykiem w kontekście bezpieczeństwa informacji.
Normy oczywiście nie są napisane zbyt przyjaznym językiem i rygorystyczne trzymanie się ich wytycznych może utrudnić pełne wykorzystanie własnego warsztatu pentestera lub audytora, jednak powołanie się na konkretne wymagania pozwala zwiększyć wartość raportów i może stanowić dobrą referencję podczas opisywania rekomendacji poprawiających stan bezpieczeństwa testowanego systemu.

 

Co wybrać?

Zanim zdecydujemy się na wybór konkretnego standardu, najpierw musimy się zastanowić, w jaki sposób chcemy zwiększyć bezpieczeństwo danego systemu. Zarówno audyt, jak i test penetracyjny sprawdzają bezpieczeństwo w zdefiniowanym oknie czasowym. Ciągłe zapewnianie bezpieczeństwa wymaga wdrożenia zmian w procesie wytwarzania oprogramowania — SDLC — i wymaga przyjęcia całkowicie odmiennej strategii (ale o tym innym razem). Skupmy się teraz na audycie i teście penetracyjnym.

Audyt weryfikuje zgodność z pewnym standardem.
Test penetracyjny jest dużo bardziej kreatywny i nieprzewidywalny.

Audytor z definicji powinien podążać za wymaganiami, ale czy spontaniczny pentester również musi zakuwać się w niewidoczne kajdany metodologii? Otóż nie musi, co nie oznacza, że nie powinien podążać za dobrymi praktykami wybranych metodologii.

Test penetracyjny jest na tyle skomplikowanym procesem, że skupienie i uporządkowanie procesu okazuje się zbawienne. Nie zawsze istnieje możliwość wykorzystywania wszystkich narzędzi lub klient ogranicza testy do wielu podsystemów. Reguły gry podczas testów penetracyjnych często potrafią się zmieniać i wtedy metodyczne podejście może okazać się jedyną deską ratunkową. Poza tym, metodyczne podejście jest wręcz wymagane w zespołach złożonych z kilku pentesterów — wtedy dużo łatwiej zrównoleglić testy i synchronizować wyniki.

Początkującym inżynierom bezpieczeństwa polecam zapoznanie się z prostymi metodologiami, takimi jak OWASP Testing Guide lub PTES – pomogą one wyrobić sobie podstawowe nawyki, które będą wykorzystywane w każdym teście penetracyjnym, niezależnie od jego charakteru.

Bardziej zaawansowani testerzy powinni zainteresować się klasyfikacją taką jak WASC-TC oraz metodologiami, które oferują szerokie spojrzenie na aspekt bezpieczeństwa – zarówno techniczne, jak i biznesowe. Ze swojej strony polecam OSSTMM, który bardzo dokładnie definiuje sposób testowania w wielu różnych sytuacjach.

Pentester nie powinien unikać metodyk i standardów. Są one doskonałym źródłem wiedzy o bezpieczeństwie IT,  dzięki nim można poznać nie tylko sposób testowania podatności, ale również informacje o wielu wektorach ataku oraz o motywacjach agresorów. Metodyki są więc dla każdego pentestera przede wszystkim źródłem cennych wskazówek oraz swoistą „check-listą” pozwalającą upewnić się, czy czegoś nie przeoczono podczas testów. Zatem: nie wolno ich unikać.

 

Bibliografia

Spis źródeł dotyczy wszystkich części cyklu.

  • S. Ali i T. Heriyanto, BackTrack 4: Assuring Security by Penetration Testing, English: Packt Publishing, 2011.
  • J. Zubairi i A. Mahboob, Cyber Security Standards, Practices and Industrial Applications: Systems and Methodologies, English: Idea Group Inc (IGI), 2011.
  • D. Kennedy, J. O’Gorman, D. Kearns i M. Aharoni, Metasploit: The Penetration Tester’s Guide, English: No Starch Press, 2011.
  • K. Scarfone, M. Souppaya, A. Cody i A. Orebaugh, „Technical Guide to Information Security Testing and Assessment – Recommendations of the National Institute of Standards and Technology,” 2008. [Online].
  • ISECOM, „Open Source Security Testing Methodology Manual (OSSTMM),” [Online].
  • OWASP, „OWASP Testing Guide v4,” [Online].
  • WASC, „The Web Application Security Consortium / Threat Classification,” [Online].
  • OISSG, „Information Systems Security Assessment Framework (ISSAF),” [Online].

 Adrian “Vizzdoom” Michalczyk dla portalu Sekurak.pl

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Damian

    Super Super Super !

    Odpowiedz
  2. ninon123

    Artykuł bardzo fajny ;)
    Ale,że tak odbiegnę od tematu. Orientuje się z Was ktoś jak to jest z pracą po technikum informatycznym?
    Jestem w maturalnej klasie i dopadły mnie filozoficzne pytanie pod tytułem ‚co dalej’ :D
    I tak się właśnie zastanawiam, czy jest szansa na coś przyzwoitego z tytułem technika,czy mogę o tym zapomnieć ;)
    Byłoby to b. pomocne przeczytać informacje o tym od kogoś w podobnej sytuacji ;)
    Pozdrawiam

    Odpowiedz
  3. Tomasz

    ninon123:
    z tytułem technika to w PL możesz bardzo mało zrobić w dziedzinie IT.
    Może serwis komputerów, zaciskanie końcówek kabla sieciowego, tworzenie prostych stron dla lokalnych małych firemek.
    Obowiązkowo trzeba mieć coś z studiami.
    Oczywiście są wyjątki ale pierwsza lepsza oferta pracy to minimum inżynier, nie upieram się że posiadając tytuł inż, magistera będziesz miał super prace ale to pomaga.

    Odpowiedz
  4. bl4de

    Odnośnie ASVS – oprócz tego, że ten dokument może służyć jako metodologia przeprowadzania pentestów, jest również świetnym materiałem dla zespołów programistycznych tworzących aplikacje webowe.

    Trzymanie się wybranego poziomu bezpieczeństwa wg. ASVS można w bardzo prosty sposób weryfikować poziom bezpieczeństwa na każdym etapie wytwarzania oprogramowania. Zarówno dla developerów w trakcie pisania kodu, jak i dla testerów i generalnie QA wytyczne zawarte w tym dokumencie w przejrzysty sposób wskazują każdy punkt aplikacji i sposób, w jaki powinien się zachować.

    A dla klienta – jest to wskazówka, że programiści i testerzy nie implementują mechanizmów związanych z bezpieczeństwem na łapu-capu, tylko w zgodzie z wypracowaną przez lata i zweryfikowaną metodyką.

    Odpowiedz
  5. bl4de

    @Tomasz
    Nieprawda, że studia są obowiązkowe. Owszem, dają sporą wiedzę, ale same studia nigdy nie zrobią z Ciebie dobrego specjalisty.

    Ja jestem po 2-letnim studium policealnym, „karierę” w IT rozpocząłem w wieku 30 lat jako młodszy programista PHP w firmie robiącej stronki www i jakieś tam proste aplikacyjki typu sklep czy intranet. Obecnie, po ponad 6 latach, pracuję jako programista w dużej angielskiej korporacji robiącej soft dla instytucji finansowych z całego świata, w tym banków z tzw. Tier 1, czyli tych z pierwszej 10-ki na świecie :) . A oferty pracy dostaję niemal codziennie z całej Europy.

    Nie chodzi mi tutaj o jakieś przechwałki, czy coś – tak po prostu wyglądają realia w branży IT :)

    @ninon123

    Z własnego doświadczenia podpowiem Ci, że w IT dla 90% pracodawców nie liczy się nic poza umiejętnościami i doświadczeniem.

    Nigdy nie daj sobie wmówić, że to, jaką szkołę skończyłeś, ile masz lat czy skąd pochodzisz ma jakiekolwiek znaczenie w ubieganiu się o pracę. Dokształcaj się, próbuj, koduj, obserwuj blogi, Twittera, subskrybuj newslettery ludzi i firm ze specjalizacji, którą sobie wybierzesz (web, programowanie aplikacji, security, sieci – whatever). Do tego szlifuj angielski, miej na oku takie rzeczy, jak Agile, zagadnienia z algorytmiki i inżynierii oprogramowania (np. wzorce projektowe, CI, systemy kontroli wersji itp.) – a na pewno rynek IT wchłonie Cię jak gąbka wodę :D

    Pozdrawiam i życzę powodzenia w realizacji celów zawodowych :)

    Odpowiedz
  6. ninon123

    Dzięki za dobre rady ;) zwłaszcza Tobie bl4de :)
    Staram się ogarniać temat jak mogę, dzięki za dokładne wskazówki na co zwrócić uwagę :)
    Tak się tylko zastanawiam, w kwestii tego,że jestem dziewczyną, czy nie będę mieć na starcie parę punktów niżej przez to,że dziewczyna i jeszcze tylko po technikum :)
    4 lata temu myślałam,że płeć nie odgrywa roli, ale praktyki w 3kl. były kubłem zimnej wody na głowę. No,ale może miałam po prostu pecha :)
    W sumie jakbym chciała iść na studia, to pewnie bym się dostała, ale jak sobie pomyślę o tym studiowaniu, to mnie słabi. Chciałabym się już jakoś usamodzielnić, a nie ciągle na łasce profesorków ze studiów i ciągnąc kasę od rodziców.
    Przyznam szczerze,że trochę się boję co to będzie :)
    I jeszcze raz wielkie dzięki :)

    Odpowiedz
  7. bl4de

    @ninon123

    Hej, bez przesady, jestem tylko skromnym programistą :) Ale dzięki za miłe słowa :)

    Płeć też się nie liczy, w mojej firmie jest co najmniej kilkanaście programistek Javy i C#. No i większość dobrych UX-owców i grafików to zdecydowanie płeć piękna :D

    PS. Nie róbmy OT w temacie o pentestach :D Jak będziesz miała jeszcze jakieś pytania, pisz śmiało ( bloorq at gmail.com )

    pozdrawiam

    Odpowiedz
  8. Niesamowite, że artykuły mogą wywołać taką refleksję :)

    @Ninon123 – wydaje mi się, że na samym Sekuraku jest naprawdę spory zbiór artykułów, które dotyczą rzeczy zarówno twardszych jak i miększych w dziedzinie bezpieczeństwa. Spróbuj realizować testy metodami z artykułu, chociażby na swoich aplikacjach lub aplikacjach znajomych i zdobywaj doświadczenie :) Aby robić… wystarczy robić ;)

    W każdym razie zapraszamy na kolejne Sekurak Hack Party. Oprócz szlifowania warsztatu będzie można również pogadać. Moja narzeczona jest koncept artystą, grafikiem 3D i hobbistycznie pracuje również jako IT Security. Oboje pracowaliśmy w swoich zainteresowaniach na studiach – więc wszystko można połączyć. Przyjedź, lub napisz, to coś poradzimy :)

    Odpowiedz

Odpowiedz