La ortodoxia en la gestión de riesgos (I): el riesgo inherente
Los seres vivos somos expertos en gestionar riesgos. Es algo que hemos hecho a lo largo de millones de años. Se llama, entre otras cosas, instinto de supervivencia. No estaríamos aquí si se nos diera mal.
Los evitamos, los mitigamos, los externalizamos, los asumimos.
Por ejemplo, ¿va a llover hoy? Si llueve, ¿cuánto va a llover? ¿Me llevo el paraguas? ¿Me quedo en casa? ¿Me encontraré con un atasco de camino al trabajo? ¿Llegaré tarde a la reunión? ¿Llamo para avisar? ¿Intento posponer la reunión? ¿Pincharé una rueda de camino a casa? ¿Cuándo fue la última vez que revisé la rueda de repuesto? ¿He pagado la prima del seguro? ¿Cuál es la cobertura de asistencia en carretera?
Todos esos procesos cotidianos de identificación y valoración de riesgos los realizamos de manera inconsciente a diario, y aplicamos medidas de gestión del riesgo sin apenas darnos cuenta. Cogemos un paraguas, llamamos a la oficina para avisar del retraso, asistimos a la reunión por teléfono, salimos antes de casa o decidimos coger el transporte público. Evidentemente, no siempre es tan sencillo.
Sin embargo, cuando nos trasladamos al entorno corporativo, empezamos con la tolerancia al riesgo, los criterios de probabilidad, impacto y vulnerabilidad, los catálogos de amenazas (estándar), las estrategias, los registros de riesgo, el riesgo inherente, residual y proyectado, los ratios de mitigación. Y nos perdemos durante meses en conceptos, documentos y metodologías, alejándonos cada vez más de la realidad que tenemos que analizar y proteger.
La ortodoxia en la gestión de riesgos (de ciberseguridad)
A raíz de esto, hace ya unos meses, en plena pandemia, fui a topar con un interesante artículo que contraponía dos visiones muy diferentes de la gestión de riesgos, que venía a llamar RM1 vs RM2.
Básicamente, y citando directamente del artículo, RM1 estaría enfocado a la “gestión de riesgos para las partes interesadas externas (Consejo, auditores, reguladores, gobierno, agencias de calificación crediticia, compañías de seguros y bancos)“, mientras que RM2 sería la “gestión de riesgos para los responsables de la toma de decisiones dentro de la empresa“.
Algunas semanas o meses después, Román Ramírez publicaba una entrada en una línea similar, criticando la ortodoxia reinante en la gestión de riesgos de ciberseguridad y los problemas que esta generaba.
Ambos artículos enlazan con una percepción que vengo teniendo de un tiempo a esta parte, y es el valor reducido que en muchos casos aporta el análisis y gestión de riesgos (de ciberseguridad, en este caso) tal y como la conocemos y realizamos hoy en día. Aunque el análisis y gestión de riesgos es un ejercicio imprescindible, el enfoque actual necesita un cambio importante para que su práctica tenga un impacto significativo en las decisiones del negocio.
A lo largo de esta serie de entradas voy a analizar algunos problemas con los que me encuentro o me he encontrado en el pasado en este ámbito, aunque mucho me temo que no siempre habrá soluciones fáciles de aplicar. Tampoco esta serie trata de establecer ningún modelo, paradigma o metodología alternativa, sino apuntar a cuestiones que son susceptibles de mejora y que en algunos casos se mantienen a) porque siempre se ha hecho así o b) porque en la bibliografía teórica dice que debe hacerse así, aunque luego su aplicación a las situaciones reales sea compleja y aporte poco valor.
Así pues, vamos con ello.
El riesgo inherente
El concepto de riesgo inherente es uno de los primeros problemas con el que cualquiera que siga un enfoque clásico se encuentra a la hora de comenzar un análisis de riesgos. Según este modelo, tenemos el siguiente esquema:
Riesgo inherente o potencial -> [evaluación de controles existentes] -> riesgo residual -> [implementación de controles o mejora de los existentes] -> riesgo futuro o proyectado
Aunque ISO 31000 (sospechosamente) no define el concepto de riesgo inherente (y parece que ISO 27000:2018 tampoco lo hace), tradicionalmente se entiende el riesgo inherente como el riesgo al que está expuesto un activo en ausencia de controles, es decir, antes del proceso de gestión de riesgos.
La motivación del riesgo inherente es proporcionar al análisis de riesgos un punto de partida inicial que solo considere los sucesos exógenos al activo. Establecida de manera adecuada esta base objetiva, deberíamos ser capaces de medir el efecto que un determinado control de seguridad tiene en la reducción del riesgo, dotando así al modelo de solidez metodológica. El problema es que sobre el papel esto tiene todo el sentido, pero su aplicación a la realidad no es tan sencilla y trae infinidad de cuestiones.
El problema detrás del concepto de control
El primero de ellos, que roza lo metafísico, se encuentra en el concepto de control. Si partimos de la definición de control de ISO 27000:2018, “una medida que modifica el riesgo“, podemos entender que algunos activos tienen, por su propia naturaleza, controles que podemos considerar como inherentes.
Por ejemplo, un datacenter tendrá una puerta de acceso, un edificio tendrá el cableado por el techo o el suelo técnico, y un sistema operativo tendrá un sistema de control de acceso lógico, por rudimentario que sea. Sin embargo, el planteamiento del riesgo inherente nos obliga no solo a ignorar todos esos controles (porque son medidas que modifican el riesgo), sino también a homogeneizar los activos y alejarnos de la realidad.
En el mundo del riesgo inherente, estrictamente, el servidor con fuentes de alimentación redundantes, RAID5 alojado en un CPD con climatización y medidas antiincendios ya no es más seguro que el portátil de 2015 que el equipo de marketing lleva de aquí para allá para sus presentaciones (no me quiero anticipar a futuras entradas, pero la identificación y evaluación de controles a nivel de activo es otra de las asunciones que nos gusta aplicar sin pensar demasiado en sus implicaciones).
¿Qué es un activo sin controles de seguridad?
Si conseguimos evadirnos de esa idea de control inherente al activo y tratamos de situarnos mentalmente en ese mundo de pesadilla imaginario donde ningún activo tiene ningún control de seguridad implementado y los activos de la misma naturaleza son todos igual de inseguros, nos daremos cuenta de lo difícil que es concebir un activo sin controles de seguridad.
Pensemos en un servidor web de comercio electrónico. Tal ejercicio mental supondría eliminar el parcheado, las copias de seguridad, el firewall y todos los controles perimetrales de red, el control de accesos al sistema operativo, la seguridad física, la seguridad del cableado, los procedimientos y procesos de operación, la gestión de vulnerabilidades y protección ante malware, la política de contraseñas, el cifrado de la información en tránsito, y así hasta eliminar todos los controles.
El resultado es aterrador, aunque cuesta imaginar algo así.
Ahora bien, aún tenemos algunas decisiones que tomar que tienen un impacto directo en nuestros niveles de probabilidad e impacto inherentes. ¿Ubicamos el servidor en la calle o en la recepción del edificio? ¿Qué cantidad de fallos de programación introducimos en el diseño y el código? ¿Asumimos que no cumple con absolutamente ninguna regulación legal? ¿Que es fácilmente vulnerable al conjunto completo de OWASP Top 10, o solo a algunos de ellos? ¿Que las actualizaciones se hacen a cualquier hora sin ningún tipo de planificación?
Probabilidad e impacto inherente
Llegados a este punto, si conseguimos realmente imaginar tal activo, nos daremos cuenta de que estamos ya bastante alejados de cualquier realidad conocida, desde la que debemos valorar la probabilidad y el impacto de una hipotética materialización de una amenaza sobre un activo que no se parece a nada que tengamos en nuestra organización.
Y al hacerlo, nos daremos cuenta de que ambos se sitúan, en la gran mayoría de casos, en valores muy elevados. De hecho, a menudo en valores que no tienen cabida en la escala que utilizaremos posteriormente en el cálculo del riesgo residual. Por ejemplo, en ausencia de controles, más de una amenaza tendrá una frecuencia diaria, o incluso superior. Esa frecuencia la tendremos difícilmente en nuestra escala de criterios de probabilidad residual.
En cualquier caso, quizá hayamos sido capaz de pasar por alto todo lo dicho y grosso modo, valorar cualitativamente la probabilidad y el impacto. Sin embargo, no podemos obviar que lo hemos hecho asumiendo unas circunstancias y condiciones que hacen que esa valoración sea, cuanto menos, poco fiable. No solo por todas las implicaciones de evaluar un activo sin controles, sino porque carecemos de datos o métricas que nos proporcionen un “suelo” en el que basarnos.
Y sin embargo, ese es nuestro punto de entrada al siguiente paso, el cálculo del riesgo residual.
La distancia con los gestores o propietarios del riesgo
Uno de los últimos problemas (al menos, en esta entrada) que presenta el análisis del riesgo inherente, y que enlaza con el “suelo” que comentaba en el anterior punto, es la incapacidad de establecer una conversación productiva en los términos que establece el riesgo inherente.
Cualquier persona de TI o del negocio será capaz de señalar sin demasiados problemas un puñado de riesgos que le preocupan (exista o no un registro de riesgos) e incluso podrá dar una valoración aproximada de cuál es su probabilidad e impacto, en términos de lenguaje natural, impacto económico, frecuencia histórica o esperada, etc. Esas valoraciones serán más o menos objetivas, pero son riesgos reales.
Sin embargo, si se les pregunta por los riesgos en ausencia de controles, más de uno levante una ceja y mire con desconfianza, como diciendo “cómo quieres que sepa yo eso y qué importancia tiene“.
La cuestión es que el ejercicio de calcular el riesgo inherente se aleja del funcionamiento normal de las organizaciones, y supone que podemos evaluar adecuadamente el impacto y la probabilidad de una situación hipotética sobre unos activos hipotéticos que, en realidad, a ningún gestor le preocupa, todo ello para dotar de una formalidad objetiva en un proceso con un alto componente subjetivo.
La solución
La solución más inmediata a este problema es prescindir del concepto de riesgo inherente y trabajar directamente con el nivel de riesgo residual, teniendo en cuenta que el riesgo inherente y el residual son simplemente dos momentos en el tiempo del mismo proceso de análisis. En cierto modo, es como si al valorar el riesgo inherente nos pusiéramos en el inicio de los tiempos para el activo en cuestión, y poco a poco avanzáramos viendo cómo se despliegan controles, hasta llegar al presente y a nuestro riesgo residual (que es, insisto, el que nos interesa). Un poco como esos vídeos que comienzan hacen millones de años y a cámara rápida nos traen hasta el día de hoy.
Es importante señalar que el riesgo inherente no determina el catálogo de amenazas al que está expuesta la organización, sino únicamente en qué medida cada uno de esos riesgos debe preocuparnos y por tanto cuántos controles debemos implementar como respuesta. El catálogo de amenazas debe obtenerse en una fase previa a partir del análisis del contexto interno y externo de la organización.
Sin embargo, no podemos obviar que el cálculo del riesgo inherente, a pesar de todos los problemas indicados, puede en teoría permitir identificar controles clave implementados, o dicho de otra forma, qué controles son más efectivos en la reducción del riesgo. Aunque dicha opción existe, en un proceso de valoración cualitativo con el grado de incertidumbre expuesto, es complicado establecer hasta qué punto es factible o útil realizar ese ejercicio.
En este sentido, la metodología FAIR le da la vuelta al concepto y define el riesgo inherente como “la cantidad de riesgo que existe cuando fallan los controles clave“. De este modo, en lugar de definir el riesgo residual a partir del inherente, establece el riesgo residual directamente valorando el conjunto de controles existente (aquí reside el -falso- problema, en realidad, que da pie a la existencia del riesgo inherente), y permite obtener escenarios concretos de riesgo inherente “parcial” en los que uno o más controles fallan. Sin conocer en profundidad la metodología ni haberla aplicado en la práctica, me resulta difícil afirmar hasta qué punto es válida esta aproximación, pero suena bien.
Pero yo quiero mi riesgo inherente
Dicho todo esto, puede darse el caso de que necesitemos calcular el riesgo inherente, por requerimientos de auditoría, metodología interna de la organización, demanda del departamento de riesgos, coherencia con análisis previos, etc.
En tal caso, tenemos dos opciones principales.
Si no necesitamos enlazar el riesgo inherente y el residual de manera explícita, podemos hacer una valoración del riesgo inherente inicial, otra residual, y argumentar a alto nivel cómo llegamos al riesgo residual desde el inherente. No es la mejor opción, pero en realidad lo que no tenemos que perder de vista que lo que queremos controlar es el riesgo residual.
Si necesitamos enlazar ambos de manera explícita, podemos hacerlo mediante coeficientes de mitigación asociados a niveles de madurez de los controles implementados, preferiblemente mapeados sobre un estándar. Es decir, calcularemos el riesgo residual aplicando porcentajes de reducción de la probabilidad, impacto o ambos, a cada riesgo, los cuales se derivan del nivel de madurez que hayamos determinado. Esto, como veremos en otro post, introduce un factor de variabilidad adicional, pero es una de las alternativas factibles.
En este caso, para reducir el impacto de la incertidumbre que introduce el riesgo inherente, y teniendo en caso que en la práctica totalidad de las amenazas el impacto y la probabilidad inherentes serán altos, descargaremos el proceso de obtención del riesgo residual sobre los coeficientes derivados de la madurez de los controles.
Hasta aquí, la primera entrada de la serie, en la que hemos analizado la problemática detrás del concepto del riesgo inherente. En próximas entradas veremos otros aspectos que alejan el propio ejercicio de análisis y gestión del riesgo de la realidad que queremos analizar y proteger.
La entrada La ortodoxia en la gestión de riesgos (I): el riesgo inherente aparece primero en Security Art Work.
Powered by WPeMatico