Blog

Elastic auf der Defence Cyber Marvel 2026: Ein technischer Überblick aus dem Übungsbereich

Ein Überblick über die Elastic Security- und KI-Infrastruktur, die zur Unterstützung der Flaggschiff-Cyberübung des britischen Verteidigungsministeriums, Defence Cyber Marvel 2026, bereitgestellt wurde.

James Garside
SecOps

Wo Sie anfangen können. Im vierten Jahr in Folge hatte Elastic das Privileg, als vertrauenswürdiger Industriepartner an der Exercise Defence Cyber Marvel mitzuwirken – der wichtigsten Cyber-Übungsreihe des britischen Verteidigungsministeriums. DCM26 war zweifellos die bisher ambitionierteste Iteration, und wir freuen uns riesig, endlich darüber sprechen zu können, was wir entwickelt haben, wie wir es entwickelt haben und was wir dabei gelernt haben.

Was ist Defence Cyber Marvel?

Für alle, denen sie noch nicht vertraut ist: Defence Cyber Marvel (DCM) ist die größte militärische Cyber-Übungsreihe des Vereinigten Königreichs, die sich auf die Verteidigung herkömmlicher IT-Netzwerke, Unternehmensumgebungen und komplexer industrieller Steuerungssysteme in realistischen Szenarien unter hohem Druck konzentriert. Sie demonstriert verantwortungsvolle Cyber-Macht und stärkt gleichzeitig die Bereitschaft, Interoperabilität und Resilienz im gesamten Verteidigungsbereich sowie bei verbündeten Nationen. Mittlerweile im fünften Jahr hat sich DCM von einer Initiative der Army Cyber Association zu einer teilstreitkraftübergreifenden Operation entwickelt, die vom Cyber and Specialist Operations Command (CSOC) geleitet wird.

Die britische Regierung hat eine offizielle Pressemitteilung zu DCM26 veröffentlicht, die einen hervorragenden Überblick über die strategische Bedeutung der Übung bietet. Wie der britische Hochkommissar in Singapur anmerkte, zeigt die Übung die enge Zusammenarbeit zwischen dem Vereinigten Königreich und vertrauenswürdigen Partnern – eine Erinnerung an die Stärke gemeinsamer strategischer Partnerschaften in einer zunehmend komplexen Sicherheitslandschaft.

Im Kern ist DCM eine Force-on-Force-Cyberübung: Die verteidigenden Blue Teams schützen ihre zugewiesenen Netzwerke und ihre Infrastruktur mit einer Reihe von Techniken vor den angreifenden Red Teams. Die Aktivitäten reichen von der Änderung von Standard-Passwörtern und der Härtung von Firewalls bis hin zur Bereitstellung einer KI-gestützten Cyberabwehr für Großunternehmen mit Elastic Security. Die Aktivitäten jedes Teams werden vom White Team überwacht, um eine Punktzahl zu ermitteln, die Systemverfügbarkeit, Angriffserkennung, Incident-Berichterstattung und Systemwiederherstellung berücksichtigt.. Sie fordert selbst die erfahrensten Teams heraus und bietet gleichzeitig einen einzigartigen Trainingsmechanismus für Nachwuchsteams bei ihrer ersten Berührung mit einer Cyber Range – und dieser doppelte Zweck macht DCM zu einer so wertvollen Übung.

Der Maßstab von DCM26

DCM26 brachte über 2.500 Einsatzkräfte aus 29 teilnehmenden Ländern und 70 Organisationen zusammen. Die Koordinierung erfolgte durch eine zentrale, in Singapur ansässige Übungsleitung (EXCON), an der über 600 Teilnehmende beteiligt waren. Die Übung lief in einer hybriden Computing-Umgebung, die sich über die CR14-Cyber-Range und AWS erstreckte und mehr als 5.000 virtuelle Systeme umfasste.

Die Übung selbst erstreckte sich über fünf Durchführungstage (9.–13. Februar 2026), denen ein optionales kursleitergeführtes Vorbereitungstraining und Konnektivitätsprüfungen vorausgingen. Das Szenario, das auf der Defence Academy Training Environment (DATE) Indo-Pacific Operating Environment aufbaute, versetzte die Teams in die Rolle von Cyber Protection Teams, die während einer eskalierenden regionalen Krise im Einsatz befindliche Militärsysteme verteidigten. Die Blue Teams waren geografisch verteilt – einige an ihren Heimatstandorten in ganz Großbritannien und international, andere im Ausland im Einsatz –, wobei sich alle über ein VPN mit der Range verbanden.

Zu den Teilnehmenden gehörten Vertreter von UK Defence, ressortübergreifenden Behörden wie der National Crime Agency, dem Department for Work and Pensions, dem Cabinet Office und dem Department for Business and Trade sowie internationale Partner, die bis zu 40 Teams bildeten. Nach dem Erfolg der letztjährigen Übung in der Republik Korea diente Singapur erstmals als Übungszentrum, was das Engagement des Vereinigten Königreichs für eine Vertiefung der Zusammenarbeit mit Partnern im indopazifischen Raum bei gemeinsamen Sicherheitsherausforderungen widerspiegelt.

Kurz gesagt, es ist eine ernsthafte Übung. Unter hohem Druck und im direkten Gegeneinander, mit realen Konsequenzen für die Bewertung und echten Lernergebnissen für alle Teilnehmenden.

Die Deployments: Unsere Elastic-Infrastruktur

Die Infrastruktur dieses Jahres stellte gegenüber früheren Iterationen eine bedeutende architektonische Weiterentwicklung dar. Statt einzelne Elastic Cloud-Cluster pro Team bereitzustellen, wechselten wir für die Blue Teams zu einem einzigen mandantenfähigen, raumbasierten Elastic Cloud-Deployment. Wir stellten außerdem Deployments für Funktionen außerhalb der Blue Teams bereit. Lassen Sie mich jedes Deployment und den Grund für seine Existenz erläutern.

Blue Teams: Elastic Security für mehrere Mandanten

