Seguridad y riesgos en las TIC (II)

Seguimos en esta segunda entrada de la serie (ver primera parte) definiendo e introduciendo algunos conceptos básicos relacionados con la gestión del riesgo y la seguridad. Como estrella de la serie, tenemos por supuesto el riesgo, que podemos definirlo como aquella eventualidad que imposibilita el cumplimiento de un objetivo. De manera cuantitativa, el riesgo es una medición de las posibilidades de incumplimiento del objetivo planteado, y en lo relacionado con tecnología, generalmente determina el grado de exposición a la ocurrencia de una pérdida (por ejemplo el riesgo de perder datos debido a avería de disco, virus informáticos, etc.).

La Organización Internacional por la Normalización (ISO) define el riesgo tecnológico (Guías para la gestión de la seguridad de TI /TEC TR 13335-1, 1996) como:

“La probabilidad de que una amenaza se materialice, utilizando vulnerabilidades existentes de un activo o un grupo de activos, generándole perdidas o daños”.

[Read more…]

¡Esto es un escándalo!

Hoy he desayunado leyendo la última entrada de Enrique Dans en su blog, llamada “Trucos para quien depende de Gmail“. En la línea de sus aportaciones habituales, con las que se puede estar más o menos de acuerdo, Enrique aboga por el uso de Gmail para el usuario corporativo, diciendo que:

En las empresas, Gmail ha provocado más de una discusión: no son pocos los directivos y trabajadores que, hartos de las limitaciones de su correo corporativo (de tamaño, usabilidad, acceso remoto, etc.) deciden un día redireccionarlo a una cuenta de Gmail y gestionarlo desde ahí, lo que provoca no pocos escándalos entre responsables de tecnología preocupados por la seguridad y la confidencialidad (escándalos, desde mi punto de vista, completamente estériles e injustificados… desde mi experiencia, es una práctica que recomiendo a cualquiera: Google siempre será capaz de gestionar tu correo mejor de como lo gestiona tu empresa, que no se dedica a esos menesteres como actividad principal).

Creo que no hay nada que añadir al respecto; se siente uno como una pequeña rata de laboratorio paranoica, aunque le queda el consuelo de saber que no lo es. Es razonable que algunas personas piensen, por ejemplo, que la LOPD es excesiva, pero el Reino Unido está empeñada en darnos la razón a los que decimos que no lo es, cuando millones de datos van y “se pierden”. También es razonable pensar que los webmails de Hotmail, Gmail o Yahoo! son sistemas seguros, pero casos como el de Sarah Palin nos dan la razón de que no lo es. Tampoco hay que olvidar las repercusiones de la LOPD en este tipo de servicios; el correo electrónico hoy en día no es sólo un sistema de comunicación electrónica: es también (y cada vez más) un repositorio de documentación. Documentación que incluye datos de carácter personal, informes confidenciales, contratos, ofertas, y muchos otros contenidos de todo tipo. Entiendo la motivación de Enrique Dans, pero es obvio que no la comparto y para ser sincero, me parece una insensatez y jamás la recomendaría a nadie, por muchas razones.

Para acabar con esto, me resulta curioso la mención de que Google gestionará tu correo mejor de lo que lo gestiona tu empresa, cuando un servidor de correo de tamaño medio no es algo tan difícil de gestionar, pero dejémoslo ahí. Si van a la entrada original, encontrarán opiniones a favor y en contra. Aquí (y allí) tienen la mía, ahora háganse la suya.

* * *

En relación con la anterior entrada, el “problema LOPD” de los Palotes de Chiclana, admito que no he dado demasiado tiempo para posibles respuestas, pero creo que el problema no era demasiado complejo. Primero he de decir que la recepcionista, María Antonia Ruíz Pérez, es empleada de Palotes, para no complicar las cosas, y no meternos en rollos de encargados del tratamiento y similares. Y en segundo lugar tengo que decir que el problema admite diversas interpretaciones, y probablemente tenga más de una solución válida; yo personalmente no me siento legitimado para decir que una solución es más correcta que otra, por lo que deberán considerar esta “solución” como mi opinión personal, y en este caso coincido con Javier Cao. Si hubiese alguna discrepancia o error con lo que sigue, les ruego que me lo digan.

