El pasado 18 de enero, nuestro compañero y “alma mater” de este Blog, el ínclito Manuel Benet, nos sorprendió con una nueva entrada que titulaba “MAGERIT: ¿Sí, o no?“, donde transcribía el artículo 13 del aún por entonces no publicado Esquema Nacional de Seguridad (ENS), y sometía la cuestión a una encuesta informal.

Para los que no conozcan el tema, en España, especialmente en las Administraciones Públicas, tenemos un referente indiscutible en el ámbito de la Seguridad de la Información cuando nos planteamos la metodología de análisis y gestión de los riesgos a seguir: MAGERIT, actualmente en su versión 2.0 y elaborada por el Consejo Superior de Administración Electrónica (CSAE), órgano del Ministerio de Administraciones Públicas encargado de la preparación, elaboración, desarrollo y aplicación de la política informática del Gobierno Español.

Hace ya unos meses, en este mismo blog, comentábamos la seguridad de los procesos de negocio y de los diferentes factores de riesgo (legal, técnico…) que pueden degradar dichos procesos; hablábamos en ese post del riesgo humano, ya que las personas son un activo crítico de las organizaciones y, como tal, pueden introducir riesgos en éstas, riesgos que como siempre debemos tratar de forma adecuada. Pero el paso previo al tratamiento de riesgos es, como siempre, su análisis, y para analizar estos riesgos debemos ser capaces de determinar amenazas, probabilidades e impactos que pueden causar las pesonas en la organización.

Bajo mi punto de vista, las amenazas derivadas del factor humano son claras: todas las englobadas bajo el paraguas de amenazas corporativas (errores), las derivadas de actividades sociales (accidentes) y las derivadas de actividades antisociales (delitos); incluso rizando el rizo, podríamos hablar del factor humano en las amenazas de origen industrial y, siendo todavía más retorcidos, en las de origen natural. De la misma forma, los impactos asociados a estas amenazas también suelen estar más o menos claros, y estarán —con toda probabilidad— en la parte más alta de la escala de impactos que queramos utilizar en nuestro análisis. ¿Dónde está entonces lo que más nos interesa? En la medida de la probabilidad, como casi siempre…

Aparte de la conocida seguridad por oscuridad, o la inseguridad de sentirse seguro, podemos hablar de la “seguridad por código binario”, y me explico. Hay muchos proyectos en los que todo es auditable, inspeccionado y revisado… excepto el código binario. Es muy habitual que éste se considere como algo seguro, inescrutable y secreto, ya que se considera que la ingeniería inversa es algo así como una tarea inabordable y de demasiada complejidad para ser llevada a cabo, si acaso por superexpertos.

Como ejemplo de este tipo, hoy en día existen numerosos binarios cerrados por diversas razones como DRM, licencias de producto, aplicaciones cliente servidor, o programación cerrada en sí misma. Ni que decir tiene que la mayor parte de ellos no son a día de hoy tan cerrados como a las empresas responsables de su desarrollo les gustaría. Para desmontar esa creencia de que la ingeniería inversa es para superdotados, en este post me gustaría repasar algunas de la herramientas existentes que permiten a no tan expertos el averiguar qué y cómo lo hacen los programas cerrados.

A continuación os presentamos un reto criptográfico que ha sido publicado por OWASP con el objetivo de promover unas conferencias en Estocolmo los días 21 al 24 de Junio organizadas por los capítulos de Suecia, Noruega y Dinamarca.

¿Qué se gana con este reto? Pues el primero en resolver el reto se lleva una entrada gratuita para estas conferencias valorada en unos 300€. Según anuncian en su página web, estos retos se realizan todos los días 21 hasta la celebración de las conferencias. En este caso, el objetivo de este reto en concreto es sencillo: obtener 8 contraseñas, compuestas por 5 caracteres codificadas en alfabeto tradicional, es decir [a-zA-z].

Aunque en alguna ocasión hemos hablado de OWASP (algunos de nosotros estuvimos en el pasado meeting del pasado mayo que tuvo lugar en Barcelona), lo cierto es que hasta la fecha, no hemos profundizado demasiado sobre este proyecto. Sirva esta entrada para solventar esta (relativamente) grave carencia.

Por si alguien no lo conoce, OWASP (acrónimo de Open Web Application Security Project, es decir Proyecto de seguridad de aplicaciones web abiertas), es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro, aunque su objetivo y foco de atención principal son las aplicaciones web. La comunidad OWASP, formada por empresas, organizaciones y particulares de todo el mundo, trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.

(A raíz de una desconcertante experiencia de la que he sido espectador esta mañana cuando esperaba en la cola del cajero para ingresar dinero, me ha parecido oportuno recuperar esta entrada, que fue uno de los primeros posts de este blog allá por mayo del 2007, que sin duda muchos de ustedes no habrán leído y los demás seguramente la habrán olvidado)

El pasado fin de semana estuve viendo por tercera o cuarta vez Casa de Juegos, de David Mamet; confieso que la recordaba mejor. Supongo que en cierto sentido, por eso el poeta cubano decía aquello de No vuelvas a los lugares donde fuiste feliz; nuestra memoria no siempre es fiel a la realidad. La película en cuestión es de hace ya veinte años, en la que Mike (Joe Mantegna) es un timador dispuesto a desvelarle los trucos y entresijos de su “oficio” a una psicóloga (Lindsay Crouse) demasiado curiosa.

