Właśnie dotarł do mnie Computerworld nr 42/2004, a w nim temat tygodnia - artykuł Moniki Stępień Zabezpieczeni, ale przed czym. Z ogólną tezą się zgadzam - audyt czy ocena bezpieczeństwa nie powinny być oderwane od rzeczywistości biznesowej.

Dotyczy to zwłaszcza zaleceń. * Natomiast argumentacja przyjęta w artykule jest w moim przekonaniu co najmniej nietrafiona. Oto kilka uwag.

Przede wszystkim wrzucenie testów penetracyjnych i audytów do jednego worka i jakiekolwiek ich porównywanie jest grubym nieporozumieniem, o czym wielokrotnie i szczegółowo pisano na tych łamach. Porównanie tradycyjnie pojmowanego audytu do manewrów figurkami na mapie w sztabie, a testów penetracyjnych do ćwiczeń na poligonie jest bardzo trafne. Zabrakło tylko konkluzji, że na poligonie ćwiczy się jedną potyczkę (taktykę), a w sztabie myśli się w kontekście całej wojny (strategia i sztuka operacyjna).

Przykład o światłowodzie jest jak najbardziej trafny, natomiast przykład z aktywnymi gniazdkami RJ45 i ograniczeniem dostępu do serwerowni jest raczej pomyłką. W większości przypadków zalecenie kontroli dostępu fizycznego do serwerowni jest uzasadnione ekonomicznie, bo nie kosztuje zbyt wiele (no, chyba że ktoś komuś doradzi wdrożenie zbyt wyszukanych systemów zabezpieczających) i nie powoduje znaczącego wydłużenia konfiguracji stanowiska pracy. Na pewno kosztuje mniej, niż wdrażanie standardów uwierzytelnienia przy dostępie do sieci. Kontrolowanie tego typu procesów ma jeszcze tę dodatkową zaletę, że wzrasta świadomość administratorów i pewnych kroków nie robią pochopnie.

Rola ilościowej analizy ryzyka, którą postuluje artykuł, jest bardzo ważna, ale autorka nie bierze pod uwagę, że w rzeczywistości analiza ryzyka (zwłaszcza w ujęciu ilościowym) kosztuje niejednokrotnie więcej niż sam audyt czy przygotowanie zaleceń. Przykład z wyliczeniem ROI dla przeglądu kodu jest mało realny. Skąd wziąć "liczbę znanych przypadków", skoro nikt nie chwali się faktem, że w działającym u niego oprogramowaniu znaleziono konia trojańskiego? Ponadto, ile będzie kosztować ów "eksperyment", na podstawie którego ustali się "szanse, że osoba dokonująca inspekcji kodu wykryje takie oprogramowanie"?

Zgadzam się z tezą, że celem zamawiającego audyt w niektórych organizacjach jest działanie typu "obrona własnego stołka", ale nie można mówić, że jest to "podstawowy, dość wyraźnie widoczny cel". W rzeczywistości takie myślenie jest naiwnością ze strony decydentów. Jeśli audytor jest niezależny i nie będzie ulegał naciskom, to w raporcie wykaże nieprawidłowości. Decydent nie "obroni własnego stołka", a raczej wręcz przeciwnie - będzie mieć problem, jeśli nie podejmie działań naprawczych. Jeszcze jeden cytat: "Firma, która może pochwalić się, że wykonała badanie według jakiejś uznanej metodologii, w powszechnej opinii dobrze zabezpieczyła się przed intruzami". Tak, ale pod warunkiem, że wynik badania był pozytywny - cokolwiek by to miało znaczyć.

Podsumowując, zgadzam się z tezą, że niektóre firmy wykonujące audyty czy oceny bezpieczeństwa robią to niekompetentnie i w oderwaniu od realiów. W tej materii zachęcam do lektury mojego artykułu Krok po kroku opublikowanego w CW 24/2004. Nie zgadam się natomiast z wnioskiem, że audytowanie czy ocenianie kwestii związanych z bezpieczeństwem IT jest przeważnie nieuzasadnione ekonomicznie. Właśnie dlatego w naszych ofertach zaw-sze piszemy, że sprawdzamy zgodność z określonym standardem (niekoniecznie COBIT) i zasadami dobrej praktyki, ale przede wszystkim ze zdrowym rozsądkiem.

Podstawowym pytaniem, na jakie klient powinien umieć odpowiedzieć podczas wstępnych rozmów poprzedzających audyt/ocenę/sprawdzenie, jest jego cel biznesowy. To dlatego, niestety, nasze usługi słabo skalują się w dół. Cena audytu w małej organizacji i tak musi być stosunkowo duża (nad czym ubolewam, bo to zamyka nam część rynku), ponieważ potrzebne są owe 2-3 tygodnie na "nauczenie się instytucji", w tym poznanie jej otoczenia biznesowego.

