He oído hablar de empresas de seguridad que consultan sobre la seguridad de los sistemas de un cliente. Todas las personas que conozco en este campo son ingenieros de redes, pero sé que los programadores también se involucran en la seguridad. ¿Qué hacen realmente los programadores de seguridad que realizan auditorías / consultorías? ¿Literalmente pasan por la base de código buscando cada vulnerabilidad en los sistemas heredados de las personas? Siempre he asumido que eso es lo que hicieron, pero parece que esto sería muy poco confiable y no haría mucho más que proporcionar una falsa sensación de seguridad. Nota: No estoy hablando de programadores que escriben algoritmos de cifrado ni nada por el estilo, solo aquellos relacionados con las auditorías / consultas de seguridad de software.
fuente
Respuestas:
Francamente, tratamos de no pasar por su base de código, tratamos de escribir herramientas para hacer eso por nosotros.
Primero, la teoría. La seguridad es un requisito de un sistema de software, por lo que, al igual que otros requisitos (funcionalidad, usabilidad, accesibilidad, rendimiento, etc.), debe considerarse en cada etapa del flujo de trabajo de ingeniería de software, desde la recopilación de requisitos hasta la implementación y el mantenimiento. De hecho, esto es posible, y existe una guía para ayudar a los equipos de proyectos de software a hacer eso. Aunque trabajo principalmente con desarrolladores de iOS, mi descripción favorita del "ciclo de vida de desarrollo seguro" es de Microsoft Press .
En este modelo, la seguridad de la aplicación comienza cuando intentamos obtener los requisitos de nuestros usuarios. Necesitamos descubrir sus preocupaciones de seguridad y privacidad, lo cual no es fácil porque somos los expertos, no los usuarios, y si comprenden sus requisitos de seguridad, es posible que les resulte difícil expresarlos. También necesitamos descubrir a qué riesgos estará expuesto el software en la implementación y a qué nivel de riesgo es aceptable.
Diseñamos nuestra aplicación teniendo en cuenta esos requisitos. Escribimos el código con el objetivo de satisfacer esos requisitos y evitar riesgos adicionales asociados con errores de seguridad a nivel de código. Probamos el software para asegurarnos de que nuestro modelo de seguridad sea coherente con lo que realmente construimos, luego implementamos el software de una manera que coincida con los supuestos que hicimos sobre el entorno cuando diseñamos la cosa. Finalmente, brindamos soporte y mantenimiento que ayudan al usuario a operar el software de una manera consistente con sus requisitos de seguridad, y que les permite (y a nosotros) reaccionar a los nuevos cambios en los riesgos presentados.
Ok, mucho para la teoría. En la práctica , por razones que se explican muy bien (aunque de manera no técnica) en Geekonomics y que se deben principalmente a la forma en que las empresas de software están motivadas, la mayoría de las cosas anteriores no suceden. En cambio, obtenemos esto. Los desarrolladores:
Entonces, lo que la mayoría de las personas de seguridad de aplicaciones realmente están haciendo es, como usted dice, encontrar errores. Esta es realmente una revisión de código glorificada, pero es una revisión de código altamente enfocada llevada a cabo por personas que son expertos en el tipo de errores que esta revisión está buscando, por lo que todavía hay valor en obtener ayuda externa para hacerlo. Esa es una regla general de las compras, por supuesto: siempre haga que alguien más pruebe que no estuvo involucrado en hacer la cosa.
Si aceptamos lo anterior como cierto, se deduce que las personas que toman decisiones de compra probablemente equiparen a "agente de seguridad capaz" con "encuentra muchos errores". Aquellos que hacen que las computadoras hagan el trabajo por ellos encontrarán más errores que aquellos que no lo hacen, por lo que, por supuesto, dependen en gran medida de las herramientas de análisis estático y tratarán de pasar más tiempo extendiendo las herramientas que codificando problemas específicos para clientes específicos. Luego concluimos que es más probable que las personas de seguridad de aplicaciones escriban herramientas para leer código que leer código.
** Advertencia: lo que queda es opinión personal y especulación **
La realidad está rota. Notará que la teoría de la seguridad del software tenía que ver con identificar y responder al riesgo de depender de un sistema de software, mientras que la práctica consistía en encontrar la mayor cantidad posible de errores. Claro, eso todavía reducirá el riesgo, pero solo como un efecto secundario. El objetivo del juego se ha vuelto menos importante que "ganar" el juego, por lo que las reglas se cambian para que sea más fácil ganar.
¿Qué puede hacer usted como desarrollador de software al respecto? Juega el juego según sus reglas originales. Encuentre a alguien en su equipo (preferiblemente en realidad en su equipo, en lugar de un contratista, de modo que estén motivados para proporcionar resultados a largo plazo en lugar de una victoria rápida) que comprenda la importancia de la seguridad y capacite a los bejeezus. Dele a esa persona la responsabilidad de dirigir al equipo para proporcionar la seguridad de extremo a extremo descrita al comienzo de mi respuesta.
Además, dele a esa persona la autoridad para seguir adelante . Si un diseño no expresa los requisitos de seguridad, debe ser revisado. Si la implementación no cumple con los requisitos de seguridad, no debe liberarse . Su persona de seguridad puede hacer la llamada del juicio, pero se le debe permitir actuar en ese juicio. Me doy cuenta de que esto puede sonar como el tipo de seguridad que dice "la seguridad OMFG es lo más importante", pero eso no es lo que quiero decir. Si su producto tampoco cumple con los requisitos de funcionalidad, usabilidad o rendimiento, tampoco debe liberarlo.
¿Por qué querrías hacer eso? Debería ser más barato: todos hemos visto (y probablemente citado por un representante barato de +10) la tabla de Código Completo donde los defectos se vuelven más caros cuanto más tarde los arregles, ¿verdad? Los defectos de seguridad también son defectos. Siendo las reglas del juego del mundo real, la mayoría de ellas son problemas en los requisitos que se fijan en el mantenimiento. ¿Eso es barato?
Ok, ahora ¿qué puedo yo como una pistola de seguridad para alquilar hacer al respecto? Bueno, resulta que también puedo negarme a jugar según las reglas enmendadas. Puedo decirle a los desarrolladores que se trata de reducir el riesgo, que esto se puede hacer en cada etapa, y luego puedo ayudarlos a hacerlo.
fuente
Después de 15 años de ejecutar programas de garantía de seguridad contra aplicaciones, entornos, sistemas, etc. pequeños y extremadamente grandes, diría que hay un poco de todo. En mis equipos siempre he tenido algunos que son programadores incondicionales.
En el nivel detallado, parte de esto se reduce a una revisión muy profunda del código; como ejemplo, actualmente estoy trabajando en una base de código de línea multimillonaria, utilizando herramientas para reducir los posibles problemas y luego analizando cada uno para clasificar por categorías.
(Es cierto que luego entrego a los desarrolladores para remediar o explicarme por qué el problema no representa un riesgo)
Pero este es un compromiso específico para el que el perfil de riesgo tiene sentido para llevar a cabo este tipo de trabajo intensivo en recursos.
Mucho más estándar y mucho más rentable es tratar de comprender el perfil de riesgo de la organización y centrarse en los riesgos de arriba hacia abajo, por ejemplo:
El lado de la programación solo se incluye en los dos últimos, con revisión de código y pruebas de penetración personalizadas. Para algunas organizaciones es de muy baja importancia, por ejemplo, si tiene capas de controles de seguridad que ya han sido revisados por pares (varios tipos de cifrado, por ejemplo), entonces, aunque puede verificar su implementación, generalmente no volverá a verificar todos los código como se ha hecho antes.
fuente
Nunca me he encontrado con ninguno que vaya mucho más allá de discutir arquitectura / mejores prácticas de manera vaga durante el diseño y / o ejecutar ataques / fritzing / suites de pruebas de excepción contra proyectos terminados.
En casi todos los casos, incluso puedo decir qué herramientas usan los vectores de ataque que intentan y la forma en que se lleva a cabo el ataque después de que una de las auditorías pasa a un sistema existente.
Me imagino que hay algunos que realmente se toman el tiempo para examinar el código y hacer algunas revisiones / pruebas de caja blanca, pero aún no los he encontrado en la vida real.
fuente