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

Los recientes informes sobre el investigador de seguridad adolescente, Bill Demirkapi, que ha sacado a la luz importantes vulnerabilidades en el software utilizado por su escuela, me han traído algunos recuerdos. Recuerdo ser el niño curioso que levantaba el capó del software para echar un vistazo por 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 la mejora continua y la fortificación de sus productos, y la comunidad de seguridad (aunque un poco descarada en su enfoque, a veces) desempeña un papel importante en el descubrimiento de defectos y desastres potenciales, con suerte antes de que un malvado haga lo mismo.

Sin embargo, la cuestión aquí es que en respuesta a sus descubrimientos, llevó una suspensión menor de la escuela. Y eso sólo ocurrió después de que agotara todas las vías para contactar con la empresa(Follett Corporation) de forma privada, optando finalmente por una explosión bastante pública para identificarse a sí mismo y su capacidad para violar su sistema. Sus repetidos intentos de advertir éticamente a Follett Corporation quedaron sin respuesta, mientras que el software seguía siendo vulnerable y las montañas de datos de los estudiantes quedaban expuestas con bastante facilidad, ya que gran parte de ellos estaban sin encriptar.

También buscó fallos en el software de otra empresa: Blackboard. Aunque los datos de Blackboard al menos estaban encriptados, los posibles atacantes podrían haber accedido a millones de registros más. Tanto este software como el producto de Follett estaban en uso en su escuela.

La narrativa del "hacker malvado" es problemática.

Demirkapi presentó sus descubrimientos en la DEF CON de este año, y los detalles más traviesos de sus travesuras fueron aplaudidos por el público. Con razón, en realidad: aunque al principio estuvo en la picota y tuvo que enfrentarse a muchos obstáculos para que se reconocieran sus descubrimientos, se dice que Follett Corporation agradeció sus esfuerzos y siguió sus consejos, haciendo finalmente su software más seguro y evitando la crisis de convertirse en otra estadística de violación de datos. Además, después de terminar el bachillerato, asistirá al Instituto Tecnológico de Rochester, por lo que está claro que va por el buen camino para convertirse en un especialista en seguridad muy demandado.

Como persona que se dedica a la seguridad, es difícil no criticar la forma en que se manejó esta situación. Aunque en este caso todo acaba bien, al principio se le trató como un molesto script kiddie que metía las narices donde no debía. Si se busca el incidente en Google, hay artículos que se refieren a él como un "hacker" (en la mente del profano en seguridad, esto lo sitúa como el villano en muchos sentidos), cuando en realidad su enfoque (y el de muchos otros) es lo que ayuda a mantener nuestros datos seguros.

Necesitamos personas inquisitivas, inteligentes y centradas en la seguridad que miren bajo el capó, y necesitamos que esto ocurra mucho más a menudo. Hasta julio, más de cuatro mil millones de registros han sido expuestos en violaciones de datos maliciosas sólo este año. Se pueden añadir otros cincuenta millones a esta cifra, gracias a la filtración de agosto de la marca de moda y estilo de vida Poshmark.

Cometemos los mismos errores y, lo que es más preocupante, a menudo son simples vulnerabilidades que nos hacen caer en la trampa.

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

Tal y como informa WIRED, Demirkapi ha descubierto que el software Blackboards Community Engagement y el sistema de información estudiantil Folletts contienen errores de seguridad comunes como el cross-site scripting (XSS) y la inyección SQL, que han sido pelos en la lengua de los especialistas en seguridad desde la década de 1990. Hemos soportado su existencia durante mucho tiempo, y al igual que las camisetas Hypercolor y los disquetes, ya deberían ser un recuerdo lejano.

Pero no lo son, y está claro que no hay suficientes desarrolladores que demuestren una concienciación de seguridad adecuada para detener la introducción de los mismos en su código. Las herramientas de escaneo y las revisiones manuales del código no pueden hacer mucho, y hay problemas de seguridad mucho más complejos que el XSS y la inyección SQL, en los que estas medidas costosas y que consumen mucho tiempo podrían utilizarse mejor.

Personas como Bill Demirkapi deberían inspirar a los desarrolladores a crear un estándar de código más alto; con tan sólo 17 años, violó dos sistemas de alto tráfico mediante vectores de amenaza que deberían haber sido detectados y corregidos antes de que el código fuera comprometido.

Gamificación: ¿La clave del compromiso?

He escrito mucho sobre por qué los desarrolladores siguen sin comprometerse con la seguridad, y la respuesta corta es que no se está haciendo mucho a nivel organizativo, ni educativo, para fomentar desarrolladores conscientes de la seguridad. Cuando las empresas se toman el tiempo necesario para crear una cultura de seguridad que recompense y reconozca el compromiso, incluyendo la implementación de una formación que hable el lenguaje de los desarrolladores y les motive a seguir intentándolo, estas molestas reliquias de vulnerabilidad empiezan a desaparecer del software que utilizamos.

Demirkapi obviamente tiene un interés extracurricular en la seguridad, y se ha tomado el tiempo para aprender cómo hacer ingeniería inversa de malware, detectar fallos y, bueno, romper cosas que no parecen rotas desde el exterior. Sin embargo, al hablar con VICE (y a través de sus diapositivas de la 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 "gamificada de enseñarme a mí mismo una cantidad significativa de pruebas de penetración. Aunque empecé mi investigación con la intención de aprender más, acabé descubriendo que las cosas eran mucho peores de lo que esperaba", dijo.

Aunque no todos los desarrolladores van a querer especializarse en seguridad, cada uno de ellos debería tener la oportunidad de tomar conciencia de la seguridad, con los fundamentos que sirven casi como una "licencia para codificar" dentro de una organización, especialmente aquellos que controlan masas de nuestros datos sensibles. Si los agujeros de seguridad más simples pueden ser parcheados por todos los desarrolladores antes de que se escriban, estaremos en una posición mucho más segura contra aquellos que buscan causar estragos.

¿Tiene curiosidad por la formación gamificada? Consulte nuestra serie Coders Conquer Security sobre XSS y inyección SQL.