Serie · Post 3 de 6

🛡 Función PR — PROTECT

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.

📅 Publicación 3 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · De la exposición a la protección

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:

Las 5 categorías de PROTECT y los controles principales que cada una abarca.

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.

💡

¿Qué cambió en PROTECT respecto a la v1.1?

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.

Modelo de defensa en profundidad implementado por TechCorp Latam. Cada capa añade fricción al atacante y reduce el impacto potencial.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Los 12 controles priorizados de TechCorp Latam. Nótese que los 4 completados son exactamente los que mitigan los riesgos EXTREMO y de mayor urgencia.

🏢 TechCorp Latam — Resultados de PROTECT (semana 8)

Controles implementados

4 de 12 completados · 4 en curso

Riesgos EXTREMO mitigados

2 de 2 — MFA habilitado y EDR en despliegue

Reducción de superficie de ataque

MFA activo en 100% de cuentas de Azure AD

Cobertura EDR

110 de 150 endpoints protegidos (73%)

Backups

Automatizados · Primera prueba de restauración OK

Inversión total estimada

USD 18,000 anuales (licencias + implementación)

⚠️

Lo que TechCorp Latam aprendió sobre el presupuesto

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

0

INTROEl framework que toda empresa debería conocer ✓

1

GOVERNLa base de todo programa de ciberseguridad ✓

2

IDENTIFYConoce tus activos antes de protegerlos ✓

3

PROTECTControles que reducen el impacto de un ataque ← Estás aquí

4

DETECTVer el ataque antes de que sea tarde

5

RESPONDActuar cuando el incidente ya ocurrió

6

RECOVERVolver a operar y salir más fuertes

#NISTCSF #NISTCSF20 #Protect #ZeroTrust #MFA #EDR #Ciberseguridad #CyberSecurity #DataSecurity #CISO #ControlsTI #SeguridadInformacion #GRC #ITSecurity #LatAm

Serie · Post 2 de 6

🔍 Función ID — IDENTIFY

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam.

📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero

El error más costoso en ciberseguridad: proteger sin saber qué tienes

Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria.

Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identificación de activos y evaluación de riesgos. Los controles protegen cosas, pero si no sabes qué cosas tienes ni cuáles son más críticas, estás distribuyendo tu presupuesto de seguridad a ciegas.

"El inventario de activos no es un ejercicio burocrático. Es el documento más estratégico que puede tener un equipo de seguridad."

La función IDENTIFY (ID) del NIST CSF 2.0 responde tres preguntas fundamentales: ¿qué tenemos? ¿cuál es nuestro riesgo real? ¿cómo mejoramos continuamente ese conocimiento?

¿Qué cubre la función IDENTIFY en el NIST CSF 2.0?

IDENTIFY es la función de conocimiento y comprensión. Su propósito es que la organización entienda su entorno — activos, riesgos, vulnerabilidades y amenazas — para tomar decisiones informadas sobre cómo y dónde aplicar los controles de las funciones siguientes (PROTECT, DETECT, RESPOND, RECOVER).

En la versión 2.0, IDENTIFY se estructura en 3 categorías y 21 subcategorías:

Las 3 categorías de la función IDENTIFY y los resultados que produce cada una.

Código	Categoría	Resultado esperado
ID.AM	Asset Management	Los activos de hardware, software, datos, sistemas y personas están inventariados, clasificados y tienen propietario asignado.
ID.RA	Risk Assessment	Los riesgos de ciberseguridad están identificados, analizados y priorizados según probabilidad e impacto para el negocio.
ID.IM	Improvement	Las mejoras al programa de ciberseguridad se identifican e implementan con base en evaluaciones, lecciones aprendidas y tendencias de amenazas.

💡

¿Qué pasó con las categorías de la v1.1?

En CSF v1.1, IDENTIFY tenía 6 categorías incluyendo Business Environment (BE), Governance (GV) y Risk Management Strategy (RM). En la v2.0, estas migraron a la nueva función GOVERN, dejando IDENTIFY más enfocada en lo que realmente le corresponde: conocer el entorno.

Paso 1: Cómo evaluar tu nivel actual en IDENTIFY

Antes de construir cualquier inventario, necesitas saber en qué punto estás. Las preguntas clave son directas y reveladoras:

• ¿Tienes un inventario actualizado de todos los dispositivos conectados a tu red?
• ¿Sabes qué software está instalado en cada endpoint y si tiene licencias vigentes?
• ¿Tus activos están clasificados por criticidad? ¿Hay un propietario asignado por activo?
• ¿Tienes un registro de riesgos documentado, priorizado y revisado periódicamente?
• ¿Consultas fuentes de inteligencia de amenazas para actualizar tu evaluación de riesgos?

⚠️

La trampa más común en ID.AM

