La experiencia que la mayoría de la comunidad ágil tiene con la seguridad es la de que entran los últimos con posibilidad de retrasar el despliegue continuo. Esto debe cambiar, en esta charla comentaré la experiencia que hemos tenido en los equipos de desarrollo de i4s (dedicada a crear productos de seguridad para una gran entidad financiera) en la integración de historias de seguridad desde los primeros sprints. Esta aproximación se ha hecho a través de BDD para que también permitan a los equipos de desarrollo entender la necesidad de realizar desarrollos seguros. La creación de estas historias de seguridad se ha hecho desde la experiencia que tenemos como empresa de seguridad y de software y siguiendo estándares como el OWASP
3. De dónde venimos? (Histórico)
Waterfall
3
Análisis
Diseño
Desarrollo
Testing
Implementación
Despliegue
Hacking
ético
Previsiones a X años vista
Añadimos X tiempo a la previsión fallida
4. De dónde venimos? (I4S)
Agile + Hacking ético
4
Análisis y diseño
Desarrollo
Testing
Implementación
Análisis y diseño
Desarrollo
Testing
Implementación
Análisis y diseño
Desarrollo
Testing
Implementación
Deploy
Deploy
Deploy
Iteración 1/Release 1
ESO NO ES
AGILE!!!!
Hacking
ético
Hacking
ético
TiempoIteración 2/Release 2 Iteración 3/Release 3
DÓNDE HE VISTO ESTO
ANTES?
5. A dónde vamos?
Agile con seguridad integrada
5
Deploy
Deploy
Deploy
Iteración 1 Iteración 2 Iteración N
Análisis y diseño
Desarrollo
Testing
Implementación
Análisis y diseño
Desarrollo
Testing
Implementación
Análisis y diseño
Desarrollo
Testing
Implementación
Desarrollo +
Seguridad
Desarrollo +
Seguridad
Desarrollo +
Seguridad
6. Cómo integrar la seguridad en el desarrollo? (I)
Agile con seguridad integrada (I4S)
6
Equipo
de
trabajo
scrum 1
Sec Dev
Ops
Escenario seguridad
Feature
Seguridad
Product Owner
Scrum
Feature 1
Feature 2
Feature 3
Feature n
Backlog Scrum
DoRDoD
7. Cómo integrar la seguridad en el desarrollo? (II)
Agile con seguridad integrada (Alternativa)
7
Product Owner
Scrum1
Product Owner
Scrum2
Product Owner
Seguridad
Feature 1
Feature 2
Feature
Seguridad 1
Feature n
Feature 1
Feature 2
Feature 3
Feature
Seguridad 1
Feature 1
Feature 2
…
Feature n
Equipo
de
trabajo
scrum 1
Equipo
de
trabajo
scrum 1
Equipo de
trabajo de
seguridad
Integración,
despliegue o entrega
continua.
Backlog Scrum 1 Backlog Scrum 2
Backlog
Seguridad
8. Cómo funciona BDD
Behaviour Driven Development
8
Historia de usuario
Gherkin -> .feature
Feature
@tag
Scenario
Given 1
When 2
Then 3
Traducción
Sacar todos los
comportamientos
esperados
STEPS -> .py
@given(‘1')
def step_impl(context):
assert False
@when(‘2')
def step_impl(context):
assert False
@then(‘3')
def step_impl(context):
assert False
~
TDD
+
Product Owner
UX
QA
Dev Team
….
9. Unión con varios estándares del MITRE como:
– CAPEC: Common Attack Pattern Enumeration and Classification
– CWE: Common Weakness Enumeration
– CVE: Common Vulnerabilities and Exposures
Historias de seguridad en BDD
Historias de seguridad desarrolladas en base a:
– OWASP
– SAFEcode
– Expertise propio
– Patrones de seguridad definidos
9
Tipos de historias:
– SQLi
– XSS
– HTTPfuzzing
– SSL/TLS configuration
– DoS
– Technical Compliance (VATS)
– …
13. Conclusiones
Cualquier dev team puede contar con las features de seguridad para
pasarlas desde el día 1.
Reaprovechamiento de escenarios ya desarrollados.
Seguridad no entra el último en el ciclo de desarrollo ágil.
Se reducen las vuelta atrás en el desarrollo por lo que realmente si se
desarrolla de manera ágil.
Automatización de un alto % de historias de seguridad porque las
vulnerabilidades son heredadas del software.
Equipos de hacking reducidos para issues específicos.
Comunidad para las features de seguridad en el future. (Our wish)
Otros frameworks: BDD Security (Irius Risk), Gauntlt, mittn (F-Secure).
13
Quién soy y Qué hago
Hablar de la trayectoria y de que hacemos productos de seguridad, tengo experiencia en productos similares (de la competencia) y creo que con eso, suficiente.
Comunidad “Agile Experiences”
Metodología clásica mala vuelta atrás
Anécdota de Project de VATS inicial a 2 años vista. Tras 3 años veo ese Project y se parece como un huevo a una castaña
En casa del herrero cuchillo de palo
En el agile “puro” cada deploy es a producción, en este caso el hacking puede hacer que esa iteración se pierda
En el agile donde los deploys a producción se hacen con las releases, te puede hacer que varias interaciones se pierdan
Suponiendo que se hiciera el deploy después de cada iteración a producción, cuando se realiza el hacking podría mandar atrás el desarrollo en cada iteración.
Agile hacking
BDD security integrado en los desarrollos
Proceso análisis inicial (C104 amenazas, riesgos, contramedidas…)
En el desarrollo historias abusivas de hacking
DoR Historias de usuario siempre tienen que estar en gherkin para poder empezar con BDD
DoD Punto en el cual se tienen que pasar todos los test de seguridad asociados a las historias
Hacer una explicación de la diferencia que hay entre hacer un desarrollo de un producto de seguridad y un producto seguro, cómo no hay necesariamente una relación entre los dos temas y cómo los perfiles necesarios (y los conocimientos) son distintos.
Reutilización de historias
Esquema desde historia de usuario a Gherkin (scenarios y tags) y como behave pasa los test
Prerequisitos: logueado en la herramienta, que la herramienta esté arriba, que tengas la base de datos cargada…
Ejemplo de gherkin con sus tags
Esquema desde historia de usuario a Gherkin (scenarios y tags) y como behave pasa los test
*Explicar flujo de trabajo entre PO y equipo de desarrollo con git
Docker con behave por scenario
Herramientas: Accunetix, Arachni…
Explicación archive configuración
Ejemplo login “básico”
(Ejemplo con tags)
(Ejemplo paralelización)
Ejemplo parámetro configuración para cualquier herramienta (cifrado con Chameleon)
Login con VATS
Explicación funcionamiento (Jenkins, archive configuracion, Behave, Selenium, herramientas seguridad…)
