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”.

Sandboxeando al Reader.

A inicios de este mes de octubre, Adobe nos dejó ver algunos detalles de lo que va a ser su tecnología sandbox que incorporará en una futura versión de Adobe Reader y que supone un avance en la protección contra las numerosas debilidades que son explotadas en cada nueva versión del Reader.

Una sandbox es una tecnología de seguridad que tiene como fin crear un ambiente virtual donde se ejecuta un programa para evitar en lo posible que se lleven a cabo acciones fuera de lo permitido. Es una “cajita de arena” para que los niños buenos y sobre todo los malos se empujen, se caigan y jueguen luchitas sin que se hagan demasiado daño ya que caerán sobre la suave arena y no podrán dañar el resto del kinder. Es una especie de caja de arena para confinar y limitar las acciones tanto de los “buenos” como de los “malos”.

En Adobe Reader esta funcionalidad también se le conocerá como “Protected Mode” y no sólo prohibirá ciertas acciones abusadas como la instalación, borrado o modificación en el sistema, sino que también “encerrará” al código malicioso que se quiera distribuir vía un archivo PDF sin mencionar que prevendrá la elevación de privilegios en el sistema del usuario.

El sandbox del Reader va a delimitar el “parseo” al leer el archivo PDF y limitará la nefasta característica para ejecutar JavaScript. Se implementará el concepto de un “intermediario” para los procesos que requieran salir del sandbox (así se implementa un control para que no cualquier proceso hijo de vecino haga lo que se le de la gana en el sistema). Finalmente, se incorporarán dos niveles de privilegio: el del usuario y el del PDF; así podremos bajar un archivo de Internet y éste se ejecutará en un contexto de muy bajos privilegios (restringidos) mientras que nosotros seguiremos trabajando con privilegios –normales- de usuario.

El concepto de sandbox no es nuevo. Uno de los más recientes en usarlo fue Chrome. También Java tiene el suyo, por decir unos ejemplos. ¿Es un sandbox “la neta”? No. Pero es un gran avance y para mí será un parte-aguas en lo que a la (in)seguridad que el Reader representa. No es secreto que la sandbox de Java tiene en sí misma debilidades que han sido explotadas en el pasado y por otro lado la seguridad de estas sandbox depende de la seguridad que pueda proveer el sistema operativo (nos quedamos indefensos si nos atacan el sistema operativo para “pagarle” al sandbox).

Más detalles técnicos los pueden encontrar en el blog de Adobe. Lo más importante a recordar es que estén al pendiente de cuando salga esa versión para que privilegien su instalación por la mejora ya expuesta (pueden suscribirse al RSS de seguridad de Adobe o seguir a @vupen que provee este tipo de información).

Sin olvidar que no deben de esperar a futuros sandbox, ya pueden sandboxear varios programas con por ejemplo SandboxIE, ya lo probaron?

StuxNet: Atacando el Mundo Real.

Salen tantos gusanos tan seguido que la mayoría no llegan a ser noticia fuera de algunos foros de seguridad, pero algunos llegan a los titulares por su peligrosidad. StuxNet es uno de ellos.

Hace unos cuatro meses, se descubrió la existencia de StuxNet, un gusano muy peculiar. Su objetivo no es tan “mundano” como el malware actual orientado a robar dinero de las víctimas. StuxNet quiere tomar control de sistemas Siemens tipo industrial llamados SCADA (Supervisory Control and Data Acquisition).

A mí antes de StuxNet no me decía nada eso de SCADA, así es que seamos más específicos. Todo apunta aparentemente a que el gusano StuxNet quería dañar plantas nucleares donde se usa SCADA. Más específico: la planta nuclear de Irán llamada Bushehr.

Ok. Ahora vayamos a unos cuantos detalles técnicos. El funcionamiento de StuxNet es complejo, tanto, que se ha manejado que un gobierno podría estar detrás de la creación de este gusano. Explotó en su momento tres debilidades de día cero de Windows (sin solución) y una debilidad zero-day del software SIMATIC de Siemens. Se propaga por ejemplo vía USB o recursos compartidos (network shares), contiene tecnología rootkit y usa certificados digitales -que al parecer fueron robados sólo para este propósito- para instalar sus propios drivers dentro de Windows. Tiene un tamaño de 1.5 MB, muy inusual para un gusano, lo cual –en este caso- significa que es altamente complejo.

