Netzwerksicherheit am Edge: Splunk-Erkennungen mit Cisco Secure Firewall Threat Defense

Durch die Integration der Firepower Threat Defense (FTD) von Cisco mit der Analyseplattform von Splunk gewinnt euer Sicherheitsteam sofort und unternehmensweit umfassende Transparenz in Bezug auf Netzwerkbedrohungen – weit mehr als das, was eine einzelne Firewall allein erkennen könnte. Trotz der dringenden Notwendigkeit, Netzwerk- und Sicherheitsdaten miteinander zu verbinden, gibt es immer noch viele Unternehmen, die zwar Perimeter-Abwehrsysteme wie Cisco FTD nutzen, deren umfangreiche Telemetriedaten aber nur schwer in verwertbare Erkenntnisse für das SOC verwandeln können. Allzu oft arbeiten solche Technologien in Silos, sodass die Sicherheitsteams gezwungen sind, bei der Einrichtung von Warnmeldungen entweder auf einfache Logs ohne ausreichenden Security-Kontext zurückzugreifen oder auf generische Integrationen wie die Splunk-App Cisco Security Cloud, die wiederum keine maßgeschneiderten, sofort einsetzbaren Erkennungsfunktionen mitbringt, sondern ausschließlich mit Firewall-Metriken (Verbindungen etc.) arbeitet. Diese Lücke müssen die Teams daher meist selbst füllen – sie müssen ihre eigene Erkennungslogik von Grund auf von Hand neu aufsetzen und können das volle Potenzial ihrer Sicherheitsinvestitionen gar nicht ausschöpfen.

Das Splunk Threat Research Team (STRT) hat diese Lücke als Gelegenheit erkannt, zu demonstrieren, wie beide Technologien zusammen noch leistungsfähiger wirken können. Unser Projekt „Better Together“ zielt darauf ab, unmittelbaren Nutzen für beiderlei Kundschaften zu schaffen:

• Für Cisco-Kundschaft: Einsatzfertige Out-of-the-box-Sicherheitserkennungen übersetzen die leistungsstarke FTD-Netzwerktelemetrie in umsetzbare Sicherheitserkennungen, ohne dass dazu erweiterte Splunk-Kenntnisse erforderlich wären.
• Für Splunk-Kundschaft: Der reiche Kontext, den die Cisco-FTD-Geräte liefern, ermöglicht detailgenaue Transparenz bei allen Bedrohungen auf Netzwerkebene.

„Better Together“ markiert die erste Phase einer erweiterten Zusammenarbeit, die ein stärker integriertes Security-Monitoring schaffen soll und auf den konkreten Kundennutzen des Sicherheitsportfolios von Cisco und die Analysefähigkeiten von Splunk fokussiert. Das Splunk Threat Research Team, das ja zu Cisco gehört, kann direkt mit der Talos-Bedrohungsforschung und den FTD-Entwicklungsteams zusammenarbeiten und hat daher genauen Einblick in die Datenstruktur und die Erkennungsfähigkeiten dieser Geräte. Dieser Beitrag zeigt, wie wir aus der Kombination der FTD-Telemetriedaten von Cisco mit den fortschrittlichen Analysefunktionen von Splunk insgesamt 17 gezielte Erkennungen entwickeln konnten – u. a. für Anomalien, verdächtige Dateidownloads und Warnmeldungen bei gehäuften Intrusion-Versuchen. So müssen die Sicherheitsteams sich nicht mehr mit isolierten Erkenntnissen aus einzelnen Geräten zufriedengeben, sondern bekommen umfassende Bedrohungstransparenz in ihrer gesamten Cisco-Firewall-Einrichtung.

Aufbau einer realistischen Testumgebung

Zur Erstellung von relevanten, im Realeinsatz erprobten Erkennungen hat das STRT eine vollständige Laborumgebung eingerichtet, in der sich reale Einsatzszenarien simulieren lassen. Damit können wir die Datenstruktur untersuchen, Angriffsszenarien testen und die Wirksamkeit der Erkennungen validieren.

