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:
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:
Proceso de entrega del libro al cliente
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:
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:
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