Muchas organizaciones tienen un inventario desactualizado que da falsa sensación de control. Un inventario con 6 meses de antigüedad en un entorno dinámico es casi tan peligroso como no tenerlo — los activos no inventariados son exactamente los que explotan los atacantes.

Paso 2: Cómo implementar IDENTIFY desde cero

El error más frecuente es querer hacer un inventario perfecto antes de hacer ninguno. La recomendación es empezar con un alcance acotado, completar el ciclo completo y luego expandir:

1. Descubrimiento automatizado de activos de red (ID.AM)

   Antes de llenar hojas de cálculo manualmente, ejecuta un escaneo de red con herramientas como Nmap, Lansweeper o Spiceworks. Obtendrás un inventario base de todos los dispositivos activos en minutos. En entornos cloud, usa las consolas de inventario de Azure, AWS o GCP.

2. Clasificar activos por criticidad y asignar propietarios (ID.AM)

   No todos los activos valen lo mismo. Define 3 niveles: Crítico (su compromiso paraliza el negocio), Alto (impacto significativo) y Medio/Bajo. Asigna un propietario responsable por cada activo — sin propietario, ningún activo tiene quien lo gestione.

3. Mapear flujos de datos sensibles (ID.AM)

   Identifica dónde viven los datos más críticos: bases de datos de clientes, contratos, información financiera, credenciales. Documenta quién accede, desde dónde y hacia dónde fluyen. Este mapa es esencial para PROTECT y DETECT.

4. Construir el registro de riesgos (ID.RA)

   Para cada activo crítico, identifica sus amenazas principales (ransomware, acceso no autorizado, error humano, fallo de proveedor), estima probabilidad e impacto, y calcula el nivel de riesgo. Prioriza los de mayor nivel para acción inmediata.

5. Incorporar inteligencia de amenazas (ID.RA)

   No evalúes riesgos en el vacío. Suscríbete a fuentes gratuitas como CISA Alerts, CVE Database o el blog de CERT Chile. Las amenazas evolucionan — tu registro de riesgos debe evolucionar con ellas.

6. Establecer un ciclo de revisión periódica (ID.IM)

   El inventario y el registro de riesgos son documentos vivos. Define una cadencia de revisión: mensual para cambios de activos críticos, trimestral para revisión completa del registro de riesgos. Documenta lecciones aprendidas de cada incidente o casi-incidente.

TechCorp Latam: Construyendo el inventario desde cero

Con la base de gobernanza establecida en GOVERN, el equipo de TechCorp Latam ejecuta su primer ejercicio formal de identificación. El resultado fue revelador — y preocupante.

Inventario de los 10 activos más críticos de TechCorp Latam. Nótese la columna de exposición — en todos los activos críticos hay brechas activas sin remediar.

🚨

Hallazgo crítico del inventario

El 60% de los laptops corporativos accedía a sistemas cloud sin MFA. Las cuentas de administrador de Azure AD — las llaves del reino — tampoco tenían MFA habilitado. Esto no era desconocido para TI, pero nunca había sido escalado a la dirección con la criticidad adecuada. El inventario lo puso en blanco y negro.

TechCorp Latam: El registro de riesgos prioritarios

Una vez mapeados los activos, el equipo construyó su primer registro formal de riesgos. Se identificaron 8 riesgos de alta y extrema criticidad que requerían acción inmediata o planificada:

Los 8 riesgos más críticos identificados. Los de prioridad INMEDIATA serán los primeros en abordar durante la función PROTECT.

🏢 TechCorp Latam — Resultados de IDENTIFY

Activos inventariados

163 activos totales catalogados

Activos críticos identificados

10 activos de criticidad alta o crítica

Propietarios asignados

100% de activos críticos con propietario

Riesgos registrados

8 riesgos priorizados · 2 de nivel EXTREMO

Hallazgo más crítico

Azure AD sin MFA — exposición total a la nube

Herramienta de inventario

Lansweeper (red) + hoja de registro manual (datos)

✅

Lección clave de TechCorp Latam

El ejercicio de IDENTIFY tomó 3 semanas con 2 personas. El resultado más valioso no fue el documento — fue la conversación con la dirección general cuando vieron los riesgos EXTREMOS en pantalla. IDENTIFY convierte la intuición en evidencia.

Conclusión: IDENTIFY como punto de partida real

Sin un inventario actualizado y un registro de riesgos priorizado, todas las decisiones de ciberseguridad son opiniones. IDENTIFY las convierte en decisiones informadas.

TechCorp Latam terminó esta fase con algo que nunca había tenido: visibilidad real de su superficie de ataque. Los dos riesgos de nivel EXTREMO — Azure AD sin MFA y ransomware vía endpoints — serán los primeros en abordar en la próxima función.

