다음을 통해 공유

ASIM(고급 보안 정보 모델) 파서(공개 미리 보기) 개발

  • 아티클

ASIM(Advanced Security Information Model) 사용자는 쿼리에서 테이블 이름 대신 통합 파서를 사용하여 데이터를 정규화된 형식으로 보고 스키마와 관련된 모든 데이터를 쿼리에 포함시킵니다. 그러면 통합 파서가 원본별 파서를 사용하여 각 원본의 특정 세부 정보를 처리합니다.

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

  • 디바이스가 ASIM 스키마에 맞는 이벤트를 제공하지만 디바이스 및 관련 스키마에 대한 원본별 파서를 Microsoft Sentinel에서 사용할 수 없습니다.

  • ASIM 원본별 파서를 디바이스에 사용할 수 있지만 디바이스가 이벤트를 보내는 방법 또는 형식이 ASIM 파서에 필요한 것과 다릅니다. 예:

    • 표준이 아닌 방식으로 이벤트를 보내도록 원본 디바이스가 구성될 수 있습니다.

    • 디바이스 버전이 ASIM 파서에서 지원하는 버전과 다를 수 있습니다.

    • 이벤트를 중개자 시스템이 수집, 수정 및 전달할 수 있습니다.

파서를 ASIM 아키텍처에 맞추는 방법을 이해하려면 ASIM 아키텍처 다이어그램을 참조하세요.

Important

ASIM은 현재 미리 보기 상태입니다. Azure Preview 추가 약관에는 베타, 미리 보기 또는 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 추가 법률 용어가 포함되어 있습니다.

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

다음 워크플로는 원본별 파서인 사용자 지정 ASIM을 개발하는 대략적인 단계를 설명합니다.

  1. 샘플 로그 수집.

  2. 원본에서 보낸 이벤트가 나타나는 스키마를 식별합니다. 자세한 내용은 스키마 개요를 참조하세요.

  3. 원본 이벤트 필드를 식별된 스키마에 매핑합니다.

  4. 원본에 대한 하나 이상의 ASIM 파서를 개발합니다. 원본과 관련된 각 스키마에 대해 필터링 파서와 매개 변수가 없는 파서를 개발해야 합니다.

  5. 파서를 테스트합니다.

  6. Microsoft Sentinel 작업 영역에 파서를 배포합니다.

  7. 새로운 사용자 지정 파서를 참조하도록 관련 ASIM 통합 파서를 업데이트합니다. 자세한 내용은 ASIM 파서 관리를 참조하세요.

  8. 기본 ASIM 배포에 파서를 제공할 수도 있습니다. 적용된 파서는 모든 작업 영역에서 기본 제공 파서로 사용할 수도 있습니다.

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

팁

또한 Microsoft Sentinel 정규화 파서 및 정규화된 콘텐츠에 대한 심층 분석 웹 세미나를 시청하거나 관련 슬라이드 데크를 검토하세요. 자세한 내용은 다음 단계를 참조하세요.

샘플 로그 수집

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

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

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

  • 이벤트 결과가 다른 이벤트.
  • 대응 작업이 다른 이벤트.
  • 사용자 이름, 호스트 이름 및 ID, 값 정규화가 필요한 기타 필드에 대한 다양한 형식.

팁

동일한 스키마에 대한 기존 파서를 사용하여 새로운 사용자 지정 파서를 시작하세요. 특히 스키마에 필요한 모든 매개 변수를 허용하도록 파서를 필터링하려면 기존 파서를 사용해야 합니다.

계획 매핑

파서를 개발하기 전에 원본 이벤트에서 사용 가능한 정보를 식별한 스키마에 매핑합니다.

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

파서 개발

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

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

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

필터링

관련 레코드 필터링

대부분의 경우 Microsoft Sentinel의 테이블에는 여러 유형의 이벤트가 포함됩니다. 예를 들면 다음과 같습니다.

  • Syslog 테이블에는 여러 원본의 데이터가 있습니다.
  • 사용자 지정 테이블은 둘 이상의 이벤트 유형을 제공하는 단일 원본의 데이터를 포함하고 다양한 스키마에 적합할 수 있습니다.

따라서 파서는 먼저 대상 스키마와 관련된 레코드만 필터링해야 합니다.

KQL의 필터링은 where 연산자를 사용하여 수행합니다. 예를 들어 Sysmon event 1은 프로세스 생성을 보고하며 따라서 ProcessEvent 스키마로 정규화됩니다. Sysmon event 1 이벤트는 Event 테이블에 포함되므로 다음 필터를 사용해야 합니다.

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Important