Die Hauptkomponenten der Architektur unseres Testgeländes werden in einer AWS VPC bereitgestellt:

• Firewall Management Center (FMC): Eine Management-Konsole, die auf Security Cloud Control gehostet ist und die zentrale Verwaltung von Richtlinien ermöglicht.
• Firepower Threat Defense (FTD): Die zentrale Security-Anwendung, aus der die Telemetriedaten stammen.
• Linux- und Windows-Hosts: Zielsysteme, mit denen wir interne Netzwerke simulieren und realistischen Datenverkehr generieren können.
• Splunk-Instanz: Eine dedizierte Umgebung für Log-Erfassung, Korrelationen und die Entwicklung von Erkennungen.

Zur Erfassung und Verarbeitung der Daten aus unseren Cisco-Geräten verwenden wir Cisco Security Cloud . Diese Splunk-App ermöglicht eine nahtlose Integration von Cisco-Sicherheitsprodukten und Splunk. Zu den Vorzügen der App gehören ein modulares UX-Eingabedesign, integrierte Statusprüfungen und ein kontinuierliches Monitoring, das die operative Integrität sicherstellt. Die App unterstützt etliche Sicherheitsprodukte von Cisco, u. a. diese:

• Cisco AI Defense
• Cisco Duo
• Cisco Email Threat Defense (ETD)
• Cisco Identity Intelligence (CII)
• Cisco Multicloud Defense
• Cisco Secure Endpoint
• Cisco Secure Firewall (FTD/eStreamer/ASA)
• Cisco Secure Malware Analytics (SMA)
• Cisco Secure Network Analytics (SNA)
• Cisco Vulnerability Intelligence
• Cisco XDR

Allein in unserer Testumgebung generierten und analysierten wir in nur 60 Tagen über 650.000 Events aus vier verschiedenen Event-Typen, sodass wir über einen umfangreichen Datenbestand zur Entwicklung und Validierung von Erkennungsfunktionen verfügten.

Das Verständnis des eStreamer-Protokolls war für unsere Arbeit unerlässlich, da es die Struktur liefert, die zum Parsen und Normalisieren der Daten für das Common Information Model (CIM) von Splunk erforderlich ist. Zwar beruhen die meisten Erkennungen auf Rohdaten, doch wir nahmen uns trotzdem die Zeit und sahen uns genau an, was die einzelnen Felder bedeuten und wie sie verwendet werden.

Mit dem eStreamer-Protokoll können bestimmte Event-Typen aus dem Firewall Management Center (FMC) aufgenommen werden. Das FMC kann zwar eine Vielzahl von Event-Typen liefern (Discovery Events, Correlation Events, Impact Flag Alerts etc.), doch mit unserer Splunk-Integration über das Technology Add-on Cisco Security Cloud konzentrierten wir uns primär auf die folgenden vier Event-Typen:

• Connection Events: Detaillierte Netzwerkflussdaten inklusive Endpunkten, Protokollen und Anwendungen.
• File Events: Informationen zu Dateien, die über das Netzwerk übertragen werden, einschließlich Malware-Vorentscheidungen.
• Intrusion Events: Warnmeldungen, die durch Snort-Regeln und andere Intrusion-Detection-Mechanismen ausgelöst werden.
• Intrusion Packets: Erfasster Netzwerkverkehr, der ein Intrusion Event ausgelöst hat. Die Intrusion Packets können mit dem entsprechenden Intrusion Event korreliert werden.

Jeder Event-Typ enthält eine ganze Reihe von Feldern, die Kontext für die Sicherheitsanalyse liefern. Ein Connection Event enthält z. B. solche Einzelheiten:

{
 "EventType": "ConnectionEvent",
 "FirstPacketSecond": 1746616737,
 "InitiatorIP": "172.16.3.110",
 "ResponderIP": "99.78.180.156", "InitiatorPort": 32116,
 "ResponderPort": 443,
 "Protocol": "tcp",
 "AC_RuleAction": "Allow",
 "ClientApplication": "SSL client",
 "Application": "HTTPS",
 "EVE_Process": "pulumi",
 "EVE_ProcessConfidencePct": 99,
 "EVE_ThreatConfidenceIndex": 1
 // Additional fields omitted for brevity
}

