log

En esta sexta entrega de la serie “Controles técnicos de PCI DSS” se realizará una breve introducción a la gestión de registros de eventos (logs) en PCI DSS como parte de la estrategia de prevención y detección de incidentes relacionados con datos de tarjetas de pago, las acciones de monitorización periódica y la gestión de estos registros en acciones de investigación posterior (forense).

Controles detectivos: Registro de eventos (logs)

locardEn 1928 Edmon Locard (un renombrado policía francés, pionero de la criminalistica moderna) enunció uno de los principios base de las investigaciones forenses: El principio de intercambio de Locard. Este principio afirma que “siempre que dos objetos entran en contacto transfieren parte del material que incorporan al otro objeto”, siendo clave en la obtención y análisis de evidencia forense.

En su libro “Manual de Técnica Policiaca” (Manuel de Technique Policière) indicaba que “es imposible que un criminal actúe, especialmente en la tensión de la acción criminal, sin dejar rastros de su presencia”. Sus enseñanzas en el área de la criminalistica se han extrapolado al área dígital (cómputo forense), sin que su principio de intercambio sufra modificaciones.

Desde la perspectiva informática, uno de los elementos críticos para soportar cualquier investigación (y que tácitamente se alinea con el principio de intercambio de Locard) es el registro de eventos (o “logs”). Un “log” es básicamente el registro de una actividad particular, indicando (entre otros elementos) la identificación del usuario o aplicación que realizó la acción, el recurso afectado, el tipo de evento, la fecha y hora y el resultado de esa acción (éxito o error).  Con estos valores se puede realizar un análisis que permitirá dos conclusiones:

  • La identificación explícita de un incidente (en donde del registro del evento (log) se puede extraer una conclusión directa)
  • La identificación no explícita de un incidente (en donde el registro del evento puede ser un indicador que algo extraño está sucediendo y requiere de correlación adicional)
Log de un servidor SSH bajo un ataque de fuerza bruta

Log de un servidor SSH bajo un ataque de fuerza bruta

Estas conclusiones llevarán a la categorización de dicho evento como un “incidente de seguridad” en el caso que comprometa o intente comprometer la confidencialidad, la integridad y/o la disponibilidad de un sistema informático.

Lamentablemente, para que se obtenga un registro (log) primero se debe ejecutar una acción o evento, lo cual presupone que – en el caso de un incidente de seguridad  – el potencial atacante ya dio un primer paso ofensivo, por lo que la monitorización en tiempo real es imprescindible para la identificación y contención del ataque. Es por ello que la gestión de registro de eventos es un elemento crucial en el proceso de gestión de incidentes corporativos.

gestion_de_incidentes

Gestión de incidentes y su relación con el registro de eventos (logs)

Registro de eventos (logs) en PCI DSS

Mapa de fuentes de logs

Mapa de fuentes de logs

Una de las acciones más importantes dentro de la gestión de seguridad del entorno de cumplimiento (CDE) de PCI DSS es el registro de eventos y la monitorización continua.  El requisito 10 del estándar (“Rastree y supervise todos los accesos a los recursos de red y a los datos de los titulares de las tarjetas”) especifica las labores necesarias para garantizar que todas las acciones que puedan afectar la integridad, la confidencialidad y/o la disponibilidad de los datos de tarjetas de pago sean registradas con el fin de soportar investigaciones posteriores y permitir retroalimentar y afinar los controles de seguridad desplegados dentro de las acciones de mejora continua cubriendo las siguientes tareas:

Activación de los registros de auditoría (Req. 10.1 y 10.2)

  • Activación de los controles automáticos de registro de eventos de los componentes del sistema
  • Configuración de los controles de auditoría para registrar las siguientes acciones:
    • Todos los accesos individuales a datos de tarjetas de pago
    • Todas las acciones realizadas por cuentas con privilegios administrativos
    • Todos los accesos a los registros de eventos
    • Todos los intentos de acceso lógico inválidos
    • Uso y/o cambios en los mecanismos de identificación y autenticación
    • Todos los cambios, adición o eliminación de cuentas con privilegios administrativos
    • Inicialización, detención o pausado del sistema de registro de eventos
    • Creación y eliminación de objetos a nivel de sistema

Configuración de los datos a ser registrados (Req. 10.3)

Adicionalmente, se describen los requerimientos mínimos que deben tener los registros de eventos:

  • Identificación del usuario
  • Tipo de evento
  • Fecha y hora
  • Resultado de la acción (éxito o fallo)
  • Origen del evento
  • Identidad del recurso afectado

Protección de los registros de eventos (Req. 10.5 y 10.7)

