© edu-Libri s.c. 2012

Redakcja merytoryczna i korekta: edu-Libri

Projekt okładki i stron tytułowych: GRAFOS

Wydawnictwo edu-Libri
ul. Zalesie 15, 30-384 Kraków
e-mail: edu-libri@edu-libri.pl

Skład i łamanie: GRAFOS
Druk i oprawa: Sowa Sp. z o.o., Warszawa

ISBN 978-83-63804-00-8
ISBN e-book 978-83-63804-01-5 (PDF)
ISBN e-book 978-83-63804-02-2 (epub)

Spis treści (wersja testowa)

Okładka

Spis treści

Wstęp

1. Wprowadzenie

1.1. Co to jest bezpieczeństwo informacji?

1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne?

1.3. Cele, strategie i polityki w zakresie bezpieczeństwa informacji

1.4. Czynniki decydujące o bezpieczeństwie systemów informacyjnych

1.5. Jak określać wymagania bezpieczeństwa?

1.6. Zarządzanie bezpieczeństwem informacji

1.7. Standardy związane z zarządzaniem bezpieczeństwem systemów informacyjnych

1.8. Zarządzanie ryzykiem a zarządzanie bezpieczeństwem informacji

1.9. Punkt wyjścia zapewniania bezpieczeństwa informacji

1.10. Krytyczne czynniki sukcesu

2. Zarządzanie ryzykiem systemów informacyjnych

2.1. Nazewnictwo związane z zarządzaniem ryzykiem

2.1.1. Pojęcia podstawowe

2.1.2. Nazewnictwo modelu zarządzania ryzykiem

2.2. Struktura ryzyka

2.2.1. Ryzyko polityczne

2.2.2. Ryzyko organizacyjne

2.2.3. Ryzyko operacyjne

2.3. Czynniki ryzyka systemów informacyjnych

2.3.1. Ludzie

2.3.2. Procesy i systemy

2.3.2.1. Systemy teleinformatyczne

2.3.2.2. Dokumentacja wewnętrzna i zewnętrzna

2.3.2.3. Lokalizacja

2.3.3. Zdarzenia zewnętrzne

2.3.3.1. Zdarzenia przewidywalne i nieprzewidywalne

2.3.3.2. Zlecanie czynności na zewnątrz (outsourcing)

2.4. Procesy zarządzania ryzykiem systemów informacyjnych

2.5. Ustalenie oczekiwań wobec zarządzania ryzykiem

2.5.1. Podstawowe kryteria oceny ryzyka systemów informacyjnych

2.5.2. Zakres i granice procesu zarządzania ryzykiem systemów informacyjnych

2.5.3. Organizacja zarządzania ryzykiem systemów informacyjnych

2.6. Zarządzanie zasobami i aktywami systemów informacyjnych

2.6.1. Zapewnianie zasobów i aktywów oraz odpowiedzialność za nie

2.6.1.1. Inwentaryzacja zasobów i aktywów

2.6.1.2. Własność zasobów

2.6.1.3. Akceptowalne użycie zasobów

2.6.2. Klasyfikacja informacji

2.6.2.1. Zalecenia do klasyfikacji

2.6.2.2. Oznaczanie informacji i postępowanie z informacjami

2.6.3. Wartość biznesowa aktywów, zwłaszcza informacji

2.7. Szacowanie ryzyka systemów informacyjnych

2.7.1. Analiza ryzyka systemów informacyjnych

2.7.1.1. Identyfikacja ryzyka

2.7.1.2. Oszacowanie (wycena) ryzyka

2.7.2. Ocena ryzyka systemów informacyjnych

2.8. Postępowanie z ryzykiem systemów informacyjnych

2.8.1. Unikanie ryzyka

2.8.2. Przeniesienie ryzyka

2.8.3. Utrzymanie/akceptowanie ryzyka

2.8.4. Redukcja ryzyka

2.8.5. Środki sterowania bezpieczeństwem

2.8.6. Środki łagodzenia ryzyka (przeciwdziałanie)

2.8.7. Strategia łagodzenia ryzyka

2.9. Akceptacja ryzyka przez kierownictwo

2.10. Informowanie o ryzyku

2.11. Monitorowanie i przegląd ryzyka

2.12. Kluczowe role w procesie zarządzania ryzykiem

3. Zarządzanie ryzykiem w projektach systemów informacyjnych

3.1. Wprowadzenie

3.2. Kryteria sukcesu projektu

3.3. Procesy zarządzania ryzykiem projektowym

3.4. Planowanie zarządzania ryzykiem projektowym

3.5. Identyfikacja zagrożeń

3.6. Analiza ryzyka

3.7. Szacowanie prawdopodobieństwa i skutku ryzyka

3.8. Planowanie reakcji na ryzyko

3.9. Sterowanie ryzykiem

3.10. Monitorowanie ryzyka

4. Zarządzanie reakcją na incydenty związane z naruszaniem bezpieczeństwa informacji

4.1. Podstawowe zagadnienia i korzyści związane z zarządzaniem incydentami

4.2. Przykłady incydentów związanych z naruszaniem bezpieczeństwa informacji

4.3. Procedury w zarządzaniu incydentami

4.3.1. Planowanie i przygotowanie

4.3.2. „Stosowanie” − wdrożenie i eksploatacja

4.3.3. Przegląd

4.3.4. Doskonalenie

5. System Zarządzania Bezpieczeństwem Informacji (SZBI)

5.1. Ustanowienie SZBI

5.1.1. Zakres i granice SZBI

5.1.2. Polityka bezpieczeństwa i jej akceptacja przez kierownictwo

5.1.3. Polityka bezpieczeństwa informacji

5.1.4. Dokument polityki bezpieczeństwa informacji

5.1.5. Przegląd polityki bezpieczeństwa informacji

5.1.6. Strategia zarządzania ryzykiem

5.2. Wdrożenie i eksploatacja SZBI

5.3. Monitorowanie i przegląd SZBI

5.4. Utrzymanie i doskonalenie SZBI

5.5. Organizacja zapewniania bezpieczeństwa informacji

5.5.1. Organizacja wewnętrzna

5.5.1.1. Zaangażowanie kierownictwa w zapewnianie bezpieczeństwa informacji

5.5.1.2. Koordynacja zarządzania zapewnianiem bezpieczeństwa informacji

5.5.1.3. Przypisanie odpowiedzialności w zakresie zapewniania bezpieczeństwa informacji

5.5.1.4. Proces autoryzacji środków przetwarzania informacji

5.5.1.5. Umowy o zachowaniu poufności

5.5.1.6. Kontakty z organami władzy

5.5.1.7. Kontakty z grupami zaangażowanymi w zapewnianie bezpieczeństwa

5.5.1.8. Niezależne przeglądy bezpieczeństwa informacji

5.5.2. Strony zewnętrzne

5.5.2.1. Ryzyko związane ze stronami zewnętrznymi

5.5.2.2. Bezpieczeństwo w kontaktach z klientami

5.5.2.3. Bezpieczeństwo w umowach ze stroną trzecią

5.6. Bezpieczeństwo zasobów ludzkich

5.6.1. Przed zatrudnieniem

5.6.1.1. Role i zakresy odpowiedzialności

5.6.1.2. Postępowanie sprawdzające

5.6.1.3. Zasady zatrudnienia

5.6.2. Podczas zatrudnienia

5.6.2.1. Odpowiedzialność kierownictwa

5.6.2.2. Uświadamianie, kształcenie i szkolenia z zakresu bezpieczeństwa informacji

5.6.2.3. Postępowanie dyscyplinarne

5.6.3. Zakończenie lub zmiana zatrudnienia

5.6.3.1. Odpowiedzialność związana z zakończeniem zatrudnienia

5.6.3.2. Zwrot zasobów

5.6.3.3. Odebranie praw dostępu

5.7. Bezpieczeństwo fizyczne i środowiskowe

5.7.1. Obszary bezpieczne

5.7.1.1. Fizyczna granica obszaru bezpiecznego

5.7.1.2. Środki ochrony fizycznego wejścia

5.7.1.3. Zabezpieczanie biur, pomieszczeń i urządzeń

5.7.1.4. Ochrona przed zagrożeniami zewnętrznymi i środowiskowymi

5.7.1.5. Praca w obszarach bezpiecznych

5.7.1.6. Obszary publicznie dostępne dla dostaw i załadunku

5.7.2. Bezpieczeństwo wyposażenia

5.7.2.1. Rozmieszczenie i ochrona wyposażenia

5.7.2.2. Systemy wspomagające przetwarzanie informacji

5.7.2.3. Bezpieczeństwo okablowania

5.7.2.4. Bezpieczna konserwacja sprzętu

5.7.2.5. Bezpieczeństwo wyposażenia znajdującego się poza siedzibą organizacji

5.7.2.6. Bezpieczne usuwanie lub ponowne wykorzystanie wyposażenia

5.7.2.7. Wynoszenie mienia

5.8. Zarządzanie eksploatacją i komunikacją SZBI

5.8.1. Procedury eksploatacyjne i odpowiedzialność

5.8.1.1. Dokumentowanie procedur eksploatacyjnych

5.8.1.2. Zarządzanie zmianami

5.8.1.3. Rozdzielanie obowiązków

5.8.1.4. Oddzielanie środowisk rozwojowych, testowych i eksploatacyjnych

5.8.2. Zarządzanie usługami dostarczanymi przez strony trzecie

5.8.2.1. Bezpieczne dostarczanie usług

5.8.2.2. Monitorowanie i przegląd usług strony trzeciej

5.8.2.3. Bezpieczne zarządzanie zmianami usług strony trzeciej

5.8.3. Planowanie i odbiór systemów

5.8.3.1. Zarządzanie pojemnością systemów

5.8.3.2. Akceptacja systemu

5.8.4. Ochrona przed kodem złośliwym i nadzór nad kodem mobilnym

5.8.4.1. Środki ochrony przed kodem złośliwym

5.8.4.2. Środki nadzoru nad kodem mobilnym

5.8.5. Kopie zapasowe

5.8.6. Zarządzanie bezpieczeństwem sieci

5.8.6.1. Systemy ochrony sieci

5.8.6.2. Bezpieczeństwo usług sieciowych

5.8.7. Obsługa nośników danych i dokumentacji

5.8.7.1. Zarządzanie nośnikami wymiennymi

5.8.7.2. Usuwanie nośników

5.8.7.3. Procedury postępowania z informacjami

5.8.7.4. Bezpieczeństwo dokumentacji systemowej

5.8.8. Wymiana informacji

5.8.8.1. Polityka i procedury wymiany informacji

5.8.8.2. Umowy o wymianie informacji

5.8.8.3. Transportowanie fizycznych nośników informacji

5.8.8.4. Wiadomości elektroniczne

5.8.8.5. Systemy informacyjne organizacji

5.8.9. Usługi handlu elektronicznego

5.8.9.1. Handel elektroniczny

5.8.9.2. Transakcje on-line

5.8.9.3. Informacje dostępne publicznie

5.9. Kontrola dostępu

5.9.1. Wymagania biznesowe i polityka kontroli dostępu

5.9.2. Zarządzanie dostępem użytkowników

5.9.2.1. Rejestracja użytkowników

5.9.2.2. Zarządzanie przywilejami

5.9.2.3. Zarządzanie hasłami użytkowników

5.9.2.4. Przeglądy praw dostępu użytkowników

5.9.3. Odpowiedzialność użytkowników

5.9.3.1. Używanie haseł

5.9.3.2. Pozostawianie sprzętu użytkownika bez opieki

5.9.3.3. Polityka czystego biurka i czystego ekranu

5.9.4. Kontrola dostępu do sieci

5.9.4.1. Zasady korzystania z usług sieciowych

5.9.4.2. Uwierzytelnianie użytkowników przy połączeniach zewnętrznych

5.9.4.3. Identyfikacja urządzeń w sieciach

5.9.4.4. Ochrona zdalnych portów diagnostycznych i konfiguracyjnych

5.9.4.5. Rozdzielanie sieci

5.9.4.6. Kontrola połączeń sieciowych

5.9.4.7. Kontrola rutingu w sieciach

5.9.5. Kontrola dostępu do systemów operacyjnych

5.9.5.1. Procedury bezpiecznego logowania się

5.9.5.2. Identyfikacja i uwierzytelnianie użytkowników

5.9.5.3. System zarządzania hasłami

5.9.5.4. Użycie systemowych programów narzędziowych

5.9.5.5. Zamykanie sesji po określonym czasie

5.9.5.6. Ograniczanie czasu trwania połączenia

5.9.6. Kontrola dostępu do informacji i aplikacji

5.9.6.1. Ograniczanie dostępu do informacji

5.9.6.2. Izolowanie systemów wrażliwych

5.9.7. Przetwarzanie mobilne i praca na odległość

5.9.7.1. Przetwarzanie i komunikacja mobilna

5.9.7.2. Praca zdalna

5.10. Pozyskiwanie, rozwój i utrzymanie systemów informacyjnych

5.10.1. Wymagania bezpieczeństwa systemów informacyjnych

5.10.2. Poprawne przetwarzanie w aplikacjach

5.10.2.1. Potwierdzanie poprawności danych wejściowych

5.10.2.2. Kontrola przetwarzania wewnętrznego

5.10.2.3. Integralność wiadomości

5.10.2.4. Potwierdzanie poprawności danych wyjściowych

5.10.3. Zabezpieczenia kryptograficzne

5.10.3.1. Zasady korzystania z zabezpieczeń kryptograficznych

5.10.3.2. Zarządzanie kluczami

5.10.4. Bezpieczeństwo plików systemowych

5.10.4.1. Zabezpieczanie eksploatowanego oprogramowania

5.10.4.2. Ochrona systemowych danych testowych

5.10.4.3. Kontrola dostępu do kodów źródłowych programów

5.10.5. Bezpieczeństwo w procesach rozwojowych i obsługi informatycznej

5.10.5.1. Procedury kontroli zmian

5.10.5.2. Techniczny przegląd aplikacji po zmianach w systemie operacyjnym

5.10.5.3. Ograniczenia dotyczące zmian w pakietach oprogramowania

5.10.5.4. Wyciek informacji

5.10.5.5. Prace rozwojowe nad oprogramowaniem powierzone firmie zewnętrznej

5.11. Wymagania dotyczące dokumentacji

5.11.1. Nadzór nad dokumentami

5.11.2. Nadzór nad zapisami

6. Zarządzanie zapewnianiem ciągłości działania

6.1. Osadzenie zapewniania ciągłości działania w kulturze organizacji

6.2. Zrozumienie istoty działania organizacji

6.2.1. Wprowadzenie procesu systematycznego zarządzania zapewnianiem ciągłości działania

6.2.2. Generalna analiza wpływu zakłóceń na działalność

6.2.3. Identyfikacja, analiza i ocena ryzyka ogólnego

6.2.4. Bezpieczeństwo informacji i ciągłość działania systemów informatycznych a zapewnianie ciągłości działania organizacji

6.3. Określanie strategii zarządzania zapewnianiem ciągłości działania

6.4. Opracowywanie i wdrażanie rozwiązań zapewniania ciągłości działania

6.4.1. Analiza ryzyka operacyjnego i mapa zakłóceń

6.4.2. Opracowywanie regulaminów, procedur, instrukcji

6.4.3. Projektowanie scenariuszy awaryjnych

6.4.4. Wdrażanie przyjętego postępowania z zakłóceniami

