Ya no te puedes fiar de nadie…

El año 2008 fue el año de la “vulnerabilidad crítica que pone en compromiso toda la seguridad de Internet”. Hemos visto varios casos de estos, primero la vulnerabilidad del DNS, luego algunas otras vulnerabilidades en los protocolos de enrutamiento, y alguna otra cosa de menor importancia.

En todos ellos, al final, la solución siempre ha sido la misma: apoyarnos en el uso de certificados digitales (clave pública y privada) para garantizar que estamos conectando donde realmente queremos conectar, y que toda la comunicación entre ambos extremos va a permanecer cifrada, no legible e inalterable por agentes externos a nuestra comunicación.

El gran problema del cifrado de comunicaciones mediante certificados es la distribución de las claves públicas, debemos encontrar alguna manera de poder obtener las claves públicas de nuestros sites web preferidos de tal manera que estos no puedan ser alterados, puesto que en ese caso no existiría ningún impedimento para que un intruso creara un certificado falso y nos lo hiciera llegar al realizar contra nosotros un ataque de Man-in-the-Middle.

Para solucionar este problema entraron en juego las CA (Certification Authority). Las autoridades de certificación son entidades a priori confiables por todo el mundo cuya misión es FIRMAR estos certificados digitales. Podriamos decir que son el equivalente a los Notarios en el “mundo real” (que me perdonen los notarios por la comparación), son entidades confiables que se encargan de “dar Fe” de que la persona que ha firmado un documento es quien dice ser. Las CA funcionan igual, disponen de su propia clave pública y su clave privada, y firman con su clave privada los certificados de las entidades que se lo solicitan.

Por poner un ejemplo para que quede la cosa más clara, pongamos que soy el administrador de www.mibanco.es y que he configurado el acceso por HTTPS con mis claves pública y privada para garantizar la seguridad de mis usuarios. Si no acudo a una CA para que firme mi certificado, los usuarios al conectar a mi web recibirán el mensaje de “este certificado no está firmado por una CA de confianza”, exactamente el mismo mensaje que les daría si un intruso realizara un ataque de Man-in-the-Middle (nos dará un certificado firmado por si mismo). Como no queremos que peligre la seguridad de nuestros usuarios, acudimos a una de las CAs reconocidas, la cual verifica nuestra identidad como administrador del host www.mibanco.es y firma con su clave privada nuestro certificado.

Al poner nuestro nuevo certificado firmado en nuestra web, a partir de ahora nuestros usuarios ya dispondrán de la diferencia entre conectar a la web auténtica (certificado firmado por la CA) y conecter a una web que intenta suplantar a la auténtica (certificado firmado por alguien que no es de confianza).

Como podeis imaginar, de esta manera, el problema de distribución de claves públicas de las webs se reduce al problema de distribución de claves públicas de las CAs, pero este es mucho menos debido a que, evidentemente, hay muchas menos CAs reconocidas que sitios webs en Internet. La solución es, sencillamente, incluir las claves públicas de las CAs más relevantes en el propio navegador web.

Después de todas esta no-breve introducción a las CAs, volvemos al problema que nos ocupa: ¿Nos fiamos de nuestras CAs?

El pasado 30 de Diciembre, en el 25th Chaos Communication Congress (25C3) en Berlín, un grupo internacional de investigadores (principalmente Estadounidenses, Holandeses y Suizos) anunciaron que habían conseguido explotar la conocida debilidad ante colisiones del algoritmo de Hash MD5 para realizar un ataque real contra la infraestructura de PKIs.

Como ya es sabido desde hace algún tiempo, el algoritmo MD5 es susceptible de presentar colisiones, es decir, es posible encontrar dos textos de entrada diferentes que sin embargo produzcan el mismo Hash resultado. Esto supone un verdadero problema para los algurirmos o sistemas que se apoyen en Hash MD5, puesto que para toda operación que se realice con este Hash, las dos entradas serán completamente indistinguibles.

Es el caso de las CAs, existen algunas CAs que a día de hoy siguen utilizando MD5 como Hash cuando firman certificados, ya que no firman el certificado entero por una cuestión de eficiencia, sino que calculan el MD5 de los parámetros más significativos del certificado y luego firman dicho Hash.

Como podeis imaginar, ahí es donde está el problema, ya que debido a la vulnerabilidad del algoritmo MD5, es posible encontrar 2 certificados diferentes cuyo Hash sea idéntico, y por lo tanto, el Hash firmado por la CA será igualmente idéntico. Este problema puede ser usado para usurpar la identidad de un host y realizar ataques Man-in-the-Middle, puesto que nuestro navegador reconocerá el certificado malicioso como firmado por una CA de confianza.

