Leonard Chvilicek

Business Context Feed:  Taxonomy

Blog Post created by Leonard Chvilicek Employee on Sep 25, 2020

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

Name Length

You are limited to 16 characters (including the "." dot delimiter)  - use lowercase only for the name and values.

 

Allowed Characters

Only alpha numeric values are allowed, except for the "." delimiter.

 

Name Construction

Metakey names should follow the Unified Data Model (UDM) "3 Logical Parts" and should not conflict with any current RSA keys.


Metakey concept image

Value Format

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.

 

Multivalued Field

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

Concept

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.

 

Context

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

 

Sub-Context 

The sub-context is the most specific, the specific sub-context values are shown below:

Description

Sub Context Abbreviation
Criticalitycrit
Categorycat
Rolerole
Hostnamehost
Datedate
Locationloc

 

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.

Metakey NameDescription
hnl.asset.critNumeric "Criticality" rating of the asset.
hnl.asset.cat"Category" of the asset
hnl.asset.role"Role" of the asset
hnl.asset.host"Hostname" of the asset
hnl.asset.date"Date" the asset was added to the feed
hnl.asset.loc"Location" of the asset

 

Metakey Value Format

Define whether this metakey value will be text or an integer.

MetakeyValue FormatStore Multiple Values
hnl.asset.critUInt8No
hnl.asset.catTextYes
hnl.asset.role

Text

Yes

hnl.asset.hostText

No

hnl.asset.dateUInt32No
hnl.asset.locTextNo

 

Metakey Values

hnl.asset.crit

This metakey identifies the criticality of the system.  The table below lists the possible values and describes the values to use in the metakey.

Metakey Value

Description

1Extremely Critical
2Highly Critical
3

Moderately Critical

4Low


hnl.asset.cat

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.

Metakey Value

Description

authenticationSystems that provide authentication services, like domain controllers, LDAP servers, RADIUS, SecurID, TACACS, etc.
firewallSystems that provide firewall services.
scanner

Systems that perform scanning activities like a port/vulnerability scanner or pen test

networkNetwork Infrastructure

 

hnl.asset.role

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.

Category

Description

Value

authenticationMicrosoft Active Directorydomain controller
authenticationRADIUS Serverradius server
authenticationSecurID Serversecurid server
firewallFirewall operating in the ecommerce DMZecommerce dmz
firewallInternal firewall for secure hostingsecure hosting
firewallInternet Perimeter Firewallinternet perimeter
scannerVulnerability Scannervulnerability
scannerPenetration testingpentest
networkCore network router

core router

networkCore network switchcore switch

 

hnl.asset.host

This metakey has the short hostname in lowercase

 

hnl.asset.date

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.

 

hnl.asset.loc

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.

Metakey Value

Description

hqdc-01Headquarters Data Center 1
lvdc-02Leonardville Data Center 2
mscwdc-03

Moscow Data Center 3

raddc-04Radium Data Center 4

 

Sample Business Context Feed Using Taxonomy

User Friendly Version:

#indexhnl.asset.crithnl.asset.cathnl.asset.rolehnl.asset.hosthnl.asset.datehnl.asset.loc
10.0.0.11firewallperimeterhnlhqfw-0120200708hqdc-01
192.168.1.11firewallsecure hostinghnlshfw-0220200708hqdc-01
192.168.63.1001authenticationdomain controllerhnraddc-0120200708raddc-04
192.168.1.871authenticationdomain controllerhnlvdc-0220200708lvdc-02
192.168.50.1001authenticationdomain controllerhnmscwdc-0320200708mscwdc-03
10.0.0.161networkcore switchhnlcsw-0120200708hqdc-01

 

CSV File format for Feed Consumption:

#index,hnl.asset.crit,hnl.asset.cat,hnl.asset.role,hnl.asset.host,hnl.asset.date,hnl.asset.loc
10.0.0.1,1,firewall,perimeter,hnlhqfw-01,20200708,hqdc-01
192.168.1.1,1,firewall,secure hosting,hnlshfw-02,20200708,hqdc-01
192.168.63.100,1,authentication,domain controller,hnraddc-01,20200708,raddc-04
192.168.1.87,1,authentication,domain controller,hnlvdc-02,20200708,lvdc-02
192.168.50.100,1,authentication,domain controller,hnmscwdc-03,20200708,mscwdc-03
10.0.0.16,1,network,core switch,hnlcsw-01,20200708,hqdc-01

 

Customizing Index

Now that the metakey names and values have been established they can be added to the necessary index custom files so that they are available to the analyst in Investigate.

 

Log/Network Decoders

There are two metakeys that are defined as integers, so we need to tell the Log or Network Decoder that these metakeys are to be formatted as integers.

The following custom index files need to be modified with the entries below:

index-logdecoder-custom.xml (Log Decoder)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet Lab Custom metakeys *** -->
<key description="HNL Asset Criticality" name="hnl.asset.crit" format="UInt8" level="IndexNone"/>
<key description="HNL Asset Date" name="hnl.asset.date" format="UInt32" level="IndexNone"/>

index-decoder-custom.xml (Network Decoder)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet Lab Custom metakeys *** -->
<key description="HNL Asset Criticality" name="hnl.asset.crit" singleton="true" format="UInt8" level="IndexNone"/>
<key description="HNL Asset Date" name="hnl.asset.date" singleton="true" format="UInt32" level="IndexNone"/>

Concentrators

All of the custom meta keys will need to be added to the Concentrator to be available in Investigate for the Analysts.

The following custom index file need to be modified with the entries below.

index-concentrator-custom.xml (Concentrator)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet custom index keys added to provide additional information from feeds *** -->

<key description="HNL Asset Criticality" name="hnl.asset.crit" singleton="true" format="UInt8" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Category" name="hnl.asset.cat" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Role" name="hnl.asset.role" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Hostname" name="hnl.asset.host" singleton="true" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Date Added" name="hnl.asset.date" singleton="true" format="UInt32" level="IndexValues" valueMax="100"/>
<key description="HNL Asset Location" name="hnl.asset.loc" singleton="true" format="Text" level="IndexValues" valueMax="50"/>

 

Now you have more information than just an IP address to look at thanks to the Taxonomy and a Business Context Feed.

 

Outcomes