En un post anterior se comentó sobre PCI DSS y Disponibilidad, señalando aquellos requisitos que buscan cubrir este criterio de seguridad. En este apartado se explica cómo dar cumplimiento al requisito 12.10 “Implemente un plan de respuesta ante incidentes. Prepárese para responder de inmediato ante un fallo en el sistema”.

La continuidad de las operaciones críticas relacionadas a tarjetas de pago no es un tema menor para PCI, los incidentes pueden deberse a diferentes causas, desde ataques deliberados que buscan denegar los servicios (DoS) en el CDE (“Cardholder Data Environment“) o bien aquellas que se producen a partir de efectos naturales (desastres).

Incluso un ataque tipo DoS podría ser utilizado únicamente como cortina de humo para cubrir un ataque que realmente busca comprometer la confidencialidad de los datos de tarjetas.

Veamos que dice la norma al respecto:

12.10.1 Desarrolle el plan de respuesta ante incidentes que se implementará en caso de que ocurra una falla del sistema. Asegúrese de que el plan aborde, como mínimo, lo siguiente:

  • Roles, responsabilidades y estrategias de comunicación y contacto en caso de un riesgo que incluya, como mínimo la notificación de las marcas de pago;
  • Procedimientos específicos de respuesta a incidentes.
  • Procedimientos de recuperación y continuidad comercial.
  • Procesos de copia de seguridad de datos.
  • Análisis de requisitos legales para el informe de riesgos.
  • Cobertura y respuestas de todos los componentes críticos del sistema;
  • Referencia o inclusión de procedimientos de respuesta ante incidentes de las marcas de pago.

Desglosemos cada uno de estos puntos:

Roles, responsabilidades y estrategias de comunicación y contacto en caso de un riesgo que incluya como mínimo la notificación de las marcas de pago

Definir funciones y responsabilidades nos conduce a la conformación de equipos de respuesta a incidentes y de recuperación.

Cada una de las personas, de acuerdo a su función,  realiza tareas específicas según el Equipo en que se encuentre, pudiendo existir miembros alternos en casos de ausencia. Generalmente sus responsabilidades están ligadas al puesto y nivel jerárquico que ocupan en la organización. Cualquier modificación sobre la conformación de equipos, así como de sus roles y responsabilidades, amerita una nueva capacitación al personal que conforma tales equipos (Req. 12.10.4).

Asimismo, deberán existir Acuerdos de Entendimiento (MOUs) pactados entre TI y las diferentes áreas de la empresa que pueden necesitarse en caso de contingencia (RR.HH., Legal,  Compras, Ciberseguridad, Seguridad Física, Operaciones, etc.)

Es necesario incluir a los proveedores de servicios en las capacitaciones y simulacros de respuesta a incidentes y continuidad comercial.

Procedimientos específicos de respuesta a incidentes

  1. Procedimiento de Respuesta: Detalla todos los pasos a seguir ante una emergencia ocurrida en el CPD (Centro de Procesamiento de Datos) y/o en el rack del CDE. Debe existir personal disponible 24×7 para responder a las alertas (Req. 12.10.3).
  2. Procedimiento de Notificación: Detalla la cadena de notificaciones comunicando que el CPD (Centro de Procesamiento de Datos) y/o el CDE o ‘evidente’ desastre. Es recomendable que para efectuar la notificación de emergencia o incidente grave se utilice una herramienta de gestión de comunicaciones (en la nube u otra red independiente) que permita localizar múltiples usuarios de forma simultánea
  3. Procedimiento de Evaluación del Daño: Detalla los pasos a seguir para evaluar el perjuicio ocasionado por el evento en el CPD (Centro de Procesamiento de Datos) y/o en el CDE.
  4. Procedimiento de Declaración: Detalla los pasos a seguir para que la alta gerencia pueda declarar ‘desastre’.

Secuencia de los procedimientos de respuesta a incidentes:

Procedimientos de recuperación y continuidad comercial

  1. Procedimiento de recuperación técnica: Detalla los pasos a realizarse para la recuperación de los sistemas que soportan procesos de tarjetas de pago críticos para el negocio a partir de un sitio (CPD) alternativo. La norma PCI DSS no establece la distancia geográfica que se debe mantener entre ambos sitios (primario y secundario), lo que sí se debe considerar es que ambos sitios no se encuentren expuestos a las mismas amenazas (Req. 12.10.6).
  2. Procedimiento de operaciones en contingencia: Detalla los pasos a seguir para operar en el Sitio (alterno) de Recuperación durante el período de contingencia, restringido a procesos de negocios críticos y los sistemas del CDE que los soportan.
  3. Procedimiento de restauración (rollback): Detalla los pasos para lograr la restauración de la operatoria del CPD (Centro de Procesamiento de Datos) y/o centro de comunicaciones original.