6.5. Testowanie, utrzymywanie i audyt rozwiązań zapewniania ciągłości działania

6.5.1. Testowanie

6.5.2. Utrzymywanie

6.5.3. Audyt

7. Odpowiedzialność kierownictwa organizacji

7.1. Zaangażowanie kierownictwa

7.2. Szkolenie, uświadamianie i kompetencje pracowników

8. Monitorowanie bezpieczeństwa

8.1. Monitorowanie i przeglądy SZBI

8.1.1. Niezależne przeglądy bezpieczeństwa informacji

8.1.2. Dzienniki zdarzeń

8.1.3. Monitorowanie wykorzystywania systemu

8.1.4. Ochrona informacji zawartych w dziennikach zdarzeń

8.1.5. Dzienniki zdarzeń administratora i operatora

8.1.6. Rejestrowanie błędów

8.1.7. Synchronizacja zegarów

8.1.8. Monitorowanie i przegląd usług strony trzeciej

8.1.9. Zgodność przeglądów z politykami bezpieczeństwa i standardami oraz zgodność techniczna

8.2. Przeglądy realizowane przez kierownictwo

8.2.1. Dane wejściowe do przeglądu

8.2.2. Wyniki przeglądu

9. Audyty SZBI

9.1. Audyty systemów informacyjnych

9.1.1. Bezpieczne prowadzenie audytu

9.1.2. Ochrona narzędzi audytu

9.2. Audyty wewnętrzne SZBI

9.3. Procesy audytowe

9.3.1. Etap przygotowawczy audytu

9.3.1.1. Spotkanie wstępne

9.3.1.2. Seminarium dla gremiów kierowniczych organizacji

9.3.2. Etap wykonawczy audytu

9.3.2.1. Ścieżka formalna audytu

9.3.2.2. Ścieżka techniczna audytu

9.3.3. Etap sprawozdawczy audytu

9.3.3.1. Opracowanie dokumentu końcowego

9.3.3.2. Przekazanie zleceniodawcy zbioru dokumentów audytowych

10. Doskonalenie SZBI

10.1. Ciągłe doskonalenie

10.2. Działania korygujące

10.3. Działania zapobiegawcze

11. Zgodność z przepisami prawa

11.1. Ustalenie odpowiednich przepisów prawa

11.2. Prawo do własności intelektualnej

11.3. Ochrona zapisów w organizacji

11.4. Ochrona danych osobowych i prywatność informacji dotyczących osób fizycznych

11.5. Zapobieganie nadużywaniu środków przetwarzania informacji

11.6. Regulacje dotyczące zabezpieczeń kryptograficznych

11.7. Sprawdzanie zgodności technicznej

12. Terminologia

12.1. Pojęcia i definicje

Wykorzystane źródła (powołania w ostatniej kolumnie)

12.2. Akronimy

Bibliografia

Wstęp

Przygotowaliśmy ten poradnik, kierując się własnym doświadczeniem – a zajmujemy się tymi zagadnieniami od ponad 20 lat – i obserwacjami czynionymi przy okazji licznych spotkań zawodowych, w których uczestniczymy. Ma on być odpowiedzią na specyfikę wyzwań, stawianych coraz częściej z jednej strony przez przepisy, a z drugiej strony przez wykształcone przez kilkanaście lat wzorce dobrych praktyk, w tym normy – międzynarodowe i krajowe. Ustawiają one na dającym się określić, niekiedy bardzo wysokim, poziomie poprzeczkę wymagań, jakie muszą być spełniane przez poszczególne organizacje. Co ciekawe, dotyczą one zagadnień z wielu obszarów i aspektów prowadzenia biznesu, w tym prawa i kilku dyscyplin techniki. Oznacza to, że nie jest możliwe, aby osoby odpowiedzialne za bezpieczeństwo informacji i systemów, w jakich są one przetwarzane, mogły być specjalistami w każdej z nich. A mimo że nie są specjalistami od wszystkiego, to muszą sprostać stawianym im zadaniom. To dlatego w tej dziedzinie tak wielkie znaczenie mają standardy dobrych praktyk.

Poradnik mówiący o tym, jak zapewniać odpowiedni poziom bezpieczeństwa systemów informacyjnych musi odwoływać się do pełnej interpretacji tego zagadnienia, a to oznacza przedstawienie nierozerwalnej triady problemowej: ryzyko – bezpieczeństwo – ciągłość działania. Z jednej strony, rozwiązania zapewniania bezpieczeństwa, jeśli mają być racjonalne, zawsze są odpowiedzią na określone rodzaje ryzyka, co oznacza, że logicznym początkiem zapewniania bezpieczeństwa jest identyfikowanie i analiza poszczególnych rodzajów ryzyka zagrażających organizacji. Z drugiej strony, żadne zabezpieczenia nie mogą być zawsze i w każdych warunkach skuteczne, a więc należy zakładać ich zawodność i na taką okoliczność szykować plany zapewniania ciągłości działania.

Powyższe wnioski są podstawą pomysłu na ten poradnik. Pokazuje on, jak interpretować kwestie bezpieczeństwa systemów informacyjnych, jakimi standardami (normami) i metodami się posługiwać, do jakich wzorców dobrych praktyk sięgać, jakie ośrodki doskonalące te praktyki obserwować, z jakim środowiskiem specjalistów się konsultować. Poradnik jest szczegółowy, w wielu fragmentach ma charakter list kontrolnych, które mają podpowiadać, jakie problemy i rozwiązania rozważać.

Poradnik jest skierowany w pierwszej kolejności do administratorów bezpieczeństwa systemów informacyjnych, ale nie tylko. Także do szeroko rozumianej kadry kierowniczej organizacji różnych branż, charakteru i wielkości, bowiem od tej kadry, znacznie częściej niż od administratorów, zależy faktyczne bezpieczeństwo. Także do specjalistów różnych profesji, którzy do zapewniania bezpieczeństwa mogą się w organizacjach przyczyniać. Rzecz bowiem w tym, że stan bezpieczeństwa budują wszyscy, a zburzyć go może już jedna osoba.

Poradnikowi nadaliśmy formę książki elektronicznej. Taki jest duch czasów, w których pracujemy, ale równocześnie ta forma powinna przysłużyć się i Czytelnikom, i treści. Posługującym się nią specjalistom będzie łatwiej mieć ją pod ręką. Autorom będzie łatwiej rozwijać jej treść, uważamy bowiem, że poradniki elektroniczne nieuchronnie zmierzają ku formule tematycznego repozytorium informacji, które stale jest wzbogacane o nowe treści, w dodatku w różnych formach. Chcielibyśmy, aby nasz poradnik można było w przyszłości aktualizować zgodnie ze zmieniającymi się standardami, wzbogacać o np. znaczące case-study, nowocześnie ilustrować, dopasowywać fragmentami do krystalizujących się specjalizacji w dziedzinie bezpieczeństwa.

4. Zarządzanie reakcją na incydenty związane z naruszaniem bezpieczeństwa informacji

Organizacja, która poważnie traktuje bezpieczeństwo informacji powinna mieć odpowiednią strukturę i zasady:

- wykrywania,

- rejestrowania i oceny incydentów związanych z naruszaniem bezpieczeństwa informacji,

- reagowania na takie przypadki, w tym przez włączenie odpowiednich zabezpieczeń w celu zapobiegania lub ograniczania wystąpienia takich zdarzeń oraz zapewniania umiejętności wznowienia działalności po ich wystąpieniu (np. planowanie ciągłości biznesowej).

Reakcja na incydenty z zakresu bezpieczeństwa informacji musi być oparta na jasnych założeniach, wynikać z przemyślanej organizacji i sprawnego współdziałania wszystkich zaangażowanych w nią jednostek. Każda organizacja powinna uczyć się na incydentach związanych z naruszaniem bezpieczeństwa informacji, tworzyć odpowiednie zabezpieczenia oraz systematycznie weryfikować ogólne podejście do zarządzania nimi.

W niniejszym rozdziale zawarto informacje na temat korzyści, jakie można uzyskać dzięki właściwemu podejściu do zarządzania incydentami związanymi z naruszaniem bezpieczeństwa informacji oraz zasad postępowania, aby było to możliwe. Podano argumenty pozwalające przekonać zarządzających organizacją, że program powinien być wprowadzony i stosowany. Opisano przykłady incydentów związanych z naruszaniem bezpieczeństwa informacji, analizując ich możliwe przyczyny, jak również opisano proces planowania i wymaganą do wprowadzenia skutecznej struktury zarządzania incydentami dokumentację. Szybkie, skoordynowane i skuteczne reagowanie na zdarzenia naruszające ochronę informacji wymaga technicznego i proceduralnego przygotowania. Reakcja na incydenty naruszenia bezpieczeństwa może polegać na podejmowaniu działań natychmiastowych, krótko- i długoterminowych. Działania takie powinny być oparte na wcześniej opracowanych, udokumentowanych i przyjętych procedurach, w tym na analizie doświadczeń. Rozdział ten dostarcza porad i wskazówek menedżerom bezpieczeństwa informacji, gestorom systemów informacji lub usług oraz zarządzającym sieciami o tym, jak zbudować skuteczny system zarządzania incydentami naruszania bezpieczeństwa informacji.

Terminologia związana z zarządzaniem incydentami nie jest jeszcze jednoznacznie ustalona. Szereg pojęć określono w normie [PN-I-02000:2002], a część w normie [PN-ISO/IEC 27001:2007], ale niestety są pewne różnice. Najbardziej istotne pojęcia zdefiniowano w specjalistycznym raporcie [ISO/IEC TR 18044:2004][1], niestety nie jest to zatwierdzony standard.

Najistotniejsze jest pojęcie incydentu. W normie [PN-I-02000:2002] napisano „incydent związany z naruszeniem bezpieczeństwa − każde działanie lub okoliczność wpływająca na sklasyfikowaną informację, odbiegające od zatwierdzonych wymagań dotyczących bezpieczeństwa” oraz „incydent związany z naruszeniem bezpieczeństwa systemu informatycznego − niekorzystne zdarzenie związane z systemem informatycznym, które według wewnętrznych reguł lub zaleceń dotyczących bezpieczeństwa jest awarią i/lub powoduje domniemane lub faktyczne naruszenie ochrony informacji albo powoduje naruszenie własności”.

Raport [ISO/IEC TR 18044:2004] wprowadza pojęcie „zdarzenie naruszenia bezpieczeństwa informacji (an information security event) to wystąpienie określonego stanu systemu, usługi lub sieci, który wskazuje na możliwe przełamanie polityki bezpieczeństwa informacji, defekt zabezpieczeń lub wcześniej nierozpoznaną sytuację, która może mieć związek z bezpieczeństwem”.

Natomiast w normie [PN-ISO/IEC 27001:2007] czytamy: „incydent związany z bezpieczeństwem informacji jest to pojedyncze zdarzenie lub seria niepożądanych lub niespodziewanych zdarzeń związanych z bezpieczeństwem informacji, które stwarzają znaczne prawdopodobieństwo zakłócenia działań biznesowych i zagrażają bezpieczeństwu informacji”.

W tym poradniku będziemy używać pojęcia „incydent związany z naruszeniem bezpieczeństwa informacji”, przez co należy rozumieć niepożądane lub niespodziewane pojedyncze zdarzenie (lub ich serię), wpływające na stan systemu, usługę lub sieć, mogące spowodować naruszenie zasad polityki bezpieczeństwa informacji, błędne działanie zabezpieczenia, nieznaną sytuację, która ze znacznym prawdopodobieństwem może wywołać zakłócenia działań biznesowych lub zakłócenia zagrażające bezpieczeństwu informacji.

4.1. Podstawowe zagadnienia i korzyści związane
z zarządzaniem incydentami

Realizacja każdego procesu zarządzania wiąże się z określonymi kosztami, dlatego szereg organizacji nie podejmuje systematycznego zarządzania incydentami najprawdopodobniej dlatego, że nie zdaje sobie sprawy z korzyści, jakie można uzyskać. Tymczasem warto zarządzać incydentami, gdyż powoduje to:

- zmniejszenie negatywnych skutków dla biznesu przez zmniejszenie przestojów powodowanych awariami i utrzymanie dobrego wizerunku organizacji;

- zmniejszenie obciążenia budżetu przez zmniejszenie kosztów ponoszonych na usuwanie skutków powodowanych przez incydenty;

- podniesienie poziomu bezpieczeństwa systemów informacyjnych przez koncentrację wysiłków organizacji na incydentach istotnych, określenie odpowiednich priorytetów, ewidencję incydentów oraz ich wnikliwą analizę; zwykle brak ewidencji incydentów i precyzyjnego określenia kosztów ponoszonych na usuwanie ich skutków nie pozwala na określenie ich wpływu na prowadzoną działalność gospodarczą;

- uwzględnienie wiedzy i doświadczenia, pozyskanych w toku zarządzania incydentami, w polityce bezpieczeństwa systemów informacyjnych oraz audytach i przeglądach;

- wprowadzanie adekwatnych zmian w analizie ryzyka i w zarządzaniu ryzykiem;

- opracowanie odpowiednich programów uświadamiania i szkolenia pracowników organizacji.

Aby zarządzanie reakcją na incydent spełniało właściwie swoje zadanie i przynosiło wspomniane korzyści, należy brać pod uwagę wymienione dalej zagadnienia.

Zaangażowanie kierownictwa wszystkich szczebli. Bez niego zarządzanie reakcją na incydent nie odniesie spodziewanych efektów. Zaangażowanie to powinno się przejawiać w motywowaniu osób odpowiedzialnych za czynności związane z zarządzaniem incydentami, dokonywaniu regularnych przeglądów prowadzonej ewidencji oraz inicjowaniu szkoleń aktualizujących wiedzę pracowników w tym zakresie.

Uświadamianie. Wysoka świadomość pracowników co do możliwych incydentów jest czynnikiem, który w istotny sposób wpływa na poziom ryzyka w organizacji. Świadomi pracownicy są w stanie unikać niekorzystnych zdarzeń, wskazywać na występujące luki i nieprawidłowości, proponować środki zaradcze oraz precyzyjnie określać czynniki ryzyka w odniesieniu do zagrożeń, z jakimi mogą mieć do czynienia.

Aspekty prawne i regulacyjne. Każda organizacja funkcjonuje w określonym systemie prawnym i organizacyjnym. System ten obejmuje ogólny układ legislacyjny, wiele regulacji lokalnych i wewnątrzorganizacyjnych oraz szereg standardów i norm. Znajomość wymagań mających związek z zarządzaniem incydentami, a wynikających z tego systemu, ma duży wpływ na właściwą realizację procedur w tym zakresie. System taki stawia bowiem inne wymagania dużym organizacjom finansowym, a inne organizacjom z kręgu średnich czy małych przedsiębiorstw. Niezależnie jednak od tych różnic należy:

- określić szczególne wymagania prawne,

- zapewnić odpowiednią ochronę danych i ochronę prywatności,

- zadbać o to, aby osoby, które badają sprawy związane z powstałymi incydentami, nie znały (jeśli to możliwe) osób mających związek z incydentem,

- zawrzeć umowy o zachowaniu poufności,

- zadbać o aktualność umów o zachowaniu poufności i ich zgodność z prawem,

- uwzględniać wszystkie wymagane kwestie w umowach z zewnętrznym personelem wsparcia,

