IDS jako narzędzie analityczne

Scenariusz 2: Fałszywe alarmy

Jeśli chodzi o fałszywe alarmy, to istotna jest kwestia strojenia - możliwość łatwego i szybkiego oczyszczenia listy alarmów z "szumów". Zarządzający ochroną podchodzą do tego problemu na dwa sposoby. Niektórzy preferują ogląd wszystkich alarmów, ale w sposób uporządkowany wg priorytetów. Inni od razu chcą się pozbyć informacji bezużytecznej.

ISS udostępnia dwie łatwe techniki filtrowania zdarzeń. W ramach polityk związanych z sensorami zakładki pozwalają na przesiewanie zdarzeń wysyłanych do konsoli IDS. Każda kombinacja zdarzeń i adresów przeznaczenia musi być wprowadzana oddzielnie. Oznacza to, że jeżeli zarządza się setkami serwerów, można spędzić sporo czasu na selekcjonowaniu zdarzeń. Druga metoda, bardziej typowa, polega na zdecydowaniu, które zdarzenia nie są istotne, i wyłączeniu ich. Jest to jednak nie całkiem bezpieczne, ponieważ nowy system i sieci mogą nie mieć wszystkich najnowszych łatek i zmian konfiguracyjnych. Proponowane przez ISS rozwiązanie może być uciążliwe w dużych sieciach.

Cisco z IDS Management Console umożliwia filtrowanie poszczególnych sygnatur, ale w sposób dość złożony. Rozproszone zarządzanie Cisco pozwala na organizowanie sensorów oraz stosowanie ustawień i zmian konfiguracyjnych na poziomie grup lub całej sieci. Na pierwszy rzut oka to dojrzały i odpowiedni sposób obsługi sieci sensorów. Jednak Cisco nie pozwala na zarządzanie na takim samym poziomie (grupy lub sieci) sygnaturami i filtrami. Tak więc, chcąc zbudować filtr selekcjonujący poszczególne zdarzenia, konieczne jest przechodzenie od sensora do sensora i kopiowanie tych samych informacji.

Interfejs w narzędziu CTR zapewnia wiele reguł, które są używane do rozszerzania i zawężania zakresu alarmów. Jednak tworzenie reguł w rodzaju "ten alarm nie jest istotny" nie jest łatwe.

Filtrowanie zdarzeń w produkcie NFR funkcjonuje zarówno na poziomie serwerów, jak i GUI.

Filtry na poziomie sensorów pozwalają na indywidualne blokowanie danych z części alarmowej i śledczej. Można wyciągnąć dowolne zdarzenie, zdefiniować dla niego filtr i zastosować go do poszczególnych lub wszystkich sensorów. Wysłanie zmian do sensorów sprowadza się do kliknięcia. Przy filtrowaniu alarmów produkt nie oferuje już tak dużego zakresu kontroli.

IDS jako narzędzie analityczne

Ocena rozwiązań

Udogodnienia strojenia zapewniane przez Intrusion zależą od tego, co ma być filtrowane. W przypadku przeprowadzonych testów kontrolę na poziomie sensorów uznano za wystarczająco efektywną i dlatego wybrano tę metodę. Policy Editor pracuje w centralnej konsoli zarządzania i pozwala na budowanie reguł polityki, które selekcjonują adresy IP ze zdarzeń - wg potrzeb. Z poziomu tej konsoli można dokonywać zmian w sensorach i znacznie zawęzić obciążenie alarmami. Intrusion wyraźnie ułatwił zarządzanie regułami polityki w odniesieniu do sensorów, ale i tak nie jest to zadanie łatwe.

Scenariusz 3: Własne alarmy

Nie każdy administrator jest chętny do tworzenia własnych alarmów, ale może to okazać się konieczne. I tak w czasie testów pojawił się robak, który "zamierzał" generować ruch do innych hostów w Internecie. Ruch ten należało przechwycić, utworzyć alarm i oczyścić sieć.

