Jak często dokonujesz spontanicznych zakupów pod wpływem efektownej reklamy, a potem pożądany przedmiot zbiera kurz w szafie, spiżarni lub garażu do następnego generalnego porządku lub przeprowadzki? W rezultacie — rozczarowanie spowodowane niespełnionymi oczekiwaniami i wydanymi na marne pieniędzmi. Znacznie gorzej, gdy coś podobnego przydarza się w biznesie. Często sztuczki marketingowe są tak dobre, że firmy nabywają kosztowne rozwiązanie, nie widząc pełnego obrazu jego zastosowania. Tymczasem testy próbne systemu pomagają zrozumieć, jak przygotować infrastrukturę do integracji, jaki funkcjonalność i w jakim zakresie warto wdrażać. Dzięki temu można uniknąć ogromnej liczby problemów związanych z wyborem produktu „w ciemno”. Co więcej, wdrożenie po dobrze przeprowadzonym „pilocie” przyniesie inżynierom znacznie mniej zniszczonych komórek nerwowych i siwych włosów. Zastanówmy się, dlaczego testowanie pilotażowe jest tak ważne dla udanego projektu, na przykładzie popularnego narzędzia do kontroli dostępu do sieci korporacyjnej — Cisco ISE. Przyjrzyjmy się zarówno typowym, jak i nietypowym zastosowaniom rozwiązania, które spotkaliśmy w naszej praktyce.
Cisco ISE — „Radius-serwer na sterydach”
Cisco Identity Services Engine (ISE) to platforma do budowy systemu kontroli dostępu do lokalnej sieci komputerowej organizacji. W społeczności ekspertów produkt zyskał miano „radius-servera na sterydach” ze względu na swoje właściwości. Dlaczego tak? W zasadzie rozwiązanie jest serwerem Radius, do którego dodano ogromną ilość dodatkowych usług i „ficzerów”, które pozwalają na uzyskanie dużej ilości kontekstowych informacji i zastosowanie zebranych danych w politykach dostępu.
Podobnie jak każdy inny serwer Radius, Cisco ISE współdziała z urządzeniami sieciowymi na poziomie dostępu, zbiera informacje o wszystkich próbach podłączenia do sieci korporacyjnej i na podstawie polityk uwierzytelniania i autoryzacji decyduje, czy wpuścić użytkowników do sieci lokalnej. Jednak możliwość profilowania, ładowania, integracji z innymi rozwiązaniami bezpieczeństwa informacji pozwala znacznie skomplikować logikę polityki autoryzacji, a tym samym rozwiązywać dość trudne i interesujące zadania.
Wdrażać, nie pilotażować: dlaczego testowanie jest potrzebne?
Wartość testów pilotażowych polega na pokazaniu wszystkich możliwości systemu w konkretnej infrastrukturze danej organizacji. Jestem przekonany, że testowanie Cisco ISE przed wdrożeniem jest korzystne dla wszystkich uczestników projektu i oto dlaczego.
Dla integratorów to daje jasny obraz oczekiwań klienta i pomaga w opracowaniu poprawnego zadania technicznego, zawierającego znacznie więcej szczegółów niż typowe stwierdzenie „zróbcie tak, żeby wszystko było dobrze”. „Pilot” pozwala nam poczuć wszystkie trudności klienta, zrozumieć, jakie zadania są dla niego priorytetowe, a które są drugorzędne. To doskonała okazja, aby wcześniej ustalić, jaki sprzęt jest używany w organizacji, jak będzie przebiegać wdrożenie, na jakich stronach, gdzie są one zlokalizowane itd.
Klienci podczas testów pilotażowych widzą rzeczywisty system w działaniu, zapoznają się z jego interfejsem, mogą sprawdzić, czy jest kompatybilny z posiadanym przez nich sprzętem i uzyskać całościowy obraz tego, jak rozwiązanie będzie działać po pełnym wdrożeniu. „Pilot” to moment, w którym można dostrzec wszystkie „pułapki”, z którymi na pewno przyjdzie się zmierzyć podczas integracji, i zdecydować, ile licencji należy zakupić.
Co może „pojawić się” podczas „pilota”?
Jak więc właściwie przygotować się do wdrożenia Cisco ISE? Z naszego doświadczenia wynika, że istnieje 4 podstawowe kwestie, które należy wziąć pod uwagę podczas testowania pilotażowego systemu.
Format
Na początku należy określić, w jakim formacie będzie wdrażany system: fizycznym czy wirtualnym appliance. Każda z opcji ma swoje zalety i wady. Na przykład, mocną stroną fizycznego appliance jest przewidywalna wydajność, jednak nie można zapominać, że takie urządzenia z czasem się starzeją. Wirtualne appliance są mniej przewidywalne, ponieważ zależą od sprzętu, na którym uruchomiona jest środowisko wirtualizacji, ale mają poważny plus: w przypadku dostępności wsparcia, zawsze można je zaktualizować do najnowszej wersji.
Czy Twoje urządzenie sieciowe jest kompatybilne z Cisco ISE?
Oczywiście, idealnym scenariuszem byłoby podłączenie do systemu całego sprzętu jednocześnie. Jednak nie zawsze jest to możliwe, ponieważ wiele organizacji nadal korzysta z niezarządzanych przełączników lub przełączników, które nie obsługują części technologii, na których działa Cisco ISE. Mówiąc o tym, nie chodzi tylko o przełączniki, mogą to być także kontrolery sieci bezprzewodowej, VPN-huby i inne urządzenia, do których podłączają się użytkownicy. W mojej praktyce zdarzały się przypadki, kiedy po prezentacji systemu w celu jego pełnego wdrożenia klient wymieniał praktycznie cały park przełączników dostępowych na nowoczesny sprzęt Cisco. Aby uniknąć nieprzyjemnych niespodzianek, warto wcześniej sprawdzić, jak wiele sprzętu nie jest obsługiwane.
Czy wszystkie Twoje urządzenia są standardowe?
W każdej sieci znajdują się standardowe urządzenia, z którymi nie powinno być trudności w podłączeniu: zautomatyzowane stanowiska pracy, telefony IP, punkty dostępowe Wi-Fi, kamery wideo i tym podobne. Może się jednak zdarzyć, że do LAN-u trzeba podłączyć urządzenia niestandardowe, na przykład konwertery sygnałów z RS232/Ethernet, interfejsy źródeł zasilania UPS, różne urządzenia technologiczne itp. Ważne jest, aby wcześniej określić listę takich urządzeń, aby na etapie wdrożenia mieć już zrozumienie, jak technicznie będą współpracować z Cisco ISE.
Konstruktywny dialog z informatykami
Często klientami Cisco ISE są działy bezpieczeństwa, podczas gdy za konfigurację przełączników dostępowych i Active Directory zazwyczaj odpowiadają działy IT. Dlatego produktywna współpraca między specjalistami ds. bezpieczeństwa a informatykami to jeden z ważniejszych warunków bezproblemowego wdrożenia systemu. Jeśli ci ostatni podchodzą do integracji 'wrogo', warto wyjaśnić im, w jaki sposób to rozwiązanie przyniesie korzyści departamentowi IT.
Top 5 przypadków użycia Cisco ISE
Z naszego doświadczenia wynika, że potrzebne funkcjonalności systemu również ujawniają się na etapie testów pilotażowych. Poniżej przedstawiamy kilka najpopularniejszych oraz mniej powszechnych przypadków użycia rozwiązania.
Bezpieczny dostęp do LAN-u przewodowego z EAP-TLS
Jak pokazują wyniki badań naszych pentesterów, stosunkowo często do włamania do sieci firmy przestępcy wykorzystują zwykłe gniazdka, do których podłączone są drukarki, telefony, kamery IP, punkty Wi-Fi i inne nieosobiste urządzenia sieciowe. Dlatego nawet gdy dostęp do sieci odbywa się na bazie technologii dot1x, ale wykorzystywane są alternatywne protokoły bez użycia certyfikatów potwierdzających autentyczność użytkowników, istnieje duże prawdopodobieństwo udanego ataku z przechwytywaniem sesji i łamaniem haseł. W przypadku Cisco ISE zhakowanie certyfikatu będzie znacznie trudniejsze — hakerzy będą potrzebować znacznie większej mocy obliczeniowej, więc ten przypadek jest dość skuteczny.
Bezprzewodowy dostęp Dual-SSID
Istota tego scenariusza polega na użyciu 2 identyfikatorów sieci (SSID). Jeden z nich można umownie nazwać „gościnnym”. Poprzez niego do sieci bezprzewodowej mogą wchodzić zarówno goście, jak i pracownicy firmy. Ci ostatni, próbując się połączyć, są przekierowywani na specjalny portal, gdzie odbywa się provisioning. To znaczy, że użytkownik otrzymuje certyfikat i następuje konfiguracja jego osobistego urządzenia do automatycznego ponownego łączenia się z drugim SSID, w którym już używane jest EAP-TLS ze wszystkimi zaletami pierwszego przypadku.
MAC Authentication Bypass i profilowanie
Kolejny popularny przypadek dotyczy automatycznego określania typu podłączanego urządzenia i stosowania odpowiednich ograniczeń do niego. Co jest w tym interesujące? Otóż nadal istnieje całkiem sporo urządzeń, które nie wspierają autoryzacji według protokołu 802.1X. Dlatego dopuszczanie takich urządzeń do sieci odbywa się przez adres MAC, który dość łatwo podrobić. Tutaj z pomocą przychodzi Cisco ISE: za pomocą systemu można zobaczyć, jak urządzenie zachowuje się w sieci, sporządzić jego profil i przypisać go do grupy innych urządzeń, na przykład telefonu IP i stacji roboczej. W przypadku próby oszustwa przez przestępcę polegającego na podrobieniu adresu MAC i połączeniu się z siecią system zauważy, że profil urządzenia uległ zmianie, wyśle sygnał o podejrzanym zachowaniu i nie wpuści podejrzanego użytkownika do sieci.
EAP-Chaining
Technologia EAP-Chaining oznacza sekwencyjną autoryzację roboczego komputera i konta użytkownika. Ten przypadek zyskał dużą popularność, ponieważ w wielu firmach nadal nie jest mile widziane łączenie osobistych gadżetów pracowników z korporacyjną siecią LAN. Stosując takie podejście do autoryzacji, można sprawdzić, czy konkretna stacja robocza jest członkiem domeny. W przypadku negatywnego wyniku użytkownik nie uzyska dostępu do sieci lub zaloguje się z pewnymi ograniczeniami.
Posturing
W tym przypadku mówimy o ocenie zgodności oprogramowania z wymaganiami bezpieczeństwa informacji. Dzięki tej technologii można zweryfikować, czy oprogramowanie na stacji roboczej jest aktualne, czy zainstalowane są środki ochrony, czy skonfigurowano zaporę sieciową itp. Co ciekawe, ta technologia pozwala również na rozwiązanie innych zadań, które nie są związane z bezpieczeństwem, takich jak sprawdzenie obecności wymaganych plików lub instalacja oprogramowania ogólnosystemowego.
Rzadziej spotykane są również takie scenariusze użycia Cisco ISE, jak kontrola dostępu z pełną autoryzacją domeny (Passive ID), mikroskalowanie oparte na SGT oraz integracja z systemami zarządzania urządzeniami mobilnymi (MDM) oraz skanerami podatności (Vulnerability Scanner).
Nietypowe projekty: jak jeszcze Cisco ISE może być przydatne, czyli 3 rzadkie przypadki z naszej praktyki
Kontrola dostępu do serwerów opartych na Linuxie
Pewnego razu rozwiązywaliśmy dość nietypowy przypadek dla jednego z naszych klientów, który już miał wdrożony system Cisco ISE: musieliśmy znaleźć sposób na kontrolowanie działań użytkowników (głównie administratorów) na serwerach z zainstalowanym systemem Linux. W poszukiwaniu odpowiedzi wpadliśmy na pomysł wykorzystania wolnego oprogramowania PAM Radius Module, które umożliwia logowanie się na serwery działające pod kontrolą Linux z autoryzacją na zewnętrznym serwerze RADIUS. Wszystko w tym planie byłoby w porządku, gdyby nie jedno „ale”: serwer RADIUS, wysyłając odpowiedź na żądanie autoryzacji, zwraca tylko nazwę konta i wynik — assess accepted lub assess rejected. Tymczasem do autoryzacji w Linuxie konieczne jest przypisanie przynajmniej jeszcze jednego parametru — home directory, aby użytkownik mógł w końcu gdzieś trafić. Nie znaleźliśmy sposobu, by zwrócić to jako atrybut RADIUS, więc napisaliśmy specjalny skrypt do zdalnego tworzenia kont na hostach w półautomatycznym trybie. To zadanie było całkowicie wykonalne, ponieważ mieliśmy do czynienia z kontami administratorów, których liczba nie była zbyt duża. Następnie użytkownicy logowali się do potrzebnego urządzenia, a następnie przydzielano im niezbędny dostęp. Pojawia się uzasadnione pytanie: czy w takich przypadkach konieczne jest użycie właśnie Cisco ISE? W rzeczywistości nie — wystarczy każdy serwer RADIUS, ale ponieważ klient miał już ten system, po prostu dodaliśmy do niego nową funkcjonalność.
Inwentaryzacja „sprzętu” i oprogramowania w LAN
Pewnego razu pracowaliśmy nad projektem dostawy Cisco ISE dla jednego klienta bez wcześniejszego „pilota”. Nie było jasnych wymagań dotyczących rozwiązania, a dodatkowo mieliśmy do czynienia z płaską, niesegregowaną siecią, co utrudniało nam zadanie. W trakcie projektu skonfigurowaliśmy wszystkie możliwe metody profilowania, które wspierała sieć: NetFlow, DHCP, SNMP, integracja z AD itp. Ostatecznie skonfigurowano dostęp przez MAR, co pozwoliło na dostęp do sieci nawet przy nieudanej autoryzacji. To znaczy, że nawet jeśli autoryzacja nie była pomyślna, system mimo to wpuszczał użytkownika do sieci, zbierał informacje o nim i zapisywał je w bazie danych ISE. Taki monitoring sieci przez kilka tygodni pomógł nam zidentyfikować podłączone systemy i nieosobiste urządzenia oraz wypracować podejście do ich segmentacji. Po tym dodatkowo skonfigurowaliśmy sharowanie w celu zainstalowania agenta na stacjach roboczych, żeby zbierać informacje o zainstalowanym oprogramowaniu. Co z tego wynikło? Udało nam się segmentować sieć i określić listę oprogramowania, które należało usunąć z stacji roboczych. Nie ukrywam, że dalsze zadania dotyczące przypisywania użytkowników do grup domenowych i ograniczania praw dostępu zajęły nam sporo czasu, ale dzięki temu zdobyliśmy pełen obraz tego, jakie „sprzęty” były w sieci u klienta. Przy okazji, to nie było trudne dzięki dobrej pracy profilowania „out of the box”. A tam, gdzie profilowanie nie pomogło, sami przyglądaliśmy się, выделяя port switcha, do którego podłączone było sprzęt.
Zdalna instalacja oprogramowania na stacjach roboczych
Ten przypadek jest jednym z najbardziej niezwykłych w mojej praktyce. Pewnego dnia skontaktował się z nami klient z prośbą o pomoc — podczas wdrażania Cisco ISE coś poszło nie tak, wszystko się zepsuło i nikt nie mógł uzyskać dostępu do sieci. Zaczęliśmy analizować sytuację i ustaliliśmy następujące. W firmie było 2000 komputerów, zarządzanie którymi z braku kontrolera domeny odbywało się z konta administratora. W celach bezpieczeństwa w organizacji wdrożono Cisco ISE. Trzeba było jakoś zrozumieć, czy na dostępnych komputerach zainstalowano program antywirusowy, czy oprogramowanie było aktualne itp. A ponieważ sprzęt sieciowy wprowadzali administratorzy IT, logiczne było, że mieli do niego dostęp. Przyglądając się, jak to działa, i przeprowadzając audyt swoich komputerów, administratorzy wymyślili, jak instalować oprogramowanie na stanowiskach roboczych pracowników zdalnie, bez osobistych wizyt. Tylko pomyślcie, ile kroków można było zaoszczędzić w ciągu dnia! Administratorzy przeprowadzili kilka kontroli APM w poszukiwaniu określonego pliku w katalogu C:Program Files, a w przypadku jego braku uruchamiano automatyczną naprawę z przekierowaniem do linku prowadzącego do zasobów plikowych z instalatorem .exe. Umożliwiło to zwykłym użytkownikom dostęp do zasobów plikowych i pobranie potrzebnego oprogramowania. Niestety, administrator źle znał system ISE i uszkodził mechanizmy audytu — niewłaściwie napisał politykę, co doprowadziło do problemu, w rozwiązanie którego się zaangażowaliśmy. Osobiście jestem szczerze zdziwiony takim twórczym podejściem, ponieważ znacznie tańsze i mniej pracochłonne byłoby stworzenie kontrolera domeny. Ale jako dowód koncepcji to zadziałało.
Więcej o technicznych aspektach związanych z wdrażaniem Cisco ISE przeczytasz w artykule mojego kolegi .
Artem Bobrikov, inżynier-projektant Centrum Bezpieczeństwa Informacji firmy „Infosytemy Jet”
Epilog:
Mimo że ten post dotyczy systemu Cisco ISE, przedstawiony problem jest aktualny dla całej klasy rozwiązań NAC. Nie ma znaczenia, jakie rozwiązanie od dostawcy ma być wdrożone — większość tego, co zostało powiedziane, pozostanie aktualna.
Źródło: habr.com
