Heartbleed, la marca de un bicho e Internet de las cosas

Una semana después, y el Error Heartbleed El ciclo de noticias está llegando a su fin sin que se conozca ningún informe de daños catastróficos. ¿Un caso de experto en seguridad, lobo llorón? No, afirma el criptógrafo y experto en seguridad Bruce Schneier, conocido por sus respuestas mesuradas y reflexivas a las vulnerabilidades, y la calificó de «catastrófica». HBR habló con Schneier sobre lo que él considera una respuesta sorprendentemente eficaz a Heartbleed, lo difícil que es la seguridad a causa de los humanos y por qué se alegra de que Heartbleed no se haya descubierto en un futuro próximo, cuando el Internet de las cosas dificultará mucho la corrección de errores.

No es conocido por su hipérbole, pero en su blog calificó Heartbleed de «catastrófico» y dijo que, en una escala del 1 al 10, es un 11. ¿Qué lo hace tan malo?
Heartbleed es una vulnerabilidad que afectó a un enorme número de servidores de Internet y los afectó de formas impredecibles pero potencialmente desastrosas. Convertir la vulnerabilidad en un código de ataque viable era trivial (basta con unas cuantas líneas de código de secuencias de comandos) y se podía ejecutar sin dejar rastro. Robar la clave SSL de un sitio es un problema enorme y que afecta a todos los usuarios del sitio. Arreglarlo era difícil y requería varios pasos y coordinación entre las personas. En ese sentido, la solución era tanto técnica como procedimental. Básicamente, fue muy malo porque había mucha incertidumbre. Ni siquiera sabíamos cómo cuantificar el riesgo.

¿Ha cambiado algo en su opinión sobre lo grave que está?
Sí y no. Se sugiere un sitio puede que no sea tan fácil conseguir claves SSL privadas como pensábamos, lo que lo haría menos grave. Y el proceso de parchear la vulnerabilidad y regenerar las claves y los certificados se está llevando a cabo sin problemas de lo previsto. Pero estamos descubriendo la vulnerabilidad en sistemas de hardware que no se pueden parchear y aún no hemos visto cómo los delincuentes la han aprovechado.

Parece que la introducción de este error en el sistema de cifrado OpenSSL fue un error honesto. ¿Podemos permitirnos cometer errores honestos al codificar el cifrado?
Por desgracia, todo siempre corre el riesgo de cometer errores. Las personas son falibles y todo lo que hacemos involucra a personas.

Pero debemos acercarnos lo más que podamos a eliminar esos errores. Cuando los sitios web dicen que son seguros, ¿qué podemos esperar que signifique eso?
Podemos esperar que sea más marketing que cualquier otra cosa. Secure no es una propiedad binaria que se activa y desactiva. Es relativo y situacional. Me siento seguro en mi casa, a pesar de que es vulnerable. Me siento seguro en los aviones, a pesar de que de vez en cuando se estrellan. Los sitios web no son diferentes.

¿La gente entiende este riesgo como lo hace con los demás? ¿Son conscientes de los peligros de estar conectados de forma tan ubicua?
La gente definitivamente no entiende el SSL ni lo que protege y lo que no protege. Pero, en general, la seguridad en Internet es bastante buena. Internet es sorprendentemente seguro. Podemos trabajar y jugar en Internet sin muchos problemas. Por supuesto que hay muchos delitos cibernéticos, pero son menores.

Las redes sociales parecen el medio perfecto para provocar reacciones exageradas e histeria por un error como este. Sorprendentemente, no ha ocurrido. Todo se ha sentido bastante ordenado y mesurado. ¿Por qué es eso?
En la comunidad de seguridad, por lo general, se nos da muy mal comunicar información sobre las vulnerabilidades al público en general. Heartbleed ha sido una excepción; los investigadores hicieron un excelente trabajo al explicar el problema y la solución. Tenían un sitio web ingenioso e informativo. Y le pusieron a la vulnerabilidad un nombre y un logotipo guays. Ese logotipo funcionó; todos los medios de comunicación lo usaron y dio a la gente un recordatorio visual de la historia. Creó una amplia conciencia de una manera inteligente.

