De acuerdo con ITIL (Information Technology Infrastructure Library), un “cambio” consiste en “la adición, modificación o eliminación de cualquier cosa que pueda tener un efecto en los servicios de tecnologías de la información“, entendiéndose como “tecnologías de la información” cualquier activo físico (servidores, equipos activos de red, appliances, discos, cintas de backup, papel, etc.), virtual (servidores y almacenamiento virtual), software (desarrollos propios, software de terceros, etc.), documentación, servicios de TI, procesos, personas, proveedores, clientes, ubicaciones, etc.

En PCI DSS, este criterio aplica a cualquier elemento del entorno de cumplimiento (“scope”) que esté inventariado en la Cardholder Data Matrix (inventario de activos del entorno PCI DSS, requisito 2.4).

Gestión de cambios en PCI DSS

El objetivo de esta actividad es garantizar que existe una correcta trazabilidad en los cambios realizados en el entorno y una segregación de responsabilidades para evitar que hayan conflictos de interés. Bajo este escenario, se deben cumplir las siguientes premisas:

  • Deben existir tres roles diferentes, como mínimo, que pueden ser personas o equipos:
    • Quien solicita el cambio (solicitante),
    • Quien autoriza el cambio (autorizador o Comité de Aprobación de Cambios (“Change advisory board” – CAB)), y
    • Quien implementa el cambio (implementador).

Y se deben aplicar las siguientes restricciones:

  • Quien solicita el cambio no puede ser el mismo que lo aprueba.
  • Quien aprueba el cambio no puede ser el mismo que lo implementa.
  • Quien solicita el cambio puede ser el mismo que lo puede implementar si y solo si ha recibido autorización y aprobación explícita.

El flujo de gestión de cambios por lo general incluye las siguientes actividades y responsables:

Para llevar un control de los cambios en los activos dentro del entorno de cumplimiento, PCI DSS requiere que cada cambio incluya lo siguiente:

  • Documentación de impacto (req. 6.4.5.1)
  • Aprobación del cambio por las partes autorizadas (req. 6.4.5.2)
  • Pruebas de funcionalidad para validar que el cambio no impacta de forma negativa la seguridad del sistema (req. 6.4.5.3)
  • Procedimientos de vuelta atrás (“rollback” / “back-out”)

No obstante, no todos los cambios son iguales. Su diferencia radica en el impacto que pueda tener en el entorno en términos de confidencialidad, integridad y disponibilidad (la cantidad de daño que le podría hacer al entorno en el caso de que el cambio fallara y la cantidad de activos afectada) y en la ventana de tiempo requerida para ejecutar dicho cambio.

Conforme con esta descripción, se podría hacer una categorización de cambios de la siguiente manera:

En función del tiempo

  • Cambios estándares (pre-aprobados): Por lo general son cambios comúnes vinculados con la operación, que se deben realizar de forma periódica con base en un procedimiento pre-establecido y cuyo riesgo está controlado.  Por ello, no requieren entrar en el ciclo de aprobación por cada ejecución (están pre-aprobados) y deben estar listados de forma explícita. Ejemplos:  Bloqueos de cuentas por inactividad, reseteo de contraseñas, actualización de las firmas antivirus, etc.
  • Cambios normales: Son cambios que requieren de una evaluación del riesgo de su ejecución y por ello necesita de una aprobación explícita por las áreas afectadas. Sin embargo, su ejecución no requiere ser inmediata y por lo general se cuenta con un calendario pre-establecido de implementación de estos cambios (“ventanas de mantenimiento”).  Ejemplos: despliegue de actualizaciones (parches), cambios en configuraciones, etc.
  • Cambios urgentes (emergencia): Son cambios que requieren de una ejecución inmediata debido al impacto que pueden tener en el negocio y no pueden esperar para ser analizados e implementados en los periodos establecidos en el calendario de cambios. Por ello, necesitan de un flujo de aprobación rápido (“express”). Ejemplos: solución de incidencias al nivel de aplicación que afecten la disponibilidad. 

En función del impacto

En este punto, cada organización debe establecer el criterio de lo que considera “impacto” en su entorno. Este valor se puede calcular en función de diferentes variables en escalas (bajo, medio, alto):

  • Cantidad de usuarios afectados (<50 usuarios, 50-100 usuarios, >100 usuarios),
  • Cantidad de activos afectados (1 servidor, 1-5 servidores, >5 servidores),
  • Tipos de activos afectados según su criticidad (servidores web, servidores de bases de datos, servidores de logs, etc.),
  • Pérdida de ganancias durante el tiempo fuera de línea (<100 USD, 100-1000 USD, >1000 USD),
  • Complejidad del proceso de vuelta atrás (fácil, medio, alto).

Por lo general, se usa el mismo criterio empleado en el análisis de riesgos (req. 12.2).

Con base en ello, se definen (como mínimo) dos niveles:

  • Cambio menor: Aquellos cambios con un impacto bajo o medio.
  • Cambio mayor (significativo): Aquellos cambios con un impacto alto.

Por lo general, lo que se suele utilizar para gestionar estas acciones es usar un formulario denominado “solicitud de cambio” (“Change Request or Request for Change” – RFC) que contenga estos campos y se almacene para evidencia posterior:

Cambios significativos en PCI DSS

Una de las preguntas más frecuentes que se hacen los responsables de la gestión de un entorno alineado con PCI DSS es la de identificar si un cambio en la infraestructura corresponde o no a un “cambio significativo. Esta duda tiene su origen en los siguientes requisitos de PCI DSS:

  • 6.4.6 Al término de un cambio significativo, deben implementarse todos los requisitos pertinentes de la PCI DSS en todos los sistemas y redes nuevos o modificados, y la documentación actualizada según sea el caso.
  • 11.2 Realice análisis internos y externos de las vulnerabilidades de la red, al menos, trimestralmente y después de cada cambio significativo en la red (como por ejemplo, la instalación de nuevos componentes del sistema, cambios en la topología de la red, modificaciones en las normas de firewall, actualizaciones de productos).
  • 11.2.3 Lleve a cabo análisis internos y externos, y repítalos, según sea necesario, después de realizar un cambio significativo. Los análisis deben estar a cargo de personal calificado.
  • 11.3.1 Lleve a cabo pruebas de penetración externas, al menos, una vez al año y después de implementar una actualización o modificación significativa en las infraestructuras o aplicaciones (como por ejemplo, actualizar el sistema operativo, agregar una subred o un servidor web al entorno).
  • 11.3.2 Lleve a cabo pruebas de penetración internas, al menos, una vez al año y después de implementar una actualización o modificación significativa en las infraestructuras o aplicaciones (como por ejemplo, actualizar el sistema operativo, agregar una subred o un servidor web al entorno).
  • 12.2 Implemente un proceso de evaluación de riesgos que cumpla con lo siguiente:
    • Se realiza, al menos, una vez al año y después de implementar cambios significativos en el entorno (por ejemplo, adquisiciones, fusiones o reubicaciones, etc.)
    • Identifica activos críticos, amenazas y vulnerabilidades
    • Los resultados en un análisis formal y documentado de riesgo.

Precisamente, la respuesta a esta pregunta proviene de la clasificación de cambios requerida en requisito 6.4.5.1, relacionada con el nivel de impacto:

Se puede concluír entonces lo siguiente:

Un cambio significativo es aquel tipo de cambio con un impacto alto, que modifica de forma sustancial el estado inicial del entorno de cumplimiento PCI DSS y, por ello, requiere de una serie de actividades al finalizar su ejecución para validar que el nivel de seguridad sigue siendo consistente. Sin embargo, no requiere de una recertificación o de una auditoría adicional fuera del ciclo anual, ya que su gestión es a través de la propia metodología de gestión de cambios de PCI DSS.

Algunos ejemplos de cambios significativos pueden ser:

  • Instalación de un service pack o de un cambio de versión radical a nivel de sistema operativo, protocolo o aplicación.
  • Instalación de un nuevo servidor, equipo de red o base de datos en el entorno.
  • Adición de un nuevo flujo de pago en el entorno.
  • Cambios en los controles de segmentación del entorno.
  • Cambios a nivel de empresa (adquisición, fusión, escisiones (“spin-off”)).
  • Migración de tecnologías.
  • Cambio de ubicación física (“datacenter”).
  • Migración a entornos con responsabilidad compartida en la nube (“cloud”).
  • Ingreso de un nuevo centro autorizador al entorno.

Debido a que cada entorno es diferente, la determinación de lo que constituye un cambio significativo debe ser definido por la propia organización  y debe quedar documentado. Durante una auditoría, el QSA validará este criterio y pedirá evidencias de las tareas vinculadas posterior al despliegue de estos cambios significativos.

Igualmente, es importante apuntar que la aplicabilidad de los requisitos vinculados con cambios significativos estará limitada únicamente a los activos afectados por el cambio. Es decir: los escaneos de vulnerabilidades, las pruebas de penetración, el análisis de riesgos, etc. se pueden limitar únicamente a los activos relacionados con el cambio y no es obligatorio (aunque sí recomendable) extender la ejecución de estas pruebas a todo el entorno.

Ejemplo de cambio significativo

Para aclarar este tema, tomaremos como un ejemplo de un “cambio significativo” el ingreso de un nuevo servidor al entorno de cumplimiento PCI DSS.  Siguiendo esta línea, las tareas a realizar al finalizar este cambio serán:

  • Actualización del diagrama de red (req. 1.1.2) y del diagrama de flujo (req. 1.1.3).
  • Actualización del inventario de activos del entorno (req. 2.4).
  • Ejecución de un análisis de vulnerabilidades interno y externo (req. 11.2.3) al nuevo servidor.
  • Ejecución de una prueba de penetración externa (req. 11.3.1) e interna (req.11.3.2) al nuevo servidor.

Para este caso, la ejecución de los escaneos de vulnerabilidades y pentests a este nuevo servidor no remplazan ni evitan la ejecución de los escaneos trimestrales ni pentest anuales a todo el entorno.

Si tienes dudas adicionales, puedes escribirnos en el foro o en  Twitter, LinkedIn, Facebook o Google+ y no olvides seguirnos vía RSS.