Como indicaba Javier, existe una resolución específica en relación con el control de acceso a edificios, la 1/1996 [pdf], que en su norma quinta, “Cancelación de los datos”, especifica que “Los datos de carácter personal deberán ser destruidos cuando haya transcurrido el plazo de un mes, contado a partir del momento en que fueron recabados“. Aunque ésta hace referencia a la LORTAD, y existe una cierta concurrencia de instrucciones con la 1/2006 sobre videovigilancia (pdf) (ver Félix Haro), no se encuentra derogada, y ha sido referenciada en resoluciones de la AEPD posteriores a la LOPD.

Por tanto, tenemos que disponemos de un fichero con una finalidad muy clara (control de acceso) y para el que existe una directiva específica de la AEPD, y al que queremos darle otra finalidad adicional (confirmación de la firma del compromiso de confidencialidad), pero cuyos plazos de conservación son claramente incompatibles. Yo, como Javier, me inclino por un segundo fichero, dado que al mantener el mismo fichero con ambas finalidades, estaríamos incumpliendo la citada directiva. Y esa es, en mi modesta opinión, la solución más apropiada.

En cualquier caso, se admiten correcciones, recursos, y quejas; sólo me queda dar gracias a los participantes y aunque no hay premio, quizá un día les pueda invitar a una cerveza.

“Problemas LOPD” (I): Palotes de Chiclana

Con esta entrada damos comienzo a una serie de posts mediante los que intentaremos presentar situaciones que representan un “problema” (en el sentido más de “examen” del término) para el lector, y que a mi modo de entender pueden aportar luz sobre algunos aspectos de la LOPD. Nada complicado; realmente triviales para cualquiera que esté un poco metido en el tema.

Algunos de dichos “ejercicios” (no puedo evitar ponerlo entre comillas) estarán basados muy vagamente en ejemplos reales, y otros serán simplemente inventados; cualquier nombre de empresa que pueda aparecer es ficticio, como no puede ser de otra manera. Por último, y para finalizar este disclaimer, la solución que se propondrá (no sé aún si en el propio cuerpo pasados un par de días, en una entrada posterior o en el siguiente post de la serie) se facilita según nuestro mejor entender, sin que de ello pueda derivarse ningún tipo de responsabilidad. Dicho esto, vamos con el “problema”.

La empresa Palotes de Chiclana tiene sus oficinas en un quinto piso de la calle Lope de Vega. Para acceder a las oficinas es necesario pasar delante de una recepcionista, que pregunta al visitante sus datos, los almacena en un registro de visitas en papel, y le informa adecuadamente de sus derechos ARCO. Dicho fichero está inscrito en el registro general de la Agencia con el nombre de “Registro de visitas”, y las medidas de seguridad son adecuadas.

Como parte de la obtención de una certificación ISO 27001, la empresa está estudiando hacer firmar a sus visitantes un compromiso de confidencialidad, que se conservaría indefinidamente, por el que éstos se comprometen a no difundir ningún tipo de información a la que tengan acceso, y cuya firma se realizaría en el momento de informarles de sus derechos ARCO. Para ello, han pensado en informatizar el registro de visitas de modo que además del registro habitual de las visitas, un campo adicional indique si ese visitante ha firmado el compromiso de confidencialidad en alguna visita previa, evitando de este modo que tenga que firmarlo de nuevo.

Puesto que los datos de los visitantes y de los firmantes del citado compromiso vienen a ser los mismos, la empresa ha considerado que no existe necesidad de declarar un fichero adicional, ni de modificar el existente. ¿Es correcto?

Seguridad y riesgos en las TIC (I)

