Jak można definiować zakres działań?

Zadaniem audytu ma być ocenienie bezpieczeństwa zgodnie ze wzorcem. Logiczne wydaje się, żeby dobór środków, jakie będą zmierzać do realizacji tego celu, był zależny od audytora i jego doświadczenia, a nie tylko od zamawiającego. Tenże dobór środków jest zależny od konkretnego zlecenia i trudno jest podać uniwersalny przepis. Problem polega na tym, że aby rzetelnie zaproponować zestaw badań i sposób badania, audytor musi dobrze znać organizację zamawiającego. Pamiętajmy przy tym, że audytor musi być niezależny, a więc wykluczone jest, żeby znał on zamawiającego z innych zleceń. Jak można rozwiązać ten problem?

1. Skupić się na celu i wybrać audytora na podstawie kompetencji. Na etapie wstępnym - po kilku spotkaniach audytora z zamawiającym, mogą oni wspólnie ustalić zestaw niezbędnych testów i sposób prowadzenia prac. Ustalenia takie zapisuje się w Planie Jakości Projektu i przystępuje do wykonania prac. Niestety, taki sposób wyboru audytora wymaga dużej dozy zaufania od zamawiającego i przyjęcia optyki: "kwotę zapisaną w umowie przeznaczam na osiągnięcie celu, a nie na to, ile godzin poświęci audytor". Wydaje się to logiczne, ale nie przystaje do sposobu wyboru usługodawców, jaki stosuje większość firm (konkurs ofert) lub instytucji publicznych (zamówienie publiczne).

2. Wybór oferenta przeprowadzić dwuetapowo. W pierwszym etapie zdefiniować cele i poprosić o wstępną ofertę (bez podawania ceny) czy też materiały dotyczące oferowanych usług i dopuścić możliwość spotkań z oferentami. Oferentów, którzy nie spytają o możliwość rozmowy w celu doprecyzowania zakresu i poznania organizacji zamawiającego, należy z góry odrzucić jako nierzetelnych. Na podstawie spotkań i pytań zadawanych przez oferentów można wstępnie ocenić kompetencje poszczególnych zespołów. Po spotkaniach i na podstawie materiałów złożonych przez oferentów zamawiający może zdefiniować zakres działań i sposób wykonania audytu w takim stopniu, żeby składane oferty cenowe dały się porównać. Wadą takiego sposobu wyboru oferenta jest czasochłonność. Wymaga to też niewątpliwie dość dużego zaangażowania zamawiającego. Jeśli zamawiający nie ma doświadczenia w zamawianiu usług audytowych, to proces ten może prowadzić do zebrania nieporównywalnych ofert cenowych i w rezultacie do zamówienia nierzetelnej usługi.

W przypadku, gdy zamawiający audyt czuje, że nie posiada właściwego doświadczenia, dobrze jest pomyśleć o zatrudnieniu już na etapie zamawiania doświadczonego konsultanta, który będzie reprezentować jego interesy. Konsultant taki może też kontrolować przebieg audytu.

Niezależność

Niezbędną cechą, którą powinien posiadać zewnętrzny zespół audytorów, jest niezależność. W przypadku audytu z zakresu bezpieczeństwa teleinformatycznego niezależność ta powinna być zachowana w stosunku do zespołu budującego system zabezpieczeń, dostawców sprzętu i oprogramowania oraz organizacji podlegającej przeglądowi (w takim sensie, że w skład zespołu audytowego nie mogą wchodzić pracownicy organizacji zlecającej audyt).

Warto przy tym zwrócić szczególną uwagę na firmy integratorskie, dla których wykonywanie "audytów bezpieczeństwa" jest środkiem do późniejszej sprzedaży zabezpieczeń. Sytuacja jest czysta tak naprawdę tylko wtedy, gdy jedynym interesem audytującego jest wykonanie audytu. W każdym innym przypadku wiarygodność audytu jest wątpliwa.

Metodyka

W praktycznie każdym zapytaniu ofertowym czy SIWZ dotyczącym audytów (czy bardziej ogólnie - badania) bezpieczeństwa występuje pytanie o metodykę prac audytowych. Zresztą słusznie, bo po tym, jak usługodawca opisuje metodykę, często można rozpoznać jego doświadczenie.

Jakie elementy powinna zawierać metodyka? Przede wszystkim powinno to być narzędzie do przeprowadzenia audytu bezpieczeństwa informatycznego, a nie zbiór frazesów mający uśpić czujność zamawiającego. Dobrze skonstruowana metodyka pomaga audytorowi prowadzić projekt audytowy, a zleceniodawcy - kontrolować prace audytora. Powinna ona zawierać m.in.:

