Roger A. Grimes - Hackear al hacker

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».

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

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, en Virginia. En unos segundos, me estaba hablando de las complejidades de la seguridad informática. Este tipo de paradojas sobrenaturales han acompañado a McGraw durante toda su vida. Empezó programando su propio ordenador, un Apple II+, en 1981, cuando tenía 16 años. Terminó yendo a la universidad para obtener la licenciatura en filosofía y, por el camino, se convirtió en un músico de formación clásica. Incluso tocó en dos ocasiones en el Carnegie Hall. Actualmente, continúa siendo uno de los expertos en seguridad informática del mundo y le gusta cocinar, la jardinería y crear nuevos cócteles.

Le pregunté a McGraw cómo pasó de ser un estudiante de filosofía en la Universidad de Virginia a interesarse por la seguridad informática. Me dijo que le interesaba la filosofía de la mente, lo que le permitió realizar un curso denominado «Ordenadores, mente y cerebro» en la Universidad de Virginia, impartido por Paul Humphreys. Pensaba que las ideas que el profesor Humphreys enseñaba eran erróneas, pero empezó a pensar con más profundidad sobre la filosofía de la mente y la inteligencia artificial. Humphreys terminó aportando ideas de la industria y del ganador del Premio Pulitzer americano, el Dr. Douglas Hofstadter, durante la clase, y eso cambió toda su carrera. No realizó ningún curso de informática hasta la universidad, pero se enamoró de la programación en 1981, cuando era niño. Bajo la tutela de Hofstadter, en la Universidad de Indiana, obtuvo un doble doctorado en Ciencias del conocimiento e Informática. Incluso terminó escribiendo el Capítulo 10 del primer libro que se vendió en Amazon: el libro de Hofstadter titulado Fluid Concepts and Creative Analogies: Computer Models of the Fundamental Mechanisms of Thought [Conceptos fluidos y analogías creativas: modelos informáticos de los mecanismos fundamentales del pensamiento].

Cuando terminó la universidad, entró en una empresa de 7 personas que más tarde se convirtió en Cigital ( https://www.cigital.com/). Cigital ganó una importante beca DARPA para investigación en seguridad informática y lo contrataron para trabajar en este proyecto. Cigital fue creciendo hasta los 500 empleados hasta que fue vendida a Synopsis en 2016. Actualmente, son 1.000 personas en la división de seguridad de software de la empresa más grande dedicada a mejorar software de un modo significativo.

Mi primer gran recuerdo del trabajo y el nombre de McGraw es cuando él y Ed Felten asumieron la seguridad del lenguaje de programación Java, escribieron un libro y detectaron decenas de vulnerabilidades de seguridad. En aquel momento, fue algo increíble, porque Sun Microsystems había hecho de Java supuestamente un lenguaje de programación muy seguro, pues sabían que estaría muy basado en la web y sería constantemente atacado por hackers . Java surgió en 1995 y Sun presumió desde sus inicios de que era un lenguaje de programación muy seguro. Lo habían construido algunos de los grandes magos de los lenguajes de programación, entre ellos, Guy Steele y Bill Joy. La mayoría de los expertos en seguridad informática se preguntaban si realmente era tan seguro como pensaban en Sun o si resultaría ser otra de las promesas de seguridad sobrevaloradas. Y resultó ser esto último. Tras algunas promesas iniciales, Java produjo algunas de las piezas de software más plagadas de errores del mundo, McGraw fue uno de los mejores en detectar vulnerabilidades de Java y él y Felten fueron el origen del análisis de Java para detectar errores de seguridad. En una conferencia, McGraw coincidió con el coautor de sus libros, Ed felten, y esta conferencia apareció en el primero de muchos otros libros. Muchos de los libros de McGraw se convirtieron en éxitos de ventas (uno de ellos, Exploiting Software , incluso llegó a ocupar el puesto 16 del ranking de ventas de Amazon, que es una gran cifra para cualquier libro de informática, y mucho más para uno de seguridad informática).

McGraw continuó pensando en seguridad del software y en dónde acudir para aprender a construir algo más seguro. Se preguntaba cómo el resto de nosotros, programadores «normales», íbamos a crear software seguro si los mejores magos (como Bill Joy y Guy Steele) no lo habían podido hacer adecuadamente. Se preguntaba qué iba mal en el proceso y por qué iba mal. Se dio cuenta de que todo el software y todos los programas tenían que ser diseñados y escritos desde cero con la seguridad en mente. Casi al mismo tiempo, se le ocurrió su Trinity of Trouble , que hablaba sobre por qué la seguridad informática seguía siendo interesante y complicada. Basicamente, si está en red, es compleja y extensible, siempre va a interesar desde un punto de vista de la seguridad y será difícil de proteger. Desafortunadamente, Java tenía estas tres características, y de qué manera, aunque su complejidad era probablemente el aspecto más difícil contra el cual luchar.