파서 확장 프로그램 사용

Google Security Operations에서는 원본 원시 로그의 데이터가 통합 데이터 모델(UDM) 레코드로 파싱 및 정규화되는 방식을 정의할 수 있는 여러 가지 방법을 제공합니다.

기본 파서: 원본 원시 로그 데이터를 UDM 필드에 매핑하는 Google Security Operations에서 관리하는 사전 빌드된 데이터 매핑 명령어입니다.
커스텀 파서: 고객의 특정 데이터 파싱 요구를 충족하도록 고객이 만들고 관리하는 커스텀 데이터 매핑 명령어입니다.
파서 확장 프로그램: 원래 원시 로그의 추가 필드를 매핑하기 위해 기본 또는 커스텀 파서를 확장하는 추가 데이터 매핑 명령어입니다. 기본 또는 커스텀 파서를 완전히 대체하지는 않지만 기본 또는 커스텀 파서의 기존 매핑 안내를 확장합니다.

이 문서에서는 파서 확장 프로그램을 사용하는 방법을 설명합니다.

시작하기 전에

다음 문서에서는 파서 확장 프로그램을 사용하려면 알아야 할 기본 요건 개념을 설명합니다.

파서 확장 프로그램 정보

파서 확장 프로그램을 사용하면 고유한 사용 사례를 충족하도록 기본 또는 커스텀 파서에 정의된 명령어 이외의 추가 매핑 명령어를 만들 수 있습니다. 기존 기본 또는 커스텀 파서를 확장하기 위한 기능입니다. 파서 확장 프로그램은 기본 또는 커스텀 파서를 대체하지 않습니다. 파서 확장 프로그램을 사용하여 새 파서를 만들 수 없습니다.

파서 확장 프로그램은 원본 원시 로그를 읽고 추출된 값을 UDM 레코드의 특정 필드에 삽입합니다. UDM 레코드에는 기본 또는 커스텀 파서 및 파서 확장 프로그램에서 설정한 데이터가 포함됩니다.

파서 확장 프로그램의 데이터 매핑 명령어가 기본 또는 커스텀 파서의 명령어보다 우선 적용됩니다. 매핑 지침이 충돌하면 파서 확장 프로그램이 기본 또는 커스텀 파서에서 설정한 값을 덮어씁니다. 예를 들어 기본 파서가 원시 로그 필드를 event.metadata.description UDM 필드에 매핑하고 파서 확장 프로그램이 다른 원시 로그 필드를 동일한 UDM 필드에 매핑하면 파서 확장 프로그램이 기본 파서에서 설정한 값을 덮어씁니다. 반복 필드는 예외입니다. 반복 필드에 데이터를 기록할 때 값을 추가하도록 파서 확장 프로그램을 구성할 수 있습니다.

로그 유형별로 하나의 파서 확장 프로그램을 만듭니다. 각 로그 유형은 고유한 수집 라벨로 식별됩니다. 로그 유형 목록은 지원되는 기본 파서를 참조하세요.

파서 확장 프로그램을 만들려면 Google Security Operations가 기본 또는 커스텀 파서를 사용하여 원본 원시 로그를 수집하고 정규화할 수 있어야 합니다. 파서 확장 프로그램은 원래의 원시 로그에서 추가 데이터를 추출한 다음 UDM 레코드에 병합합니다.

파서 확장 프로그램은 다음 유형의 매핑 명령어를 지원합니다.

코드 스니펫 유형: 기본 및 커스텀 파서와 비슷한 파서 코드를 작성합니다. 원본 원시 로그는 로그 유형에 지원되는 데이터 형식 중 하나일 수 있습니다.
데이터 필드 유형: 애플리케이션 인터페이스에서 원본 및 대상 필드를 지정합니다. 원본 원시 로그의 형식은 다음 중 하나여야 합니다.
- 네이티브 JSON, 네이티브 XML 또는 CSV
- Syslog 헤더와 네이티브 JSON, 네이티브 XML 또는 CSV 지원되는 기본 파서에서 로그 유형의 하위 집합에 대한 데이터 필드 유형 매핑 명령어를 만들 수 있습니다. JSON, XML, CSV, SYSLOG + JSON, SYSLOG + XML, SYSLOG + CSV 형식의 유형에 대해 찾아보세요.

