Elastic에서는 여러 데이터 세트, 환경, 심각도 수준에 걸쳐 크고 다양한 행동 탐지 규칙 세트를 운영하고 있습니다. 이러한 규칙의 대부분은 특정 행동, 신호 또는 공격 패턴을 감지하도록 설계된 원자적인 규칙입니다. 또한 방화벽, EDR, WAF 및 기타 보안 제어와 같은 보안 통합에서 외부 경고를 수집하고 홍보합니다.
그 결과 강력한 가시성과 함께 상당한 양의 알림을 받을 수 있습니다. 원격 분석 결과, 빌딩 블록 규칙이 아닌 것만 고려하더라도 65개의 고유한 탐지 규칙이 프로덕션 클러스터당 하루에 거의 8000개의 경고를 생성합니다. 각 알림을 개별적으로 분석하는 것은 확장성도 비용도 효율적이지 않습니다.
여기서 상위 주문 규칙이 작동합니다.
상위 규칙은 단일 행동을 감지하지 못합니다. 대신 시간 경과에 따라, 데이터 소스 전체에 걸쳐 또는 공유 컨텍스트(예: 호스트, 사용자, IP 또는 프로세스) 내에서 관련 알림을 상호 연관시킵니다. 신호를 의미 있는 패턴으로 그룹화하여 진정으로 중요한 것의 우선순위를 정하고 수동으로 수행하든, 자동화하든, AI로 증강하든 모든 개별 알림에 대한 심층적이고 비용이 많이 드는 분석의 필요성을 줄일 수 있습니다.
이 블로그에서는 Elastic에서 상위 규칙을 구축하는 접근 방식을 살펴보고, 실제 사례를 공유하며, 그 과정에서 얻은 주요 교훈을 강조합니다.
상위 주문 규칙이란 무엇인가요?
상위 규칙(HOR)은 경고를 입력으로 사용하여 경고를 다른 경보와 상호 연관시키거나(경보에 대한 경보), 경고를 원시 이벤트, 메트릭 또는 상황별 원격 분석과 같은 추가 데이터와 결합하는 탐지입니다.
단일 행동을 감지하는 원자 규칙과 달리 상위 규칙은 신호 전반의 패턴을 식별합니다. 기본 탐지를 대체하는 것이 목적이 아니라 실제 공격 활동을 나타낼 가능성이 더 높은 결과 조합을 향상시키는 것이 목적입니다. 실제로는 신뢰도가 높은 결과를 표시하고 분류 우선순위를 개선합니다. 상위 주문 규칙은 빌딩 블록 규칙과 함께 작동하도록 설계되었습니다. 빌딩 블록 규칙은 기본 알림 보기에 표시되지 않는 알림을 생성하여 노이즈를 줄이면서도 상관관계가 있는 알림을 제공합니다. 이 문서에서 참조한 많은 기본 규칙을 빌딩 블록 규칙으로도 구성할 수 있으므로 분석가 검토를 위해 상위 순서 상관관계만 표시할 수 있습니다.
핵심 인사이트는 동일한 엔티티에 수렴하는 독립적인 탐지가 신뢰도를 복합적으로 높이며, 각 추가 신호가 양성 활동이 아닌 실제 활동일 가능성을 배가시킨다는 것입니다. 이 세 가지 설계 원칙은 이러한 인사이트를 작동시킵니다:
1. 엔티티 기반 상관관계
규칙은 호스트, 사용자, 소스 IP, 대상 IP, 프로세스 등의 공유 엔터티별 활동을 상호 연관시켜 분석가가 여러 결과가 동일한 자산이나 ID에 수렴하는 시점을 빠르게 확인할 수 있도록 합니다.
2. 교차 데이터 소스 가시성
일부 규칙은 단일 통합 내에서 작동합니다(예: Elastic Defend 또는 타사 EDR의 엔드포인트 전용 탐지). 다른 이들은 의도적으로 엔드포인트와 네트워크(PANW, FortiGate, Suricata), 엔드포인트와 이메일, 엔드포인트와 시스템 메트릭 등 여러 도메인에서 신호를 결합하여 다단계 또는 교차 표면 활동을 캡처합니다.
3. 시간 및 유병률 인식
시간적 논리가 중요한 역할을 합니다.
새로 관찰된 규칙은 정의된 룩백 기간(예: 5일) 내에 특정 알림이 처음 발생하는 경우를 강조 표시하여 드문 알림 하나라도 검토를 위해 표시되도록 합니다.
전 세계적으로 소수의 호스트에서만 발생하는 알림에 대해 유병률 기반 로직(예: 인라인 통계 사용)으로 필터링하여 노이즈를 줄이고 비정상적인 동작을 강조합니다.
상위 규칙의 전체 세트는 엔드포인트 전용 상관관계, 도메인 간 탐지(엔드포인트 + 네트워크, 엔드포인트 + 이메일), 측면 이동 패턴(예: alert_1 host.ip = alert_2 source.ip), ATT&CK 정렬 그룹화(단일 또는 다중 전술 활동), 새로 관찰된 경고, 경고와 이벤트 간 상관관계(비정상 CPU 메트릭과 결합된 경고 등)를 포괄합니다. 다음 섹션에서는 이러한 카테고리의 대표적인 사례를 살펴봅니다.
상관 관계 및 새로 관찰된 상위 주문 규칙
실제로 고위험 활동이라고 해서 항상 똑같이 보이는 것은 아닙니다.
때로는 여러 개의 수렴 신호를 통해 타협이 드러나기도 합니다. 다른 경우에는 이전에 본 적이 없는 단일 알림으로 나타나기도 합니다.
두 가지 현실을 모두 처리하기 위해 상위 주문 규칙을 세 가지 상호 보완적인 패턴으로 구성했습니다:
- 상관 관계는 공유 엔터티(호스트, 사용자, IP 또는 프로세스)에 연결된 여러 개의 알림 또는 이벤트를 규칙화합니다.
- 새로 관찰된 알림은 드물게 발생하거나 정의된 시간 내에 처음 표시되는 단일 알림을 규칙으로 합니다.
- 하이브리드 패턴은 상관관계와 첫눈에 보이는 논리를 결합하여 의심을 더욱 높이고 특히 흥미로운 활동을 드러낼 수 있습니다.
상관관계 규칙은 신호 밀도와 다양성을 통해 신뢰도를 높입니다. 여러 개의 독립적인 탐지가 동일한 개체를 가리키면 실제 악성 활동의 가능성이 높아집니다.
새로 관찰된 규칙은 그 반대의 경우, 즉 볼륨은 낮지만 참신성이 높은 경우를 다룹니다. 시간 경과에 따른 희귀도에 따라 알림의 우선순위를 지정하여 처음 발생하거나 매우 이례적인 탐지가 한 번 발생했다는 이유만으로 간과되지 않도록 합니다.
이러한 접근 방식은 함께 효율적이고 확장 가능한 분류 전략의 토대를 형성합니다.
사례를 살펴보고 각 패턴의 차이점, 장점, 장단점을 살펴보겠습니다.
엔드포인트 알림 상관관계
실제 공격 발견의 상당 부분은 엔드포인트 원격 분석을 통해 이루어집니다. 풍부한 컨텍스트 프로세스 활동, 명령줄, 파일 동작, 사용자 동작을 제공하여 가장 강력한 탐지 소스 중 하나입니다.
동시에 엔드포인트 환경은 역동적입니다. 합법적인 소프트웨어, 관리 도구, 타사 애플리케이션(및 최근 GenAI 엔드포인트 유틸리티 🥲)은 많은 양의 알림과 오탐을 생성할 수 있으므로 지속적인 튜닝이 필요합니다.
상위 순서 상관관계는 개별 경보에서 동일한 호스트 또는 프로세스에 대한 여러 개의 별개의 신호로 초점을 이동하여 불필요한 조사 노력을 줄이면서 신뢰도를 높여 이 문제를 해결하는 데 도움이 됩니다.
다음 ES|QL 쿼리는 동일한 호스트에서 24시간 동안 3 고유 Elastic Defend 행동 규칙 또는 다른 기능의 경보(예: 행동이 있는 하나의 shellcode_thread, 행동이 있는 malicious_파일)가 있거나 2 악성 코드 경보가 두 개 이상 발생하는 경우 트리거됩니다:
from logs-endpoint.alerts-* metadata _id
| eval day = DATE_TRUNC(24 hours, @timestamp)
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
| stats Esql.alerts_count = COUNT(*),
Esql.event_code_distinct_count = count_distinct(event.code),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, day
| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)의심을 더 높이기 위해 동일한 프로세스 트리에 속하는 Elastic Defend 경보를 상호 연관시킬 수도 있습니다:
from logs-endpoint.alerts-*
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null
// aggregate alerts by process.Ext.ancestry and agent.id
| stats Esql.alerts_count = COUNT(*),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.event_code_distinct_count = COUNT_DISTINCT(event.code),
Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id),
Esql.message_values = VALUES(message),
... by process.Ext.ancestry, agent.id
// filter for at least 3 unique process IDs and 2 or more alert types or rule names.
| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2)
// keep unique values
| stats Esql.alert_names = values(Esql.message_values),
Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values),
... by agent.id
| keep Esql.*, agent.id일치하는 항목의 예:
커버리지를 보완하기 위해 희귀 원자도 찾아야 합니다. 다음 ES|QL은 5 또는 7 하루 룩백 창을 사용하여 10분 일정으로 실행되도록 설계되었습니다. 룩백은 전체 창에 걸쳐 규칙 이름별로 모든 알림을 집계하여 처음 본 시간을 계산합니다. 최종 필터(Esql.recent <= 10)는 현재 실행 기간인 10분 이내에 처음 표시되는 규칙만 표시되도록 하여 룩백 기간에 규칙이 처음 실행되는 순간을 효과적으로 감지합니다. 이를 통해 드물게 발생하는 오탐과 은밀한 동작을 모두 찾아낼 수 있습니다:
from logs-endpoint.alerts-*
| WHERE event.code == "behavior" and rule.name is not null
| STATS Esql.alerts_count = count(*),
Esql.first_time_seen = MIN(@timestamp),
Esql.last_time_seen = MAX(@timestamp),
Esql.agents_distinct_count = COUNT_DISTINCT(agent.id),
Esql.process_executable = VALUES(process.executable),
Esql.process_parent_executable = VALUES(process.parent.executable),
Esql.process_command_line = VALUES(process.command_line),
Esql.process_hash_sha256 = VALUES(process.hash.sha256),
Esql.host_id_values = VALUES(host.id),
Esql.user_name = VALUES(user.name) by rule.name
// first time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)
| keep host.id, rule.name, Esql.*다른 타사 EDR의 외부 알림에도 동일한 로직을 적용할 수 있습니다:
엔드포인트와 네트워크 알림 상관관계
강력한 탐지 접근 방식은 엔드포인트 알림과 네트워크 알림을 상호 연관시키는 것입니다. 이는 핵심 질문에 대한 답을 찾는 데 도움이 됩니다:
이 네트워크 경고를 트리거한 프로세스는 무엇인가요?
네트워크 알림만으로는 어떤 사용자나 실행 파일이 활동을 시작했는지 등 프로세스 컨텍스트가 부족한 경우가 많습니다. 네트워크 알림과 엔드포인트 원격 분석(EDR 데이터)을 결합하여 알림을 강화할 수 있습니다:
- 프로세스 이름 및 해시
- 명령줄 및 상위 프로세스
- 사용자 및 디바이스 정보
다음 쿼리는 모든 Elastic Defend 경보를 팔로알토 네트웍스(PANW) 및 포티넷 포티게이트와 같은 네트워크 보안 장치에서 발생한 의심스러운 이벤트와 연관시킵니다. 조인 키는 IP 주소로, 네트워크 알림의 경우 source.ip, 엔드포인트 알림의 경우 host.ip 입니다. 이 쿼리는 COALESCE 을 사용하여 단일 필드로 정규화하여 동일한 엔터티에 대해 서로 다른 필드 이름을 사용하는 데이터 소스 간에 상관 관계를 지원합니다. 이는 이 호스트가 손상되어 다중 데이터 소스 경고를 트리거하고 있음을 나타낼 수 있습니다.
FROM logs-* metadata _id
| WHERE
(event.module == "endpoint" and event.dataset == "endpoint.alerts") or
(event.dataset == "panw.panos" and event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", ...)) or
(event.dataset == "fortinet_fortigate.log" and (...)) or
(event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", ...))
| eval
fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null
| stats Esql.alerts_count = COUNT(*),
Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
Esql.message_values_distinct_count = COUNT_DISTINCT(message),
... by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
| where concat_module_values like "*endpoint*"FortiGate 경보의 source.ip가 Elastic Defend 엔드포인트 경보의 host.ip와 동일한 경우 Elastic Defend와 Fortigate 경보의 상관관계가 일치하는 예입니다:
다음 EQL 쿼리는 Suricata 경보를 Elastic Defend 네트워크 이벤트와 연관시켜 소스 프로세스 및 호스트에 대한 컨텍스트를 제공합니다:
sequence by source.port, source.ip, destination.ip with maxspan=5s
// Suricata severithy 3 corresponds to information alerts, which are excluded to reduce noise
[network where event.dataset == "suricata.eve" and event.kind == "alert" and event.severity != 3 and source.ip != null and destination.ip != null]
[network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]웹 익스플로잇 시도를 확인하는 Elastic Defend 이벤트에서 Suricata 경보를 확인하고 이를 대상 웹 서버 프로세스 nginx에 연결하는 일치 예시입니다:
통합 가시성을 갖춘 엔드포인트 보안
통합 가시성 원격 분석과 보안 알림의 상관 관계는 강력한 탐지 전략입니다.
XZ Utils 백도어 사고는 보안 관련 이상 징후가 기존의 보안 경보가 아닌 성능 저하로 먼저 나타날 수 있음을 보여주었습니다. 이 경우 SSH 데몬의 비정상적인 동작으로 인해 심층 조사가 진행되었고 결국 악성 코드가 발견되었습니다.
이는 운영상의 이상 징후가 보안 침해의 초기 징후일 수있다는 중요한 원칙을 강조합니다.
Elastic 에이전트를 사용하면 보안 원격 분석과 함께 CPU 및 메모리 사용률과 같은 시스템 메트릭을 수집할 수 있습니다. 비정상적인 리소스 급증을 프로세스별 또는 호스트별 SIEM 알림과 연관시켜 탐지 신뢰도를 높이고 고위험 활동을 조기에 발견할 수 있습니다.
예를 들어, ES|QL 상관관계 규칙은 지속적인 70% CPU 사용률을 보이는 프로세스를 식별할 수 있으며, 이 프로세스는 Elastic Defend의 크립토마이너에 대한 메모리 서명 경보의 원인이기도 합니다. 각 신호는 개별적으로 심각도가 낮거나 중간일 수 있습니다. 서로 연관성이 높은 악성 활동을 나타냅니다.
저희는 다양한 유형의 관계를 포괄하는 30 상위 주문 감지 기능을 개발했습니다. 여기서 모든 규칙을 다룰 수는 없지만 아래 링크는 이러한 규칙을 사용자 환경에 맞게 조정할 수 있는 충분한 컨텍스트를 제공합니다:
엔드포인트 알림:
에이전트별 다중 Elastic Defend 알림
단일 프로세스 트리의 여러 Elastic Defend 알림
호스트별 여러 개의 희귀한 Elastic Defend 행동 규칙
새로 관찰된 Elastic Defend 행동 경보
호스트별 여러 외부 EDR 경보
엔드포인트 및 네트워크:
새로 관측된 팔로알토 네트워크 경고
새로 관찰된 심각도가 높은 수리카타 경고
비정상적인 프로세스의 트래픽을 차단하는 FortiGate SOCKS
PANW와 Elastic Defend - 명령 및 제어 상관관계
Elastic Defend와 네트워크 보안 경보 상관관계
Suricata와 Elastic Defend 네트워크 상관관계
MITRE ATT의 일반&CK:
다른 ATT의 알림&호스트별 CK 전술
동일한 ATT의 여러 알림&호스트별 CK 전술
일반적인 다중 통합 상관관계:
소스 주소별 여러 통합의 알림
대상 주소별 여러 연동 서비스의 알림
사용자 이름별 여러 통합의 알림
새로 관찰된 심각도가 높은 탐지 알림
측면 이동 상관관계:
손상된 호스트에서 의심되는 측면 이동
새로 관측된 소스 주소로부터의 측면 이동 알림
새로 관찰된 사용자로부터의 측면 이동 알림
통합 가시성과 보안 상관관계
CPU 스파이크를 나타내는 프로세스에 대한 탐지 알림
CPU 스파이크를 나타내는 호스트에 대한 여러 개의 알림
높은 CPU 사용량을 보이는 새로 관찰된 프로세스
머신 러닝 상관관계:
인플루언서 분야별 다중 머신 러닝 알림
기타 상관관계 아이디어:
Wiz를 통한 자산별 다중 취약점 확인
Elastic Defend와 이메일 알림 상관관계
의심스러운 Kerberos 인증 티켓 요청
소스 주소로 액세스한 여러 클라우드 비밀
이 예는 엔드포인트, 네트워크, 통합 가시성 전반에서 알림을 상호 연관시켜 컨텍스트를 풍부하게 하고 조사를 가속화하며 탐지 신뢰도를 향상시킬 수 있는 방법을 보여줍니다. 추가적인 상관관계 시나리오를 지원하기 위해 이 영역의 범위를 적극적으로 확장하고 있습니다.
태그 값 규칙 유형으로 필터링하여 활성화할 수 있습니다: 규칙 관리 페이지에서 상위 주문 규칙을 선택합니다:
15일 동안 알림 수는 허용 가능한 수준(하루 최대 30건)을 유지했습니다. 초기 이상값을 타겟팅하여 조정하면 하루에 최대 20건의 알림으로 줄어들고 전반적인 신호 품질이 크게 개선될 것으로 예상됩니다.
고려 사항 및 장단점
상위 주문 규칙은 잠재적인 스케줄링 지연을 유발합니다. 알림 인덱스를 쿼리하기 때문에 기본 알림이 실행되는 시점과 상관관계가 드러나는 시점 사이에는 내재적인 지연이 있습니다. 규칙 스케줄링 간격과 루프백 윈도우는 적시성과 성능 비용의 균형을 맞추도록 조정해야 합니다. 또한 HOR 품질은 기본 탐지 품질에 직접적으로 의존합니다. 노이즈가 많은 원자 규칙은 이를 참조하는 모든 상관관계에 오탐을 연쇄적으로 발생시킵니다. 종속적인 상위 규칙을 활성화하기 전에 기본 규칙을 적극적으로 조정하는 것이 좋습니다. 마지막으로, ESQL은 광범위한 인덱스 패턴에 대한 쿼리(예 로그-*)는 대규모로 비용이 많이 들 수 있습니다. 대용량 환경에서는 특정 데이터 집합으로 인덱스 패턴의 범위를 지정하거나 데이터 뷰를 사용하면 쿼리 비용을 크게 줄일 수 있습니다.
결론
우선순위가 높은 규칙은 경보 분류의 우선순위를 정하고 자동화 및 AI 기반 분석을 위해 경보 볼륨을 관리하는 데 필수적입니다**.**. 엔티티 리스크 스코어링과 결합하면 상위 규칙을 호스트 및 사용자 리스크 프로필에 직접 적용할 수 있어 정량적 우선순위 지정 계층을 생성하여 수동 분류의 부담을 더욱 줄일 수 있습니다. 프로덕션 테스트에서 이러한 탐지의 대부분은 중간에서 낮은 경보 볼륨을 생성하여 실제 사용에 실용적이었습니다. 처음에는 소수의 노이즈가 많은 규칙이나 오탐이 나타날 수 있지만, 원자 규칙 수준에서 이를 제외하면 빠르게 높은 가치의 강력한 상관관계 집합이 남게 됩니다.
효과를 극대화하려면 두 가지 운영 관행이 중요합니다. 첫째, 입력 알림이 노이즈와 실제 영향을 모두 정확하게 반영하는 심각도 수준을 사용하도록 하고, 심각도를 정리하고 정규화하는 것이 의미 있는 상관관계를 위한 기본입니다. 둘째, 작게 시작하여 신중하게 확장하세요: 가능한 모든 경고 신호를 연관시키려고 하지 마세요. 본질적으로 노이즈가 많은 전술(예: 검색)을 제외하고, 심각도가 낮은 신호의 우선순위를 낮추고, 상관관계 결과에 불균형적으로 영향을 미치는 규칙을 더 이상 사용하지 않습니다.
하이오더 규칙을 올바르게 적용하면 조사를 간소화하고 탐지 정확도를 개선하며 최신 보안 운영의 효율성과 신뢰성을 크게 높일 수 있습니다.