EAU · Abu Dabi · Sanidad

Pruebas de penetración ADHICS para la sanidad de Abu Dabi

La sanidad es el sector donde una evaluación de seguridad tiene que diseñarse en torno a la restricción de que no se puede tirar el sistema. ADHICS fija las expectativas de control para los proveedores de Abu Dabi y sus suministradores; probar contra él tiene tanto que ver con cómo se prueba como con lo que se encuentra.

Qué cubre ADHICS

El estándar Abu Dhabi Healthcare Information and Cyber Security fija las expectativas de control para las entidades sanitarias que operan bajo el Department of Health del emirato y para los suministradores tecnológicos que les prestan servicio. Abarca gobernanza, control de acceso, gestión de activos, respuesta a incidentes y protección de datos clínicos y de pacientes, con requisitos de evaluación de seguridad y de evidencias que lo recorren de principio a fin.

El alcance llega más lejos que los hospitales. Fabricantes de historias clínicas electrónicas, plataformas de telemedicina, sistemas de laboratorio e imagen, procesadores de siniestros y seguros y los integradores que los cablean entre sí acaban todos dentro del alcance, normalmente a través del requisito contractual de un proveedor y no de una relación directa con el regulador. Si su software toca datos de pacientes de Abu Dabi, la obligación le encuentra a través de compras.

Probar en sanidad sin interrumpir la asistencia

Cualquier otra página de cumplimiento puede tratar el dimensionamiento como una cuestión comercial. Aquí es una cuestión de seguridad clínica, y se resuelve antes que ninguna otra cosa.

La hipótesis de partida es que nada en un entorno clínico es seguro de romper:

  • Sin pruebas de denegación de servicio y sin explotación automatizada contra sistemas clínicos. Nunca.
  • Sin escaneo agresivo de dispositivos médicos, monitorización de pacientes ni nada conectado a ellos: los dispositivos conectados fallan de forma impredecible bajo escaneo de maneras que el equipamiento de TI general no.
  • Ventanas de prueba acordadas en torno a la carga clínica, con un contacto clínico designado localizable durante todo el proceso y una vía de aborto inmediata que no requiera convocar una reunión.
  • Réplicas de staging cuando probar en vivo no sea apropiado, documentando con honestidad la diferencia entre staging y producción en lugar de disimularla.

Todo esto se incorpora a unas reglas de enfrentamiento escritas y firmadas antes de comenzar. Cuando un sistema genuinamente no pueda probarse de forma segura de ninguna manera, la respuesta correcta es una revisión de configuración y arquitectura más una justificación documentada, y no una prueba agresiva ejecutada con cuidado y encomendada a la suerte.

Dónde está el riesgo real

Los entornos clínicos comparten un conjunto de características que determinan qué debe buscar una prueba útil:

  • Redes planas. Los parques clínicos crecen por adición, y la segmentación entre redes administrativas, clínicas y de dispositivos es con frecuencia más fina de lo que sugiere el diagrama de arquitectura. Establecer qué es realmente alcanzable desde una estación de trabajo general suele ser el hallazgo de mayor valor en un encargo sanitario.
  • Dispositivos no parcheables. Equipamiento médico conectado que funciona con sistemas operativos sin soporte que no pueden actualizarse sin revalidación. Esto no se va a arreglar, así que el hallazgo que importa no es el parche que falta: es si el dispositivo está aislado de todo lo que podría alcanzarlo.
  • Integraciones. La sanidad funciona sobre interfaces entre sistemas: flujos HL7 y FHIR, conexiones de laboratorio e imagen, enlaces de seguros y siniestros. La autenticación y la autorización de esas interfaces son habitualmente más débiles que las de las aplicaciones de usuario, porque se construyeron entre partes de confianza sobre una red de confianza, y esa hipótesis dejó de ser cierta hace tiempo.
  • Dispersión de identidades. Inicios de sesión clínicos compartidos, cuentas de larga vida de personal que ya se fue, cuentas de acceso remoto de proveedores con privilegio permanente. En términos de Active Directory este es terreno fértil, y es la forma en que una sola estación de trabajo comprometida se convierte en un problema de todo el parque.
  • Acceso remoto de proveedores. Suministradores con acceso permanente a los sistemas clínicos con fines de soporte. El compromiso de cualquiera de ellos es un compromiso suyo, que es exactamente por lo que los proveedores ahora trasladan los requisitos de prueba a su cadena de suministro.

Alcance del encargo

Típicamente: pruebas de red externa sobre el parque expuesto a internet, incluidos portales de pacientes e infraestructura de acceso remoto; pruebas de aplicaciones web y APIs contra portales, sistemas de cita, plataformas de telemedicina y las interfaces de integración que hay detrás; pruebas de red interna centradas en segmentación y alcanzabilidad más que en explotación; revisión de Active Directory cubriendo privilegio, cuentas obsoletas y acceso de proveedores; y evaluación de nube cuando los datos clínicos o de pacientes residan en un tenant de nube.

Para suministradores y no proveedores, el alcance suele estrecharse a la plataforma en sí más su superficie de integración, que es lo que el equipo de compras del proveedor está realmente preguntando.

Apilarse con NESA y la PDPL

