블로그

Defence Cyber Marvel 2026에서 만난 Elastic: 훈련 현장에서 전하는 기술 개요

영국 국방부의 대표 사이버 훈련인 Defence Cyber Marvel 2026을 지원하기 위해 배포된 Elastic Security 및 AI 인프라 개요입니다.

James Garside
보안 운영

어디서부터 시작해야 할까요. Elastic이 영국 국방부의 대표 사이버 훈련 시리즈인 Exercise Defence Cyber Marvel에 4년 연속 신뢰할 수 있는 업계 파트너로 참여하는 영광을 안았습니다. DCM26은 의심할 여지 없이 여태껏 가장 야심 찬 시도였으며, Elastic이 무엇을 어떻게 구축했는지와 그 과정에서 무엇을 배웠는지 마침내 이야기할 수 있게 되어 대단히 기쁩니다.

Defence Cyber Marvel이란?

생소하신 분들을 위해 설명하자면, Defence Cyber Marvel(DCM)은 현실적이고 압박감이 높은 시나리오에서 기존 IT 네트워크, 기업 환경 및 복잡한 산업 제어 시스템을 방어하는 데 중점을 둔 영국 최대 규모의 군사 사이버 훈련 시리즈입니다. 여기에서는 국방 및 동맹국 전반의 준비 태세, 상호 운용성 및 복원력을 강화하는 동시에 책임 있는 사이버 역량을 선보입니다. 올해로 5회를 맞는 DCM은 육군 사이버 협회(Army Cyber Association)의 이니셔티브에서 사이버 및 특수 작전 사령부(CSOC)가 주도하는 3군 합동 작전으로 발전했습니다.

영국 정부가 발표한 DCM26 공식 보도자료는 이번 훈련의 전략적 중요성에 대한 훌륭한 개요를 제공합니다. 주싱가포르 영국 고등판무관이 언급했듯이, 이번 훈련은 영국과 신뢰할 수 있는 파트너 간의 긴밀한 협력을 보여주며, 점점 더 복잡해지는 보안 환경에서 공유되는 전략적 파트너십의 강력함을 상기시켜 줍니다.

DCM의 핵심은 대항형 사이버 훈련이라는 것입니다. 방어를 담당하는 블루 팀은 다양한 기법을 사용하여 공격하는 레드 팀으로부터 할당된 네트워크와 인프라를 보호합니다. 활동은 기본 비밀번호 변경 및 방화벽 강화부터 Elastic Security를 활용한 엔터프라이즈급 AI 기반 사이버 방어 배포에 이르기까지 다양합니다. 각 팀의 활동은 화이트 팀이 모니터링하여 시스템 가용성, 공격 탐지, 사고 보고 및 시스템 복구를 반영한 점수를 산정합니다. DCM은 가장 경험이 풍부한 팀에는 도전 과제를, 처음으로 사이버 훈련장을 접하는 주니어 팀에는 독특한 교육 수단을 제공하며, 이러한 두 가지 목적은 DCM을 매우 가치 있는 훈련으로 만듭니다.

DCM26의 규모

DCM26에는 29개 참가국과 70개 기관에서 2,500명 이상의 인원이 모였으며, 싱가포르에 위치한 중앙 훈련 통제소(EXCON)에서 조율을 진행하고 EXCON에 600명 이상의 참가자가 모였습니다. 이 훈련은 CR14 사이버 훈련장과 AWS에 걸친 하이브리드 컴퓨팅 환경에서 실행되었으며, 5,000개 이상의 가상 시스템을 호스팅했습니다.

훈련 자체는 2026년 2월 9일부터 2026년 2월 13일까지 5일 간의 실행 기간 동안 진행되었으며, 그에 앞서 선택 사항인 강사 주도형 사전 교육 및 연결 상태 점검이 이뤄졌습니다. 국방 아카데미 교육 환경(DATE) 인도태평양 작전 환경을 기반으로 구축된 이 시나리오는 팀에 지역 위기가 고조되는 동안 배치된 군사 시스템을 방어하는 사이버 보호 팀의 역할을 맡겼습니다. 블루 팀은 지리적으로 분산되어 있었는데, 일부는 영국 전역 및 해외에서 각자 위치에 있었고 다른 일부는 해외에 배치되어 모두 VPN을 통해 훈련 환경에 연결했습니다.

참가자에는 영국 국방부, 국가범죄수사청, 노동연금부, 내각부, 기업통상부 등 범정부 부처의 대표들과 최대 40개 팀으로 구성된 국제 파트너가 포함되었습니다. 지난해 대한민국에서 실시한 훈련의 성공에 이어, 싱가포르가 처음으로 훈련 허브 역할을 했으며, 이는 공동의 보안 과제에 대해 인도·태평양 파트너들과의 협력을 심화하려는 영국의 의지가 반영된 것입니다.

