Ejemplo de Análisis de Riesgos

Introducción

Este post tiene como objetivo el explicar en detalle una metodología propia de análisis de riesgos. En el pasado he utilizado esta metodología con éxito en la realización de diversos análisis de riesgos de Seguridad de la Información. Aunque, obviamente, guarda similitudes y ha nacido a la luz de otras metodologías ampliamente utilizadas como Magerit o ISO31000, posee peculiaridades que posibilitan realizar análisis de riesgos rigurosos pero muy sencillos de comprender y ejecutar.

Empezemos explicando el escenario (ficticio) que utilizaremos como ejemplo para desarrollar el análisis de riesgos.

La empresa Mascultura es una libreria online. Se dedica exclusivamente a la venta de libros (físicos, no en formato digital) a través de su página web. No tiene stock de libros, si no que los adquiere directamente a un mayorista. Dado que su negocio se basa en la venta online, y por tanto en la información, ha decidido llevar a cabo un análisis de riesgos para tener claro qué riesgos tiene y qué puede hacer para disminuirlos.

Catálogo de Amenazas

Lo primero que vamos a hacer será elaborar el catálogo de amenazas a considerar. Para ello, lo que normalmente hago es partir de un catálogo amplio, como por ejemplo el que tiene Magerit y eliminar aquellos que no son relevantes en ese caso concreto. Además, suelo agrupar algunas amenazas similares para simplificar el proceso de analizar los riesgos. Hay que tener en cuenta que trabajar con un catálogo muy amplio, aunque permitirá un análisis más riguroso, también multiplicará los esfuerzos y el tiempo necesario para llevar a cabo dicho análisis. Mi recomendación es tratar de no sobrepasar las 10 amenazas en nuestro catálogo.

En el caso de Mascultura, para simplificar al máximo en análisis, estas son las amenazas que vamos a considerar:

• Desastres Naturales
• Errores de los usuarios
• Errores de los programadores
• Errores en la administración de los equipos
• Malware
• Ataques intencionados

Aunque agrupemos amenazas para reducir su número, es importante que todas las categórias de amenazas que realmente puedan afectar a la información del negocio estén recogidas en nuestro catálogo para que el análisis sea riguroso y no menospreciemos riesgos relevantes. Asimismo, para elaborar el catálogo se debería considerar en contexto en el que opera la organización, tanto interno como externo. Por ejemplo, según qué tipo de organización estemos analizando tendrá sentido o no hablar de fraude interno, robo de activos o desastres industriales como amenazas a considerar.

Siguiendo con nuestro ejemplo, ahora que tenemos nuestro catálogo de amenazas, vamos a darle un valor de probabilidad estándar para cada una de ellas. Este será el valor de probabilidad que consideraremos por defecto, aunque podrá verse modificado en cada activo en función de sus vulnerabilidades. Para evaluar la probabilidad (y el resto de valores evaluables) voy a utilizar una escala de 5 valores. En función del grado de detalle que queramos para nuestro análisis se podrían utilizar únicamente 3 valores, o irnos a un modelo de más valores (7, 10 o incluso más):

5- Extremadamente probable
4- Muy probable

3- Probable
2- Poco probable
1- Probabilidad prácticamente despreciable

Así, nuestro catálogo de amenazas quedará de la siguiente manera (entre paréntesis la dimensión o dimensiones a las que puede afectar la amenaza):

• Desastres Naturales (Disp): 1
• Errores de los usuarios (Conf, Int, Disp): 4
• Errores de los programadores (Conf, Int, Disp): 3
• Errores en la administración de los equipos (Conf, Int, Disp): 3
• Malware (Conf, Int, Disp): 5
• Ataques intencionados (Conf, Int, Disp): 4

Mapa de Procesos

Ahora que ya tenemos nuestro catálogo de amenazas definido, vamos a realizar el BIA (Business Impact Analysis). Para ello, si no disponemos ya de uno, necesitaremos el mapa de procesos de nuestra empresa.

Para simplificar el ejemplo, vamos a considerar que únicamente existen los siguientes procesos, aunque en cualquier empresa real existirían muchos más procesos transversales o de soporte. Asimismo vamos a identificar las aplicaciones que soportan cada proceso:

• Proceso de venta de libro a los clientes:
  • Aplicación web de venta de libros.
  • Mail corporativo para la atención al cliente/resolución de dudas.
  • Aplicación para la facturación al cliente. (se cobra únicamente con tarjeta de crédito)