Hoy un cliente me preguntaba sobre posibles medidas a implantar para evitar la fuga de información corporativa, y me apuntaba a la utilización de DRM (Digital Rights Management) y DLP (Data Loss Prevention) para controlar el flujo de información, sobre lo que además tal y como me indicaba no hemos escrito nada en el blog. Me comprometo ya mismo a escribir sobre ello en las próximas semanas (si no pueden esperar hasta entonces, sobre DLP la gente de Websense tiene un PDF bastante detallado en este enlace), pero en cualquier caso, es pertinente comentar unos puntos básicos al respecto de estas tecnologías:

• Este tipo de soluciones suelen tener un coste de adquisición e implantación no despreciable, si se pretende obtener una buena efectividad.
• Además del coste económico implícito, el mantenimiento y gestión de estos sistemas y la información que generan requiere su tiempo, que puede ser significativo y que al final se traslada en un mayor coste.
• Estos sistemas no son infalibles 100%; aunque limitan mucho la gestión no autorizada de información, no son la panacea ni hay que olvidar el resto de medidas (que incluyo en la segunda parte de esta entrada).
• Finalmente, estos sistemas introducen restricciones al flujo de información que pueden generar un torrente de quejas entre el personal, que el Departamento de Informática debe estar listo para asumir y gestionar; dicho de otra forma, es bueno que la organización sea consciente de qué está implantando y que Dirección ofrezca todo su respaldo… para poder utilizarla de escudo en caso de apedreamiento público.

(Para hoy martes, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre la necesidad de dotar de un cuerpo documental a la operación de nuestros sistemas y hacerlo con el menor sufrimiento posible)

La creación de procedimientos es una de esas tareas que muchas veces, por no decir siempre, se pasa por alto dentro de las tareas propias de la gestión de sistemas. Naturalmente no es algo que a los técnicos les agrade mucho, precisamente porque lo que a un técnico le gusta es ‘jugar’ con los cacharros que tiene a su disposición; eso de escribir no es que sea sólo para novelistas, sino que cuando llega la fatídica hora de pasar al papel lo aprendido, o se ha olvidado, o ha pasado a ser la tarea menos prioritaria de las pendientes (a veces porque hay justificadamente otras tareas más urgentes, y a veces porque “se buscan” esas otras tareas). En definitiva, es una de esas cosas que presentan más batalla para el personal que esta operando y explotando los sistemas; según mi experiencia personal, si tuviera que decir cuál es la tarea más problemática que me ha tocado lidiar en el trato con las super-estrellas-técnicos-de-la-muerte, sin lugar a dudas diria que es la procedimentación de una plataforma, no tanto por el contenido sino por la calidad y la dedicación a la redacción, porque un procedimiento mal hecho es casi lo mismo que nada, por la rapidez en que cae en desuso y lo poco que se utiliza.

Hace unos días leía una interesante entrada de Alonso Hurtado sobre la disparidad de jurisdicciones en relación con las redes sociales, basada a su vez en una entrevista a Natalia Martos, directora del Área Jurídica y Privacidad de Tuenti.

En dicha entrada, Alonso hace una reflexión sobre la diferencia de obligaciones y requerimientos en materia de protección de datos que existe entre Facebook y Tuenti, al someterse a jurisdicciones diferentes, la estadounidense y la europea, siendo la primera mucho más laxa que la primera (y más si tenemos en cuenta que la LOPD es una de las leyes más restrictivas de la UE), y parece abogar por una relajación de las restricciones en materia de protección de datos para evitar la ventaja competitiva de empresas como Facebook frente a Tuenti. Al respecto, es cierto que Facebook y otras empresas extranjeras tienen una ventaja significativa frente al “producto nacional”, pero no creo que se limite a las organizaciones estadounidenses, sino a la práctica mayoría de empresas que operan en Internet con datos de carácter personal; la directiva 95/46/CE da el suficiente margen de libertad para que su aplicación entre unos estados y otros sea significativa, por lo que en la práctica, estamos en desventaja no sólo con los EEUU sino con prácticamente todo el globo terráqueo, dado que la aplicación española de la directiva tiene fama de ser la más (o una de las más) restrictiva de Europa.

Con relativa frecuencia aparecen en prensa noticias sobre demandas judiciales entre empleados y empresas por violaciones deliberadas de la privacidad en el correo electrónico, pero poco se habla de los posibles problemas de privacidad que surgen fortuitamente durante el análisis que realizan los sistemas de detección de intrusos (IDS).

Para los no familiarizados con el término —aunque imagino que habrá pocos—, un IDS es un equipo que analiza el tráfico de red, generalmente entre Internet y la red corporativa, aunque puede ser ubicado en cualquier otro punto de la estructura de red. Cualquier comunicación sospechosa de ser un ataque, virus, o comunicación ilícita es registrada para ser analizada por técnicos, quienes se encargan de diferenciar los falsos positivos —comunicaciones válidas que parecen ataques— de ataques reales. Puesto que estamos hablando de un sniffer, al monitorizar el tráfico es posible interceptar comunicaciones en texto plano que contengan información sensible, como pueden ser comunicaciones personales, detalles de navegación o contraseñas.