Sécurisation de la périphérie du réseau : détections de Cisco Secure Firewall Threat Defense pour Splunk

En intégrant Firepower Threat Defense (FTD) de Cisco à la plateforme d’analyse de Splunk, votre équipe de sécurité obtient immédiatement une visibilité complète à l’échelle de l’organisation sur les menaces réseau, bien au-delà de ce qu’un simple pare-feu peut détecter seul. Pourtant, malgré le besoin crucial de relier les données réseau et de sécurité, de nombreuses organisations continuent de déployer des défenses périmétriques comme FTD, mais peinent à transformer sa riche télémétrie en informations exploitables utiles à un SOC. Ces technologies fonctionnent trop souvent en silos, forçant les équipes de sécurité à s’appuyer soit sur une collecte de logs de base sans contexte de sécurité suffisant pour générer une alerte, soit sur des intégrations génériques comme la Cisco Security Cloud Splunk App, qui manquent de capacités de détection personnalisées prêtes à l’emploi et ne rapportent que des métriques de pare-feu comme les connexions. Cette lacune oblige souvent les équipes à créer manuellement une logique de détection personnalisée à partir de zéro, limitant ainsi le plein potentiel de leurs investissements en sécurité.

La Splunk Threat Research Team (STRT) a vu dans cette lacune l’occasion de démontrer que ces technologies peuvent être plus puissantes lorsqu’elles sont utilisées ensemble. Notre initiative « Better Together » vise à apporter une valeur immédiate aux deux clientèles :

• Pour les clients Cisco : les détections de sécurité prêtes à l’emploi convertissent la puissante télémétrie réseau du FTD en détections de sécurité exploitables sans nécessiter de connaissances avancées de Splunk.
• Pour les clients Splunk : le contexte riche fourni par les appareils Cisco FTD apporte une visibilité détaillée sur les menaces au niveau du réseau.

Cette initiative marque la première phase d’une collaboration plus large visant à offrir des expériences de supervision de la sécurité plus intégrées qui mettent en avant la valeur client dans l’ensemble du portefeuille de sécurité de Cisco et les capacités d’analyse de Splunk. En tant que membre de Cisco, la Splunk Threat Research Team collabore directement avec les équipes Talos de recherche sur les menaces et d’ingénierie FTD, apprenant ainsi la structure des données et les capacités de détection de ces dispositifs. Dans cet article, nous avons démontré comment la combinaison de la télémétrie FTD de Cisco avec l’analyse avancée de Splunk nous a permis de développer 17 détections ciblées, y compris l’identification des anomalies, les téléchargements de fichiers suspects et les alertes d’intrusion de fort volume, offrant aux équipes de sécurité une visibilité sur les menaces dans l’ensemble de leur déploiement de pare-feu Cisco, plutôt que de s’appuyer sur des informations isolées provenant d’appareils individuels.

Créer un environnement de test réaliste

Pour créer des détections significatives et éprouvées en conditions réelles, la STRT a mis en place un environnement de laboratoire complet qui reproduit des scénarios de déploiement réels. Cela nous a permis de comprendre la structure des données, de tester des scénarios d’attaque et de valider l’efficacité de la détection.

Animation : https://josehelps.github.io/cisco-ftd-visualization/

Notre architecture de laboratoire comprend plusieurs composants clés déployés dans un VPC AWS :

• Firewall Management Center (FMC) : console de gestion hébergée sur Security Cloud Control qui centralise l’administration des politiques
• Firepower Threat Defense (FTD) : l’appareil de sécurité principal qui génère les données de télémétrie
• Hôtes Linux et Windows : systèmes cibles permettant de simuler des réseaux internes et de générer un trafic réaliste
• Instance Splunk : environnement dédié à l’ingestion de logs, à la corrélation et au développement des détections

Pour collecter et traiter les données de nos appareils Cisco, nous avons utilisé l’application Cisco Security Cloud pour Splunk. Cette application Splunk offre une intégration transparente entre les produits de sécurité Cisco et Splunk, avec une conception modulaire de l’entrée UX, des vérifications d’état intégrées et une supervision continue pour garantir l’intégrité opérationnelle. L’application est compatible avec plusieurs produits de sécurité Cisco, notamment :

• 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.

Rien que dans notre environnement de test, nous avons généré et analysé plus de 650 000 événements répartis en quatre types différents en seulement 60 jours, ce qui nous a fourni un ensemble de données approfondi pour le développement et la validation des détections.

