El proveedor encargado del tratamiento de los datos de pago de una empresa fintech detectó un incidente de seguridad a las 8 a. m. de un lunes: su plataforma de EDR había identificado actividad inusual de PowerShell en un servidor del clúster de procesamiento de pagos. El analista de SOC del proveedor clasificó el incidente como P2 con base en los indicadores iniciales: ningún acceso a datos confirmado, un alcance limitado de la actividad anómala y una evaluación preliminar según la cual la actividad podría deberse a un script de automatización mal configurado y no a un ataque. El procedimiento de respuesta P2 del proveedor preveía un período de investigación de doce horas antes de escalar a P1 si se confirmaba, y en el procedimiento P2 la notificación al cliente se producía a las treinta y seis horas si el incidente se confirmaba como un evento de seguridad real que afectaba a datos de clientes. A la hora doce, la investigación confirmó que la actividad era maliciosa: un ataque basado en credenciales contra el servidor de pagos. El incidente se escaló internamente a P1, pero la notificación al cliente siguió el calendario del procedimiento P2 porque el proceso de reclasificación requería una aprobación de la dirección que no se completó hasta la hora treinta. La notificación al cliente se produjo a la hora treinta y seis. El equipo regulatorio de la empresa fintech, al recibir la notificación, se dio cuenta de inmediato de que su obligación de notificación de incidentes conforme a PCI-DSS llevaba corriendo desde la detección inicial del proveedor en la hora cero. Ahora tenía treinta y seis horas para completar una notificación que PCI-DSS exigía en un plazo de setenta y dos horas desde que la 'parte responsable' tuvo conocimiento del incidente.
¿Qué es realmente el problema de la escalada de incidentes entre proveedores?
La escalada de incidentes entre proveedores es el desafío de garantizar que los incidentes de seguridad en los entornos de los proveedores que afectan a los datos de los clientes se escalen al cliente, y a las autoridades regulatorias, en plazos que satisfagan las obligaciones regulatorias del cliente, y no solo los SLA internos de gestión de incidentes del proveedor. Los marcos de gestión de incidentes de los proveedores clasifican los incidentes por gravedad y asignan SLA de respuesta calibrados según las prioridades operativas del proveedor. Estas clasificaciones y SLA internos pueden no coincidir con los plazos regulatorios de notificación aplicables a los datos del cliente.
El problema de la desalineación de la clasificación es la falla central de la escalada. Los equipos de gestión de incidentes de los proveedores clasifican los incidentes según su impacto operativo en el entorno del proveedor: interrupción del servicio, disponibilidad de los sistemas y gravedad de la violación de datos confirmada. Es posible que no clasifiquen un incidente según sus implicaciones para las obligaciones regulatorias de notificación del cliente, que pueden activarse con cualquier acceso a datos regulados, independientemente del impacto en el servicio o de que se haya confirmado una exfiltración. Un incidente que el proveedor clasifica como P2 porque aún no ha confirmado la exfiltración de datos puede haber activado ya el reloj de notificación de setenta y dos horas de GDPR del cliente a raíz del acceso no autorizado inicial a un sistema que contiene datos personales de clientes.
El problema de la notificación en cascada es la dimensión del momento regulatorio. El artículo 33 del GDPR exige notificar a la autoridad de control dentro de las setenta y dos horas siguientes a que el responsable del tratamiento 'tenga constancia' de una violación de la seguridad de los datos personales. El responsable del tratamiento suele tener constancia cuando el encargado del tratamiento se lo notifica. El encargado del tratamiento tiene constancia cuando su equipo de seguridad detecta el incidente. El intervalo entre la detección por parte del encargado y la notificación al responsable, determinado por los procedimientos internos de escalada y notificación del proveedor, determina directamente cuánto queda del plazo de setenta y dos horas cuando el cliente recibe la notificación. Un proveedor que notifica a la hora treinta y seis deja al cliente treinta y seis horas para una notificación que requiere revisión jurídica, evaluación del alcance y presentación ante el regulador.
- La clasificación del proveedor no activa la notificación inmediata al cliente: procedimientos de P2 con notificación tardía al cliente
- El reloj regulatorio empieza a correr con la detección por parte del proveedor: la obligación del cliente corre durante la investigación del proveedor
- Demoras por reclasificación: procesos internos de aprobación que ralentizan la escalada
- Sin participación del cliente en la clasificación de incidentes: el proveedor determina la prioridad de la notificación de forma unilateral
- El plazo regulatorio del cliente no figura en los criterios de P1 del proveedor: el proveedor no sabe qué convierte esto en un P1 para el cliente
Por qué es importante
La escalada de incidentes entre proveedores es importante para TPRM porque las obligaciones regulatorias del cliente las determina la ley, no la clasificación de incidentes del proveedor. GDPR, PCI-DSS, la notificación de incidentes en servicios financieros y los requisitos sectoriales de notificación de violaciones establecen plazos de notificación a partir de eventos desencadenantes definidos, y esos plazos corren desde que la parte correspondiente tiene conocimiento, no desde que el cliente recibe la notificación del proveedor. Los proveedores cuyos procedimientos internos de escalada retrasan la notificación al cliente consumen el margen regulatorio del cliente.
La brecha de calibración contractual del SLA es la solución de gobernanza. Los contratos que exigen la notificación del proveedor 'dentro de las setenta y dos horas posteriores a una violación de datos confirmada' dejan a criterio del proveedor qué se considera 'confirmada', lo que puede ocurrir bastante después del momento en que empezó a correr el reloj regulatorio del cliente. Los contratos que exigen la notificación dentro de las veinticuatro horas posteriores a que el proveedor detecte cualquier acceso no autorizado a sistemas que contienen datos de clientes alinean el desencadenante de la notificación con el evento que pone en marcha el reloj regulatorio y no con la conclusión de la investigación del proveedor.
Dónde se equivocan la mayoría de los equipos
La falla más constante es no comprender que el reloj regulatorio de notificación del cliente empieza a correr con la detección por parte del proveedor, no con la notificación del proveedor. Los SLA de notificación que parecen generosos en términos absolutos pueden ser insuficientes cuando consumen la mayor parte del margen regulatorio del cliente.
- No se comprende que el reloj regulatorio del cliente empieza a correr con la detección por parte del proveedor
- SLA de notificación calibrado según el proceso del proveedor y no según el plazo regulatorio del cliente
- Desencadenante de clasificación no especificado: qué constituye un P1 desde la perspectiva regulatoria del cliente
- Sin participación del cliente en los criterios de P1: el proveedor define la escalada sin desencadenantes regulatorios específicos del cliente
- SLA de notificación no contrastado con el requisito regulatorio más estricto del cliente
Cómo se ve una buena práctica
Los marcos de escalada maduros definen criterios de P1 que incorporan los desencadenantes regulatorios del cliente (cualquier acceso no autorizado a sistemas que contienen datos regulados de clientes es automáticamente P1, independientemente de que se haya confirmado la exfiltración) e incorporan al contrato la notificación preliminar en cuestión de horas, y no de días, desde la detección.
- Desencadenantes de P1 específicos del cliente: cualquier acceso no autorizado a sistemas que contienen datos regulados
- Notificación preliminar en cuestión de horas, no de días, desde la detección
- Plazo regulatorio incorporado al SLA: la notificación debe dejar al cliente tiempo suficiente para cumplir su obligación
- Sin requisito de conclusión de la investigación como desencadenante de la notificación inicial
- Contexto regulatorio del cliente proporcionado al proveedor: el proveedor sabe qué desencadenantes son P1 para el cliente
Herramientas
Gestión de incidentes: PagerDuty, ServiceNow Security Incident Response
Las plataformas de gestión de incidentes con flujos de notificación al cliente pueden configurarse para activar rutas de escalada específicas del cliente cuando se clasifican incidentes que afectan a sistemas con datos de clientes. Para los profesionales de TPRM, preguntar si la plataforma de gestión de incidentes del proveedor tiene configuraciones de escalada específicas para cada cliente plantea una pregunta específica sobre el diseño de la escalada.
Desafíos de gobernanza
El desafío de gobernanza de la escalada entre proveedores es la autonomía de clasificación del proveedor. Los proveedores no aceptarán que el cliente les dicte su sistema interno de clasificación de incidentes. El enfoque contractual, que especifica desencadenantes y plazos de notificación independientes de la clasificación del proveedor, logra el objetivo del cliente sin exigir que el proveedor cambie su marco interno de clasificación.
- Defina el desencadenante de la notificación como un evento y no como una clasificación: cualquier acceso no autorizado a datos regulados
- Especifique el SLA de notificación preliminar: horas, no días
- Calibre el SLA según el requisito regulatorio más estricto del cliente
- Proporcione al proveedor los indicadores de P1 específicos del cliente: qué se escala de inmediato en el caso de este cliente
- Pruebe el plazo de notificación frente al plazo regulatorio, con un margen
Si usted forma parte de un equipo pequeño
Revise su requisito regulatorio de notificación más estricto: las setenta y dos horas de GDPR, el plazo de notificación de PCI-DSS o la notificación de incidentes en servicios financieros. Luego revise el SLA de notificación de su proveedor. Calcule la diferencia: si el proveedor notifica al final de su SLA, ¿cuánto tiempo le queda al cliente para su propia notificación regulatoria? Si la respuesta es menos de veinticuatro horas para cualquier proveedor de nivel 1, el SLA de notificación debe renegociarse.
- Calcule el tiempo que le queda al cliente una vez concluido el SLA de notificación del proveedor
- Renegocie cuando el tiempo restante sea insuficiente para el cumplimiento regulatorio
- Defina el desencadenante de la notificación como un evento y no como una clasificación: cualquier acceso no autorizado
- Proporcione al proveedor los desencadenantes de escalada específicos del cliente
Qué exigir
Pregunte directamente:
"Con su proceso actual de gestión de incidentes, si su SOC detecta un acceso no autorizado al servidor que contiene nuestros datos de pago a las 8 a. m. del lunes, ¿cuál es el plazo hasta nuestra notificación, y nos deja ese plazo tiempo suficiente para cumplir nuestra obligación regulatoria de notificación de setenta y dos horas?"
Evidencia que debe esperar
- Criterios de clasificación de incidentes para los sistemas relevantes para el cliente
- Plazo de notificación preliminar desde la detección
- Confirmación de que el SLA de notificación está calibrado según el plazo regulatorio del cliente
- Criterios de P1 específicos del cliente
A un proveedor con SLA de gestión de incidentes definidos se le debe plantear la pregunta del escenario concreto: detección a las 8 a. m. del lunes, ¿notificación al cliente para cuándo? La respuesta revela si el SLA deja tiempo suficiente para la respuesta regulatoria.
Cómo demostrarlo
- Registros de calibración según los plazos regulatorios
- Análisis de la suficiencia del SLA de notificación
- Documentación de los criterios de P1 específicos del cliente
- Documentación contractual de los desencadenantes de escalada
Conclusión clave
El reloj regulatorio empieza a correr cuando el proveedor detecta el incidente. La obligación de notificación del cliente corre desde la detección por parte del proveedor, no desde que el cliente recibe la notificación del proveedor. Un proveedor que notifica a la hora treinta y seis deja al cliente treinta y seis horas para una notificación que requiere revisión jurídica, evaluación del alcance y presentación ante el regulador. El SLA que parece suficiente de forma aislada consume en la práctica el margen regulatorio. Defina el desencadenante de la notificación como el evento: cualquier acceso no autorizado a datos regulados. Especifique en horas el SLA de notificación preliminar. Calíbrelo según el tiempo que necesita el cliente, una vez recibida la notificación, para cumplir su propia obligación. Póngalo a prueba con el escenario: detección el lunes por la mañana, ¿presentación regulatoria del cliente para cuándo?