O documento discute o Security Development Lifecycle (SDL) ou Ciclo de Vida de Desenvolvimento Seguro, propondo uma abordagem ágil para incorporar práticas de segurança ao longo de todo o ciclo de desenvolvimento de software. A proposta divide o SDL em atividades discretas em cada fase, desde os requisitos até a manutenção, de forma flexível para ser adaptada a diferentes metodologias de desenvolvimento. O objetivo é tratar a segurança como outro atributo essencial do software, identificando e corrigindo vulnerabilidades o mais cedo possível.

1. ENTENDENDO O SDLC
Security Development Lifecycle
Kleitor Franklint
kleitor@prodam.am.gov.br
Líder OWASP capítulo Manaus
Fábrica de Teste PRODAM

2. KLEITOR
Entusiasta da Vida,
Qualidade,
Colaborativos,
Ágil,
Teste e
Testes Ágeis.
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
92-99416-0873

3. SDL ou SDLC: Ciclo de vida de desenvolvimento de
software ou sistemas.
Ou ainda:
Ciclo de vida de desenvolvimento
seguro.
Para não confundir: S-SDL
ENTENDENDO O SDLC

4. Outras propostas ao título:
Construindo segurança no seu SDL;
SDL, adotando uma proposta peso leve;
Construindo aplicações seguras com práticas ágeis;
Ou ainda...
DESENVOLVIMENTO SEGURO É MAIS SIMPLES QUE VOCÊ PENSA!
ENTENDENDO O SDLC

5. S- SDL: UM ROADMAP

6. S-SDL?S-SDL?
 É um programa de práticas no qual segurança é só
mais um atributo de software como usabilidade,
desempenho, escalabilidade, etc;
 Insiste na incorporação de segurança ao Ciclo de
Vida de Desenvolvimento de Software;
 Hackers podem quebrar redes e aplicações de várias formas, por isso existe
a proposta de S-SDL;
 O objetivo cresce sistematicamente. Cada fase do SDLC vai insistir em
segurança para além do atual conjunto de atividades.
 Existe porque vulnerabilidades são identificadas muito tardiamente ou
quando violações de segurança ocorrem.

7. Iniciativas S-SDLIniciativas S-SDL

8. Uma proposta de S-SDLUma proposta de S-SDL
 Abordagem sistemática flexível que agregue mais valor ao
conhecimento;
 Orientada a práticas ágeis;
 Integração fácil com atividades correlatas;
 Atividades divididas em processos discretos e simples;
 Que seja fácil de adotar com sua maneira de trabalhar;
 Que resulte em melhorias incrementais à segurança que sejam
facilmente realizáveis, repetíveis e mensuráveis.​​ ​​

9. Não importa sua metodologia de projetoNão importa sua metodologia de projeto
S-SDL ágil, prático e adaptávelS-SDL ágil, prático e adaptável

10. Beneficios do SDLBeneficios do SDL
 Erradicar defeitos o mais cedo possível para ser economicamente
viável;
 Colabora com integração com compliance;
 Solução para problemas que não foram ainda claramente definidos;
 Consciência de engenharia potencial causado por problemas de
segurança;
 Identificação dos serviços de segurança compartilhada e reutilização
de estratégias e ferramentas de segurança;
 Melhoria na tomada de decisão através de um processo de gestão de
risco global em tempo hábil;

11. ÁGIL = Valorável, Leve, Possível e
Prático.
Integrar objetivos
de segurança
com requisitos
Avaliação
de Riscos
Integrar
atividades,
responsáveis,
padrões e
modelos
Modelagem
de ameaças
Alinhar com
objetivos e
requisitos de
segurança;
Codificação
segura, SAST, Spikes.
DAST, Fuzz
Teste Black Box.
Avaliar resultados.
Deploy seguro,
Teste black box
post production
Monitoramento de
incidentes, Revisão
da Infra.
Manutenção
Monitoramento, aprendizado, Revisões, Análises
Atividades do S-SDL
Treinamento

12. Estratégias de adoção de S-SDLEstratégias de adoção de S-SDL

13. RACIONALIZAÇÃO DO
ESFORÇO
Classifique suas
Aplicações
Classifique suas
Atividades
“One time”,
“Every Sprint”,
“Bucket requirements”
( não precisam estar completos ,
menos importantes,
e com menos regularidade).