ADHICS rara vez se aplica solo. La sanidad está designada infraestructura crítica de información, así que los Information Assurance Standards de NESA se aplican habitualmente junto a él, incluida la expectativa de retest a 90 días para hallazgos críticos y altos y la revisión de las credenciales de quien prueba. La PDPL federal añade obligaciones de protección de datos allí donde se traten datos personales, lo que en un contexto sanitario es en todas partes.

Dimensionado contra los tres desde el inicio, un encargo produce un cuerpo de pruebas y tres conjuntos de evidencias mapeadas. Dimensionado contra uno y adaptado después, suele implicar volver a probar, así que cuénteme en la primera conversación todos los regímenes a los que está sujeto.

El entregable

Un resumen ejecutivo escrito tanto para una audiencia de gobernanza clínica como técnica, un cuerpo técnico con pasos de reproducción y valoraciones CVSS, y el mapeo a los controles ADHICS que afecta cada hallazgo, más NESA y PDPL cuando apliquen. Los hallazgos se priorizan por impacto clínico y no solo por CVSS, porque un problema de severidad media en un sistema que afecta a la atención al paciente está por encima de uno de severidad alta en una web de marketing, y un informe que no hace esa distinción no le sirve a un hospital.

Después, soporte de remediación, un retest y una carta de atestación, que para los suministradores es con frecuencia el documento que desbloquea el proceso de compras. Un informe de muestra enseña el formato.

Cuestiones prácticas

En remoto desde Ammán, una hora por detrás de Abu Dabi, la misma semana laboral, en árabe o inglés. Las pruebas internas se ejecutan sobre una VPN o un jump host dentro de su entorno, dentro de las ventanas acordadas. Las credenciales —solicitadas tanto por los assessors de NESA como por las compras hospitalarias— son OSCP+, eCPPT, eWPT, eCIR, AZ-500, SC-200 y SC-300, todas verificables a través de la credential wallet de OffSec.

Siguientes pasos

Dígame si es proveedor o suministrador, qué incluye el entorno y si alguna parte está clínicamente en vivo. La primera conversación trata de qué puede probarse con seguridad y qué necesita un enfoque distinto; eso se resuelve antes de cualquier presupuesto, porque determina el alcance. Póngase en contacto: el árabe es bienvenido.

Relacionado: pruebas de penetración en los EAU, requisitos de NESA y la visión general de cumplimiento.

Preguntas sobre ADHICS

A los proveedores sanitarios que operan en Abu Dabi bajo el Department of Health y a los suministradores tecnológicos que les prestan servicio, lo que arrastra a un amplio abanico de empresas que no son clínicas en sí mismas: fabricantes de historias clínicas electrónicas, plataformas de telemedicina, sistemas de laboratorio e imagen, procesadores de seguros y siniestros, y los integradores que los conectan. Si maneja datos de pacientes de Abu Dabi o se conecta al entorno de un proveedor, normalmente está en el alcance a través de la obligación de su cliente, incluso sin relación directa con el regulador.

Sí, y es lo primero que hay que acordar. El enfoque consiste en asumir que nada es seguro de romper: sin pruebas de denegación de servicio, sin explotación automatizada contra sistemas clínicos, sin escaneo agresivo de dispositivos médicos ni de nada conectado a la monitorización de pacientes, y con ventanas de prueba acordadas en torno a la carga clínica. Cuando un sistema sea demasiado sensible para probarlo en vivo, las alternativas son una réplica de staging, una revisión de configuración y arquitectura, o pruebas manuales cuidadosamente acotadas con un contacto clínico designado y una vía de aborto inmediata. Las reglas de enfrentamiento se redactan y firman antes de empezar nada.

Hay que identificarlos y tratarlos como frágiles por defecto. Los dispositivos médicos conectados funcionan con frecuencia sobre sistemas operativos sin soporte que no pueden parchearse, fallan de forma impredecible bajo escaneo y residen en redes más planas de lo que nadie espera. El trabajo valioso ahí suele ser de alcanzabilidad más que de explotación: establecer qué dispositivos son alcanzables desde dónde, si están segmentados de la red general y qué podría hacer un atacante que llegara a ese segmento. Eso responde a la pregunta real de riesgo sin tocar nunca un dispositivo conectado a un paciente.

Se apilan. ADHICS es el estándar sectorial para la sanidad de Abu Dabi; la sanidad está designada infraestructura crítica de información, así que los Information Assurance Standards de NESA se aplican habitualmente junto a él; y la PDPL federal añade obligaciones de protección de datos allí donde se traten datos personales, lo que en sanidad significa en todas partes. Un único encargo dimensionado contra los tres desde el inicio produce un solo conjunto de pruebas y tres conjuntos de evidencias mapeadas.

Cada vez más sí, y la demanda suele llegar por la vía de compras y no del regulador. Los proveedores bajo ADHICS son responsables de la seguridad de su cadena de suministro, así que trasladan el requisito hacia fuera, lo que significa que un informe de prueba de penetración independiente se está convirtiendo en condición para ganar o conservar el contrato. Para un suministrador, tener listo un informe y una atestación vigentes acorta considerablemente el proceso de compras, y no tenerlos ha empezado a hacer perder operaciones.

¿Proveedor sanitario o suministrador en Abu Dabi?

Pruebas dimensionadas en torno a la seguridad clínica, con las evidencias que piden ADHICS y sus clientes.

Contacto