보강

다음에서 지원:

Google secops SIEM

강화에서는 다음 방법을 사용하여 통합 데이터 모델 (UDM) 표시기 또는 이벤트에 컨텍스트를 추가합니다.

일반적으로 UDM 필드인 지표를 설명하는 별칭 항목을 식별합니다.
식별된 별칭 또는 항목의 추가 세부정보로 UDM 메시지를 채웁니다.
UDM 이벤트에 GeoIP, VirusTotal과 같은 전역 보강 데이터를 추가합니다.

강화 로직 패턴 이해

Google SecOps는 보강 유형에 따라 데이터에 서로 다른 논리적 패턴을 적용합니다. 다음 표를 사용하여 문제 해결을 위한 이러한 패턴을 이해하고 특정 필드가 채워지거나 병합되거나 덮어쓰여지는 이유를 설명하세요.

논리 패턴	설명	적용 가능한 보강
첫 번째 경기	엄격한 우선순위 목록을 따릅니다. 파이프라인은 시퀀스에서 찾은 첫 번째 사용 가능한 값만 쿼리합니다.	아티팩트 (파일 해시)
병합됨	여러 필드의 데이터를 동시에 수집하고 결합하여 단일 '골든' 엔티티 레코드를 빌드합니다.	애셋, 사용자
조건부 대체	우선순위가 높은 식별자가 누락된 경우에만 특정 필드가 보강에 사용됩니다.	애셋 (`ip` 주소)
매핑 및 덮어쓰기	고유 ID (`PSPI`)를 사용하여 항목을 확인합니다. 강화 소스의 별칭이 지정된 데이터가 기존 파싱된 데이터를 대체합니다.	처리

애셋 보강

저작물 보강의 경우 파이프라인은 여러 UDM 필드를 평가하여 고유한 저작물을 식별합니다. 아티팩트 보강 (하나를 선택함)과 달리 애셋 보강은 여러 ID의 컨텍스트를 병합하여 완전한 애셋 프로필을 빌드합니다.

Google SecOps는 동일한 네임스페이스로 분류된 애셋 이벤트를 보강합니다.

저작물의 경우 특정 대체 시나리오를 제외하고 논리가 배타적이 아닌 누적입니다. 설명에 다음 세부정보를 사용하세요.

로직 유형: 병합됨 또는 대체 대체 조건 (예: asset_id 확인)이 충족되지 않는 한 파이프라인은 사용 가능한 모든 필드에서 데이터를 수집하여 단일 '엔티티' 뷰를 만듭니다.
필드 매핑:
- 호스트 이름, MAC, asset_id: 기본 ID로 취급됩니다. 이러한 모든 필드의 별칭 지정 결과가 병합되어 최종 보강 애셋 프로필이 생성됩니다.
- IP 주소: asset_id를 사용할 수 없는 경우에만 보강 쿼리에 포함됩니다.

각 애셋 이벤트에 대해 파이프라인은 principal, src, target 항목에서 다음 UDM 필드를 추출합니다.

UDM 필드	지표 유형	논리 / 우선순위
`hostname`	HOSTNAME	병합됨: 이러한 필드의 별칭 지정 결과가 결합되어 최종적으로 풍부해진 애셋 레코드가 생성됩니다.
`asset_id`	PRODUCT_SPECIFIC_ID	병합됨: 애셋 컨텍스트를 통합하는 데 사용되는 기본 식별자입니다.
`mac`	MAC	병합됨: 다른 식별자와 함께 사용하여 애셋을 확인합니다.
`ip`	IP	대체: `asset_id`를 사용할 수 없는 경우에만 보강 쿼리에 포함됩니다.

사용자 보강

사용자 보강은 특정 식별자를 찾아 ID 데이터를 확인합니다. 아티팩트 보강과 마찬가지로 이 파이프라인은 순서 환경설정을 사용하여 조회에 기본 키로 사용할 식별자를 결정합니다.

각 사용자 이벤트에 대해 파이프라인은 principal, src, target에서 다음 UDM 필드를 추출합니다.

