Secure Data Center für Großunternehmen – Threat Management ...€¦ · Secure Data Center für...

Secure Data Center für Großunternehmen –Threat Management mit NextGen IPSDesignhandbuch – Letzte Aktualisierung: 24. April 2015

Informationen zu den Autoren

Tom Hogue

Mike Storm

Bart McGlothin

2

Matt Kaneko

Informationen zu den Autoren

Tom Hogue, Security Solutions Manager, Security Business Group, Cisco

Tom Hogue ist Data Center Security Solutions Manager bei Cisco und arbeitet dort

seit mehr als 20 Jahren an der Entwicklung integrierter Lösungen. Zuvor war er in

anderen Unternehmen der Branche tätig. Er leitete die Entwicklung branchenführender

Rechenzentrumslösungen, wie z. B. FlexPod und Vblock, und sicherer

Multi-Tenant-Funktionen. In seiner jetzigen Position leitet er die Lösungsentwicklung

für das Lösungsportfolio des Secure Data Center for the Enterprise, und er wirkte am

Cisco Validated Design-Handbuch „Single Site Clustering with TrustSec“ mit.

Mike Storm, Senior Technical Engineering Leader, Security Business Group, Cisco CCIE Security #13847

Mike Storm leitet die globale Sicherheits-Community bei Cisco Systems, die

Informationen zu Konkurrenzunternehmen und deren Architekturen sammelt

und auswertet. In erster Linie kümmert er sich um das Thema Sicherheit im

Rechenzentrum und entwickelt Architekturen, die auf die nahtlose Integration

mit Sicherheits-Services der nächsten Generation in Rechenzentren und

Virtualisierungstechnologien für Unternehmen der Enterprise-Klasse ausgelegt sind.

Mike hat mehr als 20 Jahre Erfahrung in der Netzwerk- und Cyber-Sicherheitsbranche.

Er arbeitete in diesem Bereich unter anderem als Enterprise Consultant und Technical

Writer sowie als Professional Speaker in diesem Bereich. Er ist Autor mehrerer

diesbezüglicher Publikationen, u. a. des Secure Data Center Design Field Guide und

war an der Erstellung des Validated Design-Leitfadens „Single Site Clustering with

TrustSec“ mit.

Bart McGlothin, Security Systems Architect, Security Business Group, Cisco

Bart McGlothin ist Security Solutions Architect bei Cisco mit mehr als 15 Jahren

Erfahrung in der Entwicklung von Branchenlösungen. Er ist hauptverantwortlich für

die Kommunikation und Zusammenarbeit zwischen Cisco und dem National Retail

Federation's Association for Retail Technology Standards Committee. Vor seinem

Wechsel zu Cisco war er Netzwerkarchitekt bei Safeway, Inc.

Matt Kaneko, Security Systems Architect, Security Business Group, Cisco

Matt Kaneko ist der Hauptverantwortliche für die technische Umsetzung von Lösungen innerhalb des Secure Data Center Solution-Teams. Er und sein Team arbeiten eng mit Produktmarketingteams verschiedener Geschäftsgruppen zusammen. Basierend auf diesem Austausch und auf Kundenfeedback erstellen sie Lösungsarchitekturen. Davor arbeitete Matt als Technical Marketing Manager für verschiedene Cisco Security-Produktserien, darunter Cisco ASA Next-Generation Firewall, Cisco Intrusions-Schutzsystem, Cisco AnyConnect und die zugehörige Managementproduktserie.

Secure Data C

I N H A L T

Einführung 5Ziel dieses Dokuments 5Zielgruppe 6

Secure Data Center for the Enterprise – Lösungsübersicht 6Zusammenfassung 6

Lösungsdesign – Übersicht 7Threat Management mit NextGen IPS 7

Cyber-Bedrohungen für das Rechenzentrum 8Angriffskette 10Anzeichen für Bedrohungen (Indicators of Compromise) 12Die dynamische und ständig wachsende Bedrohungslandschaft 13Ein Sicherheitsmodell, das integrierte Abwehr von Bedrohungen nutzt 14

Threat Management-Systemfunktionen 16Bedrohungseingrenzung und Problembehebung 18Zugriffskontrolle und -segmentierung 18Identitätsmanagement 19Anwendungstransparenz 19Protokollierung und Nachverfolgbarkeitsmanagement 19Strategische Anforderungen zur Implementierung integrierter Abwehr von Bedrohungen 20

Threat Management-Technologien 22Retrospective Security: Ein Blick über den Ereignishorizont hinaus 22Schlüsseltechnologie für Retrospective Security: Trajectory 23Network File Trajectory und Device Trajectory 24

Threat Management-Funktionen für sämtliche Abläufe 32Validierte Komponenten 34

Design-Überlegungen zu Threat Management mit NextGen IPS 34FirePOWER-Appliance und Integration der Management-Plattform 34

Plattform-Management – FireSIGHT Management Center 34Verwendung redundanter FireSIGHT Management Center 35Lizenz-Erwägungen 37NextGen IPS Fabric Integration 38Threat Management mit NextGen IPS-Design 40

3enter for the Enterprise – Handhabung von Sicherheitsrisiken mit NextGen IPS

Secure Data C

Threat Management-Systemfunktionen – Überlegungen zum Design 59Bedrohungseingrenzung und Problembehebung 59Zugriffskontrolle und -segmentierung 65Identitätsmanagement 67Anwendungstransparenz und -kontrolle 68Protokollierung und Nachverfolgbarkeitsmanagement 72

Validierungsergebnisse 74

Zusammenfassung 74

Referenzen 75

4enter for the Enterprise – Handhabung von Sicherheitsrisiken mit NextGen IPS

Einführung

Ziel dieses DokumentsCisco Secure Data Center for the Enterprise ist ein Portfolio aus Lösungen, die Unterstützung bei Design und Implementierung für Unternehmen bieten, welche physische und virtualisierte Workloads in ihren Rechenzentren bereitstellen und gleichzeitig besten Schutz haben möchten, um sich gegen die komplexen Bedrohungen der Datensicherheit in der heutigen Welt zu wehren. Dieses Dokument behandelt vor allem die Unterstützung bei der Integration von Threat Management mit NextGen IPS in das Secure Data Center for the Enterprise-Lösungsportfolio. Es baut auf den Design- und Bereitstellungsanleitungen auf, die mit den entsprechenden Lösungen zur Verfügung gestellt werden, wie die Lösungsübersicht in Abbildung 1 zeigt.

Abbildung 1 Cisco Secure Data Center for the Enterprise-Portfolio – Lösungsübersicht 6

Weitere Inhalte, die nicht in diesem Dokument enthalten sind, finden Sie unter den zusätzlichen Inhalten im

Secure Data Center Solution-Portal unter folgender URL: http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-secure-data-center-portfolio/index.html

3479

30

Cisco Secure EnclaveArchitecture

Einzelstandort-Clustering mit Cisco TrustSec

Cisco Threat Managementmit NextGen IPS

Cisco Cyber Threat Defensefür das Rechenzentrum

Konvergente InfrastrukturComputing• Storage• Hypervisor (Flexpod, Vblock, VSPEX)VirtualisierungInfrastrukturmanagementAccess LayerSecure Enclaves

Firewall-ClusteringIntrusion PreventionAktualisierungen in EchtzeitManagement

TrustSec• SXP• Sicherheitsgruppen-Tags• Richtliniendurchsetzung• SGACLs• FWACLs

NextGen IPS in ASA ClusterDefense CenterFireSIGHTAnwendungstransparenzNetzwerk-AMPFireAMPRetrospektionFile TrajectoryNetwork Trajectory

Lancope StealthWatch• FlowCollector• FlowSensor

NetFlowNSEL

CISCO SECURE DATA CENTER FOR THE ENTERPRISE-LÖSUNGSPORTFOLIO

Unternehmenszentrale:

Copyright © 2014 Cisco Systems, Inc. Alle Rechte vorbehalten

Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-secure-data-center-portfolio/index.html

Secure Data Center for the Enterprise – Lösungsübersicht

ZielgruppeDieses Dokument enthält hilfreiche Informationen insbesondere für Sicherheitsarchitekten, Systemarchitekten, Netzwerkdesigntechniker, Systemtechniker, Außendienstmitarbeiter, Advanced Services-Spezialisten und Kunden, die mehr über das Bereitstellen einer robusten Sicherheitsarchitektur in einem Rechenzentrum erfahren möchten, um die komplexen Bedrohungen von heute abzuwenden. Bei dieser Bereitstellung soll weder die Flexibilität, virtualisierte und physische Workloads zu betreiben, noch Funktionen in herkömmlichen Modi oder von in die Cloud migrierten Betriebsmodellen beeinträchtigt werden. Dieses Dokument greift auch auf weitere ergänzende Lösungen zurück, die in separaten Design- und Bereitstellungsanleitungen dokumentiert sind. Für dieses Designhandbuch wird vorausgesetzt, dass der Leser mit den grundlegenden Konzepten von IP-Protokollen, Quality of Service (QoS), hoher Verfügbarkeit (HA) und Sicherheitstechnologien vertraut ist. Des Weiteren wird vorausgesetzt, dass der Leser mit den allgemeinen Systemanforderungen vertraut ist und über Kenntnisse im Hinblick auf das Unternehmensnetzwerk und die Rechenzentrumsarchitekturen verfügt.

Secure Data Center for the Enterprise – Lösungsübersicht

ZusammenfassungDas Secure Data Center for the Enterprise-Portfolio entwickelte sich aus einem zentralen Designhandbuch für Kunden zur Integration von Cisco ASA-Firewalls in die Rechenzentrums-Fabric. Im November 2013 wurde dieses Designhandbuch nach dem Modulprinzip ergänzt, um eine umfassende Palette an Designleitfäden für Kunden zur Verfügung zu stellen. Mit der Single Site Clustering-Lösung mit TrustSec wurden ASA 5585-X Clustering für Skalierbarkeit, TrustSec für Richtlinienaggregation und Intrusion Prevention zum Schutz vor Bedrohungen eingeführt. In Kombination mit der Secure Enclaves-Referenzarchitektur und Cyber Threat Defense für Rechenzentren bildet diese Lösung ein äußerst leistungsstarkes Sicherheitsportfolio für unsere Kunden. Daher wird dieses Produktportfolio in seiner Gesamtheit auch als Secure Data Center for the Enterprise-Portfolio bezeichnet, welches in Zukunft um weitere Funktionen ergänzt werden soll.

Threat Management mit NextGen IPS ist das nächste Cisco Validated Design, das zum Secure Data Center for the Enterprise-Lösungsportfolio hinzugefügt werden soll. Dieses neue Cisco Validated Design baut auf Single Site Clustering mit TrustSec auf und demonstriert Kunden, wie sie FirePOWER NextGen IPS in die Architektur integrieren können und mit dieser Lösung umfassende Funktionen für ein Threat Management-System erhalten. Das Designhandbuch verfolgt einen anderen Ansatz, indem er die Perspektive eines Cyber-Angreifers darstellt. Er erläutert die Angriffskette aus Sicht der Angreifer, wo sie ihre Funktionen entwickeln, um einen erfolgreichen Angriff durchzuführen. Auf diese Weise wird deutlich, dass zur Verteidigung neue Funktionen entwickelt und implementiert werden müssen, um ein Thread Management-System aufzubauen. Dieses Cisco Validated Design behandelt nicht die grundlegenden Schritte zum Schutz des Rechenzentrums, wie zum Beispiel Sicherstellen, dass keine Standardpasswörter verwendet werden. Unternehmen wird daher dringend geraten, sich für entsprechende Branchenvorgaben zu entscheiden und die Sicherheitskontrollen entsprechend zu implementieren. Dieses Dokument erläutert eine neue Funktionen und beschreibt, wie die neue FirePOWER NextGen IPS Plattform in die Fabric integriert wird.

6

Lösungsdesign – Übersicht


Threat Management mit NextGen IPSAbbildung 2 zeigt das Architektur-Framework für die Threat Management mit NextGen IPS-Lösung. Zur Erinnerung: Diese Lösung basiert auf Secure Data Center Single Site Clustering mit TrustSec als Basis. Sie ist damit Voraussetzung für dieses Designhandbuch.

Abbildung 2 Threat Management mit NextGen IPS

VPC-Peer

VPC-Peer

QFPQFP

WAN

FireSIGHTManagement Center

NetFlow Collector

NetFlow Generation Appliance

Identity Services Engine

Tier1

Tier2

TierN

DefenseCenter

StealthWatch-Konsole

Cisco SecurityManager

ISE-Admin-Portal

UCS Director

Rollenbasierter Betrieb

3479

31

(2) 10-GE-Verbindungen

ErweiterterEchtzeitschutzder Cisco SIO

DC Core Layer

DC-Aggregation und Serviceebene

Nord-Süd-Schutzservices für Serverfarmen Schutz vor Malware für Netzwerke

Hinweis: CCL = Cluster Data Link Redundante Verbindung zur Nexus 7000-Serie

Virtuelles Netzwerk und Zugriff

Ost-West-Schutz Zonenbasiertes Filtern

Physischer Zugriff

Physischer Zugriff

Computing

Storage

KonvergentesNetzwerk-Rack

Rack-Serverbereitstellung

Physisch-virtuelle-Umgebungen für Workloads

CCLCCL

ASA 5585-X-Cluster mit Sourcefire NGIPS bis zu 16 ASA 5585-X-Knotenpunkte bis

zu (16) Sourcefire 8250- oder 8350-Stacks

Workload und Sicherheit

Servicesautomatisierung Konvergentes, integriertes Infrastrukturmanagement

Benutzerintegration Statusüberprüfung

für Geräte Richtlinien-

aggregations-verwaltung

Richtlinienverwaltung für Zugriffskontrolle

NetFlow-basierter Bedrohungsschutz Verhaltensanalyse

Benutzer- und Ablaufkontex-

analyse Management der

Reaktion auf Zwischenfälle und Netzwerkforensik

Erweiterter Malware-Schutz Benutzer- und

Ablaufkontext Anwendung für

Bedrohungsschutzman-agement in Echtzeit

Transparenz URL-Kontrolle

Management und Betriebsabläufe

7


Threat Management mit NextGen IPS nutzt die Designanleitung des Single Site Clustering mit TrustSec, die Technologien umfasst, welche wirkungsvollere Sicherheitsfunktionen im gesamten Rechenzentrum ermöglichen, sofern die folgenden Designvorgaben erfüllt sind:

• ASA-Firewall-Clustering für Skalierbarkeit

• Fabric-Integration mit Virtual Port Channels (vPCs)

• Link-Aggregation für einen vereinfachten Betrieb

• Schutz vor Sicherheitsrisiken und Anwendungstransparenz

• Signatur-Updates in Echtzeit

• Sicherheitsgruppen-Tags (SGTs) für Richtlinienaggregation

Das Designhandbuch für Threat Management mit NextGen IPS erweitert das Single Site Clustering um die TrustSec-Lösung und erläutert die Integration der FirePOWER NextGen IPS-Plattform in die Architektur – sowohl aus physischer als auch aus virtueller Perspektive. Die FirePOWER-Anwendung bietet Funktionen zum Schutz vor Bedrohungen, die weit über herkömmliche IPS-Angebote hinausreichen. Kombiniert man diese Funktionen mit denen, die im Secure Data Center for the Enterprise-Portfolio enthalten waren, entsteht eine umfassende Lösung, die Kunden dank enorm leistungsstarken Thread Management-Workflows eine höchst effektive Reaktion auf die aktuellen Cyber-Bedrohungen ermöglicht.

Cyber-Bedrohungen für das Rechenzentrum

Für Unternehmen ist ein herkömmliches Rechenzentrum in der Regel der Ort, an dem sich die wichtigsten und wertvollsten Ressourcen befinden Dies können Daten in Form von urheberrechtlich geschützten Informationen, Kundenkontakte, Kundenkreditkarten, Finanzinformationen des Unternehmens, Bankkonten des Unternehmens, Mitarbeiterinformationen, etc. sein. Wenn die Daten im Rechenzentrum für das Unternehmen wertvoll sind, sind sie das auch für Cyberkriminelle – ganz gleich, ob aus Finanz-, Spionage- oder anderen Gründen. Es ist unstrittig, dass die Rechenzentren eine wichtige Ressource sind, die geschützt werden muss. Die meisten Unternehmen verfügen über ein gewisses Maß an Segmentierung mit Richtlinien für die Zugriffskontrollen, um sicherzustellen, dass nur autorisierte Benutzer Zugriff auf Informationen im Rechenzentrum haben, und zwar nur auf die Informationen, die sie wirklich benötigen. Leider basiert dieser Ansatz auf einigen veralteten Annahmen. Daher muss der Schutz der Rechenzentren überdacht werden. Viele Organisationen verlassen sich allein auf Zugriffskontrolllisten und deren Durchsetzung, um das Rechenzentrum zu schützen. Dabei geht man in erster Linie davon aus, dass der „autorisierte“ Benutzer wirklich der ist, der er vorgibt zu sein, oder dass wirklich der autorisierte Benutzer die Kontrolle hat und mit seinem eigenen Gerät auf das Rechenzentrum zugreift. Eine der einfachsten Methoden, über die sich Cyber-Angreifer Zugriff in das Netzwerk eines Unternehmens verschaffen können, ist die Installation von Rootkits auf dem Endgerät eines Benutzers. Dies kann beispielsweise geschehen, wenn der nichts ahnende Benutzer zu Hause eine schädliche Website aufruft, während er nicht mit dem Unternehmensnetzwerk verbunden ist. (Siehe Abbildung 3).

8


Abbildung 3 Exploit-Kits

Sobald die Malware auf dem Endbenutzergerät installiert ist und sich der Benutzer wieder im Unternehmensnetzwerk anmeldet, nimmt die Malware die Identität des Endbenutzers an und kann auf alle Ressourcen des Rechenzentrums zugreifen, die der Benutzer normalerweise nutzen kann. An diesem Punkt ermöglichen diese Sicherheitszugriffskontrolllisten der Malware den Zugriff auf das Rechenzentrum über das Netzwerk (siehe Abbildung 4). Dieser Ansatz berücksichtigt nicht einmal den Fall, wenn Anmeldedaten gestohlen werden und die Cyber-Angreifer einfach über die Autorisierung auf die Rechenzentrumressourcen zugreifen können.

Abbildung 4 Kompromittierter Server

VM-basierte Rootkits

Sobald ein Cyber-Angreifer direkten Zugriff auf das Rechenzentrum hat, beginnt er, die Server und Anwendungen im Rechenzentrum zu bedrohen. Ein relativ neuer Typ von Exploits, die direkt die Rechenzentren angreifen, sind die VM-basierten Rootkits (Virtual Machine-Based Rootkits, VMBR), wie in Abbildung 5 dargestellt. Erfolgreiche VMBR-Exploits, wie Blue Pill, Vitriol und SubVirt, wurden bei Black Hat von Forschern vorgeführt. Ob diese Exploits nun von Cyber-Angreifern verwendet werden oder nicht – die Bedrohung ist real.

3479

32

Malwareserver überträgtMalware auf Client

Client istkompromittiert

Webserver lenkt Client zum Malwareserver um

KompromittierterWebserver

Benutzer

3479

33KompromittierterClient

Malware erhältKernel-Zugriff

VM

VM

VM

VM

VM

VM

9


Abbildung 5 VMBR-Rootkit

Die grundlegende Frage, die beantwortet werden muss, lautet: „Ist die Durchsetzung der Zugriffskontrolle sicher genug, um die Ressourcen des Rechenzentrums zu schützen?“ Während kein Zweifel besteht, dass sich die Cyber-Angriffe gegen das Rechenzentrum richten, ist es insbesondere die Kombination aus bestehenden Sicherheitsmodellen und neuen Cyberbedrohungen, die die neue wirkliche Gefahr für Rechenzentren darstellt.

Die oben genannten Beispiele sind sehr stark vereinfacht, die Bedrohungen für das Rechenzentrum hingegen extrem komplex. Im folgenden Abschnitt werden die Angriffskette und ein neues Sicherheitsmodell beschrieben, und es wird erläutert, wie das neue Modell in die in den folgenden Abschnitten beschriebenen Unterfunktionen einzuordnen ist.

Angriffskette

Im vorhergehenden Abschnitt wurde kurz erläutert, wie ein Rootkit funktioniert. Um jedoch frühere Annahmen zum Schutz des Rechenzentrums weiter zu untersuchen, müssen wir uns zunächst näher mit den behandelten Herausforderungen beschäftigen. Es ist wichtig, zu erkennen, dass die erfolgreicheren Cyber-Angriffe sehr gezielt ausgeführt werden. Die komplexeren Cyber-Angriffe können mithilfe

des Angriffskettenmodells aus der Perspektive des Cyber-Angreifers unterteilt werden (siehe Abbildung 6).

Abbildung 6 Angriffskette

3479

34Malware hatKernel-Zugriff

VM-Überwachungkompromittiert

Malwarekontaktiert Hauptserver

VMs unterCyberangriffskontrolle

VM

VM

VM

VM

VM

VM

3479

35Untersuchung Entwicklung Überprüfung Durchführung Erreichung

10


Der im Juli 2000 im Air Force Magazine erschienene Artikel von John A. Tirpak „Find, Track, Target, Engage, Assess“ erläutert das Konzept einer Kill Chain vor. Diese Worte hat er aus der Rede von General Ronald R. Fogleman, Chef des Einsatzstabs der Luftwaffe, vom Oktober 1996 übernommen. Dieser erklärte damals: „Alles, was sich auf der Erdoberfläche bewegt, kann ausfindig gemacht, dingfest gemacht und nachverfolgt werden.“ Die Konzepte dieser Rede resultierten schließlich in der Kill Chain „Find, Fix, Target, Engage, Assess“ (finden, dingfest machen, anvisieren, angreifen, auswerten). Im Laufe der Zeit haben die Verschiedenen Gattungen des Militärs die Kill Chain an ihre individuellen Anforderungen angepasst. Dieser Bericht schlägt noch eine weitere Version des Kill Chain-Konzepts vor, die eher der Denkweise eines Softwareentwicklers (oder Hackers) entspricht. Beachten Sie, dass die Angriffskette nicht einem bestimmten Zeitplan zugeordnet wird, da einige Cyber-Angreifer ihre Ziele über mehr als ein Jahr hinweg bearbeiten, um zu vermeiden, dass sie erkannt werden. In anderen Fällen erfolgen die Angriffe sehr schnell –innerhalb von Minuten. Viele Unternehmen haben das Kill Chain-Konzept verwendet, um Modelle zum Schutz vor Cyber-Bedrohungen zu entwickeln.

Untersuchung

Um sich auf Angriffe vorzubereiten, ist es wichtig, zu wissen, wie die Umgebung aussieht:

• Welche Ports sind offen, und muss das Rootkit über mehrere Ports arbeiten?

• Welche Betriebssysteme werden erkannt?

• Welche Umgehungs- und Verschleierungstechniken muss ein Cyber-Angreifer einsetzen?

• Welches sind die wichtigsten im Zielunternehmen eingesetzten Schutzmechanismen?

• Wie weit kommt ein Cyber-Angreifer mit der Verwendung von Standard-Passwörtern?

• Können E-Mail-Adressen für eine Vielzahl von Benutzern ausgespäht werden, um eine Phishing-Kampagne zu starten?

Leider sind Phishing-Kampagnen nach wie vor äußerst erfolgreich. Das ergab der Verizon 2014 Data Breach Report. Darin wurde gezeigt, dass die Erfolgsquote bei nur zehn E-Mails, die an Endbenutzer gesendet werden, immer noch bei 90 Prozent liegt.

Entwicklung

Nachdem die gründliche Untersuchung für den Cyber-Angriff abgeschlossen ist, beginnt der Angreifer damit, Funktionen für einen erfolgreichen Angriff zu entwickeln. Dabei ist zu beachten, dass das Wort entwickeln nicht unbedingt bedeutet, dass neue Malware von Grund auf geschrieben werden muss. Es gibt zahlreiche Malware-Optionen, aus denen ein Cyber-Angreifer auswählen kann, ohne jemals selbst einen Code schreiben zu müssen. Obwohl es allgemein bekannt ist, ist es kaum zu glauben, dass man Lizenzen und Serviceverträge für Malware erwerben kann. Wenn der Angreifer benutzerdefinierte Malware für sein Ziel erstellen möchte, gibt es viele Open Source-Codes, die individuell angepasst werden können. Dies ist eine sehr effiziente Methode für die Community der Cyber-Angreifer.

