규칙 감지 지연 이해하기
이 문서에서는 Google Security Operations의 규칙 감지 지연을 설명하고, 수집 및 처리 파이프라인 전반의 기여 요인을 식별하고, 구조화된 문제 해결 접근 방식을 설명하고, 감지 지연 시간을 줄이는 기술을 제공합니다.
감지 규칙 개요
감지 규칙은 정규화된 원시 로그(일반 및 항목 범용 데이터 모델(UDM) 이벤트 모두)를 검사하여 규칙 사양에 따라 보안 감지를 생성합니다. 항목 UDM 이벤트에는 일반적으로 사용자 또는 애셋 메타데이터와 같은 컨텍스트 정보가 포함됩니다. 감지 규칙은 이전에 생성된 감지를 평가하여 복합 알림을 생성할 수도 있습니다.
예상되는 지연 및 예상치 못한 지연
감지 지연 시간은 규칙 로직, 데이터 종속 항목, 시스템 처리 주기에 따라 달라집니다. 지연은 두 가지 유형으로 분류됩니다.
- 예상 지연: 수집 프로세스, 규칙 유형, 실행 빈도, 감지 생성 방법, 일치 기간, 알려진 시스템 한도와 같은 구조적 요인으로 인해 발생하는 지연입니다. 감지 규칙 구성 및 예약 매개변수를 조정하여 예상 지연을 최소화할 수 있습니다.
- 예측되지 않은 지연: 데이터 소스의 로그 전송 병목 현상, Google SecOps 서비스 내의 일시적인 처리 지연 시간, 지연된 컨텍스트 가용성, UDM 재보강 주기를 포함한 외부 또는 동적 파이프라인 조건으로 인해 발생하는 지연입니다.
감지 생성 방법
Google SecOps는 다음 실행 파이프라인을 통해 규칙 감지를 생성합니다.
- 스트리밍 엔진: 표준 및 기간이 지정된 단일 이벤트 규칙을 거의 실시간 (일반적으로 수집 후 5분 이내)으로 지속적으로 평가하는 고속 파이프라인입니다. 지연 도착 이벤트 및 소급 보강은 표준 실행 중에 지속적으로 평가됩니다.
- 쿼리 엔진: 여러 이벤트 또는 외부 데이터 조인에서 시간 기반 이벤트 상관관계가 필요한 규칙을 평가합니다.
- 복잡한 단일 이벤트 규칙: 참조 목록 또는 데이터 테이블을 쿼리하는 단일 이벤트 규칙이 포함됩니다.
- 멀티 이벤트 규칙: 구성된 일정에 따라 이벤트 시간의 일괄 블록 (예: 10분 또는 1시간 간격, 48시간을 초과하는 기간의 경우
match_window / 10)으로 데이터를 쿼리합니다.
- 이전 데이터에 대한 규칙 실행: 소급 검색을 통해 이전 로그에 대해 규칙을 소급하여 평가합니다. 이전 스캔이 완료되면 감지가 표시됩니다.
- UDM 이벤트 재보강: 새로운 컨텍스트 또는 업데이트된 항목 데이터가 이전 이벤트에 추가되면 이전에 처리된 시간 블록을 다시 평가합니다.
규칙 감지 지연에 영향을 미치는 요인
감지가 표시되는 속도는 규칙 복잡성, 예약 간격, 데이터 수집 지연 시간, 컨텍스트 보강 파이프라인에 따라 달라집니다.
규칙 유형 및 복잡성
감지 규칙은 지연 시간 프로필이 다른 여러 카테고리로 분류됩니다.
단일 이벤트 규칙
단일 이벤트 규칙은 연속 스트리밍 엔진에서 거의 실시간으로 실행되며 가장 낮은 감지 지연 시간을 제공합니다. 이러한 규칙은 외부 데이터 세트, 데이터 테이블 또는 멀티 이벤트 일치 기간을 조인하지 않고 개별 이벤트를 평가합니다.
복잡한 단일 이벤트 규칙
이러한 규칙은 단일 이벤트를 평가하지만 추가 데이터 종속 항목을 통합합니다.
- 기간이 지정된 단일 이벤트 규칙:
match섹션이 포함된 단일 이벤트 규칙입니다 (예: 단일 이벤트가 일정 기간 동안 조건과 일치하는지 평가). 이러한 규칙은 데이터가 수집될 때 연속 스트리밍 엔진에서 거의 실시간으로 평가됩니다. - 참조 단일 이벤트 규칙: 이벤트 속성을 참조 목록 또는 데이터 테이블과 비교하는 단일 이벤트 규칙입니다.
여러 이벤트 규칙
여러 이벤트 규칙은 지정된 일치 기간 동안 두 개 이상의 UDM 이벤트 조건을 상호 연결하고 예약된 일괄 간격으로 실행됩니다.
- 표준 다중 이벤트 규칙: 여러 기간에 걸쳐 여러 이벤트를 집계하고 10분 또는 1시간 간격 (또는 48시간을 초과하는 기간의 경우
match_window / 10)으로 실행합니다. - 컨텍스트 인식 규칙: 컨텍스트 인식 분석을 사용하여 이벤트 데이터를 UDM 항목 이벤트 (예:
user_context또는asset_context)와 상호 연결합니다. 컨텍스트 인식 규칙은 여러 데이터 피드를 사용하므로 수집 타이밍에 더 민감합니다. 자세한 내용은 규칙에서 컨텍스트 보강 데이터 사용을 참조하세요.
규칙 실행 빈도
구성된 실행 빈도에 따라 쿼리 엔진이 이벤트 시간 블록을 평가하는 빈도가 결정됩니다.
- 거의 실시간: 단일 이벤트 규칙 (표준 및 기간)에 대한 지속적인 평가입니다.
- 10분 빈도: 일치 기간이 60분 미만인 멀티 이벤트 규칙에 사용할 수 있습니다.
- 1시간 빈도: 일치 기간이 48시간 이하인 멀티 이벤트 규칙의 기본 간격입니다.
match_window / 10빈도: 일치 기간이 48시간을 초과하는 멀티 이벤트 규칙에 자동으로 할당됩니다 (예: 100시간 일치 기간의 경우 10시간마다 실행, 10일 기간의 경우 24시간마다 실행).
일치 기간
멀티 이벤트 규칙의 경우 일치 기간은 이벤트를 집계하는 데 필요한 관찰 기간을 정의합니다. 전체 기간이 경과할 때까지 감지가 표시되지 않습니다.
로그 수집 지연
수집 지연은 소스에서 이벤트가 발생한 시점과 Google SecOps가 로그를 수신하고 파싱하는 시점 사이에 경과된 시간입니다.
해당 시간 블록의 초기 예약 평가 후에 이벤트가 도착하면 첫 번째 실행을 놓칩니다. 시스템은 기본 실행 후 약 4시간 (보강 완료 시 30시간) 후에 발생하는 후속 자동 백그라운드 실행 (정산 실행)에서 지연 도착 데이터를 캡처합니다.
- 예시: 규칙은 30분 기간 내에 이벤트 A (이벤트 시간 오전 9시 3분)와 이벤트 B (이벤트 시간 오전 9시 5분)를 상호 연관시킵니다. 이벤트 A가 오전 10시 5분 (1시간 지연)에 도착하면 오전 9시~9시 30분 블록의 초기 실행을 놓칩니다. 시스템은 기본 실행 후 약 4시간 (오후 2시경)에 후속 정산 실행 중에 차단을 다시 평가하여 이벤트가 발생한 후 약 5시간 후에 감지를 생성합니다.
서드 파티 API 폴링 피드의 업스트림 색인 생성 지연 시간에 대한 자세한 내용은 폴링 피드의 지연 도착 이벤트를 참고하세요.
시간대 불일치
Google SecOps는 기본적으로 로그 타임스탬프를 UTC로 해석합니다. 로그 소스에서 명시적인 시간대 오프셋을 생략하면 시스템은 타임스탬프를 UTC로 처리하므로 로그가 즉시 수신되더라도 지연 도착으로 표시될 수 있습니다.
- 예시: 이벤트가 동부 표준시 오전 10시 (15:00 UTC)에 발생하고 시간대 메타데이터 없이 15:05 UTC에 Google SecOps에 도착합니다. 시스템은 타임스탬프를 10:00 UTC로 해석하여 5시간의 수집 지연이 발생한 것으로 인식하고 규칙 평가를 백그라운드 조정 실행으로 연기합니다.
해결 방법: 시간대 불일치를 해결하려면 다음 단계를 따르세요.
- 이벤트 타임스탬프에 명시적인 UTC 시간대 오프셋을 포함하도록 로그 소스를 구성합니다.
- 지원팀에 문의하여 특정 처리 피드의 시간대 재정의를 설정합니다.
- BindPlane 프로세서를 사용하여 수집 전에 로그 본문 타임스탬프를 UTC로 정규화합니다. 자세한 내용은 BindPlane을 사용하여 로그 본문 타임스탬프 수정을 참조하세요.
컨텍스트 조인 및 데이터 보강
Google SecOps는 보조 소스의 ID, 애셋, 위협 메타데이터를 추가하여 UDM 이벤트를 보강합니다. 컨텍스트 가용성이 지연되면 감지 타이밍이 연장될 수 있습니다.
별칭 지정 및 보강 메커니즘
별칭 지정 및 보강은 원시 지표를 조직 컨텍스트와 연관시킵니다.
- 별칭 지정: 데이터 소스 전반에서 동일한 항목의 여러 식별자를 식별하고 연결합니다(예: DHCP 로그의 IP 주소를 MAC 주소 및 호스트 이름(예:
alex-macbook)에 매핑하거나 사용자 ID를 직원 직책에 매핑). - 보강: 정규화된 UDM 이벤트 필드를 별칭이 지정된 컨텍스트로 채웁니다 (예: 원시 이벤트에 IP 주소만 있는 경우
$udm.event.principal.hostname채우기).
지원되는 보강 유형에는 애셋, 사용자, 프로세스, 파일 해시 메타데이터, 지리적 위치, 클라우드 리소스가 포함됩니다. 자세한 내용은 UDM 보강 및 별칭 지정 개요를 참조하세요.
UDM 이벤트 재보강
시스템은 컨텍스트 소스가 발전함에 따라 이전 이벤트를 지속적으로 업데이트합니다.
- 기본 데이터 변경: 새 문맥 데이터가 도착하면 이전 이벤트가 수집 후 최대 24시간 동안 업데이트될 수 있습니다.
- 보강 시스템 업데이트: 항목 메타데이터, IP 위치정보 또는 VirusTotal 위협 인텔리전스가 업데이트되면 규칙 엔진은 업데이트된 컨텍스트로 감지를 생성하기 위해 일반적으로 예약된 조정 실행 또는 재처리 중에 이전 블록을 다시 평가합니다.
- 지연된 컨텍스트 데이터: 컨텍스트 데이터 (예: 호스트 이름)가 이벤트 로그보다 하루 늦게 도착하면 시스템에서 UDM 이벤트를 다시 보강하고 후속 조정 실행에서 보강된 레코드를 평가합니다.
- 컨텍스트 수정: 보강 업데이트로 이벤트 속성이 변경되는 경우 (예: IP 위치정보를
USA에서Canada로 업데이트) 업데이트된 값과 일치하는 규칙은 후속 재평가 중에 감지를 트리거합니다.
항목 컨텍스트 그래프 (ECG) 처리
항목 컨텍스트 그래프 (ECG)는 침해 지표 (IOC)와 엔터프라이즈 애셋 그래프 데이터를 상호 연관시킵니다. ECG 파이프라인은 일괄 처리에 의존하므로 (데이터 양에 따라 30시간 또는 최대 며칠이 걸릴 수 있음) graph.entity 필드를 참조하는 규칙은 그래프 관계가 완전히 계산된 후에 감지를 생성합니다.
과거 규칙 실행 및 RetroHunt
이전 데이터에 대한 규칙을 실행하면 선택한 기간 동안 Retrohunt 스캔이 완료된 후에만 감지가 생성됩니다.
- 소급 보강 워크플로:
- 오후 1시에
ip_address = 10.0.0.5(호스트 이름 알 수 없음)이 포함된 이벤트가 도착합니다. - 오후 2시 30분에
10.0.0.5를workstation-123에 연결하는 DHCP 로그가 도착합니다. - 별칭 지정 파이프라인은 이전 오후 1시 이벤트를
principal.hostname = workstation-123로 업데이트합니다. - 후속 규칙 재생은 보강된 호스트 이름을 평가하고 초기 실행 중에 트리거되지 않은 감지를 표시합니다.
- 오후 1시에
참조 목록
참조 목록을 쿼리하는 규칙은 실행 시 최신 목록 버전을 기준으로 평가됩니다. 참조 목록을 업데이트하면 예약된 규칙이 이전에 수집된 로그에 대해 소급하여 감지를 생성할 수 있습니다.
존재하지 않는 규칙
거짓양성을 방지하기 위해 시스템은 존재하지 않는 조건 (예: !$e 또는 #e=0)을 확인하는 규칙을 평가하기 전에 최소 1시간의 버퍼를 도입하여 모든 관련 로그가 도착할 시간을 확보합니다.
데이터 처리 및 정산 제한사항
감지 지연 시간을 평가할 때는 다음 시스템 동작에 유의하세요.
- 보강 처리: 컨텍스트 보강은 초기 수집 후 최대 24시간 동안 이전 UDM 이벤트를 업데이트할 수 있습니다.
- 정산 주기: 다중 이벤트 규칙은 기본 실행 후 약 4시간 (선택적으로 30시간) 후에 자동으로 다시 실행되어 지연 도착 데이터를 캡처합니다. 자세한 내용은 규칙 재생 및 MTTD 이해를 참조하세요.
- 감지 한도: 플랫폼 용량 및 제한 경계는 감지 한도 이해를 참조하세요.
규칙 감지 지연 문제 해결
규칙에서 지연된 감지가 생성된 이유를 진단하려면 Google SecOps 콘솔에서 다음 휴리스틱 및 파이프라인 단계를 검토하세요.
- 규칙 메타데이터 및 일정 검토: 규칙 대시보드에서 규칙 이름, 규칙 유형, 규칙 일정 열을 확인하여 규칙의 실행 엔진과 기준 평가 빈도를 파악합니다.
- 이벤트 시간과 수집 시간 비교: 감지 탭에서 감지를 찾아 이벤트 타임스탬프를 수집 타임스탬프와 비교합니다. 이벤트 시간과 수집 시간의 차이가 30분을 초과하는 경우 소스 또는 수집 중 로그 전송 지연으로 인해 지연 시간이 발생한 것입니다. 30분 이상 지연되어 도착한 이벤트 데이터, 자동 정산 실행, 재처리 파이프라인 또는 Retrohunt에서 생성된 감지는 감지 유형 열에 아이콘을 표시합니다.
- 컨텍스트 소스 종속 항목 검토: 규칙이
principal보강, UDM 별칭 지정 또는graph.entity필드를 참조하는지 확인합니다. 컨텍스트 파이프라인은 비동기식으로 처리되며 후속 조정 실행 중에 감지 항목이 표시될 수 있습니다. - 빈도 및 일치 기간 호환성 확인: 구성된 실행 빈도가 일치 기간 크기와 일치하는지 확인합니다 (예: 일치 기간이 15분인 규칙이 10분 또는 1시간으로 예약되어 있는지 확인).
- 데이터 피드 중단 확인: 수집 로그 및 피드 관리 대시보드에서 수집 지연 또는 일시적인 소스 중단이 있는지 검토합니다.
감지 지연을 줄이기 위한 도움말
환경 전반에서 감지 지연을 최소화하려면 다음 최적화 기법을 적용하세요.
- 규칙 실행 빈도 최적화:
- 단일 이벤트 규칙 (표준 및 기간)에는 거의 실시간을 사용합니다.
- 일치 기간이 60분 미만인 멀티 이벤트 규칙에 대해 10분 일정을 구성합니다.
- 빠른 알림이 필요한 1~48시간 사이의 일치 기간이 있는 규칙에는 1시간을 사용합니다.
- 일치 기간 조정: 일치 기간을 연관된 위협 동작을 포착하는 데 필요한 최소 기간으로 설정합니다.
- 로그 전송 병목 현상 제거: 전달자와 수집기가 이벤트 데이터를 즉시 전송하여 로그가 초기 실행 기간을 놓치지 않도록 합니다.
- 시간대 구성 검증: 로그 소스가 명시적인 UTC 오프셋을 제공하여 5시간 이상의 수집 지연이 발생하지 않도록 합니다.
- 컨텍스트 및 존재하지 않는 조건 감사: 컨텍스트가 보강된 필드와 존재하지 않는 조건 (
!$e)은 감지 로직에 필요한 경우에만 사용하세요. 이러한 조건은 의도적인 버퍼링 기간을 도입하기 때문입니다.
다음 단계
관련 예약 개념 및 구성 워크플로를 살펴보려면 다음 문서를 참조하세요.
- 규칙 실행 예약 이해: Google SecOps가 규칙 구성을 연속 스트리밍 및 예약된 일괄 쿼리 엔진에 매핑하는 방법을 알아봅니다.
- 규칙에 맞춤 일정 구성: 다중 이벤트 규칙의 실행 빈도, 정산 지연, 정산 보강 완료를 맞춤설정합니다.
- 규칙 재생 및 MTTD 이해: 자동화된 트루업 실행이 지연 도착 데이터 및 컨텍스트 업데이트를 처리하여 평균 감지 시간 (MTTD) 측정항목에 영향을 미치는 방식을 알아봅니다.
- 규칙 편집기를 사용하여 규칙 관리: Google SecOps에서 커스텀 감지 규칙을 만들고, 수정하고, 관리합니다.
도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.