파서 확장 프로그램을 만들 때 다음 사항에 유의하세요.

데이터는 표준 데이터 유형과 반복 값을 지원하는 모든 UDM 필드에 매핑될 수 있습니다.
다음 UDM 필드에는 데이터를 매핑할 수 없습니다.
- event.idm.read_only_udm.additional
- event.idm.graph.entity.additional
데이터 매핑 명령어를 만들기 전에 Google Security Operations 인스턴스가 지난 30일 동안 로그 유형에 대한 원본 원시 로그를 수집했는지 그리고 이러한 원시 로그에 전제조건 기준에 정의하려는 필드가 포함되어 있는지 확인합니다. 이러한 원본 원시 로그는 데이터 매핑 명령어를 검증하는 데 사용됩니다.
파서 확장 프로그램이 실행되면 수신 데이터의 파싱이 시작됩니다. 원시 로그 데이터를 소급해서 파싱할 수 없습니다.

파서 확장 프로그램의 수명 주기

파서 확장 프로그램의 수명 주기 상태는 다음과 같습니다.

DRAFT: 아직 제출되지 않은 새로 만든 파서 확장 프로그램입니다.
VALIDATING: Google Security Operations에서 필드가 오류 없이 파싱되도록 기존 원시 로그를 기준으로 매핑 명령어를 검증합니다.
LIVE: 파서 확장 프로그램이 검증을 통과했으며 현재 프로덕션 단계입니다. 수신되는 원시 로그에서 UDM 레코드로 데이터를 추출하고 변환합니다.
FAILED: 파서 확장 프로그램이 검증에 실패했습니다.

파서 확장 프로그램 페이지 열기

다음 섹션 중 하나의 단계를 수행하여 파서 확장 프로그램 페이지에 액세스합니다.

탐색 메뉴에서 시작

탐색 메뉴에서 설정, SIEM 설정, 파서를 차례로 선택합니다.
파서 테이블에서 확장하려는 로그 유형을 확인합니다.
해당 행으로 이동한 다음 메뉴를 클릭합니다.
확장 프로그램 만들기를 클릭합니다.

원시 로그 검색에서 시작

원시 로그 검색을 사용하여 파싱될 레코드와 유사한 레코드를 검색합니다.
이벤트 > 타임라인 패널에서 이벤트를 선택합니다.
이벤트 데이터 패널을 펼칩니다.
파서 관리 버튼을 클릭합니다.
파서 관리 대화상자에서 확장 프로그램 만들기를 선택하고 다음을 클릭합니다. 파서 확장 프로그램 페이지가 수정 모드로 열립니다. 파서 확장 프로그램 정의를 시작할 수 있습니다.

새 파서 확장 프로그램 만들기

이 섹션에서는 파서 확장 프로그램 페이지를 연 다음 파서 확장 프로그램을 만드는 방법을 설명합니다. 파서 확장 프로그램 페이지에서 사용 가능한 필드는 원시 로그 구조에 따라 다릅니다.

원시 로그 패널의 예시 원시 로그를 검토하여 파서 확장 프로그램이 처리할 로그를 나타내는지 확인합니다. 파서 확장 프로그램을 만들 때 예시 원시 로그를 참조로 사용합니다.
- 원시 로그 검색에서 파서 확장 프로그램 페이지로 이동하면 검색 결과에서 선택한 원본 원시 로그가 패널에 표시됩니다.
- 탐색 메뉴의 파서 확장 프로그램 페이지로 이동하면 해당 로그 유형의 샘플 원시 로그가 표시됩니다.
참고: 원시 로그 패널에서는 데이터를 수정할 수 없습니다. 보기 옵션 메뉴와 텍스트 줄바꿈 체크박스를 사용하여 원시 로그 문자열의 형식을 지정할 수 있습니다.
확장 프로그램 메서드를 선택합니다. 다음 중 하나를 선택합니다.
- 데이터 필드 매핑: 데이터 필드 매핑을 만듭니다. 애플리케이션 필드를 사용하여 원본 원시 로그 필드와 대상 UDM 필드를 정의합니다.
- 코드 스니펫 작성: 지원되는 모든 로그 형식의 코드 스니펫을 만듭니다. 코드 스니펫은 기본 및 커스텀 파서와 동일한 파서 문법을 사용합니다. 파서 문법에 대한 자세한 내용은 파서 문법을 참조하세요.
참고: 코드 스니펫 매핑 명령어와 데이터 필드 매핑 명령어를 혼합할 수 없습니다.