En el siguiente post veremos cómo TechCorp Latam usa este mapa de riesgos para diseñar e implementar sus controles de protección en NIST CSF 2.0 — PROTECT.

📅 Serie: NIST CSF 2.0 en la práctica

Una publicación por día · Caso de estudio: TechCorp Latam

0

INTROEl framework que toda empresa debería conocer ✓

1

GOVERNLa base de todo programa de ciberseguridad ✓

2

IDENTIFYConoce tus activos antes de protegerlos ← Estás aquí

3

PROTECTControles que reducen el impacto de un ataque

4

DETECTVer el ataque antes de que sea tarde

5

RESPONDActuar cuando el incidente ya ocurrió

6

RECOVERVolver a operar y salir más fuertes

#NISTCSF #NISTCSF20 #Identify #AssetManagement #RiskAssessment #Ciberseguridad #CyberSecurity #GestionActivos #CISO #RiesgosTI #SeguridadInformacion #GRC #ITSecurity #LatAm

Serie · Post 1 de 6

 Función GV — GOVERN

NIST CSF 2.0 — GOVERN: La base de todo programa de ciberseguridad

La función más nueva del CSF 2.0 y la más estratégica. Sin gobernanza, todo lo demás falla. Analizamos sus 6 categorías, evaluamos a TechCorp Latam y diseñamos su plan de implementación.

📅 Publicación 1 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Desde cero

¿Por qué GOVERN es la función más importante del NIST CSF 2.0?

Cuando el NIST rediseñó el framework para su versión 2.0, tomó una decisión significativa: añadir una función completamente nueva que no existía en la v1.1. No fue una categoría adicional dentro de una función existente — fue una función entera, al mismo nivel que Identify, Protect, Detect, Respond y Recover.

Esa función es GOVERN (GV), y su creación responde a una realidad que los auditores y consultores de seguridad conocen bien: la mayoría de los programas de ciberseguridad fracasan no por falta de tecnología, sino por falta de dirección estratégica, roles claros y rendición de cuentas.

"Puedes tener el mejor firewall del mundo. Si nadie sabe quién es responsable de configurarlo, actualizarlo y reportar sus alertas — no sirve de nada."

GOVERN es la función que responde la pregunta fundamental: ¿quién gobierna la ciberseguridad en tu organización?

¿Qué es la función GOVERN y qué cubre?

La función GOVERN establece el contexto, las prioridades y la supervisión del programa de ciberseguridad. Es transversal — sus resultados condicionan cómo se ejecutan todas las demás funciones (ID, PR, DE, RS, RC). Sin una gobernanza clara, las otras cinco funciones operan en el vacío.

Se estructura en 6 categorías y 22 subcategorías. Cada categoría produce resultados específicos que la organización debe alcanzar y mantener:

Las 6 categorías de la función GOVERN y su propósito dentro del programa de ciberseguridad.

Desglose de las 6 categorías

Código	Categoría	Resultado esperado
GV.OC	Contexto Organizacional	La misión, expectativas de partes interesadas y requisitos legales son comprendidos e informan la estrategia de ciberseguridad.
GV.RM	Estrategia de Gestión de Riesgos	Las prioridades, restricciones, apetito de riesgo y tolerancias están establecidas y comunicadas.
GV.RR	Roles, Responsabilidades y Autoridades	Los roles y responsabilidades de ciberseguridad están coordinados y alineados con los roles internos y externos.
GV.PO	Política	Las políticas de ciberseguridad están establecidas, comunicadas y aplicadas.
GV.OV	Supervisión	Los resultados de las actividades de gestión de riesgos son usados para informar y ajustar la estrategia.
GV.SC	Gestión de Riesgos en la Cadena de Suministro	Los riesgos de proveedores y terceros son identificados, priorizados y gestionados.

Paso 1: Cómo evaluar tu nivel actual en GOVERN

Antes de implementar cualquier cosa, necesitas un diagnóstico honesto. El NIST CSF 2.0 no prescribe una escala de madurez oficial, pero en la práctica se utiliza una escala de 5 niveles que va desde Inexistente hasta Gestionado.

📋

Cómo usar la tabla de evaluación

Para cada categoría, responde: ¿Existe evidencia documentada de este resultado? ¿Es consistente y revisado periódicamente? La honestidad en este diagnóstico es lo que hace útil el ejercicio.

Resultado del diagnóstico inicial de TechCorp Latam en las 6 categorías de GOVERN. La mayoría en nivel Inicial o Inexistente.

El diagnóstico de TechCorp Latam revela un patrón común en empresas medianas de la región: la ciberseguridad existe como práctica técnica informal, pero no existe como función gestionada. No hay quién sea responsable formalmente, no hay política aprobada por la dirección, y no hay métricas que suban hasta el nivel ejecutivo.

⚠️

La brecha más crítica de TechCorp Latam