Diese Felder werden in Konfigurationsstrukturen mit der Bezeichnung „FieldSetDef“ in der EventCatalog.json des FMC definiert, sodass wir für jeden Event-Typ spezifische Untermengen von Daten anfordern können.

Teams, die unsere Arbeit vertiefen möchten, finden im Secure Firewall eStreamer Fully-Qualified Events Guide von Cisco eine umfassende Dokumentation des Protokolls und der Event-Struktur. Darüber hinaus haben wir unsere eigenen Feldzuordnungen für jeden Event-Typ bei unseren Open-Source-Sicherheitsinhalten veröffentlicht, damit andere auf diesen Erkennungen aufbauen können.

Von Telemetrie zu umsetzbarer Sicherheit

Unsere umfangreichen Angriffssimulationen und die enge Zusammenarbeit mit dem Talos-Team von Cisco haben 17 solide Sicherheitserkennungen für Cisco Secure Firewall Threat Defense ergeben. Diese Erkennungen arbeiten mit den ausführlichen Telemetriedaten aus den FTD-Geräten und können potenzielle Bedrohungen in unterschiedlichen Phasen des Angriffslebenszyklus zu identifizieren.

Die Erkennungen haben wir als Analytics Story unter den Titel Cisco Secure Firewall Threat Defense Analytics zusammengefasst und mit dem Enterprise Security Content Update (ESCU) 5.4.0 verfügbar gemacht. Diese Story bietet ein umfassendes Framework für das Monitoring und die Erkennung von Netzwerkbedrohungen am Edge mit FTD-Geräten von Cisco.

Jede Erkennung in der Story enthält Metadaten zur Zuordnung auf das MITRE-ATT&CK-Framework, sodass die Sicherheitsteams weiteren Kontext zu den Angriffstaktiken erhalten.

Der Großteil dieser Erkennungen sind als Anomalie-Erkennungen klassifiziert, d. h. sie identifizieren Verhaltensweisen, die von den Mustern der Normalität abweichen. Hunting-Erkennungen wie „Rare Snort Rule Triggered“ hingegen sollen das proaktive Threat Hunting unterstützen.

Was diese Erkennungen besonders wertvoll macht, ist der Umstand, dass jede von ihnen exemplarische Angriffsdaten enthält, sodass Sicherheitsteams sie über das Attack Data-Projekt in ihren eigenen Umgebungen testen und validieren können. Dadurch soll sichergestellt werden, dass die Teams die Wirksamkeit der Erkennungen überprüfen können, bevor sie sie in Produktionsumgebungen einsetzen.

Die Erkennungen ordnen sich rund um die folgenden drei Event-Haupttypen:

1. Connection Events
2. File Events
3. Intrusion Events

Im Folgenden gehen wir auf jeden Event-Typ ein, erklären kurz, was er leisten kann, und zeigen eine Erkennung, die darauf aufbaut.

Connection-Event-Erkennungen

Connection Events protokollieren Netzwerk-Flow-Metadaten. Hierzu gehören Quell- und Ziel-IPs, Ports, Anwendungslogs, SSL-Zertifikatsfingerabdrücke und Details aus der Encrypted Visibility Engine (EVE) von Cisco.

