규칙 체이닝
규칙 체이닝을 사용하면 한 규칙의 출력이 다른 규칙의 입력으로 작동하도록 규칙을 상호 연결할 수 있습니다. 이 기능을 사용하면 더 복잡하고 유연한 규칙을 만들 수 있습니다. 규칙 체이닝은 여러 데이터 소스와 기간에서 이벤트를 연관시키고 분석하여 개별 이벤트 감지의 한계를 극복합니다.
규칙 체이닝의 이점:
다단계 공격 파악: 사이버 공격은 종종 서로 연결되어 있습니다. 규칙 체이닝은 단독으로 발생한 것처럼 보이는 이슈 간의 연결을 보여줌으로써 공격 내러티브를 파악하는 데 도움이 됩니다. 예를 들어 규칙 체이닝을 사용하면 초기 침해 후 권한 에스컬레이션 및 데이터 유출과 같은 전체 공격 시퀀스를 식별할 수 있습니다.
알림 피로 완화: 소비자 규칙을 구현하여 중요한 위협에 우선순위를 두고 알림 피로를 완화합니다. 이러한 규칙은 프로듀서 규칙에서 생성된 노이즈 알림을 통합하고 필터링하여 보다 집중적인 응답을 가능하게 합니다.
감지 정확도 향상: UDM 이벤트, 기타 규칙 감지, 항목 정보, UEBA 발견 항목, 데이터 표의 통계를 결합하여 정확한 감지 로직을 만듭니다.
복잡한 로직 간소화: 복잡한 감지 시나리오를 관리 가능하고 상호 연결된 재사용 가능한 규칙으로 분류하여 개발 및 유지관리를 간소화합니다.
규칙 체이닝 용어 및 개념:
감지: 규칙의 결과이며 알림이라고도 합니다.
체인: 한 규칙의 출력이 다음 규칙의 입력으로 사용되는 일련의 규칙입니다. 예를 들어 rule1 -> rule2 -> rule3 체인에서 rule1에서 생성된 감지는 rule2에서 새 감지를 생성하는 데 사용되며, rule3에서는 이 감지를 사용하여 자체 감지 집합을 생성합니다.
생산자 규칙: 감지가 다른 규칙의 입력으로 사용되는 규칙입니다. 모든 규칙이 생산자 규칙으로 작동할 수 있으며 특별한 지정이 필요하지 않습니다. 생산자 규칙은 항목과 이벤트를 입력으로 사용합니다. 감지를 입력으로 사용하지 않습니다.
소비자 규칙: 감지를 규칙 텍스트의 입력으로 사용하는 규칙입니다. 소비자 규칙에는 일치 섹션이 있어야 합니다.
체이닝 규칙: 소비자 규칙이라고도 합니다.
고급 개념
단일 이벤트 감지 규칙
Google SecOps에서는 단일 이벤트 감지 규칙을 허용하지 않습니다. 즉, 감지를 데이터 소스로 사용하는 모든 규칙에는 일치 섹션이 있어야 합니다.
감지 지연 시간
예약 문제로 인해 단일 이벤트 규칙에서만 소비자 규칙을 체이닝하는 것이 좋습니다. 단일 이벤트 규칙은 거의 실시간으로 실행되므로 이러한 규칙의 감지는 거의 항상 소비자 규칙의 첫 번째 실행에 사용할 수 있습니다. 다중 이벤트 규칙을 사용하여 규칙 체인을 만들면 생산자 규칙이 소비자 규칙 후에 실행되어 소비자 규칙에서 감지 생성이 지연될 수 있습니다.
TestRule 및 Retrohunt
소비자 규칙에서 RetroHunt를 테스트하거나 실행하면 기존 감지를 사용하여 선택한 특정 규칙만 실행됩니다. 전체 체인을 실행하려면 체인의 시작 부분에서 RetroHunt를 시작하고 각 실행이 완료될 때까지 기다린 후 다음 규칙을 실행해야 합니다.
규칙에서 테스트를 실행해도 감지가 유지되거나 데이터베이스에 쓰여지지 않으며 소비자 규칙은 입력 감지가 데이터베이스에 있어야 합니다. 따라서 테스트 규칙에서는 규칙 체인을 테스트할 수 없습니다.
규칙 체인 구성
생산자 규칙과 소비자 규칙을 조합하여 규칙 체인을 만듭니다.
제작자 규칙
제작자 규칙은 체인의 기반입니다. 이러한 시그니처는 결합 시 악의적인 활동을 나타내는 특정 이벤트 또는 조건을 식별합니다. 제작자 규칙을 구성하려면 다음 단계를 따르세요.
새 규칙 만들기 또는 기존 규칙 재사용
알림을 사용 중지하고 결과 섹션에서
$risk_score를 0으로 설정합니다. 이렇게 하면 이러한 규칙이 개별 알림을 생성하거나 항목 위험 점수에 영향을 미치지 않습니다. 이 구성을 사용하면 전체 이벤트 체인을 평가하는 소비자 규칙에서 생성된 더 중요한 알림에 우선순위를 지정할 수 있습니다.outcome섹션을 사용하여 체이닝 규칙에 액세스할 수 있는 변수를 정의합니다.
다음 프로듀서 규칙 예시에서는 로그인 실패를 감지합니다.
rule failed_login {
meta:
events:
$e.metadata.event_type = "USER_LOGIN"
any $e.security_result.action = "BLOCK"
outcome:
$risk_score = 0
$target_user = $e.target.user.userid
condition:
$e
}
이 규칙은 차단된 로그인을 식별하고 연결된 사용자를 제공합니다.
체이닝 규칙
감지를 사용하는 규칙을 작성하는 방법은 소스와 사용 가능한 필드가 다르다는 점을 제외하고 UDM을 사용하는 규칙과 거의 동일합니다. 감지 필드를 참조하려면 소스($eventname.detection.field1.field2)로 detection 키워드를 사용합니다.
detection 소스에서 사용할 수 있는 하위 필드는 컬렉션 리소스에서 확인할 수 있습니다.
다음은 컬렉션의 일반적인 필드입니다.
$d.detection.detection.rule_id$d.detection.detection.detection_fields["match_var_name"]$d.detection.detection.outcomes["outcome_name"]
다음 규칙 예시는 MFA, 열거, 무단 반출 없이 로그인을 감지합니다.
rule login_enumeration_exfiltration {
meta:
description = "Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration"
rule_name = "Login Without MFA, Enumeration, Exfiltration"
severity = "High"
events:
// Detection with name "Console Login Without MFA"
// The affected user is saved as $target_user
$login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/
$target_user = $login_without_mfa.detection.detection.outcomes["target_user"]
// Any detection with a rule name containing 'enumeration'
// The user performing enumeration is the user that logged in without mfa
$enumeration.detection.detection.rule_name = /enumeration/ nocase
$enumeration.detection.detection.outcomes["principal_users"] = $target_user
// Any detection with the mitre tactic 'TA0010' (Exfiltration)
// The user performing exfiltration is the user that logged in without mfa
$exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"
$exfiltration.detection.detection.outcomes["principal_users"] = $target_user
match:
// Looks for detections over a 24 hour period
$target_user over 24h
condition:
// All 3 must occur for a single user
$login_without_mfa and $enumeration and $exfiltration
}
계층적 감지
규칙 체이닝을 사용하면 계층적 감지 시스템을 만들 수 있습니다. 하위 수준의 생산자 규칙은 개별 의심스러운 이벤트를 식별합니다. 그런 다음 출력이 상위 수준 체이닝 또는 소비자 규칙에 제공됩니다. 이러한 규칙은 이 정보를 다른 소스의 데이터와 연결하여 단일 이벤트 규칙에서 놓칠 수 있는 다단계 공격 패턴을 감지합니다. Google Security Operations는 최대 3단계의 체이닝을 지원하여 정교한 감지와 관리 가능한 복잡성 간의 균형을 유지합니다.
예를 들면 다음과 같습니다.
수준 1: 제작자 규칙이 개별 의심스러운 이벤트를 감지합니다. 예를 들어 로그인 실패, 비정상적인 파일 액세스 등이 있습니다.
2단계: 체이닝 규칙은 1단계 감지를 연결합니다. 예를 들어 로그인 실패 후 의심스러운 파일 액세스가 발생할 수 있습니다.
3단계: 상위 체이닝 규칙은 2단계 감지와 기타 데이터를 결합하여 더욱 정교한 감지를 실행합니다. 예를 들어 인증과 관련된 수준 2 감지와 사용 중인 기기의 보안 상태와 관련된 수준 2 감지가 있습니다.
프로듀서 규칙 변경 시 고려사항
규칙 체인에서 생산자 규칙이 업데이트되면 새 버전의 생산자 규칙이 생성됩니다. 이는 로직 업데이트 (조건, 이벤트, 결과)와 메타데이터 업데이트 (이름, 설명, 심각도) 모두에 적용됩니다. 소비자 규칙은 새 버전을 사용하여 계속 작동합니다. 의도한 동작을 보장하려면 업데이트된 생산자 규칙과 하위 소비자 규칙을 테스트하는 것이 중요합니다.
제한사항
규칙 체이닝에는 다음과 같은 제한사항이 있습니다.
감지 전용 규칙 및 항목 위험 점수
감지 전용 규칙 (이벤트 또는 항목 데이터가 아닌 감지 데이터만 소스로 사용하는 규칙)은 항목 위험 점수에 기여하지 않습니다. 감지 전용 규칙에 설정된 위험 점수는 해당 규칙에 의해 생성된 감지에만 적용됩니다. 집계된 항목 위험 점수에 기여하지 않습니다.
규칙 체이닝을 위한 케이스 보기 지원
케이스 뷰에서는 복합 알림이 지원되지 않습니다.