NAM ( Network Admision Management )

Transkript

1 NAM ( Network Admision Management ) SEMINAR NETWORK SECURITY Eingereicht von: /880 Angefertigt am: Institut für Informationsverarbeitung und Mikroprozessortechnik (FIM) LVA-Leiter: Prof. Dr. Jörg R. Mühlbacher Linz, Februar 2006 Seite 1 von 18

2 Abstract Mit der Zunehmenden Vernetzung von stationären und mobilen Geräten wächst auch das Bedrohungspotential welches von jedem dieser Geräte ausgeht. Aus diesem Grund wird verstärkt an Techniken gearbeitet mit welchen verhindert werden soll, dass gefährliche Geräte in ein Netzwerk gelangen und dort Schaden anrichten können. Die Hauptidee hinter diesen Techniken ist die, potential gefährliche Geräte zuerst auf das Vorhandensein von Bedrohungen zu untersuchen. Erst nach dem dieser Test keine Bedrohungen anzeigt dürfen diese Geräte mit einer gültigen Authentifizierung in das reguläre Netzwerk. Andernfalls werden sie in ein Quarantäne Netzwerk weitergeleitet, um dort von ihren Bedrohungen befreit zu werden. Diese Arbeit beschreibt zuerst ausgehend vom Vortrag von Herrn Eschelbeck die Grundideen die hinter dem Network Admision Management stehen. Im Anschluss daran werden die drei Unterschiedlichen Lösungsansätze von Cisco, Microsoft und der Trusted Computing Group beschrieben. Inhaltsverzeichnis 1. Motivationen für NAM Grundstruktur eines regelbasierten NAM Mögliche Lösungsansätze für NAM Cisco Network Admission Control (NAC) Komponenten des Cisco NAC Ablaufschema Microsoft Network Access Protection (NAP) Komponenten der NAP Plattform NAP Client Struktur NAP Server Struktur TCG Trusted Network Connect (TNC) TNC Architektur Zusammenfassung Referenzen...17 Seite 2 von 18

3 1. Motivationen für NAM Der Aufbau heutiger Netzwerke besteht in den meisten Fällen darin, die Einzelnen Computer über Switches und Router miteinander zu verbinden. Der Weg nach draußen wird ü- ber eine Firewall geschützt, welche in vielen Fällen mit NAT arbeitet. Für die einfachere und bequemere Administration werden die Netzwerkeinstellungen mittels DHCP an die Clients verteilt. In so einer Umgebung muss man sich vorstellen was passiert, wenn zum Beispiel ein(e) Mitarbeiter(in) seinen/ihren eigenen Laptop mit bringt und an das Netzwerk anschließt. Mögliche Folgen: Dieser Laptop kann mit unterschiedlichen Bedrohungen und Gefahren behaftet sein. Im Folgenden eine Auflistung möglicher Gefahren: Vireninfektion Trojaner Infektion Nicht aktualisiertes Betriebssystem Nicht aktualisierte Software Einsatz unsicherer Software Betrieb von sicherheitskritischen Diensten wie Web-Server, FTP-Server, P2P Clients, Verwendung unsicherer Protokolle wie UDP Damit so ein Laptop in einem Netzwerk keinen Schaden anrichten kann wird eine NAM Infrastruktur benötigt mithilfe derer solche Clients aufgespürt und repariert werden können. 2. Grundstruktur eines regelbasierten NAM Die Grundlage eines regelbasierten NAM stellt die Sammlung von Regeln, auch Policies genannt, dar. Diese Regeln beschreiben alle Sicherheitslücken und Bedrohungen, Vulnerabilities, welche ein Client nicht mitbringen darf um in das Netzwerk zu dürfen. Ausgehend von diesen Regeln werden alle Client die sich mit dem Netzwerk verbinden möchten auf mögliche Gefahren untersucht. Erst wenn keine Gefahren gefunden wurden darf der Client in das Netzwerk. Für den Fall, dass der Client eine Bedrohung darstellt, wird er in ein so genanntes Quarantäne Netzwerk weitergeleitet. Die Aufgabe dieses Quarantäne Netzwerkes besteht darin, dem Client benötigte Updates und Tools zur Verfügung zu stellen, damit dieser seine Sicherheitslücken beheben kann. Seite 3 von 18

