Un SOC en un hospital no vigila solo servidores y firewalls. Necesita ver quién abrió qué historia clínica, adónde fueron las imágenes de un estudio y qué intenta alcanzar un equipo conectado a la red, y debe responder a un ataque sin detener la atención. Aquí verá qué monitorear, qué detecciones tienen sentido y dónde entra la ley brasileña de protección de datos (LGPD).
La base es pública: el programa 405(d) del Departamento de Salud de Estados Unidos (HHS), que publica las prácticas de ciberseguridad para el sector (HICP), las orientaciones de la CISA para el sector salud, el NIST y la regulación brasileña. Para una visión general de los riesgos y servicios del sector, consulte la página de ciberseguridad para salud.
Por qué la salud necesita un SOC diferente
El HICP señala como amenazas más relevantes para el sector la ingeniería social, el ransomware, la pérdida o el robo de equipos, la pérdida de datos por usuarios internos (accidental o intencional) y los ataques a dispositivos médicos conectados. Tres características hacen que este escenario sea más difícil de defender que el de una empresa común:
- La disponibilidad es seguridad del paciente. Un sistema caído retrasa estudios, prescripciones y cirugías.
- Mucha gente legítima accede a datos sensibles. Médicos, enfermería, admisión, facturación y terceros consultan historias clínicas todos los días. El riesgo no está solo en el intruso externo, sino en el acceso legítimo usado con fines indebidos.
- Parte del parque no admite agente. Los equipos médicos y los sistemas del edificio suelen ejecutar software antiguo, dependen del fabricante para actualizarse y solo pueden observarse desde la red.
Qué monitorear
- Historia clínica electrónica (HCE) y sistemas de gestión hospitalaria. La pista de auditoría de la aplicación (quién accedió, a qué paciente, cuándo, desde dónde y qué hizo) es la fuente más importante y la más olvidada.
- PACS e imágenes. Consultas y transferencias de estudios, destinos que reciben imágenes, cuentas de servicio de las modalidades y accesos externos para informes a distancia. El NIST dedicó una guía entera al tema, la SP 1800-24, sobre la seguridad de PACS.
- Dispositivos médicos e IoMT. Inventario pasivo por la red, comunicación esperada de cada equipo y cualquier desvío: un monitor de signos vitales que se comunica con internet o un equipo de imagen que abre conexiones administrativas hacia otros segmentos.
- Identidades de profesionales y terceros. Directorio, autenticación multifactor, VPN y acceso remoto de proveedores, cuentas compartidas de estaciones clínicas y cuentas privilegiadas. Vea gestión de accesos y credenciales.
- Correo electrónico. Phishing, reglas de reenvío automático creadas en buzones comprometidos y envío de adjuntos con datos de pacientes a direcciones personales. Lea más sobre phishing e ingeniería social.
- Base de infraestructura. Endpoints, servidores, firewalls, backup y nube, como en cualquier SOC 24×7.
Casos de uso de detección propios del sector
Acceso indebido a historias clínicas
La regla genérica de "inicio de sesión fuera de horario" no sirve en un entorno que funciona las 24 horas. Lo que funciona es cruzar la pista de la HCE con el contexto del profesional:
- Sin vínculo asistencial. Acceso a un paciente que no está en la unidad, la agenda o el turno del profesional.
- Pacientes sensibles. Consultas a registros de colaboradores, de personas con el mismo apellido del usuario o de pacientes de gran exposición pública.
- Volumen fuera de lo normal. Un usuario que abre decenas de historias clínicas seguidas sin registrar atención.
Buena parte de estas alertas se resuelve con una pregunta al responsable del área, no con contención. Por eso el flujo debe acordarse con el encargado de protección de datos (DPO) y con la dirección médica.
Exfiltración de datos de salud
- Exportaciones masivas de informes o consultas directas a la base de datos de la HCE fuera de las rutinas conocidas.
- Transferencias de estudios del PACS a destinos que no figuran en el registro de equipos y socios.
- Salida de datos: subida a almacenamiento personal en la nube, compresión de grandes volúmenes y correos con adjuntos voluminosos a dominios externos.
Precursores de ransomware
Antes de cifrar, el atacante necesita entrar, obtener privilegios y moverse. Son señales que el SOC debe tratar como incidente, no como curiosidad:
- Acceso remoto anómalo de proveedores o usuarios, sobre todo sin MFA o desde un origen inusual.
- Nuevas cuentas administrativas, cambios en grupos privilegiados y uso de herramientas de administración remota no homologadas.
- Desactivación de defensas y de recuperación: antivirus o EDR detenidos, instantáneas de volumen borradas y tareas de backup alteradas (técnica T1490 de MITRE ATT&CK).
- Escaneo y acceso masivo a recursos compartidos de red desde una sola estación.
Detectar en esta fase es lo que separa un incidente contenido de días operando en contingencia. La guía #StopRansomware de la CISA y el artículo sobre ransomware y RaaS detallan estas etapas.
Cómo responder sin detener la atención
En una oficina, aislar toda la red puede ser la decisión correcta. En un hospital, la misma decisión puede dejar sin sistema de prescripción a la guardia. La respuesta debe ser proporcional y acordada de antemano:
- Mapa de criticidad clínica. Saber qué sistemas sostienen qué áreas asistenciales y cuánto tiempo puede operar cada una en contingencia.
- Contención quirúrgica. Bloquear la cuenta, aislar la estación o el servidor comprometido y restringir el segmento afectado, en lugar de apagar todo.
- Equipos médicos con cuidado. Aislar o actualizar un dispositivo clínico pasa por ingeniería clínica y, cuando corresponde, por el fabricante, con el equipo fuera de uso en el paciente.
- Procedimientos de contingencia ensayados. Prescripción y registro en papel, flujo de estudios sin sistema y comunicación con los equipos asistenciales deben probarse con las áreas clínicas, no solo con TI.
- Decisión clara. Quién puede autorizar la parada de un sistema asistencial, y en cuánto tiempo, debe estar escrito en el plan de respuesta a incidentes.
El backup también es contingencia clínica. Los backups aislados y las restauraciones probadas determinan cuánto tiempo el hospital queda sin HCE y PACS. Vea backup y resiliencia cibernética.
LGPD y comunicación a la ANPD
El dato relativo a la salud es dato personal sensible según la LGPD (art. 5, II) y solo puede tratarse en los supuestos del art. 11. El art. 46 exige medidas de seguridad técnicas y administrativas contra accesos no autorizados, y la pista de auditoría de la HCE monitoreada por el SOC es una de las formas más concretas de demostrarlas.
Según la Resolución CD/ANPD n.º 15/2024, el incidente que pueda causar riesgo o daño relevante a los titulares debe comunicarse a la ANPD (autoridad brasileña de protección de datos) y a los titulares en tres días hábiles, contados desde que se supo que afectó datos personales. La presencia de datos sensibles es uno de los criterios de relevancia del reglamento, y todo incidente, comunicado o no, debe registrarse y conservarse durante al menos cinco años.
El plazo solo se cumple si el SOC entrega rápido lo que pide la comunicación: qué ocurrió, cuándo, qué sistemas y categorías de datos se vieron afectados, cuántos titulares y qué medidas ya se tomaron. Sobre las sanciones, vea cómo la ANPD calcula las multas.
Preguntas frecuentes
¿El SOC necesita ver el contenido de la historia clínica?
No. Para detectar accesos indebidos basta la pista de auditoría: usuario, paciente (preferentemente por identificador), fecha, origen y acción. Limitar lo que recibe el SOC al mínimo necesario también es una exigencia de proporcionalidad de la LGPD.
¿Cómo monitorear equipos médicos que no admiten agente?
Desde la red. El análisis del tráfico permite inventariar los dispositivos, aprender la comunicación normal de cada uno y alertar sobre desvíos, sin instalar nada en el equipo. Segmentar la red de dispositivos médicos facilita ese monitoreo.
¿Todo acceso indebido a una historia clínica debe comunicarse a la ANPD?
No automáticamente. Es un incidente de seguridad con datos sensibles y debe registrarse; la comunicación depende de la evaluación del riesgo o daño relevante a los titulares, que debe hacerse y documentarse caso por caso.
¿Un SOC tercerizado puede aislar sistemas del hospital por su cuenta?
Solo dentro de lo autorizado previamente. El modelo más seguro define en el contrato y en los playbooks qué acciones ejecuta el SOC por sí solo (bloquear una cuenta, aislar una estación administrativa) y cuáles requieren aprobación del hospital (detener un sistema asistencial).
Fuentes consultadas: HHS 405(d), Health Industry Cybersecurity Practices (HICP): Managing Threats and Protecting Patients; CISA, página del sector de salud y salud pública y #StopRansomware Guide; NIST SP 1800-24, Securing Picture Archiving and Communication System (PACS); MITRE ATT&CK, técnica T1490; Ley brasileña n.º 13.709/2018 (LGPD), arts. 5, 11 y 46; Resolución CD/ANPD n.º 15/2024 (Reglamento de Comunicación de Incidentes de Seguridad). Este artículo es educativo y no sustituye la orientación jurídica ni un plan de respuesta a incidentes adecuado a su institución.