ASIM(고급 보안 정보 모델) 파서 개발

ASIM(고급 보안 정보 모델) 사용자는 쿼리에서 테이블 이름 대신 통합 파서를 사용하여 정규화된 형식으로 데이터를 보고 쿼리에 스키마와 관련된 모든 데이터를 포함합니다. 차례로 파서를 통합하면 원본별 파서를 사용하여 각 소스의 특정 세부 정보를 처리합니다.

Microsoft Sentinel 많은 데이터 원본에 대한 원본별 기본 제공 파서를 제공합니다. 다음과 같은 상황에서 이러한 원본별 파서를 수정하거나 개발할 수 있습니다.

디바이스가 ASIM 스키마에 맞는 이벤트를 제공하지만, 디바이스 및 관련 스키마에 대한 원본별 파서가 Microsoft Sentinel에 없을 때.
디바이스에서 ASIM 원본별 파서를 사용할 수 있지만 디바이스가 ASIM 파서가 예상한 것과 다른 메서드 또는 형식으로 이벤트를 보내는 경우. 다음은 그 예입니다.
- 비표준 방식으로 이벤트를 보내도록 원본 디바이스를 구성할 수 있습니다.
- 디바이스의 버전이 ASIM 파서에서 지원하는 버전과 다를 수 있습니다.
- 이벤트는 중간 시스템에서 수집, 수정 및 전달될 수 있습니다.

파서가 ASIM 아키텍처에 어떻게 적합한지 이해하려면 ASIM 아키텍처 다이어그램을 참조하세요.

사용자 지정 ASIM 파서 개발 프로세스

다음 워크플로에서는 원본별 파서인 사용자 지정 ASIM을 개발하는 높은 수준의 단계를 설명합니다.

샘플 로그를 수집합니다.
원본에서 보낸 이벤트가 나타내는 스키마 또는 스키마를 식별합니다. 자세한 내용은 스키마 개요를 참조하세요.
원본 이벤트 필드를 식별된 스키마 또는 스키마에 매핑합니다.
원본에 대해 하나 이상의 ASIM 파서를 개발합니다. 원본과 관련된 각 스키마에 대해 필터링 파서 및 매개 변수가 없는 파서가 개발되어야 합니다.
파서를 테스트합니다.
파서를 Microsoft Sentinel 작업 영역에 배포합니다.
관련 ASIM 통합 파서가 새 사용자 지정 파서에 참조되도록 업데이트합니다. 자세한 내용은 ASIM 파서 관리를 참조하세요.
또한 파서를 제공하여 주 ASIM 배포판에 기여할 수도 있습니다. 기여된 파서는 모든 작업 영역에서 기본 제공 파서로 사용할 수도 있습니다.

이 문서에서는 프로세스의 개발, 테스트 및 배포 단계를 안내합니다.

샘플 로그 수집

효과적인 ASIM 파서를 빌드하려면 대표적인 로그 집합이 필요합니다. 대부분의 경우 원본 시스템을 설정하고 Microsoft Sentinel 연결해야 합니다. 사용 가능한 원본 디바이스가 없는 경우 클라우드 종량제 서비스를 사용하면 개발 및 테스트를 위해 많은 디바이스를 배포할 수 있습니다.

또한 로그에 대한 공급업체 설명서 및 샘플을 찾는 것은 광범위한 로그 형식 적용 범위를 보장하여 개발을 가속화하고 실수를 줄이는 데 도움이 될 수 있습니다.

대표적인 로그 집합에는 다음이 포함되어야 합니다.

이벤트 결과가 서로 다른 이벤트
다른 응답 동작이 있는 이벤트입니다.
사용자 이름, 호스트 이름 및 ID 및 값 정규화가 필요한 기타 필드에 대한 다양한 형식입니다.

팁 (조언)

동일한 스키마에 대해 기존 파서 를 사용하여 새 사용자 지정 파서 시작 기존 파서를 사용하는 것은 스키마에 필요한 모든 매개 변수를 허용하도록 파서를 필터링하는 데 특히 중요합니다.

계획 매핑

파서가 개발되기 전에 원본 이벤트 또는 이벤트에서 사용할 수 있는 정보를 식별한 스키마에 매핑합니다.