StuxNet está diseñado para pegarle a sistemas industriales, por lo que se sospecha que el o los creadores del gusano saben manejar estos sistemas SCADA de Siemens y entienden su funcionamiento (por ejemplo aprovecharon una contraseña de SCADA que no se puede cambiar –hard coded-); de hecho es probable que hayan tenido acceso a un sistema industrial de “pruebas” donde hayan ensayado su “creación” para corregir posibles fallas o verificar el buen funcionamiento del bicho. Por otro lado, desgraciadamente, StuxNet también infecta equipos Windows de compañías y usuarios (esto último yo lo veo como un error del creador ya que un objetivo de este tipo de malware es permanecer en el anonimato); sin embargo no hay una aparente afectación (McAfee lo cataloga con criticidad Low) salvo que tu sistema estuviera controlando una planta nuclear.

Hay muchos más detalles técnicos en la red que no estaremos analizando aquí, como los de Symantec o el FAQ de FSecure, sin olvidar el de McAfee. Ya hasta hay video en YouTube donde se hace una pequeña demostración de las capacidades de StuxNet.

¿Qué significa StuxNet? Que tal vez no sea el primero de su tipo pero sí es el primero de su clase que se descubre y discute públicamente. Otra característica es que se aprovecha el software para “brincar” al mundo físico: un pedazo de código con el potencial de manipular los controles de una planta nuclear. No estamos hablando del robo del usuario/contraseña para entrar a la banca en línea ni de un Blaster que reinicia equipos; estamos hablando de plantas nucleares que por cierto se controlan con software (de Siemens u otros). ¿Sí ven la relación software-bug-gusano-planta nuclear?

No por nada la OTAN ha tomado recientemente cartas en el asunto: “Pero además de los ataques militares, Rasmussen menciona otras amenazas que podrían motivar la defensa en conjunto. Entre estas amenazas se habla de los ataques cibernéticos a los sistemas informáticos de los países miembro de la OTAN”.

StuxNet es un ejemplo de lo que se podría llegar a hacer. No sabemos de un impacto que de hecho haya logrado llevar a cabo (no se ha “volado” ninguna planta nuclear recientemente, cierto?), no sabemos quién lo creó ni quién es a ciencia cierta el objetivo de StuxNet; Siemens ha comentado que lo detectó en 15 clientes de SCADA y a nivel mundial se estima que 45,000 equipos Windows se infectaron (recordemos que estos últimos no son el objetivo de StuxNet).

Inclusive en algunos sitios se ha calificado a StuxNet como un arma. ¿Era el objetivo de StuxNet volar la planta nuclear de Irán? ¿Tenía otros objetivos? ¿Los cumplió? ¿Quién está detrás de StuxNet: EUA, Israel o algún país árabe tal vez? ¿Qué sucedió con la noticia de que arrestaron a algunas personas en Irán involucradas con StuxNet?

¿Es posible destruir una planta nuclear, dañar instalaciones eléctricas, manipular compuertas de una presa o impedir el flujo de agua potable con un malware programado para lograrlo? La respuesta es que es posible hacer todo lo que el software a cargo de estas plantas y sistemas de infraestructura puedan hacer. Si los sistemas de una planta nuclear no la pueden llevar al límite, tampoco lo podrá hacer un gusano (a menos, claro, que el gusano aprovechara un error o debilidad en el sistema de control que lo obligara a llevar a cabo acciones no previstas…pero bueno, dejémoslo hasta aquí).

Se cree que StuxNet empezó a operar desde el año pasado. ¿Cuántos otros malware de este tipo andan por ahí ahora o anduvieron antes de StuxNet? Lo que sí puedo decir es que veremos noticias de software bélico en el futuro que causará más que robo de dinero o inconveniencias. Desgraciadamente, esto no se ha acabado y a penas inicia dado que cada vez más software controla sistemas e infraestructura crítica y que –mucha de- la gente a cargo de ello no hace lo suficiente para controlar ese riesgo (se cree que StuxNet entró a la planta de Irán vía USB: ¿no pudieron prohibir estos dispositivos sabiendo que son un claro vector de ataque informático? ¿y si decidieron tener Windows, no lo pudieron endurecer? Por favor).