La implementación de Zero Trust no es un proyecto de seguridad tradicional. Es una transformación organizacional que requiere cambios en arquitectura, procesos, personas y cultura. Para empresas chilenas, esta transición es especialmente relevante dado el nuevo marco regulatorio nacional: la Ley Marco de Ciberseguridad (Ley 21.663) y la Ley de Protección de Datos Personales (Ley 21.719).
Este documento proporciona una hoja de ruta práctica y secuencial, desde los primeros pasos hasta una postura operacional completa, considerando la realidad de las organizaciones chilenas: múltiples legados tecnológicos, fuerza laboral distribuida, y requisitos regulatorios en evolución constante.
1. El Contexto Regulatorio Chileno
1.1 Ley Marco de Ciberseguridad (Ley 21.663)
La Ley Marco de Ciberseguridad entró en vigencia plena en marzo 2025 y establece obligaciones para dos categorías de entidades:
Prestadores de Servicios Esenciales (PSE):
- Generación, transmisión o distribución de electricidad
- Transporte (terrestre, aéreo, ferroviario, marítimo)
- Telecomunicaciones y servicios de infraestructura digital
- Abastecimiento de agua y servicios sanitarios
- Servicios financieros y de pagos
- Salud (hospitales, clínicas)
- Investigación y producción de fármacos
Operadores de Vital Importancia (OVI):
- Subconjunto de PSE designado por la Agencia Nacional de Ciberseguridad (ANCI)
- Aproximadamente 1,700 empresas en la lista preliminar consultada en septiembre 2025
- Obligaciones más estrictas y multas significativamente mayores
Requisitos Clave:
- Reportar incidentes de ciberseguridad en 24-72 horas a la ANCI
- Designar oficial de seguridad de información
- Implementar medidas técnicas y organizacionales de seguridad
- Cumplimiento con estándares internacionales (NIST, ISO 27001)
- Multas: hasta $345,000 USD para PSE; hasta $690,000 USD para OVI
1.2 Ley de Protección de Datos Personales (Ley 21.719)
Aprobada en agosto 2024, alinea a Chile con estándares internacionales (GDPR, LGPD, LPDP):
Principios Fundamentales:
- Lawfulness & Fairness (legalidad y equidad)
- Purpose Limitation (limitación de propósito)
- Data Minimization (minimización de datos)
- Accuracy (exactitud)
- Storage Limitation (limitación de almacenamiento)
- Accountability (responsabilidad)
- Transparency (transparencia)
Datos Sensibles Requieren:
- Consentimiento explícito del titular
- Cifrado y protección especial
- Acceso controlado y auditoría
- Notificación en 30 días si hay brecha
Data Protection Impact Assessments (DPIA):
- Obligatoria para procesamiento de alto riesgo
- Tratamiento de datos sensibles
- Vigilancia sistemática
- Procesamiento a gran escala
1.3 Implicaciones Estratégicas para Zero Trust
Estas leyes transforman Zero Trust de una iniciativa de seguridad a una obligación regulatoria. Las organizaciones chilenas deben:
- Verificar continuamente identidades y dispositivos (requisito de Ley 21.663)
- Mantener trazabilidad completa de acceso a datos personales (requisito de Ley 21.719)
- Implementar segmentación de red para aislar datos sensibles
- Establecer respuesta a incidentes dentro de timelines regulatorios
2. Evaluación Inicial y Diagnóstico
2.1 Identificar Posición Actual
Pregunta Crítica: ¿Dónde está hoy su organización en el continuo de Zero Trust?
| Nivel | Característica | Madurez ZT |
|---|---|---|
| Perimetral | Todo dentro del firewall es confiable | 0% |
| Básico IAM | Autenticación centralizada (AD/Azure) | 20% |
| MFA Parcial | MFA en algunos servicios críticos | 35% |
| Segmentación Red | Redes separadas por función | 50% |
| Micro-segmentación | Segmentación a nivel de aplicación | 65% |
| Monitoreo Continuo | SIEM y EDR activos | 75% |
| Zero Trust Pleno | Todos los pilares implementados | 100% |
Ejercicio Práctico (Semana 1):
- Seleccione 10-15 personas clave (CISO, CTO, arquitectos de red, operaciones)
- Responda colectivamente estas preguntas:
- ¿Podemos verificar la identidad de cada usuario remoto?
- ¿Sabemos dónde están todos nuestros datos sensibles?
- ¿Monitoreamos el acceso a datos en tiempo real?
- ¿Podemos bloquear un usuario comprometido en menos de 1 hora?
- ¿Ejecutamos MFA obligatoria para acceso remoto?
- Asigne una puntuación 0-10 a cada pregunta
- Identifique los mayores gaps
2.2 Inventario de Activos Críticos
Sin un inventario preciso, Zero Trust es imposible. Esto no es una lista estática, es un sistema vivo que alimenta decisiones de acceso.
Áreas a Mapear:
Identidades:
- Usuarios activos en AD/Azure
- Cuentas de servicio y bots
- Acceso externo (partners, contratistas, consultores)
- Identidades de máquina (IoT, impresoras, escáneres)
Datos:
- Repositorios con datos sensibles (BBDD, SharePoint, S3)
- Clasificación: público, interno, confidencial, secreto
- Propietario de datos (dueño de negocio responsable)
- Regulaciones aplicables (PDPA, ANCI, PCI-DSS)
Aplicaciones:
- Aplicaciones críticas para operaciones (ERP, CRM)
- SaaS (Microsoft 365, Salesforce, etc.)
- On-premise heredadas
- APIs expuestas
Infraestructura:
- Servidores on-premise
- VMs en la nube (AWS, Azure, GCP)
- Contenedores y Kubernetes
- Dispositivos (laptops, móviles, IoT)
Herramientas Recomendadas para Inventario:
Para empresas pequeñas/medianas:
- Microsoft Defender for Cloud (si usa Azure/Microsoft 365)
- AWS Security Hub (si usa AWS)
- GCP Security Command Center (si usa GCP)
- Qualysec o Wiz para descubrimiento multi-nube
3. Estrategia Faseada: Roadmap de 18 Meses
La implementación de Zero Trust completo típicamente toma 18-24 meses. Dividimos en 4 fases secuenciales.
FASE 1: Fundación (0-3 meses)
Objetivo: Establecer base técnica y organizacional
Hitos:
Semanas 1-2:
- Forma “Task Force Zero Trust” (CISO, CTO, arquitectos, operaciones, compliance)
- Define sponsor ejecutivo (típicamente CTO o Chief Security Officer)
- Establece cadencia de reuniones (semanal durante esta fase)
- Comunica visión a toda la organización
Semanas 3-4:
- Completa inventario de activos críticos
- Documenta flujos de datos actuales (mapping de transacciones)
- Identifica 3-5 casos de uso piloto de alto valor
- Realiza evaluación de cumplimiento (PDPA, Ley 21.663)
Semanas 5-12:
- Implementa MFA para cuentas administrativas (meta: 100%)
- Habilita logging centralizado (CloudTrail, Azure Activity Log, etc.)
- Establece Identity Provider como fuente única de verdad
- Documenta políticas de acceso por rol
- Crea plan de respuesta ante incidentes
Entregables de Fase 1:
- Documento de visión Zero Trust alineado con requisitos regulatorios
- Inventario de activos (versión 1.0)
- Matriz de flujos de datos
- Matriz RACI de roles y responsabilidades
- Política de MFA obligatoria
- Plan de comunicaciones
FASE 2: Identidad y Acceso (3-6 meses)
Objetivo: Fortalecer control de identidades y establecer acceso granular
Semanas 13-16:
- Implementa Single Sign-On (SSO) centralizado
- Habilita MFA para todos los usuarios (no solo admins)
- Crea roles basados en funciones (RBAC)
- Implementa Privileged Access Management (PAM) para cuentas administrativas
Semanas 17-24:
- Configura Conditional Access (riesgos contextuales)
- Implementa Just-In-Time (JIT) para acceso privilegiado
- Establece auditoría completa de cambios de acceso
- Crea flujos de aprobación para acceso privilegiado
- Entrena a equipo de operaciones en PAM
Políticas Críticas a Establecer:
Política de MFA:
Obligatoria para:
- Todas las cuentas administrativas (100%)
- Acceso remoto (100%)
- Acceso a datos sensibles según clasificación
- Acceso fuera de horario laboral
- Acceso desde ubicaciones geográficas anómalas
Métodos aceptables (en orden de preferencia):
1. Autenticador físico (Yubikey, hardware token)
2. Autenticador móvil (Microsoft Authenticator, Google Authenticator)
3. SMS (último recurso, solo si no hay alternativa)
Política de Acceso Privilegiado:
Principio: Zero Standing Privileges (ZSP)
- Todas las solicitudes de acceso privilegiado requieren Just-In-Time (JIT)
- Máximo 4 horas de acceso continuo
- Require aprobación de supervisor
- Todas las sesiones grabadas y auditadas
- Acceso revocado automáticamente después del tiempo asignado
Entregables de Fase 2:
- Infraestructura de SSO operacional
- Matriz RBAC completa (versión 1.0)
- Sistema PAM implementado
- Políticas de Conditional Access definidas
- 95% de usuarios con MFA activo
FASE 3: Red y Segmentación (6-12 meses)
Objetivo: Implementar micro-segmentación y detección continua
Semanas 25-32:
- Mapea topología actual de red
- Identifica flujos de tráfico permitido vs. bloqueado
- Implementa micro-segmentación en casos de uso piloto
- Configura Network Segmentation Engine (NSE) o similar
Semanas 33-48:
- Expande micro-segmentación a todas las aplicaciones críticas
- Habilita Zero Trust Network Access (ZTNA) para acceso remoto
- Implementa SIEM/XDR centralizado
- Configura respuesta automática a amenazas
Ejemplo: Micro-segmentación en AWS VPC
Arquitectura Actual (sin segmentación):
VPC: 10.0.0.0/16
├─ Subnet Pública: 10.0.1.0/24 (Web servers)
├─ Subnet Privada: 10.0.2.0/24 (App servers)
└─ Subnet Privada: 10.0.3.0/24 (Database)
PROBLEMA: Cualquier servidor comprometido puede acceder a cualquier otro servidor
Arquitectura Zero Trust (con segmentación):
VPC: 10.0.0.0/16
├─ Subnet Web Pública: 10.0.1.0/24
│ ├ Security Group: ALLOW 443 inbound from 0.0.0.0/0
│ ├ Network ACL: ALLOW 443 inbound, DENY todo lo demás
│ └ Restricción a salida: Solo a app servers (10.0.2.0/24:8080)
│
├─ Subnet App Privada: 10.0.2.0/24
│ ├ Security Group: ALLOW 8080 from web servers only
│ ├ Network ACL: ALLOW 8080 from 10.0.1.0/24, DENY todo lo demás
│ └ Restricción a salida: Solo a DB servers (10.0.3.0/24:5432)
│
├─ Subnet DB Privada: 10.0.3.0/24
│ ├ Security Group: ALLOW 5432 from app servers only
│ ├ Network ACL: ALLOW 5432 from 10.0.2.0/24, DENY todo lo demás
│ └ NAT Gateway para salida a actualizaciones
BENEFICIO: Si web server comprometido, atacante está limitado a puerto 8080 hacia app server
Políticas de Segmentación a Crear:
| Zona | Residentes | Flujo Permitido | Aplicación | Monitoreo |
|---|---|---|---|---|
| DMZ Pública | Web servers | HTTP/HTTPS in; App servers out | Nginx, Apache | EDR + WAF |
| App Private | Application servers | App zone in; DB out; Algunos servicios | Java, .NET | EDR + NetFlow |
| DB Private | Databases | App servers only; Backups | PostgreSQL, MySQL | EDR + Query logging |
| Datos Sensibles | Filesystems, DBs | Acceso auditado 100% | Shared drives, DBs | DLP + Auditoría |
Entregables de Fase 3:
- Topología de red documentada
- Reglas de segmentación implementadas
- SIEM/XDR operacional
- Baseline de comportamiento normal establecida
FASE 4: Operaciones Continuas (12-18 meses)
Objetivo: Madurar a modelo operacional sostenible
Semanas 49-72:
- Establece cadencia de revisión de políticas (trimestral)
- Implementa automated remediation
- Crea dashboard de Zero Trust metrics
- Realiza ejercicios de tabletop trimestrales
- Documenta playbooks de respuesta
Métricas Clave a Monitorear:
Identidad & Acceso:
- Porcentaje de usuarios con MFA activo (meta: 100% para acceso remoto)
- Tiempo promedio para provisionar/desproveer acceso (meta: < 2 horas)
- Intentos fallidos de acceso por usuario (anomalía: 5x más que normal)
- Acceso privilegiado utilizando JIT (meta: 100% de sesiones admin)
Red & Segmentación:
- Tráfico bloqueado por micro-segmentación (meta: < 1% de tráfico legítimo)
- MTTR de brechas detectadas (meta: < 1 hora)
- Cobertura de monitoreo (meta: 100% de tráfico crítico)
Datos:
- Datos sensibles descubiertos y clasificados (meta: 100%)
- Intentos de acceso a datos sensibles auditados (meta: 100%)
- Incidentes de DLP por mes (meta: < 2)
Cumplimiento:
- Reportes de auditoría completados en plazo (meta: 100%)
- Hallazgos de evaluación de cumplimiento remediados (meta: 95%)
- Incidentes reportados a ANCI en plazo (meta: 100% dentro de 72 horas)
4. Implementación Detallada: Los 7 Pilares de Zero Trust
4.1 PILAR 1: Identidades
Objetivo: Verificar continuamente quién accede, nunca asumir confianza
Paso 1: Centralizar Identidades (Mes 1)
Si usa Microsoft:
Implementar: Azure AD (ahora Microsoft Entra ID)
Pasos:
1. Crear tenant en Azure AD
2. Sincronizar usuarios desde AD on-premise (Azure AD Connect)
3. Habilitar MFA (Microsoft Authenticator preferida)
4. Configurar Conditional Access policies
5. Auditar cambios en Cloud Audit Logs
Si usa AWS:
Implementar: AWS IAM + AWS Single Sign-On
Pasos:
1. Centralizar identidades en AWS SSO o AWS IAM Identity Center
2. Conectar con AD corporativo (AD Connector)
3. Definir AWS SSO groups basados en LDAP
4. Habilitar MFA virtual o hardware
5. Configurar session recording para acceso privilegiado
Si usa Google:
Implementar: Google Workspace + Cloud Identity
Pasos:
1. Provisionar Google Workspace
2. Sincronizar directorios corporativos
3. Habilitar Advanced Security (2FA, passwordless)
4. Configurar Conditional Access
5. Habilitar Cloud Audit Logs
Paso 2: Implementar MFA en Fases (Mes 1-3)
Fase 1 (Mes 1): Administratores
- Objetivo: 100% MFA para todas las cuentas admin
- Método recomendado: Yubikey (phishing-resistant) o Microsoft Authenticator
- Timeline: 2 semanas
- Rollback plan: Si MFA falla, usar token físico backup
Fase 2 (Mes 2): Acceso Remoto
- Objetivo: 100% MFA para VPN/RDP
- Timeline: 2 semanas
- Plan de comunicación: Enviar instrucciones 1 semana antes
Fase 3 (Mes 2-3): Todos los usuarios
- Objetivo: 95%+ adopción
- Excepciones: Máquinas de fabricación, legados específicos
- Support: Crear help desk con expertos MFA
Paso 3: Definir Roles y Permisos (Mes 1-2)
Ejercicio RACI por Rol:
Para cada rol (VP Finanzas, DBA, Developer, etc.), definir:
| Recurso | VP Finanzas | DBA | Developer | Support |
|---|---|---|---|---|
| SAP | Read/Approve | Read | None | Read |
| AD | Read | Read | None | Read |
| Backups | Approve restore | Execute | None | Monitor |
| Logs | Read | Read | Write | Read |
| Data warehouse | Read | Full | Query | None |
Mapear a roles técnicos:
Rol: Finance_Report_Reader
├─ Permisos: Read data warehouse
├─ Duración: Permanente
├─ MFA requerida: Sí
├─ Auditoría: Log cada acceso
└─ Aprobación: VP Finanzas + CISO
Rol: DBA_Production_Full
├─ Permisos: Full access a DB production
├─ Duración: Session-based (max 4 horas)
├─ MFA requerida: Sí (+ biometric si disponible)
├─ Auditoría: Grabar todas las sesiones
├─ Aprobación: CTO + VP Operaciones
└─ Just-In-Time: Solicitar acceso cuando se necesite
4.2 PILAR 2: Dispositivos
Objetivo: Solo dispositivos sanos y compatibles pueden acceder
Paso 1: Inventariar Dispositivos (Mes 2)
Ejecutar escaneo de descubrimiento:
En Azure:
1. Ir a Azure Intune > Devices
2. Ejecutar device discovery
3. Aplicar compliance policies
4. Identificar non-compliant devices
5. Remediación: Notificar usuarios, forzar actualizaciones
En AWS:
1. Usar AWS Systems Manager Fleet Manager
2. Identificar todas las instancias EC2, dispositivos de usuario
3. Aplicar patches
4. Validar antivirus/EDR activo
Paso 2: Enforcement Rules (Mes 2-3)
Tabla de Cumplimiento de Dispositivos:
| Control | Requerido para | Acción si No Cumple |
|---|---|---|
| OS Patch Level | Acceso a datos sensibles | Denegar acceso + Notificación |
| Disk Encryption (BitLocker/FileVault) | Todo acceso corporativo | Acceso limitado a no-sensible |
| Antivirus/EDR activo | Acceso a red corporativa | Aislamiento de red |
| Firewall local activo | Acceso a cualquier recurso | Denegar acceso |
| Password manager | Acceso a múltiples sistemas | Advertencia pero permitir |
| Screen lock enabled | Acceso remoto | Denegar acceso |
Paso 3: Acceso por Postura de Dispositivo (Mes 3)
Ejemplo de Conditional Access Rule:
SI (Usuario = "Finance_Department") AND
(Dispositivo = "No cumple antivirus") AND
(Recurso = "SharePoint Financial Data")
ENTONCES:
Acción = Bloquear acceso
Notificación = "Por favor instale antivirus y reinicie"
Bypass = Solo CISO + CTO
TTL = 1 hora (luego re-verificar)
4.3 PILAR 3: Red
Objetivo: Segmentar tráfico, asumir que cualquier paquete podría ser malicioso
Paso 1: Mapeo Actual (Mes 3)
Capturar flujos de tráfico actual:
Herramientas:
- AWS: VPC Flow Logs
- Azure: Network Watcher
- GCP: VPC Flow Logs
- On-premise: NetFlow, sFlow
Salida esperada:
Fuente: 10.0.1.0/24 (Web servers)
Destino: 10.0.2.0/24 (App servers)
Protocolo: TCP
Puerto: 8080
Volumen: 150 Mbps
Horarios: 07:00 - 18:00 CL
Criticidad: Crítica
Paso 2: Diseñar Micro-segmentación (Mes 3-4)
Tabla de Segmentación:
| Zona | CIDR | Residentes | Entrada Permitida | Salida Permitida |
|---|---|---|---|---|
| DMZ | 10.0.1.0/24 | Web servers | 443 from internet | 8080 to App zone |
| App | 10.0.2.0/24 | App servers | 8080 from DMZ | 5432 to DB zone |
| DB | 10.0.3.0/24 | Databases | 5432 from App | 443 for patching |
| Admin | 10.0.4.0/24 | Bastion hosts | 22 from VPN | Any (for troubleshooting) |
Paso 3: Implementar en Fases (Mes 4-6)
Semana 1: Implementación Piloto (Baja Criticidad)
- Zona: Non-critical development
- Validar que no hay falsos positivos
- Monitoreo intensivo
Semana 2-3: Aplicaciones Estándar
- Zona: Internal applications
- Amplificar reglas sin riesgo
Semana 4-6: Producción
- Zona: Database servers
- Máximo monitoreo, rollback plan
4.4 PILAR 4: Datos
Objetivo: Clasificar, etiquetar, encriptar, y auditar acceso a datos
Paso 1: Clasificar Datos (Mes 2-3)
Esquema de Clasificación Chileno-Alineado:
| Clasificación | Ejemplos | Protección Mínima | Acceso Permitido |
|---|---|---|---|
| Público | Información marketing, reportes anuales | Integridad | Cualquiera corporativo |
| Interno | Políticas internas, directorios | Acceso controlado | Empleados solo |
| Confidencial | Datos financieros, contratos | Cifrado + MFA | Solo autorizados, auditoría |
| Secreto | PII (PDPA), PHI médico (HIPAA/PDPA) | Cifrado + MFA + Biometric | Whitelist de roles específicos |
Herramientas de Descubrimiento:
- Microsoft Purview Data Catalog
- AWS Macie
- GCP Cloud DLP
- Varonis (multi-cloud)
Paso 2: Etiquetar Datos (Mes 3-4)
Implementación Microsoft Purview (si usa Microsoft 365):
1. Crear tipos de información sensible (SIT):
- RUT (Rol Único Tributario): \d{1,2}\.\d{3}\.\d{3}-[\dK]
- Número de tarjeta: \d{4} \d{4} \d{4} \d{4}
- Correo corporativo: \w+@empresa.cl
2. Crear labels (etiquetas):
- Público
- Interno
- Confidencial (aplica cifrado automático)
- Secreto (aplica cifrado + restricción de copia)
3. Auto-aplicar labels basadas en SIT detectado:
- Si encuentra RUT → Label Secreto automático
- Si encuentra email corporativo → Label Interno
Paso 3: Encriptar Datos Sensibles (Mes 4-5)
Cifrado en Reposo:
| Plataforma | Servicio | Método | Activación |
|---|---|---|---|
| AWS | S3 | SSE-S3 (default) o SSE-KMS (recomendado) | Default on |
| Azure | Storage Account | AES-256 (default) o CMK | Default on |
| GCP | Cloud Storage | Google-managed (default) o CMEK | Default on |
Cifrado en Tránsito:
HTTPS/TLS 1.2+ : Todos los APIs
VPN o Dedicated: Transferencias de datos sensibles
Private Link: Conexiones entre servicios cloud
Paso 4: Auditoría de Acceso a Datos (Mes 5-6)
Configurar Data Access Auditing:
En Azure:
1. Enable Azure SQL Database auditing
2. Store logs en Storage Account
3. Configurar alerts si:
- Acceso después de horario
- Acceso de ubicaciones geográficas anómalas
- Acceso de cuentas de servicio en horas no-operacionales
- Queries que retornan > 10,000 filas
En AWS:
1. Enable CloudTrail para S3 object access
2. Configurar EventBridge rules para:
- Acceso a buckets sensibles
- Cambios de bucket policy
- Exportación de datos
3. Enviar alertas a SIEM
4.5 PILAR 5: Aplicaciones
Objetivo: Descubrir shadow IT, forzar acceso a través de broker seguro
Paso 1: Descubrimiento de Aplicaciones (Mes 3)
SaaS Discovery:
- Microsoft Defender for Cloud Apps: Descubrimiento automático de SaaS
- Netskope o Zscaler: Proxy-based discovery
- DNS query analysis: Revelar ciertas aplicaciones
Paso 2: Autorización de Aplicaciones (Mes 4)
Crear whitelist de aplicaciones aprobadas:
APROBADAS:
- Microsoft 365 (Teams, Word, Excel)
- Salesforce
- Jira
- Slack (solo para comunicación)
NO APROBADAS:
- Dropbox (usar OneDrive en su lugar)
- WeChat (usar Teams)
- Telegram personal (usar Teams)
EN QUARANTINE (requiere aprobación especial):
- GitHub (solo para desarrollo)
- Notion (usar SharePoint)
Paso 3: Conditional Access para Aplicaciones (Mes 4-5)
Ejemplo de Rule:
SI (Aplicación = "Salesforce") AND
(Usuario = "Sales_Team") AND
(Dispositivo = "No-managed")
ENTONCES:
Acción = Permitir con restricciones
Control = Read-only sin exportación
Auditoría = Logging completo
Sesión = Max 2 horas
4.6 PILAR 6: Infraestructura
Objetivo: Hardening de servidores, VMs, contenedores
Paso 1: Inventario de Infraestructura (Mes 2-3)
Ejecutar Asset Inventory:
Salida esperada:
- 250 VMs on-premise
- 180 instancias EC2 en AWS
- 120 App Services en Azure
- 45 contenedores en Kubernetes
- 1,200 IoT devices (smart meters)
Paso 2: Patching y Hardening (Mes 4-6)
Policy de Patching:
Criticidad | OS Patches | App Patches | Deadline |
Critical | Mensual | Dentro de 24h | 1 semana |
Alta | Mensual | Dentro de 1 semana | 2 semanas |
Media | Trimestral | Dentro de 2 semanas | 1 mes |
Baja | Trimestral | Dentro de 30 días | Próximo ciclo |
Paso 3: Configuración Segura (Mes 5-6)
Hardening Checklist:
☐ Desactivar puertos innecesarios
☐ Firewall local habilitado
☐ Antivirus/EDR activo
☐ Disk encryption activo
☐ SSH keys instead of passwords
☐ Audit logging enabled
☐ Fail2ban o similar para brute force
4.7 PILAR 7: Visibilidad y Orquestación
Objetivo: SIEM/XDR centralizado, automatización de respuesta
Paso 1: Implementar SIEM (Mes 6)
Opciones por Tamaño:
Empresas Pequeñas (< 500 empleados):
- Microsoft Sentinel (si usan Azure/Microsoft 365)
- Splunk Cloud
- Elastic Cloud
Empresas Medianas:
- Microsoft Sentinel + Microsoft Defender suite
- Splunk Enterprise
- Datadog Security
Empresas Grandes:
- Splunk Enterprise + Phantom
- Elastic Stack + Elastic Security
- Crowdstrike + Splunk
Paso 2: Fuentes de Logs a Conectar (Mes 6-7)
Tabla de Conexiones SIEM:
| Fuente | Frecuencia | Datos Críticos | Volumen Esperado |
|---|---|---|---|
| Azure AD / Entra | Real-time | Sign-in, MFA failures | 10K eventos/día |
| AWS CloudTrail | Real-time | API calls, root usage | 50K eventos/día |
| Firewalls | Real-time | Blocked connections | 100K eventos/día |
| EDR (Defender/CrowdStrike) | Real-time | Process execution, file changes | 50K eventos/día |
| Application logs | Hourly | Errors, exceptions | 20K eventos/día |
| Database audit logs | Real-time | Data access, queries | 30K eventos/día |
Paso 3: Crear Playbooks de Respuesta (Mes 7-8)
Ejemplo de Playbook Automatizado:
Trigger: User with admin privileges signs in from new geography
Detection Rule:
event.type = "sign_in" AND
user.admin = true AND
ip.country != user.usual_country AND
time.since_last_login > 24h
Automated Response:
Step 1: Enviar alerta a CISO (inmediato)
Step 2: Requiere re-autenticación + MFA adicional
Step 3: Limitar sesión a read-only por 1 hora
Step 4: Notificar al usuario: "¿Estás viajando?"
Step 5: Si usuario confirma: Permitir acceso normal
Step 6: Si NO responde en 30 min: Revocar acceso
Step 7: Crear ticket de investigación para SOC
5. Presupuesto Estimado para Chile
5.1 Modelo de Inversión (18 meses)
| Área | Pequeña (<200 emp) | Mediana (200-2000 emp) | Grande (>2000 emp) |
|---|---|---|---|
| Herramientas (licenses) | $80K | $250K | $800K |
| Implementación/Services | $60K | $200K | $600K |
| Personal/Headcount | $40K | $150K | $500K |
| Capacitación | $10K | $30K | $100K |
| TOTAL | $190K | $630K | $2M |
5.2 Breakdown de Herramientas (Empresas Medianas)
| Herramienta | Función | Costo Anual USD | Notas |
|---|---|---|---|
| Microsoft Sentinel | SIEM | $2.50/GB (~$25K/año) | Integrado con Azure |
| Microsoft Entra ID P1 | IAM | $6/usuario/mes (~$18K/año) | Para 200-300 usuarios |
| Intune | Device Management | $6/dispositivo/mes (~$12K/año) | Para 200 dispositivos |
| Microsoft Defender Suite | EDR/Threat Detection | $3/dispositivo/mes (~$7K/año) | E5 license recomendada |
| PAM Solution (BeyondTrust/Cyberark) | Privileged Access | $50K-80K/año | Crítico para regulación |
| CASB (Cloud Access Security Broker) | SaaS Security | $20K-40K/año | Detectar shadow IT |
| TOTAL | $132K-150K/año | Puede reducirse con Open Source |
5.3 Opciones de Reducción de Costos
Para empresas con presupuesto limitado:
- Usar soluciones open source (Mes 1-2):
- OpenStack (en lugar de propietario)
- Elastic Stack (en lugar de Splunk)
- FreeIPA (en lugar de Microsoft AD)
- Costo: ~$30K en lugar de $150K
- Implementación por fases:
- Comenzar con MFA + Logging centralizado
- Agregar Segmentación de Red en Fase 2
- Completar con Monitoreo en Fase 3
- Partnerships con integradores locales:
- NLT SECURE, Assertiva, NIVEL4 en Chile
- Ofrecen paquetes implementación a menor costo
- Conocimiento local de regulaciones
- Aprovechar soluciones ya pagadas:
- Si ya tiene Microsoft 365 → Sentinel + Entra ID
- Si tiene AWS → AWS Config + GuardDuty
- Si tiene Azure → Defender for Cloud + Intune
6. Gobernanza, Riesgos y Cumplimiento (GRC)
6.1 Mapeo a Requisitos Regulatorios Chilenos
Ley 21.663 (Ciberseguridad) – Requisitos por Pilar:
| Requirimiento Legal | Pilar ZT | Evidencia de Cumplimiento |
|---|---|---|
| Verificación continua de usuarios | Identidades | Logs de MFA, Conditional Access rules |
| Monitoreo de acceso a activos | Red + Datos | SIEM logs, audit trails |
| Segmentación de red | Red | Topología de subnets, NSG rules |
| Incidente reportable en 24-72h | Visibilidad | SOC alertas, MTTR metric |
| Designar oficial de seguridad | Gobernanza | Org chart, policy signed |
| Implementar estándares (NIST, ISO27001) | Todos | Framework mapping document |
Ley 21.719 (Protección de Datos) – Requisitos por Pilar:
| Requirimiento Legal | Pilar ZT | Evidencia de Cumplimiento |
|---|---|---|
| Cifrado de datos personales | Datos | Policies, encryption status report |
| DPIA para procesamiento alto riesgo | Gobernanza | DPIA documents, risk assessment |
| Trazabilidad de acceso a datos | Datos | Audit logs 12 meses |
| Consentimiento documentado | Gobernanza | Consent records, cookies |
| Notificación en 30 días en caso de brecha | Respuesta | IR plan, notification templates |
6.2 Matriz de Evaluación de Cumplimiento (Quarterly)
Template a usar cada trimestre:
Evaluación Q1 2026
1. IDENTIDADES (Pilar 1)
☐ MFA habilitada para acceso remoto: 98% (meta: 100%)
☐ Cuentas admin con MFA: 100% (meta: 100%)
☐ Roles basados en funciones: 85% de usuarios (meta: 95%)
☐ PAM implementado para acceso privilegiado: SÍ
Status: ✓ EN CAMINO
2. DISPOSITIVOS (Pilar 2)
☐ Dispositivos corporativos con EDR: 92% (meta: 100%)
☐ Antivirus/Malware scanning: 90% (meta: 100%)
☐ Devices cumpliendo con compliance: 87% (meta: 95%)
☐ Enrollment rate en Intune/Jamf: 85% (meta: 100%)
Status: ⚠ EN REZAGO
3. RED (Pilar 3)
☐ Micro-segmentación implementada: En 3 de 5 zonas (meta: todas)
☐ NACL rules por zona: SÍ
☐ Tráfico monitorizado: 70% (meta: 100%)
Status: ⚠ EN REZAGO
[... continuar con otros pilares ...]
RECOMENDACIONES:
1. Prioridad: Completar compliance de dispositivos (rezago de 8 puntos)
2. Acción: Hacer MFA deployment obligatorio para mobile
3. Timeline: Alcanzar 98% de devices en Q2
7. Gestión del Cambio y Comunicación
7.1 Cronograma de Comunicación
Semana 1:
- Anuncio ejecutivo: “Iniciaremos transformación de seguridad”
- Target: Todos los empleados
- Canal: Town Hall + Email
- Tone: Positivo, alineado con regulación
Mes 1:
- Training para administrativos: “Cómo usar MFA”
- Training para gerentes: “Ciclo de provisioning de acceso”
- Target: 100% of leaders
Mes 2-3:
- Rollout MFA para usuarios
- Guías visuales en intranet
- Help desk establecido
- Soporte: +56 2 XXXX XXXX (helpdesk local)
Mes 4-6:
- Capacitación: “Zero Trust en el día a día”
- Ejemplos: Cómo acceder a datos sensibles
- Reconocimiento: Personas que han completado capacitación
7.2 Manejo de Objeciones Comunes
“Esto va a ralentizar nuestro trabajo”
- Realidad: Inicialmente 5-10% más lento (1-2 segundos por login)
- Solución: Pre-registrar dispositivos, SSO configurable
- Beneficio: Después de 2 meses, más rápido gracias a automatización
“No necesitamos esto, nunca nos han hackeado”
- Realidad: Promedio de detección de brecha: 207 días (2024)
- Solución: Mostrar statistics de breaches en industria similar
- Regulatorio: Es requisito legal (Ley 21.663)
“MFA es incómodo”
- Realidad: Hardware token / Facial recognition / Fingerprint disponibles
- Solución: Permitir elección de método
- Beneficio: Mejor que perder laptop con datos
8. Casos de Uso: Validación en Mundo Real
8.1 Caso de Uso: Financiera Chilena (200 empleados)
Situación Inicial:
- AD on-premise sin MFA
- VPN con solo contraseña
- No hay segmentación de red
- Datos financieros en NAS sin cifrado
- Cumplimiento PDPA + Ley 21.663 requerido
Implementación 18 Meses:
Fase 1 (Meses 1-3):
- Migrar a Azure AD
- Habilitar MFA para admins (2 semanas)
- Centralizar logging en Azure Monitor
- Costo: $45K
Fase 2 (Meses 3-6):
- MFA para todos (4 semanas)
- PAM para acceso a datos financieros
- Implement Azure DLP
- Costo: $80K
Fase 3 (Meses 6-12):
- Segmentar red (Finance, Operations, Development)
- Implementar Azure Sentinel
- Criar Conditional Access rules
- Costo: $120K
Fase 4 (Meses 12-18):
- Maduración operacional
- Tabletop exercises
- DPIA completada
- Costo: $50K
Resultado Final (Mes 18):
✓ Cumplimiento PDPA: 95%
✓ Cumplimiento Ley 21.663: 90%
✓ MFA: 100%
✓ Tiempo de respuesta a incidentes: < 1 hora
✓ Total Investment: $295K
✓ ROI: 1 año (evitar 1 breach de $500K)
8.2 Caso de Uso: Energética con OVI en AWS
Situación Inicial:
- Crítica para infraestructura nacional (OVI)
- 2,000 empleados en múltiples países
- Sistemas legacy y cloud natives simultáneamente
- Múltiples datacenters
Implementación 18 Meses:
Diferencias respecto a Financiera:
- PAM más sofisticado (múltiples niveles)
- Respuesta a incidentes <= 30 minutos (vs 1 hora)
- Mayor automatización (OVI bajo supervisión ANCI)
- Auditorías trimestrales (vs anuales)
Costo: $800K-1.2M
Timeline: Más riguroso, con milestones mensuales
9. Checklist de Implementación
Fase 1: Foundational
- CISO/CTO designado como sponsor
- Task Force formada (tamaño: 5-8 personas)
- Presupuesto aprobado
- Inventario v1.0 completado
- Visión y objetivos documentados
- Cumplimiento con PDPA y Ley 21.663 mapeado
- Principales riesgos identificados
- Project manager asignado
Fase 2: Identity & Access
- SSO centralizado operacional (95%+ usuarios)
- MFA habilitada para acceso remoto (100%)
- MFA habilitada para todos (95%)
- Roles RBAC definidos (versión 1.0)
- Conditional Access policies probadas
- PAM piloto en 10% de acceso admin
- Auditoría de cambios de acceso activa
- Help desk capacitado en MFA
Fase 3: Network & Segmentation
- Topología de red documentada
- Micro-segmentación en zonas piloto
- SIEM/XDR en piloto
- Baseline de comportamiento normal establecida
- 70%+ de tráfico crítico monitorizado
- Playbooks de respuesta automática probados
- MTTR < 1 hora para amenazas críticas
Fase 4: Operations
- 95%+ de métricas en meta
- Cadencia de revisión trimestral establecida
- Documentación de policies actualizada
- Capacitación anual completada
- Tabletop exercises ejecutados (2x/año)
- Cumplimiento auditado (externos)
- Roadmap para Year 2 documentado
La implementación de Zero Trust para empresas chilenas no es un proyecto de TI puro, sino una transformación de negocio que requiere:
- Sponsor ejecutivo fuerte (CTO o Chief Security Officer)
- Inversión sostenida ($300K-$2M dependiendo tamaño)
- Cambio cultural (desde “confía dentro, no confíes fuera” a “nunca confíes”)
- Operación continua (no es un proyecto con fin definido)
- Alineamiento regulatorio (PDPA + Ley 21.663 son mandatorias)
El ROI es claro:
- Evitar breaches: Costo promedio en Chile = $500K-$2M
- Cumplimiento regulatorio: Multas de $345K-$690K si no cumple
- Confianza de clientes: Diferenciador competitivo en mercado
Recomendación Final: Comenzar hoy mismo con Fase 1 (MFA + Logging). Los próximos 6 meses determinarán la velocidad de todo el proyecto.