Das Herzstück unseres Beitrags war ein einzelnes Elastic Cloud-Deployment, das alle 40 verteidigenden Blue Teams versorgte, getrennt durch Kibana Spaces und Datastream-Namespaces. Jedes der 39 Teams verfügte über einen eigenen, isolierten Arbeitsbereich, einschließlich Dashboards, Agents und Erkennungsregeln.

So sah die Terraform-Ressource zum Erstellen des Bereichs für jedes Team aus:

# 40 Blue-Team-Spaces erstellen
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 = "Isolierter Space für BT-${local.team_numbers[count.index]} mit Fleet-Sichtbarkeit mit Space Awareness"

  disabled_features = []
  color             = "#0077CC"
}

Der Space jedes Teams erhielt ein eigenes Set von drei Fleet Agent-Richtlinien: an Tag 1 eine Deployed-Netzwerkrichtlinie, an Tag 2 eine Host-Nation-Netzwerkrichtlinie und schließlich eine PacketCapture-Richtlinie für das Monitoring des Netzwerkverkehrs. Die phasenweise Zugriffssteuerung war elegant in ihrer Einfachheit: Das Setzen von enable_hostnation_network = true in unserer terraform.tfvars und das Ausführen von terraform apply erweiterte die Rollenberechtigungen jedes Teams und machte dessen Host-Nation-Agent-Richtlinie in seinem Space sichtbar. Die Übung wechselte von einem Netzwerk auf zwei, ohne einen einzigen manuellen Klick in Kibana.

Die Datenisolierung basierte auf Datenstream-Namespaces. Jede Agent-Richtlinie wird in teamspezifische Namespaces wie bt_01_deployed und bt_01_hostnation geschrieben, wodurch Datenstreams 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_hostnation

Die Kibana-Sicherheitsrolle jedes Teams wurde dann mithilfe dynamischer Index-Berechtigungsblöcke auf genau diese Datenströme beschränkt:

