Jeśli system bezpieczeństwa generuje dziennie 60 alertów, a przez kilka tygodni administrator widzi, że żaden z nich nie wymaga podjęcia działań, to poźniej zaczyna ignorować ostrzeżenia. Bo działy IT mają wiele innych zadań i często zbyt mało czasu lub zasobów do skrupulatnego analizowania każdego alertu. Oczywiście, każde urządzenie zabezpieczające można skonfigurować i dostroić tak, aby zminimalizować liczbę generowanych alertów. Ale jest to pracochłonne i powoduje dodatkowe obciążenie administratorów IT, które w praktyce niechętnie podejmują to zadanie. Taka jest rzeczywistość.

Pracownicy działów IT w firmach najczęściej skupiają się na zadaniach, które zapewniają ciągłość działania biznesu, wspierają jego wzrost i generują przychody.

Zobacz również:

• Apple ostrzega użytkowników w 92 krajach. Uwaga na ataki szpiegowskie
• IBM Security QRadar SIEM pomoże zarządzić globalną strukturą odpowiedzialną za bezpieczeństwo

Oprócz tego inwestycje w systemy zabezpieczeń z reguły koncentrują się obecnie na rozwiązaniach, które mają zapewnić zgodność z przepisami prawnymi i wymogami organów regulacyjnych. W efekcie

instaluje się odpowiednie urządzenie, bo musi ono być w systemie, a zapomina o jego dostrojeniu. Nie pomagają w tym dostawcy, którzy reklamują urządzenia jako gotowe do pracy prosto z pudełka: "set it and forget it" (zainstaluj i zapomnij).

Niestety domyślne ustawienia wprowadzone przez dostawcę często nie sprawdzają się po wdrożeniu rozwiązania do aktywnego środowiska produkcyjnego. W rezultacie, administratora IT zalewa fala fałszywie pozytywnych alertów, które są szumem utrudniającym wyłowienie i zidentyfikowanie sygnałów o zagrożeniach.

A niektóre z ignorowanych sygnałów są ważnymi ostrzeżeniami.

Zgodnie z raportem Verizon, już w 2010 roku, aż w 86% firm, które padły ofiarą naruszeń danych, informacje o zagrożeniach zostały wcześniej odnotowane w dziennikach aktywności, ale zignorowane.

W ostatnim czasie doskonałym przykładem ilustrującym ten problem był skuteczny atak na firmę Target. W momencie, gdy bezpieczeństwo zostało naruszone, centrum monitoringu systemu zostało zalane alertami przez urządzenie FireEye. Ale ostrzeżenia te zostały zignorowane.

Przeprowadzone później przez Target badania wykazały, że po wejściu do firmowej sieci tylko niewielka część aktywności hakerów została zarejestrowana w dzienniku aktywności i przekazana w formie alertu do pracowników zajmujących się bezpieczeństwem. Ostrzeżenia te sprawdzono, ale w oparciu o ich standardową interpretację stwierdzono, że nie wymagają one natychmiastowej reakcji.

Błąd? Łatwo teraz tak powiedzieć, ale wtedy centrum monitoringu bezpieczeństwa w firmie Target po prostu wykonywało rutynowe czynności. Zweryfikowano alert, nie stwierdzono cech ostrzeżenia o wysokim priorytecie i zajęto się innymi zadaniami. Takie sytuacje zdarzają się w wielu firmach na całym świecie codziennie. Różnica polega na tym, że o naruszeniu w Target dowiedziała się opinia publiczna.

Dave DeWalt z FireEye twierdzi, że o ile urządzenia są w stanie zidentyfikować potencjalne zagrożenia naruszenia danych o kluczowym znaczeniu, o tyle ludzie nie są w stanie odpowiednio na nie zareagować ze względu na nadmiar informacji, który znacznie utrudnia proces weryfikacji alertów.

Nadmiar danych to obciążenie dla działów IT, ale problemem jest również to, że większość dostępnych na rynku rozwiązań do analizy zagrożeń nie wykorzystuje inteligentnych mechanizmów ochrony. Najczęściej ich działanie polega po prostu na agregacji raportów dotyczących złośliwego oprogramowania i spamu, fałszywych adresów IP i błędów, których jednak nie można powiązać z konkretnym środowiskiem IT.

Dostępne rozwiązania z reguły dają ogólny przegląd zagrożeń, są świetnym i potrzebnym źródłem danych, ale samodzielnie nie są w stanie zapewnić pełnej ochrony.

Ochrona danych i dzienniki aktywności

