끊임없이 진화하는 위협 환경에서 보안 운영은 티핑 포인트에 도달하고 있습니다. 위협의 속도와 복잡성이 증가함에 따라 팀이 확장되고 관리 환경이 복잡해집니다. 일반적으로 규칙 관리에 대한 수동 접근 방식은 병목 현상이 발생합니다. 여기에서 단순한 도구가 아닌 방법론으로서 코드 기반 탐지(DaC)가 등장합니다.

방법론으로서의 DaC는 보안 탐지 규칙의 생성, 관리 및 배포에 소프트웨어 개발 관행을 적용합니다. 탐지 규칙을 코드로 취급함으로써 버전 제어, 자동화된 테스트 및 배포 프로세스를 지원하여 협업, 일관성 및 위협 대응의 민첩성을 향상시킵니다. DaC는 탐지 규칙 수명 주기를 간소화하여 동료 검토 및 자동화된 테스트를 통해 고품질 탐지를 보장합니다. 이 방법론은 또한 변경 관리 요구 사항의 준수를 지원하고 성숙한 보안 태세를 조성합니다.

그렇기 때문에 Elastic에서 보안 탐지 규칙을 작성, 테스트 및 관리하기 위한 오픈 리포지토리인 Elastic의 탐지 규칙에 대한 최신 업데이트를 공유하게 되어 기쁘게 생각하며, 또한 자체적인 코드형 탐지(DaC) 프레임워크를 만들 수 있습니다. 확장 기능을 사용한 주요 구현 예제와 Elastic의 무료 코드형 탐지 워크샵 발표에 대해 계속 읽어보세요.

Elastic Security DaC: 알파 버전에서 정식 버전으로의 여정

이제 탐지 규칙 리포지토리에 제공되는 기능을 통해 사용자는 모든 탐지 규칙을 코드로 관리하고, 규칙 조정을 검토하고, 규칙을 자동으로 테스트 및 검증하고, 환경 전반에 걸쳐 규칙 배포를 자동화할 수 있습니다.

2024년 이전: Elastic의 내부 DaC 사용

Elastic 위협 연구 및 탐지 엔지니어링 팀은 탐지 규칙 리포지토리를 생성하고 사용하여 팀으로 규칙을 검토하고 테스트 및 릴리스를 자동화하는 DaC 원칙에 따라 사전 구축된 규칙을 개발, 테스트, 관리 및 릴리스했습니다. 리포지토리에는 규칙을 만들 수 있는 대화형 CLI도 있으므로 엔지니어가 바로 거기서 규칙 작업을 시작할 수 있습니다.

코드형 원칙에 대한 보안 커뮤니티의 관심이 커지고 사용 가능한 Elastic Security API를 통해 이미 사용자 정의 탐지를 코드 솔루션으로 구현할 수 있게 되면서, Elastic은 탐지 규칙 리포지토리 기능을 확장하여 사용자가 도구의 이점을 활용하고 DaC 프로세스를 생성할 수 있도록 지원하기로 결정했습니다.

다음은 알파 버전에서 정식 버전에 이르기까지 사용자 중심의 Elastic DaC 개발의 주요 마일스톤입니다.

2024년 5월: 새로운 "'나만의 롤' 기능의 알파 릴리즈

탐지 규칙 저장소는 고객이 사용할 수 있도록 조정되어 사용자 지정 규칙을 관리하고, 사용자 요구에 맞게 테스트 스위트를 조정하고, 규칙과 함께 작업 및 예외를 관리할 수 있습니다.

주요 추가 사항:

사용자 지정 규칙 디렉토리 지원
요구 사항에 따라 실행할 테스트 선택
예외 및 작업 지원

또한 탐지 규칙 리포지토리를 사용하여 Elastic Security로 구현한 예제가 포함된 코드형 탐지에 대한 광범위한 지침을 게시했습니다.

2024년 8월: "'나만의 롤' 기능 베타 버전 출시

이 기능은 Elastic Security와 리포지토리 간에 사용자 정의 규칙을 가져오고 내보낼 수 있도록 확장되었으며, 더 많은 구성 옵션과 사용자 정의 규칙으로 확장된 버전 관리 기능을 제공합니다.

새로운 기능이 추가되었습니다:

