Protege los datos de pacientes antes de que acaben en un informe de brecha

La exposición de ePHI activa la notificación obligatoria de brecha

Bajo HIPAA, el acceso no autorizado al historial de un solo paciente obliga a notificar la brecha al HHS y, en su caso, al propio paciente. Los fallos de control de acceso que causan estas exposiciones, como el IDOR y la autorización rota en API FHIR, son exactamente lo que Penetrify encuentra.

La HIPAA Security Rule exige pruebas periódicas

45 CFR §164.308(a)(8) exige evaluaciones técnicas y no técnicas periódicas de tus controles de seguridad. «Periódico» significa más de una vez al año cuando despliegas código cada mes, y Penetrify hace que las pruebas continuas sean económicamente viables.

Las API FHIR introducen nuevas superficies de ataque

Los estándares modernos de interoperabilidad sanitaria (FHIR R4, SMART on FHIR) crean endpoints de API que exponen datos de pacientes a gran escala. Una autorización mal configurada en un único endpoint FHIR puede exponer a toda tu población de pacientes.

45 CFR §164.308(a)(8): evaluación periódica de las salvaguardas técnicas y no técnicas

Control 10.m: test de penetración como parte del programa de gestión de vulnerabilidades

CC6.1: controles de acceso lógico con evidencias de test de penetración

A.12.6: gestión de vulnerabilidades técnicas con pruebas de seguridad periódicas

HIPAA hoy y la norma propuesta que hace explícito el pentesting

La actual HIPAA Security Rule exige una evaluación «periódica» técnica y no técnica de las salvaguardas (45 CFR §164.308(a)(8)) sin nombrar explícitamente el test de penetración, y por eso los programas de seguridad sanitarios varían tanto. Esa ambigüedad está desapareciendo: la actualización de la Security Rule propuesta por el HHS (NPRM publicada el 6 de enero de 2025) haría explícitos los requisitos, incluyendo test de penetración al menos cada 12 meses y escaneo de vulnerabilidades al menos cada seis meses.

A mediados de 2026 la norma sigue siendo una propuesta, no es definitiva, y la OCR continúa aplicando la Security Rule vigente. Pero la dirección es inequívoca, y las investigaciones de la OCR ya tratan la ausencia de pruebas técnicas como evidencia de un análisis de riesgos insuficiente, la deficiencia más citada en los expedientes sancionadores. Establecer ahora la cadencia de pruebas convierte la futura norma definitiva en un no acontecimiento; esperar significa montar un programa a contrarreloj bajo una fecha límite de cumplimiento.

Las pruebas continuas responden además mejor al criterio de «periódico» ya hoy que cualquier encargo anual: un historial documentado de escaneos a lo largo del año, cada uno con sus hallazgos y evidencias de remediación, es precisamente el tipo de evaluación continua que describe el §164.308(a)(8).

FHIR y SMART on FHIR: la interoperabilidad es una superficie de ataque

Los mandatos de interoperabilidad de EE. UU. empujaron los datos de pacientes detrás de API estandarizadas: recursos FHIR R4, autorización SMART on FHIR, exportación masiva de datos. La estandarización también ayuda a los atacantes: saben exactamente qué endpoints existen (/Patient, /Observation, /DocumentReference) y exactamente qué filtra uno mal configurado. Un único endpoint FHIR que no aplique autorización a nivel de recurso puede exponer a toda una población de pacientes y, a diferencia de un portátil robado, lo hace en silencio.

Los modos de fallo recurrentes son concretos: identificadores de recurso aceptados sin verificar la relación asistencial del usuario que consulta (IDOR a escala poblacional), scopes SMART concedidos de forma amplia y nunca aplicados por recurso, y endpoints de exportación masiva alcanzables con credenciales pensadas para acceder a un solo registro. Penetrify prueba estas fronteras de autorización igual que las sondea un atacante: entre roles, entre pacientes, entre scopes, en cada despliegue de tu API.

Penetrify prueba las fronteras de autorización en todos los roles de usuario (clínico, administrador, paciente) y busca específicamente vulnerabilidades IDOR que expongan historiales de pacientes fuera de las relaciones asistenciales autorizadas. Es la causa número uno de brechas de datos en sanidad.

Cada escaneo genera un informe con marca de tiempo y clasificado por severidad. Cuando la OCR audite tu programa de seguridad, podrás demostrar un historial documentado de pruebas de seguridad periódicas en toda tu aplicación, no un único informe anual de un momento concreto.

Penetrify prueba implementaciones de FHIR R4 y SMART on FHIR en cuanto a aplicación de fronteras de autorización, validación de scopes y control de acceso a recursos: precisamente las superficies de ataque que las herramientas DAST estándar no están configuradas para probar.

Penetrify nunca modifica, borra ni extrae datos. Prueba observando las respuestas de la aplicación, no ejecutando operaciones de escritura. Se puede usar con seguridad contra entornos de staging que replican la estructura de los datos de pacientes de producción.