Ni te Arriesgues.

¿Tenemos que hacer un análisis de riesgos? Yo más bien diría que debemos de pensar en hacer uno porque obtendremos un beneficio. ¿Por qué no todos tenemos uno? Respuestas: “tedioso”; “no le veo utilidad”; “falta tiempo”; “ni sé por dónde empezar”. ¿Y saben? No los culpo del todo.

De que existen metodologías de análisis de riesgos para la seguridad de la información, existen. Y varias. Magerit, CRAMM (CCTA Risk Analysis and Management Method), 27005 u OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation). Si ustedes siguen alguna de estas metodologías u otra similar, creo que pueden detenerse en este momento y dejar de leer, este post no es para ustedes.

Si no sigues ninguna, tendrás tus razones. Probablemente se te hace complicado, tedioso, consume-tiempo o hasta una pérdida de tiempo.

¿Qué te puedo decir? Para hacer un análisis de riesgos hay que invertir tiempo (y para seguir una metodología necesitarás mucho tiempo e inclusive probablemente dinero en forma de cursos, documentación o hasta honorarios de alguien –yo me apunto- que te “traduzca” lo que la bendita metodología quiere decir). Sin olvidar el hecho de que debes de mantener tu análisis actualizado (es decir, más tiempo). Y luego viene el trabajo posterior al análisis, porque ya que evaluaste tus riesgos, hay que hacer algo al respecto, no? Pero tiene un lado positivo.

El beneficio principal en general -en mi opinión- es que te “obligas” a pensar en las amenazas y vulnerabilidades de los activos; y eso ya es bueno aunque no hayas seguido “esas” dichosas metodologías. Y claro, asumo que posterior al análisis, le darás un tratamiento (es decir, algo harás con ese riesgo). En general, todo lo anterior sería administración del riesgo: analizar-actuar-medir-analizar-actuar, etc.

En fin, si crees que seguir una metodología es complicado y tedioso, te propongo explicarte de qué se trata esto del análisis de riesgos y que está bien hacer “atajos” (adaptaciones de una metodología). Existen maneras de hacer análisis de riesgos fáciles y ágiles que es mejor que no tener nada.

Si eres un purista y fiel seguidor de una o unas de las metodologías “serias” de análisis de riesgos, mejor ni sigas leyendo, me llenarás este post de críticas y malos comentarios porque cualquier cosa que no se apague a CRAMM, 27005 o Magerit te podrá parecer incorrecto.

Empecemos.

¿Qué quieres proteger? Tal vez sea el servicio de correo, la información que pones en tu página web, los registros de tus clientes que guardas en una base de datos o un proceso de facturación.

¿Cuáles son los activos? Es decir, qué cosas son importantes para que se lleve a cabo lo que quieres proteger? ¿Qué “cosas” están involucradas en ese servicio o proceso? Si es el servicio de correo, podría ser la base de datos del Exchange, el Exchange mismo (software), el sistema operativo donde está montado, el servidor (hardware) o hasta el personal que lo administra.

¿Cuáles son las amenazas? Algunas metodologías te dicen que listes tus vulnerabilidades y amenazas de tus activos. Atajo: puedes omitir las vulnerabilidades, asumo que si evalúas amenazas, implícitamente estás tomando en cuenta las vulnerabilidades, así es que basta listar esas amenazas (por ejemplo, el 27005 lista una serie de amenazas que te pueden dar una idea de las que podrías tomar en cuenta y evaluar; es como un checklist y vas viendo si te afectan o no). Supongamos que tu activo es la base de datos del correo. Las amenazas podrían ser que se la roben, que se corrompa, que falle el disco duro. Dale un valor a esa amenaza: “Alto-medio-bajo” o “3-2-1” o bien “Relevante-No relevante”. Asimismo, piensa y enlista si hay alguien (persona/organización) que quisiera hacerte daño y qué es capaz de hacer (sus capacidades); así puedes identificar más amenazas.

¿Cuál es el impacto y la frecuencia? Si se concreta esa amenaza tendrá un impacto, cierto? Y si esa amenaza se da con cierta frecuencia entonces hay que tomarla en cuenta. Para un análisis de riesgos no se puede entender el impacto sin su debida frecuencia. Por ejemplo, la llegada de un meteorito mata-todo sería de impacto alto, sin embargo la frecuencia es baja (no ha pasado desde la extinción de los dinosaurios). ¿Lo ven? El impacto puede ser muy alto pero si la frecuencia o probabilidad de ocurrencia es baja o despreciable, entonces no nos debemos de preocupar tanto o tal vez nada (en este ejemplo, mitigar el riesgo asociado a que un meteorito efectivamente caiga, traería un desbalance en el costo-beneficio por lo cual deberíamos aceptar el riesgo y no mitigarlo, o simplemente no considerar esa amenaza). Pero si el impacto es alto y sucede a cada rato, entonces hay que tomar una acción pronta y efectiva en caso de que no lo hayamos hecho ya. Al igual que la amenaza, dale un valor al impacto y otro a la frecuencia.

Ponlo en una licuadora. Si tomamos en cuenta las amenazas de los activos, sus impactos y frecuencia, obtendremos un riesgo. Tal vez tu riesgo más alto esté asociado a una falla del disco duro y la consecuente pérdida de tu base de datos. Hasta ahí ya tienes tu análisis de riesgos, es decir, tienes enlistados tus riesgos. Ahora tienes que hacer algo con ellos: mitigarlos (por ejemplo con un control administrativo o una aplicación), transferirlos (que un tercero tenga tu base de datos y se encargue de los riesgos), aceptarlos (se vale decidir que entiendes el riesgo pero que por el momento no puedes/quieres hacer algo al respecto) o eliminarlo (recuerden que para eliminar un riesgo se debe de eliminar el activo que lo genera, en este caso, tendríamos que eliminar la base de datos, lo cual es impráctico).

En fin, no traté de establecer una metodología de análisis de riesgos ni mucho menos, sino decirte que es mejor tener algo aunque sea supuestamente incompleto que no tener nada. El análisis de riesgos te obliga a pensar en escenarios de “qué tal si”; te obliga a enlistar amenazas y a evaluar sus impactos y posible frecuencia. Si haces eso ya habrás tomado un paso importante, creo yo. Y no tienes que hacerlo solo, entre más gente esté ayudándote se enriquecerá el análisis de riesgos. Por cierto, recuerda que el resultado del análisis de riesgos es tan bueno como el “input” que le des.

Si mi forma simplista de presentarte lo que es el análisis de riesgos te pareció muy chafa (dame chance, este sólo es un blog), no temas agarrar una metodología “seria” y quitarle todo lo que no consideres relevante; insisto, es mejor que nada. También puedes ver la propuesta del SANS que es bastante práctica, creo yo. Los caballeros templarios te dirán que si no sigues una metodología seria de “pe” a “pa” y 100% apegada entonces no sirve. Ni ellos ni yo tenemos la respuesta, la tienes tú. Así es que ni te arriesgues a no pensar en tus riesgos. Y ahí me dices cómo te fue.

Algunas frases de Bruce Schneier [Beyond Fear, 2003] ligadas al tema:

“Making large changes in response to rare events often doesn’t make sense”.

“An attack is a specific way to attempt to break the security of a system or a component of a system”.

“Many countermeasures are ineffective. Either they do not prevent adverse consequences from the intentional and unwarranted actions of people, or the trade-offs simply aren’t worth it”.