Del mismo modo en que para mí fue una novedad entrar en otro nivel del mundo de la seguridad informática, ya que los aspectos de mis anteriores ocupaciones estaban sobre todo orientados a solucionar los problemas que ya hubiesen surgido en los sistemas, periferia y redes, también puede serlo para algunas de las personas que leen el contenido de Security Art Work. Me refiero a responsables financieros, gerentes, directores de departamentos, o simples curiosos por saber de qué hablamos cuándo nos referimos a Seguridad Informática.

Para el resto, los expertos en SI, mis disculpas por entrar en niveles tan básicos, pero a veces se echa de menos un lenguaje más llano, o una definición sencilla que explique aquello en lo que nosotros estamos especializados. También se proporciona una visión global de aquellos aspectos en que la seguridad incide directamente a nivel económico. Lo que publicaré a lo largo de esta serie está extraído en parte de apuntes cuya trazabilidad es imposible resolver, por lo que no menciono autores de los párrafos extractados.

El crecimiento de la tecnología de la información (TI) (También se suele referir en plural: “Tecnologías de la Información”, aunque es mejor referirse a las Tecnologías de la Información y las Comunicaciones (TIC)) en los últimos 20 años ha generado un creciente número de oportunidades así como no menos creciente número de amenazas. Un alto nivel de inversión en tecnología, tal cual existe hoy en día, produce un efecto multiplicador importante en caso que dichas amenazas se materialicen, dado que las pérdidas posibles se ven incrementadas en igual proporción al aumento de la inversión.

Pero no solamente ha cambiado el volumen del uso de la tecnología. También ha cambiado la forma de su utilización. Hoy en día el acceso a los recursos de TIC no está restringido a los profesionales en informática, sino que es accesible para la casi totalidad de la población. A su vez, el acceso a las TIC no se realiza únicamente a los recursos propios, sino que se extiende a otros organismos, sin que exista una frontera física, todo ello gracias a Internet y a la apertura de las redes corporativas, en una magnitud inimaginable años atrás. A su vez, como condición necesaria de todo ello, el grado de complejidad de la tecnología utilizada ha aumentado considerablemente, tornándola cada vez más difícil de administrar adecuadamente, lo cual incluye el control de riesgo para proteger la seguridad.

En este entorno creciente y complejo es dónde los responsables de gestionar las herramientas tecnológicas deben poder diagnosticar adecuadamente los riesgos a los cuales se ven expuestos para poder mitigar de manera oportuna las pérdidas que puedan generarse (que como se ha dicho están relacionadas a la cuantía de la inversión, pudiendo superarla).

Anteriormente, los responsables de manejar los recursos de tecnología eran solamente profesionales de tecnología. Actualmente esto ha cambiado, llevando a profesionales en otras áreas a tener que comprender razonablemente las herramientas y recursos tecnológicos con los cuales cuentan, dado que pueden ser responsables tanto por la gestión integral de las TIC en su organización, como por la gestión de algún componente específico que soporta el proceso de negocio del cual ellos son responsables. Y tras esta breve introducción, es donde comienza, en el siguiente post de la serie, el verdadero meollo de la cuestión: el Análisis de Riesgos.

Rentabilizando los problemas de seguridad

Después de leer lo que hace unos días publicaba Hispasec en relación con la particular forma de Adobe de sacar rédito a los problemas de seguridad, me parece indignante que algunos gigantes de software tengan, dicho en pocas palabras, “la cara tan dura”.

El caso es que en lugar de corregir los bugs de la versión 9, lanzan la versión 10, con algunas vulnerabilidades corrregidas y con alguna “funcionalidad aka vulnerabilidad” nueva. Estando en boga una serie de malware que se beneficia de una “función” (setClipboard) que permite modificar el portapapeles de tu sistema, la compañía libera la versión 10, que además incorpora otra función que permite leerlo. Vivir para ver.

Migren señores, migren. Pero sepan que su seguridad ni mejora ni empeora, simplemente se mantiene (igual de mal).

La LOPD está (aún) muy “verde”

