Digitale Torwächter

Network-Access-Control – Mit NAC steht eine Technologie am Anfang des »Hype Cycles«. Sie soll für mehr Sicherheit im Netzwerk sorgen.

NAC ist eine benutzerorientierte Technologie, die ein Endgerät autorisiert und Zugriff auf Ressourcen gewährt. Dies geschieht auf der Basis der Authentisierung der Identität des entsprechenden Benutzers oder/und Gerätes sowie auf dem Status des Gerätes im Hinblick auf sicherheitsrelevante Parameter und Einstellungen: die Compliance mit entsprechenden Unternehmensvorgaben. Diese Parameter werden im Pre-Connect-Assessment ermittelt, also vor Anschluss an die Infrastruktur. Es sollte aber auch dann im laufenden Betrieb eine Überprüfung erfolgen, die dann als Post-Connect-Assessment bezeichnet wird. Teilweise wird auf den einen oder anderen Baustein im Rahmen einer Implementierung auch verzichtet – je nach Anforderung. Ein Prozess zur Wiederherstellung der Compliance, der Remediation, ist hier ebenfalls enthalten. Die gilt für alle Endgeräte und Nutzer am Netz, also eigene Mitarbeiter, Partner, Gäste, Kunden und sonstige Geräte wie Drucker oder Videokameras.

NAC ist aber auch nicht das Allheilmittel gegen beliebige Sicherheitsprobleme. Insbesondere falsches Nutzerverhalten und Angriffe auf Applikationsebene können mittels NAC kaum erkannt werden, es sei denn, man setzt intensiv auch Post-Connect-Assessment-Techniken ein.

Herausforderungen für ein Unternehmen
NAC ist insbesondere eine prozessuale und organisatorische Herausforderung für größere Unternehmen. Um die gewünschten Effekte zu erzielen, müssen die Netzwerk-, die Security- und die Desktopmanagementabteilung eng verzahnt miteinander arbeiten. In der Konzeptionsphase aber auch und insbesondere im Betrieb: Die Netzwerkabteilung muss eine entsprechende Authentifizierung der Endgeräte und Nutzer durchführen. Dazu muss Zugriff auf Directory-Services erfolgen. Die Sicherheitsabteilung hat die Compliance-Vorgaben zu machen und zu kommunizieren. Die Desktopmanagement-Abteilung muss die Vorgaben prüfen und in geeigneter Form der Netzwerkabteilung als zusätzlichen Parameter bei der Authentifizierungsphase mitteilen. Die Security-Abteilung hat zusammen mit der Netzwerkabteilung zu definieren, was bei einem Non-Compliant-Endsystem zu tun ist, welche Zugriffe noch möglich sein sollen und in welchen Schritten das Problem zu beheben ist.

All diese Schritte sind notwendig, um NAC effektiv einzusetzen. Hinzu kommt die entscheidende Frage zur Auswahl der adäquaten Technik. Da sich der Markt noch am Anfang befindet, konkurrieren viele unterschiedliche Ansätze miteinander, wobei sich am Horizont aber auch eine Standardlösung abzeichnet. Je nach Unternehmen kann auf diese gewartet werden oder es müssen sinnvolle Zwischenschritte unternommen werden, die zum gewünschten Ziel führen.

Der Prozess NAC
Es gibt hier verschiedenste Modelle zur Darstellung eines NAC-Prozesses. Generell ist die folgende Einteilung nach Gartner sinnvoll.

• Policy: Die Erstellung einer Policy ist notwendig, um die Konfigurationseinstellungen, die Zugriffsrechte und die Authentisierung sowie die Korrektur und Quarantäne-Einstellungen zu regeln.
• Baseline: Diese erkennt den Security-Status bei beziehungsweise vor Anschluss an die Netzinfrastruktur.
• Access-Control: Die Zuweisung von Zugriffsrechten aus dem Vergleich von Policy und Baseline regelt die Access-Control.
• Mitigation: Bei einer Diskrepanz und limitierten Zugriffsrechten (Quarantäne) sollte hier eine vollautomatische Beseitigung der Probleme via Softwareverteilung, Patchmanagement und Konfigurationsmanagement erfolgen.
• Monitor: Es muss laufend überprüft werden, ob der Anfangsstatus sich nicht verändert.
• Contain: Falls dies doch geschieht, muss reaktiv eine erneute Quarantäne erfolgen können.
• Maintain: Es muss eine laufende Anpassung und Optimierung erfolgen.