선택한 확장 프로그램 메서드와 관련된 다음 하위 섹션 중 하나를 계속 진행합니다.

데이터 필드 매핑 명령어 만들기
코드 스니펫 매핑 명령어 만들기

데이터 필드 매핑 명령어 만들기

수신되는 원시 로그가 JSON, XML, CSV, Syslog 헤더 및 JSON, Syslog 헤더 및 XML 또는 Syslog 헤더 및 CSV 형식인 경우 데이터 필드 매핑 명령어를 만듭니다. 데이터 매핑 명령어에서 원본 필드 이름과 대상 UDM 필드의 경로를 정의합니다.

반복 필드 선택기에서 파서 확장 프로그램이 값 배열을 지원하는 필드에 값을 저장하는 방법을 지정합니다.
- 값 추가: 값이 필드에 저장된 기존 값 집합에 추가됩니다.
- 값 바꾸기: 이 값은 이전에 저장된 모든 값을 새 값으로 대체합니다.
principal.ip 및 entity.asset.hostname과 같은 일부 UDM 필드는 값의 배열을 저장합니다. 이러한 반복 필드는 통합 데이터 모델 필드 목록의 repeated 라벨로 식별됩니다. 자세한 내용은 반복 필드 선택기를 참조하세요.

중요: 데이터 필드 매핑 명령어는 반복 필드가 계층 구조의 최하위 수준에 있는 경우에만 반복되는 필드를 포함할 수 있습니다. 예를 들어 ip가 계층 구조의 최하위 수준에 있고 principal이 반복 필드가 아니므로 udm.principal.ip 반복 필드에 값을 매핑할 수 있습니다. intermediary는 반복 필드이고 계층 구조의 최하위 수준에 있지 않으므로 udm.intermediary.hostname에 값을 매핑할 수 없습니다.
Syslog 및 대상 필드가 표시되면 Google Security Operations에서 원시 로그에 Syslog 헤더가 포함된 것을 감지합니다.

Google Security Operations에서 예시 원시 로그가 네이티브 JSON, 네이티브 XML 또는 CSV가 아니며 Syslog 헤더가 있음을 확인하면 Syslog와 대상 필드가 표시됩니다. 다음 필드를 사용하여 Syslog 헤더를 사전 처리하고 로그의 구조화된 부분을 추출하는 Grok 및 정규 표현식 패턴을 정의합니다. 데이터 필드를 사용하여 로그의 구조화된 부분을 매핑할 수 있습니다.
- Syslog 필드: Syslog 헤더와 원시 로그 메시지를 식별하는 Grok 및 정규 표현식을 사용하여 추출 패턴을 지정합니다.
- 대상 필드: 로그의 구조화된 부분을 저장하는 추출 패턴에 변수 이름을 지정합니다.
Grok 및 정규 표현식을 사용하여 추출 패턴을 정의하는 방법에 대한 자세한 내용은 Syslog 추출기 필드 정의를 참조하세요.

다음 이미지는 추출 패턴 및 변수 이름을 각각 Syslog 및 대상 필드에 추가하는 방법의 예시를 보여줍니다.

Syslog 및 대상 필드는 필수이며 두 필드가 함께 작동하여 Syslog 헤더를 로그의 구조화된 부분에서 분리합니다.
Syslog 및 대상 필드에 값을 입력한 후 검증 버튼을 클릭합니다. 검증 프로세스는 문법 및 파싱 오류를 모두 확인한 후 다음 중 하나를 반환합니다.
- 성공: 데이터 매핑 필드가 표시됩니다. 파서 확장 프로그램의 나머지를 정의합니다.
- 실패: 오류 메시지가 표시됩니다. 계속하기 전에 오류 조건을 수정하세요.
원하는 경우 전제조건 명령어를 정의합니다.

