Alerting: Datos confidenciales

Document created by RSA Information Design and Development on Feb 9, 2017
Version 1Show Document
  • View in full screen mode
  

En este tema se explica la forma en que ESA maneja los datos confidenciales, como nombres de usuario o dirección IP, que recibe de Security Analytics Core. La función Encargado de la privacidad de datos (DPO) puede identificar claves de metadatos que contienen datos confidenciales y que deben mostrar datos ocultos. ESA no mostrará ni almacenará metadatos confidenciales. Por lo tanto, ESA no transmitirá datos confidenciales a Incident Management.

De manera opcional, ESA puede agregar una versión oculta de los datos confidenciales a un evento. Por ejemplo, el DPO identifica user_dst como confidencial. ESA puede agregar una versión oculta, como user_dst_hash, a un evento. Los metadatos ocultos no son confidenciales, razón por la cual ESA los mostrará y los almacenará de la misma manera que otros metadatos no confidenciales.

Para obtener más información sobre la estrategia y los beneficios del ocultamiento de datos, consulte la Guía de administración de la privacidad de datos de Security Analytics.

En este tema se explica lo siguiente:

  • Cómo ESA maneja los datos confidenciales que recibe de Security Analytics Core
  • Cómo impedir filtraciones de datos confidenciales en una regla de EPL avanzado

Cómo ESA maneja datos confidenciales de Security Analytics Core

Cuando ESA recibe datos confidenciales de Security Analytics Core, solo transmite la versión oculta de los datos. ESA no almacena ni muestra datos confidenciales.

Las siguientes funciones se ven afectadas:

  • Salidas: ESA no reenvía datos confidenciales a salidas, las cuales incluyen alertas, notificaciones y almacenamiento en MongoDB.
  • Reglas de EPL avanzado: si una declaración de EPL crea un alias para una clave de metadatos confidenciales, los datos confidenciales se filtrarán. En este tema se ilustra cómo sucede esto de modo que pueda evitarlo.
  • Enriquecimientos: si se usa una clave de metadatos confidenciales en la condición de combinación, los datos confidenciales se filtrarán. En este tema se ilustra cómo sucede esto de modo que pueda evitarlo.

Regla de EPL avanzado

Si una declaración de consulta de EPL cambia el nombre de una clave de metadatos confidenciales, los datos no se protegerán.

ESA identifica una clave de metadatos confidenciales por el nombre:

ip_src es la clave de metadatos confidenciales.
ip_src_hash es la versión oculta no confidencial.

Para ofrecer compatibilidad con la privacidad de datos, no se debe cambiar el nombre de la clave de metadatos confidenciales en una consulta EPL. Si se cambia el nombre de una clave de metadatos confidenciales, los datos ya no estarán protegidos.

Por ejemplo, en una regla como select ip_src as ip_alias…, ip_alias contiene los datos confidenciales, pero no está protegido porque ESA solo tiene conocimiento de ip_src, no de ip_alias. En este caso, las direcciones IP no se ocultarían. Se mostrarían los valores reales.

Origen de enriquecimiento

Cuando se usa una clave de metadatos confidenciales en una condición de combinación, los datos confidenciales se pueden mostrar.

La base de datos de enriquecimiento, que es la otra parte de la condición de combinación, tiene una columna que coincide con la clave de metadatos confidenciales. Esta referencia cruzada es a valores reales y no a valores ocultos. Por lo tanto, se muestran valores reales.

En el siguiente ejemplo se resaltan ambas partes de la condición de combinación.

DataObEnr.png

  • ip_src contiene datos confidenciales.
  • ipv4 se agregará a la alerta y se expondrá como datos no confidenciales

Debido a que el valor de ipv4 es igual que el valor de ip_src, ipv4 contiene y muestra datos confidenciales. 

You are here
Table of Contents > Cómo ESA genera alertas > Datos confidenciales

Attachments

    Outcomes