Comprendre le protocole eStreamer était essentiel pour notre travail, car il fournissait la structure nécessaire pour analyser et normaliser les données dans le Common Information Model (CIM) de Splunk. Alors que la plupart des détections utilisaient des données brutes, nous avons pris le temps de comprendre en profondeur ce que chaque champ signifiait et comment il était utilisé.

Le protocole eStreamer permet l’ingestion de types d’événements spécifiques depuis le Firewall Management Center (FMC). Bien que le FMC puisse fournir divers types d’événements (événements de découverte, événements de corrélation, alertes Impact Flag, etc.), notre intégration à Splunk via le Cisco Security Cloud TA se concentre sur ces quatre types principaux :

• Événements de connexion : données détaillées sur le flux réseau, couvrant les endpoints, les protocoles et les applications
• Événements de fichiers : informations sur les fichiers transférés sur le réseau, y compris les verdicts de malware
• Événements d’intrusion : alertes déclenchées par les règles Snort et d’autres mécanismes de détection d’intrusion
• Paquets d’intrusion : trafic réseau capturé qui a déclenché un événement d’intrusion. Les paquets d’intrusion peuvent être corrélés avec l’événement d’intrusion correspondant.

Chaque type d’événement comprend un vaste ensemble de champs qui fournissent un contexte pour l’analyse de sécurité. Par exemple, un événement de connexion comprend des détails tels que :

{
 "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
}

Ces champs sont définis dans des structures de configuration appelées « FieldSetDef » dans le fichier EventCatalog.json du FMC, nous permettant de demander des sous-ensembles spécifiques de données pour chaque type d’événement.

Pour les équipes souhaitant développer notre travail, le Secure Firewall eStreamer Fully-Qualified Events Guide fournit une documentation exhaustive sur le protocole et la structure des événements. De plus, nous avons publié nos mappages de champs internes pour chaque type d’événement dans le cadre de notre contenu de sécurité open source afin d’aider d’autres équipes à développer ces détections.

De la télémétrie aux données de sécurité exploitables

Nos simulations d’attaques étendues et notre collaboration étroite avec l’équipe Talos de Cisco ont permis d’obtenir un ensemble robuste de 17 détections de sécurité pour Cisco Secure Firewall Threat Defense. Ces détections exploitent la riche télémétrie fournie par les appareils FTD pour identifier les menaces potentielles à différentes étapes du cycle de vie des attaques.

Les détections sont organisées dans le scénario analytique Cisco Secure Firewall Threat Defense Analytics, disponible dans la version 5.4.0 d’Enterprise Security Content Update (ESCU). Ce scénario fournit un framework complet pour la supervision et la détection des menaces au périmètre du réseau à l’aide des dispositifs Cisco FTD.

Chaque détection dans le scénario analytique est accompagnée de métadonnées mappées au framework MITRE ATT&CK, fournissant aux équipes de sécurité un contexte sur les tactiques employées par l’adversaire.

La majorité de ces détections sont classées comme « anomalies », ce qui signifie qu’elles identifient des comportements qui s’écartent des schémas normaux, tandis que les détections de « chasse » comme « Rare Snort Rule Triggered » sont conçues pour prendre en charge les activités de threat hunting proactives.

Ces détections sont particulièrement précieuses en ce sens que chacune d’elles comprend des échantillons de données d’attaque qui permettent aux équipes de sécurité de les tester et de les valider dans leurs propres environnements à l’aide du projet Attack Data. Les équipes peuvent ainsi vérifier l’efficacité des détections avant de les déployer dans des environnements de production.

Ces détections sont organisées autour des trois types d’événements principaux suivants :

1. Événements de connexion
2. Événements de fichier
3. Événements d’intrusion

Nous présentons ci-dessous chaque type d’événement, expliquons brièvement ses caractéristiques et montrons une détection construite à partir de celles-ci.

Détection d’événements de connexion

Les événements de connexion enregistrent les métadonnées sur les flux de trafic réseau. Sont inclus les adresses IP source et de destination, les ports, les protocoles d’application, les empreintes de certificats SSL et les détails du moteur de visibilité chiffré (EVE) de 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"

}