간단히 말해, 이는 엄중한 훈련입니다. 높은 압박감 속에서 이루어지는 쌍방 대항 훈련으로, 점수에 실질적인 영향이 발생할 뿐만 아니라 모든 참가자에게 실질적인 학습 성과를 제공합니다.

배포: 우리의 Elastic 인프라

올해의 인프라는 이전에 비해 상당한 아키텍처적 진화를 보여주었습니다. 팀별로 개별 Elastic Cloud 클러스터를 배포하는 대신, 블루 팀을 위한 단일 공간 기반 멀티 테넌트 Elastic Cloud 배포로 전환했습니다. 또한 블루 팀 외부 기능을 위한 배포도 제공했습니다. 각 배포와 그 존재 이유를 자세히 살펴보겠습니다.

블루 팀: 멀티테넌트 Elastic Security

Elastic 기여의 핵심은 Kibana 스페이스와 데이터스트림 네임스페이스를 사용하여 구분되며 40개의 방어 블루팀 전체를 지원하는 단일 Elastic Cloud 배포였습니다. 39개 팀이 각각 대시보드, 에이전트 및 탐지 규칙을 포함하여 자체적으로 격리된 작업 공간을 보유했습니다.

각 팀의 스페이스를 생성하기 위한 Terraform 리소스는 다음과 같습니다.