Volviendo al ejemplo de www.mibanco.es ,supongamos que un intruso quiere usurpar la identidad del sitio web, solo tiene que descargar el certificado con la clave pública del host (que se puede descargar desde el propio host) y calcular un certificado (con su clave pública y privada) cuyo contenido tenga como resultado el mismo Hash MD5 que el certificado original. Una vez conseguido esto (algo nada sencillo, los investigadores han tenido que usar un cluster compuesto por 200 Playstation 3 durante 3 días) lo único que hay que hacer es aplicar el Hash firmado original al certificado malicioso, que efectivamente será perfectamente válido, por lo que cuando el usuario acceda al sitio malicioso este aceptará el certificado ya que lo reconocerá como firmado por una CA reconocida.

En realidad, el ataque mostrado por los investigadores es un poco más complicado, ellos lo que hacen es conseguir que una CA reconocida firme el certificado de otra CA propia, una rogueCA, a partir de lo cual cualquier cosa que firmen con esa CA (que es de la propiedad de los atacantes) será automáticamente aceptado por todos los navegadores, lo cual es aún más terrorifico si cabe. Podeis acudir a la web original de los investigadores para más detalles.

Las CAs afectadas por esta vulnerabilidad ya han anunciado que están corrigiendo este problema, pero por el momento, la única medida efectiva con la que nos podemos quedar tranquilos es eliminar los certificados públicos de las CAs que aún utilizan MD5 de nuestro navegador/sistema operativo, ya que si no confiamos en la CA, no vamos a “tragarnos” la suplantación basada en la firma de esa CA.

Para no tener que comprobar uno a uno los certificados, podemos usar esta herramienta aunque sólo funciona en entornos Windows, según se lee en la propia web.

Si es que al final no podremos confiar en nadie…

Seguridad contra Aceptabilidad

La aceptabilidad de un determinado control es un factor crítico cuando hablamos de implantar salvaguardas en nuestras organizaciones. No nos engañemos: podemos implantar la mejor política perimetral en el mejor cortafuegos, el pasillo mecanizado más moderno, la política de contraseñas más robusta… si los usuarios no las aceptan, estas medidas fracasarán antes o después: los usuarios acabarán con tarjetas 3G conectando desde sus portátiles a Internet, el vigilante de seguridad abrirá el pasillo para que no se acumule gente en horas punta, y todos apuntarán sus contraseñas en postits.

Las medidas de seguridad más efectivas no suelen ser aquellas que sólo son técnicamente más avanzadas que el resto, sino que a esa eficacia -que se presupone- se debe unir un alto grado de aceptabilidad; hace años, estudiando acerca de sistemas de autenticación, leía un ejemplo muy significativo: quizás un modelo de autenticación rápido, barato y robusto podría basarse en un análisis de ADN o similar (me lo invento, por supuesto, no sé si analizar ADN en la actualidad es barato, rápido y robusto). Al acceder a una sala de acceso restringido, o a un sistema informático, podríamos sustituir las tarjetas inteligentes o las contraseñas por un simple análisis de sangre u orina del usuario, que en caso de ser satisfactorio abriría una puerta o una aplicación. Sencillo, ¿verdad? Probablemente, desde el punto de vista de seguridad, sería perfecto, pero el nivel de aceptabilidad haría que el sistema fracasara: poca gente está dispuesta a dar sangre para abrir una puerta, y tampoco a tener un botecito con la leyenda “Deposite aquí su muestra”.

La aceptabilidad de las medidas de seguridad es cada vez más crítica conforme la medida es invasiva o puede poner en riesgo -o parecer que pone en riesgo- la privacidad del usuario; en biometría encontramos los casos más claros: el análisis de huellas se asocia a criminales, el análisis de retina puede permitir la detección de enfermedades -aparte del miedo lógico a que un escáner nos barra el ojo-, etc. Modelos de autenticación biométrica técnicamente estupendos han fracasado debido a que los usuarios no aceptan el sistema, y por tanto evitan utilizarlo o tratan de engañarlo por cualquier medio.

De esta forma, es responsabilidad de los que trabajamos en seguridad el implantar controles no sólo técnicamente correctos, sino ACEPTABLES por parte de aquellos que tienen que vivir con ellas día a día. Es especialmente importante que nuestras medidas de seguridad sean aceptables cuando repercuten en el trabajo de los usuarios menos concienciados con la seguridad: si a un técnico le obligamos a utilizar contraseñas de veinte caracteres para entrar en un router, entenderá que se trata de una importante medida de seguridad, pero si obligamos a utilizar una clave igual de larga a alguien del departamento de Recursos Humanos para acceder a su correo electrónico, acabará apuntándola en cualquier sitio o utilizando contraseñas triviales.

Evidentemente, no podemos seleccionar nuestros controles de seguridad en base únicamente a la aceptabilidad que van a tener en la organización; si así fuera, seguramente no implantaríamos ninguna medida de seguridad y dejaríamos la protección del negocio al libre albedrío de los usuarios, aproximación que significaría desprotección total (o best effort, en el mejor de los casos). Como siempre, necesitamos un equilibrio entre seguridad y, en este caso, aceptabilidad; si logramos dicho equilibrio, podremos estar seguros de haber implantado una medida que funcionará correctamente y que se mantendrá en el tiempo, garantizando así la seguridad de nuestro negocio.