Ces données nous offrent une visibilité approfondie sur les éléments qui transitent dans le réseau et leurs déplacements. Par exemple, nous pouvons détecter des destinations sortantes inhabituelles, identifier les applications qui initient des connexions (même sur du trafic chiffré), et observer quand des protocoles de confiance sont utilisés de manière suspecte.

Prenons par exemple cette détection :

Cisco Secure Firewall – Activité réseau Bits

`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 utilise BITS (Background Intelligent Transfer Service) pour livrer des mises à jour. Mais comme le service fonctionne silencieusement en arrière-plan et peut souvent contourner les proxys ou les couches d’inspection, il est largement utilisé par les adversaires pour déplacer des données ou établir des canaux de commande et contrôle.

Cette détection identifie une utilisation potentiellement suspecte du service Windows BITS à l’aide de détecteurs d’applications intégrés de Cisco Secure Firewall Threat Defense.

Dans les événements de connexion, le champ ClientApplication capture le nom de l’application à l’origine de la connexion, en fonction des détecteurs d’applications intégrés ou personnalisés.

L’un de ces détecteurs intégrés identifie spécifiquement le trafic BITS, que nous avons utilisé pour signaler les cas où BITS communiquait avec des destinations inattendues. Cela nous permet de détecter les tentatives d’abus d’un tel service.

Nous avons appliqué la même approche à d’autres champs du type d’événement « Connection ». Par exemple, le champ SSL_CertFingerprint contient le hachage SHA1 du certificat SSL utilisé dans une session. En comparant cette empreinte à une liste de certificats connus comme nuisibles, nous avons développé une détection capable de révéler le trafic chiffré lié à une infrastructure malveillante, même lorsque les indicateurs basés sur le domaine ou l’adresse IP ne sont pas disponibles.

Consultez research.splunk.com pour découvrir le scénario analytique complet.

Détections d'événements de fichiers

Les événements de fichiers capturent les détails des fichiers transférés sur le réseau, y compris le type de fichier, la direction (téléchargement ou envoi), le hachage SHA, l’application utilisée pour le transfert et la disposition AMP (que le fichier soit considéré comme malware, sain ou inconnu).

Cette télémétrie nous offre une visibilité sur les activités de fichiers potentiellement risquées, telles que les téléchargements d’exécutables, les tentatives d’exfiltration de données ou les téléchargements répétés du même fichier suspect. Étant donné que les attaquants livrent souvent des charges utiles via des téléchargements apparemment inoffensifs, la visibilité au niveau des fichiers est cruciale pour intercepter ces premières étapes de livraison.

{
    "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"
}

Un champ particulièrement utile ici : FileType. Cisco Secure Firewall Threat Defense peut classer les fichiers transférés par type, même au sein de flux chiffrés. Cela nous permet de nous concentrer sur les catégories à haut risque, telles que les formats exécutables (.exe, .msi, .scr, etc.), qui sont souvent associés à la diffusion de malwares. Par exemple :

Cisco Secure Firewall – Téléchargement de type de fichier binaire

Cette analyse détecte les téléchargements de fichiers impliquant des types de fichiers exécutables, d’archives ou qui sont liés à des scripts couramment utilisés dans la diffusion de malwares. Ces types de fichiers comprennent des formats tels que les exécutables PE, les scripts shell, les fichiers autorun, les installateurs et des échantillons de test connus comme 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`

De même que pour les événements de connexion, nous avons utilisé une combinaison d’autres champs tels que FileDirection, SHA_Disposition et ResponderPort pour créer des détections qui révèlent des téléchargements de fichiers sur des ports inhabituels ou des malwares en cours de téléchargement, ce qui peut indiquer des tentatives de contournement des contrôles de sécurité standards.

La liste complète des analyses liées à ce type d’événement est disponible sur research.splunk.com.

Détection d’événements d’intrusion

Les événements d’intrusion sont générés lorsque Snort et d’autres mécanismes de détection dans Cisco Secure Firewall Threat Defense comparent le trafic à une règle. Chaque événement consigne des informations telles que la signature déclenchée, les adresses IP source et de destination, la classification de la règle et, lorsqu’ils sont disponibles, les mappages aux techniques MITRE ATT&CK.

Cette télémétrie donne un aperçu du comportement réel des attaques, qu’il s’agisse d’exploitation, d’analyse, de trafic de malwares ou d’autres schémas connus, en particulier lorsqu’elle est combinée à l’événement IntrusionPacket. Comme les règles Snort sont gérées par la Talos Threat Research Team de Cisco, elles reflètent les techniques d’attaque réelles et sont régulièrement mises à jour en fonction des menaces émergentes.

