ASIM(고급 보안 정보 모델) 사용자는 쿼리에서 테이블 이름 대신 통합 파서를 사용하여 정규화된 형식으로 데이터를 보고 쿼리에 스키마와 관련된 모든 데이터를 포함합니다. 차례로 파서를 통합하면 원본별 파서를 사용하여 각 소스의 특정 세부 정보를 처리합니다.
Microsoft Sentinel 많은 데이터 원본에 대한 기본 제공 원본별 파서를 제공합니다. 다음과 같은 상황에서 이러한 원본별 파서를 수정하거나 개발할 수 있습니다.
디바이스가 ASIM 스키마에 맞는 이벤트를 제공하지만 디바이스 및 관련 스키마에 대한 원본별 파서를 제공하는 경우 Microsoft Sentinel 사용할 수 없습니다.
디바이스에서 ASIM 원본별 파서를 사용할 수 있지만 디바이스가 ASIM 파서가 예상한 것과 다른 메서드 또는 형식으로 이벤트를 보내는 경우. 예시:
비표준 방식으로 이벤트를 보내도록 원본 디바이스를 구성할 수 있습니다.
디바이스의 버전이 ASIM 파서에서 지원하는 버전과 다를 수 있습니다.
이벤트는 중간 시스템에서 수집, 수정 및 전달될 수 있습니다.
파서가 ASIM 아키텍처에 어떻게 적합한지 이해하려면 ASIM 아키텍처 다이어그램을 참조하세요.
사용자 지정 ASIM 파서 개발 프로세스
다음 워크플로에서는 원본별 파서인 사용자 지정 ASIM을 개발하는 높은 수준의 단계를 설명합니다.
원본에서 보낸 이벤트가 나타내는 스키마 또는 스키마를 식별합니다. 자세한 내용은 스키마 개요를 참조하세요.
원본 이벤트 필드를 식별된 스키마 또는 스키마에 매핑합니다.
원본에 대해 하나 이상의 ASIM 파서를 개발합니다. 원본과 관련된 각 스키마에 대해 필터링 파서 및 매개 변수가 없는 파서가 개발되어야 합니다.
파서 테스트
파서를 Microsoft Sentinel 작업 영역에 배포합니다.
관련 ASIM 통합 파서가 새 사용자 지정 파서에 참조되도록 업데이트합니다. 자세한 내용은 ASIM 파서 관리를 참조하세요.
또한 기본 ASIM 배포에 파서를 기여할 수도 있습니다 . 기여된 파서는 모든 작업 영역에서 기본 제공 파서로 사용할 수도 있습니다.
이 문서에서는 프로세스의 개발, 테스트 및 배포 단계를 안내합니다.
팁
또한 파서 정규화 및 정규화된 콘텐츠 Microsoft Sentinel 심층 분석 웨비나를 시청하거나 관련 슬라이드 데크를 검토합니다. 자세한 내용은 다음 단계를 참조하세요.
샘플 로그 수집
효과적인 ASIM 파서를 빌드하려면 대표적인 로그 집합이 필요합니다. 대부분의 경우 원본 시스템을 설정하고 Microsoft Sentinel 연결해야 합니다. 사용 가능한 원본 디바이스가 없는 경우 클라우드 종량제 서비스를 사용하면 개발 및 테스트를 위해 많은 디바이스를 배포할 수 있습니다.
또한 로그에 대한 공급업체 설명서 및 샘플을 찾는 것은 광범위한 로그 형식 적용 범위를 보장하여 개발을 가속화하고 실수를 줄이는 데 도움이 될 수 있습니다.
대표적인 로그 집합에는 다음이 포함되어야 합니다.
- 이벤트 결과가 다른 이벤트입니다.
- 다른 응답 동작이 있는 이벤트입니다.
- 사용자 이름, 호스트 이름 및 ID 및 값 정규화가 필요한 기타 필드에 대한 다양한 형식입니다.
팁
동일한 스키마에 대해 기존 파서 를 사용하여 새 사용자 지정 파서 시작 기존 파서를 사용하는 것은 스키마에 필요한 모든 매개 변수를 허용하도록 파서를 필터링하는 데 특히 중요합니다.
매핑 계획
파서가 개발되기 전에 원본 이벤트 또는 이벤트에서 사용할 수 있는 정보를 식별한 스키마에 매핑합니다.
- 모든 필수 필드와 권장 필드를 매핑합니다.
- 원본에서 사용할 수 있는 모든 정보를 정규화된 필드로 매핑해 보세요. 선택한 스키마의 일부로 사용할 수 없는 경우 다른 스키마에서 사용할 수 있는 필드에 매핑하는 것이 좋습니다.
- 원본의 필드에 대한 값을 ASIM에서 허용하는 정규화된 값에 매핑합니다. 원래 값은 와 같은
EventOriginalResultDetails별도의 필드에 저장됩니다.
파서 개발
각 관련 스키마에 대한 필터링 및 매개 변수 없는 파서 모두를 개발합니다.
사용자 지정 파서는 Microsoft Sentinel 로그 페이지에서 개발된 KQL 쿼리입니다. 파서 쿼리에는 다음 세 부분으로 구성됩니다.
필터>구문 분석>필드 준비
필터링
관련 레코드 필터링
대부분의 경우 Microsoft Sentinel 테이블에는 여러 유형의 이벤트가 포함됩니다. 예시:
- Syslog 테이블에는 여러 원본의 데이터가 있습니다.
- 사용자 지정 테이블에는 둘 이상의 이벤트 형식을 제공하고 다양한 스키마에 맞을 수 있는 단일 원본의 정보가 포함될 수 있습니다.
따라서 파서는 먼저 대상 스키마와 관련된 레코드만 필터링해야 합니다.
KQL에서 필터링은 연산자를 사용하여 수행됩니다 where . 예를 들어 Sysmon 이벤트 1 은 프로세스 생성을 보고하므로 ProcessEvent 스키마로 정규화됩니다.
Sysmon 이벤트 1 이벤트는 테이블의 Event 일부이므로 다음 필터를 사용합니다.
Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1
중요
파서는 시간별로 필터링하면 안 됩니다. 파서 를 사용하는 쿼리는 시간 범위를 적용합니다.
관심 목록을 사용하여 원본 유형별 필터링
경우에 따라 이벤트 자체에 특정 원본 형식에 대한 필터링을 허용하는 정보가 포함되지 않습니다.
예를 들어 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)
Kusto 설명서에서 다음 항목에 대한 자세한 내용을 참조하세요.
필터링 최적화
파서의 성능을 확인하려면 다음 필터링 권장 사항을 확인합니다.
- 항상 구문 분석된 필드가 아닌 기본 제공에서 필터링합니다. 구문 분석된 필드를 사용하여 필터링하는 것이 더 쉬운 경우도 있지만 성능에 큰 영향을 줍니다.
-
최적화된 성능을 제공하는 연산자를 사용합니다. 특히 ,
==has및 입니다startswith. 또는matches regex와 같은contains연산자를 사용하면 성능에 큰 영향을 줍니다.
성능에 대한 권장 사항을 필터링하는 것이 항상 쉽지 않을 수 있습니다. 예를 들어 를 사용하는 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 연산자는 성능 최적화에 따라 아래에 나열됩니다. 첫 번째는 가장 최적화된 성능을 제공하는 반면, 마지막은 최적화되지 않은 성능을 제공합니다.
| Operator/function() | 설명 |
|---|---|
| split() 함수 | 구분된 값의 문자열을 구문 분석합니다. |
| parse_csv() 함수 | CSV(쉼표로 구분된 값) 줄 형식의 값 문자열을 구문 분석합니다. |
| parse-kv 연산자 | 문자열 식에서 구조화된 정보를 추출하고 키/값 형식으로 정보를 나타냅니다. |
| parse 연산자 | 패턴을 사용하여 임의 문자열에서 여러 값을 구문 분석합니다. 이 패턴은 더 나은 성능의 간소화된 패턴 또는 정규식일 수 있습니다. |
| extract_all() 함수 | 정규식을 사용하여 임의의 문자열에서 단일 값을 구문 분석합니다.
extract_all 는 후자가 정규식을 사용하는 경우와 비슷한 성능을 parse 줍니다. |
| extract() 함수 | 정규식을 사용하여 임의의 문자열에서 단일 값을 추출합니다. 를 사용하면 extract 단일 값이 필요한 경우 또는 extract_all 보다 parse 더 나은 성능을 제공합니다. 그러나 동일한 원본 문자열을 통해 의 extract 여러 활성화를 사용하는 것은 단일 parse 또는 extract_all 보다 덜 효율적이며 피해야 합니다. |
| parse_json() 함수 | JSON 형식의 문자열에서 값을 구문 분석합니다. JSON에서 몇 가지 값만 필요한 경우 , extract또는 extract_all 을 사용하여 parse더 나은 성능을 제공합니다. |
| parse_xml() 함수 | XML 형식의 문자열에서 값을 구문 분석합니다. XML에서 몇 가지 값만 필요한 경우 , extract또는 extract_all 을 사용하여 parse더 나은 성능을 제공합니다. |
정상화
매핑 필드 이름
가장 간단한 정규화 형식은 원래 필드의 이름을 정규화된 이름으로 바꾸는 것입니다. 연산 project-rename 자를 사용합니다. 프로젝트 이름 바꾸기를 사용하면 필드가 여전히 실제 필드로 관리되고 필드 처리가 더 성능이 높아집니다. 예시:
| project-rename
ActorUserId = InitiatingProcessAccountSid,
ActorUserAadId = InitiatingProcessAccountObjectId,
ActorUserUpn = InitiatingProcessAccountUpn,
필드 형식 및 형식 정규화
대부분의 경우 추출된 원래 값을 정규화해야 합니다. 예를 들어 ASIM에서 MAC 주소는 콜론을 구분 기호로 사용하지만 원본은 하이픈으로 구분된 MAC 주소를 보낼 수 있습니다. 값을 변환하기 위한 기본 연산자는 extend광범위한 KQL 문자열, 숫자 및 날짜 함수 집합과 함께 입니다.
또한 파서 출력 필드가 스키마에 정의된 형식과 일치하는지 확인하는 것은 파서가 작동하는 데 중요합니다. 예를 들어 날짜 및 시간을 나타내는 문자열을 datetime 필드로 변환해야 할 수 있습니다. 및 tohex 와 같은 todatetime 함수는 이러한 경우에 유용합니다.
예를 들어 원래 고유 이벤트 ID는 정수로 보낼 수 있지만 ASIM은 데이터 원본 간의 광범위한 호환성을 보장하기 위해 값을 문자열로 지정해야 합니다. 따라서 원본 필드를 할당할 때 대신 및 tostring 를 project-rename사용합니다extend.
| 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
매핑에 두 개의 가능한 값만 있는 경우에도 조회가 유용하고 효율적입니다.
매핑 조건이 더 복잡한 경우 , 및 lookup를 case결합iff합니다. 아래 예제에서는 및 case를 결합 lookup 하는 방법을 보여줍니다. 위의 예제에서는 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 보강을 처리하는 데 유용한 함수를 제공합니다. 예를 들어 다음 함수를 사용하여 필드의 값에 따라 , SrcDomainSrcDomainType 및 SrcFQDN 필드를 SrcHostnameComputer자동으로 할당합니다.
| 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 는 관련 Dst 및 _ASIM_ResolveDvcFQDNDvc 필드를 채우는 유사한 작업을 수행합니다. ASIM 도움말 함수의 전체 목록은 ASIM 함수를 참조하세요.
결과 집합에서 필드 선택
파서는 선택적으로 결과 집합에서 필드를 선택할 수 있습니다. 불필요한 필드를 제거하면 정규화된 필드와 나머지 원본 필드 간의 혼동을 방지하여 성능을 향상시키고 명확성을 높일 수 있습니다.
다음 KQL 연산자는 결과 집합에서 필드를 선택하는 데 사용됩니다.
| 연산자 | 설명 | 파서에서 사용해야 하는 경우 |
|---|---|---|
| project-away | 필드를 제거합니다. | 결과 집합에서 제거하려는 특정 필드에 사용합니다 project-away . 혼동을 일으키거나 매우 크고 성능에 영향을 미칠 수 있는 경우가 아니면 결과 집합에서 정규화되지 않은 원래 필드를 제거하지 않는 것이 좋습니다. |
| 프로젝트 | 이전에 존재했거나 문의 일부로 만들어진 필드를 선택하고 다른 모든 필드를 제거합니다. | 파서가 정규화되지 않은 다른 필드를 제거해서는 안 하므로 파서에서 사용하지 않는 것이 좋습니다. 구문 분석 중에 사용되는 임시 값과 같은 특정 필드를 제거해야 하는 경우 를 사용하여 project-away 결과에서 제거합니다. |
예를 들어 사용자 지정 로그 테이블을 구문 분석할 때 다음을 사용하여 형식 설명자가 있는 나머지 원래 필드를 제거합니다.
| project-away
*_d, *_s, *_b, *_g
구문 분석 변형 처리
중요
다양한 변형은 일반적으로 다른 스키마에 매핑되는 다양한 이벤트 형식을 나타내며 별도의 파서를 개발합니다.
대부분의 경우 이벤트 스트림의 이벤트에는 다른 구문 분석 논리가 필요한 변형이 포함됩니다. 단일 파서에서 다른 변형을 구문 분석하려면 및 와 case같은 iff 조건문을 사용하거나 공용 구조체를 사용합니다.
를 사용하여 union 여러 변형을 처리하려면 각 변형에 대해 별도의 함수를 만들고 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…
중복 이벤트 및 과도한 처리를 방지하려면 각 함수가 필터링하여 시작되고 네이티브 필드를 사용하여 구문 분석하려는 이벤트만 사용해야 합니다. 또한 필요한 경우 각 분기에서 공용 구조체 앞에 프로젝트 어웨이를 사용합니다.
파서 배포
Azure 모니터 로그 페이지에 복사하고 쿼리를 함수로 저장하여 파서를 수동으로 배포합니다. 이 메서드는 테스트에 유용합니다. 자세한 내용은 함수 만들기를 참조하세요.
많은 수의 파서를 배포하려면 다음과 같이 파서 ARM 템플릿을 사용하는 것이 좋습니다.
각 스키마에 대한 관련 템플릿을 기반으로 YAML 파일을 만들고 쿼리를 포함합니다. 스키마 및 파서 형식, 필터링 또는 매개 변수 없는 항목과 관련된 YAML 템플릿 으로 시작합니다.
ASIM YAML에서 ARM 템플릿 변환기를 사용하여 YAML 파일을 ARM 템플릿으로 변환합니다.
업데이트를 배포하는 경우 포털 또는 함수 삭제 PowerShell 도구를 사용하여 이전 버전의 함수를 삭제합니다.
Azure Portal 또는 PowerShell을 사용하여 템플릿을 배포합니다.
연결된 템플릿을 사용하여 여러 템플릿을 단일 배포 프로세스에 결합할 수도 있습니다.
팁
ARM 템플릿은 다양한 리소스를 결합할 수 있으므로 몇 가지 유용한 옵션의 이름을 지정하기 위해 커넥터, 분석 규칙 또는 관심 목록과 함께 파서를 배포할 수 있습니다. 예를 들어 파서는 함께 배포된 관심 목록을 참조할 수 있습니다.
테스트 파서
이 섹션에서는 테스트 도구 ASIM이 파서를 테스트할 수 있도록 제공하는 것을 설명합니다. 즉, 파서는 코드이고, 때로는 복잡하며, 자동화된 테스트 외에도 코드 검토와 같은 표준 품질 보증 사례를 권장합니다.
ASIM 테스트 도구 설치
ASIM을 테스트하려면 다음과 같은 Microsoft Sentinel 작업 영역에 ASIM 테스트 도구를 배포합니다.
- 파서가 배포됩니다.
- 파서에서 사용하는 원본 테이블을 사용할 수 있습니다.
- 파서에서 사용하는 원본 테이블은 다양한 관련 이벤트 컬렉션으로 채워집니다.
출력 스키마 유효성 검사
파서가 유효한 스키마를 생성하도록 하려면 Microsoft Sentinel 로그 페이지에서 다음 쿼리를 실행하여 ASIM 스키마 테스터를 사용합니다.
<parser name> | getschema | invoke ASimSchemaTester('<schema>')
다음과 같이 결과를 처리합니다.
| 오류 | 작업 |
|---|---|
| 필수 필드 누락 [<필드>] | 필드를 파서에 추가합니다. 대부분의 경우 원본에서 이미 사용할 수 있는 필드가 아닌 파생 값 또는 상수 값이 됩니다. |
| 필수 열 [<Field>]가 있는 경우 누락된 필드 [<필드>]가 필수입니다. | 필드를 파서에 추가합니다. 대부분의 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다. |
| 열 [<Field>]가 있는 경우 필드 [<필드>]가 필수입니다. | 필드를 파서에 추가합니다. 대부분의 경우 이 필드는 참조하는 기존 열의 형식을 나타냅니다. |
| 기존 열에 대한 필수 별칭 [<Field>] 별칭 누락 [<필드>] | 파서에 별칭 추가 |
| 기존 열에 권장되는 별칭 [<필드>] 별칭이 없습니다. [<필드>] | 파서에 별칭 추가 |
| 선택적 별칭 누락 [<필드>] 기존 열 별칭 [<필드>] | 파서에 별칭 추가 |
| 누락된 필수 별칭 [<필드>] 별칭 누락 열 [<필드>] | 이 오류는 별칭이 지정된 필드에 대해 유사한 오류를 수반합니다. 별칭 필드 오류를 수정하고 이 별칭을 파서에 추가합니다. |
| 필드 [<필드>]에 대한 형식 불일치입니다. 현재 [<형식>]이며 [<형식>]이어야 합니다. | 일반적으로 와 같은 tostring변환 함수를 사용하여 정규화된 필드의 형식이 올바른지 확인합니다. |
| 정보 | 작업 |
|---|---|
| 권장 필드 누락 [<필드>] | 파서에 이 필드를 추가하는 것이 좋습니다. |
| 정보 | 작업 |
|---|---|
| 누락된 권장 별칭 [<필드>] 존재하지 않는 열 별칭 [<필드>] | 별칭 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다. |
| 선택적 별칭 누락 [<필드>] 존재하지 않는 열 별칭 [<필드>] | 별칭 필드를 파서에 추가하는 경우 이 별칭도 추가해야 합니다. |
| 선택적 필드 누락 [<필드>] | 선택적 필드가 누락되는 경우가 많지만 목록을 검토하여 원본에서 선택적 필드를 매핑할 수 있는지 확인하는 것이 좋습니다. |
| 정규화되지 않은 추가 필드 [<필드>] | 정규화되지 않은 필드는 유효하지만 목록을 검토하여 정규화되지 않은 값을 선택적 필드에 매핑할 수 있는지 확인하는 것이 좋습니다. |
참고
오류로 인해 파서 사용 콘텐츠가 제대로 작동하지 않습니다. 경고는 콘텐츠가 작동하는 것을 방지하지는 않지만 결과의 품질을 저하시킬 수 있습니다.
출력 값 유효성 검사
파서가 유효한 값을 생성하도록 하려면 Microsoft Sentinel 로그 페이지에서 다음 쿼리를 실행하여 ASIM 데이터 테스터를 사용합니다.
<parser name> | limit <X> | invoke ASimDataTester ('<schema>')
스키마 지정은 선택 사항입니다. 스키마를 지정 EventSchema 하지 않으면 필드는 이벤트가 준수해야 하는 스키마를 식별하는 데 사용됩니다. 이벤트에 필드가 EventSchema 없는 경우 공통 필드만 확인됩니다. 스키마가 매개 변수로 지정된 경우 이 스키마는 모든 레코드를 테스트하는 데 사용됩니다. 이는 필드를 설정하지 않은 이전 파서에 EventSchema 유용합니다.
참고
스키마를 지정하지 않은 경우에도 함수 이름 다음에 빈 괄호가 필요합니다.
이 테스트는 리소스를 많이 사용하며 전체 데이터 집합에서 작동하지 않을 수 있습니다. X를 쿼리 시간이 초과되지 않는 가장 큰 숫자로 설정하거나 시간 범위 선택기를 사용하여 쿼리의 시간 범위를 설정합니다.
다음과 같이 결과를 처리합니다.
| 메시지 | 작업 |
|---|---|
| (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 파일(
허용된 경고 문서화
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로 내보내기 옵션을 사용하여 결과를 , Where
EventProduct,EventProduct및EventSchema라는<EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv파일로 내보냅니다. 파서가 해당 필드에 할당한 값입니다.Logs화면에서 스키마 또는 파서 입력 테이블을 출력하는 쿼리를 실행합니다. 예를 들어 동일한 Infoblox DNS 파서의 경우 쿼리는 다음과 같습니다.
Syslog
| getschema
CSV로 내보내기 옵션을 사용하여 결과를 라는
<TableName>_schema.csv파일로 내보냅니다. 여기서TableName는 파서가 사용하는 원본 테이블의 이름입니다.PR의 두 파일을 폴더
/Sample Data/ASIM에 포함합니다. 파일이 이미 있는 경우 이름에 GitHub 핸들을 추가합니다. 예를 들면 다음과 같습니다.<EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv
테스트 결과 제출 지침
테스트 결과는 파서의 정확성을 확인하고 보고된 예외를 이해하는 데 중요합니다.
테스트 결과를 제출하려면 다음 단계를 사용합니다.
파서 테스트를 실행하고 테스트 섹션에 설명 되어 있습니다 .
및 는 CSV로 내보내기 옵션을 사용하여 각각 및
<EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv라는<EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv파일에 테스트 결과를 내보냅니다.PR의 두 파일을 폴더
/Parsers/ASim<schema>/Tests에 포함합니다.
다음 단계
이 문서에서는 ASIM 파서 개발에 대해 설명합니다.
ASIM 파서에 대해 자세히 알아보세요.
일반적으로 ASIM에 대해 자세히 알아보세요.