사용자 정의 규칙의 대량 가져오기/내보내기(Elastic Security API 기반)
완벽하게 구성 가능한 단위 테스트, 유효성 검사 및 스키마
사용자 지정 규칙의 버전 잠금

2025년 3월 - 8월: 일반적으로 사용 가능하며 지원됩니다.

Elastic Security 8.18 이상에서 DaC 사용:

사전 구축된 규칙 관리를 지원합니다. Elastic Security에서 미리 빌드된 모든 규칙을 내보내고 사용자 정의 규칙과 함께 저장할 수 있습니다.
내보내기에 대한 규칙 필터링 지원이 추가되었습니다.

DaC 노력과 더불어, 2025년 10월부터 12월까지 새로운 Terraform 리소스(V0.12.0 및 V0.13.0)도 출시하여 Terraform 사용자가 탐지 규칙과 예외를 관리할 수 있도록 했습니다.

이러한 기초를 바탕으로 탐지 엔지니어링 프로세스를 간소화하는 데 사용할 수 있는 강력한 기능을 살펴보겠습니다.

탐지 규칙 DaC 기능의 주요 특징

지난 DaC 발행 이후 몇 가지 가치 있는 추가 사항이 있으며, 이에 대해서는 아래에서 자세히 설명하겠습니다.

추가 필터

Kibana에서 규칙을 내보낼 때 사용할 수 있는 필터 기능이 확장되어 DaC에서 어떤 규칙을 동기화할지 정확하게 정의할 수 있습니다. 새로운 깃발은 다음과 같습니다:

깃발	설명
-cro	사용자가 만든 규칙만 포함하도록 내보내기를 필터링합니다(Elastic 사전 구축 규칙이 아님).
-eq	내보내는 규칙에 쿼리 필터를 적용합니다.

데이터 소스별로 규칙을 구성하고 AWS 규칙을 특정 폴더로 내보내고자 하는 경우를 예로 들어보겠습니다. 이 경우 데이터 원본의 태그에 필터링을 사용하고 Data Source AWS 태그를 사용하여 모든 규칙을 내보내 보겠습니다:

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

여기에 사용된 기본 API 호출에 대한 쿼리 문자열 필터링과 쿼리 필터를 구성하는 데 사용할 수 있는 필드의 예는 모든 탐지 규칙 API 호출 나열을 위한 Kibana 설명서를 참조하세요.

사용자 지정 폴더 구조

탐지 규칙 리포지토리에서는 플랫폼, 통합 및 MITRE ATT&CK 정보를 기반으로 한 폴더 구조를 사용합니다. 이는 조직과 규칙 개발에 도움이 됩니다. 이것이 유일한 정리 방법은 아닙니다. 고객, 날짜 또는 소스별로 규칙을 정리하는 것이 좋습니다. 이는 사용 사례에 따라 크게 달라질 수 있습니다.

이 내보내기 프로세스를 사용하든 수동으로 정리하든, 원하는 위치나 폴더 구조에 규칙을 저장해 놓으면 규칙을 다시 내보낼 때도 이 로컬 구조를 유지할 수 있습니다. 새 규칙은 원하는 위치에 수동으로 배치해야 한다는 점에 유의하세요. 로컬 규칙 로딩 메커니즘은 규칙을 어디에 배치할지 알기 위해 규칙이 배치된 위치를 감지합니다. 규칙이 없는 경우 지정된 출력 디렉터리를 사용하여 새 규칙을 배치합니다. 기존 규칙을 업데이트하기 위해 로컬 규칙 로딩을 사용하려면 kibana export-rules 및 import-rules-to-repo 명령에 --load-rule-loading / -lr 플래그를 사용합니다. 이 플래그를 사용하면 config.yaml 에 지정된 로컬 폴더를 사용할 수 있습니다.

다음과 같은 방식으로 폴더에 규칙을 정리한 예를 살펴보겠습니다:

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

config.yaml 파일에 다음을 지정합니다:

rule_dirs:
- rules
- another_rules_dir

새로운 -lr 옵션을 사용하면 이제 Kibana의 규칙 업데이트가 지정된 디렉터리로 직접 내보내는 대신 이러한 추가 경로를 사용합니다.

