1. INTRODUCCIÓN Y ENCUADRE

El análisis y la gestión de riesgos constituyen el mecanismo que transforma la seguridad de la información en una disciplina de gobierno. Una organización no puede proteger de la misma manera todos sus datos, servicios, aplicaciones, equipos, instalaciones y proveedores: los recursos son limitados, los activos tienen valores distintos y las amenazas no se materializan con la misma frecuencia ni causan el mismo daño. El propósito del análisis de riesgos es construir una representación razonada del sistema para saber qué debe protegerse, frente a qué, con qué prioridad y hasta qué nivel.

En el ámbito sanitario esta necesidad es especialmente visible. Un sistema clínico puede manejar información de salud, soportar decisiones asistenciales, coordinar profesionales, intercambiar datos con laboratorios o farmacia y permanecer disponible durante las veinticuatro horas. La pérdida de confidencialidad puede afectar a derechos fundamentales; una alteración no detectada puede comprometer la integridad de la información clínica; una indisponibilidad prolongada puede interrumpir procesos asistenciales; y la ausencia de autenticidad o trazabilidad puede impedir atribuir correctamente una actuación. El análisis debe contemplar simultáneamente estas dimensiones y evitar la simplificación de reducir la seguridad al cifrado o a la instalación de herramientas.

MAGERIT, acrónimo de Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información, fue promovida históricamente por los órganos responsables de la política informática de la Administración española. Su versión 3, publicada en 2012, proporciona un método, un catálogo de elementos y una guía de técnicas. Continúa siendo una referencia pública ampliamente utilizada y resulta especialmente relevante para interpretar el Esquema Nacional de Seguridad, aunque el Real Decreto 311/2022 no impone MAGERIT ni PILAR de forma exclusiva: exige que cada organización realice su propia gestión de riesgos mediante una metodología reconocida internacionalmente.

La metodología distingue dos grandes actividades. El análisis de riesgos determina qué tiene la organización, cuánto importa, a qué amenazas está expuesto, qué protección existe y cuál es el estado de impacto y riesgo. El tratamiento de los riesgos permite decidir si se reducen mediante salvaguardas, se evitan modificando la actividad, se comparten con terceros o se aceptan de forma consciente. Ambas actividades forman la gestión de riesgos y desembocan en decisiones de dirección, proyectos de seguridad y seguimiento continuo.

El tema también aborda el plan de seguridad, entendido en MAGERIT como la traducción de las decisiones de tratamiento a programas y proyectos concretos, con prioridades, responsables, recursos, calendario e indicadores. No debe confundirse con la política de seguridad: la política establece principios, roles y directrices; el plan ordena actuaciones para alcanzar un estado objetivo de protección.

PILAR es un conjunto de herramientas de Entorno de Análisis de Riesgos que aplica MAGERIT. Permite construir modelos de activos y dependencias, asociar amenazas, valorar frecuencia y degradación, caracterizar salvaguardas y calcular estados de impacto y riesgo. Además, incorpora módulos relacionados con el ENS, la continuidad y el cumplimiento. La herramienta automatiza cálculos y facilita la trazabilidad, pero no sustituye el conocimiento de los responsables del servicio, de la información, de la seguridad y del sistema.

Para una oposición técnica A1 interesa dominar tres planos. El primero es conceptual: diferenciar activo, amenaza, vulnerabilidad, impacto, riesgo, salvaguarda y riesgo residual. El segundo es metodológico: conocer las tareas MAR, las dependencias entre activos y la relación entre impacto y frecuencia. El tercero es de gobierno: comprender cómo los resultados se convierten en decisiones, declaración de aplicabilidad, proyectos de seguridad, continuidad, auditoría y mejora continua.

2. FUNDAMENTOS Y TERMINOLOGÍA DEL RIESGO

2.1. Qué es el Riesgo en Seguridad de la Información?

Antes de meternos en MAGERIT, tenemos que tener clarísimo qué es un riesgo. Y no, no es lo mismo que una amenaza ni que una vulnerabilidad. Vamos a desgranar los conceptos básicos:

RIESGO = función de FRECUENCIA/PROBABILIDAD e IMPACTO

2.2. Por Qué Necesitamos Gestionar los Riesgos?

La pregunta del millón. ¿Por qué no podemos simplemente «poner mucha seguridad» y ya está? Pues porque:

1. Recursos limitados: El SAS no tiene un presupuesto infinito. Hay que priorizar dónde invertimos en seguridad. ¿Gastamos en un firewall de última generación o en formar a los usuarios? ¿Ciframos todo o solo lo crítico? El análisis de riesgos te permite tomar decisiones informadas basadas en datos, no en intuiciones.
2. Cumplimiento normativo: El ENS, el RGPD, la ISO 27001… todas exigen análisis de riesgos formal y documentado. No es opcional. Si mañana te audita el CCN-CERT o la AEPD y no tienes un análisis de riesgos actualizado de Diraya, te van a poner una sanción que te vas a acordar.
3. Justificación de inversiones: Cuando quieres pedir presupuesto para comprar un SIEM (Security Information and Event Management) o contratar un servicio de respuesta a incidentes… ¿cómo justificas esa inversión? Con un análisis de riesgos que demuestre que el riesgo residual sin esas medidas es inaceptable.
4. Toma de decisiones estratégicas: ¿Migramos Diraya a la nube o lo mantenemos on-premise? ¿Permitimos BYOD (Bring Your Own Device) al personal sanitario? ¿Implementamos doble factor de autenticación en todos los sistemas? Cada una de esas decisiones tiene implicaciones de seguridad que hay que analizar.
5. Prevención vs reacción: Es mucho más barato prevenir un incidente que gestionarlo cuando ya ha ocurrido. Un ransomware que cifre las historias clínicas de un hospital puede costar millones de euros en recuperación, pérdida de reputación, multas RGPD… Un análisis de riesgos previo habría identificado esa amenaza y permitido implementar salvaguardas (backups offsite, segmentación de red, formación antiphishing) por una fracción del coste.