4 Die folgende Abbildung zeigt Schematisch wie ein regelbasiertes NAM aufgebaut ist. Abbildung 1: Grundstruktur eines regelbasierten NAM [Esch05-NAM] 3. Mögliche Lösungsansätze für NAM 3.1 Cisco Network Admission Control (NAC) Damit sich Maschinen die eine Bedrohung darstellen erst gar nicht mit dem Netzwerk verbinden können setzt die Lösung von Cisco auf den massiven Einsatz von (Cisco) Hardware und einer Client Software. Die Cisco NAC beruht im Prinzip darauf, dass sich jeder Client bevor er in das Netzwerk darf auf Bedrohungen überprüfen lassen muss. Nach dieser Überprüfung wird festgelegt in welchem Ausmaß der Client vertrauenswürdig ist und ob und in welchen Teil des Netzwerkes er darf Komponenten des Cisco NAC Die Cisco NAC besteht aus folgenden Komponenten: Cisco Trust Agent (CTA) Bei dem so genannten Trust Agent handelt es sich um nichts anderes, als um eine API mit Hilfe derer der aktuelle Status des Sicherheitsniveaus eines Endgerä- Seite 4 von 18

5 tes abfragt und an ein Netzzugangsgerät, über eine sichere Verbindung, übertragen werden kann. So lässt sich etwa der Status des Betriebssystems, seine Version, sein Patchlevel und so weiter oder der des Anti-Viren Programms abfragen. Damit die so eben genannten Möglichkeiten ausgenutzt werden können ist es notwendig, dass die betreffende Software das CTA API verwendet. Die Verwendung ist jedoch nur nach erfolgter Lizenzierung möglich. Cisco Netzzugangsgeräte Bei diesen Geräten handelt es sich um Router, Switches, Wireless Access Points oder dedizierte Sichereits-Appliances welche für die Durchsetzung der Sicherheitsrichtlinien verwendet werden. Wird ein Gerät neu an das Netzwerk angeschlossen, so fordert das Netzzugangsgerät Informationen über den aktuellen Sicherheits-Status dieses Gerätes an und sendet diese an den Secure Access Control Server weiter. Dieser Server überprüft den Sicherheits-Status und entscheidet an hand seiner Richtlinien, welchen Zugang das neue Gerät erhält. Diese Entscheidung wird dem Netzzugangsgerät zur Exekution übergeben. Auf Grund der Entscheidung des Servers erhält das Gerät nun folgende Zugangsmöglichkeiten: o permit: das Gerät erhält vollen Zugang o restrict: das Gerät erhält einen stark eingeschränkten Zugang o quarantine: das Gerät wird in Quarantäne genommen o deny: der Zugang wird verweigert Cisco Richtlinien-Server Die Basis der Richtlinien-Server ist der Cisco Secure Access Server (ACS), welcher als Authentisierungs-, Authorisierungs- und Accounting-Server (AAA- Server) arbeitet. Die Richtlinien-Server verarbeiten den Sicherheitsstatus der Clients und entscheiden über die Zugangsberechtigungen. Der ACS kann auch mit weiteren Richtlinien-Server, zum Beispiel von einem Anti-Virus Hersteller, zusammenarbeiten und übergibt diesem die Auswertung des Anti-Virus Zustandes. Management System Die Management Systeme werden für die Einrichtung und Verwaltung der Cisco NAC Infrastruktur, CiscoWorks VPN/Security Management Solution, und für Seite 5 von 18

