Riesgo tecnológico y estimación de la probabilidad: enfoques alternativos

La siguiente fórmula, sobradamente conocida por muchos, es en la que se basan la mayor parte de los análisis de riesgos que se llevan a cabo en las empresas:

Riesgo (evento) = Probabilidad x Impacto

Esta fórmula define el riesgo asociado a un evento en función de la probabilidad de ocurrencia de dicho evento, y del impacto neg ativo(normalmente económico) para la organización.

En este artículo vamos a revisar la problemática a la hora de evaluar la probabilidad de ocurrencia de algunos escenarios de riesgo tecnológico y hablaremos de enfoques alternativos centrados en la vulnerabilidad, como el seguido por la metodología OWASP. Esperemos que sea de utilidad para todos aquellos involucrados en un análisis del riesgo de TI.

Para los responsables de un negocio suele ser relativamente sencillo determinar el impacto material que un incidente puede tener. Por otro lado, para muchos tipos de riesgos de negocio, se cuenta con estadísticas suficientes como para elaborar modelos matemáticos que ayuden a determinar la probabilidad de ocurrencia. Por ejemplo:

• Las aseguradoras disponen de profusas series históricas que les permiten estimar la probabilidad de ocurrencia de una gran variedad de siniestros, y valorar así de manera bastante precisa el nivel de riesgo que toman cuando deciden asegurar a un cliente: es fácil para estas empresas saber la probabilidad de fallecimiento por cáncer de un cliente en base al conocimiento de determinadas variables de sus hábitos de vida, edad, etc; la probabilidad de descarrilamiento de un tren,….

• Por su parte, los bancos suelen disponen de datos históricos suficientes como para determinar la probabilidad de impago de su cartera de préstamos y usan esta información para modular la política de riesgo de crédito que están dispuestos a asumir en cada momento.

Con independencia de que este modo de valoración del riesgo está basado en estadísticas derivadas de hechos ocurridos en el pasado y en la asunción de una serie de supuestos que pueden no cumplirse en el futuro tal cual esperan los analistas (esto se puso de manifiesto de manera muy clara con la llamada crisis de las hipotecas subprime en 2008); lo cierto es que en promedio, las organizaciones son capaces de estimar con bastante fiabilidad y validez el nivel de riesgo que asumen en cada momento, en lo que respecta al riesgo de crédito, del mercado o al de eventos del mundo físico.

Dificultades para la estimación del riesgo tecnológico

Sin embargo, cuando se trata de evaluar el riesgo tecnológico, los analistas encuentran muchas más dificultades en la aplicación de estos métodos:

• Porque la variedad de riesgos derivados del uso, operación o adopción de la tecnología es mucho más amplia y está en constante evolución.

• Porque no existen series de datos históricas fiables sobre incidentes que las organizaciones puedan usar. Las organizaciones suelen ser además reacias a publicar los datos de los incidentes que sufren para evitar que puedan dañar su imagen.

A pesar de esto, llama la atención que la forma más habitual de caracterizar la frecuencia de materialización de riesgos tecnológicos en las organizaciones use tablas como la siguiente (tomada de la metodología de análisis de riesgos tecnológicos MAGERIT del Ministerio de Administraciones Públicas del Gobierno Español):

28_tabla_01

Está claro que en la mayor parte de los casos, los analistas que usan estás metodologías hacen un ejercicio puramente subjetivo de atribución de probabilidades a posibles riesgos sobre cuya prevalencia no se tiene ninguna información objetiva. En estas circunstancias parecería que el analista juega a ser adivino (“el evento se producirá con una frecuencia de 2 veces al año”) sin ninguna base racional objetiva. Cuando los responsables de negocio son conscientes de esta situación, esto impacta negativamente en la credibilidad de los analistas de riesgos tecnológicos y en la propia metodología.

¿Podría usted decir con que probabilidad un hacker puede vulnerar la seguridad de su página web y robar datos de clientes de la base de datos?, ¿una vez cada 2 años?, ¿cada 10?…

Las organizaciones más maduras en este sentido hace tiempo que han comenzado a crear sus bases de datos de incidentes con el propósito de sentar las bases para un estimación más cuantitativa del riesgo; además, empieza a entreverse que la legislación de protección de datos y de ciberseguridad van a tender en el futuro a exigir a las organizaciones que hagan públicos detalles sobre los incidentes que les sucedan, lo que facilitará que a nivel sectorial puedan usarse estos datos. Sin embargo, hasta que se alcance un razonable grado de madurez, las estimaciones de riesgos tecnológicos deben buscar formas de superar estas debilidades metodológicas.

Enfoques alternativos

Para aquellos incidentes sobre los que no se dispone de información suficiente para determinar su frecuencia esperada, existen enfoques alternativos que se centran no tanto en la estimación de la frecuencia de ocurrencia del suceso, sino en la facilidad con la que la vulnerabilidad puede ser explotada; este es por ejemplo el enfoque que sigue el OWASP en su metodología de análisis o el del CVSS en su metodología de scoring de vulnerabilidades.