Überprüfung

Sobald er über die richtigen Tools verfügt, fährt der Cyber-Angreifer mit der Test- und Validierungsphase fort. Es ist sehr wichtig für den Cyber-Angreifer, dass er unerkannt auf die Zielressourcen zugreifen kann. Wenn die Angreifer zu früh in der Angriffskette erkannt werden, müssen sie von vorne beginnen, da ihr anvisiertes Opfer neue Gegenmaßnahmen ergreift. Angreifer müssen sicherstellen, dass ihre Verschleierungstechniken effektiv sind. Sie wollen Zugriff erlangen, unentdeckt bleiben und sich ausreichend Zeit nehmen, um ihr Ziel zu erreichen.

11


Durchführung

Sobald die Überprüfung abgeschlossen ist, können die Angreifer sich Zugriff auf die Ressourcen des Ziels verschaffen. Dazu können sie entweder Malware auf den Endbenutzergeräten installieren, oder auf Web-Anwendungsserver, E-Mail-Server und alle anderen Geräte zugreifen, über die sie unbemerkt in das Netzwerk eindringen können. Sobald sie ins Netzwerk eingedrungen sind, versuchen sie, eine sekundäre Zugriffsmethode einzurichten, falls ihr Hauptziel durch Gegenmaßnahmen geschützt ist. Dieser wichtige Schritt wird später in diesem Dokument weiter erläutert.

Abschluss

Nachdem der Cyber-Angreifer nun Zugriff auf das Zielnetzwerk hat, kann er sein Vorhaben vollenden: Wertvolle Daten werden extrahiert oder zerstört, Verweise werden hinterlassen sowie weitere Aktionen durchgeführt, um das Ziel des Cyber-Angriffs zu erreichen. Ein Cyber-Angreifer findet auch Stellen, an denen er seine Malware für zukünftige Cyber-Attacken platzieren kann.

Anzeichen für Bedrohungen (Indicators of Compromise)

In vielen Fällen liegt zwischen der Umsetzung und dem Abschluss eines Angriffs mehr als ein Jahr. Viele Cyber-Angreifer setzen auf die Strategie „Abwarten und Tee trinken“, um ihre Angriffe mit maximaler Effizienz zu führen. Bei dieser Strategie gibt es, wenn überhaupt, nur sehr wenige Anzeichen für eine Kompromittierung. Wenn man bedenkt, dass dieser Ansatz so wenige Anzeichen liefert, im Vergleich zu den Tausenden von Warnungen, die von vorhandenen Bedrohungssystemen generiert werden, ist es kein Wunder, dass diese Arten von Angriffen sehr schwierig zu erkennen sind. Bevor die Anzeichen für eine Kompromittierung identifiziert wurden, setzte die Branche auf Anzeichen eines Angriffs. Herkömmliche Intrusion Prevention Systems boten Anzeichen für einen Angriff, indem Warnungen anhand des Abgleichs einer signaturbasierten Point-in-Time-Einstufung ausgelöst wurden. Die IPS-Systeme gaben leider viele falsch-positive Meldungen aus. Dies lag an dem Traffic-Fluss, der mit Signaturen übereinstimmt, aber harmlos ist. Die Betreiber identifizierten dann Signaturen, die mit dem gutartigen Verkehr von bestimmten Hosts übereinstimmten, damit diese Traffic-Flüsse keine Warnungen generieren. Die verbleibenden Warnmeldungen wurden als Anzeichen für Angriffe behandelt, die vom IPS-System identifiziert wurden. Leider waren diese falschen Warnungen so zahlreich, dass echte Warnmeldungen oft einfach übersehen wurden. Wenn die Unternehmen dann ein glaubhaftes Anzeichen für eine Kompromittierung erkannt hatten, mussten sie eine zeitraubende und schwierige Analyse durchführen, um die folgenden Fragen zu beantworten:

• Welche Methode und welcher Angriffspunkt wurden genutzt?

• Welche Systeme waren betroffen?

• Was genau hat die Bedrohung verursacht?

• Kann ich die Bedrohung und ihre Ursachen aufhalten?

• Wie kann der Schaden behoben werden?

• Wie kann der Angriff in Zukunft abgewehrt werden?

Cyber-Sicherheitsteams brauchten einen neuen Ansatz, der auf einem umfassenden Satz genauer Daten basiert, um zuverlässige Anzeichen für Kompromittierung abzuleiten. Ein solcher Ansatz, der eine breitere und auch genauere Analyse der Ergebnisse ermöglichen würde, könnte beispielsweise folgende Elemente umfassen:

• Was ist dieser Angriff? Beispielsweise ein bekannter Typ oder eine Kategorie.

• Welches sind die wesentlichen Merkmale des Angriffs? Beispielsweise die Vorgehensweise des Angreifers. Was hat sich möglicherweise am anvisierten Endpunkt geändert usw.?

12


• Woher kam der Angriff?

• Wie wurde der Angriff festgestellt?

• Welcher Endpunkt ist Ziel des Angriffs? Welches Betriebssystem?

• Ist das Ziel für diese Bedrohung anfällig?

• Ist der Endpunkt durch diesen oder andere Angriffe kompromittiert worden, aktuell oder in der Vergangenheit?

• Welche anderen Systeme hat dieses Gerät kontaktiert?

• Welche Anwendung wird anvisiert (z. B. Client oder Web)?

• Besteht die Möglichkeit, dass das Ziel durch dieses Ereignis beeinträchtigt wurde?

• Ist dies ein neues Problem, oder wurde es über eine externe Quelle eingeschleust, beispielsweise Bring-Your-Own-Device (BYOD)?

• Befindet sich der angreifende Host derzeit im Netzwerk oder außerhalb des Netzwerks?

• Was war/ist die Ursache?

• Kann das System sofort ermitteln, wie viele Hosts oder Netzwerkgeräte möglicherweise für diese Bedrohung anfällig sind?

• Wenn dieser Angriff blockiert wird, wie kann das System feststellen, ob es sich tatsächlich um einen Angriff handelt oder nicht?

Ein Beispiel für ein gutes Kennzeichen einer Kompromittierung wäre, wenn eine Java-Anwendung anfängt, Anwendungen zu installieren und auszuführen, was nie passieren sollte. Leider ist Java ein gängiger Bedrohungsvektor und nach wie vor der Favorit vieler Cyber-Angreifer. Diese Angriffsart kann ganz einfach mit jeder beliebigen Zugriffskontrollliste übereinstimmen und von herkömmlichen IPS übersehen werden, da die Dateisignatur keine Warnmeldung auslöst. Um eine erweiterte Anzeige für Kompromittierungen zu erreichen, müssen Ereignisse aus folgenden Komponenten und Aktivitäten korreliert werden:

• Malware-Aktivitäten

• Identifizierung von Sicherheitsrisiken

• Netzwerkverbindungen

• Network File Trajectorys

• Device Trajectorys

• Gerätenetzwerkverlauf, einschließlich, aber nicht beschränkt auf laterale Bewegungen, Überordnungs- und Unterordnungsverhältnisse oder Kontext

Das Ziel ist für alle oben genannten Aspekte gleich: Korrelation mit Netzwerk-, Endpunkt-, Anwendungs- und Benutzerkontext. Der daraus resultierende Datensatz bietet auf eine einzigartige Weise ausreichend präzise Indikatoren für Kompromittierung über das gesamte Netzwerk hinweg, die zuverlässig und sofort umgesetzt werden können.

Die dynamische und ständig wachsende Bedrohungslandschaft

Moderne erweiterte Netzwerke und ihre Komponenten entwickeln sich ständig weiter und bringen neue Angriffsvektoren mit sich: Mobilgeräte, webbasierte und mobile Anwendungen, Hypervisoren, Social Media, Webbrowser, integrierte Computer sowie eine enorme Verbreitung von Geräten, die das Internet of Everything mit sich bringt.

13


Die Menschen bewegen sich innerhalb und außerhalb des Netzwerks, nutzen diverse Geräte und greifen auf beliebige Anwendungen in vielen verschiedenen Cloud-Umgebungen zu. Dies ist die Any-to-Any-Herausforderung. Und während diese Komponenten die Kommunikation verbessert haben, bieten sie gleichzeitig mehr Möglichkeiten, über die Hacker sich Zugriff verschaffen können. Leider hat sich der Sicherheitsansatz der meisten Unternehmen nicht genauso schnell weiterentwickelt. Der Großteil der Unternehmen sichert erweiterte Netzwerke mithilfe unterschiedlicher Einzeltechnologien, die untereinander nicht kooperieren und nicht gemeinsam eingesetzt werden können. Sie verlassen sich möglicherweise auch zu sehr auf spezialisierte Service Provider für Sicherheit in der Cloud und Hosting-Unternehmen, um ihre Internet-Infrastruktur zu schützen. In dieser neuen Situation haben Administratoren allzu oft wenig Transparenz und Kontrolle für die Geräte und Anwendungen, die auf das Unternehmensnetzwerk zugreifen, und kaum Möglichkeiten, mit den neuen Bedrohungen Schritt zu halten.

Sicherheitsexperten, die mit komplexen Angriffen und der Any-to-Any-Infrastruktur konfrontiert sind, stellen sich die drei folgenden wichtigen Fragen:

1. Wie können wir angesichts neuer Geschäftsmodellen und Angriffsvektoren weiter die Sicherheit und Compliance gewährleisten, während sich unsere IT-Landschaft weiter verändert?

Unternehmen, die den Übergang zur Cloud, zur Virtualisierung oder zu Mobilgeräten vollziehen, weil diese Technologien Produktivität, Flexibilität und Effizienz bieten, müssen ihre Sicherheitsinfrastruktur entsprechend anpassen.

2. Wie verbessern wir unsere Fähigkeit, uns in einer dynamischen Bedrohungslandschaft laufend vor neuen Angriffsvektoren und immer komplexeren Bedrohungen zu schützen?

Angreifern ist es ganz gleich, wen sie attackieren. Sie suchen sich einfach das schwächste Glied in der Kette. Sie verwenden für ihre Angriffe häufig Tools, die speziell zur Umgehung der von ihrem Angriffsziel ausgewählten Sicherheitsinfrastruktur konzipiert sind. Sie achten penibel darauf, nicht entdeckt zu bleiben, und verwenden Technologien und Methoden, durch die Indicators of Compromise auf ein nahezu unmerkliches Niveau reduziert werden.

3. Wie können wir die beiden ersten Probleme lösen, und gleichzeitig Komplexität und Fragmentierung unser Sicherheitslösungen reduzieren?

Unternehmen können sich keine Sicherheitslücken erlauben, die erfahrene Angreifer von heute gerne ausnutzen. Gleichzeitig bieten getrennte, nicht integrierte Sicherheitslösungen bei zunehmender Komplexität nicht den erforderlichen Schutz vor modernen Bedrohungen.

Ein Sicherheitsmodell, das integrierte Abwehr von Bedrohungen nutzt

Wie bereits erwähnt sind neue Tools und Technologien erforderlich, um auf die modernen Bedrohungen angemessen zu reagieren, die nicht nur das Rechenzentrum betreffen, sondern auch das gesamte Unternehmen. Dies muss mithilfe eines Modells geschehen, das die Komplexität minimiert und einen kontinuierlichen Schutz der Unternehmensressourcen ermöglicht. Gleichzeitig muss es auch möglich sein, auf Änderungen in den Geschäftsmodellen, z. B. Any-to-Any, zu reagieren. Das Sicherheitssystem muss direkt in die Netzwerkstruktur integriert werden, um bestmögliche Effizienz und Funktionalität zu gewährleisten und gleichzeitig das normalerweise mit der Integration verschiedener, nicht netzwerkorientierter Sicherheitskontrollen einhergehende Risiko zu minimieren. Um ein solches System zu entwerfen, ist ein neues Modell erforderlich: Die Integration muss nahtlos erfolgen, vor allem im Rechenzentrum mit seiner äußerst geringen Fehlertoleranz. Dieses neue Modell ist eine nützliche Referenz bei der Entwicklung einer umfassenden Sicherheitslösung für jede Art von Netzwerk. Bei diesem neuen Modell gibt es eine Schlüsselkomponente – das so genannte Angriffskontinuum, welches alle wichtigen Mechanismen und Prozesse ermittelt, die für das umfassende Sicherheitssystem von Bedeutung sind. (Siehe Abbildung 7).

14


Abbildung 7 Integration von Bedrohungsabwehr mithilfe des Angriffskontinuums

Bei diesem Modell wird das Bedrohungsproblem gelöst, indem die Aktionen ermittelt werden, die vor, während und nach einem Angriff sowie über die gesamte Bandbreite der Angriffsvektoren – z. B. Endpunkte, mobile Geräte, Rechenzentrumsressourcen, VMs und selbst die Cloud – erforderlich sind. Während die meisten Sicherheitslösungen überwiegend darauf ausgelegt sind, die Bekämpfung von Bedrohungen zu bestimmten, festgelegten Zeitpunkten auszuführen, ist es wichtig, sie als kontinuierlichen Zyklus zu betrachten.

Vor einem Angriff

Kontextbewusste Angreifer erfordern kontextbewusste Sicherheit. Unternehmen müssen sich heute gegen Angreifer wehren, die häufig besser mit Maßnahmen zum Schutz der Infrastruktur vertraut sind, als die Unternehmen selbst. Um Angriffe abzuwehren, bevor sie überhaupt auftreten, benötigen Unternehmen volle Transparenz hinsichtlich ihrer IT-Umgebung, also u. a. über physische und virtuelle Hosts, Betriebssysteme, Anwendungen, Services, Protokolle, Benutzer, Inhalte und das Netzwerkverhalten, um so die Oberhand über die Angreifer zu gewinnen. Die Verantwortlichen müssen anhand von Angriffszielen, Legitimität von Angriffen und Verläufen die Risiken für ihre Infrastruktur verstehen. Wenn die Verantwortlichen nicht wissen, was sie zu schützen versuchen, sind sie nicht in der Lage, geeignete Sicherheitstechnologien zum Schutz ihrer Ressourcen zu konfigurieren. Transparenz muss im gesamten Netzwerk gewährleistet sein, d. h. für Endpunkte, E-Mail- und Web-Gateways, virtuelle Umgebungen und Mobilgeräte und auch Rechenzentren. Zusätzlich müssen auf Basis dieser Transparenz umsetzbare Warnmeldungen erzeugt werden, damit die Verantwortlichen fundiertere Entscheidungen treffen können.

Während eines Angriffs

Bösartige Angriffe und kombinierte Bedrohungen treten nicht zu einem bestimmten Zeitpunkt, sondern kontinuierlich auf und erfordern daher kontinuierliche Sicherheitsüberprüfungen. Die konventionellen Sicherheitstechnologien können nur Angriffe auswerten, die zu einem bestimmten Zeitpunkt auftreten, basierend auf einem einzelnen Datenpunkt des Angriffs. Dieser Ansatz ist gegen moderne Angriffe machtlos.

3479

36

Das neue Sicherheitsmodell

Angriffskontinuum

Mobilgerät Virtuelles CloudEndpunkteNetzwerke

Point-In-Time Durchgängig

VorherErkennen

DurchsetzenStärken

WährendErkennenBlockierenAbwehren

NachherAuswertenEingrenzen

Beheben

15


Hier ist eine Sicherheitsinfrastruktur gefragt, die sämtliche Informationen einbezieht. Gemeint ist eine Infrastruktur, die Daten aus dem erweiterten Netzwerk aggregieren und mit historischen Merkmalen und weltweiten Informationen zu Angriffen korrelieren kann. Sie muss Kontext liefern und legitime Hintergrundaktivitäten von aktiven Angriffen, Datendiebstahl und Ausspähung unterscheiden können. So wird das Sicherheitssystem von einer Aufgabe, die zu einem bestimmten Zeitpunkt durchgeführt wird, zu einem Prozess der kontinuierlichen Analyse und Entscheidungsfindung. Wenn eine als sicher eingestufte Datei in die Umgebung gelangt, aber später bösartiges Verhalten zeigt, können Unternehmen eingreifen. Dank dieser Echtzeitinformationen können Sicherheitsexperten intelligente Automatisierungsservices einsetzen, mit denen Sicherheitsrichtlinien ohne manuelle Eingriffe durchgesetzt werden.

Nach einem Angriff

Um das gesamte Angriffskontinuum abzudecken, brauchen Unternehmen Retrospective Security. Retrospective Security ist eine Big Data-Herausforderung und eine Funktion, die nur wenige Systeme gewährleisten können. Sicherheitsteams können mit einer Infrastruktur, die laufend Daten zum Sammeln von Sicherheitsinformationen erfasst und analysiert, mithilfe automatisierter Verfahren Indicators of Compromise identifizieren und Malware erkennen, die so ausgereift ist, dass sie ihr Verhalten ändert, um einer Erkennung zu entgehen sowie erkannte Probleme beheben.

Kompromittierungen, die andernfalls über Wochen oder Monate unerkannt geblieben wären, können so schnell identifiziert, gründlich untersucht, eingegrenzt und behoben werden. Durch dieses bedrohungsorientierte Sicherheitsmodell sind Unternehmen in der Lage, das gesamte Angriffskontinuum über alle Angriffsvektoren hinweg abzudecken und jederzeit in Echtzeit zu reagieren.

Threat Management-SystemfunktionenDas Angriffskontinuum-Modell bietet einen Überblick darüber, wie auf Bedrohungen reagiert werden kann. Es unterstützt Sie bei der Erstellung eines Frameworks von Funktionen als Basis für die Implementierung von Sicherheitskontrollen. So geht beispielsweise aus der NIST-Sonderveröffentlichung 800-53, „Security and Privacy Controls for Federal Information Systems and Organizations“, hervor, dass „Unternehmen die Definition bestimmter Sicherheitsfunktionen als Vorstufe zur Auswahl der Sicherheitskontrollen in Betracht ziehen können.“

Die NIST-Publikation definiert außerdem das Konzept der Sicherheitsfunktion als „Konstrukt, welches erkennt, dass der Schutz von Informationen, die durch Informationssysteme verarbeitet, gespeichert oder übertragen werden, selten von einer einzigen Schutz- oder Gegenmaßnahme (z. B. Sicherheitskontrolle) abhängig ist.“ Jedes Unternehmen sollte bemüht sein, die Einhaltung seiner jeweiligen Branchenstandards zu gewährleisten. In diesem Dokument wird zwar nicht die Einhaltung bestimmter konkreter Standards erläutert; dennoch bildet das Konzept der Funktionen den zentralen Kern eines Threat Management-Systems und dieses Dokuments. In Tabelle 1 werden die Threat Management-Systemfunktionen und -Beschreibungen zu den Angriffskontinuumphasen und den entsprechenden Produkten zugewiesen. Einige Produkte umfassen mehrere Funktionen, sodass die Zuordnung nicht immer 1:1 ist.

16


Tabelle 1 Threat Management-Systemfunktionen

Threat Management-Systemfunktionen Beschreibung Vorher Während Nachher ProdukteBedrohungsein- grenzung und Problembehebung

Untersuchung und Analyse von Bedrohungen auf Datei-, Paket- und Datenflussebene

Endpunktschutz- agenten, netzwerkbasierter Schutz des Datenverkehrs

Cloud-basierte Endpunktanalyse, netzwerkbasierte Dateianalyse, netzwerkbasierte Analyse des Datenverkehrs, signaturbasierte Analyse, Sandbox-Analyse

Verbindungs- und Datenverkehrs- analyse und Problembehebung

Sourcefire FireSIGHT, Schutz vor Sicherheitsrisiken, netzwerkbasierte AMP, E-Mail-AMP, CWS-AMP, FireAMP für Endbenutzer und mobile Geräte

Zugriffskontrolle und -segmentierung

Zugriffskontroll- richtlinien, Segmentierung, sichere Trennung

Endpunktegruppen-zuordnungen, Sicherheitszonen, Ressourcenzugriffs-richtlinien für Benutzer

Fabric-Durch- setzung, Firewall-Security-Durchsetzung, Datenverkehrs- normalisierung und Protokoll- Compliance

Durchsetzung von Richtlinien und Protokollierung

ASA 5585-X, SGTs, SGACL, SXP und TrustSec-fähige Switching Fabric oder ACI-Fabric mit ASAv

Identitätsmana- gement

Statusüber- prüfung für Benutzeridentität und -zugriff, netzwerkbasierter Benutzerkontext

Zuweisung von Benutzern zu Gruppen, Ressourcen und zulässigen Zugriffsstandorten

Benutzerkon- textanalyse

Benutzerzugriff und Analyse von Bedrohungs- entstehung und -behebung

Active Directory, Cisco ISE, Sourcefire FireSIGHT

17


Bedrohungseingrenzung und Problembehebung

Sie müssen Cyber-Bedrohungen erkennen und diese Bedrohungen so schnell wie möglich beheben. Dies ist keine Point-in-Time-Funktion, sondern eine kontinuierliche Funktion, die Retrospektion einsetzt. Wenn also eine Malware-Komponente zunächst nicht erkannt wird, kann das System die Malware zu einem späteren Zeitpunkt trotzdem noch finden und die Kompromittierung beheben.


Zugriffskontrollenrichtlinien und deren Durchsetzung bildeten die Grundlage für Netzwerksicherheit und sind auch weiterhin eine Schlüsselkernkomponente. Segmentierung ist ebenfalls ein wichtiges Mittel zur Trennung des Datenverkehrs. Die Unternehmen haben die Möglichkeiten dieses Verfahrens bisher jedoch nicht voll ausgeschöpft. Diese zwei Funktionen werden in der Regel als separate Funktionen betrachtet und in den meisten, wenn nicht sogar allen, Compliance-Standards in separate Kontrollen aufgeschlüsselt. Sie werden hier als Einheit behandelt, da sie im Rahmen der Entwicklung und Implementierung von Netzwerken in enger Wechselwirkung stehen. Jedes Netzwerk, das über eine wirksame Segmentierungsstrategie verfügt, sollte auch geeignete Zugriffskontrollrichtlinien bereitstellen, um die Sicherheitsdomänen zu definieren. Bei großen Sicherheitsdomänen besteht die Gefahr, dass Unternehmen im Falle einer Datenschutzverletzung einem erheblichen Risiko ausgesetzt sind. Mithilfe neuer Segmentierungstechniken kann die Größe dieser Sicherheitsdomänen reduziert und so deren Verwaltung vereinfacht werden.

Anwendungs- transparenz und -kontrolle

Dateiüberwachung und File Trajectory, Network File Trajectory, Anwendungsqua- rantäne, Schutz vor Datenverlust

Richtlinien zur Beschränkung und Kontrolle des Zugriffs auf interne und externe Anwendungen

Durchsetzung von Anwendungs- kontrollrichtlinien, Untersuchung vertraulicher Daten

Transparenz aller im Netzwerk aufgerufenen und ausgeführten Anwendungen

Sourcefire Access Control, Sourcefire NGFW

Protokollierung und Nachverfolg- barkeitsmana- gement

Bedrohungs- forensik und Compliance

Richtige Konfiguration der Berichterstellung im Threat Management- System

Aktive Out-of-Band-Pro- tokollierung

Direkter Zugriff durch geeignete Bedrohungs- funktions-Mana- gementplattform Konsolidierung der Protokolle in zentralem Repository für weitere Forensik und Compliance

FireSIGHT Management Center für kurzfristige Protokolle, Lancope StealthWatch für längerfristige NetFlow Analyseprotokolle, SIEM für Protokollmanage- ment-Compliance (SIEM ist nicht im Umfang für Projekt)

Tabelle 1 Threat Management-Systemfunktionen (Fortsetzung)

Threat Management-Systemfunktionen Beschreibung Vorher Während Nachher Produkte

18


Identitätsmanagement

Jedes Unternehmen nutzt in irgendeiner Form Identitätsmanagement- und Autorisierungsfunktionen, wie z. B. Active Directory, zur Benutzerauthentifizierung. Leider verwenden nicht alle Unternehmen diese Funktion auch dazu, während der Authentifizierung eine Statusüberprüfung des jeweiligen Benutzers durchzuführen. Dadurch könnten sie den Benutzer – basierend auf seinem Endpunkt oder Standort oder anhand sonstiger relevanter Kriterien – zu den entsprechenden Sicherheitsrichtlinien zuweisen. Ebenfalls ist es wichtig, Benutzerkontext zu Traffic-Fluss, Dateianalyse, Netzverbindungen und zu den anderen Netzwerkaktivitäten hinzuzufügen, um ein wirksames Threat Management zu gewährleisten.

