Miesiąc: październik 2021

Reagowanie na incydenty bezpieczeństwa, czyli jak wdrożyć systemy klasy SIEM i SOAR?
W dzisiejszych czasach każda organizacja mierzy się z wyzwaniem zapewnienia bezpieczeństwa informacji, przede wszystkim w zakresie poufności, dostępności oraz integralności danych i systemów, które zapewniają możliwość świadczenia usług biznesowych, czy też kluczowych. Co więcej część organizacji jest zobligowana do przestrzegania regulacji i zaleceń wynikających z rodzaju świadczonych usług np. wytyczne Komisji Nadzoru Finansowego dla spółek finansowych oraz ustawy o krajowym systemie cyberbezpieczeństwa dla operatorów usług kluczowych.
Każda z wymieniowych wcześniej regulacji, zakłada konieczność monitorowania i raportowania incydentów bezpieczeństwa. Dla organizacji, których regulacje nie dotyczą, monitorowanie incydentów jest równie ważne m.in. z uwagi na możliwość świadczenia usług biznesowych czy też utrzymania wysokiego poziomu zadowolenia i zaufania klientów.
Zbudowanie procesu monitorowania i reagowania na incydenty bezpieczeństwa jest zagadnieniem złożonym, do którego należy się odpowiednio przygotować i realizować krok po kroku. Niestety nie ma złotego środka w postaci rozwiązania technologicznego, które pozwoli na kompleksowe uruchomienie procesu.
Należy również pamiętać, że cały proces to nie tylko technologia, ale również kwestie organizacyjne np. polityka i procedury bezpieczeństwa, jak również ludzie, czyli odpowiednio zwymiarowany zespół, składających się ze specjalistów i ekspertów o odpowiednich kompetencjach. W opracowaniu skupię się przede wszystkim na rozwiązaniach technologicznych.
W ramach przygotowania do wdrożenia procesu można posiłkować się modelem dojrzałości monitorowania i reagowania na incydenty bezpieczeństwa.

 
Jak przygotować się do wdrożenia procesu w oparciu o technologię?
Pierwszym krokiem przygotowania się do wdrożenia procesu monitorowania i reagowania na incydenty bezpieczeństwa w kontekście technologicznym jest analiza środowiska IT w zakresie:

Wykorzystywanych rozwiązań bezpieczeństwa
Usług podstawowych np. serwer poczty
Systemów świadczących najważniejsze usługi biznesowe
Systemów wspierających

Idealna sytuacja, która jednak wymaga znaczącego nakładu pracy, to inwentaryzacja wszystkich zasobów IT w organizacji, co pozwala na przygotowanie się do pierwszego etapu, czyli wdrożenia rozwiązania zapewniającego widoczność zdarzeń bezpieczeństwa.
Na podstawie przeprowadzonych analiz możemy wyspecyfikować nie tylko obszary, które powinniśmy i możemy objąć monitorowaniem, ale również obszary, w których występują braki technologiczne czy funkcjonalne, które należy uzupełnić.
Analiza stanu obecnego infrastruktury oraz rozwiązań bezpieczeństwa pozwoli na opracowanie docelowych funkcjonalności rozwiązań log management, SIEM i SOAR, które będą możliwe do implementacji. Przykładowo brak rozwiązania klasy EDR uniemożliwi wykrywanie zdarzeń dotyczących uruchamiania podejrzanych plików czy procesów na stacjach roboczych.
Widoczność zdarzeń bezpieczeństwa
Widoczność zdarzeń bezpieczeństwa jest kluczowym elementem całego procesu. Nie można w efektywny sposób wdrożyć procesu, jeśli nie mamy odpowiedniej widoczności tego, co dzieje się w naszej infrastrukturze.
Jako pierwszy element modelu powinien zostać wdrożony system klasy zarządzania zdarzeniami (log management). Technologia będzie pobierać lub odbierać zdarzenia z monitorowanych systemów (źródeł danych) i przechowywać je przez określony czas, dając możliwość analizy zdarzeń, jak również wykonywania szczegółowych analiz czy raportowania na potrzeby zgodności.
Analizując rozwiązania dostępne na rynku warto rozważyć Producentów, którzy dostarczają zarówno rozwiązania log management jak i rozwiązania SIEM. Zapewnienie homogenicznych rozwiązań od jednego Producenta, w przyszłości może zaoszczędzić czas niezbędny do wdrożenia kolejnych rozwiązań technologicznych, w kolejnych krokach modelu dojrzałości. Dotyczy to przede wszystkim sposobu normalizacji zdarzeń, który jest odmienny dla różnych systemów log management i SIEM.
Podczas wyboru rozwiązania należy zwrócić uwagę w szczególności na:

Stopień kompresji zdarzeń przy ich długoterminowym przechowywaniu.
Funkcjonalność konfiguracji różnych okresów przechowywania zdarzeń dla poszczególnych rodzajów systemów/zdarzeń.
Stopnień skomplikowania funkcjonalności podłączania źródeł logów.
Stopień skomplikowania przygotowywania dedykowanych reguł normalizujących zdarzenia.
Sposób przekazywania zdarzeń do zewnętrznych systemów SIEM oraz SOAR.