GV.RR — Sin un CISO ni propietario formal de ciberseguridad, cualquier incidente derivará en caos de responsabilidades. Esto es lo primero que hay que resolver, incluso de forma provisional.

Paso 2: Cómo implementar GOVERN desde cero

La buena noticia: GOVERN no requiere grandes inversiones tecnológicas. Sus resultados son principalmente organizacionales — políticas, roles, estrategia. Esto lo hace abordable incluso con recursos limitados.

El error más común es querer documentar todo antes de tener claridad. La recomendación es empezar por lo que produce impacto inmediato y construir el resto de forma iterativa:

1. Designar un responsable provisional de seguridad

   No necesitas contratar un CISO en el día 1. Asigna el rol a alguien de Infraestructura o TI con autoridad para escalar decisiones. Documenta el rol y comunícalo a la organización.

2. Definir el apetito de riesgo con la dirección (GV.RM)

   Una sesión de 2 horas con el CEO y los directores para responder: ¿qué riesgos son inaceptables? ¿Cuáles son tolerables si tienen compensaciones? Esto alinea la estrategia de seguridad con el negocio.

3. Redactar la política de ciberseguridad v1 (GV.PO)

   No necesitas 80 páginas. Una política de 5-8 páginas que cubra: propósito, alcance, roles, uso aceptable, gestión de incidentes y sanciones. Aprobada y firmada por la dirección general.

4. Identificar los requisitos legales aplicables (GV.OC)

   En Chile: Ley 19.628 de Protección de Datos, normativas de la CMF si aplica, y requisitos contractuales de clientes. Documentar qué controles exigen y cuáles ya se cumplen.

5. Establecer un comité de ciberseguridad (GV.RR / GV.OV)

   No necesita ser formal. Puede ser una reunión mensual de 45 minutos entre TI, dirección general y el área legal/compliance. Lo importante es que la seguridad suba al nivel directivo con periodicidad.

6. Evaluar proveedores críticos (GV.SC)

   Listar los 5-10 proveedores con acceso a sistemas o datos sensibles. Para cada uno: ¿tienen política de seguridad? ¿Hay cláusulas de seguridad en el contrato? ¿Pueden acceder a sistemas internos?

TechCorp Latam: El plan de implementación de GOVERN

Con el diagnóstico en mano, el equipo de TechCorp Latam diseña su hoja de ruta de 90 días para GOVERN. El enfoque no es perfección — es establecer una base funcional que permita avanzar con las otras funciones del CSF 2.0.

Hoja de ruta de 90 días de TechCorp Latam para implementar los resultados esenciales de la función GOVERN.

🏢 TechCorp Latam — Resultados al día 90

Responsable de Seguridad

Jefe de Infraestructura designado (interim CISO)

Política de Ciberseguridad

v1.0 aprobada y firmada por Dirección General

Comité de Ciberseguridad

Reunión mensual establecida con gerencias

Apetito de Riesgo

Definido y documentado en acta directorial

Requisitos Legales

Ley 19.628 y contratos críticos mapeados

Proveedores Críticos

8 proveedores evaluados, 3 con brechas identificadas

✅

Lección clave de TechCorp Latam

La dirección general no tenía conciencia del nivel de exposición real de la empresa hasta la primera sesión de apetito de riesgo. GOVERN no es solo un ejercicio de documentación — es el proceso que convierte la ciberseguridad en una decisión de negocio.

Conclusión: GOVERN como fundamento, no como trámite

La función GOVERN existe porque el NIST reconoció algo que los profesionales de seguridad saben desde hace tiempo: sin apoyo ejecutivo, sin roles claros y sin políticas aprobadas, ningún control técnico funciona de manera sostenible.

No importa si tienes el mejor SIEM, el mejor firewall o el equipo más capacitado — si nadie sabe quién es responsable cuando ocurre un incidente, si la dirección no ha aprobado el apetito de riesgo, si los proveedores críticos no tienen controles mínimos exigidos: tu programa de ciberseguridad descansa sobre arena.

TechCorp Latam terminó sus primeros 90 días con algo que no tenía antes: una base de gobernanza desde la cual construir todo lo demás. En el próximo post veremos cómo usan esa base para ejecutar la función IDENTIFY — conocer exactamente qué tienen que proteger.

📅 Serie: NIST CSF 2.0 en la práctica

Una publicación por día · Caso de estudio: TechCorp Latam

0

INTROEl framework que toda empresa debería conocer ✓

1

GOVERNLa base de todo programa de ciberseguridad ← Estás aquí

2

IDENTIFYConoce tus activos antes de protegerlos

3

PROTECTControles que reducen el impacto de un ataque

4

DETECTVer el ataque antes de que sea tarde

5

RESPONDActuar cuando el incidente ya ocurrió

