¿Cómo pueden integrarse las auditorías de seguridad en un proyecto ágil?

27

Si le damos a una empresa de auditoría de seguridad un sistema que funciona, y les pedimos que lo auditen, y solo lo hacemos una vez durante un proyecto porque es caro, esto es básicamente una catarata.

¿Cómo puede integrarse la auditoría de seguridad en un proyecto ágil sin convertirlo en un proyecto de cascada, y por lo tanto introducir el riesgo de falla de auditoría?

Lo que queremos hacer es conocer por adelantado los requisitos de seguridad detallados, de modo que podamos crear historias para ellos (y / o integrarlos en historias existentes) y escribir pruebas automatizadas para ellos que nos den cierto grado de confianza en que Se han cumplido los requisitos de seguridad. Esta es la forma ágil.

Pero el problema es que si no sabe exactamente cómo será la primera implementación de producción hasta poco antes de implementarla, porque es un proyecto ágil, no puede decirle a una empresa de auditoría de seguridad qué es exactamente. va a parecer Por lo tanto, es posible que le digan "la cantidad de posibles vulnerabilidades en un sistema arbitrario es extremadamente grande, por lo que tenemos que saber qué se ve para reducirla, así que vuelva cuando sepa qué aspecto tendrá, y luego le damos los requisitos ". En ese caso, no puedes hacerlo de forma ágil.

    
pregunta Robin Green 06.10.2014 - 19:20
fuente

6 respuestas

19

Las pautas de Microsoft para el ciclo de vida del desarrollo de la seguridad (SDL) para Agile recomiendan prácticas de seguridad durante Diseño, implementación y lanzamiento del proyecto. Independientemente de la metodología de desarrollo en uso, ninguna línea de código debe estar en producción hasta que se haya sometido a una revisión de seguridad. Si las restricciones financieras impiden este nivel de revisión de seguridad de un profesional, entonces una revisión de seguridad debe ser realizada por pares antes de que se pueda finalizar un lanzamiento. La finalización de un lanzamiento se puede convertir en un proceso divertido, he visto compañías que organizan hack-a-thons en toda la empresa y entregan premios por errores interesantes.

Microsoft ha trabajado mucho en SDL y la seguridad de Microsoft ha mejorado.

    
respondido por el rook 06.10.2014 - 19:36
fuente
17

La respuesta corta es: integre la seguridad en su ciclo de vida de desarrollo de software. Debe integrarse en cada etapa: diseño, implementación y prueba.

Hay muchos recursos sobre cómo crear seguridad en su ciclo de vida de desarrollo de software. Ver, por ejemplo, SDLC de Cigital (los 7 puntos de contacto)], < a href="http://www.microsoft.com/security/sdl/default.aspx"> SDLC de Microsoft , SDLC de OpenSAMM , BSIMM , Seguridad de compilación del CERT , o preguntas aquí como Desarrollo seguro de software , Creación de entornos seguros de desarrollo de software , Lo que se considera el el ciclo de vida de desarrollo seguro más simple (o más liviano) , ¿Qué modelo de ciclo de vida de desarrollo seguro elegir? .

Una "revisión de seguridad" no es una sola cosa. Hay diferentes formas de revisión de seguridad. La integración de la seguridad en su ciclo de vida de desarrollo de software requiere tener en cuenta la seguridad en cada etapa del proceso, y esos tipos diferentes de revisión de seguridad tendrán diferentes implicaciones. Estos elementos pueden incluir:

  • Debe tener una revisión de diseño de seguridad, para revisar su diseño y comprender los riesgos de seguridad a nivel de arquitectura asociados con el diseño y la posibilidad de fallas en el nivel de diseño (esto es lo que Microsoft llama "modelado de amenazas"). No es necesario que vuelva a examinar esto cada vez que cambie la implementación, solo cuando cambie el diseño.

  • También debe tener una revisión del código de seguridad, para revisar su código a fin de identificar posibles defectos de código a nivel de implementación que podrían comprometer la seguridad. Cada vez que escriba un nuevo código o cambie un código existente, deberá revisar ese código para detectar errores de implementación.

  • También debe integrar la seguridad en sus esfuerzos de prueba. Antes de lanzar una nueva versión, puede probar su seguridad, centrándose especialmente en las características que han cambiado.