{
    "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
}

Les événements d’intrusion sont particulièrement utiles lorsqu’ils sont déployés à grande échelle. Une alerte peut ne pas être significative en soi, mais lorsque la même règle est déclenchée sur plusieurs systèmes ou en grand nombre à partir d’une seule source, ce schéma peut révéler des campagnes d’attaque de plus grande envergure ou des actifs compromis. Prenons l’exemple de détection suivant :

Cisco Secure Firewall - Volume élevé d'événements d'intrusion par hôte

Cette détection identifie les systèmes qui déclenchent un nombre anormalement élevé d’alertes d’intrusion, ce qui peut indiquer une attaque active ou une compromission.

`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`

À partir des métadonnées de l’événement et de l’événement lui-même, nous pouvons commencer à corréler et à agréger différentes alertes d’intrusion en une seule alerte avec plus d’assurance.

Better Together : le pouvoir de la collaboration

Ce projet illustre les avantages concrets de la collaboration entre Cisco et Splunk. En combinant l’expertise approfondie de Cisco en sécurité réseau avec les capacités d’analyse avancées de Splunk, nous avons créé des détections qui maximisent la valeur extraite des deux plateformes. Ce partenariat a fourni un accès direct aux 60 000 règles Snort de Cisco, nous permettant de hiérarchiser et d’intégrer les alertes les plus précieuses dans le framework de détection de Splunk. Le résultat est un ensemble complet de détections qui exploitent les atouts des deux plateformes pour offrir de meilleurs résultats de sécurité à nos clients.

Le succès de cette initiative a été rendu possible grâce à une étroite collaboration avec l’équipe Talos Network Threat Detection and Response (NTDR) de Cisco. Nous remercions tout particulièrement Nasreddine Bencherchali, qui a dirigé les efforts d’ingénierie de détection du côté de Splunk et a joué un rôle déterminant dans le développement du scénario Cisco Secure Firewall Threat Defense Analytics.

Dirigeants de l’équipe Cisco qui ont soutenu cet effort :

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

Principaux contributeurs techniques de Cisco :

• 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

Prochaine étape : bâtir sur les fondations

Bien que la publication initiale de 17 détections représente une étape importante, ce n’est que le début de notre parcours. Notre feuille de route comprend plusieurs développements passionnants :

1. Couverture étendue de la plateforme : nous prévoyons d’étendre nos capacités de détection à d’autres produits de sécurité Cisco au-delà du FTD.
2. Corrélation avancée : nous développons des détections qui corrèlent les données de plusieurs produits Cisco afin de fournir des capacités de threat hunting plus sophistiquées.
3. Intégration des points de terminaison : les futures détections combineront la télémétrie réseau avec les données des endpoints pour offrir une vue plus complète des menaces.
4. Détection de campagnes ciblées : nous travaillons à des détections spécifiquement axées sur des acteurs malveillants et des campagnes connus, en tirant parti des informations de Cisco Talos.

Notre engagement envers la philosophie « Better Together » continuera de guider cette initiative alors que nous nous employons à créer une expérience de supervision de sécurité plus fluide et plus efficace pour les clients qui utilisent à la fois les technologies Cisco et Splunk.

Pour bien démarrer

Prêt à mettre en œuvre ces détections dans votre environnement ? Voici comment démarrer :

1. Mettez à jour votre contenu : installez la dernière version d’Enterprise Security Content Update (ESCU) (version 5.4.0 ou ultérieure) à partir de Splunkbase.
2. Installez l’application Cisco Security Cloud : déployez l’application Cisco Security Cloud pour Splunk pour collecter et normaliser vos données Cisco FTD.
3. Examinez les analyses : consultez le scénario Cisco Secure Firewall Threat Defense Analytics sur Splunk Research pour examiner l’ensemble complet des détections.
4. Contribuez : vous avez des idées d’amélioration ? Accédez à notre dépôt de contenu de sécurité sur GitHub pour contribuer au développement continu de ces détections.
5. Restez connectés : rejoignez le canal #security-research dans les groupes d’utilisateurs Splunk sur Slack pour échanger avec notre équipe de recherche et notre vaste communauté.