Security Art Work

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…

Para analizar probabilidades a la hora de hablar del riesgo humano, una aproximación que me gusta mucho —adaptándola a nuestras circunstancias, por supuesto— es la presentada en [1]. La idea resumida y simplificada es que cualquier persona está modelizada por una serie de perfiles que la definen, perfiles afectados además por una serie de condiciones de contorno (relaciones, privilegios, motivaciones…) y de eventos externos o internos a la organización que pueden provocar cambios sustanciales en el perfil de una persona (un cambio de estado civil, un ERE, la muerte de un familiar…). Si somos capaces de monitorizar esto, de una u otra forma, seremos capaces de establecer controles cuando sea necesario, y por tanto de mitigar los riesgos humanos no asumibles en la organización.

¿Cuáles son los perfiles que definen a las personas? Según el trabajo anterior, son los siguientes (existe un último perfil identificado en el trabajo, el de utilización de recursos informáticos, bajo mi punto de vista demasiado ad hoc para la detección de insiders y no tan apropiado para la modelización del riesgo humano en general):

• Perfil económico (estabilidad, actividades sospechosas…).
• Perfil social (estado civil, personas dependientes, hobbies…).
• Perfil psicológico (adicciones, comportamientos anómalos, falta de carácter…).
• Perfil profesional (inteligencia, satisfacción, implicación, reconocimiento…).
• Perfil legal (antecedentes penales, procesos pendientes, sanciones…).
• Perfil ideológico (implicaciones políticas, religiosas…).

Si somos capaces entonces de crear estos perfiles, y lo que es más importante, de monitorizarlos en el tiempo para detectar cambios sustanciales que puedan introducir riesgos en nuestra organización, habremos dado un paso importante para reducir los riesgos derivados del factor humano. Ahora la pregunta del millón: ¿cómo monitorizar todo esto? Lo ideal sería, como siempre, hacerlo todo de forma automática, con sensores que nos avisan en tiempo real de cambios potencialmente peligrosos en la modelizacion de una persona. Para empezar, esto no es siempre posible (¿cómo diseño un sensor que detecte comentarios sospechosos durante la hora del café? ¿y rasgos faciales que puedan implicar falta de interés o cansancio?) y, cuando lo es, no suele ser fácil; seguramente para el gobierno estadounidense puede ser trivial controlar en tiempo real las transacciones económicas o los antecedentes de sus ciudadanos, pero desde luego, para nosotros (pobres mortales) ni es fácil ni muchas veces sería legal.

¿Qué hacer entonces? Mientras trabajamos en monitorización automática de personas para calcular probabilidades cambiantes que puedan aumentar los niveles de riesgo (¡toma ya!), podemos conformarnos con realizar manualmente una modelización de las personas de nuestra organización, teniendo en cuenta los perfiles anteriores —u otros cualesquiera que nos sean útiles — y por supuesto con las consideraciones legales oportunas. En base a este análisis, y pensando un poco, seguramente no hará falta ser psicólogo para darnos cuenta de posibles riesgos (en cualquiera de los ámbitos de la seguridad, desde un insider a un riesgo reputacional) que pueden existir derivados de las personas, y por supuesto cuando identifiquemos un nivel de riesgo no asumible, deberemos tomar medidas -aplicar controles- contra el mismo. Ojo, estos controles no tienen por qué ser ni caros ni complejos: como casi siempre en seguridad, simplemente hace falta pensar.

[1] Mitigating insider sabotage and espionage: a review of the United States Air Force’s current posture. Erika C. Leach, Air Force Institute of Technology. Marzo, 2009.

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.

Primero de todo, no hay que olvidar que los binarios de hoy en día no son como los de antes; la complejidad del software es tal que siempre están compuestos por varios módulos y librerías dinámicas reutilizables, que son llamadas y compartidas por varios binarios a través de sus nombres de función. De esta manera es bastante sencillo identificar el funcionamiento de un binario a “alto nivel” y hacerse con la idea del programa grosso modo, sin que sea necesario analizar con detalle las instrucciones de ensamblador.