respondido por el D.W. 07.10.2014 - 00:43
fuente
5

Si su modelo de seguridad se basa en el concepto de una auditoría externa puntual de todo el código base, entonces está cometiendo un error de seguridad.

... Y probablemente estés usando mal la auditoría también. Pero llegaremos a eso.

Más allá de la pregunta, todo el código debe ser auditado por seguridad. En muchos casos, esto es en realidad un requisito legal: ningún código se envía sin una auditoría, punto. La sabiduría tradicional sugiere que tal auditoría sea un evento en algún momento del ciclo de vida, pero una forma más sensata de hacerlo es auditar el código a medida que avanza. Es decir, todo el código obtiene una auditoría de seguridad antes que se puede registrar en su base de código.

La teoría es simple; El repositorio ya está auditado, por lo que no necesitamos volver a auditar sus componentes como un procedimiento estándar. Pero cuando se propone una nueva característica, un parche o una corrección de errores, la diferencia tiene que ser firmada por los mantenedores apropiados. Puede obtener la aprobación de cualquier cosa que sea importante para usted. Por ejemplo, el kernel de Linux tiene un proceso de aprobación bastante complejo que requiere varios endosos en el camino de la calidad, simplicidad, consistencia, rendimiento, etc. Sus requisitos pueden variar, pero una auditoría de seguridad debe ser parte de ese proceso de aprobación.

En este caso, no está auditando el producto de extremo a extremo, solo está auditando el diferencial. Pero miles de pequeñas auditorías a lo largo del ciclo de desarrollo del producto serán mucho más exhaustivas y exhaustivas de lo que cualquier auditoría de extremo a extremo podría esperar.

Una auditoría completa de producto es ciertamente útil y no debe evitarse. Esta auditoría debe centrarse en el producto en su totalidad de una manera que no sea tan fácil de realizar durante las auditorías a nivel de parche que ha estado realizando. Desea mirar todo el bosque de vez en cuando, no solo los árboles individuales. El calendario de estas auditorías a gran escala probablemente debería corresponder a lanzamientos importantes, cambios importantes o auditorías de certificación de cumplimiento.

Pero si se mantiene actualizado en la auditoría a nivel de parche, puede asegurarse de que el código siempre se mantenga en un estado verificable, de modo que pueda continuar enviándolo con confianza.

Acerca de las aprobaciones de tiempo de compromiso
Si su compañía no está haciendo esto, entonces está haciendo todo mal. Hay docenas, quizás cientos, de problemas que se resuelven al requerir que cada cambio de código sea aprobado por al menos otra persona, incluso (especialmente) durante el desarrollo inicial. Siempre debe tener al menos dos personas que entiendan cómo funciona cada línea de código y que acepten que el código es correcto.

Esto es al menos tan importante como las pruebas unitarias. Si no está haciendo esto, deténgalo todo y vuelva a visitar las políticas sobre calidad y seguridad.

Sí, este proceso hace escala. Como se señaló anteriormente, el proyecto de software más grande del mundo lo usa, al igual que algunas de las compañías de software más ágiles y exitosas del mundo.

    
respondido por el tylerl 07.10.2014 - 10:02
fuente
3

Como otros lo han sugerido, puede incluir historias sobre seguridad. Y sin duda te animo a que hagas eso.

Pero si estás hablando de un equipo externo que viene y pasa varias semanas haciendo una auditoría ... me parece que se trata más de ágil que de seguridad.

Sé que Agile pone un gran énfasis en el envío frecuente. Después de todo, ¿cómo va a reducir el ciclo de retroalimentación si su software no está en manos de los clientes? Pero para muchas organizaciones, liberar cada 2/3/4 semanas simplemente no es una opción. O tienen un largo proceso de revisión de QA / QC y la organización de QA no está lista para ser ágil. O tienen otros requisitos de certificación (por ejemplo, ISO) que no se ajustan al ciclo de vida ágil.