모든 필수 필드와 권장 필드를 매핑합니다.
원본에서 사용할 수 있는 모든 정보를 정규화된 필드로 매핑해 보세요. 선택한 스키마의 일부로 사용할 수 없는 경우 다른 스키마에서 사용할 수 있는 필드에 매핑하는 것이 좋습니다.
원본의 필드에 대한 값을 ASIM에서 허용하는 정규화된 값에 매핑합니다. 원래 값은 와 같은 EventOriginalResultDetails별도의 필드에 저장됩니다.

파서 개발

각 관련 스키마에 대한 필터링 및 매개 변수 없는 파서 모두를 개발합니다.

사용자 지정 파서는 Microsoft Sentinel Logs 페이지에서 개발된 KQL 쿼리입니다. 파서 쿼리에는 다음 세 부분으로 구성됩니다.

필터>구문 분석>필드 준비

파서 작업을 레코드 단위로 유지하세요

각 소스 레코드를 독립적으로 정규화하세요. 소스 레코드는 필터링 후 0개의 레코드를 생성할 수 있거나 하나의 정규화된 레코드를 생성할 수 있습니다.

선언된 소스 테이블에서만 이벤트 레코드를 읽으세요. 두 번째 테이블 리드, 이벤트 레코드 join, 작업 테이블 또는 워치리스트 참조, externaldata또는 다른 외부 표 소스 등으로 동일 테이블 또는 크로스 테이블 이벤트 풍부화를 수행하지 마세요.
기록 기수를 유지하세요. 한 소스 레코드를 여러 개의 정규화된 레코드로 바꾸지 마세요. 소스가 하나의 레코드에 여러 논리 이벤트를 결합한 경우, 커넥터나 소스 이벤트 형식을 수정하세요.
mv-apply 및 mv-*를 포함한 어떤 mv-expand 연산자도 사용하지 마세요.
distinct, arg_min, arg_max, summarize 또는 이와 동등한 작업을 사용하여 이벤트 레코드를 연관시키거나, 중복 제거, 집계 또는 재집계하지 마세요.

datatable로 생성되고 lookup로 적용되는 쿼리 로컬 정적 매핑은 각 조회 키가 고유한 경우 허용됩니다. 스칼라 식, 동적 값 및 현재 행에서 이용 가능한 값에 직접 접근하는 것을 활용하세요. 금지된 패턴 없이는 필드를 매핑할 수 없다면, 커넥터나 소스 이벤트 형태를 수정하거나 비필수 필드를 매핑하지 않은 상태로 두세요.

필터링

소스 필드별 필터

현재 이벤트에서 물리적 필드를 사용하여 소스 유형을 식별하세요. 관련 기록을 찾기 위해 감시 목록이나 다른 테이블을 쿼리하지 마세요.

이벤트가 소스나 이벤트 유형을 구분할 만큼 충분한 정보를 포함하지 못한다면, 커넥터에 소스 식별자를 포함하도록 업데이트하거나 이벤트를 소스별 테이블로 라우팅하세요. 테이블 보강으로 소스 정보의 누락을 만회하지 마세요.

파서 매개 변수를 기반으로 필터링

필터링 파서를 개발할 때 해당 스키마에 대한 참조 문서에 설명된 대로 파서가 관련 스키마에 대한 필터링 매개 변수를 허용하는지 확인합니다. 기존 파서 를 시작점으로 사용하면 파서에 올바른 함수 서명이 포함됩니다. 대부분의 경우 실제 필터링 코드는 동일한 스키마에 대한 파서를 필터링하는 경우에도 유사합니다.

필터링할 때 다음을 수행해야 합니다.

물리적 필드를 사용해 파싱하기 전에 필터링합니다. 필터링된 결과가 충분히 정확하지 않은 경우 구문 분석 후 테스트를 반복하여 결과를 미세 조정합니다. 자세한 내용은 필터링 최적화를 참조하세요.
매개 변수가 정의되지 않았고 여전히 기본값이 있는지 필터링하지 마세요.

조건부 술어를 사용하여 선택적 파서 매개변수 필터링을 구현하여, 파서는 호출자가 값을 제공할 때만 필터를 적용합니다. 다음 예제에서는 기본값이 일반적으로 '*'인 문자열 매개 변수 및 목록 매개 변수에 대해 필터링을 구현하는 방법을 보여 줍니다. 여기서 기본값은 일반적으로 빈 목록입니다.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

