규칙 효과 및 효율성 분석
이 가이드는 Google Security Operations에서 규칙을 만들고 배포하고 모니터링하는 보안 엔지니어를 위한 가이드입니다. Google SecOps 인스턴스에서 제공되는 데이터를 사용하여 규칙이 의도한 대로 작동하고 리소스를 과도하게 사용하지 않는지 확인하기 위해 규칙을 모니터링하는 방법을 설명합니다. 이 데이터는 지연된 감지를 디버그하고, 늦게 도착하는 보강 데이터가 규칙에 미치는 영향을 파악하고, 감지 시간 (MTTD)이 가장 긴 규칙을 식별하는 데 도움이 됩니다.
이 가이드에서는 다음 작업에 관한 문서를 제공합니다.
초기 출시 중에 규칙을 평가하고, 알림을 수신하고, 규칙 대시보드 를 확인하여 상태를 모니터링하는 방법
감지 지연의 원인 (예: 늦은 수집 또는 비효율적인 로직으로 인한 것인지 여부)을 식별하고 감지 시간 (MTTD) 보고를 조정하거나 추가 규칙 제외 로 규칙을 조정하는 방법
시작하기 전에
이 문서에 설명된 대로 규칙을 보고 수정하려면 Chronicle API 편집기여야 합니다. 자세한 내용은 Google Security Operations 역할 및 권한을 참고하세요.
Google SecOps에서 규칙의 효과를 분석하기 전에 YARA-L 언어, YARA-L 쿼리, 규칙을 만들고 관리하는 방법, 대시보드를 만드는 방법을 잘 이해해야 합니다.
주요 용어
- 규칙: 로그 데이터가 Google SecOps 계정으로 수집될 때 위협을 자동으로 식별합니다.
- 할당량: 데이터 수집 볼륨, 데이터에 대해 실행할 수 있는 쿼리의 수와 복잡성, Google SecOps 계정에서 활성화된 규칙의 수와 복잡성 에 대한 제한입니다.
- 알림 및 감지: Google SecOps 및 자체 보안 인프라에서 식별한 보안 문제로, 주의가 필요합니다.
- 수집: 보안 데이터를 Google SecOps로 가져오고 UDM으로 변환하는 프로세스입니다.
- 규칙 재생: 관련 문맥 데이터가 초기 이벤트 데이터보다 늦게 도착하거나 처리되는 경우 기존 데이터에 대해 규칙을 자동으로 다시 실행합니다.
- Retrohunt: 기존 데이터에 새 규칙을 적용하여 이전에 발견되지 않은 위협을 식별합니다.
규칙 분석 방법
다음 섹션에서는 규칙의 성능을 분석하는 방법을 설명합니다.
배포 후 규칙 테스트 및 평가
규칙을 처음 프로덕션에 배포할 때는 24~48시간 동안 Rule Observability 대시보드에서 모니터링합니다.
대시보드 로 이동합니다.
Rule Observability를 검색합니다.규칙 열에서 새 규칙을 검색합니다. 규칙 관찰 가능성 대시보드에는 감지 수, 수집 지연 시간, 수집부터 감지까지의 시간과 같은 통계가 포함됩니다.
규칙 로직이 우선순위가 높은 알림을 생성하기 전에 인위적인 지연을 발생시키지 않도록 하려면 감지에 스키마 참조를 사용하면 됩니다. 스키마는 보안 알림을 모니터링하는 데 사용되는 구조화된 형식을 정의합니다. 감지 빈도, 위험 분포, 규칙 성능을 추적하는 데 최적화되어 있습니다. 쿼리 예시를 자세히 살펴보면 스키마를 사용하는 방법을 더 잘 이해할 수 있습니다.
규칙 결과 지연의 원인 파악
규칙 결과가 지연되는지, 지연된다면 그 이유는 무엇인지 확인하려면 다음 단계를 완료하세요.
- 감지 > 알림 및 IOC 로 이동합니다.
- 알림 탭에서 감지 유형 열을 찾습니다.
- 노란색 전구 아이콘이 있는 알림을 검색합니다.
- 아이콘 위로 마우스를 가져가 감지가 다음 중 하나에 의해 트리거되었는지 확인합니다.
- 규칙 재처리: 사용자가 수동으로 트리거합니다.
- Retrohunt: 사용자가 수동으로 트리거합니다.
- 지연된 이벤트 데이터: 감지 지연이 예상되는지 여부를 나타냅니다.
감지 시간을 기준으로 알림 필터링
감지 > 알림 및 IOC 로 이동합니다.
알림 탭에서 감지 시간 열의 필터 요소를 사용하여 도착 시간을 기준으로 감지를 정렬합니다.
표 상단의 새로고침 아이콘 을 클릭하고 지금 새로고침을 클릭합니다. Google SecOps 계정에 도착하는 최신 알림과 각 알림과 연결된 규칙을 확인할 수 있습니다 (규칙 이름 열 확인).
메타데이터 검토
규칙의 성능에 관한 추가 통계를 얻으려면
원시 감지 JSON을
latencyMetrics를 사용하여 검사하여 oldestEventTime
과 oldestIngestionTime 간의 차이를 찾으면 됩니다.
감지 타이밍 값
다음 표에는
DetectionTimingDetails와 연결된 열거된 값이 나와 있습니다.
값 |
설명 |
MTTD 영향 |
|---|---|---|
|
표준 일정 예약 기간 내에 생성된 감지입니다. |
MTTD의 사실입니다. |
|
규칙 재생 (예: 늦게 도착하는 데이터)으로 인해 생성되었습니다. |
운영 위험을 나타내며 보고서에 반영해야 합니다. |
|
이전 Retrohunt 실행을 통해 생성되었습니다. |
일반적으로 표준 MTTD 보고에서 필터링됩니다. |
예: latencyMetrics 메타데이터
다음
latencyMetrics
예시에서는 이벤트가 발생한 시간
(oldestEventTime과 newestEventTime)과 이벤트가 수집된 시간
(oldestIngestionTime과 newestIngestionTime) 간의 시간 차이를 보여줍니다. 이벤트와 Google SecOps 계정으로의 수집 간의 지연 시간은 약
53분입니다.
"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
"oldestIngestionTime": "2025-12-09T16:54:14Z",
"newestIngestionTime": "2025-12-09T16:54:14Z",
"oldestEventTime": "2025-12-09T16:01:06Z",
"newestEventTime": "2025-12-09T16:01:06Z"
}
|
|---|
문제 해결
다음 표에는 규칙과 관련하여 발생할 수 있는 문제와 해결 방법이 나와 있습니다.
문제 |
해결 방법 |
|---|---|
전구 아이콘이 표시되지만 열거형은 UNSPECIFIED. |
이벤트 시간과 수집 시간 간의 델타가 30분을 초과하면 정상적인 동작입니다. 데이터 상태 허브 측정항목을 사용하여 수집 지연의 원인을 조사합니다. |
이벤트 시간에 비해 감지가 늦게 표시됩니다. |
detectionTimingDetails를 확인합니다. 열거형 값이 REPROCESSING인 경우 지연은 규칙 실행 지연 시간보다는 늦게 도착하는 보강 데이터로 인한 것일 가능성이 높습니다. UNSPECIFIED인 경우 규칙 로직의 효율성을 조사합니다. |
과도한 컴퓨팅. |
규칙이 너무 많은 데이터를 스캔하거나 비효율적인 로직을 가지고 있을 가능성이 높습니다. 규칙 제외 로 이동하거나 필터 오프로드 를 사용하여 규칙을 조정하여 데이터 검색 범위를 좁힙니다. |
알려진 제한사항
- 기준점 경직성: 늦은 데이터의 시각적 신호는 30분 기준점으로 고정되어 있으며 사용자 정의 지연 시간 창을 고려하지 않습니다.
- 데이터 상태: 규칙 관찰 가능성은 규칙 상태를 알려주지만 데이터 상태 모니터링 (수집에 더 가까움)은 일반적인 늦게 도착하는 데이터 문제를 포착하는 데 더 효과적입니다.
- 할당량 적용: 대시보드에 리소스 사용량이 표시되지만 규칙이 할당량 한도에 가까워지면 실시간 알림을 제공하지 않습니다.
다음 단계
규칙 재생 및 규칙 감지 지연에 관한 자세한 내용은 다음을 참고하세요.
도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.