# Bereitgestellte Datenstreams (stets gewährt)
Indizes {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# HostNation-Datenstreams (abhängig von enable_hostnation_network)
dynamic "indices" {
  for_each = var.enable_hostnation_network ? [1] : []
  Inhalt {
    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-Rollen-Mappings Keycloak-Gruppen mit Kibana-Rollen verknüpften:

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({
    Feld = {
      groups = "${local.keycloak_groups[count.index]}"
    }
  })
}

Die standardmäßigen Integrationsrichtlinien waren bewusst einfach gehalten. Jedes Team erhielt: System für die Kern-Betriebssystem-Telemetrie, Elastic Defend für Endpoint Detection and Response, Windows-Ereignisweiterleitung, Auditd für das Linux-Audit-Logging und Network Packet Capture-Integrationen. Das sind über 400 Integrationsrichtlinien, die als Code über den Elastic Stack Terraform Provider verwaltet werden.

Ein Hinweis zu Elastic Defend: Aufgrund der Wirksamkeit des Endpoint-Schutzes von Elastic – dem US DOD und IC in Produktionsumgebungen vertrauen; lesen Sie hier mehr darüber – und aufgrund der Tatsache, dass niemand bei Verstand Zero-Day-Exploits bei einer Übung einsetzt, sind wir gezwungen, Elastic Defend zu beeinträchtigen, indem wir den Prevent-Modus deaktivieren und es im reinen Detect-Modus belassen. Teams erhalten Alerts, wenn etwas Bösartiges geschieht, jedoch ohne automatische Abwehrmaßnahmen. Wir deaktivieren außerdem die Prävention und Erkennung von Speicherbedrohungen vollständig, da diese den Großteil der Implantate und Beacons des angreifenden Teams entdeckt, was den Red Teams den Spaß verderben würde. Gegen Ende der Übung erlaubten wir den Teams, Elastic Defend mit seinem vollen Funktionsumfang zu nutzen, jedoch erst, nachdem wir den Red Teams ermöglicht hatten, eine starke Ausgangsposition zu erlangen.

Wir haben außerdem die vordefinierten Erkennungsregeln von Elastic in jeden Team-Space vorinstalliert – das vollständige Set von Elastic Security Labs, kontinuierlich aktualisiert in einem offenen Repository. Diese Regeln wurden so eingerichtet, um sicherzustellen, dass sie nur Indizes abfragen, die durch die Namespace-bezogenen Berechtigungen des Teams erlaubt sind, wodurch jeglicher teamübergreifende Datenabfluss bei der Ausführung von Erkennungsregeln verhindert wird.

Zusätzlich war in jedem Teambereich der Standardindex der Security Solution so konfiguriert, dass Erkennungsregeln auf die Datenstreams dieses Teams beschränkt wurden, anstatt das standardmäßige breite Muster zu verwenden. Dies wurde durch eine Terraform-null_resource gehandhabt, die die Kibana-API für interne Einstellungen aufrief, um securitySolution:defaultIndex für jeden Bereich festzulegen.

In Spitzenzeiten verarbeitete dieses Deployment über alle 40 Teams hinweg 800.000 Ereignisse pro Sekunde (EPS). Das ist eine beachtliche Datenmenge, und der Cluster hat sie dank der Autoscaling-Funktionen von Elastic Cloud mühelos bewältigt. Davon abgesehen haben wir bereits 2018 bei eBay 5 Millionen Ereignisse pro Sekunde verarbeitet.

Der Datenlebenszyklus wurde über eine Richtlinie für das Index-Lifecycle-Management (ILM) verwaltet, die nach einem Tag oder 50 GB (je nachdem, was zuerst eintrat) einen Rollover der Indizes durchführte, sie nach zwei Tagen zur Optimierung des schreibgeschützten Zugriffs und zum Force-Merge in eine Warm-Phase verschob und die Daten nach zehn Tagen löschte. Dadurch wurden die Speicherkosten minimiert und gleichzeitig die Anforderungen an das Übungsfenster erfüllt. Nachfolgend finden Sie ein Beispiel dafür, wie die ILM-Richtlinie implementiert wurde.

resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
  name = "dcm5-10day-retention"

  heiß {
    min_age = "0ms"

    set_priority {
      Priorität = 100
    }

    Rollover {
      max_age                = "1d"
      max_primary_shard_size = "50gb"
    }
  }

  warm {
    min_age = "2d"

    set_priority {
      Priorität = 50
    }

    readonly {}

    forcemerge {
      max_num_segments = 1
    }
  }

  löschen {
    min_age = "${var.data_retention_days}d"

    löschen {
      delete_searchable_snapshot = true
    }
  }
}

Der Shard-Stresstest: Multi-Tenancy im großen Maßstab unter Beweis stellen

Bevor wir uns für eine militärische Live-Übung auf diese Architektur festlegten, mussten wir nachweisen, dass sie unsere Anforderungen erfüllen kann und bei Problemen über ein entsprechendes Failover verfügt. Der Wechsel von einzelnen Deployments zu einem einzigen mandantenfähigen Cluster brachte echte Risiken mit sich: Ressourcenkonflikte, Ingest-Engpässe, Datenlecks über Spaces hinweg aufgrund von Fehlkonfigurationen, eine hohe Anzahl von TCP-Verbindungen auf den Elasticsearch-Nodes und eine deutlich höhere Anzahl von Shards, da jedes Team eigene Indizes generiert.

Also haben wir eine dedizierte Testumgebung aufgebaut. Der Plan war einfach: 50 Kibana-Spaces bereitstellen, in jedem Space eine Agent-Richtlinie erstellen, 6.000 EC2-Instanzen (120 pro Mandant, über sechs Subnetze in drei Verfügbarkeitszonen hinweg) starten und das Ganze einem Lasttest unterziehen. Wir haben alles mit AutoOps und Stack Monitoring überwacht.

Der Deployment-Ablauf funktionierte wie folgt: Terraform erstellte die VPC und Subnetze über drei Availability Zones hinweg, stellte die 50 Kibana-Spaces und ihre Space-bezogenen Fleet-Richtlinien bereit, generierte Registrierungs-Tokens und startete dann EC2-Instances in Batches. Jede Instance installierte Elastic Agent beim Booten und registrierte sich mit ihrem Space-spezifischen Token.

Unterwegs stießen wir auf einige interessante Herausforderungen. Der standardmäßige Elastic Stack Terraform Provider unterstützte damals keine Space-bezogenen Fleet-Vorgänge, daher haben wir ihn geforkt und den Fleet-Ressourcen eine Space-ID-Verarbeitung hinzugefügt – ohne diese Anpassung hätte sich jeder Agent unabhängig von der Richtlinienzuweisung im Standard-Space registriert. Es 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 seitdem in Version 0.12.2 support for space_ids hinzugefügt.

Wir stießen außerdem auf Ratenbegrenzungen der AWS-EC2-API, als wir versuchten, alle 6.000 Instanzen gleichzeitig bereitzustellen, daher haben wir Deployments in Batches von 500 Instanzen mit fünfminütigen Ruhephasen zwischen den Batches zusammengefasst.

Die Ergebnisse waren beruhigend. Alle 6.000 Agents wurden in der Regel innerhalb von 20 Minuten nach dem Deployment registriert. In unseren Tests funktionierte die Space-Isolierung wie erwartet, ohne dass Datenlecks zwischen Mandanten beobachtet wurden. Fleet-Richtlinienaktualisierungen wurden innerhalb von 60 Sekunden an alle Agents übertragen. Suchabfragen, die auf einzelne Spaces beschränkt waren, blieben unter Volllast schnell. Und die Multi-AZ-Verteilung erwies sich bei simulierten Ausfällen von Verfügbarkeitszonen als resilient.

Diese Tests gaben uns die Zuversicht, uns für die Architektur für die Live-Übung zu entscheiden.

Red Teams: Beobachtbarkeit von C2-Implantaten

Für die Red Teams wurde ein separates, dediziertes Elastic-Deployment eingerichtet, das auf die Beobachtbarkeit von Command-and-Control-Implantaten (C2) ausgerichtet war. Dadurch erhielten die angreifenden Teams Einblick in ihre eigenen Operationen, einschließlich Implantat-Status, Beacon-Callbacks und operativem Fortschritt, ohne das Risiko einer Vermischung mit den Daten des Blue Teams. Die Red Teams verwendeten Tuoni als C2-System, ein von Clarified Security für Red Teaming entwickeltes Framework. In DCM3 haben wir mit Clarified Security zusammengearbeitet, um sicherzustellen, dass das Elastic Common Schema ordnungsgemäß unterstützt wird, was zukünftige Integrationen mit Elastic erheblich erleichtert.

NSOC: Netzwerk-Sicherheitsbetriebszentrum im Einsatz

Die Kernübung, das Network Security Operations Centre (NSOC), lief auf einem eigenen Elastic-Deployment und bot der Übungsleitung einen umfassenden Überblick über den Zustand der Range, eine Sicherheitsüberwachung für die gesamte Infrastruktur und – was besonders wichtig war – Audit-Logging für alle von uns bereitgestellten KI-Dienste. Jeder Bedrock-API-Aufruf wurde in CloudWatch protokolliert und in diesem Deployment beobachtbar, was bedeutete, dass das NSOC vollständigen Einblick darin hatte, was die KI-Agenten gefragt wurden und von wem . Mehr dazu weiter unten im KI-Abschnitt.

Infrastrukturautomatisierung: Terraform und Catapult

Alles, was Sie oben gesehen haben, wurde als Infrastruktur als Code verwaltet. Unsere provider.tf vermittelt einen Eindruck vom Provider-Ökosystem, das wir orchestriert haben:

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 von Terraform verwaltete Ressourcenbedarf war beträchtlich: ein Elastic Cloud-Deployment mit automatischer Skalierung, 40 Kibana-Spaces, 120 Fleet-Agent-Richtlinien (drei pro Team), über 400 Integrationsrichtlinien, 40 Kibana-Sicherheitsrollen, 40 Keycloak-Rollen-Mappings, ILM-Richtlinien für die Datenaufbewahrung, 41 AWS-IAM-Benutzer für Bedrock-GenAI-Connectors (einer pro Team-Space plus ein Standardbenutzer), 41 Kibana-GenAI-Aktions-Connectors, AWS-Bedrock-Guardrails, Cloudflare-Zero-Trust-Tunnel für den Tines-Zugriff, Tines-Aktions-Connectors pro Team-Space, in HashiCorp Vault gespeicherte Erkennungs-Service-Accounts und Standard-Indexkonfigurationen der Security Solution pro Space. Der gesamte Status wurde in einem verschlüsselten S3-Backend gespeichert.

Für das Agent- und Proxy-Deployment auf den eigentlichen Range-Systemen verwendeten wir Catapult, ein exzellentes Open-Source-Tool, das vom Team von Clarified Security entwickelt wurde. Catapult kombiniert Ansible mit einem containerbasierten Ausführungsmodell, das speziell für Cyber-Range-Deployments entwickelt wurde. Es übernahm die Installation und Registrierung von Elastic Agents in der gesamten Range-Infrastruktur. Die Konfiguration von Proxy-Servern (jedes Team verfügte über einen dedizierten Squid-Proxy für sein bereitgestelltes Netzwerk; dies diente dazu, einen Single Point of Egress wie in der realen Welt zu simulieren. Der Datenverkehr wurde über Endpoints wie http://elastic-proxy.dsoc.XX.dcm.ex:3128) geleitet und das Deployment von Cloudflare-Tunnels für die Tines-Konnektivität.

Während der Bereitstellung wurde Folgendes von Terraform in HashiCorp Vault geschrieben und von Catapult verwendet: Anmeldedaten, Registrierungs-Token, API-Schlüssel, Proxy-Konfigurationen, Anmeldedaten für Tines-Dienstkonten.. 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, sodass die Catapult-Playbooks ganz einfach die richtigen Anmeldedaten für jedes Team abrufen konnten.

Schulungen: Teams zum Erfolg führen

Die Bereitstellung der Plattform ist eine Sache; sicherzustellen, dass die Benutzer sie auch tatsächlich nutzen können, eine andere. Wir haben den Blue Teams während der Phase vor der Übung On-Range-Schulungen mit Kursleiter angeboten. Dies umfasste die Grundlagen von Elastic Security, das Navigieren im eigenen Team-Space in Kibana, die Arbeit mit vordefinierten Erkennungsregeln, die Nutzung von Discover für Loganalysen und Threat Hunting, das Erstellen individueller Dashboards, das Verstehen von Elastic Defend-Alerts und das Kennenlernen des Untersuchungstools Timeline.

In der Übungsanleitung selbst wurde darauf hingewiesen, dass diese Schulung optional, aber "dringend empfohlen" war, und soweit wir sehen konnten, legten die teilnehmenden Teams am ersten Tag der Umsetzung sofort los. Schulungen und Enablement sind genauso wichtig wie das Technologie-Deployment selbst. Es hätte niemandem geholfen, einem Team Sicherheitstools auf Enterprise-Niveau an die Hand zu geben, wenn es nicht wusste, wie es sie nutzen sollte.

Der On-Range-KI-Service: konform, auditiert, durch Leitplanken abgesichert

In diesem Jahr feierten wir unser Debüt bei der Bereitstellung von KI-Zugang für die DCM-Range. Wir stellten einen konformen KI-Service direkt auf der Range bereit, gestützt auf in Großbritannien gehostete AWS Bedrock-Modelle – insbesondere Claude 3.7 Sonnet, das in der Region eu-west-2 (London) ausgeführt wird. Hierbei handelte es sich nicht um KI um der KI willen; es war ein sorgfältig konzipierter Service mit Sicherheitsleitplanken, vollständigem Audit Logging und RBAC-fähigen Zugriffskontrollen. Aufgrund der Erfahrung von Elastic im KI-Bereich wurde uns der Betrieb dieses Service anvertraut.

Der KI-Dienst hatte mehrere Consumer auf der Range, und dies ist ein wichtiger Unterschied. Der konforme Bedrock-Connector, den wir im Space jedes Teams bereitgestellt haben, versorgte nicht nur unsere benutzerdefinierten Agenten mit Energie – er versorgte auch die nativen KI-Features von Elastic mit Energie, insbesondere:

Elastic AI Assistant für Security

Der Elastic AI Assistant war in jedem Blue-Team-Space verfügbar und mit unserem On-Range-Bedrock-Connector verbunden. Dadurch erhielten die Teams eine kontextbezogene Chat-Schnittstelle direkt in Elastic Security, über die sie Fragen zu ihren Warnmeldungen stellen, Hilfe beim Schreiben von ES|QL-Abfragen erhalten, verdächtige Prozesse untersuchen und angeleitete Behebungsschritte abrufen konnten. Der KI-Assistent nutzt Retrieval-Augmented Generation (RAG) mit dem Knowledge-Base-Feature von Elastic, das mit Artikeln von Elastic Security Labs vorausgefüllt ist. Teams konnten der Knowledge Base auch eigene Dokumente wie range-spezifische SOPs, Threat-Intel-Daten oder Teamnotizen hinzufügen, um die Antworten des Assistenten noch besser in ihrem operativen Kontext zu verankern.

Besonders wertvoll im Kontext der Übung war die Fähigkeit des KI-Assistenten, weniger erfahrenen Analysten dabei zu helfen, zu verstehen, was sie vor sich sahen. Ein Junior-Analyst, der erstmals mit einem aktiven Implantat-Beacon konfrontiert war, konnte den Assistenten bitten, die Warnmeldung zu erklären, Untersuchungsschritte vorzuschlagen und sogar beim Entwurf des Vorfallberichts zu helfen. Die Einstellungen zur Datenanonymisierung stellten sicher, dass sensible Feldwerte verschleiert werden konnten, bevor sie an den LLM-Anbieter gesendet wurden.

Elastic Attack Discovery

Attack Discovery war ein weiterer bedeutender Nutzer unseres On-Range-KI-Dienstes. Attack Discovery verwendet LLMs, um Alarme in der Umgebung eines Teams zu analysieren und Bedrohungen durch die Korrelation von Alarmen, Verhaltensweisen und Angriffspfaden zu identifizieren. Jede "Entdeckung" repräsentiert einen potenziellen Angriff und beschreibt Beziehungen zwischen mehreren Alarmen – und zeigt Teams, welche Nutzer und Hosts beteiligt sind, wie Alarme der MITRE ATT&CK-Matrix zugeordnet sind, und welcher Bedrohungsakteur verantwortlich sein könnte.

Für eine Cyberübung, bei der Red Teams aktiv koordinierte Angriffe starteten, war Attack Discovery bahnbrechend. Anstatt Hunderte einzelner Alerts manuell zu triagieren, konnten Blue Teams Attack Discovery ausführen, um übergeordnete Angriffsabläufe offenzulegen – zum Beispiel: "Diese 15 Alerts sind alle Teil einer Lateral-Movement-Kette von Host X zu Host Y, wahrscheinlich durch Bedrohungsakteur Z" – und ihre Untersuchungszeit dort investieren, wo es am wichtigsten war. Es ist genau die Art von Funktion, die die durchschnittliche Reaktionszeit direkt verkürzt und Alarmmüdigkeit bekämpft – genau das, was Sie brauchen, wenn Sie fünf Tage in Folge unter anhaltenden Angriffen stehen.

Die individuellen KI-Agenten: Elastic Agent Builder

Neben den nativen Elastic AI-Features haben wir drei maßgeschneiderte KI-Agenten mit dem Elastic Agent Builder erstellt. Agent Builder ist das Framework von Elastic zum Erstellen benutzerdefinierter KI-Agenten, die LLM-Anweisungen mit modularen, wiederverwendbaren Tools kombinieren, wobei jedes Tool eine ES|QL-Abfrage, eine integrierte Suchfunktion, eine Workflow-Ausführung oder eine externe Integration über MCP ist. Agenten parsen natürlichsprachliche Anfragen, wählen die passenden Tools aus, führen sie aus und iterieren, bis sie eine vollständige Antwort liefern können – und verwalten dabei den Kontext mit Daten in Elasticsearch. Mehr über das Framework erfahren Sie in der Agent Builder-Dokumentation und im Elasticsearch Labs Deep Dive.

Die drei Kernkomponenten von Agent Builder, die wir genutzt haben, waren:

Agenten: Benutzerdefinierte LLM-Anweisungen und eine Reihe von zugewiesenen Tools, die die Persona, Fähigkeiten und Verhaltensgrenzen des Agenten definieren. Jeder Agent verfügt über eine Systemaufforderung, die seine Mission, die Tools, auf die er zugreifen kann, und die Struktur seiner Reaktionen steuert.

Tools: Modulare Funktionen, die Agenten verwenden, um Elasticsearch-Daten zu suchen, abzurufen und zu bearbeiten. Wir haben benutzerdefinierte ES|QL-Tools erstellt, die bestimmte Indizes abfragten, die Übungsdokumentationen, Playbooks und Berichte enthalten.

Agent Chat: Die dialogorientierte Schnittstelle – sowohl die integrierte Kibana-UI als auch die programmatische API –, die die Teilnehmenden für die Interaktion mit den Agenten nutzten.

Agenten- und Tool-Konfigurationen werden als JSON definiert und über die Agent Builder-APIs verwaltet, wodurch der gesamte Agentenlebenszyklus – vom Prompt-Engineering bis zur Tool-Bindung – reproduzierbar und versionskontrollierbar ist. Wir werden die GrantPT-Agentenkonfiguration und die Tool-Definitionen in einem Folgebeitrag für alle teilen, die diesen Ansatz nachbilden möchten – bleiben Sie dran.

Das haben die einzelnen Agenten getan:

1. GrantPT – Der Allzweck-Assistent

GrantPT war für alle rund 2.500 Übungsteilnehmer verfügbar und war unser wichtigster KI-Agent sowie das beste Beispiel dafür, wie einfach es der Agent Builder macht, einen fähigen, domänenspezifischen Assistenten bereitzustellen. Die Konfiguration des Agenten bestand aus einem JSON-Objekt, das seine Systemaufforderung, seine Persona und ein Array verknüpfter Tool-IDs definierte – mehr nicht. Kein benutzerdefinierter Anwendungscode, keine individuelle API-Schicht, nur deklarative Konfiguration.

Was GrantPT seine Tiefe verlieh, war das Tooling. Wir haben eine Mischung aus integrierten Platform-Tools und benutzerdefinierten ES|QL-Tools definiert, die jeweils mit einer Beschreibung, einer parametrisierten Abfrage und typisierten Parameterdefinitionen registriert sind. Beispielsweise akzeptierte das Knowledge-Base-Tool einen target_index- und einen semantischen query-Parameter und führte eine parametrisierte ES|QL-Abfrage für unsere dcm5-grantpt-*-Indizes mit semantischem Such-Ranking aus:

FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10

Ein separates Tool zur Indexerkennung ermöglichte es dem Agenten, zu Beginn jeder Konversation verfügbare Knowledge-Base-Indizes dynamisch aufzulisten, was bedeutete, dass wir während der Übung neue Dokumentationsindizes hinzufügen konnten, ohne den Agenten neu konfigurieren zu müssen; er erkannte sie einfach bei der nächsten Interaktion.

Wir haben außerdem ein Jira-Integrationstool entwickelt, das eine semantische Suche über ingestierte Helpdesk-Tickets hinweg durchführte, wodurch GrantPT relevanten Kontext zur Fehlerbehebung aus früheren Support-Anfragen bereitstellen konnte. Dies war besonders nützlich für die Helpdesk-Analysten, die GrantPT zu wiederkehrenden Problemen befragen und Reaktionen erhalten konnten, die auf dem tatsächlichen Ticketverlauf statt auf allgemeinen Hinweisen basierten.

Das auf RBAC zugeschnittene Reaktionsverhalten ergab sich aus einer Kombination der Systemaufforderung des Agenten, die ihn anwies, Antworten basierend auf der Rolle des Nutzers zu kontextualisieren, und dem zugrunde liegenden Sicherheitsmodell von Elasticsearch. Da die ES|QL-Abfrage jedes Tools im Sicherheitskontext des Nutzers ausgeführt wird, kann der Agent nur Dokumente anzeigen, auf die die Rolle des Nutzers zugreifen darf. Ein Mitglied des Blue Teams, das nach Übungsverfahren fragt, würde Ergebnisse erhalten, die auf die für sein Team zugänglichen Indizes beschränkt sind, während ein HelpDesk-Analyst Ergebnisse aus helpdeskspezifischen Indizes sehen würde. Der Agent benötigte keine explizite Logik zum Wechseln von Rollen; die native Sicherheit auf Dokumentenebene von Elasticsearch übernahm die Eingrenzung, und der Agent arbeitete einfach mit den zurückgegebenen Ergebnissen. Das ist einer der Gründe, warum Agent Builder wirklich elegant ist – indem Sie das Sicherheitsmodell von Elasticsearch übernehmen, erhalten Sie RBAC-fähige KI, ohne eine einzige Zeile Autorisierungscode zu schreiben.

2. REDRock – Der Begleiter des Angreifers

Dieser Agent war ausschließlich für Red Teams verfügbar. REDRock folgte demselben Agent Builder-Muster: einem dedizierten Systemprompt, der seine gegnerische Persona definierte und an einen eigenen Satz benutzerdefinierter ES|QL-Tools gebunden war, die Red-Team-spezifische Indizes abfragen. Diese Indizes enthielten die Red-Team-Playbooks, die Dokumentation zu Tuoni C2, bekannte Systemschwachstellen innerhalb der Range-Umgebung und Informationen zu bereitgestellten Diensten. Die Tool-Definitionen spiegelten dasselbe von GrantPT verwendete Muster für die parametrisierte semantische Suche wider, waren jedoch auf Indizes beschränkt, auf die nur Red-Team-Rollen zugreifen konnten. Red-Team-Operatoren konnten Angriffsvektoren abfragen, bekannte Schwachstellen in Zielsystemen überprüfen und kontextbezogene Hinweise zu ihren Einsatzplänen erhalten. Es war, ganz offen gesagt, so, als würde man den Angreifern einen äußerst umfassend gebrieften Einsatzoffizier zur Verfügung stellen.

3. RefPT – Das Schiedsrichter-Tool

Speziell für das White Team (die Schiedsrichter und Bewerter der Übung) entwickelt, war RefPT an Tools angebunden, die Indizes abfragten, die Berichte des Blue Teams, Szenarioereignisse und die Bewertungskriterien enthielten. Sein Zweck bestand darin, eine einheitliche und faire Bewertung für alle 40+ Teams zu gewährleisten. Der System-Prompt des Agenten wurde darauf abgestimmt, eingereichte Berichte mit bekannten Szenarioereignissen und Bewertungsrubriken abzugleichen, was Bewertern half, Inkonsistenzen oder Lücken zu identifizieren. Wenn Bewerter Dutzende von Teams gleichzeitig evaluieren, ist eine KI, die Berichte mit einem strukturierten Bewertungsindex abgleichen kann, für die Konsistenz wahrhaft transformativ.

Tines: KI-gestützte Workflow-Automatisierung

Tines war ebenfalls ein Nutzer des On-Range-KI-Dienstes. Jedes Blue Team verfügte über eine dedizierte Tines-Instanz, wobei Tines-Aktions-Connectors in ihrem Kibana-Space bereitgestellt wurden. Tines konnte die Bedrock-gestü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 Workflow-Erstellung in natürlicher Sprache. Der Tines-Connector wurde pro Team mit in Vault gespeicherten Anmeldedaten 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/"
  })
}