Na podstawie zdarzeń zebranych w systemach zarządzania logami można wykonać analizę tego, co dzieje się w naszej infrastrukturze, a przede wszystkim potwierdzić możliwość realizacji docelowych funkcjonalności SIEM i SOAR w ramach rozwoju modelu dojrzałości.
Z dobrych praktyk wynika, że z modułu zarządzania logami do modułu SIEM powinno trafiać maksymalnie 50%, a zwykle ok. 30% zebranych zdarzeń, które będą wykorzystane dalej do monitorowania incydentów bezpieczeństwa w czasie zbliżonym do rzeczywistego. Z tego wynika, że wdrożenie odrębnego modułu zarządzania logami oraz odrębnego modułu SIEM pozwoli na znaczne zoptymalizowanie budżetu niezbędnego na licencje oraz zasoby sprzętowe czy też wirtualne. Należy mieć na uwadze, że koszt modułu zarządzania logami jest znacznie niższy niż koszt wdrożenia systemów SIEM.
Monitorowanie reaktywne incydentów bezpieczeństwa
Na potrzeby przejścia do kolejnego punktu modelu dojrzałości niezbędne jest wdrożenie systemu klasy SIEM w podstawowej funkcjonalności. Zakres wdrożenia jak również funkcjonalności analityczne, które będą implementowane w ramach etapu, mamy już określone w poprzednim etapie, dzięki wykonanej analizie zarówno infrastruktury, jak i zdarzeń bezpieczeństwa.
Monitorowanie reaktywne z wykorzystaniem systemu klasy SIEM polega na reagowaniu na incydenty bezpieczeństwa w momencie ich wykrycia przez silnik korelacyjny. Jednak jest to monitorowanie post factum i w obecnym etapie polega na wykonywaniu analiz już zaistniałych incydentów bezpieczeństwa.
Etap dotyczy nie tylko wdrożenia samej technologii, ale również edukacji zespołów w ramach wdrożonego rozwiązania. Poznawanie funkcjonalności i zasady działania pozwala użytkownikom na znalezienie dodatkowych sposobów wykorzystania systemu. Co więcej budowanie kompetencji operatorów, analityków i osób odpowiedzialnych za bezpieczeństwo organizacji pozwala na rozpoczęcie procesu monitorowania incydentów bezpieczeństwa. Osoby odpowiedzialne za proces mają okazję poznać specyfikę incydentów, a co za tym idzie konkretnych zagrożeń i ataków, z którymi boryka się organizacja.
Monitorowanie proaktywne incydentów bezpieczeństwa
Monitorowanie proaktywne z wykorzystaniem systemu SIEM to przesunięcie ciężaru działania z wykrywania zaistniałych incydentów bezpieczeństwa na monitorowanie potencjalnie niestandardowego i groźnego zachowania infrastruktury IT.
Z pomocą przychodzi szereg funkcjonalności udostępnionych przez producentów poszczególnych rozwiązań SIEM np.:

Integracja rozwiązań z feedami IoC, IoA oraz Threat Intelligence.
Badanie zachowania użytkowników wewnętrznych i zewnętrznych z wykorzystaniem modułów klasy user behavior analytics.
Moduły wykorzystujące machine learning i artificial intelligence do badania anomalii w infrastrukturze.

Wspomniane funkcjonalności w znakomity sposób zwiększają widoczność zdarzeń bezpieczeństwa w organizacji w bardzo szerokim zakresie. Monitorowanie proaktywne wykorzystuje przede wszystkim dynamiczne elementy i funkcjonalności, a nie bazuje już tylko na zebranych zdarzeniach i ich statycznej analizie.
Większość systemów SIEM posiada wbudowany moduł do obsługi incydentów bezpieczeństwa. Zazwyczaj działa on świetnie w obrębie danego systemu jednak posiada ograniczenia w możliwości integracji z innymi systemami, zarówno na potrzeby wykonania akcji, jak i procesowania incydentów w systemach zewnętrznych. Incydenty mogą być wzbogacane o dodatkowe informacje pochodzące ze zdarzeń ze źródeł danych, które są podłączone do SIEM. Wykonanie akcji np. blokowanie użytkownika, jest teoretycznie możliwe, ale wymaga prac developerskich. Sytuacja wygląda podobnie jeśli chodzi o możliwość współpracy pracowników zespołów bezpieczeństwa. Każdy członek zespołu musi mieć skonfigurowane odpowiednie uprawnienia w głównej konsoli systemu SIEM.
Automatyzacja
Ostatnim etapem dojrzałości modelu monitorowania i reagowania na incydenty bezpieczeństwa jest wdrożenie systemu klasy Security Orchestration Automation and Response. Systemy SOAR to uniwersalne platformy, które zapewniają jeden punkt wspólny pracy dla zespołów cyberbezpieczeństwa przy obsłudze incydentów bezpieczeństwa.
Najważniejszą zaletą systemów SOAR jest możliwość automatyzacji częściowej lub całościowej procesu obsługi incydentu bezpieczeństwa w ramach tzw. Playbooka czyli przepływów procesu. W znaczący sposób wpływa to na wzrost efektywności procesu, co skutkuje znaczącym spadkiem kosztów obsługi procesu
Docelowo system klasy SOAR powinien być wdrożony na bazie funkcjonalności, które zostały określone w poprzednich etapach modelu i rozwijać je do wysokiego poziomu dojrzałości. Przy procesie specyfikacji wspomnianych funkcjonalności należy wziąć pod uwagę następujące kwestie:

Jakie mogą być źródła informacji o danym incydencie. Jaki system oprócz SIEM może wzbogacić analizowany incydent?
Jakie integracje z zewnętrznymi systemami powinny zostać wykorzystane?
Czy system SOAR ma wykonywać akcje na innych systemach np. automatyczne blokowanie użytkownika?

Dojrzały model monitorowania i reagowania na incydenty bezpieczeństwa nie będzie oczywiście opierał się jedynie na rozwiązaniu SIEM. Tak naprawdę źródłem incydentu może być dowolny system np. EDR, czy też system backupowy. Podobnie akcją SOAR-a nie musi być tylko akcja związana z cyberbezpieczeństwem.
Dla lepszego zobrazowania podejścia do wykorzystania systemu SOAR w organizacji w bogatym zakresie, który wykorzysta wzbogacanie incydentów i wykonywanie akcji, przedstawię przykładowe playbooki: 1. 
1. Wielokrotne nieudane logowania

Zdarzenie ze SIEM uruchamia playbook.
Z Active Directory pobierane są informacje o użytkowniku – wzbogacanie incydentu.
Playbook automatycznie wysyła do użytkownika wiadomość e-mail z pytaniem, czy jest świadom zaistniałego zdarzenia i czy potwierdza ten fakt.
Jeśli użytkownik potwierdzi fakt, playbook zostaje zamknięty.
Jeśli użytkownik nie potwierdzi faktu konto użytkownika jest blokowane w Active Directory i powiadamiany jest przełożony pracownika, za pomocą wiadomości e-mail.
Priorytet incydentu jest ustawiany na wysoki.

2. Zarządzanie kontem pracownika na wypowiedzeniu

System SOAR otrzymuje informację z systemu kadrowego o pracowniku, który kończy współpracę z firmą w konkretnym terminie. Uruchamiany jest playbook, który ustawia harmonogram uruchomienia kolejnego playbooka na podstawie terminu przesłanego przez system kadrowy.
W podanym terminie uruchamiany jest playbook, który wykonuje akcje w postaci blokowania użytkownika w Active Directory, innych usługach, do których pracownik miał dostęp oraz blokuje kartę pracownika, za pomocą której wchodził on do firmy.

Przygotowane w poprzednich etapach funkcjonalności, szczególnie w etapie monitorowania proaktywnego, dobrze jest zaimplementować w SOAR, dodając procedury automatyzujące częściowo lub całościowo ich obsługę.
Efektem dojrzałego procesu monitorowania i reagowania na incydenty bezpieczeństwa jest kompleksowo wdrożony system zarządzania logami, wykrywania podejrzanych zdarzeń i anomalii, jak również system obsługi incydentów. Punktem obsługi incydentów i pracy użytkowników będzie konsola systemu SOAR, jako najwyższa warstwa procesu.
Co dalej?
Trzeba mieć na uwadze, że osiągnięcie dojrzałości procesu monitorowania i reagowania na incydenty bezpieczeństwa nie sprawia, że organizacja jest w 100% zdolna do przeciwdziałania wszystkim zagrożeniom. W sieci praktycznie codziennie pojawiają się nowe zagrożenia i ataki, często zero-day lub APT, co wymusza ciągłe doskonalenie procesu. Dlatego ważne jest, aby w sposób cykliczny przeglądać proces i dostosowywać go do obecnych warunków.
Podsumowanie
Zastosowanie modelu dojrzałości procesu monitorowania i reagowania na incydenty bezpieczeństwa ma wiele zalet. Przede wszystkim umożliwia przygotowanie roadmapy, na podstawie której proces będzie wdrażany od początku lub od momentu, w którym znajduje się obecnie w organizacji. Model daje możliwość zaplanowania nie tylko działań, ale też docelowej funkcjonalności inicjalnej, bazującej na wykonanej w fazie przygotowawczej analizie. Jest to niezwykle ważne, gdyż pozwala na określenie kryteriów sukcesu dla każdego etapu.
Wykorzystanie etapów modelu pozwala na zwiększenie efektywności budowania całego procesu, co w efekcie przekłada się na oszczędność czasu podczas wdrożeń. Podział modelu na poszczególne fazy sprzyja również rozwojowi pracowników, którzy sukcesywnie nabywają wiedzę i kompetencje, wraz z rozwojem procesu.
 