Ya lo dice el título: la LOPD está aún muy verde. Con esto no quiero decir que la LOPD o el RDLOPD necesiten cambios significativos, aunque sí, a pesar de la publicación del nuevo reglamento, siguen existiendo ciertas lagunas, indeterminaciones y ligeras contradicciones; no obstante, a eso ya nos tiene acostumbrados desde hace tiempo la Agencia. Por decirlo de alguna forma, es parte de su idiosincrasia; tiene sus cosas buenas y sus cosas malas, pero la aceptamos con cariño y resignación.

Lo que quiero decir es que casi 9 años después de la publicación de la Ley Orgánica de Protección de Datos (vamos a dejarlo en que la LORTAD, cuyo reglamento salió siete años más tarde de su publicación y fue utilizado como el reglamento de facto de una ley que no tenía reglamento, no cuenta) la adaptación de las empresas a ella es cuando menos relativa. Por supuesto, es significativo el incremento de regularizaciones y adaptaciones en los últimos años, que se reflejan al menos en el aumento del número de ficheros declarados ante el registro general de la AEPD (por algo se empieza). Tampoco hay que dejar de lado el aspecto “motivador” que supone la creciente actividad inspeccionadora y sancionadora de la Agencia; como una vez lo expresó un cliente, la decisión de adaptar o no una empresa a la LOPD puede valorarse en términos de riesgo, y es evidente que la probabilidad de sufrir una inspección ha aumentado en los últimos tiempos, bien sea por inspecciones de oficio, o mayor concienciamiento de la gente, recelosa de sus datos.

No obstante, aunque desconozco cuál es el período de “asimilación social” en el caso de otras leyes, mi experiencia me indica que en general, siguen existiendo bastantes aspectos que exige la ley que se pasan por alto, tanto a nivel de la ley como del reglamento: uso de cifrado, autorizaciones del Responsable del Fichero, registro de accesos en aplicaciones, derecho de información a empleados, firma de contratos con proveedores, envío de publicidad, etc. Muchos de estos puntos se perciben hoy en día como excesivos, y la empresa ni siquiera se llega a plantear su implantación; siguen habiendo empresas (e incluso proveedores con no poca gestión de datos de carácter personal) para las que, sin ningún tipo de mala intención, un contrato de acceso a datos o una cláusula de confidencialidad les parece un innecesario y sobre todo excesivo artificio legal (en la vertiente peyorativa del término).

Pero uno de los puntos en los que aún se percibe con evidente facilidad la falta de autoridad que tiene aún la “invocación” de la LOPD es a la hora de aplicarla a filiales españolas de grupos multinacionales, donde muchas de las políticas, aplicaciones y proveedores emanan y son escogidos por la empresa matriz, sin que las delegaciones nacionales tengan mucho que decir al respecto. A lo largo de mi experiencia profesional he podido comprobar que medidas propuestas como la firma de contratos de confidencialidad o contratos de acceso a datos con determinados proveedores suele ser considerado (si es que llega a considerarse factible) como algo “difícil”, incluso teniendo en cuenta que el ámbito principal de la mayoría de dichas organizaciones es la Unión Europea. Tampoco hay que perder de vista que la LOPD no entiende de grupos de empresas, por lo que si la empresa matriz presta servicios horizontales a la delegación española, deberá firmar un contrato de prestación de servicios y acceso a datos; imaginen por un momento las dificultades de llevar a cabo esa idea o siquiera plantearla en muchos casos. Por último, aunque podría sacar más ejemplos, en muchas ocasiones las aplicaciones escogidas por la matriz para su utilización a nivel global no cumplen las exigencias de la LOPD, una de las leyes más estrictas de la Unión Europea en este ámbito; como es lógico las cosas son como son, y hay habitualmente mucho que rascar al respecto.

Por comparación, mientras que ninguna filial nacional de una gran corporación multinacional se permitiría cometer irregularidades en el ámbito fiscal, en el caso de la LOPD algunos aspectos no insignificantes quedan a menudo abandonados, por falta de autoridad y competencias en unos casos (contratos firmados al más alto nivel, servicios horizontales prestados por la matriz, o aplicaciones globales), y por falta de “interés” o conocimiento en otros: es lógico que la matriz no se preocupe de todos los aspectos legislativos de cada una de sus delegaciones nacionales. Así que en definitiva, uno por el otro la casa sin barrer.