전제조건 명령어는 정적 값을 원시 로그의 필드와 일치시켜 파서 확장 프로그램이 처리하는 원본 원시 로그의 하위 집합만 식별합니다. 수신 원시 로그가 전제조건 기준에 부합하는 경우, 즉 값이 일치하면 파서 확장 프로그램이 매핑 명령어를 적용합니다. 값이 일치하지 않으면 파서 확장 프로그램이 매핑 명령어를 적용하지 않습니다.

다음 입력란을 작성하세요.
- 전제조건 필드: 로그 데이터 형식이 JSON 또는 XML이면 필드의 전체 경로를 입력하고 데이터 형식이 CSV이면 열 위치를 입력합니다.
- 전제조건 연산자: EQUALS 또는 NOT EQUALS를 선택합니다.
- 전제조건 값: 전제조건 필드에 데이터와 일치해야 하는 값을 입력합니다.
데이터 매핑 안내를 정의합니다.
- 원시 데이터 필드: 로그 데이터 형식이 JSON 또는 XML인 경우 필드의 전체 경로를 입력하고 데이터 형식이 CSV인 경우 열 위치를 입력합니다.
- 대상 필드: 값이 저장될 정규화된 UDM 필드 이름을 입력합니다(예: udm.metadata.collected_timestamp.seconds).
중요: 원본 원시 로그가 JSON 형식인 경우 원본 로그 값의 데이터 유형이 대상 UDM 필드의 데이터 유형과 일치해야 합니다. 예를 들어 원본 로그가 문자열("packets_sent":"16")로 전송된 패킷을 기록하고 사용자가 uint64 데이터 유형이 있는 network.sent_bytes UDM 필드에 이를 매핑하려고 하면 명령어가 실패합니다. 이 요구사항은 CSV 및 XML 형식의 로그에 적용되지 않습니다.
제출을 클릭하여 매핑 명령어를 저장합니다.

Google Security Operations가 매핑 명령어를 검증합니다.

검증 프로세스가 성공하면 상태가 라이브로 변경되고 매핑 명령어가 수신되는 로그 데이터를 처리하기 시작합니다.
검증 프로세스가 실패하면 상태가 실패로 변경되고 원시 로그 필드에 오류가 표시됩니다.

다음은 검증 오류의 예시입니다.

ERROR: generic::unknown: pipeline.ParseLogEntry failed: LOG_PARSING_CBN_ERROR:
"generic::invalid_argument: pipeline failed: filter mutate (7) failed: copy failure:
copy source field \"jsonPayload.dest_instance.region\" must not be empty
(try using replace to provide the value before calling copy)

"LOG: {"insertId":"14suym9fw9f63r","jsonPayload":{"bytes_sent":"492",
"connection":{"dest_ip":"10.12.12.33","dest_port":32768,"protocol":6,
"src_ip":"10.142.0.238","src_port":22},"end_time":"2023-02-13T22:38:30.490546349Z",
"packets_sent":"15","reporter":"SRC","src_instance":{"project_id":"example-labs",
"region":"us-east1","vm_name":"example-us-east1","zone":"us-east1-b"},
"src_vpc":{"project_id":"example-labs","subnetwork_name":"default",
"vpc_name":"default"},"start_time":"2023-02-13T22:38:29.024032655Z"},
"logName":"projects/example-labs/logs/compute.googleapis.com%2Fvpc_flows",
"receiveTimestamp":"2023-02-13T22:38:37.443315735Z","resource":{"labels":
{"location":"us-east1-b","project_id":"example-labs",
  "subnetwork_id":"00000000000000000000","subnetwork_name":"default"},
  "type":"gce_subnetwork"},"timestamp":"2023-02-13T22:38:37.443315735Z"}

파서 확장 프로그램의 모든 사용 가능한 필드 목록은 데이터 매핑 명령어의 필드를 참조하세요.

데이터 매핑 명령어의 필드

이 섹션에서는 파서 확장 프로그램에 설정할 수 있는 모든 필드를 설명합니다.