2.3. Distinciones terminológicas que deben mantenerse

En MAGERIT se utiliza con frecuencia la frecuencia de la amenaza en lugar de una probabilidad abstracta. La frecuencia expresa una tasa esperada de ocurrencia en un periodo. El riesgo se deriva algorítmicamente del impacto y la frecuencia, pero no debe enseñarse como una única multiplicación universal: las escalas cualitativas, dependencias y funciones de valoración pueden requerir tratamientos distintos.

3. MARCO NORMATIVO Y DE GOBIERNO

3.1. Gestión basada en riesgos en el Esquema Nacional de Seguridad

El Real Decreto 311/2022 configura la gestión basada en riesgos como parte del proceso integral de seguridad. Su artículo 14 exige que cada organización que desarrolle o implante sistemas para tratar información o prestar servicios realice su propia gestión de riesgos. Esta gestión se articula mediante el análisis y el tratamiento de los riesgos, empleando una metodología reconocida internacionalmente. La consecuencia práctica es doble: la organización no puede trasladar íntegramente la responsabilidad a un proveedor y tampoco puede justificar medidas mediante fórmulas genéricas sin relacionarlas con el sistema concreto.

La medida op.pl.1 del anexo II desarrolla el análisis de riesgos con niveles crecientes de formalidad. Para categoría BÁSICA se identifican los activos más valiosos, las amenazas más probables, las salvaguardas y los principales riesgos residuales. La categoría MEDIA incorpora el refuerzo R1: análisis semiformal, lenguaje específico, catálogo básico de amenazas, semántica definida, valoración cualitativa de activos, cuantificación de amenazas y valoración del riesgo residual. La categoría ALTA aplica el refuerzo R2: análisis formal con fundamento matemático reconocido, amenazas posibles, priorización de salvaguardas y asunción formal del riesgo residual.

3.2. Política de seguridad, responsabilidades y aceptación del riesgo

La política de seguridad define el marco de gobierno, los roles y la estructura documental. El ENS diferencia al responsable de la información, responsable del servicio, responsable de la seguridad y responsable del sistema. Esta separación es esencial porque la valoración del daño no puede quedar únicamente en manos técnicas: el responsable de la información conoce las consecuencias de una pérdida de confidencialidad o integridad, mientras que el responsable del servicio determina el perjuicio asociado a la interrupción o degradación del servicio.

La aceptación del riesgo residual corresponde a la autoridad con capacidad para asumir sus consecuencias, no al analista ni a la herramienta. El equipo de riesgos aporta una estimación fundamentada; la dirección decide si el nivel residual es aceptable, si exige nuevas salvaguardas o si debe modificarse el alcance del servicio. La aceptación debe documentarse, fijar condiciones y revisarse cuando cambien los supuestos.

3.3. Relación con ISO/IEC 27001, ISO/IEC 27005 y protección de datos

ISO/IEC 27001 exige que el sistema de gestión de seguridad de la información establezca un proceso de evaluación y tratamiento de riesgos coherente y repetible. ISO/IEC 27005 ofrece orientación específica para la gestión de riesgos de seguridad de la información. MAGERIT puede utilizarse como método de evaluación dentro de un SGSI siempre que la organización defina sus criterios de aceptación, mantenga la trazabilidad entre riesgos y controles y revise los resultados.

El análisis de riesgos de seguridad no es idéntico a la evaluación de impacto relativa a la protección de datos. El Reglamento General de Protección de Datos obliga a aplicar medidas apropiadas atendiendo al riesgo para los derechos y libertades de las personas y, cuando un tratamiento pueda entrañar alto riesgo, puede exigir una evaluación de impacto. Ambos trabajos comparten información sobre activos, amenazas, medidas y consecuencias, pero difieren en su objeto: la EIPD se centra en los efectos del tratamiento sobre las personas; MAGERIT analiza el sistema de información y los objetivos de la organización en sus dimensiones de seguridad.

3.4. Ciclo de vida y reevaluación

El análisis no es una fotografía perpetua. El ENS exige vigilancia continua y reevaluación periódica, y MAGERIT insiste en el seguimiento de los supuestos. Debe revisarse ante cambios significativos: incorporación de servicios en la nube, nuevas interconexiones, modificación del modelo de identidad, externalización, actualización relevante de arquitectura, aparición de amenazas, incidentes graves, cambios normativos o alteración del valor de los servicios.

4. MAGERIT: ESTRUCTURA, ALCANCE Y PRODUCTOS

4.1. Naturaleza, finalidad y alcance

MAGERIT es un método formal orientado a investigar los riesgos que soportan los sistemas de información y a recomendar medidas apropiadas para mantenerlos bajo control. Su finalidad no es producir una cifra aislada, sino facilitar decisiones de gobierno con una terminología común y una cadena de razonamiento auditable. El método conecta el valor que la organización atribuye a su información y servicios con las amenazas, las salvaguardas y los estados de impacto y riesgo.

La metodología resulta aplicable a sistemas en proyecto y a sistemas en explotación. Aplicarla durante el diseño permite incorporar requisitos de seguridad, continuidad, registro, identidad y arquitectura antes de que las decisiones sean costosas de modificar. En explotación, permite revisar si las salvaguardas continúan siendo eficaces, priorizar actuaciones y justificar inversiones.

4.2. Los tres libros de MAGERIT v3

Los catálogos son ayudas, no listas cerradas. Un análisis correcto adapta los tipos de activos, amenazas y salvaguardas al contexto. Copiar sin criterio el catálogo produce modelos voluminosos y poco útiles; omitir elementos relevantes por no aparecer literalmente en él produce una falsa sensación de exhaustividad.

4.3. Dos niveles: proceso de gestión y proyecto de análisis

MAGERIT diferencia el proceso continuo de gestión de riesgos de los proyectos que construyen o renuevan la base del análisis. La gestión establece el contexto, los criterios de evaluación y aceptación, analiza y trata riesgos, comunica las decisiones y supervisa cambios. Un proyecto de análisis, denominado PAR, organiza el trabajo intensivo necesario para disponer de un modelo fiable.