함수와 연산자 array_length 에 대한 has_any 자세한 내용은 Kusto 문서를 참조하세요:

필터링 최적화

파서의 성능을 확인하려면 다음 필터링 권장 사항을 확인합니다.

항상 구문 분석된 필드가 아닌 기본 제공 필드를 필터링 기준으로 사용하세요. 구문 분석된 필드를 사용하여 필터링하는 것이 더 쉬운 경우도 있지만 성능에 큰 영향을 줍니다.
최적화된 성능을 제공하는 연산자를 사용합니다. 특히 ==, has, 그리고 startswith입니다. 또는 contains 와 같은 matches regex 연산자를 사용하면 성능에 큰 영향을 줍니다.

성능에 대한 권장 사항을 필터링하는 것이 항상 쉽지 않을 수 있습니다. 예를 들어 를 사용하는 has 것이 보다 contains정확도가 낮습니다. 다른 경우에는 와 같은 SyslogMessage기본 제공 필드와 일치하는 것이 와 같이 DvcAction추출된 필드를 비교하는 것보다 정확도가 낮습니다. 이러한 경우 기본 제공 필드에 성능 최적화 연산자를 사용하여 계속 사전 필터링하고 구문 분석 후 보다 정확한 조건을 사용하여 필터를 반복하는 것이 좋습니다.

예제는 다음 Infoblox DNS 파서 코드 조각을 참조하세요. 파서는 먼저 SyslogMessage 필드 has 가 단어 client를 나타내는지 확인합니다. 그러나 이 용어는 메시지의 다른 위치에서 사용될 수 있으므로 필드를 구문 분석한 Log_Type 후 파서는 단어가 client 실제로 필드의 값이었는지 다시 확인합니다.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

비고

파서를 사용하는 쿼리가 이미 시간 동안 필터링하므로 파서는 시간별로 필터링해서는 안 됩니다.

구문 분석 중

쿼리가 관련 레코드를 선택한 후에는 해당 레코드를 구문 분석해야 할 수도 있습니다. 일반적으로 여러 이벤트 필드가 단일 텍스트 필드에 전달되는 경우 구문 분석이 필요합니다.

구문 분석을 수행하는 KQL 연산자는 성능 최적화에 따라 아래에 나열됩니다. 첫 번째는 가장 최적화된 성능을 제공하는 반면, 마지막은 최적화되지 않은 성능을 제공합니다.

연산자/함수()	Description
split() 함수	구분자로 구분된 값 문자열을 구문 분석합니다.
parse_csv() 함수	CSV(쉼표로 구분된 값) 형식의 한 줄 값 문자열을 구문 분석합니다.
parse-kv 연산자	문자열 식에서 구조화된 정보를 추출하고 키/값 형식으로 정보를 나타냅니다.
parse 연산자	패턴을 사용하여 임의 문자열에서 여러 값을 구문 분석합니다. 이 패턴은 더 나은 성능의 간소화된 패턴 또는 정규식일 수 있습니다.
extract_all() 함수	정규식을 사용하여 임의의 문자열에서 단일 값을 파싱합니다. `extract_all` 는 후자가 정규식을 사용하는 경우와 비슷한 성능을 `parse` 줍니다.
extract() 함수	정규식을 사용하여 임의의 문자열에서 단일 값을 추출합니다. 를 사용하면 `extract` 단일 값이 필요한 경우 또는 `parse` 보다 `extract_all` 더 나은 성능을 제공합니다. 그러나 동일한 원본 문자열을 통해 의 `extract` 여러 활성화를 사용하는 것은 단일 `parse` 또는 `extract_all` 보다 덜 효율적이며 피해야 합니다.
parse_json() 함수	JSON 형식의 문자열에서 값을 구문 분석합니다. JSON에서 몇 가지 값만 필요한 경우 , `parse`또는 `extract` 을 사용하여 `extract_all`더 나은 성능을 제공합니다.
parse_xml() 함수	XML 형식의 문자열에서 값을 구문 분석합니다. XML에서 몇 가지 값만 필요한 경우 , `parse`또는 `extract` 을 사용하여 `extract_all`더 나은 성능을 제공합니다.

정상화