14. Atividades no S-SDL: Planejamento e Requisitos
 Definir objetivos de segurança no plano de requisitos;
 Modelar riscos;
 Definir e monitorar métricas;
 Aplicar requisito a cada fase;
 Revisar.
Não se pode testar a segurança mais que se pode testar a qualidade.

15. Atividades no S-SDL: Planejamento e Requisitos
Definir objetivos de segurança no plano de requisitos.
Requisitos podem ser adicionados como tarefas dentro de um release;
Todos os requisitos “every sprint” devem estar completos e exceções a eles garantidas;
Pelo menos um requisito da categoria Bucket deve estar pronto, ou um exceção concedida a ele;
Nenhum requisito “One time” excedeu período de carência.
Modelar riscos.
Defina o escopo: orientada a Empresa, a projeto ou a problema.
Uma lista simples com plano de mitigação integrada ao plano de requisitos é um bom começo.
Definir e monitorar métricas.
Desenvolver estratégias para gerar métricas;
Definir métricas alcançaveis e aplicáveis;
Como as métricas serão relatadas: relatório de teste, bugtrack, daily scrum, dashboard, etc
Contabilize as vulnerabilidades "pre-SDL" e “pós-SDL por período;

16. Modelagem de ameaças ( crítico every sprint, apenas os novos );
Desenho de casos de uso de vulnerabilidade;
Desenho da arquitetura segura;
Desenho do deploy:
Definir padrões de codificação segura;
Desenho do deploy;
Definir padrões de codificação segura;
Definir atividades e responsáveis;
Revisar: checklist
Atividades no S-SDL: Design e arquitetura

17. Modelagem de ameaças ( crítico every sprint, apenas os novos ):
- Pode ser textual, owasp top 10, diagrama de fluxo;
- Um mínimo, mas útil, pode ser feito analisando pontos de entrada de alto
risco e dados no sistema.
Desenho de casos de uso de vulnerabilidade:
- Quais os serviços de segurança podem ser tornar vulneráveis em
aplicações;
Desenho da arquitetura segura:
- Configuração essencial servidor web ou app, patches;
Desenho do deploy:
- Criptografia, conf. mudanças;
Definir padrões de codificação segura:
- Uso de APIs, OWAP guides, etc;
Atividades no S-SDL: Design e arquitetura

18.  Utilizar melhores práticas de codificação segura;
- CERT Secure Coding Initiative28, O WASP CLASP, Microsoft SDL.
- Não defina modelos semideuses, pense em viável e produtivo.
 Executar análise estática de código(SAST);
Cumprir: alinhar Design, arquitetura e requisitos de segurança;
- Meu ambiente está pronto?
Use um spike como experimento de codificação e teste;
Revisão: periódica ou pró sprint
Atividades no S-SDL: Desenvolvimento

19. Black box manual e automatizado (DAST);
- Pentest, funcional, desempenho, fuzz em pre-produção.
Gerar relatórios de vulnerabilidades e recomendações;
Avaliação de resultados e métricas;
- Times de teste, desenvolvimento e analistas.
Atividades no S-SDL: Teste

20. Deploy seguro;
Teste black box pós produção;
Monitoramento de incidentes;
Revisão de configurações de servidores e rede;
Atividades no S-SDL: Produção

21. Lições aprendidas;
Monitoramento das vulnerabilidades: leve o software ao medico a
cada release;
Revisões: processo, projeto ou problema.
Atividades no S-SDL: Manutenção

22. Atividades do S-SDL
Integrar objetivos
de segurança
com requisitos
Avaliação
de Riscos
Integrar
atividades,
responsáveis,
padrões e
modelos
Modelagem
de ameaças
Alinhar com
objetivos e
requisitos de
segurança;
Codificação
segura, SAST, Spikes.
DAST, Fuzz
Teste Black Box.
Avaliar resultados.
Deploy seguro,
Teste black box
post production
Monitoramento de
incidentes, Revisão
da Infra.
Manutenção
Monitoramento, aprendizado, Revisões, Análises
Avaliação de Maturidade do S-SDL

23. 23
POSSO COLABORAR COM
MAIS RESPOSTAS?
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
92-99416-0873