UDM 필드	지표 유형	논리 또는 우선순위
`user.email_addresses`	이메일	최고 우선순위: 파이프라인은 먼저 사용자의 기본 또는 보조 이메일 주소를 기반으로 정보를 보강하려고 시도합니다.
`user.windows_sid`	WINDOWS_SID	두 번째 우선순위: 이메일을 사용할 수 없는 경우 파이프라인은 Windows 보안 식별자 (SID)를 사용합니다.
`user.userid`	USER_ID	세 번째 우선순위: 이메일과 SID가 누락된 경우에만 사용되며 일반적으로 로컬 또는 애플리케이션별 ID에 매핑됩니다.
`user.employee_id`	EMPLOYEE_ID	최저 우선순위: 사용자 ID를 확인하기 위한 최종 대체 수단입니다.

파이프라인은 각 지표에 대해 다음 작업을 실행합니다.

사용자 항목 목록을 가져옵니다. 예를 들어 principal.email_address 및 principal.userid의 항목은 동일할 수도 있고 다를 수도 있습니다.
WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID, PRODUCT_OBJECT_ID의 우선순위 순서에 따라 우선순위가 가장 높은 표시기 유형의 별칭을 선택합니다.
유효성 간격이 이벤트 시간과 교차하는 항목으로 noun.user를 채웁니다.

프로세스 보강

프로세스 보강은 실행 이벤트에 대한 가시성을 제공하는 데 중점을 둡니다. 파이프라인은 프로세스 세부정보를 추출하고 파일 평판과 상위-하위 관계를 상호 참조하여 세부정보를 보강합니다.

프로세스 보강을 사용하여 제품별 프로세스 ID(product_specific_process_id) 또는 PSPI를 실제 프로세스에 매핑하고 상위 프로세스에 관한 세부정보를 가져옵니다. 이 프로세스는 EDR 이벤트 일괄 처리 유형을 사용합니다.

UDM 항목	필드 소스	논리 또는 우선순위
기본 항목	`principal`, `src`, `target`	추출: 파이프라인은 이러한 최상위 항목에서 PSPI를 추출하여 조회를 시작합니다.
상위 프로세스	`principal.process.parent_process`, `src.process.parent_process`, `target.process.parent_process`	매핑: PSPI는 프로세스 별칭을 사용하여 상위 프로세스에 관한 세부정보를 가져옵니다.
데이터 병합	`noun.process`(예: `principal.process`)	덮어쓰기 규칙: 별칭이 지정된 필드가 절대 우선순위를 갖습니다. 동일한 필드에 파싱된 데이터와 별칭이 지정된 데이터가 모두 있는 경우 파이프라인은 파싱된 데이터를 별칭이 지정된 데이터로 대체합니다.

파이프라인은 프로세스 별칭을 사용하여 PSPI에서 실제 프로세스를 식별하고 상위 프로세스에 관한 정보를 가져옵니다. 그런 다음 이 데이터를 보강된 메시지 내의 해당 noun.process 필드로 병합합니다.

프로세스 별칭 지정의 EDR 색인 필드

프로세스가 시작되면 시스템은 메타데이터 (예: 명령줄, 파일 해시, 상위 프로세스 세부정보)를 수집합니다. 머신에서 실행되는 EDR 소프트웨어는 공급업체별 프로세스 UUID를 할당합니다.

다음 표에는 프로세스 실행 이벤트 중에 색인이 생성되는 필드가 나와 있습니다.

UDM 필드	지표 유형
target.product_specific_process_id	`PROCESS_ID`
target.process	전체 프로세스(표시기만 아님)

정규화된 이벤트의 target.process 필드 외에도 Google SecOps는 상위 프로세스 정보를 수집하고 색인을 생성합니다.

아티팩트 보강

아티팩트 보강은 VirusTotal의 파일 해시 메타데이터와 IP 주소의 위치정보 데이터를 추가합니다. 파일 해시의 경우 파이프라인은 우선순위가 지정된 목록에서 찾은 첫 번째 값에서 중지되지만 IP 주소의 경우 모든 항목을 병렬로 처리합니다. 각 UDM 이벤트에 대해 파이프라인은 principal, src, target 엔티티에서 다음 아티팩트 표시기의 컨텍스트 데이터를 추출하고 쿼리합니다. 여기서 보강 동작은 표시기 유형에 따라 다릅니다.