Jesteś zainteresowany naszym wsparciem w obszarze Cyber Security? Napisz do nas, wypełniając formularz kontaktowy poniżej.

 
Jeżeli ktoś z was miał styczność z przedstawicielami Microsoft i brał udział w rozmowach o przyswojeniu Microsoft Teams w organizacji – na pewno spotkał się z określeniem change management – zarządzanie zmianą. Pytanie brzmi natomiast – co to dokładnie jest? Artykułów w internecie na ten temat jest sporo i ciągle przybywa (wraz z popularyzacją tego określenia), ale często zaczynają one od części mocno teoretycznej, albo zbyt praktycznej. W tym, stosunkowo krótkim, artykule, chciałbym pokazać tzw. ‘core’ (podstawy) zarządzania zmianą, omówić jego połączenie właśnie z produktami Microsoft i w końcu odpowiedzieć na pytanie – czy bez tego da się w organizacji zaadoptować np. Microsoft Teams?
No dobra – zarządzanie zmianą… Skąd to?
Zacznę od nieco innej strony – kojarzycie pewnie zarządzanie projektami, co? Jest to podejście, które już na stałe przyjęło się w niemal każdej organizacji. Po pierwsze: istnieje “projekt” – przykładowo chcemy coś zbudować. W tym projekcie dysponujemy zasobami – ludźmi, materiałami itd. Następnie pod uwagę bierzemy dostępność tych zasobów, różne ceny etc. Na koniec zwracamy uwagę na etapy – jak budujemy dom, to nie zaczniemy od dachu 😊
Żeby miało to ręce i nogi – powstaje plan, którego staramy się trzymać i (mamy szczerą nadzieję) wszystko gra!
No i tutaj pojawia się właśnie nasz change management, jako uzupełnienie tradycyjnego modelu prowadzenia projektów. Zobaczcie – dostajecie licencję Microsoft Teams jako nowego narzędzia do komunikacji. Od strony IT – przypisujemy te licencje do użytkowników i instalujemy oprogramowanie (MOCNO spłycając proces :D). Czy to oznacza, że następnego dnia nasza efektywność w organizacji skoczy o 40%?
Aby tak faktycznie było, nasi użytkownicy muszą wiedzieć jak się poruszać w nowym środowisku, po co ono jest itp. itd. Nawiążę do tradycyjnego powiedzenia, że jak dacie człowiekowi rybę to nie będzie głodny do końca dnia, ale jak mu dacie wędkę, to nie będzie głodny do końca życia.
Osobiście się z tym nie zgadzam, bo wychodzimy z założenia (często mylnego), że nasz gość będzie umiał tą wędką się posługiwać, a nie np. rzucać nią w ryby z nadzieją, że trafi…
A co w momencie, kiedy tutaj mówimy o bardziej skomplikowanej „wędce”, jak np. Microsoft Teams?
Metodologia Prosci i model ADKAR
Właśnie ze względu na wcześniejszy scenariusz, do wdrażania nowych technologii, procesów itp. powinniśmy rozważyć zarządzanie zmianą (a najlepiej uwzględnić, a nie ‘rozważyć’ 😉). Czyli konkretnie – powinniśmy uwzględnić LUDZI.
Metodologia, która jest polecana przez Microsoft (i przeze mnie, z racji na mój certyfikat 😉) to Prosci – skalowalne podejście, wypracowane na podstawie ponad 20 lat badań.
Ja dzisiaj chciałbym wam przekazać drobny wycinek jakim jest model ADKAR. Jest to jedna z podstaw całego zarządzania zmianą, akronim, którego każda litera oznacza kolejny ‘etap’ wymagany do prawidłowego wdrożenia i zaadaptowania zmian.
Po kolei – pierwsza A to Awareness, czyli świadomość. Będę cały czas posługiwał się tymi naszymi nieszczęsnymi Teamsami jako przykład 😊

 
Co mamy na myśli, mówiąc o świadomości – chodzi de facto o to, aby nasi użytkownicy wiedzieli, dlaczego w ogóle te Teamsy wprowadzamy. Co to w ogóle za apka (‘tims? A na co to komu?), dlaczego nagle mamy z niej korzystać (‘przecież nasze obecne gadu-gadu świetnie działa!’), skąd potrzeba do zmiany?
Możemy o to zadbać na szereg różnych sposobów – odpowiednia informacja przesłana do wszystkich, wsparcie ze strony menadżerów średniego szczebla, organizowanie sesji pytań i zgłaszania wątpliwości od strony waszych użytkowników.
ALE – to nie wystarczy. Nawet jeżeli ktoś mnie przekona, że mój wypracowany sposób działania MOŻNA usprawnić i dlatego wpada coś nowego, to wcale nie znaczy, że ja teraz będę chciał to zrobić. Pojawia nam się druga literka, czyli D – Desire (chęć).

Musimy zachęcić naszych użytkowników do tejże zmiany, do spróbowania nowej technologii. Może marchewką – np. gamifikacją, albo jakimiś nagrodami czy przywilejami, raczej stroni się od metody ‘kija’ 😉 Pokazując, że z wykorzystaniem nowego podejścia uciążliwe zadania nagle stają się banalnie proste, nasi użytkownicy sami będą chcieli tego spróbować!
I tutaj pojawiają się kolejne dwie literki – K i drugie A. K odnosi się do Knowledge (wiedza), jak możemy się zmienić. Przykładowo – mamy tutaj taką jedną fajną aplikację Microsoft Teams, gdzie, jeżeli zaczniecie wymieniać się danymi w ramach zespołu, to tworzycie wspólne repozytorium na pliki, w ogóle to możecie pracować i edytować te pliki naraz w kilka osób, a każda zmiana jest zapisywana w historii wersji.
Wiedza natomiast nie wystarcza, bo potrzebne są jeszcze umiejętności – stąd A od Ability. Nasi pracownicy muszą wiedzieć jak wykorzystać tą aplikację, jak zaadoptować procesy, jak zmienić swoje przyzwyczajenia.
I wydaje mi się, że jedna z najważniejszych literek na sam koniec – R od Reinforcement (wzmocnienie, wsparcie, utrzymanie). Zmiana jest procesem – dlatego na bieżąco musimy naszym użytkownikom pomagać, rozwijać, wspierać w całym procesie. Pojawiają się nowi pracownicy, nowe aplikacje etc. – trzeba to uwzględnić 😊 Ważne, aby nie stracić zapału na początku!

