This topic introduces the concept and implementation considerations for a data privacy officer or administrator who is managing exposure of privacy-sensitive data in RSA NetWitness® Suite. In addition, information about recommended use cases is included.
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 Suite 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) was added in NetWitness Suite 10.5 to support the management of privacy-sensitive data. The DPO can configure NetWitness Suite to limit exposure of meta data and raw content (packets and logs) using a combination of techniques. The methods available to protect data in NetWitness Suite include:
- Data Obfuscation
- Data Retention Enforcement
- Auditing Logging
NetWitness Suite 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 Suite network. In place of the original values, NetWitness Suite 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 need to 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 RBAC implementation in NetWitness Suite. To implement, you need to configure meta 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 need to configure meta keys on parsers for individual Decoders and Log Decoders as transient.
Data Retention Enforcement
NetWitness Suite 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 Suite 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 Suite 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.
Administrators can leverage audit logs that NetWitness Suite 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 Suite 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 Suite. Administrators can configure NetWitness Suite 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 Suite components covered by the 10.5 or later data privacy feature with a green check mark. Components marked with an X are not supported by data privacy functions. The NetWitness Suite Getting Started Guide provides a functional description of NetWitness Suite components.
Data Privacy Feature Implementation by Component
The following table identifies which data privacy features are supported for each NetWitness Suite component. For each component, a checkmark indicates if the component supports data obfuscation, data retention enforcement, data overwriting, and audit logging.
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 - Investigation 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 Suite components and modules that obtain access to privacy-sensitive meta data and their obfuscated counterparts are Investigation, 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 Suite 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 (described in the Sensitive Data topic in the Alerting Using ESA guide). Go to the Master Table of Contents in RSA Link to find and view referenced documents.
- Malware Analysis. Malware Analysis references certain meta keys during scoring, including
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 Suite 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 the Obfuscate Private Data topic in the Respond User guide) and has a configurable data retention period for alerts (see the Set a Retention Period for Alerts and Incidents topic in the Respond User guide). Go to the Master Table of Contents in RSA Link to find and view referenced documents.
- 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. The Configure Data Privacy for Reporting Engine topic in the Reporting Engine Configuration Guide provides procedures to configure data privacy for Reporting Engine. Go to the Master Table of Contents in RSA Link to find and view referenced documents.