Proces zarządzania bezpieczeństwem informacji jest relacją trójstronną, w której występować powinni przedstawiciele biznesu, informatyki i niezależny audytor.
O tym, że bezpieczeństwo informacji to ciągły proces, a nie stan, powinni wiedzieć już wszyscy. Problem w tym, że każdy inaczej rozumie ten proces i realizuje go w różny sposób. Wiele firm w ramach zapewnienia bezpieczeństwa informacji ogranicza się do przeprowadzenia okresowych testów penetracyjnych i wdrożenia usprawnień wynikających z takich testów. Jeszcze inne popełniają grzech pierworodny i obdarzają administratora systemów IT bezgranicznym zaufaniem, pozostawiając temat bezpieczeństwa informacji w jego wyłącznej gestii. Nadal niewiele firm podchodzi do tematu bezpieczeństwa informacji w sposób właściwy i kompletny. Jednocześnie technologie wykorzystywane w biznesie są coraz bardziej skomplikowane, a liczba zagrożeń rośnie z roku na rok.
Norma bezpieczeństwa
Podejście procesowe do zarządzania bezpieczeństwem informacji jest powszechnie obowiązującym standardem. Znajduje on odzwierciedlenie w normie z zakresu zarządzania bezpieczeństwem informacji tj. PN-ISO/IEC 27001 - Technika informatyczna - Techniki bezpieczeństwa - Systemy zarządzania bezpieczeństwem informacji - Wymagania (ramka). W normie tej stosuje się model PDCA, zwany cyklem Deminga. Model ten określa podejście procesowe w celu ustanawiania, wdrożenia, eksploatacji, monitorowania, przeglądu, utrzymania i doskonalenia systemu zarządzania bezpieczeństwem informacji (ISMS) w organizacji. Model PDCA zakłada, iż na początku planujemy działanie (Plan), następnie po jego wdrożeniu (Do) weryfikujemy, czy przynosi ono oczekiwane rezultaty (Check) i na koniec wprowadzamy korekty do działania (Act) w celu jego usprawnienia.
Ogromna część zadań określonych w procesie zarządzania bezpieczeństwem informacji leży po stronie osób na co dzień zajmujących się administracją systemami IT. Nie wszystkie jednak zadania powinny być wykonywane przez te osoby. Niestety w trakcie wielu przeprowadzonych przeze mnie audytów przekonałem się, że często nawet etap planowania (ustanowienie ISMS) pozostawia się działom informatyki. Podobnie ma się sprawa z etapem sprawdzania (monitorowanie i przegląd ISMS). Przypisywanie tych odpowiedzialności działom informatyki jest powszechnym błędem, który często prowadzi do braku wsparcia procesu zarządzania bezpieczeństwem przez przedstawicieli biznesu i istotnego ograniczenia jego skuteczności i efektywności. Paradoksalnie cały ten proces ma na celu ochronę informacji... biznesowej.
|
Wymagania normy PN-ISO/IEC 27001
|
||
|
Planuj (ustanowienie ISMS) |
Ustanowienie polityki ISMS, celów, procesów i procedur istotnych dla zarządzania ryzykiem oraz doskonalenia bezpieczeństwa informacji, tak aby uzyskać wyniki zgodne z ogólnymi politykami i celami organizacji.
|
|
|
Wykonuj (wdrożenie i eksploatacja ISMS) |
Wdrożenie i eksploatacja polityki ISMS, zabezpieczeń, procesów i procedur.
|
|
|
Sprawdzaj (monitorowanie i przegląd ISMS) |
Szacowanie i pomiar wydajności procesów w odniesieniu do polityki ISMS, celów i doświadczenia praktycznego oraz dostarczanie raportów kierownictwu do przeglądu.
|
|
|
Działaj (utrzymanie i doskonalenie ISMS) |
Podejmowanie działań korygujących i zapobiegawczych w oparciu o wyniki wewnętrznego audytu ISMS i przeglądu realizowanego przez kierownictwo lub innych istotnych informacji, w celu zapewnienia ciągłego doskonalenia ISMS. |
|
Czy audytor jest potrzebny?
Jak w takim razie powinny wyglądać role w procesie zarządzania bezpieczeństwem informacji i kto powinien się w ten proces angażować? Proces zarządzania bezpieczeństwem informacji jest relacją trójstronną, w której występować powinni przedstawiciele biznesu, IT i niezależny audytor. Biznes jako właściciel informacji powinien określić wartość aktywów (informacyjnych) podlegających ochronie i oczekiwany poziom bezpieczeństwa, IT powinno dostarczyć rozwiązań zapewniających realizację założeń biznesowych oraz monitorować ich skuteczność i efektywność, a audytor powinien dokonać niezależnej i obiektywnej oceny tych rozwiązań.
Wielokrotnie spotkałem się z pytaniem, czy ocenę bezpieczeństwa musi przeprowadzać audytor. Przecież równie dobrze mogą zrobić to specjaliści z działu informatyki. Odpowiedź na to pytanie przychodzi wraz ze zrozumieniem różnicy pomiędzy monitorowaniem a niezależną oceną, jaką jest audyt. Monitorowanie jest integralnym elementem procesu zarządzania i ma na celu operacyjną weryfikację rozwiązań, ich skuteczności i efektywności. Dlatego powinno ono pozostać w gestii IT.
Niezależna ocena wykonana przez audytora ma na celu oszacowanie ryzyk związanych z przyjętą organizacją procesu i ewentualnym brakiem zgodności działań faktycznych z jego założonym przebiegiem oraz wskazanie rekomendacji usprawnień. Ocena taka wykonywana jest przez osobę niezależną od procesu i obszaru badanego, przez co jest obiektywna, a ponadto opiera się na faktycznych obserwacjach poczynionych w trakcie audytu, co stanowi o jej wiarygodności. Audytor zobowiązany jest przy tym ujawnić wszystkie istotne fakty związane z badanym obszarem, co z kolei zapewnia, że ocena jest kompletna.
Utożsamianie audytu z monitorowaniem i pozostawianie jej w rękach IT jest błędem i nie pozwala na ocenę wszystkich aspektów zarządzania bezpieczeństwem. Przekonujący jest tu argument, że rzeczą ludzką jest się mylić, tak samo jak rzeczą ludzką jest niechęć do przyznawania się do błędów. Rola audytora w procesie oceny ma za zadanie wyeliminować ten mankament poprzez włączenie w ten proces osoby zupełnie niezależnej od obszaru badanego. Nie oznacza to, że działy informatyki nie mogą przeprowadzić oceny procesu zarządzania bezpieczeństwem informacji. Co prawda, takiej oceny nie będzie można uznać za audyt, ale wniesie ona nieocenioną pomoc w usprawnianiu procesu zarządzania bezpieczeństwem.
Warsztat audytora
Podstawowym narzędziem każdego audytora systemów informatycznych jest metodyka COBIT 4.1 (Control OBjectives for Information and related Technologies). COBIT 4.1 pozwala określić kryteria oceny dla poszczególnych obszarów IT w organizacji. Towarzyszy mu przewodnik audytowania systemów informatycznych (IT Assurance Guide: Using COBIT), który zawiera szczegółowe wytyczne opisujące każdy etapów audytu, w tym planowanie, określenie zakresu, wykonanie audytu oraz raportowanie jego wyników.
Dla sprawnego przebiegu oceny niezbędne jest jej odpowiednie zaplanowanie. Plan powinien obejmować określenie celu oraz zakresu przeglądu. Należy przy tym udokumentować wszelkie ograniczenia zakresu wynikające np. z wyłączenia któregoś zagadnienia lub obszaru z oceny. Kolejnym etapem przeglądu jest jego przeprowadzenie (o czym dalej) i udokumentowanie jego wyników. Dokumentacja wyników jest niezwykle istotna ze względu na to, że stanowi ona podstawę do formułowania wniosków oraz rekomendacji zmian i usprawnień.
Przegląd powinien zakończyć się sporządzeniem raportu. Raport taki powinien opierać się na rzetelnej i wiarygodnej dokumentacji z przeglądu, a każda teza zawarta w raporcie powinna być podparta zgromadzonymi obserwacjami faktycznymi. Nadrzędną zasadą przy opracowywaniu raportu z przeglądu jest zawarcie w nim opisu zaobserwowanego stanu faktycznego, opisu ryzyk związanych z zaobserwowanym stanem oraz ewentualnych rekomendacji zmian i usprawnień. Raport sporządzany przez audytora powinien dodatkowo obejmować szereg innych informacji, które określone są w standardach audytowania systemów IT (Standard S7 - Raportowanie).
Wbrew przekonaniu, najwięcej trudności może nastręczać odpowiednie zaplanowanie i wykonanie przeglądu. Często wydaje się, że wiadomo co i po co audytować, ale w praktyce cel i zakres przeglądu powinny być zdefiniowane właściwie (aby dokonać oceny odpowiednich obszarów i zagadnień) i kompletnie (aby nie pominąć istotnych aspektów). Dodatkowo powinny one uwzględniać obszary, w których nieprawidłowości mogą być najbardziej dotkliwe.
Wykonanie przeglądu polega na ocenie konstrukcji mechanizmów kontrolnych pod kątem tego, czy zapewniają one zrealizowanie celów kontrolnych oraz ocenie skuteczności operacyjnej tych mechanizmów kontrolnych. Ocena konstrukcji mechanizmów kontrolnych powinna odpowiadać na pytanie, czy założona organizacja procesu jest prawidłowa i czy proces tak skonstruowany będzie skutecznie realizował założony cel. Ocena skuteczności operacyjnej natomiast ma na celu weryfikację, czy proces w rzeczywistości zachodzi zgodnie z założeniami. W przypadku stwierdzenia nieprawidłowej konstrukcji procesu i mechanizmów kontrolnych nie wykonuje się testów skuteczności operacyjnej.
Podsumowanie
Zarządzanie bezpieczeństwem informacji jest procesem, który nabiera coraz większego znaczenia w ochronie interesów firm wykorzystujących technologię w biznesie. Nieuchronnie zbliżamy się do punktu, w którym zaniedbania w tym zakresie będą przynosić trudne do zaakceptowania skutki. Dlatego też temat bezpieczeństwa informacji należy traktować podobnie do innych procesów biznesowych. Audytujemy procesy sprzedaży i zakupów, bo potencjalne nieprawidłowości w tych procesach są namacalne i dotkliwe. Jednocześnie w obszarze technologii polegamy na administratorach systemów i ich "tajemnej wiedzy", nie uświadamiając sobie zagrożeń wynikających z potencjalnych nieprawidłowości.
Jakość zarządzania bezpieczeństwem informacji możemy poprawić niewielkim wysiłkiem. Wystarczy uświadomić sobie, ile warta jest dla nas informacja biznesowa, określić wymagany poziom jej ochrony, a resztę oddać specjalistom IT. Później wystarczy tylko monitorować stan rzeczy, żeby poprawić proces zarządzania i przynajmniej raz w roku poddać go niezależnej ocenie. Audytowanie należy oddać audytorom, którzy zbadali niejedną firmę i doskonale wiedzą, jakie błędy się popełnia i jak można ich uniknąć.
| Proces zarządzania bezpieczeństwem informacji składa się z 11 celów kontrolnych: |
| - Zarządzanie bezpieczeństwem IT - Plan bezpieczeństwa IT - Zarządzanie tożsamością - Zarządzanie kontami użytkowników - Testy bezpieczeństwa i monitorowanie - Definicja incydentu bezpieczeństwa - Ochrona technologii bezpieczeństwa - Zarządzanie kluczami kryptograficznymi - Ochrona, wykrywanie i usuwanie wrogiego oprogramowania - Bezpieczeństwo sieci - Wymiana wrażliwych informacji |

