Poniższy artykuł nie jest bardzo techniczny, ani teoretyczny – w zamian tego jest praktyczny. Uznałem, że może być ciekawym wprowadzeniem dla interesujących się obroną informacji lub osób, które jeszcze nie próbowały tej strony “mocy“. Jeśli jeszcze nie wiesz czy to artykuł dla Ciebie to zainwestuj kilka minut na przeczytanie go, a uwagi zostaw w komentarzu.

1) Defensywa nie jest “sexy“, Ofensywa jest.

Od wielu lat istnieje dogmat mówiący o tym, że poszukiwanie błędów jest “sexy“. Z małymi wyjątkami media, ale również sektor publiczny czy prywatny gloryfikują ofensywę – o nią oparty jest wyścig zbrojeń czy raporty z popularnych testów bezpieczeństwa lub testów penetracyjnych. Za odkryte błędy można otrzymać środki finansowe z tzw. programów “bug bounty“, retweety na twitterze, “lajki” na facebooku. Generalnie ofensywa jest powszechnie znana i uznawana za potrzebną – prawdopodobnie w większości firm, które mają budżet na organizację bezpieczeństwa, główną metodą wydatkowania go są testy bezpieczeństwa i systemy bezpieczeństwa.

Poza testami bezpieczeństwa, których wynikiem zazwyczaj jest raport z wcale nie “zieloną” listą podatności, firmy inwestują w systemy bezpieczeństwa, m.in. systemy bezpieczeństwa sieciowego (od drugiej warstwy OSI/ISO w górę). Pomijając wszystkie formalne/procesowe metody zabezpieczeń to wymienione systemy odpowiadają za poziom bezpieczeństwa w firmie. *beep!* Systemy bezpieczeństwa dają tylko potencjał pozwalający zbliżyć się do oczekiwanego poziomu bezpieczeństwa, pod warunkiem, że zostały w sposób przemyślany wybrane, przede wszystkim z wyłączeniem takich kryterium jak: położenie w kwadratach Gartnera czy wyników testów NSS Labs. Wybór odpowiedniego systemu bezpieczeństwa, który spełnia nasze wymagania pod kątem realnych możliwości wykrywania, powstrzymywania, blokowania, logowania zdarzeń, ich analizy oraz integracji z innymi systemami nie może zostać oparty o wymieniony kwadrat Gartnera czy wyniki testów NSS Labs gdyż one tego nie uwzględniają w kontekście firmy/organizacji, w których chcecie je zastosować.

Kiedy mamy już wyniki testów bezpieczeństwa, może nawet analiz ryzyka i systemy bezpieczeństwa to nie koniec, to dopiero początek by myśleć o organizacji obrony, defensywy. Zdecydowanie defensywa “sexy” nie jest, ale jest warta swojej ceny. Zastanówmy się ile raportów z testów bezpieczeństwa nie jesteśmy w stanie szybko wyczyścić (usunąć podatności w terminie adekwatnym do kategoryzacji podatności), analogicznie jak to wygląda dla procesu zarządzania podatnościami nie odkrytymi w ramach testów bezpieczeństwa tylko w ramach publicznie dostępnej wiedzy o błędach w używanych przez nas oprogramowaniu. Często ten proces również realizowany jest w ramach defensywnych zadań zespołów bezpieczeństwa. Zadaniem obrońców jest m.in. skrócenie okresu pomiędzy odkryciem podatności, a jej usunięciem. Często usunięcie nie jest trywialne, zajmie za dużo czasu/zasobów, trzeba coś zrobić by uniemożliwić jej wykorzystanie oraz skutecznie identyfikować próby – dlatego stosuje się własne sygnatury na systemach IDS/IPS czy WAF (ang. Web Application Firewall).

Za skuteczne powstrzymanie napastników dużo trudniej o “pochwałę” i nagrody jak ma to miejsce w przypadku znalezienia podatności. Natomiast firma nie będzie bezpieczniejsza jeśli nie będzie choć w podstawowym zakresie działać obrona – sam raport z testów bezpieczeństwa, bez adekwatnych do niego działań, nie jest w stanie nikogo obronić.

Aktualnie mówimy o elementach działań reaktywnych, którym bardzo daleko do modelu pro aktywnego. Uważam, że to kolejny powód, dla którego “obrona” jest mniej popularna od “ataku” – wymaga długofalowej, systematycznej pracy, kiedy aby przeprowadzić “atak” (w postaci testu bezpieczeństwa) potrzebujemy prostych narzędzi, dostępu do klawiatury i kilku minut.

Jeśli “defensywa” jeszcze Cię nie zmęczyła, przejdźmy do drugiego aspektu. Zorganizujmy jednostkę odpowiedzialną za obronę w oparciu o normy!

2) Chcę SOC! – wg. ISO 27035 lub innej normy/standardu.

