NetWitness 11.x Type and Pattern Validation for Variables

Issue

>sans-serif;>

sans-serif;>The elements must be the child elements of the element. Hence

Tasks

sans-serif;>Valid email address (11.2.1 and later versions) all captures are ignored.

the value will be inherited from the parent . Refer the following screenshot.

Note: The attribute requireMatch is added in 11.3 and later versions.
When multiple format types are provided
timeline Description automatically generated src=https://netwitness.file.force.com/servlet/rtaImage?eid=ka0Rm0000004BLS&feoid=00N5Y00000TPmRL&refid=0EM4z0000050ox7 style=width: 624px;height: 114px;>
sans-serif;> insans-serif;>Type variables are applied on a per parser basis. Thus

Cause

>sans-serif;>In the above example
so long as they meet the hierarchy requirements.

Workaround

>transformation is achieved by mapping the static value ‘http’ to variable ‘protocol’ for port ‘80’.
sans-serif;>Where should elements be placed?

Resolution

Typed variables (also called as VARTYPE) added in 11.0 and later versions, provide type and pattern validation for variables. While the variables are parsed, you can conditionalize them to match a certain format. For Example, consider the following parser

Using VARTYPE, you can define the username variable to contain only characters and numbers, and fail the MESSAGE pattern match. In this case, username is a typed variable.

As shown in the above example, the variable name is specified using the name attribute. The regular expression defines the criteria that username must meet the specific condition ( [a-z0-9]+). If 192.168.1.1 is found where the username variable resides in a pattern, the pattern will not match.
Note: In 11.2.1, typed variables allow the capture of parsed values to other variables.

Typed Variables Formats

1. regex

This functionality uses the standard regular expression syntax. Use the ignorecase attribute to toggle the case sensitivity. By default, regular expressions are case sensitive. Hence, the below two statements are identical.

Note: The ignorecase attribute is optional.
In 11.5, enable regex search (instead of match) using the search attribute. By default, this attribute is set to false, resulting in regex match. Match requires the entire input to match the expression. Refer the following screenshot.

2. dateTime

The dateTime format was added in 11.5 and later versions. It includes a list of format specifiers for parsing timestamps. Refer the following screenshot.

3. format

You can set the criteria for a typed variable using the format attribute as well. The value of the attribute for the respective variables are predefined types that define the type the variables must have for a match to happen. For example, you can define the variable hostIP as a typed variable, if some log messages are incorrectly assigning it a value of hostname.com instead of valid IPs. Refer the following screenshot.

In this case, only IPs of the format XXX.XXX.XXX.XX will match and not the value of hostname.com.
The below table lists all the valid types of formats.

Column 1: Format
Column 2: Description
Column 3: Example

Column 1: Base64
Column 2: Base 64 encoded text (11.4 and later versions)
Column 3: SGVsbG8gd29ybGQhIQ== (Hello world!!).

Column 1: Float32
Column 2: Decimal numbers
Column 3: 2.71818

Column 1: Float64
Column 2: Decimal numbers
Column 3: 2.71818

Column 1: HexString
Column 2: Hex Encoded Text (11.3 and later versions)
Column 3: 48656C6C6F20776F726C642121 (Hello world!!).

Column 1: IPv4
Column 2: ipv4
Column 3: 192.168.1.1

Column 1: IPv6
Column 2: ipv6
Column 3: 2607:f0d0:1002:51::4

Column 1: MAC
Column 2: Physical Mac address
Column 3: 01:23:45:67:89:ab

Column 1: Hostname
Column 2: RFC-1123 compliant hostname (11.2.1 and later versions)
Column 3: abc.xzy.com

Column 1: Int8
Column 2: Signed 8-bit integer
Column 3: -128 to 127

Column 1: Int16
Column 2: Signed 16-bit integer
Column 3: -32768 to 32767

Column 1: Int32
Column 2: Signed 32-bit integer
Column 3: -2147483648 to 2147483647

Column 1: Int64
Column 2: Signed 64-bit integer
Column 3: -9223372036854775808 to 9223372036854775807

Column 1: URI
Column 2: Universal Resource identifier (11.2.1 and later versions)
Column 3: http://www.google.com/path/script?query=param

Column 1: UInt8
Column 2: Unsigned 8-bit integer
Column 3: 0 to 255

Column 1: UInt16
Column 2: Unsigned 16-bit integer
Column 3: 0 to 65535

Column 1: UInt32
Column 2: Unsigned 32-bit integer
Column 3: 0 to 4294967295

Column 1: UInt64
Column 2: precedence order is followed and the last format type processed wins out on requiring a match.
Note: Typed Variable processing support for TagVal messages was added in 11.3.

When multiple format types are provided
variables of the same name can have different defined types across multiple parsers and the type criteria is applied only to patterns in that parser.

Column 1:
Notes
sans-serif;>TimeDuration
Column 2: sans-serif;>Example for Normalization:
sans-serif;>event.cat.name

Column 1:>
Internal Comments
sans-serif;>Format type to convert captured time values into a duration.
Column 2:>sans-serif;>out
Column 3: they are siblings of the
and elements. It does not matter if the elements are placed before or after its siblings. It is even possible to have some before and after

Product Details
sans-serif;> Example for Categorization:
>sans-serif;>How do I view debug logging for typed variable evaluation?
Column 4:
Summary
sans-serif;> bob@company.com

Column 1: precedence order is followed and the last format type processed wins out on requiring a match.
Note: Typed Variable processing support for TagVal messages was added in 11.3.

sans-serif;>In the above example
sans-serif;>User.Activity.Successful Logins
Column 2:>
Approval Reviewer Queue
sans-serif;>VARTYPE name="timeduration" duration="%H:%T:%S">

Column 1:
normalization is achieved by tagging static values ‘logon’ and ‘logoff’ to variable ‘operation_id’ for log values ‘in/on’ and ‘out/off’ respectively.
sans-serif;>User.Activity.Logoff
Column 2:>