6 die Auditierung und das Reporting, CiscoWorks Security Information Management Solution, verwendet. Das folgende Bild soll die Funktionsweise der Cisco NAC verdeutlichen: Abbildung 2: Cisco NAC Funktions-Schema [Cisco04-1] Ablaufschema Anhand des Folgenden Schaubildes wird die Funktionsweise der NAC detaillierter beschrieben. Abbildung 3: NAC Ablaufschema [Cisco05-CNAC] Erläuterungen zu den einzelnen Punkten: Seite 6 von 18

7 1. Client sendet ein Packet bis zu einem Router bei dem NAC aktiviert ist 2. Die NAD beginnt mit der Status Validierung unter Verwendung von EOU (EAP over UDP) 3. Der Client sendet seine Status Daten mit EOU zur NAD 4. Die Status Daten des Clients werden von der NAD mittels RADIUS an den Cisco ACS gesendet. 5. Der Cisco Secure ACS sendet die Anfrage der Validierung mit dem Host Credential Authorization Protocol (HCAP) in einem HTTPS Tunnel weiter an den Validierungs-Server 6. Der Validierungs-Server sendet das Ergebnis seiner Validierung an den ACS 7. Für das Erlauben oder Ablehnen der Verbindung sendet der ACS ein accept mit einer ACL/URL an die NAD 8. Weiterleitung des Anfrage Ergebnisses an den Client 9. Je nach Inhalt des Ergebnisses darf der Client entweder voll, eingeschränkt oder nicht in das Netzwerk. Falls Bedrohungen bestehen ist auch eine Quarantäne möglich. 3.2 Microsoft Network Access Protection (NAP) Nach dem in den aktuellen Versionen von Windows keine Möglichkeit für die Zentrale Konfiguration von Sicherheits-Policies, für die Zugriffsverweigerung Infizierter Systeme und für die isolierte Reparatur von Infizierten Systemen integriert ist, wird mit Windows Server Longhorn eine so genannte Network Access Protektion (NAP) Plattform angeboten. Die NAP Plattform stellt Komponenten und Infrastruktur, mit denen das Erstellen und Durchsetzten von Netzwerk Zugriffs-Policies möglich ist, zur Verfügung. Mit Hilfe derer ist es möglich Richtlinien für die Überprüfung von Computer welche mit dem Netzwerk verbunden sind, oder Richtlinien für das Verteilen von wichtigen Updates, oder Restriktionen für das aussperren von Computern aus dem Netzwerk zu erstellen. Die Funktionalitäten von NAP kann in eigene Software oder in Programme anderer Hersteller integriert werden. Ein wichtiger Punkt von NAP ist der, dass NAP nicht für den Schutz gegen böswillige Benutzer, sondern nur für die vereinfachte Administration von Sicherheitsrichtlinien gedacht ist. Seite 7 von 18

8 3.2.1 Komponenten der NAP Plattform Die NAP Plattform besteht aus folgenden Komponenten: NAP Clients sind Computer welche die NAP Implementierung für DHCP Konfiguration, remote access VPN Verbindungen und sichere Kommunikation über IPsec zur Verfügung stellen. NAP Server sind Computer welche mit Windows Server Longhorn arbeiten und beschränkten Netzwerk Zugang für Computer zur Verfügung stellen, welche die Definition eines Gesunden Systems nicht erfüllen. IAS Server sind Computer mit Windows Server Longhorn auf denen der Internet Authentication Server (IAS) läuft. Diese Server werden für die Konfiguration der System Policies und die Koordination der Validierung des Zustandes der Clinets verwendet. Policy Server stellen die aktuellen Statusinformationen über gesunde Systeme den IAS zur Verfügung. Remediation Server stellen die benötigten Updates, Patches und Konfigurationen für die Clients zur Verfügung, damit diese einen sicheren Systemzustand erreichen können. Health Certificate Server sind Windows Server Longhorn Computer die die Zertifikate über den Gesundheitszustand für IPsec basierte NAP Clients ausstellen NAP Client Struktur Damit ein Computer ein NAP Client sein kann muss er mit einem der folgenden Betriebssysteme betrieben werden: Windows XP Service Pack 2 mit einem speziellen Update, Windows Vista oder Windows Server Longhorn. Seite 8 von 18