# 40개의 블루 팀 스페이스 생성
resource "elasticstack_kibana_space" "blue_team" {
  count = var.team_count

  space_id    = local.space_ids[count.index]
  name        = "블루 팀 ${local.team_numbers[count.index]}"
  description = "공간 인식 Fleet 가시성을 갖춘 BT-${local.team_numbers[count.index]}용 격리된 스페이스"

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

각 팀의 스페이스에는 세 가지 전용 Fleet 에이전트 정책이 제공되었습니다. 1일 차에는 배포형 네트워크 정책, 2일 차에는 호스트 국가 네트워크 정책, 마지막으로 네트워크 트래픽 모니터링을 위한 PacketCapture 정책이었습니다. 단계별 액세스 제어는 단순하면서도 명확했습니다. 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 보안 역할은 해당 데이터 스트림으로만 범위가 지정되었습니다.

# 배포된 데이터 스트림(항상 부여됨)
indices {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# HostNation 데이터 스트림 (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 텔레메트리를 위한 System, 엔드포인트 탐지 및 응답을 위한 Elastic Defend, Windows 이벤트 전달, Linux 감사 로깅을 위한 Auditd, Network Packet Capture 통합이 제공되었습니다. 이는 Elastic Stack Terraform Provider를 통해 코드로 관리되는 400개 이상의 통합 정책입니다.

Elastic Defend에 대한 참고 사항: 미국 국방부 및 정보기관(IC)이 프로덕션 환경에서 신뢰하는 Elastic 엔드포인트 보호 기능(자세한 내용은 여기에서 확인)의 뛰어난 효과와 훈련 과정에서 제로데이 익스플로잇을 소모할 사람은 아무도 없다는 점 때문에, 불가피하게 예방 모드를 비활성화하고 탐지 전용 모드로만 유지하여 Elastic Defend의 기능에 제약을 두었습니다. 악의적인 행위가 발생하면 팀에 경보가 전송되지만, 자동 완화 조치는 실행되지 않습니다. 또한 메모리 위협 방지 및 탐지도 완전히 비활성화했습니다. 이 기능이 공격팀의 임플란트와 비콘의 대부분을 찾아내어 레드 팀의 훈련을 망칠 수 있기 때문입니다. 훈련이 끝날 무렵에는 팀들이 Elastic Defend의 모든 기능을 자유롭게 활용할 수 있도록 허용했으나, 이는 레드 팀이 확고한 거점을 마련한 이후였습니다.

또한 Elastic의 사전 구축된 탐지 규칙을 각 팀 스페이스에 사전 설치했습니다. 오픈 리포지토리에서 지속적으로 업데이트되는 Elastic Security Labs의 전체 세트입니다. 이러한 규칙은 팀의 네임스페이스 범위 권한이 허용하는 인덱스만 쿼리하도록 설정되어, 탐지 규칙 실행 시 팀 간 데이터 유출을 방지합니다.

또한, 각 팀 스페이스의 Security Solution 기본 인덱스는 기본 광범위 패턴 대신 해당 팀의 데이터 스트림으로만 탐지 규칙의 범위를 지정하도록 구성되었습니다. 이는 각 스페이스의 securitySolution:defaultIndex를 설정하기 위해 Kibana 내부 설정 API를 호출하는 Terraform null_resource를 통해 처리되었습니다.

최고점에서 이 배포는 40개 팀 전체에서 초당 800,000개의 이벤트(EPS)를 수집했습니다. 이는 상당한 양의 데이터이며, 클러스터는 Elastic Cloud의 자동 확장 기능 덕분에 이를 무리 없이 처리했습니다. 뿐만 아니라 Elastic은 2018년에 이미 eBay와 함께 초당 500만 개의 이벤트를 처리했습니다.

데이터 수명 주기는 1일 또는 50GB(둘 중 먼저 도달하는 기준) 후 인덱스를 롤오버하고, 읽기 전용 최적화 및 강제 병합을 위해 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 스페이스를 배포하고, 각 스페이스에 에이전트 정책을 생성한 뒤, 6,000개의 EC2 인스턴스(3개 가용성 영역의 6개 서브넷에 걸쳐 테넌트당 120개)를 시작하고, 전체에 대해 부하 테스트를 진행하는 것이었습니다. AutoOps와 Stack Monitoring으로 모든 것을 모니터링했습니다.

배포 흐름은 다음과 같이 진행되었습니다. Terraform이 3개 가용 영역에 걸쳐 VPC와 서브넷을 생성하고, 50개의 Kibana 스페이스 및 해당 스페이스 범위의 Fleet 정책을 프로비저닝하고, 등록 토큰을 생성한 다음, EC2 인스턴스를 배치로 시작했습니다. 각 인스턴스는 부팅 시 Elastic Agent를 설치하고 해당 스페이스별 토큰으로 등록했습니다.

그 과정에서 몇 가지 흥미로운 문제에 부딪혔습니다. 당시 표준 Elastic Stack Terraform Provider는 스페이스 인식 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분 이내에 등록되었습니다. 테스트에서 스페이스 격리는 테넌트 간 데이터 유출이 관찰되지 않고 예상대로 작동했습니다. Fleet 정책 업데이트는 60초 이내에 모든 에이전트로 전파되었습니다. 개별 스페이스로 범위를 지정한 검색 쿼리는 최대 부하 상태에서도 빠른 속도를 유지했습니다. 또한 다중 AZ 분산은 시뮬레이션된 가용 영역 장애 발생 시에도 복원력이 입증되었습니다.

이러한 테스트를 통해 실전 훈련을 위한 아키텍처를 채택할 수 있다는 확신을 얻었습니다.

레드 팀: C2 임플란트 통합 가시성

명령 및 제어(C2) 임플란트 통합 가시성에 중점을 둔 별도의 전용 Elastic 배포가 레드 팀을 위해 구축되었습니다. 이를 통해 공격 팀은 블루 팀의 데이터와 혼선될 위험 없이 임플란트 상태, 비콘 콜백, 운영 진행 상황 등 자체 운영에 대한 가시성을 확보할 수 있었습니다. 레드 팀은 C2로 Clarified Security가 레드 팀을 위해 개발한 프레임워크인 Tuoni를 사용했습니다. DCM3에서는 Clarified Security와 협력하여 Elastic Common Schema를 제대로 지원하도록 함으로써 향후 Elastic과의 통합을 훨씬 수월하게 만들었습니다.

NSOC: 네트워크 보안 운영 센터 실습

핵심 훈련인 Network Security Operations Centre(NSOC)는 자체 Elastic 배포에서 실행되었으며, 훈련 통제 담당자에게 훈련장 상태에 대한 포괄적인 보기, 인프라 전반의 보안 모니터링, 그리고 특히 우리가 배포한 모든 AI 서비스에 대한 감사 로깅이 제공되었습니다. 모든 Bedrock API 호출이 CloudWatch에 기록되었습니다 이 배포에서 관찰할 수 있었습니다. 즉, NSOC는 AI 에이전트에 누가 무엇을 요청했는지 완전히 파악할 수 있었습니다. 이에 대한 자세한 내용은 아래 AI 섹션에서 확인할 수 있습니다.

인프라 자동화: Terraform 및 Catapult

위에서 살펴본 모든 내용은 코드형 인프라로 관리되었습니다. 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
  }
}

자동 확장이 지원되는 Elastic Cloud 배포 1개, Kibana 스페이스 40개, Fleet 에이전트 정책 120개(팀당 3개), 통합 정책 400개 이상, Kibana 보안 역할 40개, Keycloak 역할 매핑 40개, 데이터 보존을 위한 ILM 정책, Bedrock GenAI 커넥터용 AWS IAM 사용자 41개(팀 스페이스마다 1개 및 기본 1개), Kibana GenAI 액션 커넥터 41개, AWS Bedrock 가드레일, Tines 액세스용 Cloudflare Zero Trust 터널, 팀 스페이스별 Tines 액션 커넥터, HashiCorp Vault에 저장된 탐지 서비스 계정, 공간별 Security Solution 기본 인덱스 구성까지 Terraform으로 관리되는 총 리소스 규모는 상당했습니다. 모든 상태는 암호화된 S3 백엔드에 저장되었습니다.