필드 이름 매핑

가장 간단한 정규화 형식은 원래 필드의 이름을 정규화된 이름으로 바꾸는 것입니다. 그럴 때는 연산자 project-rename를 사용합니다. 프로젝트 이름 바꾸기를 사용하면 필드가 여전히 실제 필드로 관리되고 필드 처리가 더 성능이 높아집니다. 예를 들어, 다음 쿼리는 소스 계정 필드를 정규화된 ASIM 액터 필드 이름으로 매핑합니다:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

필드 형식 및 유형 정규화

대부분의 경우 추출된 원래 값을 정규화해야 합니다. 예를 들어 ASIM에서 MAC 주소는 콜론을 구분 기호로 사용하지만 원본은 하이픈으로 구분된 MAC 주소를 보낼 수 있습니다. 값을 변환하기 위한 기본 연산자는 extend광범위한 KQL 문자열, 숫자 및 날짜 함수 집합과 함께 입니다.

또한 파서 출력 필드가 스키마에 정의된 형식과 일치하는지 확인하는 것은 파서가 작동하는 데 중요합니다. 예를 들어 날짜 및 시간을 나타내는 문자열을 datetime 필드로 변환해야 할 수 있습니다. 및 todatetime 와 같은 tohex 함수는 이러한 경우에 유용합니다.

예를 들어 원래 고유 이벤트 ID는 정수로 보낼 수 있지만 ASIM은 데이터 원본 간의 광범위한 호환성을 보장하기 위해 값을 문자열로 지정해야 합니다. 따라서 소스 필드를 할당할 때는 와 를 사용하여 extendtostringproject-rename숫자 값을 문자열로 변환하여 정규화된 필드가 스키마의 문자열 유형 요구사항을 충족하도록 하십시오:

  | extend EventOriginalUid = tostring(ReportId),

파생 필드 및 값

소스 필드의 값이 추출된 후에는 대상 스키마 필드에 지정된 값 집합에 매핑해야 할 수도 있습니다. 와 같은 iffcase스칼라 표현식이나 , 를 포함한 lookup쿼리-로컬 정적 datatable 표현식을 사용하여 이용 가능한 데이터를 목표 값에 매핑합니다.

예를 들어, Microsoft DNS 파서는 소스별 이벤트 및 응답 코드로부터 정상화된 성공 또는 실패 결과를 도출합니다. 파서는 다음과 같이 iff 문을 사용하여 Event ID와 Response Code를 기준으로 EventResult 필드를 할당합니다:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

소스 값이 여러 정규화된 값으로 매핑될 수 있을 때 사용 case 하세요. 다음은 그 예입니다.

| extend NetworkProtocol = case(
    Proto == 6, "TCP",
    Proto == 17, "UDP",
    ""
)

규모가 더 큰 정적 매핑의 경우 쿼리 로컬 차원 테이블을 정의한 다음 lookup로 적용하세요. lookup의 오른쪽은 작업 영역 테이블, 워치리스트 또는 외부 데이터 원본이 아닌 로컬에서 정의된 정적 datatable이어야 합니다. 각 조회 키마다 한 행만 정의하여 한 소스 레코드가 여러 정규화된 레코드를 생성하지 못하게 하세요. 다음은 그 예입니다.

let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)
[
    6, "TCP",
    17, "UDP"
];
...
| lookup NetworkProtocolLookup on Proto

보강 필드

원본에서 사용할 수 있는 필드 외에도 결과 ASIM 이벤트에는 파서가 생성해야 하는 보강 필드가 포함됩니다. 이 스키마 필드들은 현재 행이나 상수에서 값을 사용하며 테이블 확장이 필요하지 않습니다. 많은 경우, 파서는 이 필드에 상수 값을 할당할 수 있습니다. 표준 풍부화 필드를 채워 각 파싱된 레코드가 일관된 제품, 공급업체, 스키마 메타데이터를 포함하도록 합니다. 예를 들어:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

파서가 설정해야 하는 다른 유형의 보강 필드는 관련 필드에 저장된 값의 형식을 지정하는 형식 필드입니다. 예를 들어 SrcUsernameType 필드는 필드에 저장된 값의 형식을 지정합니다 SrcUsername . 엔터티 설명에서 형식 필드에 대한 자세한 정보를 찾을 수 있습니다.

