Toca tras un periodo de barbecho, retomar la costumbre de publicar pensamientos sobre un análisis técnico del panorama de la seguridad de la información. Y la noticia estrella de la semana y probablemente de estos meses será Heartbleed y las consecuencias de este fallo de seguridad. A colación de estos hechos quiero plantear diferentes cuestiones que han venido a mi mente al analizar qué ha pasado y sobre todo, qué causas están de lo que ha sucedido.
Hace un par de años me atreví a realizar un post titulado El Tsunami tecnológico que no pudimos evitar donde relataba cómo un error informático producía un Pearl Harbour cibernético. En concreto, en aquel relato había un trozo de texto que trataba de hacer reflexionar sobre el proceso de creación de software y sobre la necesidad de empezar a aplicar la cultura de la "seguridad industrial" al proceso de fabricación del software.
La informática nunca quiso ser vista como una ingeniería. Aunque en las facultades se formaba a profesionales para que aplicaran metodologías de desarrollo, se validaran los programas, se formalizaran las pruebas, en definitiva, se creara un producto robusto y estable, aquello penalizaba la rentabilidad de las empresas del software y no era la práctica habitual. Solo las grandes ya habían descubierto que esa manera de generar código era la única viable para dar soporte al ciclo de vida del software. La crisis también tuvo bastante que ver porque fue la cazuela perfecta en donde cocinar todos estos ingredientes: excusas por falta de recursos, saltos al vacío para ahorrar costes y mirar a la nube como la panacea de las TI, carencias de normas de regulación tecnológica que al menos forzaran a unos procesos de desarrollo y fabricación de tecnologías más robustos y sobre todo, la extensión general de que las responsabilidades no son aplicables a las tecnologías de la información y que el "error informático" es un ente sin nombres y apellidos que siempre está en todas las consecuencias pero que no tiene un padre que determine cual es la causa y sobre todo el culpable. En todos los productos tecnológicos era una práctica habitual que aparecieran las cláusulas de "irresponsabilidad" que son todas aquellas cláusulas de responsabilidad que empezaban diciendo "este producto se entrega como está y el fabricante no se responsabiliza de nada".
Por tanto, como primera reflexión creo lo sucedido es un primer toque de atención. Estamos basando nuestra economía en un producto intelectual no tangible que no sufre el mismo proceso de fabricación que todo lo que nos rodea en el mundo físico y además, lo estamos desmaterializando cuando usamos ya términos como "cloud" o "nube" para intentar desvincular el software de los dispositivos electrónicos donde reside y se ejecuta. Sin localización de componentes físicos es más fácil lograr la deslocalización de responsabilidades.
Una segunda reflexión tiene que ver con la seguridad del código abierto. Durante años uno de los principales argumentos para generar confianza en el opensource siempre ha sido la transparencia. Sin embargo, se da la terrible paradoja de pensar que el hecho de que potencialmente haya miles de auditores pueda significar que finalmente no decida intervenir ninguno y que todo el mundo piense que otro hará el trabajo. En el post ¿Por qué tienen éxito el phishing o el scam? Psicología de las víctimas de una estafa referencié el estudio de la Universidad de Cambridge que analizaba la psicología de la estafa desde la perspectiva de la víctima. Y curiosamente en el proceso de timar a alguien se produce la aplicación inconsciente de dos principios que pueden haberse dado en el caso Openssl y que a continuación menciono.
Si un desarrollador ve que instituciones relevantes están incorporando el proyecto OpenSSL de dos personas que implementan las operaciones criptográficas, por el principio del rebaño, puede que acabe deduciendo que si estas instituciones se fían será porque el producto es robusto. Si entre esas instituciones aparece alguna con reputación y credibilidad en materia de seguridad, entonces se aplica el principio de obediencia social y probablemente demos por hecho que la seguridad del proyecto opensource es incuestionable. Y de esa forma se entra en un bucle de retroalimentación positiva donde cada vez empresas más relevantes confían en los pasos que dan otras antecesoras y extendiendo el uso de forma masiva para transformarlo en un estándar de facto en ciertos entornos. Y cuando aparece el fallo Heartbleed y la gente empieza a preguntarse cómo ha podido ser, resulta que OpenSSL es un proyecto de software libre basado en SSLeay, desarrollado por Eric Young y Tim Hudson. Dos personas han compartido su conocimiento y código en Internet para que sea utilizado y el uso se extiende tanto que cuando se da a conocer un agujero de seguridad que afecta a las versiones 1.0.1 y 1.0.1f de éste protocolo, acaba afectando a dos tercios de las comunicaciones seguras que se efectúan en Internet. La noticia OpenSSL pide ayuda también revela que muchos de estos productos software están hechos como están hechos. No voy a criticar lo que ciertos voluntarios deciden subir a Internet de forma altruista. Lo que más sorprende es ver cómo hay parte de la industria de las tecnologías de la información que incorporan esas piezas a sus entornos sin realizar ciertos controles de calidad o al menos, contribuyen a que alguien realice estas revisiones en beneficio de la "comunidad".
Una segunda reflexión tiene que ver con la seguridad del código abierto. Durante años uno de los principales argumentos para generar confianza en el opensource siempre ha sido la transparencia. Sin embargo, se da la terrible paradoja de pensar que el hecho de que potencialmente haya miles de auditores pueda significar que finalmente no decida intervenir ninguno y que todo el mundo piense que otro hará el trabajo. En el post ¿Por qué tienen éxito el phishing o el scam? Psicología de las víctimas de una estafa referencié el estudio de la Universidad de Cambridge que analizaba la psicología de la estafa desde la perspectiva de la víctima. Y curiosamente en el proceso de timar a alguien se produce la aplicación inconsciente de dos principios que pueden haberse dado en el caso Openssl y que a continuación menciono.
- El principio de obediencia social: La Sociedad nos educa y entrena para no cuestionar la autoridad. Los estafadores pueden aprovechar este "otorgamiento previo de confianza" o "nuestra anulación de la desconfianza" para hacer con usted lo que quieran.
- El principio del rebaño: Las personas más prudentes y desconfianzas bajan la guardia cuando todo el mundo parece asumir o compartir los mismos riesgos. ¿Seguridad en multitudes? No, si todos los que te acompañan están conspirando contra ti.
Si un desarrollador ve que instituciones relevantes están incorporando el proyecto OpenSSL de dos personas que implementan las operaciones criptográficas, por el principio del rebaño, puede que acabe deduciendo que si estas instituciones se fían será porque el producto es robusto. Si entre esas instituciones aparece alguna con reputación y credibilidad en materia de seguridad, entonces se aplica el principio de obediencia social y probablemente demos por hecho que la seguridad del proyecto opensource es incuestionable. Y de esa forma se entra en un bucle de retroalimentación positiva donde cada vez empresas más relevantes confían en los pasos que dan otras antecesoras y extendiendo el uso de forma masiva para transformarlo en un estándar de facto en ciertos entornos. Y cuando aparece el fallo Heartbleed y la gente empieza a preguntarse cómo ha podido ser, resulta que OpenSSL es un proyecto de software libre basado en SSLeay, desarrollado por Eric Young y Tim Hudson. Dos personas han compartido su conocimiento y código en Internet para que sea utilizado y el uso se extiende tanto que cuando se da a conocer un agujero de seguridad que afecta a las versiones 1.0.1 y 1.0.1f de éste protocolo, acaba afectando a dos tercios de las comunicaciones seguras que se efectúan en Internet. La noticia OpenSSL pide ayuda también revela que muchos de estos productos software están hechos como están hechos. No voy a criticar lo que ciertos voluntarios deciden subir a Internet de forma altruista. Lo que más sorprende es ver cómo hay parte de la industria de las tecnologías de la información que incorporan esas piezas a sus entornos sin realizar ciertos controles de calidad o al menos, contribuyen a que alguien realice estas revisiones en beneficio de la "comunidad".
"En OpenSSL no se trabaja por dinero. Tampoco por la fama, que casi nunca transciende el mundillo de la tecnología, lo hacen porque creen en ello, lo ven cómo una forma de artesanía. No se concreta el sueldo mensual propuesto, pero sí considera que tendrían que rondar los 250 dólares por hora. “Que puede parecer mucho, pero no lo es tanto para un médico o un abogado. Se trata de que se ganen bien la vida”, subraya."Creo que todos hemos caído en este bucle de generación de confianza espontánea hasta que algo o alguien nos ha planteado el por qué de la situación. De nuevo las revelaciones Snowden hicieron a todos pensar si algunas de las técnicas de la NSA se basaban en la colocación de puertas traseras en determinados elementos estratégicos que permitieran controlar una determinada tecnología. Yo por ejemplo, decidí confiar en Truecrypt cuando leí a Bruce Schneier recomendando el producto como una solución de cifrado robusta. Tras el caso Snowden se empezó a rumorear quién estaba detras de esta aplicación porque no era fácil identificar a sus autores. Hoy la noticia es que hace pocos meses se ha auditado el código fuente de esta herramienta ante la sospecha de si podía ser la NSA la que estuviera detrás de este proyecto y que hubieran colocado una puerta trasera a un programa que se usa extensamente. El informe está consultable en este enlace "Informe de auditoría a TrueCrypt". Todos los usuarios Truecrypt hemos confiando en un producto sin evidencias de su robustez.
Como reflexión final cabe analizar la siguiente infografía que ilustra de una forma bella la cantidad de líneas de código de los productos software actuales. Como se puede ver, la complejidad va en aumento y es bastante probable que el "susto Heartbleed" no sea el último de este año. Existen aplicaciones y servicios que actualmente están basados en la filosofía Lego. Ellos se construyen en base a piezas ya existentes hechas por otros que se referencian y utilizan. Si el error se produce en una pieza situada muy abajo, el resto de elementos software que emplean esa pieza se ven colateralmente afectados por el problema de seguridad y la torre de naipes se cae de golpe. Heartbleed ha sido un primer buen ejemplo de reflexión.
La solución en parte es la certificación ISO 15408 que se aplica a ciertos elementos software pero también habría que ver si hay productos con Openssl certificados. Para quien quiera saber más de esta norma conocida como "Common Criteria" y que se requiere para ciertos productos software en determinados sectores, puede leer la entrada ISO 15408 y el DNI-e, PP para el desarrollo de aplicaciones (Parte I)
Un saludo y esperemos que no pasen 4 meses antes de volver a publicar ;-)
0 comentarios:
Publicar un comentario