Merge pull request #312621 from yummyblabla/derricklee/introduce-asset-schema

[Sentinel] [ASIM] Add asset schema doc

Author: Stacyrch140

articles/sentinel/TOC.yml

@@ -982,6 +982,8 @@
           items:
             - name: ASIM alert event schema
               href: normalization-schema-alert.md
+            - name: ASIM asset entity schema
+              href: normalization-schema-asset.md
             - name: ASIM audit event schema
               href: normalization-schema-audit.md
             - name: ASIM authentication schema

articles/sentinel/normalization-about-parsers.md

@@ -40,6 +40,7 @@ The following table lists the available unifying parsers:
 | Schema | Unifying parser | 
 | ------ | ------------------------- |
 | Alert Event | _Im_AlertEvent |
+| Asset Entity | _Im_AssetEntity |
 | Audit Event | _Im_AuditEvent |
 | Authentication | _Im_Authentication | 
 | DHCP Event | _Im_DhcpEvent |

articles/sentinel/normalization-about-schemas.md

@@ -13,11 +13,13 @@ ms.author: ofshezaf
 
 # Advanced Security Information Model (ASIM) schemas
 
-An Advanced Security Information Model ([ASIM](normalization.md)) schema is a set of fields that represent an activity. Using the fields from a normalized schema in a query ensures that the query will work with every normalized source.
+An Advanced Security Information Model ([ASIM](normalization.md)) schema is a set of fields that represent an activity or entity. Using the fields from a normalized schema in a query ensures that the query will work with every normalized source.
 
 To understand how schemas fit within the ASIM architecture, refer to the [ASIM architecture diagram](normalization.md#asim-components).
 
-Schema references outline the fields that comprise each schema. ASIM currently defines the following schemas:
+## Activity/Event Schemas
+
+Schema references outline the fields that comprise each schema. ASIM currently defines the following schemas for events:
 
 | Schema | Version | Status |
 | ------ | ------- | ------ |
@@ -33,13 +35,21 @@ Schema references outline the fields that comprise each schema. ASIM currently d
 | [User Management](normalization-schema-user-management.md) | 0.1.2 | GA |
 | [Web Session](normalization-schema-web.md) | 0.2.7 | GA |
 
+## Entity Schemas
+
+ASIM currently defines the following schemas for entities:
+
+| Schema | Version | Status |
+| ------ | ------- | ------ |
+| [Asset Entity](normalization-schema-asset.md) | 0.1.0 | GA |
+
 ## Field naming
 
 At the core of each schema are its field names. Field names belong to the following groups:
 
 - Fields common to all schemas.
 - Fields specific to a schema.
-- Fields that represent entities, such as users, which take part in the schema. Fields that represent entities [are similar across schemas](#entities).
+- Fields that represent entities, such as users, which take part in the schema. Fields that represent entities [are similar across schemas](#event-entities).
 
 When sources have fields that aren't presented in the documented schema, they're normalized to maintain consistency. If the extra fields represent an entity, they'll be normalized based on the entity field guidelines. Otherwise, the schemas strive to keep consistency across all schemas.<br><br> For example, while DNS server activity logs don't provide user information, DNS activity logs from an endpoint might include user information, which can be normalized according to the user entity guidelines.
 
@@ -57,11 +67,11 @@ Fields might have several classes, which define when the fields should be implem
 - **Conditional** fields are mandatory if the field they follow is populated. Conditional fields are typically used to describe the value in another field. For example, the common field [DvcIdType](normalization-common-fields.md#dvcidtype) describes the value int the common field [DvcId](normalization-common-fields.md#dvcid) and is therefore mandatory if the latter is populated.
 - **Alias** is a special type of a conditional field, and is mandatory if the aliased field is populated.
 
-## Entities
+## Event Entities
 
 Events evolve around entities, such as users, hosts, processes, or files. Each entity might require several fields to describe it. For example, a host might have a name and an IP address.
 
-A single record might include multiple entities of the same type, such as both a source and destination host. <br><br>ASIM defines how to describe entities consistently, and entities allow for extending the schemas. <br><br>For example, while the Network Session schema doesn't include process information, some event sources do provide process information that can be added. For more information, see [Entities](#entities). 
+A single record might include multiple entities of the same type, such as both a source and destination host. <br><br>ASIM defines how to describe entities consistently, and entities allow for extending the schemas. <br><br>For example, while the Network Session schema doesn't include process information, some event sources do provide process information that can be added. For more information, see [Entities](#event-entities). 
 
 To enable entity functionality, entity representation has the following guidelines:
 

articles/sentinel/normalization-develop-parsers.md

@@ -262,7 +262,7 @@ Microsoft Sentinel provides handy functions for common lookup values. For exampl
 | invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')
 ```
 
-The first option accepts as a parameter the value to lookup and let you choose the output field and therefore useful as a general lookup function. The second option is more geared towards parsers, takes as input the name of the source field, and updates the needed ASIM field, in this case `DnsResponseCodeName`.
+The first option accepts as a parameter the value to look up and let you choose the output field and therefore useful as a general lookup function. The second option is more geared towards parsers, takes as input the name of the source field, and updates the needed ASIM field, in this case `DnsResponseCodeName`.
 
 For a full list of ASIM help functions, refer to [ASIM functions](normalization-functions.md)
 
@@ -280,7 +280,7 @@ In addition to the fields available from the source, a resulting ASIM event incl
      EventSchema = 'ProcessEvent'
 ```
 
-Another type of enrichment fields that your parsers should set are type fields, which designate the type of the value stored in a related field. For example, the `SrcUsernameType` field designates the type of value stored in the `SrcUsername` field. You can find more information about type fields in the [entities description](normalization-about-schemas.md#entities).
+Another type of enrichment fields that your parsers should set are type fields, which designate the type of the value stored in a related field. For example, the `SrcUsernameType` field designates the type of value stored in the `SrcUsername` field. You can find more information about type fields in the [entities description](normalization-about-schemas.md#event-entities).
 
 In most cases, types are also assigned a constant value. However, in some cases the type has to be determined based on the actual value, for example:
 
@@ -327,7 +327,7 @@ For example, when parsing a custom log table, use the following to remove the re
 >[!IMPORTANT]
 > The different variants represent *different* event types, commonly mapped to different schemas, develop separate parsers
 
-In many cases, events in an event stream include variants that require different parsing logic. To parse different variants in a single parser either use conditional statements such as `iff` and `case`, or use a union structure.
+In many cases, events in an eventstream include variants that require different parsing logic. To parse different variants in a single parser either use conditional statements such as `iff` and `case`, or use a union structure.
 
 To use `union` to handle multiple variants, create a separate function for each variant and use the union statement to combine the results:
 
@@ -430,7 +430,7 @@ To make sure that your parser produces valid values, use the ASIM data tester by
   <parser name> | limit <X> | invoke ASimDataTester ('<schema>')
   ```
 
-Specifying a schema is optional. If a schema is not specified, the `EventSchema` field is used to identify the schema the event should adhere to. Ig an event does not include an `EventSchema` field, only common fields will be verified. If a schema is specified as a parameter, this schema will be used to test all records. This is useful for older parsers that do not set the `EventSchema` field. 
+Specifying a schema is optional. If a schema is not specified, the `EventSchema` field is used to identify the schema the event should adhere to. If an event does not include an `EventSchema` field, only common fields will be verified. If a schema is specified as a parameter, this schema will be used to test all records. This is useful for older parsers that do not set the `EventSchema` field. 
 
 > [!NOTE]
 > Even when a schema is not specified, empty parentheses are needed after the function name.