Wie zuvor erwähnt, sind hier die Workflows und die Organisation eines Unternehmens entsprechend anzupassen.

Die großen Frameworks
Zunächst gestartet, um die Integrität eines Endsystems in Bezug auf Hardware- und Softwarekonfiguration sicherzustellen (und damit einen Grossteil bestehender Host-IPS- und Personal-Firewall-Ansätze zu ersetzen), können diese Ansätze optimal durch bestehende APIs auch zur Kommunikation des Security-Status eines Endsystems in einer NAC-Umgebung genutzt werden.

Die IETF teilt die Funktionen hier wie folgt ein. Der »Agent« auf dem Endsystem ist typischerweise mehrteilig – der Posture-Collector überprüft einzelne Einstellungen je nach Hersteller des Kollektors wie Patchlevel, Antivirus-Status oder Personal-Firewall-Einstellungen und gibt diese an den Client-Broker weiter, dessen API verschiedene Posture-Kollektoren nutzen können. Der Client-Broker wiederum gibt diese Information an den Network-Access-Requestor weiter, der neben Authentifizierung auch den Security-Status an den die Serverseite leitet. Typisch für einen Network-Access-Requestor sind 802.1x-Supplicants oder IPSec-Clients.

Beim Network-Enforcement-Point handelt es sich typischerweise um Switches, Router, Access-Points, Firewalls und IPS-Systeme oder VPN-Konzentratoren.

Auf der Serverseite werden die Komponenten der Client-Seite in Form der Network-Access-Authority widergespiegelt. Diese entspricht typischerweise einem Radius-Server oder einem Policy-Server. Dieser steuert das Network-Enforcement und den Server-Broker (ein Stück Middleware wie auch der Client-Broker), der wiederum die verschiedenen Posture-Validatoren anspricht.

Für agentenbasierte Lösungen werden diese Lösungen in den nächsten zwei bis fünf Jahren wohl die dominierende Position einnehmen.

Microsoft-NAP
Die Microsoft-Network-Access-Protection-Lösung NAP, die mit Vista und Longhorn-Server Einzug hält, wird wohl erst ab Anfang 2008 für »General Deployments« bereit stehen. Die Beta-Tests und Early-Adaptor-Implementierungen sind noch für 2007 geplant oder schon in Betrieb. Es soll auch einen NAP-Client für Windows-XP geben, der aber nur die minimalen Kundenanforderungen umsetzt. Der NAP-Client soll dann DHCP, VPN und 802.1x-Enforcement unterstützen.

Der Enforcement-Point kann aber auch in der Netzwerkinfrastruktur liegen, die Steuerung erfolgt dann via Radius-Server. Da der Endgerätemarkt nicht nur aus Microsoft-Produkten besteht, ist hier ein Standard notwendig, der sich mit der TCG und deren Sub-Group TNC-SG-Trusted-Network-Connect abzeichnet. Vereinzelt sind auch schon Produkte zu finden, die diese Spezifikation unterstützen. Ein großer Durchbruch ist aber für 2007 zumindest für TNC noch nicht zu sehen, obwohl schon mehr als 160 Unternehmen dort Mitglied sind. Das Modell der TNC-SG 1.1-Spezifikation sieht auch wiederum sehr dem MS-NAP-Konzept ähnlich.

Cisco-CNAC
CNAC besteht prinzipiell aus ähnlichen Komponenten wie die anderen Frameworks. Auf der Client-Seite primär aus dem Cisco-Trust-Agent (CTA), der als Network-Access-Requestor, Client-Broker und in Teilen als Posture-Collector (für OS-Patch und Hotfix-Überprüfung) fungiert. Er stellt auch eine Cisco-eigene API und ein Skripting-Interface für externe Posture-Collectoren bereit. Und nebenbei kann der CSA-Cisco-Security-Agent als Enforcer und Posture-Collector genutzt werden. Auf der Serverseite besteht CNAC aus dem Cisco-ACS-Access-Control-Server, der als Radius-Server der Network-Access-Authority und dem Server-Broker entspricht. Cisco setzt im CNAC-Programm auf die Integration von Partnern für den Posture-Check, der mittels der Cisco-proprietären Protokolle Host-Credential-Authorization-Protocol (HCAP) und Generic-Authorization-Message-Exchange (GAME) erfolgen kann. GAME ist eine SAML-basierte (Security-Assertion-Markup-Language) Sprache für die Kommunikation mit Audit-Servern, HCAP ermöglicht die Überprüfung der Security-Posture auf den jeweiligen Policy-Servern beispielsweise der Anti-Virus-Hersteller, die im CNAC-Programm teilnehmen.

