통합 데이터 모델 개요

이 문서에서는 통합 데이터 모델(UDM)에 대해 간략하게 설명합니다. 각 필드에 대한 설명과 함께 UDM 필드에 대한 자세한 내용은 UDM 필드 목록을 참조하세요. 파서 매핑에 대한 자세한 내용은 파서 매핑의 중요한 UDM 필드를 참조하세요.

UDM은 소스에서 수신한 데이터에 대한 정보를 저장하는 Google Security Operations 표준 데이터 구조입니다. 이를 스키마라고도 합니다. Google Security Operations는 수신하는 원본 데이터를 원본 원시 로그 및 구조화된 UDM 레코드와 같은 두 가지 형식으로 저장합니다. UDM 레코드는 원본 로그의 구조화된 표현입니다.

파서가 지정된 로그 유형으로 존재할 경우에는 원시 로그를 사용하여 UDM 레코드를 만듭니다. 또한 고객은 수집 API를 사용하여 데이터를 Google Security Operations에 전송하기 전에 원시 로그를 구조화된 UDM 형식으로 변환할 수 있습니다.

UDM의 이점은 다음과 같습니다.

• 동일한 시맨틱스를 사용하여 여러 다른 공급업체로부터 동일한 유형의 레코드를 저장합니다.
• 데이터가 표준 UDM 스키마로 정규화되기 때문에 사용자, 호스트, IP 주소 사이의 관계를 쉽게 파악할 수 있습니다.
• 규칙이 플랫폼과 독립적이기 때문에 규칙을 쉽게 작성할 수 있습니다.
• 새로운 기기의 로그 유형을 쉽게 지원할 수 있습니다.

참고: Google Security Operations 규칙 엔진은 같은 UDM 필드 이름을 사용합니다. 규칙을 만들 때 동일한 필드 이름을 사용할 수 있습니다.

원시 로그 검색으로도 이벤트를 검색할 수 있지만 구조화된 방식 덕분에 UDM 검색이 더 빠르고 정확합니다.

Google Security Operations는 수집하는 모든 이벤트에 UDM 스키마를 사용합니다. UDM에는 이벤트 기술 및 분류에 사용되는 수천 개의 필드가 포함되어 있습니다. 예를 들어 UDM은 네트워크 커뮤니케이션 이벤트만큼 쉽게 엔드포인트 프로세스 이벤트를 처리할 수 있습니다.

UDM 구조

UDM 이벤트는 여러 섹션으로 구성됩니다. 모든 UDM 이벤트에서 찾을 수 있는 첫 번째 섹션은 메타데이터 섹션입니다. 이벤트가 발생한 타임스탬프와 Google Security Operations에 수집된 타임스탬프를 포함하여 이벤트에 대한 기본적인 설명을 제공합니다. 또한 제품 정보, 버전, 설명이 포함되어 있습니다. 수집 파서는 특정 제품 로그와 관계없이 사전 정의된 이벤트 유형에 따라 각 이벤트를 분류합니다. 메타데이터 필드만 있으면 데이터 검색을 빠르게 시작할 수 있습니다.

메타데이터 섹션 외에 다른 섹션에서도 이벤트의 추가 특성을 설명합니다. 섹션이 불필요하면 메모리 절약을 위해 포함되지 않습니다.

• principal: 이벤트에서 해당 활동을 시작하는 항목입니다. 소스(src) 및 대상 (target)을 참조하는 섹션도 포함됩니다.
• intermediary: 프록시 서버 또는 SMTP 릴레이와 같이 이벤트가 통과되는 시스템입니다.
• observer: 트래픽을 통해 수동으로 모니터링하는 패킷 스니퍼와 같은 시스템입니다.

UDM 검색 예시

이 섹션에서는 기본 구문, 기능, UDM 검색 기능을 보여주는 UDM 검색 예시를 제공합니다.

예시: 성공한 Microsoft Windows 4624 로그인 검색

다음 검색은 단 2개의 UDM 이벤트를 기반으로 이벤트가 생성된 시간과 함께 성공한 Microsoft Windows 4624 로그인 이벤트를 나열합니다.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

예시: 모든 성공한 로그인 검색

다음 검색은 공급업체 또는 애플리케이션에 관계없이 모든 성공한 로그인 이벤트를 나열합니다.

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

예시: 성공한 사용자 로그인 검색