Sicherstellen von Compliance: Leitplanken und Audit

Jede KI-Interaktion aller dieser Nutzer wurde durch strenge AWS Bedrock Guardrails geregelt. Wir haben Guardrails mit Inhaltsfilterung (Hass, Beleidigungen, sexuelle Inhalte und Gewalt bei MEDIUM-Schwellenwerten), PII-Schutz (Blockierung von E-Mail-Adressen, Telefonnummern, Namen, Adressen, britischen Nationalversicherungsnummern, Kreditkartennummern und IP-Adressen), themenbasierter Filterung zur Verhinderung von Diskussionen über tatsächliche geheime Operationen und Obszönitätenfilterung bereitgestellt. Hier ist ein Ausschnitt der Guardrail-Konfiguration aus unserem Terraform:

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "Guardrails für DCM5 Prod Elastic Kibana GenAI-Konnektoren"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... weitere Inhaltsfilter für BELEIDIGUNGEN, SEXUELLE INHALTE, GEWALT
  }

  sensitive_information_policy_config {
    pii_entities_config {
      action = "BLOCK"
      type   = "UK_NATIONAL_INSURANCE_NUMBER"
    }
    pii_entities_config {
      action = "BLOCK"
      type   = "IP_ADDRESS"
    }
    # ... zusätzliche Filter für personenbezogene Daten
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "Diskussionen über tatsächliche geheime Operationen, aktuelle reale militärische Aktivitäten oder Operational Intelligence."
      type       = "DENY"
    }
  }
}

