Heading

Szukasz planu reakcji na incydenty na terenie kampusu? Przejdź do Dokumentów Bezpieczeństwa Informacji. Poniższe wytyczne dotyczące planowania reagowania na incydenty odnoszą się do systemów i aplikacji, które muszą być zgodne z polityką Campus MSSEI.

Polityka bezpieczeństwaUC Berkeley nakazuje zgodność z Minimalnym Standardem Bezpieczeństwa Informacji Elektronicznych dla urządzeń obsługujących dane objęte ochroną. Poniższe zalecenia są opcjonalnymi wskazówkami dotyczącymi wymagań w zakresie reagowania na incydenty.

Wymagania

Każdy administrator systemu musi opracować i co najmniej raz w roku poddawać przeglądowi plan reagowania na incydenty na poziomie systemu, który zawiera:

• Nazwiska i informacje kontaktowe lokalnego zespołu reagowania na incydenty, w tym:
  • Kontakt ds. bezpieczeństwa i kontakt zastępczy(e) posiadający uprawnienia administratora systemu, wiedzę techniczną o systemie i wiedzę o lokalizacji planu reagowania na incydenty.
  • Lokalny autorytet/decydent dla systemu, który rozumie wpływ biznesowy systemu i jego niedostępności.
• Szczegóły systemu, lub odniesienie do lokalizacji takich informacji, w tym:
  • Schematy przepływu danych
  • Schematy sieci
  • Inwentaryzację sprzętu systemowego (zgodnie z wymaganiami kontroli Rejestracja roczna)
  • Informacje o logowaniu (zgodnie z wymaganiami kontroli Audit Logging)
