martes, 5 de enero de 2010

EU2010.es, Mr Bean y la gestión de la seguridad

Estaba cocinando varios post sobre la revisión del año 2009 y los pronósticos del año 2010 pero la actualidad informativa obliga hoy a saltarse la planificación previa. Nos hemos levantado con la noticia del señor Mr. Bean como portada de algunos de los periódicos en relación al incidente sucedido ayer con el portal de la presidencia de la Unión Europea. Los hechos salen a la luz en los medios de comunicación tradicionales seguramente haciéndose eco de algunos comentarios que corrían ya por otros canales de difusión más populares en la Red como son menéame.net y el propio Twitter.

Parece que siempre aprendemos más por "lo sufrido" que por "lo avisado" y el presente post quiere ser una reflexión sobre varios aspectos que hay que meditar en relación a los hechos acontecidos. Más vale prevenir que curar, pero siempre acabamos con las tiritas en la mano. Lo secuenciaré por escenarios.

Los hechos.
Durante el día de ayer, y según lo que he podido leer en la prensa técnica y no técnica, durante cierto tiempo la Web de la Presidencia Española de la Unión Europea albergada en el dominio www.eu2010.es permitía Cross-Site Scriptings que hacía que cierto enlace creado a tal efecto fuera visualizado por los navegadores de los usuarios que lo pulsaban con la presencia de Mr. Bean en vez de Zapatero. Hay dos blogueros que explican con precisión lo sucedido:
Los daños.
En relación a la seguridad de la información pura y dura de la Web, realmente este incidente supone un "cero zapatero" dado que el supuesto problema de seguridad no afectaba ni a la confidencialidad de los datos, ni a la disponibilidad (inicialmente, luego veremos que sí) ni a la integridad (dado que en el lado servidor no hay alteración alguna). Por tanto, los daños calificables como operativos son CERO. Sin embargo, atendiendo a otras valoraciones que siempre han de hacerse sobre todo "activo de información", si se ha producido un impacto o daño. El hecho de que hoy aparezca en prensa una noticia sobre un fallo de seguridad, se cuestione la inversión en el portal y la diligencia de la empresa encargada de gestionarlo es en sí mismo un daño en imagen. Una Web institucional es el escaparate de una Organización y por tanto SI tiene asignada una valoración en relación al daño a la imagen corporativa de la organización que representa. En este sentido, este incidente de seguridad mancha la imagen institucional que la presidencia europea ha querido dar y arranca su andadura con una noticia negativa. Además y de forma colateral (y me atrevo a aventurar que también atrevida) se está cuestionando la diligencia de la empresa contratada a tal efecto sin haber todavía asistido a un análisis técnico detallado de los hechos. Este quizás haya sido también el fallo de los responsables del portal que no han sabido dar quizás unas explicaciones técnicamente clarificadoras a los hechos (Mal porque todo plan de contingencia/continuidad de negocio debe contemplar también los aspectos mediáticos del incidente y controlar la información que se proporciona a prensa para aclarar los hechos).
En este sentido, es muy criticable también el papel desempeñado por los medios de comunicación. Reconozco que lograr llamar la atención en la actual sociedad de la información es el hito que todos los medios (y sobre todo los online) buscan a diario. Pero dado que la principal misión del periodismo es contar la verdad, el rigor informativo, la precisión de los datos y el contraste de las fuentes son pilares que deben sostener todo trabajo. La noticia publicada ayer por "El Mundo" decía textualmente:
"Los hackers consiguieron saltarse los sistemas de seguridad de la web de la Presidencia española el lunes, bloquear la página y colocar una imagen de Mr. Bean, sonriente, con los ojos muy abiertos y con cara de sorpresa, que saludaba con un "Hi there" ("Hola a todos", en un inglés coloquial)."
Como bien nos han contado MMadrigal.com y Securitybydefault.com, podemos afirmar que realmente el problema se sitúa más en el lado cliente que en el lado servidor. Por intentar hacer un símil con la seguridad física que sea entendible, sería algo como decir que por pintar la fachada del muro exterior del Palacio de la Moncloa se ha vulnerado la seguridad del Palacio de la Moncloa. Un poco exagerado, ¿no? El supuesto ataque ha consistido en que se ha empleado una captura de una página de búsqueda del sitio para hacer un fotomontaje al que se ha asignado una dirección (url o enlace) que luego se ha distribuido en Internet, a través de redes sociales y blogs. El Instituto Nacional de Tecnologías de la Comunicación (INTECO), adscrito al Ministerio de Industria, Turismo y Comercio, confirma en su auditoría de seguridad sobre http://www.eu2010.es que “el supuesto ataque ha consistido en aprovechar una vulnerabilidad del código fuente denominada XSS (cross site scripting) dirigida a los usuarios de la web y no a la web en sí misma”. Según Inteco “este tipo de ataques, para resultar efectivos, deben combinarse con alguna técnica adicional que engañe al usuario de la web para que pinche en un enlace modificado malintencionadamente, por ejemplo, con ingeniería social”. Sin embargo, el incidente inicial tuvo un efecto colateral no deseado pero algo más serio que acabó afectando a la disponibilidad de la Web. Una noticia llamativa y una Web de relevancia que presentaba un aspecto gracioso hizo que muchos internautas, picados por la curiosidad quisieran en un breve espacio de tiempo consultar la página y ello acabo (de forma improvisada) generando una denegación de servicio en toda regla.