En consecuencia, muchos equipos ágiles descubrieron desde el principio que necesitaban desacoplar sus lanzamientos de sus iteraciones o sprints.
Es decir, en lugar de promover la producción, usted promueve cambios en un entorno dedicado a la seguridad / control de calidad / lo que sea. Cuando el código ha sido certificado allí, lo promueves a producción (o a la siguiente puerta).

Si ha estado construyendo historias de "mal uso", probablemente su lista de defectos / problemas debería ser corta.

Si se encuentra un defecto, se puede colocar en el backlog o priorizar para una solución inmediata, dependiendo de su gravedad.

Por supuesto, el entorno adicional no es gratuito ... pero, según mi experiencia, es más económico que las alternativas (lo que generalmente hace que los equipos se pisen los dedos de los pies).

    
respondido por el David 07.10.2014 - 23:16
fuente
2

Añadir casos de mal uso.

Si hay una característica que el sistema debe exhibir, utiliza un caso de uso. Si hay una característica que el sistema no debe exhibir, use un caso de uso indebido.

"Como competidor, quiero consultar los datos confidenciales de la compañía en el back-end de la base de datos; esto no debe suceder".

"Como hacktivista, quiero usar la DMZ para reflejar los ataques al gobierno; esto no debe suceder".

El propietario del producto puede priorizar estas historias junto con las demás, pero se pueden probar como cualquier otra historia de usuario.

(Admito libremente que no soy un iniciado de los misterios secretos de Agile; Agile se ha convertido en algo así como la 77.ª orden de los Masones, llena de misterios y mandamientos que NO DEBEN RETRARSE, por temor a horrores inefables).

    
respondido por el Mark C. Wallace 06.10.2014 - 19:33
fuente
2

Puede realizar auditorías para cada versión al igual que un proyecto de cascada. Aunque notó algunos problemas al hacer eso, muchas compañías de seguridad pueden trabajar de manera muy efectiva con proyectos ágiles. Sin embargo, si liberas con frecuencia, el costo de esto puede ser prohibitivo.

Otro enfoque es mover las pruebas internamente. Si compra una herramienta de escaneo, puede realizar sus propias auditorías. Puede que no sean tan completos como una empresa de seguridad especializada, pero puede ejecutarlos con la frecuencia que desee. Tal vez los integre con un sistema de compilación nocturno, o incluso los ejecute en un gancho de confirmación previa mediante la integración continua. Existen dos tipos principales de estas herramientas: Pruebas de seguridad de aplicaciones dinámicas (DAST), que es una prueba de penetración automatizada, y Pruebas de seguridad de aplicaciones estáticas (SAST, por sus siglas en inglés), que es una revisión automática del código fuente. Un beneficio de SAST es que los resultados se informan en términos del desarrollador: archivo de código fuente y número de línea. Creo que las herramientas de prueba DAST / SAST encajan muy bien con el modelo ágil; En cierto modo, son pruebas unitarias de seguridad.

Un equipo de desarrollo con procesos de seguridad maduros utilizará las pruebas internas y de terceros. SAST / DAST se utiliza para garantizar que todo el código reciba al menos una revisión de seguridad básica y para detectar problemas antes. Periódicamente se realizan pruebas de penetración para tratar de detectar problemas complejos que las pruebas automatizadas no pueden identificar. Esto puede ser en un horario fijo, o puede estar basado en el riesgo, mirando los cambios en cada versión.

Su pregunta fue sobre auditorías de seguridad. Por supuesto, hay otros aspectos para la seguridad de una aplicación. El modelado de amenazas para garantizar la seguridad se refleja en el diseño. Seleccione herramientas y marcos de desarrollo que fomenten la seguridad y capacite a los desarrolladores para utilizar estas herramientas de forma segura. Esto es lo mismo que para el desarrollo en cascada, pero con Agile es más importante integrar estas habilidades dentro del equipo de desarrollo, en lugar de que el equipo de seguridad ingrese periódicamente.

    
respondido por el paj28 06.10.2014 - 22:44
fuente

Lea otras preguntas en las etiquetas