OP.EXP.10 Protección de los registros de actividad

Documentos de referencia

• Real Decreto 311/2022 - Anexo II, Medida OP.EXP.10
• T-024-016 - Procedimiento de protección de logs
• T-024-017 - Arquitectura de almacenamiento seguro de logs
• GP-013 - Gestión de Ciberseguridad
• OP.EXP.8 - Registro de la actividad de los usuarios
• ISO/IEC 27001:2022 - Control A.8.15 (Protección de registros)
• FDA 21 CFR Part 11 - Integridad de audit trails

Guía de implantación

Objetivo

Garantizar la protección, integridad, disponibilidad y no repudio de todos los registros de actividad (logs) generados por los sistemas de información de Legit Health, asegurando que constituyan evidencia fiable para auditorías, investigaciones forenses y cumplimiento regulatorio.

Alcance

Este procedimiento aplica a:

• Logs de aplicaciones y sistemas
• Registros de auditoría (audit trails)
• Logs de seguridad y eventos
• Registros de acceso y autenticación
• Logs de transacciones del dispositivo médico
• Registros de cambios y configuración
• Logs de infraestructura y red

Amenazas a los registros de actividad

Amenazas identificadas

Amenaza	Impacto	Probabilidad	Controles
Modificación no autorizada	Crítico	Media	Write-once, firma digital
Eliminación accidental/maliciosa	Crítico	Media	Backups, replicación
Acceso no autorizado	Alto	Media	Control de acceso, cifrado
Corrupción de datos	Alto	Baja	Checksums, verificación
Pérdida por fallo hardware	Alto	Baja	Redundancia, cloud
Exfiltración de información	Medio	Media	Cifrado, DLP
Manipulación de timestamps	Alto	Baja	NTP seguro, TSA

Arquitectura de protección

Modelo de seguridad en capas

Arquitectura de Protección de Logs en Capas:

Capa 1: Aplicación

• Generación segura de logs
• Firma digital en origen

Capa 2: Transmisión

• Cifrado TLS 1.3
• Autenticación mutua

Capa 3: Procesamiento

• Validación de integridad
• Normalización y enriquecimiento

Capa 4: Almacenamiento

• Write-once (WORM)
• Cifrado at-rest
• Replicación multi-zona

Flujo de protección

1. Generación: Log creado con timestamp certificado
2. Firma: Aplicación de firma digital al log
3. Cifrado: Encriptación antes de transmisión
4. Transmisión: Envío seguro al colector
5. Validación: Verificación de firma e integridad
6. Almacenamiento: Escritura en storage inmutable
7. Replicación: Copia a múltiples ubicaciones
8. Verificación: Chequeos periódicos de integridad

Medidas de protección implementadas

Protección de integridad

Firma Digital de Logs:

La organización aplica firma digital criptográfica a cada entrada de log para garantizar su integridad y no repudio.

Proceso de Firma de Logs:

1. Serializar el log entry en formato JSON normalizado
2. Calcular hash SHA-256 del contenido serializado
3. Firmar el hash con clave privada usando RSA-PSS con padding MGF1
4. Adjuntar la firma digital y el hash al log entry
5. Codificar firma y hash en Base64 para almacenamiento

Resultado: Cada log contiene su firma digital verificable y hash del contenido.

Hash Chain (Cadena de Bloques):

Los logs se vinculan mediante una cadena de hashes tipo blockchain para detectar cualquier alteración en la secuencia.

Proceso de Cadena de Hash:

1. Incluir el hash del log anterior en el log actual
2. Combinar el hash previo con el contenido del log actual
3. Calcular nuevo hash SHA-256 de la combinación
4. Almacenar el hash actual y referencia al hash previo
5. Resultado: Cadena inmutable donde cualquier modificación rompe la secuencia completa

Verificación periódica:

• Verificación automática cada 6 horas
• Validación completa semanal
• Auditoría de integridad mensual
• Alertas inmediatas ante discrepancias

Protección de confidencialidad

Cifrado en Reposo:

Configuración	Especificación
Algoritmo	AES-256-GCM
Gestión de Claves	AWS KMS
Rotación de Claves	Automática cada 90 días
Control de Acceso	Basado en roles IAM
Auditoría	AWS CloudTrail habilitado

Cifrado en Tránsito:

Configuración	Especificación
Protocolo	TLS 1.3
Cipher Suites	TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
Certificado	EV SSL
Autenticación Mutua	Requerida para sistemas críticos
Perfect Forward Secrecy	Habilitado

Anonimización de Datos Sensibles:

La organización aplica técnicas de anonimización a los logs para proteger datos personales mientras mantiene utilidad para análisis de seguridad.

Proceso de Anonimización:

1. Hashear datos PII: Identificadores de paciente se convierten a hash irreversible
2. Enmascarar IPs internas: Direcciones IP se enmascaran parcialmente
3. Eliminar números de tarjeta: Datos de pago se eliminan completamente antes del almacenamiento
4. Preservar utilidad: Datos anonimizados mantienen valor para análisis de seguridad