El precio de los sentidos

Estas navidades fui obsequiado con una flamante sudadera azul con un inmenso logotipo en letras blancas que anunciaba Nike just do it! Me parece que no es necesaria una descripción más detallada puesto que todos tenemos en mente el popular icono de esta marca deportiva.

Tras la abundante pitanza de la cena y enfundado en mi nueva prenda me dispuse a abrir el Pub de la plaza del pueblo, bar que junto con mi primo con gran ilusión compramos hace ya algunos años. Subí con gran esfuerzo la persiana oxidada del local golpeándome súbitamente un olor, como diría yo… un olor así como a mueble-bar antiguo, ya sabéis, esa puerta de obertura horizontal que nuestros abuelos tenían en el salón de casa y que siendo niño no te dejaban abrir. Tres botes de ambientador en spray solucionaron el problema, así mucho mejor.

Me dirigí al fondo del local donde tengo, en el privado, una caja de herramientas. Sacando un gran martillo y un par de enormes clavos me dispuse a colocar en la pared el cuadro que me amiga Silvia me había pintado y que desde hacia tiempo le había prometido que colocaría a la entrada. Precioso quedó arriba de las butacas de raso, y es que esta chica tenía casi tanto talento como el mismísimo Picasso.

Iba siendo hora ya de comenzar a crear ambiente, así que puse uno de los últimos discos que había adquirido y de un par de brincos me metí detrás de la barra. En ese preciso instante una voz grave desde la puerta dijo:

—Buenas Noches.
—Buenas noches —contesté yo— ¿Qué desea?
—Mire, represento a la Sociedad General de Autores Gráficos, SGAG y venia a reclamarle el canon visual por su sudadera y… ¡ese cuadro que tiene en la pared!
—Canon visual, ¿usted está loco?, ¿qué quiere decir con canon visual? —respondí enérgicamente.
—Sí mire, ya que usted tiene una obra creada por un autor de nuestra sociedad, este debería percibir una modesta parte de sus ingresos debido a que todo cliente de su local puede disfrutar visualmente de su sudadera o de su flamante cuadro. Así que debe pagar 300 euros mensuales si quiere exhibir públicamente esos objetos.
—Pero bueno, esta usted en sus cabales, quiere decir que ¿tengo que pagar por ponerme una prenda que he comprado o un cuadro que me han regalado?
—Sí —contestó el cuervo negro.
—¡Márchese ahora mismo de mi local y no vuelva por aquí!

canon.jpg

Madre mía, ¿había enloquecido este hombre pasto de los polvorones navideños? Cuando todavía no me había repuesto de semejantes barbaridades, oí nuevamente una voz estridente que decía:

—Buenas Noches.
—Buenas noches —contesté yo. Era un tipo bajito con un maletín negro de piel. —¿Qué desea?
—Mire, represento a la Sociedad General de Autores de Perfumes, SGAP y venia a reclamarle el canon aromático por el ambientador que utiliza.
—¡¿Canon aromático?! —¡Madre mía! parece que el especial de “Mira quien baila” navideño ha hecho bastante daño este año.
—¿Qué quiere decir con canon aromático? —respondí desconcertado.
—Sí mire, ya que usted utiliza un ambientador con derechos de autor, nuestra sociedad debería percibir una modesta parte de sus ingresos, debido a que todo cliente de su local puede disfrutar olfativamente de su fragancia y su persona se esta lucrando haciendo uso de ella. Así que debe pagar 300 euros mensuales si quiere dispersar públicamente su ambientador.
—Joder, el mundo esta lleno de tarados, ¡me está diciendo que tengo que pagar por que mis clientes huelan mi spray perfumado!
—Efectivamente —contestó la pequeña alimaña.
—Lárguese de aquí enseguida antes de que le eche a patadas.

Dios mío, salió más rápido que el anterior. No daba crédito a lo que me estaba sucediendo; parece ser que la gente se estaba buscando la vida de forma un tanto extraña últimamente, pero a mi no me iban a engañar.

—Buenas Noches. —Madre mía, ¿quien será ahora?, pensé.
—Mire, represento a la Sociedad General de Autores y Editores, SGAE y venia a reclamarle el canon de derechos de autor por toda la música que usted tiene en el local y de la cual se esta lucrando al emitirla a sus clientes.

Reflexiones navideñas…

Seguridad contra Seguridad

Los que nos dedicamos a Seguridad siempre hemos oído (y asumido como propio) aquello del equilibrio entre seguridad y funcionalidad: debemos conseguir una seguridad aceptable para los procesos corporativos de nuestra organización, pero al mismo tiempo sin degradar el correcto funcionamiento de dichos procesos y permitiendo que el negocio continúe; y todo esto, por supuesto, en base a los recursos de los que dispongamos y a la estrategia corporativa. Dicho de otra forma, si mi seguridad se basa en mantener siempre los sistemas críticos apagados o las puertas de mi oficina comercial cerradas permanentemente, lo más probable es que sea el más seguro… de la cola del paro.