python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,을 실행하면 test_local 공간에서 규칙을 내보내고, my_test_rule.toml 은 이미 디스크에 있던 대로 dac_test/rules/에 기록되며, high_number_of_process_and_or_service_terminations.toml 은 다음과 같이 기록됩니다. dac_test/another_rules_dir/.

이는 고객마다 다른 하위 폴더 구성에 동일한 규칙이 있는 경우에 특히 유용할 수 있습니다. 예를 들어, Elastic의 사전 구축된 규칙 폴더 구조와 유사하게 플랫폼 및 통합별로 규칙을 세분화했다고 가정해 보겠습니다. 고객, SOC 또는 위협 추적 팀의 경우, 이러한 플랫폼/통합 폴더 아래에 규칙을 정리하는 것이 규칙을 관리하는 데 가장 유용한 메커니즘일 수 있습니다. 그러나 정보 보안 팀이나 기본 탐지 엔지니어링 팀에서는 특정 개인이나 팀이 담당하는 모든 규칙을 한 곳에 정리할 수 있도록 이니셔티브 또는 규칙 작성자별로 규칙을 관리할 수도 있습니다. 이제 로컬 규칙 로딩 플래그를 사용하면 두 개의 구성 파일과 각 구조에 중복된 규칙을 간단히 가질 수 있습니다. 규칙에 대한 업데이트를 내보내는 경우 환경 변수를 사용하여 적절한 구성 파일을 선택하고 규칙 업데이트를 내보내면 됩니다. 그러면 이러한 업데이트가 기존 규칙에 적용되어 디렉터리 구조가 유지됩니다.

기타 로컬 로딩 업데이트

위와 더불어, 탐지 규칙 TOML 파일 및 스키마에 로컬 정보를 추가하는 사용자를 돕기 위해 설계된 두 가지 작은 새 기능이 추가되었습니다. 그 내용은 다음과 같습니다:

로컬 파일에서 로컬 날짜를 지원하는 경우 원본 파일에서 로컬 날짜가 유지됩니다.
기존 스키마에서 알려진 유형을 상속하는 자동 생성 기능으로 업그레이드합니다.

로컬 날짜 구성 요소는 파일의 날짜 필드를 보다 수동으로 제어하려는 경우에 유용할 수 있습니다. 오버라이드를 사용하지 않으면 날짜는 Kibana 규칙 콘텐츠를 내보낸 시점을 기준으로 합니다. --local-creation-date 플래그를 사용하면 파일 내용을 다시 내보낼 때 날짜가 업데이트되지 않습니다.

자동 스키마 생성은 다른 인덱스/통합이 있는 경우 그 유형을 상속하도록 업데이트되었습니다. 이는 잠재적으로 더 정확한 스키마를 제공할 뿐만 아니라 사후 수동 업데이트의 필요성을 줄여줍니다. 예를 들어, 다음 필드와 함께 "new-integration*" 인덱스를 사용하는 규칙이 있습니다:

host.os.type.new_field
dll.Ext.relative_file_creation_time
process.name.okta.thread

이러한 각 필드가 기본 유형으로 스키마에 추가되는 대신 해당 유형은 기존 스키마에서 상속됩니다. 이 경우 dll.Ext.relative_file_creation_time 및 process.name.okta.thread 유형이 상속됩니다.

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

사용자 정의 데이터 유형에 이를 사용하는 방법을 알아보려면 이 블로그의 구현 예제 부분의 사용자 정의 스키마 사용 섹션을 참조하세요.

사용 예시 확장

아래에서 새로운 기능 추가에 초점을 맞춘 것이 아니라 커뮤니티에서 논의된 주제에 대해 더 자세히 살펴볼 수 있는 DaC 구현의 더 많은 예를 확인할 수 있습니다.

코드 기반 탐지 기능은 선택한 프로세스 및 아키텍처에 대한 사용자 지정 구현을 구축하는 데 사용할 수 있는 구성 요소로 제공된다는 점에 주목할 필요가 있습니다. 프로덕션 환경에서 DaC를 구현할 때는 엔지니어링 프로세스로 간주하고 모범 사례를 따르세요.

Gitlab으로 DaC 구현

