inventory-tracking-4

En este primer artículo de la serie “Documentación de soporte para PCI DSS” se describirá uno de los documentos fundamentales para la identificación del entorno de cumplimiento de PCI DSS: la Cardholder Data Matrix (CHDM).

Uno de los elementos claves dentro de la gestión contable es un inventario.  De acuerdo con la Real Academia de la Lengua Española, un inventario se define como “Asiento de los bienes y demás cosas pertenecientes a una persona o comunidad, hecho con orden y precisión“. Básicamente, su función principal es permitir conocer en un momento dado las características, cantidad, estado y ubicación de bienes existentes y detectar cualquier modificación frente a un estado deseable, lo cual puede dar pie a una acción determinada por parte de la organización.

Dicho concepto ha sido adaptado en múltiples áreas, incluyendo la gestión de Tecnologías de la Información (TI) y su campo de acción va más allá del mero hecho contable.  La referencia más importante a la gestión de inventarios de activos de TI la podemos encontrar en la Biblioteca de Infraestructura de Tecnologías de Información (ITIL: Information Technology Infrastructure Library) y en el estándar BS 15000 (actualmente ISO/IEC 20000) bajo el concepto de “Base de Datos de la Gestión de Configuración” o CMDB por sus siglas en inglés (Configuration Management Database). Una CMDB es un repositorio de información donde se enumeran todos los componentes de un sistema de TI (denominados “elementos de configuración” o CI (Configuration Items)) y sus relaciones entre sí, describiendo de manera detallada sus características (hardware, software, direccionamiento IP, responsable, etc.)  y definiendo una línea base que permita detectar cualquier cambio, incidencia o problema que lo involucre de forma directa o indirecta, convirtiéndose en el corazón de todo el ciclo de vida del sistema.

Ahora bien, dentro del entorno de datos de tarjetas de pago (CDE: Cardholder Data Environment) relacionado con PCI DSS, el uso de un inventario de activos nos puede ser de bastante utilidad en las fases de identificación y delimitación de dicho entorno, así como en la gestión diaria de los controles.  Es aquí en donde entra el concepto de Cardholder Data Matrix (CHDM), que sin ser un requerimiento se convierte en una de las recomendaciones más útiles dentro del proceso global de PCI DSS.  Una Cardholder Data Matrix contiene la información de todos los activos que procesan, almacenan y transmiten datos de tarjetas de pago, así como los demás elementos que ofrecen soporte al entorno, que se pueden categorizar como sigue:

  • Personal relacionado con el CDE
  • Servidores y estaciones de trabajo
  • Equipos activos de red y de seguridad perimetral
  • Bases de datos
  • Aplicaciones
  • Medios de almacenamiento y otros soportes
  • Canales de comunicación
  • Proveedores
  • Instalaciones
  • Documentación

Toda esta información se puede obtener de forma manual o automática y se puede almacenar en una base de datos, una hoja de cálculo, un fichero de texto, etc. en función de la complejidad y cantidad de activos que se gestionen en el entorno de cumplimiento.  Inclusive, una organización que trabaje siguiendo las buenas prácticas de ITIL y tenga implementada una CMDB puede perfilar de una forma sencilla los CI que la componen para reflejar la pertenencia al CDE.

Índice de pestañas CHDM

Inventario de servidores CHDM

Un ejemplo de CHDM se puede encontrar en esta plantilla, que contiene todos los elementos descritos anteriormente y puede servir como punto de partida para el diseño de una CHDM a la medida de las necesidades de la organización, agregando o eliminando los campos que se requieran dependiendo del nivel de detalle que se considere necesario.

Cardholder Data Matrix v0.1

Adicional a las funcionalidades descritas anteriormente, una CHDM es clave en estas otras tareas:

  • Provee una visión detallada de los flujos de datos de tarjetas de pago y equipos involucrados cuando se acompaña de los diagramas de red.
  • Identificación rápida de activos involucrados en un potencial incidente, ya que permite conocer las relaciones entre los diferentes dispositivos y sus responsables.
  • Es una herramienta muy útil en el proceso de auditoría, ya que permite dimensionar el alcance de la misma y escoger de forma óptima los elementos de la muestra (en el caso que sea necesario).
  • Permite visualizar el potencial impacto en el entorno en el caso que se ingrese, modifique o retire un elemento.
  • Puede facilitar las labores de seguimiento y monitorización de tareas periódicas, tales como despliegue de actualizaciones, gestión de cambios, realización de escaneos de seguridad, etc.  proporcionando una foto del sistema en un momento dado.

Por otro lado, el uso de una CHDM puede tener  algunas desventajas:

  • Cuando la gestión de la información de activos en la CHDM se realiza de forma manual, la tarea de actualización y seguimiento del estado de cada elemento se puede tornar en un trabajo complicado cuando el entorno es complejo o muy dinámico.
  • Cuando el nivel de detalle de los atributos de cada activo es muy específico se puede encontrar con bastante información que potencialmente no sea muy útil, con lo cual es importante definir los niveles de granularidad en los detalles que se emplearán con base en las necesidades reales de información.

Finalmente, recordar que este documento contiene información confidencial de la organización y del entorno, con lo cual se deben desplegar los controles necesarios para la protección de su confidencialidad e integridad.

Conclusión: Una Cardholder Data Matrix contiene la información de todos los activos del entorno de cumplimiento. No es un requerimiento, pero es una buena práctica y su implementación puede traer bastantes ventajas  a la organización en el proceso de identificación, implementación y mantenimiento de los controles del estándar PCI DSS.

Información adicional:

Cardholder Data Security Best Practices for VisaNet Processors: http://usa.visa.com/download/merchants/cardholder-data-security-best-practices-for-visanet-processors.pdf

Step-by-Step Guide to Building a CMDB updated for ITIL v3: http://viewer.zmags.com/publication/897d92f9#/897d92f9/1