4.4. Proyecto PAR y método MAR

El proyecto PAR comprende actividades preliminares, elaboración y comunicación. Las preliminares incluyen el estudio de oportunidad, la determinación del alcance, la planificación y el lanzamiento. El método de análisis de riesgos, MAR, se estructura en caracterización de activos, amenazas y salvaguardas, y estimación del estado de riesgo. Esta nomenclatura es especialmente preguntable porque permite distinguir tareas metodológicas de actividades económicas o de gestión de proyectos.

4.5. Productos y trazabilidad

Entre los productos se encuentran el modelo de valor, el mapa de amenazas, la declaración de aplicabilidad de salvaguardas, la valoración de su eficacia, los informes de impacto y riesgo, el informe de insuficiencias y el plan de seguridad. La calidad no depende de acumular documentos, sino de que cada conclusión pueda rastrearse hasta las evidencias y criterios utilizados. Un riesgo debe poder relacionarse con los activos afectados, las amenazas, las valoraciones, las salvaguardas existentes, las actuaciones previstas y el responsable que lo acepta.

5. ACTIVOS, DEPENDENCIAS Y VALORACIÓN

5.1. Activos

Los activos son el núcleo del análisis de riesgos. Todo gira alrededor de ellos. MAGERIT define diferentes tipos de activos:

5.1.1. Valoración de Activos

Una vez identificados los activos, hay que valorarlos. ¿Cuánto «valen» para la organización? No hablamos de su precio de compra, sino de su valor estratégico.

MAGERIT propone valorar cada activo en 5 dimensiones de seguridad:

• [C] Confidencialidad: ¿Qué impacto tendría que personas no autorizadas accedieran a este activo? En historias clínicas: CRÍTICO (violación RGPD, daño reputacional, multas millonarias, daño al paciente).
• [I] Integridad: ¿Qué impacto tendría que el activo se modificase sin autorización o de forma incorrecta? En datos de prescripción médica: CRÍTICO (riesgo vital para el paciente, responsabilidad penal).
• [D] Disponibilidad: ¿Qué impacto tendría que el activo no estuviera accesible cuando se necesita? En servicio de urgencias de Diraya: CRÍTICO (imposibilidad de atender emergencias, riesgo vital).
• [A] Autenticidad: ¿Qué impacto tendría que no pudiéramos verificar quién realizó una acción sobre el activo? En recetas electrónicas: ALTO (posible fraude, prescripción no autorizada, problemas legales).
• [T] Trazabilidad: ¿Qué impacto tendría que no pudiéramos demostrar qué acciones se realizaron sobre el activo? En accesos a historias clínicas: ALTO (imposibilidad de auditar accesos indebidos, problemas en juicios, incumplimiento RGPD).

VALOR DEL ACTIVO = [C, I, D, A, T] Ejemplo: Historia Clínica Digital en Diraya = [10, 10, 9, 8, 9] (escala 0-10, donde 10 = impacto crítico)

5.3. Dependencias, valor propio y valor acumulado

Las dependencias permiten trasladar el valor de los activos esenciales a los activos que los soportan. Un servidor puede no tener un valor propio elevado para la misión, pero acumular un valor muy alto porque de él dependen varios servicios clínicos. Esta propagación evita infravalorar infraestructuras, identidades, comunicaciones o personas que, consideradas aisladamente, parecerían reemplazables.

La dependencia debe modelarse por dimensión. Una aplicación puede depender totalmente de una base de datos para integridad y disponibilidad, pero solo parcialmente de un componente de presentación para confidencialidad. La simplificación de usar una única relación para todas las dimensiones puede distorsionar el resultado.

6. AMENAZAS, VULNERABILIDADES, FRECUENCIA Y DEGRADACIÓN

6.1. Amenazas

Una amenaza es un evento que, si se materializa, puede causar daño a los activos. MAGERIT clasifica las amenazas en varios tipos:

6.1.1. Clasificación de Amenazas según MAGERIT v3

6.2. Vulnerabilidades

Las vulnerabilidades son las debilidades que permiten que las amenazas se materialicen. Importante: una amenaza sin vulnerabilidad asociada NO puede materializarse.

Ejemplo: La amenaza [N.1] Fuego existe siempre. Pero si el CPD tiene un sistema de detección y extinción automática de incendios (salvaguarda), la vulnerabilidad es baja y la probabilidad de que el fuego cause daños significativos es mínima.

MAGERIT no tiene un catálogo cerrado de vulnerabilidades (serían miles), pero proporciona técnicas para identificarlas. Las más comunes en el SAS:

• Vulnerabilidades técnicas: Software sin parchear, configuraciones inseguras, cifrado débil o inexistente, ausencia de segmentación de red, contraseñas débiles, puertos innecesarios abiertos, servicios obsoletos no desactivados
• Vulnerabilidades organizativas: Falta de políticas de seguridad, ausencia de procedimientos documentados, roles y responsabilidades no definidos, falta de formación del personal, ausencia de controles de acceso, no segregación de funciones
• Vulnerabilidades físicas: Acceso no controlado al CPD, ausencia de sistemas contra incendios, climatización insuficiente, ausencia de SAIs o generadores, ubicación en zona inundable

6.4. Frecuencia y degradación

La caracterización de una amenaza requiere estimar con qué frecuencia puede materializarse y qué degradación causaría en cada dimensión. Una amenaza puede ser frecuente y de impacto limitado, o rara y catastrófica. El historial de incidentes, la telemetría, la inteligencia de amenazas, los informes de proveedores y el juicio experto son fuentes posibles, pero deben documentarse.

La degradación no siempre es total. Puede expresarse como porcentaje o mediante escalas. Un fallo de comunicaciones de cinco minutos no tiene el mismo efecto que una interrupción de ocho horas; una divulgación parcial no equivale a la exposición completa de una base de datos. Cuando el tiempo cambia las consecuencias, conviene complementar el análisis con continuidad y análisis de impacto.