Las reflexiones.
La primera reflexión es un tirón de orejas contra los medios de comunicación tradicionales que han caído en el sensacionalismo tecnológico. O bien por su ignorancia técnica no suplida por asesoramiento específico, o bien por sus dobles intenciones de otra índole, finalmente el verdadero "incidente de seguridad" ha sido el causado por la noticia y no en sí mismo por el hecho contado en la misma.


Además, bastante mal se están haciendo las cosas en seguridad como para meter más leña al tema. El pie de página de la captura de página de la noticia dice "La presidencia ha invertido 11,9 millones de euros en la seguridad de su web". Por favor, seamos serios. Esa cuantía no se corresponde con la seguridad solamente y antes de afirmarlo, informense porque los pliegos de contratación son públicos y se puede saber perfectamente qué se licita. Lo hace www.securitybydefault.com, qué mínimo que un periodista. Además, san Google lo localiza todo rápidamente pero hay que tener interés por contrastar la información.

La segunda tiene que ver con la importancia no cuantitativa de algunos activos de información. Es cierto que en la Web Eu2010.es no hay quizás información confidencial o datos de carácter personal pero sin embargo, tiene un peso simbólico que debe ser protegido. Por tanto, cualquier amenaza que pudiera afectar a su contenido, aspecto o disponibilidad debe ser bien valorada. Si además, es un "activo muy expuesto" y este lo es porque está accesible por Internet, ciertas medidas de seguridad deben ser cuidadosamente implantadas, auditadas y posteriormente vigiladas. Los hechos han demostrado que no ha sido el caso. La valoración final de los hechos es que no hay daño de seguridad pero si impacto para la imagen de la Presidencia Europea representada por España, dado que otros medios se hacen eco hoy del incidente, sin entrar en la gravedad. La noticia es el hecho, no los daños.

La tercera tiene que ver con la gestión de la seguridad y más específicamente con la gestión de la vulnerabilidad. No es de recibo que una Web que va a ser visitada a lo largo del mandato de España en la Presidencia Europea y que cuenta con un presupuesto bastante cuantioso no haya sido convenientemente protegida. La gestión de la vulnerabilidad no es una actividad estática, no es realizar un chequeo de vulnerabilidades, generar un informe y solventar las deficiencias. Es un proceso porque las vulnerabilidades nacen, crecen, se reproducen y finalmente se mitigan, como las cucarachas. Por tanto, su vigilancia no es simplemente cada cierto tiempo hacer una revisión, es una tarea continua de investigar si se conocen para los productos que tenemos instalados nuevas vulnerabilidades, si hay que aplicar parches, programar las tareas para mitigarlas y vuelta a empezar. Queda muy bien explicado por el siguiente dibujo.



En este sentido, ya empiezan a aparecer en el mercado de este segmento de medidas de seguridad soluciones donde su principal valor añadido es precisamente esta gestión asistida. A mí personalmente me encanta el enfoque que le han dado la gente de Outpost24 y que podéis ver en esta presentación. También es importante considerar la monitorización de servicios y noticias. Si por lo que parece, en varias Webs ya se iba comentando que en el dominio había problemas de "cross site scripting" lo prudente habría sido haber auditado si algo podía fallar. Tan sencillo como usar los servicio de Google Alerts y establecer cadenas como el nombre del dominio y podríamos al menos advertir que Google empieza a indexar demasiadas cosas sobre nuestros recursos. Yo lo hago sobre mi blog para detectar quién me referencia.