파서는 시간으로 필터링하면 안 됩니다. 파서를 사용하는 쿼리는 시간 범위를 적용합니다.

관심 목록을 사용하여 원본 유형별 필터링

이벤트 자체에는 특정 원본 유형에 대한 필터링을 허용하는 정보가 포함되지 않는 경우가 있습니다.

예를 들어 Infoblox DNS 이벤트는 Syslog 메시지로 전송되며, 다른 원본에서 전송된 Syslog 메시지와 구별하기 어렵습니다. 이러한 경우 파서는 관련 이벤트를 정의하는 원본 목록을 사용합니다. 이 목록은 Sources_by_SourceType 관심 목록에서 관리됩니다.

파서에서 ASimSourceType 관심 목록을 사용하려면 파서 필터링 섹션에서 _ASIM_GetSourceBySourceType 함수를 사용합니다. 예를 들어 Infoblox DNS 파서의 필터링 섹션에는 다음이 포함됩니다.

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

파서에서 이 샘플을 사용하려면 다음을 수행합니다.

  • Computer를 원본에 대한 원본 정보를 포함하는 필드 이름으로 바꿉니다. Syslog 기반의 파서인 경우 Computer로 두어도 됩니다.

  • InfobloxNIOS 토큰을 파서에 원하는 값으로 바꿉니다. 파서 사용자에게 ASimSourceType 관심 목록을 선택한 값으로 업데이트하고, 이 유형의 이벤트를 보내는 원본 목록을 업데이트해야 한다고 알립니다.

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

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

필터링할 때 다음 사항을 지켜야 합니다.

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

다음 예제에서는 기본값이 일반적으로 '*'인 문자열 매개 변수와 기본값이 일반적으로 빈 목록인 목록 매개 변수에 대한 필터링을 구현하는 방법을 보여줍니다.

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

필터링 최적화

파서의 성능을 보장하려면 다음 필터링 권장 사항을 참고하세요.

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

성능에 대한 필터링 권장 사항을 따르기 어려울 때도 있습니다. 예를 들어, has 사용은 contains보다 덜 정확합니다. 다른 경우에는 SyslogMessage와 같은 기본 제공 필드와 일치시키는 것은 DvcAction과 같은 추출된 필드와 비교하는 것보다 덜 정확합니다. 이러한 경우에는 기본 제공 필드에 대해 성능 최적화 연산자를 사용하여 미리 필터링하고 구문 분석 후에 더 정확한 조건을 사용하여 필터를 반복하는 것이 좋습니다.

예제를 보려면 다음 Infoblox DNS 파서 코드 조각을 참조하세요. 파서는 먼저 SyslogMessage 필드에 client 단어가 has(있는지) 확인합니다. 그러나 이 용어는 메시지의 다른 위치에서 사용될 수 있으므로 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을 사용합니다. project-rename을 사용하면 필드가 여전히 실제 필드로 관리되고 필드 처리가 보다 효율적으로 수행되도록 합니다. 예시:

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

필드 형식 및 형식 정규화

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

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

예를 들어 원래 고유 이벤트 ID는 정수로 전송될 수 있지만 ASIM에서는 데이터 원본 간의 광범위한 호환성을 보장하기 위해 값이 문자열이어야 합니다. 따라서 원본 필드를 할당할 때 project-rename 대신 extend 및 tostring을 사용합니다.

  | extend EventOriginalUid = tostring(ReportId),

파생 필드 및 값

원본 필드의 값은 추출된 후 대상 스키마 필드에 대해 지정된 값 세트에 매핑해야 할 수 있습니다. iff, case 및 lookup 함수는 사용 가능한 데이터를 대상 값에 매핑하는 데 도움이 될 수 있습니다.

예를 들어, Microsoft DNS 파서는 다음과 같이 iff 문을 사용하여 이벤트 ID와 응답 코드를 기반으로 EventResult 필드를 할당합니다.

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

여러 값을 매핑하려면 datatable 연산자를 사용하여 매핑을 정의하고 lookup을 사용하여 매핑을 수행합니다. 예를 들어, 일부 원본은 숫자 DNS 응답 코드와 네트워크 프로토콜을 보고하지만 스키마는 둘 모두에 대해 보다 일반적인 텍스트 레이블 표현을 요구합니다. 다음 예는 datatable 및 lookup을 사용하여 필요한 값을 도출하는 방법을 보여 줍니다.

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

매핑에 가능한 값이 두 개뿐인 경우에도 조회가 유용하고 효율적입니다.