Anwendungstransparenz

Anwendungstransparenz über das gesamte Netzwerk ist eine entscheidende Funktion für jedes Unternehmen, die in keinem Portfolio zum Schutz vor Cyber-Bedrohungen fehlen darf. Anwendungen sind immer noch ein Hauptangriffsvektor. Daher ist es äußerst wichtig, dass ungewöhnliches Verhalten von Anwendungen beim Zugriff auf Rechenzentrumsressourcen sowie deren Kommunikationsfluss analysiert werden kann.

Protokollierung und Nachverfolgbarkeitsmanagement

Es ist nach wie vor wichtig, dass sämtliche Aspekte der Netzwerk- und Endpunktaktivität detailliert protokolliert werden können. Nachverfolgbarkeit umfasst mehr als nur einen Zeitstempel für Warnmeldungen. Es geht darum, die File Trajectory zu bestimmen, wenn Malware in Netzwerke eingedrungen ist. Ein Unternehmen muss in der Lage sein, eine detaillierte Forensik durchzuführen, sobald eine Sicherheitsverletzung erkannt wird.

Zuordnung von Funktionen zu NIST-Kontrollen

Obwohl die Zuordnung der Compliance-Kontrolle in diesem Dokument nicht ausführlich behandelt wird, wollen wir dieses Thema der Vollständigkeit halber kurz ansprechen. Ein kurzer Blick in NIST SP 800-53 und die „SANs Top 20 Critical Security Controls“ ermöglicht eine Zuordnung der zuvor erläuterten Funktionen zu den in diesen beiden Dokumenten behandelten Kontrollen. Wie in Tabelle 2 erläutert, können nicht alle Kontrollen zugeordnet werden – die meisten Internetsicherheitskontrollen werden jedoch berücksichtigt.

19


Strategische Anforderungen zur Implementierung integrierter Abwehr von Bedrohungen

Es gibt eine Reihe von Anforderungen, die für die Anwendung der Logik vor, während und nach dem Angriff über alle Angriffsvektoren hinweg wichtig sind. Sie dienen außerdem dazu, zu jedem Zeitpunkt, durchweg und in Echtzeit eine geeignete Reaktion zu gewährleisten. Diese Anforderungen werden nachfolgend erläutert.

Transparenz

SecOPS-Teams müssen genau wissen, „was bereits vorgefallen ist“ und „was aktuell passiert“, damit sie ihre Aufgaben effizient erfüllen können. Dies erfordert sowohl den Überblick über die gesamte Bandbreite von Angriffsvektoren als auch detaillierten Einblick in die einzelnen Vektoren. „Gesamtüberblick“ bedeutet die Fähigkeit, Daten von allen potenziellen Angriffsvektoren in der gesamten Netzwerkstruktur, aus E-Mails und Web-Gateways, Mobilgeräten, virtuellen Umgebungen und in der Cloud zu überblicken und zu erfassen, um Informationen zu Umgebungen und Bedrohungen zu sammeln.

Tiefe

Die Tiefe ermöglicht es, diese Informationen zu korrelieren, Informationen zum besseren Verständnis des Kontexts einzusetzen, fundiertere Entscheidungen zu treffen und Maßnahmen entweder manuell oder automatisch zu treffen. Die Technologie, die diesen umfassenden kontextbezogenen Überblick bietet, heißt FireSIGHT. Sie bildet die technologische Grundlage für das FireSIGHT Management Center.

Tabelle 2 Zuordnung von Bedrohungsfunktionen zu Kontrollen

Bedrohungsein- grenzung


Identitätsmana- gement

Anwendungsver- waltung

Protokollierung und Nachverfolgbar- keit

Funktionen Untersuchung und Analyse von Bedrohungen auf Datei-, Paket- und Datenflussebene


Benutzeridentitäts-, -zugriffs- und -statusüberprüfung, netzwerkbasierter Benutzerkontext

Anwendungs- transparenz und -kontrolle

Bedrohungsfo- rensik und Compliance

Für NIST relevante Kontrollen

Reaktion, Wartung, Medienschutz, Risikoanalyse, System- und Datenintegrität


Zugriffskontrolle System- und Datenintegrität, Zugriffskontrolle

Audit und Verantwortlichkeit

Die 20 wichtigsten Sicherheitskon- trollen für SAN

Kontinuierliche Schwachstellen- analyse und Problembehebung, Malware-Schutz, Datenschutz

Erfassung autorisierter und nicht autorisierter Geräte, Schutz von Systemgrenzen, kontrollierter, bedarfsbasierter Zugriff, sicheres Netzwerkengi- neering

Kontrollierter, bedarfsbasierter Zugriff, sichere Netzwerktechnik

Erfassung autorisierter und nicht autorisierter Software, sichere Netzwerktechnik

Pflege, Überwachung und Analyse von Audit-Protokollen

20


Abbildung 8 zeigt die Bandbreite, die eine Lösung benötigt, sowie ein Beispiel für eine „Analysenzusammenfassung“, die einen detaillierten Einblick in sämtliche Ereignisse über alle Angriffsvektoren hinweg ermöglicht. Diese Analysenzusammenfassung stellt umfassende Detailinformationen bereit, auf deren Basis das SecOPS-Team Elemente im Angriffsprozessverlauf minimieren kann.

Abbildung 8 In die Breite und in die Tiefe – Alle Ereignisse im Blick

Bedrohungsorientiert

Moderne Netzwerke reichen heute überall hin, wo sich Mitarbeiter aufhalten, wo Daten vorhanden sind und von wo aus auf Daten zugegriffen werden kann. Trotz aller Bemühungen ist es für die Verantwortlichen kein Leichtes, mit den sich ständig weiterentwickelnden Angriffsvektoren Schritt zu halten, und das wird von Angreifern ausgenutzt. Angreifer nutzen alle bestehenden Lücken im System. Richtlinien und Kontrollmechanismen werden benötigt, damit solche Angriffe möglichst wenig Chancen haben. Dennoch lassen sich manche Bedrohungen nicht verhindern. Die eingesetzten Technologien müssen daher auch in der Lage sein, Bedrohungen zu erkennen, zu verstehen und abzuwehren. „Bedrohungorientiert“ bedeutet hierbei, wie ein Angreifer zu denken, für Transparenz und Kontext zu sorgen, um Veränderungen in der Umgebung zu verstehen und anzupassen und daraus Schutzmechanismen gegen Bedrohungen zu entwickeln. Angesichts der modernen Malware und Zero-Day-Angriffe ist dies ein kontinuierlicher Prozess, bei dem laufend Analysen und Sicherheitsinformationen in Echtzeit aus lokalen Systemen und der Cloud bereitgestellt und zur Effizienzsteigerung von allen Produkten gemeinsam genutzt werden.

21


Threat Management-Technologien

Retrospective Security: Ein Blick über den Ereignishorizont hinaus

Retrospective Security ist eine einzigartige Funktion der Cisco Sicherheitslösungen und spielt eine zentrale Rolle im Kampf gegen moderne Bedrohungen und Malware. Retrospective Security nutzt eine kontinuierliche Funktion, die auf der Basis von Big Data Analytics im erweiterten Netzwerk nach Daten und Ereignissen zur permanenten Verfolgung und Analyse sammelt und nach Elementen, z. B. Dateien, sucht, die ursprünglich für sicher befunden wurden, aber aktuell als schädlich bekannt sind. Wenn eine Datei zunächst von den Erkennungssystemen nicht beanstandet, aber später als schädlich erkannt wird, kann diese Datei rückwirkend erkannt, der Umfang des Outbreaks ermittelt und eingegrenzt und die Malware schließlich automatisch entfernt werden. Bevor dieses System eingeführt und erfolgreich umgesetzt wurde, gab es keine Möglichkeit, einen Angriff über den Ereignishorizont hinweg zu verfolgen. Ein Beispiel dafür ist der „Point of no return“, an dem für harmlos befundene Dateien in das Netzwerk eindringen, sich dort versteckt einnisten und erst später aktiv werden.

Abbildung 9 zeigt ein Beispiel für Retrospective Security über den Ereignishorizont hinaus. Die Abbildung illustriert den Vergleich zwischen Point-in-Time-Erkennung und kontinuierlicher rückwirkender Analyse, wobei einige bekannte Anti-Malware-Techniken wie AV, IPS und Sandboxing zum Einsatz kommen, die zentrale Komponenten der meisten Threat Management-Systeme sind. Besonders bei modernen, „sandbox-bewussten“ Bedrohungen ist diese Funktion von großem Nutzen. Im oberen Bereich von Abbildung 9 sehen Sie die Schwächen einer typischen Point-in-Time-Erkennung ohne rückwirkende Funktion. Im unteren Bereich kommt zur Point-in-Time-Erkennung noch die kontinuierliche Analyse hinzu, um zu zeigen, dass die rückwirkende Funktion notwendig ist, um moderne Malware zu erkennen und sich gegen solche Angriffe zu verteidigen. Im unteren Abschnitt sehen Sie außerdem, warum Zieltransparenz so wichtig ist. Nur so kann man verstehen, wie das Threat Management-System den genauen „Umfang“ des möglichen Outbreaks über den Ereignishorizont hinaus erkennt und Maßnahmen genau anwenden kann, um weitere Outbreaks dynamisch zu verhindern.

22


Abbildung 9 Ereignishorizont: Vergleich von Point-in-Time-Erkennung mit kontinuierlicher

Analyse

Schlüsseltechnologie für Retrospective Security: Trajectory

Trajectory ist eine einzigartige Technologie von Cisco, die verhindert, dass die Sicherheitslösung Malware jenseits des Ereignishorizonts nicht weiter überwacht. Sie ist eine Schlüsselkomponente der ereignis- oder bedrohungszentrierten Sicherheitsmodelle und sollte in modernen Rechenzentren nicht fehlen. Neben der zusätzlichen Transparenz bietet Trajectory für das SecOPS-Team außerdem die Möglichkeit, Umfang und Zeitpunkt von Outbreaks zu ermitteln und Malware oder verdächtige Dateien im gesamten Netzwerk sowie auf System- oder Endpunktebene zu verfolgen. Trajectory ist eine Funktion, die für das gesamte Advanced Malware Protection-Lösungsportfolio verfügbar ist.

Trajectory erfüllt quasi die Funktion eines Netzwerkflugschreibers für Malware, der alles aufzeichnet, was diese Malware tut, wie und wohin sie sich ausbreitet. Malware von heute ist dynamisch und kann auf verschiedensten Wegen in Netzwerke oder Endpunkte eindringen. Auf dem betroffenen Ziel führt sie dann typischerweise böswillige und/oder scheinbar nicht schädliche Aktivitäten aus (z. B. Herunterladen weiterer Malware). Mithilfe von Big Data Analytics erstellt die Lösung eine grafische Karte dieser Dateiaktivitäten, in der alle Aktivitäten auf Netzwerk-, Endpunkt- und Systemebenen erfasst werden. So können Sicherheitsexperten den Angriffspunkt, die Ausbreitung und das Verhalten von Malware schnell analysieren. Dies ermöglicht ein ungekannt hohes Maß an Transparenz bezüglich Angriffsaktivitäten von Malware und schließt die Lücke zwischen Erkennung, Behebung und Kontrolle von Malware-Outbreaks. Dies ist ein Schlüsselfaktor, der bisher allein von Cisco Retrospective Security so umgesetzt wird.

3479

37

Point-in-Time-Erkennung

Antivirus

Sandboxing

Anfängliche Einstufung = Sauber Aktuelle Einstufung = Schädlich = Zu spät!!!

Analyse wird angehalten

Umfang des Schadensnicht erkennbar

Analyse zurückliegender Ereignisse

Transparenz und Kontrolle sind sehr wichtig

nicht zu 100 %

Rückwirkende (kontinuierliche) Erkennung

Anfängliche Einstufung = Sauber Aktuelle Einstufung = Schädlich = Gesperrt

Analyse wird fortgesetzt

Schlaftechniken Unbekannte ProtokollePolymorphe Verschlüsselung

23


Network File Trajectory und Device Trajectory

Für Sicherheitsexperten ist es schwierig, die weitreichenden Auswirkungen, den Kontext und die Ausbreitung von Malware im Netzwerk und auf Endpunkten zu erkennen. Es ist wichtig zu wissen, ob es sich bei erkannter Malware um einen Einzelfall handelt(e) oder ob mehrere Systeme betroffen sind/waren. File Trajectory bietet die Möglichkeit, Malware über das Netzwerk mithilfe vorhandener FirePOWER-Anwendungen oder FireAMP Connectors zu verfolgen. So erhält man detaillierte Angaben zu Angriffspunkt, Ausbreitung, verwendeten Protokollen und betroffenen Benutzern oder Endpunkten (siehe Abbildung 10 und Abbildung 11).

Network File Trajectory durchsucht das gesamte Unternehmensnetzwerk und liefert Antworten zu folgenden Fragen:

• Welche Systeme wurden infiziert?

• Wer wurde zuerst infiziert („Patient 0“) und wann?

• Wo war der Angriffspunkt?

• Wann fand der Angriff statt?

• Welche weiteren Probleme wurden hierdurch verursacht?

Abbildung 10 File Trajectory im Netzwerk

24


Abbildung 11 Zusammenfassung der dynamischen Dateianalyse

Durch die dateibasierte Struktur von File Trajectory und Device Trajectory kann Cisco Daten noch detaillierter erfassen und Malware- und Dateiaktivitäten auf Systemebene visualisieren. Das ist die Grundlage für wichtige Analysefunktionen, mit denen Security- und Incident Response-Teams Ursachenanalysen durchführen und die genaue Beziehung zwischen Malware auf betroffenen Systemen und möglichen weitergehenden Infektionen ermitteln können. Mit Device Trajectory kann das System durch unverzügliche Ursachenanalyse den üblichen Zyklus wiederholter erneuter Infektionen durch einmal eingeschleppte Malware unterbinden.

Device Trajectory analysiert die genaue Beziehung zwischen der Malware auf infizierten Systemen und einer weitergehenden Infektion. Die Lösung nutzt dabei hocheffiziente Such- und Filterfunktionen, die in allen Systemen, auch in Systemen mit FireAMP, nach verdächtigen Aktivitäten suchen. So können unsere Kunden schnell verdächtige und bösartige Aktivitäten auf einem System erkennen und umgehend auf allen Systemen nach ähnlichen Indikatoren suchen. Device Trajectory verfolgt Aktivitäten und Daten wie beispielsweise Parent-Child-Beziehungen: Welche Dateien oder Anwendungen wurden von welchen Dateien erstellt, und welche Dateien haben andere Dateien heruntergeladen (oder umgekehrt). Device Trajectory sucht außerdem nach Ursprungsprozessen, also Prozessen, durch die andere Prozesse ausgelöst oder ausgeführt wurden. Außerdem wird die Kommunikation überwacht, darunter IP-Adressen, Ports, Protokolle und URLs. (Siehe Abbildung 12).

Mithilfe der dynamischen Trajectory-Daten können auch mögliche Hinweise auf schädliches Verhalten schnell erkannt werden. Außerdem werden Verhaltensweisen aufgedeckt, die darauf hinweisen, dass schädliche Aktionen ausgeführt wurden, die wahrscheinlich eine Sicherheitsverletzung verursacht haben. Device Trajectory führt eine tiefgehende Analyse der einzelnen Geräte durch und hilft bei der Beantwortung folgender Fragen:

• Wie gelangte die Bedrohung in das System?

• Wie gravierend ist die Infektion auf einem bestimmten Gerät?

• Welche Kommunikation hat stattgefunden?

25


• Was weiß ich nicht?

• Wie sieht die Ereigniskette aus?

Abbildung 12 File Trajectory und Device Trajectory

Anhand der oben beschriebenen Angriffskette werden Sie im FireSIGHT Management Center intuitiv durch die einzelnen Programmfenster geleitet, um einen unberechtigten Zugriff oder Hinweise auf schädliche Aktivitäten zu verfolgen. Das Ablaufdiagramm in Abbildung 13 zeigt einen Beispielablauf zur Analyse potenzieller Bedrohungen. Im folgenden Abschnitt sehen Sie einige Screenshots für die einzelnen Schritte auf dem Weg zur Ursachenanalyse.

Hinweis In diesem Beispiel werden nur einige der tatsächlichen Möglichkeiten des FirePOWER-Managementsystems gezeigt.

Abbildung 13 Beispiel für einen Cyber Defender Analysis-Workflow

Im Context Explorer können Sie als Benutzer weitere und detailliertere Analysen aufrufen. (Siehe Abbildung 14).

3479

38

Informationen zu SicherheitsrisikenInformationen zu Sicherheitsrisiken

ContextExplorerContextExplorer

Indicators ofCompromiseIndicators ofCompromise DateiinformationenDateiinformationen Host-Profile

Malware-Ereignisattribute UrsachenanalyseUrsachenanalyse

26


Abbildung 14 Hauptfenster des Context Explorer

Im Zuge der weiteren Analyse gelangen Sie zu einem Fenster mit einer Auflistung von „Compromise by Hosts“ (Kompromittierung nach Hosts) und „Hosts by Indication“ (Hosts nach Indikatoren). Siehe Abbildung 15. Im Fenster „Indicators of Compromise“ gelangt der Benutzer schnell zu Hosts, die als kompromittiert erkannt wurden, wo im Fenster „Host Profile“ (Host-Profil) weitere Details angezeigt werden.

Abbildung 15 Indikatoren für kompromittierte Hosts

Abbildung 16 ermöglicht einen detaillierten Einblick in die Indications of Compromise nach „Traffic by Risk and Application“ (Verkehr nach Risiko und Anwendung), „Intrusion Events by Risk and Application“ (Angriffsversuche nach Risiko und Anwendung) und „Hosts by Risk and Application“ (Hosts nach Risiko und Anwendung).

27


Abbildung 16 Indications of Compromise nach Client-Anwendung

Abbildung 17 bietet einen detaillierten Überblick über die Angriffsversuche nach Auswirkung und Priorität, sodass der Benutzer die wichtigsten Ereignisse zuerst bearbeiten kann. Außerdem können Sie weitere Details zu identifizierter Malware aufrufen.

Abbildung 17 Detaillierter Überblick über Angriffsversuche

28


Weitere Details zu Angriffsversuchen finden Sie in den Fenstern „Verified Threats Default Workflow“ (Standard-Workflow für bestätigte Bedrohungen) (siehe Abbildung 18) und „Intrusion Event Specifics“ (Details zu Angriffsereignissen) (siehe Abbildung 19).

Abbildung 18 Bestätigte Bedrohungen

Im Zuge der weiteren Analyse gelangen Sie zu den „Malware Event Attributes“ (Malware-Ereignis-Attribute) mit dem Fenster „Event Specifics“ (Ereignisdetails) in Abbildung 19.

Abbildung 19 Ereignisdetails

Nachdem Sie die Angriffsdetails ermittelt haben, müssen im nächsten Schritt des Workflows die Zieldateien analysiert werden.

Im Fenster „File Information“ (Dateiinformationen) (siehe Abbildung 20) wird die Malware den beschädigten Dateien zugeordnet, die von den Network AMP- oder FireAMP-Clients ermittelt wurden. Jetzt sind Dateinamen, Hosts und Malware-Zuordnungen erkennbar. Bitte beachten Sie, dass diese Anzeige aus der Netzwerkperspektive erfolgt, da sehr wahrscheinlich mehr als ein Host von einmal erkannte Malware betroffen sein wird.

29


Abbildung 20 Malware- und Dateidetails

Wie oben gezeigt, ermöglicht Network File Trajectory einen Überblick über kompromittierte Geräte und Dateien im gesamten Netzwerk. Abbildung 21 zeigt das Network File Trajectory-Fenster mit Detaillierungsmöglichkeiten im Fenster „Host Profile“, der die Indication of Compromise dem betreffenden Host zuordnet.

Abbildung 21 Network Trajectory und Host Profile

30


Durch die Auswahl von „Malware Detected IoC“ (Von IoCs ermittelte Malware) erhalten Sie Details zu der von diesem Host erkannten Malware, die ein Eingreifen fordert (siehe Abbildung 22). Dieses Fenster enthält Kontextinformationen über das Malware-Ereignis, mit denen das Risiko der verdächtige(n) Datei(en) für das Unternehmen eingeschätzt werden kann, noch bevor die Datei für das Sandboxing an die Cisco Sourcefire Cloud gesendet wird. Sicherheitsinformations-Feeds nutzen die Cisco Sourcefire Cloud, VRT und andere Big Data-Quellen, um auf der Grundlage von Datenverkehrs-Quellen und -Zielen Richtlinien zu erstellen. In diesem Fenster wird auch die von der Cisco Sourcefire Cloud gelieferte URL-Reputation genutzt. Durch die Nutzung mehrerer Quellen von Bedrohungsereignissen steht der gesamte Kontext dieser Bedrohung zur Verfügung.

Abbildung 22 Kontextbasierte bestätigte Bedrohungen

Abbildung 23 zeigt die Details einer abschließenden Analyse als Ergebnis einer Reihe von Klassifizierungen/Bewertungen der verdächtigen Dateien. In dieser Phase des Workflows können Sie geeignete Maßnahmen gegen die Datei ergreifen.

31


Abbildung 23 Bedrohungsanalyse-Details

Auch hier ist der oben gezeigte Workflow ein anschauliches Beispiel dafür, wie ein Operator mithilfe des FireSIGHT Management Center den Analyseprozess durchläuft, um die nächsten Lösungsschritte festzulegen.

Threat Management-Funktionen für sämtliche AbläufeDas FirePOWER-System bietet vielfältige Technologien mit einer breiten Funktionspalette zur Behandlung von Sicherheitsrisiken. Beim Entwickeln einer Sicherheitsarchitektur mit Fokus auf das gesamte Spektrum vor, während und nach einem Angriff als Schlüsselkonzept wird jedoch deutlich, dass die Funktionen im gesamten Rechenzentrum benötigt werden. Die Lösung muss mehr leisten, als eine Point-in-Time-Lösung, die lediglich einen einzelnen Angriffsvektor berücksichtigt.

In Abbildung 24 sehen Sie ein Beispiel dafür, wie Malware versucht, über ein kompromittiertes Endgerät auf den Server des Rechenzentrums zuzugreifen.

32


Abbildung 24 Vor, während und nach einem Angriff

1. Die FireAMP-Komponente auf dem Client führt die Dateianalyse auf dem Client aus, um Malware zu ermitteln und zu entfernen. Die ISE analysiert anhand einer Whitelist von Anwendungen den Benutzer- und Gerätestatus. Benutzeraktivitäten werden an das FireSIGHT Management Center übermittelt. FireAMP meldet die Ergebnisse an das FireSIGHT Management Center.

2. Die Cisco Switching Fabric aktiviert die SGACLs und sendet NetFlow-Datensätze zur Datenverkehrsanalyse an das FireSIGHT Management Center und Lancope StealthWatch.

3. Nexus 7000 to ASA-/FirePOWER-Appliance Cluster Fabric-Verbindungen verhindern Daten-Blackholes und die Umgehung von Überprüfungen.

4. Malwarepakete werden zur verbesserten Durchsetzung der Zugriffskontrolllisten, Normalisierung des Datenverkehrs und Protokollprüfung dem ASA-Cluster hinzugefügt.

5. Malwarepakete werden zwecks Intrusion Prevention, AMP-Dateianalyse im Netzwerk, Anwendungserkennung und -kontrolle, File Trajectory und Network Trajectory und DLP für vertrauliche Daten werden in die FirePOWER-Appliance eingespielt.

6. Die Secure Enclave Architecture sorgt für sicheres Anwendungs-Tiering, Ost-West-Hypervisor-Layer-Sicherheit, Ost-West-Enclave-Sicherheit, automatisierte sichere Workload-Bereitstellung sowie Serviceverkettung. Der Einsatz von ASAv und der virtuellen FirePOWER-Appliance in der Secure Enclave Architecture verbessert den Schutz weiter.

Benutzer amStandort

Physischer Zugriff

Computing

Storage

KonvergentesNetzwerk-Rack

Rechenzentrumsserver/-Ressourcen

ASA 55853D8250Cluster

DefenseCenter

Mgmt

SXPSXP &SGACLs

DC-Core/AggCampusCore

Mobiler Benutzer

Statusüberprüfung für Geräte FireAMP für Dateianalyse Benutzerprotokol-lierung

