Privacidad de datos: Configuraciones recomendadas

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

En este tema se describe la implementación recomendada de la privacidad de datos para Security Analytics y varios casos de uso adicionales para administrar la exposición de datos confidenciales en Security Analytics. Los administradores pueden configurar hosts y servicios de Security Analytics para satisfacer los requisitos de privacidad de datos del ambiente. RSA ofrece configuraciones recomendadas para la privacidad y la retención de datos.

Configuración recomendada de la privacidad de datos

La configuración recomendada para obtener el mejor valor analítico con el ocultamiento de datos habilitado es definir metadatos confidenciales y mantener los valores originales y ocultos (hash) de los datos confidenciales en disco para Decoders, Log Decoders, Concentrators y Brokers.

El supuesto es que solo se clasificarán como protegidos algunos metadatos (aproximadamente 10 claves de metadatos) y que se usará para la aplicación de hash un algoritmo compatible con FIPS 140 junto con un valor de sal con el fin de dificultar la ingeniería inversa del valor original. La solución recomendada es SHA-256 con un valor de sal de por lo menos 16 y un máximo de 60 caracteres.

Nota: de manera predeterminada, los valores de hash se almacenan en formato binario, debido a que esto ofrece mejores tiempos de respuesta y a que se requiere menos espacio de almacenamiento en la base de datos respecto de cuando se guardan en formato de cadena. El método de almacenamiento recomendado es texto/cadena.

Para Brokers e Investigation, la caché puede contener datos originales y ocultos debido al uso de Investigation por parte de los encargados de la privacidad de datos para confirmar el valor original al cual se mapea el valor oculto durante las investigaciones. Los servicios descendentes también pueden limitar el uso de los valores confidenciales originales al procesamiento en la memoria, de modo que los datos no persisten en disco en esos sistemas descendentes; esto se cumple en ESA y Malware Analysis.

La solución recomendada para eliminar datos cuando están listos es la aplicación incorporada y automática de la retención de datos, la cual elimina los datos en cierto umbral. Puede usar este método para los siguientes componentes en Security Analytics 10.5: Decoder, Log Decoder, Log Collector, Archiver, Malware Analysis, Incident Management y Reporting Engine. Puede configurar manualmente Event Stream Analysis para brindar compatibilidad con una aplicación automática de la retención de datos similar.

Para administrar el almacenamiento en caché, el servidor de Security Analytics borra la caché relacionada con las investigaciones de eventos cada 24 horas. El Broker también se puede configurar para que ejecute una eliminación periódica de la caché almacenada localmente.

Opciones para las configuraciones de la retención de datos

Security Analytics proporciona controles alternativos que el administrador puede aplicar para imponer restricciones más estrictas en cuanto al almacenamiento de datos confidenciales cuando el ocultamiento de datos está habilitado.

Almacenamiento de datos con opciones de retención de datos vigentes

En la siguiente tabla se resume dónde se almacenan los datos en la configuración predeterminada sin privacidad de datos y para cada alternativa de retención de datos. Una marca de verificación indica que los datos confidenciales se guardan en el componente; una X indica que no se almacenan datos confidenciales en el componente.

                                                                                                                                                   
ComponenteConfiguración predeterminadaOpciones de almacenamiento de datos
 Se almacenan datos originalesSe almacenan datos originales y hash
(recomendado)
Solo se almacena hashNo se almacenan datos (todos los metadatos son transitorios)
del almacenamiento
Decoder checkmark3.png checkmark3.png X X
Log Decoder checkmark3.png checkmark3.png X X
Agregación de metadatos
Concentrator checkmark3.png checkmark3.png X X
Broker checkmark3.png (solo caché) checkmark3.png (solo caché)X X
Analítica en tiempo real  
Investigation checkmark3.png checkmark3.png (solo caché)X X
Event Stream Analysis checkmark3.png X X X
Malware Analysis checkmark3.png X X X
Incident Management checkmark3.png X X X
Informes
Reporting Engine checkmark3.png checkmark3.png (opcional)X X
Analítica a largo plazo
Archiver checkmark3.png (opcional) checkmark3.png (opcional)X X
Warehouse checkmark3.png (opcional) checkmark3.png (opcional)X X
Contenido
En vivoN/DN/DN/DN/D
Análisis de fraude     
WebThreat DetectionN/DN/DN/DN/D
Protección de terminal
ECATN/DN/DN/DN/D
Notas:
Solo caché significa que los datos confidenciales están en la caché del Broker o del servidor de Security Analytics. Configurar retención de datos proporciona detalles sobre el borrado automatizado y manual de la caché.

