Kontrowersje wokół NAC

Forrester Research opublikowała raport wieszczący upadek technologii NAC (Network Access Control) w obecnej formie. Cisco broni tej idei. O wynikach tego sporu może zdecydować IETF, przygotowujący standaryzację protokołów kontroli dostępu do sieci.

Forrester Research opublikowała raport wieszczący upadek technologii NAC (Network Access Control) w obecnej formie. Cisco broni tej idei. O wynikach tego sporu może zdecydować IETF, przygotowujący standaryzację protokołów kontroli dostępu do sieci.

Dzisiejsze technologie kontroli dostępu do sieci nie sprawdzą się i wkrótce znikną z rynku, zastąpione przez sprzętowe systemy autentykacji instalowane w urządzeniach końcowych" - taki, nieco zaskakujący, krytyczny wniosek zaprezentowano w marcowym raporcie opublikowanym przez Forrester Research. Opinia ta wywołała oczywiście ostrą reakcję Cisco Systems, która od kilku lat zdecydowanie promuje ideę i własne oprogramowanie umożliwiające implementację mechanizmów szczegółowego skanowania i autentykacji urządzeń przed udostępnieniem im zasobów sieciowych. Technologie umożliwiające kontrolowanie systemów podłączanych do sieci przyciągnęły zresztą uwagę wielu producentów, np. Microsoft, który opracował własną wersję NAC - Microsoft NAP (Network Access Protection) lub organizacji Trusted Computing Group promującej własny standard TNC (Trusted Network Connect).

Forrester: NAC się nie sprawdził

Analitycy Forrester Research zauważają, że wiele korporacji z desperacją dążących do zwiększenia bezpieczeństwa swoich systemów IT w obliczu rosnącego zagrożenia ze strony hakerów i złośliwych kodów zaczęło stosować technologie NAC oferowane przez różnych producentów. Ale okazuje się, że dostępne obecnie narzędzia są trudne do instalacji, obsługi i utrzymania i właśnie te negatywne doświadczenia każą sądzić, że w najbliższych latach nastąpi odwrót od NAC i poszukiwanie lepszych alternatyw.

Dobrym przykładem rozbieżności i niezgodności dotyczących technologii NAC jest m.in. różne nazewnictwo podobnych funkcji, które organizacja IETF chce ujednolicić.

Dobrym przykładem rozbieżności i niezgodności dotyczących technologii NAC jest m.in. różne nazewnictwo podobnych funkcji, które organizacja IETF chce ujednolicić.

Systemy klasy NAC oferujące funkcje kontroli dostępu i automatycznego skanowania urządzeń podłączanych do sieci proponowane są obecnie przez wielu producentów oprogramowania do zabezpieczania sieci, a także znanych potentatów na rynku infrastruktury sieciowej, jak Cisco i Juniper.

Podstawową funkcją takich narzędzi jest kontrola obecności i aktualności odpowiednich mechanizmów zabezpieczeń zanim urządzenie (jego użytkownik) uzyska autoryzację i dostęp do zasobów IT. Niektóre z oferowanych systemów obiecują również możliwość bieżącego monitorowania zachowań już autoryzowanych użytkowników, co ma zapewnić ochronę przed ukrytymi, wcześniej nie zlokalizowanymi atakami.

Źródła porażki

1 Pierwszy powód to fakt, że systemy NAC prowadzą do tworzenia zbyt wielu różnych polityk bezpieczeństwa, które mają na celu kontrolowanie tych samych procesów. Podawanym przez analityków przykładem jest często obserwowana w firmach, równoległa instalacja oprogramowania Symantec Sygate do kontroli zdalnego i bezprzewodowego dostępu oraz oprogramowania Cisco do kontroli lokalnych użytkowników. W efekcie tworzone są dwie polityki zabezpieczania dostępu, a użytkownicy mają różne, niezgodne doświadczenia zależnie od tego czy łączą się zdalnie, czy lokalnie do tego samego systemu IT.

2 Forrester podkreśla także, że systemy NAC są zbyt skomplikowane, a rozwiązania różnych producentów niezgodne ze sobą, nawet jeśli są to firmy deklarujące wsparcie dla takich standardów, jak specyfikacje proponowane przez Cisco, Microsoft lub TCG.

3 Wiele z dostępnych obecnie narzędzi NAC oferuje tylko funkcje prewencyjne, a nie jest w stanie obronić systemu przed nowymi, pojawiającymi się zagrożeniami. Zbyt często jedynym ich zadaniem jest udzielenie informacji, jak komputer użytkownika należy dostosować, by był zgodny ze zdefiniowaną polityką bezpieczeństwa, a brak jest jakiejkolwiek pomocy w rozwiązywaniu rzeczywistych problemów.