Una vez entrados en materia, pasemos a ver algunas herramientas que son útiles para averiguar qué esconde un determinado programa. Lo más sencillo que se me ocurre es la herramienta strings disponible en Linux, que como dice su nombre, al aplicarlo sobre un ejecutable muestra las cadenas del binario, en los que a veces nos encontramos con alguna sorpresa (usuarios, rutas, claves, direcciones IP, etc.):

# strings a.out

Si nuestro propósito es ver qué operaciones hace un programa a través de la red, la primera herramienta útil para averiguarlo puede ser un simple sniffer de red, de los que hay infinidad: tcpdump, wireshark, dsniff, etc.

Una herramienta curiosa para Windows que nos permite capturar tráfico cuando hay SSL interceptando la llamadas a la librería es Traceplus / Webdetective, de modo que si el binario intenta conectarse de manera cifrada para que no seamos capaces de ver el tráfico “va apañado”.

Dependiendo del tipo de binario también podemos hacer una traza de las llamadas que realiza al sistema operativo, viendo de esta manera qué fichero abre, que llamadas al sistema realiza, etc. En Linux destaca por su simplicidad strace, truss en Solaris, y Api monitor en Windows. Subiendo un poquito más de complejidad, es posible ver qué llamadas hace el binario a librerías con ltrace en Linux y con Blade Api Monitor en Windows.

En cuando a la inspección de binarios específicos de Windows (.NET y derivados), cabe destacar Reflector, un software gratuito que nos permite ver el código .net (y derivados). Por último, una técnica utilizada para desentrañar los secretos de un binario consiste en modificar y usar solo partes del programa, como llamadas a librerías. Tomando un ejemplo muy simple, si hemos descubierto el nombre de una llamada interesante como ObtainSecret();, una tarea sencilla puede ser generar un programa que realice una llamada a esa librería e imprimir en pantalla el resultado.

Y hasta aquí todas esta herramientas nos permiten ver el funcionamiento del software, sin saber ni una linea de ensamblador, viéndolo todo en alto nivel. Si queremos llegar mas lejos y tenemos conocimientos de ensamblador existen otras herramientas de depuración como IDA debugger, Ollydbg o SoftICE, mucho más especializadas y que probablemente aquellos de nuestros lectores que realicen desarrollo de sistemas o ingeniería inversa de manera habitual conocerán.

Como conclusión, si como parte de un proyecto vamos a proporcionar un binario “cerrado” a los clientes, hay que considerar todas las funciones que contenga como públicas y por lo tanto la fuerza del sistema no debe basarse en su integridad o seguridad, ya que como hemos visto con más o menos esfuerzo los funcionamientos de los binarios puede ser desvelados y modificados (el DRM tiene una curiosa historia de sistemas teóricamente inviolables que han sido rotos en cuestión de horas). Tal como si se tratara de javascript o flash, el hecho de que el códifo esté compilado en un .exe, elf o lo que sea, no lo hace impenetrable.

PD: Me tendrán que disculpar si no he puesto herramientas orientadas a Java, pero no estoy demasiado familiarizado con este lenguaje. No obstante, se trata de un lenguaje de programación complejo de alto nivel donde hay desensambladores, decompiladores, y muchas otras herramientas. Si lo desean, en los comentarios pueden aportar sus sugerencias.