{
    "EventType": "ConnectionEvent",
    "FirstPacketSecond": 1746616737,
    "LastPacketSecond": 1746616746,
    "ConnectionDuration": 9,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-xxxxxxx",
    "InstanceID": 1,
    "ConnectionID": 13715,
    "AC_RuleAction": "Allow",
    "InitiatorIP": "172.16.xxx.xxx",
    "ResponderIP": "99.78.xxx.xxx",    "InitiatorPort": 32116,
    "ResponderPort": 443,
    "Protocol": "tcp",
    "IngressInterface": "inside",
    "EgressInterface": "outside",
    "IngressZone": "inside",
    "EgressZone": "outside",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "FirewallPolicy": "default",
    "FirewallRule": "Permit Outbound",
    "PrefilterPolicy": "Default Prefilter Policy",
    "ClientApplication": "SSL client",
    "Application": "HTTPS",
    "WebApplication": "Amazon Web Services",
    "InitiatorPackets": 19,
    "ResponderPackets": 20,
    "InitiatorBytes": 3497,
    "ResponderBytes": 6222,
    "NAP_Policy": "Balanced Security and Connectivity",
    "SSL_Policy": "None",
    "SSL_FlowStatus": "Success",
    "SSL_CipherSuite": "Unknown",
    "SSL_CertFingerprint": "ba6360463452acfa35e48eb7d446e4c1165ed659",
    "SSL_Version": "Unknown",
    "SSL_ServerCertStatus": "Valid",
    "SSL_ActualAction": "Do Not Decrypt",
    "SSL_ExpectedAction": "Do Not Decrypt",
    "URL": "https://ssm.us-east-2.amazonaws.com",
    "NAT_InitiatorPort": 32116,
    "NAT_ResponderPort": 443,
    "NAT_InitiatorIP": "172.16.xxx.xxx",
    "NAT_ResponderIP": "99.78.xxx.xxx",    "EVE_Fingerprint": "tls/1/(0303)(c02bc02fc02cc030cca9cca8c009c013c00ac014130113021303)[(0000)(000500050100000000)(000a000c000a6399001d001700180019)(000b00020100)(000d001a0018080404030807080508060401050106010503060302010203)(0010000e000c02683208687474702f312e31)(0012)(0017)(002b00050403040303)(0033)(ff01)]",
    "EVE_Process": "pulumi",
    "EVE_ProcessConfidencePct": 99,
    "EVE_ThreatConfidencePct": 0,
    "EVE_ThreatConfidenceIndex": 1,
    "ClientAppDetector": "AppID"

}

Diese Daten verschaffen uns gründliche Transparenz: was sich durchs Netzwerk bewegt und wie es sich bewegt. So können wir z. B. ungewöhnliche Outbound-Ziele erkennen, können die Anwendungen identifizieren, die Verbindungen initiieren (sogar bei verschlüsseltem Datenverkehr), und beobachten, ob an sich vertrauenswürdige Protokolle auf verdächtige Weise genutzt werden.

Sehen wir uns z. B. die folgende Erkennung an:

Cisco Secure Firewall – BITS-Aktivitäten im Netzwerk

`cisco_secure_firewall` EventType=ConnectionEvent action=Allow ClientApplication="BITS" AND NOT url IN ("*://msedge.b.tlu.dl*")| stats count min(_time) as firstTime max(_time) as lastTime by src_ip, dest, dest_port, transport, rule, url, EVE_Process, ClientApplication, ClientApplicationVersion, action
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `cisco_secure_firewall___bits_network_activity_filter`

Microsoft verwendet BITS (Background Intelligent Transfer Service) zur Bereitstellung von Updates. Da der Service jedoch unauffällig im Hintergrund läuft und Proxys oder Prüfschichten häufig umgehen kann, ist er auch bei Angreifern beliebt, die darüber Daten verschieben oder C&C-Kanäle einrichten.

Diese Erkennung identifiziert die potenziell verdächtige Nutzung von Windows BITS, sie verwendet dazu die integrierten Anwendungsdetektoren von Cisco Secure Firewall Threat Defense.

Bei den Connection Events erfasst das Feld ClientApplication den Namen der Anwendung, die die Verbindung initiiert hat; dies geschieht auf der Grundlage entweder der integrierten oder eigener App-Detektoren.

Einer dieser integrierten Detektoren identifiziert konkret den BITS-Traffic, was wir nutzen können, um Fälle zu markieren, bei denen BITS mit unerwarteten Zielen kommuniziert. Damit können wir Versuche, einen solchen Service zu missbrauchen, abfangen.