Największym problemem jest zbyt niski wskaźnik stosunku sygnału do szumu. Pojawia się, gdy brakuje mechanizmów umożliwiających przetwarzanie informacji o incydentach w taki sposób, by można było wykryć zdarzenia mające istotne znaczenie dla bezpieczeństwa danych.

Bo często drobne powiązania między incydentami, które na pierwszy rzut oka wyglądają jak szum przypadkowych zdarzeń o małym znaczeniu, mogą być podstawą do wykrycia realnego zagrożenia.

Dobrym przykładem są trojany zawierające keylogger takie, jak Zeus, których częstotliwość występowania jest duża, ale z reguły są traktowane jako niewielkie zagrożenie dla systemów biznesowych w firmach. Wynika to z założenia, że trojany takie mają na celu kradzież danych użytkowników indywidualnych takich, jak hasła dostępu do osobistych kont bankowych itp.

Ale tego typu oprogramowanie może zostać wykorzystane do kradzieży danych umożliwiających logowanie do systemów IT. Tak było w przypadku Target, gdy pracownik firmy Fazio Mechanical zalogował się do jej serwisu wsparcia przeznaczonego dla zewnętrznych dostawców, co w efekcie doprowadziło do kradzieży danych służących do uwierzytelniania kont kluczowych dla działalności biznesowej firmy.

Podobnie jest też w wypadku spamu, który z reguły jest traktowany jako mało znaczące zagrożenie dla bezpieczeństwa. Ale aktywny bot wysyłający spam z dużą częstotliwością może sprawić, że zewnętrzny adres IP firmy trafi na czarną listę. A to oznacza pozbawienie pracowników narzędzi komunikacji, zmniejsza ich wydajność pracy oraz negatywnie wpływa na wizerunek firmy.

Warto też zauważyć, że firmy często gromadzą i na wszelki wypadek przechowują dużo danych bez jasnego celu dotyczącego ich wykorzystania. Np. dane dotyczące ruchu sieciowego, dane syslog dla każdej sesji, dane logowania z różnych serwerów aplikacji lub wiadomości syslog związane z działaniem blokujących dostęp reguł zapory sieciowej.

Ta sama sytuacja ma miejsce w przypadku wiadomości syslog generowanych dla każdego zablokowanego adresu URL. Niemal zawsze zakłada się, że to pracownik chciał naruszyć zasady polityki bezpieczeństwa firmy, choć zdarzenie może być równie dobrze wywołane przez bota lub zewnętrznego hakera.

"Firmy gromadzą mnóstwo informacji w nadziei, że kiedyś ktoś w firmie z tych danych skorzysta. Niestety, zazwyczaj wraca się do nich tylko podczas śledztwa spowodowanego naruszeniem danych" mówi Oliver Tavakoli, dyrektor ds. technologii w Vectra Networks.

Cała sztuka nie polega więc na tym, aby zgromadzić możliwie najwięcej danych, lecz na tym, aby zgromadzić właściwe dane we właściwym czasie. Oliver Tavakoli sugeruje przyjęcie strategii właściwej dla osiągnięcia tego celu. Jej kluczowym założeniem powinno być określenie przez firmę priorytetów w odniesieniu do monitorowanych przez firmę danych.

W pierwszej kolejności warto dowiedzieć się, gdzie zlokalizowane są dane najważniejsze dla firmy, jak można uzyskać do nich dostęp i co zrobić, aby je chronić. Następnie, należy zidentyfikować główną powierzchnię ataku i obliczyć prawdopodobieństwo jego wystąpienia.

Miejscem ataku są często urządzenia wykorzystywane przez pracowników, ale równie dobrze zagrożenie może pochodzić od wykonawców, a także gościnnych sieci bezprzewodowych czy portali sieciowych uzyskujących dostęp do systemów lub kont wewnętrznych firmy.

Ważne jest także monitorowanie systemów wewnętrznych pod kątem anormalnych zachowań, zwłaszcza w kontekście ich komunikacji między sobą (np. serwera aplikacji z bazą danych), jak również ich komunikacji z systemami zewnętrznymi. Jeśli nastąpi atak na te systemy, to każdy alert dotyczący zdarzeń zarejestrowanych między nimi powinien zostać zbadany. Rozwiązania bezpieczeństwa wymagają jednak właściwej konfiguracji, aby generowały alerty dotyczące wyłącznie nietypowych zdarzeń. Kluczowym warunkiem jest zatem określenie punktu wyjścia.