실제 훈련장 시스템으로의 에이전트 및 프록시 배포에는 Clarified Security 팀이 구축한 뛰어난 오픈 소스 도구인 Catapult를 사용했습니다. Catapult는 사이버 훈련장 배포를 위해 특수 제작된 컨테이너 기반 실행 모델로 Ansible을 래핑합니다. 이를 통해 훈련장 인프라 전반에 걸친 Elastic Agent의 설치 및 등록을 처리했습니다. 프록시 서버 구성(각 팀은 배포된 네트워크를 위한 전용 Squid 프록시를 보유했으며, 이는 실제 환경과 마찬가지로 단일 송신 지점을 시뮬레이션하기 위한 것이었습니다. 트래픽은 http://elastic-proxy.dsoc.XX.dcm.ex:3128과 같은 엔드포인트를 통해 라우팅되었습니다) 및 Tines 연결을 위한 Cloudflare 터널의 배포도 처리했습니다.

프로비저닝하는 동안 자격 증명, 등록 토큰, API 키, 프록시 구성, Tines 서비스 계정 자격 증명이 Terraform에 의해 HashiCorp Vault에 기록되고 Catapult에서 사용되었습니다. 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 경보의 이해, Timeline 조사 도구 익히기 등이 포함되었습니다.

실습 안내서 자체에 이 교육이 선택 사항이지만 '적극 권장'된다고 명시되어 있었으며, Elastic이 확인한 바에 따르면 참석한 팀들은 실행 첫날부터 확실하게 빠르게 역량을 발휘했습니다. 교육 및 지원은 기술 배포 자체만큼이나 중요합니다. 사용 방법을 모르는 엔터프라이즈급 보안 도구를 팀에 제공하는 것은 그 누구에게도 도움이 되지 않았을 것입니다.

온레인지 AI 서비스: 규정 준수, 감사 완료, 가드레일 적용

올해에는 DCM 제품군에 AI 액세스를 제공하기 시작했습니다. 영국 테넌트 AWS Bedrock 모델, 특히 eu-west-2(London) 리전에서 실행되는 Claude 3.7 Sonnet을 기반으로 DCM 제품군에서 직접 규정을 준수하는 AI 서비스를 제공했습니다. 이는 AI 자체를 위한 AI가 아니라 가드레일, 완전한 감사 로깅 및 RBAC를 고려한 액세스 제어를 갖춘 신중하게 설계된 서비스였습니다. AI 분야에서 쌓은 Elastic의 경험 덕분에 이 서비스 운영에 대한 신뢰를 얻을 수 있었습니다.

AI 서비스는 훈련장에 여러 소비자를 보유하고 있었으며, 이는 중요한 차이점입니다. 각 팀 스페이스에 프로비저닝한 규정 준수 Bedrock 커넥터는 커스텀 에이전트만 지원한 것이 아니라 다음과 같은 Elastic의 기본 AI 기능도 지원했습니다.

Elastic AI Assistant for Security

Elastic AI Assistant는 온레인지 Bedrock 커넥터에 연결되어 모든 블루 팀 스페이스에서 사용할 수 있었습니다. 이를 통해 팀은 Elastic Security 내에서 바로 컨텍스트를 인식하는 채팅 인터페이스를 활용하여, 알림에 대해 질문하고, ES|QL 쿼리 작성 지원을 받고, 의심스러운 프로세스를 조사하며, 단계별 조치 가이드를 받을 수 있었습니다. AI Assistant는 미리 Elastic Security Labs 문서로 채워진 Elastic의 지식 기반 기능과 함께 검색 증강 생성(RAG)을 사용합니다. 또한 팀은 훈련장별 SOP, 위협 인텔리전스 또는 팀 노트와 같은 자체 문서를 지식 기반에 추가하여 어시스턴트의 응답을 운영 컨텍스트에 더욱 밀접하게 연계할 수 있었습니다.

이 훈련 컨텍스트에서 특히 가치 있었던 것은 AI Assistant가 경험이 적은 분석가가 자신이 보고 있는 내용을 이해할 수 있도록 도와준다는 점이었습니다. 처음 라이브 임플란트 비콘을 마주한 주니어 분석가는 어시스턴트에게 경보에 대한 설명과 조사 단계에 대한 제안을 요청하고 인시던트 보고서 작성에 대한 도움까지 받을 수 있었습니다. 데이터 익명화 설정을 통해 민감한 필드 값이 LLM 제공업체로 전송되기 전에 난독화할 수 있었습니다.

Elastic Attack Discovery

Attack Discovery는 당사의 온레인지 AI 서비스를 주로 사용한 또 다른 주요 기능입니다. Attack Discovery는 LLM을 활용하여 팀 환경 내의 경보를 분석하고 경보, 행동 및 공격 경로 간의 상관관계를 파악하여 위협을 식별합니다. 각 '탐지'는 하나의 잠재적 공격을 나타내며 여러 경보 간의 연관 관계를 설명하여 팀에 어떤 사용자와 호스트가 관련되어 있는지, 경보가 MITRE ATT&CK 매트릭스에 어떻게 맵핑되는지, 어떤 위협 행위자가 배후에 있을 수 있는지를 알려줍니다.

레드 팀이 조직적인 공격을 적극적으로 실행한 사이버 훈련에서 Attack Discovery는 혁신적인 변화를 가져왔습니다. 블루 팀은 수백 개의 개별 경보를 수동으로 분류하는 대신 Attack Discovery를 실행하여 "이 15개의 경보는 모두 호스트 X에서 호스트 Y로 이어지는 측면 이동 체인의 일부이며, 위협 행위자 Z에 의한 것일 가능성이 높습니다"와 같은 상위 수준의 공격 내러티브를 파악하고, 가장 중요한 부분에 조사 시간을 집중할 수 있었습니다. 이는 평균 대응 시간을 직접적으로 단축하고 경보 피로를 줄이는 기능으로, 5일 연속 지속적인 공격을 받을 때 정확히 필요한 기능입니다.

맞춤형 AI 에이전트: Elastic Agent Builder

기본 Elastic AI 기능 외에도 Elastic Agent Builder를 사용하여 3개의 맞춤형 AI 에이전트를 구축했습니다. Agent Builder는 LLM 지침과 모듈식의 재사용 가능한 도구를 결합하는 맞춤형 AI 에이전트를 구축하기 위한 Elastic의 프레임워크이며, 각 도구는 ES|QL 쿼리, 기본 제공 검색 기능, 워크플로우 실행 또는 MCP를 통한 외부 통합입니다. 에이전트는 자연어 요청의 구문을 분석하고, 적절한 도구를 선택하여 실행하며, 완전한 답변을 제공할 수 있을 때까지 반복하는 동시에 Elasticsearch 내부의 데이터로 컨텍스트를 관리합니다. 프레임워크에 대한 자세한 내용은 Agent Builder 설명서 및 Elasticsearch Labs 심층 분석에서 확인할 수 있습니다.

Elastic이 활용한 Agent Builder의 세 가지 핵심 구성 요소는 다음과 같습니다.

에이전트: 에이전트의 페르소나, 기능 및 동작 범위를 정의하는 사용자 지정 LLM 지침과 할당된 도구 세트입니다. 에이전트마다 미션, 액세스할 수 있는 도구 및 응답 구조를 제어하는 시스템 프롬프트가 있습니다.

도구: 에이전트가 Elasticsearch 데이터를 검색, 조회 및 조작하는 데 사용하는 모듈식 함수입니다. 연습 문서, 플레이북, 보고서가 포함된 특정 인덱스를 쿼리하는 맞춤형 ES|QL 도구를 구축했습니다.

에이전트 채팅: 참가자가 에이전트와 상호 작용하는 데 사용한 대화형 인터페이스로, 기본 제공 Kibana UI와 프로그램 방식의 API를 모두 포함합니다.

에이전트 및 도구 구성은 JSON으로 정의되고 Agent Builder API를 통해 관리되므로, 프롬프트 엔지니어링부터 도구 바인딩에 이르는 전체 에이전트 수명 주기를 재현하고 버전을 관리할 수 있습니다. 이러한 접근 방식을 재현하려는 분들을 위해 후속 게시물에서 GrantPT 에이전트 구성 및 도구 정의를 공유할 예정이니 계속 주목해 주시기 바랍니다.

각 에이전트가 수행한 작업은 다음과 같습니다.

1. GrantPT - 범용 어시스턴트

약 2,500명의 훈련 참가자 전원에게 제공된 GrantPT는 당사의 주요 AI 에이전트였으며, Agent Builder를 통해 유능한 도메인 특화 어시스턴트를 얼마나 쉽게 구축할 수 있는지를 가장 잘 보여준 사례였습니다. 에이전트의 구성은 시스템 프롬프트, 페르소나, 바인딩된 도구 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의 네이티브 도큐먼트 수준 보안이 범위 지정을 처리했고, 에이전트는 반환된 결과를 그대로 사용했습니다. 이는 Agent Builder를 진정으로 우아하게 만드는 요소 중 하나입니다. Elasticsearch의 보안 모델을 상속하므로 단 한 줄의 권한 부여 코드도 작성하지 않고 RBAC 인식 AI를 구현할 수 있습니다.

2. REDRock - 공격자의 동반자

이 에이전트는 레드 팀에만 독점적으로 제공되었습니다. REDRock은 동일한 Agent Builder 패턴을 따랐으며, 적대적 페르소나를 정의하는 전용 시스템 프롬프트가 레드 팀 전용 인덱스를 쿼리하는 자체 맞춤형 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 Bedrock Guardrails의 통제를 받았습니다. 콘텐츠 필터링(중간 임계값의 증오, 모욕, 성적 콘텐츠, 폭력), PII 보호(이메일 주소, 전화번호, 이름, 주소, 영국 국민보험 번호, 신용카드 번호, IP 주소 차단), 실제 기밀 작전에 대한 논의를 방지하기 위한 주제 기반 필터링 및 비속어 필터링이 포함된 가드레일을 배포했습니다. Terraform의 가드레일 구성 스니펫은 다음과 같습니다.

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "DCM5 Prod Elastic Kibana GenAI 커넥터용 가드레일"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... 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"
    }
    # ... 추가 PII 필터
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "실제 기밀 작전, 현재 실제 군사 활동 또는 운영 인텔리전스에 대한 논의."
      type       = "DENY"
    }
  }
}