9 Abbildung 4: NAP Client Struktur [Micro05-NAP3] Die in Abbildung 4 dargestellten Komponenten eines NAP Clients haben folgende Aufgaben: Ein SHA ist ein so genannter System Health Agent. Jeder dieser Agenten hat eine spezielle Aufgabe, z.b. Überprüfung der Anti-Viren Signatur oder Überprüfung der Systemupdates. Jeder dieser SHAs kann mit einem Remediation Server verbunden sein, über den er Statusinformationen und Updates beziehen kann. Es ist aber auch möglich, dass ein SHA mit keinem Remediation Server verbunden ist, zum Beispiel kann ein SHA nur überprüfen ob Virenscanner oder Personal Firewall aktiviert sind. Der Quarantine Agent verwaltet den Gesundheits-Zustand des Clients durch die Auswertung der Informationen der einzelnen SHAs. Eine weitere Aufgabe des Quarantine Agent ist die Erleichterung der Kommunikation zwischen der SHA Schicht und den Quarantine Enforcement Clients (QEC). Die Aufgabe eines QEC besteht darin, einen bestimmten Netzwerk Service zur Verfügung zu stellen. Zum Beispiel kann ein QEC IPsec Verbindungen anbieten oder ein anderer DHCP Konfiguration. Jeder dieser QEC arbeitet mit einem NAP Server zusammen der den Dienst des QEC verwendet bzw. anbietet. Seite 9 von 18

10 Die Kommunikation zwischen den SHAs und dem Quarantine Agent erfolgt über so genannte Statements of Health (SoHs) welche von den SHAs erzeugt und dem Quarantine Agent übergeben werden NAP Server Struktur Wie schon mehrmals erwähnt wird für die Verwendung eines Computers als NAP Server Windows Server Longhorn benötigt. Für den Betrieb eines NAP Servers gibt es weiters zwei Möglichkeiten: entweder ein NAP und ein IAS Server, oder ein Server der NAP und IAS Server zugleich ist. Im Folgenden wird auf die erste Variante näher eingegangen. Abbildung 5: NAP Server Struktur [Micro05-NAP3] Ein NAP Server besteht aus einer Menge von Quarantine Enforement Server (QES) Komponenten, wobei jeder dieser QES für eine bestimmte Netzwerkkommunikation oder Netzwerk Zugriffe zuständig ist. So kann ein QES etwa für die DHCP Konfiguration oder ein anderer für die VPN Verbindungen zuständig sein. Typischerweise arbeitet jeder dieser QES mit einem NAP Client zusammen. Seite 10 von 18

11 Für den Fall, dass für die Überprüfung des Gesundheitszustandes eines NAP Clients SoHs verwendet werden, so ist ein IAS Server für die Validierung nötig. Die SoHs werden von den QES über eine RADIUS Access-Request Nachricht an den IAS gesendet. Die Einzelnen Komponenten des IAS Server aus Abbildung 5 haben folgende Aufgaben: IAS ist für das Empfangen der RADIUS Access-Request Nachrichten, das Entpacken der SoHs und das Weiterleiten der SoHs an Quarantine Server zuständig. Quarantine Server ist Teil der NAP Plattform und erleichtert die Kommunikation zwischen dem IAS und den SHVs. Die Schicht der Einzelnen System Health Validators (SHV) beinhaltet für jeden zu Überprüfenden Zustand einen SHV. Zum Beispiel kann hier ein SHV für die Überprüfung von Antiviren Updates vorhanden sein. Weiters ist es auch möglich das einzelne SHV mit einem Policy Server verbunden sind, um von diesem aktuelle Updates zu erhalten. Bei dieser Konfiguration handelt es sich um die Standard Konfiguration bei der es einen NAP Server und einen IAS Server gibt. Es ist jedoch auch möglich auf jeden NAP Server den IAS Server zu installieren. In diesem Fall befinden sich alle NAP Komponenten auf einem Server und es muss jeder Server so konfiguriert werden, dass er die richtigen Policies und Richtlinien für Gesunde Systeme verwendet und durchsetzt. Für die in den Schaubildern erwähnten APIs findet man im Windows Server Longhorn SDK eine ausführliche Dokumentation damit auch eigene SHV oder QEC implementiert und eingesetzt werden können. Das Folgende Schaubild zeigt das Zusammenarbeiten der einzelnen NAP Komponenten. Seite 11 von 18