Protección de disponibilidad

Arquitectura de Alta Disponibilidad:

La organización implementa una arquitectura multi-zona para garantizar disponibilidad continua de los logs.

Configuración de Zonas:

Zona	Función	Sincronización
AZ1 (eu-west-1a)	Primary Storage	Escritura principal
AZ2 (eu-west-1b)	Replica 1	Síncrona desde AZ1
AZ3 (eu-west-1c)	Replica 2	Asíncrona desde AZ1

Load Balancer: Activo-Activo para distribución de carga de lectura

Configuración de Replicación y Backup:

• Replicación síncrona: A zona secundaria (AZ2) para mínima pérdida de datos
• Replicación asíncrona: A zona terciaria (AZ3) para balance coste-performance
• Backup diario: A S3 Glacier para retención a largo plazo
• Snapshots: Cada 4 horas para recuperación rápida

Control de acceso

Modelo de Permisos Basado en Roles:

Rol	Permisos	Alcance	Requisitos Adicionales
log-reader	Lectura	Logs no sensibles	MFA requerido
log-analyst	Lectura, búsqueda, exportación	Todos los logs	MFA + aprobación de manager
log-admin	Lectura, búsqueda, exportación, configuración	Todos los logs + configuración	MFA + aprobación CISO + control dual
system	Escritura	Fuente asignada	Autenticación por certificado

Registro de Accesos a Logs:

Cada acceso a los logs se registra con la siguiente información para garantizar trazabilidad:

Campo	Ejemplo
Timestamp	2024-11-15T10:30:00Z
Usuario	analyst@legithealth.com
Acción	search
Consulta	error_level:critical AND timestamp:[2024-11-14 TO 2024-11-15]
Resultados	42 registros devueltos
Justificación	Investigating incident INC-2024-1115
Aprobado por	manager@legithealth.com
Session ID	sess-uuid-12345

Almacenamiento seguro

Tecnología WORM (Write Once Read Many)

Configuración AWS S3 Object Lock:

Parámetro	Configuración
Bucket	legit-health-immutable-logs
Modo Object Lock	COMPLIANCE
Período Retención	2555 días (7 años)
Legal Hold	Disponible cuando sea requerido
Versionado	Habilitado
MFA Delete	Habilitado
Replicación	Cross-region a eu-central-1

Prevención de Modificación (Inmutabilidad):

• Una vez escrito, el log no se puede modificar ni eliminar
• Ni siquiera el root account puede bypassear la protección
• Cumple con normativas: SEC 17a-4, FINRA 4511, CFTC 1.31

Segregación de almacenamiento

Estructura de Almacenamiento por Criticidad y Retención:

Categoría	Criticidad	Retención	Subcategorías
/security/	CRÍTICO	7 años	authentication, authorization, incidents
/clinical/	ALTO	10 años	patient-access, diagnoses, treatments
/operational/	MEDIO	3 años	performance, errors, debugging
/compliance/	CRÍTICO	10 años	audit-trails, regulatory, data-processing

Sincronización temporal

NTP seguro

Configuración NTP:

Servidores NTP:

• Primario: time.google.com
• Secundario: time.cloudflare.com
• Terciario: pool.ntp.org

Configuración de Seguridad:

Parámetro	Valor
Autenticación	Clave simétrica
Protocolo	NTPv4
Stratum Máximo	3
Tolerancia de Drift	± 100ms

Monitorización:

Parámetro	Configuración
Intervalo de Chequeo	5 minutos
Umbral de Alerta	± 1 segundo de drift
Auto-corrección	Habilitada

Timestamp Authority (TSA)

Integración con Timestamp Authority:

La organización utiliza un servicio de Timestamp Authority (TSA) conforme a RFC 3161 para certificar el timestamp de logs críticos.

Proceso de Certificación de Timestamp:

1. Crear solicitud RFC 3161
   • Incluir hash SHA-256 del contenido del log
   • Solicitar certificado de timestamp
2. Enviar a TSA
   • Transmisión segura a autoridad de timestamp
   • Autenticación mediante certificado cliente
3. Validar respuesta
   • Verificar estado de éxito de la respuesta
   • Extraer token de timestamp certificado
4. Almacenar token
   • Adjuntar token al log para prueba verificable de existencia en momento específico

Resultado: Timestamp certificado por tercera parte confiable que prueba la existencia del log en momento específico.

Procedimientos de verificación

Verificación de integridad

Verificación Automática (Cada 6 Horas):

La organización ejecuta verificaciones automáticas de integridad de logs cada 6 horas para detectar cualquier alteración o anomalía.

Proceso de Verificación Automática:

1. Seleccionar Muestra Aleatoria

   • Tamaño mínimo: 1,000 logs
   • O 1% del total de logs (el mayor de los dos)
   • Selección aleatoria para representatividad