Opcional significa que el almacenamiento de datos confidenciales se produce, pero se puede limitar con configuraciones opcionales. Por ejemplo, para limitar dónde se almacenan los datos confidenciales, no habilite al acceso del DPO para Reporting y no agregue datos protegidos originales en el Archiver.

Opción 1: No se guardan datos originales en disco, solo se almacena hash

Los administradores pueden eliminar la persistencia en disco de datos confidenciales y almacenar solo un valor oculto si el riesgo de exposición es demasiado grande. En este escenario, los metadatos generados durante el análisis en Decoders y Log Decoders se usan solo en la memoria y no se escriben en disco. Los administradores pueden configurar claves de metadatos individuales en un Decoder o un Log Decoder como transitorias para asegurarse de que los metadatos confidenciales no se escriban en disco. Los servicios descendentes no ven valores originales y deben usar valores ocultos para realizar tareas de investigación y analítica.

Para configurar este esquema de privacidad de datos, el ocultamiento de datos debe estar habilitado con valores de hash configurados. Puede configurar claves de metadatos individuales en un Decoder o un Log Decoder como transitorias para asegurarse de que los valores originales no se escriban en disco.

  • Los valores originales que se identifican como confidenciales se extraen de los datos crudos en el análisis en el Decoder y el Log Decoder, y el sistema puede acceder a ellos durante el análisis (analizadores, reglas y feeds).
  • El Decoder no guarda los valores originales para las claves de metadatos identificadas como confidenciales y solo almacena el hash de estos valores junto con otros metadatos no confidenciales relacionados con el evento.

Un efecto secundario de estas opciones es cierta pérdida en la funcionalidad analítica, pero puede configurarlas de modo que se ajusten a las necesidades del ambiente.

  • Si todos los datos confidenciales se configuran como transitorios, los valores confidenciales no persisten en disco y las funcionalidades analíticas que usan el valor original solo están disponibles en el momento del análisis (analizadores, reglas y feeds).
  • Los sistemas Event Stream Analysis (ESA) y Malware Analysis deben confiar solo en los valores de metadatos ocultos cuando realizan sus tareas de correlación y puntaje, respectivamente.
  • Reporting Engine está limitado a extraer informes con el uso de los valores no confidenciales y ocultos.
  • El encargado de la privacidad de datos no puede ver el valor original, pero puede usar el hash y el valor de sal configurados para determinar si un valor oculto representa un valor original conocido específico.

Opción 2: No se almacenan valores originales u ocultos: no recomendado

Los administradores pueden eliminar por completo la persistencia en disco del valor original si el riesgo de exposición es demasiado grande. Como en la opción 1, en este escenario, los metadatos generados durante el análisis en Decoders y Log Decoders se usan solo en la memoria y no se escriben en disco. Los administradores pueden configurar claves de metadatos individuales en un Decoder o un Log Decoder como transitorias para asegurarse de que los metadatos confidenciales no se escriban en disco. Los servicios descendentes no ven valores originales y no tienen valores ocultos para realizar tareas de investigación y analítica.

Para configurar este esquema de privacidad de datos, configure claves de metadatos individuales en un Decoder o un Log Decoder como transitorias con el fin de asegurarse de que los valores originales no se escriban en disco.

  • Los valores originales que se identifican como confidenciales se extraen de los datos crudos en el análisis en el Decoder y el Log Decoder, y el sistema puede acceder a ellos durante el análisis (analizadores, reglas y feeds).
  • El Decoder no guarda los valores originales para las claves de metadatos identificadas como confidenciales y solo almacena metadatos no confidenciales relacionados con el evento.

Un efecto secundario de estas opciones es una pérdida significativa en la funcionalidad analítica, pero puede configurarlas de modo que se ajusten a las necesidades del ambiente.

  • Si todos los datos confidenciales se configuran como transitorios, los valores confidenciales no persisten en disco y las funcionalidades analíticas que usan el valor original solo están disponibles en el momento del análisis (analizadores, reglas y feeds). Consulte Configurar retención de datos.
  • Todos los componentes descendentes no tienen ninguna visibilidadde los valores originales, ya sea ocultos u otros.
  • El encargado de la privacidad de datos no tiene ninguna visibilidad del valor original, ya sea oculto u otro.

Alternativas opcionales de sobrescritura de datos

Opción 1: Limitar el espacio en disco para la sobrescritura continua de datos más antiguos

Si se conoce el periodo de retención de datos deseado para almacenar los datos y, por lo tanto, la cantidad de almacenamiento que se requiere para esos datos, el tamaño del hardware subyacente o de la partición se puede limitar a ese tamaño. Con la reducción del almacenamiento en disco duro o del tamaño de la partición, también se limitaría la cantidad de espacio libre disponible que se debe llenar antes de que los nuevos datos lo sobrescriban. Los datos recopilados recientemente sobrescriben los datos más antiguos de manera continua. Para que sea eficaz, cualquier solución se debe aplicar en el momento de la implementación.