7. SALVAGUARDAS, EFICACIA Y MADUREZ

7.1. Salvaguardas

Las salvaguardas (o contramedidas) son los controles de seguridad que implementamos para reducir el riesgo. Actúan de tres formas:

1. Reduciendo la probabilidad de que la amenaza se materialice: Ej: Un firewall reduce la probabilidad de intrusión externa.
2. Reduciendo el impacto si la amenaza se materializa: Ej: Un backup diario no evita que un ransomware cifre los datos, pero reduce el impacto porque podemos recuperar.
3. Detectando cuando la amenaza se está materializando: Ej: Un IDS no evita ni reduce el impacto de un ataque, pero nos alerta para que podamos reaccionar rápido.

MAGERIT clasifica las salvaguardas en familias, alineadas con ISO 27002 y con el Anexo II del ENS:

7.3. Eficacia, cobertura y madurez

La existencia nominal de una salvaguarda no implica eficacia. Debe valorarse su cobertura, grado de implantación, operación, supervisión y capacidad para reducir la amenaza concreta. Un procedimiento aprobado pero desconocido por los usuarios tiene baja eficacia; una copia de seguridad no probada no garantiza recuperación; un registro que no se revisa aporta trazabilidad limitada.

La madurez puede representarse mediante niveles de proceso, pero no debe confundirse con el efecto técnico. Una salvaguarda madura puede no cubrir todos los activos, y una tecnología avanzada puede operar con baja madurez. La estimación debe justificar cómo afecta a la frecuencia y a la degradación.

8. MÉTODO DE ANÁLISIS DE RIESGOS MAR

8.1. Estructura del método MAR

El método MAR se compone de cuatro actividades: MAR.1 caracterización de los activos, MAR.2 caracterización de las amenazas, MAR.3 caracterización de las salvaguardas y MAR.4 estimación del estado de riesgo. Las tres primeras construyen el modelo; la cuarta combina sus resultados para estimar impacto y riesgo potenciales y residuales.

8.1. Tarea 1: Identificación de Activos

El primer paso es hacer un inventario completo de todos los activos del sistema de información que vamos a analizar. No puedes proteger lo que no conoces.

¿Cómo se hace?

• Entrevistas con responsables de negocio y técnicos
• Revisión de documentación existente (diagramas de arquitectura, inventarios CMDB)
• Análisis de flujos de información (¿qué datos se procesan?, ¿de dónde vienen?, ¿a dónde van?)
• Identificación de dependencias entre activos (Diraya depende de la base de datos Oracle, que depende del servidor físico, que depende de la red, que depende del router…)

8.2. Tarea 2: Valoración de Activos

Una vez identificados los activos, hay que valorarlos. ¿Cuánto valen para la organización en cada una de las 5 dimensiones de seguridad?

Aquí se puede optar por dos enfoques:

8.2.1. Enfoque Cuantitativo

Asignamos un valor económico estimado al activo. ¿Cuánto nos costaría si se pierde, se daña, o se ve comprometido?

Ejemplo: Base de Datos de Historias Clínicas del SAS Confidencialidad: 50.000.000 € (coste estimado de multas RGPD + demandas + daño reputacional) Integridad: 10.000.000 € (coste de verificar y recuperar datos corruptos) Disponibilidad: 100.000 €/hora (pérdida asistencial por hora de caída)

8.2.2. Enfoque Cualitativo

Usamos una escala ordinal (por ejemplo, 0 a 10, o Muy Bajo / Bajo / Medio / Alto / Muy Alto / Crítico) para valorar el impacto.

Ejemplo: Base de Datos de Historias Clínicas del SAS (escala 0-10) Confidencialidad: 10 (impacto CRÍTICO) Integridad: 10 (impacto CRÍTICO) Disponibilidad: 9 (impacto MUY ALTO) Autenticidad: 8 (impacto ALTO) Trazabilidad: 9 (impacto MUY ALTO)

8.3. Tarea 3: Identificación y Valoración de Amenazas

Para cada activo, identificamos qué amenazas le pueden afectar y con qué probabilidad.

Técnicas:

• Uso del catálogo de amenazas de MAGERIT como referencia
• Análisis histórico de incidentes pasados
• Consulta de fuentes de inteligencia de amenazas (CCN-CERT, INCIBE, ENISA)
• Evaluación de la exposición del activo (¿está expuesto a Internet? ¿tiene muchos usuarios? ¿contiene datos muy valiosos?)

Valoración de la probabilidad:

8.5. Trabajo iterativo y comunicación

En la práctica, las tareas no se ejecutan como compartimentos estancos. Al entrevistar al responsable de un activo surgen simultáneamente dependencias, amenazas y salvaguardas. La metodología permite iterar, siempre que se mantenga la coherencia y se documenten los cambios. La comunicación de resultados transforma el análisis técnico en información útil para la decisión.

9. ESTIMACIÓN DEL IMPACTO, RIESGO Y TRATAMIENTO

9.1. Tarea 4: Cálculo del Impacto y del Riesgo

Aquí es donde unimos todo. Para cada par (Activo, Amenaza), calculamos:

1. IMPACTO POTENCIAL: Si la amenaza se materializa, ¿qué daño causa al activo en cada dimensión de seguridad?
2. RIESGO INTRÍNSECO (o Riesgo sin salvaguardas): Combinamos la probabilidad de la amenaza con el impacto potencial.

IMPACTO = Valor del Activo × Degradación causada por la Amenaza RIESGO INTRÍNSECO = Probabilidad × Impacto

Matriz de Riesgo (enfoque cualitativo):

Se suele representar en una matriz de doble entrada:

Interpretación:

• Muy Bajo → Riesgo aceptable. No requiere acción inmediata.
• Bajo → Riesgo tolerable. Monitorizar.
• Medio → Riesgo importante. Requiere plan de tratamiento.
• Alto → Riesgo grave. Requiere acción prioritaria.
• Crítico → Riesgo inaceptable. Requiere acción INMEDIATA.