2. Para Cada Log en la Muestra: a) Verificar Firma Digital

   • Validar firma criptográfica del log
   • Si falla → Registrar error de firma b) Verificar Hash Chain
   • Verificar integridad de la cadena de bloques
   • Si falla → Registrar ruptura de cadena c) Verificar Timestamp
   • Validar timestamp del log
   • Si falla → Registrar timestamp inválido

3. Si se Detectan Errores:

   • Alertar al equipo de seguridad inmediatamente
   • Iniciar análisis forense para investigar causa
   • Documentar todos los errores detectados

4. Resultado:

   • Éxito: Sin errores detectados en la muestra
   • Fallo: Uno o más errores encontrados → Investigación forense iniciada

Auditoría forense

Procedimiento de análisis forense:

1. Aislar logs sospechosos
2. Crear copia forense certificada
3. Analizar metadatos y timestamps
4. Verificar cadena de custodia
5. Reconstruir secuencia de eventos
6. Identificar punto de compromiso
7. Documentar hallazgos
8. Preservar evidencias

Recuperación y restauración

Procedimiento de recuperación

Recovery Procedure:

1. Identify Failure:
   • Type: Corruption / Deletion / Hardware failure
   • Scope: Time range and systems affected
   • Impact: Critical / High / Medium / Low
2. Select Recovery Source:
   • Primary: Hot standby replica
   • Secondary: Recent backup (< 24h)
   • Tertiary: Archive storage
3. Validate Backup:
   • Verify checksums
   • Check signatures
   • Confirm completeness
4. Restore Process:
   • Isolate affected storage
   • Restore from validated source
   • Verify hash chains
   • Re-establish replication
5. Verification:
   • Compare with known-good hashes
   • Validate time continuity
   • Check for gaps
6. Documentation:
   • Document incident
   • Record recovery actions
   • Update disaster recovery plan

Tiempos de recuperación

Fuente	RTO	RPO	Disponibilidad
Réplica hot standby	< 5 min	0	99.99%
Backup reciente	< 1 hora	< 24h	99.9%
Archivo (Glacier)	< 12 horas	< 7 días	99.99%
Cinta (offsite)	< 48 horas	< 30 días	99.999%

Cumplimiento regulatorio

Requisitos FDA 21 CFR Part 11

• ✓ Audit trails seguros y automáticos
• ✓ Firma electrónica en registros críticos
• ✓ Imposibilidad de modificación
• ✓ Timestamps certificados
• ✓ Backup y recuperación validados
• ✓ Controles de acceso documentados

Requisitos ENS

• ✓ Protección acorde a categoría ALTA
• ✓ Integridad garantizada mediante firma
• ✓ Disponibilidad 99.9% mínimo
• ✓ Retención mínima 2 años
• ✓ Sincronización temporal certificada
• ✓ Segregación por nivel de sensibilidad

Métricas y monitorización

KPIs de protección

Métrica	Objetivo	Actual	Tendencia
Integridad logs	100%	99.999%	→
Disponibilidad sistema	99.9%	99.95%	↑
Tiempo verificación	< 10 min	7 min	↓
Logs perdidos/mes	0	0	→
Intentos modificación	-	3/mes	↓
Recuperaciones exitosas	100%	100%	→

Dashboard de protección

┌─────────────────────────────────────────────────┐ │ LOG PROTECTION DASHBOARD │ ├─────────────────────────────────────────────────┤ │ Storage Status: [██████████] 100% Healthy │ │ Replication: All zones synchronized │ │ Last Integrity: 2024-11-15 10:00:00 ✓ │ │ Signatures Valid: 15,234,567 / 15,234,567 │ │ Access Attempts: 342 (3 blocked) │ │ Archive Status: On schedule │ │ Alerts: 0 Critical, 2 Warning │ └─────────────────────────────────────────────────┘

Procedimientos de emergencia

Respuesta a compromiso de logs

1. Detección (T+0)
   • Alerta automática de integridad fallida
   • Activación equipo de respuesta
2. Contención (T+15min)
   • Aislar sistemas afectados
   • Detener escritura a logs comprometidos
   • Activar almacenamiento alternativo
3. Análisis (T+1h)
   • Determinar alcance del compromiso
   • Identificar período afectado
   • Evaluar impacto regulatorio
4. Recuperación (T+4h)
   • Restaurar desde fuente confiable
   • Revalidar integridad completa
   • Restablecer operaciones normales
5. Notificación (T+24h)
   • Informar a autoridades si requerido
   • Documentar para auditoría
   • Actualizar procedimientos

Formación y concienciación

• Administradores: Gestión segura de logs (semestral)
• Desarrolladores: Implementación de logging seguro
• Analistas: Uso de herramientas de verificación
• Auditores: Validación de cadena de custodia

Documentación y evidencias

• T-024-016: Procedimiento detallado de protección
• T-024-017: Arquitectura técnica de seguridad de logs
• Informes de integridad: Generados automáticamente
• Certificados TSA: Almacenados con cada lote de logs
• Registros de acceso: Audit trail de consultas a logs
• Informes de recuperación: Documentación de cada restore

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, JD-004
• Approver: JD-001