Quien decide, quien responde y quien audita.
El gobierno no es un problema de TI: es la estructura que decide prioridades, aprueba el apetito de riesgo y exige evidencia de que los controles funcionan. Sin gobierno, las politicas y la evaluacion de riesgo que vienen despues no tienen quien las haga cumplir.
Cada area mantiene un responsable de seguridad que reporta funcionalmente al CISO, pero conserva su responsabilidad operacional frente a su propio director.
| Rol | Responde por |
|---|---|
| Directorio / Direccion | Aprueba politica, apetito de riesgo, presupuesto y aceptacion de riesgos criticos. |
| Comite de Seguridad | Revisa riesgos, incidentes, excepciones y resultados de pruebas. |
| CISO | Lidera el SGSI; coordina politicas, analisis de riesgo e incidentes. |
| DPO / Privacidad | Licitud, minimizacion, brechas y relacion con autoridades. |
| IT | Identidades, cifrado, respaldos, monitoreo, recuperacion tecnica. |
| Areas de negocio | Duenas del proceso: definen criticidad y acceso necesario. |
| RR. HH. | Altas, cambios y bajas; evita cuentas huerfanas al dia siguiente de una salida. |
| Auditoria interna | Verifica de forma independiente, sin auditar su propio trabajo. |
Porque el CISO coordina el sistema de gestion, pero no es dueno de los datos ni de los procesos. Si un area clinica o de negocio no asume su propio riesgo, cualquier politica queda en el papel: nadie mas puede decidir, por ejemplo, que tan estricto debe ser un control de acceso sin frenar la operacion real.
Evita que la misma unidad ejecute, controle y audite una actividad.
Quien solicita un acceso no debe aprobarlo ni implementarlo. Un administrador privilegiado no debe poder borrar sus propios registros de actividad. Para emergencias existe el acceso de emergencia o break-glass: temporal, justificado, monitoreado y revisado despues, nunca silencioso.
Estos tres conceptos son los que un auditor o un tribunal usan para juzgar si el gobierno de seguridad fue solo un documento, o una practica real.
Es la politica que fija cuanto riesgo la organizacion esta dispuesta a tolerar antes de exigir tratamiento inmediato.
ISO 27001/27002, GDPR, Ley 21.719 y otros marcos.
El gobierno se traduce en exigencias concretas y auditables. ISO 27001 dice que sistema de gestion construir; ISO 27002 dice como se implementa cada control; las leyes fijan el piso legal minimo; y marcos como NIST o COBIT ofrecen otras formas de organizar y madurar lo mismo.
Norma que define los requisitos para establecer, implementar, mantener y mejorar un Sistema de Gestion de Seguridad de la Informacion (SGSI) basado en riesgos, con mejora continua bajo el ciclo PDCA (planificar, hacer, verificar, actuar).
| Control | Para que sirve |
|---|---|
| 5.15 / 5.16 / 5.18 | Control de acceso e identidades en todo el ciclo laboral. |
| 8.13 / 8.14 | Respaldo y redundancia de instalaciones de procesamiento. |
| 8.15 / 8.16 | Registro y monitoreo de actividades y anomalias. |
| 8.24 | Uso de criptografia y gestion de claves. |
27001 no esta sola: es la norma "paraguas" de una familia completa, cada una enfocada en un angulo distinto del mismo SGSI.
| Norma | Enfoque |
|---|---|
| ISO/IEC 27000 | Vocabulario y vision general de toda la familia. |
| ISO/IEC 27001 | Requisitos del SGSI: la unica certificable de esta lista. |
| ISO/IEC 27002 | Guia de implementacion de cada control (ver pilar Controles y madurez). |
| ISO/IEC 27005 | Metodologia de gestion de riesgo especifica para seguridad de la informacion (ver pilar Evaluacion de riesgo). |
| ISO/IEC 27017 | Controles de seguridad para servicios en la nube. |
| ISO/IEC 27018 | Proteccion de datos personales (PII) en la nube publica. |
| ISO/IEC 27019 | Controles especificos para el sector energetico. |
| ISO/IEC 27701 | Extension de gestion de privacidad (PIMS) sobre 27001/27002, alineada con GDPR. |
Para el caso hospital: si el hospital usa un proveedor de nube para almacenar la ficha clinica, 27017 y 27018 aplican directamente sobre ese proveedor.
| Norma | Que exige |
|---|---|
| GDPR, arts. 5, 9, 25, 32, 33, 35 | Principios de tratamiento, datos de salud como categoria especial, privacidad desde el diseno, notificacion de brechas. |
| Ley 19.628 (Chile) | Proteccion de la vida privada y datos sensibles. |
| Ley 20.584 + Decreto 41 | Reserva y manejo de la ficha clinica. |
| Ley 21.719 | Nuevo marco de proteccion de datos; vigencia desde diciembre de 2026. |
| Ley 21.663 | Marco de ciberseguridad e infraestructura critica. |
| Ley 19.799 | Firma electronica y documentos electronicos: da valor legal a la firma avanzada. |
Convenio de Budapest: primer tratado internacional contra el cibercrimen, base de la cooperacion entre paises para investigar delitos informaticos. EU AI Act: regula sistemas de inteligencia artificial segun su nivel de riesgo, con obligaciones mayores para los usos considerados de alto riesgo. Shadow AI: el uso de IA generativa por personal de la organizacion sin control ni aprobacion del area de seguridad, un riesgo emergente que el EU AI Act y las politicas internas buscan volver "Trusted AI": supervisada, documentada y con responsable definido.
Un hospital publico grande puede calificar como OIV: eso significa reportar incidentes a la ANCI en plazos acotados y demostrar controles minimos, no solo tenerlos documentados.
La Ley 21.719 es el nuevo marco chileno de proteccion de datos personales. Se publico en diciembre de 2024 y moderniza por completo a la antigua Ley 19.628 de 1999, que ya quedaba corta frente a estandares como el GDPR.
| Derecho | En simple |
|---|---|
| Acceso | saber que datos tuyos tiene una organizacion y para que los usa. |
| Rectificacion | corregir datos inexactos o desactualizados. |
| Cancelacion | pedir que se eliminen datos que ya no se justifican. |
| Oposicion | negarse a un tratamiento especifico de tus datos. |
| Portabilidad | pedir tus datos en un formato que puedas llevar a otro proveedor. |
| Bloqueo | congelar temporalmente el uso de un dato mientras se resuelve un reclamo. |
La ley exige notificar brechas de seguridad a la APDP y, cuando corresponde, a las personas afectadas; exige un encargado de tratamiento de datos en varios organismos publicos y en privados que procesan grandes volumenes o datos sensibles; y clasifica las infracciones en leves, graves y gravisimas, con multas en UTM que escalan segun la gravedad y pueden incluir medidas correctivas ademas de la sancion economica. Los montos exactos y los plazos de entrada en vigencia por tramo conviene revisarlos siempre en el texto oficial de la ley, no en un resumen como este.
Hoy la Ley 19.628 sigue rigiendo; la 21.719 la reemplaza por completo cuando termine su entrada en vigencia escalonada.
Una politica sin procedimiento es una intencion. La piramide documental va de lo general a lo operativo:
Seguridad de la informacion · clasificacion y manejo de datos · control de acceso · criptografia · uso aceptable y trabajo remoto · gestion de incidentes · continuidad y respaldo · gestion de vulnerabilidades y cambios · proveedores y nube · seguridad fisica.
ISO no es el unico lenguaje. Distintas industrias y reguladores usan otros marcos que resuelven el mismo problema de gobierno y riesgo con otra estructura.
A diferencia de ISO 31000, estas 6 funciones no son un orden fijo: una organizacion madura las ejecuta a la vez.
ISO 31000, BIA, RIA y cuanto cuesta en pesos.
Una matriz cualitativa ordena la prioridad. Los numeros en pesos responden la pregunta que realmente decide un presupuesto: cuanto cuesta no actuar.
Proceso continuo, no un informe unico.
Los nodos resaltados (analizar / evaluar) son donde entran BIA, RIA y la cuantificacion economica.
ISO 31000 es el proceso generico de gestion de riesgo, valido para cualquier tipo de riesgo de una organizacion. ISO/IEC 27005 toma ese mismo proceso y lo aterriza especificamente a riesgos de seguridad de la informacion: como identificar activos, amenazas y vulnerabilidades, y como conectar ese analisis directamente con el Anexo A de ISO 27001.
En la practica: ISO 31000 dice "hay que evaluar el riesgo"; ISO 27005 dice exactamente como hacerlo cuando el riesgo es de seguridad de la informacion.
Probabilidad e impacto, cada uno de 1 a 5. El nivel es el producto.
| Rango | Banda |
|---|---|
| 1 a 6 | Bajo |
| 7 a 12 | Medio |
| 13 a 19 | Alto |
| 20 a 25 | Critico |
El BIA dice que procesos hay que recuperar primero. El RIA identifica por que podrian fallar.
| Proceso | MTPD | RTO | RPO |
|---|---|---|---|
| Ficha clinica (HCE) | 4 h | 2 h | 15 min |
| UCI y dispositivos | 30 min | 15 min | ≈ 0 |
| Facturacion | 72 h | 24 h | 8 h |
Entre mas critica la vida del paciente, menor la tolerancia: la UCI no admite casi ninguna perdida de datos, facturacion si.
| ID | Amenaza | Nivel |
|---|---|---|
| R1 | Acceso no autorizado via cuentas obsoletas. | 20 · Critico |
| R2 | Phishing / ransomware por falta de capacitacion. | 20 · Critico |
La matriz cualitativa no dice cuanto invertir. Para eso: SLE, ARO y ALE.
SLE = AV × EFvalor del activo × factor de exposicion = perdida por evento ALE = SLE × AROperdida por evento × frecuencia anual = perdida anual esperadaPorque el costo real de mitigar varias partidas juntas (identidades, MFA, capacitacion, EDR) no es una suma fija: cada partida tiene un rango optimista/probable/pesimista. Por eso se simula.
SLE/ARO/ALE y Monte Carlo no son las unicas herramientas del curso. Otras tecnicas que se usan segun el tipo de riesgo:
| Tecnica | Para que sirve |
|---|---|
| FTA | Arbol de fallas: parte del incidente no deseado y baja hacia sus causas combinadas. |
| ETA | Arbol de eventos: parte de un evento inicial y proyecta hacia adelante sus posibles consecuencias. |
| DAFO / FODA | Debilidades, amenazas, fortalezas y oportunidades a nivel estrategico. |
| Juicio experto / Delphi | Consulta estructurada a especialistas cuando no hay datos historicos suficientes. |
| HAZOP | Estudio de peligros y operabilidad: identifica desviaciones de un proceso paso a paso. |
| Bow-tie | Combina causas y consecuencias de un mismo riesgo en un solo diagrama, con las barreras al medio. |
| Cadenas de Markov | Modela como un sistema pasa de un estado a otro con cierta probabilidad, util para procesos con memoria corta. |
| Estadistica bayesiana | Actualiza la probabilidad de un riesgo a medida que llega nueva evidencia. |
En vez de un numero unico, se corren miles de escenarios (10.000, tipicamente) con distribuciones triangulares por partida de costo, y se lee el resultado como probabilidad, no como certeza.
CIS Controls v8.1, la estructura de ISO 27002 y que tan madura esta la organizacion.
Saber que riesgos hay no basta: hay que elegir controles concretos, saber como estan documentados, y medir que tan bien se implementan hoy frente a donde deberian estar.
CIS Controls es un conjunto prescriptivo, priorizado y simplificado de buenas practicas. Su gracia es practica: empezar por medidas de alto valor antes de pasar a controles mas complejos, en vez de intentarlo todo a la vez.
| N.º | Control | Salvaguardas | IG1 |
|---|---|---|---|
| 1 | Inventario y control de activos empresariales | 5 | 2 |
| 2 | Inventario y control de activos de software | 7 | 3 |
| 3 | Proteccion de datos | 14 | 6 |
| 4 | Configuracion segura de activos y software | 12 | 7 |
| 5 | Gestion de cuentas | 6 | 4 |
| 6 | Gestion del control de acceso | 8 | 5 |
| 7 | Gestion continua de vulnerabilidades | 7 | 4 |
| 8 | Gestion de registros de auditoria | 12 | 3 |
| 9 | Proteccion de correo y navegadores | 7 | 2 |
| 10 | Defensas contra malware | 7 | 3 |
| 11 | Recuperacion de datos | 5 | 4 |
| 12 | Gestion de infraestructura de red | 8 | 1 |
| 13 | Monitoreo y defensa de la red | 11 | 0 |
| 14 | Concienciacion y capacitacion | 9 | 8 |
| 15 | Gestion de proveedores de servicios | 7 | 1 |
| 16 | Seguridad del software de aplicaciones | 14 | 0 |
| 17 | Gestion de respuesta a incidentes | 9 | 3 |
| 18 | Pruebas de penetracion | 5 | 0 |
La logica es acumulativa: IG2 incluye todo IG1, e IG3 incluye IG1 e IG2. El control 13 y el 18 son buen ejemplo: en IG1 casi no aplican, porque exigen capacidad de monitoreo y pruebas ofensivas que una organizacion pequena aun no tiene.
Un control tiene numero, nombre, total de salvaguardas, cantidad aplicable por grupo, y una explicacion de por que es critico. Cada salvaguarda agrega codigo, tipo de activo, funcion de seguridad (identificar, proteger, detectar, responder, recuperar, gobernar) y frecuencia. Ejemplo del Control 1: la salvaguarda 1.1 exige un inventario detallado de activos, revisado al menos cada semestre; la 1.2 exige un proceso semanal para retirar activos no autorizados; la 1.3 exige una herramienta de descubrimiento activo, corriendo a diario.
Explota una vulnerabilidad desconocida o sin parche disponible todavia. Por eso ninguna lista de controles basta por si sola: se necesita defensa en profundidad, monitoreo y capacidad de respuesta para reducir el impacto incluso cuando la falla especifica aun no tiene solucion.
Mientras 27001 exige que exista un control, 27002 explica como implementarlo: proposito, guia de implementacion y atributos (tipo de control, propiedades de seguridad, conceptos de ciberseguridad, capacidades operativas, dominios de seguridad).
Son la arquitectura detras de muchos de los controles anteriores: no son un control puntual, sino la forma en que se organizan todos juntos.
En vez de confiar en una sola barrera, se ponen varias capas independientes, de modo que si una falla las siguientes igual detienen el ataque: perimetro (firewall, VPN) · red (segmentacion, monitoreo) · endpoints (EDR, parches) · aplicaciones (desarrollo seguro, pruebas) · datos (cifrado, control de acceso). Zero Trust y defensa en profundidad se complementan: una desconfia por defecto, la otra multiplica las barreras.
Un control puede existir "en el papel" y no estar realmente institucionalizado. Los modelos de madurez miden ese salto entre documento y practica real.
Un GAP grande entre "nivel actual: 1" y "nivel objetivo: 4" no se cierra con una politica nueva: se cierra con una hoja de ruta de varias fases, igual que la del pilar de mitigacion.
Que hacer con el riesgo, y como saber si funciona.
Identificar y cuantificar el riesgo no sirve de nada sin un plan que lo trate, una forma de seguir operando si igual ocurre, e indicadores que digan si el plan realmente funciona.
Lo que queda despues de aplicar controles. Un residual "medio" no significa que se pueda dejar de vigilar: un incidente puede seguir siendo grave aunque su probabilidad haya bajado.
Se validan con simulacros, no con la existencia del documento. La practica ensena a escalar las pruebas en 4 niveles de complejidad creciente:
| Nivel | Tipo de prueba | Frecuencia |
|---|---|---|
| 1 | Revision documental: se lee y actualiza el plan, sin ejecutar nada. | Mensual |
| 2 | Ejercicio de mesa (tabletop): el equipo discute un escenario paso a paso, sin tocar sistemas reales. | Trimestral |
| 3 | Prueba funcional: se ejecuta una parte real del plan, por ejemplo restaurar un respaldo. | Semestral |
| 4 | Simulacro integral: se activa el plan completo como si la crisis fuera real. | Anual |
"Cero brechas este trimestre" no es evidencia de seguridad si no hay forma de detectarlas. Toda metrica necesita universo, periodo, fuente y responsable definidos para ser creible.
| Fase | Foco |
|---|---|
| 0 a 30 dias | Contencion: cerrar lo urgente y confirmado. |
| 31 a 90 dias | Fortalecimiento: controles, capacitacion, pruebas. |
| 91 a 180 dias | Resiliencia: segmentacion, DRP/BCM, SoA. |
| Continuo | Mejora: revision periodica del apetito de riesgo. |