- używać informacji tylko w sprawie, której dotyczą (tzn. konkretnego incydentu),

- wprowadzić zabezpieczenia w celu zapewnienia realizacji wymagań kontraktowych,

- zadbać o określenie odpowiedzialności,

- określić wpływ incydentu na organizację,

- umieć wykrywać słabości w produkcie,

- przekazywać informacje do odpowiednich organów państwowych,

- określić formalne wymagania co do czasu przechowywania zapisów,

- zbierać informacje o pracownikach zaangażowanych w incydent,

- wykrywać nieprawdziwe informacje o produkcie,

- odpowiednio przechowywać zapisy, na przykład dla audytu, uwzględniając rodzaj prowadzonej działalności i ich przypisanie do konkretnego incydentu.

Skuteczność operacyjna i jakość. Ich zapewnienie polega na:

- prowadzeniu skutecznej akcji dyscyplinarnej lub stawianie uzasadnionych oskarżeń,

- ustaleniu, czy system IT działał poprawnie w chwili incydentu,

- dbałości o kompletność zapisów,

- dbałości o identyczność kopii.

Anonimowość. Osobom udzielającym informacji o źródłach zagrożeń i sprawcach naruszania bezpieczeństwa należy zapewnić anonimowość. Jest to ważne z uwagi na ich bezpieczeństwo, ale również zapewnia kontynuację współpracy z tymi osobami.

4.2. Przykłady incydentów związanych z naruszaniem bezpieczeństwa informacji

Wyszczególnienie wszystkich potencjalnych rodzajów zagrożeń czy incydentów nie jest możliwe. W Internecie można znaleźć raporty zawierające wiele przykładów incydentów, żadna jednak ich lista na pewno nie jest zamknięta. Poniżej przytoczono przykładowe kategorie [ISO/IEC TR 18044:2004], które mogą zagrozić działalności prowadzonej przez organizację.

- Utrata usługi, urządzenia lub funkcjonalności.

- Przeciążenie lub niepoprawne działanie systemu.

- Błędy ludzkie.

- Odstępstwo od przyjętych zasad lub zaleceń.

- Naruszenia ustaleń związanych z bezpieczeństwem fizycznym.

- Niekontrolowane zmiany systemu.

- Niepoprawne działanie oprogramowania lub sprzętu.

- Naruszenia systemu kontroli dostępu.

- Odmowa obsługi.

- Zablokowanie zasobów:

- przeciążenie sieci,

- wysyłanie wiadomości w błędnych formatach,

- wymuszanie otwierania nadmiarowych sesji,

- błędna konfiguracja,

- niekompatybilność oprogramowania.

- Kradzież lub zniszczenie zasobów:

- kradzież sprzętu lub jego celowe zniszczenie,

- zniszczenie sprzętu przez wodę lub pożar,

- ekstremalne warunki otoczenia, np. temperatura,

- awaria systemu lub jego przeciążenie,

- niekontrolowana zmiana systemu,

- awaria oprogramowania lub sprzętu.

- Nielegalne pozyskiwanie informacji. Zwykle wiąże się to z rozpoznawaniem topologii sieci i wewnętrznej komunikacji oraz określeniem słabości atakowanych instalacji. W tym celu wykonywane są następujące operacje:

- pobranie adresów DNS (domain name systems),

- sprawdzenie adresów sieciowych,

- sprawdzenie identyfikacji hostów,

- skanowanie portów,

- sprawdzanie znanych słabości.

Po wykonaniu rozpoznania następuje bezpośredni atak[2], w wyniku którego dochodzi do naruszenia ochrony fizycznej i przez to nieautoryzowany dostęp do informacji lub kradzież urządzeń zawierających ważne dane, a w konsekwencji:

- bezpośrednie lub pośrednie ujawnienie lub modyfikacja informacji,

- kradzież własności intelektualnej,

- naruszenie rozliczalności,

- nadużycie systemu.

Najczęstszą przyczyną wystąpienia tego rodzaju incydentów jest słaby lub źle skonfigurowany system operacyjny, niekontrolowane wprowadzanie zmian, awarie sprzętu i oprogramowania umożliwiające dostęp do informacji osobom, które nie mają do nich praw.

Inne przypadki to:

- pozyskanie plików haseł,

- przepełnienie bufora w celu uzyskania dodatkowych przywilejów,

- wykorzystanie słabości protokołów w celu przejęcia lub oszukania połączeń sieciowych,

- powiększenie przywilejów ponad te, udzielone przez administratora,

- przełamanie ochrony fizycznej w celu nieuprawnionego dostępu do informacji,

- spadek wydajności spowodowany większą liczbą użytkowników, niż przewidziano,

- awaria sprzętu (naruszenie dostępności),

- zablokowanie systemu spowodowane brakiem umiejętności użytkowników,

- błąd (awaria) oprogramowania,

- atak (malwa re − naruszenie integralności i dostępności),

- włamanie i usunięcie danych (naruszenie integralności i dostępności),

- ujawnienie informacji, wykorzystanie w celach prywatnych (naruszenie poufności).

4.3. Procedury w zarządzaniu incydentami

Zarządzanie reakcją na incydent wchodzi w zakres zarządzania bezpieczeństwem a więc i w tym przypadku proces ten można przedstawić przy pomocy modelu PDCA – zwanym również cyklem Deminga (rys. 1.4). Tabela 4.1 przedstawia procedury w układzie modelu PDCA z uwzględnieniem specyfiki zarządzania incydentami.

4.3.1. Planowanie i przygotowanie

Od dokładności przeprowadzenia tego etapu zależy jakość realizowanych w przyszłości prac związanych z zarządzaniem incydentami. Po jego zakończeniu organizacja powinna być w pełni przygotowana do właściwego zarządzania incydentami. Na tym etapie podejmowane są następujące czynności:

- prace przygotowawcze,

- opracowanie polityki zarządzania incydentami naruszania bezpieczeństwa informacji,

- ustalenie postępowania z incydentami naruszania bezpieczeństwa informacji,

- aktualizacja polityki bezpieczeństwa informacji i procedur analizy ryzyka,

- powołanie Zespołu Reagowania na Incydenty (naruszania) Bezpieczeństwa Informacji − ZRIBI,

- powiązanie zarządzania incydentami z innymi obszarami zarządzania organizacją,

- powiązanie z zewnętrznymi organizacjami,

- organizacja wsparcia technicznego i organizacyjnego,

- opracowanie programu uświadamiania i szkolenia.

Tabela 4.1. Procedury w układzie modelu PDCA stosowane w procesach zarządzania incydentami

Planuj − Planowanie i przygotowanie (ustanowienie SZBI − plan)

Ustanowienie polityki bezpieczeństwa, jej celów, zakresu stosowania, procesów i procedur odpowiadających zarządzaniu ryzykiem oraz zwiększających bezpieczeństwo informacji, tak aby uzyskać wyniki zgodne z ogólnymi zasadami i celami organizacji.

Wykonaj − Stosowanie

(wdrożenie i eksploatacja SZBI − do)

Wdrożenie i eksploatacja polityki bezpieczeństwa, zabezpieczeń, procesów i procedur.

Wdrażanie procedur i innych zabezpieczeń zdolnych do zapewnienia natychmiastowego wykrycia i reakcji na incydenty związane z naruszeniem bezpieczeństwa.

Sprawdzaj − Przegląd

(monitorowanie i przegląd SZBI − check)

Ocena lub nawet pomiar wykonania procesów w odniesieniu do polityki bezpieczeństwa, celów i praktycznych doświadczeń oraz przekazywanie kierownictwu wyników przeglądu.

Realizowanie procedur monitorowania i przeglądu oraz innych zabezpieczeń w celu natychmiastowego identyfikowania naruszeń bezpieczeństwa i incydentów, zakończonych niepowodzeniem lub sukcesem.

Działaj − Doskonalenie

(utrzymanie i doskonalenie SZBI − act)

Podejmowanie działań korygujących i prewencyjnych na podstawie wyników przeglądu realizowanego przez kierownictwo, tak aby osiągnąć stałe doskonalenie SZBI.

Źródło: opracowanie własne na podstawie: [ISO/IEC TR 18044:2004].

Prace przygotowawcze. Skuteczne i efektywne wprowadzenie w życie schematu zarządzania incydentami jest uwarunkowane podjęciem i zakończeniem z sukcesem kilku działań przygotowawczych, do których należy zaliczyć:

- sformułowanie polityki zarządzania incydentami oraz uzyskanie dla niej akceptacji najwyższego kierownictwa;

- opracowanie szczegółowego schematu zarządzania incydentami, który powinien uwzględniać:

- skalę ważności incydentów, umożliwiającą ich formalny podział,

- wzorce formularzy do zgłaszania i raportowania zdarzeń i incydentów, opis powiązanych z nimi procedur i działań z odniesieniami do procedur wykorzystywanych przez systemy i plan zapewniania ciągłości działania; jeśli to możliwe, to wszystkie formularze powinny być w formie elektronicznej z linkami do bazy zdarzeń/incydentów;

- operacyjne procedury dla ZRIBI ze zdefiniowaną odpowiedzialnością oraz przydzieleniem ról do konkretnym osobom w celu wykonywania takich czynności, jak np.:

- zamykanie systemu, co w poszczególnych przypadkach powinno być poprzedzone uzgodnieniem tego z właścicielem biznesowym oraz z osobą odpowiedzialną za systemy teleinformatyczne,

- pozostawienie działającego systemu,

- uruchomienie procedur odtwarzania z kopii zapasowych, procedur planu zapewniania ciągłości działania oraz podjęcie działań wynikających z polityk bezpieczeństwa poszczególnych systemów,

- zapewnianie bezpiecznego przechowywania śladów i dowodów (także w wersji elektronicznej), szczególnie w przypadku gdy niezbędne jest przeprowadzenie działań śledczych lub wewnętrznego postępowania wyjaśniającego,

- wymiana informacji o incydentach z innymi osobami wewnątrz organizacji lub z osobami (organizacjami) trzecimi;

- testowanie użycia ustalonej procedury zarządzania incydentami oraz procesów i procedur ZRIBI;

- aktualizacja polityki bezpieczeństwa informacji, polityki analizy i zarządzania ryzykiem oraz polityk dedykowanych do poszczególnych systemów;

- zorganizowanie ZRIBI wraz z odpowiednim programem szkoleniowym dla jego członków;

- zapewnienie środków (szczególnie technicznych) wspierających zarządzanie incydentami, a co za tym idzie pracę ZRIBI;

- zaplanowanie, rozwój oraz realizację programu uświadamiającego i szkoleniowego dla wszystkich pracowników.

Opracowanie polityki zarządzania incydentami naruszania bezpieczeństwa informacji. Celem polityki jest wskazanie podstawowych zasad zarządzania incydentami naruszania bezpieczeństwa informacji w organizacji, które będą podstawą do opracowania i wdrożenia procesu zarządzania incydentami. Polityka powinna być zatwierdzona przez najwyższe kierownictwo organizacji, a fakt ten powinien być udokumentowany.

Polityka jest przeznaczona dla wszystkich osób posiadających uprawniony dostęp do zasobów informacyjnych organizacji. Powinna być dostępna dla każdego pracownika, współpracownika lub zleceniobiorcy organizacji oraz powinna być uwzględniona w programie uświadamiającym i szkoleniowym.

Polityka powinna:

- określać podstawy formalnoprawne;

- podkreślać znaczenie zarządzania incydentami dla organizacji;

- komunikować akceptację najwyższego kierownictwa dla polityki oraz systemu zarządzania incydentami;

- zawierać przegląd kwestii związanych z wykrywaniem, zgłaszaniem i gromadzeniem informacji o zdarzeniach oraz zdefiniowaniem, w jaki sposób mogą one być wykorzystane do określenia incydentów; przegląd ten powinien zawierać podsumowanie możliwych typów zdarzeń, sposobów wyjaśniania, zakresu raportowania (co, w jaki sposób, gdzie i do kogo przekazywać) oraz sposobu reagowania na nowe, nieznane dotąd, typy zdarzeń;

- określać modelowy przegląd oceny incydentu, ustalenie kto jest odpowiedzialny za jego zaistnienie, wskazanie co ma być zrobione, powiadomienie zainteresowanych stron i przełożonych;

- wskazywać, jak przeprowadzać podsumowanie działań, podjętych po potwierdzeniu faktu, że zdarzenie jest incydentem, co obejmuje:

- ocenę pierwszej reakcji,

- analizę śladów i dowodów,

- komunikację ze wszystkimi zainteresowanymi stronami,

- ocenę, czy przebieg incydentu jest kontrolowany,

- wskazanie właściwej dalszej reakcji,

- podjęcie działań kryzysowych,

- określenie warunków informowania przełożonych,

- wskazanie, kto jest odpowiedzialny za poszczególne działania;

- wskazywać potrzebę zadbania o to, aby:

- wszystkie działania zostały właściwie zapisane w celu ich późniejszej analizy,

- prowadzone było ciągłe monitorowanie w celu zapewnienia bezpieczeństwa zgromadzonych i przechowywanych śladów i dowodów (także w wersji elektronicznej), szczególnie w przypadku gdy będzie to wymagane do prowadzenia śledztwa lub wewnętrznego postępowania wyjaśniającego;

- określać działania podjęte po zamknięciu incydentu, włącznie z wnioskami wyciągniętymi z przebiegu i wyjaśniania incydentu oraz udoskonalaniem procesu zarządzania incydentami;

- wskazywać miejsce przechowywania dokumentacji zarządzania incydentami (włącznie z procedurami);

- określać, jak dokonywać przeglądów programu uświadamiającego i szkoleniowego w zakresie zarządzania incydentami;

- podawać podstawowe informacje o ZRIBI obejmujące:

- strukturę organizacyjną ZRIBI wraz z identyfikacją kluczowego personelu oraz określeniem, kto jest odpowiedzialny za:

- powiadamianie o incydentach najwyższego kierownictwa organizacji,

- gromadzenie informacji i podejmowanie działań,

- kontakty (kiedy to konieczne) z organizacjami lub organizacjami zewnętrznymi;

- precyzyjne określenie, czym zajmuje się ZRIBI i z jakiego upoważnienia działa; minimum to zdefiniowanie misji, zakresu zadań, sponsora i uprawnień ZRIBI:

- jasne i jednoznaczne określenie misji i celu funkcjonowania ZRIBI, które powinno skupić się na najważniejszych jego działaniach (m.in. wspieranie, ocenianie, reagowanie i zarządzanie reakcją na incydent, aż do ostatecznego wyjaśnienia jego przyczyn);

- definicję zakresu działania ZRIBI, który zwykle obejmuje wszystkie systemy przetwarzania informacji; w szczególnych przypadkach organizacja może ograniczać ten zakres, ale powinno to być jasno określone (co jest objęte zakresem, a co zostało wyłączone) i odpowiednio udokumentowane;

- wskazanie osoby z najwyższego kierownictwa, która odpowiada za finansowanie prac ZRIBI i autoryzuje jego działania.

Wiedza na ten temat pozwala pracownikom organizacji zrozumieć podstawy działania i umocowanie ZRIBI, co z kolei umożliwia zbudowanie zaufania do ZRIBI. Przed opublikowaniem tych informacji należy dokonać ich weryfikacji z prawnego punktu widzenia. Należy wziąć pod uwagę fakt, że w niektórych przypadkach ujawnienie uprawnień danego członka ZRIBI może go narazić na naciski wynikające z podległości służbowej.