각 블루 팀 스페이스에는 Bedrock 액세스용 IAM 사용자가 있었으며, 팀이 자체 커넥터를 구성하지 못하도록 genAiSettings:defaultAIConnectorOnly Kibana 설정이 적용되었습니다. 즉, 모든 API 호출은 CloudWatch를 통해 특정 팀까지 추적할 수 있었고, NSOC는 완전한 감사 가시성을 확보했습니다. CloudWatch 로그 그룹 /aws/bedrock/grantpt-prod/invocations은 모든 호출 및 가드레일 이벤트를 캡처했습니다.

맞춤형 AI 에이전트 3개, 대화 2,797회, 전체 실습 과정에서 소비된 AI 토큰 7억 8,500만 개까지 모든 AI 소비자에 대한 수치가 이를 증명합니다.

게임 내 실시간 모니터링

훈련 시나리오에서 각 팀은 온레인지 메시징 클라이언트로 RocketChat에 액세스할 수 있었습니다. 블루 팀 전원에게 자체 채널, 훈련 중인 누구에게나 다이렉트 메시지를 보낼 수 있는 기능, 필요에 따라 새로운 채널을 자유롭게 개설할 수 있는 유연성이 제공되었습니다. DCM 전통에서 가장 중요한 점은 여기에 밈 채널이 포함되었다는 것입니다. 이 채널은 팀 내 온갖 짓궂은 장난이 벌어지는 기반이자 수천 명의 사이버 운영자가 일주일 동안 압박을 받을 때 터지기 마련인 사기 진작을 위한 창의적 유머의 근원이었습니다.