Secuencia de los procedimientos de recuperación y continuidad:

Procesos de copia de seguridad de datos

Las copias de seguridad de los sistemas informáticos que contengan el PAN (número de cuenta principal), se realizarán de forma cifrada tal como se especifica en el Req. 3.4 de la norma PCI DSS.

El transporte o replicación de las copias de seguridad entre los distintos edificios de la organización y empresas externas, se realizará con los niveles de seguridad necesarios en cada caso.

La recuperación sólo debe ser realizada por personal autorizado por la gerencia. Se debe mantener el registro (fichero de log) de todas las sesiones de restore ejecutadas (incluidas fallidas o de prueba) según la configuración normal del log de cada herramienta y en todo caso por un plazo mínimo de 3 meses (en sitio) y al menos 1 año en histórico (Req. 10.7).

El inventario de soportes para copias de respaldo (cintas o discos) debe contener la siguiente información (Req. 2.4 y Req. 9.7 de la norma PCI DSS):

  • Identificación del soporte
  • Tipo de soporte
  • Propietario
  • Ubicación física
  • Información de contacto
  • Datos generales del contenido (por seguridad, no se describe en detalle).
  • Fecha de caducidad del fichero soportado, si corresponde (en caso de reutilización, eliminación o destrucción).

Análisis de requisitos legales para el informe de riesgos

Es necesario mantener actualizado en coordinación con el área legal de la empresa, un inventario de aquellas leyes y decretos locales que de alguna manera directa o indirecta pueden afectar a los datos de tarjetahabientes o componentes del CDE.

Asimismo, se recomienda que los procesos de análisis de impacto al negocio y de análisis de riesgos interactúen entre sí, a fin de brindar resultados consistentes, independientemente de qué proceso se realice primero.

Cobertura y respuestas de todos los componentes críticos del sistema

Si bien todos los componentes del CDE son sensibles por naturaleza del PAN, esto no quiere decir que necesariamente sean catalogados como críticos para la continuidad del negocio en condiciones adversas (Ej. luego de un desastre), por lo que determinar qué componentes son críticos y cuáles no, es de vital importancia para elaborar una estrategia efectiva de recuperación de las operaciones, en este sentido, el BIA (Análisis de Impacto al Negocio), es una herramienta que tiene como entrada, cada uno de los servicios involucrados en tarjetas de Pago, y retorna como salida, el inventario de servicios y componentes críticos así como aquellos servicios y componentes asumibles (no críticos para el negocio).

Asimismo, el Anexo A3: Validación suplementaria de las entidades designadas, en su punto A3.1.3.a, establece:

  • Gestionar el análisis del impacto comercial para determinar los posibles impactos de la PCI DSS para las decisiones comerciales estratégicas.

Un error muy común al momento de elaborar BIAs es realizarlos sobre componentes físicos o sistemas del CDE en lugar de realizarlo sobre servicios que el negocio ofrece interna o externamente como parte del proceso de tarjetas de pago.

Este análisis de impacto puede traducirse en un cuestionario realizado con el dueño del proceso de tarjetas de pago o con un usuario líder del servicio específico en el CDE (siempre y cuando luego sea aprobado por el dueño del proceso), con el objeto de recopilar los siguientes datos:

Servicio de Ejemplo para el BIA: Alta de Tarjetas de Crédito

  • Identificar el nombre de la Aplicación que se ejecuta como parte del servicio a analizar.
  • Enumerar otras áreas de la organización que consumen este servicio
  • Determinar el ejecutivo Responsable funcional del servicio
  • Determinar el ejecutivo Responsable técnico (TI) de brindar soporte al servicio
  • Señalar las Ubicaciones donde se encuentran las personas que operan este servicio
  • Determinar el MTPD, Periodo máximo de inactividad que el negocio está dispuesto a tolerar.
  • Determinar el RTO, tiempo requerido de recuperación en contingencia, desde la interrupción del servicio. Este dato en ningún caso puede ser mayor que el MTPD.
  • Determinar el RPO, pérdida de datos que el negocio está dispuesto a ‘sacrificar’ en caso de desastre.
  • Señalar la Cantidad de usuarios requeridos en contingencia
  • Determinar Impactos (Económicos, operativos, reputacionales, laborales, legales, regulatorios o de las marcas), durante las primeras horas, días, semanas, y meses de indisponibilidad. Tomar en cuenta que el nivel de impacto se incrementa a medida que pasa el tiempo de inactividad, o en el mejor de los casos se mantiene en el mismo nivel, pero en ningún caso puede ser menor.
  • Determinar Impactos (Económicos, operativos, reputacionales, laborales, legales, regulatorios o de las marcas) por divulgación de información, pudiendo afectar a la continuidad de las operaciones de negocio
  • Determinar Impactos (Económicos, operativos, reputacionales, laborales, legales, regulatorios o de las marcas) por alteración no autorizada de información, pudiendo afectar a la continuidad de las operaciones de negocio
  • Señalar si el servicio actualmente tiene un Plan de Recuperación de Desastres (PRD) implementado o no. En caso de no contar con un plan de recuperación y que el punto anterior haya determinado que este servicio tiene un impacto crítico para el negocio, es necesario empezar a dimensionar los recursos necesarios para poder incluirlo en el PRD. En caso de que el servicio resulte no crítico, es decir, asumible para el negocio, no es necesario que el servicio cuente con un PRD.
  • Enumerar otros servicios requeridos para que el servicio en cuestión pueda funcionar correctamente
  • Enumerar proveedores necesarios para garantizar la operatividad del servicio en contingencia
  • Señalar si los datos de tarjetahabientes se puedan recuperar desde otro medio diferente a las cintas de respaldo.
  • Señalar la cadencia, o periodo de tiempo en que la criticidad del servicio llega a su pico de relevancia.
  • Estimar una línea de tendencia para los próximos doce meses (mayor cantidad de transacciones, usuarios, volumen de datos de tarjetahabientes, etc.)

Al margen del BIA para servicios de tarjetas de pago, se realiza un BIA con el área de TI para determinar la infraestructura, servicios básicos y plataformas críticas que dan soporte a las aplicaciones de tarjetas de pago determinadas críticas para el negocio.

La triste realidad es que muchas organizaciones no cuentan con un sitio alternativo con las mismas capacidades de equipamiento tecnológico y de controles tanto físicos y lógicos con los que sí se cuentan en el sitio principal por lo que habrá que trabajar fuertemente en los controles compensatorios.

Asimismo, el negocio debe considerar que un periodo prolongado de operación en contingencia puede traer consecuencias funestas para mantener la certificación, ya que muy pocas veces se cuenta con ambientes de desarrollo y prueba en sitios de contingencia, mucho menos separados del ambiente productivo en contingencia.

Referencia o inclusión de procedimientos de respuesta ante incidentes de las marcas de pago

Es necesario incluir en los procedimientos técnicos, guías de actuación en caso de incidentes específicos relacionados con tarjetas de pago, ejercitando estos posibles escenarios en las pruebas anuales de continuidad del negocio. La descripción detallada del supuesto escenario debe estar documentada y ser comunicada a los miembros de los equipos de respuesta a incidentes, con la debida anticipación para estar preparados ante el ejercicio anual, la documentación del escenario recreado deberá adjuntarse en el informe de resultados del ejercicio, con el fin de exponer si se lograron los objetivos ante el supuesto escenario de tarjetas de pago comprometidas.

12.10.2 Revise y pruebe el plan, incluidos todos los elementos enumerados en el Requisito 12.10.1, al menos anualmente

Es necesario elaborar un informe sobre el ejercicio de continuidad realizado, señalando el porcentaje de componentes críticos que fueron tomados en cuenta para la prueba,  los tiempos de recuperación de los servicios de tarjetas de pago críticos, porcentajes de cumplimiento de los RPOs, posibles incidencias en las notificaciones, comunicaciones y procesos de recuperación, así como la participación total de los usuarios críticos.  Se recomienda que cada año el ejercicio recree un diferente escenario, con afectación total o parcial del CDE, ej. un año el ejercicio puede estar basado sobre el supuesto escenario de un ataque de DoS sobre el CDE u otro ataque similar que se haya dado recientemente en la industria, y el siguiente año el escenario puede ser un desastre natural (inundación) en el CPD afectando al rack del CDE. El informe del siguiente año, además deberá exponer que se cubrieron las incidencias identificadas en la anterior prueba, como parte de las lecciones aprendidas (Req. 12.10.6).

Existen herramientas tecnológicas para llevar un seguimiento de todas las incidencias identificadas durante el ejercicio, auditorías o incidentes reales, registrando las causas-raiz del problema, remediaciones, y evidencias de respaldo, todo como parte de las lecciones aprendidas (Req. 12.10.1.b).