Estoy seguro de que muchas de estas cuestiones se resolverán a medida que la LOPD y sus respectivas leyes europeas vayan cogiendo madurez y los usuarios (clientes, proveedores, personal propio, etc.) vayan adquiriendo conocimiento y conciencia de sus derechos y obligaciones, pero a día de hoy, la complejidad y restricciones impuestas por la LOPD plantea un reto a superar en muchas organizaciones multinacionales con presencia nacional. Afortunadamente, en los casos que he visto, un reto que aceptan gustosas.

¿Romper WPA/WPA2 con GPUs? ¡Chorradas y más chorradas!

En primer lugar, decir que es desalentador el tono con el que algunos lectores de este blog hacen llegar sus comentarios. Les insto a que moderen sus formas ya que este pretende ser un foro de discusión técnica, donde argumentos y datos se superpongan a insultos y ofensas, que no tienen cabida. Dicho esto, me gustaría contestar uno a uno los comentarios realizados durante este fin de semana sobre el post de seguridad WPA anterior que ha aparecido recientemente en menéame.net.

Por lo que respecta al usuario Anónimo que afirma que el cálculo ha sido realizado para el caso peor, es decir aquel en el que la “Primary Master Key” (PMK) se encuentra al final de nuestro diccionario, estoy totalmente de acuerdo: se debería considerar el caso medio. Los cálculos reflejan el coste de computar las “Rainbow Tables” (tablas hash precomputadas) para un ESSID y una PSK concreta, obteniendo un ratio mas desalentador (300 p/s) del propuesto inicialmente en el post (400 p/s, y ya dije que fui benévolo) según el estudio realizado en el proyecto final de carrera adjunto [Seguridad en Redes 802.11, PDF, 5MB]. Para ello se compararon los dos algoritmos que actualmente pueden realizar ataques de fuerza bruta a WPA/WPA2: Cowpatty y Aircrack-ng, utilizando para ello diversos procesadores.

Los resultados obtenidos fueron que en un Intel 3 Ghz Core Duo se llegaron a computar un ratio máximo de 300 palabras por segundo, por lo que recalculando tendríamos que para el caso medio, utilizando un alfabeto de 100 caracteres (mayúsculas, minúsculas, números y símbolos) y una PSK de 8 caracteres, un espectro de (100)^8 = 10.000.000.000.000.000 posibles palabras del lenguaje. Multiplicando por 100 la capacidad de cálculo anteriormente comentada (300 palabras/seg.), según dice el fabricante del software:

“With the latest version of Elcomsoft Distributed Password Recovery, it is now possible to crack WPA and WPA2 protection on Wi-Fi networks up to 100 times quicker with the use of massively parallel computational power of the newest NVIDIA chips. Elcomsoft Distributed Password Recovery only needs a few packets intercepted (with any network sniffer that can export data in tcpdump format) in order to perform the attack.” [Referencia]

tardaríamos 10569,930661255 años en el peor de los casos y 5284,965330627 años en el caso medio. Como se puede ver los resultados todavía son mas desalentadores que los comentados en el post inicial.

Ahora supongamos que tenemos una granja de 1000 tarjetas NVIDIA GFORCE y que dividimos el espacio de palabras a calcular repartido en todas ellas. Se tardaría 10,5 años en el peor de los casos y 5,2 años en el caso medio, lo que parece acercarse a valores temporales manejables. No obstante, todos estos cálculos se habían realizado para el mejor de los casos, es decir que el usuario hubiera utilizado una PSK de 8 caracteres. Aumentar tan sólo en 1 la longitud de la contraseña multiplica por un factor de 100 el tiempo necesario para la recuperación, por lo que con sólo 12 caracteres el tiempo necesario tanto en el peor como en el caso medio se dispara de nuevo. Ni cabe tiene que decir que si seguimos aumentando el tamaño de la PSK obtenemos tiempos de recuperación inmanejables.

