Jak w standardowy sposób zmierzyć bezpieczeństwo
-
- Paweł Krawczyk,
- 02.03.2010
Na świecie od dłuższego czasu prowadzone są prace nad standardyzacją metod oceny bezpieczeństwa systemów informatycznych. Jest to dalekowzroczna strategia, której celem jest obiektywizacja analizy ryzyka systemów informatycznych, a w konsekwencji stworzenie racjonalnych metod ich zabezpieczania.
Problem, który NIST stara się rozwiązać, wynika z faktu, że w branży IT jako stosunkowo młodej, gwarancje jakości są nadal w powijakach. Co gorsza ich dostępność jest niewspółmiernie mała w stosunku do odpowiedzialności jaką obarczają te systemy ich twórcy - wykorzystanie informatyki w każdej praktycznie dziedzinie życia skoczyło w ciągu ostatnich lat do przodu na niespotykaną skalę ale systematyczne techniki inżynierskie w tej branży dopiero niedawno zaczęły doganiać peleton postępu.
W zakresie oceny ryzyka powszechnie stosuje się audyty (np. ISO 27001) lub różne formy oceny ryzyka, w tym testy penetracyjne. Te pierwsze sprawdzają się nieźle w ocenie ogólnej dojrzałości w zakresie zarządzania bezpieczeństwem. Te drugie mogą dostarczyć wartościowych infomacji o praktycznym poziomie bezpieczeństwa danego systemu, jednak powtarzalność wyników i gwarancja ich jakości pozostawia nadal wiele do życzenia.
Lista zawiera na przykład pozycję sugerującą sprawdzenie aktualnie ustawionego czasu automatycznego wylogowania użytkownika po określonym czasie braku aktywności. Jeśli wartość ta odbiega od założonej wartości 15 minut to nalezy wskazać rozbieżność. W przypadku ręcznej weryfikacji na podstawie pliku Excela zrobiłaby to osoba testująca. W przypadku weryfikacji automatycznej rozbieżność powinno zauważyć oprogramowanie działające na podstawie listy w formacie OVAL.
Stąd bierze się właśnie intensywny rozwój systemów certyfikacji branżowej - począwszy od ogólnych certyfikatów audytowych (CISSP, CISA), aż po wyspecjalizowane certyfikaty inżynierskie (CEPT, CEH, LPT, OPSA), z których niektóre stały się standardem de facto przy zleceniach dla administracji publicznej (np. CHECK w Wielkiej Brytanii).
Powstają także metodyki ocen bezpieczeństwa - od ogólnych (ISO 27002, polska LP-A) po niskopoziomowe (OSSTMM, NIST SP 800-42 i 800-115, OISSG ISSAF, polska P-PEN, OWASP). Można także znaleźć podobne metodyki dla konkretnych protokołów (SSL Server Rating Guide) czy produktów (Microsoft Security Baseline Analyzer).
Powtarzalność i mierzalność wyników ocen bezpieczeństwa wymaga także standardyzacji samych obiektów, które podlegają testowaniu oraz ich podatności. Na szeroką skalę zajmuje się tym NIST, rozwijający National Vulnerability Database (NVD), National Checklist Program, SCAP (Security Content Automation Protocol) czy OVAL (Open Vulnerability and Assessment Language).