매핑 조건이 더 복잡한 경우 iff, case 및 lookup을 결합합니다. 아래 예는 lookup과 case를 결합하는 방법을 보여 줍니다. 위의 lookup 예는 조회 값을 찾을 수 없는 경우 DnsResponseCodeName 필드에 빈 값을 반환합니다. 아래의 case 예는 가능한 경우 lookup 작업의 결과를 사용하고 그렇지 않은 경우 추가 조건을 지정하여 이를 보강합니다.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel은 공통 조회 값에 대한 편리한 함수를 제공합니다. 예를 들어 위의 DnsResponseCodeName 조회는 다음 함수 중 하나를 사용하여 구현할 수 있습니다.


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

첫 번째 옵션은 조회할 값을 매개 변수로 받아 출력 필드를 선택할 수 있도록 하므로 일반 조회 함수로 유용합니다. 두 번째 옵션은 파서에 더 적합하고 원본 필드의 이름을 입력으로 사용하며 필요한 ASIM 필드(이 경우 DnsResponseCodeName)를 업데이트합니다.

ASIM 도움말 함수의 전체 목록은 ASIM 함수를 참조하세요.

보강 필드

원본에서 사용 가능한 필드 외에도 결과 ASIM 이벤트에는 파서가 생성해야 하는 보강 필드가 포함됩니다. 많은 경우 파서는 필드에 상수 값을 할당할 수 있습니다. 예를 들면 다음과 같습니다.

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

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

대부분의 경우 형식에도 상수 값이 할당됩니다. 그러나 어떤 경우에는 형식이 실제 값을 기반으로 결정되어야 합니다. 예를 들면 다음과 같습니다.

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

Microsoft Sentinel은 보강 처리에 유용한 함수를 제공합니다. 예를 들어, 다음 함수를 사용하여 Computer 필드의 값을 기반으로 SrcHostname, SrcDomain, SrcDomainType 및 SrcFQDN 필드를 자동으로 할당합니다.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

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

컴퓨터 필드 출력 필드
server1 SrcHostname: server1
SrcDomain, SrcDomainType, SrcFQDN 모두 비어 있음
server1.microsoft.com SrcHostname: server1
SrcDomain: microsoft.com
SrcDomain 형식: FQDNSrcDomainType
SrcFQDN:server1.microsoft.com

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

결과 집합에서 필드 선택

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

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

Operator 설명 파서에서 사용하는 경우
project-away 필드를 제거합니다. 결과 집합에서 제거하려는 특정 필드에는 project-away를 사용합니다. 혼동을 일으키거나 매우 크고 성능에 영향을 미칠 수 있는 경우가 아니면 결과 집합에서 정규화되지 않은 원래 필드를 제거하지 않는 것이 좋습니다.
project 이전에 존재했거나 명령문의 일부로 만들어진 필드를 선택하고, 그 외의 필드를 모두 제거합니다. 파서가 정규화되지 않은 다른 필드를 제거하지 않아야 하므로 파서에서 사용하지 않는 것이 좋습니다.

구문 분석 중에 사용되는 임시 값과 같은 특정 필드를 제거해야 하는 경우에는 project-away를 사용하여 결과에서 제거합니다.

예를 들어, 사용자 지정 로그 테이블을 구문 분석할 때 다음을 사용하여 여전히 형식 설명자가 있는 나머지 원래 필드를 제거합니다.

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

구문 분석 변형 처리

Important

다른 변형은 일반적으로 다른 스키마에 매핑되는 다른 이벤트 유형을 나타내며 별도의 파서를 개발합니다.

대부분의 경우 이벤트 스트림의 이벤트는 다른 구문 분석 논리가 필요한 변형을 포함합니다. 단일 파서에서 다양한 변형을 구문 분석하려면 iff 및 case와 같은 조건문을 사용하거나 통합 구조를 사용합니다.

union을 사용하여 여러 변형을 처리하려면 각 변형에 대해 별도의 함수를 만들고 결합 문을 사용하여 결과를 결합합니다.

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

중복 이벤트 및 과도한 처리를 방지하려면 네이티브 필드를 사용하여 구문 분석하려는 이벤트만 필터링하여 각 함수를 시작해야 합니다. 또한 필요한 경우 공용 구조체를 사용하기 전에 각 지점에서 project-away를 사용합니다.

파서 배포

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