이 모든 커뮤니케이션 데이터는 훈련장 상태, 팀 감정, 훈련 전반에 걸친 트렌드 토픽을 실시간으로 파악할 수 있는 훌륭한 창구가 되었습니다. 그냥 지나치기에는 너무 좋은 기회였기에, 전체 RocketChat 대화 말뭉치를 실시간으로 Elastic에 수집하여 활용했습니다.

정서 분석 및 명명된 엔티티 인식

개체명 인식을 위해 dslim/bert-base-NER Hugging Face 모델을 Elastic ELAND 클라이언트를 사용한 NSOC 배포의 머신 러닝 노드에 배포했습니다. 그런 다음 수집 시 모든 RocketChat 메시지가 통과하는 Elasticsearch 수집 파이프라인에 이를 연결했습니다. 추출된 개체 중 가장 빈번한 항목들을 대시보드 테마로 표시하여 훈련 전반에 걸친 대화 주제의 변화 흐름을 실시간으로 확인할 수 있었습니다.

또한 각 팀의 생활 패턴을 파악하기 위해 그룹 활동, 사용자 통계, 전반적인 커뮤니케이션 패턴을 분석했습니다. 여기에는 가장 활동적인 참여자, 시간 경과에 따른 메시지 양, 개별 사용자별 감성 트렌드 등이 포함됩니다. 전반적으로, 이를 통해 훈련장에서 일어나는 상황을 거의 실시간으로 파악할 수 있는 매우 흥미로운 인사이트를 얻을 수 있었습니다. 예를 들어 Elastic Agent를 예방 모드로 전환했을 때, 대시보드의 워드 클라우드에 'Elastic'이 모든 채널에서 가장 많이 논의된 주제로 즉시 떠올랐습니다. 블루 팀은 그 효과에 대해 논의했고, 레드 팀은 손실된 비콘에 대해 아쉬워했습니다. 상당히 만족스러운 결과였습니다.