9.2. Tarea 5: Tratamiento del Riesgo y Selección de Salvaguardas

Una vez calculado el riesgo, hay que gestionarlo. MAGERIT (siguiendo ISO 31000) propone 4 estrategias de tratamiento del riesgo:

9.2.1. REDUCIR el Riesgo (MITIGAR)

Implementar salvaguardas para disminuir la probabilidad de que la amenaza se materialice, o para reducir el impacto si ocurre.

Ejemplo en el SAS: Ante el riesgo de ransomware (probabilidad ALTA, impacto CRÍTICO), se implementan salvaguardas:

• Formación antiphishing (reduce probabilidad)
• Filtros de correo con sandboxing (reduce probabilidad)
• EDR en endpoints (reduce probabilidad + detecta temprano)
• Segmentación de red (reduce impacto, contención)
• Backups offsite con versionado (reduce impacto, permite recuperación)

Tras implementar estas salvaguardas, el riesgo residual baja de CRÍTICO a MEDIO.

9.2.2. TRANSFERIR el Riesgo

Trasladar el riesgo (o parte de él) a un tercero. Típicamente mediante seguros o contratos con proveedores.

Ejemplo en el SAS:

• Contratar un seguro de ciberriesgos que cubra costes de recuperación post-ransomware
• Contratar un servicio cloud con SLA que garantice disponibilidad del 99,95% (el proveedor asume el riesgo de caídas)
• Externalizar el servicio de backup a un proveedor especializado con cláusulas de responsabilidad

9.2.3. EVITAR el Riesgo

Eliminar completamente la causa del riesgo, típicamente no realizando la actividad que genera el riesgo.

Ejemplo en el SAS:

• Decisión de NO permitir acceso remoto sin VPN a sistemas críticos (se evita el riesgo de accesos no seguros desde Internet)
• Decisión de NO implementar BYOD para personal sanitario (se evitan riesgos de fuga de datos en dispositivos no controlados)
• Decisión de NO publicar ciertos datos estadísticos porque podrían permitir reidentificación de pacientes

9.2.4. ACEPTAR el Riesgo

Tomar la decisión consciente de asumir el riesgo sin tratamiento adicional, generalmente porque:

• El riesgo residual es Muy Bajo o Bajo
• El coste de mitigarlo es desproporcionado respecto al riesgo
• No existen salvaguardas técnicamente viables

Ejemplo en el SAS:

• Aceptar el riesgo de terremoto en el CPD de Sevilla (probabilidad muy baja, impacto alto, pero salvaguardas como edificio antisísmico son inasumibles económicamente). Se mitiga parcialmente con CPD de respaldo en Granada.

9.2.5. Riesgo Residual

Tras aplicar las salvaguardas (estrategia de REDUCIR), siempre queda un riesgo residual. Es imposible llevar el riesgo a cero (a menos que evites la actividad completamente).

RIESGO RESIDUAL = Riesgo Intrínseco - Eficacia de las Salvaguardas

El objetivo del análisis de riesgos es que el riesgo residual sea ACEPTABLE para la organización, según los criterios de aceptación del riesgo definidos en la Política de Seguridad.

9.3. Impacto potencial, residual y riesgo residual

El impacto potencial representa las consecuencias sin considerar la eficacia de las salvaguardas; el impacto residual considera las medidas presentes. De forma análoga, el riesgo potencial se estima antes de las salvaguardas y el residual después. Comparar ambos estados muestra el efecto de la protección y permite identificar insuficiencias.

El riesgo residual nunca es automáticamente aceptable por ser menor que el inicial. Debe compararse con los criterios definidos por la organización. Puede ser necesario implantar nuevas medidas, modificar el servicio, transferir parte del riesgo o aceptar formalmente la exposición.

9.4. Criterios de aceptación y priorización

Los criterios deben fijarse antes de manipular resultados para evitar decisiones oportunistas. Pueden establecer umbrales por dimensión, tipos de activo, obligaciones legales, continuidad, seguridad de las personas o compromisos contractuales. La priorización combina gravedad, urgencia, coste, dependencia entre proyectos, viabilidad y riesgo durante la transición.

10. MODELOS CUALITATIVO, CUANTITATIVO Y TÉCNICAS DE ANÁLISIS

MAGERIT soporta dos enfoques para realizar el análisis de riesgos: el enfoque cualitativo y el enfoque cuantitativo. Vamos a compararlos:

10.1. Análisis Cualitativo

Definición: Utiliza escalas ordinales (categorías) para valorar probabilidades e impactos.

Características:

• Usa etiquetas: Muy Bajo / Bajo / Medio / Alto / Muy Alto / Crítico
• O escalas numéricas ordinales: 0-10, 1-5…
• Basado en juicio experto y experiencia
• Más rápido y menos costoso
• No requiere datos históricos precisos
• Resultados más fáciles de comunicar a no técnicos

Ventajas:

• ✅ Rapidez de ejecución (semanas vs meses)
• ✅ No requiere estimaciones económicas complejas
• ✅ Fácil de entender por la Dirección y responsables no técnicos
• ✅ Suficiente para cumplir requisitos ENS y RGPD
• ✅ Permite priorizar riesgos claramente

Inconvenientes:

• ❌ Subjetividad en las valoraciones
• ❌ Dificulta el cálculo preciso del ROI de las salvaguardas
• ❌ No permite comparar riesgos de forma cuantitativa

¿Cuándo usarlo?

• Análisis iniciales o de alto nivel
• Organizaciones sin datos históricos de incidentes
• Cuando el tiempo es limitado
• Para sistemas no críticos o de impacto medio
• En la mayoría de casos en el sector público (incluido el SAS)

10.2. Análisis Cuantitativo

Definición: Asigna valores numéricos (típicamente económicos) a probabilidades e impactos.