Postępowanie z incydentami naruszania bezpieczeństwa informacji. Ustalenie modelu właściwego postępowania z incydentami może polegać na opracowaniu szczegółowej dokumentacji opisującej procesy i procedury takiego postępowania oraz sposoby komunikowania o incydentach. Dokumenty te są używane w przypadku wykrycia zdarzenia i służą za poradnik w zakresie:

- reagowania na zdarzenia,

- ustalenia, czy zdarzenie jest incydentem,

- zarządzania incydentami aż do ostatecznego ich wyjaśnienia,

- wdrażania zidentyfikowanych udoskonaleń.

Dokumentacja zarządzania incydentami jest przeznaczona dla wszystkich pracowników organizacji, w szczególności:

- osób odpowiedzialnych za wykrywanie i zgłaszanie zdarzeń, ocenę i reagowanie na zdarzenia i incydenty,

- osób zaangażowanych w działania podjęte po fazie wyjaśniania incydentu, w doskonalenie procesu zarządzania incydentami i samego systemu, personelu wspierającego działania operacyjne, ZRIBI, kierownictwa organizacji, działu prawnego, rzecznika biura prasowego itp.,

- firm trzecich, organizacji gospodarczych i urzędów.

Dokumentacja zarządzania incydentami powinna zawierać wymienione poniżej elementy.

- Przegląd polityki zarządzania incydentami.

- Przegląd całego systemu zarządzania incydentami.

- Szczegółowe procesy i procedury oraz informacje o narzędziach i klasyfikacji incydentów są związane z:

- wykrywaniem i opiniowaniem występowania zdarzeń,

- zbieraniem informacji o zdarzeniach,

- przeprowadzaniem oceny zdarzeń, wykorzystywaniem klasyfikacji zdarzeń i incydentów oraz ustalaniem, czy zdarzenie można uznać za incydent,

- fazą „przeglądania” (w przypadku gdy incydenty są potwierdzone),

- komunikowaniem wystąpienia incydentu lub przekazaniem informacji o incydencie wewnątrz organizacji oraz organizacjom trzecim,

- podejmowaniem natychmiastowej reakcji zgodnie z analizą i potwierdzoną oceną stopnia ważności incydentu, która może obejmować aktywację procedur odtworzenia i kontakty między osobami zaangażowanymi w reakcję,

- przeprowadzaniem analizy śladów i dowodów, a jeśli to konieczne, dokonaniem zmiany kategorii lub stopnia ważności incydentu,

- podejmowaniem decyzji, czy przebieg incydentu ma być kontrolowany,

- rozpoczęciem innych wymaganych działań (np. ułatwiających odtworzenie systemu po awarii lub zniszczeniu),

- podejmowaniem działań kryzysowych, jeśli przebieg incydentu nie jest kontrolowany (np. powiadomienie straży pożarnej, uruchomienie planu ciągłości działania),

- powiadamianiem przełożonych w celu podjęcia dalszej oceny lub decyzji,

- zapewnianiem, że wszystkie działania są właściwie zapisane w celu ich późniejszej analizy,

- aktualizacją bazy zdarzeń/incydentów.

- Szczegóły klasyfikacji (skali ważności) zdarzeń i incydentów oraz związanych z nimi wskazówek.

- Wytyczne do podejmowania decyzji, czy wymagane jest zawiadomienie przełożonych w poszczególnych fazach procesu, oraz powiązane z wytycznymi procedury. Każda osoba oceniająca zdarzenie lub incydent powinna wiedzieć, bazując na poradach zawartych w dokumentacji postępowania z incydentami, kiedy w normalnych przypadkach informować przełożonych i których. Należy rozważyć to, że może mieć miejsce nieprzewidywalny lub mało ważny incydent, który w przypadku podjęcia niewłaściwej reakcji lub jej braku może doprowadzić do sytuacji kryzysowej. Poradnik powinien definiować zdarzenia i typy incydentów, typy zgłoszeń do wyższego kierownictwa i określać, kto może zgłaszać.

- Procedury zapewniające, że wszystkie działania są właściwie zapisane, we właściwej formie, a analiza zapisów jest przeprowadzana przez odpowiedni personel.

- Procedury i mechanizmy zapewniające właściwe zarządzanie zmianami w zakresie śledzenia zdarzeń i incydentów oraz aktualizacji raportowania o incydentach oraz samego systemu zarządzania incydentami.

- Procedury analizy śladów i dowodów.

- Procedury korzystania z systemów wykrywania włamań IDS, zapewniające, że spełnione są wymagania prawne i regulacyjne.

- Schemat struktury organizacyjnej.

- Warunki powoływania i zakres odpowiedzialności ZRIBI (jako całości oraz poszczególnych jego członków).

- Ważne dane kontaktowe (numery telefonów, adresy e-mail).

Dokumentacja postępowania z incydentami powinna określać zarówno natychmiastową, jak i długoterminową reakcję na incydenty. Wszystkie incydenty wymagają bowiem jak najszybszej oceny potencjalnych negatywnych skutków w krótkiej i długiej perspektywie czasu. Dodatkowo, w przypadku wystąpienia zupełnie nieprzewidzianych wcześniej incydentów, podjęcie reakcji może oznaczać konieczność zastosowania rozwiązań tymczasowych (ad hoc). Nawet w takich sytuacjach opis sposobu postępowania z incydentami powinien podawać ogólne wytyczne co do kroków, jakie trzeba wykonać.

Po wystąpieniu incydentu należy podjąć takie czynności, dzięki którym w sposób systematyczny i dokładny można będzie ustalić przyczyny jego zaistnienia oraz które pozwolą przygotować właściwą dokumentację. Ułatwi ona i usprawni działania w tym zakresie w przyszłości. Do najważniejszych czynności należą:

- przeprowadzenie (jeśli to wymagane) dodatkowej analizy śladów i dowodów,

- identyfikacja i udokumentowanie wniosków wynikających z incydentu,

- przeglądanie i identyfikacja usprawnień rozwiązań bezpieczeństwa informacji,

- ocena efektywności procesów i procedur w trakcie odtwarzania stanu wyjściowego, oraz wskazywanie możliwości doskonalenia rozwiązań zarządzania incydentami,

- aktualizacja bazy zdarzeń/incydentów.

Stosownie do wniosków wynikających z incydentów, należy dążyć do wprowadzenia udoskonaleń, mając w szczególności na względzie:

- rezultaty analizy i ich odniesienia do dotychczasowego systemu zarządzania ryzykiem,

- zasady zarządzania incydentami (np. procesy, procedury, formularze, struktura organizacyjna),

- ogólny poziom bezpieczeństwa wynikający z wdrożenia nowych lub ulepszonych zabezpieczeń.

W organizacji potrzebne są udokumentowane i sprawdzone procedury, które powinny między innymi:

- określać osoby odpowiedzialne,

- dotyczyć śladów i dowodów związanych z incydentem oraz działań kryzysowych,

- być zgodne z polityką oraz dokumentacją zarządzania incydentami.

ZRIBI powinien zagwarantować publiczny dostęp do porad oraz rezultatów z analizy incydentów, w czytelnej i zrozumiałej dla wszystkich pracowników postaci. Niektóre z tych procedur mogą być opatrzone klauzulą „poufne”. Zwłaszcza powinno to dotyczyć informacji szczegółowych o zastosowanych zabezpieczeniach, sposobach śledzenia zdarzeń i sposobach reakcji na zaistniałe incydenty. Ma to na względzie ochronę przed możliwością manipulacji wewnątrz organizacji, jak również wrogimi działaniami z zewnątrz.

Treść procedur zależy od kilku czynników:

- typu incydentu,

- typu produktu,

- natury poszczególnych zdarzeń i incydentów,

- typu zasobów,

- środowiska przetwarzania.

Procedura powinna określać podejmowane kroki i osobę (lub osoby), która ma je podejmować. W procedurze powinny być wykorzystane doświadczenia wewnętrzne i zewnętrzne. Procedury są opracowywane przede wszystkim dla znanych typów zdarzeń i incydentów, ale również dla nieznanych. Dla nieznanych typów zdarzeń i incydentów określa się:

- tryb ich zgłaszania,

- czas niezbędny na uzyskanie aprobaty najwyższego kierownictwa, na tyle krótki, aby uniknąć jakiegokolwiek opóźnienia w podjęciu reakcji,

- delegowanie uprawnień do podejmowania decyzji w sytuacjach nadzwyczajnych lub kryzysowych.

Należy zaplanować regularne kontrole oraz testowanie procesu i procedur, tak aby było możliwe ujawnienie i wskazanie potencjalnych wad oraz problemów, mogących wystąpić w trakcie zarządzania zdarzeniami lub incydentami. Jakakolwiek zmiana, która wynika z przeglądu dokonanego po wyjaśnieniu zdarzenia lub incydentu, powinna być drobiazgowo i dokładnie sprawdzona oraz testowana przed wprowadzeniem w życie.

Polityka bezpieczeństwa informacji i polityka zarządzania ryzykiem. Włączenie kwestii zarządzania reakcją na incydent do polityki bezpieczeństwa informacji, polityki zarządzania ryzykiem oraz polityk poszczególnych systemów:

- zapewnia skuteczne zarządzanie reakcją na incydent, w tym właściwe zgłaszanie incydentów;

- podkreśla rolę kierownictwa organizacji we właściwym przygotowaniu reagowania na incydenty;

- zapewnia spójność polityk i procedur;

- umożliwia spójne zaplanowanie systematycznego i racjonalnego trybu reagowania na incydenty, co ogranicza ich niekorzystne skutki.

Wszystkie wymienione polityki powinny być aktualne i wyraźnie odnosić się do polityki zarządzania reakcją na incydent. Dodatkowo wymagają one określenia mechanizmów przeglądania w celu zagwarantowania, że wszelkie informacje pochodzące z wykrywania, zgłaszania, monitorowania lub rozwiązywania incydentów, są wykorzystywane do aktualizowania zasad zarządzania i polityk bezpieczeństwa poszczególnych systemów.

Utworzenie Zespołu Reagowania na Incydenty (naruszania) Bezpieczeństwa Informacji (ZRIBI). Powołanie ZRIBI oznacza wskazanie personelu uprawnionego do oceniania, reagowania i wyciągania wniosków z incydentów, a także do koordynacji postępowania będącego reakcją na incydent oraz zapewniania komunikacji między zainteresowanymi stronami. Dobrze zorganizowana działalność ZRIBI może w dużym stopniu przyczynić się do zmniejszenia strat materialnych i finansowych, jak również utrzymywania właściwego wizerunku i reputacji organizacji.

ZRIBI to grupa odpowiednio wyszkolonych i zaufanych osób (członków organizacji), która jest w stanie zapewnić właściwą reakcję na incydent naruszenia bezpieczeństwa informacji, wspomagana czasem przez zewnętrznych ekspertów, np. reprezentujących uznane zespoły reagowania, CERT itp. Przy powoływaniu tego zespołu należy pamiętać że:

- właściwa wielkość, struktura i skład ZRIBI powinny odpowiadać rozmiarowi i strukturze organizacji;

- jakkolwiek ZRIBI może stanowić wydzielony zespół lub jednostkę organizacyjną, to jego członkowie mogą mieć także i inne obowiązki;

- w wielu przypadkach ZRIBI jest zespołem zadaniowym, zbierającym się na wezwanie, kierowanym przez osobę z najwyższego kierownictwa, która w razie potrzeby będzie wspierana przez specjalistów od obszarów wiedzy powiązanych z typem incydentu;

- w zależności od wielkości organizacji jedna osoba może spełniać więcej niż jedną rolę w ZRIBI.

Członkami ZRIBI mogą, a nawet powinny być osoby pracujące w różnych jednostkach organizacyjnych. Muszą one być łatwo osiągalne, dlatego też ich dane kontaktowe (oraz osób ich zastępujących) powinny być łatwo dostępne w organizacji. np. zawarte w dokumentacji reagowania na incydent, procedurach i formularzach.

Osoba kierująca pracami ZRIBI (zwykle jest to kierownik ZRIBI) powinna:

- mieć upoważnienie (pełnomocnictwo) do podejmowania natychmiastowych decyzji, dotyczących postępowania z incydentami;

- mieć specjalną, oddzielną od codziennej (tzw. biznesowej), drogę kontaktu z najwyższym kierownictwem;

- upewnić się, że wszyscy członkowie ZRIBI są wystarczająco kompetentni, a ich wiedza i umiejętności są stale aktualizowane i rozwijane;

- uczynić odpowiedzialną za wyjaśnianie każdego incydentu najbardziej właściwą (ze względu na wiedzę, umiejętności i doświadczenie) osobę w ZRIBI.

Powiązania zarządzania incydentami z innymi obszarami zarządzania. Kierownik i członkowie ZRIBI muszą mieć odpowiednie pełnomocnictwo, aby móc reagować na incydenty. Jednak działania, które mogą przynieść niepożądane efekty dla całej organizacji (finansowe lub związane z wizerunkiem), powinny być uzgadniane z najwyższym kierownictwem. Z tego powodu istotne jest wskazanie w dokumentacji reagowania na incydent przełożonego, którego kierownik ZRIBI informuje o poważnych incydentach.

Ważną sprawą jest również współpraca z mediami. Procedury określające i precyzujące odpowiedzialność za współpracę z mediami powinny być zaakceptowane przez najwyższe kierownictwo i udokumentowane. Powinny one precyzować:

- kto w organizacji odpowiada na pytania mediów,

- w jaki sposób osoba lub jednostka organizacyjna odpowiedzialna w organizacji za współpracę z mediami współpracuje ze ZRIBI.

Powiązanie z organizacjami zewnętrznymi. Efektywne i skuteczne wyjaśnianie oraz naprawianie sytuacji powstałych w wyniku incydentu wymaga nawiązywania odpowiednich kontaktów i współpracy między ZRIBI a:

- współpracownikami z organizacji zewnętrznych i zleceniobiorcami,

- zespołami ZRIBI innych organizacji lub organizacjami zajmującymi się tematyką incydentów (np. CERT, FIRST),

- organizacjami związanymi z przestrzeganiem prawa (np. policja),

- służbami ratowniczymi (np. straż pożarna, pogotowie ratunkowe),

- organami administracji państwowej i samorządowej,

- mediami (prasa, radio, telewizja),

- partnerami biznesowymi,

- klientami,

- społeczeństwem.

Przygotowanie wsparcia technicznego i organizacyjnego. Duży wpływ na szybkie i efektywne reagowanie na incydenty ma stosowanie środków technicznych i organizacyjnych, do których można zaliczyć:

- dostęp do aktualnego rejestru aktywów organizacji oraz do informacji na temat ich wpływu na funkcje biznesowe;

- dostęp do dokumentacji opisującej strategię oraz planów zapewniania ciągłości działania;

- udokumentowane i opublikowane procesy komunikowania się;

- wykorzystanie bazy zdarzeń/incydentów oraz środków technicznych w celu szybkiego wypełniania i aktualizacji bazy, analizowania zawartych tam informacji i podjęcia postępowania reakcji na incydent;

- zapewnienie ciągłości działania bazy zdarzeń/incydentów.

Środki techniczne wykorzystywane w celu szybkiego wypełniania bazy zdarzeń/incydentów, analizowania zawartych w niej informacji oraz ułatwienia reagowania na incydenty powinny zapewniać:

