70

BEZPIECZNA FIRMA

HAKIN9 5/2009

W

ciągu ostatnich kilku lat zdecydowanie
wzrosła ilość systemów i usług
informatycznych wykorzystywanych

w organizacjach. Równolegle ze wzrostem
systemów zwiększyła się ilość przetwarzanych
w nich informacji. Jak wiadomo, informacja jest
jednym z najcenniejszych aktywów należących
do organizacji. Dlatego ważne jest, aby była
ona w odpowiedni sposób chroniona. Od
systemów informatycznych oczekuje się, aby
spełniały one wymagania odnośnie poufności,
integralności i dostępności informacji w nich
przetwarzanych. Definicja powyższych pojęć
według normy ISO/IEC 13335-1:2004 jest
następująca:

• dostępność – właściwość bycia dostępnym

i użytecznym na żądanie upoważnionego
podmiotu,

• poufność – właściwość, że informacja

nie jest udostępniona lub wyjawiana
nieupoważnionym osobom, podmiotom lub
procesom,

• integralność – właściwość zapewnienia

dokładności i kompletności aktywów.

W praktyce spełnienie powyższych wymagań
oznacza wprowadzenie w projektowanych
rozwiązaniach stosownych zabezpieczeń
technicznych i organizacyjnych. Poniżej
wybrane przykłady zabezpieczeń (technicznych)
zwiększających bezpieczeństwo:

SEBASTIAN STROIK

Z ARTYKUŁU

DOWIESZ SIĘ

jak w praktyce przeprowadzić

projekt testów penetracyjnych w

swojej organizacji,

jak poprawnie zdefiniować cel i

zakres projektu,

na co powinieneś zwrócić

uwagę,

z jakich metodyk możesz

skorzystać,

co powinien zawierać raport

z przeprowadzonych testów

penetracyjnych.

CO POWINIENEŚ

WIEDZIEĆ

powinieneś posiadać

podstawowe informacje na

temat bezpieczeństwa.

• możliwość współpracy z centralnym systemem

identyfikacji aktywów,

• możliwość kontroli zmian w eksploatacji

systemów operacyjnych, aplikacji oraz innego
typu oprogramowania,

• możliwość współpracy z centralnym system

wspomagania zarządzania i zbierania informacji
związanych z incydentami dotyczącymi
bezpieczeństwem systemu informatycznego,

• możliwość centralnego i zdalnego zarządzania

urządzeniami kontroli transmisji, kontroli dostępu,
zmian ACL i in. (np. poprzez wydzielenie
dedykowanego dla tego typu urządzeń
odpowiedniego segmentu VLAN),

• możliwości rozdziału sieci instytucji na fizycznie/

logiczne rozdzielone części (np. segmenty VLAN),

• możliwość tworzenia zapasowych kopii

informacji zarządzanych i dokonywanych
centralnie,

• możliwości centralnej i rozproszonej (z

centralnym zarządzaniem) ochrony przed
szkodliwym oprogramowaniem typu: wirusy
komputerowe, robaki sieciowe, konie trojańskie,
bomby logiczne itp.,

• możliwość centralnego nadzoru dzienników

operatorów/zdarzeń wybranych elementów
sieci instytucji (np. ocenionych jako krytyczne i
ważne w ramach analizy ryzyka), monitorowania
dostępu do systemu oraz jego użycia (np.
dostępność zasobów sprzętowych),

• możliwość synchronizacji zegarów wszystkich

bądź wybranych elementów sieci organizacji,

Stopień trudności

Testy

penetracyjne

Jako że w prawie każdym wydaniu niniejszego miesięcznika

opisywane są metody badania podatności, identyfikacji włamań,

wykorzystywania fragmentów kodu do działań destrukcyjnych,

poniższy tekst skupi się na zagadnieniu dobrej organizacji projektu,

jakim są testy penetracyjne.

71

TESTY PENETRACYJNE

HAKIN9