Desde esta perspectiva, el riesgo se manifiesta como consecuencia de que una agente explota una vulnerabilidad existente, siendo la consecuencia la ocurrencia de la pérdida. Lo importante aquí no es tanto conocer con precisión la frecuencia absoluta con la que se materializará el riesgo sino lo fácil o difícil que es que alguien pueda explotar dicha vulnerabilidad. Esto ayuda a priorizar de manera objetiva la implantación de medidas de control.

Por ejemplo,  la vulnerabilidad puede ser un fallo en una aplicación Web que, en caso de ser detectada y explotada por un hacker, podría tener como consecuencia que los datos confidenciales de la base de datos cayesen en manos del hacker. El riesgo para la organización propietaria de la aplicación  es que se produzcan pérdidas como consecuencia de sanciones a partir de las reclamaciones de los afectados y que la imagen de la compañía se vea afectada negativamente. Está claro que puede ser difícil estimar con qué frecuencia se producirá un incidente de este tipo; sin embargo, puede ser más fácil determinar la facilidad con la que alguien podría detectar y explotar la vulnerabilidad en caso de existir.

Estimación de la probabilidad con el OWASP Risk Rating Method

Personalmente, suelo usar una versión adaptada de la ya referida metodología del OWASP, la cual en mi opinión es muy intuitiva y fácil de emplear. Dicha metodología usa diferentes factores para estimar la probabilidad en que una determinada vulnerabilidad puede ser explotada:

Factores relacionados con los agentes que pueden explotar la vulnerabilidad

Factor Descripción Nivel (puntuación)
Nivel de habilidad técnica del colectivo de agentes ¿Cuál es el grado de conocimientos y habilidades técnicas que necesita el colectivo de agentes para poder explotar la vulnerabilidad?
  • Competentes Auditores de Seguridad (1)
  • Conocimientos de redes y programación (3)
  • Conocimientos avanzados de informática (4)
  • Conocimientos básicos de informática (6)
  • Ningún conocimiento de informática (9)
Motivación para explotar la vulnerabilidad ¿Cuál es la recompensa esperada que recibiría el colectivo de agentes en caso de explotar la vulnerabilidad?
  • Recompensa insignificante (1)
  • Recompensa posible moderada (4)
  • Recompensa cuantiosa (9)
Oportunidad para explotar la vulnerabilidad ¿Qué recursos y circunstancias debe tener a su alcance el colectivo para poder encontrar y explotar la vulnerabilidad?
  • Acceso total a la red y/o cuantiosos recursos (0)
  • Accesos y/o recursos especiales (4)
  • Pocos recursos y un nivel de acceso a la red limitado (7)
  • No necesario ni acceso a la red ni recursos (9)
Tamaño del colectivo de potenciales agentes ¿Es muy grande el colectivo de potenciales agentes que se espera pudieran explotar la vulnerabilidad?
  • Desarrolladores y/o administradores de sistemas de la organización (2)
  • Empleados usuarios de los sistemas corporativos (4)
  • Contratistas, socios comerciales, consultores con acceso limitado (5)
  • Usuarios registrados accediendo desde Internet (6)
  • Usuarios anónimos accediendo desde Internet (9)

Factores relacionados con la propia vulnerabilidad

Factor Descripción Niveles (valores)
Facilidad con la que la vulnerabilidad puede ser descubierta ¿Cómo de fácil  será para el colectivo de agentes descubrir la vulnerabilidad?
  • Prácticamente imposible (1)
  • Difícil (3)
  • Fácil (7)
  • Muy fácil (9)
Facilidad con la que la vulnerabilidad puede ser explotada ¿Cómo de fácil  será para el colectivo de agentes explotar la vulnerabilidad?
  • Muy difícil (1)
  • Difícil (3)
  • Fácil (5)
  • Trivial (9)
Grado de conocimiento de la vulnerabilidad entre los colectivos de agentes ¿Es conocida por el grupo de agentes la vulnerabilidad?
  • Desconocida (1)
  • Existe un conocimiento limitado sobre la vulnerabilidad (5)
  • Públicamente conocida (9)
Facilidad para detectar un ataque explotando la vulnerabilidad ¿Cómo de probable sería la detección de un intento de explotar la vulnerabilidad?
  • Muy poco probable, se necesitaría un sistema de detección muy complejo/sofisticado (9)
  • Posible, con personal dedicado a revisar eventos de sistema relacionados (8)
  • Muy probable con sistemas básicos de detección (3)
  • Casi segura por la propia operativa y la naturaleza de los eventos relacionados con el intento (1)

Cálculo del rating global de probabilidad y matriz de clasificación de riesgos

Una vez puntuados los factores para el agente y la propia vulnerabilidad, se calcula la media aritmética, sumando las puntuaciones obtenidas en cada factor y dividiendo por el número total de factores. El valor final obtenido se traduce en un rating global de acuerdo con la siguiente tabla:

28_tabla_02

A partir de este momento y una vez estimado el impacto (a la cual dedicaremos probablemente otro artículo) , ya es posible usar la tradicional matriz de clasificación de riesgos; por ejemplo:

28_tabla_03

De esta manera, como analistas de riesgos tecnológicos evitaremos tener que jugar a ser adivinos y seremos capaces de priorizar de manera bastante consistente y objetiva los riesgos que necesitan ser gestionados.

Esperemos que este breve artículo sea de utilidad, nos vemos pronto.

Deja un comentario