- szybkie pozyskiwanie informacji niezbędnych do zgłaszania zdarzeń i incydentów;

- powiadamianie wybranych wcześniej pracowników lub organizacji zewnętrznej za pomocą określonych środków (np. poczta elektroniczna, faks, telefon) wymagających zarządzania rzetelną bazą kontaktów oraz ułatwiających komunikację i transmisję informacji do poszczególnych osób w bezpieczny sposób;

- podejmowanie środków ostrożności proporcjonalnych do oszacowanego ryzyka, tak aby zagwarantować, że komunikacja elektroniczna nie będzie mogła być podsłuchana, nawet podczas ataku na system;

- zapewnienie gromadzenia informacji o systemach oraz przetwarzanych przez nie danych;

- udzielanie odpowiedzi na pytania o odpowiedniość zastosowanych mechanizmów kryptograficznej kontroli integralności oraz o to, czy i jakie części systemu oraz jakie dane zostały zmienione;

- zachowywanie, archiwizację i zabezpieczanie zebranych informacji (np. przez dodanie podpisów cyfrowych do dzienników zdarzeń (tzw. logów) oraz śladów i dowodów przed ich składowaniem na nośnikach jednokrotnego zapisu − CD/DVD− ROM);

- możliwość sporządzenia wydruku newralgicznych danych, włączając te, które pokazują rozwój incydentu oraz kroki procesu reakcji na incydent;

- odtworzenie i przywrócenie (w powiązaniu z planem zapewniania ciągłości działania) systemu do normalnego stanu pracy przy wykorzystaniu:

- procedur tworzenia kopii zapasowych,

- pewnych kopii zapasowych,

- testowania kopii zapasowych,

- kontroli złośliwego kodu,

- stosowania oryginalnych nośników z systemami i aplikacjami,

- samoinicjujących nośników,

- pewnych i zaktualizowanych poprawek (tzw. łat) systemów i aplikacji.

Wszystkie środki techniczne powinny być starannie dobrane, prawidłowo wdrożone i regularnie testowane (włącznie z testami kopii zapasowych).

Należy zauważyć, że opisane środki techniczne nie obejmują tych, które są wykorzystywane bezpośrednio do wykrywania incydentów oraz automatycznego powiadamiania.

Opracowanie programu uświadamiania i programu szkoleń. Zarządzanie reakcją na incydent jest procesem, który wymaga nie tylko środków technicznych, ale przede wszystkim ludzi. Powinno być ono wspierane przez osoby odpowiednio przeszkolone w zakresie ochrony informacji. Świadomość zadań oraz uczestnictwo w szkoleniach wszystkich pracowników organizacji są bardzo ważne dla odniesienia sukcesu w zarządzaniu incydentami. Z tego powodu zarządzanie reagowaniem na incydenty obejmuje promocję wiedzy o polityce bezpieczeństwa jako części korporacyjnego programu uświadamiającego i szkoleniowego. Program uświadamiający i związane z nim materiały muszą być dostępne dla wszystkich pracowników, włączając w to osoby nowo zatrudnione, współpracowników i zleceniobiorców. Powinien istnieć specjalny program szkoleniowy dla członków ZRIBI, grup wsparcia technicznego oraz dla administratorów systemów i osób związanych z ochroną informacji. Należy pamiętać, że każda z grup zaangażowanych bezpośrednio w zarządzanie reagowaniem na incydenty może wymagać szkoleń na różnym poziomie, w zależności od typu, częstotliwości oraz znaczenia ich powiązania z zarządzaniem reakcją na incydent. Szkolenia powinny obejmować:

- podstawowe zasady zarządzania reakcją na incydent, włącznie z jego zakresem oraz przepływem informacji na temat zdarzeń i incydentów,

- sposób opisywania zdarzeń i incydentów,

- zabezpieczenia poufności źródeł informacji,

- schemat poziomu świadczonych usług,

- przypadki, gdy osoby lub komórki organizacyjne będące źródłami informacji o zdarzeniach i incydentach powinny być powiadamiane o rezultatach,

- wyjaśnienie ograniczeń nakładanych przez umowy o zachowaniu poufności,

- kompetencje poszczególnych osób i jednostek organizacyjnych w zakresie zarządzania reakcją na incydenty oraz zasady raportowania o nich,

- informacje o tym, kto i w jaki sposób otrzymuje raporty na temat incydentów.

W niektórych przypadkach może być wymagane, aby w wyraźny sposób zaznaczyć informacje na temat zarządzania incydentami w innych programach szkoleniowych (np. dla kadry zarządzającej lub dotyczących ogólnej tematyki bezpieczeństwa organizacji). Takie podejście może wydatnie przyczynić się do podniesienia efektywności i skuteczności programu szkoleniowego dla poszczególnych grup pracowników.

Przed operacyjnym wykorzystaniem dokumentacji zarządzania reakcją na incydent wszystkie zaangażowane w to osoby muszą poznać procedury wykrywania oraz opisywania zdarzeń i incydentów, a wybrane osoby powinny posiąść dogłębną wiedzę na temat wszystkich związanych z tym procesów. Następstwem powinny być regularne szkolenia, które dodatkowo powinny być wsparte przez szkolenia specjalistyczne oraz ćwiczenia symulujące sytuacje potrzeby wsparcia dla członków ZRIBI, administratorów i pracowników związanych z bezpieczeństwem informacji.

4.3.2. „Stosowanie” − wdrożenie i eksploatacja

Zgodnie z rysunkiem 1.4 i tabelą 4.1 „stosowanie” to faza, która obejmuje wdrożenie systemu zarządzania incydentami i jego eksploatację. W niniejszym podrozdziale zawarto przegląd kluczowych procesów realizowanych w ramach systemu zapewniania bezpieczeństwa informacji, omówiono procesy wykrywania, dokumentowania i zgłaszania zdarzeń naruszania bezpieczeństwa informacji, oceny zdarzenia/incydentu i podejmowania decyzji w przypadku wystąpienia incydentu naruszenia bezpieczeństwa informacji, jak również reagowania na zdarzenia naruszające ochronę informacji, w tym analizę kryminalistyczną.

Do kluczowych działań procesu zapewniania bezpieczeństwa informacji zalicza się:

- wykrywanie i zgłaszanie faktów wystąpienia zdarzeń naruszenia bezpieczeństwa informacji;

- gromadzenie danych o tych zdarzeniach;

- ocenę zdarzenia naruszenia bezpieczeństwa przez ZRIBI, w celu potwierdzenia, że zdarzenie naruszenia bezpieczeństwa informacji jest incydentem; a jeśli jest, to następstwem tego powinno być natychmiastowe rozpoczęcie analizy śladów i dowodów oraz podjęcie działań informowania o zdarzeniu;

- reagowanie na incydenty naruszenia bezpieczeństwa informacji, tj. dokonanie przez ZRIBI przeglądu danych o incydencie w celu określenia, czy przebieg incydentu jest kontrolowany, a jeśli tak, to uruchomienie odpowiednich działań oraz zapewnienie, że wszystkie informacje są przygotowane do przeprowadzenia przeglądu stanu po incydencie; jeśli zaś uznaje się, że incydent nie jest kontrolowany, to uruchomienie działań związanych z zaistniałym kryzysem oraz zaangażowanie do nich odpowiednich pracowników (np. osób odpowiedzialnych za plan ciągłości działania);

- informowanie o incydencie naruszenia bezpieczeństwa informacji, przekazanie wyższemu szczeblowi decyzyjnemu informacji o zdarzeniu naruszenia bezpieczeństwa informacji do dalszej oceny lub podjęcia decyzji, zagwarantowanie, że wszystkie zainteresowane strony, a w szczególności członkowie ZRIBI, właściwie zarejestrowali swoje działania związane ze stwierdzeniem naruszenia bezpieczeństwa informacji w celu ich późniejszej analizy; zapewnienie, że ślady i dowody (szczególnie w formie elektronicznej) są bezpiecznie gromadzone i przechowywane, a zachowanie bezpieczeństwa jest ciągle monitorowane, co ma szczególne znaczenie w przypadku prowadzenia dochodzenia lub wewnętrznego postępowania wyjaśniającego;

- zapewnienie, że kontrola zmian jest prowadzona i obejmuje śledzenie incydentów, aktualizację opisów incydentów, a baza zdarzeń/incydentów jest aktualna;

- komunikację wewnątrz i na zewnątrz organizacji.

Wszystkie zgromadzone informacje, które odnoszą się do zdarzeń i incydentów, powinny być przechowywane w bazie danych zarządzanej przez ZRIBI. Informacje zgłaszane w trakcie wszystkich faz procesu powinny być możliwie jak najbardziej kompletne i aktualne, aby umożliwić właściwą ocenę sytuacji oraz podejmowanie decyzji i działań (rys. 4.1).

Rysunek 4.1. Przepływ informacji w procesie zarządzania incydentami

Źródło: opracowanie własne na podstawie: [ISO/IEC TR 18044:2004].

Cele kolejnych faz procesu, po wykryciu, opisaniu i zgłoszeniu zdarzenia są następujące:

- wyznaczenie osób do oceniania sytuacji, podejmowania decyzji i zarządzania incydentami;

- dostarczenie każdej zaangażowanej w ten proces osobie opisu zadań dotyczących przeglądania i dokonywania poprawek w przekazanym raporcie, szacowania strat i powiadamiania właściwego personelu;

- wykorzystanie wytycznych opisujących sposób przygotowywania szczegółowej dokumentacji dotyczącej zdarzeń, a jeśli zdarzenie zostanie zakwalifikowane jako incydent, to także dokumentacji dotyczącej podjęcia kolejnych działań i aktualizacji bazy zdarzeń/incydentów.

Wymienione wskazówki mogą dotyczyć:

- wykrywania, opisywania i zgłaszania incydentów;

- oceniania i podejmowania decyzji co do tego, czy zdarzenie może być sklasyfikowane jako incydent;

- reagowania na incydenty, czyli:

- natychmiastowych reakcji;

- dokonywania przeglądu w celu określenia, czy przebieg incydentu jest kontrolowany;

- późniejszych reakcji polegających na:

- działaniach kryzysowych,

- analizie śladów i dowodów,

- powiadamianiu zainteresowanych,

- wytycznych co do dalszej eksploatacji,

- rejestrowania działań.

Wykrywanie i zgłaszanie występowania zdarzeń naruszania bezpieczeństwa informacji. Zdarzenia mogą być wykrywane przez osoby, które zauważą coś niepokojącego, lub przez urządzenia albo środki techniczne (np. detektory wykrywania pożaru/dymu, systemy antywłamaniowe, zapory ogniowe, systemy IDS, narzędzia antywirusowe), które przesyłają sygnały alarmowe.

Niezależnie od źródła wykrycia zdarzenia naruszenia bezpieczeństwa informacji każda osoba powiadomiona o tym fakcie lub taka, która sama zauważyła coś niezwykłego, jest odpowiedzialna za zainicjowanie dalszego postępowania i za poinformowanie innych. Istotne jest, aby cały personel był świadomy możliwości zaistnienia naruszenia bezpieczeństwa informacji oraz miał dostęp do wytycznych opisujących zgłaszanie różnych typów zdarzeń.

Osoba zgłaszająca zdarzenie powinna wypełnić odpowiedni formularz, podając jak najwięcej dostępnych informacji. Istotne są nie tylko dokładność i kompletność informacji, niekiedy przede wszystkim czas.

Kiedy zawodzą domyślne drogi zgłaszania incydentów (np. poczta elektroniczna, strony WWW), a szczególnie w sytuacji kiedy system jest zaatakowany, a formularze zgłoszenia mogą być przeglądane i czytane przez osoby nieuprawnione, należy wykorzystać zapasowe środki powiadamiania.

W wielu przypadkach, zanim zdarzenie zostanie zgłoszone w celu podjęcia działań przez grupę wsparcia technicznego, może ono być rozwiązane przez użytkowników, jeśli są odpowiednio przygotowani do takiej sytuacji.

Należy zagwarantować, aby zdarzenia związane z naruszaniem bezpieczeństwa informacji oraz wady systemów informacyjnych były zgłaszane w sposób umożliwiający szybkie podjęcie działań korygujących. Powinny zostać wdrożone formalne procedury zgłaszania zdarzeń naruszenia bezpieczeństwa. Wszyscy pracownicy, a także wykonawcy i użytkownicy systemów informacyjnych reprezentujący stronę trzecią powinni być uświadomieni w zakresie procedur zgłaszania różnych typów zdarzeń oraz słabości, które mogą mieć wpływ na bezpieczeństwo aktywów organizacji. Zaleca się ponadto, aby byli zobowiązani do niezwłocznego zgłaszania w wyznaczonym, zawsze dostępnym punkcie kontaktowym wszystkich zdarzeń związanych z bezpieczeństwem informacji oraz podatnościami zasobów na naruszenia tego bezpieczeństwa.

Procedury zgłaszania powinny określać:

- proces zwrotnego informowania zgłaszających zdarzenia naruszenia bezpieczeństwa o wynikach postępowania ze zdarzeniem, a co najmniej zgłoszeniem;

- formularze zgłaszania zdarzeń naruszania bezpieczeństwa informacji, pomagające zgłaszającym utrwalić wszystkie niezbędne fakty;

- poprawne zachowanie w przypadku takich zdarzeń obejmujące:

- obowiązek natychmiastowego zanotowania wszystkich ważnych szczegółów (np. typu niezgodności lub naruszenia, błędu działania, wiadomości z ekranu, dziwnego zachowania);

- zakaz podejmowania jakichkolwiek własnych działań i natychmiastowe zgłoszenie incydentu do punktu kontaktowego;

- elementy procesu dyscyplinarnego postępowania z pracownikami, wykonawcami i użytkownikami reprezentującymi stronę trzecią, którzy naruszają bezpieczeństwo.

W środowiskach, gdzie występuje poważne ryzyko wrogiej ingerencji, można wprowadzić specjalny rodzaj sygnału alarmowego „działanie pod przymusem” (jest to metoda tajnego informowania, że podejmowane działania są wykonywane „pod przymusem” np. terrorysty). Zaleca się, aby procedury obsługi zgłoszenia alarmu pod przymusem odzwierciedlały wskazywaną sytuację wysokiego ryzyka.

Przy zachowaniu należytej staranności w odniesieniu do poufności, analizy incydentów związanych z naruszeniem bezpieczeństwa informacji mogą być wykorzystane do podnoszenia świadomości użytkowników jako przykład tego, co może się zdarzyć, jak reagować na takie incydenty oraz jak ich unikać w przyszłości. Aby móc poprawnie postępować ze zdarzeniami związanymi z bezpieczeństwem informacji oraz incydentami naruszania tego bezpieczeństwa, niezbędnym może okazać się gromadzenie materiału dowodowego tak szybko, jak to możliwe.

Awarie lub inne nienormalne zachowania systemu informacyjnego mogą wskazywać na atak lub rzeczywiste naruszenie bezpieczeństwa i należy je zawsze zgłaszać jako zdarzenia związane z bezpieczeństwem informacji.

Wszyscy pracownicy, wykonawcy i użytkownicy reprezentujący stronę trzecią, korzystający z systemów informacyjnych i usług powinni być zobowiązani do zgłaszania zaobserwowanych lub podejrzewanych niedoskonałości rozwiązań zapewniania bezpieczeństwa do kierownictwa albo bezpośrednio do swojego dostawcy usług, tak szybko, jak to możliwe, aby uniknąć incydentów związanych z naruszeniem bezpieczeństwa informacji. Mechanizm zgłaszania powinien być prosty, dostępny i osiągalny.