La cuarta tiene que ver con la auditoría de seguridad como evidencia de haber atado cabos. La seguridad no existe nunca al 100% y siempre toca asumir riesgos. Sin embargo, no es lo mismo no haber hecho nada que haber hecho algo aunque no haya evitado el incidente. Lo primero demuestra NEGLIGENCIA, lo segundo, GESTIÓN DEL RIESGO. Las auditorias siempre tienen un doble objetivo. El primero y fundamental es encontrar deficiencias pero el segundo es evidenciar una situación en un momento dado. En este caso, contar con una auditoría de vulnerabilidades sirve para saber si se revisaron los sistemas y no se encontró el fallo o bien, el problema era conocido pero no se había "gestionado".

Lo inquietante.
De todo esto, la cosa que más me inquieta es ver cómo los servicios online caen ante la consulta masiva de usuarios. Es razonable que no se pueda dar servicio a demasiados usuarios simultáneos pero , ¿cuántos son la cifra razonable?. En el caso de un portal con información dirigida a ciudadanos de la Unión Europea situados en unas franjas horarias similares, ¿cuantas peticiones es razonable atender?. Lo razonable podría ser un ratio entre la población a la que se dirige el servicio y la probabilidad de que lo hagan de forma simultánea. En su momento se vendió la atención telemática como ese factor que permite servicios 24x7x365 de forma continua. Sin embargo y en los inicios de la e-Administración, ¿va a ser esto verdad? ¿Tendremos que acabar haciendo de nuevo cola ante los servidores Web?. Mucho me temo que cuando estemos al final de un plazo de recaudación, muchos ciudadanos olvidadizos o descuidados van a querer hacer sus trámites en el último momento y supuestamente la e-administración permite trabajar hasta las 23:59:59 del día antes del plazo.


Seamos positivos, miremos adelante pero aprendiendo de los errores del pasado.

Mucho ya he hablado en este blog sobre la inocencia que a veces demuestran tanto Administraciones Públicas como empresas en esto de la seguridad de la información. El peligro está ahí fuera porque siempre hay riesgos. Otra cosa es que no se manifiesten pero ello puede deberse simplemente a un "factor suerte" o a la no existencia de una motivación clara para producir daño.

En este sentido, ya comenté en su momento la aparición en escena del famoso "Esquema Nacional de Seguridad" que será una R.D. que establezca los mínimos necesarios en la materia exigibles a la e-Administración. Solo hay que leer el artículo primero para ver cuales son sus intenciones.

Artículo 1. Objeto.
1. El presente real decreto tiene por objeto regular el Esquema Nacional de Seguridad establecido en el artículo 42 de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, y determinar la política de seguridad que se ha de aplicar en la utilización de los medios electrónicos a los que
se refiere la citada ley.
2. El Esquema Nacional de Seguridad está constituido por los principios básicos y requisitos mínimos requeridos para una protección adecuada de la información. Será aplicado por las Administraciones Públicas para asegurar el acceso, integridad, disponibilidad, autenticidad, confidencialidad, trazabilidad y conservación de los datos, informaciones y servicios utilizados en medios electrónicos que gestionen en el ejercicio de sus competencias.


Más adelante, entre sus principios básicos de protección, tenemos joyas como el artículo 7, 19 y 20.

Artículo 7. Prevención, reacción y recuperación.
1. La seguridad del sistema debe contemplar los aspectos de prevención, detección y corrección, para conseguir que las amenazas sobre el mismo no se materialicen, no afecten gravemente a la información que maneja, o los servicios que se prestan.
2. Las medidas de prevención deben eliminar o, al menos reducir, la posibilidad de que las amenazas lleguen a materializarse con perjuicio para el sistema. Estas medidas de prevención contemplarán, entre otras, la disuasión y la reducción de la exposición.
3. Las medidas de detección estarán acompañadas de medidas de reacción, de forma que los incidentes de seguridad se atajen a tiempo.
4. Las medidas de recuperación permitirán la restauración de la información y los servicios, de forma que se pueda hacer frente a las situaciones en las que un incidente de seguridad inhabilite los medios habituales.
5. Sin merma de los demás principios básicos y requisitos mínimos establecidos, el sistema garantizará la conservación de los datos e informaciones en soporte electrónico.