Por lo que respecta a los comentarios de ValaV afirmado que consigue un incremento “de unas 5000 – 1000 tests por segundo, a 50 millones”, pueden ocurrir dos cosas: que estés confundiendo de protocolo de seguridad (esos cálculos se asemejan más a ataques estadísticos WEP), o que estés utilizando tablas precomputadas, las cuales dudo que lleguen a 50 millones como afirmas. A eso hay que añadir que esas tablas solo son válidas para un ESSID concreto, por lo que no sirven para un ataque genérico.

“Pobrecito Hablador” comenta “deja de pensar en ataques de fuerza bruta que ya no se usan desde hace 20 años”. No voy a comentar tal afirmación, pero sí que me gustaría que comentara cómo realizar un ataque criptológico a RC4 (WPA) o AES (WPA2) sin el uso de la fuerza bruta; quizá estemos ante un nuevo “Bruce Schneier”. Es relevante indicar que con unos simples paquetes capturados de la red no es posible obtener la PSK, dado que lo único que se consigue es la PTK temporal, que no te serviría de mucho ya que que se regenera para cada sesión (se necesita el Handshake). Te aconsejo pegues un vistazo a la serie de posts sobre WPA.

Por lo que respecta a los comentarios de Heffeque, que dice que se aplican datos falsos e ignoran detalles, respeto su opinión pero en ningún momento presenta información que contradiga lo analizado en el post. El calculo CPU:GPU que indicado está basado en la información que la empresa fabricante del software ha dado, para mí “Phising Comercial”, término que parece que ha levantado ampollas.

En relación con este aspecto, cuando una empresa realiza afirmaciones demasiado aventuradas, desde mi punto de vista, sobre una tecnología ampliamente extendida tirando por tierra al grupo de trabajo de IEEE 802.11i, para mi es un Phising en toda regla. Tratando de vender un producto que permite reducir en tiempo de recuperación de la PSK de WPA/WPA2 pero que dista mucho de las afirmaciones que algunas publicaciones han reflejado “WiFi encryption cracked by Russians using Nvidia graphics cards“, me parece apropiado utilizar este término cuando lo que se pretende es “Pescar Clientes”.

Por último, agradezco a todos los comentaristas sus intervenciones (a pesar, en algunos casos, de las formas utilizadas), e insto a los lectores a que tras leer la serie de entradas sobre seguridad en WPA publicados en este mismo blog, aporten argumentos de peso que permitan mostrar que estoy equivocado, o que al contrario estoy en lo cierto y esto no es más que una estrategia comercial apoyada (no intencionadamente, en cualquier caso) por varios medios de comunicación.

¿Romper WPA/WPA2 con GPUs? ¡Chorradas!

Se ha publicado recientemente que la empresa Elcomsoft ha desarrollado una nueva tecnología que permite utilizar la GPU de la tarjeta gráfica Nvidia para romper el cifrado de WPA/WPA2 hasta 100 veces más rápido que utilizando un PC normal [engadget, ItWire, securityandthe.net]. Aunque no dudo en absoluto que dicho anuncio sea cierto, permitidme una sarcástica carcajada para lo que es un phising comercial en toda regla, y veamos por qué.

Dado que la longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32], tenemos (29+29+10+32)8 = 10.000.000.000.000.000 posibles palabras del lenguaje, que son… bastantes. Teniendo en cuenta que, siendo benévolo, los procesadores actuales mas potentes (utilizando el algoritmo de Aircrack) pueden a lo sumo barrer 400 palabras por segundo, y multiplicando por el incremento de la capacidad de procesamiento de la tarjeta Nvidia tenemos un total de 40.000 palabras del lenguaje por segundo.

