Istnieją dwa duże obszary, na których należy się skoncentrować:
- Trudno się dostać do środka.
- Tworzenie zasad i procedur w celu spokojnego i skutecznego radzenia sobie z sytuacją, w której ktoś przekroczył punkt 1.
Trudno się dostać do środka
Jest to bardzo złożony temat i wiele z nich koncentruje się na upewnieniu się, że masz wystarczająco dużo informacji, aby dowiedzieć się, że WTF wydarzyło się po tym fakcie. Streszczenie punktorów dla uproszczenia:
- Zachowaj dzienniki (patrz także Zarządzanie zdarzeniami informacji o bezpieczeństwie)
- Wszelkie próby autoryzacji, zarówno udane, jak i niepowodzenia, najlepiej z nienaruszonymi informacjami źródłowymi.
- Dzienniki dostępu do zapory ogniowej (może to obejmować zapory ogniowe na serwer, jeśli są używane).
- Dzienniki dostępu do serwera WWW
- Dzienniki uwierzytelniania serwera bazy danych
- Dzienniki użytkowania specyficzne dla aplikacji
- Jeśli to możliwe, SIEM może wysyłać alerty dotyczące podejrzanych wzorców.
- Wymuszaj odpowiednią kontrolę dostępu
- Upewnij się, że prawa są ustawione poprawnie wszędzie i unikaj „leniwych praw” („och, po prostu daj wszystkim czytać”) tam, gdzie to możliwe.
- Okresowe audyty list ACL w celu upewnienia się, że procedury są rzeczywiście przestrzegane, a tymczasowe kroki rozwiązywania problemów („daj wszystkim do przeczytania, sprawdź, czy to wtedy działa”) zostały poprawnie usunięte po zakończeniu rozwiązywania problemów.
- Wszystkie reguły przekazywania zapory muszą być uzasadnione i okresowo kontrolowane.
- Kontroli dostępu do serwera WWW należy również poddać audyt, zarówno listy ACL serwera, jak i systemu plików.
- Wymuszaj zarządzanie zmianami
- Wszelkie zmiany w środowisku bezpieczeństwa muszą być centralnie śledzone i przeglądane przez więcej niż jedną osobę.
- W tym procesie należy uwzględnić łatki.
- Posiadanie wspólnej kompilacji systemu operacyjnego (szablonu) uprości środowisko i ułatwi śledzenie i stosowanie zmian.
- Wyłącz konta gości.
- Upewnij się, że wszystkie hasła nie są ustawione na wartości domyślne.
- Gotowe aplikacje mogą konfigurować użytkowników przy użyciu wstępnie zdefiniowanych haseł. Zmienić je.
- Wiele urządzeń IT jest dostarczanych z bardzo dobrze znanymi parami użytkownik / hasło. Zmień je, nawet jeśli logujesz się w tym temacie tylko raz w roku.
- Ćwicz najmniejsze przywileje. Daj użytkownikom dostęp, którego naprawdę potrzebują.
- Dla administratorów rozsądna jest konfiguracja dwóch kont. Jedno zwykłe konto używane do poczty e-mail i innych zadań biurowych, a drugie do pracy z podwyższonym poziomem uprawnień. Maszyny wirtualne ułatwiają to.
- NIE zachęcaj do regularnego korzystania z ogólnych kont administratora / root, trudno jest śledzić, kto co robił, kiedy.
Tworzenie zasad i procedur w celu spokojnego i skutecznego radzenia sobie z sytuacją, gdy ktoś się dostanie
Polityka zdarzeń związanych z bezpieczeństwem jest obowiązkowa dla wszystkich organizacji. To znacznie zmniejsza fazę odpowiedzi „bieganie z odciętymi głowami”, ponieważ ludzie stają się irracjonalni w obliczu takich wydarzeń. Włamania są dużymi, przerażającymi sprawami. Wstyd z powodu wtargnięcia może spowodować, że sysadmini zorientowani w inny sposób zaczną niepoprawnie reagować.
Wszystkie poziomy organizacji muszą znać zasady. Im większy incydent, tym bardziej prawdopodobne jest, że wyższe kierownictwo w jakiś sposób się zaangażuje, a ustalenie procedur postępowania z rzeczami znacznie pomoże w odparciu „pomocy” z wysoka. Zapewnia również poziom ochrony dla techników bezpośrednio zaangażowanych w reakcję na incydent, w postaci procedur dla kierownictwa średniego szczebla w celu komunikacji z resztą organizacji.
Idealnie, twoja polityka odzyskiwania po awarii już określiła, jak długo niektóre usługi mogą być niedostępne przed uruchomieniem zasad odzyskiwania po awarii. Pomoże to w reagowaniu na incydenty, ponieważ tego rodzaju zdarzenia są katastrofami. Jeśli zdarzenie jest typu, w którym okno odzyskiwania NIE zostanie spełnione (przykład: witryna DR z funkcją tworzenia kopii zapasowej na gorąco otrzymuje kanał informacyjny o zmianach w czasie rzeczywistym, a intruzi usunęli kilka danych, które zostały skopiowane do witryny DR zauważono, dlatego konieczne będzie zastosowanie procedur odzyskiwania po przeziębieniu), a następnie kierownictwo wyższego szczebla będzie musiało wziąć udział w rozmowach dotyczących oceny ryzyka.
Niektóre elementy każdego planu reagowania na incydenty:
- Zidentyfikuj zagrożone systemy i ujawnione dane.
- Wczesne ustalenie, czy konieczne będzie przechowywanie dowodów prawnych w celu ewentualnego wniesienia oskarżenia.
- Aby zachować dowody , nie dotykaj niczego w tym systemie, chyba że jest to absolutnie wymagane . Nie loguj się do niego. Nie przesiewaj plików dziennika. Robić. Nie. Dotknąć.
- Aby zachować dowody, zaatakowane systemy należy pozostawić w trybie online, ale należy je rozłączyć do czasu, aż certyfikowany ekspert ds. Kryminalistyki komputerowej będzie mógł dokonać podziału systemu w sposób zgodny z zasadami postępowania z dowodami.
- Wyłączenie zainfekowanego systemu może spowodować skażenie danych.
- Jeśli system pamięci na to pozwala (dyskretne urządzenie SAN), wykonaj migawkę dotkniętych jednostek LUN przed rozłączeniem i oznacz je jako tylko do odczytu.
- Zasady postępowania z dowodami są złożone i och, tak łatwe do zepsucia. Nie rób tego, chyba że przeszedłeś szkolenie na ich temat. Większość ogólnych SysAdminów NIE ma tego rodzaju szkolenia.
- Jeśli zachowane zostaną dowody, traktuj utratę usługi jako katastrofę spowodowaną utratą sprzętu i rozpocznij procedury odzyskiwania z nowym sprzętem.
- Wstępnie ustalone zasady dotyczące rodzajów katastrof wymagają zawiadomienia. Przepisy i regulacje różnią się w zależności od miejscowości.
- Zasady dotyczące „narażenia” i „udowodnionego kompromisu” są różne.
- Reguły powiadomień będą wymagały zaangażowania działu komunikacji.
- Jeśli wymagane powiadomienie jest wystarczająco duże, konieczne będzie zaangażowanie kierownictwa najwyższego poziomu.
- Korzystając z danych DR, określ, ile czasu „WTF właśnie się wydarzyło”, zanim przywrócenie usługi do sieci stanie się wyższym priorytetem.
- Czasy odzyskiwania usługi mogą wymagać pracy nad ustaleniem, co się stało z podporządkowanym. Jeśli tak, to po przywróceniu usług zrób zdjęcie dysku urządzenia, którego dotyczy problem, w celu przeprowadzenia analizy (nie jest to kopia dowodowa, tylko inżynierowie muszą dokonać inżynierii wstecznej).
- Zaplanuj zadania odzyskiwania usługi, tak aby obejmowały całkowitą przebudowę systemu, którego dotyczy problem, a nie tylko usuwanie bałaganu.
- W niektórych przypadkach czasy odzyskiwania usługi są na tyle krótkie, że obrazy dysku należy wykonać natychmiast po zidentyfikowaniu kompromisu i nie można przechowywać dowodów prawnych. Po przebudowaniu usługi można rozpocząć pracę nad ustaleniem, co się stało.
- Przeszukuj pliki dziennika, aby uzyskać informacje dotyczące sposobu, w jaki atakujący wszedł i co mógł zrobić od razu.
- Przeszukuj zmienione pliki, aby uzyskać informacje dotyczące tego, jak się dostali i co zrobili po wejściu.
- Przeszukuj dzienniki zapory, aby uzyskać informacje o tym, skąd pochodzą, skąd mogły wysłać dane i ile z nich mogło zostać wysłanych.
Posiadanie zasad i procedur przed kompromisem, dobrze znanych osobom, które będą je wdrażać w przypadku kompromisu, jest czymś, co należy po prostu zrobić. Zapewnia wszystkim ramy reakcji w czasie, gdy ludzie nie będą myśleć prosto. Wyższe kierownictwo może grzmotać i huczeć w związku z procesami sądowymi i oskarżeniami kryminalnymi, ale w rzeczywistości połączenie sprawy jest kosztownym procesem, a świadomość, że wcześniej może pomóc w tłumieniu furii.
Zauważam również, że tego rodzaju zdarzenia muszą być uwzględnione w ogólnym planie reagowania na katastrofy. Kompromis najprawdopodobniej uruchomi politykę „utraconego sprzętu”, a także reakcję „utraty danych”. Znajomość czasów odzyskiwania usługi pomaga ustalić, ile czasu może zająć zespół ds. Reakcji bezpieczeństwa na przelanie faktycznego zaatakowanego systemu (jeśli nie zachowuje dowodów prawnych), zanim będzie on potrzebny w trakcie odzyskiwania usługi.