MP.S Protección de los servicios

Esta sección establece las medidas de protección para servicios relacionados con dispositivos médicos, garantizando la disponibilidad, integridad y confidencialidad de los servicios críticos para la atención sanitaria.

MP.S.1 Protección del correo electrónico

Objetivo

Proteger las comunicaciones por correo electrónico que contengan información relacionada con dispositivos médicos y datos de pacientes, implementando controles de seguridad apropiados.

Documentos de referencia

• Real Decreto 311/2022 - Artículo 36
• Guía CCN-STIC 812 - Seguridad en entornos y aplicaciones Web

Guía de implantación

Implementación para dispositivos médicos

Medidas obligatorias:

1. Cifrado de comunicaciones

   • TLS 1.3 obligatorio para todas las comunicaciones de correo
   • S/MIME para cifrado de extremo a extremo en comunicaciones médicas sensibles
   • Certificados digitales válidos para autenticación de remitentes autorizados

2. Filtrado y detección de amenazas

   • Filtros anti-spam con listas blancas para proveedores médicos autorizados
   • Detección de phishing específica para el sector sanitario
   • Sandboxing de archivos adjuntos antes de la entrega

3. Control de información médica

   • Etiquetado automático de correos con información de pacientes
   • Prevención de envío accidental de datos médicos fuera del dominio
   • Archivo seguro de comunicaciones médicas según normativa de retención

4. Gestión de identidades

   • Autenticación multifactor para cuentas con acceso a sistemas médicos
   • Integración con Active Directory para control centralizado
   • Políticas de contraseñas robustas específicas para personal sanitario

Controles específicos:

• Alertas automáticas para correos con información de pacientes enviados externamente
• Cuarentena temporal para archivos adjuntos de proveedores no verificados
• Logs de auditoría para comunicaciones relacionadas con dispositivos médicos críticos

MP.S.2 Protección de servicios y aplicaciones web

Objetivo

Asegurar las aplicaciones web y servicios relacionados con dispositivos médicos contra ataques cibernéticos, garantizando la continuidad de servicios críticos para la atención sanitaria.

Documentos de referencia

• Real Decreto 311/2022 - Artículo 36
• Guía CCN-STIC 815 - Métricas e Indicadores

Guía de implantación

Implementación para dispositivos médicos

Medidas obligatorias:

1. Arquitectura de seguridad

   • Segmentación de red para servicios de dispositivos médicos críticos
   • WAF (Web Application Firewall) implementado: app-pro-backend-waf con reglas AWS Managed (IP Reputation, Known Bad Inputs) y reglas personalizadas para protección de APIs de informes diagnósticos. Ver evidencia en op.nub — Servicios en la Nube
   • Balanceadores de carga con capacidades de detección de anomalías

2. Autenticación y autorización

   • Autenticación de clientes API mediante API keys y OAuth 2.0 client credentials (máquina-a-máquina)
   • Autorización basada en permisos del cliente API (scopes por organización)
   • Tokens JWT con expiración configurable y rotación automática de API keys

3. Protección de APIs médicas

   • Rate limiting para APIs de dispositivos médicos
   • Validación estricta de entradas para datos de pacientes
   • Cifrado de datos en tránsito y en reposo (AES-256)

4. Monitoreo continuo

   • SIEM con correlación de eventos específica para entornos médicos
   • Detección de comportamientos anómalos en tiempo real
   • Alertas automatizadas para intentos de acceso no autorizado

Configuraciones específicas:

• Certificados SSL/TLS renovados automáticamente cada 90 días
• Headers de seguridad HTTP específicos (HSTS, CSP, X-Frame-Options)
• Timeouts de sesión diferenciados: 8 horas para sistemas críticos, 2 horas para administrativos

Auditorías de seguridad de aplicaciones web (Refuerzo R2 — Nivel ALTO)

Para categoría ALTO, el ENS exige la realización de auditorías de seguridad de tipo «caja blanca» sobre las aplicaciones web durante su desarrollo. Esta exigencia se satisface mediante un enfoque combinado de verificación de seguridad interna continua y auditoría externa periódica, ambas ya integradas en el proceso de ciclo de vida del producto sanitario conforme a IEC 62304 e IEC 81001-5-1.

Modalidad

Tipo de auditoría	Modalidad	Ejecutor	Frecuencia
Verificación de seguridad interna	Caja blanca	Equipo de desarrollo (con acceso completo al código fuente)	Continua — con cada versión del software
Prueba de penetración externa	Caja negra (CASA Tier 3)	Laboratorio acreditado externo (DEKRA)	Al menos con cada versión mayor o anualmente
Modelado de amenazas	Caja blanca	Equipo de ciberseguridad interno	Con cada versión mayor o cambio arquitectónico

La combinación de caja blanca interna (continua) y caja negra externa (periódica) proporciona una cobertura de seguridad superior a la requerida por el ENS, ya que:

• La verificación interna de caja blanca tiene acceso completo al código fuente, la arquitectura y los controles de seguridad, lo que permite detectar vulnerabilidades a nivel de diseño e implementación.
• La prueba de penetración externa valida la resistencia del sistema desde la perspectiva de un atacante sin información privilegiada.
• El modelado de amenazas STRIDE identifica amenazas a nivel arquitectónico antes de que se materialicen.

Alcance

El alcance de las auditorías abarca el único servicio web en el ámbito del ENS: la API REST de diagnóstico (el producto sanitario), incluyendo:

• Endpoints de autenticación y autorización (API keys, OAuth 2.0 client credentials)
• Endpoints clínicos de procesamiento de imágenes y soporte diagnóstico
• Controles de seguridad: TLS, JWT, rate limiting, validación de entradas, registros de auditoría
• Infraestructura de soporte: AWS WAF, balanceadores de carga, segmentación de red

Metodología y herramientas

Verificación interna (caja blanca):

• Metodología: Verificación basada en requisitos de seguridad trazados desde IEC 62443-4-2 y la guía de ciberseguridad de la FDA 2023. Cada requisito de seguridad se vincula a casos de prueba específicos con criterios de aceptación objetivos.
• Modelado de amenazas: Metodología STRIDE aplicada a la arquitectura del sistema, documentada con Microsoft Threat Modeling Tool.
• Gestión de pruebas: TestRail como sistema de gestión, con casos de prueba clasificados por tipo (Security, Functional, Performance) y trazados a requisitos.
• Ejecución: Tests unitarios, de integración y de sistema ejecutados en entornos Dev, Pre y Pro, con evidencia almacenada en S3 y verificada mediante manifiestos criptográficos.
• CI/CD: GitHub Actions ejecuta pruebas automatizadas antes de cada despliegue a producción.

Prueba de penetración externa (caja negra):

• Metodología: Marco OSE de DEKRA, con 133 casos de evaluación según criterios CASA Tier 3.
• Herramientas: Burp Suite, Fuff, Nuclei, Nikto, OpenSSL.
• Cobertura: Análisis estático (dependencias, componentes expuestos), análisis dinámico (manejo de peticiones, criptografía, resiliencia), modelado de amenazas arquitectónico y pruebas de penetración.

Documentación y evidencia

Toda la documentación de las auditorías de seguridad se mantiene en el expediente técnico del producto sanitario, accesible desde el SGC:

• R-TF-030-001 Plan de Gestión de Ciberseguridad — Define el proceso de gestión de riesgos de seguridad, verificación y trazabilidad.
• R-TF-030-003 Informe de Evaluación de Ciberseguridad — Contiene el informe de la prueba de penetración externa, la matriz de trazabilidad de controles de seguridad y el análisis de amenazas.
• R-TF-030-004 Matriz de Riesgos de Ciberseguridad — Registro de los 32 riesgos identificados con evaluación CVSS.
• R-TF-012-033 Plan de Pruebas de Software — Define la estrategia de verificación, incluyendo los tests de seguridad (TLS, JWT, auditoría) y su trazabilidad a requisitos.
• R-TF-012-035 Informe de Pruebas de Software — Resultados de la verificación completa, incluyendo pruebas de seguridad con 100% de aprobación.

El proceso de desarrollo seguro y gestión de cambios se rige por el GP-012 (Proceso de Desarrollo de Software) y el GP-023 (Gestión de Control de Cambios), que garantizan que cualquier cambio que afecte a la seguridad desencadena la reevaluación de riesgos y la ejecución de las pruebas de seguridad correspondientes.

MP.S.3 Protección frente a la denegación de servicio

Objetivo

Implementar medidas preventivas y reactivas contra ataques de denegación de servicio que puedan afectar la disponibilidad de dispositivos médicos y servicios críticos.

Documentos de referencia

• Real Decreto 311/2022 - Artículo 36
• Guía CCN-STIC 817 - Esquema Nacional de Seguridad

Guía de implantación

Implementación para dispositivos médicos

Medidas obligatorias:

1. Infraestructura resistente

   • CDN (Content Delivery Network) para distribución de carga
   • Servidores redundantes en múltiples ubicaciones geográficas
   • Capacidad de sobrecarga del 200% para picos de demanda médica

2. Detección temprana

   • Monitoreo de tráfico en tiempo real con umbrales dinámicos
   • Análisis de patrones de tráfico específicos de aplicaciones médicas
   • Correlación de eventos con inteligencia de amenazas sectorial

3. Mitigación automática

   • Rate limiting adaptativo basado en comportamiento histórico
   • Blacklisting automático de IPs maliciosas por periodos definidos
   • Priorización de tráfico médico crítico durante ataques

4. Respuesta a incidentes

   • Procedimientos de escalado automático de recursos en la nube
   • Comunicación automática a stakeholders médicos durante ataques
   • Planes de continuidad con sistemas alternativos pre-configurados