일반적으로 DaC의 구현을 살펴보면 특정 트리거에 따라 자동으로 규칙 관리를 수행하는 일종의 CI/CD 제품을 사용하는 경우가 많습니다. 이러한 트리거는 원하는 설정, 특히 규칙의 권한 있는 소스 및 버전 관리 시스템(VCS)의 원하는 상태에 따라 상당히 달라집니다. 이러한 고려 사항 중 일부에 대해 더 자세히 알아보려면 DaC 참조 자료를 참조하세요. 아래는 Gitlab을 VCS 공급자로 사용하고 Gitlab Actions를 통해 내장된 CI/CD를 사용하는 간단한 예제입니다.

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

이는 Gitlab 및 Gitea와 같은 다른 Git 기반 VCS의 다른 내장형 CI/CD와 매우 유사합니다. 가장 큰 차이점은 트리거 이벤트를 결정하는 구문에 있습니다. kibana import-rules 같은 DaC 명령은 VCS에 관계없이 동일합니다. 이 예에서는 탐지 규칙 리포지토리의 포크에서 Kibana 프로덕션 공간으로 규칙을 동기화하고 있습니다. 이는 규칙 업데이트를 병합하기 전에 단위 테스트를 통과해야 하고 메인 규칙을 프로덕션할 준비가 되어 있어야 하는 등 여러 가지 사전 결정을 기반으로 합니다. 이 특정 접근 방식에 대한 고려 사항에 대한 Github 기반 안내를 보려면 데모 동영상을 살펴보세요.

사용자 지정 단위 테스트 팁 및 예제

탐지 툴킷에 추가할 기능으로 DaC를 고려할 때는 규칙의 품질과 유용성을 개선하기 위한 지속적인 프로세스의 첫 번째 단계로 CI/CD 및 기본 인프라를 설정하는 것을 고려해야 합니다. '코드형' 툴을 사용하는 주요 목적 중 하나는 사용자의 요구와 환경에 맞게 툴을 추가로 커스터마이즈할 수 있는 기능을 추가하는 것입니다.

한 가지 예로 규칙에 대한 단위 테스트를 들 수 있습니다. 기본 기능 테스트 외에도, 기존의 다른 주요 단위 테스트는 규칙 성능과 최적화, 메타데이터와 태그 구성에 대한 Elastic만의 고려 사항을 적용합니다. 이를 통해 탐지 엔지니어와 위협 연구자는 규칙 개발에서 일관성을 유지할 수 있습니다. 이 예제를 기반으로 특정 요구 사항에 따라 사용자 지정 단위 테스트를 추가하는 것을 고려할 수 있습니다.

이를 설명하기 위해 다양한 도메인과 작업을 담당하는 여러 분석가가 있는 보안 운영 센터(SOC) 환경을 예로 들어보겠습니다. SIEM에서 알림이 발생하면 누가 문제 해결을 처리해야 하는지, 어떤 팀에 인시던트를 알려야 하는지 즉시 명확하지 않을 수 있습니다. 팀 태그로 규칙에 태그 지정: 예를 들면 다음과 같습니다. Team: Windows Servers 는 데이터 소스에 태그를 사용하는 방식과 유사하게, 문제 해결에 도움을 줄 수 있는 사람에 대한 연락 창구를 경보에서 직접 SOC에 제공할 수 있습니다.

DaC 환경에서는 새로운 테스트 모듈을 빠르게 생성하여 모든 사용자 지정 규칙(또는 사전 구축된 규칙)에 이를 적용할 수 있습니다. 이 테스트에서는 Elastic에서 작성하지 않은 모든 프로덕션 규칙에 Team: <some name> 태그를 사용하도록 강제할 것입니다. 탐지 규칙 리포지토리에서 테스트는 pytest 이라는 Python 테스트 스위트를 통해 처리되며, 이러한 단위 테스트는 tests/ 폴더 아래의 파이썬 모듈(파일)과 이 파일에 포함된 후속 클래스 및 함수로 구성됩니다. 테스트를 추가하려면 기존 파일에 클래스나 함수를 추가하거나 새 파일을 생성하기만 하면 됩니다. 일반적으로 새 테스트 파일을 생성하여 차이점을 병합할 필요 없이 Elastic으로부터 기존 테스트에 대한 업데이트를 받을 수 있도록 하는 것이 좋습니다.