6

RECOVERVolver a operar y salir más fuertes

#NISTCSF #NISTCSF20 #Govern #GRC #Ciberseguridad #CyberSecurity #GobernanzaTI #CISO #RiesgosTI #SeguridadInformacion #LiderazgoTI #GestionTI #ITSecurity #LatAm

Serie · Post 0 de 6

NIST CSF 2.0: El framework de ciberseguridad que toda empresa debería conocer

Una guía práctica con caso de estudio real para implementar el Cybersecurity Framework en tu organización, función por función.

📅 Publicación 0 — Introducción ⏱ Lectura: ~8 min 🏢 Caso de estudio: TechCorp Latam

¿Tiene tu empresa un programa de ciberseguridad… o solo tiene antivirus?

Si esa pregunta genera incomodidad, no estás solo. La mayoría de las organizaciones medianas en América Latina operan con medidas reactivas y dispersas: un antivirus aquí, un firewall básico allá, backups que nadie verifica. Sin una visión integral del riesgo cibernético.

El problema no es la falta de herramientas. Es la falta de un marco de referencia que conecte estrategia, personas, procesos y tecnología de forma coherente.

"La ciberseguridad no es un problema de tecnología — es un problema de gestión. Y todo problema de gestión necesita un framework."

Para eso existe el NIST Cybersecurity Framework 2.0. Esta es la primera entrega de una serie de 7 publicaciones donde vamos a aplicarlo completamente, función por función, a través de un caso de estudio concreto: TechCorp Latam.

📌

¿Cómo seguir esta serie?

Cada publicación funciona de forma independiente, pero el mayor valor lo obtendrás siguiéndola en orden. Activa las notificaciones del blog para no perderte ninguna entrega.

¿Qué es el NIST Cybersecurity Framework?

El NIST Cybersecurity Framework (CSF) es una guía desarrollada por el National Institute of Standards and Technology del gobierno de los Estados Unidos. Fue creada en 2014 para proteger infraestructuras críticas, pero su claridad y flexibilidad la convirtieron en el estándar de referencia global para organizaciones de cualquier sector y tamaño.

No es una norma de cumplimiento obligatorio. Es un framework voluntario que proporciona un lenguaje común y una estructura lógica para gestionar el riesgo de ciberseguridad de forma continua y adaptable.

Línea de tiempo visual: 2014 (v1.0) → 2018 (v1.1) → Febrero 2024 (v2.0)

NIST CSF 2.0: ¿Qué cambió respecto a la versión 1.1?

En febrero de 2024 el NIST publicó la versión 2.0, la actualización más significativa desde la creación del framework. Estos son los cambios principales:

Versión 1.1 — Antes

• 5 funciones (sin Govern)
• Enfocado en infraestructura crítica
• Gestión de cadena de suministro básica
• Sin Perfiles de Implementación formales
• Integración limitada con otros frameworks

Versión 2.0 — Ahora

• 6 funciones — nueva: GOVERN
• Para cualquier organización, cualquier tamaño
• C-SCRM reforzado significativamente
• Perfiles Current / Target implementados
• Alineación con ISO 27001, COBIT, CIS Controls

1. Nueva función: GOVERN

La adición más importante. La v2.0 introduce GOVERN (GV) como función transversal que establece el contexto organizacional, roles, responsabilidades y la estrategia de gestión de riesgos. Es la columna vertebral de todo el programa.

2. Alcance universal

La v1.1 estaba orientada a operadores de infraestructura crítica. La v2.0 es explícitamente para cualquier organización, sin importar tamaño ni sector — mucho más accesible para PyMEs y startups tecnológicas.

3. Gestión de riesgos en la cadena de suministro

Con ataques como el de SolarWinds como precedente, la v2.0 refuerza las categorías de Cybersecurity Supply Chain Risk Management (C-SCRM): tu postura de seguridad depende también de tus proveedores.

4. Perfiles de implementación

Se introducen los Organizational Profiles para documentar el estado actual (Current Profile) versus el estado deseado (Target Profile), facilitando la planificación y la comunicación con la dirección.

Las 6 funciones del NIST CSF 2.0

El corazón del framework son sus 6 funciones, que representan los pilares de un programa maduro. No son pasos secuenciales — son capacidades que operan de forma simultánea y continua.

NIST Cybersecurity Framework Version 2.0

GV

Govern

Define la estrategia, roles, políticas y cultura de ciberseguridad de la organización.

Nueva en v2.0

ID

Identify

Inventario de activos, evaluación de riesgos y comprensión del entorno organizacional.

PR

Protect

Controles y salvaguardas para limitar o contener el impacto de un incidente.

DE

Detect

Identifica la ocurrencia de eventos de ciberseguridad de forma oportuna.

RS

Respond

