Hackear al hacker. Roger A. Grimes

papel en Microsoft al adoptar las prácticas SDL. Me dijo: «Era una sinergia de muchas cosas distintas con las que tanto yo como otros estábamos involucrados. Empecé en el año 2001, cuando el equipo .NET daba un evento de “concienciación de seguridad” para analizar los problemas de seguridad existentes y los riesgos potenciales. Aprendimos mucho y se añadieron muchas defensas nuevas. Recuerdo que habíamos preparado camisetas especialmente para el evento con las fechas, y se produjo un gran temporal de nieve y tuvo que aplazarse. Fue muy irónico que, en un evento de código más seguro, apareciera en nuestras camisetas una fecha incorrecta. No obstante, lo que surgió de este evento fueron aprendizajes que nutrieron de algún modo el SDL. El libro de David y mío vio la luz e hizo que mucha gente pensara más en la seguridad del código. Microsoft fue atacada en 2001 por un elevado número de malware y de hackers. Los gusanos Code Red y Nimda fueron especialmente fuertes. Entonces, Bill Gates nos preguntó acerca de la naturaleza de las vulnerabilidades de software y por qué todavía existían. Yo fuí elegido como parte del equipo que se reunió con Bill Gates. Le entregué una copia de nuestro libro Writing Secure Code y, desde esa reunión, escribió su famoso memorando Trustworthy Computing. En el informe, Bill mencionaba nuestro libro, ¡el cual tuvo unas ventas estratosféricas! Acabé trabajando en la recientemente creada división Trustworthy Computing de Microsoft. Esto empezó un proceso de concienciación de seguridad adicional (también para Windows, SQL Server y muchos otros productos de Microsoft). El SDL los generó y actualizó todos, y los mejoró e hizo más eficientes. Y continúa actualizándose una vez al año».

      Le pregunté si era cierto que él y Microsoft habían publicado más información y herramientas relacionadas con la codificación segura que otras empresas. Y me dijo: «De manera inequívoca y enfática, ¡sí! Pero lo que es más importante son las herramientas y las técnicas que utilizamos en nuestro entorno de producción, en millones de líneas de código de producción, cada día. No se trata de un ejercicio académico, sino que es lo que hace una de las empresas más grandes del mundo. Y nosotros lo compartimos prácticamente todo».

      Le pregunté por qué, si los programadores de todo el mundo están mejor formados en problemas de seguridad informática, no se anuncian menos vulnerabilidades. Me contestó lo siguiente: «Bueno, seguramente hay más software con más líneas de código. Pero el verdadero problema es que los programadores todavía no están formados en codificación segura y no han entendido las amenazas básicas de seguridad. La enseñanza aún está muy atrasada en la mayoría de los casos. El otro día estaba revisando el programa de un curso de seguridad informática en la universidad y casi el 50 % del curso estaba centrado en amenazas de red de bajo nivel. No había formación en seguridad en la nube o codificación segura. Nuestras universidades todavía están formando a programadores sin muchas nociones de seguridad informática o codificación segura, que parece una broma si pensamos que estos, cuando se gradúen, crearán sistemas críticos conectados a Internet. Yo sigo buscando errores en códigos de otra gente. Cuando muestro un problema de corrupción de memoria o una vulnerabilidad de inyección SQL —algo muy básico y común—es como si hubiera hecho algo mágico o especial. Es tan difícil encontrar nuevos programadores que realmente entiendan los fundamentos de la seguridad informática que me emocionaré si el candidato como mínimo se preocupa por ello. Si el programador pone los ojos como platos cuando le hablo de problemas de seguridad informática, me siento muy feliz. Si al menos muestran interés, ya podemos enseñarles todo lo demás. Os sorprendería cómo a muchos no les preocupa este tema, y la principal razón de ello es porque todavía no se enseña. O se enseñan cosas incorrectas, como centrarse en seguridad de redes u otras pequeñeces. Las escuelas enseñan a los alumnos el funcionamiento detallado del algoritmo RSA, y no dedican el tiempo a enseñar por qué se debe utilizar, qué problemas resuelve y para qué es una buena solución. Saber cómo utilizar algo para resolver problemas de seguridad reales es mucho más importante que saber cómo funciona. Todos podemos memorizar un protocolo, pero necesitamos personas que conozcan los riesgos y piensen en soluciones. Algunos profesores y universidades lo están haciendo correctamente, como Matt Bishop de la Universidad de California, en Davis, y son los heroicos esfuerzos de Matt y otra gente lo que lo hacen posible. Él y el resto de profesores como él son los verdaderos héroes».

      Le pregunté que, si la mayoría de las universidades no preparaban de forma adecuada a nuestros programadores en este ámbito, qué es lo que podía hacer un programador por su parte. Y me dijo: «Seguir aprendiendo. Yo tengo marcada en mi agenda una hora cada día que dice “Aprender”. Y leo/codifico/pruebo durante una hora algo que no conozco, cada día. Y lo he estado haciendo durante toda mi carrera. En segundo lugar, si no te estás formando en seguridad informática de un modo formal, hazlo tú mismo. Dirígete al CVE (http://cve.mitre.org/cve/), lee sobre los errores recientes, lee sobre ellos atentamente con todo detalle. Después, escribe el código que tiene la vulnerabilidad e imagínate cómo debería ser para prevenir esta vulnerabilidad, tanto a nivel técnico como de procesamiento. ¿Cómo ha ocurrido la vulnerabilidad y se ha situado en el código en primer lugar? Y, por último, utiliza todas las lecciones aprendidas para mantener esos mismos tipos de errores fuera del propio código».

      Le pregunté qué podrían hacer la mayoría de las empresas para escribir código más seguro, además de seguir todos los consejos actuales del SDL y utilizar sus herramientas. La respuesta fue la siguiente: «Hacer que los programadores entiendan las amenazas reales, no solo la parte teórica. Y construir el proceso de seguridad en proceso de desarrollo, de forma que el código inseguro y malo no tenga cabida. En Microsoft, los llamamos Quality Gates. Un buen ejemplo (no de seguridad) es alguien que escribe código que asume que todas las direcciones IP tienen cuatro octetos. Esto significa que el código no funcionaría nunca en un entorno IPv6. Este código no puede ser enviado a nuestros repositorios de código porque una herramienta que se ejecuta automáticamente encontrará un problema y rechazará la entrada. Esto es lo que nosotros conocemos como Quality Gate. No obstante, por seguridad, lo puedes repetir en casos de inyección SQL, amenazas de seguridad de memorias y cualquier otra cosa que no quieras incluir en el código.

      »Si tuviera que elegir unas cuantas sentencias básicas relacionadas con la seguridad, estas serían:

      ■ Los desarrolladores deben aprender a no confiar nunca en los datos de entrada y a validar los que son correctos, preferiblemente mediante una biblioteca revisada y probada correctamente. Si quieres que los datos tengan una longitud de solo 20 bytes, no permitas más de 20 bytes, si quieres que sea un número, comprueba que lo sea, etc.

      ■ Diseñadores/arquitectos/gestores de programas deben aprender a modelar amenazas y comprobar que las defensas correctas se encuentran en su lugar en el sistema.

      ■ Por último, los probadores necesitan probar que los desarrolladores se equivocan al crear o facilitar herramientas que generen información maliciosa y/o deformada. El objetivo es vencer las comprobaciones de los desarrolladores, ¡si es que tienen alguna!

      »Existe mucho más en la seguridad de software que lo que he dicho, pero estas son, en mi opinión, las habilidades fundamentales relacionadas con la seguridad que todo ingeniero de software debería tener».

      Para más información sobre Michael Howard

      Si deseas más información sobre Michael Howard, consulta estos recursos:

      ■ Libros de Michael Howard

      ■ Blogs de Michael Howard: https://blogs.msdn.microsoft.com/michael_howard/

      ■ Michael Howard en Twitter: https://twitter.com/michael_howard

      8

      Perfil: Gary McGraw

      Cuando llamé a Gary McGraw para entrevistarlo, me dijo que acababa de hablar con un monje católico que paseaba cerca de su propiedad en el río Shenandoah,