No obstante, conforme la seguridad se ha convertido en una materia multidisciplinar en las organizaciones, en las que ya no hablamos sólo de seguridad sino que ampliamos el concepto a protección del negocio, y tocamos ramas tan dispares (¿o no?) como la seguridad legal, la continuidad del negocio, la seguridad física o la seguridad lógica, nos encontramos con que en ocasiones no sólo debemos mantener el equilibrio del que hablábamos antes (seguridad vs. funcionalidad, seguridad vs. coste) sino que además debemos anteponer en ocasiones una visión de esa seguridad frente a otras.

Imaginemos que nuestra compañía organiza unas sesiones comerciales para presentar sus nuevos productos, sesiones a las que va a acudir algún que otro VIP. Cuando desde Seguridad se solicita a Protocolo la relación de personas que van a asistir, para determinar qué medidas de protección es necesario adoptar, Protocolo nos dice que por la LOPD no puede facilitarnos esta relación (o sí que puede, pero tardará N días, cuando la sesión es dentro de N-1 días). ¿Qué hacemos? Aparte de iniciar los trámites necesarios para que no vuelva a ocurrir, tenemos dos opciones: si queremos proteger adecuadamente a las personas que acuden al evento, debemos conseguir esa lista por algún medio, y si queremos cumplir con la ley, no podemos conseguirla… En cualquier caso, el problema tiene mala solución, ¿verdad?

A diario en nuestro trabajo podemos encontrar ejemplos como el anterior. Ya no sólo se trata de garantizar la seguridad global de la organización, sino que en ocasiones se trata de anteponer una visión de la seguridad a otras; como hemos dicho, los riesgos que debemos evaluar sobrepasan muchas veces el habitual “seguridad vs. funcionalidad”. Sólo un detalle: tengamos en cuenta que la protección de personas siempre suele ser el elemento más crítico en cualquier organización (por si sirve de pista para solucionar el problema anterior ;).

Ah, podemos enlazar esta entrada con la serie acerca de Problemas LOPD, en este mismo blog… ¿o no es lo mismo?

Vodafone les desea feliz navidad (y S2 Grupo feliz año)

No, no me he equivocado. Esta mañana leía en un foro lo siguiente, con fecha del pasado 22/12 21:40h:

Durante la tarde de hoy observo una incidencia en Mi Vodafone. Tengo 3 líneas que gestionar una de contrato y 2 de prepago, el caso es he observado de cada vez que accedo a la sección “mis datos” y nombre del “titular de la línea” me sale una persona distinta, me explico conecto y en alguna de las lineas me sale un nombre, nif, dirección, teléfono de contacto y dirección que nada tienen que ver conmigo, me desconecto y vuelvo a conectarme y vuelven a salirme los datos de otras personas, nunca son los mismos. Cada vez que me conecto veo los datos de otras personas en lugar de los mios. ¿Es esto normal? ¿Están a salvo nuestros datos en manos de Vodafone? [gsmspain.com]

Al parecer, este problema afectaba únicamente a los clientes de prepago, y aunque no he indagado demasiado en el error, también existía alguna relación entre el usuario que el cliente veía cuando accedía, y las fechas de alta de la tarjeta o el programa de puntos de ambos. Vodafone dió de baja el acceso a dicha sección de la web a partir de las 12h del día siguiente, un poco tarde en mi opinión para un operador nacional de móvil de estas dimensiones. A pesar de ello, hasta ayer 29 los medios de comunicación no se hicieron eco del problema, y todo gracias a la denuncia interpuesta por Facua contra Vodafone ante la AEPD. Sin mayores reflexiones, sirva este último caso como colofón a un año que nos ha traído la entrada en vigor de un nuevo reglamento y un buen montón de fugas, pérdidas, robos, evaporaciones, transmutaciones y venta de datos de carácter personal, algunas públicas, otras (¿muchas?) no. Y discúlpenme que no ponga los enlaces, pero es que son muchos.

* * *

No podíamos acabar el año sin dar respuesta al tercer problema LOPD, aunque lo cierto es que todos los participantes habéis acertado de pleno y no creo que pueda añadir demasiado. Más allá de las medidas que Atmedsa debe implantar en relación con sus propios trabajadores, la idea era centrarse en la relación responsable – encargado del tratamiento.

La verdad es que, si les gustan los puzzles, la situación en la que Atmedsa y Plásticos Cremallera están es un bonito rompecabezas que incluso es parcialmente regularizable. ¿Se han planteado que Plásticos Cremallera, contra todo pronóstico, podría actuar de Encargado del Tratamiento de los datos responsabilidad de Atmedsa, dando servicios de soporte informático? Entre otras muchas cosas, deberían firmar un contrato de acceso a datos y Cremallera disponer de un Documento de Seguridad como Encargado del Tratamiento. Claro que el tema de las llaves del armario no hay manera de regularizarlo.