Jeder Blue-Team-Space hatte einen eigenen IAM-Nutzer für den Bedrock-Zugriff, und die Kibana-Einstellung genAiSettings:defaultAIConnectorOnly wurde erzwungen, um zu verhindern, dass Teams eigene Connectors konfigurieren. Dies bedeutete, dass jeder einzelne API-Aufruf über CloudWatch zu einem bestimmten Team zurückverfolgt werden konnte und das NSOC über vollständige Audit-Transparenz verfügte. Die CloudWatch-Loggruppe /aws/bedrock/grantpt-prod/invocations erfasste jeden Aufruf und jedes Guardrail-Ereignis.

Die Zahlen für alle KI-Nutzer sprechen für sich: 3 benutzerdefinierte KI-Agenten, 2.797 Gespräche und 785 Mio. KI-Token, die im Laufe der Übung verbraucht wurden.

In-Game-Echtzeit-Monitoring

Innerhalb des Übungsszenarios hatte jedes Team Zugriff auf RocketChat als Messaging-Client auf der Übungsumgebung. Jedes Blue Team erhielt einen eigenen Kanal, die Möglichkeit, jeder Person in der Übung Direktnachrichten zu senden, sowie die Freiheit, bei Bedarf neue Kanäle einzurichten. Von entscheidender Bedeutung für die DCM-Tradition war dabei auch der Memes-Kanal – das spirituelle Rückgrat aller teamübergreifenden Sticheleien und des kreativen, die Moral stärkenden Humors, der unweigerlich entsteht, wenn man einige Tausend Cyber-Operatoren eine Woche lang unter Druck setzt.