Gdy użytkownik ma złą wersję programu antywirusowego lub brak zainstalowanej aktualnej łaty dla systemu operacyjnego, większość systemów NAC po prostu izoluje urządzenie bez podawania przyczyn. Jest to obecnie jeden z największych problemów dotyczących użyteczności NAC. Problemy te powodują, że wiele firm zaczyna podchodzić do implementacji systemów NAC z uzasadnioną rezerwą, obawiając się przede wszystkim kłopotów związanych z blokadą dostępu użytkowników do niezbędnych im zasobów w sieci. Dopiero gdyby ryzyko takich sytuacji było znacznie mniejsze niż obecnie, firmy te mogą zdecydować się na wdrożenia systemów automatycznej kontroli dostępu.

Zdaniem Natalie Lambert w praktyce oznacza to, że największe są perspektywy popularyzacji systemów wykorzystujących sprzętowe mechanizmy autentykacji i testowania bezpieczeństwa zainstalowane w urządzeniach klienckich. "Sądzę, że inteligentne technologie kontroli dostępu będą bardziej związane z urządzeniami końcowymi niż systemem sieciowym. Zwłaszcza że wiele firm już dysponuje infrastrukturą bezpieczeństwa i systemem zarządzania, które mogą realizować tego typu zadania, oczywiście po pewnym ich rozszerzeniu o odpowiednie funkcje".

Aby znani producenci mogli poskładać te wszystkie elementy i zaoferować systemy, zdolne pracować w zadowalający użytkowników sposób, najprawdopodobniej wykorzystają przejęcia mniejszych firm, które opracowały brakujące elementy technologii. Ten kierunek rozwoju rynku jest już obecnie widoczny, jako przykład podając przejęcie w październiku 2006 r. przez McAfee firmy Onigma, producenta systemów DLP (Data Leakage Prevention) służących do zapobiegania wyciekom danych. W najbliższym czasie można oczekiwać kolejnych tego typu transakcji.

Bezpieczeństwo narzucone sieciowo

Producenci systemów NAC przyjęli ten raport z mieszanymi uczuciami zauważając, że stawia on sprzeczne żądania jednoczesnego uproszczenia i skomplikowania tej technologii, a Cisco podkreśla, że raport Forrester Research uwidacznia różnicę między analitykami i dostawcami oprogramowania w opiniach, jakie elementy systemu NAC są jego niezbędnymi składnikami.

"Raport skupia się na mechanizmach kontroli stanu systemu z perspektywy bezpieczeństwa antywirusowego i obecności poprawek dla OS, a Cisco widzi funkcjonalność NAC znacznie szerzej, włączając do mechanizmów skanowania funkcje określające rodzaj komputera i systemu operacyjnego oraz informacje dotyczące użytkownika" - mówi Irene Sandler, dyrektor marketingu w Cisco NAC Appliance Business Unit. Przedstawiciele tej firmy zwracają jednocześnie uwagę, że inne raporty na temat NAC pozytywnie oceniają właśnie sieciowe mechanizmy autentykacji tak krytykowane przez Forrester. Wyniki ankiety przeprowadzonej przez Infonetics Research wskazują, że 80% menedżerów IT uważa, że polityka bezpieczeństwa powinna przynajmniej w części być wymuszana przez mechanizmy sieciowe, a 51% sądzi, że elementy kontrolne powinny się znajdować w urządzeniach końcowych.

Cisco broni się też przed zarzutami zawartymi w raporcie Forrester zapowiadając, że wraz z rozwojem technologii NAC wiele z prezentowanych problemów zniknie, a systemy kontrolujące dostęp do sieci będą prostsze i łatwiejsze w użyciu. O dobrej przyszłości stojącej przed tego typu rozwiązaniami świadczyć ma też ponad 1600 firm, które już zdecydowały się na implementację Cisco NAC.

IETF przygotowuje standard

Choć wielu producentów oprogramowania oferuje systemy kontroli dostępu do sieci określane jako NAC i mające podobną funkcjonalność, to praktycznie żadne z tych rozwiązań nie współpracuje z innymi aplikacjami, bo wykorzystuje różne protokoły i niezgodne mechanizmy skanowania systemów. Dlatego też już jesienią ub.r. organizacja IETF utworzyła NEA (Network Endpoint Assessment) Working Group, której zadaniem jest standaryzacja mechanizmów wykorzystywanych do wymiany informacji w sieciowych systemach kontroli dostępu. Chodzi głównie o uzgodnienie najpopularniejszych protokołów Cisco NAC, Microsoft NAP i Trusted Computing Group TNC tak, aby wykorzystujące je systemy mogły ze sobą współpracować przynajmniej w podstawowym zakresie.

NEA przygotowała już pierwszą wersję dokumentu prezentującego proponowaną, ujednoliconą terminologię, model referencyjny, przewidywane zastosowania technologii oraz wymagania dotyczące niezbędnych modyfikacji istniejących protokołów, które mają być ewentualnie poddane standaryzacji. Na razie jest to dopiero wstępna propozycja dotycząca tylko niektórych, podstawowych funkcji protokołu. Według planu IETF specyfikacja RFC (Request For Comment), która ma być podstawą opracowania ostatecznego standardu, zostanie opublikowana w grudniu tego roku.


TOP 200