다음 예시에서는 userid "fkolzig"를 검색하는 방법과 사용자가 이 사용자 ID로 성공적으로 로그인한 시간을 확인하는 방법을 보여줍니다. 대상 섹션을 사용하여 이 검색을 완료할 수 있습니다. 대상 섹션에는 대상을 설명하는 하위 섹션과 필드가 포함되어 있습니다. 예를 들어 여기에서 대상은 사용자이고 연관된 많은 속성을 포함하지만 파일, 레지스트리 설정, 애셋도 대상이 될 수 있습니다. 이 예시에서는 target.user.userid 필드를 사용하여 "fkolzig"를 검색합니다.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

예시: 네트워크 데이터 검색

다음 예시에서는 target.port

(3389) 및 principal.ip(35.235.240.5)를 사용하여 RDP 이벤트의 네트워크 데이터를 검색합니다. 또한 네트워크 섹션의 UDM 필드와 데이터 방향(network.direction)이 포함되어 있습니다.

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

예시: 특정 프로세스 검색

서버에 생성된 프로세스를 검사하려면 net.exe 명령어의 인스턴스를 검색하고 예상 경로에서 특정 파일을 검색합니다. 검색할 필드는 target.process.file.full_path입니다. 이 검색을 위해서는 target.process.command_line 필드에 해당 명령어를

포함합니다. 또한 정보 섹션에 Microsoft Sysmon 이벤트 코드 1(ProcessCreate)을 설명하는 필드를 추가할 수 있습니다.

UDM 검색은 다음과 같습니다.

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

선택적으로 다음 UDM 검색 필드를 추가할 수 있습니다.

• principal.user.userid: 명령어를 실행하는 사용자를 식별합니다.
• principal.process.file.md5: MD5 해시를 식별합니다.
• principal.process.command_line: 명령줄입니다.

예시: 특정 부서와 연관된 성공한 사용자 로그인 검색

다음 예시는 기업의 마케팅 부서(target.user.department가 marketing)와 연관된 사용자(metadata.event_type이 USER_LOGIN)의 로그인을 검색합니다. target.user.department가 사용자 로그인 이벤트에 직접 연결되지 않아도 사용자에 대해 수집된 LDAP 데이터에 포함됩니다.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

논리적 객체: 이벤트 및 항목

UDM 스키마는 데이터를 저장하는 사용 가능한 모든 속성을 설명합니다. 각 UDM 레코드는 해당 레코드가 이벤트 또는 항목을 기술하는지 식별합니다. 데이터는 레코드가 이벤트 또는 항목을 설명하는지 여부와 metadata.event_type 또는 metadata.entity_type 필드에 설정된 값에 따라 서로 다른 필드에 저장됩니다.

• UDM 이벤트: 환경에 발생한 작업의 데이터를 저장합니다. 원래 이벤트 로그는 방화벽 및 웹 프록시와 같이 기기에 기록된 대로 작업을 기술합니다. 이는 UDM 이벤트 데이터 모델입니다.
• UDM 항목: 환경에 있는 애셋, 사용자, 리소스와 같은 요소를 상황에 맞게 표시한 것입니다. 이 항목은 신뢰할 수 있는 데이터 소스에서 가져옵니다. 이는 UDM 항목 데이터 모델입니다.

다음은 이벤트 데이터 모델과 항목 데이터 모델의 두 가지 시각적 표현입니다.

그림: 이벤트 데이터 모델

참고: 명사(Noun)는 속성 유형을 기술합니다. 주 구성원, 대상, src, 중개자, 관찰자, 정보 등의 용어는 데이터가 저장되는 필드 이름입니다.

그림: 항목 데이터 모델

참고: 명사(Noun)는 속성 유형을 기술합니다. 애셋, 사용자, 리소스라는 용어는 데이터가 저장되는 필드 이름입니다.

UDM 이벤트 구조

UDM 이벤트에는 각각 단일 레코드에 대한 데이터 하위 집합을 저장하는 여러 섹션이 포함되어 있습니다. 섹션은 다음과 같습니다.

• metadata
• principal
• target
• src
• 관찰자
• 중개자
• 정보
• 네트워크
• security_result

• 확장 프로그램

  

  그림: 이벤트 데이터 모델

메타데이터 섹션은 타임스탬프를 저장하고 event_type을 정의하고 기기를 설명합니다.

