Por qué necesitamos apoyar, no castigar, a las mentes curiosas de seguridad

Informes recientes del investigador de seguridad adolescente, Bill Demirkapi, exponiendo las principales vulnerabilidades en el software utilizado por su escuela sin duda le trajo algunos recuerdos. Recuerdo que cuando era un niño curioso, levanté el capó del software para echar un vistazo y ver cómo funcionaba todo y, lo que es más importante, si podía descifrarlo. Durante décadas, los ingenieros de software han buscado la mejora continua y el fortalecimiento de sus productos, y la comunidad de seguridad (aunque con un enfoque un poco descarado, a veces) desempeña un papel importante a la hora de descubrir fallos y posibles desastres, esperemos que antes de que un villano haga lo mismo.

Sin embargo, el problema aquí es que, en respuesta a sus descubrimientos, fue suspendido levemente de la escuela. Y eso solo ocurrió cuando agotó todas las vías para contactar con la empresa (Corporación Follett) en privado, y finalmente optó por una explosión bastante pública para identificarse a sí mismo y a su capacidad de infringir su sistema. Sus repetidos intentos de advertir éticamente a Follett Corporation quedaron sin respuesta, mientras que el software seguía siendo vulnerable y montones de datos de estudiantes quedaban expuestos con bastante facilidad, ya que gran parte de ellos no estaban cifrados.

También buscó errores en el software de otra empresa: Blackboard. Si bien los datos de Blackboard al menos estaban cifrados, los posibles atacantes podrían haber accedido a millones de registros más y haberse apoderado de ellos. Su escuela utilizaba tanto este software como el producto de Follett.

La narrativa del «hacker malvado» es problemática.

Demirkapi presentó sus hallazgos en la ICONO DE DEFINICIÓN, y los detalles más traviesos de sus travesuras reciben el aplauso del público. La verdad es que, aunque al principio estaba en los libros malos y se enfrentaba a muchos obstáculos para que se reconocieran sus descubrimientos, Follett Corporation le agradeció sus esfuerzos y siguió sus consejos para, en última instancia, hacer que su software fuera más seguro y evitar que la crisis se convirtiera en otra estadística de violación de datos. También asistirá al Instituto de Tecnología de Rochester después de terminar la escuela secundaria, por lo que está claro que va por buen camino para convertirse en un especialista en seguridad muy solicitado.

Como agente de seguridad, es difícil no estar en desacuerdo con la forma en que se manejó esta situación. Aunque en este caso todo va bien, al principio lo trataron como si fuera un fastidioso guionista metiéndose las narices donde no le correspondía. Una búsqueda en Google sobre el incidente arroja artículos en los que se lo califica de «hacker» (en la mente del experto en seguridad, esto lo posiciona como el villano de muchas maneras), cuando en realidad su enfoque (y el de muchos otros) es lo que ayuda a mantener nuestros datos seguros.

Necesitamos personas curiosas, inteligentes y centradas en la seguridad que miren de manera clandestina, y necesitamos que suceda con mucha más frecuencia. A partir de julio, más de cuatro mil millones de registros han estado expuestos a violaciones de datos maliciosas solo este año. Se podrían añadir otros cincuenta millones a esa cifra, gracias a la irrupción en agosto de una marca de moda y estilo de vida, Poshmark.

Cometemos los mismos errores y, lo que es aún más preocupante, a menudo se trata de vulnerabilidades simples que nos ponen la palma de la mano y nos hacen tropezar.

Las secuencias de comandos entre sitios y la inyección de SQL no han desaparecido.

Según lo informado por CABLEADO, Demirkapi descubrió que el software Blackboards Community Engagement y el Folletts Student Information System contenían errores de seguridad comunes, como las secuencias de comandos entre sitios (XSS) y la inyección de SQL, los cuales han sido un pelo en la lengua de los especialistas en seguridad desde la década de 1990. Hemos soportado su existencia durante un De Verdad hace mucho tiempo, y al igual que las camisetas y disquetes de Hypercolor, ya deberían ser un recuerdo lejano.

Sin embargo, no lo son, y está claro que no hay suficientes desarrolladores que demuestren una conciencia de seguridad adecuada para impedir su introducción en su código. Las herramientas de escaneo y las revisiones manuales del código no sirven para mucho, y existen problemas de seguridad mucho más complejos que los de la inyección de XSS y SQL, por lo que estas costosas y lentas medidas podrían aprovecharse mejor.

Personas como Bill Demirkapi deberían inspirar a los desarrolladores a crear un estándar de código más alto; con tan solo 17 años, violó dos sistemas de alto tráfico mediante vectores de amenazas que deberían haberse detectado y corregido incluso antes de que se cometiera el código.

Gamificación: ¿la clave del compromiso?

Tengo escrito mucho explica por qué los desarrolladores siguen desinteresados en gran medida con la seguridad, y la respuesta breve es que no se está haciendo mucho a nivel organizativo ni educativo para fomentar que los desarrolladores se preocupen por la seguridad. Cuando las empresas dedican tiempo a crear una cultura de seguridad que premie y reconozca el compromiso, lo que incluye implantar una formación que hable el idioma de los desarrolladores y los motive a seguir intentándolo, estas molestas reliquias de vulnerabilidad comienzan a desaparecer del software que utilizamos.

Obviamente, Demirkapi tiene un interés extracurricular en la seguridad, y se ha tomado el tiempo para aprender a aplicar ingeniería inversa al malware, detectar defectos y, bueno, romper cosas que no parecen rotas desde fuera. Sin embargo, al hablar con VICIO (y a través de sus diapositivas de DEF CON), hizo una interesante declaración sobre su autoeducación... la gamificó:

«Con el objetivo de encontrar algo en el software de mi escuela, fue una forma divertida y gamificada de enseñarme una cantidad significativa de pruebas de penetración. Aunque empecé mi investigación con la intención de obtener más información, acabé descubriendo que las cosas estaban mucho peor de lo que esperaba», explica.

Si bien no todos los desarrolladores querrán especializarse en seguridad, todos deberían tener la oportunidad de tomar conciencia de la seguridad, ya que lo básico sirve casi como una «licencia para programar» dentro de una organización, especialmente aquellas que controlan una gran cantidad de nuestros datos confidenciales. Si todos los desarrolladores pueden corregir las brechas de seguridad más sencillas incluso antes de que se escriban, estaremos en una posición mucho más segura frente a quienes buscan causar estragos.

¿Tienes curiosidad por la formación gamificada? Consulta nuestra serie Coders Conquer Security en XSS y Inyección SQL.