NIST CSF 2.0 — PROTECT: Controles que reducen el impacto de un ataque
Conocer el riesgo no es suficiente. PROTECT es donde se actúa sobre él. Analizamos las 5 categorías, priorizamos controles desde el registro de riesgos y construimos la defensa en profundidad de TechCorp Latam.
De saber el riesgo a actuar sobre él
En el post anterior, TechCorp Latam completó su función IDENTIFY: tenían 163 activos catalogados, 10 de criticidad alta o crítica, y 8 riesgos priorizados — dos de nivel EXTREMO. El inventario y el registro de riesgos estaban sobre la mesa.
Ahora viene la pregunta que toda dirección termina haciendo: ¿y qué hacemos con esto?
La respuesta es PROTECT. Esta función no elimina el riesgo — eso es imposible. Lo que hace es implementar los controles y salvaguardas que reducen la probabilidad de que un ataque tenga éxito y, cuando ocurre, limitan su impacto.
"PROTECT no te hace invulnerable. Te hace resiliente. Y en ciberseguridad, la resiliencia vale más que la ilusión de la invulnerabilidad."
El error más común en esta función es querer implementar todo a la vez. La clave es priorizar desde el riesgo: los controles que mitigan los riesgos de mayor criticidad identificados en IDENTIFY van primero, siempre.
¿Qué cubre la función PROTECT en el NIST CSF 2.0?
PROTECT abarca los controles preventivos y de reducción de impacto que la organización implementa para salvaguardar sus activos. En la v2.0 se organiza en 5 categorías y 21 subcategorías:
| Código | Categoría | Resultado esperado |
|---|---|---|
| PR.AA | Identity Management & Access Control | El acceso a activos está limitado a usuarios, procesos y dispositivos autorizados, gestionado conforme al riesgo de acceso no autorizado. |
| PR.AT | Awareness and Training | El personal entiende sus roles y responsabilidades en ciberseguridad y está capacitado para ejecutarlos. |
| PR.DS | Data Security | Los datos son gestionados conforme a la estrategia de riesgo para proteger su confidencialidad, integridad y disponibilidad. |
| PR.PS | Platform Security | El hardware, software y servicios están gestionados conforme a la estrategia de riesgo para proteger su confidencialidad, integridad y disponibilidad. |
| PR.IR | Technology Infrastructure Resilience | Las arquitecturas de seguridad son gestionadas con resiliencia frente a eventos de ciberseguridad. |
En la v1.1, PROTECT tenía 6 categorías. En la v2.0 se reorganizaron en 5: Protective Technology (PT) y Maintenance (MA) se fusionaron dentro de PR.PS (Platform Security), y PR.IR reemplaza y amplía la antigua categoría de protección de infraestructura.
El modelo de defensa en profundidad
PROTECT no es una lista de controles aislados — es una arquitectura de capas. El principio de defensa en profundidad establece que ningún control es suficiente por sí solo. Si un atacante supera una capa, la siguiente lo frena o lo limita.
Este modelo tiene una implicación práctica importante: no necesitas que todas las capas sean perfectas. Necesitas que ninguna sea inexistente. Un atacante que enfrenta 4 capas mediocres tiene más trabajo que uno que enfrenta una capa perfecta con nada detrás.
Paso a paso: Cómo implementar PROTECT desde el registro de riesgos
La regla de oro es sencilla: los controles de PROTECT deben derivarse directamente del registro de riesgos de IDENTIFY. Si un riesgo es EXTREMO, su control correspondiente es PRIORIDAD 1. No hay que inventar nada — el trabajo de IDENTIFY ya te dijo dónde actuar primero.
-
Activar MFA inmediatamente en todas las cuentas críticas (PR.AA)
Es el control con mejor relación costo-impacto en ciberseguridad. Microsoft y Google ofrecen MFA gratuito. Prioridad absoluta en cuentas de administrador, acceso a la nube y VPN. En TechCorp Latam, esto eliminó el riesgo EXTREMO de Azure AD en menos de una semana.
-
Desplegar EDR en todos los endpoints (PR.PS)
El antivirus tradicional no detecta ransomware moderno. Un EDR (Endpoint Detection & Response) como Microsoft Defender for Endpoint, CrowdStrike o SentinelOne añade detección por comportamiento. En 150 endpoints, esto mitiga directamente el riesgo EXTREMO de ransomware.
-
Establecer gestión de parches automatizada (PR.PS)
El 60% de los ataques exitosos explotan vulnerabilidades con parche disponible desde hace más de 90 días. Herramientas como Windows Update for Business, WSUS o soluciones de terceros automatizan el proceso. Establece una ventana de parcheo mensual como mínimo.
-
Cifrar datos críticos en reposo y en tránsito (PR.DS)
Para bases de datos: habilita el cifrado nativo del motor (PostgreSQL, MySQL, SQL Server todos lo soportan). Para tránsito: TLS 1.2+ en todos los servicios expuestos. Para laptops: BitLocker (Windows) o FileVault (Mac). Sin cifrado, cualquier acceso no autorizado es una filtración inmediata.
-
Verificar y automatizar los backups (PR.DS)
Un backup que nadie verifica no es un backup — es una falsa esperanza. Establece: frecuencia (diario para datos críticos), destino (regla 3-2-1: 3 copias, 2 medios, 1 offsite), y verificación periódica (prueba de restauración mensual). Sin backup verificado, un ransomware es un desastre total.
-
Segmentar la red por zonas de confianza (PR.IR)
Una red plana donde todos los dispositivos se comunican entre sí es el mejor regalo para un atacante con acceso inicial. Implementa VLANs separando al menos: servidores, laptops de usuario, dispositivos IoT/impresoras y acceso de proveedores. Esto limita el movimiento lateral post-intrusión.
-
Ejecutar capacitación anti-phishing (PR.AT)
El 90% de los incidentes comienza con un correo de phishing. Plataformas como KnowBe4, Proofpoint o incluso Microsoft Attack Simulator permiten enviar phishing simulado y medir quién cae. No es para castigar — es para entrenar. Capacitación trimestral mínima para todos los empleados.
TechCorp Latam: El plan de controles en acción
Usando directamente su registro de riesgos de IDENTIFY, TechCorp Latam diseñó un plan de 12 controles priorizados. La dirección aprobó el presupuesto en base a los dos riesgos EXTREMO — ese era el argumento que faltaba para desbloquear recursos.
🏢 TechCorp Latam — Resultados de PROTECT (semana 8)
La dirección preguntó por qué nunca se había implementado MFA antes, si es prácticamente gratuito con Microsoft 365. La respuesta fue reveladora: no era un problema de presupuesto ni de tecnología — era un problema de gobernanza. Sin GOVERN que lo exigiera y sin IDENTIFY que lo priorizara, nunca escaló como urgente. Las tres funciones se necesitan mutuamente.
Conclusión: PROTECT como inversión, no como gasto
Uno de los hallazgos más importantes del ejercicio de TechCorp Latam fue la relación costo-impacto de los primeros controles: los cuatro controles que más redujeron su riesgo costaron prácticamente cero — MFA, revisión de reglas del firewall, rotación de tokens de GitHub y configuración de backups automáticos.
La protección efectiva no siempre es cara. Es, sobre todo, sistemática y priorizada. El NIST CSF 2.0 te da el sistema. Tu registro de riesgos te da la priorización. Lo que resta es ejecutar.
TechCorp Latam tiene ahora una postura de protección activa. Pero proteger no significa ser invisible a los atacantes. Por eso el siguiente paso es igualmente crítico: DETECT — ver el ataque antes de que sea tarde.
📅 Serie: NIST CSF 2.0 en la práctica
Una publicación por día · Caso de estudio: TechCorp Latam
No hay comentarios.:
Publicar un comentario