principal, target, src, observer, intermediary 섹션은 이벤트에 포함된 객체에 대한 정보를 저장합니다. 객체는 기기, 사용자, 프로세스일 수 있습니다. 대부분의 경우 이러한 섹션 중 일부만 사용됩니다. 데이터를 저장하는 필드는 이벤트 유형과 각 객체가 이벤트에서 담당하는 역할에 따라 결정됩니다.

네트워크 섹션에는 이메일 및 네트워크 관련 통신 등 네트워크 활동과 관련된 정보가 저장됩니다.

• 이메일 데이터: to, from, cc, bcc, 및 기타 이메일 필드의 정보입니다.
• HTTP 데이터: method, referral_url, useragent와 같습니다.

security_result 섹션은 안티바이러스 제품과 같은 보안 제품으로 기록된 작업 또는 분류를 저장합니다.

정보 및 확장 프로그램 섹션은 다른 섹션에서 캡처하지 않는 추가 공급업체별 이벤트 정보를 저장합니다. 확장 프로그램 섹션은 자유 형식 키-값 쌍 집합입니다.

각 UDM 이벤트는 원래의 원시 로그 이벤트 값을 저장합니다. 이벤트 유형에 따라 어떤 속성은 필수이고, 어떤 속성은 선택적입니다. 필수 및 선택적 속성은 metadata.event_type 값에 따라 결정됩니다. Google Security Operations에서는 metadata.event_type을 읽고 로그가 수신된 후 해당 이벤트 유형과 관련된 필드 유효성 검사를 수행합니다.

확장 프로그램 섹션과 같이 UDM 레코드 섹션에 데이터가 저장되지 않았으면 해당 섹션이 UDM 레코드에 표시되지 않습니다.

메타데이터 필드

이 섹션에서는 UDM 이벤트에 필요한 필드를 설명합니다.

event_timestamp 필드

UDM 이벤트는 이벤트가 발생한 GMT 타임스탬프인 metadata.event_timestamp의 데이터를 포함해야 합니다. 값은 RFC 3339 또는 Proto3 타임스탬프 표준 중 하나를 사용하여 인코딩되어야 합니다.

다음 예시는 RFC 3339 형식 yyyy-mm-ddThh:mm:ss+hh:mm(년, 월, 일, 시, 분, 초, UTC 시간 오프셋)을 사용하여 타임스탬프를 지정하는 방법을 보여줍니다. UTC 오프셋은 마이너스 8시간, 즉 PST를 나타냅니다.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

또한 에포크 형식을 사용하여 값을 지정할 수 있습니다.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

event_type 필드

UDM 이벤트에서 가장 중요한 필드는 metadata.event_type입니다. 이 값은 수행된 작업 유형을 식별하며 공급업체, 제품, 플랫폼과 독립적입니다. 예시 값에는 PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS가 있습니다. 전체 목록은 UDM 필드 목록 문서를 참조하세요.

metadata.event_type 값은 UDM 레코드에 포함되어야 하는 추가적인 필수 및 선택적 필드를 결정합니다. 각 이벤트 유형에 포함할 필드에 대한 자세한 내용은 UDM 사용 가이드를 참조하세요.

주 구성원, 대상, src, 중개자, 관찰자, 정보 속성

principal, target, src, intermediary, observer 속성은 이벤트와 관련된 애셋을 설명합니다. 각 속성에는 원래의 원시 로그에 기록된 대로 활동에 관련된 객체에 대한 정보가 저장됩니다. 이는 해당 활동을 수행한 기기 또는 사용자이거나 해당 활동의 대상이 되는 기기 또는 사용자일 수 있습니다. 또한 이메일 프록시 또는 네트워크 라우터와 같이 해당 활동을 관측한 보안 기기를 설명할 수 있습니다.

가장 일반적으로 사용되는 속성은 다음과 같습니다.

• principal: 활동을 수행한 객체입니다.
• src: 주 구성원과 다른 경우, 활동을 시작하는 객체입니다.
• target: 활동의 대상이 되는 객체입니다.

모든 이벤트 유형에서 이러한 필드 중 하나 이상에 데이터가 포함되어야 합니다.

보조 필드는 다음과 같습니다.

• intermediary: 이벤트에서 중간자 역할을 수행한 객체입니다. 여기에는 프록시 서버 및 메일 서버와 같은 객체가 포함될 수 있습니다.
• observer: 문제의 트래픽과 직접 상호작용하지 않는 객체입니다. 이는 취약점 스캐너 또는 패킷 스니퍼 기기일 수 있습니다.
• about: 이벤트에서 특정 역할을 수행했고 선택적인 다른 객체입니다.