파서를 대량으로 배포하려면 다음과 같이 파서 ARM 템플릿을 사용하는 것이 좋습니다.

  1. 각 스키마에 대한 관련 템플릿을 기반으로 YAML 파일을 만들고 이 파일에 쿼리를 포함시킵니다. 스키마 및 파서 형식, 필터링 또는 매개 변수 없는 파서와 관련된 YAML 템플릿으로 시작합니다.

  2. ASIM Yaml-ARM 템플릿 변환기를 사용하여 YAML 파일을 ARM 템플릿으로 변환합니다.

  3. 업데이트를 배포하는 경우 포털 또는 함수 삭제 PowerShell 도구를 사용하여 이전 버전의 함수를 삭제합니다.

  4. Azure Portal 또는 PowerShell을 사용하여 템플릿을 배포합니다.

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

팁

ARM 템플릿은 여러 리소스를 결합할 수 있으므로 커넥터, 분석 규칙, 관심 목록 등의 유용한 옵션과 함께 파서를 배포할 수 있습니다. 예를 들어 파서는 함께 배포되는 관심 목록을 참조할 수 있습니다.

파서 테스트

이 섹션에서는 파서를 테스트할 수 있도록 ASIM이 제공하는 테스트 도구에 대해 설명합니다. 즉, 파서는 코드이며 때로는 복잡하며 자동화된 테스트 외에도 코드 검토와 같은 표준 품질 보증 사례가 권장됩니다.

ASIM 테스트 도구 설치

ASIM을 테스트하려면 다음과 같은 Microsoft Sentinel 작업 영역에 ASIM 테스트 도구를 배포합니다.

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

출력 스키마 유효성 검사

파서가 유효한 스키마를 생성하게 하려면 Microsoft Sentinel 로그 페이지에서 다음 쿼리를 실행하여 ASIM 스키마 테스터를 사용합니다.

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

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

오류 작업
Missing mandatory field [<Field>] 파서에 필드를 추가합니다. 원본에서 이미 사용할 수 있는 필드가 아니라 파생 값 또는 상수 값인 경우가 많습니다.
Missing field [<Field>] is mandatory when mandatory column [<Field>] exists 파서에 필드를 추가합니다. 많은 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다.
Missing field [<Field>] is mandatory when column [<Field>] exists 파서에 필드를 추가합니다. 많은 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다.
Missing mandatory alias [<Field>] aliasing existing column [<Field>] 파서에 별칭 추가
Missing recommended alias [<Field>] aliasing existing column [<Field>] 파서에 별칭 추가
Missing optional alias [<Field>] aliasing existing column [<Field>] 파서에 별칭 추가
Missing mandatory alias [<Field>] aliasing missing column [<Field>] 이 오류는 별칭이 지정된 필드에 대한 유사한 오류를 수반합니다. 별칭 필드 오류를 수정하고 이 별칭을 파서에 추가하세요.
Type mismatch for field [<Field>]. It is currently [<Type>] and should be [<Type>] 정규화된 필드의 형식이 올바른지 확인합니다. 일반적으로 tostring과 같은 변환 함수를 사용합니다.
정보 작업
Missing recommended field [<Field>] 파서에 이 필드를 추가하는 것이 좋습니다.
정보 작업
Missing recommended alias [<Field>] aliasing non-existent column [<Field>] 별칭이 지정된 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다.
Missing optional alias [<Field>] aliasing non-existent column [<Field>] 별칭이 지정된 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다.
Missing optional field [<Field>] 선택적 필드가 자주 누락되지만, 목록을 검토하여 원본에서 매핑할 수 있는 선택적 필드가 있는지 확인하는 것이 좋습니다.
Extra unnormalized field [<Field>] 정규화되지 않은 필드도 유효하지만, 목록을 검토하여 선택적 필드에 매핑할 수 있는 정규화되지 않은 값이 있는지 확인하는 것이 좋습니다.

참고 항목

오류가 발생하면 파서를 사용하는 콘텐츠가 제대로 작동하지 않습니다. 경고가 표시되어도 콘텐츠가 작동하지만 방지하지 않지만 결과의 품질이 저하될 수 있습니다.

출력 값의 유효성 검사

파서가 유효한 값을 생성하게 하려면 Microsoft Sentinel 로그 페이지에서 다음 쿼리를 실행하여 ASIM 데이터 테스터를 사용합니다.

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

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

참고 항목

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

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

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

메시지 작업
(0) Error: type mismatch for column [<Field>]. It is currently [<Type>] and should be [<Type>] 정규화된 필드의 형식이 올바른지 확인합니다. 일반적으로 tostring과 같은 변환 함수를 사용합니다.
(0) Error: Invalid value(s) (up to 10 listed) for field [<Field>] of type [<Logical Type>] 파서가 올바른 원본 필드를 출력 필드에 매핑하는지 확인합니다. 올바르게 매핑된 경우 원본 값을 올바른 유형, 값 또는 형식으로 변환하도록 파서를 업데이트합니다. 각 논리 형식의 올바른 값과 형식에 대한 자세한 내용은 논리 형식 목록을 참조하세요.