Stosujemy metodykę LP-A (Liderman, Patkowski) przeprowadzania audytu bezpieczeństwa IT, która zawiera fazę "uczenia się instytucji" (faza przygotowawcza), pozwala na elastyczne podejście do stosowanego przy audycie standardu i uwzględnienie wyników badań technicznych (ot, choćby ochrony przed spamem czy możliwości phishingu, jeżeli takie są uzgodnienia z klientem), oraz wyraźny podział na ścieżkę formalną i ścieżkę techniczną.

Wojciech Dworakowski, ekspert ds. bezpieczeństwa IT w firmie SecuRing

* Formalnie rzecz biorąc "audyt" (taki przez duże A) to jedynie sprawdzenie stanu faktycznego i nie powinien zawierać ŻADNYCH zaleceń,a jedynie suchy opis sytuacji bieżącej. Argumenty związane z publikowaniem zaleceń na wyrost są tutaj nie na miejscu. Chyba że pojęcie "audyt" jest używane jako synonim jakiegokolwiek badania czy oceny stanu bezpieczeństwa.

Od autorki

Z ogromnym zainteresowaniem przeczytałam dwie polemiki dotyczące artykułu Zabezpieczeni, ale przed czym, autorstwa Wojciecha Dworakowskiego oraz duetu Jakub Bojanowski i Radosław Kaczorek. Prezentują one argumenty z zupełnie dwóch różnych punktów widzenia i o różnej wadze merytorycznej.

Wojciech Dworakowski patrzy na temat z punktu widzenia praktyka. Trudno się z nim nie zgodzić, gdy pisze, że kontrolowanie pewnych procesów ma wpływ na osoby odpowiedzialne za stan infrastruktury. Rolą audytu jest także kształtowanie świadomości pewnych ryzyk, zarówno u osób pełniących funkcje techniczne, jak i u menedżerów informatyki. Audyt rozumiany jako sygnalizacja zagrożeń i propozycja działań je ograniczających, stosownie do ich istotności, jest jak najbardziej potrzebny z punktu widzenia organizacji - nade wszystko w perspektywie spełnienia jej celów biznesowych - i tego nie kwestionowałam.

Po przeczytaniu obszernej wypowiedzi pp. Bojanowskiego i Kaczmarka, dominowało u mnie przekonanie, że znakomicie wywiązują się z roli akwizytora usług swojego pracodawcy. Gdybym wszystkie te opinie, które zawarli w swoim artykule, słyszała od menedżerów informatyki, byłabym przekonana o ich prawdziwości i celowości. Niestety, opinie CIO na temat realnej wartości audytu informatycznego, mówiąc wprost, rzadko pokrywają się z tymi przytaczanymi przez posiadaczy certyfikatów. Nic dziwnego, że autorzy powołują się na Ustawę Sarbanes-Oxley, a dokładniej jej sekcję 404, która "doceniła także audytorów informatycznych, których kwalifikacje stały się bardzo poszukiwane na rynku". Pozwolę sobie zauważyć, że popyt sztucznie "wspomagany" przez regulatora to dokładne przeciwieństwo mechanizmu rynkowego i doprawdy audytorzy nie mają być z czego dumni, że firmy zmuszone do szukania ich pomocy rzeczywiście to robią. Zaś skuteczność takich audytów na rok przed wprowadzeniem obowiązku ich przeprowadzania jest na razie hipotezą nie do zweryfikowania. Chciałabym zobaczyć realne fakty potwierdzające tę hipotezę; na razie jednak realne są wyłącznie koszty - 21 mld USD w 2005 r.

Kwestionowałam także wartość skodyfikowanego standardu w radzeniu sobie zarówno z ryzykami rozproszonymi, jak i nowymi jakościowo, na którą to wątpliwość polemiści nie odpowiadają. Myślę, że dlatego, iż tego typu zagrożenia mają charakter niedeterministyczny i trudny do wyszczególnienia w ramach prostej checklisty, a audytor bez checklisty nie jest audytorem, tylko "zwykłym" specjalistą.

W gruncie jednak chodzi nam o to samo - o zarządzanie ryzykiem systemów informatycznych. I w tym sensie pp. Dworakowski, Bojanowski i Kaczmarek zmierzają do tego samego co ja i dobrze, że racje każdego z nas ścierają się w dyskusji, bo od tego bezpieczeństwa raczej przybywa niż ubywa.

Monika Stępień