Operación ShadowLock

01 —

Equipo CSIRT

Cuatro estudiantes, cuatro fases, un objetivo: responder al incidente.

Carlos D. León

ID: 10163099

Fase 1 — Preparación

Matriz RACI · Política IR · Backups · Herramientas

Steven

ID: 10163717

Fase 2 — Detección y Análisis

Cronología · Comandos · Clasificación

+ Página Web del Proyecto

Jose Alberto

ID: 10163332

Fase 3 — Contención y Recuperación

Contención · Erradicación · Golden Image

Luiz M. Díaz

ID: 10162142

Fase 4 — Post-Incidente

Métricas · Costos · Mejoras 30/60/90 días

02 —

Resumen Ejecutivo

MedTech Dominicana fue víctima de un ataque de ransomware Ryuk que cifró sistemas críticos y comprometió historiales médicos de pacientes.

Organización Afectada

MedTech Dominicana

Tipo de Ataque

Ransomware Ryuk — Categoría 1

Sistemas Afectados

Servidores, historiales médicos, sistema de citas

Regulaciones Violadas

HIPAA + Ley 172-13 (Rep. Dominicana)

Detección

26 de marzo de 2026 — 08:30 AM

Responsable

Incident Response Manager · CSIRT

03 — 06

Las 4 Fases NIST

Marco completo de gestión de incidentes aplicado al ataque Operación ShadowLock.

Responsable: Carlos D. León — ID: 10163099 · NIST Sección 2

La preparación define los recursos, equipos, políticas y herramientas necesarias antes de que ocurra cualquier incidente.

Matriz RACI — Equipo CSIRT

Rol	Detección	Contención	Erradicación	Recuperación	Post-Inc.
IR Manager	A	A	A	A	A
Analista SOC	R	R	C	I	C
Ing. de Sistemas	C	R	R	R	C
Asesor Legal	I	C	I	C	R
Dir. Médico	I	I	I	R	I
Comunicaciones	I	I	I	I	R
CISO	C	A	C	C	A

R = Responsable A = Accountable C = Consulted I = Informed

Política IR Oficial

Alcance y Objetivo

Esta política establece el marco formal para la detección, reporte, manejo y recuperación de incidentes en MedTech Dominicana, en cumplimiento con NIST SP 800-61 Rev. 2, HIPAA y Ley 172-13 de la República Dominicana.

Reglas Obligatorias

Todo incidente debe reportarse al IR Manager en máximo 1 hora desde su detección.
Ningún empleado puede manejar un incidente de forma independiente sin notificar al CSIRT.
Se debe preservar la evidencia digital antes de cualquier acción correctiva.
La comunicación externa es exclusiva de Comunicaciones y el Asesor Legal.
El cumplimiento con HIPAA y Ley 172-13 es obligatorio en toda respuesta.

Plan de Backups 3-2-1 — Ejecución Real

🔄

rsync v3.4.1 OUTPUT REAL

Elegimos rsync como herramienta de backup porque es el estándar de facto en sistemas Linux/Unix para sincronización incremental de archivos. A diferencia de un simple cp, rsync verifica integridad bloque a bloque, solo transfiere lo que cambió (delta), soporta cifrado vía SSH y genera logs detallados auditables — exactamente lo que requiere una política de backup conforme al NIST SP 800-61.

¿Por qué no otras opciones? Amanda o Bacula son más complejos de configurar para un entorno médico pequeño. Duplicati requiere interfaz gráfica. rsync es ligero, scriptable y verificable — ideal para automatizar con cron y auditar cada transferencia.

rsync — Backup 3-2-1 · Copia 1: NAS Local (backup_local)

# Backup de pacientes → NAS local (simula almacenamiento cifrado AES-256)

$ rsync -av --progress ~/medtech/pacientes/ ~/medtech/backup_local/pacientes/

sending incremental file list

created directory /home/stevenkrx/medtech/backup_local/pacientes

./

juan_perez.txt

62 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=1/3)

maria_lopez.txt

66 100% 64.45kB/s 0:00:00 (xfr#2, to-chk=0/3)

sent 339 bytes received 126 bytes 930.00 bytes/sec

total size is 128 speedup is 0.28

rsync — Backup 3-2-1 · Copia 2: Offsite (Datacenter Santo Domingo)

# Backup offsite → simula réplica en datacenter externo

$ rsync -av --progress ~/medtech/pacientes/ ~/medtech/backup_offsite/pacientes/

sending incremental file list

created directory /home/stevenkrx/medtech/backup_offsite/pacientes

juan_perez.txt

62 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=1/3)

