Data Privacy Overview

This topic introduces the concept and implementation considerations for a data privacy officer or administrator who is managing exposure of privacy-sensitive data in NetWitness. In addition, information about recommended use cases is included.

Note: A data privacy plan touches on most components of NetWitness. The person who configures data privacy needs to understand NetWitness network components, configuration of NetWitness hosts and services as described in the Host and Services Getting Started Guide, and the types of information that need to be protected.

Regulatory mandates in some locations, for example the European Union (EU), require that information systems have a means of protecting privacy-sensitive data. Any data that could directly or indirectly identify "Who did what when?" may be considered privacy-sensitive data. A few examples are user names, email addresses, and host names. NetWitness provides a range of controls that customers can leverage to protect privacy-sensitive data. These controls can be used in a variety of combinations to protect privacy-sensitive data, without significantly reducing analytical capability.

A user role for a Data Privacy Officer (DPO) supports the management of privacy-sensitive data. The DPO can configure NetWitness to limit exposure of metadata and raw content (packets and logs) using a combination of techniques. The methods available to protect data in NetWitness include:

  • Data Obfuscation
  • Data Retention Enforcement
  • Audit Logging

Data Obfuscation

NetWitness has configurable options for data obfuscation. Data privacy officers and administrators can specify which meta keys in their environment are privacy-sensitive and limit where the meta values and raw data for those keys are displayed in the NetWitness network. In place of the original values, NetWitness can provide obfuscated representations to enable investigation and analytics. In addition, DPOs and administrators can prevent persistence of privacy-sensitive meta values and raw logs or packets.

Three methods work together to implement data obfuscation:

  • Obfuscation of meta values for privacy-sensitive meta keys with an optional salt. Meta keys configured as protected are represented by obfuscated values at the time of creation on a Decoder or Log Decoder; the obfuscated values are hashed and considered to be impossible to read. To implement, you must configure the Decoder and Log Decoder hash algorithm and salt, and configure privacy-sensitive language keys as protected on all Core services.
  • Role-based access (RBAC) to the raw logs or packets and the privacy-sensitive meta values. The DPO can use roles with granular permission capabilities to restrict what an analyst versus a data privacy officer is able to view during configuration, analysis, and investigation. The System Security and User Management Guide provides in-depth coverage of the RBAC implementation in NetWitness. To implement, you must configure metadata and content visibility per role on individual Brokers, Concentrators, Decoders, Log Decoders, and Archivers.
  • Preventing persistence of privacy-sensitive meta values and raw logs or packets. To implement, you must configure meta keys on parsers for individual Decoders and Log Decoders as transient.

Data Retention Enforcement

NetWitness can ensure that data is retained only as long as necessary or as specified. An administrator can configure data retention using age and time thresholds on a per-service basis. Schedulers running on each service automatically delete data meeting those thresholds. Once the data is deleted, it is no longer available through user interfaces, queries, or application programming interface (API) calls. Some of the NetWitness components also support purging of data through overwrites.

An administrator can manage data retention in several ways:

  • Configure how long data persists in storage on the system.
  • For Core services, strategically remove privacy-sensitive data that may have been written by configuring automatic removal of data of a specific age.
  • Configure NetWitness so that original data is not sent or saved to the other components. If privacy-sensitive data makes its way into another database on the Reporting Engine, Malware Analysis, and NetWitness Servers, data retention can be managed there as well. This configuration for Event Stream Analysis is managed in the Services Explorer view.

Note: If a situation arises where the DPO decides that already collected data is privacy-sensitive after the system is functional, the administrator can manually overwrite the data from databases or files where the data is saved.

Audit Logging

Administrators can leverage audit logs that NetWitness creates using the Global Audit Logging feature. The audit logging feature generates audit log entries about many activities, and the following are examples of log entries that are relevant to data privacy:

  • Modifications to permissions and users assigned to roles.
  • Failed and successful attempts to log on to NetWitness and log off.
  • Data deletion.
  • Data exports and downloads.
  • Navigation by users to user interfaces and queries that users performed.
  • Attempts (successful or not) to view or modify privacy-sensitive data, including an identification of the user who made the attempts.