Características:

• Usa valores monetarios: 10.000€, 500.000€…
• Probabilidades expresadas en porcentaje o frecuencia anual
• Basado en datos históricos, estadísticas, modelos actuariales
• Permite cálculos precisos de expectativa de pérdida
• Requiere más tiempo y recursos

Conceptos clave del análisis cuantitativo:

SLE = Valor del Activo × Factor de Exposición

ARO = Número de veces que se espera que ocurra la amenaza en un año

ALE = SLE × ARO

ROI = (ALE antes - ALE después - Coste Anual Salvaguarda) / Coste Inicial Salvaguarda

Ventajas:

• ✅ Precisión en la valoración de riesgos
• ✅ Permite justificar inversiones con ROI claro
• ✅ Facilita la comparación objetiva entre riesgos
• ✅ Útil para reporting a Dirección (lenguaje económico)
• ✅ Facilita la toma de decisiones sobre priorización de salvaguardas

Inconvenientes:

• ❌ Requiere datos históricos fiables (que a menudo no existen)
• ❌ Proceso lento y costoso
• ❌ Difícil valorar económicamente ciertos impactos (reputación, confianza…)
• ❌ Falsa sensación de precisión (los datos base suelen ser estimaciones)
• ❌ Requiere personal especializado

¿Cuándo usarlo?

• Sistemas de muy alto valor o muy críticos
• Cuando se necesita justificar grandes inversiones
• Organizaciones con buenos datos históricos de incidentes
• Sector financiero, seguros, grandes corporaciones
• Cuando se requiere certificación específica que lo exija

10.3. Comparativa Cualitativo vs Cuantitativo

10.4. Enfoque Mixto (Recomendación de MAGERIT)

MAGERIT recomienda en la práctica un enfoque híbrido:

1. Primera iteración: Análisis cualitativo de alto nivel de todos los activos. Identificar los activos y riesgos más críticos.
2. Segunda iteración: Para los activos críticos identificados, realizar un análisis más profundo (posiblemente cuantitativo si se dispone de datos).
3. Monitorización continua: Revisar y actualizar el análisis periódicamente, refinando las valoraciones con datos reales de incidentes.

Este enfoque combina lo mejor de ambos mundos: rapidez inicial del cualitativo + precisión del cuantitativo donde realmente importa.

10.5. Técnicas de apoyo

La Guía de Técnicas de MAGERIT incluye técnicas específicas de análisis, análisis mediante tablas, métodos algorítmicos, árboles de ataque y técnicas generales. Entre las técnicas de recogida y consenso son útiles las entrevistas, cuestionarios, sesiones de trabajo, Delphi y comparación por pares. Para representar escenarios se emplean tablas de activos-amenazas, árboles de ataque, diagramas de dependencias y matrices.

El análisis cuantitativo puede utilizar pérdida anual esperada cuando existen estimaciones monetarias y frecuencias fiables. Si una pérdida por evento se representa como SLE y la tasa anual de ocurrencia como ARO, una formulación habitual es ALE = SLE × ARO. Esta métrica facilita comparaciones económicas, pero no captura por sí sola daños asistenciales, legales o reputacionales y depende de la calidad de los datos.

El análisis de sensibilidad modifica supuestos para comprobar qué variables dominan el resultado. Si pequeños cambios alteran radicalmente la prioridad, la decisión debe tratarse con cautela. Las simulaciones probabilísticas pueden ser útiles en modelos maduros, pero no compensan una mala definición de activos o escenarios.

11. EL PLAN DE SEGURIDAD

11.1. Qué es el Plan de Seguridad?

El Plan de Seguridad es el documento resultante del análisis de riesgos. Recoge:

• Los riesgos identificados
• Las decisiones de tratamiento de cada riesgo
• Las salvaguardas a implementar
• El calendario de implantación
• Los responsables de cada acción
• Los recursos necesarios (presupuesto, personal)
• El riesgo residual aceptado

El ENS (RD 311/2022, Anexo II) establece que todos los sistemas categorizados como MEDIO o ALTO deben tener un Plan de Seguridad formal, aprobado por el Responsable de Seguridad de la Información (RSI) y por el responsable del sistema.

11.2. Contenido Mínimo del Plan de Seguridad según el ENS

El Anexo II del ENS especifica qué debe contener como mínimo un Plan de Seguridad:

1. Descripción del sistema:
   • Identificación del sistema de información
   • Responsable del sistema
   • Descripción funcional (qué hace el sistema)
   • Entorno operacional (dónde opera, usuarios, ubicación…)
   • Categorización del sistema (BÁSICO/MEDIO/ALTO)
2. Análisis de riesgos:
   • Metodología utilizada (habitualmente MAGERIT)
   • Activos identificados y su valoración
   • Amenazas identificadas y su probabilidad
   • Impactos potenciales
   • Riesgos calculados (intrínseco y residual)
3. Evaluación del estado de seguridad:
   • Salvaguardas ya implementadas (estado actual)
   • Nivel de madurez de cada salvaguarda
   • Gaps (brechas) respecto a lo requerido por el ENS
4. Plan de mejora de la seguridad:
   • Listado de salvaguardas a implementar
   • Priorización (basada en el riesgo)
   • Calendario de implantación (hitos, plazos)
   • Responsables de cada acción
   • Recursos necesarios (presupuesto estimado)
5. Declaración de aplicabilidad:
   • Tabla con todas las medidas del Anexo II ENS
   • Para cada medida: Aplicable Sí/No, Estado de implementación, Justificación si no aplica
6. Riesgo residual:
   • Identificación del riesgo que permanece tras aplicar las salvaguardas
   • Aceptación formal del riesgo residual por el responsable del sistema

11.3. Ciclo de Vida del Plan de Seguridad

El Plan de Seguridad NO es un documento estático. Sigue un ciclo de vida continuo:

11.4. Periodicidad de Revisión del Plan de Seguridad

El ENS establece que el Plan de Seguridad debe revisarse:

• Anualmente: Revisión ordinaria para verificar avances, actualizar riesgos, ajustar calendario.
• Cuando haya cambios significativos:
  • Cambios en el sistema (nueva funcionalidad, migración cloud…)
  • Cambios en el entorno de amenazas (nuevas vulnerabilidades críticas)
  • Tras un incidente de seguridad grave
  • Cambios normativos (nueva ley, actualización ENS)

11.5. Las tareas PS.1, PS.2 y PS.3

MAGERIT identifica tres tareas: PS.1 identificación de proyectos de seguridad, PS.2 plan de ejecución y PS.3 ejecución. La primera traduce decisiones en programas; la segunda los ordena temporalmente y construye el cronograma; la tercera implanta salvaguardas, normas, procedimientos e indicadores, actualizando el modelo y el estado de riesgo.

La planificación puede organizarse en plan director, planes anuales y planes de proyecto. El plan director aporta perspectiva plurianual; el anual asigna recursos y prioridades; el proyecto detalla tareas, responsables, criterios de aceptación y transición a operación.

12. LA HERRAMIENTA PILAR

12.1. Concepto y variantes

PILAR es un conjunto de herramientas EAR, Entorno de Análisis de Riesgos, cuya función es analizar y gestionar los riesgos de un sistema de información siguiendo MAGERIT. Está desarrollada y financiada parcialmente por el Centro Criptológico Nacional y se actualiza periódicamente. El portal oficial distingue la versión íntegra PILAR, PILAR Basic, μPILAR y RMAT para personalización.

Dentro de la versión íntegra se ofrecen dos orientaciones principales. PILAR RM se dedica al análisis y la gestión de riesgos en confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad. PILAR BCM se orienta al análisis de impacto y continuidad de operaciones, incorporando la duración de las interrupciones, elementos de respaldo y planes de recuperación.

El portal oficial consultado en agosto de 2026 mostraba como última versión descargable PILAR 2025.1.2, publicada el 28 de marzo de 2025. Las versiones cambian, por lo que en un documento operativo debe verificarse siempre el portal antes de instalar o citar una release concreta.

12.2. Flujo de trabajo en PILAR

El flujo parte de la identificación y valoración de activos. Después se modelan dependencias para propagar el valor de los activos esenciales hacia los activos de soporte. Se asocian amenazas a los tipos de activos y se ajustan frecuencia y degradación conforme a la realidad observada. El sistema calcula impacto y riesgo potencial; posteriormente se identifican y valoran salvaguardas, se estima su madurez o grado de implantación y se obtiene el impacto y riesgo residual.

Activos y dependencias
        ↓
Valor por dimensiones
        ↓
Amenazas: frecuencia + degradación
        ↓
Impacto y riesgo potencial
        ↓
Salvaguardas y madurez
        ↓
Impacto y riesgo residual
        ↓
Plan de tratamiento y seguimiento

El núcleo de la herramienta no es una simple matriz de colores. Mantiene catálogos, asociaciones entre amenazas y activos, reglas de propagación, valoración de salvaguardas y distintos escenarios o etapas de tratamiento. Esto permite comparar el estado actual con estados objetivo y observar cómo cambia el riesgo cuando se implantan programas de seguridad.

12.3. Perfil de seguridad, ENS y declaración de aplicabilidad

PILAR incorpora módulos de cumplimiento ENS. Tras analizar las dimensiones y la categoría, puede ayudar a construir la evaluación de riesgos, la declaración de aplicabilidad y el perfil de cumplimiento. El perfil de seguridad expresa los umbrales o requisitos que debe alcanzar el sistema según su categorización y el marco aplicable; no inventaría activos ni asignaría responsables por sí mismo.

La declaración de aplicabilidad relaciona medidas, requisitos, estado de implantación, evidencias y justificaciones. No debe generarse de forma mecánica: el resultado necesita revisión por los responsables, coherencia con el análisis y correspondencia con la arquitectura real. Una medida marcada como implantada sin evidencia suficiente es un problema de gobierno, no un éxito de la herramienta.

12.4. Ventajas y límites

Entre sus ventajas están la homogeneidad del lenguaje, la reutilización de modelos, el cálculo automatizado, la gestión de dependencias, la comparación de escenarios y la generación de informes. Facilita que un análisis complejo sea mantenible y que las decisiones puedan revisarse. También reduce errores aritméticos y ayuda a documentar el razonamiento.

Sus límites son igualmente importantes. PILAR no conoce por sí sola el valor asistencial de un servicio, la tolerancia a una interrupción, las obligaciones contractuales ni la eficacia real de un procedimiento. Si las entradas son arbitrarias, el resultado también lo será. La herramienta no sustituye entrevistas, revisión de arquitectura, evidencias de operación, pruebas de continuidad ni aceptación por la dirección.

12.5. Uso responsable y mantenimiento del modelo

El modelo debe versionarse, limitar accesos y protegerse porque contiene información sensible sobre activos, dependencias, amenazas y debilidades. Conviene establecer un propietario, un calendario de revisión, un procedimiento de cambio y criterios para incorporar incidentes, vulnerabilidades y modificaciones de arquitectura. Los informes destinados a dirección pueden agregarse; los detalles técnicos deben distribuirse según necesidad de conocer.

13. APLICACIÓN EN EL SERVICIO ANDALUZ DE SALUD

13.1. Particularidades del entorno sanitario

La aplicación al Servicio Andaluz de Salud debe partir de la misión asistencial y de la organización real del sistema analizado. No basta con afirmar que los datos de salud son sensibles. Hay que identificar los servicios concretos, los procesos clínicos y administrativos soportados, los usuarios, las interconexiones, los proveedores, los centros afectados y las consecuencias de una degradación. Un mismo componente puede tener diferente criticidad según el servicio que soporte.

