컨텍스트 인식 분석 만들기
Chronicle을 사용하면 Chronicle 계정 내에서 원격 분석, 항목 컨텍스트, 관계, 취약점을 한 번의 감지 작업으로 확인할 수 있습니다. 원격 분석의 행동 패턴과 이러한 패턴의 영향을 받는 항목 컨텍스트까지 모두 이해할 수 있게 해주는 항목 컨텍스트화 기능을 제공합니다.
예를 들면 다음과 같습니다.
- 무작위 공격 로그인이 시도되는 계정의 권한을 제공합니다.
- 아웃바운드 네트워크 활동의 소스이기도 한 애셋에서 호스팅되는 데이터의 중요도
고객은 감지 필터링, 휴리스틱 알림 우선순위화, 분류, 조사에 이러한 컨텍스트화를 사용할 수 있습니다.
보안 분석가 및 감지 엔지니어는 일반적으로 이벤트 원격 분석의 기본 패턴(아웃바운드 네트워크 연결)에 따라 감지를 구성해서 분석가 분류를 위해 여러 감지를 만듭니다. 분석가는 알림이 트리거된 상황과 해당 위협의 중요성에 대한 이해를 결합하려고 시도합니다.
컨텍스트 인식 분석은 감지 작성 및 실행 워크플로의 초기에 고급 보강 기능을 사용함으로써 다음과 같은 추가 기능을 제공할 수 있게 해줍니다.
- 인간 분류 단계보다는 감지 실행 시간에 감지에 대한 휴리스틱 기반의 상황별 위험 평가를 위해 관련 컨텍스트를 사용할 수 있도록 지원
- 분류 시간을 줄이고 개별 IT 보안 시스템(EDR 콘솔, 방화벽/프록시 로그, CMDB 및 IAM 컨텍스트, 취약점 스캔 결과)의 정보를 수동으로 결합할 수 있도록 지원
- 분석가 및 감지 엔지니어가 예상 가능하거나 기업에 거의 위험하지 않은 전체 위협을 필터로 제외할 수 있도록 지원(샌드박스 환경의 멀웨어 테스트, 민감한 정보 또는 액세스 권한 없이 개발 네트워크에서 수행되는 취약점 및 비정상 활동 등)
컨텍스트 인식 분석을 위한 규칙 작성
Detection Engine 규칙을 사용하여 Chronicle 계정의 항목 컨텍스트 데이터를 검색할 수 있습니다.
항목 컨텍스트 데이터를 검색하려면 다음을 수행합니다.
udm 또는 항목을 사용하여 소스를 지정합니다.
$eventname.[<source>].field1.field2항목 컨텍스트에서 <source>는 'graph'입니다. UDM 이벤트에서 <source>는 'udm'입니다. 생략하면 <source>에 기본적으로 udm이 사용됩니다.항목 데이터를 지정합니다.
$e1.graph.entity.hostname = "my-hostname"$e1.graph.entity.relations.relationship = "OWNS"UDM 이벤트 데이터를 지정합니다. 다음 문은 동일합니다.
$e1.udm.principal.asset_id = "my_asset_id"$e1.principal.asset_id = "my_asset_id"
다음을 포함하여 UDM 이벤트에서와 같이 항목 컨텍스트에 같은 유형의 많은 규칙을 만들 수 있습니다.
여러 이벤트 규칙
항목 컨텍스트를 다른 항목 컨텍스트와 비교
항목 컨텍스트를 UDM 이벤트와 비교
항목 컨텍스트의 반복 필드
슬라이딩 기간
감지를 위한 위험 점수 계산
UDM 이벤트와 달리 항목 컨텍스트에는 특정 타임스탬프가 없습니다. 각 항목 컨텍스트 레코드에는 항목 컨텍스트가 유효한 시간 간격(entity.metadata.interval)이 있습니다. 이 시간 간격은 일 경계가 될 수 없으며 임의의 기간일 수 있습니다.
UDM 이벤트는 UDM 이벤트의 타임스탬프가 항목 컨텍스트 레코드의 시간 간격 내에 있는 경우에만 항목 컨텍스트 레코드와 상관관계가 있습니다. 이 조건이 충족되지 않으면 UDM 및 항목이 감지 대상으로 평가되지 않습니다. 감지 엔진은 이를 암시적으로 적용하며, 이를 규칙의 조건으로 지정할 필요가 없습니다.
- UDM 이벤트를 윈도잉이 있는 항목 컨텍스트와 비교할 때 항목 컨텍스트는 지정된 기간 동안의 상수 값을 나타냅니다.
- 항목 컨텍스트에서 해당 값이 변경되는 인접한 일 버킷이 있는 경우 Chronicle은 모든 항목 컨텍스트 값과 매칭을 시도하고 발견된 모든 일치 항목을 반환합니다.
규칙 예시
관리자 컨텍스트로 항목 검색
다음 규칙은 관리자 권한에 연결된 항목을 검색합니다. 관리자 권한이 있는 누군가가 시스템에서 로그인 또는 로그아웃을 시도한 시간을 찾습니다.
rule LoginLogout {
meta:
events:
$log_in.metadata.event_type = "USER_LOGIN"
$log_in.principal.user.user_display_name = $user
$log_out.metadata.event_type = "USER_LOGOUT"
$log_out.principal.user.user_display_name = $user
$log_in.metadata.event_timestamp.seconds <=
$log_out.metadata.event_timestamp.seconds
$context.graph.entity.user.user_display_name = $user
$context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"
match:
$user over 2m
condition:
$log_in and $log_out and $context
}
슬라이딩 구간 예시
다음 슬라이딩 구간 예시는 유효합니다.
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Using e2 (a UDM event) as a pivot.
$host over 3h after $e2
condition:
$e1 and $e2
}
잘못된 슬라이딩 구간 예시
다음 슬라이딩 구간 예시는 유효하지 않습니다. 항목 컨텍스트는 슬라이딩 구간의 피벗으로 사용될 수 없습니다.
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Attempting to use $e1 (an entity context) as a pivot. Invalid.
$host over 3h after $e1
condition:
$e1 and $e2
}
결과 섹션을 사용한 로그인 예시
다음 예시에서는 outcome 섹션을 사용하여 감지 위험 점수를 계산합니다.
rule Detection {
meta:
events:
$auth.metadata.event_type = "USER_LOGIN"
$auth.metadata.vendor_name = "Acme"
$auth.metadata.product_name = "Acme SSO"
$auth.target.user.userid = $user
$auth.target.user.termination_date.seconds > 0
$auth.metadata.event_timestamp.seconds >
$context.graph.entity.user.termination_date.seconds
$context.graph.metadata.vendor_name = "Microsoft"
$context.graph.metadata.product_name = "Azure Active Directory"
$context.graph.metadata.entity_type = "USER"
$context.graph.entity.user.userid = $user
$context.graph.entity.user.termination_date.seconds > 0
match:
$user over 15m
outcome:
$risk_score = max(
if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
if (
$context.graph.entity.user.title = "Remote" nocase or
$context.graph.entity.user.title = "Temp" nocase or
$context.graph.entity.user.title = "Vendor" nocase, 40) +
if ( $context.graph.entity.user.title = "Legal" nocase, 10)
)
condition:
$auth and $context
}
의심스러운 프로세스 실행 예시
다음 예시에서는 항목 컨텍스트로 저장된 IOC 컨텍스트 데이터에 대해 UDM 이벤트 프로세스 데이터를 평가합니다.
rule ProcessLaunch {
meta:
events:
$ioc.graph.metadata.vendor_name = "ACME"
$ioc.graph.metadata.product_name = "IOCs"
$ioc.graph.metadata.entity_type = "FILE"
$ioc.graph.entity.file.sha256 = $hash
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.hostname = $hostname
(
not $process.target.process.file.sha256 = "" and
$process.target.process.file.sha256 = $hash
)
match:
$hash over 15m
condition:
$ioc and $process
}
항목 컨텍스트의 추가 한정자
항목 컨텍스트를 사용하는 이벤트 변수를 만들려면 이벤트 이름 다음에 <source>를 제공해야 합니다. <source>는 graph여야 합니다.
다음 패턴은 항목 컨텍스트를 참조합니다.
$e.graph.entity.hostname
UDM 이벤트를 참조할 때는 두 가지 동일한 메서드가 있습니다.
$u.udm.principal.asset_id$u.principal.asset_id
규칙 텍스트에서 이러한 한정자를 모두 혼합하고 매칭할 수 있습니다. 동일한 이벤트에 다른 한정자를 사용할 수도 있습니다.
결과 섹션
Detection Engine에서는 규칙에서 더 많은 정보를 파생할 수 있게 해주는 outcome 섹션이 지원됩니다. outcome 섹션에 정의된 논리는 각 감지에 대해 평가됩니다. 규칙에서 N개의 발견 항목을 생성하면 N개의 각 발견 항목은 다른 결과 집합을 초래할 수 있습니다.
여기에서 outcome 섹션을 사용하는 예시 규칙을 찾을 수 있습니다.
outcome 섹션의 자세한 사용법 및 구문은 이 섹션에서 찾을 수 있습니다.
결과 섹션 및 발견 항목 중복 제거/발견 항목 그룹화
일치 섹션이 있는 규칙의 경우 발견 항목이 일치 변수에 따라 '그룹화'됩니다. 이렇게 하면 발견 항목이 중복 제거되어, 일치 변수 및 시간 기간의 각 고유 집합에 대해 하나의 행이 반환됩니다.
이러한 중복 제거를 수행할 때 결과 변수는 무시됩니다. 따라서 일치 변수 및 시간 기간에 대해 값이 동일한 2개의 서로 다른 발견 항목이 있지만 결과 변수의 값이 서로 다르면 이러한 발견 항목이 중복 제거되고 발견 항목 하나만 표시됩니다. 예를 들어 늦게 도착한 데이터로 인해 발견 항목이 생성되었을 때 이러한 경우가 발생할 수 있습니다. 다음은 이러한 경우를 보여주는 예시입니다.
rule ExampleOutcomeRule {
...
match:
$hostname over <some window>
outcome:
$risk_score = <some logic here>
...
}
이 규칙에 따라 다음 일치가 발생합니다.
발견 항목 1: 호스트 이름: test-hostname 시간 기간: [t1, t2] risk_score: 10
발견 항목 2: 호스트 이름: test-hostname 시간 기간: [t1, t2] risk_score: 73
발견 항목 1과 발견 항목 2 모두 일치 변수 및 시간 기간이 동일하기 때문에 이 두 항목이 중복 제거되고 결과 변수인 risk_score가 다르더라도 발견 항목이 하나만 표시됩니다.
다음 단계
Chronicle이 문맥 데이터를 수집하고 항목을 보강하는 방법에 대한 자세한 내용은 Chronicle이 이벤트 및 항목 데이터를 보강하는 방법을 참조하세요.