maria_lopez.txt

66 100% 64.45kB/s 0:00:00 (xfr#2, to-chk=0/3)

sent 339 bytes received 128 bytes 934.00 bytes/sec

total size is 128 speedup is 0.27

md5sum — Verificación de Integridad de las 3 Copias

# Verificar que los hashes sean idénticos en las 3 copias

$ find ~/medtech/pacientes ~/medtech/citas ~/medtech/historiales -type f | sort | xargs md5sum

--- ORIGEN ---

028ac806e2efc3c21e6a211db423f638 .../citas/citas_marzo.txt

d1c50bc8b85be60dc22070f189c97f39 .../historiales/historial_001.txt

66e84e9a3949322eda05f5371501cb5f .../pacientes/juan_perez.txt

1836d37f35e127f3c2908b4fcb8793db .../pacientes/maria_lopez.txt

--- BACKUP LOCAL (NAS) ---

028ac806e2efc3c21e6a211db423f638 .../backup_local/citas/citas_marzo.txt

d1c50bc8b85be60dc22070f189c97f39 .../backup_local/historiales/historial_001.txt

66e84e9a3949322eda05f5371501cb5f .../backup_local/pacientes/juan_perez.txt

1836d37f35e127f3c2908b4fcb8793db .../backup_local/pacientes/maria_lopez.txt

--- BACKUP OFFSITE (Datacenter SD) ---

028ac806e2efc3c21e6a211db423f638 .../backup_offsite/citas/citas_marzo.txt

d1c50bc8b85be60dc22070f189c97f39 .../backup_offsite/historiales/historial_001.txt

66e84e9a3949322eda05f5371501cb5f .../backup_offsite/pacientes/juan_perez.txt

1836d37f35e127f3c2908b4fcb8793db .../backup_offsite/pacientes/maria_lopez.txt

✓ Hashes MD5 idénticos en las 3 copias — Integridad verificada

✓ Backup 3-2-1 completado: 4 archivos · 3 destinos · 0 errores

Herramientas Utilizadas — Verificadas en Laboratorio

rsync — Backup 3-2-1 de datos médicos v3.4.1

Fase 1 · Copia incremental con verificación de integridad MD5

osquery — Detección de procesos y conexiones v5.21.0

Fase 2 · Consultas SQL en tiempo real al sistema operativo

nmap — Escaneo de red y detección de propagación v7.98

Fase 3 · Ping sweep para mapear hosts comprometidos

ClamAV — Erradicación y escaneo antivirus v1.5.2

Fase 3 · 3,627,814 firmas · 0 infectados confirmado

md5sum — Verificación de integridad de backups GNU coreutils

Fase 1 · Hashes idénticos en las 3 copias verificados

freshclam — Actualización de firmas ClamAV v1.5.2

Fase 3 · Base de datos actualizada antes del escaneo

Responsable: Steven — ID: 10163717 · NIST Secciones 3.1–3.2

Identificación del ataque, análisis técnico detallado y clasificación del incidente según su impacto sobre sistemas médicos críticos.

Cronología del Incidente

06:30 AM

Actividad anómala detectada

Múltiples accesos a archivos médicos en horas no laborables desde cuenta administrativa.

07:15 AM — ALERTA EDR

Proceso malicioso identificado

CrowdStrike detecta ryuk.exe activo en estación Admin-01. Propagación lateral iniciada vía SMB.

07:45 AM — CRÍTICO

Propagación a 3 servidores adicionales

Ransomware explota puerto 445 (SMB) para moverse lateralmente dentro de la red interna de la clínica.

08:30 AM — CIFRADO MASIVO

Nota de rescate en todos los escritorios

Archivos cifrados con extensión .ryuk. Sistema de citas caído. MTTD confirmado: 2 horas.

08:30 AM

Incidente escalado al CSIRT completo

Declarado Categoría 1 / Prioridad Crítica. IR Manager asume comando del incidente.

Herramienta de Detección — Justificación y Output Real

🔍

osquery v5.21.0 OUTPUT REAL

Elegimos osquery para la fase de detección porque convierte el sistema operativo en una base de datos relacional consultable con SQL estándar. Esto permite al analista SOC interrogar procesos, conexiones de red, archivos y usuarios con una sola interfaz unificada — sin necesidad de aprender múltiples comandos del sistema. En el contexto de MedTech Dominicana, esto reduce el MTTD al permitir queries inmediatas como "muéstrame todos los procesos con uso de CPU anormal" o "qué conexiones externas activas hay ahora mismo".

¿Por qué no otras opciones? Sysmon requiere Windows y configuración XML compleja. Auditd genera logs verbosos difíciles de filtrar en tiempo real. Volatility es excelente para forense post-mortem pero no para detección en vivo. osquery es multiplataforma, liviano y permite detección en tiempo real con una curva de aprendizaje mínima.

osquery v5.21.0 — Detección de Procesos Sospechosos por CPU

# Identificar procesos con mayor consumo — vector inicial de Ryuk

osquery> SELECT name, path, pid, user_time, system_time, uid

FROM processes ORDER BY user_time DESC LIMIT 10;

name = brave

path = /opt/brave-bin/brave

pid = 61032

user_time = 6809540

system_time = 637620

uid = 1000

name = wireplumber

path = /usr/bin/wireplumber

pid = 1610

user_time = 908880

system_time = 125710

uid = 1000

name = Hyprland

path = /usr/bin/Hyprland

pid = 1183

user_time = 828170

system_time = 576740

uid = 1000

✓ Sin procesos anómalos detectados — En escenario real, ryuk.exe aparecería aquí con user_time > 5,000,000

osquery v5.21.0 — Análisis de Archivos en Directorios Temporales

# Buscar archivos sospechosos en /tmp — Ryuk copia su payload aquí

osquery> SELECT path, size, type FROM file WHERE path LIKE '/tmp/%' LIMIT 10;

path = /tmp/checkup-db-1000/

size = 80 | type = directory

path = /tmp/org.chromium.Chromium.cC65n7/

size = 80 | type = directory

path = /tmp/sddm-:0-zVFaau

size = 0 | type = socket

path = /tmp/systemd-private-d224d267746b4c93a6c1c312184a05f2-bluetooth.service-yMTU6f/

size = 60 | type = directory

✓ Sin archivos .ryuk o .enc detectados en /tmp — Entorno limpio verificado

osquery v5.21.0 — Monitoreo de Conexiones de Red Activas (C2 Detection)

# Detectar conexiones C2 (Command & Control) — patrón típico de Ryuk

osquery> SELECT pid, local_address, local_port, remote_address, remote_port, state

FROM process_open_sockets WHERE remote_port != 0 LIMIT 10;

pid = 2127 | local_address = 192.168.0.110

local_port = 41828 | remote_address = 151.101.66.137

remote_port = 443 | state = ESTABLISHED

pid = 2127 | remote_address = 157.240.14.52

remote_port = 5222 | state = ESTABLISHED

pid = 2127 | remote_address = 18.97.36.17

remote_port = 443 | state = ESTABLISHED

pid = -1 | local_port = 68

remote_address = 192.168.0.1 | remote_port = 67

✓ Conexiones corresponden a tráfico legítimo (HTTPS/443) — Sin IPs C2 maliciosas

# En escenario Ryuk real: se detectarían conexiones a IPs TOR o rangos 185.x.x.x conocidos como C2

Clasificación del Incidente

Categoría NIST

● Categoría 1

Malware / Ransomware con impacto en sistemas críticos de salud.

Prioridad

● Alta / Crítica

Impacto directo en vidas humanas por sistemas médicos comprometidos.

Confidencialidad

● Comprometida

Riesgo de exfiltración de historiales médicos de pacientes.

Integridad

● Comprometida

Archivos cifrados y potencialmente alterados por el malware.

Disponibilidad

● Comprometida

Sistema de citas y registros médicos completamente inoperativos.

Marco Regulatorio

HIPAA Ley 172-13

Notificación obligatoria en 72 horas según ambas regulaciones.

Responsable: Jose Alberto — ID: 10163332 · NIST Sección 3.3

Detener la propagación, eliminar el ransomware del entorno y restaurar los sistemas desde backups verificados.

Contención Inmediata (0 – 4 horas)

01

Desconectar servidores afectados de la red

Aislamiento físico y lógico de Admin-01 y los 3 servidores comprometidos.

Ejecutado — 08:45 AM

02

Activar firewall en todos los perfiles de red

Bloqueo total del tráfico entrante sospechoso vía Windows Firewall.

Ejecutado — 08:50 AM

03

Bloquear puertos SMB (445) y RDP (3389)

Vectores usados por Ryuk para propagación lateral en la red interna.

Ejecutado — 09:00 AM

04

Deshabilitar cuentas administrativas comprometidas

Revocación inmediata de credenciales expuestas durante el ataque.

Ejecutado — 09:15 AM

05

Notificación HIPAA + Ley 172-13

Proceso legal de notificación a pacientes afectados y autoridades regulatorias.

En proceso — Asesor Legal

Herramientas de Contención y Erradicación — Justificación y Output Real

🌐

nmap v7.98 OUTPUT REAL

Elegimos nmap para la fase de contención porque es la herramienta más confiable para mapear rápidamente todos los dispositivos activos en la red local — paso crítico para determinar el alcance de la propagación lateral de Ryuk. Un ping sweep con -sn identifica en segundos cuántos equipos están activos sin generar tráfico intrusivo que alertaría al atacante.

¿Por qué no otras opciones? Angry IP Scanner tiene interfaz gráfica (no scriptable). netdiscover es más lento y menos confiable. Masscan es demasiado agresivo para una red médica en producción. nmap tiene el equilibrio perfecto entre velocidad, precisión y control granular del escaneo.

🛡️

ClamAV v1.5.2 OUTPUT REAL

Elegimos ClamAV para la erradicación porque es el antivirus open-source más completo disponible en Linux, con una base de datos actualizable de más de 3.6 millones de firmas. Permite escanear recursivamente todos los directorios de datos médicos restaurados para confirmar que el backup no contiene archivos comprometidos antes de reconectar los sistemas a la red.

¿Por qué no otras opciones? Maldet está desactualizado. Chkrootkit detecta rootkits pero no ransomware. Sophos y Kaspersky son de pago. ClamAV es gratuito, actualizable automáticamente con freshclam y genera reportes auditables — ideal para documentar la erradicación ante reguladores HIPAA y Ley 172-13.

nmap v7.98 — Ping Sweep · Detección de Propagación Lateral en Red 192.168.0.0/24

# Identificar todos los hosts activos — determinar alcance del ransomware

$ sudo nmap -sn 192.168.0.0/24 -oN ~/medtech/scan_red.txt

Starting Nmap 7.98 ( https://nmap.org ) at 2026-04-03 17:33 -0400

Nmap scan report for 192.168.0.1

Host is up (0.0026s latency).

MAC Address: 08:40:F3:63:26:A8 (Tenda Technology — Router)

Nmap scan report for 192.168.0.110

Host is up.

Nmap done: 256 IP addresses (2 hosts up) scanned in 2.90 seconds

✓ Solo 2 hosts activos: Router (192.168.0.1) + Estación de trabajo (192.168.0.110)

✓ Sin propagación lateral detectada — Red contenida exitosamente

# En escenario Ryuk real: se verían múltiples hosts comprometidos en el mismo segmento /24

ClamAV v1.5.2 — Actualización de Firmas + Escaneo de Erradicación

# Paso 1: Actualizar base de datos de firmas antes de escanear

$ sudo freshclam

ClamAV update process started at Fri Apr 3 17:33:53 2026

daily database available for download (remote version: 27960)

daily.cvd updated (version: 27960, sigs: 355404, f-level: 90)

main.cvd updated (version: 63, sigs: 3287027, f-level: 90)

bytecode.cvd updated (version: 339, sigs: 80, f-level: 90)

✓ Base de datos actualizada: 3,642,511 firmas totales

# Paso 2: Escaneo recursivo de todos los datos médicos restaurados

$ clamscan -r ~/medtech/ --infected --log=/home/stevenkrx/medtech/clamav_scan.txt

----------- SCAN SUMMARY -----------

Known viruses: 3627814

Engine version: 1.5.2

Scanned directories: 12

Scanned files: 14

Infected files: 0

Data scanned: 1.42 KiB

Start Date: 2026:04:03 17:35:30

End Date: 2026:04:03 17:35:49

✓ 0 archivos infectados — 3,627,814 firmas verificadas

✓ 12 directorios · 14 archivos escaneados — Sistema limpio confirmado

✓ Datos médicos seguros para reconectar a la red de producción

Recuperación — Golden Image

#	Paso	Tiempo Est.	Responsable	Estado
01	Restaurar desde backup offline (Golden Image)	4 h	Ing. Sistemas	Completado
02	Probar restauración en entorno aislado (sandbox)	6 h	Analista SOC	Completado
03	Verificar integridad de datos médicos	8 h	Dir. Médico	Completado
04	Reconectar sistemas con monitoreo intensivo	2 h	Ing. Sistemas	Completado
05	Monitoreo continuo durante 72 horas	72 h	Analista SOC	Completado
06	Confirmar restauración y cierre del incidente	2 h	IR Manager	Cerrado

Responsable: Luiz M. Díaz — ID: Pendiente · NIST Sección 3.4

Documentar lecciones aprendidas, calcular métricas de desempeño e implementar mejoras para fortalecer la postura de seguridad.

Métricas de Desempeño

2 h

Objetivo < 4 h

MTTD — Detección

Cumplido

48 h

Objetivo < 72 h

MTTR — Recuperación

Cumplido

45 min

Objetivo < 2 h

Contención

Excelente

100 %

Sistemas restaurados

Recuperación

Cumplido

Análisis de Costos

Categoría	Costo (RD$)	Observación
Tiempo de inactividad (48 h)	800,000	Sistema de citas caído
Honorarios legales HIPAA + Ley 172-13	450,000	Notificaciones y asesoría
Recuperación técnica (horas extra IT)	350,000	72 horas de trabajo intensivo
Herramientas forenses y licencias	200,000	Velociraptor Enterprise, etc.
Comunicación a pacientes afectados	150,000	Cartas certificadas + call center
Mejoras de seguridad post-incidente	550,000	MFA, EDR, segmentación de red
Total Estimado	RD$ 2,500,000	Costo total del incidente

Plan de Mejoras — 30 / 60 / 90 Días

30 días

Acciones Críticas

Implementar MFA en todos los sistemas. Actualizar y probar backups offline. Parchear vulnerabilidades SMB/RDP.

60 días

Hardening de Red

Segmentar red en VLANs por departamento. Realizar tabletop exercise completo. Actualizar política IR.

90 días

Cultura de Seguridad

Capacitación en ciberseguridad para todo el personal. Monitoreo 24/7 con SIEM. Revisión trimestral del plan IR.

07 —

Tabletop Exercise

Simulacro de 45 minutos donde el equipo CSIRT practica la toma de decisiones en un entorno controlado.

Escenario 01

⏱ 10 minutos

Detección del Incidente

El SOC recibe alerta del EDR. El proceso ryuk.exe está activo en Admin-01 y hay tráfico hacia IPs externas desconocidas.

Correlaciona la alerta del EDR con otras fuentes: revisa logs de Windows Event (IDs 4688, 7045), verifica si el proceso tiene firma digital válida, analiza el hash del archivo en VirusTotal, y confirma si hay tráfico C2 saliente. Si dos o más indicadores coinciden, es verdadero positivo.
NIST SP 800-61 § 3.2.2 — Analyzing Incidents
Escala inmediatamente al confirmar el verdadero positivo o si el impacto potencial supera la capacidad del analista individual. En este caso, al detectar ryuk.exe activo y tráfico C2, la escalada es automática e inmediata — no esperes a tener certeza total para activar el CSIRT.
NIST SP 800-61 § 3.2.7 — Incident Notification
Captura imagen forense de memoria RAM, dump del proceso sospechoso, logs del sistema (Security, Application, System), tráfico de red (pcap), y estado actual del sistema de archivos. Nunca apagues el equipo primero — la RAM contiene claves de cifrado que se pierden al apagarlo.
NIST SP 800-61 § 3.3.2 — Evidence Gathering
Según la Matriz RACI, el IR Manager es el primero en ser notificado (Accountable). El Analista SOC que detectó el incidente es el Responsable del reporte inicial. El CISO es Consulted en esta fase. Todos los demás roles son Informed una vez confirmado el incidente.
NIST SP 800-61 § 2.4.2 — Incident Response Team

Escenario 02

⏱ 15 minutos

Decisión de Contención

El ransomware se propaga activamente. ¿Aíslas solo el servidor afectado o desconectas toda la red incluyendo urgencias?

Opción A (aislar solo servidor): el ransomware continúa propagándose, riesgo de cifrado total en minutos. Opción B (cortar toda la red): sistemas de urgencias y monitoreo de pacientes quedan sin datos en tiempo real. La decisión correcta según NIST es contención selectiva: aislar los segmentos afectados, manteniendo activos los sistemas críticos de soporte vital.
NIST SP 800-61 § 3.3.1 — Containment Strategies
Ambas opciones generan obligaciones bajo HIPAA. Si el ransomware continúa (Opción A), el riesgo de exfiltración escala y la notificación es obligatoria en 72h. Si cortas la red (Opción B), debes documentar que la interrupción fue para proteger la integridad de la PHI (Protected Health Information). HIPAA exige documentar todas las decisiones tomadas durante el incidente.
HIPAA Breach Notification Rule § 164.404
Es aceptable cuando: (1) la propagación es activa e incontrolable, (2) existen protocolos manuales de emergencia documentados y listos, (3) los equipos de soporte vital funcionan de forma autónoma sin red, y (4) el personal médico ha sido notificado. Nunca se corta sin antes activar el protocolo de contingencia manual.
NIST SP 800-61 § 3.3.1 — Choosing a Containment Strategy
Monitores cardíacos, ventiladores, bombas de infusión IV, sistemas de alarma de urgencias y desfibriladores. Estos deben estar en una VLAN aislada de misión crítica con acceso físico independiente. Si están en la misma red comprometida, activa inmediatamente los protocolos manuales de las áreas de UCI y emergencias.
NIST SP 800-82 — ICS/SCADA Critical Systems

Escenario 03

⏱ 20 minutos

Comunicación de Crisis

Los atacantes amenazan publicar 5,000 historiales médicos si no se paga el rescate. Un periodista llama. Salud Pública pide un informe.

No. El NIST, el FBI y CISA recomiendan explícitamente no pagar. Razones: (1) pagar no garantiza recuperar los datos, (2) financia operaciones criminales futuras, (3) convierte a la organización en objetivo recurrente, (4) puede violar sanciones del OFAC si el grupo está en lista negra. La alternativa es restaurar desde backups offline verificados.
NIST SP 800-61 § 3.3.4 — CISA Ransomware Guide 2021
Solo el vocero oficial designado por Comunicaciones y el Asesor Legal puede hablar con prensa. El mensaje debe ser: "Estamos atendiendo un incidente de seguridad, hemos activado nuestros protocolos de respuesta y la seguridad de nuestros pacientes es nuestra prioridad. Informaremos conforme avance la situación." Nunca confirmar detalles técnicos ni el vector del ataque.
NIST SP 800-61 § 3.2.7 — External Communications
HIPAA exige notificar al HHS (Dept. of Health) en 60 días tras confirmar la brecha, y a los pacientes afectados sin demora irrazonable. La Ley 172-13 RD exige notificación a la autoridad competente en 72 horas. La notificación debe incluir: qué datos fueron afectados, cuándo ocurrió, qué medidas se tomaron y cómo los pacientes pueden protegerse.
HIPAA § 164.404 + Ley 172-13 RD Art. 29
El informe debe incluir: (1) cronología del incidente, (2) sistemas y datos afectados, (3) número aproximado de pacientes impactados, (4) medidas de contención adoptadas, (5) estado actual de los sistemas, (6) plan de recuperación y tiempos estimados, y (7) medidas para prevenir recurrencia. Debe ser firmado por el Director Médico y el Asesor Legal.
NIST SP 800-61 § 3.4 — Post-Incident Activity

Rúbrica de Evaluación

Competencia	Criterio de Éxito	Peso
Velocidad de detección	Escalada al CSIRT en < 30 min	25 %
Decisión de contención	Decisión documentada y justificada	25 %
Gestión de comunicación	Cumple plazos HIPAA y Ley 172-13	25 %
Coordinación del equipo RACI	Todos los roles activos y coordinados	25 %

Equipo CSIRT

Resumen Ejecutivo

Las 4 Fases NIST

Tabletop Exercise

OPERACIÓN
SHADOWLOCK