Los activos esenciales suelen ser la información y los servicios. Entre los primeros pueden encontrarse datos identificativos, episodios clínicos, prescripciones, resultados, imágenes, agendas, información de recursos humanos o económica. Entre los servicios, la consulta de información clínica, la prescripción, la citación, la integración con laboratorios, la atención al ciudadano o el soporte a profesionales. Los activos de soporte incluyen aplicaciones, bases de datos, identidad, redes, puestos, CPD, servicios cloud, personal y contratos.

13.2. Organización del análisis

El equipo debe combinar conocimiento funcional y técnico. Participan responsables de la información y del servicio, seguridad, sistemas, explotación, redes, desarrollo, protección de datos, continuidad, contratación y representantes de usuarios. En un sistema asistencial es imprescindible que los profesionales expliquen qué ocurre cuando un dato no está disponible, llega tarde o es incorrecto; los técnicos no pueden inferir por sí solos el impacto clínico.

El alcance debe incluir interconexiones y recursos externos. El ENS mantiene la responsabilidad de la organización aunque utilice servicios de terceros. Por ello, el análisis debe considerar ubicación y jurisdicción, subencargados, niveles de servicio, reversibilidad, portabilidad, gestión de incidentes, continuidad, borrado, evidencias de auditoría y cadena de suministro.

13.3. Caso didáctico: servicio de consulta de resultados

Supóngase un servicio que permite a profesionales autorizados consultar resultados diagnósticos. El activo esencial es la información de resultados y el servicio de consulta. Depende de la aplicación, API de integración, base de datos, sistema de identidad, red corporativa, monitorización, personal de soporte y proveedor de ciertos componentes. Esta dependencia permite comprender que una amenaza sobre el directorio de identidad puede afectar indirectamente al servicio clínico.

Se identifican amenazas como error de asociación, modificación no autorizada, indisponibilidad de la base de datos, fallo de integración, compromiso de credenciales, abuso de privilegios, malware, pérdida de comunicaciones o fallo del proveedor. Para cada una se estima degradación y frecuencia. Las salvaguardas pueden incluir autenticación robusta, mínimo privilegio, segregación, validación de mensajes, controles de integridad, alta disponibilidad, copias, monitorización, registro protegido, pruebas de restauración, procedimientos de contingencia y formación.

13.4. Riesgo de terceros y nube

La utilización de nube no está prohibida de forma general para datos de salud. Debe analizarse el servicio, la ubicación, las transferencias, el contrato, el ENS, las medidas técnicas y organizativas, la continuidad y los derechos de las personas. Que un centro de datos se ubique en otro Estado miembro del Espacio Económico Europeo no constituye por sí solo una transferencia a un tercer país, aunque siguen siendo necesarias las garantías del tratamiento.

13.5. Integración con proyectos y explotación

En nuevos proyectos, el análisis debe iniciarse antes de cerrar la arquitectura y los pliegos. Sus conclusiones alimentan requisitos no funcionales, criterios de aceptación, acuerdos de nivel de servicio, pruebas de seguridad, continuidad, reversibilidad y operación. En explotación, se integra con gestión de cambios, vulnerabilidades, incidentes, capacidad, configuración y continuidad. Un cambio significativo debe desencadenar una revisión del modelo, no limitarse a actualizar un inventario.

14. SEGUIMIENTO, REVISIÓN E IDEAS CLAVE

14.1. Del análisis a la decisión

El análisis solo aporta valor si conduce a decisiones claras. Cada riesgo relevante debe tener propietario, decisión de tratamiento, actuaciones, fecha objetivo, recursos, dependencia con otros proyectos y criterio de cierre. La dirección necesita conocer escenarios, tendencias y excepciones; los equipos técnicos necesitan detalles sobre activos, amenazas y salvaguardas. Los informes deben adaptarse a cada audiencia sin romper la trazabilidad.

14.2. Indicadores

Los indicadores pueden medir la ejecución del plan y la evolución del riesgo. Son ejemplos útiles el porcentaje de salvaguardas objetivo implantadas y verificadas, riesgos por encima del umbral, antigüedad de aceptaciones, cumplimiento de hitos, tiempo de corrección de vulnerabilidades críticas, resultados de pruebas de restauración, cobertura de registro, incidentes por escenario y desviaciones de los niveles de servicio. Un indicador debe tener definición, fuente, periodicidad, responsable y umbral.

No debe confundirse actividad con eficacia. Instalar una herramienta o impartir una formación acredita ejecución, pero no necesariamente reducción del riesgo. La eficacia exige comprobar si disminuye la frecuencia, la degradación o la exposición, y si el control funciona bajo condiciones reales.

14.3. Revisión por cambios e incidentes

Los incidentes proporcionan evidencia para recalibrar el modelo. Pueden revelar amenazas omitidas, frecuencias subestimadas, dependencias ocultas o salvaguardas menos eficaces de lo previsto. La revisión posterior debe actualizar datos, no buscar encajar el incidente en el modelo anterior. También deben incorporarse cambios de negocio, tecnología, proveedores, normativa y arquitectura.

14.4. Errores frecuentes

• Confundir vulnerabilidad con amenaza o riesgo.
• Valorar únicamente hardware y olvidar información y servicios esenciales.
• Asignar valores sin criterios comunes ni participación de los responsables.
• Usar una matriz de colores como sustituto del razonamiento.
• Considerar implantada una salvaguarda sin evidencia de eficacia.
• Aceptar riesgos por inacción, sin decisión formal ni fecha de revisión.
• Omitir proveedores, interconexiones y dependencias organizativas.
• No actualizar el análisis después de cambios o incidentes.

14.5. Ideas de repaso

Para el examen, memoriza la secuencia lógica: activos, dependencias y valor; amenazas, frecuencia y degradación; salvaguardas y eficacia; impacto y riesgo; tratamiento y riesgo residual; plan, ejecución y seguimiento. Recuerda las tareas MAR.1 a MAR.4, las tres tareas del plan de seguridad PS.1 a PS.3, los niveles de análisis de op.pl.1 y la función de PILAR como soporte, no como decisor.

15. MAPA CONCEPTUAL