• Procedury zgłaszania i obsługi podejrzanego incydentu, zdefiniowane w podziale na role: Sys Admin, Bulk Access User, End User, np.,
  • Kto się kontaktować
  • Jak NIE manipulować potencjalnymi dowodami (tj.,

Opis ryzyka

Jeśli użytkownicy i administratorzy systemów nie są świadomi procedur reagowania na incydenty, reakcja będzie opóźniona, a dowody mogą zostać uszkodzone lub utracone, co znacznie zwiększa potencjalny wpływ incydentu.

Zalecenia

Aby zapewnić, że zdarzenia związane z bezpieczeństwem informacji oraz słabe punkty związane z objętymi ochroną systemami podstawowymi są komunikowane w sposób umożliwiający podjęcie na czas działań naprawczych, procedury zgłaszania zdarzeń i eskalacji powinny być udokumentowane w formalnym Planie Reagowania na Incydenty. Procedury reagowania na incydenty zazwyczaj dzielą się na następujące fazy:

• Wykrywanie – Wstępna ocena i selekcja incydentów bezpieczeństwa w systemach objętych ochroną, w tym eskalacja do Biura Bezpieczeństwa Informacji (ISO) i przypisanie poziomu priorytetu incydentu.

• Analiza – Przeprowadzenie szczegółowej analizy wpływu w celu właściwego określenia priorytetów dodatkowych działań wymaganych w przypadku naruszeń o dużym wpływie. Rozpocznij działania związane z zabezpieczeniem i ograniczeniem dowodów, a także wstępnym odzyskiwaniem danych.

• Odzyskiwanie – W zależności od powagi incydentu, złagodzenie wpływu incydentu poprzez zakończenie działań związanych z ograniczaniem i eliminacją oraz ostateczne przywrócenie stanu normalnego. W tej fazie, działania często powracają do wykrywania i analizy – na przykład, aby sprawdzić, czy dodatkowe hosty zostały zainfekowane złośliwym oprogramowaniem podczas eliminowania incydentu związanego ze złośliwym oprogramowaniem.

• Post-Incydent – Po odpowiednim zajęciu się incydentem, należy wydać raport, który szczegółowo określa przyczynę i całkowity koszt incydentu, wraz z krokami, jakie organizacja powinna podjąć, aby zapobiec przyszłym incydentom.

Wszyscy pracownicy kampusu, wykonawcy i użytkownicy zewnętrzni powinni zostać zapoznani z procedurami zgłaszania różnych typów zdarzeń, które mogą mieć wpływ na bezpieczeństwo urządzeń objętych ochroną. Powinni oni być zobowiązani do jak najszybszego zgłaszania wszelkich incydentów związanych z bezpieczeństwem informacji do wyznaczonego punktu kontaktowego.

Co to jest incydent bezpieczeństwa?

Incydent bezpieczeństwa w kontekście niniejszego wymogu MSSEI to zdarzenie, które zagraża lub może zagrozić:

• działaniu objętych systemów podstawowych lub
• poufności lub integralności objętych aktywów danych

Incydent bezpieczeństwa może obejmować którekolwiek lub wszystkie z poniższych zdarzeń:

• naruszenie zasad i norm bezpieczeństwa komputerowego kampusu
• nieupoważniony dostęp do komputera lub danych
• obecność złośliwej aplikacji, takiej jak wirus
• obecność nieoczekiwanych/nietypowych programów
• warunek odmowy usługi wobec danych, sieci lub komputera
• nieuprawnione wykorzystanie usługi, systemów lub informacji
• fizyczne lub logiczne uszkodzenie systemów
• kradzież komputera

Składniki Planu Reagowania na Incydenty dla poszczególnych systemów i usług

Właściciele zasobów i opiekunowie zasobów powinni zapewnić, że ich Plan Reagowania na Incydenty zawiera następujące składniki. Zapewniamy ten TEMAT dla planów reagowania na incydenty dla poszczególnych systemów i usług.

• Nazwy, dane kontaktowe i obowiązki lokalnego zespołu reagowania na incydenty, w tym:

  • Obsługa incydentu: Osoba kontaktowa ds. bezpieczeństwa i osoba(y) kontaktowa(e) zastępcza(e) posiadająca uprawnienia administratora systemu, wiedzę techniczną na temat systemu oraz wiedzę na temat lokalizacji planu reagowania na incydenty.
  • Kierownik ds. zasobów: Lokalny autorytet/decydent dla systemu, który rozumie wpływ biznesowy systemu i jego niedostępności. Właściciel zasobu powinien wziąć na siebie obowiązki kierownika zasobu lub wyznaczyć do tej roli pracownika kampusu.

• Szczegóły systemu, lub odniesienie do lokalizacji takich informacji, w tym:

  • Schematy przepływu danych
  • Schematy sieci
  • Inwentaryzacja sprzętu systemowego (zgodnie z wymaganiami kontroli Rejestracja roczna)
  • Informacje o logowaniu (zgodnie z wymaganiami kontroli Rejestrowanie audytu)

• Procedury zgłaszania i obsługi podejrzanego incydentu, w tym:

  • Pełny raport z przejęcia incydentu, który powinien zawierać następujące informacje:
    • Nazwisko i numer telefonu osoby kontaktowej
    • Adres IP, nazwa hosta i fizyczna lokalizacja naruszonego systemu
    • Nazwa systemu objętego ochroną (tak jak pojawia się w NetReg)
    • Jakie typy danych objętych ochroną były dostępne na/z naruszonego hosta?
      • Pełne imię i nazwisko
      • Numer ubezpieczenia społecznego
      • Numer prawa jazdy lub numer kalifornijskiej karty identyfikacyjnej
      • Numer karty kredytowej lub numer konta finansowego (w tym PIN lub data ważności)
      • Numer konta bankowego (w tym PIN lub data ważności)
      • Numer konta bankowego (w tym PIN lub data ważności)
      • Numer konta bankowego (w tym PIN lub inne informacje o dostępie)
      • Informacje medyczne lub informacje o ubezpieczeniu zdrowotnym
      • Inne
    • Dla każdego pliku zawierającego dane osobowe należy podać:
      • Nazwa pliku
      • Rozmiar pliku
      • Lokalizacja (pełna ścieżka do) pliku
    • Czy dane zostały zaszyfrowane, a jeśli tak, to w jaki sposób?
    • Opisać wpływ incydentu (np. liczbę naruszonych rekordów danych lub liczbę użytkowników, których dotyczy niedostępność systemu)
    • Opisać incydent bezpieczeństwa, w tym oś czasu działań, sposób wykrycia incydentu, wpływ (biznesowy i techniczny) incydentu, szczegóły dotyczące zastosowanych środków zaradczych, takich jak zastosowany mechanizm szyfrowania danych.
    • Dokumentacja działań podjętych w związku z naruszonym systemem (jaki jest obecnie stan systemu, itp.)

Zgłoszenie incydentu bezpieczeństwa do ISO (email [email protected]*) i dołączenie raportu z przejęcia. Przydzielimy analityka ds. bezpieczeństwa do koordynowania wszelkich dalszych działań związanych z reagowaniem na incydenty.

• Po zgłoszeniu incydentu bezpieczeństwa do ISO, nie należy rozłączać ani logować się do naruszonego systemu do czasu otrzymania instrukcji od Analityka Bezpieczeństwa ISO.
• Zakłócenia w świadczeniu usług, które nie są wynikiem złośliwych działań, należy zgłaszać odpowiednim pracownikom wsparcia IT. Dodatkowe informacje na temat zgłaszania różnych typów incydentów można znaleźć na stronie internetowej poświęconej bezpieczeństwu. Na przykład, w przypadku większości aplikacji korporacyjnych w całym kampusie, zakłócenia w świadczeniu usług powinny być zgłaszane do działu IT Campus Shared Services.

Reakcja na incydent bezpieczeństwa w odpowiednim czasie w oparciu o wytyczne dotyczące priorytetyzacji incydentów.

*Uwaga: adres e-mail [email protected] powinien być używany wyłącznie do zgłaszania incydentów bezpieczeństwa objętych MSSEI. Incydenty bezpieczeństwa nieobjęte MSSEI powinny być zgłaszane na adres [email protected].

Ustalanie priorytetów dla incydentów bezpieczeństwa

Aby pomóc w ustaleniu priorytetów dotyczących czasu i zasobów potrzebnych do wdrożenia działań naprawczych, właściciele i opiekunowie zasobów muszą ocenić wpływ incydentu bezpieczeństwa w oparciu o następujące czynniki:

• Jak incydent wpłynie na istniejącą funkcjonalność dotkniętych systemów
• Czy incydent narusza poufność lub integralność danych objętych UC P4 (dawniej UCB PL2), czy danych nieobjętych ochroną
• Jak duża część populacji użytkowników jest dotknięta incydentem bezpieczeństwa
• Jaki jest wpływ na reputację/finansowy dla kampusu

Używając czynników wymienionych powyżej jako punktu wyjścia, incydenty bezpieczeństwa powinny być oceniane i przypisywane do wysokiego lub niskiego poziomu priorytetu przez wyznaczoną osobę zajmującą się obsługą incydentów i kierownika ds. zasobów. Czynniki do rozważenia obejmują nie tylko bieżący wpływ incydentu, ale również prawdopodobny przyszły wpływ incydentu, jeśli nie zostanie on natychmiast skorygowany. Wszelkie incydenty o wysokim priorytecie powinny być natychmiast zgłaszane do ISO zgodnie z procedurami obsługi incydentów. Po zgłoszeniu incydentu bezpieczeństwa do Analityka ISO, ocena priorytetu zostanie potwierdzona lub zmieniona po dodatkowej analizie zdarzenia.

Przykłady incydentów bezpieczeństwa o wysokim priorytecie obejmują zdarzenie prowadzące do utraty funkcji krytycznych dla użytkowników z całego kampusu lub wydziału. Podobnie, naruszenie poufności danych objętych ochroną, dotyczące więcej niż 500 użytkowników, również musi mieć przypisany wysoki priorytet. Poziom priorytetu incydentu może zostać zmieniony w późniejszych fazach procesu reagowania na incydent, po tym jak dodatkowa analiza dowodów pozwoli na dokładniejsze zrozumienie skutków incydentu. Każda aktualizacja poziomu priorytetu powinna zostać zweryfikowana przez członków lokalnego zespołu reagowania na incydenty oraz analityka ISO.

Poniższa tabela zawiera dodatkowe wskazówki dotyczące zaangażowania czasowego członków zespołu reagowania na incydenty w przypadku wystąpienia incydentu bezpieczeństwa (Analityk ISO, Incident Handler, Resource Manager):

.

Fazy reagowania na incydenty	Incydent o wysokim priorytecie	Incydent o niskim priorytecie
Wykrywanie	Niezwłocznie	8 godzin
Analiza	Resource Manager i osoba zajmująca się incydentami przydzielona do pracy z Analitykiem ISO* w sposób dedykowany, w sposób ciągły.	Pracownik zajmujący się incydentami przydzielony i dedykowany do pracy z Analitykiem ISO nad sprawą w normalnych godzinach pracy.
Odzyskiwanie	Menedżer zasobów i specjalista ds. obsługi incydentów przydzielony do pracy z Analitykiem ISO* w sposób dedykowany i ciągły.	Specjalista ds. obsługi incydentów przydzielony do pracy z Analitykiem ISO nad sprawą w miarę dostępności czasu/ zasobów.
Post-Incident	Pracownik obsługujący zdarzenie wyznaczony do pracy z analitykiem ISO nad sprawą w miarę dostępności czasu/zasobów.	Pracownik obsługujący zdarzenie wyznaczony do pracy z analitykiem ISO nad sprawą w miarę dostępności czasu/zasobów.

* Sprawy o wysokim priorytecie mogą obejmować inne zainteresowane strony na terenie kampusu, w tym dział IT, radców prawnych kampusu i innych przedstawicieli kierownictwa kampusu.

Definicje fazy reakcji na incydent:

• Wykrywanie – określa maksymalny czas, jaki powinien upłynąć od momentu wykrycia podejrzanego zdarzenia do momentu, w którym oczekuje się wykonania następujących działań:

  • Wstępna ocena i triage
  • Określenie wstępnego poziomu priorytetu w oparciu o raport wlotowy
  • Zgłoszenie incydentu do ISO
  • Przydzielenie analityka ISO do współpracy z Incident Handlerem i Resource Managerem
  • Wprowadzenie incydentu do systemu zgłoszeń ISO

• Analiza -. Okres czasu w cyklu życia sprawy, w którym wymagana jest aktywna reakcja na incydent w celu zapewnienia pomyślnego rozwiązania sprawy. Zazwyczaj obejmuje to przestoje systemu lub usług i/lub pilne zabezpieczenie dowodów. Incydent jest również weryfikowany jako uzasadniony, potwierdzana jest jego priorytetowość oraz dokonywana jest odpowiednia eskalacja w oparciu o wpływ incydentu. Typowe działania obejmują:

  • Ocena, selekcja, ograniczanie, zabezpieczanie dowodów, wstępne przywracanie sprawności

• Odzyskiwanie sprawności – Okres w cyklu życia sprawy, w którym aktywna reakcja na incydent nie jest wymagana do pomyślnego rozwiązania sprawy. Typowe działania obejmują:

  • Zbieranie dowodów, analizę i dochodzenie, kryminalistykę, remediację, pełne odzyskanie, post-mortem.

• Post-Incydent – Po odpowiednim zajęciu się incydentem, zespół reagowania na incydent wydaje raport, w którym wyszczególnia przyczyny i koszty incydentu oraz kroki, jakie organizacja powinna podjąć, aby zapobiec przyszłym incydentom.

Definicje pochodzą z http://www.first.org/_assets/resources/guides/csirt_case_classification….

Dodatkowe zasoby

• NIST Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

• Software Engineering Institute Handbook for Computer Security Incident Response Teams (CSIRTs),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

• Szablon planu reagowania na incydenty dla poszczególnych systemów i usług

• Kampusowy plan reagowania na incydenty