Infraestructura

PÁGINA: 1 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

Gestión de cambios y cambios significativos en PCI DSS

Procedimiento de Control de cambios

 Infraestructura

PÁGINA: 2 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

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 haya 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))
 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.

Roles en el proceso de gestión

 Infraestructura

PÁGINA: 3 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

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

Flujo del proceso de gestión de cambios

Para llevar un control de los cambios en los activos se requiere que cada cambio incluya lo siguiente:
 Documentación de impacto
 Aprobación del cambio por las partes autorizadas
 Pruebas de funcionalidad para validar que el cambio no impacta de forma negativa la seguridad
del sistema
 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 afectados) 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:

Categorización de cambios
 Infraestructura

PÁGINA: 4 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

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

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.
 Infraestructura

PÁGINA: 5 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

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
PENTAFON
y se almacene para evidencia posterior
DIRECCIÓN GENERAL DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIONES 01/03/18

FORMATO VER 1.0

Formato de Control de cambios (RFC) SOLICITUD DE CAMBIO

FECHA DE ELABORACION FECHA DE ULTIMA MODIFICACIÓN No. Solicitud (RFC)

PTF1000090919

OBJETIVO DEL CAMBIO RAZÓN DEL CAMBIO

SERVICIO(S) AFECTADO(S) PROGRAMA(S)/APLICACIÓN(ES) AFECTADA(S) ASSET/CI AFECTADO(S)

RIESGO CATEGORIA URGENCIA IMPACTO PRIORIDAD

Menor Menor Media Medio Media
TIPO SUBTIPO
Servicios de cómputo central Ambientes físicos e infraestructura
DESCRIPCION DEL IMPACTO A USUARIOS

CONSIDERACIONES IMPORTANTES

Nombre:
Crea do:
SITIO DE COLABORACIÓN:
Modi fi ca do:
Modi fi ca do
VENTANA DE MANTENIMIENTO PROPUESTA
(HORA, FECHA Y DURACIÓN DEL CAMBIO)

DURACIÓN DEL CAMBIO: 03:17 horas Implementación: 107 min

FECHA DE INICIO: Validación: 44 min

FECHA FIN: Retorno: 81 min

OBSERVACIONES ADMINISTRADOR DE CONFIGURACIONES
 Infraestructura

PÁGINA: 6 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

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:

 Al término de un cambio significativo, deben implementarse todos los requisitos pertinentes de

la PCI DSS en todos los sistemas y redes nuevas o modificadas, y la documentación
actualizada según sea el caso.

 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).

 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.

 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).

 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).

 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.
 Infraestructura

PÁGINA: 7 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

Formato de riego
Pentafon PROCESO Actualizaciones Servidores
DIRECCIÓN GENERAL DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIONES 01/03/18

FORMATO VER 1.0

ANALISIS DE RIESGO
PTF1000090919

NIVELES DE RIESGO
CATEGORÍA Alto Moderado Bajo Sin Riesgo
Riesgo total
(4) (3) (2) (1)

Impacta a una gran cantidad de Impacta a una gran cantidad de

usuarios finales, interrupción
Impacto a los usuarios finales
mayor a sistemas críticos, impacto
en servicios de misión crítica.
Impacta a un número pequeño de No impacta a usuarios finales,
usuarios finales, interrupción
usuarios finales, mínimo impacto a no impacta a sistemas o 1
significativa a sistemas críticos o a
servicios de misión crítica. servicios de misión crítica.
servicios de misión crítica.

Involucra recursos de más de 1 Involucra recursos de más de 1 Involucra recursos de más de 1

grupo de trabajo de más de 1 grupo de trabajo de 1 Dirección, grupo de trabajo de más de 1
Impacto en recursos de TIC Requiere de 1 recurso. 1
Dirección, no se cuenta con los se tienen expertos limitados en el Dirección, se cuenta con los
expertos requeridos. tema. expertos requeridos.

Alta complejidad que requiere

Complejidad significativa que Baja complejidad que no requiere
Complejidad de Implantación coordinación tanto técnica como Sin complejidad. 1
requiere coordinación técnica. coordinación técnica.
de negocio.

El tiempo de interrupción es mayor

El tiempo de interrupción es El tiempo de interrupción es
a 1 hora y afecta a los usuarios en
Duración del Cambio menor a 1 hora durante horas pico menor a 1 hora en horas no No se espera interrupción. 2
horas pico. Muy largo el tiempo de
o mayor a 1 hora en horas no pico. pico.
instalación y de retorno.

Afecta datos no críticos o la

Afecta datos críticos o la No hay afectaciones a la
seguridad del servidor y el retorno
Seguridad seguridad del servidor y el retorno seguridad y el retorno es No requiere plan de retorno. 2
no excederán la ventana de
excederán la ventana de tiempo. sencillo.
tiempo.

Impacto a los Acuerdos de Impacta a los SLA durante horas Impacta a los SLA durante horas Poca afectación en tiempo No afecta los tiempos de los
1
Niveles de Servicio pico. no pico. medible para los SLA. SLA

RIESGO 8

Se puede concluir 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
 Infraestructura

PÁGINA: 8 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

Algunos 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 PENTAFON y debe quedar documentado.

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

Cambios significativos

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 y del diagrama de flujo.

 Actualización del inventario de activos del entorno.
 Ejecución de un análisis de vulnerabilidades interno y externo al nuevo servidor.
 Ejecución de una prueba de penetración externa e interna al nuevo servidor.

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

PÁGINA: 9 DE 9 DOCUMENTO INTERNO VERSIÓN: 1.0

CONCLUSIÓN
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)