Z dumą informujemy, że Integrity Partners zostało wyróżnione nagrodą Darktrace Service Partner of the Year 2021 dla regionu EMEA.
Już po raz kolejny zostaliśmy wyróżnieni jako kluczowy Partner firmy Darktrace, która specjalizuje się w wykrywaniu anomalii sieciowych w oparciu o machine learning. Nagroda jest owocem ciężkiej pracy całego zespołu Integrity Partners. Od lat wyposażamy organizacje w najnowocześniejszą technologię Darktrace, dzięki czemu nasi klienci 
Nagroda Services Partner of the Year jest szczególnie dla nas ważna, ponieważ pozycjonuje Integrity Partner na lidera w regionie EMEA (Europa, Bliski Wschód, Afryka).
 

 
Więcej o rozwiązaniu Darktrace
Darktrace Enterprise Immune System wykrywa i klasyfikuje zagrożenia w całym przedsiębiorstwie. Wykorzystuje czołową na świecie technologię uczenia maszyn oraz sztuczną inteligencję, by wykrywać, klasyfikować i wizualizować potencjalne zagrożenia. Oprócz niezwykłej skuteczności działania jego niewątpliwą zaletą jest również szybka instalacja. Ponadto w odróżnieniu od podejścia opartego na zasadach i sygnaturach, Darktrace Enterprise nie opiera się na atakach historycznych, by przewidzieć przyszłość. Zamiast tego buduje własną, unikalną wiedzę o tym, jak wygląda typowe zachowanie w danej firmie i potrafi wykrywać pojawiające się zagrożenia w czasie rzeczywistym, w tym zagrożenia z wykorzystaniem informacji poufnych oraz zautomatyzowane wirusy, takie jak oprogramowanie ransomware.
Jesteś zainteresowany rozwiązaniem Darktrace? Napisz do nas!

Hardening, czy może po polsku „utwardzanie” (szczerze mówiąc wolę angielską nazwę), to w skrócie zwiększenie odporności danego systemu na włamania poprzez jego rekonfigurację. Utwardzać można zarówno systemy jak i urządzenia sieciowe, bazy danych, usługi czy stacje robocze.
Hardening – Od czego zacząć?
Oczywiście od planu. Warto zastanowić się jakie systemy chcemy hardenować, w jakiej kolejności i kiedy. Hardening zawsze dobrze jest rozpocząć od analizy ryzyka – odpowiedzmy tu sobie na pytania: które systemy są najbardziej narażone na włamania? Które systemy są kluczowe z punktu widzenia procesów biznesowych? Które systemy, w przypadku utraty integralności i dostępności niosłyby za sobą największe straty?
Potrzeba hardeningu może także wynikać z przebytego audytu zewnętrznego/wewnętrznego czy testów penetracyjnych, które wykazały istniejące podatności. Możemy mieć też potrzebę bycia zgodnymi z pewnymi standardami – dla przykładu, aby zachować zgodność z PCI-DSS musimy przeprowadzać okresowe skanowanie podatności i mitygować te, które są o wysokim priorytecie.
Jakie systemy utwardzać?
Najlepiej te, które są najbardziej krytyczne i narażone na włamania. Takimi systemami bez wątpienia są systemy, aplikacje i urządzenia, które są dostępne z Internetu. Atakujący z całego świata bez ustanku skanują Internet w poszukiwaniu udostępnionych usług. Nie muszą nawet robić tego sami – w Internecie dostępne są na bieżąco aktualizowane bazy danych, zawierające informacje na temat publicznych usług wystawionych do Internetu. Poniżej znajduje się jedna z takich usług – Shodan.

Proste zapytanie, pokazane poniżej, pozwoli nam wyszukać wszystkie usługi SSH dostępne w Polsce. I to nie tylko na domyślnym porcie 22. Muszę tutaj rozczarować fanów tzw. głębokiego ukrycia, a więc ukrywania usług na portach innych niż domyślne – wystawienie usługi na nietypowym porcie nie zabezpieczy nas przed znalezieniem naszej usługi. Jeśli atakujący jest uparty może to co najwyżej opóźnić trochę jego działania.
[caption id="attachment_1988" align="aligncenter" width="604"] Widok z konsoli shodan.io – liczba znalezionych usług SSH wystawionych do Internetu w Polsce[/caption]
 