SGACL-Durchsetzung NetFlow-Analyse

Richtlinienkonsolidierung Datenverkehrnormalisierung Asymmetrischer Traffic-Fluss Flussredundanz ASA Cluster

FireAMP auf Servern Sicheres Anwendungs-Tiering Port-Profil-SGT Ost-West-Schutz

SGACL-Durchsetzung TrustSec SXP-Daten-Blackhole-Schutz Betriebliche Effizienz

Benutzer-identität

Benutzer-identität

3479

41

1 2

2

3 4 5

5

6

634

1

Schutz vor Sicherheitsrisiken Netzwerk-AMP-Dateianalyse und -kontrolle Indications of Compromise Retrospektion Connection Intelligence File Trajectory Network Trajectory

33

Design-Überlegungen zu Threat Management mit NextGen IPS

Validierte KomponentenEinzelstandort-Clustering mit TrustSec war eine Grundlage für diese Validierung. Weitere Komponenten, die in dieser Lösung validiert werden, sind in Tabelle 3 aufgeführt.

Design-Überlegungen zu Threat Management mit NextGen IPSWie bereits zuvor erwähnt, ist es äußerst wichtig, bei der Entwicklung eines Systems als adäquate Reaktion auf Bedrohungen für Rechenzentren den bedrohungsrelevanten Funktionen höchste Priorität einzuräumen. Im nächsten Abschnitt erfahren Sie, wie Sie die FirePOWER NextGen IPS-Appliance in die Fabric integrieren können. Anschließend werden die durch die modernen Technologien FirePOWER-Appliance und Advanced Malware Protection (AMP) für Endpunkte verfügbaren Funktionen vorgestellt. Sie erfahren, wie Sie die Gesamtheit der Threat Management-Systemfunktionen nutzen, um eine äußerst effektive Strategie für den Schutz Ihres Rechenzentrums zu entwickeln.

FirePOWER-Appliance und Integration der Management-Plattform

Plattform-Management – FireSIGHT Management Center

Ein FireSIGHT Management Center bietet eine Managementzentrale und Ereignisdatenbank für die Bereitstellung der FirePOWER-Appliance. FireSIGHT Management Center aggregieren und korrelieren Daten zu Angriffen, Dateien, Malware, Erkennung, Verbindung und Performance. Diese Funktion ermöglicht Ihnen, die Informationen zu überwachen, die die FirePOWER-Appliances gegenseitig berichten, und die Gesamtaktivitäten des Netzwerks zu analysieren und zu kontrollieren.

Tabelle 3 Validierte Komponenten

Komponente Funktion Hardware VersionCisco Adaptive Security Appliance (ASA)

Firewall-Cluster für Rechenzentren

Cisco ASA 5585-SSP60

Cisco ASA-Softwareversion 9.2

FirePOWER-Appliance NextGen IPS-Plattform 3D8250 5.3

FireSIGHT Management Center-Appliance

NextGen IPS-Plattformmana- gement

DC3500 5.3

FireAMP Schutz gegen Malware für Endpunkte

K/A Version XX

Cisco Nexus 7000 Aggregations- und FlexPod-Access Switch

Cisco 7004 NX-OS Version 6.1(2)

Hinweis Cisco FireSIGHT Management Center umfasst Lizenzen für FireSIGHT, Protection, Malware sowie Anwendungs- und URL-Kontrolle, sodass diese Funktionen in der FirePOWER-Appliance aktiviert werden können.

34


Wichtigste Funktionen des FireSIGHT Management Center:

• Geräte, Lizenz- und Richtlinienmanagement

• Anzeige von Ereignis- und Kontextinformationen in Tabellen, Grafiken und Diagrammen

• Integritäts- und Leistungsüberwachung

• externe Benachrichtigungen und Warnmeldungen

• Korrelations-, Indications of Compromise- und Problembehebungsfunktionen zur Reaktion auf Bedrohungen in Echtzeit

• Berichtserstellung

• Funktion für hohe Verfügbarkeit (Redundanz) für Kontinuität der Abläufe

Die Verwaltung der physischen und virtuellen Appliances von FirePOWER mit FireSIGHT Management Center erfordert Netzwerkanbindung für einen richtigen Kommunikationsfluss. Abbildung 25 illustriert die Datenströme zwischen den physischen und virtuellen FirePOWER- Appliances und dem FireSIGHT Management Center.

Abbildung 25 FireSIGHT Management Center und FirePOWER-Appliance – Informationsfluss

Verwendung redundanter FireSIGHT Management Center

Zwei FireSIGHT Management Center können als hochverfügbares Paar betrieben werden, um den Betrieb sicherzustellen, falls ein FireSIGHT Management Center ausfällt. Richtlinien, Benutzerkonten und andere Ressourcen werden von beiden FireSIGHT Management Centern gemeinsam genutzt. Ereignisse werden automatisch an beide FireSIGHT Management Center gesendet.

FireSIGHT Management Center aktualisieren sich regelmäßig gegenseitig bei Änderungen der Konfiguration. Alle Änderungen an einem der beiden FireSIGHT Management Center wird im Normalfall innerhalb von 10 Minuten auch auf dem anderen FireSIGHT Management Center vorgenommen. Jedes FireSIGHT Management Center hat eine Synchronisierungsschleife von fünf Minuten, aber die Schleifen selbst können bis zu fünf Minuten abweichen, sodass Änderungen innerhalb von zwei Fünf-Minuten-Schleifen übermittelt werden. Während dieser 10 Minuten erscheinen Konfigurationen möglicherweise unterschiedlich auf den FireSIGHT Management Centern.

3479

42

GerätestatistikenCPU

FestplatteArbeitsspeicher

RichtlinienSicherheitsrisikoNetzwerkerkennungZugriffskontrolleSystemIntegritätFireSIGHT Management Center

Verwaltetes GerätErkennungsdatenHostAnwendungBenutzeraktivität

EreignisseSicherheitsrisikoErkennungGesundheitVerbindungsdaten

Verkehr

35


FireSIGHT Management Center in einem hochverfügbaren Paar verwenden gemeinsam die folgenden Informationen:

• Benutzerkontenattribute

• Authentifizierungskonfigurationen

• Benutzerdefinierte Benutzerrollen

• Authentifizierungsobjekte für Benutzerkonten und Benutzererkennung sowie Benutzer und Gruppen, die für Nutzerbedingungen in Zugriffskontrollregeln verfügbar sind

• Benutzerdefinierte Dashboards

• Benutzerdefinierte Workflows und Tabellen

• Geräteattribute (z. B. Hostname des Geräts), mit denen die vom Gerät generierten Ereignisse gespeichert werden, und die Gruppe, in der sich das Gerät befindet

• Angriffsrichtlinien und die zugehörigen Regelstatus

• Dateirichtlinien

• Zugriffskontrollrichtlinien und zugehörige Regeln

• Lokale Regeln

• Benutzerdefinierte Angriffsregelklassifizierungen

• Variablenwerte und benutzerdefinierte Variablen

• Network Discovery-Richtlinien

• Benutzerdefinierte Anwendungsprotokolldetektoren und von diesen erkannte Anwendungen

• Aktive benutzerdefinierte Fingerprints

• Hostattribute

• Network Discovery-Benutzerfeedback (mit Hinweisen und Wichtigkeit des Hosts), Löschung der Hosts, Anwendungen und Netzwerke aus der Netzwerkzuordnung, Deaktivierung oder Änderung von Schwachstellen

• Korrelationsrichtlinien und -regeln, Compliance Whitelists und Datenverkehrsprofile

• Änderungen an Abgleichs-Snapshots und Berichtseinstellungen

• Aktualisierungen von Angriffsregeln, Geolokations-Datenbanken (GeoDB) und Schwachstellendatenbanken (VDB)

Die FireSIGHT Management Center Appliances gibt es in drei Modellen. Die Leistungsbeschreibungen finden Sie in Tabelle 4.

Tabelle 4 Leistung des FireSIGHT Management Center

DC750 DC1500 DC3500

Maximal verwaltete Geräte

10 35 150

Max. IPS-Ereignisse 20 Mio. 30 Mio. 150 Mio.

Ereignisspeicher 100 GB 125 GB 400 GB

Max. Netzwerkübersicht (Hosts/Benutzer)

2.000/2.000 50.000/50.000 300.000/300.000

36


Hinweis FireSIGHT Management Center ist auch virtuell verfügbar und unterstützt die Verwaltung von bis zu 25 physischen und/oder virtuellen Anwendungen. Es ist mit VMware ESX 4.5/5.x oder höher kompatibel und erfordert mindestens vier CPU-Kerne und mindestens 4 GB Speicher.

Lizenz-Erwägungen

Das Thema der Lizenzierung von Produkten und Anwendungen wird in der Regel nicht in Cisco Validated Designs behandelt. Da jedoch die FirePOWER-Appliances eine umfassende Suite von Technologien und Funktionen unterstützen, werden in diesem Dokument der Vollständigkeit halber die Lizenzierungen kurz behandelt.

FireSIGHT

FireSIGHT Management Center enthält eine FireSIGHT-Lizenz für Host, Anwendungen und Benutzererkennung. Die FireSIGHT-Lizenz im FireSIGHT Management Center legt fest, wie viele einzelne Hosts und Benutzer mit dem FireSIGHT Management Center und seinen verwalteten Geräten überwacht werden können und für wie viele Benutzer die Benutzerkontrolle eingerichtet werden kann. (Siehe Tabelle 5.) Cisco empfiehlt, dass Lizenzen während der erstmaligen Einrichtung von FireSIGHT Management Center hinzugefügt werden. Andernfalls werden sämtliche Geräte, die bei der Ersteinrichtung registriert werden, als lizenziert zum FireSIGHT Management Center hinzugefügt. Nach Abschluss der Ersteinrichtung müssen Lizenzen auf jedem Gerät einzeln aktiviert werden.

Schutz

Mit einer Schutzlizenz können die verwalteten Geräte Identifizierung/Verhinderung von Sicherheitsrisiken, Dateikontrolle und Sicherheitsdatenfilterung durchführen.

Max. Durchsatzrate 2.000 fps 6.000 fps 10.000 fps

Funktionen für hohe Verfügbarkeit

Lights-Out-Management (LOM)

RAID 1, LOM, Hochverfügbarkeitspaar (HA)

RAID 5, LOM, HA, redundanter Wechselstrom

Tabelle 4 Leistung des FireSIGHT Management Center (Fortsetzung)

DC750 DC1500 DC3500

Tabelle 5 FireSIGHT-Grenzwerte nach FireSIGHT Management Center

Modell FireSIGHT Management Center FireSIGHT Host- und Benutzer-LimitVirtuelles FireSIGHT Management Center 50.000

DC500 1.000 (keine Benutzerkontrolle)

DC750 2.000

DC1000 20.000

DC1500 50.000

DC3000 100.000

DC3500 300.000

37


Kontrolle

Eine Kontrolllizenz erlaubt verwalteten Geräten die Ausführung der Benutzer- und Anwendungskontrolle. Außerdem ermöglicht sie Switching und Routing (einschließlich DHCP Relay), Network Address Translation (NAT) und Geräte- und Stack-Clustering. Voraussetzung für eine Kontrolllizenz ist eine vorhandene Schutzlizenz.

URL-Filterung

Mit einer URL-Filterungslizenz können verwaltete Geräte regelmäßig aktualisierte Cloud-basierte Kategorie- und Reputationsdaten nutzen, um auf Basis der von den überwachten Hosts angeforderten URLs festzulegen, welcher Datenverkehr das Netz passieren darf. Voraussetzung für eine URL-Filterungslizenz ist eine vorhandene Schutzlizenz.

Malware

Mit einer Malware-Lizenz erhalten verwaltete Geräte netzwerkbasierten erweiterten Schutz gegen Malware (AMP). So kann die Plattform Malware-Dateien ermitteln, erfassen und blockieren, die über das Netzwerk eingedrungen sind, und die Dateien für die dynamische Analyse übermitteln. Mit dieser Funktion können Benutzer File Trajectorys für im Netzwerk übertragene Dateien anzeigen. Voraussetzung für eine Malware-Lizenz ist eine vorhandene Schutzlizenz.

NextGen IPS Fabric Integration

Wenn die FirePOWER-Appliances inline bereitgestellt werden, können die Appliances verwendet werden, um den Datenverkehr anhand mehrerer Kriterien zu beeinflussen. Die FirePOWER-Appliances bieten Threat Management-Funktionen, die häufig die von herkömmlichen IPS-Geräten übertreffen. Diese Funktionen werden im weiteren Verlauf dieses Dokuments näher beschrieben.

ASA Cluster-Integration

Das Einzelstandort-Clustering mit TrustSec CVD bietet umfangreiche detaillierte Informationen zu Design- und Bereitstellungsüberlegungen für die Integration von ASA 5585-X im Cluster-Modus. Nach der Veröffentlichung dieses CVD wurde das Betriebssystem ASA inzwischen auf Version 9.2 aktualisiert. Diese Version bietet eine höhere Skalierbarkeit durch Unterstützung von bis zu 16 aktiven Verbindungen mit EtherChannel. Dadurch können Kunden bis zu 16 ASA 5585-X im Cluster für bis zu 640 Gbit/s der Bandbreite skalieren.

Bei der Bereitstellung des ASA-Clusters müssen alle ASAs exakt dieselben Konfigurationen haben, damit das ASA-System ordnungsgemäß funktioniert. Darüber hinaus sollten sie auf einheitlichem Wege bereitgestellt werden. Dies meint die Verwendung des gleichen Porttyps auf jedem Gerät für die Verbindung zur Fabric. Verwenden Sie die gleichen Ports für den Cluster Control Link zur mit Switching Fabric. Gleiches gilt für Daten-Links. Wenn der ASA Cluster ordnungsgemäß bereitgestellt wird, repliziert das Master-Gerät des Clusters seine Konfiguration auf den anderen Geräten im Cluster, damit der Cluster über eine konsistente Bereitstellung auf allen Geräten verfügt.

ASA Cluster-Performance

Durch Hinzufügen eines neuen ASA 5585-X zum Cluster kann eine Steigerung des Gesamtsystemdurchsatzes um etwa 70 Prozent der Gesamtverarbeitungsleistung für dieses Gerät erreicht werden. Der Durchsatz eines ASA 5585-X-SSP60 beträgt 40 Gbit/s für optimierten Datenverkehr, Jumbo-Frames oder UDP und etwa 20 Gbit/s für IMIX-/EMIX-Datenverkehr. Die maximale Anzahl an Verbindungen und Verbindungen pro Sekunde hat einen Skalierungsfaktor von 60 Prozent bzw. 50 Prozent. (Siehe Tabelle 6.)

38


ASA-Cluster-Integrität

Das Hauptgerät überwacht alle Geräte im Cluster indem es Keep-Alive-Nachrichten über den Cluster-Link sendet. Wenn die ASA-Schnittstellen im Spanned EtherChannel-Modus arbeiten, überwacht das Gerät die cLACP-Nachrichten und meldet den Link-Status an das Hauptgerät. Bei aktivierter Funktionsüberwachung werden ausgefallene Einheiten automatisch aus dem Cluster entfernt. Wenn das Master-Gerät ausfällt, übernimmt ein anderes Gerät des Clusters mit der höchsten Priorität die Master-Rolle.

ASA an normalen Cisco IPS Traffic-Fluss

Wie in diesem Dokument erläutert baut diese Lösung auf der Einzelstandort-TrustSec Architektur auf. Daher ist es äußerst wichtig, dass die Integration von FirePOWER-Appliances in das ASA 5585-X 16-Knoten-Cluster eine konsistente Architektur aufweist. In diesem Designhandbuch wird in Kurzform erläutert, wie der Traffic-Fluss des IPS-Moduls in ASA 5585-X den Kontext und den Hintergrund des Architekturansatzes liefert.

ASA 5585-X ist ein Zwei-Slot-Chassis mit dem ASA 5585-X-SSP60-Modul im ersten Steckplatz des Chassis. Das Designhandbuch für das Einzelstandort-Clustering mit TrustSec erläutert, wie das IPS-Modul (5585-SSP-IPS60) im zweiten Steckplatz integriert wird. Mit dem IPS-Modul im zweiten Steckplatz verläuft der Traffic-Fluss ähnlich dem „IPS auf einem Stick“-Ansatz. Die auf dem ASA konfigurierten Datenverkehrsrichtlinien identifizieren den Datenverkehr, der das IPS-Modul für die Deep Packet Inspection passieren muss (siehe Abbildung 26). Obwohl der Datenverkehr innerhalb des ASA-Chassis verbleibt, verlässt der Datenverkehr das ASA-Modul, passiert das IPS 5585-SSP-IPS60-Modul und fließt wieder zurück. Im folgenden Abschnitt wird beschrieben, wie dieses Grundmodell angepasst wird, um die FirePOWER-Appliance in die Rechenzentrums-Fabric zu integrieren.

Tabelle 6 ASA Cluster-Performance

Funktion PerformanceASA 5585-X Firewall-Durchsatz – Multiprotocol 20 Gbit/s

ASA 5585-X 16-Knoten-Cluster (IMIX/EMIX) 224 Gbit/s

TCP-Verbindungen pro Sekunde (1 Chassis) 350.000 Verbindungen pro Sekunde

ASA 5585-X 16-Knoten-Cluster TCP-Verbindungen pro Sekunde

2,8 Mio. Verbindungen pro Sekunde

Gleichzeitige (max.) TCP-Verbindungen (1 Chassis) Max. 10 Mio.

ASA 5585-X Knoten-Cluster Max- Verbindungen Max. 96 Mio.

39


Abbildung 26 ASA zu IPS 5585-SSP-IPS60 – Fluss

Threat Management mit NextGen IPS-Design

In diesem Abschnitt werden einige Architekturoptionen behandelt, mit denen Bestandskunden mit Nexus- und ASA-Rechenzentren die Vorteile der erweiterten Threat Management-Funktionen von Cisco FirePOWER nutzen können. Ziel jedes Designs ist es, den hohen Standard der Sicherheitssystemintegration für das Netzwerk aufrecht zu erhalten, Risiken, Paketverlust und Ausfallzeiten zu minimieren und Kapazitäten sowie Funktionen des bestehenden hochverfügbaren Rechenzentrums zu maximieren. Damit Kunden ihre Investitionen bei der Aktualisierung von Architekturen zur Anpassung an das Secure Data Center für das Enterprise-Portfolio optimal schützen können, wird spezielle Designunterstützung mit Blick auf die drei ursprünglichen Designoptionen angeboten. Die verfügbaren Optionen ermöglichen verschiedene Wege der Implementierung, z. B. inline oder passiv, physisch und virtuell, Kapazitäts- und Datenverkehrsmanagement sowie Erweiterbarkeit der Sicherheitslösung selbst oder der unterstützten Funktionen. Alle Optionen erfüllen die hohen und obligatorischen Anforderungen für Rechenzentrumsnetzwerke, die Kunden von Cisco erwarten. Dies sind im einzelnen folgende Anforderungen:

• Hochverfügbarkeit

• Keine Ausfallzeiten mehr

• Ausfallsicherer Datenfluss

• Hardware- und Link-Redundanz

• Link-Vielfalt und deterministische Abwicklung des Datenflusses

• Asymmetrischer Paketfluss erwartet und korrekt gehandhabt

• Datenverkehrsanomalien oder Datenverkehrs-Blackholes werden nicht toleriert

• Flexible Skalierung

• Geringe Latenz

• Keine Standard-Abzugswerte für den Verlust von Datenpaketen durch Services

• Verwaltbarkeit/Transparenz/Orchestrierung

• Sicherheit und Erfüllung gesetzlicher Auflagen

Die Optionen für Threat Management mit NextGen IPS werden nachfolgend ausführlich behandelt und beinhalten:

• Option 1: FirePOWER im Inline-Design (ASA Cluster-Kontext-Paarung)

• Option 2: FirePOWER in passivem Design

• Option 3: Virtual FirePOWER- und Virtual ASA-Design

40


Auf den folgenden Seiten wird jede Option detailliert behandelt. Außerdem zeigt ein Bedrohungs-Flussdiagramm, wie der bedrohungszentrierte Ansatz vor, während und nach einem Angriff angewendet wird.

Option 1: FirePOWER in einem Inline-Cluster mit ASA

Die ASA-Cluster-Kontextpaarung ermöglicht den besten Skalierungsdurchsatz für eine Inline FirePOWER NextGen IPS-Bereitstellung mit ASA, wenn die Bereitstellung aufgrund der Skalierung mithilfe des physischen Formfaktors vorgenommen werden muss. Inline-Bereitstellungen haben den zusätzlichen Vorteil, dass gefährlicher Datenverkehr ausgesondert werden kann, bevor er sein Ziel erreicht, und zwar an der optimalen Stelle in der Netzwerkstruktur: direkt an der Quelle. Dank der ASA-Cluster-Kontextpaarung können alle Sicherheitsfunktionen durch das Secure Data Center-Design auf ASA-Cluster-Ebene genutzt werden.

• Anwendungstransparenz und -kontrolle mit OpenAppID™

• URL-Kategorisierung und zugehörige Indications of Compromise

• FireSIGHT™-Endpunktetransparenz und -kontext und zugehörige Indications of Compromise

• NextGen IPS mit den Managementfunktionen für komplexe Bedrohungen von FirePOWER™

• Advanced Malware Protection (AMP)

• Benutzeridentitäts-Managementoptionen

• Cloud-basierte Big Data-Analysen sowie Nutzung des Managed Threat Defense Service von Cisco

• File Trajectory und Network Trajectory

• Point-in-Time- und retrospektive (kontinuierliche) Analyse

• Schwachstellenmanagement

• Patch-Management

• Forensik

• Fail-Open-/Closed-Funktion für das NextGen IPS-System

• Alle erweiterten Netzwerkfunktionen wie DRP und BGP, die standardmäßig Teil einer ASA-Bereitstellung sind

• Direkte Integration mit der virtuellen Komponente Secure Enclave Architecture (siehe „Option 3: Virtuelles Bedrohungsmanagement in Secure Enclave“ in diesem Dokument)

Die ASA-Cluster-Kontextpaarung bedeutet die geringsten Änderungen für bestehende physische Rechenzentrumsnetzwerke eines Inline-Systems, wodurch die Bereitstellung ohne Ausfallzeiten für das Rechenzentrum durchgeführt werden kann. Außerdem ermöglicht die Funktion von ASA-Clustern zur Verwaltung asymmetrischer Datenströme eine Reduzierung der Paketverluste auf Null für alle Ausfallszenarien einer ASA-Einheit oder einer FirePOWER-Appliance.

Das Design selbst wird durch die Verknüpfung der FirePOWER-Appliance mit ASA 5585-X über duale 10-Gbit/s-Ethernet-Doppelschnittstellen auf allen Chassis und die Nutzung von VLAN Tag Rewrite komplettiert. Der Datenfluss zwischen den Geräten bleibt konsistent mit den typischen Datenströmen, wenn IPS in ASA 5585-X als Modul eingebettet ist, außer in dem Fall, dass der Strom einen zusätzlichen Kontext hat. Der zweite, oder nach Süden ausgehende, ASA-Kontext soll die kontinuierliche Unterstützung des asymmetrischen Datenverkehrs im Rechenzentrum gewährleisten. Es greift auch direkt in die Secure Enclave Architecture für sichere Multi-Tenant-Virtualisierung ein. ASA liefert mit jedem ASA-Chassis standardmäßig zwei Kontexte. Daher ist keine zusätzliche Lizenz für diese Bereitstellung erforderlich, sofern bereits eine Multi-Kontext-Bereitstellung vorhanden ist und die Kontext-Lizenzen bereits erworben wurden.

41


Abbildung 27 und Abbildung 28 erläutern die mindestens erforderlichen Änderungen an der Infrastruktur des Rechenzentrumsnetzwerks für die ASA-Cluster-Kontextpaarung.

Abbildung 27 Netzwerkdiagramm vor der FirePOWER-Implementierung

In diesem Beispiel wird der ASA-Cluster im transparenten Modus mit cLACP zwischen VLANs 2001 und 3001 implementiert. Beachten Sie die VLAN-Flow-Masken auf den bestehenden Trunk-Links zwischen ASA und Nexus 7000 – 2001 und 3001, und sehen Sie, wie sie im Diagramm „Nach“ in Abbildung 28 dargestellt werden.

VM VM

VM VM

