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 Platform. 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 Platform 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 Platform to limit exposure of metadata and raw content (packets and logs) using a combination of techniques. The methods available to protect data in NetWitness Platform include:
- Data Obfuscation
- Data Retention Enforcement
- Audit Logging
NetWitness Platform 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 Platform network. In place of the original values, NetWitness Platform 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 Platform. 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 Platform 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 Platform 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 Platform 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 Platform 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 Platform 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 Platform. Administrators can configure NetWitness Platform 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 Platform 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 Platform Getting Started Guide provides a functional description of NetWitness Platform components.
Data Privacy Feature Implementation by Component
The following table identifies which data privacy features are supported for each NetWitness Platform component. For each component, a check mark 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 - 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 Platform 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 Platform 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
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 Platform 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.