Nachdem die CNAC-Phase 2 lange auf sich warten gelassen hat (und damit neben Routern auch Switches mit 802.1x unterstützt werden), hat Cisco realisieren müssen, dass die Kundenbasis mit ihren Infrastruktur-Upgrades nicht für CNAC bereit ist. Daher wurde das Unternehmen Perfigo gekauft, um das Produkt namens Cleanaccess anzubieten. Es gehört zur Klasse der Out-of-Band-Appliances (mit Inband-Option für geringe Portdichten/Geschwindigkeiten). Aktuell ist noch nicht zu erkennen, wie Cleanaccess und CNAC zusammenkommen sollen.

Mit Microsoft-NAP stellt sich Microsoft neben dem Voice-VoIP-Geschäft auch im Security-Umfeld als Wettbewerber von Cisco auf. Das wurde erkannt und schnellstens eine Kooperation vereinbart, die effektiv dazu führt, daß der CTA für Microsoft-basierte Endsysteme verschwinden wird und nur EAP-FAST sowie EAPoUDP als proprietäre Fragmente auf dem Desktop übrig bleiben und in den NAP-Agent integriert werden.

Das Zusammenspiel in heterogenen Umgebungen
Auf der Desktop-Ebene wird Microsoft mit dem NAP-Agent wohl eine maßgebliche Rolle spielen – in Bezug auf Sicherheit zieht Microsoft hier die Daumenschrauben stark an. Die Akzeptanz der TNC-Implementierungen wird in der Non-Microsoft-Welt groß sein, für Microsoft-basierte Endsysteme bleibt dies abzuwarten. Eine Integration der verschiedenen Systeme ist auf der Serverseite möglich. Hier müssen intelligente Network-Access-Authority-Server erkennen, welche Clients installiert sind und auf dieser Basis muss eine Umleitung an den entsprechenden (Network-Access-Authority-) Server erfolgen. Enterasys geht mit Enterasys-Sentinel diesen Weg des intelligenten Radius-Proxies und Brokers, der diese Integration übernehmen kann. Auf dem Desktop muss sich der IT-Verantwortliche für jeweils einen Agenten und eine Technologie entscheiden.

Policy-Enforcement-Points
Die optimale Lösung für NAC im LAN ist die Implementierung von Access-Switches, die eine entsprechende Authentifizierung via 802.1x und eine Zuordnung von Policies unterstützt. Insbesondere aber auch in einer heterogenen Umgebung mit Non-802.1x-Endgeräten und mehreren Geräten pro Switch-Port sind hier mehr Optionen notwendig. Dies gilt auch für Migrationen und bei der Verwendung von Fibre-to-the-Office ein entscheidender Faktor. Wenn man Authentisierung einführen möchte, stellt sich zunächst die Frage nach der Art und Weise des Verfahrens. Es gibt mehrere Möglichkeiten, dies zu tun. Hier ist man sehr abhängig vom verwendeten Endsystem:

• 802.1x für eigene PCs und Laptops, in Zukunft teilweise auch IP-Phones ist die präferierte Lösung,
• MAC-Adresse für Drucker, IP-Phones und andere Maschinen am Netz (wie Sicherheitskameras, Produktionssteuerungen oder Sensoren),
• Web-Portal für Gäste, Consultants, Service-Techniker,
• Default-Eigenschaften beispielsweise für TFTP/Bootp, damit Diskless-Stationen booten.

Ein Switch sollte alle Verfahren gleichzeitig pro Port unterstützen, damit sich der Administrationsaufwand nicht unnötig erhöht. Bei der Authentisierung verschiedener Benutzer/Geräte gleichzeitig an einem Port ist natürlich davon auszugehen, dass an diesem Port dann auch unterschiedliche Gruppen-Regeln je nach Benutzer und Gerät spezifisch und gleichzeitig vorhanden sein müssen. Der PC soll beispielsweise andere Regeln bekommen wie das IP-Phone am selben Port. Ein Gast sollte andere Regeln haben als ein eigener Mitarbeiter. Das heißt nach erfolgreicher Authentisierung muss eine Policy-Vergabe pro Benutzer/Gerät erfolgen.