Auf vergleichbare Weise sind wir bei anderen Feldern des Event-Typs „Connection“ vorgegangen. Das Feld SSL_CertFingerprint enthält z. B. den SHA1-Hash des SSL-Zertifikats einer Session. Durch den Abgleich dieses Fingerabdrucks mit einer Liste bekannter Schadzertifikate haben wir eine Erkennung entwickelt, die anschlägt, wenn verschlüsselter Datenverkehr mit Schadinfrastruktur in Verbindung steht, und zwar selbst dann, wenn keine Domain- oder IP-basierten Indikatoren verfügbar sind.

Die vollständige Analytic Story hierzu ist auf research.splunk.com zu finden.

File-Event-Erkennungen

File Events erfassen Einzelheiten zu den Dateien, die über das Netzwerk übertragen werden: Dateityp, Richtung (Download oder Upload), SHA-Hash, für die Übertragung verwendete Anwendung, die sogenannte AMP-Disposition (ob die Datei sauber, unbekannt oder als Malware bekannt ist) etc.

Diese Telemetriedaten geben uns Einblick in potenziell riskante Dateiaktivitäten und machen uns z. B. auf Downloads von ausführbaren Dateien aufmerksam, auf versuchte Datenexfiltration oder auf wiederholte Downloads derselben verdächtigen Datei. Da Angreifer ihre Payloads oft über scheinbar harmlose Downloads einschleusen, ist Transparenz auf Dateiebene der Schlüssel zur Erkennung von Schadaktivitäten in diesen frühen Stadien.

{
    "EventType": "FileEvent",
    "EventSecond": 1746614252,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-eeb1de9c8a63",
    "InstanceID": 1,
    "FirstPacketSecond": 1746614252,
    "ConnectionID": 13652,
    "InitiatorIP": "172.16.xxx.xxx",
    "ResponderIP": "146.75.xxx.xxx",    "InitiatorPort": 32018,
    "ResponderPort": 80,
    "Protocol": "tcp",
    "FileDirection": "Download",
    "FileAction": "Malware Cloud Lookup",
    "FileSHA256": "5806a935e72d5606cd504f5cb1b4f533705118e869db872f6dc4876006defd8c",
    "SHA_Disposition": "Unknown",
    "SperoDisposition": "Spero detection not performed on file",
    "FileName": "am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",
    "FileType": "MSEXE",
    "FileSize": 767600,
    "Application": "HTTP",
    "ClientApplication": "Parallels",
    "WebApplication": "Microsoft Update",
    "FilePolicy": "Test",
    "FileStorageStatus": "Not Stored (Disposition Was Pending)",
    "FileSandboxStatus": "Sent for Analysis",
    "FileStaticAnalysisStatus": "Failed to Send",
    "URI": "/d/msdownload/update/software/defu/2025/05/am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "Device": "172.16.0.10",
    "DeviceIP": "172.16.0.10",
    "DeviceSerialNumber": "9AD5V8FSS0D"
}

Ein besonders hilfreiches Feld ist hier FileType. Cisco Secure Firewall Threat Defense kann übertragene Dateien nach Typ klassifizieren, sogar in verschlüsselten Datenströmen. So können wir uns auf Hochrisikokategorien konzentrieren, z. B. auf ausführbare Formate (.exe, .msi, .scr etc.), die häufig zur Platzierung von Malware verwendet werden. Beispiele:

Cisco Secure Firewall – Binärdatei-Downloads

Diese Analyse erkennt Downloads von Archivdateien, ausführbaren Dateien und Skriptdateien, also der Dateiformen, die bei der Verbreitung von Malware oft eine Rolle spielen. Zu diesen Dateitypen gehören PE-Dateien, Shell-Skripte, Autorun-Dateien, Installationsprogramme und bekannte Testdateien wie EICAR.