Produkt Cisco zawiera specyficzną metodę edytowania i modyfikowania sygnatur. Zamiast prezentowania sygnatur w postaci prostego pliku tekstowego, udostępnia złożone tablice motorów i parametrów. Kreator, eliminując konieczność znajomości szczegółów, ułatwia generowanie wymyślonych sygnatur. Jednakże narzędzia Cisco do tworzenia sygnatur - choć spisują się dobrze w podstawowych przypadkach - z pewnymi rodzajami sygnatur mogą sobie nie poradzić.

NFR zapewnia silne środowisko projektowe związane z własnym językiem N-Code. NFR dysponuje też wieloma sygnaturami opartymi na regułach. W testach użyto najpierw gotowych sygnatur, a następnie podjęto próbę napisania własnego programu N-Code. Program ten ma bardzo duże możliwości, ale korzystanie z reguł jest znacznie prostsze.

Zrealizowanie tych zadań w przypadku Intrusion i ISS było utrudnione, ponieważ rdzenne sygnatury tych produktów są ukryte. ISS oferuje język Trons, który pozwala dołożyć do bazy istniejących reguł sygnatury w składni Snort. Policy Editor ma ograniczony interfejs GUI, pozwalający na tworzenie nowych sygnatur. Wymagania testów były dostatecznie proste, aby wygenerować niezbędne sygnatury bez wychodzenia poza istniejący interfejs.

Scenariusz 4: Polowanie na robaka

Ze względu na to, że testowana sieć celowo nie była "łatana", pozostawiono lukę Microsoft RCP DCOM. Kwestią czasu było więc jej wykorzystanie przez napastnika. W dużej sieci zdolność do odpowiedzi na pytanie, kto wykorzystał lukę, i szybkie odnalezienie (oraz uszczelnienie) użytych maszyn jest problemem o najwyższym priorytecie. Sprawdzając ten scenariusz, systemy IDS przełączono na tryb śledczy.

W przypadku produktu NFR kluczowe dla jakichkolwiek akcji śledczych jest określenie, jakie zdarzenia są poszukiwane. Po kilku próbach zdobyto adres atakującego, lecz niewiele więcej. Na przykład nie można było zobaczyć numerów portów, które były zaatakowane. GUI trybu śledczego jest także dość skomplikowany: gdy zachodzi potrzeba obejrzenia opisu poszczególnych zdarzeń, trzeba przechodzić do innej części interfejsu.

Test ten wyeksponował także problem wspólny dla wszystkich produktów: brak możliwości obserwowania podejrzanych pakietów, co uniemożliwia kontrolę sygnatur w celu sprawdzenia, czy nie generują one fałszywych rozpoznań.

Narzędzie śledcze Intrusion otwiera się z całym zestawem oglądów śledczej bazy danych wg: atakujących, celu ataku, priorytetu i grup sygnatur. Rozpoczęto od grup sygnatur, rozwijając pierwszy poziom drzewa. Każdą główną grupę sygnatur pokazano wraz z licznikiem zdarzeń. Poszukiwana grupa wyróżniała się bardzo dużą liczbą zdarzeń.

ISS nie zapewnia szybkiego przejścia do potrzebnych sygnatur, ale udostępnia kilka wbudowanych opcji. Analiza zdarzeń wg atakującego tworzy pozycje dla każdego intruza w sieci. Po sortowaniu ich na podstawie liczników, zainfekowane maszyny w sieci pojawiły się na początku listy. ISS powinien umożliwiać także zawężenie kwerendy przez wybranie tylko adresu korporacyjnego IP.

Cisco nie zapewnia tak dobrego czasu odpowiedzi jak ISS, ale ma podobne mechanizmy. W przeglądzie zdarzeń podstawowym wzorcem jest arkusz kalkulacyjny z przesuwalnymi i rozszerzalnymi kolumnami. Cisco Management Center sortuje dane zgodnie z kolumnami i sumuje powtarzające się pozycje. Pozwala to na nawet lepszy ogląd danych niż w ISS.


TOP 200