5/2009

• możliwości pracy wybranych urządzeń

lub elementów sieci świadczących usługi
(na podstawie analizy ryzyka) w trybie tzw.
failover.

• możliwość wykorzystywania

zabezpieczeń kryptograficznych w
odniesieniu do przechowywanych,
przesyłanych informacji lub nośników
informacji (np. wykorzystanie VPN lub
innych rozwiązań opartych na PKI),

• możliwość współpracy z centralnym

systemem zarządzania dostępem
użytkowników

• możliwość zdalnej kontroli połączeń

sieciowych, wymuszania dróg połączeń
oraz identyfikacji komputera, terminala
lub innego urządzenia sieciowego.

Tam, gdzie nie udaje się wdrożyć
odpowiednich zabezpieczeń technicznych,
wprowadza się zabezpieczenia
organizacyjne. Aby zweryfikować, czy
określone w organizacji wymagania
bezpieczeństwa zostały odpowiednio

zaimplementowane, należy przeprowadzać
audyty bezpieczeństwa. Ważne, aby były
one przeprowadzane regularnie. Z każdego
audytu powinien być sporządzony raport
opisujący zaobserwowane niezgodności
wraz z propozycją wykonania działań
zapobiegawczo – korygujących, które to
działania powinny zostać sprawdzone
podczas kolejnych przeglądów.

Aby móc zweryfikować, czy podczas

sprawdzającego audytu zostały wykonane

należycie działania zapobiegawczo-
korygujące, należy wprowadzić mierniki
pozwalające na określenie poziomu
bezpieczeństwa badanych systemów.

Pamiętajmy, że bezpieczeństwo to

proces, który należy ciągle monitorować.
Zagrożeń nie wyeliminujemy w 100%.
Możemy jedynie minimalizować ryzyko
ich wystąpienia. Aby jednak być pewnym
poruszania się na określonym poziomie
bezpieczeństwa, powinniśmy ciągle

Przykładowy projekt

przeprowadzony dla klienta X z branży utilities

Cel projektu:

Weryfikacja poziomu bezpieczeństwa systemów przetwarzających dane osobowe

Zakres/Etapy projektu:

(Tabela 1)

Opis realizacji projektu:

Projekt X wiązał się z weryfikacją poziomu bezpieczeństwa systemów przetwarzających dane osobowe klienta. Projekt został uruchomiony w następstwie
wdrożenia nowych zabezpieczeń technicznych w obszarze IT.
Projekt został podzielony na dwa etapy:

• zbadanie podatności na włamanie do systemów bezpośrednio z sieci Internet,
• analiza bezpieczeństwa systemów przetwarzających dane osobowe.

Celem Etapu 1 było wykrycie wszelkich możliwych podatności umożliwiających kompromitację serwerów znajdujących się w strefie DMZ.
Raport z Etapu 1 prezentował wykryte podatności wraz z określeniem możliwości ich wykorzystania przez atakującego oraz rekomendował
zabezpieczenia niezbędne do usunięcia wykrytych zagrożeń.
Celem Etapu 2 było sprawdzenie zgodności bezpieczeństwa systemów z ustalonymi zasadami bezpieczeństwa obowiązującymi w organizacji. W
raporcie z Etapu 2 zostały przedstawione wykryte nieprawidłowości wraz z zalecanymi sposobami ich usunięcia.

Podsumowanie:

W opisywanym projekcie Klient nie zdecydował się na wykonywanie stricte testów penetracyjnych, a skoncentrował się na zbadaniu podatności oraz
wyeliminowaniu wykrytych zagrożeń. Dodatkowo została przeprowadzona analiza bezpieczeństwa systemów wewnętrznych. Cel określony w projekcie
został osiągnięty.
Zakres projektu każdorazowo różni się i uzależniony jest od potrzeb Klienta. Najczęstsze powody uruchamiania projektów związanych z
przeprowadzaniem testów penetracyjnych:

• wdrożenie nowych zabezpieczeń technicznych i organizacyjnych,
• aktualizacje oprogramowania (wersje oprogramowania, update'y, aktualizacje),
• wystąpienie incydentu bezpieczeństwa,
• zalecenia audytowe,
• itp.

Tabela 1.

Zakres projektu

L.p.

Etapy projektu

Termin realizacji

Narzędzia

1

Badanie podatności z zewnątrz

1 tydzień od

momentu

podpisania umowy

Nessus, Nmap

2

Analiza bezpieczeństwa

systemów przetwarzających dane

osobowe

2 tygodnie

od momentu

podpisania umowy

Analiza konfiguracji,

wywiad techniczny

z administratorami

systemów

3

Raport z etapów 1 i 2

4 tygodnie

od momentu

podpisania umowy

ND

BEZPIECZNA FIRMA

72

HAKIN9 5/2009

TESTY PENETRACYJNE

73

HAKIN9

5/2009

monitorować nasze systemy. Skutecznym
narzędziem pozwalającym zbadać poziom
bezpieczeństwa naszej organizacji są testy
penetracyjne. Są one, oprócz technik badania
podatności i wywiadów kontrolnych, jednym
z najczęściej wykorzystywanych narzędzi
audytu. Poniżej zostały opisane najlepsze
praktyki dotyczące przeprowadzania testów
penetracyjnych.

Testy penetracyjne może prowadzić

osoba lub zespół projektowy w organizacji
klienta lub zadanie takie może zostać
zlecone firmie zewnętrznej, zajmującej się
profesjonalnie zagadnieniami tego typu. Przed
przystąpieniem powinna zostać podpisana
klauzula o poufności, zabezpieczająca
obydwie strony przed ewentualnymi skutkami
naruszenia zasad współpracy.

Przystępując do projektu powinniśmy

określić szczegółowo jego cel i zakres,
metodykę oraz sprecyzować zakres raportu.

Cel i zakres projektu

Cel projektu określamy po to, aby po
skończonym projekcie móc sprawdzić, czy
został osiągnięty. Celem testu może być
np. zbadanie zgodności z wymaganiami.
Wymagania mogą być zdefiniowane przez
klienta lub też mogą to być wymagania
zdefiniowane przez światowe organizacje
zajmujące się bezpieczeństwem, np.
wymagania normy ISO/IEC 27001:2005.

Innym celem może być np. zbadanie

podatności lub też pełna próba włamania i
uzyskanie dostępu do zasobów.

Badanie podatności wiąże się z

przeprowadzeniem testów, najczęściej
automatycznych. Pozwala nam na wykrycie
w audytowanych systemach znanych luk i
zagrożeń, i na tym etapie kończy się projekt.

Pełne testy penetracyjne są natomiast

rzeczywistą próbą włamania. Na etapie
zbierania informacji badana jest podatność
systemów. Wykryte słabości są sprawdzane
pod kątem możliwości ich wykorzystania.
Tak jak w każdym projekcie należy określić
osoby odpowiedzialne za prowadzenie
projektu, zarówno po stronie klienta, jak i po
stronie zespołu testującego. Należy określić
i wspólnie przedyskutować scenariusze
testowe związane z przeprowadzeniem testów
penetracyjnych. Powinny zostać ustalone
wszelkie czynności, które należy wykonać
przed przystąpieniem do wykonywania
testów. W szczególności powinno się określić
procedury odtwarzania danych; powinien

zostać zrobiony backup danych. Należy
ustalić godziny trwania testów oraz sposoby
komunikacji pomiędzy administratorami
ze strony działu IT klienta oraz zespołem
testującym. W scenariuszu testowym należy
szczegółowo określić zakres projektu (sposób
testowania, rodzaje wykonywanych testów,
zakres analizy – adresy IP itp.)

Scenariusze testowe

Scenariusz testowy uzależniony jest
oczywiście od przyjętego modelu testowania.

Popularne nazwy: Black Box, White

Box i Grey Box oznaczają nic innego jak
zakres wiedzy, którą posiada audytor przy
wykonywaniu testów penetracyjnych.

• Black Box – oznacza pełną wiedzę na

temat zasobów klienta. Ten rodzaj testów
przeprowadza się np. w przypadku
testowania aplikacji czy badania
konkretnego systemu bądź aplikacji,

• White Box – oznacza brak wiedzy na

temat zasobów. Najczęściej testy typu
White Box związane są z audytem
przeprowadzanym z zewnątrz organizacji,

• Grey Box – oznacza próbę symulacji

ataku z wewnątrz organizacji, np.
z wykorzystaniem standardowych
uprawnień użytkownika.

Scenariusz testowy powinien określać fazy
audytu; sposoby przechodzenia do dalszych
faz. Przed wykonaniem testów należy
zweryfikować procedurę audytu. Scenariusz
testowy powinien zostać zaakceptowany
przez obie strony przed przystąpieniem do
testów. W scenariuszu testów zewnętrznych
powinny znaleźć się:

• komputery i urządzenia sieciowe objęte

analizą,

• rodzaje uruchamianych testów (np.

badanie odporności DoS tylko dla
testów z zewnątrz),

• harmonogram prac,
• zasady współpracy z administratorami

systemów.

W przypadku testów wewnętrznych bada się:

• serwery i komputery pod względem

aktualności poprawek,

• weryfikuje urządzenia sieciowe,
• wykonuje próby przechwytywania

informacji,

• próby uzyskania wyższych uprawnień w

systemie informatycznym.

Przy wyborze zakresu testów należy zwrócić
uwagę na systemy produkcyjne. Warto się
zastanowić, czy przeprowadzać atak, czy
może zbudować środowisko testowe. Jeśli
już jako obiekt zostanie wybrany system
produkcyjny, to czy jest on należycie chroniony
na wypadek awarii. Czy została utworzona
kopia zapasowa, czy próba odtworzenia była
udana. Jeśli system jest obsługiwany przez
firmę zewnętrzną, czy mamy odpowiedni
poziom SLA pozwalający na przywrócenie
usług w zaplanowanym czasie itp.

Metodyka projektu

Aby móc skutecznie badać poziom
bezpieczeństwa organizacji systemów
informatycznych, należy monitorować go w
sposób ciągły. Testy penetracyjne powinny
być przeprowadzane okresowo. Można
wprowadzać wykonanie testów cząstkowych,
np. okresowo badać podatność sieci,
podatność sieci Wi-Fi, podatność bluetooth
itp. Niezależnie od tego, jaki obszar badamy,
powinny zostać określone sposoby realizacji
testów, czyli tak naprawdę należy zdefiniować/
przyjąć metodykę ich przeprowadzania.
Przyjęcie odpowiedniej metodyki jest ważne
z kilku powodów. Po pierwsze: spowoduje
wykonanie testów na odpowiednim
poziomie. Będziemy mieli pewność, że
niezależnie od wyboru dostawcy, testy
zostaną przeprowadzone według przyjętej
przez nas metodyki. Po drugie: wprowadzi
możliwość porównania wykonanego testu
z poprzednim poprzez wprowadzenie
odpowiednich mierników. Zestandaryzowanie
sposobu wykonania testów pozwala
również na bardziej elastyczne dobieranie
wykonawców. Nie jesteśmy uzależnieni od
tego samego zespołu czy firmy zajmującej
się przeprowadzaniem testów penetracyjnych.

Możemy opracować własną metodykę

wykonywania testów penetracyjnych lub
skorzystać z jednej z uznanych metodyk
wypracowanych przez organizacje zajmujące
się bezpieczeństwem. Takimi organizacjami
są między innymi: ISACA, ISECOM, OWASP,
NSA, CESG, NIST, WASC, itp. Poniżej kilka
wybranych metodyk przeprowadzania
audytów systemów informatycznych:

• Open Source Security Testing

Methodology v 3.0 – metodyka

BEZPIECZNA FIRMA

BEZPIECZNA FIRMA

72

HAKIN9 5/2009

TESTY PENETRACYJNE

73

HAKIN9

5/2009

opracowana przez organizację
ISECOM (Institute for Security and Open
Methodologies),

• Nist 800-42, 800-115 – wytyczne

opracowane przez organizację NIST
(National Institute of Standards and
Technology),

• OWASP Testing Guide v3 – podręcznik

testera bezpieczeństwa zawierający
najlepsze praktyki związane z
bezpieczeństwem aplikacji webowych,
opracowany w ramach projektu OWASP
(Open Web Application Security Project),

• BSI Penetration Testing Model

– metodyka prowadzenia testów
opracowana przez BSI (Bundesamt fur
Sicherheit in der Informationstechnik)

Powyższe metodyki, oprócz szczegółowego
zdefiniowania technik testowania, określają
również zasady planowania, raportowania
oraz oceniania wyników.Niezależnie od
przyjętej metodyki, przeprowadzanie testów
technicznych możemy podzielić na dwa
etapy: rekonesans oraz wykonywanie
prób włamania. Poniżej zostaną
opisane najczęściej używane narzędzia
wykorzystywane podczas tych etapów.

Narzędzia

Etap rekonesansu ma za zadanie zebranie jak
największej ilości informacji, które pozwolą na
wykonanie prób włamania. Najczęściej etap
rekonesansu rozpoczyna się od pasywnego
zbierania informacji. Wykorzystuje się tutaj
zapytania do powszechnie dostępnych
zasobów internetowych, takich jak: rejestr
nazw domenowych, wyszukiwarki WWW,
książki telefoniczne, grupy dyskusyjne, profile
społecznościowe itp. Dodatkowo sprawdza
się informacje zawarte w rekordach DNS.

Następnie przechodzimy do aktywnego

zbierania informacji. Najczęściej na tym
etapie mamy do czynienia ze skanowaniem
portów oraz bardziej inwazyjnymi
narzędziami badającymi podatności poprzez
wykorzystanie np. enumeracji.

Skanowanie portów polega na

wykonywaniu prób połączenia się na
kolejne porty w danym komputerze w celu
sprawdzenia, jakie usługi są na nim aktywne.
Enumeracja polega na nawiązywaniu
połączenia z konkretnym portem i wydawaniu
komendy pozwalającej na uzyskanie
pożądanych informacji. Najczęściej używane
narzędzia w tym etapie to: Nmap, netcat,

amap, xprobe2, sinfp, nbtscan, netenum,
fping. Oprócz skanowania portów na
etapie rekonesansu, wykorzystuje się
szereg automatycznych narzędzie do
badania podatności. Najbardziej znane
i wykorzystywane narzędzia to: Nessus,
MaxPatrol oraz NGS Typhon. Programy te
służą do badania bezpieczeństwa sieciowego
pod kątem występowania dobrze znanych
podatności lub powszechnie znanych
błędów w konfiguracji oprogramowania.
Skanery sprawdzają się bardzo dobrze przy
identyfikacji aktywnych portów i usług.

Zebrane w etapie rekonesansu

informacje dotyczące wykrytych luk i
zagrożeń pozwalają na przeprowadzenie
ataku. Atak polega na spreparowaniu
odpowiedniego programu (exploita),
wykorzystującego wykrytą podatność.
Uruchomienie exploitów ma na celu
przejęcie kontroli nad systemem bądź też
zablokowanie jego działania (ataki typu DoS).
Istnieje kilka narzędzi, które automatyzują
uruchamianie exploitów, aczkolwiek są one
jedynie narzędziami wspomagającymi.

Do najpopularniejszych możemy zaliczyć:

Metasploit, Canvas, Inguma, SQL Power
Injector, Security Forest, Core Impact itp.

Przy realizacji tego etapu testów

penetracyjnych najważniejsza jest wiedza i
doświadczenie zespołu testującego. Często
przy niektórych formach ataku pisane są
własne skrypty lub kawałki kodu.

Raport

Raport z testów jest dokumentem opisującym
efekty prac związanych z realizacją projektu.
Zebrane w nim informacje powinny udzielić
nam odpowiedzi, czy i w jakim zakresie
został osiągnięty cel projektu. Format raportu
powinien zostać ustalony podczas ustalania
metodyki prowadzenia projektu z wykonawcą.
Niezależnie od przyjętej metodyki pewne
elementy raportu są stałe i składają się na nie:

• cel i zakres testów,
• podsumowanie ogólne,
• analiza techniczna,
• podsumowanie techniczne wraz z

wnioskami.

Cel i zakres testów określa warunki brzegowe
przyjęte do realizacji projektu. W tej sekcji
opisywana jest: procedura wykonywania
testów, wykorzystane scenariusze testowe,
harmonogram wykonywanych prac oraz

BEZPIECZNA FIRMA

74

HAKIN9 5/2009

wszelkie inne ustalenia mające wpływ na
zakres projektu.

Podsumowanie ogólne jest abstraktem

z analizy technicznej napisanym dla
kierownictwa opisującym poziom
bezpieczeństwa badanego systemu. Analiza
techniczna jest tą częścią projektu, która
powinna zawierać: szczegółowy zakres testów,
rodzaje użytych narzędzi, opisy wykrytych
zagrożeń oraz ich ocenę. W przyjętej
metodyce powinny znaleźć się mierniki, które
pozwalają w realny sposób ocenić wykryte
zagrożenia. Często w raportach z testów
penetracyjnych możemy się spotkać z analizą
techniczną wykrytych podatności z podziałem
według wskaźników ryzyka zawartych w
powszechnie dostępnych bazach podatności
(CVE). Przyjmuje się wtedy podział trzy- lub
czterostopniowy (critical, high, medium, low).

Przyjęcie tylko jednego miernika do oceny

znalezionych zagrożeń nie jest wystarczające.
Oprócz wskaźnika określającego stopień
zagrożenia powinno się przyjąć również
prawdopodobieństwo jego wystąpienia
w odniesieniu do badanego obiektu. Na
podstawie przyjętych mierników możemy

wstępnie szacować poziom bezpieczeństwa
badanych systemów i aplikacji.

Przyjęcie stałych mierników pozwala

dodatkowo na porównywanie ze sobą
wyników raportów. Bez powtarzania testów
nie jesteśmy w stanie określić, czy udało nam
się usprawnić dany system bądź aplikację.
Porównując raporty możemy dokonać
szeregu analiz. Dla przykładu: w raportach
możemy na przykład analizować średnią ilość
wystąpienia wskaźników ryzyka typu high.
Analizy mogą być prowadzone dla wszystkich
systemów i aplikacji bądź też zawężone dla
wybranej usługi. Podsumowanie techniczne
wraz z wnioskami często jest połączone
z analizą techniczną. Zawarte w tej części
raportu powinny dostarczyć informacji
pozwalających zweryfikować oraz usunąć
wykryte błędy.

Podsumowanie

Zawarte w artykule informacje przybliżają
temat przeprowadzania tego rodzaju testów
w organizacji. Wybór rodzaju, zakresu i
metodyki testów należy już bezpośrednio do
osób odpowiedzialnych za bezpieczeństwo.

Dokonując wyboru powinno

indywidualnie zastanowić się, czy
przeprowadzać pełne testy penetracyjne,
czy skupić się na częściowym badaniu
podatności. Wybór rodzaju testu też zależy od
tego, co chcemy uzyskać.

Jeśli zależy nam na przeglądzie

zabezpieczeń, to warto przeprowadzać pełen
audyt bezpieczeństwa, wybrać podejście
typu Black Box, a testy traktować jako jeden
z elementów audytu. Można wtedy skupić się
jedynie na badaniu podatności. Zmniejsza to
czas wykonania testów oraz koszty. Badanie
podatności trwa 1-2 dni, natomiast testy
penetracyjne mogą zająć nawet kilka tygodni.

Z drugiej strony, chcąc na przykład

zbadać skuteczność wdrożonego systemu
wykrywania włamań (IDS/IPS), powinniśmy
wybrać symulację ataku oraz podejście typu
White Box.

Oprócz wyboru rodzaju i zakresu testów

należy również określić częstotliwość ich
wykonywania. W dojrzałych organizacjach
najczęściej wprowadza się harmonogram
audytów, w których testy penetracyjne mają
swoje miejsce. Warto zastanowić się nad
możliwością wykonania testów bezpośrednio
po określonych zdarzeniach. Przykładem
tutaj może być zmiana konfiguracji bądź
aktualizacja oprogramowania czy też
wprowadzenie nowej wersji aplikacji.

Częstotliwość audytów powinna zakładać

ich regularne wykonywanie. Bez powtarzania
testów nie jesteśmy w stanie określić, czy
udało nam się usprawnić system. Zarządzanie
bezpieczeństwem musi być systematyczne.
Wyniki raportu natomiast powinny zostać
opisane miernikami przyjętymi w metodyce
oraz pozwolić na określenie priorytetów
realizacji zaleceń poaudytowych.

Ze względu na ciągle rosnącą ilość

systemów i aplikacji zwiększają się również
koszty ich zabezpieczania. Organizacja bardzo
często musi wybierać, które zabezpieczenie
wdrożyć, a które ryzyko zaakceptować. Dane
w raporcie powinny być tak ułożone, abyśmy
mogli przeprowadzić analizę ryzyka określając
na początku tylko te najwyższe i zajmując się
nimi.

Sebastian Stroik

Od ponad 8 lat związany jest zawodowo z branżą

informatyczną. Na co dzień zajmuje się pracami

związanymi z realizacją projektów informatycznych.

Specjalizacja to projekty z zakresu bezpieczeństwa

IT. Obecnie pracuje jako specjalista do spraw

bezpieczeństwa IT w Synergy Group.

Kontakt z autorem: [e-mail]

W Sieci

Organizacje zajmujące się bezpieczeństwem

• ISACA – Information Systems Audits and Control Association – http://www.isaca.org/,
• ISECOM – Institute for Security and Open Methodologies – http://www.isecom.org/,
• OWASP – Open Web Application Security Project community – http://www.owasp.org/

index.php/Main_Page

• NSA – National Security Agency – http://www.nsa.gov/.
• CESG – http://www.cesg.gov.uk/
• NIST – National Institute of Standards and Technology – http://csrc.nist.gov/,
• WASC – Web Application Security Consortium – http://www.webappsec.org/.

Wybrane metodyki przeprowadzania audytów informatycznych

• Open Source Security Testing Methodology Manual – OPSSTM – http://www.isecom.org/

osstmm/,

• NIST Guideline on Network Security Testing – http://csrc.nist.gov/publications/nistpubs/800-

42/NIST-SP800-42.pdf,

• OWASP Testing Guide v.3 – http://www.owasp.org/index.php/Category:OWASP_Testing_

Project,

• BSI Penetration Testing Model – http://www.bsi.de/english/publications/studies/

penetration.pdf,

Narzędzia

• Top 100 Network Security Tools – http://sectools.org/,
• BackTrack – http://www.remote-exploit.org/backtrack.html.

Bazy podatności

• NVD – National Vulnerability Database – http://nvd.nist.gov/,
• CVE – Common Vulnerabilities and Exposures – http://cve.mitre.org/,
• CVSS – Common Vulnerability Scoring System – http://first.org/cvss/.