필드 이름	설명
Syslog	Syslog 헤더를 사전 처리하고 원시 로그의 구조화된 위치로부터 분리하는 사용자 정의 패턴입니다.
대상	로그의 구조화된 부분을 저장하는 Syslog 필드의 변수 이름입니다.
전제조건 필드	비교할 값이 포함된 원시 로그의 필드 식별자입니다. 전제조건 명령어에 사용됩니다.
전제조건 연산자	`EQUALS` 또는 `NOT EQUALS`를 선택합니다. 전제조건 명령어에 사용됩니다.
전제조건 값	원시 로그의 전제조건 필드와 비교할 정적 값입니다. 전제조건 명령어에 사용됩니다.
원시 데이터 필드	매핑 명령어에 사용됩니다. 데이터 형식이 JSON이면 필드 경로를 정의합니다(예: `jsonPayload.connection.dest_ip`). 데이터 형식이 XML인 경우 필드의 전체 경로를 정의합니다(예: `/Event/Reason-Code`). 데이터 형식이 CSV인 경우 열의 색인 위치를 정의합니다. 색인 위치는 1부터 시작합니다.
대상 필드	매핑 명령어에 사용됩니다. 데이터가 저장될 UDM 필드의 전체 경로를 정의합니다. 예를 들면 다음과 같습니다. `udm.network.dhcp.opcode` 또는 `graph.entity.asset.hostname`

코드 스니펫 매핑 명령어 만들기

코드 스니펫은 Logstash와 비슷한 문법을 사용하여 원본 원시 로그에서 값을 추출 및 변환하고 UDM 레코드에 할당하는 방법을 정의합니다. 코드 스니펫은 기본 또는 커스텀 파서와 동일한 명령어 문법 및 섹션을 사용합니다. 코드 스니펫의 섹션은 다음과 같습니다.

섹션 1. 원본 로그에서 데이터를 추출합니다.
섹션 2. 추출된 데이터를 변환합니다.
섹션 3. UDM 필드에 하나 이상의 값을 할당합니다.
섹션 4. UDM 이벤트 필드를 @output 키에 결합합니다.

다음 예시는 코드 스니펫을 보여줍니다.

다음은 예시 원시 로그입니다.

{
    "insertId": "00000000",
    "jsonPayload": {
        ...section omitted for brevity...
        "packets_sent": "4",
        ...section omitted for brevity...
    },
    "timestamp": "2022-05-03T01:45:00.150614953Z"
}

다음은 jsonPayload.packets_sent의 값을 network.sent_bytes UDM 필드에 매핑하는 샘플 코드 스니펫입니다.

mutate {
 replace => {
    "jsonPayload.packets_sent" => ""
 }
}

filter {
    # Section 1. extract the data from the original JSON log
    json {
        source => "message"
        array_function => "split_columns"
        on_error => "_not_json"
    }

    if [_not_json] {
        drop {
            tag => "TAG_UNSUPPORTED"
        }

    } else {
        # Section 2. transform the extracted data
        if [jsonPayload][packets_sent] not in ["",0] {
            mutate {
                convert => {
                    "jsonPayload.packets_sent" => "uinteger"
                }
            }

            # Section 3. assign the value to a UDM field
            mutate {
                copy => {
                    "udm.network.sent_bytes" => "jsonPayload.packets_sent"
                }
                on_error => "_exception"
            }

            if ![_exception] {
                # Section 4. Bind the UDM fields to the @output key
                mutate {
                    merge => {
                        "@output" => "event"
                    }
                }
            }
        }
    }
}

제출을 클릭하여 매핑 명령어를 저장합니다.
Google Security Operations가 매핑 명령어를 검증합니다.
- 검증 프로세스가 성공하면 상태가 라이브로 변경되고 매핑 명령어가 수신되는 로그 데이터를 처리하기 시작합니다.
- 검증 프로세스가 실패하면 상태가 실패로 변경되고 원시 로그 필드에 오류가 표시됩니다.
참고: 파서 확장 프로그램이 검증되는 동안에는 데이터 매핑 명령어를 수정할 수 없습니다.

기존 파서 확장 프로그램 보기

탐색 메뉴에서 설정, SIEM 설정, 파서를 차례로 선택합니다.
파서 목록에서 파서 확장 프로그램이 포함된 로그 유형을 식별합니다. 이름 옆에 EXTENSION 텍스트로 식별됩니다.
해당 행으로 이동한 다음 메뉴를 클릭합니다.
확장 프로그램 보기를 클릭합니다.
커스텀/사전 빌드된 파서 보기 > 확장 프로그램 탭이 파서 확장 프로그램 관련 세부정보와 함께 표시됩니다. 요약 패널에는 기본적으로 LIVE 파서 확장 프로그램이 표시됩니다.

