Gran pregunta.
Primero, el "mínimo" que citó se refiere a la política de requisitos mínimos de Microsoft , no necesariamente al mínimo de "mejores prácticas de la industria". No es que esté diciendo que está mal, pero el MS-SDL sí dice que su SDL no es necesariamente adecuado para ninguna organización fuera de Microsoft ... De hecho, los arquitectos de MS-SDL, como Michael Howard, son a menudo -comentado diciendo:
No hagas lo que hacemos, haz lo que hicimos.
Es decir, no se trata tanto de los requisitos prescritos como aparecen específicamente en el documento (aunque podrían ser muy buenos), pero realizaron estudios en varias ocasiones, incluido el análisis basado en el riesgo, comparaciones de métricas históricas, análisis de tendencias , análisis de la causa raíz, pruebas en diferentes equipos para ver qué "toma", etc.
No hay un SDL simple y bien definido que simplemente puedes descargar instalar y estar seguro. Ese punto de MS es correcto: realmente necesita adaptar su SDL de acuerdo con su organización específica, sus equipos, su competencia, los tipos de productos que están creando, el proceso de desarrollo actual, el perfil de riesgo, etc. esa es realmente la mejor solución para "probar" ...
Por otra parte, SDL no es una cosa de una sola vez, ni siquiera una cuestión de definir e implementar la política correcta. La construcción de una SDL es en sí misma un proceso continuo, que, sin duda, puede tardar varios años en implementarse por completo. Microsoft realizó algunas iteraciones hasta que sus SDL alcanzaron algo ejemplar ... Y se necesitaron un par de años más para que realmente estuviera arraigado en (la mayoría de) sus desarrolladores. Realmente no puede "probar" un SDL, porque el beneficio generalmente no se mostrará en el primer o segundo mes, es una inversión a largo plazo.
Por lo tanto, para las organizaciones que recién comienzan y buscan definir su SDL: sugeriría que lo haga despacio, que alguien con experiencia lo guíe en el proceso:
- Comience por definir la situación actual, el proceso, los equipos, la experiencia, la flexibilidad, etc.
-
Si los equipos + administración no están convencidos al 100% de la necesidad de SDL y de la seguridad en general, considere hacer una revisión de seguridad inicial para resolver los problemas. ... Un pentest suele ser más útil aquí, simplemente porque puede ser bastante visual (NO porque sea necesario para el SDL en este punto).
- Asegúrese de que en este momento tenga participación, tanto de un patrocinador ejecutivo como de los propios equipos. Sin ninguno de los dos, el SDL está condenado al fracaso.
- Entrenamiento! A los desarrolladores les gusta hacer las cosas bien, si saben cómo .
- Agregue lentamente mínimo actividades de seguridad adicionales, de acuerdo con los beneficios que recibirá para ellos, en comparación con el esfuerzo invertido, y la interrupción de los equipos de desarrollo. Recuerde, el objetivo del ejercicio es involucrar a TODOS en la seguridad, y no apagarlos de inmediato.
- Configure la experiencia en seguridad, ya sea en su equipo (como campeón de seguridad) o en un equipo central con el que todos puedan hablar - y hacer que hablen . Mejor aún, es un modelo híbrido de ambos (como en el modelo MS).
- De acuerdo con su capacidad para realizar inversiones adicionales en seguridad, en cada ciclo agregue actividades mínimas adicionales, además de las anteriores. El punto es acostumbrarlos a hacer cosas de uno a dos pequeños, que se convierta en algo natural (casi) y que ya no se "demore mucho en hacer esto de seguridad". Entonces tendrás ancho de banda para más ...
- Recopile métricas a lo largo del camino, para que pueda saber qué está funcionando y qué no, y también para mostrar el beneficio de la inversión de SDL para la administración.
- ¡Más entrenamiento!
Ahora, el verdadero problema es que la lista de arriba, parece mucho.
Pero realmente no lo es, ya que la mayoría de esas balas son "meta-actividades". Algunos de ellos probablemente deberían ser realizados por un experto en seguridad / gal / consultor, con experiencia en la implementación de SDL en un tipo de entorno similar al suyo . Es cierto que todavía no es tan simple, pero cuando hago esto pongo énfasis en la interrupción mínima y la inversión continua. puede hacerse liviano.