• Specyfikację dokumentów audytowych - przede wszystkim specyfikację zbiorczą zawierającą wszystkie dokumenty, jakie są niezbędne do zainicjowania audytu, oraz te, które będą produkowane w trakcie audytu - zarówno przekazywane do zleceniodawcy, jak i wewnętrzne.

• Opis procesów audytowych - które powinny prowadzić do powstania powyższej dokumentacji - z określeniem zależności między procesami oraz danych wejściowych i wyjściowych z każdego procesu.

• Wykaz tzw. rzetelnych praktyk - czyli zasad postępowania wypracowanych i sprawdzonych podczas dotychczasowej praktyki audytora.

• Pożądany skład zespołu audytowego i wyposażenie narzędziowe - opisowo bez zbędnej szczegółowości. Zarówno dobór ekspertów dziedzinowych, jak i narzędzi szczegółowych powinien być wykonany po zapoznaniu się z przedmiotem audytu na etapie budowy Planu Jakości Projektu.

Doświadczenie

Jednym z kluczowych elementów, który powinien podlegać ocenie przy wyborze wykonawcy audytu bezpieczeństwa, są kwalifikacje członków zespołu audytowego. Doświadczenie audytorów nie jest jednak proste do ocenienia ze względu na to, że w tak delikatnej dziedzinie, jaką jest bezpieczeństwo, z reguły nie udziela się referencji. Zwracam przy tym uwagę, że firmy często chwalą się referencjami, które uzyskały w wyniku prac integratorskich i wdrożeniowych, trudno je jednak uznać za doświadczenia audytowe.

Sposób prowadzenia projektu

Audyt bezpieczeństwa IT jest specyficznym przykładem projektu informatycznego. Specyficznym o tyle, że nie do końca da się go uściślić przed przystąpieniem do realizacji. Drugą z cech audytu jako projektu jest konieczność dość dużej interakcji ze zleceniodawcą. Dotyczy to zarówno spotkań z zespołem, jak i konieczności dostępu do serwerów, stacji roboczych i urządzeń. W związku z tym ważną rzeczą jest właściwa logistyka projektu (umawianie spotkań, zapewnienie dostępu do urządzeń itp). Kolejną niebagatelną różnicą w stosunku do innych projektów IT jest dość duża liczba generowanych dokumentów. Wymusza to prowadzenie sprawnej kancelarii projektu (po stronie usługodawcy).

Przy zamawianiu audytu warto wziąć pod uwagę to, że pierwszy jego etap powinien zmierzać do poznania organizacji przez audytora. Na tym etapie ustala się też procedury przepływu informacji, sposób przekazywania dokumentów i precyzuje wykonywane badania. Wszystko to powinno zostać zapisane w dokumencie opisującym projekt (funkcjonują tu różne nazwy, np. Plan Jakości Projektu, Podstawowy Dokument Projektu) i przyjęte przez obie strony. Posiadanie takiego dokumentu znacznie ułatwia i porządkuje późniejsze kontakty obu stron.

Czego nie należy się spodziewać?

Równie ważne jak świadomość, czego możemy spodziewać się po pracach audytowych, jest świadomość, czego nie należy się spodziewać. Przede wszystkim, jego efektem nie będzie budowa systemu bezpieczeństwa - audyt to tylko postępowanie oceniające. Jeśli audytor ma formułować zbyt daleko idące zalecenia, to zahacza to już o budowanie systemu bezpieczeństwa i może grozić utratą niezależności. Oczywiste jest, że zamawiający będzie spodziewał się konkretnych zaleceń, jednak powinny one dotyczyć jedynie usunięcia konkretnych słabych punktów.

Sposób wyceny

Z reguły przy projektach IT zleceniodawca chce uzależnić cenę od pracochłonności projektu. Przy audytach bezpieczeństwa ten sposób wyceny raczej się nie sprawdza. Po pierwsze, trudno jest na etapie konstruowania oferty ocenić pracochłonność. Jeśli usługodawca zostanie do tego zmuszony, to prawdopodobnie będzie stosował dość duże marginesy bezpieczeństwa, czyli w rezultacie ryzyko związane z niedoszacowaniem ponosi zleceniodawca. Poza tym większość prac audytor wykonuje poza siedzibą zleceniodawcy (analiza danych, pisanie raportów), pracochłonność nie jest więc miarą prostą do rozliczenia.

Dużo logiczniejszym sposobem jest wycena na podstawie wartości chronionych aktywów. Od tej wartości jest uzależniony budżet na bezpieczeństwo IT, a z reguły od tego budżetu zależy budżet na audyt bezpieczeństwa. Takie podejście, polegające na zorientowaniu się na cel, wymaga jednak dość dużego zaufania do audytora oferującego swoje usługi.

Wojciech Dworakowski jest kierownikiem projektów w krakowskiej firmie SecuRing.