Hierbei können mehrere »User« pro Port mit beliebigen Authentisierungsverfahren zu völlig unterschiedlichen Policies dynamisch zugeordnet werden. Ein weiteres Augenmerk sollte auf die Art der Policies gelegt werden: Oft werden nur einfache VLAN-Policies unterstützt, innerhalb eines VLANs gibt es aber gar keine Kontrolle.

Die Antwort liegt in Port-Policies (ACLs und QoS auf Layer 2-4), die auch zwischen Ports im gleichen VLAN greifen und auch Informationen von Layer-2 bis Layer-4 mit einbeziehen. Hinzu kommt dann die Verifizierung des Endsystemstatus während der Authentisierung.

Appliance-based
Um schneller eine NAC-Lösung zu implementieren wird heute verstärkt die Aufmerksamkeit auf Appliances gelegt, die oft eine Übergangslösung zu einer Switch-basierten NAC-Lösung darstellen. Die Access-Switches können zunächst weiter genutzt werden, auch wenn sie keine Authentifizierung und Policy-Verfahren unterstützen. In sehr heterogenen Umgebungen mit relativ alten Switches ist dies ein gangbarer Weg.

Inband-Appliances
Inband-Appliances sind typischerweise eine Erweiterung einer Switch-basierten Lösung mit der Unterstützung von mehreren hundert bis mehreren tausend Geräten pro Port, die mit unterschiedlichsten Authentifizierungsverfahren und Policies autorisiert werden können. Zusätzlich sind oft Windows-Login-Snooping-Verfahren zu finden, die eine User-zu-IP-Adressen-Verbindung herstellt. Eine Implementierung im Distribution-Layer eines Netzwerkdesigns ist der geeignete Ort für eine Inband-Appliance, die auch hinter einem WLAN-Switch oder VPN-Konzentrator installiert werden kann.

Out-of-Band-Appliances
Im Gegensatz zu den Inband-Appliances stehen die Out-of-Band-Appliances für den normalen Verkehr nicht im Datenpfad – jedoch bei der Authentifizierung, im Assessment-Prozess und auch im Quarantäne-Fall. Es gibt zwar auch Lösungen, die hier out of band arbeiten, das ist jedoch eher die Ausnahme als die Regel. Dieser Ansatz erscheint zunächst attraktiv, er hat aber auch seine Tücken – insbesondere in den Bereichen Erkennung neuer Endsysteme, Rekonfiguration der Access-Switches im Assessment und Quarantäne-Fall sowie Granularität im Assessment- und Quarantäne-Fall.

Diese Probleme können zwar durch das Einschalten einer 802.1x-Authentifizierung am Access-Switch umgangen werden. Dann entspricht das Ganze aber eher einer Switch-based-NAC-Lösung und die Appliance ist kaum noch erforderlich. Die Erkennung erfolgt typischerweise durch SNMP-Traps für neue MAC-Adressen oder durch das regelmäßige Pollen von Source-Address-Tabellen oder Router-ARP-Caches in den verschiedenen Netzkomponenten – was auch unzuverlässig und mit Verzögerungen verbunden ist. Auch sind die Access-Switches hier mit einer Reihe von Quarantäne-VLANs zu konfigurieren, was wiederum einen höheren administrativen Aufwand bedeutet. Die automatische Rekonfiguration eines Port-VLANs durch die Appliance ist dann auch oft wieder herstellerspezifisch. Dies zeigt sich dann auch in der Granularität der Antwort und es ist fast unmöglich in einer VoIP-Umgebung mit PC und IP-Phone am selben Switch-Port.

Software-basierte Lösungen
Ein Enforcement auf dem Agent des Clients bietet sehr präzise Möglichkeiten zur Steuerung im Quarantäne-Fall. Die neuen Frameworks werden hier gute Möglichkeiten bieten. Es gibt auch heute schon eine Reihe von Personal-Firewall- und Host-Intrusion-Prevention-Herstellern, die sich seit längerem dieser Thematik widmen. Checkpoint-Integrity oder auch Symantec, um nur zwei bekannte zu nennen. Diese Lösungen können aber wiederum mit netzwerkbasierten Lösungen kombiniert werden können.

