Dobrą ocenę rzeczywistego poziomu bezpieczeństwa może dać audyt obejmujący nie tylko system IT, ale również pracowników, ich zwyczaje i odporność na ataki socjotechniczne.

W wielu firmach przeprowadzane są audyty bezpieczeństwa. Zdarza się jednak, że decyzje o wykonaniu takiego czy innego audytu są podejmowane niespójnie i w efekcie wybór obszaru analizy nie przystaje zupełnie do potrzeb. Ocenę rzeczywistego poziomu bezpieczeństwa w przedsiębiorstwie może dać jedynie kompleksowy audyt, który jest oparty na jednym podstawowym założeniu - firma jako całość jest czymś więcej niż tylko zestawem poszczególnych części składowych.

Przez dziurkę od klucza

Najczęściej spotykanym audytem jest kontrola poprawności ustawień zapory sieciowej oraz stanu zabezpieczeń serwerów dostępnych z Internetu. Wiele firm korzysta z VPN, zatem potencjalni włamywacze potrafią wykorzystać słabości spowodowane nieprawidłową konfiguracją bramy albo też błędami w jej eksploatacji. Najczęściej spotykaną luką jest stara wersja oprogramowania posiadająca znane błędy. Warto pamiętać, że przy realizacji VPN typowej dla małych i średnich polskich firm, po kompromitacji bramy tej usługi, przed włamywaczem stoi otworem cała sieć lokalna. Przyczyna jest prosta - koszt (każda zapora kosztuje) i brak separowanej podsieci zawierającej serwery usług udostępnianych tą drogą.

Typowe testy penetracyjne mają za zadanie wyłapanie niedostatków zabezpieczeń zapory i serwerów. Są wykonywane przez specjalistów przez Internet, całkowicie zdalnie. Taki test jest stosunkowo prosty w realizacji i wiele firm wykonuje go za niewielkie pieniądze. Pozostaje pytanie, w jaki sposób firma to robi - czy uruchamia gotową konfigurację dedykowanego oprogramowania (choćby takiego jak Nessus) i przyjmuje wyniki za pewnik, czy specjalista za pomocą odpowiednich narzędzi dokonuje analizy.

Istotnym testem jest ustalenie poziomu zabezpieczeń serwerów usługowych. Wiele firm udostępnia usługi przez Internet. Nie zawsze można użyć VPN, czasami serwer musi być publicznie dostępny, zatem należy zadbać o jego bezpieczeństwo. Audyt powinien wykazać aktualność stosowanego oprogramowania, podatność na powszechnie znane luki. Testy penetracyjne powinny uwzględniać także podatność na ataki odmowy obsługi. Szczególnie ważną informacją jest reakcja serwera (i zapory) na próbę ataku, a także ilość danych o typie, wersji i konfiguracji składników serwera, jakie udaje się uzyskać tą drogą. Należy sprawdzić, czy możliwa jest enumeracja użytkowników, czy napastnik może uzyskać informacje o stosowanych zabezpieczeniach, czy daje się ustalić kiedy i kto się loguje itd.

Ważną informacją jest możliwość przejęcia kontroli nad serwerem poprzez eksploitowanie któregoś z powszechnie znanych błędów. Jeśli to jest możliwe w łatwy sposób, a serwer jest w sieci lokalnej firmy, to poziom bezpieczeństwa może być nawet mniejszy niż przy błędnie skonfigurowanej zaporze sieciowej. W dzisiejszych czasach rootkit umieszczony w środowisku serwerowym, a także w bazie danych jest coraz bardziej prawdopodobny. Każdy audyt bezpieczeństwa obejmujący serwery musi zawierać test integralności składników oprogramowania, mechanizmy umożliwiające detekcję rootkitów oraz ocenę podatności na powszechnie znane eksploity.

Sam serwer, nawet najlepiej zabezpieczony, nie gwarantuje bezpieczeństwa, jeśli aplikacja na nim hostowana zawiera poważne błędy. W dobie narzędzi umożliwiających udostępnienie usług przez przeglądarkę należy zwrócić szczególną uwagę na aplikację po stronie serwera realizującą tę usługę klientom. Tutaj nie można podać standardowego szablonu działania audytu, należy jedynie wskazać, co powinno zostać zbadane. Nie można także wskazać ani lepszej, ani gorszej technologii - można napisać bardzo bezpieczną aplikację w PHP lub dziurawą jak sito w ASP. Lub na odwrót.

Przede wszystkim muszą zostać przetestowane narzędzia dokonujące autoryzacji użytkowników - oprócz zasad ich działania należy sprawdzić, czy istnieje możliwość ich ominięcia. Należy sprawdzić, czy możliwe jest uzyskanie przez atakującego informacji, które nie mogą zostać ściągnięte z serwera, takich jak popularne pliki include. Następnym krokiem powinno być sprawdzenie, czy możliwe jest wykonanie złośliwego kodu SQL wewnątrz aplikacji za pomocą odpowiednio spreparowanych danych umieszczanych w polach formularzy. Taki błąd, popularnie nazywany SQL Injection, był bardzo często spotykany w wielu serwisach. Wynika on przeważnie z niedopatrzenia autorów aplikacji albo niedostatków używanych bezkrytycznie narzędzi. Osobnym problemem jest podatność na ataki cross-site-scripting. Wymienione błędy są tak poważne, że ustalenie odporności na takie ataki powinno być obowiązkową czynnością podczas audytu bezpieczeństwa publicznie dostępnej aplikacji.

Nie można do końca oddzielić audytu samej aplikacji od audytu serwera, na którym jest ona hostowana. Zdarzają się przypadki, gdy niektórych błędów aplikacji nie można eksploitować, gdyż konfiguracja serwera przed tym zabezpiecza. Bywa też odwrotnie - niedostatek w realizacji czy konfiguracji serwera aplikacyjnego może skutkować naruszeniem bezpieczeństwa poprawnie napisanej aplikacji.