12 Abbildung 6: Beziehungen der NAP Komponenten [Micro05-NAP3] 3.3 TCG Trusted Network Connect (TNC) Das Ziel der TNC Architektur ist das bereitstellen eines Frameworks mit Hilfe dessen es möglich sein soll eine Standard Spezifikation zu erstellen die in einem heterogenen Netzwerk folgende Funktionen zur Verfügung stellt: Platform Authentication: Die Verifizierung der Identität eines Gerätes welches einen Neztwerkzugang anfordert und die Verfizierung der Integrität seiner Plattform. Endpoint Policy Compliance (Authorization): Definiert ein Level von Vertrauen im Bezug auf ein Endgerät, welches angibt welche Versionen von Programmen oder Updates des Betriebssystems oder der Viren Signatur installiert sein müssen. Policy Compliance kann auch als Autorisierung gesehen werden, bei welcher der Netzwerkzugang eines Endgerätes von der Erfüllung der Policy abhängt. Access Policy: Stellt sicher, dass sich ein Endgerät und/oder sein Benutzer vor dem Verbinden mit dem Netzwerk authentifizieren und sein Vertrauens-Level, Seite 12 von 18

13 unter Verwendung existierender Standards, Produkte oder Verfahren, bekannt geben muss. Assessment, Isolation and Remediation: Stellt sicher, dass Endgeräte, welche die Sicherheits-Policies für Vertrauenswürdige Systeme nicht erfüllen, nicht in das gesamte Netzwerk, sonder nur in einen Isolierten oder Quarantäne Teil des Netzwerkes dürfen. Über Remediation soll versucht werden, Systeme durch Updates in einen Zustand zu bringen, in welchem sie die Sicherheits-Policies erfüllen und anschließend Zugriff auf das gesamte Netzwerk erhalten. Dabei will TNC sicherstellen, das jedes Gerät welches die verwendeten Protokolle, die benötigte Soft und Hardware unterstützen kann, in dieser Umgebung integriert werden kann TNC Architektur Die TNC Architektur ist so gestaltet, dass sie mit einer Fülle von unterschiedlichen Netzwerk Geräten, Topologien und Konfigurationsimplementierung eingesetzt werden kann. Sie besteht aus mehreren Einheiten, Komponenten und Interfaces wie aus der folgenden Abbildung ersichtlich ist. Abbildung 7: TNC Architektur [TCG05-TNC] Die drei Spalten in dieser Abbildung stellen die folgenden Einheiten der TNC Architektur dar: Access Requestor (AR) Seite 13 von 18

14 Policy Enforcement Point (PEP) Policy Decision Point (PDP) In den Horizontalen Schichten werden die Komponenten der einzelnen Einheiten Gruppiert. Die beschrifteten Verbindungslinien stellen die standardisierten Interfaces dar. Im Folgenden werden die einzelnen Einheiten, Komponenten, Schichten und Interfaces genauer beschrieben TNC Schichten Network Access Layer In dieser Schicht befinden sich jene Komponenten, deren Hauptaufgabe es ist Netzwerk Verbindungen und Sicherheitsfunktionen zur Verfügung zu stellen. Mögliche Technologien auf dieser Schicht sind VPN oder 802.1x. Die Komponenten die sich hier befinden sind: Network Access Requestor (NAR), Policy Enforcement Point (PEP) und die Network Access Authority (NAA) Integrity Evaluation Layer Die Komponenten dieser Schicht sind für die Evaluierung der gesamten Integrität des Access Requestors zuständig. Integrity Measurement Layer Auf dieser Schicht befinden sich Plug-In Komponenten für das Sammeln und Verifizieren von Informationen die die Integrität betreffen und von Unterschiedlichen Sicherheitsanwendungen des Access Requestors benötigt werden TNC Einheiten Access Requestor (AR) ist eine Einheit welche versucht Zutritt zu einem geschützten Netzwerk zu erlangen. Policy Enforcement Point (PEP) ist diejenige Einheit welche die Entscheidungen der PDP über den Netzwerkzugriff durchsetzen muss. Policy Decision Point (PDP) ist die Einheit welche die Entscheidung über die Anfrage des AR unter Verwendung der Zutritts-Policy trifft. Wichtig ist noch anzumerken, dass es sich bei den Einheiten und Komponenten der TNC Architektur um logische nicht um physikalische Einheiten handelt. Wobei eine Seite 14 von 18

