Security Art Work

Los ataques de SQL-i siguen con nosotros. Por ejemplo, hace unos días un hacker hizo uso de esta técnica para obtener los contratos entre la compañía CEIEC y el Ministerio de Defensa chino.

Debido a su criticidad y efectividad, el peligro que suponen los ataques de Inyección de Código SQL ha ido creciendo frente a otro tipo de amenazas hasta situarse como la principal amenaza para las aplicaciones Web (en lucha encarnizada con los ataques Cross-Site Scriptings XSS).

El rápido crecimiento de la oferta de servicios a través de Internet ha generado un amplio abanico de aplicaciones que, en su mayoría, utilizan bases de datos para almacenar y proporcionar la información.
El riesgo inherente en este tipo de aplicaciones es que durante la entrada de datos por parte del usuario,se manipule la consulta legítima a la base de datos y se genere otro código manipulado, permitiendo acceder a información de la base de datos o eludir la autenticación. Pero como la mayoría de ustedes ya saben que son los SQL-i, vamos a pasar a lo que interesa: nuevas técnicas para prevenirlos.

Basándome en un paper que leí el otro día, voy a exponer algunas de las técnicas que están siendo objeto de estudio por parte de diversos investigadores y desarrolladores para defenderse de los temidos ataques SQL-i:

[Read more…]

Tras la primera parte que vimos el otro día, en esta entrada vamos a ver el uso de Security Manager y la correcta configuración del protocolo SSL sobre un Apache Tomcat.

Respecto al primero, vamos a configurar Security Manager para que restrinja el uso de ciertos métodos y clases que puedan implicar un riesgo para el servidor de aplicaciones. Estas restricciones se definen en el fichero catalina.policy. Para activar Security Manager será necesario añadir las siguientes dos entradas en el arranque de Tomcat:

-Djava.security.manager 
-Djava.security.policy=$CATALINA_BASE/conf/catalina.policy  

Nota: si se usa el script por defecto de arranque en vez de JSVC se debe añadir el tag -security, que realmente hace lo mismo: añadir las dos entradas anteriores.

Un ejemplo práctico de Security Manager sería una aplicación con un fallo de seguridad donde un posible atacante ha conseguido subir una Web Shell para intentar ejecutar órdenes en el servidor mediante el método Runtime.getRuntime().exec(). Al intentar ejecutar dicho método Security Manager impedirá su ejecución devolviendo la siguiente excepción:

java.security.AccessControlException: access denied

Donde sí se ha tratado adecuadamente la excepción, tal como se documento en la anterior entrada, únicamente se mostrara la página error.html cuando se intente ejecutar órdenes en el servidor mediante la Web Shell del atacante. Otro punto importante a tener en cuenta es la correcta configuración del registro de sucesos. Para ello se recomienda seguir los siguientes consejos:

• Aplicar una configuración adecuada para registrar la mayor información posible de los clientes que han realizado una solicitud a una aplicación del servidor Tomcat, añadiendo para ello la siguiente válvula al campo Host del fichero server.xml:

  <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    prefix="localhost_access." suffix=".log"
    resolveHosts="false"
    pattern="%t %h %H %m %s "%r" cookie:%{SESSIONID}c User- Agent:%{User-Agent}i " />
  

• Crear registros específicos para cada aplicación. Para realizar esta tarea es necesario especificar un fichero de logging.properties por cada aplicación desplegada en el directorio .../aplicacion/WEB-INF/clases/ donde aplicacion es el directorio de la aplicación. Dicho fichero tendrá la siguiente configuración:

  handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
  org.apache.juli.FileHandler.level = FINEST
  org.apache.juli.FileHandler.directory = ${catalina.base}/logs
  org.apache.juli.FileHandler.prefix = aplicacion.
  org.apache.juli.FileHandler.suffix = .log
  org.apache.juli.FileHandler.rotatable = true
  java.util.logging.ConsoleHandler.level = FINEST
  java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
  

• Emplear LOG4J para aquellas aplicaciones donde las librerías de registros por defectos de Tomcat no cumplan todos nuestros requisitos.

Para finalizar trataremos de configurar adecuadamente los conectores que empleen protocolos cifrados (conectores SSL) definidos en nuestro servidor de aplicaciones Tomcat siguiendo para ello los siguientes puntos:

• Forzar a los conectores que no cifran las comunicaciones a usar SSL mediante los siguientes pasos, llamado también redirección a conector SSL:

  1. En los conectores definidos en el fichero server.xml que no se empleen protocolo SSL se debe aplicar una redireccionan hacia un conector que emplee el puerto SSL:

  <Connector port="80" protocol="HTTP/1.1"
                  redirectPort="443"
  ...
  />
  <Connector port="443" protocol="HTTP/1.1"
                  scheme="https"
  ...
  />
  

2. Indicar que los métodos GET, POST y HEAD sean confidenciales añadiendo la siguiente entrada al fichero web.xml:

<web-app xmlns="http://java.sun.com/xml/ns/javaee" …>
...
    <security-constraint>
            <web-resource-collection>
                    <web-resource-name>Servidor Aplicaciones</web-resource-name>
                    <url-pattern>/*</url-pattern>
                    <http-method>GET</http-method>
                    <http-method>POST</http-method>
                    <http-method>HEAD</http-method>
           </web-resource-collection>
            <user-data-constraint>
                    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
            </user-data-constraint>
    </security-constraint>
</web-app>

• Impedir el uso de algoritmos y protocolos débiles. Para ello en la configuración de los conectores cifrados, definidos en el fichero server.xml, se deberá indicar que se desea usar TLS mediante la variable sslProtocol="TLS". Hay que tener en cuenta que el valor “TLS” en las últimas versiones de Tomcat identifica a la versión 1.1, y por tanto, acepta tanto TLS como SSL v3 pero no SSL versión 2, tal y como se especifica en la documentación del protocolo TLS v1.1.

  Será necesario definir que ciphers suite de los soportados por Java (ver enlace) se deben emplear. Estos presentan la siguiente forma:

  Proto_AlgClaveAsimetrica_WITH_AlgClaveSimetrica_tamClaveSim_AlgCompendio
  

Para esta restricción se pueden aplicar listas negras: aceptamos todos los algoritmos menos unos cuantos, como se recomienda en la entrada de SecurityByDefault, o se pueden aplicar listas blancas: solo permito los estrictamente indicados. Para gustos colores, pero en mi opinión prefiero aplicar listas blancas, es decir, indicar solo los que puedo usar.

En mi opinión, sin ser ni mucho menos un experto en algoritmos de cifrado, recomendaría usar TLS, algoritmos de curva elíptica o RSA como clave asimétrica, AES de 128 bits mínimo para clave simétrica y SHA como algoritmo de compendio:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

Por ello se definirán los cipher suite indicados con anterioridad en cada conector SSL creado en el fichero server.xml mediante la variable ciphers separados por comas:

<Connector port="443" protocol="HTTP/1.1"
scheme="https"
...
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA"
...
 />

Hay que tener en cuenta que para que pueda emplear algoritmos de curvas elípticas y algoritmos simétricos de más de 128 bits será necesario sustituir las librerías por defecto del Java JDK local_policy.jar y US_export_policy.jar por las suministradas en el paquete Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. Esto es debido a que por defecto el JDK está restringido a las leyes de EEUU donde no se permite más de 128 bits ni algoritmos de curva elíptica. Una vez sustituidas las librerías y reiniciado Tomcat ya se permitirá emplear dichos algoritmos, tal como se muestra a continuación:

$ openssl s_client -host localhost -port  443 -tls1 -cipher AES256-SHA
…
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
...

Con este par de pasos ya se dispondrá de un servidor Tomcat con una configuración de seguridad más o menos correcta ya que se han omitido una serie de configuraciones adicionales que se deberían aplicar para mejorar la seguridad del entorno, aspecto que queda fuera del contexto de esta entrada.

En el último post de esta serie comentábamos la problemática asociada a la cantidad y calidad de las alertas generadas al monitorizar entornos no cooperativos. Para corregir estos problemas debemos aplicar las mismas medidas que cuando monitorizamos entornos cooperativos, y esas medidas pasan, irremediablemente, por la correlación de las alertas generadas por los monitores que vamos desplegando día a día.

Como casi siempre suele suceder, hablar de correlación es muy sencillo pero hacerla de verdad no suele serlo. Para empezar, el primer gran escollo a superar es el motor de correlación: obviamente necesitamos “algo” capaz de correlar, “algo” a lo que decirle qué relaciones entre alertas pueden existir o ser más significativas -o “algo” capaz de aprenderlo por sí mismo, que ya sería el colmo :)-. Bien, pues esta obviedad que indicamos suele ser bastante compleja de implementar en la práctica; de hecho, llevamos años de correlación en PowerPoint pero aún hay muy pocos correladores decentes en el mercado. Existen algunos motores de correlación, pero suelen presentar dos graves problemas (ojo, generalizando, no siempre es así): su precio (aunque hay algunos proyectos abiertos que pueden dar buenos resultados) y, sobre todo, su complejidad, tanto para ponerlos en marcha como para mantenerlos en el tiempo. Como siempre, no voy a hablar de unos y otros aquí (y como siempre, menos aún de los de la competencia :), así que cada uno puede analizar un poco la gama de productos disponibles para correlar y elegir el que mejor se ajuste a sus necesidades…

Estos dos problemas a los que hacemos referencia están causando que con frecuencia la correlación de las alertas procedentes de entornos no cooperativos -como, en muchas ocasiones, también las de entornos cooperativos- no se realice en un motor global, sino que se acabe haciendo correlación en el agente de monitorización: incluimos en el propio monitor cierta inteligencia para que, por sí mismo, sea capaz de generar alertas de mayor valor (a priori) de las que generaría sin esa inteligencia adicional, lo que podemos denominar correlación en origen. Así, si por experiencia sé que cuando aparece un detonante en una red social a principios de mes con un cierto formato no pasa nada porque es la agencia de publicidad distribuyendo noticias, en el propio agente encargado de vigilar esa red social pongo una condición para que si detecto el detonante con el formato correspondiente y además es principio de mes, no se genere una alerta. ¿Y por qué sé esto? Porque conozco el entorno y me ha pasado muchas veces, y por tanto he sido capaz de aprender… Igual que sé que si se produce un pico de CPU o determinado ataque entre dos máquinas internas los martes por la noche no pasa nada ni debo preocuparme, porque es el programa de copias haciendo un backup, y por tanto pongo una excepción o una ventana de mantenimiento en mi sistema de monitorización…

La correlación en origen no tiene por qué ser negativa; todo lo contrario, puede resultarnos muy útil para evitar la saturación de un motor central, permitiéndonos enviar a ese motor sólo la información relevante de un determinado monitor, pero por sí misma presenta alguna limitación. Para empezar, la inteligencia que aportemos debe implantarse agente a agente, sin tener la posibilidad -en términos generales- de distribuirla a un grupo de monitores, ya que estamos hablando de reglas o condiciones muy particulares. Esto motiva un elevado coste de mantenimiento, que si siempre supone un problema lo es aún más en los tiempos que corren… Pero además de este problema de mantenimiento, que podemos arreglar “simplemente” con dinero, hay un problema adicional en la correlación en origen exclusiva que los euros no arreglan, y es la imposibilidad obvia de que podamos relacionar datos generados por diferentes sensores: sin un mecanismo centralizado tenemos que conformarnos con un nivel básico de correlación en origen que muchas veces se limita a excepciones, ventanas y poco más, y luego podemos invertir tiempo en tratar de establecer relaciones o patrones de forma manual, viendo las alertas que se han ido generando en nuestro SIEM. Viendo estos problemas, parece obvio que la correlación en origen molestar no molesta, pero creo que estaremos de acuerdo en que necesitamos ese “algo” capaz de centralizar las alertas recibidas y aplicarles, mejor o peor, cierta inteligencia… Así que lo dicho: analicemos un poco el mercado, elijamos el motor de correlación que mejor nos encaje, despleguémoslo y a jugar :)

Llegados hasta aquí, ya hemos superado (más o menos :) el primer problema que indicábamos, el del motor de correlación: tenemos una plataforma capaz de, con el conocimiento que un humano pueda aportarle, o con el que ella misma sea capaz de inferir, correlar de una u otra forma las alertas recibidas. Además, lo conocemos a la perfección desde el punto de vista técnico y hablamos su lenguaje, con lo que podemos empezar a “insultarle” definiendo reglas… En este punto debemos enfrentarnos a nuestro segundo gran reto: ¿qué inteligencia le proporcionamos al correlador? Quizás es ahora cuando empiezan los problemas de verdad… El introducir conocimiento válido en un correlador es sin duda la parte que más nos va a costar (por muy caro o difícil a la hora de usarlo que sea el motor). Debemos ser capaces de identificar nuestro conocimiento del entorno, plasmarlo en reglas de correlación y desplegar éstas sobre el motor; vayamos por partes:

El conocimiento, en el mejor de los casos, suele estar disperso entre los miembros del equipo de seguridad que han desplegado los sensores para monitorización de entornos no cooperativos y que suelen ser también quienes atienden las alertas generadas (al menos en nivel 2). Y digo en el mejor de los casos porque otras veces ni siquiera existe: ¿cómo sé, de entrada, que un detonante en un foro es bueno o es malo? Probablemente una persona deba acceder al foro, revisar el histórico de conversaciones y, en función de lo que lea ahí, decidir si está delante de un falso positivo o por el contrario es una alerta a considerar… Difícil de plasmar en reglas de correlación, ¿no? El conocimiento del entorno es algo que, como siempre, debe ir afinándose poco a poco. Empezaremos con unidades de conocimiento muy básicas: si el usuario que habla de nosotros en Twitter está en una lista determinada, no generes alerta; si el detonante es pastebineado genera alerta crítica sin correlar nada más; si aparece el detonante en una página focalizada en el negocio, genera una alerta para otro área… En fin, lo que -muchas veces de forma casi inconsciente- están haciendo las personas que atienden las alertas recibidas desde los monitores de entornos no cooperativos… Conforme vayamos identificando unidades de conocimiento básicas, iremos traduciéndolas del lenguaje natural al que hable nuestro motor y las desplegaremos en el mismo para empezar a generar eventos más inteligentes… y de verdad que las reglas sencillas acaban aportando mucha inteligencia y nos ahorran una cantidad de tiempo más que considerable…

Cuando tenemos un cierto número de reglas básicas ya nos podemos enfrentar al siguiente reto: la correlación compleja, la generación de alertas de orden superior en función de la correlación de datos provenientes de múltiples fuentes. Aquí es donde se demuestra el potencial de un correlador: la correlación simple podíamos hacerla, mejor o peor, y con más o menos coste de mantenimiento, en origen, pero para llegar a relacionar datos de fuentes diferentes ya necesitamos algo más elaborado: ese motor de correlación del que hablábamos antes…

Si la correlación compleja es compleja (valga la redundancia :) en entornos cooperativos, a los que conocemos habitualmente mejor y de los que podemos sacar toda la información que necesitemos, en entornos no cooperativos la cosa es mucho más complicada; ¿cómo sé yo que la aparición significativa de un detonante en N entornos a la vez, o simplemente con una relación temporal definida, es buena, mala o simplemente que existe? Realmente, sólo puedo hacerlo de una forma: conociendo el entorno (o aprendiéndolo, aunque como decía antes esto son palabras mayores) a través, casi siempre, de la experiencia adquirida. Seguramente debo empezar con reglas de correlación compleja relativamente sencillas, al igual que hacía con la correlación simple, reglas que con el tiempo y el conocimiento adquirido iré mejorando y haciendo cada vez más valiosas…

Poco a poco, gracias a las reglas de correlación simple y compleja que voy a ir definiendo y mejorando, iré creando una base de datos de conocimiento capaz de aportar cada vez más inteligencia a mis sistemas de monitorización de entornos no cooperativos; llegados a este punto, nos queda ir ampliando el catálogo de entornos monitorizados, mejorar nuestras reglas y, en este caso especial, cruzar los dedos para que la fuente de datos no sufra cambios significativos que afecten a mi monitorización. Recordemos que estamos vigilando elementos fuera de nuestro control, con lo que en cualquier momento pueden desde cambiar el formato de emisión de información (con lo que nos tocaría cambiar nuestros elementos de adquisición de datos) hasta restringir su acceso de alguna forma o, simplemente, desaparecer. Ojo al control de errores en los monitores: no seríamos los primeros -ni los últimos probablemente- que creemos tener perfectamente monitorizada una fuente concreta y de repente nos damos cuenta, por un factor externo casi siempre negativo, de que no es así…. Validemos correctamente la información recibida para darla por buena en forma y tengamos especial consideración con los datos nulos o sencillamente con la ausencia de datos de un monitor que debería estar enviando…

Y si todo va bien… ¿ahora qué? Pues me queda, básicamente, dar valor a mi vigilancia: ser capaz de generar alerta temprana. Material para el próximo post de la serie :)

A raíz de la entrada de Guillermo Mir sobre el bastionado de Apache (parte I y parte II) y una entrada en el blog SecurityByDefault sobre cómo trabajar con SSL en Tomcat me he decidido a escribir una entrada sobre el bastionado de Tomcat que debía desde hace mucho tiempo a Manolo, quien no se olvidaba de recordármelo (N.d.E. como es mi obligación…).

En primer lugar indicar que la entrada se centrará en un correcto bastionado de Tomcat sobre un entorno Linux, puesto que sinceramente Tomcat en Windows no ofrece las mismas opciones, por muy Java que sea, que en un entorno Linux. Como documentar una guía de bastionado de Tomcat ocuparía muchas páginas, esta y la siguiente entrada tratará los principales puntos a tener en cuenta durante un bastionado adecuado. Para más información os remito a la documentación de Tomcat.

[Read more…]

Como ya vimos en el anterior post, lo primero que deberíamos hacer al instalar un apache es ocultar cierta información que podría ser usada para ponérselo más fácil a algún malintencionado para que nos ataque. Como bien se dijo en los comentarios, esto no proporciona seguridad en si mismo, si no que dificulta (un poco) un posible ataque.

Otro factor que creemos que debería tenerse en cuenta, sin entrar todavía en la protección activa, es el de ajustar la configuración según el uso se va a dar a la aplicación web que apache va a servir. Pasemos a describir los métodos mas esenciales que debemos tener en cuenta.

Segundo paso: Activa lo justo y necesario

Lo primero que se podría realizar, para asegurar que cada directorio tenga activado únicamente lo que se necesite, es desactivar las Options y “overrides” para el servidor, teniendo que ir activando una a una, de manera explícita, las que necesitemos. Supongamos que tenemos una aplicación en www, entonces podríamos hacer algo así:

<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>

<Directory /www>
Order Allow,Deny
Allow from all
</Directory>

Por otro lado, una de las recomendaciones más comunes a la hora de configurar apache es la de evitar que éste tenga la posibilidad de seguir enlaces simbólicos. Esto se hace para evitar que un enlace simbólico malicioso pueda acceder a archivos fuera de la estructura de directorios, con el consecuente riesgo de que estos sean manipulados o destruidos. Para evitar esto, debemos marcar la directiva FollowSymLinks con un “-” en el directorio especificado.

<Directory>
...
Options –FollowSymLinks
...
</Directory>

En el caso que se necesite que se puedan seguir enlaces simbólicos, puede usarse SymLinksIfOwnerMatch, que sirve para que el servidor siga los enlaces simbólicos siempre y cuando los ficheros o directorios finales pertenezcan al mismo usuario que el propio enlace.

Es importante desactivar la opción de ejecución de CGI en todos los directorios de la web, salvo en uno concreto destinado a alojar todos los ejecutables. De esta forma se minimiza la posibilidad de que un atacante ejecute código de forma aleatoria. Lo desactivamos de la misma forma que los enlaces simbólicos.

<Directory>
...
Options -ExecCGI
...
</Directory>

En muchos casos la configuración para un directorio en concreto está en el archivo .htaccess. Las siguientes directivas evitan, mediante el uso de una expresión regular, que se puedan descargar los archivos que empiezan por “.ht”:

AccessFileName .httpdoverride
<Files ~ “^\.ht”>
Order allow,deny
Deny from all
Satisfy All
</Files>

Por supuesto, no actives módulos innecesarios, y desactiva aquellos que no vayas a usar.

Otro factor que podemos tener en cuenta es controlar desde dónde se va a consultar la aplicación web. Si el objetivo es que sólo se consulte desde una intranet conocida, o desde una única IP, esto se puede configurar de la siguiente forma:

<Directory>
...
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/16
...
</Directory>

para una red, o:

<Directory>
...
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
...
</Directory>

para una única IP.

En las siguientes entregas hablaremos un poco más de que parámetros se pueden usar para ayudar un poco más en la defensa e instalaremos algunos módulos exclusivos para defendernos de varios tipos de ataque.

Durante años he ido a muchos saraos, a muchos congresos, congresillos, jornadas o como les queramos o podamos llamar, donde nos reunimos para hablar de seguridad y tomar un café. Comerciales o no comerciales, mejores o peores, generalistas o muy específicos… en todos ellos, en todos, siempre he aprendido algo (bueno o malo). Y un “algo” que siempre me ha llamado mucho la atención son las cosas que, presentación tras presentación, mesa redonda tras mesa redonda, café tras café… se van repitiendo de unos a otros: los típicos tópicos de la seguridad; cosas que siempre aparecen por mucho que intentemos evitarlas: desde simples errores hasta ejemplos que alguien puso hace veinte años y hoy en día seguimos repitiendo como loros sin aportar nada nuevo sobre los mismos, pasando por frases que siempre acaban diciéndose, con o sin razón, pero siempre…

Aquí he recopilado algunas de las cosas que oigo y vuelvo a oir y cada vez que las dicen anoto mentalmente “tengo que escribir un post”, aunque luego no lo haga (hasta hoy). Vamos, seguro que todos hemos oído muchos de estos e incluso hasta los hemos soltado en alguna ocasión -ojo, yo el primero-; y seguro que seguiremos haciéndolo, no digais que no :) Pongo algunos típicos tópicos en este post y espero colaboraciones para recopilar más; si conseguimos suficientes, haremos el security bingo para llevarlo a todos los congresos :)

Encriptar y desencriptar
La primera en la frente. Cada vez que lo oigo se me llevan los demonios, porque aparte de repetido es un error. A ver, que aquí nadie desencripta a nada ni a nadie, ni lo mete en criptas, ni nada parecido… en todo caso lo CIFRA, lo CIFRA y lo DESCIFRA mediante algoritmos de CIFRADO. Encriptar o desencriptar no son verbos en castellano (ahí está la RAE) y si lo fueran seguramente harían referencia al rito judeocristiano de enterrar a muertos en criptas, no a proteger los datos mediante algoritmos “de encriptación“. Dejemos de encriptar y desencriptar la información y comencemos a cifrarla, porque si la enterramos en una cripta pero no la ciframos cualquiera con acceso físico la podrá leer :)

La seguridad es una cadena
Ya, que sí, que ya lo sabemos, que se rompe si lo hace su eslabón más débil. El ejemplo es muy bueno, muy gráfico… o lo era en los 90, pero ahora aunque sigue siendo cierto está un poco visto. Si cada vez que he leído o me han dicho que la seguridad es como una cadena me hubieran dado un eslabón, habría rodeado varias veces la Tierra :) Propongo que busquemos símiles alternativos: la seguridad es como un rosario, la seguridad es como una pulsera… o la seguridad es como una caja de bombones. Venga, un poco de imaginación…

La seguridad total no existe
Sí que existe: estoy totalmente seguro de que me he cansado de que me digan esto. ¡Qué ya lo sé! Que Gene Spafford ya lo dijo hace muchos años (su cita no puede faltar en el pogüerpoin, con lo del bunker y los guardias armados), pero insistir e insistir no va a hacer que seamos más seguros. De nuevo, se acepta cualquier alternativa que diga lo mismo pero de forma diferente y si no incluye la palabra holística, mejor aún (por cierto, ¿alguien se ha parado a buscar la definición de holismo en la RAE?).

El arte de la guerra
No hay presentación que se precie sin una buena cita del libro de Sun Tzu; la de decepción (“All warfare is based on deception”) es de mis preferidas y siempre cae, pero últimamente, con todo eso de la innovación y demás, hemos empezado a detectar otras frasecillas del libro en cuestión. El problema no es usarlas (es un libro excelente y a pesar de los años marca pautas clarísimas en seguridad), sino meterlas con calzador en nuestra presentación: en una charla sobre los forlayos alineados en la nube con el negocio holístico, por poner un ejemplo, es muy complicado referenciar a Sun Tzu de forma natural :)

Las certificaciones
Todos sabemos que una buena presentación tiene que incluir en portada o en contraportada (aquí mola más, porque al acabar la charla están a la vista todo el rato, durante la parte de ruegos y preguntas) tooooodas las certificaciones del ponente. Cuanto más larga sea la lista, más siglas tenga y más anglosajona parezca, más mejor: CISA, CISM, SANS*, Lead Auditor… vamos, que si no caben en una transparencia, reduzco el tamaño de letra pero pongo ahí como sea mi curriculum. ¿No bastaría con un nombre, un cargo y una organización? Ya sé que si estás dando una charla en un congreso o eres bueno o tienes pasta: demuestra lo primero, no lo segundo :)

Ejemplos de consultores
No hay orador que se precie que no ponga un ejemplo de consultores: la típica anecdotilla de cuando era consultor/auditor/responsable/nosequé de una gran empresa -americana, of course– en Villabotijos de Abajo. Esto no está mal, siempre aporta algo nuevo, pero hay un ejemplo de consultores que destaca por encima de los demás: el del password apuntado en un postit en el monitor, debajo del teclado o similar. Vamos, que parece ya una leyenda urbana o un hoax: todo el mundo ha visto esto (o se lo ha dicho alguien que lo ha visto, como lo de la mujer de la curva). Que sí, estamos de acuerdo, todos lo hemos visto… No contemos esta anécdota como si fuera una experiencia que sólo nosotros hemos vivido, porque es como decir “No os lo vais a creer: el otro día iba por la calle… ¡y crucé!” Puede sorprender a nuestras madres, pero no a nuestros colegas de profesión :)

Venga, a ver qué mas típicos tópicos vamos sacando… en serio, si conseguimos una buena recopilación, me comprometo a hacer el security bingo y colgarlo aquí ;)

OCTAVE

OCTAVE es una metodología de análisis de riesgos desarrollada por la Universidad Carnegie Mellon en el año 2001, y su acrónimo significa “Operationally Critical Threat, Asset and Vulnerability Evaluation“, estudia los riesgos en base a tres principios Confidencialidad, Integridad y Disponibilidad, esta metodología se emplea por distintas agencias gubernamentales tales como el Departamento de defensa de Estados Unidos.

Existen 3 versiones de la metodología OCTAVE:

• La versión original de OCTAVE
• La versión para pequeñas empresa OCTAVE-S
• La versión simplificada de la herramienta OCTAVE-ALLEGRO

Al igual que CRAMM cuenta con 3 fases durante el proceso de desarrollo de la metodología:

1) La primera contempla la evaluación de la organización, se construyen los perfiles activo-amenaza, recogiendo los principales activos, así como las amenazas y requisitos como imperativos legales que puede afectar a los activos, las medidas de seguridad implantadas en los activos y las debilidades organizativas.
2) En la segunda se identifican las vulnerabilidades a nivel de infraestructura de TI.
3) En la última fase de desarrolla un plan y una estrategia de seguridad, siendo analizados los riesgos en esta fase en base al impacto que puede tener en la misión de la organización.

Además se desarrollan planes para mitigar los riesgos prioritarios y una estrategia de protección para la organización.

MEHARI

MEHARI es la metodología de análisis y gestión de riesgos desarrollada por la CLUSIF (CLUb de la Sécurité de l’Information Français) en 1995 y deriva de las metodologías previas Melissa y Marion. La metodología ha evolucionado proporcionando una guía de implantación de la seguridad en una entidad a lo largo del ciclo de vida. Del mismo modo, evalúa riesgos en base a los criterios de disponibilidad, integridad y confidencialidad.

En cuanto al proceso de análisis de riesgos mediante esta metodología, se expone a continuación de un modo resumido:

SP800-30

SP800-30 es un documento de la serie SP-800 dedicada a la seguridad de la información y desarrollada por el NIST (National Institute of Standards and Techonogy), el cual es una agencia del Departamento de Comercio de los Estados Unidos. La publicación de esta guía data julio de 2002, y a continuación se muestra el flujo de proceso para el desarrollo del análisis de riesgos mediante el SP800-30

Espero que este breve resumen de metodologías de análisis de riesgos les haya servido a nuestro lectores para hacerse una idea de las tareas asociadas a la realización de un análisis de riesgos. Continuaremos en la siguiente entrada a analizar una de las vistas anteriormente… .

Día tras día, nos exponemos a riesgos de todo tipo. El simple hecho de cruzar la calle implica el riesgo de ser atropellados, lanzarse en paracaídas puede conllevar que el paracaídas no se abra y ya pueden intuir el resultado, o realizar una compra por internet puede entrañar el riesgos de que obtengan nuestros datos bancarios. Está claro que a nivel personal no podemos hacer un análisis de riesgos de cada acción o decisión que tomemos y no hablemos ya de documentarlo conscientemente.

Si pensamos en el ámbito empresarial, donde la mayor parte de acciones deben tomarse de un modo objetivo, ser capaz de cuantificar el riesgo puede suponer en muchos casos la diferencia entre el éxito o el fracaso. En este sentido las áreas TIC de las empresas han sido uno de los ámbitos pioneros en acometer análisis de riesgos, impulsado por ser un requisito de normas como la ISO 27001 y sus anteriores ediciones, o como proyecto de entidad propia.

El análisis de riesgos es la herramienta a través de la cual se puede obtener una visión clara y priorizada de los riesgos a los que se enfrenta una entidad: tiene como propósito identificar los principales riesgos a los que una entidad está expuesta, ya sean desastres naturales, fallos en infraestructura o riesgos introducidos por el propio personal. En este sentido pretende identificar los riesgos más significativos que pueden afectar a la operativa de la entidad y priorizar medidas a implantar para minimizar la probabilidad de materialización de dichos riesgos o el impacto en caso de materializarse.

La pregunta principal es: ¿cómo llevamos a cabo un análisis de riesgos?

Antes entrar en harina, para los lectores que no estén familiarizados con el concepto, vamos a proponer 2 definiciones de análisis de riesgos que provienen del ámbito TIC:

• Proceso sistemático para estimar la magnitud de los riesgos a la que está expuesta una Organización. (MAGERIT)
• Utilización sistemática de la información disponible para identificar peligros y estimar riesgos. (ENS)

¿Cómo se hace un análisis de riesgos?

Como todo en esta vida uno tiene la opción de reinventar la rueda o partir de una metodología reconocida. La intención de este post es introducir al lector en las distintas metodologías existentes, no en detallar el proceso de análisis de riesgos definido en una de ellas. En posteriores post seleccionaremos una de ellas y la diseccionaremos… adivinen cual .

No obstante, en esta entrada y la siguiente vamos a introducirles en metodologías de análisis de riesgos:

MAGERIT

MAGERIT es la metodología de análisis y gestión de riesgos desarrollada por un equipo del Comité Técnico de Seguridad de los Sistemas de Información y Tratamiento Automatizado de Datos Personales del consejo Superior de Administración Electrónico. El nombre de MAGERIT viene de Metodología de Análisis y GEstión de Riesgos de los Sistemas de Información de las adminisTraciones públicas. No obstante también proporciona un marco valido para el desarrollo de análisis de riesgos en entidades privadas.

Se han realizado dos versiones de MAGERIT. La primera de ellas data de 1997 y la versión vigente data de 2005. La versión 2 de la metodología está compuesta de 3 libros:

• El primero se denomina Método, y describe las tareas a realizar para acometer proyectos de análisis y gestión de riesgos aportando una guía para el desarrollo de análisis de riesgos, aspectos prácticos y consejos para facilitar la tarea.
• El segundo libro Catálogo de elementos, recoge el catálogo de elementos implicados en el análisis de riesgos tales como: una categorización de activos, las dimensiones aplicables (DICAT), criterios para valoración de activos como procesos de negocio o datos, catálogo de amenazas y un catálogo de medidas a implantar para mitigar los riesgos a los que están expuestos los sistemas de información. Por último indica cómo desarrollar un informe.
• El tercer libro, Guía de Técnicas, proporciona técnicas para el análisis de riesgos tales como: Algoritmos de análisis, árboles ataque, análisis coste-beneficio, diagramas de flujo, tablas de procesos o técnicas de trabajo. El uso de la herramienta asociada a esta metodología PILAR implementa muchas de estas soluciones técnicas.

A modo resumen a continuación se expone un diagrama que contempla las distintas fases en el análisis de riesgos que recoge esta metodología:

CRAMM

CRAMM es la metodología de análisis de riesgos desarrollado por la Agencia Central de Comunicación y Telecomunicación del gobierno británico. El significado del acrónimo proviene de CCTA Risk Analysis and Management Method. Su versión inicial data de 1987 y la versión vigente es la 5.2. Al igual que MAGERIT, tiene un alto calado en administración pública británica, pero también en empresas e instituciones de gran tamaño. Dispone de un amplio reconocimiento.

La metodología de CRAMM incluye las siguientes 3 etapas:

• La primera de las etapas recoge la definición global de los objetivos de seguridad entre los que se encuentra la definición del alcance, la identificación y evaluación de los activos físicos y software implicados, la determinación del valor de los datos en cuanto a impacto en el negocio y la identificación.
• En la segunda etapa de la metodología se hace el análisis de riesgos, identificando las amenazas que afecta al sistema, así como las vulnerabilidades que explotan dichas amenazas y por último el cálculo de los riesgos de materialización de las mismas.
• En la tercera etapa se identifican y seleccionan las medidas de seguridad aplicadas en la entidad obteniendo los riesgos residuales, CRAMM proporciona una librería unas 3000 medidas de seguridad.

Algunas profesiones despiertan pocas simpatías: árbitro, auditor, informático de sistemas… Y, en ocasiones, esa poca simpatía puede ser recíproca y lo mejor que se puede hacer cuando a uno le toca ejercer una de estas profesiones es intentar pasar desapercibido. Nunca un árbitro será noticia ni saldrá en la portada de ningún diario por lo bien que lo ha hecho durante el último partido aunque ciertamente su actuación haya sido impecable y hasta sirva como ejemplo y material de entrenamiento y formación para futuros árbitros. Sin embargo, cualquier árbitro aspira cada semana a convertirse en noticia de telediario por el mero hecho de cometer un fallo, un simple error, quizá un único fallo en todo un partido.

Con la profesión de informático de sistemas a veces puede pasar algo parecido; si todo funciona a la perfección nadie se acordará de usted ni del gran trabajo que pueda estar desempeñando. Es más: si la organización es mediana/grande mucha gente no sabrá lo que hace ni cómo se llama (ni cómo se llama usted ni cómo se llama lo que hace), quizá ni que existe. Ahora bien, si cae la red o si el equipo de un usuario empieza a ir demasiado lento o si simplemente no se puede imprimir, por poner algunos ejemplos, ese mismo usuario necesitará echar la culpa a alguien, aunque no lo conozca. A los de informática, así en general. Nos guste o no esto es así o casi.

Y no sólo parece injusto sino que además lo es pero a continuación les voy a contar una anécdota vivida no como informático sino como usuario. Y es que, en realidad, hay gente que se gana la mala fama a pulso y contribuye a que nuestra profesión se afiance entre esas que antes decíamos que despiertan pocas simpatías. Hagamos cuanto esté en nuestra mano para evitarlo. Si cuando todo funciona a la perfección nadie se acuerda de los informáticos se podría decir que hacerlo bien sería equivalente a pasar desapercibido lo cual, dicho sea de paso, nada tiene que ver con escaquearse. Hagamos pues lo posible por que todo funcione y pasar desapercibidos. Y el que quiera aplausos y olés del gran público y sobadas de chepa que se dedique a otra cosa. Aún así, y por bien que lo hagamos, con total seguridad algún día algo fallará y los usuarios se quejarán…

Lo que les cuento a continuación verán que se trata de cualquier cosa menos de pasar desapercibido. Vista con la perspectiva del tiempo transcurrido la anécdota me resulta casi graciosa. Pero en el momento no lo fue en absoluto y les puedo asegurar que contó con el rechazo y la antipatía de un buen número de usuarios entre los cuáles yo mismo me encontraba. Por aquel entonces yo trabajaba en una organización con una sede central en Madrid y con una serie de delegaciones repartidas por toda España. Y no ejercía de informático.
En cierta ocasión el departamento de sistemas se reservó el derecho de tomar el control de los PCs en remoto de manera unilateral sin estar justificado y sin previo aviso. Entenderán que no despertasen grandes simpatías entre los demás compañeros.

Aunque no deja de ser una injerencia, a algunos afortunados le resultó transparente la operación porque dio la casualidad de que se encontraban ausentes de sus puestos en el momento en que intervenían sus PCs. Pero el resto de los compañeros de entrada se llevaron un buen susto, para después mostrar abiertamente su fastidio por ver su trabajo interrumpido, al comprobar sorprendidos cómo el ratón cobraba vida propia en la pantalla y empezaba a moverse arriba y abajo abriendo ventanas, seleccionando opciones y aplicando cambios y cómo aparecían y se ejecutaban comandos en el prompt del sistema, comandos tecleados por alguien que se encontraba sentado a centenares de kilómetros de allí, alguien que no había tenido la decencia de enviar un e-mail unos días antes explicando a los compañeros, que en los próximos días desde Sistemas iban a proceder a conectarse en remoto con nuestros equipos para instalar o configurar tal o cual servicio o aplicación o tal medida de seguridad. Ni tan siquiera de hacer simple llamada telefónica informando a los afectados acerca del comienzo del show.

En mi delegación yo tuve el dudoso honor de que mi equipo fuese el primero. Cuando el ratón comenzó a desplazarse a lo largo y ancho de mi pantalla yo, que contaba con la ventaja sobre algunos de mis compañeros de despacho (químicos, ingenieros, economistas, farmacéuticos…) de ser informático de sistemas, en seguida supe el origen del problema (o mejor dicho creí saberlo, porque cuando empezó la función no podía estar 100% seguro). Así con toda la intención pero también un poco “por si acaso” inmediatamente desconecté mi portátil por las bravas de la red y del suministro eléctrico y desalojé la batería de su emplazamiento. Quince segundos más tarde sonaba el teléfono de mi mesa y un tío de sistemas (¡y encima cabreado!, ¿cabe mayor prepotencia?) me pedía explicaciones sobre lo ocurrido. Yo le dije, no sin un puntito de cinismo y dos de mala leche, que me había asustado y que había pensado que se trataba de uno de esos virus cabrones que se había hecho con el control de mi equipo, pero mira por dónde, afortunadamente, has resultado ser tú. Y a la próxima por favor avisa, camarada, a mí y al resto de mis compañeros, porque además de ahorrarnos sustos innecesarios algunos podemos encontrarnos intentando terminar un informe complicado, preparando una reunión inminente, redactando un e-mail urgente o haciendo algún tipo de transacción o consulta importante, quizá con un cliente al teléfono.

Y es que muy poquitos motivos justificarían el que tú decidas irrumpir en nuestros equipos como un elefante en una tienda de Lladró, por más que te lo permitan la tecnología y tus permisos de superusuario superprivilegiado. Yo voto para que te los revoquen. A ti y a quién te los otorgó. Así que aunque la norma ISO 27002 no diga nada al respecto guardemos las formas, por favor, que ya tenemos bastante con lo que tenemos, ¿no? :)