Nie wystarczy jednak samo monitorowanie przychodzącego ruchu pod kątem anormalnych zdarzeń. W równym stopniu należy monitorować ruch wychodzący, bo to w tym miejscu odbywa się komunikacja między systemami dowodzenia i kontroli, i to tutaj można zaobserwować zjawisko eksfiltracji danych.

Inne możliwe anomalie

Ataki na system z reguły poprzedza rekonesans. Są jego dwa rodzaje: szybki i zauważalny albo powolny i dyskretny. Powolny rekonesans można wykryć, gdy host w sieci kontaktuje się z wieloma wewnętrznymi adresami IP, które w ostatnim czasie pozostawały nieaktywne. Takie skanowanie to długi proces, trwający wiele godzin lub dni, w przeciwieństwie do skanowania portów trwającego kilka minut lub, maksymalnie, kilka godzin. Aby skutecznie wykryć takie działania zwiadowcze, trzeba ignorować alerty dotyczące prób kontaktu z systemami, które nie reagują na skanowania, ale są aktywne.

Z kolei ataki typu brute-force można wykryć, dokładnie weryfikując dzienniki aktywności dla serwerów zintegrowanych z firmową infrastrukturą zarządzania tożsamością i dostępem (IdAM), np. Microsoft Active Directory, albo obserwując ruch w sieci wykorzystujący różne protokoły (SMB, Kerberos, RDP, VNC, SSH, HTTP, HTTPS).

Wykrycie niewielkiej eksfiltracji danych jest z reguły bardzo trudne, ale warto przygotować strategię umożliwiającą wykrycie i zablokowanie dużych wycieków.

„Korzystając z wzorców typowego ruchu w sieci, można wykryć anomalie takie jak sytuacja, gdy jakiś host pozyskuje duże ilości danych z serwerów wewnętrznych, a następnie próbuje przesyłać je na zewnątrz” mówi Olivier Tavakoli.

Często sprawdza się też weryfikacja przepływów znacznej ilości danych wychodzących z hostów w niestandardowych kanałach (np. 10 Gb danych wychodzących z serwera FTP). Im większy wolumen danych otrzymywanych i wysyłanych, tym większe zagrożenie i większa potrzeba kontroli. Alerty dla tego rodzaju zdarzeń powinny być oznaczone najwyższym priorytetem, gdyż to ostatni krok w łańcuchu ataku. „Najczęściej jest to ostatni moment na uniknięcie utraty danych lub przynajmniej maksymalne złagodzenie jego skutków” radzi Olivier Tavakoli.

Mniej znaczy więcej

Większość firm dysponuje obecnie dość zaawansowaną infrastrukturą bezpieczeństwa, zatem pole do działania w kontekście konfiguracji i dostrajania urządzeń, aby efektywnie filtrowały szum informacyjny jest naprawdę szerokie. Trzeba jednak podkreślić, że kluczem do rozwiązania problemu jest identyfikacja najbardziej krytycznych danych i kierunków potencjalnego ataku.

Dla przykładu, jeśli największą wartość mają dane zgromadzone w bazie Oracle, warto rzetelnie podejść do kwestii identyfikacji punktu wyjściowego: do jakich hostów baza jest podłączona, jakie kwerendy wykonuje regularnie i jakie są typowe ilości danych generowanych w wyniku wykonywania tych kwerend.

Określenie takich parametrów umożliwia szybką reakcję i intuicyjne sprawdzenie, czy liczba stu tysięcy hostów łączących się z bazą danych Oracle wykonującą pięć milionów kwerend dziennie to normalny wskaźnik, czy już anomalia.

Kontrola miejsc eksfiltracji danych, jest jednym z przykładów dobrych praktyk bezpieczeństwa. Poprzez identyfikację warunków wyjściowych w kontekście ilości danych wysyłanych przez hosty na zewnątrz i ustalenie limitów tych danych, można sprawić, że alerty będą wyzwalane automatycznie przy przekroczeniu normalnych poziomów.

Im większa automatyzacja procesów realizowanych w czasie rzeczywistym, tym skuteczniejsza ochrona przed atakami i lepsze zapobieganie ich skutkom.

A czy są strumienie danych, które można bezpiecznie zignorować? Tak, ale jest ich niewiele i trudno tu podać przykład, bo zależy to od specyfiki firmy.

„Zdarzeń, które można bezpiecznie zignorować jest w rzeczywistości bardzo niewiele, dlatego warto weryfikować oprogramowanie mające wesprzeć automatyzację procesów identyfikacji zagrożeń. Ważne jest, by działało ono w czasie rzeczywistym. Każda minuta spóźnienia to większy ryzyko dla firmy” podsumowuje Oliver Tavakoli.