15 Einheit oder eine Komponente entweder ein einzelnes Programm, ein Gerät oder eine Replikation mehrerer Komponenten, verteilt über ein Netzwerk, ist Komponenten Network Access Requestor (NAR) ist eine Komponente welche für das Ermöglichen von Netzwerkzugängen verantwortlich ist. Wobei diese Komponente als Software implementiert werden kann. Auf einem AR können entweder ein NAR oder mehrere NARs laufen welche mit unterschiedlichen Verbindungen umgehen können. TNC Client (TNCC) ist eine Software Komponente welche auf einem AR betrieben wird und für das Sammeln von Integritätsdaten der IMCs, für die Unterstützung im Management des Integrity Check Handshake und für das Aufzeichnen und Bereitstellen von Integritätsinformationen von IMCs. Wobei hier der Integrity Check Handshake nur als Beispiel eines TCG Verifizierungs-Protokoll im Kontext von TNC ist. Integrity Measurment Collector (IMC) ist eine weitere Software Komponente die sich auf einem AR befindet und dort für das Sammeln sicherheitsrelevanter Informationen die die Integrität betreffen zuständig ist. Zu diesen Informationen zählen der Status der Personal Firewall oder des Antiviren Programms. Wichtig ist noch zu erwähnen, dass die TNC Architektur Platz für das Betreiben mehrer IMCs auf einem einzelnen AR bietet. Policy Enforcement Point (PEP) kontrolliert den Zugang zu einem geschützten Netzwerk. Wobei der PEP für die Entscheidung ob ein Zutritt gewährt wird oder nicht in Absprache mit einem PDP trifft. Ein Beispiel eines PEP ist der 802.1X Authentifizierer welcher oft in einem Wireless Access Point integriert ist. Network Access Authority (NAA) entscheidet darüber ob ein AR Zutritt erhält. Für diesen Zweck kann die NAA einen TNC Server befragen ob der AR die Integritätsbestimmungen der Security Policy erfüllt oder nicht. In manchen Fällen kann der NAA auch ein AAA Server sein. TNC Server (TNCS) managet den Nachrichtenfluss zwischen den IMVs und den IMCs, sammelt Handlungsempfehlungen von den IMVs und kombiniert diese, auf den Policies basierenden Empfehlungen, zu einer TNCS Handlungsempfehlung für die NAA. Seite 15 von 18