밈 분석(네, 정말입니다)

눈살을 찌푸리는 사람들도 있었지만 마지막으로 채널에 제출된 모든 밈을 가져와 이미지를 벡터화하고, 최근접 이웃 평가를 실행하여 유사한 밈과 주제를 함께 클러스터링했습니다. 또한 각 밈 콘텐츠의 주제별 설명을 생성하기 위해 제로샷 NER 추론 모델을 통과시켰습니다. 이러한 출력이 추후 필터링, 모더레이션 또는 기타 게임 내 상호 작용에 유용할 수 있다는 로직이었습니다. 밈 분석이 운영상 중요한 인텔리전스를 산출했는지는 논란의 여지가 있습니다. 정말 재미있는 작업이었는지에 대해서는 의심의 여지가 없습니다.

문제의 싹 잘라내기

훈련 주간 동안 모든 것이 순조롭게 실행되기를 바랐지만, 필연적으로 문제가 발생하거나, 완전히 이해되지 않거나, 특정 팀의 사용 방식에 맞게 추가적인 맞춤화가 필요한 상황이 발생하기도 합니다. 이를 위해 모든 팀이 Elastic 및 GenAI 전용 요청을 등록할 수 있는 인레인지 헬프데스크의 자체 하위 섹션을 마련했습니다.

훈련 기간 내내 헬프데스크를 운영하며 지침, 문서, 문제 디버깅 및 훈련 환경별 권장 사항을 제공했습니다. 마지막 사항은 좀 더 자세히 설명할 가치가 있습니다. 종종 블루 팀이 Elastic에서 확인한 것은 실제로 Elastic 문제가 아니라, 추가 조사가 필요한 훈련 환경의 무언가를 Elastic이 충실하게 표시한 내용이었습니다(레드 팀은 엄청난 혼란을 일으킬 수 있으며, 텔레메트리는 거짓말을 하지 않습니다). Elastic은 훈련 과정에서 특별히 도움을 요청한 팀들의 개별 지원 요청 125건을 처리했습니다.

Tines와 함께하는 선제적 디버깅

VTC를 통해 또는 EXCON에서 직접 팀을 방문하는 것 외에도, Tines와 협력하여 좀 더 사전 예방적인 방식을 시도했습니다. 수신된 요청에서 티켓 본문을 추출하고, 문제를 분류하고자 시도했으며, 이전에 해결된 티켓 말뭉치와 비교하여 분류를 실행한 후, GenAI를 통한 선별을 거쳐 대기열에 들어오기 전에 사용자의 문제를 해결하는 것을 목표로 요약된 1차 응답을 생성하도록 했습니다.

이는 실제로 Elastic의 지원 조직에서 차용한 패턴입니다. 이 조직에서는 이전에 해결된 문제로 구성된 광범위한 지식 기반을 AI 에이전트 컨텍스트를 지원하기 위한 리포지토리로 사용하여 유사한 기능을 제공합니다. 아이디어는 간단합니다. 과거의 해결책을 사용해 문제 해결을 위한 정보에 기반한 머신 생성 초기 대응을 제공하고, 지원 엔지니어가 모든 티켓을 수동으로 처리해야 하는 필요성을 줄이는 것입니다. 모든 문제가 해결된 것은 아니었습니다. 일부 문제는 실제로 폭넓은 컨텍스트를 이해하는 사람이 필요했지만, 대기열 부담을 크게 줄이고 답변이 필요한 팀에 더 빠르게 답변을 제공했습니다. 이 방식은 자체 특정 티켓과 대기열에서 매우 성공적이었기에, 실제로 실습 후반부에는 적용 범위를 전체 헬프데스크로 확장하여 실습을 지원하는 그린 팀의 다른 그룹이 부담하는 업무량을 줄이는 데 도움을 주었습니다.

업계 파트너십: 시너지

가장 자랑스러운 점 중 하나는 파트너십 에코시스템이 매년 성장해 왔다는 것입니다. DCM은 단순한 Elastic만의 행사가 아니며, 업계 파트너들이 각자 보안 플랫폼에 고유한 가치를 더하는 진정한 연합 행사입니다.

1년 차(DCM2) - Elastic이 업계 파트너로 합류하여 보안 모니터링 및 엔드포인트 탐지 플랫폼을 제공했습니다.

2년 차(DCM3) - Elastic이 Endace를 도입하여 1:1 패킷 캡처 기능을 제공했습니다. Elastic의 네트워크 가시성과 함께 전체 패킷을 캡처함으로써 로그 기반 분석만으로는 제공할 수 없는 심층 포렌식을 수행할 수 있는 기능을 팀에 제공했습니다.