Acciones de contención y gestión ante un incidente de ciberseguridad detectado.

RC

Recover

Restaura capacidades afectadas y mejora la postura de seguridad post-incidente.

Estructura interna: categorías y subcategorías

Cada función se divide en categorías y subcategorías que describen resultados específicos a alcanzar. En total, la v2.0 contiene 106 subcategorías de resultados:

Función	Código	Categorías	Subcategorías
Govern	GV	6	22
Identify	ID	5	21
Protect	PR	5	21
Detect	DE	2	7
Respond	RS	4	17
Recover	RC	2	6

El caso de estudio: TechCorp Latam

A lo largo de esta serie utilizaremos a TechCorp Latam como hilo conductor — una empresa ficticia que representa a miles de organizaciones reales en la región.

🏢 TechCorp Latam — Perfil inicial

Sector

TI y Servicios en la Nube

Tamaño

150 empleados, 3 oficinas en LatAm

Madurez en ciberseguridad

Inicial — sin políticas formales ni CISO

Infraestructura actual

Antivirus, firewall básico, backups esporádicos

Motivación para adoptar CSF

Requisito contractual de cliente corporativo

Plan de respuesta a incidentes

Ninguno — reacción completamente ad-hoc

¿Te suena esta historia? Para muchas empresas medianas, un requisito contractual o una auditoría inesperada es el primer empujón real hacia la madurez en seguridad.

⚠️

Spoiler de la serie

En los posts 5 y 6 (RESPOND y RECOVER), TechCorp Latam enfrentará un incidente de ransomware. El nivel de preparación que construyan función por función determinará qué tan rápido pueden recuperarse — y cuánto les cuesta no haberlo hecho antes.

Organigrama simplificado de TechCorp Latam

Conclusión: ¿Por qué importa esto para tu organización?

El NIST CSF 2.0 no es un documento burocrático para grandes corporaciones. Es una hoja de ruta práctica que cualquier organización puede adoptar para pasar de una postura reactiva a una proactiva frente al riesgo cibernético.

No requiere que implementes las 106 subcategorías de golpe. El framework está diseñado para que priorices según tu contexto, tu riesgo y tu capacidad. TechCorp Latam lo hará exactamente así — y verás exactamente qué decisiones toma, por qué las toma y qué resultado obtienen.

✅

Puntos clave de esta publicación

El NIST CSF 2.0 es aplicable a cualquier organización · La v2.0 agrega GOVERN como función central · TechCorp Latam parte desde cero · La serie cubre evaluación + implementación de cada función.

📅 Próximas entregas de la serie

Una publicación por día. Cada una cubre evaluación, implementación y caso de estudio de la función correspondiente.

1

GOVERNLa base de todo programa de ciberseguridad

2

IDENTIFYConoce tus activos antes de protegerlos

3

PROTECTControles que reducen el impacto de un ataque

4

DETECTVer el ataque antes de que sea tarde

5

RESPONDActuar cuando el incidente ya ocurrió

6

RECOVERVolver a operar y salir más fuertes

#NISTCSF #NISTCSF20 #Ciberseguridad #CyberSecurity #GRC #Gobernanza #SeguridadInformacion #CISO #RiesgosTI #Frameworks #ITSecurity #TransformacionDigital #SeguridadTI #LatAm

Ciberseguridad · Gestión de Riesgos

Cuando el Mayor Riesgo
Viene de Adentro:
Qué es UEBA y por qué
su empresa lo necesita

Lectura estimada: 7 minutos  ·  Por Luis Bolivar

Durante años, las organizaciones han invertido millones en protegerse de amenazas externas: firewalls, antivirus, sistemas de detección de intrusos. Sin embargo, existe una categoría de riesgo que suele pasar inadvertida en las salas de directorio — y que estadísticamente representa uno de los mayores costos en incidentes de seguridad: la amenaza interna.

Una historia que se repite en muchas organizaciones

Imagine esta situación: un empleado con acceso legítimo a los sistemas críticos de su empresa comienza a descargar grandes volúmenes de información confidencial. No hay una intrusión desde afuera. No se activa ningún antivirus. Todo ocurre dentro de los canales autorizados. Desde la perspectiva de los sistemas tradicionales de seguridad, todo parece completamente normal.

📋 Caso de uso real

En una empresa de servicios financieros, un analista senior con credenciales de acceso a bases de datos de clientes comenzó a exportar registros de manera sistemática durante varias semanas. Lo hacía fuera del horario laboral habitual, desde una dirección IP distinta a la que usaba normalmente, y accediendo a archivos que nunca había consultado en sus dos años de trabajo.

Los sistemas tradicionales no levantaron ninguna alerta. No hubo contraseñas robadas ni malware. El empleado simplemente estaba usando su propio acceso.