16 Integrity Measurement Verifier (IMV) verifiziert spezielle Aspekte der AR s Integrität basierend auf den empfangenen Informationen der IMCs und/oder anderer Daten TNC Interfaces Die in Abbildung 7 eingezeichneten Interfaces beschreiben die Beziehungen zwischen den einzelnen Komponenten und über welche Protokolle welche Daten ausgetauscht werden. Das Integrity Measurement Collector Interface (IF-IMC) ist die Schnittstelle zwischen den IMCs und den TNC Client. Es wird primär zum Sammeln von Integritätsinformationen für die IMCs verwendet damit diese mit den IMVs kommunizieren können. Weiters erlaubt es, wenn notwendig, die Koordination der IMCs mit den TNC Client. Zwischen den IMVs und dem TNC Server befindet sich das Integrity Measurement Verifier Interface (IF-IMV). Dieses Interface wird primär für das Empfangen von Integritätsinformationen, die von den IMVs zu den IMCs gesendet werden, benutzt. Zusätzlich erlaubt es noch den IMVs ihre Entscheidungen den TNCS zugänglich zu machen. Das TNC Client-Server Interface (IF-TNCCS) beschreibt die Interaction zwischen dem TNC Client und dem TNC Server für das austauschen von Integritätsdaten. Genauer gesagt definiert das IF-TNCCS ein Protokoll welches folgende Punkten umfasst: Senden von Nachrichten von IMCs zu IMVs Senden von Nachrichten von IMVs zu IMCs Session Management Nachrichten für die beiden ersten Punkte und andere Session Synchronisationsinformationen zwischen TNC Client und TNC Server. Die Vendor-Specific IMC-IMV Messages (IF-M) betrifft den Austausch von herstellerabhängigen Informationen zwischen IMCs und IMVs. Für den Transport von Nachrichten zwischen dem AR und dem PDP ist das Network Authorization Transport Protocol (IF-T) zuständig. Genau genommen wird Seite 16 von 18

17 dieses Protokoll zwischen dem Network Access Requestor und der Network Access Authority verwendet. Das Platform Trust Service Interface (IF-PTS) stellt Services, mit denen sichergestellt wird das TNC Komponenten Vertrauenswürdig sind, zur Verfügung. Das Policy Enforcement Point Interface (IF-PEP) erlaubt dem PDP mit dem PEP zu kommunizieren. Speziell gestattet es dem PDP den PEP Instruktionen, für das Isolieren des AR in der Remediation Phase und für das Erlauben des Netzwerkzugangs nach erfolgreicher Remediation, zu erteilen. 4. Zusammenfassung Zusammenfassend gesehen handelt es sich bei diesen drei Ansätzen für die Implementierung eines NAM um gelungene Ansätze, von denen sich jeder auf einem anderen Niveau befindet. Da es sich bei den Ansätzen von Cisco und Microsoft um Lösungen handelt, welche in die Produkte dieser Hersteller integriert sind, ist es nur logisch das die Lösung von Cisco primär auf Hardware und die von Microsoft primär auf Software setzt. Die Lösung der TCG nimmt in gewisser weise eine Sonderstellung ein, da sie nicht versucht ein konkretes Produkt zu beschreiben, sondern ein allgemeines Framework für die Implementierung zur Verfügung stellen will. Welche dieser Lösungsansätze sich etablieren werden, wird sehr stark von der Akzeptanz der Kunden und von möglichen Implementierungen abhängen. 5. Referenzen [Esch05-NAM] Gerhard Eschelbeck, Kapitel 4 der Vortragsfolien zu Network Admision Management (NAM) im Rahmen des Seminars Netzwork Security, FIM/JKU, November 2005 [Cisco04-CNAC] Informationsprospekt über Cisco NAC pdf Seite 17 von 18

18 [Cisco05-CNAC] Implementing Network Admission Control Phase One Configuration and Deployment, Cisco nt_0900aecd80234ef4.pdf [Micro05-NAP1] Microsoft TechNet, Network Access Protection Platform Overview, 29.Juni mspx [Micro05-NAP2] Microsoft Windows Server System White Paper, Network Access Protection Platform, Juni 2004 Update Juli spx, NAPIntro.doc [Micro05-NAP3] Microsoft Windows Server System White Paper, Network Access Protection Platform Architecture, Juni 2004 Update Juli spx, NAPArch.doc [TCG05-TNC] TCG Trusted Network Connect TNC Architecture for Interoperability, Specification Version 1.0, Revision 4, 3.Mai tecture_v1_0_r4.pdf [TCG05-TNC2] TCG Trusted Network Connect to Ensure Endpoint Integrity, Mai 2005, Seite 18 von 18