Nie należy, pod żadnym pozorem, próbować sprawdzać na własną rękę istnienia podejrzewanej słabości. Może to być zinterpretowane jako potencjalne niewłaściwe korzystanie z systemu i może spowodować szkody w systemie informacyjnym lub usłudze oraz pociągnąć za sobą konsekwencje prawne wobec osoby wykonującej takie próby.

Gromadzenie danych o naruszeniach bezpieczeństwa informacji. Jeśli działania podejmowane po wystąpieniu incydentu związanego z bezpieczeństwem informacji obejmują kroki prawne (natury cywilnoprawnej lub karnej), to zaleca się zgromadzenie, zachowanie i przedstawienie materiału dowodowego zgodnie z zasadami obowiązującymi w systemie prawnym. Zaleca się, przy zbieraniu i przedstawianiu materiału dowodowego, opracowanie i stosowanie procedur wewnętrznych na potrzeby postępowania dyscyplinarnego prowadzonego w organizacji.

W ogólnym przypadku zasady związane z materiałem dowodowym dotyczą:

- dopuszczalności materiału dowodowego, tj. czy materiał dowodowy może być wykorzystany w sądzie;

- wagi materiału dowodowego, tj. jego jakości i kompletności.

Dopuszczalność materiału dowodowego jest osiągana, gdy systemy informacyjne organizacji są zgodne z opublikowanymi normami lub ogólnie przyjętymi zasadami tworzenia takiego materiału dowodowego.

Z kolei waga materiału dowodowego jest odpowiednia, gdy zapewniona jest jakość i kompletność zabezpieczeń używanych do ochrony materiału dowodowego (tzw. proces zabezpieczania materiału dowodowego). Mówi się w takim przypadku o utrzymaniu mocnego śladu dowodowego. Na ogół można to uzyskać pod następującymi warunkami:

- dla dokumentów papierowych: oryginał jest bezpiecznie przechowywany wraz z informacją, kto znalazł dokument, gdzie, kiedy i kto był świadkiem tego zdarzenia, a każde śledztwo może wykazać, że oryginał nie został naruszony;

- dla dokumentów na nośnikach komputerowych zaleca się:

- utworzenie obrazu lub kopii (zależnie od stosownych wymagań) wszelkich nośników wymiennych,

- zapisanie informacji znajdujących się na dyskach twardych lub w pamięci komputera, aby zapewnić ich dostępność,

- zachowanie zapisów zdarzeń (tzw. log lub inaczej dziennik zdarzeń) wszelkich działań dokonywanych podczas procesu kopiowania oraz aby proces ten odbywał się w obecności świadków,

- przechowywanie oryginalnego nośnika i dziennika zdarzeń w sposób bezpieczny i nienaruszony (jeśli to niemożliwe, to co najmniej jednego obrazu lustrzanego lub kopii).

Zaleca się:

- przeprowadzanie wszelkich działań śledczych na kopiach materiału dowodowego,

- ochronę integralności wszystkich materiałów dowodowych,

- aby kopiowanie tych materiałów było nadzorowane przez zaufany personel,

- zapisać informację, gdzie i kiedy kopiowanie miało miejsce, kto je wykonał oraz za pomocą jakich narzędzi lub programów.

Gdy incydent związany z naruszeniem bezpieczeństwa informacji jest wykryty po raz pierwszy, może nie być oczywiste, czy sprawa znajdzie finał w sądzie. Z tego powodu istnieje zagrożenie, że potrzebny materiał dowodowy zostanie zniszczony umyślnie lub przypadkowo, zanim zostanie określona rzeczywista waga incydentu. Przed decyzją o podjęciu odpowiednich działań prawnych, zaleca się zaangażowanie prawnika lub policji w celu określenia, jaki materiał dowodowy należy zabezpieczyć.

Materiały dowodowe mogą mieć charakter, który wykracza poza obszar działania i poza kompetencje organizacji. W takich przypadkach należy upewnić się, że organizacja jest uprawniona do zbierania informacji wymaganej jako materiał dowodowy. W celu zwiększenia szansy dopuszczenia materiału dowodowego zaleca się uwzględnienie wymagań uregulowań zewnętrznych wobec organizacji oraz wymagań prawa powszechnego.

Ocena zdarzenia naruszenia bezpieczeństwa informacji. Organizacja powinna zadbać o mechanizmy umożliwiające określanie i monitorowanie rodzajów, rozmiarów i kosztów incydentów związanych z naruszaniem bezpieczeństwem informacji. Zaleca się wykorzystywanie informacji zebranych w trakcie oceny takich incydentów do identyfikowania zdarzeń powtarzających się lub o znacznych konsekwencjach. Ocena incydentów może wskazać potrzebę rozszerzenia istniejących lub wdrożenia dodatkowych zabezpieczeń w celu zmniejszenia w przyszłości częstości występowania naruszeń bezpieczeństwa, rozmiaru szkód i kosztów z nimi związanych. Podobnie, incydenty takie powinny być analizowane w procesie przeglądu polityki bezpieczeństwa (patrz punkt 5.1.5).

Na tym etapie działań bardzo często potrzebne są specjalistyczne kompetencje, które zapewnia często grupa wsparcia technicznego złożona ze specjalistów różnych specjalności. Członek grupy wsparcia technicznego, który otrzymał wypełniony formularz zgłoszenia zdarzenia, powinien zapoznać się z jego treścią i potwierdzić ten fakt, wprowadzić formularz do bazy zdarzeń/incydentów. W dalszej kolejności powinien dokonać oceny w celu określenia, czy zdarzenie można zakwalifikować jako incydent, czy jako fałszywy alarm. Kopię wypełnionego formularza należy przekazać osobie zgłaszającej i jej bezpośredniemu przełożonemu.

Dane, ślady i dowody gromadzone na tym etapie mogą być później wykorzystane w trakcie dochodzenia lub wewnętrznego postępowania wyjaśniającego, wobec tego osoby zobowiązane do gromadzenia informacji i dokonywania oceny powinny być specjalnie przeszkolone w tym zakresie. Niezbędne jest odnotowywanie:

- daty i czasu podjęcia działania,

- ustaleń, działań i ich uzasadnienia,

- lokalizacji oraz sposobu przechowywania i przeprowadzania weryfikacji śladów i dowodów,

- pozostałych informacji związanych z bezpiecznym przechowywaniem i dostępem do zgromadzonych materiałów.

Jeśli zdarzenie jest określone jako prawdopodobny incydent, a członek grupy wsparcia technicznego ma odpowiednią wiedzę i kompetencje, wtedy może przeprowadzić dalszą ocenę. Rezultatem może być podjęcie działań zapobiegawczych, takich jak wskazanie potrzeby dodatkowych zabezpieczeń i polecenie ich przygotowania.

W przypadku zajścia zdarzeń identyfikowanych jako poważne incydenty powinien zostać poinformowany kierownik ZRIBI, natomiast w sytuacjach kryzysowych (w celu uruchomienia planu ciągłości działania) również najwyższe kierownictwo i kierownik zarządzania ciągłością działania.

Członek grupy wsparcia technicznego powinien zawrzeć w formularzu zgłoszenia zdarzenia lub incydentu jak najwięcej informacji. Oprócz części opisowej formularz powinien zawierać następujące informacje:

- czego dotyczy incydent,

- w jaki sposób został spowodowany (przez co lub przez kogo),

- na co miał lub może mieć wpływ,

- rzeczywiste lub potencjalne skutki dla procesów biznesowych organizacji,

- wskazanie, z wykorzystaniem przyjętej w organizacji klasyfikacji (skali ważności), czy incydent jest poważny, czy nie,

- w jaki sposób postępowano z incydentami do tej pory.

Przy określaniu potencjalnego lub rzeczywistego negatywnego wpływu incydentu na procesy biznesowe organizacji w związku z naruszeniem bezpieczeństwa informacji, pierwszym krokiem jest rozważenie, jakie mogą z tego wyniknąć konsekwencje. Mogą to być np.:

- straty finansowe,

- przerwa w świadczeniu usług,

- pozbawienie korzyści handlowych lub ekonomicznych,

- nieuprawniony dostęp do danych osobowych,

- naruszenie zobowiązań prawnych lub kontraktowych,

- zakłócenia operacji biznesowych lub procesów zarządzania,

- utrata wizerunku, reputacji i zaufania klientów.

Wypełniony formularz powinien być przekazany do ZRIBI w celu przejrzenia i wprowadzenia do bazy zdarzeń/incydentów. Jeśli jest prawdopodobne, że postępowanie wyjaśniające potrwa dłużej, powinien zostać przygotowany raport.

Należy podkreślić, że członek grupy wsparcia technicznego dokonujący oceny, bazując na wytycznych pochodzących z dokumentacji postępowania z incydentami, powinien być świadomy:

- tego, kiedy należy przekazywać informacje dalej i do kogo,

- tego, że we wszystkich działaniach podejmowanych przez grupę wsparcia technicznego należy kierować się udokumentowanymi procedurami dotyczącymi kontroli zmian.

Drugi etap oceny oraz potwierdzenie bądź nie, że zdarzenie jest incydentem, leży w kompetencji ZRIBI. Osoba przyjmująca zgłoszenie w ZRIBI powinna:

- potwierdzić przyjęcie formularza zgłoszenia incydentu, wypełnionego przez grupę wsparcia technicznego,

- wprowadzić informacje z formularza do bazy zdarzeń/incydentów,

- zwrócić się o niezbędne wyjaśnienia do grupy wsparcia technicznego,

- zebrać inne wymagane lub możliwe do osiągnięcia informacje od grupy wsparcia technicznego, osoby, która wypełniła formularz zgłoszenia lub z innych źródeł.

Jeśli istnieje niepewność, co do autentyczności zdarzenia lub kompletności informacji, to członek ZRIBI powinien dokonać oceny w celu określenia, czy incydent jest rzeczywisty, czy też jest fałszywym alarmem. Jeśli jest fałszywym alarmem, to zgłoszenie zdarzenia powinno być uzupełnione, dodane do bazy zdarzeń/incydentów i przekazane do kierownictwa ZRIBI. Kopię zgłoszenia należy przesłać do grupy wsparcia technicznego, osoby dokonującej zgłoszenia i jej bezpośredniego przełożonego.

Jeśli incydent jest rzeczywisty, wtedy członek ZRIBI (angażując w razie potrzeby innych członków ZRIBI) powinien dokonać dalszej oceny, której celem jest potwierdzenie, najszybciej jak to możliwe, tego:

- czym jest incydent, jak został spowodowany (przez co lub przez kogo), na co ma lub może mieć wpływ, jaki ma lub może mieć wpływ na procesy biznesowe organizacji, a także wskazanie (wykorzystując zdefiniowaną skalę ważności), czy incydent jest poważny;

- w przypadku umyślnych ataków fizycznych spowodowanych przez ludzi, których celem jest system informatyczny, usługa, urządzenia sieciowe lub lokalizacja − jakie są bezpośrednie i pośrednie skutki zniszczeń fizycznych;

- dla incydentów niespowodowanych bezpośrednio przez działania ludzi, jakie są bezpośrednie i pośrednie skutki (np. czy dostęp fizyczny jest spowodowany pożarem, czy system informatyczny jest podatny z powodu niewłaściwego działania oprogramowania lub kanału komunikacyjnego);

- w jaki sposób postępowano z incydentem do tej pory oraz jak postępowano z podobnymi incydentami w przeszłości.

Przeglądając potencjalne lub faktyczne niepożądane skutki incydentu dla procesów biznesowych organizacji w zakresie naruszenia bezpieczeństwa informacji, niezbędne jest potwierdzenie, jakie są z tym związane konsekwencje.

Reagowanie na incydenty naruszenia bezpieczeństwa informacji. Należy zagwarantować stosowanie spójnego i skutecznego podejścia do zarządzania incydentami związanymi z naruszaniem bezpieczeństwa informacji. Powinno to opierać się na wprowadzeniu uprawnień i odpowiedzialności za rozwiązania bezpieczeństwa oraz procedur skutecznej obsługi zdarzeń związanych z naruszaniem bezpieczeństwa informacji jako reakcji na ich zgłoszenia. Zaleca się też wdrożenie zasad ciągłego doskonalenia w zakresie reagowania, monitorowania, oceny i całościowego zarządzania takimi incydentami.

Wszędzie tam, gdzie jest to wymagane, zaleca się gromadzenie dowodów w celu zapewnienia zgodności z przepisami prawa.

Zaleca się wprowadzenie odpowiedzialności kierownictwa oraz procedur zapewniających szybką, skuteczną i uporządkowaną reakcję na incydenty związane z naruszaniem bezpieczeństwa informacji. Oprócz zgłaszania zdarzeń z tym związanych oraz słabości, zaleca się wykorzystywanie monitorowania systemów alarmowania do wykrywania incydentów związanych z naruszaniem bezpieczeństwa informacji. W procesie zarządzania takimi incydentami jest wskazane:

- ustanowienie procedur obsługi różnych typów incydentów związanych z naruszeniem bezpieczeństwa informacji, łącznie z:

- awariami systemów informacyjnych i utratą usługi,

- kodem złośliwym,

- odmową usługi,

- błędami wynikającymi z niekompletnych lub niewłaściwych danych biznesowych,

- naruszeniem poufności i integralności,

- niewłaściwym użyciem systemów informacyjnych;

- dodatkowo, w odniesieniu do zwykłych planów ciągłości działania, zaleca się, aby procedury obejmowały:

- analizę i identyfikację przyczyny incydentu,

- ograniczanie zasięgu naruszenia,

- jeśli to potrzebne, planowanie i wdrażanie działań naprawczych w celu uniknięcia ponownego wystąpienia incydentu,

- komunikację z podmiotami dotkniętymi incydentem i zaangażowanymi w jego usunięcie,

- raportowanie działań do odpowiednich osób;

- jeśli zachodzi taka potrzeba, to zaleca się gromadzenie i zabezpieczanie śladów audytowych lub podobnych dowodów w celu:

- wewnętrznej analizy problemu,

- wykorzystania w postępowaniu dowodowym w związku z:

- potencjalnym naruszeniem wymagań kontraktowych lub regulacji wewnętrznych,

- prowadzeniem postępowania cywilnego lub kryminalnego, np. na podstawie przepisów prawa odnoszących się do przestępstw związanych z niewłaściwym użyciem komputera lub ochrony danych osobowych;

- negocjacji rekompensat ze strony dostawców oprogramowania lub usług;

- staranne i formalne nadzorowanie działań odtwarzających (po naruszeniu bezpieczeństwa) oraz naprawczych (po awarii systemu); ponadto zaleca się, aby procedury dawały pewność, że:

- tylko jednoznacznie wskazani (uprawnieni) pracownicy mają dostęp do działających systemów i rzeczywistych danych (patrz także punkt 5.8.2 w zakresie dostępu zewnętrznego),

- wszystkie podejmowane działania awaryjne są szczegółowo dokumentowane,

- działania awaryjne są zgłaszane kierownictwu i sprawnie przeglądane,

- integralność systemów biznesowych i zabezpieczeń jest potwierdzana z minimalnym opóźnieniem.