`cisco_secure_firewall` EventType=FileEvent FileDirection="Download" 
FileType IN ("ISHIELD_MSI", "BINHEX", "BINARY_DATA", "ELF", "MACHO", "JARPACK", "TORRENT", "AUTORUN", "EICAR", "LNK", "SCR", "UNIX_SCRIPT")
| lookup cisco_secure_firewall_filetype_lookup Name as FileType OUTPUT Description
| stats count min(_time) as firstTime max(_time) as lastTime
        values(uri) as uri
        values(ClientApplication) as ClientApplication
        values(file_hash) as file_hash
        values(SHA_Disposition) as SHA_Disposition
        by FileDirection FileType src_ip dest app file_name ThreatName dest_port Description
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| table firstTime lastTime src_ip dest dest_port FileDirection FileType Description uri file_name file_hash app ClientApplication SHA_Disposition ThreatName
| `cisco_secure_firewall___binary_file_type_download_filter`

Genau wie bei den Connection Events haben wir mit einer Kombination aus anderen Feldern wie FileDirection, SHA_Disposition und ResponderPort gearbeitet und daraus Erkennungen gebaut, die Malware-Downloads oder Dateidownloads über ungewöhnliche Ports aufzeigen, was darauf hindeuten könnte, dass jemand versucht, die Standard-Sicherheitskontrollen zu unterlaufen.

Die komplette Analyseliste für diesen Event-Typ ist ebenfalls bei research.splunk.com zu finden.

Intrusion-Event-Erkennungen

Intrusion Events werden erzeugt, wenn Snort und andere Erkennungsmechanismen von Cisco Secure Firewall Threat Defense den Traffic mit einer Regel abgleichen. Jedes Event zeichnet bestimmte Informationen auf: Auslösesignatur, Quell- und Ziel-IPs, Klassifizierung der Regel und, sofern zutreffend, eine Zuordnung zu MITRE ATT&CK.

Diese Telemetriedaten geben Aufschluss über das tatsächliche Angriffsverhalten: ob es sich um eine Ausnutzung, um Scanning oder um Malware-Traffic handelt oder ob ein anderes bekanntes Muster vorliegt, insbesondere in Kombination mit dem IntrusionPacket-Event. Da die Snort-Regeln durch das Bedrohungsforschungsteam von Cisco Talos gepflegt und regelmäßig auf der Grundlage neuer Bedrohungen aktualisiert werden, bilden sie reale Angriffstechniken ab.

