para muchos de sus descubrimientos.
Sistemas operativos más seguros
La mayoría de los sistemas operativos no solo han sido codificados por programadores formados en el SDL que utilizan por defecto lenguajes de programación más seguros, sino que también incluyen defensas integradas contra los vectores de explotación más comunes. La mayoría de los sistemas operativos actuales más populares incluyen defensas de memoria especialmente diseñadas y protegen las áreas más críticas del sistema operativo. Algunos también incluyen software para evitar el desbordamiento de búfer, software antimalware y cortafuegos; todo ello ayuda a limitar errores explotables o sus consecuentes daños.
Protecciones de terceros y complementos del fabricante
Existen miles de programas capaces de defender un sistema informático contra vulnerabilidades de software desconocidas previamente con un mínimo de éxito. Algunos los ofrece el fabricante de forma gratuita o de pago y otros proceden de terceros. Los programas que prometen la detección y detención de nuevas explotaciones son muy comunes y, aunque no son nunca perfectos, pueden reducir significativamente el riesgo de nuevas amenazas. Uno de mis tipos favoritos de software de defensa son los denominados de control de aplicación o lista blanca. Estos programas no detienen la explotación inicial, sino que evitan o complican que los hackers o programas maliciosos provoquen daños adicionales.
El software perfecto no erradicará todos los males
Ninguna defensa puede superar un software que ha sido codificado de forma más segura con menos errores explotables desde el principio. Sin embargo, el software perfecto y sin errores es imposible y no acabaría con todo el hackeo aunque esto fuera posible. Desafortunadamente, las vulnerabilidades de software no son nuestro único problema. Los programas troyanos funcionan simplemente haciendo que el usuario ejecute un programa malicioso. Muchos hackers y programas maliciosos explotan las capacidades inherentes y, por otro lado, legítimas de datos, lenguajes de programación y otros componentes para hacer cosas malas. Y la ingeniería social puede llevar a cabo lo que el software no es capaz de hacer.
Aún así, nadie discute que unos programas más seguros no sean de gran ayuda. En los Capítulos 7 y 8 se presentan dos expertos que han dedicado sus vidas a perfeccionar software. El Capítulo 7 presenta a Michael Howard, quien popularizó prácticas de codificación más seguras, y el Capítulo 8 se centra en Gary McGraw, uno de los mejores buscadores de errores que existen.
7
Perfil: Michael Howard
Michael Howard es contagioso. Es un gran educador, un ponente enérgico y, después de aproximadamente 20 años, sigue tan apasionado de su especialización en seguridad informática, la codificación segura, como lo era en sus inicios. Resulta difícil estar con él más de unos minutos sin desear hacer el mundo más seguro en cada línea de código. Fue conocido a nivel mundial como coautor del libro Writing Secure Code (Escribir código seguro) junto a David LeBlanc, así como por haber sido una parte importante de la razón por la cual Microsoft se dedica ampliamente a escribir código más seguro. Howard, originario de Nueva Zelanda pero establecido actualmente en Austin, Texas, ha colaborado en la redacción de muchos libros sobre la escritura de código más seguro y es un bloguero activo.
NOTA David LeBlanc, coautor con Howard en Writing Secure Code, es otro especialista en seguridad con visión de futuro. Es el responsable de que Microsoft Office sea significativamente más seguro y ha creado un modelo de seguridad para navegadores que han acabado utilizando Google, Adobe y Microsoft.
Le pregunté a Howard cómo empezó en esto de la seguridad informática. Su respuesta fue la siguiente: «Estaba trabajando en las primeras versiones de Windows NT para Microsoft. Me dedicaba a tareas de bajo nivel como control de acceso, criptografía y GINA personalizadas (interfaces gráficas que solían ser la manera de iniciar sesión en Microsoft Windows y otros proveedores de autenticación). Esto realmente me permitió empezar a pensar en la seguridad como una característica más. Sobre el año 2000, estaba claro que las características de seguridad no hacen a un producto seguro, por lo que decidí que me tenía que centrar en funcionalidades seguras, que son una disciplina diferente».
Le pregunté cómo empezó el SDL en Microsoft. Me dijo: «Con el tiempo, varias prácticas relacionadas con la seguridad aprendidas por los equipos de SQL Server, Office, Windows y .NET Framework y otros evolucionaron hacia el ciclo de vida de desarrollo de seguridad (SDL). El SDL ayudó a popularizar el código seguro y el movimiento de diseño seguro y actualmente es la fuerza que dirige la mayor parte de las empresas que mejor protegen su software ».
Le pregunté si el SDL fue una pequeña mejora de algo que había leído o si lo había construido de la nada sin ninguna referencia previa. Me contestó: «Todos construimos sobre el trabajo de otros, pero la mayor parte del SDL surgió de acciones y aprendizaje. Lo que funciona se mantiene y lo que no funciona o no es completamente práctico se tira. A veces me pregunto si alguno de los modelos académicos ha sido probado en un entorno de producción alguna vez, con plazos, requisitos de desempeño, tiempo para sacarlo al mercado, aspectos económicos, requisitos de compatibilidad anteriores, etc.
»En ese momento, había una enorme escuela de pensamiento que creía que si se puede aumentar la calidad general del código también se aumentará directamente la seguridad del código. Pero yo aún no he visto ninguna evidencia empírica de ello. Puedes hacer un código SQL funcional que pase todas las pruebas de funcionalidad, pero podría estar plagado de vulnerabilidades de inyección de SQL. Si nunca has aprendido qué es la vulnerabilidad de inyección de SQL, todo cuanto verás será un código perfecto, que hace lo que se supone que tiene que hacer. Un sistema seguro solo hace lo que se supone que tiene que hacer y nada más, y esta es la “funcionalidad extra” que viene con la vulnerabilidad de inyección de SQL que lo hace inseguro».
Le pregunté cuál era su 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