(Imagen de http://www.everyjoe.com/thegadgetblog/files/2009/12/drm-locked-cd.jpg)

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

El esquema del reto es iterativo, como se puede comprobar en la siguiente ilustración. Es decir, obtenemos la primera contraseña, que se debe utilizar en el segundo paso para averiguar la segunda contraseña, ésta se usa para obtener la tercera y así sucesivamente.

Y cómo sabemos que la contraseña encontrada es la correcta? Pues con la información que se detalla a continuación:

• LM(pwd1) 0C04DACA901299DBAAD3B435B51404EE
• MD2(pwd2 + pwd1) 16189F5462BF906E9D88CF6F152DE86F
• MD4(pwd3 + pwd2) FA8F46A6D347087D6980C3FA77DD4DE9
• MD5(pwd4 + pwd3) 425B33D6F60394C897B8413B5C185845
• RIPEMD160(pwd5 + pwd4) 35F34671D30472D403937820DCABC1C78C837071
• SHA1(pwd6 + pwd5) AE81A30510B2931921934218636B26A803330EB1
• SHA256(pwd7 + pwd6) B2FF0269E927C6559804A37590A0688C45DF143F85CEE0E3F239F846B65C9644
• GOST3411(pwd8 + pwd7) 16CC9F1FF65688E040F5ADA82A41A258FF948769CDA4C4A17D85228A6F358971

El reto está desarrollado en Java y el código fuente que genera las hash se encuentra disponible (.ZIP), a excepción del algoritmo LM para el que se ha utilizado Bouncy Castle 1.4.5. Aunque el reto ya está resuelto en los foros, y no, no conocemos a quien lo ha resuelto —de hecho yo me he enterado cuando ya estaba resuelto—, eso no quita para intentar obtener las claves en menos tiempo que el ganador: 15 horas después de su publicación.

Siempre les quedará la victoria moral, que no es poca.

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.

Organizativamente, OWASP se encuentra dividido en capítulos distribuidos geográficamente. Mención especial debe realizarse al capítulo ibérico, formado por los capítulos de España y Portugal, que organizó el pasado mes de Diciembre la primera conferencia de este capítulo en territorio español con el objetivo de difundir y discutir los problemas y soluciones relacionados con la seguridad de las aplicaciones, destacando la presencia del conocido Bruce Schneier, entre otros.

Una de las partes más conocidas de la documentación que genera esta comunidad, y que va a ser el objeto de las siguientes entradas de esta serie, son las revisiones de las 10 vulnerabilidades web más conocidas y explotadas dentro del sector. Muchos desarrolladores y técnicos han conocido la existencia de las inyecciones de SQL, el cross site scripting o la importancia del manejo de sesiones, entre otras, gracias a la documentación generada por esta comunidad en las versiones publicadas en el año 2004 y 2007. Está previsto que durante el año 2010 se publique una nueva versión de este documento que ya está disponible en la página web del proyecto para su validación y consulta (PDF). Entre los aspectos más destacados de esta nueva revisión podemos indicar que el top 5 no cambia, lo que a todas luces muestra que la mayor parte de la industria del desarrollo web (así como desarrollo en general) continúa considerando la seguridad como una parte prescindible y auxiliar de las aplicaciones, ignorando aspectos de seguridad críticos y en muchos casos fácilmente solventables.

Así pues, esta nueva serie de post sobre el TOP 10 de OWASP, que publicaremos semanalmente si el tiempo lo permite, mostrará en qué consiste cada una de las vulnerabilidades descritas y ofrecerá indicaciones y recomendaciones sobre la forma de evitar estas situaciones. Esperemos que les parezca interesante y nos hagan llegar sus impresiones al respecto.

Pasen, como siempre y a pesar del mal tiempo, un buen fin de semana.

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

En una de las escenas, ambos se acercan a una “tienda” de envío de dinero, se sientan y esperan al siguiente cliente. A los pocos segundos, un marine que tiene que volver a la base entra en el establecimiento. Justo en ese momento, Mike se acerca al dependiente y ostensiblemente se queja de que no hay noticias de su dinero, mientras el recién llegado observa la escena; en realidad, él no sabe que ese dinero no existe. Los siguientes minutos transcurren viendo cómo en una breve conversación el timador se gana la confianza de su víctima, lamentándose de su situación y comprometiéndose a que si su dinero llega antes que el del marine, le pagará el autobús para que pueda volver a la base. Finalmente, como era de esperar, el dinero del chico llega y éste se ofrece a darle parte de éste a Mike. Dinero a un desconocido a cambio de nada. ¿Qué hemos aprendido hoy?, le pregunta él a ella cuando salen del establecimiento (rechazando la oferta). A no fiarse de nadie, contesta él mismo.

No, no teman, no nos hemos convertido en un blog cinematográfico. Pero me pareció que esa escena es una buena forma de mostrar qué y cómo actúa a menudo la Ingeniería Social. Según Melissa Guenther, ésta puede definirse como «la adquisición de información sensible o accesos privilegiados por parte de terceros, a partir de la creación de falsas relaciones de confianza con personal interno de la organización», o en otras palabras, ¿porqué intentar forzar la puerta de atrás cuando pueden abrirte la principal desde dentro? Según esta autora, y para acabar, la ingeniería social se rige por los tres siguientes principios:

(1) El deseo de ser de ayuda,
(2) la tendencia a confiar en la gente, y
(3) el miedo a meterse en problemas (Le entiendo, pero si no me ayuda, voy a tener que dar parte a…).

No vamos a llegar hasta el punto de aconsejarles que, como suele decirse, no se fíen ni de su padre, ni es nuestra intención extender un estado de desconfianza entre las personas, pero por lo general, cuando se trate de temas de seguridad, desconfíen. Esa suele ser una buena política.

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.

Teniendo estos puntos en cuenta, es lógico que algunas organizaciones decidan llevar a cabo la implantación de DRM/DLP, por las indudables ventajas que aportan al control de la información que fluye por la organización. No obstante, sin que sirva de comparación o contrapartida, dejando de lado sistemas específicos, mis recomendaciones (bastante más baratas, por otro lado) son las siguientes:

• Disponer de normativas internas que especifiquen las funciones y obligaciones del personal, y de contratos de confidencialidad firmados con los empleados, que garanticen un respaldo legal en caso de robo “evidente” de información (el problema es que a veces no tiene nada de evidente).
• Implantación de controles técnicos que eviten que una persona pueda acceder a recursos y documentación a la que no debería tener acceso.
• Seguir la regla del need-to-know, y que a cada usuario se le otorgue acceso exclusivamente a lo que necesita para su trabajo, y no más que eso.
• Definir niveles de confidencialidad que establezcan de manera incremental los controles necesarios para el acceso a los recursos.
• Por último, pero casi lo más importante, concienciar a los usuarios sobre el buen uso de la información corporativa; quizá compartir el identificador de usuario con “el nuevo” que acaba de llegar y todavía no tiene acceso no sea tan buena idea, después de todo.

Todas estas medidas forman parte de un SGSI implantado y bien gestionado, que añade muchas más. Una opción alternativa es establecer restricciones a aquellos medios que pueden ser utilizados para la extracción de información, como son el acceso a Internet, los puertos USB y las grabadoras de CD/DVD, pero es algo para lo que también hay que estar (muy) preparado.

En definitiva, mi opinión es que una solución DLP/DRM es útil cuando se ha alcanzado un buen nivel de madurez en la gestión de la seguridad de la organización; hacerlo antes implica muy probablemente una implantación ineficaz que no (a)traiga más que problemas. ¿Cuál es su opinión al respecto?

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

Algunos de ustedes (no todos) estarán pensando: ¿que tiene que ver esto con la seguridad? ¿esto no es una cosa que se hace una vez al año con los auditores? ¿tú tienes tiempo para esas cosas?

[Read more…]

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.

El principal problema no es tanto que Estados Unidos tenga una regulación en materia de privacidad mucho más laxa que la de la UE, sino de que cuando esta última trata de lidiar con grandes multinacionales parece ignorar las exigencias que les hace a sus propios estados miembros, como se ha visto anteriormente con las “exigencias” a Google. Es cierto que una persona que decide crear una nueva aplicación o red social puede llegar a valorar el hecho de llevarse fuera de nuestras fronteras la empresa (no perdamos nunca de vista el hecho de que son siempre empresas) para evitar la estricta regulación nacional, pero al mismo tiempo, el usuario de ese sistema, red social o aplicación debería valorar ese hecho. Me resulta complicado explicar esto sin caer en radicalismos y sin duda estoy entrando en opiniones personales que no son el objeto de este blog, pero pienso que en todo esto rezuma una clara cuestión ética. No podemos anteponer los intereses económicos a la privacidad de las personas, si estamos de acuerdo en que la regulación europea incorpora mejoras y no se trata de simple e inútil burocracia; salvando las distancias, ese tipo de prácticas juegan en la misma liga que la deslocalización a empresas del tercer mundo donde los derechos de los trabajadores “están menos contemplados”, o la domiciliación de empresas en paraísos fiscales donde los requerimientos de transparencia son “menores”. La palabra es responsabilidad.

Entonces, la pregunta principal que deberíamos hacernos es si creemos que la regulación europea es necesaria y útil para la protección de datos de las personas. Mi opinión es que sí. Con indudables mejoras, que al parecer y como leo en el blog de Félix Haro ya se están estudiando (hace ya quince años de la directiva), pero sí. Rotundamente.

Acabo. Creo que el enfoque que debemos adoptar con respecto a esta “desventaja competitiva” es radicalmente opuesto al que expone Alonso (aunque no de manera tajante): no se trata de desregularizar, sino de aprovechar los controles que introduce la LOPD y su reglamento como una ventaja competitiva y no sólo en su aplicación en redes sociales sino también como experiencia aprendida en muchas otras áreas (la consultoría, sin ir más lejos). Somos uno de los países del mundo con mayores garantías en materia de protección de datos personales, por mucho que desde el sector nos quejemos de la poca implantación de la LOPD (algo que no deja por ello de ser cierto al menos para nuestros estándares). Deberíamos dejar de ver ese hecho como un obstáculo, y comenzar a potenciarlo como un sello propio de cara al usuario final; más allá del “Made in Spain“, el “Hosted in Spain“. Por supuesto, para que esto suponga realmente una ventaja, es necesario informar, concienciar y en cierto modo “educar” a éste (por paternalista que suene) en la importancia, relevancia y visibilidad de sus datos personales, algo para lo que quizá no esté (todavía) listo, pero después de todo, nadie dijo que fuese fácil.

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.

Sin una correcta configuración podemos encontrarnos con los siguientes escenarios:

• Al enviar un correo electrónico con un adjunto o contenido sospechoso, tanto el adjunto como parte del contenido del correo quedan registrados.
• Existen páginas de dudosa reputación, por ejemplo de contenidos para adultos, que contienen virus o malware. Al navegar un usuario por ella, además de arriesgarse a ser infectado, se arriesga a que el IDS clasifique la navegación como vírica y que por ello los técnicos encargados de la revisión vean por donde ha navegado.
• Al utilizar servicios de mensajería instantánea con clientes comprometidos las conversaciones quedan registradas.
• Al utilizar servicios de IRC sobre servidores configurados en puertos distintos de los estándares, estos son considerados como posibles comunicaciones entre bots y por tanto registradas.
• Al conectar con servicios de red que utilizan protocolos de autenticación no cifrados, en caso de realizar muchos intentos de conexión simultáneos como es el caso de usuarios lícitos navegando desde un mismo proxy, puede interpretarse como un ataque de fuerza bruta quedando registradas las credenciales.

Con Snort, un IDS muy extendido, estos casos se pueden mitigar en gran medida configurando las variables $HOME_NET, $EXTERNAL_NET, $DNS_SERVERS , $SMTP_SERVERS, $HTTP_SERVERS, $SQL_SERVERS, $TELNET_SERVERS, $FTP_SERVERS y $SNMP_SERVERS, evitando así que conexiones internas a servidores de la DMZ o Internet sean registradas por confundirse con ataques.
Esto se debe a que generalmente se crean las firmas de detección buscando ataques desde la red externa ($EXTERNAL_NET) hacia los servidores definidos en las variables que acaban en “SERVERS”, por lo que las comunicaciones que provienen de la red interna ($HOME_NET), quedan fuera de esté análisis. Puede parecer que esta configuración deja desprotegidos a los usuarios, pero no es así ya que las reglas destinadas a los usuarios apuntan hacia la ($HOME_NET). Además ha de realizarse un análisis de cada red y sus necesidades de monitorización con el fin de eliminar todas las reglas que no sean necesarias, ya que además de aumentar el rendimiento del IDS, podremos eliminar o afinar las reglas que puedan violar la privacidad de los usuarios (y de paso, eliminaremos falsos positivos).

Merecen una mención especial ciertos paquetes de reglas diseñados para monitorizar las actividades de los usuarios en lugar de detectar exclusivamente ataques. Algunos ejemplos son los paquetes policy, porn, p2p, chat o multimedia, todos ellos deshabilitados por defecto. Frente a la posibilidad de que las comunicaciones privadas de los usuarios puedan quedar expuestas a los técnicos que revisan los eventos, en ocasiones se opta por ocultarlo para así evitar el descontento de los empleados, o incluso para no preocupar a clientes ante la posibilidad de que se revele información sensible al contratar un servicio de detección de intrusos. Esta actitud errónea lleva a quedar expuesto innecesariamente a denuncias de los empleados o rupturas de contrato por el simple hecho de no informar debidamente a las partes implicadas.

Por todo esto, en caso de disponer de un servicio de detección de intrusos ya sea propio o para terceros, existen una serie de medidas básicas a adoptar:

• Si no disponemos de un fichero o tratamiento LOPD que cubra ya esta finalidad, debe darse de alta.
• Los empleados deben ser informados de que sus comunicaciones pueden ser analizadas, dejando totalmente claro el alcance y objetivo de dicho análisis. Esta información debe constar en la normativa de seguridad, y se ha de tener la certeza de que todos los empleados la leen y aceptan, preferiblemente por escrito.
• Los clientes deben ser informados de que el IDS puede capturar tráfico legítimo de la organización que será analizado por causas siempre justificadas, y debe firmarse el correspondiente contrato de confidencialidad y contrato de acceso a datos.
• El personal que gestiona el IDS debe firmar (al igual que cualquier otro empleado) el correspondiente contrato de confidencialidad.
• La información del IDS, más allá del nivel de los datos de carácter personal que gestiona, debe ser accesible únicamente al personal autorizado, dada la sensibilidad de la información que puede contener desde perspectivas personales o corporativas.

Dicho esto, para el fin de semana quiero dejarles una pregunta: Imaginen que en una revisión del IDS se detectan accesos hacia páginas web de contenido “no apropiado”, o el envío de información sensible hacia direcciones de e-mail “sospechosas” ¿hasta qué punto deberíamos informar al cliente sobre las actividades de sus empleados en una red que monitorizamos, si no nos han contratado para dicha tarea?

Esperamos sus respuestas. Pasen un buen fin de semana.

El pasado viernes, estuvimos participando en una sesión sobre “ITIL y Seguridad en la práctica”, organizada por nuestros amigos de Tecnofor en Madrid. Asistieron más de cincuenta directivos de entidades públicas y privadas de prestigio. Nos acompañó Manuel Mata, director de TI de Ciudad de las Artes y las Ciencias de Valencia, a quien desde aquí queremos agradecer el favor de su participación y su interés y esfuerzo.

Tras una introducción de Marlon Molina (Tecnofor), José Antonio Espinal (Tecnofor) presentó los referenciales de base de ITIL y los SGSI, preparando el terreno para los casos prácticos presentados a continuación por José Rosell (S2 Grupo) y Manuel Mata (CAC).

El punto de vista de José Rosell fue el de evidenciar la necesidad de conocer los riesgos a los que una organización se ve expuesta, valorar cuáles de ellos es necesario eliminar, mitigar o, a veces, incluso asumir. Según explicó José, el SGSI es la manera de asegurar el terreno ganado en la aplicación de medidas de seguridad en la organización, a la manera en que se apuntala una mina según se va perforando. Destacó también la necesidad de la monitorización como la única forma factible de gestionar la seguridad como un proceso.

Manuel Mata explicó su experiencia en primera persona, a la hora de implantar y gestionar un SGSI. Destacó la importancia del compromiso de la dirección, pero también de cómo el SGSI ayuda a poner en valor la seguridad cara a la propia dirección. Según Manuel, un SGSI requiere un esfuerzo importante por parte del área de TI, pero rinde beneficios tanto en el servicio a otras áreas como en la delimitación de responsabilidades.

Tal como comentó uno de los asistentes, los que conocemos la Ciudad de las Artes y las Ciencias, empezaremos a verla con otros ojos, sabiendo que, detrás de las impresionantes estructuras arquitectónicas y las instalaciones, hay un sistema de monitorización y un sistema de gestión de seguridad de la información que garantiza la protección de activos lógicos y datos.

Las presentaciones se pueden ver y descargar en el blog de Tecnofor, por si puede resultar de interés.