Data Privacy: Configure Data Obfuscation

Document created by RSA Information Design and Development on May 5, 2016
Version 1Show Document
  • View in full screen mode
 
  

This topic provides the procedures for configuring data obfuscation in Security Analytics. 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.

Prerequisite

In order for data obfuscation to work, user accounts need to be configured as described in Configure User Accounts for Use in Data Privacy.

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 Security Analytics values for defaults are: hash algorithm (SHA-256) and salt (none). 

Note: Security Analytics 10.4 and below supports the use of the SHA-1 hash algorithm for backwards compatibility. RSA does not recommend the use of the SHA-1 algorithm and it is not available in Security Analytics 10.5 and above.

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 Security Analytics Services Explorer view:

  • /decoder/parsers/transforms/default.type

    The algorithm to use for any keys with a transform defined that does not specify type.  The supported algorithms are: duplicate and sha-256.

  • /decoder/parsers/transforms/default.salt

    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:

  1. In the Security Analytics menu, select Administration > Services.
  2. In the Services grid, select a Decoder or Log Decoder service and  > View > Config and click the Data Privacy tab.

  3. 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.)
  4. (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. 
  5. Click Apply.

    The new settings become effective immediately. 

Configure Language Keys

In Security Analytics 10.5 the Security Analytics Core Language had several language key attributes added 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 key attributes:

  • protected

    This attribute specifies that Security Analytics should consider the values as protected and tightly control any release of the value. When propagating the protected attribute, Security Analytics 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 Security Analytics Core services. The exception to this rule is that a Broker with no index file specified does not need to have the attribute added. 

  • token

    This attribute specifies that values for this key are stand-ins for another value and may not be visually interesting. The token attribute is informational, primarily for UI elements to display the value in a more useful or visually pleasing format.

  • transform

    This child element of key indicates that any values for a given meta key should be transformed and the resulting value persisted in another meta key. The transform element is only required on Decoders and Log Decoders and is informational if specified on any other Core services.  The transform element has the following attributes and children:    

                             
NameTypeDescriptionOptional or Required
destination attributeSpecifies the key name where the transformed value will be persisted.required
type attributeThe transform algorithm to apply. If not specified, the value of /decoder/parsers/transforms/default.type is used.optional
param child-elementA name/value pair, where each param element has a required attribute name and the child text is the value. The only supported param is used to specify a key specific salt value. If not specified, the value of /decoder/parsers/transforms/default.salt is used.optional

Example 1

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"><transform destination="username.hash"/></key>

Example 2

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" token="true"/> </language>

Example 3

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 Meta and Content Visibility Per User Role on Core Services

User group access to meta and content is configurable for individual Broker, Concentrator, Decoder, Log Decoder, and Archiver services in the Services Security view. Administrators enable the SDK meta role capability and specify the type of meta role filtering in the Settings tab. Additional meta key role permissions become visible in the Roles tab, and they have the effect of black listing or white listing selected meta roles for specific groups.

The following table lists the options for filtering 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 meta and content visibility manually in the system.roles node.

                                                          
system.roles Node ValueSettings Tab OptionMeta Data in a SessionPackets in a Session
0No Filtering.
System roles that define permissions on a per meta key basis are disabled.
VisibleVisible
1Whitelist meta and content.
By default no meta and no packets are visible. Selecting individual SDK meta roles per user group allows users to see meta and packets for that SDK meta role.
Not Visible
Select to Show
Not Visible
Select to Show
2Whitelist only meta.
By default packets are shown, but no meta is visible. Selecting individual SDK meta roles per user group allow users to see meta for that role.
Not Visible
Select to Show
Visible
3Whitelist only content.
By default meta are visible, but no packets are visible. Selecting individual SDK meta roles per user group allow users to see packets for that role.
VisibleNot Visible
Select to Show
4Blacklist meta and content.
By default all meta and all packets are visible. Selecting individual SDK meta roles per user group prevents users from seeing meta and packets for that role.
Visible
Select to Hide
Visible
Select to Hide
5Blacklist only meta.
By default all meta and all packets are visible. Selecting individual SDK meta roles per user  group prevents users from seeing meta for that role.
Visible
Select to Hide
Visible
6Blacklist only content.
By default all meta and all packets are visible. Selecting individual SDK meta roles per user  group prevents users from seeing packets  for that role.
VisibleVisible
Select to Hide

Three factors determine what a user sees:

  • The SDK meta role setting.
  • The restricted meta keys configured for the Group to which the user belongs.
  • The meta keys in the session being analyzed.

Here's an example of how the SDK meta role configuration meshes with a Group that has restricted meta keys.

Configuration:

  • The SDK meta role setting is Blacklist meta and content. With this option implemented, all meta 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, username).
  • 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, username, Because the session includes username , no packets or logs from the session are displayed for the Analyst.

To configure meta and content restrictions for a Decoder or Log Decoder:

  1. In the Security Analytics menu, select Administration > Services.
  2. In the Services grid, select a Broker, Concentrator, Decoder, Log Decoder, or Archiver service and ic-actns.png > View > Security and click the Settings tab.

  3. Select one of the filtering methods (blacklist or whitelist) and content types (meta and content, meta only, or content only), and click Apply.

  4. 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.

  5. 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.

Note: The same capabiilty was previously available on Log Decoders, and was configured when setting up parsers by modifying the table-map.xml file. Now it is integrated in the Services Config view.

To configure selected meta keys on individual parsers that will not written to disk:

  1. In the Security Analytics menu, select Administration > Services.
  2. In the Services grid, select a Decoder or Log Decoder service and ic-actns.png > View > Config.
  3. In the Parsers Configuration section, select a parser and then select Transient in the Config Value drop-down list.

    The configuration change is marked by a red triangle.

    SvsCfgGetParCfTb.png

  4. Click Apply.

    The change is effective immediately. The parser configured as Transient will no longer store meta keys to disk.

You are here: In-Depth Procedures > Configure Data Obfuscation

Attachments

    Outcomes