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