지표 유형	추출 로직	우선순위 / 연산 순서
파일 해시	첫 번째 경기	파이프라인은 다음 순서로 해시를 검색하고 VirusTotal에 쿼리할 수 있는 첫 번째 해시만 선택합니다. `file.sha256` `file.sha1` `file.md5` `process.file.sha256` `process.file.sha1` `process.file.md5`
IP 주소	병렬 (반복됨)	모든 공개 또는 라우팅 가능한 IP 주소는 독립적인 항목으로 처리됩니다. 선호도 순서는 없으며 각 IP는 자체 보강 결과를 수신합니다.

파이프라인은 UNIX 에포크 및 이벤트 시간을 사용하여 파일 아티팩트 쿼리의 기간을 정의합니다. 위치정보 데이터를 사용할 수 있는 경우 파이프라인은 위치정보 데이터의 출처에 따라 principal, src, target 엔티티의 다음 UDM 필드를 덮어씁니다.

artifact.ip
artifact.location
artifact.network (데이터에 IP 네트워크 컨텍스트가 포함된 경우에만)
location (원본 데이터에 이 필드가 포함되지 않은 경우에만)

파이프라인에서 파일 해시 메타데이터를 찾으면 표시기의 출처에 따라 해당 메타데이터를 파일 또는 process.file 필드에 추가합니다. 파이프라인은 새 데이터와 중복되지 않는 기존 값을 유지합니다.

IP 위치정보 보강

지리적 별칭은 외부 IP 주소에 대한 위치정보 데이터를 제공합니다. UDM 이벤트의 principal, target 또는 src 필드에 있는 별칭이 지정되지 않은 각 IP 주소에 대해 연결된 위치 및 ASN 정보가 포함된 ip_geo_artifact 하위 프로토콜 버퍼가 생성됩니다.

지리적 별칭은 되돌아보기 또는 캐싱을 사용하지 않습니다. 이벤트가 많기 때문에 Google SecOps는 메모리에 색인을 유지합니다.

VirusTotal 파일 메타데이터로 이벤트 보강

Google SecOps는 파일 해시를 UDM 이벤트로 보강하고 조사 중 추가 컨텍스트를 제공합니다. 해시 별칭은 모든 유형의 파일 해시를 결합하고 검색 중 파일 해시에 대한 정보를 제공하여 UDM 이벤트를 보강합니다.

Google SecOps는 VirusTotal 파일 메타데이터 및 관계 보강을 통합하여 악성 활동의 패턴을 식별하고 네트워크 전반에서 멀웨어 이동을 추적합니다.

원시 로그는 파일에 관한 정보를 제한적으로 제공합니다. VirusTotal은 악성 해시 및 파일에 관한 세부정보를 포함한 파일 메타데이터로 이벤트를 보강합니다. 메타데이터에는 파일 이름, 유형, 가져온 함수, 태그와 같은 정보가 포함됩니다. 이 정보를 YARA-L과 함께 UDM 검색 및 탐지 엔진에 사용하여 악성 파일 이벤트를 파악하고 위협 헌팅 중에 사용할 수 있습니다. 예를 들어 위협 감지를 위해 파일 메타데이터를 사용하는 원본 파일의 수정사항을 감지할 수 있습니다.

다음 정보가 레코드와 함께 저장됩니다. 모든 UDM 필드 목록은 통합 데이터 모델 필드 목록을 참조하세요.