Standardy, normy czy przewodniki na pewno będą pomocne w zorganizowaniu tzw. Security Operation Center, które w okresie od 0 do 24h na dobę będzie monitorować bezpieczeństwo firmy lub ich klientów (w zależności od przyjętego zakresu). Jeśli nie mamy dużego doświadczenie w organizacji obrony (wdrażanie i konfiguracja firewalli, VPNów, itp. nie liczy się) to mam dla Ciebie kilka sugestii zanim pochłoną Cię dziesiątki-setki stron lektury w postaci norm czy standardów:

• rzadko (nigdy?) obrona jest kompletna (na danym poziomie jej dojrzałości/zaawansowania) w terminie kiedy rusza biznes, który to mamy bronić, dlatego na początku skup się na działaniach, które możesz skończyć najszybciej i dadzą jak najwięcej (przykładem jest tu np. odwieczny dylemat czy najpierw SIEM czy wcześniej Log Management? IDS vs. IPS vs. WAF?)
• nie przeceniaj potencjalnych napastników, jeśli skupisz się początkowo na tych z najwyższej półki to jest spora szansa, że przegrasz ze “script-kiddies”
• nie wybieraj narzędzi (w tym systemów bezpieczeństwa), które nie pasują do całej układanki, musi być realny pomysł na ich integrację, a zdarzenia, które wygenerują muszą dać się wyjaśniać (bez szybkiej ścieżki analizy zdarzeń, rozpatrywania czy jest to fałszywy-pozytyw czy atak, itp., skończysz na używaniu systemu jako narzędzia do tworzenia raportów dla kadry zarządzającej – tylko czy chcesz tak skończyć i czy to pozwala skutecznie bronić firmę lub jej klientów?)
• na pierwszych poziomach dojrzałości/zaawansowania nie analizuj alarmów z sygnatur na mało prawdopodobne ataki dla zasobów które chronisz (np. masz tylko Apache, nie patrz na IIS) czy też wykrywania anomalii – na początku nie zrobisz z tego użytku, a zajmie to czas, który możesz wykorzystać na podnoszenie dojrzałości do poziomu, w którym już zrobisz z tego użytek
• jeśli nie potrafisz wyjaśnić danego alarmu to prawdopodobnie go nie potrzebujesz oglądać (lub nie przygotowałeś się do tego – UWAGA: złodziej czasu)

Oszczędzaj czas dedykowany pracy operacyjnej by nie zabrakło go na rozwój – bez niego nie ma mowy o ciągłym monitoringu bezpieczeństwa, który powinien być rozumiany jako co najmniej doganianie zmieniającego się ciągle modelu zagrożeń.

3) Musisz być przygotowany do obsługi incydentu.

Podczas wielu prezentacji, szkoleń (w tym odnośnie ISO 27035 – dedykowanie zarządzaniu incydentami bezpieczeństwa) i regulacjach czytamy, że organizując procesy obsługi incydentów bezpieczeństwa, które są nieodłącznym elementem defensywy, należy przygotować się do tego pisząc np. procedury obsługi. Jeśli nie korzystacie z własnych doświadczeń lub zapożyczonych od np. zew. konsultanta to przygotowanie procedur może stanowić nie lada wyzwanie. W takich sytuacjach proponuję kilka dróg, które można obrać:

• zintegruj działania zespołu ofensywnego z zespołem defensywnym i podczas testów bezpieczeństwa szukaj metod identyfikacji takiego ataku, metod zablokowania go, powstrzymania i kolejnych kroków jeśli atak miałby zakończyć się powodzeniem, sprawdź czy potrafisz zabezpieczyć ślady, analizować je, wyciągać wnioski, czego brakuje i jak to osiągnąć (nawet jeśli nie masz czasu robić tego przy każdym teście, zrób takie ćwiczenie przy każdym teście nowego systemu/procesu, choćby raz)
• ćwicz “na sucho” bez praktycznej symulacji ataku, ale weryfikuj czy jesteś w stanie przeprowadzić kroki, które zakładasz (pozwoli to ocenić realną zdolność do reakcji, a to czy w praktyce wszystko pójdzie jak założyliśmy wyjdzie w boju)
• twórz procedury obsługi w oparciu o obsługę incydentów bezpieczeństwa, uzupełniaj je o to co chcesz poprawić następnym razem
• spisz generalne zasady obsługi incydentów bezpieczeństwa i zawsze staraj się ich trzymać, nawet jeśli jest naprawdę “gorąco”, nie trać głowy, nie podpalaj się nowymi pomysłami, zawsze je oceniaj pod kątem realnego wpływu na wynik obsługi incydentu – jeśli sposób obsługi danego typu incydentu nie jest dobrze opisany to jego obsługa może przypominać burzę mózgów, nie daj się zwariować, będą przychodziły pomysły dobre/złe jak i absurdalne/genialne

Podsumowanie

Moim celem było przekazanie garści praktycznych sugestii jeśli myślisz o organizacji realnej obrony informacji. Zapraszam do komentowania oraz zgłaszanie sugestii najbardziej interesujących aspektów – tych technicznych, organizacyjnych czy też ludzkich. Kolejne artykułu z tej serii mają odpowiadać na Wasze potrzeby.