A business what? A Business Context Feed is a feed that provides context about systems or data that is present in NetWitness to aid the analyst in understanding more about the system or data they are examining. The Business Context Feed should answer some basic questions that always come up during the analysis.
What is this system? - Web Server, Domain Controller, Proxy Server, etc...
What does it do? - Authentication, Database/Application Server, Customer Portal, etc...
Would it be considered a Critical Asset?
A classic scenario would be for an IP address. If an analyst would like to know if the IP address of interest is a Domain Controller, they would need to obtain or identify all of the IP addresses of the Domain Controllers. Then a query must be constructed to determine if there is a match (ip.all= 10.1.22.36,10.1.22.37.14,10.16.4.3,10.8.48.89,... you get the idea). If there is any content such as reports or alerts that are developed for this use case the list of IP addresses would need to be in all of those as well. It can get complicated real quick once you start putting this list of IP's in content, especially when the addresses change periodically. Creating a Business Context Feed will simplify this use case by maintaining a single feed that is centrally managed. Updating the feed can even be automated in most cases. When the feed is applied to this use case the query gets simplified from (ip.all= 10.1.22.36,10.1.22.37.14,10.16.4.3,10.8.48.89,... you get the idea) to a query using a custom metakey hnl.asset.role='domain controller'.Now, it is not uncommon for an organization to create around a dozen custom metakeys in NetWitness for their own use to provide additional context for data that is collected in NetWitness. But not everyone takes the time to create a taxonomy document to set the standard on how the custom content will be defined and populated to provide consistency for other content that will be developed around it. Frankly, it is not advised to comingle custom meta values with the meta values that are created by NetWitness natively. This can create confusion on what the values "are" versus what they "should be", and can adversely affect other content that uses these standard keys. There are reserved metakeys that custom values do not belong, these can be identified in the Unified Data Model (UDM) as "Reserved" in the "Meta Class" column or in the "Notes" column (use "ctrl+f" in the browser). When creating custom content it is important to set standards on how the content is created, this includes naming conventions, spelling, formatting and values. This practice provides the necessary consistency for stable content development and performance. Another common issue is the custom content becomes knowledge exclusive to the author and can affect the time it takes to bring new people up to speed. Another factor is time, as the undocumented knowledge becomes stale to the author and often cannot recall the logic behind the naming, purpose, or value. The taxonomy document takes the burden off of the content author and provides a reference for all parties involved in creating, updating and consuming the content. Below is an example use case of the taxonomy to create custom metakeys and content to identify critical assets.
Creating Custom Metakeys - Things to Know
You are limited to 16 characters (including the "." dot delimiter) - use lowercase only for the name and values.
Only alpha numeric values are allowed, except for the "." delimiter.
You must decide what your metakey value it will store and define it in the appropriate custom index files if needed. The most commonly used formats are "Text" and "Integer". There are other formats but these are the most commonly used.
You will have to properly identify whether or not your metakey may contain multiple values in the same session. This is done in the index file with a singleton="true" in the concentrator custom index files. The reason for this is to have the ESA properly identify the field as a multivalued field (array) or a single valued field automatically.
Example Use Case: Creating Critical Asset Metakeys
The concept is the least specific part of the metakey name, typically used to group the metakeys, or in this case clearly identify the custom metakeys from the standard metakeys. The concept for these asset metakeys will be an abbreviation of my "Homenet Lab", it is not uncommon to use an abbreviated company name here. I will use "hnl" in this case.
The context is more specific and will typically define the "classification" of the key. A context name of "asset" will be used here as these keys are for identifying the critical assets
The sub-context is the most specific, the specific sub-context values are shown below:
Sub Context Abbreviation
General Description of the Metakeys
The table below contains the metakey names fully assembled with the "concept.context.sub-context" values applied, showing a general description of the custom metakeys.
Numeric "Criticality" rating of the asset.
"Category" of the asset
"Role" of the asset
"Hostname" of the asset
"Date" the asset was added to the feed
"Location" of the asset
Metakey Value Format
Define whether this metakey value will be text or an integer.
Store Multiple Values
This metakey identifies the criticality of the system. The table below lists the possible values and describes the values to use in the metakey.
This metakey identifies the category of the system. The table below lists the possible values and describes the values to use in this metakey. Note the values are always lowercase.
Systems that provide authentication services, like domain controllers, LDAP servers, RADIUS, SecurID, TACACS, etc.
Systems that provide firewall services.
Systems that perform scanning activities like a port/vulnerability scanner or pen test
This metakey identifies the role of the system. The table below lists the possible values grouped by category along with the descriptions of the values to use in this metakey. Note the values are always lowercase.
Microsoft Active Directory
Firewall operating in the ecommerce DMZ
Internal firewall for secure hosting
Internet Perimeter Firewall
Core network router
Core network switch
This metakey has the short hostname in lowercase
This metakey contains the numeric date the system was added to the feed in YYYYMMDD format. The date is used to determine the age of the entry and to also know that prior to this date there is no contextual meta generated.
This metakey identifies the location of the system. The table below lists the possible values and describes the values to use in this metakey. Note the values are always lowercase.