Trunk VLAN 2001 3001Trunk VLAN 2001 3001

ASA FW-Cluster

3479

43

BGP/OSPFCore

Trunk VLAN 3001

SVI VLAN 2001SVI VLAN 200110.1.1.0/2410.1.1.1/24

VLAN2001

VLAN3001

VLAN2001

VLAN3001

PoD

42


Abbildung 28 Netzwerkdesign „nach“ der Implementierung von FirePOWER

In Abbildung 28 illustriert das Diagramm „Nach“ die geringfügigen Änderungen am ASA-Cluster-Master. ASA verwendet einen zweiten (Süd-) Kontext, um die Abwicklung des asymmetrischen Datenverkehrs zu und von den FirePOWER-Appliances in beide Richtungen zu ermöglichen. VLAN 2001 bleibt hierbei im ursprünglichen Kontext (es sei denn, dass bereits mehrere Kontexte verwendet wurden). In diesem Fall wird es in den Nordkontext integriert (Hinweis: die Bezeichnung „Nord“ ist willkürlich gewählt). VLAN 3001 wird ein Mitglied des neuen Südkontexts Süd (die Bezeichnung „Süd“ ist wieder willkürlich willkürlich gewählt). Ein neues VLAN wird jedem dieser Kontexte 2101 zu Nord und 3101 zu Süd hinzugefügt. Es sind keine Gateway- oder VLAN-Änderungen an Hosts und keine Trunkflow-Maskenänderungen (Einschränkung) erforderlich. Die Lösung nutzt die bereits vorhandenen Links im ASA-Cluster, um Nexus 7000-Switches zu verbinden, ohne dass Änderungen durchgeführt werden müssen.

Die beiden neuen VLANs werden verwendet, um die FirePOWER-Appliance in den Fluss einzubinden und effizient zwischen den Nord- und Süd-ASA-Kontexten einzufügen. So soll sichergestellt werden, dass das Management des asymmetrischen Datenverkehrs auf beiden Seiten der FirePOWER-Appliance erfolgt, indem die Fähigkeiten des ASA-Clusters genutzt werden, CCLs asymmetrisch wieder zusammenzufügen. Die FirePOWER-Appliance wird zu einem neuen physischen 10-Gbit/s-Port auf jedem ASA hinzugefügt und jedem ASA-Kontext zugewiesen. So entsteht ein Netzwerk-Backplane-Fluss, der die optimierte Flow-Semantik der ASA-Cluster nutzt.

VM VM

VM VM

Trunk VLAN 2001 3001

Südkontext 3001, 3101

Nordkontext 2001, 2101

Südkontext 3001, 3101

Nordkontext 2001, 2101

Trunk VLAN 2001 3001

ASA FW-Cluster

3479

44

BGP/OSPFCore

DC Edge

Trunk VLAN 3001

SVI VLAN 2001SVI VLAN 200110.1.1.0/2410.1.1.1/24

VLAN2001

VLAN3001

VLAN2001

VLAN3001

PoD

43


VLAN Tag-Switching der FirePOWER-Appliance

Die FirePOWER-Appliances können für eine Layer 2-Bereitstellung konfiguriert werden, um Paket-Switching zwischen zwei oder mehr Netzwerksegmenten zu ermöglichen. In einer Bereitstellung mit ASA-Cluster-Kontextpaarung konfigurieren Sie Switched Interfaces und virtuelle Switches auf verwalteten Geräten, um sie als Standalone Broadcast Domains zu nutzen. Ein virtueller Switch verwendet die MAC-Adresse eines Hosts, um festzustellen, wohin Pakete gesendet werden sollen. In diesem Fall ist ASA der referenzierte Host. Diese Layer 2-Bereitstellung der FirePOWER-Appliance wird verwendet, um die VLAN-Tags zwischen den beiden 10-Gbit/s-Ethernet-Schnittstellen der FirePOWER-Appliance an die dedizierte 10-Gbit/s-Schnittstellen auf der lokalen ASA zu schalten. (Siehe Abbildung 29).

Abbildung 29 ASA 5585-X zu 3D8250-Fluss

Abbildung 30 zeigt die Kommunikation durch den ASA 5585-X-Cluster mit der integrierten FirePOWER-Appliance.

Paketfluss

1. Paket kommt an SVI VLAN 2001 an – ARP-Anfrage an Server 10.11.1.88 – ASA antwortet mit Außen-Schnittstellen-MAC-Adresse

2. Durchläuft ASA-Nordkontext 1 zu FirePOWER VLAN 2101 mittels physischer Schnittstelle mit Ziel ASA-Südkontexts 2 – Pakete, die an VLAN 2001 auf ASA ankommen, werden auf ASA per Richtlinie verarbeitet – (Clustering-Inhaber/Director) und so weiter. Symmetrischer Fluss wird für diese Sitzung beibehalten.

3. Von FirePOWER-Appliance untersuchtes Paket wird an (outside/inside) ASA-Kontext 2 Schnittstelle weitergeleitet – schaltet VLAN TAG zu 3101

4. ASA-Kontext 2 verarbeitet Richtlinie, vergibt neues Tag für Paket auf Trunk zu VL3001 – zurück an Nexus 7000 mit VLAN 3001

5. Nexus 7000 leitet Paket über VLAN 3001 an den Server weiter

6. Paket kommt auf Server an 10.11.1.88

3479

39

ASA 5585-X

ExternIntern

Firewall Security

Firewall Security

Südkontext

10 GE 10 GE

Nordkontext

VLAN 2101VLAN 3101

VLAN 2001VLAN 3001

Flussinspektion

VPN-Entschlüsselung

Sourcefire3D 8250-Sensor

44


Abbildung 30 Paketfluss

Abwicklung asymmetrischen Datenverkehrs für sichere Datenströme

In einem gut strukturierten hochverfügbaren Rechenzentrum wird asymmetrischer Datenverkehr nicht nur erwartet, sondern ist in vielen Fällen sogar erwünscht, damit die hohen Investitionen in die Netzwerk-Switching-Komponenten eines Rechenzentrums und feinstens abgestimmte Nutzung von skalierbaren (Up-)Links den größtmöglichen Effekt erzielen. Da Sitzungen immer bidirektional sind, besteht immer die Möglichkeit, dass selbst Datenverkehr mit derselben Quelle und demselben Ziel (basierend auf symmetrischen LACP-Hashes) auf dem Rückweg über einen anderen physischen Pfad geleitet wird. Für die Sicherheit ist Genauigkeit entscheidend. Allerdings kann ein System wie NextGen IPS weder umfassende Transparenz noch angemessene Reaktionsfähigkeit für Pakete bieten, die nicht erkannt werden. Diese Form der Genauigkeit berücksichtigt keine fehlenden Pakete, die einen anderen Weg genommen haben. Mit der ASA-Cluster-Kontextpaarung kann die FirePOWER-Appliance effektiv zwischen zwei logischen ASA-Clustern eingefügt werden. Dies ermöglicht die inhärente Abwicklung asymmetrischer Datenflüsse aus dem Cluster, um sicherzustellen, dass jedes Paket in einer Sitzung stets von der richtigen FirePOWER-Appliance gesehen wird. Das gilt unabhängig von der Flussrichtung zwischen Quelle und Ziel im Rahmen derselben Anwendungssitzung. Wenn die FirePOWER-Appliance alle Pakete während einer Sitzung ohne Ausnahme erkennt, wird die Genauigkeit erzielt, die für umfassende Sicherheit notwendig ist. Abbildung 31 zeigt ein Beispiel für asymmetrischen Datenverkehr zwischen Quelle und Ziel und wie das ASA-Cluster-Kontext-Paar die Stickiness jeder Sitzung mittels ASA CCL sicherstellt.

VLAN 3001 10.1.1.88

6VM VM

VM VM

Trunk VLAN 2001-3001 Trunk VLAN 2001-3001

3479

46

DC Edge

BGP/OSPFCore

ASA 1 ASA N

Kontext 1, Nord

Trunk VLAN 3001

Kontext 2, Süd

SVI VLAN 2001 10.1.1.1/24SVI VLAN 2001 10.1.1.1/24

VLAN2001

VLAN3101

VLAN2101

VLAN3001

VLAN2001

VLAN3101

VLAN2101

VLAN3001

PoD

1

3

4

5

2

45


Abbildung 31 Abwicklung des asymmetrischen Datenverkehrs im ASA-Cluster-Kontext-Paar

Paketfluss

1. Das Paket des Quellhosts wird vom lokalen Switch über einen Pfad zur Richtlinienverarbeitung an ASA A1 gesendet. Ist die Richtlinie zulässig und lautet die anfängliche Einstufung durch FirePOWER „Sauber“, wird das Paket weitergeleitet.

2. Sauberes Paket erreicht Ziel-Host auf dem erwarteten Pfad.

3. Ziel-Host sendet Rückpaket.

4. Lokaler Switch wählt einen zufälligen Pfad, über den das Paket auf ASA A2 durchgeleitet werden kann.

5. ASA A2 leitet das Paket mithilfe der CCL-Semantik zur asymmetrischen Reassembly über CCL weiter. Das Paket erreicht das korrekte ASA A1 zur weiteren Verarbeitung.

6. Paket wird über das Kontext-Paar mittels korrektem Pfad gesendet, sodass die FirePOWER-Appliance alle Pakete der Sitzung erkennen und die Sicherheit des Datenverkehrs genau bewerten kann.

7. Sauberes Paket erreicht die Quelle wie vorgesehen.

Designoption – ASA-Cluster-Paar ohne zusätzliche VLANs

Wenn die Secure Enclave Architecture für Multi-Tenant-Virtualisierung nicht verwendet wird oder nicht geplant ist, ist es möglich, die ASA-Cluster-Paare bereitzustellen, indem nur die beiden vorherigen VLANS verwendet werden – in diesem Fall 2001 und 3001. In dieser Designoption (siehe Darstellung in Abbildung 32) sind die Schnittstellen, die über die ASA mit der FirePOWER-Appliance verbunden sind, eigene physische Schnittstellen, die ohne zugewiesene VLAN-Tags dem Nord- und Südkontext zugeordnet sind. Für diese Designoption muss die FirePOWER-Appliance kein VLAN Tag-Switching ausführen. Die EEM-Konfiguration bleibt für diese Designoption weiterhin gültig.

A1A1

2

A2

61

73 4

5A2

3479

47

ASA 5585-X

Intern Extern

QuelleZiel

Südkontext Nordkontext

Südkontext Nordkontext

10 GE 10 GE

VLAN 2001VLAN 3001

VLAN 2101VLAN 3101

Flussinspektion

Flussinspektion

ASA 5585-X

Intern Extern

CCL10 GE 10 GE



VLAN 2001VLAN 3001

VLAN 2101VLAN 3101

FirewallSecurity

FirewallSecurity


FirewallSecurity

FirewallSecurity


46


Abbildung 32 ASA-Cluster-Kontext-Paare ohne zusätzliche VLANs

Abbildung 33 zeigt den Kommunikationsfluss durch das ASA 5585-X-Cluster mit der FirePOWER-Appliance bei Bereitstellung ohne zusätzliche VLAN-Tags.

Hinweis Diese Option wurde in den Bereitstellungsleitfäden nicht validiert.

Paketfluss

1. Paket kommt an SVI VLAN 2001 an – ARP-Anfrage an Server 10.1.1.88 – ASA antwortet mit Außen-Schnittstellen-MAC-Adresse

2. Durchläuft ASA-Nordkontext 1 zu SF mittels physischer Schnittstelle mit Ziel ASA-Südkontexts 2 – Pakete, die an VLAN 2001 auf ASA ankommen, werden auf ASA per Richtlinie verarbeitet – (Clustering-Inhaber/Director) und so weiter. Symmetrischer Fluss wird für diese Sitzung beibehalten.

3. Von FirePOWER-Appliance untersuchtes Paket wird an (outside/inside) ASA-Kontext-2-Schnittstelle weitergeleitet .

4. ASA-Kontext 2 verarbeitet Richtlinie, vergibt neuen Tag für Paket auf Trunk zu VL3001 – zurück an Nexus 7000 mit VLAN 3001.

5. Nexus 7000 leitet Paket über VLAN 3001 an den Server weiter.

6. Paket erreicht Server 10.1.1.8834

7948

ASA 5585-X

ExternInternSüdkontext Nordkontext

10 GE 10 GE

VLAN 2001VLAN 3001

Flussinspektion Sourcefire3D 8250-Sensor

FirewallSecurity

FirewallSecurity


47


Abbildung 33 Paketfluss für ASA-Cluster-Kontext-Paare ohne zusätzliche VLANs

IPS Fail Open

Es ist sehr wichtig, sicherzustellen, dass der Datenverkehr im Falle eines Geräteausfalls nicht blockiert wird. Der folgende Modultyp wurde wegen der Fail-Open-Fähigkeit des Schnittstellenmoduls ausgewählt, damit der Verkehr nicht blockiert wird. Die Bandbreite der Schnittstelle wurde wegen der Port-Konfigurationen des ASA 5585-X sowie der Port-Konfigurationen des angeschlossenen Nexus 7000 ausgewählt:

• Dual-Port 10GBASE-MM-Glasfaserschnittstellen mit konfigurierbarer Bypassfunktion

Zusätzliche Schnittstellen mit konfigurierbarem Bypass sind verfügbar, garantieren aber möglicherweise nicht den folgenden für das Design erforderlichen Durchsatz:

• Quad-Port 1000BASE-T-Kupferschnittstelle mit konfigurierbarer Bypassfunktion

• Quad-Port 1000BASE-SX-Glasfaserschnittstelle mit konfigurierbarer Bypassfunktion

• Dual-Port 40GBASE-SR4-Glasfaserschnittstelle mit konfigurierbarer Bypassfunktion (nur 2-U-Geräte)

Beachten Sie, dass für die Plattformen der Serie 8200 Quad 10-Gbit/s-Module verfügbar sind. Diese unterstützen jedoch nicht die Bypassfunktion.

VLAN 3001 10.1.1.88

6VM VM

VM VM

SVI VLAN 2001 3001 SVI VLAN 2001 3001

3479

49

DC Edge

BGP/OSPFCore

ASA 1 ASA N

Kontext 1, Nord

Trunk VLAN 3001

Kontext 2, Süd

SVI VLAN 2001 10.1.1.1/24SVI VLAN 2001 10.1.1.1/24

VLAN2001

VLAN3001

VLAN2001

VLAN3001

PoD

1

3

4

5

2

48


Optionale Bereitstellung des Embedded Event Manager

Falls die FirePOWER-Appliance oder ein Link zwischen ASA und der FirePOWER-Appliance ausfällt, kommt es möglicherweise zu einer Verzögerung von neun Sekunden beim ASA-Systemstatuscheck, bevor die ASA sich und die FirePOWER-Appliance aus dem Cluster entfernt. Diese Verzögerung entsteht durch das EtherChannel-Wiederherstellungsverfahren der ASA. ASA VLAN 2101 (Nord) und ASA VLAN 3101 (Süd) werden zwar jeweils über eine separate, dedizierte Schnittstelle mit der FirePOWER-Appliance verbunden, jedoch müssen ASA-Cluster-Datenebenenschnittstellen bei der Konfiguration mit EtherChannel aufgesetzt werden. Dieser eine EtherChannel ist unumgänglich. Beim EtherChannel-Wiederherstellungsverfahren der ASA werden Timer verwendet, um eine ausgefallene Verbindung wieder herzustellen und den erneuten Anschluss an das Paket zu ermöglichen. Der Timer-Standardwert (Mindestwert) für die Wiederherstellung der EtherChannel-Verbindung auf der ASA beträgt neun Sekunden. Künftige Versionen des ASA-Codes sollen die Möglichkeit bieten, diesen Timer zu ändern. Die Verzögerung lässt sich jedoch durch den Einsatz von EEM zur Überwachung der Schnittstelle komplett vermeiden. Es wird empfohlen, mithilfe eines isolierten VLAN, in dem ein EEM-Skript Ausfälle überwacht und die Verbindung zum einzelnen EtherChannel sofort wiederherstellt, eine sekundäre Verbindung mit beliebiger Geschwindigkeit auf der ASA und der FirePOWER-Appliance zu Nexus 7000 herzustellen.

EEM bietet die Möglichkeit, Ereignisse zu überwachen und informative oder korrigierende Maßnahmen einzuleiten, wenn bei der Überwachung Ereignisse auftreten oder ein bestimmter Grenzwert erreicht wird. Bei einer EEM-Richtlinie handelt es sich um eine Komponente, die ein Ereignis sowie die auszuführenden Aktionen definiert, wenn dieses Ereignis eintritt (siehe Abbildung 34). Es gibt zwei Arten von EEM-Richtlinien: Applets und Skripte. Ein Applet ist eine einfache Richtlinienart. Diese wird innerhalb der CLI-Konfiguration definiert. Ein Skript ist eine Richtlinie, die in Tool Command Language (TCL) geschrieben wird.

Abbildung 34 EEM-Richtlinie

Hinweis Obwohl die ASA über eine Lite-Version von EEM verfügt, wird für diese Lösung die Vollversion von EEM auf Nexus 7000 verwendet.

In Abbildung 35 ist die FirePOWER-Appliance zwischen dem Nord- und Südkontext für die Enclave 1 mit zusätzlicher Verbindung zu Nexus 7000 in einem dedizierten EEM-VLAN dargestellt. Nach der Verbindungsherstellung wird durch die Konfiguration von Nexus 7000 mithilfe eines EEM-Skripts (siehe Abbildung) die Verzögerung von neun Sekunden bei einem Ausfall der FirePOWER-Appliance beseitigt.

49


Abbildung 35 EEM-Bereitstellung

Der Datenfluss mit integriertem Schutz vor Bedrohungen – vor, während, nach dem Angriff

Abbildung 36 ist ein Beispiel dafür, wie Malware versucht, über ein kompromittiertes Benutzergerät durch die ASA-Cluster-Kontextpaarung auf einen Rechenzentrums-Server zuzugreifen. In der Abbildung sehen Sie die Vorgänge vor, während und nach dem Angriff im Rahmen der Bereitstellungsoption der ASA-Cluster-Kontextpaarung. Bei dem Prozess wird angenommen, dass eine Verbindung nördlich des DC Edge versucht, auf eine Datei oder Anwendung auf dem Zielserver im Access Layer des Rechenzentrums zuzugreifen.

Paketfluss

1. Serveranfrage für 10.1.1.88 geht auf Nexus 7000 ein. Es folgen die standardmäßigen Abläufe von Layer 3 und 2, über die die Anfrage an die ASA im Nordkontext zur Richtlinienverarbeitung auf VLAN 2001 weitergeleitet wird.

2. Die ASA führt die Richtlinienkontrollen durch und reduziert die Angriffsfläche, indem sie die zulässige Quell-/Zieladresse, das Protokoll, die Ports, die SGT-Informationen usw. überprüft. Sobald die Anfrage bestätigt wird, werden die Pakete für VLAN 2101 neu getaggt und mithilfe einer MAC-Adresse von NextGen IPS an das Süd-Clusterpaar weitergeleitet.

3. Pakete in der Anfrage werden über NextGen IPS verarbeitet. Das System übernimmt die Inline-Sicherheitskontrollen, das Scannen und das Management. Dieser Schritt umfasst alle Komponenten des Thread Management-Systems, u. a. Anwendungstransparenz, Geolokations-Richtlinien, Advanced Malware Protection, IoC, Gerätekontext, Trajectory usw. Wenn die anfängliche Einstufung „Gutartig“ lautet, werden die Pakete für VLAN 3101 neu getaggt und an die MAC-Adresse der ASA im Süden weitergeleitet.

4. Wenn die Pakete an der ASA im Süden eingetroffen sind, können zusätzliche Richtlinienprüfungen vorgenommen werden.

5. Nach Bestätigung der Richtlinien werden die Pakete von der ASA im Süden für VLAN 3001 neu getaggt und für die Übertragung an den Zielserver 10.1.1.88 an Nexus 7000 weitergeleitet.

3479

51

ASA 5585-X (ASA 1)Enclave 1

Nordkontext

ASA 5585-X (ASA1)Enclave 1

Südkontext

VLAN 2001

VLAN 2101

VLAN 3101

VLAN 3001

Die gleiche physische ASA für jede ASA im Cluster wiederholt

(Applet-Skript pro ASA im Cluster)

event manage applet Track_SF1_ASA1_Down

event manager applet Track_SF2_ASA2_Down

Physische 10-GE-Schnittstellen auf ASA und 3D8250

EEM VLAN

Nexus 7000

event track 1 state downaction 1 syslog msg EEM applet Track_SF1_ASA1_Down shutting down ASA1 CCLaction 2 cli conf termaction 3 cli interface port-channel 40action 4 cli shut

event track 2 state downaction 1 syslog msg EEM applet Track_SF2_ASA2_Down shutting down po41action 2 cli conf termaction 3 cli interface port-channel 41action 4 cli shut

50


6. Sobald das Paket im Access Layer ankommt, sorgt die Secure Enclave Architecture für sicheres Anwendungs-Tiering, Ost-West-Hypervisor-Layer-Sicherheit, Ost-West-Enclavessicherheit über die ASAv und die Virtual FirePOWER-Appliance und automatisierte sichere Workload-Bereitstellung und Serviceverkettung. AMP an Endpunkten kann an dieser Stelle auch eine Rolle spielen. Mit Nexus 1000v können Sie auch die SGT-Zuweisung für Port-Profile vornehmen. Weitere Informationen zu diesem Schritt finden Sie im Designhandbuch für Secure Enclave Architecture.

Abbildung 36 Bedrohungsfluss bei ASA-Cluster-Kontextpaarung – vor, während und nach dem Angriff

Weitere Informationen zu den Phasen vor, während und nach einem Angriff erhalten Sie später ingdiesem Dokument im Abschnitt „Threat Management-Systemfunktionen“.

Option 2: FirePOWER-Appliances im passiven Design

Option 2 bietet mit dem FirePOWER-System in einem passiven Designmodell den höchsten Skalierungsdurchsatz mit minimalen Auswirkungen auf die Latenz, wenn die Bereitstellung aufgrund der Skalierungsanforderungen mithilfe des physischen Formfaktors erfolgen muss. Außerdem kann gewünscht sein, den Traffic-Fluss auf der Virtualisierungsebene zu überwachen, was mit dieser Designoption ebenfalls möglich ist.

VM VM

VM VM

Trunk VLAN 2001 3001 Trunk VLAN 2001 3001

3479

52

DC Edge

BGP/OSPFCore

ASA 1 ASA N

Kontext 1, Nord

Trunk VLAN 3001

Kontext 2, Süd

SVI VLAN 2001 10.11.1.1/24SVI VLAN 2001 10.11.1.1/24

VLAN2001

VLAN3101

VLAN2101

VLAN3001

VLAN 3001 10.1.1.88

VLAN2001

VLAN3101

VLAN2101

VLAN3001

PoD

1

2

3

4

5

6

- FireAMP auf Servern- Sicheres Anwendungs-Tiering- Portprofil-SGT-Aufgaben- Ost-West-Schutz- Serverrichtlinienkonsolidierung- Next-Gen Intrusion Prevention

Vorher

- Next-Gen Intrusion Prevention- Netzwerk-AMP-Dateianalyse- Erkennen und Steuern von Anwendungen- Indications of Compromise- Retrospektion- Verbindungsinformationen- Network File Trajectory- Device Trajectory

Fire-Kontrollrichtlinien

Whitelists

Gerätestatusüberprüfung

Gerätekonformitätsprüfungen

Anwendungskontrolle

Während

Anwendungserkennung

SSL-Erkennung

Erkennung und Kontrolle vertraulicher Daten

Network File Trajectory

Nachher

Network File Trajectory

SSL-Erkennung

Erkennung und Kontrolle vertraulicher Daten

Client File Trajectory

- Sicherheitsrichtlinienkonsolidierung- Reduzierte Angriffsfläche- Datenverkehrsnormalisierung- Asymmetrische Datenverkehrseindämmung- Sicherheitsablaufredundanz- ASA-Cluster-Skalierung

Host-Profile

Durchsetzungsbenachrichtigung für Benutzer

51


Bei passiven Bereitstellungen besteht nicht die Möglichkeit, gefährlichen Datenverkehr zu unterbinden, bevor er das anvisierte Ziel erreicht. Sie bieten aber einen hohen Grad an Zuverlässigkeit, wenn Bedrohungstransparenz das oberste Anliegen ist. Zudem ermöglichen sie Ihnen, manuelle Maßnahmen gegen Outbreaks zu ergreifen. Das passive Design bietet dennoch hervorragende Sicherheitsfunktionen, die über das Secure Data Center-Design auf ASA-Cluster-Basis nach Bedarf genutzt werden können:




• Anti-Virus und Anti-Malware

• NextGen IPS mit den erweiterten Threat Management-Funktionen von FirePOWER™


• Benutzeridentitätsmanagement-Optionen

• Cloud-basierte Big Data-Analysen und Nutzung des Managed Threat Defense Service von Cisco





• Forensik

In Abbildung 37 wird ein redundantes Paar von FirePOWER-Appliances in einer Aktiv/Standby-Konfiguration implementiert. Eine SPAN-Überwachungssitzung wird auf allen Core-Switches von Nexus 7000 erstellt. Nexus 7000 ermöglicht bis zu 48 Überwachungssitzungen, wobei wie bei den meisten anderen Cisco Switches mehrere Quellschnittstellen/VLANs und mehrere Zielschnittstellen/VLANs sowie die Überwachung von Traffic-Flüssen (Eingang, Ausgang) oder von Traffic-Fluss in beide Richtungen möglich ist. Die in Abbildung 37 dargestellte Option bietet Transparenz für den gesamten Datenverkehr, der durch den Kern zu bzw. von einem Aggregation Layer oder Edge fließt. Optional können virtuelle FirePOWER-Appliances im Überwachungsmodus konfiguriert werden, um Transparenz für den Ost-West-Datenverkehr vom Access Layer zu ermöglichen. Das FireSIGHT Management Center überwacht alle diese Systeme und bietet eine zentrale und zuverlässige Schnittstelle für alle gesammelten Daten. Im folgenden Beispiel werden verschiedene Szenarien erläutert, die zu Ausfällen führen, darunter: Nexus 7000-Chassis, Uplinks zwischen Core und Aggregation, Ausfall der FirePOWER-Appliance oder Ausfall einer beliebigen zugehörigen Schnittstelle. Eine einfache Konfiguration ist in Abbildung 37 dargestellt. Weitere Informationen zur Konfiguration von Nexus 7000 SPAN finden Sie unter folgender URL: http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/113038-span-nexus-config.html.

In Abbildung 37 sind die Nord-Süd-Datenflüsse der physischen Ebene und die Ost-West-Datenflüsse der Virtualisierungsebene dargestellt, die überwacht werden können.

52

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/113038-span-nexus-config.html

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/113038-span-nexus-config.html


Abbildung 37 Passive NextGen IPS-Gesamtlösung

Wie bei allen passiven IPS-Bereitstellungen steht die Größe im Vordergrund. Wenn die Verbindungen überlastet sind, wird eventuell nicht der gesamte Datenverkehr über eine einzelne 10-Gbit/s-Verbindung zwischen Nexus 7000 und den FirePOWER-Appliances übertragen. Es gibt mehrere Möglichkeiten, volle Transparenz zu gewährleisten – z. B. durch zusätzliche Verbindungen zu den FirePOWER-Appliances zur Anpassung an die Gesamtgröße, wenn die Implementierung klein und leicht zu managen ist, oder durch den Einsatz von 40-Gbit/s-Schnittstellen auf den FirePOWER-Appliances. Abbildung 37 ist potenziell für Datenverkehr mit 80 Gbit/s ausgelegt – vorausgesetzt, dass alle Core-Verbindungen 10 Gbit/s bieten. Skalieren Sie die Überwachungslösung je nach Bedarf.

Das in diesem Beispiel verwendete FirePOWER HA ist ein einfaches Aktiv/Standby-System. Beide FirePOWER-Appliances erhalten eine Kopie des Datenverkehrs in diesem Design, aber nur das aktive System erstellt Ereignisdatensätze in FireSIGHT Management Center.

VM VM

VM VM

StandbyAktiv

VM

VM

VM

VM

3479

53

DC Edge

BGP/OSPF Core

DC-Core VDC (geroutet)

L2

L3

L2

L3

Visualisierung/Compute Access Layer

PoD

Schnittstelle e3/9 – 12Switch-Port Switch-Port-Überwachung!Überwachungssitzung 16 Quellschnittstelle e3/3 – 6 beide (Agg-Layer-Links)Zielschnittstelle e3/9 – 12 (zu FirePOWER-Appliances)

SPAN-Überwachungsschnittstellen

L3-Link

L2-Link

Redundante FirePOWER-Appliances

-8250/8350-8390

DefenseCenter

PoD

Virtuelle FirePOWER-Überwachung so konfiguriert, dass erforderlicher Ost-West-Datenverkehr eingesehen wird mit SPAN von vSwitch oder Nexus 1000v

Defense Center hat Einblick in ALLE von allen Sensoren erfasste Abläufe.

DC-Aggregation-VDC(s) (Switch)

53


Option 3 – Virtual FirePOWER- und Virtual ASA-Design

Der Schwerpunkt von Option 1, bei der eine ASA-Cluster-Kontextpaarung verwendet wurde, lag auf einer NextGen IPS-Inline-Bereitstellung unter Verwendung eines ASA-Clusters, da die Bereitstellung aufgrund der Skalierungsanforderungen mithilfe des physischen Formfaktors durchgeführt wurde. Bei Option 3, d. h. der Threat Management in Secure Enclave, werden weiter die Option der ASA-Cluster-Kontextpaarung, die EEM-Bereitstellung usw. genutzt. Zusätzlich werden in diesem Design jedoch auch die virtuellen Formfaktoren der ASAv und der Virtual FirePOWER-Appliance in den Enclaves genutzt.

Hinweis Eine vollständige Beschreibung der Secure Enclave Architecture ist unter Cisco Validated Design: Secure Data Center for the Enterprise: Secure Enclave Architecture zu finden.

Dieser Abschnitt enthält eine Übersicht der Option, da sie die ASA-Cluster-Kontextpaarung nutzt und die ASAv und die Virtual FirePOWER-Appliance genau denselben integrierten Schutz vor Bedrohungen bieten können. Außerdem werden bei der Virtual FirePOWER-Appliance alle Bedrohungsmanagement-Workflows über die zentrale Plattform FireSIGHT Management Center verwaltet. Wie die Option mit ASA-Cluster-Kontextpaarung enthält die Virtual FirePOWER- und Virtual ASA-Designoption eine Reihe integrierter Thread Management-Funktionen:




• Anti-Virus und Anti-Malware

• NextGen IPS mit den erweiterten Threat Management-Funktionen von FirePOWER™


• Benutzeridentitätsmanagement-Optionen

• Cloud-basierte Big Data-Analysen und Nutzung des Managed Threat Defense Service von Cisco





• Forensik

• Fail-Open-/Closed-Funktion für das NextGen IPS-System

• Alle erweiterten Netzwerkfunktionen, die standardmäßig Teil einer ASA-Bereitstellung sind, wie DRP und BGP,

• Direkte Integration in die virtuelle Komponente der Secure Enclave Architecture

Zudem kann diese Designoption mit verschiedenen Virtualisierungsplattformen integriert werden:

• VXLAN

• Serviceverkettung

• vMotion

• Sicherheitsgruppen-Tag-Zuordnung in Port-Profilen

In Abbildung 38 ist ein Beispiel für virtuelles Thread Management in Secure Enclave Architecture dargestellt. Es gibt für jede Enclave, von denen einige geroutet und andere transparent sind, VLAN-Paare, wobei der Schwerpunkt auf der Virtualisierungskomponente liegt.

54


Abbildung 38 ASA-Cluster-Kontextpaarung in Secure Enclave Architecture

Leistung der FirePOWER-Appliance – Überlegungen zum Design

Tabelle 7 stellt die Grundlage für die angegebene Leistung der FirePOWER-Appliance dar. Obwohl ein einzelner 3D8250-Durchsatz mit 10 Gbit/s angegeben ist, liegt der maximale Durchsatz durch Integration des Geräts in das ASA-Cluster im Bereich zwischen 10 Gbit/s und 160 Gbit/s. So können unsere Kunden das System an das Unternehmenswachstum anpassen.

3479

54

Von Core und Clients

Enclave 1sichtbar

VLAN 2001

VLAN 2101

VLAN 3101

VLAN 3001

Enclave 2sichtbar

VLAN 2002

VLAN 2102

VLAN 3102

VLAN 3002

Enclave 3Routed

cLACP

Nordkontext

Südkontext

FirePOWER

VLAN 2003 VLAN 200310.11.3.192

VLAN 300310.11.3.254

VLAN 210310.11.103.194/30

VLAN 310310.11.103.193/30

VLAN 2103

VLAN 3103

VLAN 3003

VLAN 2001 10.11.255.254/24VLAN 2001 10.11.2.254/24VLAN 2001 10.11.3.254/24

OSPF AREA 2000 NSSA

ASA-Cluster-Datenebene EtherChannel

Zu Enclave-ServernVLAN 3001 VLAN 3002 VLAN 3003

Tabelle 7 Leistung der FirePOWER-Appliance

Funktion PerformanceIPS-Durchsatz 10 Gbit/s

IPS-Durchsatz in ASA 5585-X-Cluster mit 16 Knoten 160 Gbit/s

Nur Firewall (kein IPS) 20 Gbit/s

TCP-Verbindungen pro Sekunde 180.000

TCP-Verbindung pro Sekunde in ASA 5585-X-Cluster mit 16 Knoten 2.800.000

55


Implementierung mit niedriger Latenz

Auch wenn die bereits erläuterte passive Bereitstellung die Option mit der niedrigsten Latenz ist, lassen sich FirePOWER-Appliances mit noch geringerer Latenz konfigurieren. Ein ausgewogenes Verhältnis zwischen notwendiger Sicherheit und akzeptabler Latenz kann mithilfe eines Grenzwertverfahrens für Regellatenz erzielt werden. Bei dem Grenzwertverfahren wird die verstrichene Zeit gemessen, die jede Regel benötigt, um ein einzelnes Paket zu verarbeiten. Wird der Grenzwert für die Verarbeitungszeit von einer Regel nacheinander so oft überschritten, wie konfiguriert wurde, wird die entsprechende Regel zusammen mit der Gruppe zugehöriger Regeln für einen bestimmten Zeitraum ausgesetzt und nach Ablauf der Aussetzung wieder aktiviert.

Bei dem Grenzwertverfahren für Regellatenz wird die verstrichene Zeit, nicht nur die reine Verarbeitungszeit, gemessen, um möglichst präzise wiederzugeben, wie viel Zeit tatsächlich zur Verarbeitung eines Pakets durch eine Regel benötigt wird. Das Latenz-Grenzwertverfahren ist jedoch eine softwarebasierte Latenzimplementierung ohne präzise Zeitmessung.

Wenn Sie das Latenz-Grenzwertverfahren für ein Paket aktivieren, wird ein Timer für jedes Paket gestartet, sobald die Decoderverarbeitung beginnt. Die Zeitmessung wird fortgesetzt, bis die gesamte Verarbeitung des Pakets abgeschlossen ist oder bis bei der Verarbeitung an einem Zeitmesspunkt ein Grenzwert überschritten wird.

Wie in Abbildung 39 gezeigt, wird die Paketlatenzzeit an den folgenden Messpunkten überprüft:

• Nach Abschluss der Verarbeitung des Decoders und Präprozessors und vor Beginn der Regelverarbeitung

• Nach der Verarbeitung durch jede einzelne Regel Wenn die Verarbeitungszeit an einem der Messpunkte den Grenzwert überschreitet, wird die Paketprüfung unterbrochen.

Abbildung 39 Paketlatenz

Das Latenz-Grenzwertverfahren für Pakete kann die Systemleistung in passiven und Inline-Bereitstellungen verbessern und die Latenz in Inline-Bereitstellungen reduzieren, indem die Prüfung von Paketen gestoppt wird, deren Verarbeitung übermäßig lange dauert. Diese Leistungsvorteile können in den folgenden Szenarien auftreten:

Gleichzeitige TCP-Verbindungen 12.000.000

Gleichzeitige TCP-Verbindungen in ASA 5585-X-Cluster mit 16 Knoten 96.000.000

Tabelle 7 Leistung der FirePOWER-Appliance (Fortsetzung)

Regel 1 Regel 2 Regel n

3479

55

Ereignisda-tenbank

Präprozessoren

Regel-Engine

Verwaltetes Gerät

ÜberprüfungStart Überprüfung Überprüfung Überprüfung Überprüfung

Paket-Decoder

56


• Bei passiven und Inline-Bereitstellungen wird für die sequenzielle Prüfung eines Pakets durch mehrere Regeln übermäßig viel Zeit benötigt.

• Bei Inline-Bereitstellungen wird die Paketverarbeitung durch eine schlechte Netzwerkleistung über einen bestimmten Zeitraum verlangsamt, z. B. wenn ein Benutzer eine sehr große Datei herunterlädt.

Anforderungen an Kommunikations-Ports

Für bestimmte Funktionen der FirePOWER-Appliances ist eine Internetverbindung erforderlich. Diese werden standardmäßig so konfiguriert, dass sie automatisch eine direkte Verbindung zum Internet herstellen.

Außerdem müssen für die bidirektionale Kommunikation zwischen den FirePOWER-Appliances bestimmte Ports geöffnet bleiben. Diese bidirektionale Kommunikation verläuft über einen SSL-verschlüsselten Kommunikationskanal unter Verwendung von Port 8305/TCP. Im Allgemeinen bleiben funktionsspezifische Ports geschlossen, bis sie aktiviert werden bzw. die zugehörige Funktion konfiguriert wird.

In den FirePOWER-Appliances sind Änderungen an den Kommunikations-Ports möglich. Hierbei sollten Sie jedoch mit Vorsicht vorgehen, da die Änderungen negative Auswirkungen auf die Bereitstellung haben können. Wird z. B. der Port 25/TCP (SMTP) (Ausgang) auf einem verwalteten Gerät geschlossen, kann das Gerät keine E-Mail-Benachrichtigungen für einzelne Angriffsversuche mehr versenden.

Auch kann der Zugriff auf die Web-Schnittstelle eines verwalteten physischen Geräts durch Schließen von Port 443/TCP (HTTPS) deaktiviert werden. Dadurch wird jedoch auch verhindert, dass das Gerät verdächtige Malware-Dateien zur dynamischen Analyse an die Cloud sendet.

Benutzerdefinierte Ports können für die LDAP- und RADIUS-Authentifizierung konfiguriert werden, wenn eine Verbindung zwischen dem System und dem Authentifizierungsserver eingerichtet ist. Der Management-Port (8305/TCP) kann geändert werden. Cisco empfiehlt jedoch ausdrücklich, die Standardeinstellungen beizubehalten. Wenn der Management-Port geändert wird, muss die Veränderung für alle FirePOWER-Appliances im Netzwerk vorgenommen werden, die miteinander kommunizieren müssen. Über Port 32137/TCP können aktualisierte FireSIGHT Management Center mit der Sourcefire-Cloud kommunizieren. Cisco empfiehlt jedoch, Port 443 als Kommunikations-Port zu verwenden.

Weitere Informationen finden Sie unter „Standardkommunikations-Ports für Sourcefire 3D-System – Funktions- und Betriebstabelle“ im Benutzerhandbuch zum Sourcefire 3D-System.

Management-Netzwerk

Um das FireSIGHT Management Center zu schützen, sollte die Appliance in einem geschützten Management-Netzwerk installiert werden. Das FireSIGHT Management Center ist so konfiguriert, dass nur die notwendigen Dienste und Ports verfügbar sind. Dennoch müssen Sie sicherstellen, dass Angriffe nicht zu diesem (oder einem verwalteten Gerät) von außerhalb der Firewall durchdringen können. Wenn sich das FireSIGHT Management Center und die überwachten Geräte im selben Netzwerk befinden, können die Managementschnittstellen auf den Geräten mit demselben geschützten Management-Netzwerk wie das FireSIGHT Management Center verbunden werden. Sie müssen Vorkehrungen treffen, um sicherzustellen, dass die Kommunikation zwischen FirePOWER-Appliances nicht unterbrochen, blockiert oder manipuliert werden kann, z. B. durch einen Distributed DDoS-Angriff (Denial of Service) oder einen Man-in-the-Middle-Angriff.

57


SNMP

Simple Network Management Protocol (SNMP) Polling kann mithilfe einer Systemrichtlinie für eine Appliance aktiviert werden. Für die SNMP-Funktion wird die Version 1, 2 und 3 des SNMP-Protokolls unterstützt. Durch Aktivierung der SNMP-Funktion per Systemrichtlinie kommt es nicht dazu, dass die Appliance SNMP-Traps sendet. Die Informationen in den MIBs werden nur für das Polling über das Netzwerkmanagementsystem zur Verfügung gestellt. Der SNMP-Zugriff muss für jeden Computer hinzugefügt werden, der die Appliance abfragt. Die SNMP-MIB enthält Daten, die verwendet werden können, um FirePOWER-Appliances anzugreifen. Cisco empfiehlt, die Zugriffsliste für den SNMP-Zugriff auf die Hosts zu begrenzen, die für das Polling der MIB verwendet werden. Darüber hinaus empfiehlt Sourcefire die Verwendung von SNMPv3 und sicheren Kennwörtern für den Netzwerkmanagement-Zugriff.

Cisco Sourcefire-Cloud-Kommunikation

Die FirePOWER-Appliance verbindet sich mit der Cisco Sourcefire-Cloud, um folgende Daten abzurufen:

• Falls das Unternehmen über ein FireAMP-Abonnement verfügt, kann das System endpunktbasierte Malware-Ereignisse empfangen.

• Dateirichtlinien, denen Zugriffskontrollregeln zugewiesen sind, ermöglichen verwalteten Geräten, Dateien zu erkennen, die im Netzwerkverkehr übertragen werden.

• Das FireSIGHT Management Center verwendet Daten der Cisco Sourcefire-Cloud, um zu ermitteln, ob es sich bei Dateien möglicherweise um Malware handelt.

• Wenn die URL-Filterung aktiviert ist, kann das FireSIGHT Management Center Kategorie- und Reputationsdaten für eine Vielzahl häufig besuchter URLs abrufen und nach nicht kategorisierte URLs suchen.

Automatische Updates

Mithilfe automatischer Updates kann sich das System in regelmäßigen Abständen mit der Cisco Sourcefire-Cloud verbinden, um die URL-Daten in den lokalen Datensätzen der FirePOWER-Appliance zu aktualisieren. In der Regel aktualisiert die Cloud ihre Daten einmal pro Tag. Wenn automatische Updates aktiviert sind, sucht das FireSIGHT Management Center automatisch alle 30 Minuten nach Updates. So ist gewährleistet, dass die Daten im System stets auf dem aktuellen Stand sind. Die täglichen Updates haben in der Regel nur eine geringe Größe. Wenn seit dem letzten update jedoch mehr als fünf Tage vergangen sind, kann es je nach Bandbreite bis zu 20 Minuten dauern, neue Daten für die URL-Filterung herunterzuladen. Die anschließende Installation der Updates kann bis zu 30 Minuten dauern.

Hinweis Cisco empfiehlt, automatische Updates zu aktivieren bzw. regelmäßige Updates mithilfe des integrierten Zeitplaners zu konfigurieren, um die aktuellsten URL-Daten abzurufen.

Freigabe von URI-Informationen

Optional können FireSIGHT Management Center Informationen über die im Netzwerkverkehr erkannten Dateien an die Cisco Sourcefire-Cloud senden. Zu diesen Informationen gehören URI-Informationen zu erkannten Dateien und ihre SHA-256-Hash-Werte. Die Freigabe und Weiterleitung dieser Informationen muss aktiviert werden. Dadurch unterstützen Sie Cisco in dem Bemühen, künftige Malware zu identifizieren und zu verfolgen.

58


Internetzugriff und hohe Verfügbarkeit

Das System verwendet die Ports 80/HTTP und 443/HTTPS, um sich mit der Cisco Sourcefire-Cloud zu verbinden, und unterstützt die Verwendung von Proxyservern. Auch wenn alle URL-Filterungskonfigurationen und -informationen zwischen den FireSIGHT Management Centern in einer hochverfügbaren Bereitstellung synchronisiert werden, lädt nur das primäre FireSIGHT Management Center die URL-Filterungsdaten herunter. Wenn das primäre FireSIGHT Management Center ausfällt, sorgen Sie bitte dafür, dass das sekundäre FireSIGHT Management Center direkten Zugriff auf das Internet hat, und aktivieren Sie das sekundäre FireSIGHT Management Center über die Web-Schnittstelle.

FireSIGHT Management Center in einem hochverfügbaren Paar nutzen Cloud-Verbindungen oder Malware-Einstufungen nicht gemeinsam. Um einen unterbrechungsfreien Betrieb und identische Malware-Einstufungen für gefundene Dateien in beiden FireSIGHT Management Centern zu gewährleisten, müssen das primäre und das sekundäre FireSIGHT Management Center Zugriff auf die Cloud haben.

Threat Management-Systemfunktionen – Überlegungen zum DesignSobald die FirePOWER-Appliance richtig in das Fabric integriert ist, ist der nächste Schwerpunkt die Aktivierung der Funktionen und darauf, wie mit deren Hilfe über das gesamte Angriffskontinuum hinweg auf Bedrohungen reagiert werden kann. Die folgenden Abschnitte enthalten Designhilfestellungen für die Funktionen, wobei jede Funktion den entsprechenden Phasen im Angriffskontinuum zugeordnet ist. Einige Funktionen beziehen sich, wie in der Zuordnung dargestellt, auf mehrere Phasen.

Bedrohungseingrenzung und Problembehebung

Sicherheitsinformationslisten und -Feeds - Angriffskontinuum-Übersicht: vor und während eines Angriffs

Die Sicherheitsinformationsfunktion ermöglicht anhand einer Richtlinie für die Zugriffskontrolle, dass bestimmter Datenverkehr auf Basis einer Quell- oder Ziel-IP-Adresse durch das Netzwerk fließen kann. Dies ist besonders hilfreich, um spezifische IP-Adressen auf Blacklists zu setzen, bevor der Datenverkehr durch die Zugriffskontrollregeln analysiert wird. Ebenso können IP-Adressen auf eine Whitelist gesetzt werden, um das System dazu zu zwingen, deren Verbindungen über die Zugriffskontrolle zu verwalten.

Eine globale Whitelist und eine globale Blacklist sind standardmäßig in jeder Zugriffskontrollrichtlinie enthalten. Diese gelten für sämtliche Bereiche. Zusätzlich kann für jede Zugriffskontrollrichtlinie eine separate Whitelist und Blacklist mithilfe von Netzwerkobjekten und -gruppen, Sicherheitsinformationslisten und -Feeds erstellt werden, die auf bestimmte Sicherheitsbereiche beschränkt werden können.

Ein Sicherheitsinformations-Feed ist eine dynamische Auswahl von IP-Adressen, die das FireSIGHT Management Center in benutzerseitig konfigurierbaren Abständen von einem HTTP- oder HTTPS-Server herunterlädt. Da Feeds regelmäßig aktualisiert werden, verwendet das FirePOWER-System stets aktuelle Daten, um den Netzwerkverkehr zu filtern. Cisco stellt für die Erstellung von Blacklists den Sicherheitsinformations-Feed bereit, der IP-Adressen enthält, die gemäß Sourcefire VRT eine schlechte Reputation haben.

59


Netzwerkbasierte Advanced Malware Protection – Angriffskontinuum-Übersicht: vor und während eines Angriffs

Netzwerkbasierte Advanced Malware Protection (AMP) ermöglicht dem System, den Netzwerkverkehr in verschiedenen Dateitypen auf Malware zu prüfen. Appliances können gefundene Dateien zur weiteren Analyse entweder auf der Festplatte oder in einem Malware-Storage-Paket speichern. Unabhängig davon, ob eine gefundene Datei gespeichert wird, kann diese für eine einfache bekannte Dispositionssuche mithilfe des SHA-256-Hash-Wertes der Datei an die Cisco Sourcefire-Cloud gesendet werden. Dateien können auch zur dynamischen Analyse eingesandt werden, um die Bedrohungswerte zu ermitteln. Dieser Punkt wird später in diesem Abschnitt behandelt. Mithilfe dieser Kontextinformationen lässt sich das System so konfigurieren, dass bestimmte Dateien blockiert bzw. zugelassen werden. Der Malware-Schutz wird beim Einrichten der Zugriffskontrolle insgesamt konfiguriert. Die Dateirichtlinien, denen die Zugriffskontrollregeln zugewiesen sind, überprüfen, ob der Netzwerkverkehr den Regelkriterien entspricht. Abbildung 40 zeigt den Kommunikationsfluss zwischen Cisco Sourcefire-Cloud, FireSIGHT Management Center, Netzwerk-AMP und Endpunkten.