En otras palabras, era de marca.
Sí. Existe el riesgo de que nos acusen de «lobo llorón». Si no hay sangre en las calles o aviones chocando en el aire, la gente se preguntará por qué tanto alboroto, como el año 2000. Si pone logotipos en todas las vulnerabilidades, la gente las ignorará y desconfiará de sus motivos. Pero es como las tormentas. Los malos reciben nombres por una razón.

¿Qué más aprendemos de Heartbleed?
Hemos aprendido lo difícil que es coordinar los aspectos humanos de un sistema de seguridad. Estamos descubriendo que no tenemos la infraestructura necesaria para revocar rápidamente millones de certificados y emitir otros nuevos. Estamos descubriendo que parte de nuestro software de código abierto fundamental lo mantienen voluntarios que tienen una vida ajetreada y que, a menudo, nadie más evalúa la seguridad de ese software. Estamos aprendiendo lo complicado que es el proceso de revelar una vulnerabilidad de esta magnitud. Algunas empresas más grandes recibieron un aviso previo para poder arreglar sus sitios. Los que no recibieron un aviso anticipado están comprensiblemente molestos, pero si todo el mundo recibe un aviso anticipado, ya no es un aviso previo. Estamos aprendiendo lo difícil que es crear seguridad con la participación de las personas.

En un sistema distribuido como Internet, ¿cómo podemos garantizar la erradicación casi total de los sistemas vulnerables?
No podemos, pero podemos supervisar el progreso. Podemos escanear todo Internet y hacer una lista de sitios vulnerables en menos de media hora. Muchos grupos están haciendo esto y nos estamos enterando de que la mayoría de los sitios han parcheado y vuelto a proteger sus sistemas. Me preocupan menos y más los sistemas integrados, como los módems de cable y los enrutadores, que no tienen medios de actualización. Con dispositivos como esos, arreglar la vulnerabilidad implica una papelera, una tarjeta de crédito y un viaje a la tienda de ordenadores.

Más allá de los módems de cable y los enrutadores, está el Internet de las cosas. ¿Deberíamos pensar en Heartbleed en el contexto de ese fenómeno?
Sí. Hace poco escribí un ensayo eso hablaba de la dificultad de proteger todos los sistemas informáticos integrados de bajo coste que se van a hacer comunes en nuestras vidas en los próximos años. Son dispositivos que se fabrican a bajo precio con márgenes muy bajos, y las empresas que los fabrican no tienen la experiencia necesaria para asegurarlos. Heartbleed habría sido mucho peor en un mundo de termostatos, refrigeradores, coches y todo lo demás con acceso a Internet, y ese es el mundo al que nos dirigimos.

Parece que vamos a necesitar alguna forma de clasificar la infraestructura en crítica y no crítica. ¿O tendremos que licenciar a las personas a las que se les permite jugar con códigos críticos, como OpenSSL? ¿Estamos avanzando hacia un entorno regulado más profundamente? ¿Deberíamos estarlo?
Gran parte de nuestra infraestructura informática crítica está en manos privadas, tanto corporativas como comunitarias. Tener normas en torno a este código tiene valor, pero también conlleva riesgos. Lo mejor es crear sistemas resilientes que puedan sobrevivir mejor a cosas como Heartbleed. Y recuerde que se trata de un hecho singular. No es que este tipo de cosas hayan estado sucediendo todos los meses, o incluso todos los años. Esta es la peor vulnerabilidad que Internet ha tenido que capear en mucho tiempo.

Cuando se entere de que OpenSSL, que se considera infraestructura crítica, está siendo desarrollado por cuatro desarrolladores con financiación insuficiente, ¿le sorprende? ¿Debería sorprendernos saber que esta pieza fundamental de seguridad es un proyecto de codificación con problemas económicos y un tanto descuidado?
Sí, fue sorprendente. Y de nuevo, aquí es donde la resiliencia es importante. Pasará mucho tiempo antes de que seamos lo suficientemente sofisticados como para prevenir este tipo de vulnerabilidades. Tenemos que aprender a prosperar a pesar de ellos.