No obstante, el señor Botón y su amigo, que se dedica “a eso de la LOPD”, son partidarios de las soluciones sencillas. De la navaja de Occam y del Principio KISS (Keep It Simple, Stupid) que tanto le gusta a Tanenbaum. Y por eso se dan cuenta de que convertir a Plásticos Cremallera en Encargado del Tratamiento de Atmedsa, es, aparte de una estupidez, y perdónenme el lenguaje, un marrón considerable teniendo en cuenta el nivel de los datos que el servicio médico gestiona.

Así pues, en la línea de las soluciones indicadas, es imperativo que el servicio médico tenga en exclusiva las llaves del armario, y recomendable que los equipos informáticos sean proporcionados por Atmedsa. Vuelve a ser imperativo que el soporte técnico de los equipos (copias, registro de acceso, cifrado, etc.), independientemente de quien lo proporcione, no lo preste técnicos de Plásticos Cremallera, sino personal de Atmedsa o una tercera empresa contratada por ésta (desde el punto de vista de cumplimiento, ese es ya su problema y no el de Plásticos Cremallera). Es recomendable que se disponga de segmentación en la red, tanto para evitar el acceso al equipo del servicio médico por parte del personal de Plásticos Cremallera (esto debe ser preocupación de la empresa del servicio médico) como para impedir que el personal médico tenga acceso a la red corporativa (y esto, preocupación de Cremallera). En este caso en particular, la solución ideal podría ser en mi opinión una ADSL directa al equipo del médico sin ningún tipo de conexión con la red corporativa, pero por supuesto eso tiene un coste (tanto económico como de gestión, y en este caso yo deshabilitaría lógicamente cualquier punto de red a menos de 5 metros del router ADSL). Y creo que, aunque no haya añadido nada, eso es más o menos todo; ¿qué les parece?

Ahora, déjennos que tomemos las uvas, pensemos un poco y el año que viene venimos con más problemas. Total, es pasado mañana. Así pues, feliz año a todos, con puente o sin él.

La norma ISO 28012:2008

Dentro de la familia de normas ISO 28000, relativas a seguridad en la cadena de suministro, y de especial relevancia en el tema de protección de infraestructuras críticas nacionales que ya hemos comentado en algún post dentro de este mismo blog, ISO acaba de publicar la norma ISO 28012:2008, Metodologías para el Análisis de Riesgos en la Cadena de Suministro Portuaria.

Esta norma, no certificable -para eso está ISO 28001-, define como su nombre indica los métodos a seguir para realizar un análisis de riesgos focalizado en el suministro a través de puertos. Para ello, define una clasificación de activos muy distinta a lo que hasta ahora conocíamos (por ejemplo, a través de MAGERIT), y es que la norma se basa no en lo que los activos son (sistemas, información, personas…), sino en lo que los activos valen para la organización (algo completamente coherente, dicho sea de paso). Así, tanto los impactos sobre el negocio de la pérdida o degradación de un activo se calculan en base a esta premisa, y por tanto el riesgo que la organización soporta viene directamente derivado del valor de cada activo concreto para el negocio.

ISO 28012:2008 clasifica el valor de los activos en cinco niveles, del 1 (valor más bajo) al 5 (máximo valor), y determina los riesgos para el negocio en base a esos valores. Por tanto, un activo de valor 1 puede degradarse -o perderse- por una amenaza determinada sin que el impacto asociado cause daño en la organización, mientras que esa misma amenaza sobre un activo de valor 5 constituye un riesgo no asumible y que por tanto debe ser mitigado.

Realmente, esta aproximación es similar en resultados a la aproximación clásica de cualquier metodología de análisis de riesgos; lo realmente curioso es que al valorar los activos -de todo tipo-, la norma establece valores de mercancías transportadas en barco (en base al precio global del contenedor y del impacto de su pérdida), pero también establece “valores” para otros activos relevantes en la cadena de suministro, como son las personas encargadas de garantizar que dicha cadena es correcta y completa.

Sin entrar a juzgar la ética de valorar a las personas con un determinado nivel, y considerar su pérdida como algo asumible o no para el negocio, hemos realizado un “simulacro” de análisis según esta norma, y siguiendo sus indicaciones al pie de la letra podemos determinar que las personas más prescindibles para la cadena de suministro portuario son los keypiggers, una figura hasta ahora considerada clave en cualquier autoridad portuaria y cuyo cometido es registrar por triplicado las entradas y salidas de mercancías, buques y personas al recinto portuario. Y realmente, fijándonos con un poco de atención en las funciones de dicha figura, podemos determinar que desde hace años está realizando un trabajo completamente redundante, ya que el control de contenedores y buques se realiza de forma automática en cualquier puerto moderno, mediante tecnologías como RFID, mientras que el control de personas se realiza a través de la Policía Portuaria, que tiene delegada dicha función por Real Decreto desde 1.966.