Oprócz systemów wystawionych do Internetu warto brać także pod uwagę systemy krytyczne dla biznesu oraz te, które przechowują dane wrażliwe. Nie chcemy przecież, żeby atakujący przełamał zabezpieczenia bazy danych zawierających dane kadrowe naszych pracowników albo dostał się do systemu CRM, przechowującego dane wszystkich naszych klientów. Pamiętajmy, że atakujący może próbować uzyskać do takich systemów dostęp również z wewnątrz sieci. Jeśli jest to ktoś spoza naszej organizacji może użyć do tego stacji pośredniej (np. takiej wystawionej do Internetu, w przypadku nieprawidłowo wdrożonej segmentacji) albo stacji naszego nieświadomego pracownika – w końcu stacje użytkowników są jednym z najczęstszych źródeł ataku na organizację. Ponadto nasz pracownik może także działać świadomie na naszą szkodę – motywacja może być różna – od niezadowolenia z pracy do chęci zarobku kosztem naszej firmy.
Plan hardeningu
Nasze działania powinniśmy zaplanować. Mając już wstępną listę systemów, które warto zabezpieczyć możemy zrobić ich inwentaryzację i zaplanować ścieżkę aktualizacji. Dla przykładu mając serwer z Centos łatwiej zrobić nam będzie aktualizację do najnowszej wersji Centosa zamiast do Ubuntu. Dobrze byłoby przy tym zastanowić się, czy nasze działania nie spowodują niekompatybilności z istniejącymi usługami, które na danym hoście działają. Być może aktualizując system do najnowszej wersji sprawimy, że jakaś ważna usługa przestanie działać, bo np. jest dawno nie wspierana i nie jest z tą wersją kompatybilna.
Biorąc to pod uwagę możemy stworzyć sobie prosty arkusz, który pomoże nam zaplanować nasze prace. Poniżej znajduje się przykład takiego arkuszu.

Jest to oczywiście przykład, który zawiera bardzo podstawowe informacje i dla każdej organizacji taki arkusz może wyglądać inaczej i zawierać więcej istotnych parametrów.
Aktualizacje systemowe i oprogramowania
Każda organizacja powinna mieć tzw. politykę aktualizacji, która określa w jaki sposób realizowane jest aktualizowanie oprogramowania do nowszych wersji. Jeśli natomiast takiej polityki nie ma, lub nie jest ona przestrzegana może się zdarzyć, że mamy w swoim środowisku oprogramowanie, które jest nieaktualne i, w związku z tym, może posiadać podatności. Dlatego też myśląc o hardeningu powinniśmy wziąć pod uwagę aktualizację systemu operacyjnego do najnowszych, stabilnych wersji. To samo dotyczy usług i oprogramowania.
Oczywiście zanim przystąpimy do aktualizacji upewnijmy się, że nowe wersje będą ze sobą kompatybilne i po aktualizacji nie spowodujemy niedostępności jakichś krytycznych usług. Możemy zacząć od aktualizacji środowiska testowego, o ile takie środowisko posiadamy a dopiero później przejść do produkcji. Innym ze sposobów zabezpieczenia się przed taką ewentualnością jest wykonanie wcześniej kopii zapasowej a dopiero potem rozpoczęcie procesu aktualizacji. W razie problemów zawsze możemy wtedy odtworzyć system w oryginalnej formie i ustalić powód niedostępności po aktualizacji.
Wyłączenie zbędnych usług
Dzięki wyłączeniu zbędnych usług działających w systemie operacyjnym lub urządzeniu sieciowym efektywnie redukujemy ich powierzchnię ataku. Jeśli na przykład mamy serwer pocztowy Linux, na którym ktoś, z niewiadomych przyczyn, zainstalował kiedyś usługę NFS, pewnie powinniśmy ją odinstalować. O jedną usługę mniej do zabezpieczania, aktualizowania i utrzymywania. Dodatkową zaletą jest pozytywny wpływ na wydajność, bo te bardziej zaawansowane usługi potrafią czasami zajmować sporo miejsca w RAM i niepotrzebnie wykorzystywać cykle procesora.
Zablokowanie nieużywanych portów
Jeśli mamy jakieś usługi, których nie możemy wyłączyć może chociaż możemy zablokować do nich dostęp? Niektóre usługi są niezbędne dla prawidłowego działania systemu operacyjnego, ale niekoniecznie muszą być wystawione do sieci. Blokując do nich dostęp na zaporze sieciowej upewniamy się, że nie zostaną one wykorzystane do tzw. przemieszczania poziomego (Lateral Movement), a więc propagacji atakującego po naszej sieci.
Alternatywnie, jeśli usługa potrzebna jest tylko dla lokalnej aplikacji, możemy skonfigurować ją tak, żeby nasłuchiwała jedynie na lokalnym interfejsie loopback.
Jeśli chcemy sprawdzić jakie usługi nasłuchują na naszym systemie zarówno w systemach Linux jak i Windows możemy do tego użyć komendy „netstat”.
Odinstalowanie zbędnych programów
Niektóre programy mogą posiadać własne podatności, które pozwolą atakującemu przełamać zabezpieczenia danego hosta. Dobrym przykładem są tu stacje robocze. Zastanówmy się czy nadal potrzebujemy na stacjach roboczych zainstalowanego Flasha, skoro już od dawna jest on nie wspierany przez producenta i nie są do niego wydawane żadne aktualizacje zabezpieczeń a każdy szanujący się producent oprogramowania już dawno powinien zrezygnować z jego wsparcia.
Wyłączenie zbędnych protokołów
Protokoły sieciowe również mogą posiadać podatności. Ma to szczególne znaczenie w przypadku sprzętu sieciowego, ale może też dotyczyć serwerów czy stacji roboczych. Dla przykładu, szukając po słowie kluczowym „IPv6” na stronie MITRE możemy znaleźć sporo podatności występujących w implementacji tego protokołu. Czy rzeczywiście potrzebujemy wsparcia IPv6? Aktualnie adaptacja tego protokołu nie jest jeszcze powszechna, szczególnie w sieci LAN. Jeśli nie pracujemy jako ISP (Internet Service Provider) prawdopodobnie nie mamy potrzeby jego wspierania, tym samym, jeśli wyłączymy jego wsparcie na Access Pointach Wifi zabezpieczymy się przed znanymi i jeszcze nieznanymi podatnościami w implementacji danego vendora.
Zmiana domyślnych poświadczeń
Często urządzenia czy oprogramowanie, które kupujemy trafia do nas z zestawem domyślnych poświadczeń. Ma to szczególne znaczenie w przypadku sprzętu IoT, które czasami nie mają przypisanego swojego administratora w organizacji. Czasami też osoba, która nimi zarządza nie jest świadoma zagrożeń związanych z tymi urządzeniami. Warto jest więc upewnić się, że nasze usługi i urządzenia mają zmienione poświadczenia na inne niż domyślne. Listę przykładowych domyślnych poświadczeń możecie znaleźć poniżej.