Por otro lado, se establecen los criterios a seguir en la protección de los registros de eventos (logs) con el fin de garantizar su integridad y disponibilidad en el caso de investigaciones:

  • Implementación de controles de necesidad de saber (need-to-know) en el acceso a los registros de eventos
  • Protección de los registros de eventos para evitar modificaciones no autorizadas
    • Centralización de los registros de eventos
    • Copia en medios de almacenamiento
    • Uso de herramientas de monitorización de integridad
    • Almacenamiento de los registros de eventos por lo menos un año con disponibilidad inmediata de tres meses

Revisión periódica de los registros de eventos (Req. 10.6)

Tal y como se comentaba al principio, no tiene ninguna aplicabilidad práctica el hecho de generar registros de eventos (logs) si no se revisan. Es por ello que el propio estándar define las directrices para la revisión periódica de los logs:

  • De forma diaria para todos los eventos de seguridad, los registros de eventos de componentes que almacenen, procesen o transmitan datos de tarjetas, sistemas críticos y todos los servidores y sistemas que ejecutan labores de seguridad
  • Los demás logs deben ser revisados conforme con los criterios de priorización obtenidos del análisis de riesgo de la organización

En este punto, la revisión se puede realizar de diferentes maneras:

  • De forma manual
  • Empleando herramientas de correlación automática empleando herramientas SIEM/SIM/SEM (Security Information and Event Management (SIEM), Security Information Management (SIM) y Security Event Management (SEM))

Planificación e implementación de una infraestructura de registro de eventos para PCI DSS

Con el objetivo de facilitarle la vida al responsable de la implementación de los controles de registro de eventos en un entorno de PCI DSS, VISA Europa publicó el documento “Planning for and implementing security logging“, en donde desde el punto de vista metodológico ofrece un conjunto de buenas prácticas para apoyar el proceso de diseño y despliegue de una solución de gestión de logs, incluyendo:

  • Preparación para el análisis de logs
  • Análisis de las necesidades de negocio y de cumplimiento
  • Alcance de la solución y estrategia de registro de eventos
  • Desarrolllo de una política de análisis de logs
  • Desarrollo de un criterio de evaluación de la solución
  • Evaluación de las opciones
  • Pruebas de concepto
  • Despliegue del análisis de logs
  • Revisión y refinamiento del despliegue de la solución de registro de eventos

Monitorización de logs e integración con la estrategia de respuesta a incidentes

Como complemento a las descripciones de gestión de logs provistas directamente en el estándar PCI DSS, el PCI SSC publicó en mayo de 2016 el suplemento informativo “Effective Daily Log Monitoring” focalizándose en las actividades vinculadas con la revisión periódica de los registros de eventos y su integración con la gestión de incidentes de PCI DSS, complementando las recomendaciones del documento de VISA Europe comentado anteriormente.

Este documento se divide en 5 apartados que cubren todo el proceso de despliegue de una solución de registro de eventos en PCI DSS: Requerimientos de monitorización de logs en PCI DSS, planificación, preparación, ejecución y aplicación de una monitorización efectiva de logs. Este es un documento imprescindible para cualquier responsable de implementación de controles de PCI DSS.

Ciclo del proceso de monitorización de logs

Ciclo del proceso de monitorización de logs

Herramientas técnicas para la gestión de logs

Actualmente son muy pocos los sistemas incapaces de generar registro de sus eventos. Sistemas operativos, aplicaciones, bases de datos y equipos activos de red se pueden configurar de forma nativa o empleando herramientas de terceros para generar logs y copiarlos en un servidor central. Dentro de ellas podemos enumerar el tradicional Syslog (documentado en la RFC 5424), pasando por su evolución syslog-ng o su competencia rsyslog, hasta soluciones más complejas de SIEM/SIM/SEM dentro de las que se encuentran las siguientes (extraídas del reporte de Gartner para SIEM de 2016):

Captura

 

  • IBM Security
  • Hewlett Packard Enterprise
  • Splunk
  • Intel Security
  • LogRhythm
  • EMC (RSA)
  • AlienVault
  • TrustWave
  • MicroFocus (NetIQ)
  • AccelOps
  • EventTracker
  • SolarWinds
  • BlackStratus

 

 

Asi como herramientas Open Source como Graylog, Logcheck, Logwatch y Logstash.

En esta URL se puede encontrar un listado exhaustivo de diferentes herramientas que pueden soportar el proceso de gestión de logs en una organización.

Referencias adicionales

Como complemento a los documentos enumerados anteriormente, a continuación se listan varios recursos que pueden ser útiles en el proceso de despliegue de soluciones de gestión de logs conforme con PCI DSS:

¿Conoce alguna solución de gestión de logs diferente a las listadas en este artículo? ¿Cómo ha sido su experiencia en el despliegue de estas soluciones en entornos PCI DSS? Las respuestas y otras preguntas que se puedan tener las pueden formular en los comentarios y el foro.