{
    "EventType": "IntrusionEvent",
    "EventSecond": 1746614252,
    "EventMicrosecond": 859986,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-eeb1de9c8a63",
    "InstanceID": 1,
    "FirstPacketSecond": 1746614252,
    "ConnectionID": 13652,
    "InitiatorIP": "146.75.xxx.xxx",
    "ResponderIP": "172.16.xxx.xxx",    "InitiatorPort": 80,
    "ResponderPort": 32018,
    "Protocol": "tcp",
    "IngressInterface": "outside",
    "EgressInterface": "inside",
    "IngressZone": "outside",
    "EgressZone": "inside",
    "PriorityID": 1,
    "GeneratorID": 1,
    "SignatureID": 11192,
    "SignatureRevision": 20,
    "Impact": 5,
    "IntrusionRuleMessage": "FILE-EXECUTABLE download of executable content",
    "Classification": "Potential Corporate Policy Violation",
    "WebApplication": "Microsoft Update",
    "ClientApplication": "Parallels",
    "Application": "HTTP",
    "IntrusionPolicy": "default",
    "FirewallPolicy": "default",
    "FirewallRule": "Permit Outbound",
    "NAP_Policy": "Balanced Security and Connectivity",
    "InlineResult": "Would block",
    "InlineResultReason": "Intrusion Policy in \"Detection\" Inspection Mode",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "HTTP_Hostname": "au.download.windowsupdate.com",
    "HTTP_URI": "/d/msdownload/update/software/defu/2025/05/am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",    "SnortRuleGroups": "Rule Categories>File>Executable",
    "MitreAttackGroups": "MITRE>ATT&CK Framework>Enterprise>Execution>User Execution>Malicious File",
    "ApplicationID": 676,
    "ApplicationProductivityIndex": 3,
    "ApplicationRiskIndex": 1,
    "ClientApplicationID": 2802,
    "ClientApplicationProductivityIndex": 4,
    "ClientApplicationRiskIndex": 2,
    "Device": "172.16.xxx.xxx",
    "DeviceIP": "172.16.xxx.xxx",    "DeviceSerialNumber": "9AD5V8FSxxx",
    "EgressInterfaceUUID": "efbb6160-f60a-11ef-a955-43d7eeccc024",
    "EgressZoneUUID": "efbcd7ac-f60a-11ef-a955-43d7eeccc024",
    "EventID": 250,
    "FirewallPolicyUUID": "00000000-0000-0000-0000-000068187db4",
    "FirewallRuleID": 268434433,
    "Hostname": "ip-172-16-0-50.us-east-2.compute.internal",
    "IngressInterfaceUUID": "ef9a2180-f60a-11ef-a955-43d7eeccc024",
    "IngressZoneUUID": "ef9c7c64-f60a-11ef-a955-43d7eeccc024",
    "InitiatorContinent": "North America",
    "InitiatorContinentCode": "na",
    "InitiatorCountry": "United States",
    "InitiatorCountryCode": "usa",
    "InitiatorCountryID": 840,
    "InlineResultID": 5,
    "InlineResultReasonID": 2,
    "IntrusionPolicyRevUUID": "c1fab45a-f615-11ef-bd70-44d7eeccc024",
    "IntrusionPolicyUUID": "0210b9f5-95a7-0ed3-0000-004294971142",
    "NAP_PolicyUUID": "a6738542-f604-11ef-8765-a4eeeeccc024",
    "ProtocolID": 6,
    "RealmID": 0,
    "RealmName": "Invalid ID",
    "SensorID": 2,
    "SnortVersionID": 3,
    "UserID": 9999997,
    "WebApplicationHTTP": "Microsoft Update",
    "WebApplicationID": 731,
    "WebApplicationProductivityIndex": 2
}

Intrusion Events sind besonders praktisch, wenn sie in großem Umfang genutzt werden. Eine einzelne Warnmeldung mag für sich genommen unauffällig sein, aber wenn dieselbe Regel auf mehreren Systemen oder gehäuft von einer einzigen Quelle ausgelöst wird, kann das Muster eine größere Angriffskampagne oder bereits kompromittierte Assets aufzeigen. Nehmen wir das folgende Erkennungsbeispiel:

Cisco Secure Firewall – gehäufte Intrusion Events pro Host

Diese Erkennung identifiziert Systeme, die eine ungewöhnlich hohe Anzahl von Intrusion-Warnmeldungen auslösen, was auf einen laufenden Angriff oder eine Kompromittierung hindeuten kann.

`cisco_secure_firewall` EventType=IntrusionEvent
| bin _time span=30m
| stats count as TotalEvents values(signature_id) as signature_id
        values(signature) as signature
        values(dest) as dest
        values(dest_port) as dest_port
        min(_time) as firstTime max(_time) as lastTime 
        by src_ip class_desc MitreAttackGroups InlineResult InlineResultReason rule transport app
| where TotalEvents >= 15
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `cisco_secure_firewall___high_volume_of_intrusion_events_per_host_filter`

Wenn wir die Metadaten des Events und das Event selbst nutzen, können wir unterschiedliche Intrusion-Warnmeldungen korrelieren und zu einer Warnmeldung mit höherer Relevanz aggregieren.

Better Together – durch Zusammenarbeit noch stärker