All diese Kommunikationsdaten boten einen hervorragenden Echtzeit-Einblick in den Range-Zustand, die Teamstimmung und die während der Übung im Trend liegenden Themen. Das war einfach zu verlockend, um es sich entgehen zu lassen, also ingestierten wir den gesamten RocketChat-Konversationskorpus in Echtzeit in Elastic und machten ihn nutzbar.

Sentimentanalyse 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 auf einem Machine-Learning-Node im NSOC-Deployment bereitgestellt. Dies wurde dann in eine Elasticsearch-Ingest-Pipeline eingebunden, die jede RocketChat-Nachricht bei der Ingestion durchlief. Wir haben die extrahierten Entitäten übernommen und die häufigsten als Dashboard-Themen dargestellt, was uns während der gesamten Übung einen Live-Überblick über das Auf und Ab der Gesprächsthemen verschaffte.

Wir analysierten außerdem Gruppenaktivitäten, Nutzerstatistiken und allgemeine Kommunikationsmuster, um ein Bild der Aktivitätsmuster jedes Teams zu erstellen – der aktivsten Teilnehmer, des Nachrichtenvolumens im Zeitverlauf und der nach einzelnen Nutzern aufgeschlüsselten Stimmungstrends. Alles in allem gab uns das einige wirklich interessante Einblicke darin, was auf dem Übungsgelände nahezu in Echtzeit geschah. Als wir beispielsweise Elastic Agent in den Prevent-Modus versetzten, leuchtete in unserem Dashboard sofort eine Wortwolke auf, in der "Elastic" als das meistdiskutierte Thema über alle Kanäle hinweg erschien – Blue Teams diskutierten über dessen Wirksamkeit, Red Teams beklagten den Verlust ihrer Beacons. Ziemlich zufriedenstellend, das.