Zaleca się zapewnienie, że cele zarządzania incydentami związanymi z bezpieczeństwem informacji są uzgodnione z kierownictwem oraz że osoby odpowiedzialne za zarządzanie incydentami związanymi z naruszaniem bezpieczeństwa informacji rozumieją priorytety organizacji związane z obsługą takich incydentów.

Incydenty związane z naruszaniem bezpieczeństwa informacji mogą wykraczać poza granice organizacji lub kraju. Obsługa takich incydentów zwiększa potrzebę koordynacji i wymiany informacji na ich temat z organizacjami zewnętrznymi.

Wybór właściwego postępowania. W większości przypadków kolejną czynnością członka ZRIBI jest identyfikacja działania, które należy podjąć jak najszybciej w celu zajęcia się incydentem, zapisania szczegółów na formularzu zgłoszenia i w bazie zdarzeń/incydentów oraz powiadomienie o wszystkim właściwych osób lub grup. Może to skutkować zastosowaniem awaryjnych zabezpieczeń (np. wyłączeniem zaatakowanego systemu) lub zidentyfikowaniem innych stałych zabezpieczeń oraz powiadomieniem o działaniach właściwych osób lub grup. Jeśli nie zostało to jeszcze zrobione, to incydent może być sklasyfikowany przy użyciu zdefiniowanej wcześniej skali ważności i − jeśli jest wystarczająco poważny − należy poinformować o tym najwyższe kierownictwo. W przypadku sytuacji kryzysowej, należy powiadomić osobę odpowiedzialną za plan ciągłości działania (w celu ewentualnego uruchomienia tego planu), kierownika ZRIBI i najwyższe kierownictwo.

Przykładowym działaniem, które w przypadku umyślnych ataków na system należy natychmiast podjąć, może być pozostawienie podłączenia do Internetu lub innej sieci w celu:

- umożliwienia krytycznym aplikacjom biznesowym poprawnego funkcjonowania,

- zebrania jak największej liczby informacji o atakującym, tak aby nie zorientował się, że jest nadzorowany.

Jednak, podejmując taką decyzję, należy brać pod uwagę, że:

- atakujący może zdawać sobie sprawę, że jest obserwowany, i może podjąć działania, które spowodują dalsze zniszczenia systemu i przetwarzanych danych;

- atakujący może zniszczyć informacje użyteczne do śledzenia jego działań.

Jeśli tylko taka decyzja zostanie podjęta, to musi być zapewniona techniczna możliwość szybkiego i pewnego odcięcia lub wyłączenia zaatakowanego systemu. Istotne jest stosowanie odpowiedniej metody uwierzytelniania, tak aby nieupoważnione osoby nie mogły podjąć takiej decyzji.

W dalszej kolejności należy wziąć pod uwagę, że zapobieganie ponownemu wystąpieniu incydentu ma zwykle wysoki priorytet i może w efekcie doprowadzić do wniosku, że atakujący wyeksponował słabość, która powinna być usunięta lub skorygowana, a korzyści osiągnięte w wyniku śledzenia go nie uzasadniają wysiłku w to włożonego, szczególnie w przypadku kiedy atakujący nie jest złośliwy i spowodował małe szkody lub nie spowodował żadnych.

W odniesieniu do incydentów, które są spowodowane przez coś innego niż atak umyślny, należy zidentyfikować ich źródło. W trakcie wdrażania zabezpieczeń może się okazać, że konieczne jest wyłączenie systemu lub wyizolowanie odpowiednich jego części, a następnie ich wyłączenie (za wcześniejszą zgodą osób odpowiedzialnych za systemy informatyczne i funkcje biznesowe). Może to zająć dużo czasu, jeśli podatność ma istotne znaczenie dla budowy systemu lub jest to podatność krytyczna. Inną reakcją może być uruchomienie mechanizmów śledczych.

Dane, co do których istnieje prawdopodobieństwo, że w wyniku incydentu mogły zostać naruszone, powinny być porównane z danymi przechowywanymi na kopiach zapasowych w celu wykrycia nielegalnych operacji modyfikacji, usunięcia lub wstawienia. Warto także rozważyć sprawdzenie integralności logów, którymi atakujący mógł manipulować, aby ukryć ślady ataku.

Informowanie o incydencie naruszenia bezpieczeństwa informacji, dalsze działania. W kolejnym kroku członek ZRIBI powinien szczegółowo uzupełnić zgłoszenie incydentu, uzupełnić bazę incydentów, powiadomić kierownika ZRIBI oraz inne osoby (jeśli uzna to za niezbędne). Taka aktualizacja powinna polegać na zweryfikowaniu i ewentualnym skorygowaniu opisu tego:

- czym jest incydent,

- w jaki sposób został spowodowany (przez co lub przez kogo),

- na co ma lub może mieć wpływ,

- jaki ma lub może mieć wpływ na procesy biznesowe organizacji,

- jak zmienia się ocena wagi incydentu (wykorzystując zdefiniowaną skalę ważności),

- w jaki sposób postępowano z incydentem do tej pory oraz jak postępowano z podobnym incydentem w przeszłości.

Po wyjaśnieniu incydentu trzeba sporządzić raport zawierający szczegóły dotyczące zastosowanych zabezpieczeń oraz wyciągniętych wniosków. Należy dodać go do bazy zdarzeń/incydentów, powiadomić kierownika ZRIBI oraz inne osoby (jeśli to niezbędne).

Za wszystkie zgromadzone do tej pory informacje odnoszące się do incydentu (w tym zapewnienie bezpiecznego ich zachowania do dalszej analizy oraz do prowadzenia dochodzenia) odpowiada ZRIBI. Oznacza to, że np. dla incydentu związanego z systemami informatycznymi, już po wstępnym jego wykryciu wszystkie łatwo ulotne dane powinny być zebrane zanim zaatakowany system zostanie wyłączony.

Dane do zebrania to zawartość pamięci RAM, pamięci cache, rejestrów oraz szczegóły o wszystkich pracujących procesach. Przede wszystkim w zależności od natury incydentu:

- powinna być wykonana pełna kopia zaatakowanego systemu (w tym kopia zapasowa dzienników zdarzeń i wszystkich istotnych plików);

- powinny być gromadzone i przeglądane dzienniki zdarzeń ze współpracujących systemów;

- wszystkie informacje powinny być przechowywane w bezpieczny sposób i na nośnikach jednokrotnego zapisu;

- przynajmniej dwie osoby powinny być obecne w trakcie wykonywania kopii zapasowych dla organów wymiaru sprawiedliwości, aby zapewnić i zaświadczyć, że wszystkie działania zostały przeprowadzone zgodnie z odpowiednimi przepisami i regulacjami, a w każdym razie poświadczyć, jak zostały przeprowadzone;

- specyfikacje i opisy narzędzi lub poleceń używanych do wykonania kopii zapasowych dla organów wymiaru sprawiedliwości powinny być udokumentowane i przekazane wraz z oryginalnymi nośnikami.

Członek ZRIBI jest także odpowiedzialny za ułatwienie przywrócenia zaatakowanego systemu do bezpiecznego stanu operacyjnego oraz, jeśli to możliwe na tym etapie, aby nie był on więcej podatny na naruszenie jego ochrony w podobny sposób, jak to już miało miejsce.

Jeśli jest prawdopodobne, że postępowanie wyjaśniające zajmie więcej czasu, niż zakładają wytyczne postępowania, należy przygotować wewnętrzny raport. Członek ZRIBI, który ocenia incydent − bazując na wytycznych − powinien mieć na uwadze, że:

- w określonym momencie może stać się konieczne przekazanie informacji o zdarzeniu do przełożonych lub służb wyższego poziomu reagowania,

- we wszystkich działaniach prowadzonych przez ZRIBI należy przestrzegać procedur związanych z zarządzaniem zmianami.

Kiedy występuje problem (lub nawet zachodzi podejrzenie co do jego wystąpienia) z podstawowymi środkami komunikacji (np. z pocztą elektroniczną), np. z uwagi na to, że i te środki są celem ataku, a naruszenie bezpieczeństwa jest poważne, to wtedy informacje zwrotne o incydencie powinny być przekazywane do odpowiednich osób osobiście bądź za pomocą telefonu lub wiadomości tekstowych.

Jeśli wydaje się to konieczne, to kierownik ZRIBI, w porozumieniu z osobą odpowiedzialną za bezpieczeństwo informacji w organizacji i z właściwą osobą z najwyższego kierownictwa, powinien skomunikować się ze wszystkimi właściwymi osobami i zespołami wewnątrz organizacji lub organizacjami zewnętrznymi.

Aby zapewnić, że łączność będzie nawiązana skutecznie i sprawnie, niezbędne jest wcześniejsze zaplanowanie i ustanowienie bezpiecznej metody komunikacji, która nie zależy od systemu, na który może mieć wpływ incydent. Podobnie konieczne jest wskazanie zawczasu dublerów osób wyznaczonych do reagowania na incydenty i sytuacje kryzysowe.

Zapewnienie, że kontrola zmian i incydentów jest prowadzona. Po podjęciu przez członka ZRIBI natychmiastowej reakcji oraz działań związanych z analizą śladów i dowodów, a także z nawiązaniem komunikacji, należy szybko stwierdzić, czy przebieg incydentu jest kontrolowany.

Jeżeli to konieczne, to członek ZRIBI może się konsultować z innymi członkami (w tym kierownikiem) ZRIBI, a także z innymi osobami lub grupami. Jeżeli zostanie potwierdzone, że przebieg incydentu jest właściwie kontrolowany, wtedy członek ZRIBI powinien zainicjować wszystkie wymagane w dalszej kolejności działania, analizę śladów i dowodów oraz informowanie zainteresowanych stron, aby doprowadzić do wyjaśnienia incydentu oraz odtworzenia lub przywrócenia systemu do stanu normalnego działania. Jeżeli potwierdzono natomiast, że przebieg incydentu nie jest dostatecznie kontrolowany, wtedy członek ZRIBI musi zainicjować działania kryzysowe.

Po stwierdzeniu, że przebieg incydentu jest kontrolowany i nie wymaga podjęcia działań kryzysowych, członek ZRIBI powinien określić, czy i ewentualnie jakie dalsze działania są wymagane, aby skutecznie wyjaśniać incydent. Powinien zapisać szczegóły w formularzu zgłoszenia incydentu, w bazie zdarzeń/incydentów oraz powiadomić osoby odpowiedzialne za podjęcie stosownych działań.

Celem podjęcia niektórych działań będzie uniknięcie lub zmniejszenie prawdopodobieństwa wystąpienia takiego samego lub podobnego incydentu w przyszłości. Na przykład:

- trzeba niezwłocznie skontaktować się z dostawcą sprzętu/oprogramowania, jeśli stwierdzono, że powodem incydentu był błąd tego sprzętu/oprogramowania, a naprawa we własnym zakresie nie jest możliwa;

- system informatyczny powinien być niezwłocznie uaktualniony, jeśli powodem incydentu była znana już jego podatność na dany rodzaj naruszenia bezpieczeństwa;

- może być potrzebna zmiana konfiguracji sprzętu lub oprogramowania służąca podniesieniu odporności na naruszenia bezpieczeństwa;

- warto dokonać zmiany haseł lub zablokować nieużywane/niepotrzebne usługi.

Inny obszar działań może być związany z monitorowaniem systemu. Następstwem oceny incydentu może być potrzeba stosowania dodatkowych zabezpieczeń monitorowania w celu lepszego wykrywania nieoczekiwanych lub podejrzanych zdarzeń, które mogą być symptomem dalszych incydentów. W rezultacie takiej obserwacji mogą być ujawniane symptomy poważnych incydentów oraz wskazywane inne systemy narażone na to samo naruszenie bezpieczeństwa.

Konieczne może być także uruchomienie specjalnych działań, np. opisanych w dokumentacji planu ciągłości działania. Zaliczają się do nich działania dotyczące wszystkich aspektów biznesowych, nie tylko bezpośrednio związanych z systemami informacyjnymi, ale również z zarządzaniem kluczowymi funkcjami biznesowymi i procesem odtwarzania.

Na koniec odtwarza się lub przywraca do stanu normalnego działania systemy dotknięe incydentem naruszenia bezpieczeństwa. Można to osiągnąć przez dokonywanie poprawek w elementach rozwiązań, które stanowiły o ujawnionych podatnościach, lub przez zablokowanie/odłączenie elementu, który był przedmiotem ataku i którego ochrona została naruszona.

Jeśli z powodu zniszczenia w trakcie incydentu dzienników zdarzeń całkowity jego zasięg nie jest znany, wtedy przed uruchomieniem planu ciągłości działania może być konieczna całkowita przebudowa systemu.

Jeśli w ramach oceny członek ZRIBI stwierdzi, że przebieg incydentu nie jest kontrolowany, należy postępować, jak w przypadku sytuacji kryzysowej, wykorzystując przygotowany wcześniej plan.

Najlepsze opcje postępowania ze wszystkimi możliwymi typami incydentów, mogącymi mieć wpływ na dostępność oraz integralność systemów informacyjnych, powinny być zidentyfikowane w strategii zapewniania ciągłości działania organizacji. Opcje te powinny być bezpośrednio zależne od priorytetów działalności biznesowej, co powinny wyrażać z góry wyznaczone limity czasu na odtworzenie tej działalności. Limity te określają maksymalny akceptowalny czas awarii lub niedostępności systemów informatycznych, kanałów komunikacyjnych, personelu lub pomieszczeń.

W ramach wytycznych dla poszczególnych opcji postępowania powinny być wskazane:

- środki zaradcze wspierające ciągłość działania,

- struktura organizacyjna oraz zakresy uprawnień i odpowiedzialności w kwestii zarządzania zapewnianiem ciągłości działania,

- struktura i zarys zawartości planu zapewniania ciągłości działania.

Plan ciągłości działania i przetestowane zabezpieczenia, wdrożone w celu wspierania tego planu, stanowią podstawy zasad postępowania w przypadku większości działań kryzysowych.

Inne rodzaje rozwiązań kryzysowych to:

- system gaszenia pożarów i procedury ewakuacji,

- system zapobiegania powodziom i procedury ewakuacji,

- procedury ewakuacji związane z alarmami bombowymi,

- systemy wykrywania nadużyć,

- systemy wykrywania ataków/włamań (np. IDS, systemy antywirusowe itd.).

Analiza śladów i dowodów powinna być dokonana przez ZRIBI, w przypadku gdy zgodnie z wcześniejszą oceną incydentu jest niezbędna przy prowadzeniu dochodzenia lub wewnętrznego postępowania wyjaśniającego. Powinna ona uwzględniać wykorzystanie technik i narzędzi informatycznych, wspieranych przez procedury, tak aby wskazane incydenty zostały zbadane bardziej szczegółowo, niż zostało to zrobione to tej pory.

Rozwiązania służące do prowadzenia analizy śladów i dowodów można podzielić na:

- techniczne,

- proceduralne,

- personalne,

- organizacyjne.

Każda czynność związana z analizą śladów i dowodów powinna być w całości udokumentowana, wliczając w to zdjęcia, raporty analityczne z audytów, logi z odtwarzania danych. Wskazane jest, aby profesjonalizm i wiedza osoby lub osób przeprowadzających analizę była udokumentowana.