Abbildung 40 Malware-Datenfluss

FireAMP – Angriffskontinuum-Übersicht: vor und während dem Angriff

Auch wenn der Endpunkteschutz nicht Bestandteil des Designs der Rechenzentrums-Architektur ist, wird das Thema dennoch behandelt, da diese Geräte auf die Ressourcen des Rechenzentrums zugreifen. Aus diesem Grund ist es wichtig, diese Geräte in die Gesamtbetrachtung einzubeziehen.

FireAMP ist die intelligente Lösung der Enterprise-Klasse von Cisco zur Analyse von und zum Schutz vor Malware, um komplexere Malware-Angriffe, Advanced Persistent Threats und zielgerichtete Angriffe zu erkennen, zu analysieren und zu blockieren. Wenn das Unternehmen über ein FireAMP-Abonnement verfügt, installieren die einzelnen Benutzer FireAMP Connectors auf ihren Rechnern und mobilen Geräten (den Endpunkten). Diese einfachen Agenten tauschen Daten mit der Cisco Sourcefire-Cloud aus, die wiederum mit dem FireSIGHT Management Center verbunden ist. Sobald das FireSIGHT Management Center für die Verbindungsherstellung zur Cloud konfiguriert ist, werden über die Web-Schnittstelle des FireSIGHT Management Center die endpunktbasierten Malware-Ereignisse angezeigt, die durch Scannen, Erkennen und Quarantänevorgänge auf den Endpunkten generiert werden. Das FireSIGHT Management Center verwendet ebenfalls FireAMP-Daten, um Indications of Compromise auf Hosts zu generieren und zu verfolgen und Network File Trajectorys anzuzeigen.

Malware-Cloud-Suche

Benutzer auf überwachtem

Netzwerk

3479

56

Netzwerk-verkehr

DefenseCenter

FireAMP-Agentbenutzer

Security Analyst

Malwarein-formationen

Dateiinformationen

Sourcefire-Cloud

Dateiinfor-mationen

Datei- undMalwareereignisse

VerwalteteGeräte

60


