This topic provides the procedures for configuring data obfuscation in NetWitness Platform. In a single deployment, all Core service configurations for a data privacy solution must be the same; be sure to use the same hash and salt across all Decoders and Log Decoders.
Configure the Decoder Hash Algorithm and Salt
Value hashing accomplished as part of the data privacy solution occurs at the time of meta key creation on the Decoder and Log Decoder. Both services have default settings for use with all meta keys whose values are transformed without a specified hash algorithm type or salt value. The initial NetWitness Platform values for defaults are: hash algorithm (SHA-256) and salt (none).
If you want to change the default settings, you can edit them in the Services Config view > Data Privacy tab or in the following nodes in the NetWitness Platform Services Explorer view:
The algorithm to use for any keys with a transform defined that does not specify type. The supported algorithms are: duplicate and sha-256.
The salt value prepended to any value that is hashed (sha-256). This value is optional, an empty salt is valid and produces an unsalted hash. The salt is not defined by default so that you can create a unique salt for your environment. In general, the longer and more complex the salt, the better the security. A salt of up to 60 characters can be used without any major impact. A salt of at least 16 characters is recommended.
To edit the default hash algorithm and salt:
- Go to Admin > Services.
- In the Configure Hash Algorithm and Salt section, select a Hash Algorithm to use for any meta keys with a defined transform that does not specify type: sha-256. (A second algorithm, duplicate, is available for administrators to use in validating that expected hashing behavior is occurring in the network.)
- (Optional) In the Salt field, enter a salt value to be prepended to any value that is hashed. This value is optional, an empty salt is valid and produces an unsalted hash. The salt is not defined by default so that you can create a unique salt for your environment. In general, the longer and more complex the salt, the better the security. Best practices for security purposes dictate a salt value that is no less than 100 bits or 16 characters in length. If a unique salt is required for each individual meta key, that needs to be configured in the index file as shown in example 3 below.
The new settings become effective immediately.
Configure Language Keys
The NetWitness Platform Core Language has several language key attributes to facilitate data privacy. You can edit these attributes in the custom index file for each Decoder or Log Decoder. The custom index file (for example, index-decoder-custom.xml) is editable in the Services Configuration view > Files tab. After making changes in the index file, like the ones shown in the examples below, a service restart in a specific sequence is required.
Based on the data privacy requirements for your site, configure individual meta keys to be protected using the following
This attribute specifies that NetWitness Platform should consider the values as protected and tightly control any release of the value. When propagating the protected attribute, NetWitness Platform ensures that any downstream trusted system treats the values accordingly. Add this attribute to all services that create the protected values (that is, Decoder or Log Decoder) and any services that will provide trusted access (software development kit (SDK) query/values, aggregation) outside of Core services. The exception to this rule is that a Broker with no index file specified does not need to have the attribute added.
This attribute specifies that values for this key are stand-ins for another value and may not be visually interesting. The
tokenattribute is informational, primarily for UI elements to display the value in a more useful or visually pleasing format.
This child element of
keyindicates that any values for a given meta key should be transformed and the resulting value persisted in another meta key. The
transformelement is only required on Decoders and Log Decoders and is informational if specified on any other Core services. The
transformelement has the following attributes and children:
On a Decoder or Log Decoder, mark
username as protected and hash all values into
username.hash with the default algorithm and salt:
<key name="username" description="Username" format="Text" protected="true">
On a Concentrator, mark username as protected and username.hash as token:
<?xml version="1.0" encoding="utf-8"?> <language level="IndexNone" defaultAction="Auto">
<key description="Username" format="Text" level="IndexValues" name="username" protected="true"/>
<key description="Username Hash" format="Binary" level="IndexValues" name="username.hash"
On a Decoder or Log Decoder, mark username as protected and hash all values into username.bin with the specified algorithm and salt:
<key name="username" description="Username" format="Text" protected="true">
<transform destination="username.bin" type="sha-256">
param name="salt">0000</param> </transform></key>
Configure Metadata and Content Visibility Per User Role on Core Services
On individual Broker, Concentrator, Decoder, Log Decoder, and Archiver services being viewed in the Services Security view, administrators can configure the visibility of metadata and content based on the user group or role assigned to a user. This is called the SDK meta roles capability, and it is enabled by default. Administrators who want to configure metadata and content visibility per user must not disable the sdk.content permission (in the Roles tab). If the sdk.content permission has been disabled in the Roles tab, packets and raw logs are not visible to system.roles node. The system.roles node handles the filtering using the method configured in the Settings tab.
With sdk.content capability enabled, the next step is to select the method of filtering metadata and content in the Settings tab. Selecting a blacklist or whitelist option makes additional permissions for specific meta keys available in the Roles tab. The result is that administrators can choose a user role, such as analyst, in the Roles tab and select specific meta keys (and content) to be blacklisted or whitelisted for that user group. The permissions apply to any user in the user group.
The following table lists the options for filtering in the Settings tab and the numeric values used to disable (0) and the types of filtering (1 through 6). There is no need to know the numeric value unless configuring metadata and content visibility manually in the system.roles node.
Three factors determine what a user sees:
- The SDK meta role setting (blacklist or whitelist).
- The restricted meta keys configured for the group to which the user belongs.
- The meta keys in the session being analyzed.
Here is an example of how the SDK meta role configuration meshes with a Group that has restricted meta keys.
- The SDK meta role setting is Blacklist meta and content. With this option implemented, all metadata and all content (packets and logs) are visible by default.
- The administrator has restricted meta keys configured for the Analysts group to prevent viewing of sensitive data (for example,
- The packets and logs for any session that includes the username meta key are not visible to an analyst.
Result: Now a user who is a member of the Analyst Group investigates a session. Depending on the content of the session, the results are different:
- Session 1 includes the following meta keys: ip, eth, host, and file The session does not include username so all packets and logs in the session are displayed.
- Session 2 includes the following meta keys, ip, time, size, file, and username, Because the session includes username , no packets or logs from the session are displayed for the analyst.
To configure metadata and content restrictions for a Decoder or Log Decoder:
- Go to ADMIN > Services.
In the Services view, select a Broker, Concentrator, Decoder, Log Decoder, or Archiver service and select > View > Security. Click the Roles tab, select a role, and verify that the sdk.content role is enabled.
Click the Settings tab.
Select one of the filtering methods (blacklist or whitelist) and content types (meta and content, meta only, or content only), and click Apply.
Click the Roles tab and a role for which you want to allow content (whitelist) or block content (blacklist) as specified in the SDK Meta Role Permissions setting.
The Role Permissions for the selected role are displayed, and the SDK Meta Role Permissions are available for selection, for example, sdk.meta.action. If you selected one of the whitelist options in the SDK Role Permissions setting, you must assign each SDK meta role to make the selected content visible to users assigned that SDK meta role. If you selected one of the blacklist options in the SDK Role Permissions setting, selected content will be hidden from users assigned that SDK meta role.
- Select the SDK meta role permissions for users assigned this role. Click Apply.
The settings become effective immediately and apply to new packets and logs processed by the Decoder or Log Decoder.
Configure Meta Keys Not Written to Disk Per Parser on a Decoder
On a Decoder and Log Decoder, a Data Privacy Officer can configure individual meta keys that are not written to disk. To do so, the DPO specifies the meta keys as transient in the index and the parser configuration.
To configure selected meta keys on individual parsers that will not written to disk:
- Go to ADMIN > Services.
- In the Services view, select a Decoder or Log Decoder service and select > View > Config.
In the Parsers Configuration section of the General tab, select a parser and then select Transient in the Config Value drop-down list. Access the list by clicking on the configuration value (Enabled, Disabled, or Transient).
The configuration change is marked by a red triangle.
The change is effective immediately. The parser configured as Transient will no longer store meta keys to disk.