Wszystkie zapisy o incydentach i czynnościach analitycznych oraz związane z tym nośniki powinny być przechowywane w bezpiecznym środowisku, tak aby nie mogły być dostępne dla nieupoważnionych osób, zmienione czy zniszczone.

Narzędzia informatyczne do analizy śladów i dowodów powinny być zgodne ze standardami i normami, aby w świetle prawa ich dokładność nie mogła być podważona, a ze względu na zmiany technologiczne powinny być systematycznie uaktualniane.

ZRIBI powinno przygotować warunki, które zagwarantują, że ślady i dowody będą zbierane i opisywane w sposób, który nie pozwoli na ich podważenie. Obecnie analiza śladów i dowodów często obejmuje złożone środowiska sieciowe (włącznie z serwerami plików, wydruków, komunikacyjnymi, pocztowymi, infrastrukturą), jak również zdalny dostęp do zasobów. Dlatego też trzeba skupić uwagę na tym, aby procedury analizy gwarantowały, że ślady i dowody będą zweryfikowane, zabezpieczone przed zmianami lub zniszczeniem oraz sprostają wszelakim wymaganiom prawnym, a sama analiza będzie przeprowadzana na dokładnej kopii oryginalnych śladów i dowodów w celu zapewnienia, że prace analityczne nie wpłyną negatywnie na integralność oryginalnych danych.

Pełny proces analizy śladów i dowodów powinien umożliwiać:

- zapewnienie, że docelowy system jest zabezpieczony w czasie analizy przed uczynieniem go niedostępnym, zmienionym lub doprowadzeniem do tego, że w inny sposób została naruszona jego ochrona;

- zapewnienie, że nie ma wpływu zabezpieczenia śladów i dowodów na jego normalną pracę;

- ustalenie priorytetów śladów i dowodów, tj. przechodzenie od najbardziej do najmniej zmiennych (ulotnych), co w dużym stopniu zależy od natury incydentu;

- identyfikacja w danym systemie wszystkich związanych z incydentem plików, wliczając istniejące, skasowane, zabezpieczone (zaszyfrowane) pliki i hasła;

- odtworzenie jak największej ilości skasowanych plików lub innych danych;

- ujawnienie adresów IP, nazw komputerów, tras routingów w sieci lub informacji związanych z WWW;

- odtworzenie zawartości plików ukrytych lub tymczasowych wykorzystywanych przez aplikacje lub systemy operacyjne;

- dostęp do zawartości plików chronionych lub zaszyfrowanych;

- analizę wszystkich związanych z incydentem danych odnalezionych w specjalnych (zwykle chronionych) obszarach pamięci masowej;

- analizę logów (dzienników zdarzeń);

- analizę czasu dostępu, modyfikacji lub utworzenia plików;

- określenie działań użytkowników lub/i aplikacji w systemie;

- analizę wiadomości pocztowych (nadawca i adresaci);

- sprawdzenie integralności plików w celu wykrycia koni trojańskich oraz plików, które nie zostały zainstalowanie w oryginalnym systemie;

- zapewnienie, że ślady i dowody są obsługiwane i przechowywane w sposób uniemożliwiający ich zniszczenie, uczynienie ich nieużytecznymi lub niedostępnymi dla osób nieupoważnionych;

- wyciąganie wniosków z przebiegu incydentu (powody wystąpienia incydentu, wymagane czynności, ramy czasowe, zestawienia obejmujące listy związanych z incydentem plików i stanowiące załączniki do raportu głównego);

- jeśli to konieczne, zapewnienie wsparcia ekspertów.

Trzeba podkreślić, że gromadzenie śladów i dowodów musi być zawsze zgodne z zasadami i przepisami prawa. Wszystkie możliwe do wykorzystania metody powinny być opisane w procedurach. ZRIBI powinien zapewnić wystarczającą kombinację umiejętności, aby dostarczyć szeroki zakres:

- wiedzy technicznej (włączając w to narzędzia i techniki, które mogą być wykorzystywane przez zaawansowanych atakujących),

- doświadczenia w analizowaniu i prowadzeniu postępowań wyjaśniających (włączając umiejętność zabezpieczania użytecznych śladów i dowodów),

- wiedzy z zakresu prawa i zagadnień regulacyjnych,

- aktualnej wiedzy o trendach co do technik i sposobów naruszania bezpieczeństwa informacji.

Komunikacja wewnątrz i na zewnątrz organizacji. Poinformowanie osób wewnątrz organizacji, osób trzecich, organizacji zewnętrznych (włączając w to media) może być potrzebne czy wręcz niezbędne w wielu sytuacjach, np. kiedy:

- incydent jest potwierdzony jako rzeczywisty,

- jego przebieg jest kontrolowany,

- wystąpiła sytuacja kryzysowa,

- incydent został wyjaśniony i zakończony,

- został wykonany przegląd po incydencie,

- zostały wyciągnięte wnioski z wystąpienia, przebiegu i badania incydentu.

Dobrą praktyką jest przygotowanie wzorów niektórych informacji z wyprzedzeniem, tak aby mogły być one szybko dostosowane do okoliczności konkretnego incydentu i przekazane mediom lub zainteresowanym stronom.

Jeśli jakiekolwiek informacje odnoszące się do incydentu mogą być przekazane mediom, to powinno to być uczynione zgodnie z polityką informacyjną organizacji, a same informacje powinny być przejrzane przez uprawnione osoby w organizacji (najwyższe kierownictwo, osoby odpowiedzialne za kontakty z mediami oraz osoby związane z bezpieczeństwem informacji).

Mogą także zaistnieć okoliczności, w których dalsze postępowanie musi być przekazane do najwyższego kierownictwa, innej grupy w organizacji lub osób/grup poza organizacją. Może być niezbędne podjęcie decyzji o wykonaniu rekomendowanych działań związanych z incydentem lub o wykonaniu dalszej oceny w celu określenia, jakie działania są wymagane. Powinno to mieć miejsce po opisanym procesie oceny lub w trakcie trwania tego procesu, jeśli jakiekolwiek zagadnienie zostaje uznane za zbyt poważne, by je rozwiązywać na dotychczasowym szczeblu organizacji.

Wskazówki dla tych, którzy prawdopodobnie będą w pewnym momencie musieli podejmować decyzje o takim przekazaniu incydentu (np. grupa wsparcia technicznego i członkowie ZRIBI), powinny być dostępne jako wytyczne zarządzania incydentami.

Wszystkie osoby zajmujące się informowaniem o incydencie i zarządzające postępowaniem z incydentem powinny, wykorzystując formularz zgłoszenia incydentu i bazę zdarzeń/incydentów, właściwie zapisywać podejmowane działania w celu ich późniejszej analizy. Zapisy powinny być systematycznie aktualizowane w trakcie całego cyklu życia incydentu − od pierwszego formularza zgłoszenia aż do całkowitego wyjaśnienia i zamknięcia incydentu. Informacje te powinny być przechowywane bezpiecznie z zachowaniem adekwatnego reżimu tworzenia kopii zapasowych.

Dalej, wszystkie zmiany wykonane w ramach śledzenia incydentu oraz aktualizowania formularza zgłoszenia incydentu i bazy zdarzeń/incydentów, powinny być formalnie akceptowane zgodnie z procesem zarządzania zmianami w organizacji.

4.3.3. Przegląd

Po wyjaśnieniu i zamknięciu incydentu należy przeprowadzić dalszą analizę śladów i dowodów w celu wyciągnięcia wniosków oraz zidentyfikowania możliwych usprawnień w całości rozwiązań zapewniania bezpieczeństwa organizacji i w systemie zarządzania incydentami. W ramach tej fazy wykonuje się kolejną analizę prawną, ustala się, jaka nauka płynie z incydentu, określa się potrzebny zakres doskonalenia zabezpieczeń oraz koryguje się zasady postępowania z incydentami.

Dodatkowa analiza śladów i dowodów. Może się zdarzyć, że po wyjaśnieniu incydentu, zachodzi jeszcze potrzeba przeprowadzenia dodatkowej analizy śladów i dowodów. Powinna być ona wykonana przez ZRIBI przy wykorzystaniu tego samego zestawu narzędzi i procedur jak omówione wcześniej w punkcie „Gromadzenie danych o naruszeniach bezpieczeństwa informacji”.

Po zamknięciu incydentu istotne jest, aby szybko wyciągnąć wnioski wynikające z przebiegu obsługi incydentu i wcielić je w życie. Mogą to być:

- nowe lub zmienione wymogi wobec zabezpieczeń; w zależności od wyciągniętych wniosków można do nich zaliczyć potrzebę przeprowadzenia aktualizacji oprogramowania, pozyskania nowych rozwiązań, szkoleń i spotkań uświadamiających dla użytkowników i pozostałego personelu, przejrzenia dotychczasowych i wydania nowych wytycznych i porad dotyczących bezpieczeństwa;

- zmiana schematu zarządzania incydentami i jego procesów, formularzy zgłoszeń zdarzeń i incydentów oraz bazy zdarzeń/incydentów.

Konieczne jest spojrzenie szersze, wykraczające poza pojedynczy incydent. Może ono prowadzić do sprawdzenia wzorców dobrych praktyk, trendów w zakresie stosowania zabezpieczeń oraz możliwości wprowadzenia zmian w systemach informacyjnych lub praktyce korzystania z nich. Zalecane jest rozważenie scenariuszy testów bezpieczeństwa sytuacji kojarzonych z analizowanymi incydentami, a w szczególności oceny podatności posiadanych rozwiązań przy tego typu sytuacjach.

Dane w bazie zdarzeń/incydentów powinny być regularnie przeglądane i analizowane, aby:

- identyfikować trendy w kształtowaniu się incydentów lub ich charakterystyk,

- określić obszary działalności organizacji lub rozwiązania przetwarzania informacji albo rodzaje zabezpieczeń, które są przedmiotem zainteresowania intruzów,

- ustalić, gdzie można podjąć działania prewencyjne, celem zmniejszenia prawdopodobieństwa wystąpienia przyszłych incydentów.

Istotne informacje pozyskane w trakcie trwania incydentu powinny znaleźć odzwierciedlenie w analizie wzorców i trendów, która − bazując na doświadczeniu i udokumentowanej wiedzy − może znacząco przyczynić się do wcześniejszej identyfikacji przyszłych incydentów oraz do przekazywania ostrzeżeń co do tego, jakie z nich mogą jeszcze wystąpić.

Ocena podatności oraz testowanie bezpieczeństwa systemu wykonywane po incydencie nie mogą być ograniczone tylko do systemu dotkniętego przez incydent. Działania te powinny obejmować również systemy współpracujące, co pozwoli przyjrzeć się podatnościom innych systemów wykorzystywanych w trakcie trwania incydentu oraz zbadać, czy ujawniły się nowe podatności.

Istotne jest, aby ocena podatności była wykonywana regularnie, a jej ponowne przeprowadzenie po wystąpieniu incydentu było częścią ciągłego procesu oceny. Podsumowanie analizy incydentów powinno być przedstawiane na każdym spotkaniu forum zarządzania bezpieczeństwem informacji w organizacji oraz innych forach zdefiniowanych w polityce bezpieczeństwa organizacji.

Identyfikacja udoskonaleń bezpieczeństwa. W trakcie dokonywania przeglądu po zamknięciu incydentu mogą zostać zidentyfikowane jako konieczne nowe lub zmienione zabezpieczenia. Może się jednak okazać, iż szybkie wdrożenie rekomendacji oraz związanych z nimi wymaganych zabezpieczeń będzie niemożliwe lub niezwykle trudne z finansowego lub operacyjnego punktu widzenia i w takim przypadku powinno stać się zadaniem długoterminowym dla organizacji.

Po zakończeniu prac nad incydentem kierownik ZRIBI (lub nominowana przez niego osoba) powinien przeanalizować całość podjętych prac oraz ocenić je i, co za tym idzie, określić ilościowo efektywność podjętych działań. Celem takiej analizy jest wskazanie, czy organizacja zarządzania incydentami jest prawidłowa i czy są konieczne jej udoskonalenia.

Ważnym aspektem analizy po incydencie jest wyciągnięcie wniosków pod kątem jakości i kompletności wytycznych zarządzania incydentami. Jeśli incydent jest dostatecznie ważny, to wyznacza się spotkanie wszystkich zainteresowanych stron. Powinno ono mieć miejsce możliwie szybko po zamknięciu incydentu, gdy osobiste wrażenia ze zdarzenia są jeszcze świeże. Kwestie do rozważenia na takim spotkaniu, prowadzące do sformułowania rekomendacji doskonalenia rozwiązań, to:

- czy procedury wymienione w schemacie zarządzania incydentami działały tak, jak zaplanowano;

- czy istnieją jakiekolwiek procedury lub metody, które mogłyby pomóc w wykrywaniu incydentu;

- czy zostały zidentyfikowane procedury lub narzędzia, które zostały wykorzystane w procesie reagowania na incydent;

- czy istniały jakiekolwiek procedury, które pomogły w odtworzeniu systemu po incydencie;

- czy komunikacja między zainteresowanymi stronami była efektywna w trakcie całego procesu (od wykrycia, przez zgłaszanie, raportowanie, aż do całkowitego wyjaśnienia incydentu).

4.3.4. Doskonalenie

Faza ta obejmuje wdrożenie rekomendacji z fazy „przegląd”, czyli ostateczne uwzględnienie wniosków pochodzących z analizy i zarządzania ryzykiem, a dotyczących systemu zasad zarządzania incydentami i bezpieczeństwem informacji. W ramach tych działań przeprowadzane jest doskonalenie analizy ryzyka bezpieczeństwa i zarządzania, wdrożenie usprawnień zabezpieczeń, wdrożenie usprawnień zasad postępowania itp.

W zależności od ważności i skutków incydentu, w ocenie przeglądu wyników analizy i zarządzania ryzykiem naruszenia bezpieczeństwa informacji należy wziąć pod uwagę nowe zagrożenia i podatności. Następstwem aktualizacji może być wprowadzenie nowych lub zmienionych zabezpieczeń.

Poza wdrażaniem rekomendacji wynikających z analizy incydentów, wszystkie systemy organizacji powinny być przedmiotem regularnej oceny, aby systematycznie identyfikować podatności i modelować proces podnoszenia poziomu bezpieczeństwa (tzw. hardening).

Długofalowym celem ZRIBI i osoby zarządzającej bezpieczeństwem informacji w organizacji jest aktualizacja polityk i procedur, tak by wziąć pod uwagę zebrane wiadomości i problemy zidentyfikowane w czasie procesu zarządzania incydentami oraz zapewnić, że zaktualizowane dokumenty zostaną upowszechnione w organizacji. Obszary zidentyfikowane do doskonalenia w wytycznych zarządzania incydentami powinny być analizowane, a uzasadnione zmiany wprowadzane do zaktualizowanej dokumentacji wytycznych. Wszelkie zmiany procesów, procedur i formularzy zgłaszania zdarzeń i incydentów należy dokładnie sprawdzić i przetestować przed wprowadzeniem ich w życie.

W trakcie fazy „przegląd” mogą być zidentyfikowane również inne udoskonalenia, np. zmiany polityk, standardów i procedur bezpieczeństwa informacji, zmiany sprzętu informatycznego lub zmiany konfiguracji oprogramowania.

1  W przyszłości przewiduje się wydanie na podstawie tego raportu standardu [ISO/IEC 27005].

2  Atak – zamierzone działanie zmierzające do naruszenia bezpieczeństwa.