파서 확장 프로그램 수정

커스텀/사전 빌드된 파서 보기 > 확장 프로그램 탭을 엽니다. 페이지를 여는 방법은 기존 파서 확장 프로그램 보기를 참조하세요.
확장 프로그램 수정 버튼을 클릭합니다. 파서 확장 프로그램 페이지가 표시됩니다.
파서 확장 프로그램을 수정합니다.
- 수정을 취소하고 변경사항을 삭제하려면 초안 삭제를 클릭합니다.
파서 확장 프로그램 수정을 마치면 제출을 클릭합니다.
변경사항을 제출하면 검증 프로세스가 실행되어 새 구성을 검증합니다.

참고: 파서 확장 프로그램이 검증되는 동안에는 데이터 매핑 명령어를 수정할 수 없습니다.

파서 확장 프로그램 삭제

커스텀/사전 빌드된 파서 보기 > 확장 프로그램 탭을 엽니다. 페이지를 여는 방법은 기존 파서 확장 프로그램 보기를 참조하세요.
확장 프로그램 수정 버튼을 클릭합니다. 파서 확장 프로그램 페이지가 표시됩니다.
확장 프로그램 삭제 버튼을 클릭합니다.

파서 확장 프로그램을 수정하는 동안 언제든지 삭제할 수 있습니다. 다음 중 하나를 클릭합니다.

초안 삭제
실패한 확장 프로그램 삭제

반복 필드 선택기 자세히 알아보기

일부 UDM 필드에는 principal.ip 및 Entity.asset.hostname과 같은 값 배열이 저장됩니다. 반복 필드에 데이터를 저장하기 위해 파서 확장 프로그램을 만드는 경우, 이 옵션으로 값이 배열에 추가되는지 또는 기본 파서가 설정한 모든 기존 값을 대체하는지 여부를 제어할 수 있습니다. 반복 필드는 통합 데이터 모델 필드 목록에 반복되는 라벨로 식별됩니다.

값 추가가 선택되면 파서 확장 프로그램이 추출된 값을 UDM 필드의 기존 값 배열에 추가합니다. 값 바꾸기가 선택되면 파서 확장 프로그램이 UDM 필드의 기존 값 배열을 추출된 값으로 바꿉니다. 반복 필드 선택기는 반복되지 않는 필드에 데이터가 저장되는 방식에 영향을 주지 않습니다.

파서 확장 프로그램은 반복 필드가 계층 구조의 최하위 수준에 있는 경우에만 반복 필드에 데이터를 매핑할 수 있습니다. 예를 들어 반복된 ip 필드는 계층 구조의 최하위 수준에 있고 principal은 반복 필드가 아니므로 udm.principal.ip에 값을 매핑하는 것이 지원됩니다. intermediary가 반복 필드이고 계층 구조의 최하위 수준에 있지 않으므로 udm.intermediary.hostname에 값을 매핑하는 것은 지원되지 않습니다.

다음 표에서는 반복 필드 구성이 생성된 UDM 레코드에 미치는 영향을 보여주는 예시를 제공합니다.