대부분의 경우 형식에도 상수 값이 할당됩니다. 하지만 경우에 따라 실제 가치를 기준으로 유형을 결정해야 하기도 합니다. 예를 들어, 파싱된 호스트명이 두 개 이상의 세그먼트를 포함하는지 확인하여 완전 적격 도메인 이름(FQDN)인지 확인합니다:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel는 강화 작업을 처리하는 데 유용한 함수를 제공합니다. 예를 들어, 헬퍼 기능을 사용하여 _ASIM_ResolveSrcFQDN 해당 열에서 Computer 정규화된 소스 호스트네임, 도메인, 도메인 유형, FQDN 필드를 도출할 수 있습니다. 다음 스니펫은 Computer 필드의 값을 기준으로 SrcHostname, SrcDomain, SrcDomainType, SrcFQDN 필드를 자동으로 채웁니다.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

이 함수는 다음과 같이 필드를 설정합니다.

컴퓨터 분야	출력 필드
server1	SrcHostname: server1 SrcDomain, SrcDomainType, SrcFQDN 모두 비어 있음
server1.microsoft.com	SrcHostname: server1 SrcDomain: microsoft.com SrcDomainType: FQDN SrcFQDN:server1.microsoft.com

함수 및 _ASIM_ResolveDstFQDN 는 관련 _ASIM_ResolveDvcFQDN 및 DstDvc 필드를 채우는 유사한 작업을 수행합니다. ASIM 도움말 함수의 전체 목록은 ASIM 함수를 참조하세요.

결과 집합에서 필드 선택

파서는 선택적으로 결과 집합에서 필드를 선택할 수 있습니다. 불필요한 필드를 제거하면 정규화된 필드와 나머지 원본 필드 간의 혼동을 방지하여 성능을 향상시키고 명확성을 높일 수 있습니다.

다음 KQL 연산자는 결과 집합에서 필드를 선택하는 데 사용됩니다.

Operator	Description	파서에서 사용해야 하는 경우
project-away	필드를 제거합니다.	결과 집합에서 제거하려는 특정 필드에 사용합니다 `project-away` . 혼동을 일으키거나 매우 크고 성능에 영향을 미칠 수 있는 경우가 아니면 결과 집합에서 정규화되지 않은 원래 필드를 제거하지 않는 것이 좋습니다.
프로젝트	이전에 존재했거나 문의 일부로 만들어진 필드를 선택하고 다른 모든 필드를 제거합니다.	파서가 정규화되지 않은 다른 필드를 제거해서는 안 하므로 파서에서 사용하지 않는 것이 좋습니다. 구문 분석 중에 사용되는 임시 값과 같은 특정 필드를 제거해야 하는 경우 를 사용하여 `project-away` 결과에서 제거합니다.

예를 들어, 커스텀 로그 테이블을 파싱할 때, 남은 소스별 타입 열(예: , _d, _s_b 접미사가 포함된 _g필드)을 제거하여 파서 출력에 유지하려는 정규화된 필드만 포함하도록 합니다:

    | project-away
        *_d, *_s, *_b, *_g

파싱 변형 처리

중요합니다

서로 다른 이벤트 유형을 나타내거나 서로 다른 스키마에 매핑하는 변형별로 별도의 파서를 개발하세요.

동일한 이벤트 유형의 변형이 다른 구문 분석 논리를 요구한다면, 각 소스 레코드에 대해 하나의 출력 레코드를 보존하면서 와 case 같은 iff 스칼라 조건 표현식을 사용하세요. 표 형식 분기를 만들고 union로 다시 결합하지 마세요. 분기가 동일한 소스 레코드를 두 번 이상 처리하거나 반환할 수 있기 때문입니다.

파서 배포

Azure Monitor 로그 페이지에 복사하고 쿼리를 함수로 저장하여 파서를 수동으로 배포합니다. 이 메서드는 테스트에 유용합니다. 자세한 내용은 함수 만들기를 참조하세요.

많은 수의 파서를 배포하려면 다음과 같이 파서 ARM 템플릿을 사용하는 것이 좋습니다.