Los efectos secundarios de esta opción son:

  • La eliminación de algunos discos limitará la cantidad de recursos disponibles para distribuir los I/O, lo cual causa cierta degradación en el rendimiento.
  • El tamaño más pequeño de la partición puede causar cierta degradación en el rendimiento, pero también puede aliviar parte del impacto en el rendimiento de la eliminación de discos.

Opción 2: Usar almacenamiento en niveles para sobrescribir datos de manera calendarizada

Si la sobrescritura de datos se requiere de manera automática y programada, puede configurar Decoders y Concentrators de modo que usen almacenamiento en niveles. La configuración del almacenamiento en niveles proporciona un mecanismo para invocar un script después de la eliminación de un archivo de la base de datos de la aplicación, pero antes de su eliminación del sistema de archivos. Si es necesario, en lugar de transferir el archivo al segundo nivel, o almacenamiento inactivo (la función prevista en un caso de uso del almacenamiento en niveles), el script puede usar una utilidad como shred de CentOS para sobrescribirlo. Esta herramienta es menos eficaz cuando la base de datos se almacena en un sistema de archivos de registro como XFS, en el cual reside la base de datos de Security Analytics Core, y en una unidad lógica RAID como aquellas con las cuales se conectan los hosts de Security Analytics Core.

En su mayoría, los otros componentes de Security Analytics no tienen esta opción; sus datos se almacenan en una base de datos que no es compatible con el mecanismo de almacenamiento en niveles. De estos otros componentes, el único que podría usar este método de sobrescritura es Reporting Engine, puesto que guarda informes y alertas como archivos individuales. Sin embargo, los gráficos de Reporting Engine se almacenan en una base de datos, razón por la cual estarían exentos de esta técnica.

Opción 3: Depurar datos mediante la opción de redacción de cadenas y patrones

La depuración de datos proporciona un mecanismo para sobrescribir estratégicamente un subconjunto específico de datos del sistema en caso de que datos confidenciales hayan persistido a propósito o por accidente. La utilidad wipe de Security Analytics permite escribir patrones únicos sobre los datos en las bases de datos de metadatos y paquetes para los servicios Security Analytics Core, las cuales pueden contener registros o paquetes RAW para sesiones existentes en función de un identificador de sesión. Todos los componentes de Security Analytics Core tienen la funcionalidad de sobrescribir un subconjunto de datos encontrado mediante la ejecución de una cadena de consulta, incluidos los patrones regex. Los identificadores de sesión que devuelve la consulta se alimentan en la utilidad wipe de Security Analytics.

Nota: Esta opción no está disponible si los datos en la base de datos de SA Core se comprimieron (como se hace generalmente en implementaciones de Archiver).

En la mayoría de los componentes de Security Analytics, la base de datos en uso no proporciona un mecanismo incorporado de redacción o eliminación segura. El componente Malware Analysis puede sobrescribir el objeto de datos en la base de datos con el valor private en lugar de eliminarlo durante el proceso de administración de la retención de datos, pero esto no tiene el propósito de ser un mecanismo de eliminación seguro.

Precaución: El uso de este método en una gran cantidad de sesiones tiene dos desventajas: puede ser lento y puede afectar el rendimiento.

Limitaciones de la sobrescritura de datos

Las técnicas de sobrescritura descritas como las opciones 2 y 3 tienen limitaciones. Para ejecutar la sobrescritura de los datos en los sectores del disco, las opciones de sobrescritura anteriores y la herramienta de la línea de comandos para sobrescritura que se proporciona como un método alternativo (shred, una función de CentOS) hacen suposiciones sobre el diseño de disco.  Los hosts de Security Analytics usan unidades de disco SSD y configuraciones RAID por motivos de rendimiento y confiabilidad, y estas limitan la funcionalidad de las técnicas de sobrescritura. Si las técnicas de sobrescritura modifican las unidades de disco SSD y las configuraciones RAID en un intento por aumentar la seguridad, habrá inevitablemente un costo asociado en términos de rendimiento, el cual se reflejará en las tasas de recopilación, las velocidades de consulta y, posiblemente, en otras áreas. Las herramientas de la línea de comandos disponibles para sobrescritura se recomiendan únicamente para casos de uso especiales en los cuales es necesario redactar datos específicos. Las herramientas no se deben usar en un método continuo en tiempo real debido al posible costo en términos de rendimiento en que se incurrirá.

You are here
Table of Contents > Descripción general de la privacidad de datos > Configuraciones recomendadas

Attachments

    Outcomes