De esta forma, algo tan sencillo como la publicación -y aplicación- de una norma de seguridad, va a ahorrar a los puertos de todo el mundo una enorme cantidad de dinero, simplemente prescindiendo de la figura del keypigger, considerada clave hasta el momento y que se ha demostrado poco o nada relevante en la realidad (y que por tanto, con toda probabilidad, va a ser la figura a desestimar en cualquier puerto). Y lo más sorprendente es que, después del keypigger, seguramente vendrán más.

Como vemos, esta norma ha entrado muy fuerte en el panorama de la seguridad, ya que su publicación y aplicación ha detectado de forma directa un gasto sin sentido desde hace años y cuya anulación va a suponer a las autoridades portuarias de todo el mundo un gran ahorro. Esto demuestra, una vez más, dos cosas: por un lado, la enorme utilidad de una norma bien aplicada, y por otro, el grado de pasividad que hemos adquirido con el tiempo, ya que hemos sido incapaces de detectar esta situación hasta que ISO nos ha abierto los ojos. En fin, ver para creer…

PD. Como muchos de mis compañeros ya no me consideran tan técnico como antes -ellos sabrán- aquí va una prueba que demuestra lo contrario: este paper que he enviado a USENIX, acerca del impacto de las simetrías en el cifrado. Disfrutadlo :)

La medida más importante de seguridad

Hace unos días en una reunión con la familia lejana, comenté que me dedicaba a temas de seguridad, y como suele ser habitual, los interesados tardaron poco en preguntar que les recomendaba para sus equipos caseros personales. Entonces tuve que ver cual era la medida de seguridad más importante que les iba a recomendar.

Dado que todos los presentes eran usuarios de Microsoft, lo primero que se me vino a la cabeza fue el “escudito” que Microsoft incluye en sus sistemas operativos de escritorio. Seguro que muchos de ustedes lo han visto alguna vez en la esquina derecha de la pantalla, y que de una manera semafórica le indica al usuario si su sistema es “seguro” (verde), “no es seguro del todo” (amarillo), o “no es seguro” (rojo). Hay que que reconocer que aunque sea una simplificación y las cosas no tiendan a ser tan simples, a un usuario doméstico puede ayudarle bastante. Las tres cosas que este sistema comprueba en un Windows XP son las siguientes:

– Firewall: Seguridad perimetral, si el sistema tiene activado el firewall y está protegido de ataques externos.

– Antivirus: En este caso, el sistema garantiza que existe un antivirus y que se encuentra actualizado, con lo que con suerte estamos protegidos frente a virus conocidos y software malicioso.

– Actualizaciones automáticas: Garantizan que el sistema esta actualizado, al menos el sistema operativo. Por desgracia no comprueba otras aplicaciones frecuentemente utilizadas, entre ellas navegadores y otras aplicaciones vulnerables a la asalvajada Internet, pero como suele decirse, más vale algo que nada. No obstante, no deja de ser curioso que Windows pueda “hablar” con los antivirus y comprobar su nivel de actualización, pero no sea capaz de comprobar el estado de actualización de programas populares de otros fabricantes (Apple, Adobe, Firefox, OpenOffice, etc.), algo que apunta más a cuestiones de protección de negocio que de dificultad técnica.

Por supuesto, todos estos controles y medidas son muy importantes, pero no considera la medida más importante de seguridad en —al menos— cualquier entorno doméstico, que es la que trasladé a mi audiencia: realizar copias de seguridad. Esto proteje los datos no sólo frente a amenazas cibernéticas, sino frente a desastres físicos, fallos manuales y muchas otras circunstancias indeseables. Excepto suplantación de identidad y robo de información, cualquier otro problema se soluciona con las copias de seguridad.

Estoy seguro de que a estas alturas, la mayor parte de ustedes están pensando en lo obvio que resulta lo que les estoy diciendo. Probablemente mi familia estaba pensando lo mismo. Sin embargo, también estoy seguro de que la mayor parte ustedes están pensando que no tienen copia de seguridad de sus equipos personales, o que ésta se remite a varios meses, siendo optimistas; es una tarea molesta, algo tediosa y no muy habitual para la gran mayoría de la gente. Pero es sin ningún género de duda la más importante.

Así que si tengo que dar una sola recomendación, esta es: ¡Copiad malditos! ¡Copiad!

SQL Injection

—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.

exploits of a mom

—Sí, ésta la he encontrado en esta noticia de abril sobre un ataque de inyección de SQL. Me ha hecho gracia y se me ha ocurrido traerla como excusa para ver si eres capaz de decirme algo nuevo sobre un tema tan conocido ([1] [2] [3]) y que, sin embargo, sigue dándonos sustos tan a menudo.
—Pues precisamente acabo de leer hace nada otra noticia sobre un ataque a los servidores de MS SQL Server a través del IE7, que parece tener relación. Mira, aquí está. Aunque sé que no hace falta, te traduzco libremente algunas frases:

“[…] otra vulnerabilidad zero-day en un producto de MS. Esta vez es el SQL Server […] el bug de SQL permitiría la ejecución de código malicioso a un usuario autenticado mediante una conexión directa a la BD o también a través de una inyección SQL en una aplicación Web vulnerable […]”

—En la noticia de abril también se habla de inyección de SQL, aprovechando una funcionalidad del Microsoft Internet Information Server (IIS) que llama comandos genéricos, que sólo tiene SQL Server.
—Sí, recuerdo el caso. La vulnerabilidad es una funcionalidad de SQL Server, y eso es lo que permitió que el ataque fuera genérico y por tanto, masivo. Pero la puerta de entrada son las vulnerabilidades en las aplicaciones Web que había en los servidores. El revuelo en ambos casos viene porque la funcionalidad genérica en un caso y el bug en el otro son en productos de Microsoft y permiten ataques genéricos.
—Esto es un sinvivir.
—Claro, el problema es que el software sobre el que descansan nuestras aplicaciones es muy complejo y una vulnerabilidad se cuela con cierta facilidad. Es más, te diría que pasa poco para lo que podría pasar.
—Y, maestro, ¿qué hacemos? Si cambiamos de SGBD (Sistema de Gestión de Base de Datos), tendremos otras vulnerabilidades. No creo que Microsoft sea especialmente peor que los demás.
—Pues no. Lo que pasa es que, muchas veces, no se presta la atención debida a las aplicaciones que se construyen sobre el software de base y no podemos esperar que éste sea invulnerable a cualquier ataque. Además, la entrada se produce porque las aplicaciones Web no están bien diseñadas y programadas. Es decir, que nos dejamos las puertas abiertas. Por ejemplo, todavía no se siguen las reglas básicas para evitar los ataques de inyección de SQL, que, como bien sabes, son…
—Si, claro: “No utilizarás accesos a la BD en tus aplicaciones con privilegios mayores que lo mínimo imprescindible“, “No usarás sentencias SQL dinámicas con variables, sino queries parametrizadas“, “Usarás procedimientos almacenados con cuidado“, “No usaras nombres dinámicos de tablas, salvo en caso de extrema necesidad“…
—Cuando estas cosas hacen falta, vale la pena replantearse el diseño de la funcionalidad que quieres conseguir.
—Y con eso, ¿nos evitamos el riesgo?
—Lo reducimos, lo reducimos. Ya sabes que la seguridad absoluta no existe. Como decía Einstein, sólo hay dos cosas infinitas: el Universo y la estupidez humana… y, de lo primero, no estaba seguro.

“Problemas LOPD” (III): Plásticos Cremallera

(Primero, la solución del anterior)

Hace ya demasiado tiempo, recordarán que planteamos el problema de Piruletas de Motilla del Palancar. Resumiendo, Piruletas es una empresa que utiliza los servicios de la empresa Bolsa de Trabajo, (BdT) cuya actividad es un portal web de selección de personal. Cuando un candidato ve una oferta de Piruletas, se apunta a ella y Piruletas es informada de ello. El problema es que BdT no permite que Piruletas informe al candidato de sus derechos respecto de dicha cesión cuando se le informa de que se ha apuntado a la oferta, por lo que el candidato sabe que sus datos son cedidos pero no cómo y frente a quién exactamente ejercer sus derechos.

A lo largo de los comentarios que hemos mantenido Javier Cao, Edgard (inspirador del caso) y un servidor, han quedado evidenciadas algunas lagunas en el procedimiento de actuación de BdT. Al parecer, aunque el candidato conoce el nombre de la empresa ofertante, BdT no permite que tras la inscripción, Piruletas le conteste con los datos de contacto para el ejercicio de derechos ARCO (asumo que Piruletas no conoce los datos de contacto “externos” del candidato, ya que esto facilitaría mucho las cosas); esto no tiene como finalidad (creo) que BdT siga actuando de intermediaria durante todo el proceso. Continuando las suposiciones, se me ocurre que pueden existir empresas que se quieren mantener anónimas hasta el final del proceso, en el cual ellas mismas se ponen en contacto con los “finalistas”, o que como sugería Javier, el negocio de BdT se centre en la gestión, filtrado y envío inicial del lote de candidatos, tras lo cual la empresa (en este caso Piruletas), puede ponerse en contacto con ellos.

Dejando ya el campo de las suposiciones, y pasando a la solución, existe por supuesto una solución inmediata que es el cese de la colaboración con la empresa, aunque quiero considerar esa opción como el último recurso a efectos del presente caso. Por supuesto, en el mundo real ™, cuando se valoran ofertas de diferentes proveedores, uno de los criterios para escoger no es otro que el cumplimiento legal. Otra solución aportada por Javier es la de que BdT anonimice los datos de los candidatos, ya que en un proceso de selección, y excepto cuando la presencia personal tiene un papel importante, los datos identificativos carecen de sentido. Esta solución, aunque es buena, obligaria a BdT a cambiar su forma de trabajar, algo a lo que no creemos que BdT sea especialmente receptiva.