각 스키마에 대한 관련 템플릿을 기반으로 YAML 파일을 만들고 쿼리를 포함합니다. 스키마 및 파서 형식, 필터링 또는 매개 변수 없는 항목과 관련된 YAML 템플릿 으로 시작합니다.
ASIM YAML에서 ARM 템플릿 변환기를 사용하여 YAML 파일을 ARM 템플릿으로 변환합니다.
업데이트를 배포하는 경우 포털 또는 함수 삭제 PowerShell 도구를 사용하여 이전 버전의 함수를 삭제합니다.
Azure Portal 또는 PowerShell을 사용하여 템플릿을 배포합니다.

연결된 템플릿을 사용하여 여러 템플릿을 단일 배포 프로세스에 결합할 수도 있습니다.

팁 (조언)

ARM 템플릿은 서로 다른 자원을 결합할 수 있어, 파서를 커넥터, 분석 규칙, 감시 목록과 함께 배포할 수 있습니다. 파서를 감시 목록이나 다른 테이블과 독립적으로 유지하세요.

테스트 파서

ASIM은 사용자 지정 파서를 검증할 수 있는 테스트 도구를 제공합니다. 즉, 파서는 코드이고, 때로는 복잡하며, 자동화된 테스트 외에도 코드 검토와 같은 표준 품질 보증 사례를 권장합니다.

ASIM 테스트 도구 설치

ASIM 테스트 도구를 배포하기 전에, 다음 기능이 있는 Microsoft Sentinel 작업 공간이 있는지 확인하세요:

파서가 배포됩니다.
파서에서 사용하는 원본 테이블을 사용할 수 있습니다.
파서에서 사용하는 원본 테이블은 다양한 관련 이벤트 컬렉션으로 채워집니다.

작업 공간이 이 요구사항을 충족하면 ASIM 테스트 도구를 해당 작업 공간에 배포하세요.

출력 스키마 유효성 검사

파서가 유효한 스키마를 생성하는지 확인하려면 Microsoft Sentinel Logs 페이지에서 다음 스키마 테스트 쿼리를 실행하세요. 이 명령어는 파서의 출력 필드, 타입, 별칭이 예상되는 ASIM 스키마와 일치하는지 확인합니다:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

다음과 같이 결과를 처리합니다.

오류	Action
필수 필드 누락 [<필드>]	파서에 필드를 추가합니다. 대부분의 경우 원본에서 이미 사용할 수 있는 필드가 아닌 파생 값 또는 상수 값이 됩니다.
필수 열 [<Field>]가 있는 경우 누락된 필드 [<필드>]가 필수입니다.	파서에 필드를 추가합니다. 대부분의 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다.
누락된 필드 [<필드>]는 열 [<필드>]가 있는 경우 필수입니다.	파서에 필드를 추가합니다. 대부분의 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다.
기존 열 [<Field>]에 대한 필수 별칭 [<Field>]이(가) 누락되었습니다.	파서에 별칭 추가
누락된 권장 별칭 [<Field>] 기존 열에 대한 별칭 [<Field>]	파서에 별칭 추가
선택적 별칭 누락 [<필드>] 기존 열 별칭 [<필드>]	파서에 별칭 추가
필수 별칭 누락 [<필드>], 별칭이 없는 열 [<필드>]	이 오류는 별칭이 지정된 필드에 대해 유사한 오류를 수반합니다. 별칭 필드 오류를 수정하고 이 별칭을 파서에 추가합니다.
필드 [<필드>]의 형식이 일치하지 않습니다. 현재 [<형식>]이며 [<형식>]이어야 합니다.	일반적으로 와 같은 `tostring`를 사용하여 정규화된 필드의 형식이 올바른지 확인합니다.

Info	Action
누락된 권장 필드 [<필드>]	파서에 이 필드를 추가하는 것이 좋습니다.

Info	Action
누락된 권장 별칭 [<필드>] 존재하지 않는 열 별칭 [<필드>]	별칭 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다.
존재하지 않는 열 [<필드>]에 대한 선택적 별칭 [<필드>]이 누락되었습니다.	별칭 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다.
선택적 필드 누락 [<필드>]	선택적 필드가 누락되는 경우가 많지만 목록을 검토하여 원본에서 선택적 필드를 매핑할 수 있는지 확인하는 것이 좋습니다.
정규화되지 않은 추가 필드 [<필드>]	정규화되지 않은 필드는 유효하지만 목록을 검토하여 정규화되지 않은 값을 선택적 필드에 매핑할 수 있는지 확인하는 것이 좋습니다.