Meme-Analyse (ja, wirklich)

Schließlich – und das sorgte für einiges Erstaunen – haben wir jedes über die Kanäle eingereichte Meme abgerufen, die Bilder vektorisiert und Nearest-Neighbour-Auswertungen ausgeführt, um ähnliche Memes und Themen zu clustern. Außerdem haben wir sie durch das Zero-Shot-NER-Inferenzmodell geschickt, um thematische Beschreibungen des Inhalts der einzelnen Memes zu generieren. Die Logik dahinter war, dass sich diese Ausgänge später für Filterung, Moderation oder sonstige In-Game-Interaktionen als nützlich erweisen könnten. Ob die Meme-Analyse betrieblich entscheidende Erkenntnisse lieferte, ist fraglich. Ob es großen Spaß gemacht hat, hingegen nicht.

Probleme im Keim ersticken

So sehr wir auch gehofft hatten, dass während der Übungswoche alles reibungslos abläuft, gehen unweigerlich Dinge kaputt, werden nicht vollständig verstanden oder müssen weiter angepasst werden, damit ein bestimmtes Team sie wie gewünscht nutzen kann. Dazu hatten wir einen eigenen Unterbereich des In-Range-Helpdesks eingerichtet, in dem Elastic- und GenAI-spezifische Anfragen von jedem Team eingereicht werden konnten.

Wir besetzten diesen Helpdesk über die gesamte Dauer der Übung hinweg und boten Unterstützung, Dokumentation, Fehlerbehebung und Range-spezifische Empfehlungen. Auf diesen letzten Punkt lohnt es sich, näher einzugehen. Manchmal war das, was ein Blue Team in Elastic sah, überhaupt kein Problem von Elastic, sondern vielmehr die getreue Wiedergabe eines Vorgangs auf der Range durch Elastic, der weitere Untersuchungen erforderte (Red Teams können enormes Chaos anrichten, und die Telemetriedaten lügen nicht). Im Laufe der Übung bearbeiteten wir 125 einzelne Support-Anfragen von Teams, die gezielt um Hilfe von uns bei Elastic gebeten hatten.

Präventives Debugging mit Tines

Neben Besuchen bei Teams per VTC oder persönlich auf der EXCON haben wir auch mit Tines zusammengearbeitet, um einen etwas proaktiveren Ansatz zu verfolgen. Wir haben den Ticket-Text aus eingehenden Anfragen extrahiert, versucht, das Problem zu kategorisieren, die Kategorisierung mit unserem Korpus zuvor gelöster Tickets ausgeführt und durch GenAI eine zusammenfassende Erstreaktion erstellen lassen, die darauf abzielte, das Problem des Nutzers zu lösen, bevor die Triage es in unsere Warteschlange leitete.

Das ist tatsächlich ein Muster, das wir von unserer eigenen Supportorganisation bei Elastic übernommen haben, bei der wir eine ähnliche Funktion bereitstellen, indem wir unsere umfangreiche Wissensdatenbank bereits gelöster Probleme als Repository für den Kontext von KI-Agenten im Support nutzen. Der Gedanke ist einfach: Vergangene Lösungen werden genutzt, um einen maschinell generierten, fundierten ersten Versuch zur Lösung eines Problems zu ermöglichen und die Notwendigkeit zu umgehen, dass ein Support-Techniker jedes Ticket manuell bearbeitet. Es löste nicht alles; einige Probleme erforderten tatsächlich einen Menschen mit umfassendem Kontext, doch es verringerte den Druck auf die Warteschlange erheblich und sorgte dafür, dass die Teams, die Antworten benötigten, diese schneller erhielten. Dies war bei unseren eigenen spezifischen Tickets und unserer Warteschlange ein so großer Erfolg, dass wir den Aufgabenbereich in der zweiten Hälfte der Übung auf den gesamten Helpdesk ausweiteten und so dazu beitrugen, die Belastung der anderen Gruppen im Green-Team zu verringern, die die Übung unterstützten.