En nuestra opinión el problema reside en su mayoría en la actuación de BdT, que realiza una cesión cuyo destinatario no está definido. Por parte de Piruletas, es cierto que accede a datos identificativos de personas a quienes no puede informar de sus derechos durante el tiempo que dura el proceso de selección (entiendo que no hay manera de contactar con ellos), pero no vemos mayor problema. Respecto a aquellos que rechaza, no está obligado a comunicarles sus derechos ya que no va a tratar sus datos (de forma similar a un curriculum que se destruye nada más ser recibido. Aún así, si considerasemos que existe tratamiento, éste puede verse como extremadamente marginal para ser significativo). Respecto a los que acepta para una fase posterior del proceso de selección, es obvio que tarde o temprano tendrá que conocer sus datos de contacto, que es cuando deberá informarles de sus derechos. Quizá hilando muy fino podríamos ver una no conformidad “temporal”, pero en cualquier caso, creo que no supone un gran problema.

¿Qué os parece?

* * *

Andrés Cremallera fundó Plásticos Cremallera la primavera de 1987. Gracias a varios contratos con la administración pública y a una impecable gestión, pasó de tres empleados a trescientos cincuenta diez años después, momento en el que el crecimiento de la compañía se estabilizó. A partir de 1991, y por requerimientos legales y del negocio, se decidió contratar una empresa de atención médica (Atmedsa) que prestase servicios de asistencia médica en las oficinas de la planta. Dicha atención médica se facilita actualmente por parte de un médico “residente”, en una sala anexa al despacho de Antonio Botón, Responsable del Departamento de Prevención de Riesgos Laborales. Aunque en un principio para el almacenamiento de información había sólo un único archivador, en la actualidad dispone de cinco archivadores con llave (copias de las cuales están en posesión de Antonio Botón), y un ordenador personal propiedad de Cremallera, ubicado lógicamente en el segmento de usuarios, y cuya copia de seguridad diaria (incremental) y semanal (total) están incluidas en las políticas de backup de la compañía. El médico utiliza dicho equipo para almacenar la información habitual (minusvalías, alergias, analíticas) en ficheros ofimáticos de rápido acceso, y para conectar, por medio de la salida a Internet de Plásticos Cremallera, a la aplicación de Atmedsa para la gestión de historiales clínicos.

Ayer, primer día de la primera auditoría del reglamento a la que la empresa se somete, Antonio Botón se dió cuenta de cómo la cara del auditor cambiaba a medida que le describía el funcionamiento del servicio médico, así que por miedo a haber metido “la pata hasta el fondo”, llamó a un amigo suyo que se dedica a “eso” de la LOPD. ¿Qué le dijo éste?

Actualización 19/12, 12h: Dani, de Eddasec, plantea una solución en esta entrada de su blog.

Otra pérdida masiva de datos de caracter personal

Hoy, El Pais da cuenta de una noticia: “Filtrados a un diario alemán los datos de tarjetas de crédito de miles de clientes”, en la que se informa de otra pérdida de datos de tarjetas de crédito.

¿Por qué se producen tantos incidentes graves en la gestión de datos personales que hacen las entidades públicas o privadas? Hoy el Berliner Landesbank, pero no hace mucho fue la Hacienda británica ¡por segunda, tercera vez! la que perdió datos personales de los ciudadanos.

No sé si es por la forma de redactar del periodista de El País, pero no da la impresión de que a nadie le haya extrañado demasiado ni se haya rasgado las vestiduras. Estas noticias están dejando de ser noticia. Voy a hacer una predicción: cada vez vamos a enterarnos de casos más graves, en los que se pierda información más sensible o de más millones de usuarios. ¿Hasta cuándo?

¿Nos podemos imaginar que se hubiera perdido dinero, contenido de las cajas de seguridad o documentación confidencial del banco? Seguro que alguien acabaría en la calle. O secretos militares… menudo escándalo. A algún ministro le costaría el cargo.

¿Cuál es la diferencia? En mi opinión, hay tres: (1) se trata de información de los ciudadanos, que no perjudica directamente a los depositarios de la misma, sino a los propios ciudadanos; (2) el perjuicio es difuso, no es que le hayan robado nada a nadie, sino que podrían robarle a algunos de los ciudadanos, si no toman las medidas adecuadas; y (3) la información “extraviada” no la maneja un grupo reducido de personas que entienden su valor, sino mucha gente dentro de varias organizaciones: el banco, la empresa subcontratada para la gestión de los cómputos bancarios (¿?), la delegación… es tan sencillo copiarse una base de datos o una hoja de cálculo…

En resumen, información que manejan muchas personas que no valoran adecuadamente su importancia, que la manejan de manera rutinaria, sino con indeferencia.

Hace falta formación, hacen falta procedimientos y hacen falta mecanismos de seguridad adecuados. Y mucha, mucha concienciación.