Procedimiento de reacción ante ataque DDoS

Para categoría ALTO, se requiere un procedimiento de reacción documentado que incluya la comunicación con el proveedor de servicios de Internet y el proveedor cloud.

Protocolo de actuación

Fase	Acción	Responsable	Tiempo máximo
1. Detección	Alerta automática de AWS Shield / CloudWatch por tráfico anómalo	Automático	Inmediato
2. Verificación	Confirmar que se trata de un ataque DDoS (no pico legítimo de tráfico)	Responsable del Sistema	15 min
3. Activación mitigación	Verificar que AWS Shield Standard y WAF están mitigando el ataque	Responsable del Sistema	30 min
4. Escalado a AWS	Si el ataque supera la capacidad de mitigación automática: abrir caso de soporte AWS con severidad Crítica	Responsable del Sistema	1 hora
5. Mitigación adicional	Activar reglas adicionales en AWS WAF / CloudFront y, si procede, evaluar la activación de AWS Shield Advanced. Si algún empleado pierde conectividad, este contacta individualmente con su ISP doméstico	Responsable del Sistema	1 hora
6. Notificación interna	Informar al Comité de Seguridad y a los usuarios afectados	Responsable de Seguridad	2 horas
7. Notificación CCN-CERT	Si el ataque causa indisponibilidad prolongada (>4h) o afecta datos, notificar según Guía 817	Responsable de Seguridad	24 horas
8. Post-incidente	Análisis de causa raíz, lecciones aprendidas, actualización de reglas WAF/Shield si procede	Responsable de Seguridad	5 días

Medidas de protección implementadas

Capa	Servicio	Función
Red (L3/L4)	AWS Shield Standard	Protección automática contra ataques volumétricos (SYN flood, UDP reflection)
Aplicación (L7)	AWS WAF (app-pro-backend-waf)	Reglas de rate limiting, bloqueo de IPs maliciosas, protección contra ataques a nivel de aplicación
CDN	AWS CloudFront	Distribución geográfica de contenido estático, absorción de tráfico
DNS	AWS Route 53	Resolución DNS con health checks y failover automático

Escalado a AWS Shield Advanced

Actualmente se utiliza AWS Shield Standard (incluido sin coste). Si la frecuencia o severidad de los ataques lo justifica, se evaluará la contratación de AWS Shield Advanced, que incluye acceso al equipo DDoS Response Team (DRT) de AWS 24/7 y protección de costes contra picos de tráfico DDoS.

Métricas clave:

• Tiempo de detección de ataques DDoS < 60 segundos
• Tiempo de mitigación automática < 300 segundos
• Disponibilidad de servicios críticos > 99.95% durante ataques

MP.S.9 Medios alternativos

Objetivo

Establecer servicios alternativos y de respaldo para garantizar la continuidad de operaciones críticas de dispositivos médicos durante fallos o interrupciones de servicios principales.

Documentos de referencia

• Real Decreto 311/2022 - Artículo 36
• Guía CCN-STIC 817 - Esquema Nacional de Seguridad

Guía de implantación

Implementación para dispositivos médicos

Medidas obligatorias:

1. Servicios de respaldo críticos

   • Servidores espejo para aplicaciones de soporte vital
   • Sistemas de backup para bases de datos de pacientes
   • Servicios de comunicación alternativa para emergencias médicas

2. Arquitectura redundante

   • Balanceadores de carga con failover automático
   • Replicación de datos en tiempo real entre sitios
   • DNS secundario para resolución de servicios críticos

3. Procedimientos de activación

   • Playbooks automatizados para activación de servicios alternativos
   • Umbrales de performance para conmutación automática
   • Notificaciones inmediatas al personal médico durante conmutaciones

4. Testing y mantenimiento

   • Pruebas mensuales de failover para servicios críticos
   • Sincronización continua de configuraciones entre sitios primario y alternativo
   • Validación de integridad de datos durante conmutaciones de servicio

Configuraciones específicas:

• RTO (Recovery Time Objective) < 4 horas para servicios no críticos
• RTO < 30 minutos para servicios críticos de soporte vital
• RPO (Recovery Point Objective) < 15 minutos para datos de pacientes

Monitoreo y métricas:

• Disponibilidad de servicios alternativos > 99.9%
• Tiempo de detección de fallas < 3 minutos
• Tiempo de activación de servicios alternativos < 10 minutos para sistemas críticos

Evaluación de eficacia

Indicadores clave de rendimiento:

• Tiempo medio entre fallas (MTBF) > 720 horas para servicios críticos
• Tiempo medio de reparación (MTTR) < 2 horas para servicios críticos
• Disponibilidad general de servicios médicos > 99.95%

Revisión y mejora continua:

• Auditorías semestrales de capacidad de servicios alternativos
• Simulacros de contingencia con personal médico cada trimestre
• Actualización anual de procedimientos basada en lecciones aprendidas

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager

ㅤ