Análisis de riesgos

El análisis de riesgos es el procedimiento con el que se averigua qué puede pasarle a un sistema y cuánto daño haría. Todo él se apoya en cinco términos que hay que distinguir con precisión, porque las preguntas se construyen justamente intercambiándolos.

La relación entre los tres es de encaje, no de suma: una amenaza sin vulnerabilidad que aprovechar no llega a materializarse, y una vulnerabilidad sobre la que ninguna amenaza actúa no produce daño. Hay además dos matices que caen. Primero, la amenaza es externa al sistema y no se puede eliminar (no está en tu mano que deje de haber atacantes ni que deje de haber tormentas), mientras que la vulnerabilidad es propia del sistema y sí se puede corregir. Y segundo, las amenazas no son solo malintencionadas: un error humano, un fallo de un disco o una inundación son amenazas de pleno derecho.

La amenaza es el suceso y viene de fuera; la vulnerabilidad es la debilidad y está dentro. Sobre la amenaza no se actúa, sobre la vulnerabilidad sí.

El impacto es el daño que sufre un activo cuando la amenaza se materializa. Se valora sobre cada dimensión por separado, porque el mismo suceso puede ser gravísimo en una y trivial en otra: que se publique el listado de matrículas destroza la confidencialidad y no toca la disponibilidad.

Los activos, sin embargo, no están sueltos: dependen unos de otros. Un servicio se apoya en una aplicación, la aplicación en una base de datos, la base de datos en un servidor y el servidor en la instalación eléctrica de la sala. Esa cadena obliga a distinguir dos formas de mirar el impacto.

• Impacto acumulado: el que se calcula sobre un activo teniendo en cuenta, además de su propio valor, el de todos los activos que dependen de él. Un disco duro vale poco por sí mismo, pero si de él cuelga el servicio entero, su impacto acumulado es enorme.
• Impacto repercutido: el que llega a un activo superior por culpa de algo que ha fallado más abajo. Es la misma dependencia leída al revés, desde el servicio hacia el componente.

La utilidad de esta distinción es puramente práctica: el impacto acumulado es el que dice dónde conviene gastar el dinero en salvaguardas, porque señala los componentes de los que cuelga más cosa. El repercutido es el que se enseña a los responsables del servicio, porque habla en el idioma que a ellos les afecta.

El riesgo es la estimación del daño esperado, y sale de combinar dos factores: cuánto daño haría el suceso (el impacto) y con qué frecuencia se espera que ocurra (la probabilidad). Se escribe como una función de las dos variables, y no como una suma, porque cualquiera de ellas a cero anula el resultado: lo que no puede pasar no es un riesgo por mucho daño que hiciera, y lo que no hace daño no es un riesgo por mucho que pase.

De ahí sale la forma habitual de representarlo, un plano con la probabilidad en un eje y el impacto en el otro. La esquina donde ambas son altas es la que exige actuar de inmediato; la esquina opuesta, la que se puede asumir. Y en el medio quedan los dos casos interesantes que suelen decidirse mal: lo muy probable pero poco dañino, que se trata con automatismos, y lo muy dañino pero improbable, que es donde viven los planes de continuidad.

Contra el riesgo se aplican salvaguardas, que son las medidas previstas para evitarlo o reducirlo. Y como una salvaguarda casi nunca lo elimina del todo, hace falta nombrar los dos momentos de la medición.

El riesgo residual nunca es cero, y no se busca que lo sea: se busca que quede por debajo del umbral que la dirección ha declarado aceptable.

Analizar el riesgo es solo la mitad del trabajo. La otra mitad, la gestión, consiste en decidir qué se hace con cada uno de los riesgos identificados, y las opciones sobre la mesa son cuatro y solo cuatro. La decisión no es técnica: la toma la dirección, porque implica comprometer dinero o asumir un daño.

Aceptar un riesgo es una decisión legítima siempre que sea consciente, esté documentada y la firme quien tiene autoridad para hacerlo. Lo que no vale es la aceptación por omisión, que es lo que ocurre cuando nadie ha analizado nada: ahí el riesgo no está aceptado, simplemente está ignorado.

Y hay un límite económico que conviene tener presente: una salvaguarda que cuesta más que el daño que evita no es seguridad, es despilfarro. El análisis de riesgos existe precisamente para poder justificar ese cálculo delante de quien firma el presupuesto.

MAGERIT es la Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información, elaborada y publicada por la Administración General del Estado. Es la metodología de referencia del sector público español: describe el procedimiento entero, desde el inventario y la valoración de activos hasta la selección de salvaguardas, y aporta catálogos ya hechos de tipos de activo, de amenazas y de salvaguardas para no partir de cero.

Una metodología, sin embargo, no se aplica a mano sobre un sistema de cierto tamaño: hacen falta miles de valoraciones cruzadas entre activos, dimensiones y amenazas. Para eso está PILAR, la herramienta informática que automatiza MAGERIT y que distribuye el Centro Criptológico Nacional.

• PILAR: la versión completa, para el análisis y la gestión de riesgos de una organización.
• PILAR Basic: versión reducida, pensada para organizaciones pequeñas.
• microPILAR: versión ligera para análisis de alcance limitado.
• RMAT: herramienta de configuración, dirigida a consultores y a grandes organizaciones que necesitan adaptar los catálogos.
• EAR: el entorno de análisis de riesgos en el que se integra toda la familia.

La relación entre las dos piezas es la pregunta que más cae, y se responde en una frase: MAGERIT es el método y PILAR es el programa que lo ejecuta. Ni MAGERIT es una herramienta ni PILAR es una metodología.

MAGERIT, metodología de la Administración General del Estado. PILAR, herramienta del CCN que la implementa.

MAGERIT no es la única metodología de análisis de riesgos, y en el examen se preguntan las demás por su nombre, sin exigir su detalle. Basta con reconocer de dónde viene cada una.

Junto a ellas circula otra lista distinta que conviene no mezclar: la de los marcos de gobierno y buenas prácticas. No son metodologías de análisis de riesgos, sino formas de organizar el gobierno de las tecnologías o la prestación del servicio. Los que hay que reconocer son ISM3, COBIT, SOGP e ITIL.

Common Criteria es un esquema internacional de evaluación y certificación de la seguridad de productos de tecnologías de la información, normalizado como ISO/IEC 15408. Su objeto no es una organización ni un sistema en explotación, sino un PRODUCTO concreto: una tarjeta chip, un cortafuegos, un sistema operativo. Un laboratorio independiente comprueba que el producto hace lo que su fabricante declara y que lo hace con el rigor exigido.

El resultado de esa evaluación se expresa en un nivel de garantía, el EAL (Evaluation Assurance Level), que va del EAL1 al EAL7. La escala no mide cuánta seguridad tiene el producto, sino cuánta confianza merece la comprobación que se ha hecho de él: a más nivel, más documentación exigida, más formalidad en el diseño y más pruebas independientes. Por eso un producto sencillo con EAL5 puede ser más fiable que uno complejo con EAL2, pero no necesariamente más seguro para un uso dado.

En España el ejemplo característico es el documento nacional de identidad electrónico, cuyo chip se construyó y certificó bajo este esquema. Common Criteria surgió a mediados de los años noventa de la unificación de tres criterios anteriores que competían entre sí: el estadounidense TCSEC, conocido como el Libro Naranja, el europeo ITSEC y el canadiense CTCPEC.

Common Criteria certifica productos y da un nivel EAL de 1 a 7. La ISO/IEC 27001, en cambio, certifica el sistema de gestión de una organización. No se confunden: distinto objeto y distinto certificado.