• Proceso de compra de libros al mayorista:
  • Aplicación web de venta de libros (la aplicación envía un pedido directamente al mayorista utilizando el mail corporativo)
  • Mail corporativo
• Proceso de entrega del libro al cliente
  • Aplicación web de venta de libros (la aplicación envía un pedido a la empresa de mensajería indicando qué libro recoger en el mayorista y a qué dirección entregarlo).
  • Mail corporativo

BIA (Business Impact Analysis)

Procedamos ahora con nuestro Análisis de Impacto al Negocio. Para ello vamos a valorar el impacto que tendría un compromiso en la Confidencialidad, Integridad o Disponibilidad de la información asociada a cada uno de los procesos de negocio que acabamos de identificar. Esta valoración, además, considerará diferentes ámbitos en los que puede existir un impacto.

Algunos ejemplos de ámbitos posibles son:

• Económico
• Legislativo/regulatorio
• Operativo
• Ambiental
• Daño a las personas
• Daño a la imagen de la empresa o pérdida de confianza de sus clientes
• Etc..

En nuestro caso, como algunos ámbitos no son de aplicación (daño medioambienta, o daño a las personas), vamos a valorar únicamente los impactos en los siguientes ámbitos:

	Económico	Legislativo/ regulatorio
Muy Bajo	Menos de 500€	-
Bajo	Entre 500€ y 2500€	-
Medio	Entre 2500 y 7500€	Apercibimiento
Alto	Entre 7500 y 20000€	Multa o sanción
Muy Alto	Más de 20000€	Revocación de la licencia de comercialización.

La escala de valores que utilicemos deberá estar alineada con las cifras de negocio que maneje la organización que estamos analizando. Las cuantías establecidas en el ejemplo son considerando que se trata de una pequeña empresa para la que sufrir una pérdida de 20000€ sería una pérdida de gran impacto, mientras que para otras organizaciones, una pérdida de esta misma cuantía estará catalogada como un impacto muy bajo.

Analicemos por tanto el impacto para cada uno de los procesos de negocio:

Si analizamos la confidencialidad del proceso de venta a los clientes, podemos ver que un compromiso en la confidencialidad de la información del proceso tendrá un impacto económico muy alto, puesto que la aplicación trata con los datos personales de los clientes y las multas de LOPD en su rango más bajo pueden alcanzar los 40.000€. En lo que se refiere a impacto legislativo, estaríamos en un nivel Alto, puesto que se pueden dar multas o sanciones también de tipo LOPD.

Realizaremos un análisis similar para la Integridad y la Disponibilidad (en este caso valoraremos el impacto de que el proceso no funcione durante 1 hora, 1 día o 1 semana):

Proceso de venta a los clientes		Económico	Legislativo
Confidencialidad		Muy Alto (5)	Alto (4)
Integridad		Muy Alto (5)	Alto (4)
Disponibilidad	1 hora	Muy Bajo (1)	-
	1 día	Bajo (2)	-
	1 semana	Medio (3)	-

Finalmente, para cada una de las dimensiones nos quedamos con el impacto más alto de entre las categorías que estamos valorando. Nuestro BIA quedará de la siguiente guisa:

	Confidencialidad	Integridad	Disponibilidad
			1 hora	1 día	1 semana
Venta	5	5	1	2	3
Compra	1	5	0	0	1
Entrega	5	5	0	0	2

Nivel de Riesgo Tolerable

Una vez finalizado el BIA ya estamos en disposición de establecer cual es el nivel de riesgo tolerable para nuestra organización. Es decir, dónde vamos a establecer la linea que separará los riesgos aceptables de aquellos que requieran acciones urgentes para su resolución. Establece este umbral teniendo en cuenta que no desea aceptar riesgos que superen los 7.500€ o puedan suponerle multas o sanciones ni, por supuesto, la revocación de su licencia para vender libros online, es decir, que no se tolerarán riesgos con un valor de 4 o 5.

Inventario de activos y Mapa de Dependencias

Ahora que ya tenemos nuestro BIA finalizado y el umbral de riesgos definido, necesitamos disponer del inventario de activos y el mapa de dependencias antes de iniciar propiamente el análisis de riesgos.

Veamos nuestro inventario de activos (simplicado, ya que no vamos a considerar ubicaciones o personal):

Aplicaciones:

• Aplicación Venta de libros (APP_Venta)
• Mail corporativo (App_Mail)
• Aplicación de facturación (App_facturación)

Bases de datos:

• Base de datos de clientes (BD_clientes) (SQL Server)
• Base de datos con maestro de libros (BD_Maestro)(SQL Server)
• Base de datos histórico de operaciones (BD_Operaciones)(SQL Server)

Sistemas:

• Sistema A (Linux + Apache)
• Sistema B (Windows XP)
• Sistema C (Windows 2008 Server)

Las aplicaciones se ejecutan en el Sistema A, el Sistema B aloja el correo electrónico y el Sistema C tiene el SQL Server con las bases de datos identificadas.

Veamos ahora nuestro mapa de dependencias:

Proceso de VENTA -> App_venta -> Sistema A

                                    -> BD_clientes -> Sistema C

                                    -> BD_Maestro -> Sistema C

                                    -> App_Mail -> Sistema B

                                    -> App_facturación -> Sistema A

                                    -> BD_clientes -> Sistema C

Proceso de COMPRA -> App_venta -> Sistema A

                                        -> BD_Maestro -> Sistema C

                                        -> App_Mail -> Sistema B

Proceso de ENTREGA -> App_venta -> Sistema A

                                         -> BD_clientes -> Sistema C

                                         -> BD_Operaciones -> Sistema C

                                         -> App_Mail -> Sistema B

                                         -> App_facturación -> Sistema A

                                         -> BD_clientes -> Sistema C

Ahora vamos a hacer que los activos hereden la clasificación de impacto según este mapa de dependencias. El resultado de impactos que obtendremos será el siguiente:

	Confidencialidad	Integridad	Disponibilidad (1 día)
			1 hora	1 día	1 semana
Venta	5	5	1	2	3
Compra	1	5	0	0	1
Entrega	5	5	0	0	2
APP_Venta	5	5	1	2	3
APP_Mail	5	5	1	2	3
APP_Facturación	5	5	1	2	3
BD_Clientes	5	5	1	2	3
BD_Maestro	5	5	1	2	3
BD_Operaciones	5	5	0	0	2
Sistema A	5	5	1	2	3
Sistema B	5	5	1	2	3
Sistema C	5	5	1	2	3

El siguiente paso a realizar es coger cada uno de los activos de nuestro inventario (o tipología de activo si se quiere simplificar) y analizar si son o no vulnerables a cada una de las amenazas identificadas en nuestro catálogo:

	Aplicaciones	Bases de Datos	Sistemas
Desastres Naturales	No Vulnerable	No Vulnerable	Vulnerable
Errores usuarios	Vulnerable	No Vulnerable	No Vulnerable
Errores de los programadores	Vulnerable	No Vulnerable	No Vulnerable
Errores en la administración	No Vulnerable	Vulnerable	Vulnerable
Malware	No Vulnerable	No Vulnerable	Vulnerable
Ataques intencionados	Vulnerable	Vulnerable	Vulnerable

Vamos ahora a calcular el riesgo intrínseco que soportan los activos de nuestro inventario, es decir, el riesgo sin tener en cuenta los controles de seguridad que existen para disminuir el impacto o la probabilidad de los riesgos. Para no alargar en exceso este post, realizaremos el ejemplo sobre un único activo; el sistema A.

Para calcular el Riesgo usaremos la siguiente matriz en función del Impacto y la probabilidad. Esta matriz es una propuesta totalmente adaptable en función del tipo de negocio que se esté analizando, puesto que en determinados sectores, puede tener sentido dar un mayor peso al impacto que a la probabilidad con objeto de considerar los posibles 'cisnes negros'.

		Impacto
		5	4	3	2	1
Probabilidad	5	5	5	4	3	2
	4	5	4	4	3	2
	3	4	4	3	3	2
	2	3	3	3	2	1
	1	2	2	2	1	1

Veamos pues el riesgo inherente de nuestro 'Sistema A':

Sistema A – Riesgo inherente	Impacto	Probabilidad	Riesgo
Desastres Naturales	Disponibilidad: 2	1	1
Errores usuarios	No Vulnerable
Errores de los programadores	No Vulnerable
Errores en la administración	Confidencialidad: 5	3	4
	Integridad: 5
	Disponibilidad: 2
Malware	Confidencialidad: 5	5	5
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	4	5
	Integridad: 5
	Disponibilidad: 2

Por lo tanto, vemos que el riesgo inherente de nuestro Sistema A es muy Alto (5). Veamos ahora qué controles tiene implementados el sistema para calcular cual es su riesgo efectivo:

• Antivirus actualizado y con actualización diaria de firmas. (reduce considerablemente la probabilidad de la amenaza de malware).
• Alojado en red interna separado de la DMZ y de Internet mediante firewalls bien gestionados. (reduce la probabilidad de ataques intencionados).
• Se le realiza un análisis de vulnerabilidades anual, y aunque en el último mostraba vulnerabilidades, las más críticas ya están corregidas. (dado que es anual, se decide no bajar aún más la probabilidad de malware o ataques intencionados. Si el proceso fuera al menos trimestral con corrección de las vulnerabilidades en corto espacio de tiempo, se podría reducir aún más la probabilidad de estas amenazas).
• La organización dispone de un procedimiento de gestión de cambios sólido que reduce la probabilidad de errores de administración y también su impacto, puesto que siempre se cuenta con un procedimiento de 'marcha atrás'.

Por lo tanto, el riesgo efectivo de nuestro sistema será el siguiente:

Sistema A – Riesgo efectivo	Impacto	Probabilidad	Riesgo inherente	Riesgo Efectivo
Desastres Naturales	Disponibilidad: 2	1	1	1
Errores en la administración	Confidencialidad: 4	2	4	3
	Integridad: 4
	Disponibilidad: 2
Malware	Confidencialidad: 5	3	5	4
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	3	5	4

Plan de Tratamiento de Riesgos

Ahora que ya tenemos nuestro mapa de riesgos (inherentes y efectivos) para todos los activos o grupos de activos de nuestra organización, podemos proceder a elaborar el plan de tratamiento de riesgos. A tal fin, determinaremos acciones a realizar para aquellos riesgos que sobrepasen el umbral que hemos definido como tolerable en nuestra organización (4 en el caso de ejemplo).

Para cada uno de estos riesgos tendremos las siguientes alternativas:

• Evitarlo: Dejar de efectuar la actividad que origina el riesgo. En el caso de ejemplo, apagar el Sistema A, desconectarlo de la red y darlo de baja de nuestra organización.
• Asumirlo: Asumir que no se puede hacer nada para paliar este riesgo, y que por lo tanto la Organización prefiere mantenerlo. Esta estrategia puede ser válida cuando el activo está a punto de ser dado de baja o cuando las alternativas existentes para rebajar su nivel de riesgo son excesivamente costosas y podrían superar incluso el coste potencial de la materialización del riesgo.
• Transferirlo: En ocasiones, existen riesgos que pueden transferirse a terceras empresas mediante la contratación de un seguro o la externalización de determinados servicios.
• Mitigarlo: En la mayoría de los casos esta será la estrategia óptima. Consiste en establecer o mejorar los controles de seguridad del activo para reducir sus riesgos hasta niveles aceptables, bien por reducir la probabilidad de las amenazas o bien por reducir el impacto que estas tendrían en caso de materializarse.

En nuestro ejemplo, los riesgos a tratar son dos:

Sistema A	Impacto	Probabilidad	Riesgo inherente	Riesgo Efectivo
Malware	Confidencialidad: 5	3	5	4
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	3	5	4

Y el plan de tratamiento asociado en este caso, podría ser el siguiente:

• Aumentar la frecuencia de escaneos de vulnerabilidades en el equipo para realizarlos mensualmente.
• Adquirir el compromiso de resolver todas las vulnerabilidades que se detecten en el sistema en un plazo máximo de 2 meses.
• Hardenizar el servidor para eliminar todos aquellos servicios que no sean necesarios.

Lo ideal, a la hora de establecer el plan de tratamiento de riesgos será priorizar las acciones en función del riesgo que ayuden a mitigar y, siempre que sea posible, agruparlas en proyectos transversales que permitan mitigar los riesgos de toda una tipología de activos en lugar de abordarlos de manera individual en cada caso.

Tras analizar los efectos que estas medidas tendrán sobre los riesgos, establecemos cual será el riesgo residual, es decir, el riesgo efectivo que permanecerá una vez implantadas las medidas definidas:

Sistema A – Riesgo Redidual	Impacto	Probabilidad	Riesgo Efectivo	Riesgo Residual
Desastres Naturales	Disponibilidad: 2	1	1	1
Errores en la administración	Confidencialidad: 4	2	3	3
	Integridad: 4
	Disponibilidad: 2
Malware	Confidencialidad: 5	2	4	3
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	2	4	3

Espero que hayáis encontrado útil este post. Como siempre, si encontráis cualquier error en el mismo, queréis proponer cualquier mejora al respecto del tema tratado o simplemente queréis dejar un comentario opinando sobre el mismo, no dudéis en hacerlo!

Twitter: @omarbenjumea

http://about.me/omarbenjumea