Blog de Seguridad de la Información de S2 Grupo
Cuando le preguntaron a Albert Einstein cómo creía que sería la tercera guerra mundial, respondió que no sabía cómo sería la tercera, pero que la cuarta sería con palos y piedras. Él pensaba, lógicamente, que la tercera sería nuclear y, por tanto, que acabaría con nuestra civilización.
En el entorno científico-tecnológico, con un buen nombre se tienen más probabilidades de llegar a algún sitio. Piénsese en el “método de la burbuja” como algoritmo de ordenación, en la “partícula de dios” (bosón de Higgs), en la computación cuántica o en la nanotecnología. Marketing científico, podríamos llamarlo. Viene esto a cuento de que, la semana pasada, asistí a la Jornada de Inteligencia Computacional Aplicada al Negocio, organizada por el ITI y me llamó la atención los nombres tan atractivos que tienen los tipos de algoritmos de que se trata en este campo: redes neuronales, inteligencia de enjambre, computación evolutiva… son nombres que inspiran.
Una de los ponentes, Arthur Kordon, de Dow Chemical, presentó una clasificación de las diferentes ramas de la Inteligencia Computacional que me resultó bastante esclarecedora y que paso a comentar de manera muy resumida. Algunas de estas técnicas son utilizadas en los sistemas de detección y protección de seguridad de la información. Ya hablaremos de ello.
Agentes inteligentes.
Se construyen diferentes agentes especializados, con un (micro)comportamiento y un objetivo definido en términos locales y emergen (macro)patrones de comportamiento en el nivel más alto del sistema. En otras palabras, definimos el comportamiento de partes simples del sistema y esperamos a que el resultado se muestre en un comportamiento global deseable.
Inteligencia de enjambre.
De nuevo, se definen agentes simples o boids, todos iguales, que interactúan localmente entre sí y con el entorno y que, sin que se haya definido un control centralizado, hacen emerger un comportamiento inteligente global y auto-organizado que consigue optimizar el sistema.
Computación evolutiva (algoritmos genéticos, entre otros).
Se expresan las ecuaciones para modelar un fenómeno en forma de algoritmos y se realiza una simulación evolutiva haciéndolos competir para alcanzar una solución óptima, a base de la recombinación de sus características y la selección de aquellos que tienen mejor comportamiento.
Lógica difusa.
Se consigue la optimización del control de un sistema complejo mediante el uso de sensores con variables no binarias, expresadas en términos cercanos a los usados por los seres humanos (difusos) y la aplicación de reglas de inferencia que utilizan esos valores “difusos”.
Redes neuronales.
Se consigue el modelado automático y el aprendizaje suministrando datos experimentales a una red que simula el funcionamiento de un cerebro animal (quizás decir humano sea decir demasiado).
Máquinas de soporte vectorial.
Se consigue la clasificación de datos mediante sistemas de modelado automático que aprenden a base de datos experimentales y se aproximan a la optimización de manera automática.
En general, se podría decir que todos estos métodos tienen en común la aceptación de que se renuncia a una solución exacta y analítica del sistema y se deja en manos de la auto-organización la obtención de una solución razonablemente buena del problema. Es una especie de imitación de los sistemas evolutivos naturales. En cierto modo, obtenemos una solución sin entender en el nivel macro cómo se llega a ella. Nos ocurre lo mismo, por ejemplo, cuando somos capaces de entender el funcionamiento de una neurona, pero no el de los procesos cerebrales de alto nivel. ¿No es inquietante?
No voy a hablar de la importancia de la I+D para el futuro de un país, ni de que los sectores que aportan más valor añadido y, por tanto, generan puestos de trabajo de mayor nivel son aquellos que requieren profesionales cualificados, formados en ambientes impregnados de ciencia (que no es otra cosa que curiosidad organizada con método), ni de que los sectores tradicionales que, por no ser sostenibles, han provocado que nuestra crisis sea peor que la de otros países de nuestro entorno, son, precisamente, los que absorben la mano de obra menos cualificada.
No hablaré tampoco de que, mientras nosotros estamos peleando por mantener puestos de trabajo en sectores de la segunda ola, hay países con empuje que nos van a adelantar por la derecha porque trabajan ya en la economía de la tercera ola.
No hablaré de que, cuando se dice que España es el noveno país en cuanto a aportación científica en el ranking mundial, medida en artículos científicos de alto nivel publicados, se están contando a todos los científicos que trabajan en universidades extranjeras (léase norteamericanas). Nosotros los formamos y ellos los aprovechan.
No diré todo esto, porque seguro que hoy, todos estos argumentos ya se han explicado en otros blogs. Y, ya que estamos en un entorno empresarial, diré por qué creo que los recortes en I+D son malos para las empresas españolas.
La semana pasada, en la Conferencia Europea sobre Investigación en Seguridad que José Rosell les comentaba ayer, tuvo lugar una interesante sesión paralela con el título Citizens Security Needs vs Citizens Integrity, el conocido debate sobre el balance entre la seguridad y la pérdida de libertad. Dos de los ponentes defienden la necesidad de introducir consideraciones éticas (léase privacidad, respeto a la intimidad y a las libertades) en los proyectos de investigación, desde el principio, y no como una cuestión a posteriori.
En el turno de preguntas, una persona en la audiencia hace una observación que merece ser registrada: la disyuntiva entre ética y seguridad no se puede plantear como un balance, ya que aunque es indiscutible que todos queremos, como mínimo, algo de seguridad, ¿quién es capaz de decir que quiere menos del 100% de ética?
Sin embargo, en la práctica, sí que renunciamos a parte de nuestra libertad por algo más de seguridad (en realidad, muchas veces es más bien teatro de la seguridad) y si no, pensemos en lo que nos toca hacer en los aeropuerto; como dijo otro de los ponentes, cuando se encuentra con el cinturón y los zapatos en la mano, sujetándose los pantalones, le da la impresión de que, de alguna manera, los terroristas han ganado una batalla.
Para mí, el asunto se puede plantear en los siguientes términos: ¿Es la disyuntiva entre seguridad y libertades un juego de suma cero? En otras palabras, ¿un aumento de nuestra seguridad significa necesariamente un recorte de nuestras libertades? Yo creo que así nos lo quieren hacer creer muchas veces, pero también opino que eso es una falacia. Y con la que se nos viene encima, vamos a tener que prestar mucha atención a este tema.
“No News is Good News“. Todos hemos oído en alguna ocasión esta frase, un poco pesimista, si pensamos que implica que es más probable recibir malas que buenas noticias. Sin embargo, como directivo de una empresa, opino que lo peor es no enterarse de lo que está sucediendo. Como dice mi socio: “Ojos que no ven… batacazo que te pegas”.
Los ingenieros llevamos muchos años monitorizando los procesos industriales; son procesos con parámetros de funcionamiento bien definidos en el diseño, y cuya variación tiene consecuencias conocidas. Sabemos qué desviaciones se pueden permitir sin afectar negativamente al resultado final, vigilamos esos parámetros y establecemos sistemas de control que nos avisan cuando alguno se sale de lo establecido.
En términos generales, la gestión de una empresa consiste en controlar el funcionamiento de sus procesos manteniendo los parámetros de funcionamiento dentro de los límites admisibles, para garantizar que los resultados cumplen con el plan de operaciones. En este caso, los procesos no son sólo los industriales, sino también los logísticos, comerciales, financieros y, por supuesto, la seguridad, de la que a estas alturas no hace falta hablar; todos conocemos el mantra de Bruce Schneier: “Security is a process, not a product“. No hay más que echarle un vistazo a su blog Schneier on Security para comprobar su insistencia en esta idea.
Hace un par de meses, Manuel Benet escribió un interesante post sobre seguridad física; en concreto, sobre cerraduras. A mí, me llamó la atención tanto el post como los comentarios y, “curioso que es uno”, me dispuse a perder un rato en Internet buscando sobre el tema. En particular, me había llamado la atención la tendencia a hacer analogías entre el mundo informático y el físico (qué sería de los ingenieros sin las analogías). En este post, quiero compartir algunas de las ideas que me fui haciendo sobre el tema, según investigaba.
En primer lugar, yo empezaría por el artículo “Keep it secret, stupid!”, de Matt Blaze. En él, el autor explica por qué se le ocurrió meterse en el mundo de la seguridad “ferretera”. El primer párrafo se puede traducir como sigue:
Impulsado por esta curiosidad, Mr. Blaze hizo trizas la base de la mayoría de los sistemas de cerraduras que utilizan llaves maestras. Como saben, se trata de cerraduras (y llaves) organizadas jerárquicamente, de manera que quien tiene privilegios puede abrir las cerraduras por debajo en su jerarquía.
El artículo científico que publicó a consecuencia de esta “inquietud” se titula Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks y apareció en IEEE Security & Privacy (que no está nada mal). Fíjense en que lo único que hizo este señor fue aplicar conocimiento del área de la criptología a un sistema mecánico, con resultados devastadores.
En su sitio web, publicó una explicación práctica de la vulnerabilidad que puso de manifiesto en el artículo y una interesante discusión sobre si es conveniente discutir (y publicar) las vulnerabilidades. El eterno tema de la seguridad por oscuridad o por ocultación.
Siempre es interesante la visión de nuestro amigo Schneier sobre el tema. En su opinión, la batalla de las cerraduras mecánicas está perdida: «Parece que hay un límite para el nivel de seguridad de una cerradura totalmente mecánica, así como al tamaño e incomodidad de la llave. Como resultado, hay un creciente interés en otras tecnologías». Claro que, una de las alternativas planteadas por Schlage, permite la apertura por varios medios, incluido Internet. No sé yo si osaría instalar una de esas. Bueno, sí que lo sé.
Otras referencias interesantes:
MIT Guide to Lock Picking, que una de las guías más antiguas, Lock Picking 101, que es uno de los foros más famosos o el artículo de la Wikipedia sobre Lock Picking, que es un buen punto para comenzar con estos conceptos.
Y, por supuesto, dénse una vuelta por youtube y busquen “lock picking” o “key bumping” (como abrir, literalmente, a martillazos… pero sin violencia). Y si alguien se aficiona, que comparta sus experiencias.
(Imagen original de vissago en Flickr)
Hasta hace poco, se preocupaban por su identidad pública sólo los personajes públicos: artistas, políticos, celebridades en general, disponen muchas veces de sus asesores de imagen, sus relaciones públicas, puestos cuya responsabilidad incluye cuidar de la imagen de sus clientes, asegurándose la construcción de un “personaje” que sirva a los fines económicos o al ego de la persona.
No tengo muy claro si, con la proliferación de famosos, el negocio de los asesores ha aumentado o simplemente se las arreglan por sí mismos, pero esto de la identidad pública sigue sin afectar a la mayoría de las personas “normales”, porque nos relacionamos con personas en nuestro entorno físico más próximo y controlamos bastante bien quién tiene acceso a qué información sobre nosotros y qué cara queremos poner ante diferentes personas y en diferentes entornos.
Pero el mundo digital es diferente. Poco a poco, nos estamos construyendo una identidad en la red. Participamos en redes sociales como Facebook, Linkedin o Xing, donde tenemos perfiles públicos y privados. Aparecemos en noticias en medios cuando participamos en algún evento, aunque solo sea en los sitios Web de la organización. Nuestras multas se publican en el boletín de nuestra provincia. ¿Pertenecemos a alguna asociación? ¿Hemos escrito algún artículo? ¿Participado en un foro de nuestra especialidad? Todo ello deja huella en la red y, una vez allí, es muy probable que permanezca durante años, aun en contra de nuestros deseos. Y las nuevas generaciones lo van a tener más crudo, ya que han empezado a tener presencia digital desde bien jóvenes.
Y no tenemos demasiado control sobre toda esa información. Ni planificamos el contenido, ni le prestamos demasiada atención, dejando aparte el puntito de narcisismo que nos hace “googlear” nuestro nombre de vez en cuando.
Sin embargo, esta información construye un perfil en la red que, cada vez más frecuentemente, es consultado por otras personas. Empieza a ser una práctica común buscar información sobre un candidato a un puesto de trabajo o una posible relación personal. ¿Deberíamos empezar a preocuparnos de ese perfil? ¿Qué impacto puede tener una información inapropiada sobre nuestra persona en nuestras relaciones profesionales o en la marcha de nuestro negocio? Puesto que, en mi opinión, es inevitable tener una identidad digital, ¿no debemos ser conscientes de ella y empezar a cuidarla?
(Al respecto, son interesantes los libros de Daniel J. Solove, publicados gratuitamente y que ya hemos mencionado en alguna otra ocasión: The digital person. Technology and privacy in the information age, y The future of reputation: gossip, rumor and privacy on the internet).
(Imagen por FredCavazza.net)
—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.
—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.
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.
(…)
—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “<br />”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando < para “<" y lo mismo con el resto de caracteres.
—Entonces, basta con “escapar" todos los caracteres especiales.
—En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable.
—Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=", pero no otras, como “<script>".
—Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E", que es lo mismo que “<script>", como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas.
—Pero seguro que sabes una solución y me la vas a contar…
—Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa.
—Usando expresiones regulares.
—Es uno de los métodos más útiles, sí.
—En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta.
—Ni más, ni menos.