주 구성원 속성

활동을 시작한 행위 항목 또는 기기를 나타냅니다. 주 구성원은 하나 이상의 머신 세부정보(호스트 이름, MAC 주소, IP 주소, CrowdStrike 머신 GUID와 같은 제품별 식별자) 또는 사용자 세부정보(예: 사용자 이름)를 포함해야 하며, 선택적으로 프로세스세부정보를 포함할 수 있습니다. 이메일, 파일, 레지스트리 키 또는 값과 같은 필드는 포함하지 않아야 합니다.

이벤트가 단일 머신에서 발생하는 경우 해당 머신은 주 구성원 속성에만 기술됩니다. 대상 또는 src 속성에서 머신을 설명할 필요가 없습니다.

참고: 보안 기기가 이벤트를 기록할 수 있지만 주 구성원 속성에는 기술되지 않습니다. 관찰자 또는 중간자 속성에 설명되어 있습니다. 보안 소프트웨어(예: Carbon Black)가 활동을 시작한 동일한 기기(예: 멀웨어가 감지된 Windows 엔드포인트)에서 실행되는 경우 Windows 기기가 주 구성원입니다.

다음 JSON 스니펫은 principal 속성이 채워지는 방법을 보여줍니다.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

이 속성은 이벤트의 주 구성원 작업 수행자인 기기 및 사용자에 대해 알려진 모든 것을 설명합니다. 이 예시에는 기기 IP 주소, 포트 번호, 호스트 이름이 포함됩니다. 또한 타사 보안 제품에서 생성된 고유 식별자인 Sophos의 공급업체 특정 애셋 식별자를 포함합니다.

대상 속성

이벤트로 참조되는 대상 기기 또는 대상 기기에 대한 객체를 나타냅니다. 예를 들어 기기 A에서 기기 B로의 방화벽 연결에서 기기 A는 주 구성원으로 캡처되고 기기 B는 대상으로 캡처됩니다.

프로세스 C가 대상 프로세스 D로 삽입하는 프로세스의 경우에는 프로세스 C가 주 구성원이고 프로세스 D가 대상입니다.

그림: 주 구성원과 대상 비교

다음 예시는 대상 필드를 채우는 방법을 보여줍니다.

target {
   ip: "192.0.2.31"
   port: 80
}

호스트 이름, 추가 IP 주소, MAC 주소, 고유 애셋 식별자와 같이 원래의 원시 로그에 더 많은 정보가 있으면 이것도 대상 및 주 구성원 필드에 포함해야 합니다.

주 구성원과 대상 모두 동일한 머신의 행위자를 나타낼 수 있습니다. 예를 들어 머신 X에서 실행되는 프로세스 A(주 구성원)는 또한 머신 X의 프로세스 B(대상)에 대해 작동할 수 있습니다.

src 속성

소스 객체에 대한 기기 또는 프로세스 컨텍스트(소스 객체가 존재하는 머신)와 함께 참여자에 의해 작동하는 소스 객체를 나타냅니다. 예를 들어 사용자 U가 머신 X에서 파일 A를 머신 Y의 파일 B에 복사할 경우, 파일 A와 머신 X 모두 UDM 이벤트의 src 부분에 지정됩니다.

중개자 속성

이벤트에 기술된 활동을 처리하는 하나 이상의 중간 기기에 대한 세부정보를 나타냅니다. 여기에는 프록시 서버 및 SMTP 릴레이 서버와 같은 기기에 대한 기기 세부정보가 포함될 수 있습니다.

관찰자 속성

직접적인 중개자는 아니지만 문제의 이벤트를 관측하고 보고하는 관찰자 기기를 나타냅니다. 여기에는 패킷 스니퍼 또는 네트워크 기반 취약점 스캐너가 포함될 수 있습니다.

정보 속성

이는 주 구성원, src, 대상, 중개자, 관찰자 필드에 설명되지 않은 이벤트에서 참조하는 객체에 대한 세부정보를 저장합니다. 예를 들어 다음을 캡처할 수 있습니다.

• 이메일 첨부파일
• 이메일 본문에 포함된 도메인, URL 또는 IP 주소
• PROCESS_LAUNCH 이벤트 중 로드된 DLL

security_result 속성