3년 차(DCM4) - Tines가 합류하여 워크플로우 자동화를 도입했습니다. 이제 블루 팀은 네이티브 Tines 커넥터를 통해 Elastic 환경에 직접 통합된 자동화된 응답 플레이북, 분류 워크플로우 및 알림 체인을 구축할 수 있게 되었습니다.

4년 차(DCM26, 이전의 DCM5) - AWS가 참여하여 당사의 AI 에이전트를 위한 Bedrock 액세스를 제공하고 Elastic 배포에 자금을 지원했습니다. 이는 중요한 이정표였습니다. 하이퍼스케일러가 훈련의 성공에 직접 투자함으로써, 그렇지 않았다면 불가능했을 역량(완벽한 가드레일 및 감사 로깅을 갖춘 규정 준수 영국 테넌트 AI 추론 등)을 확보할 수 있었습니다. 올해 Tines 통합은 온레인지 LLM 액세스가 추가되면서 한층 더 강화되었습니다. DCM 시리즈 역시 올해 중요한 이정표를 세우며, 육군 사이버 협회의 이니셔티브로 시작된 초기 단계에서 사이버 및 특수 작전 사령부 산하의 공식 재정 지원 프로그램으로 전환되었습니다.

Endace, Tines 및 AWS 팀 여러분께 진심으로 감사드립니다. 여러분의 기여 덕분에 이번 훈련의 완성도가 더욱 높아졌으며, 함께 구축한 플랫폼을 통해 모든 팀이 더 나은 역량을 갖추게 되었습니다. Elastic은 이미 DCM27을 계획하고 있습니다. 여러분 모두에게 감사와 응원을 보냅니다.

문화, 주요 내용과 이를 가치 있게 만드는 요소

챌린지 코인

DCM26를 위해 맞춤형 챌린지 코인을 제작했습니다. 아는 사람은 아시겠지만, 챌린지 코인은 오랜 군 전통이며 이 훈련에 대한 코인을 제작하는 것은 참여 4주년을 기념하는 적절한 방법처럼 느껴졌습니다.

칵테일 파티

또한 감사하게도 주싱가포르 영국 고등판무관이 주최한 고등판무관실 칵테일 파티에 초대되었습니다. 대사의 초청을 받아 진토닉을 들고 Elasticsearch 샤드 수와 Terraform 상태 관리에 대해 논의하는 것은 사뭇 비현실적인 느낌을 주었습니다. 기술과 외교의 접점에 이러한 훈련이 존재하며, 이곳에서 구축된 관계가 기술적인 영역을 훨씬 뛰어넘어 확장된다는 점을 진정으로 일깨워 주는 훌륭한 저녁이었습니다.

결론

멀티 테넌트 아키텍처는 지속적인 부하 속에서도 그 가치를 입증했으며, 네이티브 Elastic AI 기능(AI Assistant 및 Attack Discovery)는 불과 몇 년 전만 해도 SF에서나 볼 수 있었던 역량을 팀에 제공했고, 맞춤형 AI 에이전트의 도입은 기대를 뛰어넘었습니다. 파트너십 모델은 업계가 참여한 국방 훈련이 단일 조직만으로는 달성할 수 없는 성과를 창출한다는 점을 계속해서 입증하고 있습니다.

Defence Cyber Marvel 2026은 포부, 복잡성, 영향력 면에서 계속해서 성장하고 있는 훈련의 획기적인 회차였습니다. 29개국 40개 블루 팀에 핵심 방어 보안 플랫폼, 올해는 특히 AI 역량까지 제공할 만큼 신뢰를 쌓았다는 것은 Elastic에 큰 의미를 갖습니다. 이 훈련은 향후 실제 네트워크를 방어하게 될 실제 사람들을 위한 실질적인 기술을 개발하며, 이러한 임무의 일원이 된다는 것은 진정으로 뜻깊은 일입니다.

영국 정부의 보도 자료에서 밝혔듯이, DCM은 국제 파트너십을 강화하는 실제 시나리오의 실질적인 가치를 입증합니다. Elastic도 전적으로 동의합니다.

내년에 다시 찾아뵙겠습니다. 그때는 더 많은 이야기를 나눌 수 있을 것으로 생각합니다. 그동안 Defence Cyber Marvel과 같은 환경에 대한 지원이 해마다 더욱 발전할 수 있도록 제품을 계속 개선해 나가겠습니다.

훈련장에서 뵙겠습니다.

소셜 미디어에서 DCM26 스토리 팔로우하기:

Facebook | LinkedIn | Instagram

추가 읽기

Elastic Security & AI

인프라 및 도구

훈련 컨텍스트

이 콘텐츠가 얼마나 도움이 되었습니까?

문제 신고하기