Por qué debemos apoyar a los responsables de seguridad curiosos en lugar de castigarlos

El reciente informe del investigador de seguridad juvenil Bill Demircapi sobre la exposición de vulnerabilidades importantes en el software que se utilizaba en su escuela me trajo recuerdos. Recuerdo que, cuando era un niño curioso, levantaba la tapa del software para mirar debajo y ver cómo funcionaba. Y lo que es más importante, si podía romperlo. Durante décadas, los ingenieros de software han buscado mejorar y reforzar continuamente sus productos, y la comunidad de seguridad (a veces con un enfoque un poco descarado) desempeña un papel importante en la detección de fallos y posibles desastres. Antes de que lo hagan personas malintencionadas.

Pero el problema aquí es que, como reacción a lo que descubrió, recibió una leve sanción disciplinaria. Y eso ocurrió solo después de que agotara todos los medios a su alcance para ponerse en contacto con la empresa (Follett Corporation). En privado, finalmente optó por una explosión bastante pública para identificarse a sí mismo y su capacidad para violar el sistema. Sus repetidos intentos de alertar éticamente a Follett Corporation no obtuvieron respuesta alguna. El software seguía siendo vulnerable y los datos de los estudiantes, acumulados en montones, no estaban encriptados, por lo que podían exponerse fácilmente.

También encontró errores en Blackboard, un software de otra empresa. Aunque los datos de Blackboard contaban con al menos una función de cifrado, los posibles atacantes podían acceder a millones de registros y robar muchos más. Su escuela utilizaba tanto este software como los productos de Follett.

La expresión «hacker malicioso» plantea un problema.

Demircapí presentó los resultados de su investigación en la conferencia de este año. El icono Def, los detalles más divertidos de sus bromas están recibiendo el aplauso del público. Así es. De hecho, Follett Corporation se enfrentó a muchos obstáculos al principio para que se reconociera el descubrimiento que había hecho al sumergirse en libros de mala calidad, pero, agradeciendo sus esfuerzos y siguiendo sus consejos, finalmente reforzó la seguridad del software y evitó lo que podría haber sido otra crisis de filtración de datos. Además, tiene previsto ingresar en la Universidad Tecnológica de Rochester tras graduarse en el instituto, por lo que está claro que va por el buen camino para convertirse en un experto en seguridad muy solicitado.

Como responsable de seguridad, me resulta difícil no cuestionar cómo se ha gestionado esta situación. En este caso, todo ha salido bien, pero al principio se le trató como a un molesto guionista novato que se entrometía en asuntos que no le incumbían.Si se busca este caso en Google, hay artículos que se refieren a él como «hacker» (los profanos en materia de seguridad lo consideran un villano en muchos aspectos). De hecho, su enfoque (y el de muchas otras personas) ayuda a proteger los datos de forma segura.

Se necesitan personas curiosas, inteligentes y centradas en la seguridad. Y este tipo de cosas deberían ocurrir con mucha más frecuencia. En julio, más de 4000 millones de registros se vieron expuestos a violaciones de datos maliciosas solo este año. En agosto, gracias a la violación de la seguridad de la marca de moda y estilo de vida Poshmark, se pueden añadir 50 millones de dólares más a esta cifra.

Nosotros también estamos cometiendo el mismo error. Lo que es más preocupante aún es que estas vulnerabilidades, que a menudo son simples vulnerabilidades que nos provocan irritación, nos siguen haciendo caer.

El cross-site scripting y la inyección SQL no han desaparecido.

Según lo informado por Yoo Seon, Demirkapi ha confirmado que el software de participación comunitaria de Blackboard y el sistema de información estudiantil de Follets contienen errores de seguridad comunes, como scripts entre sitios (XSS) e inyección SQL, ambos de los cuales han sido señalados por los expertos en seguridad desde la década de 1990. Hemos mantenido firme su presencia por su importancia. Hace mucho tiempo, como las camisetas de colores vivos y los disquetes, ahora solo quedan como un recuerdo lejano.

Pero no es así. Y está claro que no hay suficientes desarrolladores con la concienciación necesaria en materia de seguridad como para impedir que se introduzcan estas funciones en el código. Las herramientas de escaneo y la revisión manual del código tienen un alcance limitado, y los problemas de seguridad son mucho más complejos que los de XSS y la inyección SQL. Esto se debe a que se pueden aprovechar mejor estos métodos, que requieren mucho tiempo y dinero.

Personas como Bill Demirkapi deben inspirar a los desarrolladores a crear código de mayor calidad. Con solo 17 años, comprometió dos sistemas con mucho tráfico a través de un vector de amenaza que debería haber detectado y corregido antes de confirmar el código.

Juego: ¿Cuál es la clave de la participación?

He escrito mucho sobre ello. Para explicar brevemente por qué los desarrolladores siguen sin involucrarse mucho en la seguridad, diré que no se está haciendo un gran esfuerzo a nivel organizativo o educativo para formar desarrolladores con buenos conocimientos de seguridad. Si las empresas dedican tiempo a hablar el idioma de los desarrolladores y les ofrecen formación que les motive a seguir intentándolo, además de recompensarles por su participación y crear una cultura de seguridad que les reconozca, empezarán a desaparecer esas molestas vulnerabilidades de los programas que usamos.

Demirkapi claramente tiene un interés especial en la seguridad y ha dedicado tiempo a aprender a realizar ingeniería inversa de malware, encontrar fallos y destruir cosas que, desde fuera, no parecen estar averiadas. Sin embargo, al conversar con él (y a través de las diapositivas de DEF CON), hizo una declaración interesante sobre su autoaprendizaje... Lo convirtió en un juego.

«El objetivo era encontrar algo en el software de la escuela, por lo que fue un método divertido y gamificado que me permitió aprender por mi cuenta una cantidad considerable de pruebas de penetración. Empecé a investigar con la intención de obtener más información, pero al final descubrí que la situación era mucho peor de lo que esperaba», afirmó.

No todos los desarrolladores quieren especializarse en seguridad, pero todos deben tener la oportunidad de comprenderla. En particular, los conocimientos básicos de los desarrolladores que gestionan grandes cantidades de datos confidenciales actúan casi como una «licencia para escribir código» dentro de la organización. Si todos los desarrolladores pudieran corregir las vulnerabilidades de seguridad más simples antes incluso de crearlas, estaríamos en una posición mucho más segura frente a los desarrolladores que buscan causar estragos.

¿Le interesa la educación gamificada? Eche un vistazo a la serie Coders Conquer Security en el siguiente enlace. XSS y inyección SQL.