반복 필드 선택	예시 로그	파서 확장 프로그램 구성	생성된 결과
값 추가	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}}`	전제조건 필드: `protoPayload.requestMetadata.callerIp` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.requestMetadata.callerIp` 대상 필드: `event.idm.read_only_udm.principal.ip`	`metadata:{event_timestamp:{}.....}principal:{Ip:"1.1.1.1, 2.2.2.2"} } }`
값 추가	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}}`	전제조건 1: 전제조건 필드:`protoPayload.requestMetadata.callerIp` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.requestMetadata.callerIp` 대상 필드: `event.idm.read_only_udm.principal.ip` 전제조건 2: 원시 데이터 필드: `protoPayload.requestMetadata.name` 대상 필드: `event.idm.read_only_udm.metadata.product_name`	확장 프로그램을 적용하기 전에 사전 빌드된 파서에서 생성된 이벤트 `metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 확장 프로그램을 적용한 후 출력 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} .... product_name: "Akamai Ltd"}principal:{ip:"1.1.1.1, 2.2.2.2, 3.3.3.3"}}}`
값 바꾸기	`{"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2"}}}`	전제조건 필드: `protoPayload.authenticationInfo.principalEmail` 전제조건 값: `" "` 전제조건 연산자: `NOT_EQUALS` 원시 데이터 필드: `protoPayload.authenticationInfo.principalEmail` 대상 필드: `event.idm.read_only_udm.principal.ip`	확장 프로그램을 적용하기 전에 사전 빌드된 파서에서 생성된 UDM 이벤트 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 확장 프로그램 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ....} principal:{ip:"2.2.2.2"}}}`를 적용한 후 UDM 출력

Syslog 추출기 필드 자세히 알아보기

Syslog 추출기 필드를 사용하면 출력을 저장할 정규 표현식 패턴에 Grok, 정규 표현식, 이름이 지정된 토큰을 정의하여 Syslog 헤더를 구조화된 로그와 분리할 수 있습니다.

Syslog 추출기 필드 정의

Syslog 및 대상 필드의 값이 함께 작동하여 파서 확장 프로그램이 Syslog 헤더를 원시 로그의 구조화된 부분에서 분리하는 방법을 정의합니다. Syslog 필드에서 Grok 및 정규 표현식 문법의 조합을 사용하여 표현식을 정의합니다. 표현식에는 원시 로그의 구조화된 부분을 식별하는 변수 이름이 포함됩니다. 대상 필드에 해당 변수 이름을 지정합니다.

다음 예시는 이러한 필드가 함께 작동하는 방식을 보여줍니다.

다음은 원시 로그의 예시입니다.

<13>1 2022-09-14T15:03:04+00:00 fieldname fieldname - - - {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

원시 로그에는 다음 섹션이 포함됩니다.

Syslog 헤더: <13> 2022-09-14T15:03:04+00:00 fieldname fieldname - - -
JSON 형식 이벤트: {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

원시 로그의 JSON 부분에서 Syslog 헤더를 분리하려면 Syslog 필드에 다음 예시 표현식을 사용합니다. %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

표현식의 이 부분에서 Syslog 헤더를 식별합니다. %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
표현식의 이 부분에서 원시 로그의 JSON 세그먼트를 캡처합니다. %{GREEDYDATA:msg}

이 예시에는 변수 이름 msg가 포함됩니다. 변수 이름을 선택합니다. 파서 확장 프로그램은 원시 로그의 JSON 세그먼트를 추출하여 msg 변수에 할당합니다.

대상 필드에 변수 이름 msg를 입력합니다. msg 변수에 저장된 값이 파서 확장 프로그램에서 만드는 데이터 필드 매핑 명령어에 입력됩니다.

예시 원시 로그를 사용하여 다음 세그먼트를 데이터 매핑 명령어에 입력합니다.

{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

다음 이미지는 완료된 Syslog 및 대상 필드를 보여줍니다.

Syslog 추출기 필드

다음 표에서는 샘플 로그, Syslog 추출 패턴, 대상 변수 이름, 결과가 포함된 추가 예시를 제공합니다.

샘플 원시 로그	Syslog 필드	대상 필드	Result
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}`	msg	`field_mappings { field: "msg" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg1} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`field_mappings { field: "msg2" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`"<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:message} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`Error - message already exists in state and not overwritable.`

파서 확장 프로그램에 대한 액세스 제어

파서 확장 프로그램을 보고 관리할 수 있는 사용자를 제어하는 새 권한을 사용할 수 있습니다. 기본적으로 파서 확장 프로그램은 관리자 역할이 있는 사용자가 액세스할 수 있습니다. 사용자 및 그룹 관리 또는 역할 할당에 대한 자세한 내용은 역할 기반 액세스 제어를 참조하세요.

다음 표에서는 Google Security Operations의 새 역할을 요약해서 보여줍니다.

기능	작업	설명
Parser	삭제	파서 확장 프로그램을 삭제합니다.
Parser	수정	파서 확장 프로그램을 만들고 수정합니다.
Parser	뷰	파서 확장 프로그램을 봅니다.