Data Privacy: Data Privacy: Overview

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

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

Note: A data privacy plan touches on most components of Security Analytics. The person who configures data privacy needs to understand Security Analytics network components, configuration of Security Analytics 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. Security Analytics 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 Security Analytics 10.5 to support the management of privacy-sensitive data. The DPO can configure Security Analytics to limit exposure of meta data and raw content (packets and logs) using a combination of techniques. The methods available to protect data in Security Analytics include:

  • Data Obfuscation
  • Data Retention Enforcement
  • Auditing Logging

Data Obfuscation

Security Analytics 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 Security Analytics network. In place of the original values, Security Analytics 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. 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 Security Analytics 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 Security Analytics. 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.

Note: Based on the default Security Analytics Analyst role permissions, an analyst who is restricted from viewing certain meta can export and download PCAPs for the restricted meta keys from Investigation and view the data in a third-party application like Wireshark. To prevent this, the DPO must remove sdk.packets permission from the default Analyst role. Keep in mind though, that removing sdk.packets permission for the Analyst role restricts all analysts in that role from exporting or downloading PCAPs, preventing them from performing certain types of analysis. If analysts must have the ability to export or download PCAPs, a DPO can leverage the Security Analytics global auditing feature to capture events pertaining to such exports or downloads, and monitor audit logs for any policy violations.

Data Retention Enforcement

Security Analytics 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 Security Analytics 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 Security Analytics 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 Security Analytics 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 Security Analytics 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 Security Analytics 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 Security Analytics. Administrators can configure Security Analytics 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 Security Analytics 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 Security Analytics Getting Stared Guide provides a functional description of Security Analytics components.

Note: Security Analytics data privacy features are not supported for Warehouse and protected meta data can make it to Warehouse via Warehouse Connector, unless explicitly configured to be filtered out using Warehouse Connector Meta Filters. If protected meta data 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 Security Analytics.

Data Privacy Feature Implementation by Component

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

ComponentData ObfuscationData Retention Enforcement Data OverwritingAudit Logging
Decoder checkmark3.png checkmark3.png checkmark3.png checkmark3.png
Log Decoder checkmark3.png checkmark3.png checkmark3.png checkmark3.png
Meta Aggregation
Concentrator checkmark3.png checkmark3.png checkmark3.png checkmark3.png
Brokern/a checkmark3.png
(stored in DPO cache only)1
Real-Time Analysis  
Investigation checkmark3.png checkmark3.png
(stored in DPO cache only)2
Event Stream Analysis checkmark3.png    checkmark3.png
Malware Analysis checkmark3.png checkmark3.png   checkmark3.png
Incident Management checkmark3.png checkmark3.png   checkmark3.png
Reporting Engine checkmark3.png checkmark3.png   checkmark3.png
Long-Term Analytics
Archiver checkmark3.png checkmark3.png checkmark3.png

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 Security Analytics 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

Security Analytics components and modules that obtain access to privacy-sensitive meta data and their obfuscated counterparts are Investigation, Event Stream Analysis (ESA), Malware Analysis, Incident Management, 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 Security Analytics 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).
  • 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 Security Analytics 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.
  • Incident Management. Incident Management uses a data privacy mapping file to display obfuscated data in alerts.(see the Obfuscate Private Data topic in the Incident Management guide) and has a configurable data retention period for alerts (see the Set a Retention Period for Alerts and Incidents topic in the Incident Management 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. The Configure Data Privacy for Reporting Engine topic in the Reporting Engine Configuration Guide provides procedures to configure data privacy for Reporting Engine.

Related Topic

You are here: Data Privacy: Data Privacy: Overview