Lo que finalmente lo detectó fue una plataforma de User and Entity Behaviour Analytics (UEBA), que identificó una desviación significativa respecto a su patrón histórico de comportamiento y disparó una alerta al equipo de seguridad. La empresa pudo actuar antes de que la información fuera utilizada con fines fraudulentos.

Esta historia no es un caso aislado. Según el Verizon Data Breach Investigations Report, las amenazas internas — ya sean maliciosas o accidentales — son responsables de una proporción significativa de las brechas de datos más costosas registradas a nivel global.

¿Qué es exactamente UEBA?

UEBA, por sus siglas en inglés User and Entity Behaviour Analytics, es una tecnología de ciberseguridad que utiliza inteligencia artificial y aprendizaje automático para establecer líneas base de comportamiento — es decir, aprende cómo actúan normalmente los usuarios, dispositivos y sistemas dentro de una organización — y detecta cuando algo se desvía de ese patrón habitual.

A diferencia de las herramientas de seguridad tradicionales, que buscan amenazas conocidas (firmas de malware, vulnerabilidades catalogadas), UEBA trabaja con comportamiento anómalo. Esto le permite identificar actividades sospechosas incluso cuando no existe una amenaza conocida de por medio.

"UEBA no busca lo malo que ya conocemos. Detecta lo que no debería estar ocurriendo, aunque nadie lo haya visto antes."

En términos prácticos, UEBA responde preguntas como:

¿Por qué este usuario está accediendo a carpetas que nunca antes abrió? ¿Por qué está descargando cinco veces más datos que en cualquier otro día del último año? ¿Por qué inició sesión desde un país diferente al mismo tiempo que lo hizo desde la oficina?

Estas señales, por separado, pueden parecer menores. Correlacionadas e interpretadas en contexto, revelan patrones de riesgo con alta precisión.

¿Por qué importa esto a nivel gerencial?

La seguridad cibernética suele presentarse ante la alta dirección como un gasto inevitable, difícil de justificar sin un incidente previo. UEBA cambia esa conversación porque su valor es directamente medible en términos de negocio.

🔍

Visibilidad total del entorno

Saber exactamente qué ocurre dentro de la organización, no solo en el perímetro externo. Visibilidad es control.

⏱️

Reducción del tiempo de detección

El costo de un incidente es directamente proporcional al tiempo que pasa desapercibido. UEBA reduce ese tiempo de semanas a horas.

💼

Protección de activos críticos

Propiedad intelectual, datos de clientes, información financiera — los activos más valiosos son los más apetecidos internamente.

📊

Decisiones informadas

Reemplaza la seguridad reactiva por una postura proactiva basada en datos reales del comportamiento organizacional.

Más allá de la tecnología, UEBA le permite a la dirección responder con certeza a preguntas que hoy quedan en el aire: ¿Sabemos si hay empleados con acceso a información que no deberían tener? ¿Podríamos detectar un caso de fraude interno antes de que cause un daño significativo? ¿Cumplimos con los estándares regulatorios en materia de control de accesos?

¿Cómo se implementa UEBA en una organización?

Una de las barreras más comunes para adoptar UEBA es la percepción de que se trata de un proyecto técnico complejo, reservado para grandes corporaciones con equipos de seguridad robustos. La realidad es diferente. Implementar UEBA sigue un proceso estructurado que puede adaptarse al tamaño y madurez de cualquier organización.

Diagnóstico y levantamiento de fuentes de datos

El primer paso es identificar qué fuentes de datos existen en la organización: logs de Active Directory, registros de acceso a aplicaciones, tráfico de red, actividad en endpoints. UEBA necesita datos para aprender; el diagnóstico inicial define con qué insumos se trabajará.

Definición de perfiles de comportamiento y roles

Se establecen grupos de usuarios según su función y nivel de acceso. El sistema aprende qué es "normal" para un gerente de finanzas versus un desarrollador de software. Cuanto más específico sea el perfilamiento, más precisas serán las alertas.

Período de aprendizaje y calibración

La plataforma requiere un período inicial — generalmente entre 30 y 90 días — para establecer las líneas base de comportamiento. Durante esta fase no se generan alertas operativas; el sistema simplemente observa y aprende.

Operación y respuesta a alertas

Una vez calibrado, el sistema empieza a generar alertas priorizadas por nivel de riesgo. El equipo de seguridad (o el CISO) recibe notificaciones accionables con contexto suficiente para investigar y decidir. No se necesita analizar millones de logs: UEBA hace ese trabajo.

Mejora continua y gobierno

Con el tiempo, el sistema se vuelve más preciso. Se ajustan umbrales, se refinan perfiles y se integran nuevas fuentes de datos. UEBA es una capacidad que madura con la organización, no una solución de instalación única.