Dieses Projekt ist ein Musterbeispiel für die handfesten Vorteile der Zusammenarbeit von Cisco und Splunk. Aus der Kombination von Ciscos gründlicher Expertise in Sachen Netzwerksicherheit mit den fortschrittlichen Analysefähigkeiten von Splunk haben wir Erkennungen entwickelt, die aus beiden Plattformen den maximalen Nutzen ziehen. Diese Partnerschaft hat uns den direkten Zugriff auf die 60.000 Snort-Regeln von Cisco ermöglicht, sodass wir die aussagekräftigsten Warnmeldungen priorisieren und in das Erkennungsframework von Splunk integrieren konnten. Das Ergebnis ist ein umfassender Satz von Erkennungen, der die Stärken beider Plattformen kombiniert, um unserer Kundschaft bessere Security-Resultate zu ermöglichen.

Der Erfolg dieses Projekts ist der engen Zusammenarbeit mit dem Cisco-Team von Talos Network Threat Detection and Response (NTDR) zu verdanken. Besonderer Dank gilt Nasreddine Bencherchali, der die Erkennungsarbeiten auf Splunk-Seite leitete und maßgeblich an der Entwicklung der Analytics Story „Cisco Secure Firewall Threat Defense Analytics“ beteiligt war.

Zu den Führungskräften des Cisco-Teams, die diese Arbeit unterstützt haben, gehören:

• Christopher Marshall, Director of Security Research
• Alain Zidouemba, Director of Detection & Response for Talos
• Marc Mastrangelo, Product Management
• Zack Kielich, Director Solutions

Zu den wichtigsten technischen Beitragenden von Cisco gehören:

• Keith Lehrschall, Sr. Manager of Network Security Research
• Matthew Mickel, Security Research Engineering Technical Leader
• Spenser Reinhardt, Security Research Engineering Technical Leader
• John Levy, Security Research Engineering Technical Leader

Was wir als Nächstes vorhaben: erweitern und aufbauen

Die erste Veröffentlichung von 17 Erkennungen stellt zwar einen wichtigen Meilenstein dar, ist aber erst der Anfang unserer Reise. Auf unserer Roadmap stehen noch ein paar spannende Entwicklungen:

1. Erweiterte Plattformabdeckung: Wir wollen unsere Erkennungsfunktionen über FTD hinaus noch auf weitere Sicherheitsprodukte von Cisco ausweiten.
2. Erweiterte Korrelation: Wir entwickeln Erkennungen, die Daten aus unterschiedlichen Cisco-Produkten korrelieren und dadurch ein noch schärferes Threat Hunting ermöglichen.
3. Endpunkt-Integration: Zukünftige Erkennungen werden Netzwerktelemetrie mit Endpunktdaten kombinieren, sodass wir ein vollständigeres Bild potenzieller Bedrohungen erhalten.
4. Gezielte Kampagnenerkennung: Wir arbeiten an Erkennungen, die sich konkret auf bekannte Bedrohungsakteure und -kampagnen konzentrieren und dabei die Erkenntnisse von Cisco Talos nutzen.

Unser „Better Together“-Engagement wird dafür sorgen, dass dieses Projekt weiter gut vorankommt, damit wir ein bruchloses und effektives Security-Monitoring für Kundschaften schaffen, die sowohl Cisco- als auch Splunk-Technologien verwenden.

Erste Schritte

Bereit zur Implementierung dieser Erkennungen in eure Umgebung? So geht ihr am besten vor:

1. Inhalte aktualisieren: Installiert das neueste Enterprise Security Content Update (ESCU) 5.4.0 oder höher via Splunkbase.
2. Cisco Security Cloud installieren: Mit der Splunk-App Cisco Security Cloud erfasst und normalisiert ihr eure Cisco-FTD-Daten.
3. Erkennungen kennenlernen: Geht auf Splunk Research die Analytics Story Cisco Secure Firewall Threat Defense Analytics mit der vollständigen Liste der Erkennungen durch.
4. Beitragen: Habt ihr Vorschläge für Verbesserungen? Besucht unser Security Content Repository auf GitHub und wirkt an der Weiterentwicklung dieser Erkennungen mit.
5. Dranbleiben: Tretet dem Kanal #security-research bei den Splunk-User-Gruppen auf Slack bei und tauscht euch mit unserem Research-Team und der Community aus.