Nutzen Sie das FireAMP-Portal (http://amp.sourcefire.com/), um eine FireAMP-Bereitstellung zu konfigurieren. Das Portal hilft Ihnen, Malware schneller zu erkennen und in die Quarantäne auszusondern. Sicherheitsstörungen werden erkannt, sobald sie auftreten. Verfolgen Sie deren Trajectorys, lernen Sie ihre Auswirkungen kennen und erfahren Sie, wie Sie Störungen erfolgreich beheben können. Mit FireAMP können Sie außerdem benutzerdefinierte Schutzvorkehrungen einrichten, die Ausführung bestimmter Anwendungen anhand von Gruppenrichtlinien blockieren und benutzerdefinierte Whitelists erstellen.

Vergleich: Netzwerk-AMP und endpunktbasierte FireAMP

Da die FireAMP-Malware-Erkennung am Endpunkt zum Zeitpunkt des Downloads oder der Ausführung ausgeführt wird und verwaltete Geräte Malware im Netzwerkverkehr erkennen, unterscheiden sich die Informationen zu diesen beiden Typen von Malware-Ereignissen. Endpunktbasierte Malware-Ereignisse enthalten beispielsweise Informationen zu Dateipfad, aufrufender Client-Anwendung usw. Bei der Malware-Erkennung im Netzwerkverkehr werden Informationen über den Port, das Anwendungsprotokoll und die ursprüngliche IP-Adresse für die Verbindung ermittelt, über die die Datei übertragen wird.

Netzwerkbasierte Malware-Ereignisse enthalten Benutzerinformationen des zuletzt am Host angemeldeten Benutzers, für den die Malware gemäß Netzwerkanalyse bestimmt war. Andererseits beziehen sich die Informationen der von FireAMP gemeldeten Benutzer auf den Benutzer, der auf dem Endpunkt angemeldet ist, auf dem die Malware laut lokalem Connector erkannt wurde.

Hinweis Die IP-Adressen, die in den endpunktbasierten Malware-Ereignissen gemeldet werden, sind möglicherweise nicht in der Netzwerkübersicht enthalten und werden je nach Art der Bereitstellung, Netzwerkarchitektur, Compliance-Niveau und weiteren Faktoren ggf. nicht im Netzwerk überwacht. Die Endpunkte mit installierten Connectors sind u. U. nicht die gleichen Hosts wie die, die von den verwalteten Geräten überwacht werden.

Identifizierung von und Schutz vor Sicherheitsrisiken – Angriffskontinuum-Übersicht: Während des Angriffs

Die Identifizierung von und der Schutz vor Sicherheitsrisiken ist eine richtlinienbasierte Funktion, die in die Zugriffskontrolle integriert ist. Sie ermöglicht die Überwachung des Netzwerkverkehrs auf Sicherheitsverstöße, um schädlichen Datenverkehr in einer Inline-Bereitstellung zu blockieren oder zu ändern. Eine Richtlinie zu Sicherheitsrisiken enthält u. a. folgende Komponenten:

• Regeln, die die Protokoll-Header-Werte, den Payload-Inhalt und bestimmte Paketgrößeneigenschaften prüfen

• Regelstatuskonfiguration auf Basis von FireSIGHT-Empfehlungen

• erweiterte Einstellungen, wie Präprozessoren und andere Erkennungs- und Performancefunktionen

• Präprozessorregeln, die Ereignisse für verknüpfte Präprozessoren und Präprozessoroptionen generieren können

Das System verwendet die mehrfach ausgezeichnete Snort®-Technologie, um den Netzwerkverkehr zu analysieren und Angriffsereignisse zu generieren. Dabei handelt es sich um Datensätze des Verkehrs, der gegen die auf das Gerät angewendete Richtlinie für Sicherheitsrisiken verstößt, durch die ein bestimmtes Netzwerksegment überwacht wird. In Abbildung 41 ist ein grundlegender Prüfungsablauf dargestellt.

61

http://amp.sourcefire.com/


Abbildung 41 Grundlegender Prüfungsablauf

Bediener können die Ereignisse überprüfen und feststellen, ob diese im Netzwerkkontext wichtig sind. Angriffsereignisse können durch folgende Komponenten generiert werden:

• Link-Layer-Decoder, z. B. Ethernet-II-Decoder

• Netzwerk-Layer-Decoder, z. B. IP-Decoder

• Transport-Layer-Decoder, z. B. TCP-Decoder

• Anwendungsebenen-Decoder oder Präprozessor, z. B. HTTP-Untersuchungspräprozessor

• Regel-Engine

Ereignisse enthalten u. a. die folgenden Informationen:

• Datum und Uhrzeit der Generierung des Ereignisses

• Ereignispriorität

• bei Verwendung der Netzwerkanalyse die Auswirkungsmarkierung zum Ereignis

• ob das Paket, durch das das Ereignis verursacht wurde, verworfen wurde oder in einer Inline-, Switch- oder gerouteten Bereitstellung verworfen worden wäre

• Name des Geräts, von dem das Ereignis generiert wurde

• Protokoll des Pakets, welches das Ereignis verursacht hat

• Quell-IP-Adresse und -Port für das Ereignis

• Ziel-IP-Adresse und -Port für das Ereignis

• Name des am Quell-Host angemeldeten Benutzers

• ICMP-Typ und -Code (für ICMP-Datenverkehr)

• Cisco FirePOWER-Systemkomponente, die das Ereignis generiert hat (z. B. Regel, Decoder oder Präprozessor)

• kurze Beschreibung des Ereignisses

• Klassifizierung der Regel, durch die das Ereignis generiert wurde

• VLAN, zu dem der Host gehört

3479

57

Verwaltetes Gerät

Decoder

Präprozessoren

ErfasstePakete

Regel-Engine Warnung

Zwischenfälle

Angriffsereignis-Anzeigen

Ereignis-datenbank

62


FireSIGHT – Angriffskontinuum-Übersicht: Während und nach dem Angriff

FireSIGHT ist die Erkennungstechnologie von Cisco, die Informationen über Hosts, Betriebssysteme, Anwendungen, Benutzer, Dateien, Netzwerke, Geolokation und Sicherheitslücken erfasst. Diese umfangreiche Datensammlung ermöglicht einen kompletten Überblick über das Netzwerk und bietet ein zuverlässiges Verfahren zur Meldung der Indications of Compromise. Das FireSIGHT Management Center dient zur Anzeige und Analyse der von FireSIGHT erfassten Daten. Zudem können Sie diese Daten für die Zugriffskontrolle durchführen und mit deren Hilfe den Regelstatus für Sicherheitsrisiken ändern. Darüber hinaus lassen sich auf Basis korrelierter Ereignisdaten für die Hosts Indications of Compromise im gesamten Netzwerk verfolgen. In Tabelle 8 sind alle Informationen aufgeführt, für die FireSIGHT Transparenz gewährleisten kann.

Indications of Compromise – Angriffskontinuum-Übersicht: Während und nach dem Angriff

Das System kann direkte Zusammenhänge zwischen bestimmten Arten von Zugriffsversuchen, Malware und anderen Ereignissen, die auf Hosts im Netzwerk auftreten, herstellen, um zu ermitteln, wann die Hosts potenziell kompromittiert wurden, und diese Hosts mit IOC-Tags (Indications of Compromise) kennzeichnen. IOC-Daten bieten ein präzises, direktes Bild der Bedrohungen des überwachten Netzwerkes, da sie sich auf dessen Hosts beziehen.

Das System nutzt all diese Informationen zur Unterstützung im Rahmen der forensische Analyse, Erstellung von Verhaltensprofilen, der Zugriffskontrolle sowie bei der Eindämmung von Schwachstellen und Exploits, für die das Unternehmen anfällig ist, und der entsprechenden Reaktion darauf.

Tabelle 8 FireSIGHT-Transparenz

Kategorien StichprobenCisco NGIPS und NGFW Typische IPS Typische NGFWs

Bedrohungen Angriffe, Anomalien

Ja Ja Ja

Nachsichtige AD, LDAP, POP3 Ja Nein Ja

Web-Anwen- dungen

Facebook-Chat, Ebay

Ja Nein Ja

Anwendungspro- tokolle

HTTP, SMTP, SSH

Ja Nein Ja

Client-Anwen- dungen

Firefox, IE 6, BitTorrent

Ja Nein Nein

Netzwerkserver Apache 2.3.1, IIS4 Ja Nein Nein

Betriebssysteme Windows, Linux Ja Nein Nein

Router und Switches

Cisco, Nortel, Wireless

Ja Nein Nein

Wireless Access Points

Linksys, Netgear Ja Nein Nein

Mobilgeräte iPhone, Android Ja Nein Nein

Drucker HP, Xerox, Canon Ja Nein Nein

VoIP-Telefone Avaya, Polycom Ja Nein Nein

Virtuelle Systeme VMware, Xen Ja Nein Nein

63


Dynamische Dateianalyse (Sandboxing) – Angriffskontinuum-Übersicht: während und nach dem Angriff

Zur weiteren Malware-Analyse und Identifikation von Sicherheitsrisiken in Dateien können qualifizierte abgefangene Dateien zur dynamischen Analyse an die Sourcefire-Cloud gesendet werden. Die Cisco Sourcefire-Cloud führt solche Dateien in einer Testumgebung aus und anhand der Ergebnisse ein Bedrohungswert-Rating und einen zusammenfassenden Bericht zur dynamischen Analyse an das FireSIGHT Management Center zurück. Qualifizierte Dateien können auch zur Spore-Analyse an die Cisco Sourcefire-Cloud gesendet werden, bei der ergänzend zur Malware-Identifizierung die Struktur der Datei überprüft wird. Es können nur bestimmte Dateitypen zur dynamischen Analyse an die Cloud gesendet werden. Zudem müssen die Dateien den in der Richtlinie für die Zugriffskontrolle konfigurierten Werten für die zulässige minimale und maximale Dateigröße entsprechen. Dateien können wie folgt gesendet werden:

• automatisch zur dynamischen Analyse, wenn eine Dateiregel eine Malware-Cloud-Suche für eine ausführbaren Datei durchführt und die Einstufung der Datei unbekannt ist

• manuell bis zu fünfundzwanzig Dateien auf einmal zur dynamischen Analyse, nachdem diese gespeichert sind und sofern der betreffende Dateityp unterstützt wird, z. B. PDF, Microsoft Office-Dokumente und andere

Nach dem Absenden der Dateien werden sie zur Analyse in der Cloud einer Warteschlange hinzugefügt. Die abgefangenen Dateien und die zugehörige File Trajectory können angezeigt werden, um zu prüfen, ob eine Datei zur dynamischen Analyse gesendet wurde. Immer, wenn eine Datei zur dynamischen Analyse gesendet wird, analysiert die Cloud die Datei, selbst wenn während der ersten Analyse Ergebnisse generiert wurden. Die Cloud führt die dynamische Analyse durch, wobei die Datei in einer Sandbox-Umgebung ausgeführt wird. Die Cloud-Analyse gibt folgende Ergebnisse zurück:

• Bedrohungswert: ein Maß für die Wahrscheinlichkeit, dass eine Datei Malware enthält

• einen zusammenfassenden Bericht zur dynamischen Analyse, in dem erläutert wird, warum die Cloud den Bedrohungswert vergeben hat

Auf Basis der Dateirichtlinienkonfiguration können Dateien, deren Bedrohungswert über einem festgelegten Grenzwert liegt, automatisch blockiert werden. Eine genauere Prüfung des zusammenfassenden Berichts zur dynamischen Analyse kann dabei helfen, Malware leichter zu identifizieren und Erkennungsfunktionen zu verfeinern.

Verbindungsdaten – Angriffskontinuum-Übersicht: Während und nach dem Angriff

FirePOWER-Appliances überwachen ständig den durch die Hosts im Netzwerk generierten Datenverkehr. Mithilfe der Zugriffskontrollfunktion können Sie Verbindungsereignisse generieren, wenn der Netzwerkverkehr spezifische Bedingungen erfüllt. Verbindungsereignisse enthalten Daten zu den erkannten Sitzungen, z. B. Zeitstempel, IP-Adresse, Geolokationsdaten, Anwendungen usw. Zugriffskontrollrichtlinien zur Protokollierung von Verbindungsereignissen in folgenden Fällen:

• Netzwerkverkehr wird mithilfe von Sicherheitsinformationen zu Blacklists hinzugefügt oder überwacht. Dadurch werden auch Sicherheitsinformationsereignisse erstellt.

• Netzwerkverkehr erfüllt die Bedingungen einer nicht überwachungsspezifischen Zugriffskontrollregel.

• Netzwerkverkehr wird durch die Standardaktion einer Richtlinie zur Zugriffskontrolle verarbeitet.

• Netzwerkverkehr erfüllt die Bedingungen mindestens einer Überwachungsregel (automatisch aktiviert).

64


• Eine Richtlinie für Sicherheitsrisiken, die mit einer Zugriffskontrollregel verknüpft ist, generiert ein Ereignis (automatisch aktiviert).

• Eine Dateirichtlinie, die mit einer Zugriffskontrollregel verknüpft ist, erkennt oder blockiert eine Datei bzw. erkennt oder blockiert Malware (automatisch aktiviert).

Die Verknüpfung der Verbindungsprotokollierung mit einzelnen Zugriffskontrollregeln, Richtlinien und Konfigurationen ermöglicht Ihnen die präzise Kontrolle über die zu protokollierenden Verbindungen.

Verbindungsprotokolle – Angriffskontinuum-Übersicht: Nach dem Angriff

Das Cisco FirePOWER-System erstellt aus den Verbindungsdaten, die in den fünfminütigen Intervallen erfasst werden, Verbindungsprotokolle, aus denen das System Verbindungsdiagramme und Datenverkehrsprofile erzeugt. Optional können auf Basis der Verbindungsprotokolldaten benutzerdefinierte Workflows erstellt werden, die genau so verwendet werden, wie Workflows, die auf individuellen Verbindungsereignissen basieren. Es gibt keine separaten Verbindungsprotokolle für Sicherheitsdatenereignisse. Allerdings können die Ereignisse beim Beenden von Verbindungen innerhalb der Verbindungsprotokolldaten zusammengefasst werden. Für die Zusammenfassung müssen mehrere Verbindungen:

• das Ende der Verbindungen darstellen.

• dieselben Quell- und Ziel-IP-Adressen haben und denselben Port auf dem Host des Responders (Ziel) verwenden.

• dasselbe Protokoll (TCP oder UDP) verwenden.

• dasselbe Anwendungsprotokoll verwenden.

• entweder vom selben von FireSIGHT verwalteten Gerät erkannt werden oder vom selben NetFlow-fähigen Gerät exportiert werden. Jedes Verbindungsprotokoll enthält Statistiken zum gesamten Datenverkehr sowie die Anzahl der im Protokoll zusammenfassten Verbindungen.

Verbindungsprotokolle enthalten nicht alle Informationen über die zusammengefassten Verbindungen. Da beispielsweise keine Kundendaten zur Erstellung von Verbindungsaufstellungen aus Verbindungen verwendet werden, sind in den Aufstellungen keine Kundendaten enthalten.


Mit dem Einzelstandort-Clustering von TrustSec und der Secure Enclave Architecture steht Ihnen eine breite Auswahl an Zugriffskontroll- und Segmentierungsfunktionen zur Verfügung.

Zugriffskontrolle – Angriffskontinuum-Übersicht: Vor und während des Angriffs

Mit einer Richtlinie zur Zugriffskontrolle wird festgelegt, wie das System den Datenverkehr im Netzwerk behandelt. Eine oder mehrere Richtlinien zur Zugriffskontrolle können konfiguriert und auf eine oder mehrere FirePOWER-Appliances angewendet werden. Jedes Gerät darf jeweils nur eine aktuell angewendete Richtlinie haben.

Eine einfache Richtlinie zur Zugriffskontrolle kann Datenverkehr auf Basis von Sicherheitsinformationsdaten filtern. Mithilfe der Standardaktion der Richtlinie kann der nicht durch Blacklists überwachte Datenverkehr nachfolgenden Optionen behandelt werden:

• gesamten Datenverkehr blockieren, bevor er ins Netzwerk gelangt

• gesamten im Netzwerk eingehenden Datenverkehr ohne weitere Prüfung als vertrauenswürdig einstufen und passieren lassen

65


• gesamten im Netzwerk eingehenden Datenverkehr passieren lassen und nur durch eine Netzwerkanalyserichtlinie prüfen

• gesamten im Netzwerk eingehenden Datenverkehr passieren lassen und den Datenverkehr durch Richtlinien für Sicherheitsrisiken und Netzwerkanalyse prüfen

Optional können einer Richtlinie Zugriffskontrollregeln hinzugefügt werden, die eine präzise Kontrolle über die Abwicklung und Protokollierung des Netzwerkverkehrs ermöglichen. Für jede Regel wird eine Regelaktion festgelegt, die bestimmt, ob zutreffendem Netzwerkverkehr vertraut bzw. dieser überwacht oder blockiert werden oder dieser mithilfe einer Richtlinie für Sicherheitsrisiken oder einer Dateirichtlinie geprüft werden soll. Jede Regel enthält eine Reihe von Bedingungen, die den zu kontrollierenden Datenverkehr identifizieren. Dies können einfache oder sehr komplex Regeln handeln, die durch eine beliebige Kombination von Sicherheitsbereich, Netzwerk, VLAN, Quell- oder Zielland oder -kontinent, Active Directory-LDAP-Benutzer oder Gruppe, Anwendung, Transportprotokoll-Port oder URL den zutreffenden Datenverkehr eingrenzen.

In Abbildung 42 sind der Traffic-Fluss durch die FirePOWER-Appliance und einige Details zu den Prüfungen für diesen Datenverkehr dargestellt. Beachten Sie, dass das System keinen Fastpath-Datenverkehr oder Datenverkehr auf Blacklists prüft. Bei Datenverkehr, der über eine Zugriffskontrollregel oder Standardaktion verwaltet wird, sind Fluss und Prüfung von der Regelaktion abhängig. Aus Vereinfachungsgründen sind Regelaktionen nicht im Diagramm dargestellt. Das System führt jedoch keine Prüfung des als vertrauenswürdig eingestuften und gesperrten Datenverkehrs durch. Außerdem wird die Dateiprüfung nicht im Zusammenhang mit der Standardaktion unterstützt.

Abbildung 42 Flussdiagramm: Richtlinie für Zugriffskontrolle

HTTP-Antwortseite – Angriffskontinuum-Übersicht: Nach dem Angriff

Wenn die HTTP-Anfrage eines Benutzer durch eine Zugriffskontrollregel blockiert wird, erhält der Benutzer im Webbrowser je nach Konfiguration der Sperre der Sitzung durch das System eine andere Anzeige. Zur Festlegung der Regelaktion haben Sie folgende Auswahlmöglichkeiten:

• Sperre oder Sperre mit Zurücksetzen, um die Verbindungsherstellung abzulehnen. Die blockierte Sitzung läuft ab. Das System setzt die Sperre und die Verbindungen zurück. Für beide Sperraktionen kann die Standardbrowser- oder -serverseite durch eine benutzerdefinierte Seite ersetzt werden, auf der eine Meldung erscheint, dass die Verbindungsherstellung abgelehnt wurde.

EingehendesPaket

Fast-Path-Regeln

SecurityIntelligence

Zugriffs-kontrollregeln

Zugriffskontroll-Standardaktion

Nichtüber

Fast Path

Nicht inBlacklist

Übereinstimmungnur mit

Überwachungsregeloder mit keiner Regel

Angriffsinspektion

Dateiinspektion

Erkennung

Angriffsinspektion

Dateiinspektion

Erkennung

Über Fast Path Auf Blacklist

Zugriffskontrollrichtlinie

Datenverkehr zugelassen Datenverkehr gesperrt Traffic-Flussund Inspektion

erfolgen gemäß Regelaktion

Traffic-Flussund Inspektion

erfolgen laut Standardaktion

Erste Nicht-Überwachungsregel zugeordnet

66


• Interaktive Sperre oder interaktive Sperre mit Zurücksetzen, wobei eine HTTP-Antwortseite mit einer Warnmeldung angezeigt wird, auf der Benutzer die Möglichkeit haben, den Vorgang durch Klicken auf eine Schaltfläche fortzusetzen oder die Seite zu aktualisieren, um die ursprünglich angeforderte Seite zu laden.

Solche Meldungen über die Aktion zur Durchsetzung von Richtlinien führen zu weniger Frustration bei Benutzern und Administratoren, da diese schnell erfahren, warum der Datenverkehr blockiert wurde.

Beachten Sie, dass keine HTTP-Antwortseiten für Datenverkehr angezeigt werden, der aufgrund einer Blacklist auf Basis von Sicherheitsinformationen oder einer auf Basis eines SSL-Zertifikats (Secure Sockets Layer) erkannten Anwendung blockiert wurde.

Identitätsmanagement

Wenn eine FirePOWER-Appliance eine Anmeldung erkennt, sendet sie folgende Daten an das FireSIGHT Management Center, die als Benutzeraktivitäten protokolliert werden:

• bei der Anmeldung identifizierter Benutzername

• Zeitpunkt der Anmeldung

• IP-Adresse der Anmeldung

• E-Mail-Adresse des Benutzers (für POP3-, IMAP- und SMTP-Anmeldungen)

• Name des Geräts, das die Anmeldung erkannt hat. Wenn der Benutzer zuvor schon einmal identifiziert wurde, aktualisiert das FireSIGHT Management Center dessen Anmeldehistorie.

Das FireSIGHT Management Center kann anhand der E-Mail-Adressen der POP3- und IMAP-Anmeldungen eine Verbindung zu LDAP-Benutzernamen herstellen. Erkennt das FireSIGHT Management Center z. B. eine neue IMAP-Anmeldung und die E-Mail-Adresse der IMAP-Anmeldung stimmt mit der eines vorhandenen LDAP-Benutzers überein, wird durch die IMAP-Anmeldung kein neuer Benutzer erstellt, sondern der Verlauf des LDAP-Benutzers aktualisiert. Wenn ein Benutzer nie zuvor identifiziert wurde, fügt das FireSIGHT Management Center diesen der Benutzerdatenbank hinzu. Bei einmaligen AIM-, SIP- und Oracle-Anmeldungen werden stets neue Benutzerdatensätze erstellt, da diese Verbreitungsweg keine Daten enthalten, die das FireSIGHT Management Center in Zusammenhang mit anderen Anmeldetypen bringen kann.

Das FireSIGHT Management Center protokolliert in folgenden Fällen keine Benutzeraktivitäten oder Benutzeridentitäten:

• Wenn die Netzwerkanalyserichtlinie so konfiguriert ist, dass der Anmeldetyp ignoriert wird.

• Wenn ein verwaltetes Gerät eine SMTP-Anmeldung erkennt, aber die Benutzerdatenbank keine zuvor erkannten LDAP-, POP3- oder IMAP-Benutzer mit einer übereinstimmenden E-Mail-Adresse enthält.

Cisco empfiehlt, Sourcefire-Benutzeragenten auf allen Microsoft Active Directory-LDAP-Servern zu installieren, um die Benutzeraktivitäten über die Active Directory-Server zu überwachen. Um die Benutzerkontrollfunktion zu aktivieren, müssen die Sourcefire-Benutzeragenten installiert werden, damit den Benutzern IP-Adressen zugewiesen werden können. Dadurch lassen sich Zugriffskontrollregeln mit bestimmten Benutzerbedingungen auslösen.

Ein Sourcefire-Benutzeragent kann zur Überwachung der Benutzeraktivitäten auf bis zu fünf Active Directory-Servern verwendet werden. Zur Verwendung eines Agenten müssen Sie eine Verbindung zwischen allen FireSIGHT Management Centern, die mit dem Agenten verbunden sind, und den überwachten LDAP-Servern einrichten. Diese Verbindung ermöglicht nicht nur das Abrufen von Metadaten für Benutzer, deren An- und Abmeldungen von Benutzeragenten erkannt wurden. Sie dient auch dazu, die Benutzer und Gruppen festzulegen, die in Zugriffskontrollregeln verwendet werden.

67


Vom LDAP-Server bezieht das FireSIGHT Management Center folgende Informationen und Metadaten für jeden Benutzer:

• LDAP-Benutzername

• Vor- und Nachname

• E-Mail-Adresse

• Geschäftsbereich

• Telefonnummer

Die Benutzeraktivitätsdatenbank enthält Datensätze der Benutzeraktivitäten im Netzwerk, entweder über eine Verbindung zu einem Active Directory-LDAP-Server, der ebenfalls von einem Sourcefire-Benutzeragenten überwacht wird, oder durch Netzwerkerkennung. Das System protokolliert Ereignisse in folgenden Fällen:

• wenn es einzelne An- oder Abmeldungen erkennt

• wenn es einen neuen Benutzer erkennt

• wenn ein Benutzer manuell gelöscht wird

• wenn das System einen Benutzer erkennt, der noch nicht in der Datenbank vorhanden ist, den Benutzer aber nicht hinzufügen kann, weil die laut Lizenz zulässige Höchstzahl für FireSIGHT erreicht ist

Anwendungstransparenz und -kontrolle

Hostprofile – Zuordnung des Angriffskontinuums: Vor und während eines Angriffs

Ein Hostprofil bietet eine vollständige Übersicht über sämtliche Informationen, die das FireSIGHT Management-System über einen einzigen Host gesammelt hat, wie MAC-Adresse, Hostnamen und Betriebssystem. Hostattribute sind benutzerdefinierte Beschreibungen, die auf einen Host angewendet werden können und auch im Hostprofil aufgeführt sind. Beispielsweise könnte ein Hostattribut zugewiesen werden, welches das Gebäude benennt, in dem sich der Host befindet. In einem Hostprofil können Sie die vorhandenen Hostattribute anzeigen, die auf einen Host angewendet werden, und die Hostattributwerte ändern. Hostprofile bieten außerdem Informationen über die Server, Clients und Hostprotokolle, die auf einem bestimmten Host ausgeführt werden, z. B. ob diese einer Compliance Whitelist entsprechen. Server können von der Whitelist entfernt werden, und Details können für diese Server angezeigt werden.

Weitere Informationen sind verfügbar, z. B. Verbindungsereignisse für Server und Clients, Protokollaufzeichnungen über die Sitzung, in der Serverdatenverkehr erkannt wurde, sowie Server, Clients oder Hostprotokolle, die aus dem Hostprofil gelöscht wurden. Daten zur Benutzerhistorie für Hosts können angezeigt werden, wenn das System so konfiguriert wurde, dass diese aufgezeichnet werden. Das Hostprofil enthält eine Liste von Schwachstellen, die bearbeitet werden kann. Diese Funktion enthält Informationen darüber, welche Schwachstellen für den Host behoben wurden.

Dateikontrolle – Zuordnung des Angriffskontinuums: Vor und während eines Angriffs

Über die Dateikontrolle können verwalteten Geräte das Hochladen (Senden) oder Herunterladen (Empfangen) von Dateien bestimmter Typen durch Benutzer über bestimmte Anwendungsprotokolle erkennen und blockieren. Die Dateikontrolle kann als Teil der gesamten Zugriffskontrollkonfiguration mit Dateirichtlinien konfiguriert werden, die Zugriffskontrollregeln enthalten. Eine Dateirichtlinie ist eine Auswahl von Konfigurationseinstellungen, die vom System zur Ausführung von Advanced Malware Protection und Dateikontrolle im Rahmen der Zugriffskontrollkonfiguration genutzt werden. Abbildung 43 zeigt eine einfache Zugriffskontrollrichtlinie in einer Inline-Bereitstellung.

68


Abbildung 43 Einfache Zugriffskontrollrichtlinie

Eine Dateirichtlinie enthält, ebenso wie ihre übergeordnete Zugriffskontrollrichtlinie, Regeln, die festlegen, wie das System Dateien behandelt, die den Bedingungen der einzelnen Regeln entsprechen. Mehrere Dateiregeln können konfiguriert werden, um verschiedene Aktionen für verschiedene Dateitypen, Anwendungsprotokolle oder Übertragungsrichtungen festzulegen. Sobald eine Datei einer Regel entspricht, kann die Regel:

• Dateien anhand eines einfachen Dateitypabgleichs zulassen oder blockieren.

• Dateien anhand des Malware-Ratings blockieren.

• abgefangene Dateien auf dem Gerät speichern.

• abgefangene Dateien zur dynamischen Analyse einsenden.

Darüber hinaus kann eine Dateirichtlinie:

• Dateien anhand von Einträgen in der Whitelist oder der benutzerdefinierten Erkennungsliste automatisch als unschädlich oder als Malware behandeln

• Dateien als Malware behandeln, wenn der Bedrohungswert einen konfigurierbaren Grenzwert überschreitet.

In Tabelle 9 sind die Dateiregelkomponenten aufgeführt.

Regel 1: ZulassenÜbereinstim-

mender Datenverkehr

Übereinstimmender Datenverkehr

Zugriffskontrollrichtlinie

Regel 2: Zulassen

Dateirichtlinie A

Standardaktion: Zulassen

Datenverkehr zugelassenohne Dateiinspektion

Dateirichtlinie B

Keine Übereinstimmung

Keine Übereinstimmung

3479

59

Netzwerkverkehr

Dateien zugelassen/gesperrtper Dateirichtlinie A

Dateien zugelassen/gesperrtper Dateirichtlinie A

Tabelle 9 Dateiregelkomponenten

Dateiregelkom- ponente BeschreibungAnwendungs- protokoll

Das System kann Dateien erkennen und untersuchen, die über FTP, HTTP, SMTP, IMAP, POP3, und NetBIOS-ssn (SMB) übertragen wurden.

Übertragungs- richtung

Das System kann über FTP, HTTP, IMAP, POP3 und NetBIOS-ssn (SMB) eingehenden Datenverkehr auf heruntergeladene Dateien prüfen. Das System kann über FTP, HTTP, SMTP und NetBIOS-ssn (SMB) ausgehenden Datenverkehr auf hochgeladene Dateien prüfen.

69


Erkennung von SSL-Anwendungen –Zuordnung des Angriffskontinuums: Während des Angriffs

Das FirePOWER-System bietet Detektoren, die anhand der Daten einer SSL-Sitzung (Secure Socket Layer) das Anwendungsprotokoll, die Client-Anwendung oder die Web-Anwendung in der Sitzung identifizieren können.

Wenn das System eine verschlüsselte Verbindung erkennt, markiert es diese entweder als generische HTTPS-Verbindung oder als ein bestimmtes sicheres Protokoll, wie z. B. SMTPS. Wenn das System eine SSL-Sitzung erkennt, fügt es SSL client in das Clientfeld in den Verbindungsereignissen für die Sitzung ein. Wenn eine Web-Anwendung für die Sitzung identifiziert wird, generiert das System Erkennungsereignisse für den Datenverkehr.

Für SSL-Anwendungsdatenverkehr können verwaltete Geräte, auf denen Version 5.2 oder höher ausgeführt wird, den allgemeinen Namen aus dem Serverzertifikat erkennen und mit einer Client- oder Web-Anwendung aus einem SSL-Hostmuster abgleichen. Wenn das System einen konkreten Client identifiziert, ersetzt es SSL client durch den Namen dieses Clients. Da der SSL-Anwendungsdatenverkehr verschlüsselt ist, kann das System nur Informationen im Zertifikat und nicht die Anwendungsdaten des verschlüsselten Datenstroms zur Identifizierung nutzen. Aus diesem Grund können SSL-Hostmuster in einigen Fällen lediglich den Hersteller von Anwendung identifizieren. Daher weisen mehrere eventuell vorhandene SSL-Anwendungen vom selben Hersteller möglicherweise dieselbe Identifizierung auf.

Network File Trajectory – Zuordnung des Angriffskontinuums: Während und nach einem Angriff

Die Funktion Network File Trajectory verwendet SHA-256-Hash-Werte, um Dateiübertragungspfade im Netzwerk zu verfolgen.

Um eine Dateiübertragung im Netzwerk zu verfolgen, muss das System eine der folgenden Aufgaben ausführen:

• SHA-256-Hash-Wert der Datei berechnen und anhand dieses Werts eine Malware-Cloud-Suche durchführen

• über die Integration von FireSIGHT Management Center in das FireAMP-Abonnement des Unternehmens endpunktbasierte Bedrohungs- und Quarantänedaten zu dieser Datei empfangen

Für jede Datei gibt es eine Trajectory-Übersicht mit einer visuellen Anzeige der erfolgten Übertragungen und zusätzlichen Informationen zu der Datei.

Dateikategorien und Dateitypen

Das System kann verschiedene Dateitypen erkennen, die in bestimmte Hauptkategorien wie Multimedia (swf, mp3), ausführbare Dateien (exe, torrent) und PDF-Dateien unterteilt werden.

Dateiregelaktion Die für eine Dateiregel definierte Aktion legt fest, wie das System Datenverkehr behandelt, der den Bedingungen der Regel entspricht. Dateiregeln werden in der Reihenfolge evaluiert, die in der Regel definiert ist, und nicht in numerischer Reihenfolge.

Tabelle 9 Dateiregelkomponenten (Fortsetzung)

70


Anwendungserkennung – Angriffskontinuum-Übersicht: Während und nach dem Angriff

Während das FireSIGHT Management-System den IP-Datenverkehr analysiert, versucht es, häufig verwendeten Anwendungen im Netzwerk zu identifizieren. Die Anwendungserkennung ist entscheidend für die anwendungsbasierte Zugriffskontrolle. Das System erkennt drei Arten von Anwendungen:

• Anwendungsprotokolle wie HTTP und SSH

• Clients wie Webbrowser und E-Mail-Clients

• Web-Anwendungen wie MPEG-Videos und Facebook

Das System identifiziert Anwendungen im Netzwerk-Traffic entweder anhand der ASCII- oder hexadezimalen Muster in den Paket-Headern oder anhand des Ports, den der Datenverkehr verwendet. Einige Verbreitungsweg verwenden sowohl Port- als auch Mustererkennung, um die Wahrscheinlichkeit der korrekten Identifizierung des Datenverkehrs für eine bestimmte Anwendung zu erhöhen.

Es gibt zwei Quellen von Anwendungsdetektoren im FireSIGHT-System:

• von Sourcefire bereitgestellte Detektoren, die Web-Anwendungen, Clients und Anwendungsprotokolle erkennen

• benutzerdefinierte Anwendungsprotokolldetektoren, die erstellt werden können, um die Funktionen des Systems zur Erkennung von Anwendungsprotokollen zu optimieren

Anwendungsprotokolle können auch durch implizierte Anwendungsprotokollerkennung erkannt werden, bei der die Existenz eines Anwendungsprotokolls auf Basis der Erkennung eines Clients impliziert wird. Das FireSIGHT Management-System verwendet verschiedene Merkmale, um Anwendungsfilter zu erstellen, mit denen die Zugriffskontrolle durchgeführt sowie Suchvorgänge, Berichte und Dashboard-Widgets eingeschränkt werden können.

Erkennung vertraulicher Daten – Angriffskontinuum-Übersicht: Während und nach dem Angriff

Vertrauliche Daten, wie z. B. Sozialversicherungsnummern, Kreditkartennummern, Führerscheinnummern usw., können absichtlich oder versehentlich ins Internet gelangen. Das System verfügt über einen Präprozessor, der vertrauliche Daten in ASCII-Text erkennen und entsprechende Ereignisse generieren kann, was bei der Erkennung ungewollte Datenlecks besonders nützlich sein kann.

Das System erkennt keine verschlüsselten oder verschleierten vertraulichen Daten oder vertrauliche Daten in komprimierten oder codierten Formaten wie Base64-codierten E-Mail-Anhängen. Das System erkennt vertrauliche Daten pro TCP-Sitzung, indem individuelle Datentypen mit dem Datenverkehr abgeglichen werden. Die Standardeinstellungen können für jeden Datentyp und für globale Optionen geändert werden, die für alle Datentypen in der Intrusion-Richtlinie gelten. Das FireSIGHT Management-System bietet vordefinierte, häufig verwendete Datentypen und ermöglicht auch die Erstellung benutzerdefinierter Datentypen. Jedem Datentyp ist eine Präprozessorregel für vertrauliche Daten zugeordnet. Die Erkennung vertraulicher Daten und die Ereignisgenerierung können für jeden Datentyp aktiviert werden, indem die entsprechende Präprozessorregel für den Datentyp aktiviert wird. Da das System über die Vorverarbeitung des TCP-Streams überwachte Sitzungen erstellt, muss die Vorverarbeitung des TCP-Streams aktiviert werden, um die Erkennung vertraulicher Daten in der Richtlinie verwenden zu können.

Hinweis Die Erkennung vertraulicher Daten kann unter Umständen die Leistung erheblich beeinträchtigen. Zusätzliche Hinweise zur Bereitstellung dieser Funktion finden Sie in der Benutzeranleitung zum Sourcefire FirePOWER-System.

71


Protokollierung und Nachverfolgbarkeitsmanagement

Aktivieren des Datenbankzugriffs

Das FireSIGHT Management Center kann so konfiguriert werden, dass Clients oder Anwendungen von Drittanbietern schreibgeschützten Zugriff auf die Datenbank erhalten. Beachten Sie, dass für die Anmeldung bei der Datenbank über einen externen Client ein Benutzername und ein Kennwort für einen Administrator oder einen externen Datenbankbenutzer im FireSIGHT Management Center verwendet werden müssen.

Grenzwerte für Datenbankereignisse konfigurieren

Um eine höhere Leistung zu erzielen, sollte ein Höchstwert für die Anzahl der einzelnen speicherbaren Ereignistypen eingestellt werden. Verwenden Sie die Datenbankseite, um die maximale Anzahl der einzelnen Ereignistypen anzugeben, die vom FireSIGHT Management Center gespeichert werden können. Wenn die Anzahl der Ereignisse in der Angriffsversuchsdatenbank die Höchstzahl überschreitet, werden die ältesten Ereignisse und Paketdateien gelöscht, bis die Ereignisgrenzwerte in der Datenbank wieder eingehalten werden. Die Erkennungs- und die Benutzerdatenbank können auch manuell bereinigt werden. Außerdem kann eine E-Mail-Adresse konfiguriert werden, an die Benachrichtigungen gesendet werden, wenn Angriffsversuche und Prüfprotokolle aus der Datenbank gelöscht werden. In Tabelle 10 sind die minimale und maximale Anzahl der Datensätze aufgeführt, die für die einzelnen Ereignistypen gespeichert werden können.

Tabelle 10 Grenzwerte für Datenbankereignisse

Ereignistyp Oberer EreignisgrenzwertUnterer Ereignisgrenzwert

Angriffsversuche 2,5 Millionen (DC500) 10 Millionen (DC1000, virtuelles FireSIGHT Management Center) 20 Millionen (DC750) 30 Millionen (DC1500) 100 Millionen (DC3000) 150 Millionen (DC3500)

10.000

Erkennungsereignisse 10 Millionen null (Speicher wird deaktiviert)

Verbindungsereignisse/Sicherheitsinforma- tionsereignisse

10 Millionen (DC500, DC1000, virtuelles FireSIGHT Management Center) 50 Millionen (DC750) 100 Millionen (DC1500, DC3000) 500 Millionen (DC3500) Der obere Ereignisgrenzwert wird auf Verbindungsereignisse und Sicherheitsinformationsereignisse aufgeteilt. Die Summe der konfigurierten Höchstwerte für die beiden Ereignistypen kann nicht höher sein, als der obere Ereignisgrenzwert.

null (Speicher wird deaktiviert)

Verbindungsaufstel- lungen (aggregierte Verbindungsereignisse)

10 Millionen (DC500, DC1000, virtuelles FireSIGHT Management Center) 50 Millionen (DC750) 100 Millionen (DC1500, DC3000) 500 Millionen (DC3500)

null (Speicher wird deaktiviert)

72


Systemprüfprotokolle

Die Appliances, die Bestandteil des FirePOWER-Systems sind, generieren einen Prüfdatensatz für jede Benutzerinteraktion mit der Web-Schnittstelle und speichern Systemstatusmeldungen im Systemprotokoll.

FireSIGHT Management-Appliances und verwaltete FirePOWER-Appliances bieten zudem umfassende Berichtsfunktionen. Damit können Berichte für nahezu alle Datentypen generiert werden, die in einer Ereignisansicht zugänglich sind, beispielsweise Prüfdaten. Im Prüfprotokoll werden maximal 100.000 Einträge gespeichert. Wenn die Anzahl der Prüfprotokolleinträge 100.000 überschreitet, löscht die Appliance die ältesten Datensätze aus der Datenbank.

Streaming-Prüfprotokoll

Eine Systemrichtlinie kann so konfiguriert werden, dass die Appliance ein Prüfprotokoll auf einen externen Host überträgt. Es ist wichtig, dass der externe Host aktiv ist und dass die Appliance, die das Prüfprotokoll sendet, darauf zugreifen kann. Beachten Sie, dass der Host das Prüfprotokoll nicht akzeptiert, wenn der für den Empfang des Prüfprotokolls konfigurierte Computer nicht für den Empfang von Remote-Meldungen konfiguriert ist.

Korrelations- und Compliance-Whitelist-Ereignisse

1 Million eins

Malware-Ereignisse 10 Millionen 10.000

Dateiereignisse 10 Millionen null (Speicher wird deaktiviert)

Systemstatusereignisse 1 Million null (Speicher wird deaktiviert)

Prüfdatensätze 100.000 eins

Problembehebungs- statusereignisse

10 Millionen eins

Whitelist-Verletzungs- verlauf der Hosts im Netzwerk

30-tägiger Verletzungsverlauf eintägiger Verlauf

Benutzeraktivitäten (Benutzerereignisse)

10 Millionen eins

Benutzeranmeldungen (Benutzerverlauf)

10 Millionen eins

Protokolldatensätze für importierte Regelaktualisierungen

1 Million eins

Tabelle 10 Grenzwerte für Datenbankereignisse

Ereignistyp Oberer EreignisgrenzwertUnterer Ereignisgrenzwert

73

Validierungsergebnisse

Systemprotokoll

Die Seite „Systemprotokoll“ (Syslog) enthält Daten aus dem Systemprotokoll für die Appliance. Im Systemprotokoll werden die vom System generierten Meldung in folgender Reihenfolge angezeigt:

• Datum, an dem die Meldung generiert wurde

• Uhrzeit, zu der die Meldung generiert wurde

• Host, der die Meldung generiert hat

• Text der Meldung

Hinweis Die Informationen im Systemprotokoll sind lokal. So können etwa mit FireSIGHT Management Center keine Systemstatusmeldungen in den Systemprotokollen auf den FirePOWER-Appliances angezeigt werden. Systemprotokollmeldungen können für bestimmte Komponenten über die Filterfunktion angezeigt werden.

NetFlow

Für die festgelegten Netzwerke können die FirePOWER-Appliances die von NetFlow-fähigen Geräten exportierten Datensätze erkennen, anhand der enthaltenen Daten Verbindungsereignisse generieren und diese Ereignisse an das FireSIGHT Management Center senden, damit diese in der Datenbank protokolliert werden.

Secure Data Center for the Enterprise umfasst das Cisco Validated Design Cyber Threat Defense, eine auf Lancope Stealthwatch basierende Lösung, die für NetFlow-basierte Bedrohungsanalysen optimiert wurde. Zusätzliche Empfehlungen für die Verwendung von NetFlow mit den FireSIGHT Management- und FirePOWER-Appliances werden in diesem Designhandbuch nicht behandelt.

ValidierungsergebnisseDiese Lösung wurde für die verschiedenen in diesem Dokument beschriebenen Bereitstellungsoptionen validiert. Jede Bereitstellungsoption wird mit ausführlichen Validierungsergebnissen in separaten Implementierungshandbüchern behandelt.

ZusammenfassungFür Rechenzentren zuständige Teams sind in puncto Cybersicherheit mit einer Herausforderung konfrontiert, die in dieser Form in der Geschichte der IT bisher einmalig ist. Die Community der Cyber-Angreifer entwickelt seit Jahren ihre Fähigkeiten weiter, um jederzeit in Netzwerke und Geräte eindringen zu können. Secure Data Center: Threat Management with NextGen IPS ist Teil eines größeren Lösungsportfolios, das umfassende Funktionen zur Abwehr von Cyber-Angriffen bietet, um Rechenzentren zu schützen und gleichzeitig einen effizienten und skalierbaren Betrieb zu ermöglichen.

74

Referenzen

Referenzen• Secure Data Center for the Enterprise: Einzelstandort-Clustering mit TrustSec –

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/sdc-dg.pdf

• Secure Data Center for the Enterprise: Secure Enclaves Architecture

• Secure Data Center for the Enterprise: Cyber Threat Defense für das Rechenzentrum – http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-secure-data-center-portfolio/sea_ctd.pdf

• Benutzerhandbuch zum Sourcefire 3D-System 60

• Installationshandbuch zum Sourcefire 3D-System

• Systemmanagement- und Konfigurationshandbuch zu NX-OS für Cisco Nexus Serie 7000 – http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg.pdf

• NIST-Sonderpublikation 800-53, 4. überarbeitete Ausgabe, „Security and Privacy Controls for Federal Information Systems and Organizations“ – http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915447

• „Subvirt: Implementing Malware with Virtual Machines“ Präsentation, Samuel T. King, Peter M. Chen, University of Michigan – http://www.cse.psu.edu/~mcdaniel/cse544/slides/cse544-subvirt-sawani.pdf

• „Top 20 Critical Security Controls – Version 5“, SANS Institute – http://www.sans.org/critical-security-controls/

• „Find, Fix, Track, Target, Engage, Assess“, John A. Tirpak – www.airforcemag.com/magazinearchive/pages/2000/july%202000/0700find.aspx

75

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/sdc-dg.pdf

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-secure-data-center-portfolio/sea_ctd.pdf

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg.pdf

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915447

http://www.cse.psu.edu/~mcdaniel/cse544/slides/cse544-subvirt-sawani.pdf

http://www.sans.org/critical-security-controls/

www.airforcemag.com/magazinearchive/pages/2000/july%202000/0700find.aspx

Referenzen

76

Secure Data Center für Großunternehmen – Threat Management ...€¦ · Secure Data Center für...

Documents

Transcript of Secure Data Center für Großunternehmen – Threat Management ...€¦ · Secure Data Center für...