먼저 tests/ 디렉터리에 다음 내용으로 test_custom_rules.py 이라는 파이썬 파일을 새로 생성합니다:

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

이제 각 비 Elastic 규칙에는 문제 해결을 담당하는 팀을 위해 지정된 패턴의 태그가 있어야 합니다. 예 Team: Team A.

사용자 지정 스키마 사용

자체 데이터 유형을 가져올 수 있는 Elastic의 기능은 DaC 기능으로도 확장됩니다. 예를 들어 네트워크 프로토콜에 대한 몇 가지 사용자 정의 스키마를 살펴 보겠습니다. 스택에 있는 다양한 데이터는 당연히 규칙에 의해 쿼리될 수 있으며, 이러한 데이터 유형에 대한 사용자 지정 규칙에 대해서도 해당 유효성 검사 및 테스트를 활용하고 싶을 것입니다. 이때 사용자 정의 스키마가 유용합니다.

쿼리의 유효성을 검사할 때 쿼리는 각 필드로 구문 분석되고 이러한 필드의 유형은 주어진 스키마에 제공된 것과 비교됩니다(예 ECS 스키마, AWS 데이터용 AWS 통합 등). 사용자 지정 데이터 유형의 경우 로컬로 정의된 사용자 지정 스키마에서 가져올 수 있는 기능과 함께 동일한 유효성 검사 경로를 따릅니다. 이러한 스키마 파일은 하나 이상의 json 파일로 직접 작성할 수 있지만, 스택에 이미 샘플 데이터가 있는 경우 이를 활용하여 유효성 검사로 사용하고 스키마를 자동으로 생성할 수 있습니다.

사용자 지정 규칙 폴더가 이미 구성되어 있다고 가정하고(지침을 참조하지 않은 경우) 구성 파일에 auto_gen_schema_file: <path_to_your_json_file> 을 추가하여 자동 스키마 생성을 사용 설정할 수 있습니다. 그러면 각 필드 및 인덱스 조합에 대한 항목을 추가하는 데 사용되는 스키마 파일이 지정된 위치에 생성됩니다. 이 파일은 import-rules-to-repo, kibana export-rules, view-rule 등을 포함하여 규칙 내용이 스키마에 대해 유효성이 검사되는 모든 명령 중에 업데이트됩니다. 또한 사용자 지정 규칙 디렉터리 및 구성을 사용할 때 stack-schema-map.yaml 파일에 자동으로 추가됩니다.

쿼리에 사용된 모든 필드가 즉시 유효한 것으로 간주되어 스키마에 추가되므로 규칙 검토자의 책임이 더 커집니다. 위험을 완화하는 한 가지 방법은 데이터에 액세스할 수 있는 개발 공간을 활용하는 것입니다. 그런 다음 PR에서 데이터 유형에 대한 스택 수준 유효성 검사를 통해 쿼리의 성공적인 실행을 연결할 수 있습니다. 이 작업이 승인되면 구성에서 auto_gen_schema_file 추가를 제거할 수 있으며 이제 사용자 지정 데이터를 기반으로 유효한 스키마를 갖게 됩니다. 이는 다른 규칙 작성자가 필요에 따라 구축할 수 있는 기준선을 제공하고 유형 검사 유효성 검사를 유지합니다.

DaC에 대해 자세히 알아보고 직접 사용해 보세요

대화형 Instruqt 교육을 통해 Elastic Security의 코드 기반 탐지(DaC) 기능을 직접 체험해 보세요. 이 교육은 사전 구성된 테스트 환경에서 핵심 DaC 기능을 직접 살펴볼 수 있는 간단한 방법을 제공하므로 수동 설정이 필요하지 않습니다. 한번 사용해 보세요!

DaC를 구현하고 있다면 커뮤니티 슬랙 DaC 채널에서 경험을 공유하고, 질문하고, 다른 사람들을 도와주세요.

Elastic Security 체험판

Elastic이 탐지 엔지니어를 위해 제공하는 모든 이점을 경험해 보려면 Elastic Security 무료 체험판을 시작하세요. 자세히 알아보려면 elastic.co/security를 방문하세요.

이 게시물에서 설명된 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

코드로 보는 Elastic 탐지에 대한 엔지니어 가이드