테스트 도구는 잘못된 값 10개 샘플만 나열합니다.
(1) Warning: Empty value in mandatory field [<Field>] 필수 필드를 정의하는 데서 그치지 말고 채워야 합니다. 현재 원본이 비어 있는 레코드에 대한 다른 원본에서 필드를 채울 수 있는지 확인합니다.
(2) Info: Empty value in recommended field [<Field>] 일반적으로 권장 필드를 채워야 합니다. 현재 원본이 비어 있는 레코드에 대한 다른 원본에서 필드를 채울 수 있는지 확인합니다.
(2) Info: Empty value in optional field [<Field>] 별칭이 지정된 필드가 필수 또는 권장 필드인지 확인하고, 필수 또는 권장 필드인 경우 다른 원본에서 채울 수 있는지 확인합니다.

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

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

참고 항목

오류가 발생하면 파서를 사용하는 콘텐츠가 제대로 작동하지 않습니다. 경고가 표시되어도 콘텐츠가 작동하지만 방지하지 않지만 결과의 품질이 저하될 수 있습니다.

파서 제공

기본 ASIM 배포에 파서를 제공할 수 있습니다. 수용되면 모든 고객은 파서를 ASIM 기본 제공 파서로 사용할 수 있습니다.

파서를 제공하려면:

  • 필터링 파서와 매개 변수가 없는 파서를 모두 개발합니다.
  • 위의 파서 배포에 설명된 대로 파서에 대한 YAML 파일을 만듭니다.
  • 파서가 오류 없이 모든 테스트를 통과하는지 확인합니다. 경고가 남아 있으면 파서 YAML 파일에 문서화합니다.
  • 다음을 포함하여 Microsoft Sentinel GitHub 리포지토리에 대해 끌어오기 요청을 만듭니다.

허용된 경고 문서화

ASIM 테스트 도구에 의해 나열된 경고가 파서에 유효한 것으로 간주되는 경우 아래 예와 같이 예외 섹션을 사용하여 파서 YAML 파일에 허용된 경고를 문서화합니다.

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 파일에 지정된 경고는 고유하게 식별되는 경고 메시지의 짧은 형식이어야 합니다. 값은 자동화된 테스트를 수행할 때 경고 메시지를 일치시키고 무시하는 데 사용됩니다.

샘플 제출 지침

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

이벤트 샘플을 제출하려면 다음 단계를 따릅니다.

  • Logs 화면에서 원본 테이블에서 파서가 선택한 이벤트만 추출하는 쿼리를 실행합니다. 예를 들어, Infoblox DNS 파서의 경우 다음 쿼리를 사용합니다.
    Syslog
    | where ProcessName == "named"

  • CSV로 내보내기 옵션을 사용하여 결과를 <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv 파일로 내보냅니다. 여기서 EventProduct, EventProduct 및 EventSchema는 파서가 해당 필드에 할당한 값입니다.

  • Logs 화면에서 스키마 또는 파서 입력 테이블을 출력할 쿼리를 실행합니다. 예를 들어, 동일한 Infoblox DNS 파서의 경우 쿼리는 다음과 같습니다.

    Syslog
    | getschema

  • CSV로 내보내기 옵션을 사용하여 결과를 <TableName>_schema.csv 파일로 내보냅니다. 여기서 TableName은 파서가 사용하는 원본 테이블의 이름입니다.

  • /Sample Data/ASIM 폴더의 PR에 두 파일을 모두 포함합니다. 파일이 이미 있는 경우 이름에 GitHub 핸들을 추가합니다(예: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHanlde>.csv).

테스트 결과 제출 지침

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

테스트 결과를 제출하려면 다음 단계를 따릅니다.

  • 파서 테스트를 실행하고 테스트 섹션에 설명되어 있습니다.

  • CSV로 내보내기 옵션을 사용하여 각각 <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv 및 <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv라는 파일로 테스트 결과를 내보냅니다.

  • /Parsers/ASim<schema>/Tests 폴더의 PR에 두 파일을 모두 포함합니다.

다음 단계

이 문서에서는 ASIM 파서 개발에 대해 설명했습니다.

ASIM 파서에 대해 자세히 알아보기:

일반적으로 ASIM에 대해 자세히 알아봅니다.