Pocas industrias enfrentan un cóctel de riesgo como la salud mexicana. Un hospital que digitaliza expedientes, conecta dispositivos médicos a su red interna y abre un portal para pacientes opera tres regulaciones al mismo tiempo: la LFPDPPP sobre datos personales sensibles, la NOM-024-SSA3 sobre el expediente clínico electrónico y el deber de continuidad clínica que ningún paciente perdona.
El pentesting para el sector salud, también llamado pruebas de penetración hospitalarias, es la simulación controlada de un ciberataque real contra los sistemas de un hospital o clínica, con el objetivo de identificar vulnerabilidades en aplicaciones, redes, APIs y dispositivos médicos antes de que un atacante real las explote. Su valor es descubrir, antes que los ciberdelincuentes, las brechas que ningún manual de cumplimiento puede ver desde un escritorio.
La presión regulatoria sube cada año y los números acompañan. En el primer semestre de 2025, México registró 40.6 millones de intentos de ciberataques y se ubicó como el segundo país más atacado de América Latina, según el Informe Global de Amenazas de Fortinet.
Especialistas del sector estiman que el 50% de los centros de salud en el país ya sufrió al menos una violación de datos, y el FBI documenta que el 53% de los dispositivos médicos conectados arrastra vulnerabilidades críticas conocidas.
Este artículo explica, desde la mirada de un equipo que ejecuta pentests en instituciones médicas mexicanas, qué evalúa un pentest hospitalario, cómo se ejecuta sin detener la atención clínica y qué evidencia técnica entrega para auditores de NOM-024-SSA3 y LFPDPPP.
- 01 ¿Por qué es vital el pentesting en hospitales?
- 02 Ciberseguridad para el sector salud: qué lo hace distinto a una empresa de TI
- 03 NOM-024-SSA3: qué exige sobre seguridad del expediente clínico electrónico
- 04 LFPDPPP y datos sensibles de salud: qué exige y qué entrega un pentest
- 05 ¿Qué evalúa un pentest hospitalario?
- 06 ¿Qué tipo de pentesting conviene a un hospital?
- 07 ¿Cómo se ejecuta un pentest hospitalario sin detener la atención clínica?
- 08 ¿Qué entregables entrega un pentest hospitalario?
- 09 Preguntas frecuentes sobre pentesting hospitalario
¿Por qué es vital el pentesting en hospitales?
El pentesting es vital en hospitales por cuatro razones concretas: protege los datos personales sensibles que exige la LFPDPPP, identifica vulnerabilidades en dispositivos médicos conectados antes de un incidente, sostiene la continuidad de la atención clínica frente a campañas de ransomware y aporta evidencia técnica defendible para auditorías bajo NOM-024-SSA3 y pólizas de ciberseguro.
Un hospital no es una empresa de TI estándar. Combina sistemas que no pueden apagarse, datos cuya filtración tiene consecuencias regulatorias inmediatas y dispositivos médicos conectados que rara vez pueden parchearse a tiempo.
Esa combinación explica por qué el sector salud es uno de los blancos preferidos por los ciberdelincuentes en LATAM. Las campañas de ransomware en particular monetizan el secuestro del expediente y la presión por restablecer la atención.
Los datos lo confirman. El informe de Claroty Team82 sobre el estado de la seguridad sanitaria 2025 reporta que el 58% de las organizaciones sanitarias está en riesgo de sufrir ciberataques con potencial de comprometer datos médicos e interrumpir servicios.
El mismo informe documenta que el 20% de los sistemas HIS (Hospital Information System, el sistema central que gestiona expedientes y procesos clínicos) contiene vulnerabilidades explotables conocidas vinculadas a campañas activas de ransomware.
A escala global, encuestas de Health-ISAC en 2025 identificaron más de 1.2 millones de dispositivos médicos accesibles públicamente desde internet. En la práctica, el atacante no necesita un día cero (vulnerabilidad desconocida): le basta con un dispositivo legacy expuesto al perímetro o un usuario clínico cayendo en phishing.
Para una dirección de TI hospitalaria, este panorama tiene una traducción concreta. Un incidente exitoso no solo paraliza la consulta externa o la facturación: activa obligaciones de notificación bajo la LFPDPPP, expone a la institución a multas administrativas y, en el peor escenario, retrasa procedimientos clínicos en curso.
El pentest existe para encontrar esos puntos de entrada antes de que un grupo organizado los explote. Esa diferencia entre cumplimiento formal y cumplimiento técnico es lo que vamos a desarrollar en lo que sigue.
Ciberseguridad para el sector salud: qué lo hace distinto a una empresa de TI
La idea de "asegurar el hospital como cualquier empresa" es un error de partida. La superficie de ataque hospitalaria mezcla sistemas administrativos, sistemas clínicos críticos, dispositivos médicos en red y APIs de interoperabilidad con otros centros. Cada capa exige un tratamiento distinto.
Sistemas HIS, RIS y PACS
El HIS gestiona expedientes, citas, facturación y reportes. El RIS (Radiology Information System) administra las solicitudes y reportes de imagenología, y el PACS (Picture Archiving and Communication System) almacena y distribuye las imágenes médicas, desde una radiografía hasta una tomografía.
Estos tres sistemas suelen tener años en operación, conviven con módulos legacy que ya no reciben parches y se integran con el resto del ecosistema a través de conexiones que no siempre están bien segmentadas.
En la práctica, un atacante que compromete una estación administrativa puede saltar al HIS por movimiento lateral si la red es plana, y desde ahí alcanzar el expediente clínico electrónico completo.
Dispositivos médicos en red (IoMT)
El IoMT (Internet of Medical Things, internet de las cosas médicas) incluye bombas de infusión, monitores de signos vitales, ventiladores, dispositivos de imagen, sistemas de llamada a enfermería y, en general, todo equipo clínico con interfaz de red.
Investigaciones recientes reportan en promedio 6.2 vulnerabilidades por dispositivo IoMT y un 60% de equipos en fin de vida útil, sin soporte del fabricante.
Esto convierte a cada bomba de infusión mal segmentada en un punto de pivote potencial. Y aunque el atacante no quiera dañar al paciente, sí puede usar ese dispositivo como puente hacia el expediente clínico.
APIs de interoperabilidad (HL7 y FHIR)
La interoperabilidad clínica se sostiene sobre estándares como HL7 v2 (Health Level 7, el protocolo histórico para mensajería entre sistemas clínicos) y FHIR (Fast Healthcare Interoperability Resources, su sucesor moderno basado en APIs REST).
Estas APIs mueven información sensible entre HIS, laboratorios, farmacias y sistemas de pago. Si una API FHIR del portal del paciente no valida tokens correctamente o expone identificadores secuenciales, un atacante puede enumerar y descargar miles de expedientes sin necesidad de explotar el HIS directamente.
La superficie de ataque de las APIs hospitalarias merece su propio capítulo dentro del pentest. Para profundizar en cómo se evalúan estas APIs y dónde aparecen los fallos más frecuentes, vale la pena revisar nuestra guía sobre pentesting de API.
Datos personales sensibles bajo la LFPDPPP
La LFPDPPP clasifica como datos personales sensibles aquellos relacionados con el estado de salud presente o futuro, información genética, origen étnico y preferencia sexual, entre otros. Es decir, prácticamente todo lo que un expediente clínico contiene cae en esta categoría reforzada.
La reforma a la LFPDPPP publicada en marzo de 2025 trasladó la autoridad reguladora del INAI a la nueva Secretaría de Anticorrupción y Buen Gobierno, y amplió la definición de tratamiento y de datos sensibles.
El estándar de cuidado para los hospitales no bajó con la reforma: se endureció, en especial en lo que respecta a datos sensibles de salud.
NOM-024-SSA3: qué exige sobre seguridad del expediente clínico electrónico
La NOM-024-SSA3 es la norma oficial mexicana que regula los Sistemas de Información de Registro Electrónico para la Salud (SIRES) y, en particular, los productos de Expediente Clínico Electrónico.
La versión vigente fue publicada en el Diario Oficial de la Federación en noviembre de 2012 y establece los objetivos funcionales y de interoperabilidad que cualquier sistema que registre, intercambie o consolide información clínica debe cumplir. Su objetivo declarado abarca interoperabilidad, procesamiento, interpretación, confidencialidad, seguridad y uso de estándares y catálogos.
El cumplimiento formal se verifica mediante un proceso de certificación coordinado por la DGIS (Dirección General de Información en Salud) y el CENETEC (Centro Nacional de Excelencia Tecnológica en Salud).
Esa certificación valida que el sistema, en papel, cumple con los requisitos funcionales: autenticación, control de acceso por roles, registro de auditoría, interoperabilidad con HL7 y FHIR, firma electrónica y conservación de la información.
Lo que la certificación no verifica con la profundidad necesaria es si esos controles están implementados correctamente en el entorno real del hospital, con sus integraciones, sus excepciones operativas y sus parches pendientes.
Ese es el espacio donde entra el pentesting hospitalario. Un sistema certificado puede tener autenticación robusta en su documentación y, al mismo tiempo, exponer un endpoint REST sin token de sesión, una consola de administración con contraseña por defecto o un servicio de respaldo accesible desde la red administrativa.
El pentest cierra la distancia entre el cumplimiento que se firma y el cumplimiento que opera. Para auditores y responsables de calidad, el informe de pentest es un anexo defendible que demuestra que los controles obligatorios bajo NOM-024-SSA3 no son solo declarativos.
Si la institución también busca evidenciar postura general más allá del expediente clínico, conviene apoyarse en una visión integral de cumplimiento normativo en ciberseguridad que articule frameworks complementarios.
LFPDPPP y datos sensibles de salud: qué exige y qué entrega un pentest
La LFPDPPP exige al responsable del tratamiento (el hospital, la clínica, el laboratorio) que adopte medidas de seguridad físicas, técnicas y administrativas proporcionales al riesgo. Para datos sensibles, ese estándar se eleva.
La autoridad reguladora, ahora la Secretaría de Anticorrupción y Buen Gobierno, puede solicitar evidencia de que esas medidas existen, operan y se evalúan periódicamente. Aquí es donde el pentest deja de ser un ejercicio técnico aislado y se convierte en pieza documental del programa de protección de datos.
El pentest entrega tres tipos de evidencia útiles para LFPDPPP. La primera es el inventario de vulnerabilidades explotables en sistemas que tratan datos personales sensibles, con prioridad por riesgo y referencia a CVE (Common Vulnerabilities and Exposures, identificador estándar de vulnerabilidades conocidas) cuando aplica.
La segunda es la demostración del impacto real: qué información se puede extraer si esa vulnerabilidad se explota, lo que ayuda a justificar inversiones ante dirección general. La tercera es el plan de remediación con responsables y plazos, que convierte el hallazgo en un proceso de mejora trazable.
Para una institución de salud que pueda enfrentar una solicitud de auditoría o una verificación tras un incidente, contar con esta evidencia documenta diligencia. Un hospital que puede mostrar pentests periódicos, planes de remediación cerrados y retests verificados está en una posición sustancialmente distinta frente a la autoridad respecto a otro que solo presenta políticas firmadas.
La LFPDPPP no exige el pentest con ese nombre, pero sí exige medidas de seguridad técnicas evaluadas y mejoradas continuamente, y el pentest es la forma estándar de la industria de hacerlo.
¿Qué evalúa un pentest hospitalario?
Un pentest hospitalario bien diseñado define el alcance por áreas funcionales, no por listas planas de IPs. La diferencia con un pentest corporativo estándar (cuyos fundamentos se cubren en nuestra guía sobre qué es el pentesting en ciberseguridad) es que el alcance debe trazarse alrededor del flujo del paciente.
En TecnetOne, nuestra metodología parte de un mapeo del flujo del paciente, del flujo del dato y del flujo del dispositivo, y desde ahí define los activos críticos a evaluar. El alcance típico para una institución mediana incluye cuatro áreas.
Aplicaciones web del portal del paciente
El portal del paciente concentra autenticación, agendamiento, resultados de laboratorio, descarga de estudios y, en muchos casos, pago en línea. Es la ventana directa al expediente clínico desde internet.
La evaluación incluye autenticación y gestión de sesión, autorización por rol, validación de entrada, exposición de datos sensibles en respuestas, exposición de identificadores secuenciales en URLs, protección contra OWASP Top 10 y manejo seguro de archivos médicos descargables.
APIs de integración clínica
Las APIs que conectan el HIS con laboratorios externos, con sistemas de imagen, con farmacias y con aseguradoras son frecuentemente la superficie menos vigilada.
La evaluación busca fallas de autenticación entre servicios, rate limiting (control de tasa de peticiones) ausente, exposición de datos clínicos en respuestas verbosas, manejo inseguro de tokens y endpoints públicos que no deberían estarlo. En arquitecturas FHIR, también se revisan permisos por recurso y la separación entre lectura, escritura y administración.
Red administrativa frente a red clínica
La segmentación entre la red administrativa (computadoras de oficinas, facturación, recursos humanos) y la red clínica (HIS, dispositivos médicos, sistemas de imagen) es uno de los controles compensatorios más importantes, ya que muchos dispositivos clínicos no pueden parchearse.
El pentest verifica si esa segmentación existe en VLANs, si las reglas de firewall están realmente aplicadas, si hay rutas laterales por wifi, por dispositivos compartidos o por estaciones de servicio. Una segmentación que existe en el diagrama pero no en la configuración real es uno de los hallazgos más comunes.
Dispositivos médicos conectados (IoMT)
Aquí se aplica un enfoque conservador. No se ejecutan exploits contra dispositivos en operación clínica, ya que la prioridad es la seguridad del paciente.
La evaluación se limita a identificación pasiva, análisis de comunicaciones, revisión de firmware en entornos de laboratorio o ventanas controladas, y validación de la segmentación que protege a esos dispositivos del resto de la red. La mayor parte del riesgo IoMT se mitiga arquitectónicamente, no por hardening del dispositivo, y eso es justamente lo que el pentest valida.
Caja blanca, caja negra o caja gris: qué tipo de pentesting conviene a un hospital
La elección entre caja blanca, caja negra y caja gris no es estética. Define qué riesgo se está evaluando, cuánto tarda y qué tipo de hallazgo se obtiene. Una descripción breve de cada uno, con su lectura para el sector salud, basta para decidir.
En caja negra, el pentester no tiene información previa del sistema y opera desde la perspectiva de un atacante externo. Es el escenario más realista respecto a una amenaza desde internet, pero también el más limitado en profundidad: el equipo invierte tiempo descubriendo arquitectura en lugar de evaluar lógica clínica interna.
En caja blanca, el pentester recibe documentación completa, credenciales y acceso al código fuente cuando aplica, lo que permite un análisis más profundo y exhaustivo, aunque pierde la perspectiva del atacante real.
En caja gris, el punto intermedio, el equipo recibe información parcial (un usuario válido de portal del paciente, por ejemplo) y desde ahí evalúa tanto la superficie externa como los controles internos.
Para un hospital mediano mexicano, la recomendación práctica suele ser caja gris. Permite cubrir tanto la postura externa visible desde internet como la lógica interna del portal y las APIs en un tiempo razonable, y produce un informe con hallazgos accionables en ambos planos. Para profundizar en las diferencias entre estos enfoques y cuándo conviene cada uno, puedes consultar nuestra guía completa sobre tipos de pentesting.
¿Cómo se ejecuta un pentest hospitalario sin detener la atención clínica?
Esta es la pregunta que más preocupa a una dirección de TI hospitalaria, y con razón. Un pentest mal diseñado puede degradar un sistema crítico justo cuando se necesita disponible. En TecnetOne, nuestra metodología para entornos clínicos parte de cuatro principios operativos.
El primero es la definición conjunta de ventanas. Antes de cualquier prueba que pueda generar carga significativa, se acuerdan ventanas con el equipo clínico y el área biomédica, idealmente fuera de horarios pico de consulta externa y de urgencias.
El segundo es la categorización de activos por criticidad. Los sistemas que sostienen atención clínica directa (HIS en producción, ventiladores, monitores, bombas de infusión) se evalúan en modo no intrusivo: identificación pasiva, análisis de tráfico, revisión documental, sin lanzar exploits que puedan degradar disponibilidad.
El tercero es el canal de comunicación en tiempo real. El equipo del pentest mantiene comunicación con el responsable de TI durante toda la ventana de pruebas, con un protocolo de detención inmediata ante cualquier comportamiento anómalo en sistemas clínicos.
El cuarto es la separación clara entre la red clínica y la red administrativa en el alcance de las pruebas; cada una se evalúa con su propio criterio de intrusividad.
Esto tiene una consecuencia operativa importante: un pentest hospitalario serio dura más que un pentest corporativo equivalente. La fase de planeación, el reconocimiento detallado y la coordinación clínica añaden tiempo, y eso es deseable.
Para conocer en detalle cómo se estructuran cada una de las fases de un pentest profesional, puedes revisar la guía sobre las fases de las pruebas de penetración. La diferencia entre un pentest hospitalario y uno genérico no está en las herramientas; está en la disciplina operativa que rodea su ejecución.
¿Qué entregables entrega un pentest hospitalario?
Un pentest sin entregables documentados es un ejercicio académico. Para que el pentest cumpla su función dentro del programa de seguridad y de cumplimiento del hospital, debe producir cuatro piezas concretas, cada una con audiencia distinta y propósito específico.
El informe técnico es la pieza dirigida al equipo de TI y de desarrollo. Detalla cada hallazgo con su prueba de concepto, su impacto, su CVSS (Common Vulnerability Scoring System, el estándar para puntuar gravedad de vulnerabilidades), su CVE asociado cuando aplica y sus pasos de remediación reproducibles.
El resumen ejecutivo está dirigido a dirección general, dirección médica y comité de calidad, y traduce los hallazgos en lenguaje de riesgo de negocio, exposición regulatoria e impacto sobre continuidad clínica, sin tecnicismos innecesarios.
El plan de remediación prioriza los hallazgos por riesgo, asigna responsables, propone plazos y deja un cronograma que el comité puede seguir mes a mes.
Por último, el retest verifica que los hallazgos críticos y altos quedaron efectivamente cerrados después de la remediación, y entrega un informe complementario que la institución puede presentar a auditores.
En conjunto, estos cuatro entregables conforman la evidencia documental que un hospital necesita para sostener su postura técnica ante auditorías de NOM-024-SSA3, ante verificaciones de LFPDPPP y ante los requisitos de pólizas de ciberseguro, que cada año son más exigentes.
Pentesting y SOC: cómo mantener postura continua en una institución de salud
Un pentest es una fotografía. Muestra el estado de la postura de seguridad en un momento específico, con un alcance específico, frente a un equipo atacante con tiempo limitado. Esa fotografía es valiosa, pero envejece.
Entre dos pentests anuales, el hospital sigue desplegando integraciones nuevas, conectando dispositivos nuevos y abriendo accesos temporales que después se vuelven permanentes.
Por eso, el pentest se complementa con la operación continua de un SOC. TecnetSOC es la plataforma propia de TecnetOne que combina protección activa de la infraestructura con generación de evidencia para cumplimiento, operada desde equipo propio en LATAM.
En un hospital, esa operación continua significa que entre pentest y pentest hay alguien revisando alertas, correlacionando eventos del HIS con eventos de red, detectando movimiento lateral hacia el expediente clínico electrónico y respondiendo cuando algo se sale de patrón.
El pentest descubre las brechas, el SOC vigila que ninguna nueva pase desapercibida, y juntos sostienen una postura demostrable ante auditores en lugar de un cumplimiento de papel. Si tu institución todavía no tiene un servicio centralizado de pruebas ofensivas como referencia, puedes revisar nuestro contenido sobre pentesting para empresas para entender cómo se articula con el resto del programa de seguridad.
Preguntas frecuentes sobre pentesting hospitalario
-
¿Es obligatorio un pentest en hospitales mexicanos? No existe una obligación explícita y nominal de "pentest" en NOM-024-SSA3 ni en LFPDPPP. Lo que ambas regulaciones sí exigen son medidas de seguridad técnicas proporcionales al riesgo y evaluadas continuamente. El pentest es la forma estándar de la industria para demostrar que esas medidas operan, y se ha convertido en un requisito de hecho para muchas auditorías y pólizas de ciberseguro.
-
¿Un pentest puede afectar dispositivos médicos en operación? No, si está bien diseñado. Un pentest hospitalario serio aplica un enfoque no intrusivo sobre dispositivos clínicos en producción: identificación pasiva, análisis de tráfico y revisión arquitectónica, sin lanzar exploits contra bombas de infusión, monitores o ventiladores. La intrusividad se reserva para sistemas administrativos y para entornos controlados con autorización explícita del área biomédica.
-
¿Con qué frecuencia debe hacerse un pentest en una institución de salud? La práctica recomendada es ejecutar al menos un pentest anual de alcance completo, complementado con retests dirigidos cada vez que se despliegue un cambio significativo: portal del paciente nuevo, integración con un laboratorio externo, migración del HIS, apertura de APIs hacia aseguradoras. Para instituciones en sectores muy expuestos, dos pentests anuales son la norma.
-
¿Cumple un pentest con NOM-024-SSA3 y LFPDPPP simultáneamente? Sí, cuando el alcance está diseñado correctamente. Un mismo pentest puede generar evidencia para ambos marcos: revisa la seguridad del expediente clínico electrónico (NOM-024-SSA3) y al mismo tiempo evalúa los controles técnicos sobre datos personales sensibles (LFPDPPP). Lo que cambia es cómo se redacta el informe ejecutivo, que debe mapear hallazgos a los requisitos de cada marco.
-
¿Cuánto dura un pentest hospitalario y qué entregables se reciben? La duración típica para una institución mediana es de tres a cinco semanas, dependiendo del alcance, número de aplicaciones, número de APIs y tamaño de la red. Los entregables son cuatro: informe técnico para TI y desarrollo, resumen ejecutivo para dirección, plan de remediación priorizado y, después de las correcciones, un retest que verifica el cierre de hallazgos críticos.