Echando cálculos, y si no me equivoco, se tardarían 7.927 años en barrer todas las posibles cadenas, y eso suponiendo que has acertado con el ESSID (ya que la cadena de cifrado depende de él) y que la PSK es ¡sólo de 8 caracteres!, cuando la longitud de la cadena en WPA puede ser mayor de 60 caracteres. Teniendo en cuenta además que cada incremento de la longitud en 1 caracter multiplica por un factor de 100 el tiempo necesario, pueden hacerse una idea de la magnitud temporal si tomamos 12 caracteres en lugar de 8.

Así que este producto esta bien, sí, pero esta muy muy lejos de lo que anuncian, y es más un reclamo comercial que otra cosa. He visto varios anuncios de este tipo con gente que vende colecciones de DVD’s con tablas precomputadas, que aseguran que rompen todos las claves WPA. Chorradas; el verdadero problema de seguridad de WPA son los usuarios y solo será vulnerable cuando se rompa el cifrado (RC4/AES).

Para acabar, si les gusta el tema de aparatillos hardware que permiten incrementar la potencia de cálculo, Picocomputing contruye mediante ASICs y FPGAs dipositivos que pueden llegar a barrer 1000 palabras por segundo. Aunque vistos los cálculos previos, no se hagan ilusiones…

Actualización 20/10, 13:15h (N.d.E.): El autor, Roberto Amado, ha publicado una segunda entrada rebatiendo algunos comentarios.

Actualización 20/10, 11:45h (N.d.E.): Mientras espero la contestación de Roberto Amado a los comentarios realizados, tanto aquí como en menéame.net, hay varios aspectos que es necesario comentar.

El primero es que aunque quizá el término “phising comercial” esté algo cogido por los pelos, decir que “WPA/WPA2 protected networks are not immune against distributed attacks performed with GPU-accelerated algorithms“, como Elcomsoft hace en su nota de prensa, es cuanto menos amarillista; sólo hay que echar un vistazo a Google para ver hasta qué punto ha calado el mensaje. La seguridad de WPA2 sigue siendo igual de robusta hoy que antes del anuncio de Elcomsoft, siempre y cuando, como es habitual, la contraseña tenga una longitud mínima y sus correspondientes reglas de complejidad.

En segundo lugar, aunque no se menciona el uso de una única GPU, utilizar 5, 10, 100 o 1000 no resulta un factor decisivo comparado con el incremento temporal que tienen dos o tres caracteres adicionales; descontando por supuesto que no todo el mundo dispone de tal cantidad de dispositivos.

En tercer lugar, comparar la seguridad de WEP con WPA/WPA2 carece totalmente de sentido, y no hay mucho más que decir al respecto.

En cuarto lugar, para la velocidad de crackeo por fuerza bruta es necesario el uso de tablas precomputadas, que pueden incrementar la velocidad hasta cerca de 40,000 passwords por segundo; no obstante, dichas tablas, aparte de tener que calcularlas, dependen del SSID de la red, por lo que en muchas ocasiones resultan de escasa utilidad. Al respecto, alguno parece haber asumido que el crackeo se hace haciendo pruebas con la Wifi, cuando en el artículo jamás se menciona ese punto. Otra persona dice que los ataques de fuerza bruta no se usan desde hace 20 años, pero me abstendré de contestar a dicha afirmación.

Para acabar, resulta más bien decepcionante (aunque previsible, por otro lado) que en lugar de aportar argumentos convincentes, algunas personas (no todas, afortunadamente) se limiten a insultar o a rebatir el artículo con afirmaciones vacías. En breve espero tener una respuesta de Roberto con todos los detalles. Hasta entonces, espero que apliquemos, antes de soltar los dedos, esa cautela que tanto se pide.

Irresponsabilidad Corporativa y Mal Gobierno

Ahora que está tan de moda la Responsabilidad Corporativa y el Buen Gobierno (ver la reciente entrada de José Rosell), parece que los eventos que estamos viviendo a nivel mundial se empeñan en demostrarnos que éstas brillan por su ausencia, o que al menos se están entendiendo más como una moda o una cuestión de imagen de cara a la galería, que como un compromiso real. Sólo así se entienden hechos como el desplome financiero de grandes (y hasta hace poco, reputadísimas) entidades financieras que han incurrido en situaciones de riesgo operacional tan irracionales como irresponsables, o problemas como los que está sufriendo Islandia. Estos acontecimientos hacen cada vez más patente la necesidad de supervisión y control interno real en las organizaciones, y remarcan la necesidad (y al mismo tiempo, su insuficiencia) de la existencia de leyes como la SOX; evidentemente mejorables, pero imprescindibles.

