Skip to content

Commit 499adb0

Browse files
Merge pull request #312740 from yummyblabla/derricklee/add-schema-names-asim
[ASIM] Edits to normalization-about-schema page
2 parents 99ef4ab + 93a910e commit 499adb0

1 file changed

Lines changed: 24 additions & 24 deletions

File tree

articles/sentinel/normalization-about-schemas.md

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -13,35 +13,35 @@ ms.author: ofshezaf
1313

1414
# Advanced Security Information Model (ASIM) schemas
1515

16-
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.
16+
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 works with every normalized source.
1717

1818
To understand how schemas fit within the ASIM architecture, refer to the [ASIM architecture diagram](normalization.md#asim-components).
1919

2020
## Activity/Event Schemas
2121

2222
Schema references outline the fields that comprise each schema. ASIM currently defines the following schemas for events:
2323

24-
| Schema | Version | Status |
25-
| ------ | ------- | ------ |
26-
| [Alert Event](normalization-schema-alert.md) | 0.1 | GA |
27-
| [Audit Event](normalization-schema-audit.md) | 0.1.2 | GA |
28-
| [Authentication Event](normalization-schema-authentication.md) | 0.1.4 | GA |
29-
| [DNS Activity](normalization-schema-dns.md) | 0.1.7 | GA |
30-
| [DHCP Activity](normalization-schema-dhcp.md) | 0.1.1 | GA |
31-
| [File Activity](normalization-schema-file-event.md) | 0.2.2 | GA |
32-
| [Network Session](normalization-schema.md) | 0.2.7 | GA |
33-
| [Process Event](normalization-schema-process-event.md) | 0.1.4 | GA |
34-
| [Registry Event](normalization-schema-registry-event.md) | 0.1.3 | GA |
35-
| [User Management](normalization-schema-user-management.md) | 0.1.2 | GA |
36-
| [Web Session](normalization-schema-web.md) | 0.2.7 | GA |
24+
| Schema | Schema Name for Tests | Version | Status |
25+
| ------ | --------------------- | ------- | ------ |
26+
| [Alert Event](normalization-schema-alert.md) | `AlertEvent` | 0.1 | GA |
27+
| [Audit Event](normalization-schema-audit.md) | `AuditEvent` | 0.1.2 | GA |
28+
| [Authentication Event](normalization-schema-authentication.md) | `Authentication` | 0.1.4 | GA |
29+
| [DHCP Activity](normalization-schema-dhcp.md) | `DhcpEvent` | 0.1.1 | GA |
30+
| [DNS Activity](normalization-schema-dns.md) | `Dns` | 0.1.7 | GA |
31+
| [File Activity](normalization-schema-file-event.md) | `FileEvent` | 0.2.2 | GA |
32+
| [Network Session](normalization-schema.md) | `NetworkSession` | 0.2.7 | GA |
33+
| [Process Event](normalization-schema-process-event.md) | `ProcessEvent` | 0.1.4 | GA |
34+
| [Registry Event](normalization-schema-registry-event.md) | `RegistryEvent` | 0.1.3 | GA |
35+
| [User Management](normalization-schema-user-management.md) | `UserManagement` | 0.1.2 | GA |
36+
| [Web Session](normalization-schema-web.md) | `WebSession` | 0.2.7 | GA |
3737

3838
## Entity Schemas
3939

4040
ASIM currently defines the following schemas for entities:
4141

42-
| Schema | Version | Status |
43-
| ------ | ------- | ------ |
44-
| [Asset Entity](normalization-schema-asset.md) | 0.1.0 | GA |
42+
| Schema | Schema Name for Tests | Version | Status |
43+
| ------ | --------------------- | ------- | ------ |
44+
| [Asset Entity](normalization-schema-asset.md) | `AssetEntity` | 0.1.0 | GA |
4545

4646
## Field naming
4747

@@ -51,7 +51,7 @@ At the core of each schema are its field names. Field names belong to the follow
5151
- Fields specific to a schema.
5252
- Fields that represent entities, such as users, which take part in the schema. Fields that represent entities [are similar across schemas](#event-entities).
5353

54-
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.
54+
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're 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.
5555

5656
## Common fields
5757

@@ -61,7 +61,7 @@ Some fields are common to all ASIM schemas. Each schema might add guidelines for
6161

6262
Fields might have several classes, which define when the fields should be implemented by a parser:
6363

64-
- **Mandatory** fields must appear in every parser. If your source doesn't provide information for this value, or the data can't be otherwise added, it won't support most content items that reference the normalized schema.
64+
- **Mandatory** fields must appear in every parser. If your source doesn't provide information for this value, or the data can't be otherwise added, it does not support most content items that reference the normalized schema.
6565
- **Recommended** fields should be normalized if available. However, they might not be available in every source. Any content item that references that normalized schema should take availability into account.
6666
- **Optional** fields, if available, can be normalized or left in their original form. Typically, a minimal parser wouldn't normalize them for performance reasons.
6767
- **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.
@@ -81,7 +81,7 @@ To enable entity functionality, entity representation has the following guidelin
8181
|**Identifiers and types** | A normalized schema allows for several identifiers for each entity, which we expect to coexist in events. If the source event has other entity identifiers that can't be mapped to the normalized schema, keep them in the source form or use the **AdditionalFields** dynamic field. <br><br>To maintain the type information for the identifiers, store the type, when applicable, in a field with the same name and a suffix of **Type**. For example, **UserIdType**. |
8282
|**Attributes** | Entities often have other attributes that don't serve as an identifier and can also be qualified with a descriptor. For example, if the source user has domain information, the normalized field is **SrcUserDomain**. |
8383

84-
For more information about specific entity types refer to:
84+
For more information about specific entity types, refer to:
8585
- [User Entity](normalization-entity-user.md)
8686
- [Device Entity](normalization-entity-device.md)
8787
- [Application Entity](normalization-entity-application.md)
@@ -91,10 +91,10 @@ For more information about specific entity types refer to:
9191
Aliases allow multiple names for a specified value. In some cases, different users expect a field to have different names. For example, in DNS terminology, you might expect a field named [DnsQuery](normalization-schema-dns.md#query), while more generally, it holds a domain name. The alias [Domain](normalization-schema-dns.md#domain) helps the user by allowing the use of both names.
9292

9393
> [!NOTE]
94-
> Aliases are intended to help an analyst with interactive queries. When using queries in reusable content such asn custom detections, analytic rules or workbooks, use the aliased field rather than the alias. Using the aliased field ensures better performance, less errors and better query readability.
94+
> Aliases are intended to help an analyst with interactive queries. When using queries in reusable content such asn custom detections, analytic rules, or workbooks, use the aliased field rather than the alias. Using the aliased field ensures better performance, less errors and better query readability.
9595
>
9696

97-
In some cases, an alias can have the value of one of several fields, depending on which values are available in the event. For example, the [Dvc](normalization-common-fields.md#dvc) alias, aliases either the [DvcFQDN](normalization-common-fields.md#dvcfqdn), [DvcId](normalization-common-fields.md#dvcid), [DvcHostname](normalization-common-fields.md#dvchostname), or [DvcIpAddr](normalization-common-fields.md#dvcipaddr) , or [Event Product](normalization-common-fields.md#eventproduct) fields. When an alias can have several values, its type has to be a string to accommodate all possible aliased values. As a result, when assigning a value to such an alias, make sure to convert the type to string using the KQL function [tostring](/kusto/query/tostring-function?view=microsoft-sentinel&preserve-view=true).<br><br>[Native normalized tables](normalization-ingest-time.md#ingest-time-parsing) do not include aliases, as those would imply duplicate data storage. Instead the [stub parsers](normalization-ingest-time.md#combining-ingest-time-and-query-time-normalization) add the aliases. To implement aliases in parsers, create a copy of the original value by using the `extend` operator.
97+
In some cases, an alias can have the value of one of several fields, depending on which values are available in the event. For example, the [Dvc](normalization-common-fields.md#dvc) alias, aliases either the [DvcFQDN](normalization-common-fields.md#dvcfqdn), [DvcId](normalization-common-fields.md#dvcid), [DvcHostname](normalization-common-fields.md#dvchostname), or [DvcIpAddr](normalization-common-fields.md#dvcipaddr) , or [Event Product](normalization-common-fields.md#eventproduct) fields. When an alias can have several values, its type has to be a string to accommodate all possible aliased values. As a result, when assigning a value to such an alias, make sure to convert the type to string using the KQL function [tostring](/kusto/query/tostring-function?view=microsoft-sentinel&preserve-view=true).<br><br>[Native normalized tables](normalization-ingest-time.md#ingest-time-parsing) don't include aliases, as those would imply duplicate data storage. Instead the [stub parsers](normalization-ingest-time.md#combining-ingest-time-and-query-time-normalization) add the aliases. To implement aliases in parsers, create a copy of the original value by using the `extend` operator.
9898

9999

100100
## Logical types
@@ -109,10 +109,10 @@ Each schema field has a type. The Log Analytics workspace has a limited set of d
109109
|**MAC address** | String | Colon-Hexadecimal notation. |
110110
|**IP address** |String | Microsoft Sentinel schemas don't have separate IPv4 and IPv6 addresses. Any IP address field might include either an IPv4 address or an IPv6 address, as follows: <br><br>- **IPv4** in a dot-decimal notation.<br>- **IPv6** in 8-hextets notation, allowing for the short form.<br><br>For example:<br>- **IPv4**: `192.168.10.10` <br>- **IPv6**: `FEDC:BA98:7654:3210:FEDC:BA98:7654:3210`<br>- **IPv6 short form**: `1080::8:800:200C:417A` |
111111
|**FQDN** | String | A fully qualified domain name using a dot notation, for example, `learn.microsoft.com`. For more information, see [The Device entity](normalization-entity-device.md). |
112-
|<a name="hostname"></a>**Hostname** | String | A hostname which is not an FQDN, includes up to 63 characters including letters, numbers and hyphens. For more information, see [The Device entity](normalization-entity-device.md).|
112+
|<a name="hostname"></a>**Hostname** | String | A hostname that isn't an FQDN, includes up to 63 characters including letters, numbers, and hyphens. For more information, see [The Device entity](normalization-entity-device.md).|
113113
|**Domain** | String | the domain part of an FQDN, without the hostname, for example, `learn.microsoft.com`. For more information, see [The Device entity](normalization-entity-device.md). |
114114
| **DomainType** | Enumerated | The type of domain stored in domain and FQDN fields. For a list of values and more information, see [The Device entity](normalization-entity-device.md). |
115-
| **DvcIdType** | Enumerated | The type of the device ID stored in DvcId fields. For a list of allowed values and further information refer to [DvcIdType](normalization-entity-device.md#dvcidtype). |
115+
| **DvcIdType** | Enumerated | The type of the device ID stored in DvcId fields. For a list of allowed values and further information, refer to [DvcIdType](normalization-entity-device.md#dvcidtype). |
116116
|<a name="devicetype"></a>**DeviceType** | Enumerated | The type of the device stored in DeviceType fields. Possible values include:<br>- `Computer`<br>- `Mobile Device`<br>- `IOT Device`<br>- `Other`. For more information, see [The Device entity](normalization-entity-device.md). |
117117
|<a name="username"></a>**Username** | String | A valid username in one of the supported [types](#usernametype). For more information, see [The User entity](normalization-entity-user.md). |
118118
|<a name="usernametype"></a>**UsernameType** | Enumerated | The type of username stored in username fields. For more information and list of supported values, see [The User entity](normalization-entity-user.md). |

0 commit comments

Comments
 (0)