Wo soll ich anfangen? Zum vierten Mal in Folge hatte Elastic das Privileg, als vertrauenswürdiger Industriepartner bei der Übung Defence Cyber Marvel – der wichtigsten Cyber-Übungsreihe des britischen Verteidigungsministeriums – mitzuwirken. DCM26 war ohne Frage die bisher ambitionierteste Version, und wir freuen uns riesig, endlich darüber sprechen zu können, was wir gebaut haben, wie wir es gebaut haben und was wir dabei gelernt haben.
Was ist Defence Cyber Marvel?
Für diejenigen, die damit nicht vertraut sind: Defence Cyber Marvel (DCM) ist die größte britische Militärübungsreihe im Bereich Cybersicherheit, die sich auf die Verteidigung traditioneller IT-Netzwerke, Unternehmensumgebungen und komplexer industrieller Steuerungssysteme in realistischen, anspruchsvollen Szenarien konzentriert. Es demonstriert verantwortungsvolle Cybermacht und verbessert gleichzeitig die Einsatzbereitschaft, Interoperabilität und Widerstandsfähigkeit der Verteidigungskräfte und verbündeter Nationen. Das DCM-Programm, das nun im fünften Jahr läuft, hat sich von einer Initiative der Army Cyber Association zu einer Operation aller drei Teilstreitkräfte unter der Leitung des Cyber and Specialist Operations Command (CSOC) entwickelt.
Die britische Regierung veröffentlichte eine offizielle Pressemitteilung zu DCM26, die einen hervorragenden Überblick über die strategische Bedeutung der Übung bietet. Wie der britische Hochkommissar in Singapur feststellte, demonstriert die Übung die enge Zusammenarbeit zwischen Großbritannien und vertrauenswürdigen Partnern und erinnert an die Stärke gemeinsamer strategischer Partnerschaften in einem zunehmend komplexen Sicherheitsumfeld.
Im Kern ist DCM eine Cyberübung im Force-on-Force-Verfahren: Die verteidigenden Blue Teams schützen ihre zugewiesenen Netzwerke und Infrastrukturen vor den angreifenden Red Teams mithilfe verschiedener Techniken. Die Aktivitäten reichen von der Änderung von Standardpasswörtern und der Härtung von Firewalls bis hin zur Bereitstellung von KI-gestützter Cyberabwehr auf Unternehmensebene mit Elastic Security. Die Aktivitäten jedes Teams werden vom White Team überwacht, um eine Punktzahl zu ermitteln, die Systemverfügbarkeit, Angriffserkennung, Vorfallsmeldung und Systemwiederherstellung berücksichtigt. Es fordert selbst die erfahrensten Teams heraus und bietet gleichzeitig einen einzigartigen Trainingsmechanismus für Nachwuchsteams bei ihrer ersten Begegnung mit einem Cyber-Übungsgelände. Dieser doppelte Zweck macht DCM zu einer so wertvollen Übung.
Der Maßstab von DCM26
DCM26 brachte über 2.500 Personen aus 29 teilnehmenden Ländern und 70 Organisationen zusammen, koordiniert von einer zentralen Übungsleitung (EXCON) mit Sitz in Singapur, wobei EXCON über 600 Teilnehmer betreute. Die Übung fand in einer hybriden Rechenumgebung statt, die sich über die CR14 Cyber Range und AWS erstreckte und mehr als 5.000 virtuelle Systeme beherbergte.
Die Übung selbst erstreckte sich über fünf Tage (9.–13. Februar 2026) und wurde durch optionale, von Ausbildern geleitete Vorschulungen und Verbindungsprüfungen vorbereitet. Das Szenario, das auf der Indo-Pazifik-Einsatzumgebung der Defence Academy (DATE) basierte, versetzte die Teams in die Rolle von Cyber-Schutzteams, die im Verlauf einer eskalierenden regionalen Krise stationierte Militärsysteme verteidigten. Die Blue Teams waren geografisch verteilt, einige an ihren Heimatstandorten in Großbritannien und international, andere im Ausland stationiert, und alle verbanden sich über VPN mit dem Übungsgelände.
Zu den Teilnehmern gehörten Vertreter des britischen Verteidigungsministeriums, ressortübergreifender Behörden wie der National Crime Agency, des Ministeriums für Arbeit und Pensionen, des Kabinettsbüros und des Ministeriums für Wirtschaft und Handel sowie internationaler Partner, die bis zu 40 Teams bildeten. Nach dem Erfolg der letztjährigen Übung in der Republik Korea diente Singapur zum ersten Mal als Übungszentrum und unterstreicht damit das Engagement Großbritanniens für eine vertiefte Zusammenarbeit mit Partnern im Indopazifik bei gemeinsamen Sicherheitsherausforderungen.
Kurz gesagt, es ist eine ernsthafte Angelegenheit. Hoher Druck, Kraft gegen Kraft, mit realen Konsequenzen für die Punktzahl und echten Lernergebnissen für jeden Teilnehmer.
Die Bereitstellungen: Unsere elastische Infrastruktur
Die diesjährige Infrastruktur stellte eine bedeutende architektonische Weiterentwicklung gegenüber früheren Versionen dar. Anstatt für jedes Team einen eigenen Elastic Cloud-Cluster bereitzustellen, sind wir zu einer einzigen, speicherbasierten, mandantenfähigen Elastic Cloud-Bereitstellung für die Blue Teams übergegangen. Wir stellten auch Einsatzmöglichkeiten für Funktionen außerhalb der Blue Teams bereit. Ich werde nun die einzelnen Einsatzbereiche und ihre jeweiligen Existenzgründe erläutern.
Blue Teams: Mandantenfähige, elastische Sicherheit
Das Herzstück unseres Beitrags war eine einzige Elastic Cloud-Bereitstellung, die alle 40 verteidigenden Blue Teams bediente, getrennt durch Kibana Spaces und Datastream-Namespaces. Jedes der 39 Teams verfügte über einen eigenen isolierten Arbeitsbereich mit Dashboards, Agenten und Erkennungsregeln.
So sah die Terraform-Ressource für die Erstellung des jeweiligen Teambereichs aus:
# Create 40 Blue Team spaces
resource "elasticstack_kibana_space" "blue_team" {
count = var.team_count
space_id = local.space_ids[count.index]
name = "Blue Team ${local.team_numbers[count.index]}"
description = "Isolated space for BT-${local.team_numbers[count.index]} with space-aware Fleet visibility"
disabled_features = []
color = "#0077CC"
}Jedem Teambereich stand ein eigener Satz von drei Fleet -Agent-Richtlinien zur Verfügung: am ersten Tag eine Richtlinie für das bereitgestellte Netzwerk, am zweiten Tag eine Richtlinie für das Netzwerk des Gastlandes und schließlich eine PacketCapture-Richtlinie zur Überwachung des Netzwerkverkehrs. Die gestaffelte Zugriffskontrolle war in ihrer Einfachheit elegant: Durch das Setzen enable_hostnation_network = true in unserem terraform.tfvars und das Ausführen von terraform apply wurden die Rollenberechtigungen jedes Teams erweitert und die Agentenrichtlinie des Gastlandes in ihrem Bereich sichtbar gemacht. Die Übung wurde von einem Netzwerk auf zwei erweitert, ohne dass in Kibana ein einziger manueller Klick erforderlich war.
Die Datenisolation basierte auf Datenstrom-Namensräumen. Jede Agentenrichtlinie wird in teamspezifische Namensräume wie bt_01_deployed und bt_01_hostnation geschrieben, wodurch Datenströme nach folgendem Muster erzeugt werden:
logs-system.auth-bt_01_hostnation
logs-system.syslog-bt_01_hostnation
metrics-system.cpu-bt_01_hostnation
logs-endpoint.events.process-bt_01_hostnation
logs-windows.forwarded-bt_01_hostnation
logs-auditd.log-bt_01_hostnationDie Kibana-Sicherheitsrolle jedes Teams wurde anschließend mithilfe dynamischer Indexberechtigungsblöcke auf diejenigen Datenströme beschränkt, die sie umfassten:
# Deployed data streams (always granted)
indices {
names = [
"logs-*-${local.deployed_namespaces[count.index]}",
"metrics-*-${local.deployed_namespaces[count.index]}",
".fleet-*"
]
privileges = ["read", "view_index_metadata"]
}
# HostNation data streams (conditional on enable_hostnation_network)
dynamic "indices" {
for_each = var.enable_hostnation_network ? [1] : []
content {
names = [
"logs-*-${local.hostnation_namespaces[count.index]}",
"metrics-*-${local.hostnation_namespaces[count.index]}"
]
privileges = ["read", "view_index_metadata"]
}
}Die Authentifizierung erfolgte über Keycloak SSO, wobei Elasticsearch-Rollenzuordnungen Keycloak-Gruppen mit Kibana-Rollen verbanden:
resource "elasticstack_elasticsearch_security_role_mapping" "blue_team" {
count = var.team_count
name = "bt-${local.team_numbers[count.index]}-keycloak-mapping"
enabled = true
roles = [
elasticstack_kibana_security_role.blue_team[count.index].name
]
rules = jsonencode({
field = {
groups = "${local.keycloak_groups[count.index]}"
}
})
}Die standardmäßigen Integrationsrichtlinien waren bewusst einfach gehalten. Jedes Team erhielt: System für die Telemetrie des Kernbetriebssystems, Elastic Defend für Endpoint Detection and Response, Windows-Ereignisweiterleitung, Auditd für die Linux-Audit-Protokollierung und Integrationen zur Netzwerkpaketerfassung. Das sind über 400 Integrationsrichtlinien, die als Code über den Elastic Stack Terraform Provider verwaltet werden.
Eine Anmerkung zu Elastic Defend: Aufgrund der Effektivität des Endpunktschutzes von Elastic – auf den das US-Verteidigungsministerium und die US-Nachrichtendienste im Produktiveinsatz vertrauen (lesen Sie hier mehr darüber ) – und der Tatsache, dass niemand bei klarem Verstand Zero-Day-Exploits in einer Übung ausnutzt, sind wir gezwungen, Elastic Defend einzuschränken, indem wir den Prevent-Modus deaktivieren und es im reinen Detect-Modus belassen. Die Teams erhalten Benachrichtigungen, wenn etwas Böswilliges passiert, jedoch ohne automatische Gegenmaßnahmen. Wir deaktivieren außerdem die Speicherbedrohungsprävention und -erkennung vollständig, da diese die meisten Implantate und Beacons des angreifenden Teams aufdeckt, was das Spiel für die roten Teams eher verderben würde. Gegen Ende der Übung haben wir den Teams die Freiheit gegeben, Elastic Defend in vollem Umfang zu nutzen, aber nicht, bevor wir den Red Teams einen starken Fußabdruck verschafft haben.
Wir haben außerdem die vorkonfigurierten Erkennungsregeln von Elastic in jedem Teambereich vorinstalliert – das komplette Set von Elastic Security Labs, das in einem offenen Repository kontinuierlich aktualisiert wird. Diese Regeln wurden eingerichtet, um sicherzustellen, dass nur Indizes abgefragt werden, für die die Namespace-bezogenen Berechtigungen des Teams dies zulassen, wodurch ein teamübergreifendes Datenleck bei der Ausführung von Erkennungsregeln verhindert wird.
Darüber hinaus war in jedem Teambereich der Standardindex der Sicherheitslösung so konfiguriert, dass die Erkennungsregeln nur auf die Datenströme dieses Teams beschränkt waren und nicht auf das standardmäßige breite Muster. Dies wurde durch ein Terraform null_resource erledigt, das die interne Einstellungs-API von Kibana aufrief, um securitySolution:defaultIndex für jeden Bereich festzulegen.
In Spitzenzeiten wurden bei diesem Einsatz 800.000 Ereignisse pro Sekunde (EPS) über alle 40 -Teams hinweg verarbeitet. Das ist eine beachtliche Datenmenge, die der Cluster dank der automatischen Skalierungsfunktionen von Elastic Cloud problemlos bewältigen konnte. Allerdings verzeichneten wir im Jahr 2018 5 Millionen Ereignisse pro Sekunde mit eBay.
Der Datenlebenszyklus wurde durch eine Index Lifecycle Management (ILM)-Richtlinie verwaltet, die Indizes nach einem Tag oder 50 GB (je nachdem, was zuerst eintrat) neu rollte, sie nach zwei Tagen in eine Warmphase zur Optimierung und zum erzwungenen Zusammenführen von Lesedaten versetzte und die Daten nach zehn Tagen löschte. Dadurch konnten die Lagerkosten minimiert werden, während gleichzeitig die Anforderungen an das Übungsfenster eingehalten wurden. Nachfolgend ein Beispiel für die Umsetzung der ILM-Richtlinie.
resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
name = "dcm5-10day-retention"
hot {
min_age = "0ms"
set_priority {
priority = 100
}
rollover {
max_age = "1d"
max_primary_shard_size = "50gb"
}
}
warm {
min_age = "2d"
set_priority {
priority = 50
}
readonly {}
forcemerge {
max_num_segments = 1
}
}
delete {
min_age = "${var.data_retention_days}d"
delete {
delete_searchable_snapshot = true
}
}
}Der Shard-Stresstest: Nachweis der Mandantenfähigkeit in großem Umfang
Bevor wir uns für diese Architektur bei einer militärischen Übung im laufenden Betrieb entscheiden konnten, mussten wir nachweisen, dass sie unseren Anforderungen gerecht wird und im Falle von Problemen über eine geeignete Ausfallsicherung verfügt. Der Übergang von individuellen Bereitstellungen zu einem einzigen mandantenfähigen Cluster brachte reale Risiken mit sich: Ressourcenkonflikte, Engpässe bei der Datenaufnahme, Datenlecks zwischen verschiedenen Bereichen aufgrund von Fehlkonfigurationen, eine große Anzahl von TCP-Verbindungen auf den Elasticsearch-Knoten und eine deutlich größere Anzahl von Shards, da jedes Team seinen eigenen Satz von Indizes generiert.
Deshalb haben wir einen speziellen Testaufbau gebaut. Der Plan war einfach: 50 Kibana Spaces bereitstellen, in jedem Space eine Agentenrichtlinie erstellen, 6.000 EC2-Instanzen starten (120 pro Mandant, verteilt auf sechs Subnetze in drei Verfügbarkeitszonen) und das Ganze einem Lasttest unterziehen. Wir haben alles mit AutoOps und Stack Monitoring überwacht.
Der Bereitstellungsablauf funktionierte folgendermaßen: Terraform erstellte die VPC und Subnetze über drei Verfügbarkeitszonen hinweg, provisionierte die 50 Kibana Spaces und ihre bereichsbezogenen Fleet-Richtlinien, generierte Registrierungstoken und startete dann EC2-Instanzen in Batches. Auf jeder Instanz wurde Elastic Agent beim Systemstart installiert und mit dem jeweiligen bereichsspezifischen Token registriert.
Wir stießen dabei auf einige interessante Herausforderungen. Der standardmäßige Elastic Stack Terraform Provider unterstützte zu diesem Zeitpunkt keine raumbezogenen Fleet-Operationen, daher haben wir ihn geforkt und die Verwaltung von Raum-IDs zu den Fleet-Ressourcen hinzugefügt - ohne diese Änderung hätte sich jeder Agent unabhängig von der Richtlinienzuweisung im Standardraum registriert. Dies war nicht das erste Mal, dass wir den Provider für eine Übung erweitern mussten; vor zwei Jahren hatten wir für DCM2 die Datenquelle elasticsearch_cluster_info hinzugefügt. Glücklicherweise hat der Upstream-Provider support for space_ids inzwischen in Version 0.12.2 hinzugefügt.
Beim Versuch, alle 6.000 Instanzen gleichzeitig zu starten, stießen wir außerdem auf die Ratenbegrenzungen der AWS EC2 API. Daher haben wir die Bereitstellungen in Batches auf 500 Instanzen mit fünfminütigen Abkühlphasen zwischen den Batches aufgeteilt.
Die Ergebnisse waren beruhigend. Alle 6.000 Agenten wurden in der Regel innerhalb von 20 Minuten nach der Bereitstellung registriert. In unseren Tests funktionierte die Raumisolation wie erwartet, ohne dass ein Datenleck zwischen den Mietern beobachtet wurde. Aktualisierungen der Flottenrichtlinien werden innerhalb von 60 Sekunden an alle Agenten weitergegeben. Suchanfragen, die auf einzelne Bereiche beschränkt waren, blieben auch unter Volllast schnell. Und die Multi-AZ-Verteilung erwies sich bei simulierten Ausfällen der Verfügbarkeitszonen als widerstandsfähig.
Diese Tests gaben uns das Vertrauen, uns für die Architektur im Live-Einsatz zu entscheiden.
Rote Teams: C2-Implantat-Beobachtbarkeit
Für die Red Teams wurde eine separate, dedizierte Elastic-Bereitstellung eingerichtet, die sich auf die Beobachtbarkeit von Command-and-Control-(C2)-Implantaten konzentrierte. Dadurch erhielten die angreifenden Teams Einblick in ihre eigenen Operationen, einschließlich Implantatstatus, Beacon-Rückrufe und operativer Fortschritt, ohne dass die Gefahr einer Vermischung mit den Daten des Blue Teams bestand. Die Red Teams nutzten Tuoni als ihre C2-Einheit. Tuoni ist ein Framework, das von Clarified Security für Red Teaming entwickelt wurde. In DCM3 haben wir mit Clarified Security zusammengearbeitet, um sicherzustellen, dass es das Elastic Common Schema ordnungsgemäß unterstützt, was die zukünftige Integration mit Elastic deutlich vereinfacht.
NSOC: Übungszentrum für Netzwerksicherheit
Die Kernübung, das Network Security Operations Centre (NSOC), lief auf einer eigenen Elastic-Bereitstellung und bot dem Übungsleitungspersonal einen umfassenden Überblick über den Zustand des Übungsbereichs, die Sicherheitsüberwachung der gesamten Infrastruktur und, ganz entscheidend, die Protokollierung von Audits für alle von uns eingesetzten KI-Dienste. In dieser Bereitstellung wurde jeder Bedrock-API-Aufruf in CloudWatch protokolliert und war somit beobachtbar. Das NSOC hatte also vollständige Transparenz darüber, was von wem an die KI-Agenten angefordert wurde. Mehr dazu im Abschnitt „KI“ weiter unten.
Infrastrukturautomatisierung: Terraform und Catapult
Alles, was Sie oben gesehen haben, wurde als Infrastructure as Code verwaltet. Unser provider.tf vermittelt einen Eindruck von dem von uns orchestrierten Anbieter-Ökosystem:
terraform {
required_version = ">= 1.5"
required_providers {
elasticstack = {
source = "elastic/elasticstack"
version = "~> 0.13.1"
}
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
vault = {
source = "hashicorp/vault"
version = "~> 3.20"
}
cloudflare = {
source = "cloudflare/cloudflare"
version = "~> 5.15.0"
}
}
backend "s3" {
bucket = "elastic-terraform-state-dcm5"
key = "prod/terraform.tfstate"
region = "eu-west-2"
encrypt = true
}
}Der gesamte Ressourcenbedarf, der von Terraform verwaltet wurde, war beträchtlich: eine Elastic Cloud-Bereitstellung mit Autoscaling, 40 Kibana Spaces, 120 Fleet-Agent-Richtlinien (drei pro Team), über 400 Integrationsrichtlinien, 40 Kibana-Sicherheitsrollen, 40 Keycloak-Rollenzuordnungen, ILM-Richtlinien für die Datenaufbewahrung, 41 AWS IAM-Benutzer für Bedrock GenAI-Konnektoren (einer pro Team-Space plus ein Standardbenutzer), 41 Kibana GenAI-Aktionskonnektoren, AWS Bedrock Guardrails, Cloudflare Zero Trust-Tunnel für den Tines-Zugriff, Tines-Aktionskonnektoren pro Team-Space, in HashiCorp Vault gespeicherte Erkennungsdienstkonten und die Standardindexkonfiguration der Sicherheitslösung pro Space. Alle Statusdaten wurden in einem verschlüsselten S3-Backend gespeichert.
Für die Bereitstellung des Agenten und des Proxys auf den eigentlichen Range-Systemen verwendeten wir Catapult, ein hervorragendes Open-Source-Tool, das vom Team von Clarified Security entwickelt wurde. Catapult kapselt Ansible in ein containerbasiertes Ausführungsmodell ein, das speziell für den Einsatz in Cyber-Range-Umgebungen entwickelt wurde. Es übernahm die Installation und Registrierung von Elastic Agents in der gesamten Infrastruktur. Die Konfiguration der Proxy-Server (jedes Team hatte einen eigenen Squid-Proxy für sein bereitgestelltes Netzwerk; dies sollte einen einzigen Ausgangspunkt simulieren, wie er in der realen Welt vorhanden wäre). Der Datenverkehr wurde über Endpunkte wie http://elastic-proxy.dsoc.XX.dcm.ex:3128 geleitet, und es wurden Cloudflare-Tunnel für die Tines-Konnektivität bereitgestellt.
Während der Bereitstellung wurden folgende Daten von Terraform in HashiCorp Vault geschrieben und von Catapult verwendet: Anmeldeinformationen, Registrierungstoken, API-Schlüssel, Proxy-Konfigurationen, Anmeldeinformationen für das Tines-Dienstkonto. Die Vault-Pfade folgten einer einheitlichen Struktur wie dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed und dcm/gt/elastic/tines-sa/tines-sa-btXX, wodurch es für die Catapult-Playbooks unkompliziert war, die richtigen Anmeldeinformationen für jedes Team abzurufen.
Training: Teams auf den Erfolg vorbereiten
Die Plattform bereitzustellen ist das eine; sicherzustellen, dass die Leute sie auch tatsächlich nutzen können, ist etwas ganz anderes. Wir haben den Blue Teams während der Vorbereitungsphase ein Training auf dem Übungsgelände unter Anleitung von Ausbildern angeboten. Dies umfasste die Grundlagen von Elastic Security , die Navigation im Teambereich in Kibana, die Arbeit mit den vordefinierten Erkennungsregeln, die Verwendung von Discover für die Protokollanalyse und die Bedrohungssuche, das Erstellen benutzerdefinierter Dashboards, das Verständnis von Elastic Defend-Warnungen und die Vertrautmachung mit dem Timeline-Untersuchungstool.
In der Übungsanleitung selbst wurde darauf hingewiesen, dass dieses Training zwar optional, aber „dringend empfehlenswert“ sei, und nach dem, was wir gesehen haben, legten die teilnehmenden Teams am ersten Tag der Übung einen fulminanten Start hin. Schulung und Befähigung sind genauso wichtig wie der Technologieeinsatz selbst. Einem Team Sicherheitstools auf Unternehmensebene zur Verfügung zu stellen, mit denen es nicht umgehen kann, wäre für niemanden hilfreich gewesen.
Der On-Range AI-Service: Konform, geprüft, mit Leitplanken versehen
In diesem Jahr haben wir erstmals KI-Zugriff auf die DCM-Produktpalette angeboten. Wir haben einen konformen KI-Service direkt auf der Teststrecke bereitgestellt, der auf in Großbritannien gemieteten AWS Bedrock-Modellen basiert – genauer gesagt auf Claude 3.7 Sonnet, das in der Region eu-west-2 (London) läuft. Hierbei handelte es sich nicht um KI um der KI willen, sondern um einen sorgfältig konzipierten Dienst mit Schutzmechanismen, vollständiger Protokollierung und rollenbasierten Zugriffskontrollen. Aufgrund der Erfahrung von Elastic im Bereich der künstlichen Intelligenz wurde uns die Durchführung dieses Dienstes anvertraut.
Der KI-Dienst hatte mehrere Kunden auf der Produktpalette, und dies ist ein wichtiger Unterschied. Der kompatible Bedrock-Connector, den wir in den jeweiligen Team-Bereichen bereitgestellt haben, trieb nicht nur unsere benutzerdefinierten Agenten an, sondern auch die nativen KI-Funktionen von Elastic, insbesondere:
Elastic AI Assistant für Security
Der Elastic AI Assistant war in jedem Blue Team-Bereich verfügbar und mit unserem On-Range Bedrock Connector verbunden. Dadurch erhielten die Teams eine kontextbezogene Chat-Oberfläche direkt innerhalb von Elastic Security, über die sie Fragen zu ihren Warnmeldungen stellen, Hilfe beim Schreiben von ES|QL-Abfragen erhalten, verdächtige Prozesse untersuchen und Anleitungen zu Abhilfemaßnahmen erhalten konnten. Der KI-Assistent nutzt Retrieval-Augmented Generation (RAG) mit der Knowledge Base-Funktion von Elastic, die mit Artikeln aus den Elastic Security Labs vorausgefüllt ist. Teams können der Wissensdatenbank auch eigene Dokumente hinzufügen, wie zum Beispiel bereichsspezifische Standardarbeitsanweisungen, Bedrohungsinformationen oder Teamnotizen, um die Antworten des Assistenten noch stärker in ihren operativen Kontext einzubetten.
Besonders wertvoll im Kontext der Übung war die Fähigkeit des KI-Assistenten, weniger erfahrenen Analysten zu helfen, zu verstehen, was sie da sahen. Ein junger Analyst, der zum ersten Mal mit einem aktiven Implantat-Beacon konfrontiert wird, könnte den Assistenten bitten, die Warnung zu erklären, Untersuchungsschritte vorzuschlagen und sogar beim Verfassen des Vorfallberichts zu helfen. Die Einstellungen zur Datenanonymisierung stellten sicher, dass sensible Feldwerte vor der Übermittlung an den LLM-Anbieter verschleiert werden konnten.
Erkennung elastischer Angriffe
Attack Discovery war ein weiterer bedeutender Abnehmer unseres On-Range-KI-Dienstes. Attack Discovery nutzt LLMs, um Warnmeldungen in der Umgebung eines Teams zu analysieren und Bedrohungen zu identifizieren, indem Warnmeldungen, Verhaltensweisen und Angriffspfade korreliert werden. Jede „Entdeckung“ stellt einen potenziellen Angriff dar und beschreibt Beziehungen zwischen mehreren Warnmeldungen – sie informiert die Teams darüber, welche Benutzer und Hosts beteiligt sind, wie die Warnmeldungen der MITRE ATT&CK-Matrix zugeordnet werden und welcher Bedrohungsakteur möglicherweise verantwortlich ist.
Für eine Cyberübung, bei der Red Teams aktiv koordinierte Angriffe durchführten, war Attack Discovery von grundlegender Bedeutung. Anstatt Hunderte einzelner Warnmeldungen manuell zu priorisieren, könnten Blue Teams Attack Discovery einsetzen, um die übergeordneten Angriffsmuster zu ermitteln, zum Beispiel: „Diese 15 Warnmeldungen sind alle Teil einer lateralen Bewegungskette von Host X zu Host Y, wahrscheinlich durch Bedrohungsakteur Z“, und ihre Untersuchungszeit dort konzentrieren, wo es am wichtigsten ist. Es handelt sich um eine Fähigkeit, die die mittlere Reaktionszeit direkt verkürzt und der Alarmmüdigkeit entgegenwirkt, was genau das ist, was man braucht, wenn man fünf Tage lang ununterbrochen einem anhaltenden Angriff ausgesetzt ist.
Die benutzerdefinierten KI-Agenten: Elastic Agent Builder
Über die nativen Elastic AI-Funktionen hinaus haben wir mit dem Elastic Agent Builder drei maßgeschneiderte KI-Agenten entwickelt. Agent Builder ist das Framework von Elastic zum Erstellen kundenspezifischer KI-Agenten, die LLM-Anweisungen mit modularen, wiederverwendbaren Tools kombinieren. Jedes Tool ist eine ES|QL-Abfrage, eine integrierte Suchfunktion, eine Workflow-Ausführung oder eine externe Integration über MCP. Agenten analysieren Anfragen in natürlicher Sprache, wählen die passenden Tools aus, führen sie aus und wiederholen den Vorgang, bis sie eine vollständige Antwort liefern können. Dabei verwalten sie stets den Kontext mit Daten innerhalb von Elasticsearch. Mehr über das Framework erfahren Sie in der Agent Builder-Dokumentation und im Elasticsearch Labs Deep Dive.
Die drei wichtigsten Komponenten von Agent Builder, die wir genutzt haben, waren:
Agenten: Individuelle LLM-Anweisungen und eine Reihe zugewiesener Tools, die die Persona, die Fähigkeiten und die Verhaltensgrenzen des Agenten definieren. Jeder Agent verfügt über eine Systemaufforderung, die seine Mission, die ihm zur Verfügung stehenden Werkzeuge und die Struktur seiner Antworten steuert.
Tools: Modulare Funktionen, die Agenten zum Suchen, Abrufen und Bearbeiten von Elasticsearch-Daten verwenden. Wir haben maßgeschneiderte ES|QL-Tools entwickelt, die spezifische Indizes abfragen, welche Übungsdokumentationen, Playbooks und Berichte enthalten.
Agenten-Chat: Die Konversationsschnittstelle – sowohl die integrierte Kibana-Benutzeroberfläche als auch die programmatische API –, die die Teilnehmer zur Interaktion mit den Agenten nutzten.
Agenten- und Tool-Konfigurationen werden als JSON definiert und über die Agent Builder APIs verwaltet. Dadurch ist der gesamte Agentenlebenszyklus – von der Prompt-Erstellung bis zur Tool-Anbindung – reproduzierbar und versionskontrollierbar. In einem Folgebeitrag stellen wir die GrantPT-Agentenkonfiguration und die Tool-Definitionen für alle vor, die diesen Ansatz nachbilden möchten – bleiben Sie gespannt.
Folgendes hat jeder Agent getan:
1. GrantPT – Der Allzweckassistent
GrantPT stand allen rund 2.500 Übungsteilnehmern zur Verfügung und war unser primärer KI-Agent sowie die beste Demonstration dafür, wie einfach es mit Agent Builder ist, einen leistungsfähigen, domänenspezifischen Assistenten zu erstellen. Die Konfiguration des Agenten bestand aus einem JSON-Objekt, das seine Systemansage, seine Persona und ein Array von gebundenen Tool-IDs definierte – das war alles. Kein kundenspezifischer Anwendungscode, keine maßgeschneiderte API-Schicht, nur deklarative Konfiguration.
Die Stärke von GrantPT lag in den Werkzeugen. Wir haben eine Mischung aus integrierten Plattform-Tools und benutzerdefinierten ES|QL-Tools definiert, die jeweils mit einer Beschreibung, einer parametrisierten Abfrage und typisierten Parameterdefinitionen registriert sind. Das Wissensdatenbank-Tool akzeptierte beispielsweise einen target_index und einen semantischen query -Parameter und führte eine parametrisierte ES|QL-Abfrage gegen unsere dcm5-grantpt-* -Indizes mit semantischer Suchrangfolge aus:
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10Ein separates Indexfindungstool ermöglichte es dem Agenten, zu Beginn jeder Konversation dynamisch die verfügbaren Wissensbasisindizes aufzulisten. Das bedeutete, dass wir während der Übung neue Dokumentationsindizes hinzufügen konnten, ohne den Agenten neu konfigurieren zu müssen; er würde sie einfach bei der nächsten Interaktion entdecken.
Wir haben außerdem ein Jira-Integrationstool entwickelt, das eine semantische Suche in den erfassten Helpdesk-Tickets durchführt und GrantPT so ermöglicht, relevante Kontextinformationen zur Fehlerbehebung aus früheren Supportanfragen abzurufen. Dies war besonders nützlich für die Helpdesk-Analysten, die GrantPT zu wiederkehrenden Problemen befragen konnten und Antworten erhielten, die auf der tatsächlichen Tickethistorie basierten und nicht auf allgemeinen Hinweisen.
Das RBAC-basierte Antwortverhalten resultierte aus einer Kombination aus der Systemaufforderung des Agenten, die ihn anwies, Antworten basierend auf der Rolle des Benutzers zu kontextualisieren, und dem zugrunde liegenden Elasticsearch-Sicherheitsmodell. Da die ES|QL-Abfrage jedes Tools im Sicherheitskontext des Benutzers ausgeführt wird, kann der Agent nur Dokumente anzeigen, auf die der Benutzer Zugriff hat. Ein Mitglied des Blue Teams, das Fragen zu Übungsverfahren stellt, erhält Ergebnisse, die auf die für sein Team zugänglichen Indizes beschränkt sind, während ein Helpdesk-Analyst Ergebnisse aus helpdeskspezifischen Indizes sieht. Der Agent benötigte keine explizite Logik zum Rollenwechsel; die native Dokumentensicherheit von Elasticsearch übernahm die Bereichsbegrenzung, und der Agent arbeitete einfach mit den zurückgegebenen Ergebnissen. Dies ist einer der Gründe, warum Agent Builder wirklich elegant ist – durch die Übernahme des Sicherheitsmodells von Elasticsearch erhält man RBAC-fähige KI, ohne eine einzige Zeile Autorisierungscode schreiben zu müssen.
2. REDRock – Der Begleiter des Gegners
Dieser Agent stand ausschließlich Red Teams zur Verfügung. REDRock folgte dem gleichen Agent Builder-Muster, einer dedizierten Systemaufforderung, die seine gegnerische Persona definierte, gebunden an einen eigenen Satz von benutzerdefinierten ES|QL-Tools, die Red Team-spezifische Indizes abfragen. Diese Indizes enthielten die Playbooks des Red Teams, die Tuoni C2-Dokumentation, bekannte Systemschwachstellen innerhalb der Range-Umgebung sowie Informationen über die eingesetzten Dienste. Die Werkzeugdefinitionen spiegelten das gleiche parametrisierte semantische Suchmuster wider, das von GrantPT verwendet wurde, waren aber auf Indizes beschränkt, die nur für Red-Team-Rollen zugänglich waren. Die Red-Team-Operatoren könnten Angriffsvektoren abfragen, nach bekannten Schwachstellen in Zielsystemen suchen und kontextbezogene Hinweise zu ihren Einsatzplänen erhalten. Es war, ehrlich gesagt, so, als ob man den Angreifern einen extrem gut informierten Einsatzleiter zur Verfügung gestellt hätte.
3. RefPT – Das Schiedsrichterwerkzeug
RefPT wurde speziell für das White Team (die Übungsschiedsrichter und -beurteiler) entwickelt und war an Tools gebunden, die Indizes abfragten, welche Berichte des Blue Teams, Szenarioereignisse und die Bewertungskriterien enthielten. Ziel war es, eine einheitliche und faire Punktevergabe für alle über 40 Mannschaften zu gewährleisten. Die Systemabfrage des Agenten wurde so eingestellt, dass die eingereichten Berichte mit bekannten Szenarioereignissen und Bewertungskriterien abgeglichen werden konnten, um den Gutachtern zu helfen, Unstimmigkeiten oder Lücken zu erkennen. Wenn Gutachter Dutzende von Teams gleichzeitig bewerten, ist eine KI, die Berichte mit einem strukturierten Bewertungsindex korrelieren kann, wahrlich revolutionär für die Konsistenz.
Tines: KI-gestützte Workflow-Automatisierung
Tines nutzte auch den KI-Service auf der Weide. Jedes Blue Team verfügte über eine eigene Tines-Instanz, in deren Kibana-Bereich Tines-Aktionskonnektoren bereitgestellt waren. Tines könnte die von Bedrock unterstützten KI-Funktionen für die intelligente Workflow-Automatisierung nutzen, wie z. B. die automatisierte Anreicherung von Warnmeldungen, KI-gestützte Triage-Entscheidungen, Zusammenfassungen in natürlicher Sprache in Benachrichtigungs-Workflows und die Erstellung von Workflows in natürlicher Sprache. Der Tines-Connector wurde teamweise mit in Vault gespeicherten Anmeldeinformationen konfiguriert:
resource "elasticstack_kibana_action_connector" "tines_bt" {
count = var.team_count
name = "BT-${local.team_numbers[count.index]}-Tines"
connector_type_id = ".tines"
space_id = local.space_ids[count.index]
config = jsonencode({
url = "https://tines.dsoc.${local.team_numbers[count.index]}.dcm.ex/"
})
}Sicherstellung der Einhaltung von Vorschriften: Leitplanken und Audit
Jede KI-Interaktion mit all diesen Konsumenten unterlag den strengen AWS Bedrock Guardrails. Wir haben Schutzmechanismen mit Inhaltsfilterung (Hass, Beleidigungen, sexuelle Inhalte und Gewalt bei mittleren Schwellenwerten), Schutz personenbezogener Daten (Sperrung von E-Mail-Adressen, Telefonnummern, Namen, Adressen, britischen Sozialversicherungsnummern, Kreditkartennummern und IP-Adressen), themenbasierter Filterung zur Verhinderung von Diskussionen über tatsächliche geheime Operationen und Schimpfwortfilterung eingesetzt. Hier ein Ausschnitt der Leitplankenkonfiguration aus unserem Terraform-Skript:
resource "aws_bedrock_guardrail" "dcm5_elastic" {
name = "dcm5-prod-elastic-guardrail"
description = "Guardrails for DCM5 Prod Elastic Kibana GenAI connectors"
content_policy_config {
filters_config {
input_strength = "MEDIUM"
output_strength = "MEDIUM"
type = "HATE"
}
# ... additional content filters for INSULTS, SEXUAL, VIOLENCE
}
sensitive_information_policy_config {
pii_entities_config {
action = "BLOCK"
type = "UK_NATIONAL_INSURANCE_NUMBER"
}
pii_entities_config {
action = "BLOCK"
type = "IP_ADDRESS"
}
# ... additional PII filters
}
topic_policy_config {
topics_config {
name = "classified-information"
definition = "Discussions about actual classified operations, current real-world military activities, or operational intelligence."
type = "DENY"
}
}
}Jeder Blue-Team-Bereich hatte seinen eigenen IAM-Benutzer für den Bedrock-Zugriff, und die Kibana-Einstellung genAiSettings:defaultAIConnectorOnly wurde erzwungen, um zu verhindern, dass Teams ihre eigenen Konnektoren konfigurieren. Dies bedeutete, dass jeder einzelne API-Aufruf über CloudWatch zu einem bestimmten Team zurückverfolgt werden konnte und das NSOC über vollständige Transparenz bei den Audits verfügte. Die CloudWatch-Protokollgruppe /aws/bedrock/grantpt-prod/invocations erfasste jedes Aufruf- und Schutzmaßnahmenereignis.
Die Zahlen für alle KI-Konsumenten sprechen für sich: 3 benutzerdefinierte KI-Agenten, 2.797 Konversationen und 785 Millionen verbrauchte KI-Token während der gesamten Übung.
Echtzeitüberwachung im Spiel
Im Rahmen des Übungsszenarios hatte jedes Team Zugriff auf RocketChat als Messaging-Client für den Übungsbereich. Jedes Blue Team erhielt einen eigenen Kanal, die Möglichkeit, jeden Teilnehmer der Übung per Direktnachricht zu kontaktieren, und die Freiheit, bei Bedarf neue Kanäle zu erstellen. Besonders wichtig für die DCM-Tradition war dabei der Meme-Kanal – das spirituelle Rückgrat aller teaminternen Neckereien und des kreativen, moralstärkenden Humors, der unweigerlich entsteht, wenn man ein paar tausend Cyber-Operatoren eine Woche lang unter Druck setzt.
Diese Kommunikationsdaten boten einen hervorragenden Einblick in den Zustand des Übungsgeländes, die Stimmung im Team und die Themen, die während der Übung im Trend lagen. Das Angebot war zu verlockend, um es zu verpassen, also haben wir den gesamten RocketChat-Konversationskorpus in Echtzeit in Elastic importiert und ihn zum Einsatz gebracht.
Stimmungsanalyse und Erkennung benannter Entitäten
Für die Erkennung benannter Entitäten haben wir das dslim/bert-base-NER- Modell von Hugging Face mithilfe des Elastic ELAND-Clients in einen Machine-Learning-Knoten der NSOC-Bereitstellung implementiert. Dies wurde dann in eine Elasticsearch-Ingest-Pipeline eingebunden, die jede RocketChat-Nachricht beim Einlesen durchlief. Wir haben die extrahierten Entitäten genommen und die häufigsten als Dashboard-Themen dargestellt, wodurch wir einen Live-Überblick über den Verlauf der Gesprächsthemen während der Übung erhalten.
Wir analysierten außerdem die Gruppenaktivität, Nutzerstatistiken und allgemeine Kommunikationsmuster, um ein Bild der Lebensmuster jedes Teams zu erstellen – die aktivsten Teilnehmer, das Nachrichtenvolumen im Laufe der Zeit und die von einzelnen Nutzern beeinflussten Stimmungstrends. Alles in allem hat es uns einige wirklich interessante Einblicke in das Geschehen auf dem Schießstand in nahezu Echtzeit gegeben. Als wir beispielsweise Elastic Agent in den Prevent-Modus schalteten, leuchtete sofort eine Wortwolke auf unserem Dashboard auf, in der "Elastic" als das meistdiskutierte Thema über alle Kanäle hinweg auftauchte – Blue Teams diskutierten über seine Effektivität, Red Teams beklagten den Verlust ihrer Beacons. Das ist durchaus befriedigend.
Meme-Analyse (ja, wirklich)
Schließlich – und das sorgte für einige Verwunderung – haben wir alle an die Kanäle übermittelten Memes gesammelt, die Bilder vektorisiert und Nearest-Neighbor-Analysen durchgeführt, um ähnliche Memes und Themen zu gruppieren. Wir haben sie außerdem durch das Zero-Shot-NER-Inferenzmodell geleitet, um thematische Beschreibungen des Inhalts jedes Memes zu generieren. Die Logik dahinter war, dass diese Ausgaben später für Filterung, Moderation oder andere Interaktionen im Spiel nützlich sein könnten. Ob die Meme-Analyse operativ kritische Erkenntnisse lieferte, ist fraglich. Ob es ein großer Spaß war, ist nicht bekannt.
Probleme im Keim ersticken
So sehr wir auch gehofft hatten, dass während der Übungswoche alles reibungslos verlaufen würde, geht doch unweigerlich etwas kaputt, wird nicht vollständig verstanden oder muss noch weiter angepasst werden, damit es den Bedürfnissen eines bestimmten Teams entspricht. Hierfür hatten wir einen eigenen Unterbereich des In-Range-Helpdesks, in dem Elastic- und GenAI-spezifische Anfragen von jedem Team gestellt werden konnten.
Wir haben diesen Helpdesk während der gesamten Übungsdauer besetzt und Anleitungen, Dokumentationen, Fehlerbehebung und bereichsspezifische Empfehlungen bereitgestellt. Dieser letzte Punkt verdient eine nähere Erläuterung. Manchmal handelte es sich bei dem, was ein Blue Team in Elastic sah, gar nicht um ein Problem von Elastic, sondern vielmehr um etwas, das Elastic getreu auf dem Schießstand anzeigte und das eine weitere Untersuchung rechtfertigte (Red Teams können absolutes Chaos anrichten, und die Telemetrie lügt nicht). Im Laufe der Übung bearbeiteten wir 125 individuelle Supportanfragen von Teams, die ausdrücklich um Hilfe von uns bei Elastic baten.
Präventives Debugging mit Tines
Neben den Besuchen bei Teams per Videokonferenz oder persönlich auf der EXCON-Konferenz haben wir auch mit Tines zusammengearbeitet, um etwas proaktiver vorzugehen. Wir haben den Tickettext aus eingehenden Anfragen extrahiert, versucht, das Problem zu kategorisieren, die Kategorisierung mit unserem Korpus zuvor gelöster Tickets abgeglichen und GenAI eine zusammenfassende erste Antwort erstellen lassen, die darauf abzielte, das Problem des Benutzers zu lösen, bevor die Triage es in unsere Warteschlange brachte.
Dies ist eigentlich ein Muster, das wir von unserer eigenen Supportorganisation bei Elastic übernommen haben, wo wir eine ähnliche Funktionalität anbieten, indem wir unsere umfangreiche Wissensdatenbank mit zuvor gelösten Problemen als Repository für den unterstützenden Kontext von KI-Agenten nutzen. Die Idee ist einfach: Man nutzt vergangene Lösungen, um einen maschinell generierten, fundierten ersten Lösungsansatz für ein Problem zu erstellen und so die Notwendigkeit zu umgehen, dass ein Support-Techniker jedes Ticket manuell bearbeiten muss. Es hat nicht alles gelöst; für manche Probleme war tatsächlich ein Mensch mit Kontextwissen erforderlich, aber es hat den Druck auf die Warteschlange deutlich verringert und den Teams, die Antworten benötigten, schnellere Lösungen geliefert. Dies war mit unseren eigenen Tickets und unserer Warteschlange ein solcher Erfolg, dass wir im späteren Verlauf der Übung den Aufgabenbereich auf den gesamten Helpdesk ausweiteten, wodurch die Belastung der anderen Gruppen im Green Team, die die Übung unterstützten, reduziert wurde.
Branchenpartnerschaften: Gemeinsam sind wir stärker
Eines der Dinge, auf die wir besonders stolz sind, ist das kontinuierliche Wachstum unseres Partnernetzwerks. DCM ist nicht einfach nur eine Elastic-Messe; es ist eine echte Koalition von Industriepartnern, von denen jeder etwas Einzigartiges zur Sicherheitsplattform beiträgt.
Jahr 1 (DCM2) – Elastic trat als Industriepartner bei und stellte die Plattform für Sicherheitsüberwachung und Endpunkterkennung bereit.
Jahr 2 (DCM3) - Wir haben Endace eingeführt, das eine 1:1-Paketerfassungsfunktion bietet. Die vollständige Paketerfassung in Verbindung mit der Netzwerktransparenz von Elastic gab den Teams die Möglichkeit, tiefgreifende forensische Untersuchungen durchzuführen, die mit einer rein protokollbasierten Analyse nicht möglich sind.
Jahr 3 (DCM4) – Tines stieß zur Familie hinzu und brachte die Workflow-Automatisierung mit ein. Blue Teams können nun automatisierte Reaktions-Playbooks, Triage-Workflows und Benachrichtigungsketten erstellen, die alle über den nativen Tines-Connector direkt in ihre Elastic-Umgebung integriert sind.
Jahr 4 (DCM26, ehemals DCM5) – AWS stieg ein und stellte Bedrock-Zugriff für unsere KI-Agenten bereit sowie beteiligte sich an der Finanzierung der Elastic-Implementierungen. Dies war ein bedeutender Meilenstein; die direkte Beteiligung eines Hyperscalers am Erfolg der Übung ermöglichte den Zugang zu Fähigkeiten (wie z. B. konforme, in Großbritannien gemietete KI-Inferenz mit vollständigen Schutzmechanismen und Audit-Protokollierung), die sonst schlichtweg nicht möglich gewesen wären. Die Integration von Tines wurde in diesem Jahr auch durch die Hinzunahme des Zugangs zu LLMs direkt auf dem Schießstand verbessert. Die DCM-Serie erreichte in diesem Jahr ebenfalls einen Meilenstein: Sie wandelte sich von einer Initiative der Army Cyber Association zu einem offiziell finanzierten Programm unter dem Cyber and Specialist Operations Command.
Den Teams von Endace, Tines und AWS ein herzliches Dankeschön. Diese Übung ist dank Ihrer Beiträge besser geworden, und alle Teams sind dank der gemeinsam entwickelten Plattform besser gerüstet. Wir planen bereits für DCM27. Ein Hoch auf euch alle!
Kultur, Höhepunkte und die Details, die es lohnenswert machen
Die Challenge Coins
Wir ließen für DCM26 spezielle Erinnerungsmünzen prägen. Kenner wissen, dass Challenge Coins eine langjährige militärische Tradition sind, und die Anfertigung einer solchen Münze für die Übung erschien uns als der richtige Weg, unser viertes Jahr der Teilnahme zu würdigen.
Die Cocktailparty
Wir haben uns außerdem sehr über die Einladung zum Cocktail-Empfang der britischen Hochkommission in Singapur gefreut. Es hat etwas ziemlich Surreales, über Elasticsearch-Shard-Zähler und Terraform-Zustandsverwaltung zu diskutieren, während man auf Einladung des Botschafters einen Gin Tonic genießt. Es war ein brillanter Abend, eine echte Erinnerung daran, dass diese Übungen an der Schnittstelle von Technologie und Diplomatie stattfinden und dass die hier geknüpften Beziehungen weit über das Technische hinausgehen.
Wrapping up
Die mandantenfähige Architektur bewährte sich unter Dauerlast; die nativen Elastic AI-Funktionen (AI Assistant und Attack Discovery) gaben den Teams Möglichkeiten, die vor wenigen Jahren noch Science-Fiction gewesen wären; und die benutzerdefinierten KI-Agenten übertrafen unsere Erwartungen hinsichtlich der Akzeptanz. Das Partnerschaftsmodell beweist immer wieder, dass die Beteiligung der Industrie an Verteidigungsübungen Ergebnisse hervorbringt, die keine einzelne Organisation allein erreichen könnte.
Defence Cyber Marvel 2026 war eine wegweisende Iteration einer Übung, die hinsichtlich Anspruch, Komplexität und Wirkung stetig wächst. Für Elastic ist es eine große Ehre, das Vertrauen zu genießen, die zentrale defensive Sicherheitsplattform für 40 Blue Teams aus 29 Nationen bereitzustellen, und in diesem Jahr auch die KI-Fähigkeit. Die Übung vermittelt echte Fähigkeiten für echte Menschen, die später echte Netzwerke verteidigen werden, und die Teilnahme an dieser Mission ist wirklich sinnvoll.
Wie die britische Regierung in ihrer Pressemitteilung ausführt, demonstriert DCM den praktischen Nutzen realer Szenarien, die internationale Partnerschaften stärken. Dem können wir nur voll und ganz zustimmen.
Wir kommen nächstes Jahr wieder, und ich vermute, wir werden dann noch mehr zu besprechen haben. In der Zwischenzeit werden wir das Produkt weiter verbessern, damit die Unterstützung für Umgebungen wie Defence Cyber Marvel von Jahr zu Jahr herausragend wird.
Wir sehen uns auf dem Schießstand.
Verfolgen Sie die Geschichte von DCM26 in den sozialen Medien:
Facebook | LinkedIn | Instagram
Weitere Lektüre
Elastische Sicherheit und KI
- Elastic Security – Die Plattform, die die Blue-Team-Einsätze unterstützt
- KI-Assistent für Sicherheit – Kontextsensitiver KI-Chat innerhalb von Elastic Security
- Angriffserkennung – LLM-gestützte Alarmkorrelation und Generierung von Bedrohungsberichten
- Agent Builder – Framework zum Erstellen benutzerdefinierter KI-Agenten mit Elasticsearch
Infrastruktur & Werkzeuge
- Elastic Stack Terraform Provider – Infrastruktur als Code für den Elastic Stack
- Elastic Fleet Guide – Zentrale Verwaltung von Elastic Agents in großem Umfang
- Catapult von Clarified Security – Ansible-basierte Bereitstellung von Cyber-Ranges
Übungskontext
- Pressemitteilung der britischen Regierung zu DCM26 – Offizieller Überblick über die Übung