Branchenpartnerschaften: Gemeinsam geht's besser

Besonders stolz sind wir darauf, wie unser Partner-Ökosystem von Jahr zu Jahr gewachsen ist. DCM ist nicht nur eine reine Elastic-Show; es ist ein echter Zusammenschluss von Branchenpartnern, von denen jeder etwas Einzigartiges in die Sicherheitsplattform einbringt.

Jahr 1 (DCM2) - Elastic trat als Industriepartner bei und stellte die Platform für Sicherheitsüberwachung und Endpoint-Erkennung bereit.

Jahr 2 (DCM3) – Wir haben Endace eingeführt, um eine 1:1-Paketerfassung zu ermöglichen. Die vollständige Paketerfassung in Kombination mit der Netzwerk-Sichtbarkeit von Elastic gab Teams die Möglichkeit, tiefgehende forensische Untersuchungen durchzuführen, die eine rein logbasierte Analyse nicht bieten kann.

Jahr 3 (DCM4) – Tines stieß zur Familie und brachte die Workflow-Automatisierung mit an den Tisch. Blue Teams konnten nun automatisierte Playbooks für Reaktionen, Triage-Workflows und Benachrichtigungsketten erstellen, die alle über den nativen Tines-Connector direkt in ihre Elastic-Umgebung integriert waren.

Jahr 4 (DCM26, ehemals DCM5) – AWS kam an Bord, stellte den Zugriff auf Bedrock für unsere KI-Agenten bereit und beteiligte sich an der Finanzierung der Elastic-Deployments. Dies war ein wichtiger Meilenstein; dass ein Hyperscaler direkt in den Erfolg der Übung investiert war, schaltete Funktionen frei (wie etwa konforme, im Vereinigten Königreich gehostete KI-Inferenz mit vollständigen Guardrails und Audit Logging), die andernfalls schlichtweg nicht möglich gewesen wären. Die Integration von Tines wurde in diesem Jahr zudem durch den On-Range-Zugriff auf LLMs erweitert. Die DCM-Reihe erreichte in diesem Jahr ebenfalls einen Meilenstein und entwickelte sich von ihren Ursprüngen als Initiative der Army Cyber Association zu einem offiziell geförderten Programm unter dem Cyber and Specialist Operations Command.

An die Teams von Endace, Tines und AWS – herzlichen Dank. Diese Übung ist dank Ihrer Beiträge besser, und alle Teams sind dank der Plattform, die wir gemeinsam entwickelt haben, besser ausgestattet. Wir planen bereits für DCM27. Auf Sie alle.

Kultur, Highlights und die Dinge, die es lohnenswert machen

Die Challenge Coins

Wir haben individuelle Challenge Coins für DCM26 prägen lassen. Wenn Sie Bescheid wissen, wissen Sie: Challenge Coins haben eine lange militärische Tradition, und eine für die Übung anfertigen zu lassen, fühlte sich nach dem richtigen Weg an, unser viertes Jahr der Beteiligung zu würdigen.

Die Cocktailparty

Wir waren außerdem sehr dankbar für die Einladung zur Cocktailparty der High Commission, die vom britischen High Commissioner in Singapur veranstaltet wurde. Es hat schon etwas Surreales, über Elasticsearch-Shard-Zahlen und Terraform-State-Management zu sprechen, während man auf Einladung des Botschafters einen Gin Tonic in der Hand hält. Es war ein fantastischer Abend und eine echte Erinnerung daran, dass diese Maßnahmen an der Schnittstelle von Technologie und Diplomatie stattfinden und dass die hier aufgebauten Beziehungen weit über das rein Technische hinausgehen.

Fazit

Die mandantenfähige Architektur hat sich unter anhaltender Last bewährt; die nativen Elastic AI-Features (AI Assistant und Angriffserkennung) gaben Teams Fähigkeiten, die vor wenigen Jahren noch Science-Fiction gewesen wären; und die benutzerdefinierten KI-Agenten übertrafen unsere Erwartungen hinsichtlich der Akzeptanz. Das Partnerschaftsmodell zeigt weiterhin, dass die Beteiligung der Industrie an Verteidigungsübungen Ergebnisse schafft, die keine Organisation allein erreichen könnte.

Defence Cyber Marvel 2026 war eine wegweisende Iteration einer Übung, die kontinuierlich an Ambition, Komplexität und Wirkung gewinnt. Für Elastic ist das Vertrauen, die zentrale defensive Sicherheitsplattform für 40 Blue Teams aus 29 Nationen – und in diesem Jahr auch die KI-Funktionen – bereitzustellen, etwas, das wir sehr ernst nehmen. Die Übung vermittelt echte Fähigkeiten für reale Menschen, die in der Praxis echte Netzwerke verteidigen werden, und Teil dieser Mission zu sein, ist von wahrer Bedeutung.

Wie die Pressemitteilung der britischen Regierung es formulierte, demonstriert DCM den praktischen Nutzen von realitätsnahen Szenarien, die internationale Partnerschaften stärken. Dem können wir nur voll und ganz zustimmen.

Wir sind nächstes Jahr wieder da, und ich vermute, dass wir dann noch mehr zu besprechen haben. In der Zwischenzeit werden wir das Produkt weiter verbessern, damit der Support für Umgebungen wie Defence Cyber Marvel im Jahresvergleich herausragend ist.

Wir sehen uns auf der Range.

Verfolgen Sie die DCM26-Story in den sozialen Medien:

Facebook | LinkedIn | Instagram

Weitere Lektüre

Elastic Security und KI

Infrastruktur & Tools

Übungskontext

Wie hilfreich war dieser Inhalt?

Ein Problem melden