어디서부터 시작할까요? Elastic은 4년 연속 영국 국방부의 대표적인 사이버 훈련 시리즈인 Exercise Defence Cyber Marvel에서 신뢰할 수 있는 업계 파트너로 활동할 수 있는 특권을 누리고 있습니다. DCM26은 의심할 여지 없이 가장 야심 찬 반복 작업이었으며, 마침내 무엇을 만들었는지, 어떻게 만들었는지, 그 과정에서 무엇을 배웠는지에 대해 이야기할 수 있게 되어 매우 기쁘게 생각합니다.
디펜스 사이버 마블이란 무엇인가요?
잘 모르시는 분들을 위해 설명하자면, 디펜스 사이버 마블(DCM)은 현실적이고 고압적인 시나리오에서 전통적인 IT 네트워크, 기업 환경 및 복잡한 산업 제어 시스템을 방어하는 데 중점을 둔 영국 최대 규모의 군 사이버 훈련 시리즈입니다. 이는 국방부와 동맹국 전반의 준비태세, 상호운용성, 복원력을 강화하는 동시에 책임감 있는 사이버 파워를 보여줍니다. 올해로 5년째를 맞이한 DCM은 육군 사이버 협회 이니셔티브에서 사이버 및 특수작전사령부(CSOC)가 주도하는 3군 작전으로 발전했습니다.
영국 정부는 이 훈련의 전략적 중요성에 대한 훌륭한 개요를 제공하는 DCM26에 대한 공식 보도 자료를 발표했습니다. 싱가포르 주재 영국 고등판무관이 언급했듯이, 이번 훈련은 영국과 신뢰할 수 있는 파트너 간의 긴밀한 협력을 보여주며 점점 더 복잡해지는 안보 환경에서 전략적 파트너십의 힘을 상기시켜 줍니다.
DCM의 핵심은 다양한 기술을 사용하여 방어하는 블루팀이 레드팀의 공격으로부터 할당된 네트워크와 인프라를 보호하는 무력 충돌 사이버 훈련입니다. 활동은 기본 비밀번호 변경과 방화벽 강화부터 Elastic Security를 통한 엔터프라이즈급 AI 기반 사이버 방어 배포에 이르기까지 다양합니다. 화이트팀은 각 팀의 활동을 모니터링하여 시스템 가용성, 공격 탐지, 사고 보고 및 시스템 복구를 고려한 점수를 설정합니다. 가장 경험이 많은 팀을 늘리는 동시에 사이버 사격장을 처음 접하는 주니어 팀을 위한 독특한 훈련 메커니즘을 촉진하며, 이러한 두 가지 목적이 DCM을 매우 가치 있는 훈련으로 만드는 이유입니다.
DCM26의 규모
DCM26에는 29 참가국 및 70 조직에서 2,500명 이상의 인원이 모였으며, 싱가포르에 위치한 중앙 연습통제소(EXCON)에서 조정하고, EXCON은 600 참가자를 호스트했습니다. 이 훈련은 5,000개 이상의 가상 시스템을 호스팅하는 CR14 사이버 범위와 AWS를 아우르는 하이브리드 컴퓨팅 환경에서 진행되었습니다.
훈련 자체는 5일간(2026년 2월 9일부터 13일까지) 진행되었으며, 강사가 진행하는 사전 교육과 연결성 점검(선택 사항)이 선행되었습니다. 국방 아카데미 훈련 환경(DATE)의 인도 태평양 작전 환경을 기반으로 구축된 이 시나리오에서는 지역 위기가 고조되는 동안 배치된 군사 시스템을 방어하는 사이버 보호 팀으로 팀을 배치했습니다. 블루팀은 지리적으로 분산되어 일부는 영국과 해외에, 다른 일부는 해외에 배치되었으며 모두 VPN을 통해 범위 내에 연결했습니다.
영국 국방부, 국가범죄청, 근로연금부, 내각부, 기업통상부 등 범정부 부서와 국제 파트너들이 최대 40 팀을 구성하여 참가했습니다. 작년 대한민국에서 성공적으로 진행된 훈련에 이어 싱가포르가 처음으로 훈련 허브로 참여했으며, 이는 공동의 안보 과제에 대해 인도 태평양 파트너들과 협력을 강화하려는 영국의 의지를 반영합니다.
한마디로 심각한 운동입니다. 모든 참가자에게 점수와 실제 학습 결과에 대한 실제 결과를 제공하는 고압력, 강제력입니다.
배포: Elastic 인프라
올해의 인프라는 이전 버전보다 아키텍처적으로 크게 발전한 모습을 보여주었습니다. 팀별로 개별 Elastic Cloud 클러스터를 배포하는 대신 블루팀을 위한 단일 공간 기반 멀티테넌트 Elastic Cloud 배포로 전환했습니다. 또한 블루팀 외부의 기능에 대한 배포도 제공했습니다. 각 배포와 그 존재 이유를 자세히 설명해 드리겠습니다.
블루팀: 멀티 테넌트 Elastic 보안
저희 기여의 핵심은 Kibana 스페이스와 데이터스트림 네임스페이스를 사용해 분리된 모든 40 방어 블루팀에 서비스를 제공하는 단일 Elastic Cloud 배포였습니다. 39 팀은 각각 대시보드, 에이전트 및 탐지 규칙을 포함한 고유의 격리된 작업 공간을 가졌습니다.
각 팀의 공간을 만들기 위한 테라폼 리소스의 모습은 다음과 같습니다:
# 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"
}각 팀의 공간에는 1일차에는 배포된 네트워크 정책, 2일차에는 호스트 국가 네트워크 정책, 마지막으로 네트워크 트래픽 모니터링을 위한 PacketCapture 정책 등 세 가지 Fleet 에이전트 정책으로 구성된 전용 세트가 제공됩니다. 단계적 액세스 제어는 매우 간단했습니다. terraform.tfvars 에서 enable_hostnation_network = true 을 설정하고 terraform apply 을 실행하면 각 팀의 역할 권한이 확장되고 호스트 국가 에이전트 정책이 해당 공간에 표시되었습니다. 이 연습은 Kibana에서 단 한 번의 수동 클릭 없이 하나의 네트워크에서 두 개의 네트워크로 전환되었습니다.
데이터 격리는 데이터스트림 네임스페이스에 의존했습니다. 각 상담원 정책은 bt_01_deployed 및 bt_01_hostnation 과 같은 팀별 네임스페이스에 기록되어 패턴에 따라 데이터 스트림을 생성합니다:
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그런 다음 각 팀의 Kibana 보안 역할은 동적 인덱스 권한 블록을 사용하여 해당 데이터 스트림으로만 범위가 지정되었습니다:
# 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"]
}
}인증은 Keycloak SSO를 통해 처리되었으며, Elasticsearch 역할 매핑이 Keycloak 그룹을 Kibana 역할에 연결했습니다:
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]}"
}
})
}기본 통합 정책은 설계상 단순했습니다. 각 팀은 다음과 같이 받았습니다: 핵심 OS 원격 측정을 위한 시스템, 엔드포인트 탐지 및 대응을 위한 Elastic Defend, Windows 이벤트 포워딩, Linux 감사 로깅을 위한 Auditd, 네트워크 패킷 캡처 통합. 여기( 400 )를 통해 코드 형태로 관리되는 통합 정책은 Elastic Stack Terraform Provider를 통해 관리됩니다.
Elastic Defend에 대한 참고 사항:미국 국방부와 IC가 실제 운영 환경에서 신뢰하고 있는 Elastic의 엔드포인트 보호 효과( 자세한 내용은 여기를 참조하세요 )와 제정신인 사람은 훈련 연습에서 제로데이 익스플로잇을 태우지 않는다는 사실 때문에, 우리는 예방 모드를 비활성화하고 탐지 전용 모드로 남겨두는 방식으로 Elastic Defend를 손볼 수 밖에 없습니다. 팀원들은 악의적인 일이 발생하면 경고를 받지만 자동 완화 기능은 없습니다. 또한 메모리 위협 방지 및 탐지 기능을 완전히 비활성화했는데, 이는 대부분의 공격 팀 임플란트와 비콘을 발견하여 오히려 레드 팀의 게임을 망칠 수 있기 때문입니다. 연습이 끝날 무렵, 우리는 팀들이 Elastic Defend의 모든 기능을 자유롭게 사용할 수 있도록 허용했지만, 레드 팀이 강력한 발판을 마련하기 전에는 허용하지 않았습니다.
또한 각 팀 공간에 Elastic의 사전 구축된 탐지 규칙을 사전 설치했습니다. Elastic Security Labs의 전체 세트는 오픈 리포지토리에서 지속적으로 업데이트됩니다. 이러한 규칙은 팀의 네임스페이스 범위 권한이 허용하는 인덱스만 쿼리하도록 설정되어 탐지 규칙 실행 시 팀 간 데이터 누출을 방지했습니다.
또한 각 팀 공간에는 기본 광범위한 패턴이 아닌 해당 팀의 데이터 스트림으로만 탐지 규칙의 범위를 지정하도록 보안 솔루션 기본 인덱스가 구성되어 있습니다. 이것은 각 스페이스에 대해 securitySolution:defaultIndex 을 설정하기 위해 Kibana 내부 설정 API를 호출하는 Terraform null_resource 에 의해 처리되었습니다.
이 배포가 최고조에 달했을 때, 모든 40 팀에서 초당 80만 개의 이벤트(EPS)를 수집했습니다. 이는 엄청난 양의 데이터인데, 클러스터는 Elastic Cloud의 자동 확장 기능 덕분에 이를 편안하게 처리했습니다. 예를 들어, 2018 당시에는 eBay에서 초당 5 백만 건의 이벤트를 진행했습니다.
데이터 수명 주기는 인덱스를 1일 또는 50 GB(둘 중 먼저 도래하는 날짜) 후에 롤오버하고, 2일 후에 읽기 전용 최적화 및 강제 병합을 위해 웜 단계로 이동한 다음, 10일 후에 데이터를 삭제하는 ILM(인덱스 수명 주기 관리) 정책에 의해 관리되었습니다. 그 결과, 연습 기간 요건을 유지하면서 보관 비용을 최소화할 수 있었습니다. 다음은 ILM 정책이 어떻게 구현되었는지에 대한 예시입니다.
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
}
}
}샤드 스트레스 테스트: 대규모 멀티테넌시 입증
실제 군사 훈련을 위해 이 아키텍처를 도입하기 전에 요구 사항을 충족하고 문제 발생 시 적절한 장애 조치를 취할 수 있음을 입증해야 했습니다. 개별 배포에서 단일 멀티테넌트 클러스터로 이동하면서 리소스 경합, 수집 병목 현상, 잘못된 구성으로 인한 공간 간 데이터 유출, Elasticsearch 노드의 대규모 TCP 연결 수, 각 팀이 자체 인덱스 세트를 생성하므로 훨씬 더 많은 샤드 수 등 실제 위험이 발생했습니다.
그래서 전용 테스트 장비를 구축했습니다. 계획은 간단했습니다. 50 Kibana 스페이스를 배포하고, 각 스페이스에 에이전트 정책을 생성하고, 3개의 가용성 영역의 6개 서브넷에서 테넌트당 120개씩 6,000개의 EC2 인스턴스를 실행하고, 로드 테스트하는 것이었습니다. 자동 운영 및 스택 모니터링으로 모든 것을 모니터링했습니다.
배포 흐름은 다음과 같이 진행되었습니다: Terraform은 3개의 가용성 영역에 걸쳐 VPC와 서브넷을 생성하고, 50 Kibana 스페이스와 해당 스페이스 범위의 Fleet 정책을 프로비저닝하고, 등록 토큰을 생성한 다음, EC2 인스턴스를 일괄적으로 실행했습니다. 각 인스턴스는 부팅 시 Elastic 에이전트를 설치하고 공간별 토큰에 대해 등록합니다.
그 과정에서 몇 가지 흥미로운 도전에 직면했습니다. 표준 Elastic Stack Terraform 제공자는 당시 공간 인식 Fleet 운영을 지원하지 않았기 때문에, 우리는 이를 포크하고 Fleet 리소스에 공간 ID 처리를 추가했습니다. 이러한 수정이 없었다면 모든 에이전트는 정책 할당에 관계없이 기본 공간에 등록되었을 것입니다. 연습을 위해 공급자를 확장한 것은 이번이 처음이 아니며, 2년 전에도 DCM2의 경우 elasticsearch_cluster_info 데이터 원본을 추가한 바 있습니다. 다행히도 업스트림 공급자는 이후 버전 0.12.2 에 support for space_ids 을 추가했습니다.
또한 6,000개의 인스턴스를 동시에 모두 스핀업하려고 할 때 AWS EC2 API 속도 제한에 부딪혔기 때문에 배치 사이에 5분의 쿨오프 기간을 두고 500 인스턴스에서 일괄 배포를 진행했습니다.
결과는 안심할 수 있었습니다. 일반적으로 6,000명의 상담원 모두 배포 후 20 몇 분 이내에 등록되었습니다. 테스트 결과, 공간 격리는 테넌트 간에 데이터 유출이 관찰되지 않고 예상대로 작동했습니다. 플릿 정책 업데이트가 60 초 이내에 모든 상담원에게 전파됩니다. 개별 스페이스로 범위가 지정된 검색 쿼리는 최대 부하에서도 빠른 속도를 유지했습니다. 또한 다중 AZ 배포는 모의 가용성 영역 장애 시 복원력이 뛰어난 것으로 입증되었습니다.
이 테스트를 통해 저희는 라이브 연습을 위한 아키텍처에 확신을 가질 수 있었습니다.
레드 팀: C2 임플란트 관찰 가능성
명령 및 제어(C2) 임플란트 통합 가시성에 초점을 맞춘 별도의 전용 Elastic 배포가 레드팀을 위해 마련되었습니다. 이를 통해 공격팀은 블루팀의 데이터와 교차 오염의 위험 없이 임플란트 상태, 비콘 콜백, 작전 진행 상황 등 자체 작전에 대한 가시성을 확보할 수 있었습니다. 레드팀은 레드팀 구성을 위해 클래리파이드 시큐리티에서 개발한 프레임워크인 투오니를 C2로 사용했습니다. DCM3에서는 Clarified Security와 협력하여 Elastic Common Schema를 제대로 지원하도록 하여 향후 Elastic과의 통합을 훨씬 쉽게 만들었습니다.
NSOC: 네트워크 보안 운영 센터 운동
핵심 연습인 네트워크 보안 운영 센터(NSOC)는 자체 Elastic 배포에서 실행되어 연습 제어 담당자에게 범위 상태, 전체 인프라에 대한 보안 모니터링, 그리고 중요한 것은 우리가 배포한 모든 AI 서비스에 대한 감사 로깅에 대한 종합적인 보기를 제공했습니다. 이 배포에서는 모든 Bedrock API 호출이 CloudWatch에 기록되고 관찰 가능했기 때문에 NSOC는 AI 에이전트에게 무엇을 요청하고 누가 요청했는지 완벽하게 파악할 수 있었습니다. 이에 대한 자세한 내용은 아래 AI 섹션에서 확인하세요.
인프라 자동화: 테라폼과 캐터펄트
위에서 보신 모든 것은 코드형 인프라로 관리되었습니다. 저희 provider.tf 에서 저희가 조율하고 있는 공급자 생태계를 확인할 수 있습니다:
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
}
}Terraform이 관리하는 총 리소스 공간은 상당했습니다: 자동 확장 기능이 있는 하나의 Elastic Cloud 배포, 40 Kibana 스페이스, 120 Fleet 에이전트 정책(팀당 3개), 400개 이상의 통합 정책, 40 Kibana 보안 역할, 40 Keycloak 역할 매핑, 데이터 보존을 위한 ILM 정책, 41 Bedrock GenAI 커넥터용 AWS IAM 사용자(팀 공간당 1개와 기본 1개), 41 Kibana GenAI 액션 커넥터, AWS Bedrock 가드레일, Tines 액세스를 위한 Cloudflare 제로 트러스트 터널, 팀 공간당 Tines 액션 커넥터, 해시코프 볼트에 저장된 탐지 서비스 계정, 공간별 보안 솔루션 기본 인덱스 구성. 모든 상태는 암호화된 S3 백엔드에 저장되었습니다.
실제 범위 시스템에 에이전트 및 프록시를 배포하기 위해 Clarified Security 팀이 구축한 우수한 오픈 소스 도구인 Catapult를 사용했습니다. Catapult는 사이버 범위 배포를 위해 특별히 제작된 컨테이너 기반 실행 모델로 Ansible을 감싸고 있습니다. 범위 인프라 전반에 걸쳐 Elastic 에이전트의 설치 및 등록을 처리했습니다. 프록시 서버 구성(각 팀은 배포된 네트워크에 전용 Squid 프록시를 사용했는데, 이는 실제와 같은 단일 이그레스 지점을 시뮬레이션하기 위한 것이었습니다. http://elastic-proxy.dsoc.XX.dcm.ex:3128)와 같은 엔드포인트를 통해 트래픽을 라우팅하고, Tines 연결을 위한 Cloudflare 터널을 배포했습니다.
프로비저닝하는 동안 테라폼에 의해 해시코프 볼트에 다음이 기록되었고, 캐터펄트에 의해 소비되었습니다: 자격 증명, 등록 토큰, API 키, 프록시 구성, Tines 서비스 계정 자격 증명.... Vault 경로는 dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed 및 dcm/gt/elastic/tines-sa/tines-sa-btXX 과 같은 일관된 구조를 따르기 때문에 Catapult 플레이북에서 각 팀에 적합한 자격 증명을 가져오는 것이 간단합니다.
교육: 성공을 위한 팀 구성
플랫폼을 배포하는 것과 사람들이 실제로 사용할 수 있도록 하는 것은 별개의 문제입니다. 연습 전 단계에서 블루팀에게 강사가 진행하는 현장 교육을 제공했습니다. 여기에는 Elastic Security 기본 사항, Kibana의 팀 공간 탐색, 사전 구축된 탐지 규칙 작업, 로그 분석 및 위협 헌팅을 위한 Discover 사용, 사용자 정의 대시보드 구축, Elastic Defend 경보 이해, 타임라인 조사 도구에 익숙해지기 등이 포함되었습니다.
연습 지침 자체에는 이 교육이 선택 사항이라고 명시되어 있지만, "적극 권장(" )하며, 저희가 확인한 바에 따르면 참석한 팀들은 실행 첫날에 완전히 성공했습니다. 교육과 지원은 기술 배포 자체만큼이나 중요합니다. 사용 방법도 모르는 엔터프라이즈급 보안 도구를 팀에 넘기는 것은 누구에게도 도움이 되지 않았을 것입니다.
온레인지 AI 서비스: 규정 준수, 감사, 가드 레일
올해는 DCM 제품군에 대한 AI 액세스를 제공하는 첫 해였습니다. 영국에 입주한 AWS 베드락 모델, 특히 eu-west-2(런던) 지역에서 운영되는 Claude 3.7 Sonnet을 통해 규정을 준수하는 AI 서비스를 직접 제공했습니다. 이는 AI를 위한 AI가 아니라 가드레일, 완벽한 감사 로깅, RBAC 인식 액세스 제어를 통해 신중하게 설계된 서비스입니다. AI 분야에서 쌓은 Elastic의 경험 덕분에 이 서비스를 운영할 수 있었습니다.
AI 서비스에는 여러 소비자들이 이용하고 있었으며, 이는 중요한 차이점입니다. 각 팀의 공간에 프로비저닝한 규정을 준수하는 Bedrock 커넥터는 사용자 정의 에이전트를 지원할 뿐만 아니라 특히 Elastic의 기본 AI 기능도 지원했습니다:
Elastic AI Assistant for Security
Elastic AI Assistant는 온레인지 Bedrock 커넥터에 연결된 모든 Blue Team 공간에서 사용할 수 있습니다. 이를 통해 팀은 Elastic Security 내에서 바로 상황 인식 채팅 인터페이스를 통해 경보에 대해 질문하고, ES|QL 쿼리 작성에 도움을 받고, 의심스러운 프로세스를 조사하고, 해결 단계 안내를 받을 수 있게 되었습니다. AI 어시스턴트는 Elastic 보안 연구소의 문서로 미리 채워진 Elastic의 지식 기반 기능과 함께 검색 증강 생성(RAG)을 사용합니다. 또한 팀은 범위별 SOP, 위협 인텔리전스 또는 팀 노트와 같은 자체 문서를 지식창고에 추가하여 운영 상황에 맞는 어시스턴트의 대응을 더욱 구체화할 수 있습니다.
연습 상황에서 이 기능이 특히 유용했던 이유는 경험이 적은 분석가도 자신이 보고 있는 내용을 이해할 수 있도록 도와주는 AI 어시스턴트의 능력 덕분이었습니다. 처음 실시간 임플란트 비콘을 접하는 주니어 분석가는 어시스턴트에게 알림을 설명하고, 조사 단계를 제안하고, 사고 보고서 초안을 작성하는 데 도움을 요청할 수 있습니다. 데이터 익명화 설정을 통해 민감한 필드 값은 LLM 제공업체로 전송되기 전에 난독화할 수 있습니다.
Elastic 공격 탐색
Attack Discovery는 온레인지 AI 서비스의 또 다른 중요한 고객이었습니다. 공격 발견은 LLM을 사용하여 팀 환경의 경고를 분석하고 경고, 행동 및 공격 경로를 상호 연관시켜 위협을 식별합니다. 각 "발견" 은 잠재적 공격을 나타내며 여러 경보 간의 관계를 설명하여 팀에게 어떤 사용자와 호스트가 관련되어 있는지, 경보가 MITRE ATT& CK 매트릭스에 어떻게 매핑되는지, 어떤 위협 행위자가 책임이 있을 수 있는지 알려줍니다.
레드팀이 적극적으로 조직적인 공격을 개시한 사이버 훈련에서 공격 발견은 혁신적인 역할을 했습니다. 수백 개의 개별 경보를 수동으로 분류하는 대신, 블루팀은 공격 검색을 실행하여 높은 수준의 공격 내러티브를 파악할 수 있습니다(예: "이 15 경보는 모두 위협 행위자 Z가 호스트 X에서 호스트 Y로 이동하는 측면 이동 체인의 일부입니다") 그리고 가장 중요한 곳에 조사 시간을 집중할 수 있습니다. 이는 평균 대응 시간을 직접적으로 단축하고 경보 피로를 해소하는 기능으로, 5일 연속 공격을 받을 때 꼭 필요한 기능입니다.
사용자 정의 AI 에이전트: Elastic 에이전트 빌더
기본 Elastic AI 기능 외에도 Elastic 에이전트 빌더를 사용해 세 개의 맞춤형 AI 에이전트를 구축했습니다. 에이전트 빌더는 LLM 명령과 재사용 가능한 모듈식 도구를 결합하는 사용자 정의 AI 에이전트를 구축하기 위한 Elastic의 프레임워크로, 각 도구는 ES|QL 쿼리, 기본 제공 검색 기능, 워크플로우 실행 또는 MCP를 통한 외부 통합이 됩니다. 에이전트는 자연어 요청을 구문 분석하고, 적절한 도구를 선택하고, 실행하고, 완전한 답변을 제공할 수 있을 때까지 반복하면서 Elasticsearch 내부의 데이터로 컨텍스트를 관리합니다. 프레임워크에 대한 자세한 내용은 에이전트 빌더 설명서 및 Elasticsearch Labs 심층 분석에서 확인할 수 있습니다.
우리가 활용했던 에이전트 빌더의 세 가지 핵심 구성 요소는 다음과 같습니다:
상담원: 상담원의 페르소나, 기능 및 행동 경계를 정의하는 사용자 지정 LLM 지침 및 할당된 도구 세트입니다. 각 상담원에게는 임무, 액세스할 수 있는 도구, 응답 구조를 제어하는 시스템 프롬프트가 있습니다.
도구: 도구: 에이전트가 Elasticsearch 데이터를 검색, 검색 및 조작하는 데 사용하는 모듈식 기능입니다. 연습 문서, 플레이북, 보고서가 포함된 특정 인덱스를 쿼리하는 사용자 지정 ES|QL 도구를 구축했습니다.
상담원 채팅: 참가자들이 상담원과 상호 작용하는 데 사용하는 대화형 인터페이스(기본 제공 Kibana UI와 프로그래밍 방식의 API 모두)입니다.
에이전트 및 툴 구성은 JSON으로 정의되고 에이전트 빌더 API를 통해 관리되므로 프롬프트 엔지니어링부터 툴 바인딩까지 전체 에이전트 수명 주기를 재현 가능하고 버전 제어할 수 있습니다. 이 접근 방식을 복제하고자 하는 사람들을 위해 후속 게시물에서 GrantPT 에이전트 구성 및 도구 정의를 공유할 예정이니 이 공간을 지켜봐 주세요.
각 상담원이 수행한 작업은 다음과 같습니다:
1. GrantPT - 범용 어시스턴트
약 2,500명의 연습 참가자가 모두 사용할 수 있었던 GrantPT는 당사의 주요 AI 에이전트이자 에이전트 빌더를 통해 얼마나 간단하게 유능한 도메인별 어시스턴트를 구축할 수 있는지를 가장 잘 보여준 사례였습니다. 에이전트의 구성은 시스템 프롬프트, 페르소나 및 바인딩된 툴 ID 배열을 정의하는 JSON 개체로 구성되었습니다. 사용자 지정 애플리케이션 코드나 맞춤형 API 계층 없이 선언적 구성만 가능합니다.
GrantPT에 깊이를 더한 것은 툴링이었습니다. 저희는 기본 제공 플랫폼 도구와 사용자 정의 ES|QL 도구를 혼합하여 정의했으며, 각각 설명, 매개변수화된 쿼리 및 입력된 매개변수 정의로 등록했습니다. 예를 들어, 지식창고 도구는 target_index 및 시맨틱 query 매개변수를 받아 시맨틱 검색 순위가 있는 dcm5-grantpt-* 인덱스에 대해 매개변수화된 ES|QL 쿼리를 실행했습니다:
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10별도의 색인 검색 도구를 사용하면 상담원이 각 대화를 시작할 때 사용 가능한 지식창고 색인을 동적으로 열거할 수 있으므로 상담원을 재구성하지 않고도 연습 중에 새 문서 색인을 추가할 수 있으며, 다음 상호작용에서 색인을 검색하기만 하면 됩니다.
또한 수집된 헬프데스크 티켓에서 시맨틱 검색을 수행하는 Jira 통합 도구를 구축하여 GrantPT가 이전 지원 요청에서 관련 문제 해결 컨텍스트를 표시할 수 있도록 했습니다. 이는 특히 헬프데스크 분석가에게 유용했는데, 이들은 반복되는 문제에 대해 GrantPT에 문의하고 일반적인 지침이 아닌 실제 티켓 기록에 근거한 답변을 얻을 수 있었습니다.
RBAC 맞춤형 응답 동작은 사용자의 역할에 따라 상황에 맞는 답변을 제공하도록 지시하는 에이전트의 시스템 프롬프트와 기본 Elasticsearch 보안 모델의 조합에서 비롯되었습니다. 각 도구의 ES|QL 쿼리는 사용자의 보안 컨텍스트 내에서 실행되므로 에이전트는 사용자의 역할에 액세스할 수 있는 문서만 표시할 수 있습니다. 운동 절차에 대해 문의하는 블루팀원은 팀의 접근 가능한 인덱스에 한정된 결과를 볼 수 있고, 헬프데스크 애널리스트는 헬프데스크 관련 인덱스의 결과를 볼 수 있습니다. 에이전트는 명시적인 역할 전환 로직이 필요하지 않았습니다. Elasticsearch의 기본 문서 수준 보안이 스코핑을 처리하고 에이전트는 반환되는 모든 결과를 가지고 작업하기만 하면 되었습니다. 이것은 에이전트 빌더를 진정으로 우아하게 만드는 요소 중 하나입니다. Elasticsearch의 보안 모델을 상속함으로써 한 줄의 승인 코드도 작성하지 않고도 RBAC 인식 AI를 얻을 수 있습니다.
2. 레드록 - 적의 동반자
이 에이전트는 레드 팀만 사용할 수 있었습니다. 레드록은 적대적 페르소나를 정의하는 전용 시스템 프롬프트인 에이전트 빌더 패턴을 따라 레드팀 전용 인덱스를 쿼리하는 자체 맞춤형 ES|QL 도구 세트에 바인딩했습니다. 이러한 인덱스에는 레드팀 플레이북, Tuoni C2 문서, 범위 환경 내에서 알려진 시스템 취약점, 배포된 서비스에 대한 정보가 포함되어 있습니다. 도구 정의는 GrantPT에서 사용하는 것과 동일한 매개변수화된 시맨틱 검색 패턴을 반영했지만, 레드팀 역할만 액세스할 수 있는 인덱스로 범위가 한정되었습니다. 레드팀 운영자는 공격 벡터를 쿼리하고, 표적 시스템의 알려진 취약점을 확인하고, 운영 계획에 대한 상황별 지침을 얻을 수 있습니다. 솔직히 말해서 공격자들에게 매우 잘 훈련된 작전 책임자를 제공한 것과 같았습니다.
3. RefPT - 심판의 도구
화이트 팀(연습 심판 및 평가자)을 위해 특별히 제작된 RefPT는 블루 팀 보고서, 시나리오 이벤트 및 채점 기준이 포함된 지표를 쿼리하는 도구에 묶여 있었습니다. 그 목적은 40개 이상의 모든 팀에서 균일하고 공정한 채점을 보장하는 것이었습니다. 상담원의 시스템 프롬프트는 제출된 보고서를 알려진 시나리오 이벤트 및 채점 루브릭과 상호 참조하도록 조정되어 평가자가 불일치 또는 격차를 식별하는 데 도움이 됩니다. 평가자가 수십 개의 팀을 동시에 평가하는 경우, 구조화된 채점 지표에 따라 보고서를 상호 연관시킬 수 있는 AI가 있으면 일관성을 위해 진정으로 혁신적인 변화를 가져올 수 있습니다.
Tines: AI 기반 워크플로 자동화
Tines도 온레인지 AI 서비스의 소비자였습니다. 각 블루팀에는 전용 Tines 인스턴스가 있으며, Kibana 공간에 Tines 액션 커넥터가 프로비저닝되어 있습니다. Tines는 자동화된 알림 강화, AI 지원 분류 결정, 알림 워크플로우의 자연어 요약, 자연어 워크플로우 생성 등 지능형 워크플로 자동화를 위해 Bedrock이 지원하는 AI 기능을 활용할 수 있습니다. Tines 커넥터는 Vault에 저장된 자격 증명을 사용하여 팀별로 구성되었습니다:
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/"
})
}규정 준수 보장: 가드 레일 및 감사
이러한 모든 소비자에 대한 모든 AI 상호 작용은 엄격한 AWS 베드락 가드레일의 적용을 받습니다. 콘텐츠 필터링(혐오, 모욕, 성적 콘텐츠, 폭력 콘텐츠는 중간 임계값으로 차단), 개인 정보 보호(이메일 주소, 전화번호, 이름, 주소, 영국 국민 보험 번호, 신용카드 번호, IP 주소 차단), 실제 기밀 업무에 대한 토론을 방지하기 위한 주제 기반 필터링, 욕설 필터링 기능을 갖춘 가드레일을 배포했습니다. 다음은 테라폼의 가드레일 구성의 일부입니다:
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"
}
}
}각 Blue Team 공간에는 Bedrock 액세스를 위한 자체 IAM 사용자가 있었고, 팀이 자체 커넥터를 구성하지 못하도록 genAiSettings:defaultAIConnectorOnly Kibana 설정이 적용되었습니다. 즉, CloudWatch를 통해 모든 API 호출을 특정 팀으로 추적할 수 있고 NSOC는 완벽한 감사 가시성을 확보할 수 있었습니다. CloudWatch 로그 그룹( /aws/bedrock/grantpt-prod/invocations )은 모든 호출 및 가드레일 이벤트를 캡처했습니다.
모든 AI 소비자에 대한 수치는 다음과 같습니다: 3 맞춤형 AI 에이전트, 2,797건의 대화, 785 연습 기간 동안 소비된 AI 토큰 백만 개.
게임 내 실시간 모니터링
연습 시나리오에서 각 팀은 온레인지 메시징 클라이언트로 RocketChat에 액세스했습니다. 모든 블루팀에게는 자체 채널이 주어지고, 운동에 참여하는 모든 사람에게 쪽지를 보낼 수 있으며, 필요에 따라 자유롭게 새 채널을 개설할 수 있습니다. DCM 전통에서 가장 중요한 것은 밈 채널인데, 이는 모든 팀 간 갈등의 정신적 지주이자 수천 명의 사이버 요원들을 일주일 동안 압박감에 몰아넣을 때 필연적으로 나타나는 창의적인 사기 진작 유머입니다.
이 모든 커뮤니케이션 데이터는 운동 범위의 건강 상태, 팀 분위기, 운동 전반에 걸쳐 유행하는 주제를 실시간으로 파악할 수 있는 훌륭한 창입니다. 그냥 지나치기에는 너무 좋은 기회라고 생각되어 전체 RocketChat 대화 말뭉치를 실시간으로 Elastic으로 수집하여 작업에 적용했습니다.
감성 분석 및 명명된 개체 인식
명명된 엔티티 인식을 위해, 우리는 Elastic ELAND 클라이언트를 사용해 NSOC 배포의 머신 러닝 노드에 Hugging Face의 dslim/bert-base-NER 모델을 배포했습니다. 그런 다음 모든 RocketChat 메시지가 수집될 때 통과하는 Elasticsearch 수집 파이프라인에 연결되었습니다. 추출된 엔터티를 가져와 가장 일반적인 엔터티를 대시보드 테마로 표시하여 연습 내내 대화 주제의 썰물과 흐름을 실시간으로 볼 수 있게 했습니다.
또한 그룹 활동, 사용자 통계, 일반적인 커뮤니케이션 패턴을 분석하여 가장 활발한 참여자, 시간대별 메시지 양, 개별 사용자의 감정 동향 등 각 팀의 생활 패턴에 대한 그림을 구축했습니다. 이를 통해 거의 실시간으로 사격장에서 일어나는 일에 대한 흥미로운 인사이트를 얻을 수 있었습니다. 예를 들어, Elastic Agent를 예방 모드로 전환하자 대시보드의 워드 클라우드에 즉시 "Elastic" 이 모든 채널에서 가장 많이 논의된 주제로 표시되었습니다. 블루팀은 그 효과에 대해 논의하고, 레드팀은 비콘을 잃어버렸다고 한탄했습니다. 오히려 만족스럽습니다.
밈 분석(예, 정말)
마지막으로 - 그리고 이 밈은 많은 사람들의 이목을 집중시켰습니다 - 채널에 제출된 모든 밈을 가져와 이미지를 벡터화한 후 가장 가까운 이웃 평가를 실행하여 유사한 밈과 주제를 한데 묶었습니다. 또한 각 밈의 콘텐츠에 대한 주제별 설명을 생성하기 위해 제로 샷 NER 추론 모델을 통과시켰습니다. 이러한 출력은 나중에 필터링, 중재 또는 기타 게임 내 상호작용에 유용하게 사용될 수 있다는 논리였습니다. 밈 분석을 통해 운영상 중요한 정보를 얻을 수 있었는지는 논란의 여지가 있습니다. 재미있었는지 여부는 중요하지 않습니다.
문제 발생의 싹을 잘라내기
운동 주간 동안 모든 것이 원활하게 진행되기를 바랐지만, 불가피하게 문제가 발생하거나 완전히 이해되지 않거나 특정 팀의 사용 방식에 맞게 추가 사용자 지정이 필요한 경우가 있습니다. 이를 위해 모든 팀에서 Elastic 및 GenAI 관련 요청을 제기할 수 있는 자체적인 헬프데스크 하위 섹션을 마련했습니다.
연습 기간 내내 헬프데스크를 운영하며 지침, 문서화, 문제 디버깅, 범위별 권장 사항을 제공했습니다. 마지막 요점은 좀 더 자세히 설명할 필요가 있습니다. 때로는 블루팀이 Elastic에서 보고 있던 것이 실제로는 Elastic의 문제가 아니라 추가 조사가 필요한 범위의 문제를 충실히 드러낸 것일 수도 있습니다(레드팀은 절대적인 혼란을 야기할 수 있으며 원격 분석은 거짓말을 하지 않습니다). 연습이 진행되는 동안 Elastic에 특별히 도움을 요청하는 팀들의 개별 지원 요청( 125 )을 다루었습니다.
Tines를 사용한 선제적 디버깅
VTC를 통해 팀을 방문하거나 EXCON에서 직접 만나는 것 외에도, 저희는 Tines와 협력하여 좀 더 적극적인 방법을 시도했습니다. 수신 요청에서 티켓 본문을 가져와 문제를 분류하고, 이전에 해결된 티켓의 말뭉치와 비교하여 분류를 실행한 다음, 분류를 통해 대기열로 가져오기 전에 사용자의 문제를 해결하기 위한 요약된 1차 응답을 GenAI가 생성하도록 했습니다.
이것은 실제로 Elastic의 자체 지원 조직에서 차용한 패턴으로, 이전에 해결된 문제에 대한 광범위한 지식 기반을 AI 에이전트 컨텍스트 지원을 위한 저장소로 사용하여 유사한 기능을 제공하고 있습니다. 과거의 솔루션을 사용하여 기계가 정보를 바탕으로 문제를 해결하기 위한 첫 번째 단서를 제공하고, 지원 엔지니어가 모든 티켓을 수동으로 처리할 필요성을 줄이자는 간단한 아이디어입니다. 모든 문제를 해결한 것은 아니며, 일부 문제는 범위 컨텍스트를 가진 사람이 진정으로 필요했지만 대기열 부담을 의미 있게 줄이고 필요한 팀에 더 빠른 답변을 제공했습니다. 특정 티켓과 대기열이 매우 성공적이어서 연습 후반부에는 실제로 전체 헬프데스크로 송금을 확대하여 연습을 지원하는 Green 팀의 다른 그룹의 부하를 줄이는 데 도움을 주었습니다.
업계 파트너십: 함께하면 더 좋습니다
가장 자랑스러운 점 중 하나는 파트너십 생태계가 해마다 성장하고 있다는 점입니다. DCM은 단순한 Elastic 쇼가 아니라 보안 플랫폼에 각각 고유한 것을 제공하는 업계 파트너들의 진정한 연합체입니다.
연도 1 (DCM2) - Elastic이 업계 파트너로 합류하여 보안 모니터링 및 엔드포인트 탐지 플랫폼을 제공했습니다.
연도 2 (DCM3) - 1:1 패킷 캡처 기능을 제공하는 Endace를 도입했습니다. Elastic의 네트워크 가시성과 함께 전체 패킷 캡처를 통해 팀은 로그 기반 분석만으로는 제공할 수 없는 심층 포렌식을 수행할 수 있게 되었습니다.
연도 3 (DCM4 ) - Tines가 합류하여 워크플로 자동화를 도입했습니다. 이제 Blue팀은 자동화된 대응 플레이북, 분류 워크플로우, 알림 체인을 구축할 수 있으며, 이 모든 것이 기본 Tines 커넥터를 통해 Elastic 환경에 직접 통합됩니다.
연도 4 (DCM26, 이전 DCM5 ) - AWS가 합류하여 AI 에이전트를 위한 Bedrock 액세스를 제공하고 Elastic 배포를 위한 자금 지원에 기여했습니다. 하이퍼스케일러가 이 연습의 성공에 직접 투자함으로써 다른 방법으로는 불가능했을 기능(완전한 가드레일 및 감사 로깅을 갖춘 규정을 준수하는 영국 테넌트 AI 추론 등)을 확보할 수 있었으니 이는 중요한 이정표였습니다. 올해 Tines의 통합은 LLM에 대한 온레인지 액세스를 추가하여 더욱 강화되었습니다. DCM 시리즈는 올해 육군 사이버 협회 이니셔티브로 시작하여 사이버 및 특수작전사령부 산하 공식 자금 지원 프로그램으로 전환하는 이정표를 세웠습니다.
Endace, Tines, AWS의 팀원들에게 진심으로 감사드립니다. 여러분의 기여 덕분에 이 운동은 더 좋아졌고, 우리가 함께 구축한 플랫폼 덕분에 모든 팀은 더 나은 장비를 갖추게 되었습니다. 이미 DCM27을 계획하고 있습니다. 많은 분들께 건배합니다.
문화, 볼거리 및 가치 있는 정보
챌린지 코인
저희는 DCM26을 위해 맞춤형 챌린지 코인을 발행했습니다. 아시다시피 챌린지 코인은 오랜 군대 전통으로, 이번 행사를 위해 코인을 제작하는 것이 4주년을 기념하는 적절한 방법이라고 생각했습니다.
칵테일 파티
또한 싱가포르 주재 영국 고등판무관이 주최한 고등판무관 칵테일 파티에 초대받게 되어 감사했습니다. 대사의 초대로 진토닉을 마시며 Elasticsearch 샤드 수와 Terraform 상태 관리에 대해 논의하는 것은 꽤나 초현실적인 일이었습니다. 기술과 외교의 교차점에 이러한 훈련이 존재하며, 여기서 구축된 관계는 기술적 차원을 훨씬 뛰어넘는다는 것을 상기시켜주는 멋진 저녁이었습니다.
Wrapping up
멀티테넌트 아키텍처는 지속적인 부하에서도 그 성능을 입증했고, 기본 Elastic AI 기능(AI Assistant 및 공격 탐색)은 몇 년 전만 해도 공상 과학 소설에나 나올 법한 기능을 팀에 제공했으며, 맞춤형 AI 에이전트는 채택에 대한 우리의 기대치를 뛰어넘었습니다. 파트너십 모델은 방위 훈련에 대한 업계의 참여가 단일 조직이 단독으로 달성할 수 없는 성과를 창출한다는 것을 지속적으로 입증하고 있습니다.
디펜스 사이버 마블( 2026 )은 야망과 복잡성, 영향력이 계속 커지고 있는 훈련의 획기적인 반복이었습니다. Elastic에게 있어서, 29 국가의 40 블루팀에 핵심 방어 보안 플랫폼을 제공하고, 올해에는 AI 기능까지 제공하게 된 것은 결코 가볍게 여기지 않는 일입니다. 이 훈련은 실제 네트워크를 방어할 실제 사람들을 위한 실제 기술을 개발하며, 그 임무의 일부가 되는 것은 진정으로 의미 있는 일입니다.
영국 정부의 보도 자료에서 말했듯이 DCM은 국제 파트너십을 강화하는 실제 시나리오의 실질적인 가치를 보여줍니다. 전적으로 동의합니다.
내년에 다시 만나면 더 많은 이야기를 나눌 수 있을 것 같습니다. 그 동안에도 지속적으로 제품을 개선하여 매년 디펜스 사이버 마블과 같은 환경에 대한 지원이 더욱 향상될 수 있도록 노력할 것입니다.
연습장에서 뵙겠습니다.
소셜 미디어에서 DCM26 스토리를 팔로우하세요:
추가 읽기
Elastic Security & AI
- Elastic Security - 블루팀 배포를 지원하는 플랫폼
- 보안을 위한 AI 어시스턴트 - Elastic Security 내의 상황 인식 AI 채팅
- 공격 발견 - LLM 기반 경보 상관관계 및 위협 내러티브 생성
- 에이전트 빌더 - Elasticsearch로 사용자 정의 AI 에이전트를 구축하기 위한 프레임워크
인프라 & 툴링
- Elastic Stack Terraform 공급자 - Elastic Stack을 위한 코드로서의 인프라
- Elastic Fleet Guide - 대규모 Elastic 에이전트를 중앙에서 관리하기
- 클래리파이드 시큐리티의 캐터펄트 - Ansible 기반 사이버 범위 프로비저닝
운동 컨텍스트
- 영국 정부 DCM26 보도 자료 - 훈련의 공식 개요