Una empresa de tecnología sanitaria incorporó a un proveedor de gestión de datos clínicos cuyo informe de SOC 2 Tipo II abarcaba los criterios de control de acceso, disponibilidad y confidencialidad. El aseguramiento del SOC 2 se citó en la evaluación de TPRM como prueba de que los controles de acceso del proveedor funcionaban eficazmente. Lo que la evaluación de TPRM no verificó fue la pregunta concreta que había planteado el CISO de la empresa sanitaria: ¿puede un usuario del sistema del proveedor acceder al historial de cualquier paciente, o los controles de acceso se limitan a los pacientes concretos que cada usuario está autorizado a tratar? El SOC 2 confirmó que el programa de control de acceso del proveedor funcionaba: los usuarios se autenticaban, los accesos se registraban y las revisiones de accesos se realizaban cada trimestre. No probó si el modelo de autorización impedía que un usuario autenticado accediera a historiales de otros pacientes. Ese no era un criterio del marco de SOC 2. Durante una prueba de penetración que la empresa sanitaria encargó para el proveedor (en ejercicio de su derecho de auditoría), el evaluador se autenticó como usuario clínico estándar y accedió con éxito a historiales de pacientes ajenos a su cartera autorizada mediante una manipulación de parámetros de API que el programa de control de acceso del proveedor no había abordado. El aseguramiento del SOC 2 era válido. El control de autorización concreto que la empresa sanitaria necesitaba validar no lo había probado el SOC 2.
¿Qué es realmente el problema del aseguramiento frente a la validación?
El aseguramiento es la confianza profesional, expresada por un tercero independiente, de que un sistema de controles funciona conforme a criterios definidos, a partir de pruebas reunidas mediante métodos de evaluación estructurados. El aseguramiento de SOC 2, la certificación ISO 27001 y las atestaciones de cumplimiento de PCI-DSS aportan aseguramiento: confianza en que los controles del proveedor cumplen criterios definidos, a partir de las pruebas del auditor. La validación es la confirmación directa de que un control concreto, en una configuración concreta, previene un riesgo concreto en un contexto concreto. La diferencia está entre lo general y lo concreto: el aseguramiento opera al nivel de los marcos y los criterios, mientras que la validación opera al nivel de los controles individuales y los escenarios de ataque concretos.
La brecha de criterios es el mecanismo por el que el aseguramiento deja riesgos concretos sin validar. Todo marco de aseguramiento define los criterios que evalúa, es decir, los requisitos de control concretos que deben cumplirse para emitir la opinión de aseguramiento. Los controles y riesgos que no forman parte del marco de criterios no se evalúan ni quedan asegurados. Los Trust Services Criteria de SOC 2 abarcan categorías amplias de gestión de accesos, disponibilidad y confidencialidad, pero no especifican la prueba de todas las técnicas posibles de elusión de la autorización. Un proveedor cuyo SOC 2 confirma que los controles de acceso funcionan eficazmente puede tener un modelo de autorización con vulnerabilidades concretas que los criterios de SOC 2 no se diseñaron para detectar.
La brecha del riesgo específico de la aplicación es la manifestación más práctica para TPRM. Cada relación con un cliente crea riesgos concretos según los datos, los sistemas y los patrones de acceso concretos que intervienen. El riesgo concreto de una empresa sanitaria, el acceso a historiales de otros pacientes mediante la manipulación de parámetros de API, es un riesgo específico de la relación que un marco de cumplimiento genérico no abordará específicamente. Validar los riesgos específicos de la relación requiere pruebas dirigidas a esos riesgos concretos en el contexto concreto de la relación con el proveedor, no el aseguramiento de un marco que define sus propios criterios con independencia del perfil de riesgo de cualquier cliente concreto.
- Criterios del marco de aseguramiento que no cubren el riesgo concreto del cliente
- Escenarios de ataque específicos de la relación que no figuran en los criterios de cumplimiento
- La elusión de la autorización de API no es un criterio de SOC 2
- Brechas de control de acceso específicas de la aplicación que el aseguramiento genérico pasa por alto
- No se realiza una validación directa de los escenarios específicos del cliente de mayor riesgo
Por qué es importante
El aseguramiento frente a la validación es importante para TPRM porque los riesgos concretos que crean las relaciones con los clientes (los datos concretos que exponen, los patrones de acceso concretos que permiten, los escenarios de ataque concretos más relevantes) con frecuencia no forman parte de los criterios de los marcos de cumplimiento que aportan las principales pruebas de aseguramiento. El aseguramiento del cumplimiento confirma el programa de control genérico. El riesgo específico del cliente requiere una validación específica.
La dimensión de los datos regulados hace que esto sea especialmente grave. Los tipos de datos regulados (la PHI en el sector sanitario, los PII en virtud del GDPR, los datos de titulares de tarjetas en virtud de PCI-DSS, los datos financieros en virtud de la normativa financiera) generan requisitos concretos de control de acceso que pueden no estar plenamente representados en los criterios del marco de cumplimiento general de un proveedor. Un proveedor cuyo SOC 2 confirma que los controles de acceso funcionan puede no haber sido probado específicamente frente a los requisitos de autorización que se aplican al tipo concreto de datos regulados que comparte el cliente.
Dónde se equivocan la mayoría de los equipos
El fallo más habitual es aceptar el aseguramiento como validación del riesgo concreto del cliente. El aseguramiento responde a la pregunta del marco. La validación responde a la pregunta del cliente. Ambas preguntas pueden tener respuestas distintas para un mismo proveedor.
- Aceptar el aseguramiento como validación del riesgo específico del cliente
- Criterios del marco tratados como cobertura del riesgo del cliente
- Sin validación del riesgo específico del cliente para los escenarios de mayor riesgo
- Derecho de auditoría no utilizado para pruebas de validación específicas
- Escenarios de ataque específicos de la relación no probados
Cómo se ve una buena práctica
Los programas maduros de aseguramiento y validación usan el aseguramiento del cumplimiento como base para comprender el entorno de control general y lo complementan con pruebas de validación específicas para los escenarios específicos del cliente de mayor riesgo, mediante pruebas de penetración, pruebas de seguridad de API y ejercicios específicos del derecho de auditoría para validar los controles concretos que exige el perfil de riesgo del cliente.
- El aseguramiento como base y la validación como complemento: el cumplimiento aporta confianza general y la validación aborda riesgos concretos
- Escenarios de riesgo específicos del cliente identificados: qué ataques concretos afectarían más a esta relación
- Pruebas de validación específicas para los escenarios concretos de mayor riesgo
- Derecho de auditoría ejercido con fines de validación, orientado a cuestiones de riesgo específicas del cliente
- Hallazgos de validación que alimentan el registro de riesgos junto con la evaluación basada en el aseguramiento
Herramientas
Pruebas de seguridad de aplicaciones: Burp Suite, OWASP ZAP, pruebas de seguridad de API
Las herramientas de pruebas de seguridad específicas de aplicaciones permiten validar vulnerabilidades concretas de control de acceso y de autorización que las pruebas de los marcos de cumplimiento no abordan. Para los profesionales de TPRM, encargar pruebas de seguridad de API específicas centradas en los riesgos concretos de control de acceso de la relación con el proveedor aporta las pruebas de validación que el aseguramiento de SOC 2 no puede aportar.
Pruebas de penetración: ejercicios específicos del derecho de auditoría
Las pruebas de penetración dirigidas, encargadas como ejercicios del derecho de auditoría y centradas en escenarios de riesgo concretos definidos por el cliente, validan exactamente los riesgos que crea la relación con el cliente. Para los profesionales de TPRM, desarrollar escenarios de prueba específicos del cliente para las pruebas de penetración en ejercicio del derecho de auditoría permite la validación específica que las pruebas genéricas de cumplimiento no pueden producir.
Desafíos de gobernanza
El reto de gobernanza del aseguramiento frente a la validación es el costo de las pruebas de validación específicas. Las pruebas de penetración dirigidas y las evaluaciones de seguridad de aplicaciones requieren una inversión considerable por cada relación con un proveedor. La solución de gobernanza consiste en escalonar el requisito de validación según el riesgo: una validación específica exhaustiva para las relaciones de mayor riesgo, en las que el riesgo específico del cliente tiene más consecuencias, y confianza en el aseguramiento para las relaciones de menor riesgo, en las que los criterios del marco son un indicador suficiente del riesgo del cliente.
- Identifique los dos o tres escenarios de riesgo específicos del cliente más importantes para cada relación de alto riesgo
- Encargue pruebas de validación específicas para esos escenarios concretos
- Use el derecho de auditoría para la validación, no solo para la atestación
- Distinga lo que SOC 2 ha probado y lo que no para la relación concreta con el proveedor
- Documente la brecha de validación: qué riesgos concretos cubre el aseguramiento y cuáles requieren validación directa
Si usted forma parte de un equipo pequeño
Para su proveedor de mayor riesgo, anote el escenario de ataque concreto que más daño causaría a sus clientes si tuviera éxito en ese proveedor: el patrón de acceso concreto, el tipo de datos concreto, la vía de explotación concreta. Después, pregunte si el informe de SOC 2 o la evaluación de ISO 27001 más reciente del proveedor probó específicamente ese escenario. Si la respuesta es no o no está clara, ha identificado la brecha de validación. Ese escenario concreto es el alcance de una prueba específica en ejercicio del derecho de auditoría que valide lo que el aseguramiento del cumplimiento no valida.
- Identifique el escenario de ataque más dañino para cada relación con un proveedor de alto riesgo
- Compruebe si el aseguramiento del cumplimiento probó específicamente ese escenario
- Encargue pruebas de validación específicas para los escenarios de alta prioridad no validados
- Use el derecho de auditoría para una validación específica de cada escenario
Qué exigir
Pregunte directamente:
“Hemos identificado [escenario de ataque concreto, p. ej., manipulación de parámetros de API que permite el acceso a datos de otros clientes] como el escenario de mayor riesgo para nuestra relación. ¿Su SOC 2 o su prueba de penetración más reciente probó específicamente este escenario? En caso contrario, ¿daría su consentimiento para una prueba dirigida de este escenario concreto en virtud de nuestra cláusula de derecho de auditoría?”
Evidencia que debe esperar
- Confirmación de si el escenario concreto se probó en las evaluaciones existentes
- Consentimiento para pruebas de validación específicas de los escenarios no validados
- Resultados de pruebas anteriores si el escenario se evaluó
- Pruebas de la corrección si el escenario se había identificado previamente como brecha
A un proveedor que confirme el aseguramiento de los controles de acceso de SOC 2 se le debe preguntar si se ha probado específicamente el escenario de acceso más relevante para los datos del cliente. El aseguramiento cubre los criterios. La validación cubre el escenario.
Cómo demostrarlo
- Registros de identificación de escenarios de riesgo específicos del cliente
- Registros de las pruebas de validación específicas
- Documentación de la brecha de validación
- Registros del ejercicio del derecho de auditoría con fines de validación
Conclusión clave
El aseguramiento responde a la pregunta del marco. La validación responde a la pregunta del cliente. El SOC 2 confirmó que los controles de acceso funcionan: autenticación, registro, revisiones. La prueba de penetración descubrió que un usuario autenticado podía acceder al historial de cualquier paciente mediante la manipulación de parámetros de API. Ambos hallazgos son ciertos. El marco de aseguramiento no planteó la pregunta del cliente. Solo lo hicieron las pruebas de validación específicas. Identifique los escenarios de riesgo específicos del cliente. Compruebe si el aseguramiento existente los ha probado. Encargue pruebas de validación para los que no. El marco aporta la base. El riesgo concreto del cliente requiere el complemento.