이 섹션에는 보안 시스템에서 발견된 보안 위험 및 위협과 이러한 위험 및 위협을 완화하기 위해 수행된 조치에 대한 정보가 포함되어 있습니다.

다음은 security_result 속성에 저장할 수 있는 정보 유형입니다.

• 이메일 보안 프록시에서 피싱 시도(security_result.category = MAIL_PHISHING)가 감지되어 이메일이 차단되었습니다(security_result.action = BLOCK).
• 이메일 보안 프록시 방화벽에서 2개의 감염된 연결(security_result.category = SOFTWARE_MALICIOUS)이 감지되었으며 이러한 첨부파일을 격리 및 치료(security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION)한 후 치료된 이메일을 전달했습니다.
• SSO 시스템이 차단된 로그인(security_result.category = AUTH_VIOLATION)을 허용합니다(security_result.action = BLOCK).
• 멀웨어 샌드박스가 사용자의 수신함으로 파일이 전달된지(security_result.action = ALLOW) 5분 후에 첨부파일에서 스파이웨어(security_result.category = SOFTWARE_MALICIOUS)를 감지했습니다.

네트워크 속성

네트워크 속성은 네트워크 관련 이벤트에 대한 데이터 및 하위 메시지 내의 프로토콜 세부정보를 저장합니다. 여기에는 송수신된 이메일, HTTP 요청 등의 활동이 포함됩니다.

확장 프로그램 속성

이 속성 아래의 필드는 원본 원시 로그에서 캡처된 이벤트에 대한 추가 메타데이터를 저장합니다. 여기에는 취약점 또는 추가 인증 관련 정보가 포함될 수 있습니다.

UDM 항목의 구조

UDM 항목 레코드는 조직 내의 모든 항목에 대한 정보를 저장합니다. metadata.entity_type이 사용자인 경우 레코드는 entity.user 속성에 사용자 정보를 저장합니다. metadata.entity_type이 애셋인 경우 레코드는 워크스테이션, 노트북, 전화, 가상 머신과 같은 애셋에 대한 정보를 저장합니다.

그림: 이벤트 데이터 모델

메타데이터 필드

이 섹션에는 다음과 같이 UDM 항목에 필요한 필드가 포함되어 있습니다.

• collection_timestamp: 레코드가 수집된 날짜 및 시간입니다.
• entity_type: 애셋, 사용자, 리소스와 같은 항목 유형입니다.

항목 속성

항목 속성 아래의 필드에는 자산의 호스트 이름 및 IP 주소 또는 사용자의 windows_sid 및 이메일 주소와 같은 특정 항목에 대한 정보가 저장됩니다. 필드 이름은 '항목'이지만 필드 유형은 명사입니다. 명사는 항목 및 이벤트 모두의 정보를 저장하는 일반적으로 사용되는 데이터 구조입니다.

• metadata.entity_type이 사용자인 경우 데이터는 entity.user 속성에 저장됩니다.
• metadata.entity_type이 애셋이면 데이터가 entity.asset 속성에 저장됩니다.

관계 속성

관계 속성 아래의 필드에는 기본 항목이 연결된 다른 항목에 대한 정보가 포함됩니다. 예를 들어 기본 항목이 사용자이고 사용자에게 노트북이 발급되었다고 가정해보세요. 이 때는 노트북이 관련된 항목입니다. 노트북에 대한 정보는 metadata.entity_type = ASSET으로 구성된 '항목' 레코드로 저장됩니다. 사용자에 대한 정보는 metadata.entity_type = USER와 함께 '항목' 레코드로 저장됩니다.

또한 사용자 항목 레코드는 "관계" 속성 아래의 필드를 사용해서 사용자와 노트북 사이의 관계를 캡처합니다. 관계 필드는 사용자와 노트북의 관계, 특히 사용자가 노트북을 소유한 관계를 저장합니다. 노트북이 기기이므로 relation.entity_type 필드는 애셋 값을 저장합니다.

relations.entity 속성 아래의 필드에는 호스트 이름 및 MAC 주소와 같은 노트북 관련 정보가 저장됩니다. 여기서 필드 이름은 '항목'이고 필드 유형은 명사입니다. 명사는 일반적으로 사용되는 데이터 구조입니다. relation.entity 속성 아래의 필드는 노트북에 대한 정보를 저장합니다.

relation.direction 필드는 사용자와 노트북 간의 관계 방향을 저장합니다. 특히 관계가 양방향인지 단방향인지를 저장합니다.