Jeśli urządzeń mamy dużo najlepiej jest przeszukać je w poszukiwaniu domyślnych poświadczeń w sposób automatyczny. Możemy w tym celu skorzystać z darmowych dostępnych narzędzi, którymi przeskanujemy sieć i spróbujemy zalogować się do znalezionych usług domyślnymi poświadczeniami (przykładowy opis) albo możemy skorzystać z profesjonalnych, płatnych rozwiązań. Jednym z rozwiązań, które potrafi przeprowadzić taką ocenę jest Forescout, którego oferujemy w ramach naszego portfolio rozwiązań bezpieczeństwa.
Ochrona danych w spoczynku i w transmisji
Warto zadbać także o ochronę danych, zarówno w spoczynku jak i w locie. Jeśli w ramach komunikacji wysyłane są dane wrażliwe zawsze wykorzystujmy protokoły szyfrowane, co zapewni nam tajność przesyłanych danych w przypadku ich podsłuchania przez osoby niepowołane. Zamiast http używajmy HTTPS, zamiast telnetu SSH, zamiast FTP użyjmy FTPS/SFTP.
Co do danych w spoczynku szczególne znaczenie ma zabezpieczenie laptopów i innych urządzeń mobilnych. To one najbardziej narażone są na kradzież czy zgubę, zadbajmy więc o to, żeby dane przechowywane na nich były szyfrowane i to najlepiej metodą Full Disk Encryption. W środowiskach Windows najlepiej sprawdzi się tutaj wbudowany BitLocker, natomiast na systemach Linux można użyć LUKS a dla Mac OS mamy FileVault.
Skąd brać wskazówki na temat utwardzania systemów?
W dzisiejszych czasach ciężko jest być ekspertem od wszystkich systemów operacyjnych, usług, baz danych, wszystkich vendorów sieciowych i chmur obliczeniowych. Tego jest po prostu za dużo. 😊 Na szczęście nie musimy być ekspertem od wszystkiego, żeby zwiększyć poziom bezpieczeństwa naszej organizacji, niezależnie od tego z jakich rozwiązań korzysta.
Naprzeciw temu wyzwaniu wychodzą autorzy publikacji w CIS (Center of Internet Security). Udostępniają oni świetne dokumenty, zwane „CIS Benchmark”, które w prosty sposób opisują jak krok po kroku możemy przeprowadzić hardening danego rozwiązania.
Dokumenty podzielone są per system operacyjny, per usługa, per dana baza danych i pisane są przez ekspertów w swojej dziedzinie. Są łatwe do zrozumienia a każdy rozdział zawiera listę opisującą istotne ustawienia, które warto zmienić w danym systemie operacyjnym np. Windows Server 2016 czy Red Hat Linux w wersji 6. „Benchmarki” dostępne są do pobrania. Do pobrania wymagana jest jednak rejestracja. Dokumenty są dosyć obszerne (na przykład wskazówki dotyczące Windows Server potrafią mieć ponad 1000 stron), ale często są podzielone w taki sposób, żeby łatwo można było wybrać poszczególne podrozdziały, które mają znaczenie w naszej organizacji.
[caption id="attachment_1990" align="aligncenter" width="437"] Przykładowy fragment dokumentu CIS Benchmark dla Exchange 2016[/caption]
 