Aunque también habría que implantar controles relacionados con la Responsabilidad Moral o Ética para algunas de estas empresas y sus directivos, pero para esto, así a bote pronto, me cuesta más plantearme el diseño de los controles. Discúlpenme, pero necesitaba desahogarme.

La necesaria segregación de funciones

En una ocasión tuve la oportunidad de revisar el procedimiento que asegura que en una cadena de montaje el tornillo que sujeta la barra de la dirección de un vehículo se introduce correctamente, aspecto como comprenderán de vital importancia por sus implicaciones en seguridad. Dicho procedimiento era el siguiente:

1. Un operario colocaba el tornillo.
2. Otro operario apretaba dicho tornillo con otro par de apriete.
3. Un tercer operario pintaba de blanco el tornillo, y no por una cuestión estética, sino para obligar a que alguien tuviera que hacer algo sobre el tornillo existente.
4. Finalmente, un último operario de calidad revisaba que estaba dicho tornillo y además estaba pintado de blanco, y procedía a anotar el resultado en una hoja de control de calidad; por supuesto, si el operario no encontraba el tornillo no se limitaba a apuntar que éste no estaba y dejaba el coche continuar por la cadena de montaje como si nada.

Con este procedimiento los responsables del proceso estaban razonablemente tranquilos de que todos los coches salían con su tornillo en la barra de la dirección, ya que cualquiera de los intervinientes podía levantar la alarma ante la falta del tornillo. Como pueden imaginar, otro tipo de revisiones más “ligeras” nos podrían llevar a que si el primer operario no pone el tornillo, nadie se da cuenta y el vehículo sale sin dicho elemento, con el problema evidente que eso supone.

Si extrapolamos este caso al campo de las Tecnologías de la Información, aunque en muchos casos las consecuencias del fallo de un proceso no suelen ser del mismo calibre (aunque en ocasiones, como sistemas SCADA de entornos críticos, sí que lo son), tenemos que las responsabilidades de instalación, mantenimiento y auditoría recaen a menudo sobre la misma persona/grupo o departamento en su totalidad.

Así pues, procesos como el parcheado y la configuración segura de servidores, gestión de cortafuegos, cambios de arquitectura, o seguridad perimetral deberían auditarse y revisarse con rigurosidad, por terceras partes ajenas a aquellas que han intervenido en el proceso de instalación o los mantienen funcionando en el día a día; porque además lo más probable, por un simple factor psicológico, es que una persona que tiene un fallo en una instalación o en la gestión de un servidor de producción no se percate de ello aun en el caso de tener que auditar estos elementos.

Por ello, y aquí es donde quería llegar, es imprescindible que el Departamento de Seguridad esté segregado, y revise y audite los elementos de cualquier proceso relacionado con la seguridad con total independencia y desde su propio punto de vista. Es más, en cualquier organización la posición jerárquica del responsable de seguridad debe de estar por encima o en paralelo del responsable de TI, pero nunca por debajo de éste. Eso nos asegurará que dispone de libertad para “levantar la voz” cuando lo considere necesario, y promover iniciativas propias que no son relegadas a un segundo plano por las necesidades inmediatas de TI; en otras palabras, que cuando vea que un tornillo no está donde debe, pueda anotarlo sin que se considere que un tornillo es sólo un tornillo y que es mejor que el coche siga por la cadena de montaje.

En definitiva, no tenemos que olvidar que además de operarios que ponen tornillos, es necesario tener personal que revisa que esos tornillos están donde deben estar, por lo que pueda pasar. Para acabar, les contaría por qué se estaba revisando con detenimiento el tema del tornillo, pero eso es otra historia…