De igual modo, el sistema mantendrá disponibles los servicios durante todo el ciclo vital de la información digital, a través de una concepción y procedimientos fiables que generen objetos digitales auténticos y estables, que sean la base para la preservación del patrimonio digital.

Artículo 19. Seguridad por defecto.
Los sistemas deben diseñarse y configurarse de forma que garanticen la
seguridad por defecto:
a) El sistema proporcionará la mínima funcionalidad requerida para que la organización sólo alcance sus objetivos, y no alcance ninguna otra funcionalidad adicional.
b) Las funciones de operación, administración y auditoría del sistema serán las mínimas necesarias, y se asegurará que sólo son accesibles por las personas autorizadas.
c) En un sistema de explotación se eliminarán o desactivarán, mediante el control de la configuración, las funciones que no sean de interés, sean innecesarias e, incluso, aquellas que sean inadecuadas al fin que se persigue.
d) El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una utilización insegura requiera de un acto consciente por parte del usuario.

Artículo 20. Integridad y actualización del sistema.
1. Todo elemento físico o lógico requerirá autorización formal previa a su instalación en el sistema.
2. Se deberá conocer en todo momento el estado de seguridad de los sistemas, en relación a las especificaciones de los fabricantes, a las vulnerabilidades y a las actualizaciones que les afecten, reaccionando con diligencia para gestionar el riesgo a la vista del estado de seguridad de los mismos.


Y luego, dentro del Anexo referido a las medidas de seguridad a aplicar tenemos soluciones que de haberse aplicado, podrían evitado lo sucedido:

  • 4.1.1 Análisis de riesgos [op.pl.1].

  • 4.3.3 Gestión de la configuración [op.exp.3].

  • 5.6.2.Aceptación y puesta en servicio [mp.sw.2].


De todas formas, es el problema de siempre. Lo importante en seguridad no es saber qué hay que hacer sino hacerlo y mucho me temo que pasará igual que con la protección de datos, que el cumplimiento de la Ley no es suficiente motivación.

Por cerrar este extenso post y como conclusión final, que cada cual aguante sus riesgos. Nos vemos en el siguiente incidente. Buenas tardes y buena suerte ZP.

1 comentarios:

Daryl dijo...

Anda como un pato, suena como un pato y nada como un pato: Mr Bean + caida servidor + silencio = Fallo seguridad.
Da igual si hubo o no fallo. La realidad es que para casi todo el mundo (medios incluidos) hubo un fallo. El objetivo del "ataque" se cumplió.
Para la mayoria de los usuarios la seguridad suele ser invisible en muchos sistemas. Solo los expertos saben que está. Y esta invisibilidad es su fuerte o su debilidad si el objetivo no es penetrar el sistema para inutilizarlo sino desprestigiarlo para lo mismo.
Estamos en un mundo tan paranoico que no solo hay que colocar grandes barreras sino mostrar que existen esas barreras. En este sentido el fallo garrafal fue no dar explicaciones claras y convincentes de forma rápida. Actualmente es casi más importante la gestión de los incidentes que las medidas de seguridad en si.
Y en el caso que muestras de la pintada en el muro de la Moncloa la repercusión hubiera sido idéntica en todos los medios: "terrible fallo de seguridad. la vigilancia estaba dormida. ¿Y si en vez de pintura hubiera sido una bomba?". El técnico de seguridad tal vez este tranquilo en su mundo interior ya que todas las medidas preventivas funcionaron: los infrarrojos no detectaron explosivos ni armas, el muro mide 20 metros de espesor, etc. Pero la repercusión final mediática es idéntica, hubiera o no fallo y la culpa pues.. a los de siempre, a los invisibles.
Y no hay que confiar en la "profesionalidad" de los medios. La ética periodística solo queda en los manuales de la facultad en las añejas series tipo Lou Grant. Ahora hay que considerarlos como un riesgo. Hay que darles la información de forma sencilla, clara, rápida y sin ambiguedades, bien mascadita. Si le sueltas a un medio clásico lo de "leve vulnerabilidad Cross-Site Scriptings, XSS" pensaran "estos informáticos siempre hablando raro" buscaran en San Google, pueden encontrar esto "The Cross-site Scripting Virus" en http://www.bindshell.net/papers/xssv/ y soltar el siguiente titular "Un virus informático de 2005 deja en envidencia la nueva web de la presidencia española de la UE"

 
;