Es importante destacar que UEBA no reemplaza a las personas: potencia su capacidad de respuesta. Un equipo de seguridad pequeño, equipado con UEBA, puede tener la misma visibilidad que un equipo mucho más grande operando de forma manual.

La pregunta que toda organización debería hacerse hoy

La adopción de UEBA no es una decisión exclusivamente técnica. Es una decisión estratégica sobre el nivel de visibilidad y control que una organización quiere tener sobre sus propios activos e información.

Las amenazas externas acaparan los titulares. Pero los incidentes internos — ya sean causados por empleados descontentos, cuentas comprometidas o simplemente errores humanos — son estadísticamente más frecuentes y, en muchos casos, más costosos, precisamente porque son más difíciles de detectar con herramientas convencionales.

La pregunta no es si su organización necesita visibilidad sobre el comportamiento interno. La pregunta es cuánto le cuesta no tenerla — en términos de datos expuestos, reputación dañada, multas regulatorias o propiedad intelectual perdida.

¿Está este tema en la agenda de su directorio?

Si esta publicación generó preguntas sobre el nivel de exposición de su organización, estoy disponible para conversar sobre cómo UEBA puede integrarse a su estrategia de seguridad. Deje su comentario o contácteme directamente.

Ciberseguridad UEBA Riesgo Interno Estrategia Empresarial Gobierno Corporativo Transformación Digital CISO Seguridad Empresarial

La Gran Brecha Organizacional: Por qué la Seguridad Física y la Lógica no son lo mismo (y por qué tu Gerencia debe saberlo)

 

Introducción

Para la alta dirección, la palabra "Seguridad" suele ser un paraguas único. Sin embargo, en el mundo de la infraestructura tecnológica, esta simplificación es peligrosa. Confundir el control de acceso a un edificio con el control de acceso a una base de datos es el primer paso hacia un incidente crítico de escala mayor.

1. El Conflicto de las "Dos Seguridades"

La Seguridad Física se centra en lo tangible (rondas, CCTV, perímetros). La Seguridad Lógica (TI) se centra en la triada de la información: Confidencialidad, Integridad y Disponibilidad.

El problema surge cuando la gerencia subordina una a la otra. Si TI depende de Seguridad Patrimonial, las decisiones técnicas se toman bajo una óptica analógica. Si es al revés, el equipo de infraestructura termina gestionando turnos de guardias, alejándose de su core técnico.

2. Caso de Estudio: "El técnico que no existía" (Realidad en Chile)

Analicemos un escenario común en empresas nacionales con protocolos no integrados:

• El Ingreso: Un atacante llega a portería con uniforme de telecomunicaciones y una orden de trabajo falsa.

• El Registro: El guardia le solicita su RUT para anotarlo en el libro de visitas. Cumple la norma: verifica identidad pero no retiene el documento (facultad exclusiva de policías). El atacante ingresa.

• El Vacío de Poder: La gerencia delegó las llaves del Data Center a Seguridad para "agilizar procesos". El guardia le abre la sala de servidores al supuesto técnico y se retira.

• La Brecha: El atacante conecta un dispositivo de acceso remoto en un puerto de red libre de un switch sin protección de puerto.

• El Resultado: Por la noche, exfiltra datos críticos saltándose el firewall perimetral, ya que la conexión nace desde el "interior confiable".

3. Recomendaciones Técnicas: Blindando la convergencia

Para que la seguridad no dependa del criterio del guardia, debemos implementar capas tecnológicas que hablen el mismo idioma:

• NAC y Segmentación (802.1X):

  • Fortinet: Implementar FortiNAC o políticas de FortiSwitch para que ningún dispositivo acceda a la red sin estar certificado.

  • Cisco / Meraki: Uso de Cisco ISE o Group Policies en Meraki para aislar dispositivos desconocidos automáticamente.

  • pfSense: Crear reglas de firewall estrictas y segmentación de VLANs para que la red de "Invitados" o "CCTV" jamás vea la red de producción.

• Infraestructura de Vigilancia: * Ubiquiti (UniFi): Activar Port Isolation en switches y bloquear puertos por dirección MAC para evitar que alguien desconecte una cámara y conecte un laptop.

• Monitoreo Proactivo con Zabbix:

  • No esperes a que alguien te avise. Configura SNMP Traps en Zabbix para recibir alertas inmediatas si un puerto crítico del Data Center se activa (Link Up) fuera de horario.

  • Dashboards unificados que muestren desde la temperatura del rack hasta picos de tráfico inusuales.

Conclusión

La seguridad exitosa no nace de mezclar departamentos, sino de coordinar especialistas. En un Chile digitalizado, el "candado en la puerta" es solo el inicio. Si tu empresa cree que el jefe de guardias puede supervisar la ciberseguridad, es hora de actualizar el organigrama antes de que la realidad lo haga por ustedes.