All audit log entries are part of a standard audit trail for NetWitness. Administrators can configure NetWitness to forward audit logs to a designated destination, including third-party systems to provide additional filtering and reporting capabilities. For more information on Global Audit Logging, see "Configure Global Audit Logging" in the System Configuration Guide.

Components Covered by the Data Privacy Feature

The figure below identifies the NetWitness components covered by the Version 11.x data privacy feature with a green check mark. Components marked with an X are not supported by data privacy functions. The NetWitness Getting Started Guide provides a functional description of NetWitness components.

Note: NetWitness data privacy features are not supported for Warehouse and protected metadata can make it to Warehouse through Warehouse Connector, unless explicitly configured to be filtered out using Warehouse Connector Meta Filters. If protected metadata makes it to Warehouse, users having direct access to Warehouse can query such data. Data privacy officers need to prevent that through administrative, technical, and procedural controls outside of NetWitness.

netwitness_dpcovge_700x293.png

Data Privacy Feature Implementation by Component

The following table identifies which data privacy features are supported for each NetWitness component. For each component, a check mark indicates if the component supports data obfuscation, data retention enforcement, data overwriting, and audit logging.

Component Data Obfuscation Data Retention Enforcement Data Overwriting Audit Logging
Ingestion
Decoder netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Log Decoder netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Meta Aggregation
Concentrator netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Broker n/a netwitness_checkmark-best.png (stored in DPO cache only)1 netwitness_checkmark-best.png
Real-Time Analysis
Investigate netwitness_checkmark-best.png netwitness_checkmark-best.png (stored in DPO cache only)2 netwitness_checkmark-best.png
Event Stream Analysis netwitness_checkmark-best.png netwitness_checkmark-best.png
Malware Analysis netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Respond netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Reporting
Reporting Engine netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png
Long-Term Analytics
Archiver netwitness_checkmark-best.png netwitness_checkmark-best.png netwitness_checkmark-best.png(uncompressed)3 netwitness_checkmark-best.png
Warehouse

Notes:
1 - Brokers can cache data and this needs to be cleared by configuring an independent rollover and other removal of cache as required. The administrator can configure cache rollover for a Broker using the Scheduler in the Services Config view Files tab.
2 - Investigate and the NetWitness Server cache data, and this is cleared automatically every 24 hours.
3 - The overwriting procedure described in Configure Data Retention applies to uncompressed data.

Component-Specific Configuration Guidelines

NetWitness components and modules that obtain access to privacy-sensitive metadata and their obfuscated counterparts are Investigate, Event Stream Analysis (ESA), Malware Analysis, Respond, and Reports. They get access to data based on the permissions defined for the role to which the user belongs. The Administrator or DPO configures each Decoder or Log Decoder to identify meta keys that are flagged for obfuscation.

These components have additional guidelines to ensure that they function as expected with a data privacy scheme:

  • Event Stream Analysis. When ESA receives privacy-sensitive data from NetWitness core, ESA passes on only the obfuscated version of the data. ESA does not store or show protected data. There are some additional guidelines for configuring advanced EPL rules and enrichment sources as well as information on how to remove sensitive data globally from all alerts (see "How ESA Handles Sensitive Data" in the Alerting with ESA Correlation Rules User Guide).
  • Malware Analysis. Malware Analysis references certain meta keys during scoring, including alias.host, client, and others. To ensure no loss of analytical functionality Malware Analysis should be configured as a trusted client; that is, configured to connect to the NetWitness Core infrastructure with an account equivalent to a user in DPO role. Otherwise, if meta keys referenced by Malware Analysis do get tagged for obfuscation and are not accessible to Malware Analysis, some of the Indicators of Compromise (IOCs) may be rendered ineffective.
  • Respond Server service. The Respond Server service uses a data privacy mapping file to display obfuscated data in alerts.(see "Obfuscate Private Data" in the NetWitness Respond User Guide) and has a configurable data retention period for alerts (see "Set a Retention Period for Alerts and Incidents" in the NetWitness Respond User Guide).
  • Reports. In Reporting Engine, each Core service is added as two separate data sources, using the two separate service accounts; one data source has a service account representing the Data Privacy Officer role and the other data source has a service account representing a non-Data Privacy Officer role. "Configure Data Privacy for Reporting Engine" in the Reporting Engine Configuration Guide provides procedures to configure data privacy for Reporting Engine.