Kiedy organizacja, a wraz z nią struktura informatyczna zaczynają się rozrastać, pojawiają się problemy, które spędzają sen z powiek osób odpowiedzialnych za bezpieczeństwo IT. Objęcie czujnym okiem kilku systemów bezpieczeństwa, kilkudziesięciu serwerów, kilkuset urządzeń sieciowych, z których każde generuje tony informacji w różnych formatach - to prawdziwa "Mission Impossible". Prezentujemy bardzo ogólne spojrzenie na "Incident Management", zagadnienie na tyle skomplikowane, że nie mieści się w całości w tym krótkim opracowaniu.

Ogarnięcie dużego środowiska IT, stałe monitorowanie aktualnego stanu zabezpieczeń oraz wprowadzanie odpowiednich korekt jest zadaniem niezwykle złożonym. Do tego dochodzi pilnowanie zgodności z najróżniejszymi regulacjami i normami. Przykładem może być np. SOX, który od każdej firmy powiązanej z rynkiem kapitałowym w USA wymaga prowadzenia bieżącego monitoringu i audytowania systemów wykorzystywanych do wytwarzania danych nt. sprawozdawczości finansowej. Potrzebne jest zatem uporządkowanie tych wszystkich elementów, pozwalające na uzyskanie klarownego obrazu bezpieczeństwa systemów informatycznych, zapobieganie zagrożeniom i skuteczną obsługę tzw. incydentów bezpieczeństwa. Tutaj właśnie wkracza zarządzanie zdarzeniami i incydentami bezpieczeństwa. Jest ono kluczowe z punktu widzenia zapewnienia ciągłości biznesowej - daje możliwość usprawnienia procesów na nią wpływających, a także powoduje, że w razie zaistnienia incydentu ciągłość biznesowa zostanie zachwiana na możliwie najkrótszy okres.

Mówiąc o zarządzaniu incydentami, należy przede wszystkim poprawnie zrozumieć dwa terminy, którymi będziemy się dalej posługiwali - zdarzenie i incydent.

Według normy PN/ISO 27001:2007 zdarzeniem związanym z bezpieczeństwem informacji jest taki stan systemu, usługi lub sieci, który wskazuje na możliwe naruszenie polityki bezpieczeństwa informacji, błąd zabezpieczenia lub nieznaną dotychczas sytuację, która może być związana z bezpieczeństwem.

Incydentem bezpieczeństwa natomiast możemy nazwać takie niepożądane lub niespodziewane pojedyncze zdarzenie lub ich serię, które stwarzają znaczne prawdopodobieństwo zakłócenia działań biznesowych i zagrażają bezpieczeństwu informacji. Wynika stąd zatem, że incydent jest pojęciem zdecydowanie szerszym, niż zdarzenie. Wystąpienie określonego zdarzenia nie musi równać się naruszeniu zasad bezpieczeństwa. Natomiast powstanie incydentu stanowi dla nich (zasad) bezpośrednie zagrożenie.

Incident Management to "działka" bezpieczeństwa stosunkowo nowa i nie do końca jeszcze okrzepła. Widać to w regulacjach, które w coraz większym stopniu dotykają problematyki "Incident Management". Obecnie problematyka zarządzania incydentami poruszana jest w kilku źródłach. Pierwszym, który trzeba wziąć pod uwagę, jest wspominana już norma PN/ISO 27001:2007, dotycząca Systemów Zarządzania Bezpieczeństwem Informacji (SZBI - w oryginale Information Security Management System - ISMS). Jest ona aktualnym następcą klasycznej już normy BS 7799-2. Mówiąc ogólnie, dotyczy zasad przygotowywania, wdrażania, a następnie utrzymywania i monitorowania Systemu Zarządzania Bezpieczeństwem Informacji. Wytycznych dotyczących zarządzania samymi incydentami w normie tej należy szukać w szczególności w Załączniku normatywnym A punkt 13. (zainteresowani powinni jak najszybciej nabyć ww. normę -http://www.pkn.pl). Zarysowane są w nim wymagania w stosunku do postępowania ze zdarzeniami związanymi z bezpieczeństwem informacji oraz wynikającymi z nich incydentami (włącznie z gromadzeniem materiału dowodowego na potrzeby postępowania sądowego).

Kolejnym aktem normatywnym, który koniecznie powinien znaleźć się na podorędziu, powinien być ISO/IEC TR 18044:2004. Jest to tak naprawdę raport techniczny pokazujący, w jaki sposób powinno odbywać się zarządzanie incydentami bezpieczeństwa. Zawiera nie tylko wskazówki, ale również przykłady incydentów bezpieczeństwa wraz z wyjaśnieniem ich przyczyn. Traktuje także o dokumentacji, jaka powinna być prowadzona podczas wdrażania zasad zarządzania incydentami.

Poza tymi dwoma dokumentami tematyka związana z incydentami bezpieczeństwa pojawia się także we wszelkiego rodzaju metodykach. Przykładem może być ITIL (Information Technology Insfrastructure Library) zawierająca między innymi stosunkowo niewielki dział poświęcony Incident Management. ITIL wskazuje w nim, jak powinien wyglądać proces zarządzania incydentami, aby możliwe było jak najszybsze powrócenie do stanu "normalności", minimalizując przy tym negatywny wpływ na działania biznesowe.

Normalność to takie funkcjonowanie usług, które jest zgodne z SLA (Service Level Agreement). ITIL rozumie incydent w sposób zbliżony do normy PN/ISO 27001:2007, z tym że nacisk położony jest tutaj na cele biznesowe i utrzymanie jakości świadczonych usług. Innym przykładem metodyki, czy też zestawu najlepszych praktyk, która porusza problem Incident Management jest CoBIT (Control Objectives for Information and related Technology). Stanowi ona, według wielu specjalistów, znakomite uzupełnienie w tym temacie dla ITIL.

Warto też wspomnieć o wytycznych publikowanych w słynnej serii 800 przez amerykański NIST (National Institute of Standards and Technology). Nie należy pomijać również wskazówek stworzonych przez stowarzyszenie ISSA (Information Systems Security Association) - GAISP (Generally Accepted Information Security Principles) - m.in. zasada BFP-7 mówiąca, że kierownictwo powinno zapewnić zdolność do reagowania oraz umożliwić rozwiązywanie incydentów związanych z naruszeniem bezpieczeństwa informacji tak szybko i efektywnie, aby zminimalizować wpływ incydentu na działalność biznesową oraz zminimalizować prawdopodobieństwo wystąpienia podobnych incydentów w przyszłości.

Wspomnieliśmy, że zarządzanie incydentami to proces. Musi zatem składać się z pewnych faz. W zależności od podejścia, model procesu może przybierać różne postaci.