Pre-Connect-Assessment
Beim netzwerkbasierten Pre-Connect-Assessment werden typische Netzwerkscan-Produkte wie Nessus, Qualys, Rapid7 oder Tenable eingesetzt und mit den NAC-Appliances meist auf proprietäre Weise verknüpft. Mit entsprechenden Credentials auf dem Endsystem sind hier auch tiefere Analysen wie File-System-, Anti-Virus- und Registry-Prüfungen möglich. Diese Produkte prüfen typischerweise beliebige Betriebssysteme. Heute gibt es hier mehrere Ansätze, die mit permanenten oder auch mit temporären Agenten arbeiten. Diese sind oft Windows-zentriert. Fat-Agent-based sind die Framework-Agenten. Sie kombinieren das Baselining mit HIPS- und PFW-Funktionen für das Enforcement. Die Vorteile sind die gute Kontrolle des Endsystems und die Tatsache, dass keine Verzögerung beispielsweise durch Scans auf dem Endsystem stattfindet.

Aber auch die bestehenden Desktop-, Patch- und Konfigurationsmanagement-Agenten wie die von Altiris, CA, IBM oder Patchlink können hier mit genutzt werden. Damit entfällt der Aufwand der Installation eines weiteren Agenten.

Post-Connect-Assessment
Die Überprüfung des Clients vor Anschluss an die Infrastruktur und auch dessen regelmäßige Prüfung löst nur einen Teil des Sicherheitsproblems. Ein völlig konformes Endsystem kann dennoch nicht autorisierte Aktionen in der Infrastruktur vornehmen. Diese müssen auch erkannt werden und im gleichen Prozess enden wie eine Identifikation eines Problems bei/vor Anschluss an die Infrastruktur. Die Funktion ist eine IDS/IPS-ähnliche, die von den Inline-Appliance-Herstellern fokussiert angeboten wird. Ein typischer Markt für Startups im NAC-Markt.

Remediation
Die Support-Last sollte durch das In-Quarantäne-Stellen von Systemen nicht ansteigen. Also sind Automatismen notwendig, um eine Beseitigung des Schadens durchzuführen. Bei gemanagten Desktops mit Agenten ist dies relativ einfach mit der Verknüpfung eines Patchmanagement-Systems möglich, auf das Zugriff auch in der Quarantäne besteht. Eine universelle Funktion ist die Umleitung auf eine Remediation-Webpage, wo der Anwender Hinweise zur Beseitigung finden kann und durch den Prozess geleitet wird.

Dem Thema Remediation wird in Zukunft noch mehr Bedeutung zukommen. Insbesondere auch die Möglichkeiten der Integration mit Patch- und Update-Services wie Windows-Server-Update-Service (WSUS) werden die Effektivität der Betriebs von NAC Lösungen erhöhen.

NAC-Lösungen
Enterasys hat durch ihre Secure-Network-Architektur eine Basis für Switch-basierte NAC-Lösungen geschaffen. Für eine Pre-Connect-Assessment-NAC-Lösung sind neben den Switches selbst die Netsight-Komponenten-Console, Policy-Manager und Trusted-Access-Manager zusammen mit dem Trusted-Access-Gateway notwendig. Dabei ist die Wahl eines Assessment-Servers noch erforderlich. Enterasys unterstützt hier heute schon eine Reihe von Technologien und ist auch Mitglied der TCG.

Eine Post-Connect-Assessment-NAC-Lösung erfordert noch die Netsight-Automated-Security-Manager-Komponente sowie den Einsatz von Intrusion-Detection-Technologien.

Weiterhin ist eine Inline-Appliance-NAC-Lösung durch den Einsatz der Matrix-N-Serie im Distribution-Layer möglich. Diese Appliance kann auch das Trusted-Access-Gateway und in Zukunft die Dragon-Funktion in einer einzigen Lösung beinhalten und vereint damit Pre-Connect- und Post-Connect-Assessment.

Eine Out-of-Band-Appliance-Lösung stellt die Enterasys-Sentinel-Lösung mit den Netsight-Komponenten Console und Trusted-

Access-Manager zusammen mit dem Trusted-Access-Gateway dar. Hier können auch 3rd-Party-Geräte unterstützt werden, die 802.1x-Authentisierung und VLAN-Zuweisung nach RFC 3580 ermöglichen.

Fazit
Der NAC-Markt ist noch sehr volatil. Damit ist es für IT-Verantwortliche schwierig, auf das richtige Pferd zu setzen. Generell ist darauf zu achten, dass der Hersteller eine flexible Architektur mit offenen Schnittstellen besitzt, um sich den Marktgegebenheiten anpassen zu können. Die Entscheidung, NAC einzuführen, ist nicht nur eine technologische, sondern auch eine organisatorische.

Markus Nispel,
Director Solution Architecture, Enterasys