데이터 유형	UDM 필드
sha-256	`( principal \| target \| src \| observer ).file.sha256`
md5	`( principal \| target \| src \| observer ).file.md5`
sha-1	`( principal \| target \| src \| observer ).file.sha1`
크기	`( principal \| target \| src \| observer ).file.size`
ssdeep	`( principal \| target \| src \| observer ).file.ssdeep`
vhash	`( principal \| target \| src \| observer ).file.vhash`
authentihash	`( principal \| target \| src \| observer ).file.authentihash`
PE 파일 메타데이터 Imphash	`( principal \| target \| src \| observer ).file.pe_file.imphash`
security_result.threat_verdict	`( principal \| target \| src \| observer ).(process \| file).security_result.threat_verdict`
security_result.severity	`( principal \| target \| src \| observer ).(process \| file).security_result.severity`
last_modification_time	`( principal \| target \| src \| observer ).file.last_modification_time`
first_seen_time	`( principal \| target \| src \| observer ).file.first_seen_time`
last_seen_time	`( principal \| target \| src \| observer ).file.last_seen_time`
last_analysis_time	`( principal \| target \| src \| observer ).file.last_analysis_time`
exif_info.original_file	`( principal \| target \| src \| observer ).file.exif_info.original_file`
exif_info.product	`( principal \| target \| src \| observer ).file.exif_info.product`
exif_info.company	`( principal \| target \| src \| observer ).file.exif_info.company`
exif_info.file_description	`( principal \| target \| src \| observer ).file.exif_info.file_description`
signature_info.codesign.id	`( principal \| target \| src \| observer ).file.signature_info.codesign.id`
signature_info.sigcheck.verfied	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.verified`
signature_info.sigcheck.verification_message	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.verification_message`
signature_info.sigcheck.signers.name	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.signers.name`
signature_info.sigcheck.status	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.signers.status`
signature_info.sigcheck.valid_usage	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.signers.valid_usage`
signature_info.sigcheck.cert_issuer	`( principal \| target \| src \| observer ).file.signature_info.sigcheck.signers.cert_issuer`
file_type	`( principal \| target \| src \| observer ).file.file_type`

강화 문제 해결

UDM 이벤트에 예상되는 보강 데이터가 누락된 경우 다음 제안을 사용하여 문제를 해결하세요.

일반 보강

일부 이벤트가 전혀 보강되지 않는 경우 Google SecOps에서 전송 속도를 우선시하기 때문일 수 있습니다. 첫 번째 패스 중에 이벤트의 일부 (<1%)가 보강을 건너뛸 수 있습니다. 이 문제를 해결하려면 몇 분 후에 다시 확인하세요. 시스템에서 이러한 이벤트를 자동으로 다시 처리합니다. 한 시간 후에도 보강이 누락된 경우 로그 소스가 UDM으로 올바르게 파싱되었는지 확인합니다.

아티팩트 보강 (첫 번째 일치 로직)

이벤트에 MD5 및 SHA256 해시가 있지만 SHA256의 VirusTotal 메타데이터만 표시되는 경우 이는 첫 번째 일치 논리입니다. 파이프라인은 우선순위가 가장 높은 해시 (sha256)를 찾는 즉시 중지됩니다. SHA256이 있는 경우 VirusTotal에서 MD5를 쿼리하지 않습니다.

principal.ip의 위치정보는 표시되지만 target.ip의 위치정보는 표시되지 않는 경우 병렬 로직은 각 IP를 독립적으로 처리합니다. 한 IP가 내부 또는 비공개 (라우팅 불가능)이고 다른 IP가 공개인 경우 공개 IP만 지리정보 보강을 수신합니다.

애셋 보강 (병합 및 대체 로직)

IP 주소 필드에 애셋의 보강 데이터가 표시되지 않으면 조건부 대체 논리입니다. IP는 asset_id (PSID)가 누락된 경우에만 보강 쿼리에 사용됩니다. asset_id가 있으면 시스템은 이를 사용하고 중복되거나 충돌하는 데이터를 방지하기 위해 해당 특정 쿼리의 IP를 무시합니다.

사용자 보강 (순서 환경설정)

Department 필드에 "Security"이 아닌 "IT"이 표시되면 사용자 보강에서 별칭이 지정된 필드보다 파싱된 필드를 선호한다는 의미입니다. 원시 로그가 "IT"로 파싱된 경우 보강 파이프라인은 ID 소스 (예: Okta 또는 AD)의 "Security" 값으로 이를 덮어쓰지 않습니다.

프로세스 보강 (매핑 및 덮어쓰기)

원시 로그에 프로세스 이름이 표시되지만 UDM 검색에서는 다른 이름으로 대체되는 경우 덮어쓰기 로직이 적용된 것입니다. 프로세스 보강은 별칭이 지정된 필드에 우선순위를 부여합니다. PSPI 조회에서 EDR 컨텍스트의 더 정확한 프로세스 이름을 반환하면 원래 파싱된 값이 완전히 대체됩니다.

다음 단계

다른 Google SecOps 기능과 함께 보강된 데이터를 사용하는 방법은 다음을 참고하세요.

도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.