Oczywiście warto tutaj zauważyć, że zazwyczaj nie mamy potrzeby wprowadzać wszystkich wskazanych w tych dokumentach ustawień. Zalecenia są podzielone na kategorie istotności a także opisany jest potencjalny wpływ zastosowania danego ustawienia. Możemy więc podjąć świadomą decyzję czy daną zmianę powinniśmy wprowadzić czy nie.
Mimo, że dokumenty napisane zostały w ten sposób, żeby zrozumieć je mógł każdy specjalista bezpieczeństwa, niekoniecznie ekspert w danym systemie, na pewno powinniśmy wprowadzać opisane tam zmiany po konsultacji z lokalnym specjalistą odpowiedzialnym za dane zagadnienie w naszej organizacji. Niektóre ustawienia mogą mieć wpływ na powiązane usługi i lepiej jest dmuchać na zimne zamiast później tłumaczyć się z awarii 😊 Oczywiście przed takimi sytuacjami powinien chronić nas dobrze prowadzony proces Zarządzania Zmianą (Change Control), ale zdaję sobie sprawę, że nie każda organizacja taki proces stosuje.
Co prawda zalecenia CIS Benchmark to najlepsze praktyki i z punktu widzenia bezpieczeństwa najlepiej byłoby wdrożyć je wszystkie, ale na koniec i tak musimy patrzeć na nie przez pryzmat naszych potrzeb, polityk i procedur w naszej organizacji.
Automatyzacja procesu sprawdzania zgodności z dobrymi praktykami
Jeśli chcemy zaoszczędzić czas i szybko chcemy sprawdzić czy nasze środowisko jest zgodne z dobrymi praktykami opisanymi w CIS Benchmark może ten proces zautomatyzować.
Z pomocą przychodzi nam tutaj protokół SCAP (Security Content Automation Protocol), który pozwala na automatyczne skanowanie systemów w poszukiwaniu ustawień niezgodnych z dobrymi praktykami. Na stronie projektu OpenSCAP można pobrać narzędzia, które pozwolą nam wykonać takie skanowanie zarówno na maszynie lokalnej jak i na maszynie zdalnej, na przykład wykorzystując SCAP Workbench. W oparciu o analizę możemy później wprowadzić odpowiednie zmiany, żeby zwiększyć poziom bezpieczeństwa naszego serwera czy stacji roboczej.
[caption id="attachment_1991" align="aligncenter" width="494"] Narzędzie SCAP Workbench pozwala nam przeskanować lokalną lub zdalną maszynę pod względem zgodności z dobrymi praktykami[/caption]
 
 
Samo narzędzie jednak nie wystarczy – do skutecznej oceny stanu zgodności z dobrymi praktykami potrzebujemy też definicji reguł w formacie SCAP. Tu możemy wykorzystać na przykład darmowe repozytorium udostępnione przez NIST.
Alternatywnie swoją wersję narzędzia wraz z gotowymi regułami oferuje sama organizacja CIS – dostępna zarówno w wersji darmowej jak i płatnej CIS CAT Lite/Pro. Polecam wypróbować i sprawdzić na ile nasza stacja robocza zgodna jest z najlepszymi praktykami. Po weryfikacji otrzymujemy przejrzysty raport w HTML pokazujący wyniki naszego testu.
[caption id="attachment_1992" align="aligncenter" width="605"] Przykładowy wynik sprawdzenia stacji roboczej Windows narzędziem CIS CAT Lite[/caption]
 
Bezpieczeństwo w chmurze
Jeśli korzystamy z usług chmurowych często producenci tych środowisk udostępniają nam gotowe narzędzia automatyzujące proces „utwardzania” naszych usług, zarówno, jeśli chodzi o rozwiązania IaaS, PaaS jak i SaaS. Dla przykładu takim rozwiązaniem dla chmury Azure jest „Security Center”. Dla uzyskania wszystkich korzyści musimy posiadać wersję płatną, ale już w bezpłatnej może ona dać nam sporo wskazówek na temat tego jak zabezpieczyć nasze środowisko.
[caption id="attachment_1993" align="aligncenter" width="605"] Rekomendacje Azure Security Center[/caption]
Oczywiście Security Center ma dużo więcej możliwości, ale nie jest to tematem tego artykułu.
Utworzenie wzorca
Żeby zapewnić skalowalność naszego przedsięwzięcia dobrze jest zredukować powtarzalne procesy. Dla przykładu, jeśli planujemy utwardzić kilkanaście czy kilkadziesiąt systemów typu Centos dobrze jest zacząć od stworzenia maszyny wzorcowej. Stwórzmy jeden podstawowy obraz maszyny w postaci utwardzonej z wyłączonymi niepotrzebnymi usługami, bez zbędnych aplikacji, niepotrzebnie otwartych portów i z bezpieczną konfiguracją. Potem dla każdego nowego systemu nie musimy zaczynać od nowa a wystarczy skorzystać z istniejącego obrazu. Na tej samej zasadzie można stworzyć baseline konfiguracji urządzeń sieciowych.
Jeśli chodzi o środowiska chmurowe, często dostępne są już gotowe, utwardzone obrazy maszyn wirtualnych. Dla przykładu gotowe maszyny zgodnie z wytycznymi CIS (CIS hardened images) możemy znaleźć w poniższej tabeli.
[caption id="attachment_1994" align="aligncenter" width="605"] Gotowe obrazy maszyn wirtualnych, stworzone przez CIS[/caption]
 
Podsumowanie
Hardening, czy po polsku „utwardzanie” systemów, to proces długotrwały i wymagający dużo pracy, do którego powinniśmy podejść ostrożnie. Najlepiej byłoby, gdyby był wykonywany przez dział bezpieczeństwa w bliskiej kooperacji z działem IT oraz przy wsparciu zarządu. To w jakim stopniu utwardzimy systemy powinno wynikać z naszych potrzeb, polityk i aktualnych priorytetów. W trakcie realizacji dobrze jest postępować zgodnie z procesem Zarządzania Zmianą, który zapewni nam, że odpowiednie osoby zostaną poinformowane o zmianie i że proces w razie wystąpienia awarii będzie możliwy do odwrócenia.
Mam nadzieję, że tym artykułem przybliżyłem w skrócie na czym może polegać hardening. Jeśli potrzebujesz pomocy w realizacji podobnego przedsięwzięcia nie wahaj się skorzystać z doświadczenia profesjonalistów, jakimi są Integrity Partners.
Skontaktuj się z nami!