비고

오류로 인해 파서 사용 콘텐츠가 제대로 작동하지 않습니다. 경고는 콘텐츠가 작동하는 것을 방지하지는 않지만 결과의 품질을 저하시킬 수 있습니다.

출력 값 유효성 검사

파서가 유효한 값을 생성하는지 확인하려면 ASIM 데이터 테스터를 사용해 파서 출력 샘플의 필드 값을 검증하고 오류나 경고를 식별하세요. Microsoft Sentinel Logs 페이지에서 다음 쿼리를 실행하세요:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

스키마 지정은 선택 사항입니다. 스키마를 지정 EventSchema 하지 않으면 필드는 이벤트가 준수해야 하는 스키마를 식별하는 데 사용됩니다. 이벤트에 필드가 EventSchema 없는 경우 공통 필드만 확인됩니다. 스키마가 매개 변수로 지정된 경우 이 스키마는 모든 레코드를 테스트하는 데 사용됩니다. 이는 EventSchema 필드를 설정하지 않는 구형 파서에 유용합니다.

비고

스키마를 지정하지 않은 경우에도 함수 이름 다음에 빈 괄호가 필요합니다.

이 테스트는 리소스를 많이 사용하며 전체 데이터 집합에서 작동하지 않을 수 있습니다. X를 쿼리 시간이 초과되지 않는 가장 큰 숫자로 설정하거나 시간 범위 선택기를 사용하여 쿼리의 시간 범위를 설정합니다.

다음과 같이 결과를 처리합니다.

Message	Action
(0) 오류: 열 [<필드>]에 대한 형식 불일치입니다. 현재 [<형식>]이며 [<형식>]이어야 합니다.	일반적으로 와 같은 `tostring`를 사용하여 정규화된 필드의 형식이 올바른지 확인합니다.
(0) 오류: [<논리 형식>] 형식의 필드 [<Field>]에 잘못된 값(최대 10개 나열됨)	파서가 올바른 원본 필드를 출력 필드에 매핑하는지 확인합니다. 올바르게 매핑된 경우 파서가 업데이트되어 원본 값을 올바른 형식, 값 또는 형식으로 변환합니다. 각 논리 형식에 대한 올바른 값 및 형식에 대한 자세한 내용은 논리 형식 목록을 참조하세요. 테스트 도구는 잘못된 값 10의 샘플만 나열합니다.
(1) 경고: 필수 필드의 빈 값 [<필드>]	필수 필드는 단지 정의만 해서는 안 되고, 값이 입력되어 있어야 합니다. 현재 원본이 비어 있는 레코드에 대한 필드를 다른 원본에서 채울 수 있는지 확인합니다.
(2) 정보: 권장 필드의 빈 값 [<필드>]	권장 필드는 일반적으로 채워져야 합니다. 현재 원본이 비어 있는 레코드에 대한 필드를 다른 원본에서 채울 수 있는지 확인합니다.
(2) 정보: 선택적 필드의 빈 값 [<필드>]	별칭이 지정된 필드가 필수인지 아니면 권장되는지 확인하고, 그렇다면 다른 원본에서 채울 수 있는지 확인합니다.

또한 대부분의 메시지는 메시지를 생성한 레코드 수와 총 샘플의 백분율을 보고합니다. 이 비율은 문제의 중요성을 나타내는 좋은 지표입니다. 예를 들어 권장되는 필드의 경우:

90% 빈 값은 일반적인 구문 분석 문제를 나타낼 수 있습니다.
25% 빈 값은 올바르게 구문 분석되지 않은 이벤트 변형을 나타낼 수 있습니다.
소수의 빈 값은 무시할 수 있는 문제일 수 있습니다.

비고

파서 제공

파서를 주 ASIM 배포판에 기여하는 것을 고려해 볼 수 있습니다. 승인되면 해당 파서는 모든 고객에게 ASIM 기본 제공 파서로 제공됩니다.

파서를 제공하려면:

필터링 파서와 매개 변수가 없는 파서 모두를 개발합니다.
위의 파서 배포에 설명된 대로 파서용 YAML 파일을 만드세요.
파서가 오류 없이 모든 테스트를 통과해야 합니다. 경고가 남아 있는 경우 파서 YAML 파일에 문서화합니다 .
다음을 포함하여 Microsoft Sentinel GitHub 리포지토리 대한 끌어오기 요청을 만듭니다.
- ASIM 파서 폴더의 파서 YAML 파일(/Parsers/ASim<schema>/Parsers)
- 샘플 제출 지침에 따른 대표적인 샘플 데이터입니다.
- 테스트 결과 제출 지침에 따라 결과를 테스트합니다.

허용된 경고 문서화

ASIM 테스트 도구에서 나열된 경고가 파서에 유효하다고 간주되면, 예외 섹션을 통해 파서 YAML 파일에 허용된 경고를 문서화하세요. 다음 YAML 예시는 파서 정의 섹션에서 Exceptions 허용된 파서 테스트 경고를 기록하는 방법을 보여줍니다:

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

YAML 파일에 지정된 경고는 해당 ASIM 테스터 경고 메시지의 짧은 형태여야 하며, 해당 특정 경고를 식별할 만큼 고유해야 합니다. 이 값은 자동 테스트 중 ASIM 테스터 경고 메시지를 일치시키고 일치하는 경고는 무시하는 데 사용됩니다.

샘플 제출 지침

구문 분석기 문제를 해결하고 파서에 대한 향후 업데이트가 이전 샘플을 준수하는지 확인하는 경우 샘플 데이터가 필요합니다. 제출하는 샘플에는 파서가 지원하는 이벤트 변형이 포함되어야 합니다. 샘플 이벤트에는 성공 및 실패 활동을 나타내는 이벤트와 같은 가능한 모든 이벤트 형식, 이벤트 형식 및 변형이 포함되어 있는지 확인합니다. 또한 값 형식의 변형이 표시되는지 확인합니다. 예를 들어 호스트 이름을 FQDN 또는 간단한 호스트 이름으로 나타낼 수 있는 경우 샘플 이벤트에는 두 형식이 모두 포함되어야 합니다.

이벤트 샘플을 제출하려면 다음 단계를 사용합니다.

Logs 화면에서 파서가 선택한 이벤트만 원본 테이블에서 추출하는 쿼리를 실행합니다. 예를 들어, Infoblox DNS 파서의 경우, 파서가 처리하는 Infoblox NIOS Syslog 레코드만 가져오려면 다음 쿼리를 사용하세요:

    Syslog
    | where ProcessName == "named"

CSV로 내보내기 옵션을 사용하여 결과를 <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv라는 이름의 파일로 내보냅니다. 여기서 EventProduct, EventProduct, 및 EventSchema는 파서가 해당 필드에 할당한 값입니다.
Logs 화면에서 소스 테이블에서 getschema을 실행하여 사용 가능한 열과 해당 열의 데이터 형식을 확인하세요. 이 스키마 정보를 샘플 데이터와 함께 내보내세요. 예를 들어, Infoblox DNS 파서의 쿼리는 다음과 같습니다:

    Syslog
    | getschema

CSV로 내보내기 옵션을 사용하여 결과를 라는 <TableName>_schema.csv파일로 내보냅니다. 여기서 TableName 는 파서가 사용하는 원본 테이블의 이름입니다.
PR의 두 파일을 폴더 /Sample Data/ASIM에 포함합니다. 파일이 이미 있는 경우 이름에 GitHub 핸들을 추가합니다. 예를 들면 다음과 같습니다. <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

테스트 결과 제출 지침

테스트 결과는 파서의 정확성을 확인하고 보고된 예외를 이해하는 데 중요합니다.

테스트 결과를 제출하려면 다음 단계를 사용합니다.

테스트 파서에서 설명한 대로 파서 테스트를 실행하세요.
그리고 테스트 결과를 CSV로 내보내기 옵션을 사용하여 각각 <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv 및 <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv라는 이름의 파일로 내보냅니다.
PR의 두 파일을 폴더 /Parsers/ASim<schema>/Tests에 포함합니다.

ASIM 파서에 대해 자세히 알아보세요.

일반적으로 ASIM에 대해 자세히 알아보세요.

피드백

이 페이지가 도움이 되었나요?

2026-09-08 에 마지막으로 업데이트됨