Material completo do workshop ministrado na FIAP com o tema DevSecOps.

2. bruno.dantas.net@gmail.com
@bdantasnet
linkedin.com/in/bdantas/
Bruno Dantas
Arquiteto de Segurança de Software
Banco Safra
17 anos de experiência com TI
8 anos trabalhando na indústria financeira
5 anos com segurança
Amante de carros, aviões e meus filhos ☺

3. Módulo 1
DevOps vs formas
tradicionais de criar
software

4. Como desenvolvemos sistemas
nos últimos 20 anos
Módulo 1

5. O SDLC
O SDLC (Ciclo de Vida de
Desenvolvimento de Sistemas, em
inglês Systems Development Life
Cycle) é um dos modelos mais
antigos de organização do
desenvolvimento de software.
As primeiras formas de organizar o desenvolvimento de software surgiram nos anos 70,
quando grandes empresas passaram a adotar sistemas computacionais para automação de
seus processos.

6. Desenvolvimento em Cascata
Verificação
Manutenção
Implementação
Desenho
Requisitos
É o processo ideal quando o escopo
dos requisitos de um software estão
definidos e claros, além de um prazo
para entrega maior estar disponível.
As metodologias tradicionais para criar sistemas tem o objetivo de acompanhar o seu
desenvolvimento, de forma estruturada e metódica, com controles rígidos e sequenciais,
desde o início da ideia até entrega do software final. Esse processo de desenvolvimento
chamamos de cascata e tem o RUP, sigla de Rational Unified Process ou Processo Unificado
da Rational, como o seu mais famoso representante.

7. Implantando Software: Modelo ITIL
Para implantação de mudanças em software dentro de grandes empresas, o uso do processo
de Gestão de Mudanças (GMUD) pregado pelo ITIL (Information Technology Infrastructure
Library) é muito comum. Por meio do registro de uma RDM (Requisição de Mudança), a
solicitação de implantação de uma nova funcionalidade é registrada e passada pela
aprovação de um Comitê, geralmente semanal.

8. Estudo de Caso: Obama Care

9. HealthCare.gov

10. Resultado do Modelo em Cascata

11. Inspirações do Silicon Valley
para mundo real
Módulo 1

12. Modelos de Trabalho Criados no Silicon Valley
Squads, tribos, chapters e guilds
Chaos monkey
Site Reliability Engineering (SRE)

13. O que é DevOps
Um perto de mão forte entre os times de Desenvolvimento e Operações de TI

14. Pioneiros do DevOps
John Willis, Patrick Debois e Gene Kim

15. Primeiro DevOpsDays, 2009 na Bélgica

16. O que é DevOps
Focar em pessoas
Abraçar mudanças e experimentações
Cultura
Automação
Medição
Compartilhamento
Entrega Contínua
Infraestrutura como Código
Medir o que for possível
Mostrar as melhorias
Abertura para compartilhamento de informações
Colaboração e comunicação
DevOps é regido por alguns princípios. O mais conhecido é o CAMS,
abreviatura de Culture, Automation, Measurement and Sharing.

17. Tabela Periódica de Ferramentas para DevOps

18. Literatura de Referência

19. Porquê se preocupar com
segurança em software
Módulo 1

20. Mas antes, um pouco de história
Como comecei na área de
Segurança?

21. Em 2003 construí um site dinâmico em ASP 3 :-)

22. Pouco tempo depois recebi um e-mail do Registro.br

24. ‘ OR 1 = 1 --
Motivo

25. Ranking das Vulnerabilidades Web mais Críticas

26. CVE 2017-5638
RCE (Remote Code Execution)
Caso

27. Caso
Falha expõe dados pessoais de
2 milhões de clientes da Movida

28. Caso

29. Por que minha aplicação precisa ser segura?
Para as empresa
✓ Evitar perdas financeiras $$$ diretas
✓ Risco de imagem (perda financeira indireta)
✓ Está OK com os reguladores (PCI, Banco Central etc)
Para você
✓ Poder dormir a noite e ter finais de semana

30. Foto acima protegida por direitos autorais
Crédito: Copyright © 2017 Checkmarx.com LTD
1. Diz NÃO pra tudo maioria das coisas
2. Descobre as vulnerabilidades depois de algo ir para produção
3. Não sabe lidar com o time de Dev
Postura comum dos times de Segurança

31. Foto acima protegida por direitos autorais
Crédito: Copyright © 2017 Checkmarx.com LTD
1. Não prioriza a correção das vulnerabilidades
2. Acredita que a melhor solução para o problema é a sua
3. O seu código NÃO dá pau tem problema
Postura comum dos times de Desenvolvimento

32. Como resolver isso?

33. Módulo 2O que é DevSecOps

34. Propósito e benefícios do
DevSecOps
Módulo 2

35. Mas antes, um pouco de história
Vamos conhecer o que é
Segurança da Informação

36. Aspectos CID ou CIA
Os aspectos da CID são o “coração” da Segurança da Informação e norteiam a tomada de
decisão dos times que trabalham nessa área.

37. Domínios da Segurança da Informação

38. Domínios da Segurança da Informação
O controle de acesso é geralmente considerado em três etapas: identificação, autenticação
e autorização. As organizações podem possuir parcialmente ou totalmente o controle de
acesso em processo automatizado, combinado com fluxos manuais, onde analisas avaliam
a real necessidade de acesso e conflitos de segregação de função, em inglês Segregation
of Duties – SoD.
Controle de
Acesso

39. Domínios da Segurança da Informação
Os processos de segurança e sua governança por meio de políticas são importantes, pois
contextualizam quais as preocupações que a empresa quer endereçar. Para ser aderente a
padrões de segurança do mercado como ISO 27000 ou PCI, a organização deverá publicar,
manter e controlar políticas, normas e procedimentos de segurança, bem como para
atender a entidades de regulação externa.
Processo de
Segurança

40. Domínios da Segurança da Informação
O plano de continuidade de negócios (PCN) refere-se a arranjos destinados a proteger as
funções críticas de negócios de uma organização contra interrupções causadas por
incidentes ou, pelo menos, minimizar os efeitos. O PCN é essencial para qualquer
organização manter a tecnologia e os negócios alinhados com as ameaças atuais à
continuidade dos negócios.
Continuidade
de Negócios

41. Domínios da Segurança da Informação
Um SOC, sigla em inglês para Security Operation Center, pode ser visto em um primeiro
momento como uma extensão do NOC (Network Operation Center), porém a preocupação é
manter as operações e processos de segurança em execução. Pode ser organizado em
diversos níveis, de maneira comum, em 3, onde cada estágio é responsável por dar sua
tratativa dentro do previsto no processo de resposta a incidentes, de maneira combinada
com a execução das atividades operacionais de segurança.
SOC

42. Domínios da Segurança da Informação
O gerenciamento de riscos é o processo de identificação de vulnerabilidades e ameaças
aos recursos de informação usados por uma organização para atingir seus objetivos de
negócios. Por meio desse processo, é possível decidir quais contramedidas devem ser
adotadas para reduzir os riscos a um nível aceitável, com base no valor da informação para
organização.
Gerenciamento
de Riscos

43. Segurança da Informação e Cibersegurança

44. Como organiza-se SI e Cibersegurança
Segurança da Informação
Cibersegurança
A Segurança da Informação geralmente é um conjunto de medidas defensivas, postas em
prática, para garantir que as vulnerabilidades serão tratadas e mitigadas. Já a Segurança
Cibernética também considera as medidas defensivas para dissuadir e impedir as
intenções dos atacantes, mas enfoca nas ações técnicas de desenvolvimento, servidores,
banco de dados, redes, firewalls, não atingindo a esfera estratégica.

45. Como DevSecOps difere de outras
abordagens de segurança
Módulo 2

46. Diferente do DevOps, existe um manifesto…
Avaliar mais que Dizer Sempre “Não”
Ciência de Dados e Segurança mais que Medo, Incerteza e Dúvida
Contribuição Aberta e Colaboração mais que Somente Requisitos de Segurança
Serviços de Segurança por meio de APIs mais que Controles Obrigatórios e Burocráticos
Avaliações de Segurança Dirigidas ao Negócio mais que Carimbos de Segurança
Testes Ofensivos com Red & Blue Team mais que Confiança em Scans e Vulnerabilidades Teóricas
Monitoração de Segurança Proativo 24x7 mais que Reagir apenas ao ser Informado de um Incidente
Inteligência de Ameaças Compartilhada mais que Manter as Informações para nós mesmos
Operar a Conformidade mais que Checklists e seguir apenas Manuais
devsecops.org

47. Agile sSDLC
DevOps Security
SecDevOps
Agile Security DevOpsSec
Vários nomes para a “mesma coisa”
Engenharia de
Software
Operação de
Tecnologia
Controle de
Qualidade
Segurança
DevOps
Seguro
Rugged DevOps

48. Uma iniciativa DevSecOps não é isso…

49. O começo de tudo…

50. DevSecOps é…
cultura
processos
ferramentas

51. DevSecOps por John Willis
Por anos eu resisti a várias tentativas de mudar o nome
“DevOps”, já que era só um nome. Porém a palavra
DevSecOps funciona, pois esse nome realmente
diferencia a declaração do problema, em um mundo
onde nós não estamos fazendo um ótimo trabalho de
segurança da informação.

52. Aonde injetar segurança
dentro do DevOps
Propósito e benefícios do DevSecOps
Módulo 2

53. #1 cultura
• Saber dizer “SIM” com
responsabilidade
• Disseminar a
preocupação com
segurança
• Querer participar de
todas as decisões
• Praticar segurança por
obscuridade
Imagem acima protegida por direitos autorais
Crédito: Copyright © 2017 Checkmarx.com LTD

54. #2 processos
• Começar com processos
simples
• Gerar indicadores sempre
• Burlar os processos
para colocar as coisas
mais rápido no ar
• Querer automatizar
todos os processos

55. Estratégia & Métricas
Política & Compliance
Orientação & Educação
Avaliação de Ameaça
Requisitos de
Segurança
Arquitetura de
Segurança
Revisão de Design
Revisão da Implantação
Teste de Segurança
Gestão de Problemas
Hardening do Ambiente
Aperfeiçoamento
Operacional
Práticas de Segurança
Governança Construção Verificação Operações
Funções de Negócio
Modelo de Maturidade de Segurança de Software
Software Assurance Maturity Model

56. #3 ferramentas
• Adotar soluções open
source
• Manter as ferramentas
atualizadas
• Não querer gastar $$$
com ferramentas boas

57. Exemplos de Processo com uso de Ferramentas

58. Builds
Noturnos
Análise
Estática
Análise
Dinâmica
Open
Source
Análise dos
Resultados
Gestão das
Vuln.
Fase 1: Nightly Builds
OWASP
ZAP

59. Entrega
Contínua
Análise
Estática
Análise
Dinâmica
Open
Source
Thresholds
Gestão das
Vuln.
Ofuscação
Fase 2: Continuous Delivery
OWASP
ZAP

60. Ferramentas

61. Tabela Periódica de Ferramentas para DevOps

62. Tabela Periódica de Ferramentas para DevOps
Voltado para
segurança

63. Tabela Periódica de Ferramentas para DevSecOps
github.com/b-dantas/devsecops-periodictable

64. Literatura de Referência

65. Módulo 3
Disseminando as
práticas de segurança

66. Como treinar os desenvolvedores
quem escreve código
Módulo 3

67. Coding Dojo
Um dos melhores investimentos que podem ser feitos é o treinamento dos times, orientado
para como escrever código seguro nas linguagens e tecnologias utilizadas pela empresa.

68. Campeonatos de Segurança
Time com seus troféus do programa Security Champions do LinkedIn
https://engineering.linkedin.com/blog/2018/04/scaling-linkedin-s-security-champions-program

69. Gameficação e
hackathons
Módulo 3

70. Gameficação
Gostamos de ter escolhasAutonomia
Maestria
Feedback
Finalidade
Gostamos de nos preocupar com o que fazemos
Nós gostamos de obter feedback sobre
como estamos fazendo
Significado amplificado o que fazemos
Social Tudo significa mais com os outros
Gameficação não trata de como jogar games no trabalho, embora 70%
dos executivos admitem terem jogados games no trabalho.

71. Hackathons: Participação do Itaú no Roadsec
Um dos melhores investimentos que podem ser feitos é o treinamento dos times, orientado
para como escrever código seguro nas linguagens e tecnologias utilizadas pela empresa.

72. Criando programas de bug bounty
e práticas blameless
Módulo 3

73. Bug Bounty
Bug Bounty é o pagamento de
uma recompensa, muitas vezes
em dinheiro, pela descoberta de
falhas, especialmente de
segurança.

74. Plataformas de Bug Bounty
DICA! Começar de maneira comedida, com programas de divulgação responsável,
passando por iniciativas fechadas de recompensa, até abertura total ao público
hackerone.com
bugcrowd.com

75. O programa do Facebook
Em 2011 o Facebook começou a distribuir cartões de débito para os ganhadores de
recompensas de vulnerabilidades descobertas.

76. O programa da Netflix
medium.com/netflix-techblog
Netflix levou 5 anos para tornar seu programa de Bug Bounty público

77. Blameless
Blameless é não culpar as pessoas pelas
falhas, mas sim identificar no processo
as falhas e corrigi-las, sem deixar de lado
as responsabilidades inerentes da
função.
Uma cultura Blameless acredita que os
sistemas não são inerentemente seguros e
humanos fazem o melhor para
continuarem funcionando.

78. O incidente do GitLab.com
https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

79. Fernando Ike, o cara do Blameless
fernandoike.com/tags/blameless/

80. Exercícios de
Red & Blue Team
Módulo 3

81. Red & Blue Team
Executa ações
de simulação
de ataque real
Executa os
protocolos de
proteção e
defensa

82. Um exercício de Red & Blue Team

83. O “DevOps” do Red & Blue Team

84. Indo além:
DevOps dentro da segurança
Módulo 3

85. Agile Security
Uso de práticas Agile/Scrum para o controle e organização das atividades de
segurança.

86. Segurança Centrada em Pessoas

87. Exemplo: Política de Senhas
Favorecer o usuário: Para começar, torne suas políticas de senha amigáveis ao usuário e
coloque a carga sobre o verificador quando possível. Em outras palavras, precisamos parar
de pedir aos usuários que façam coisas que na verdade não estão melhorando a
segurança.
Tamanho importa: Pelo menos quando se tratam de senhas. As novas diretrizes do NIST
dizem que você precisa de um mínimo de 8 caracteres. (Isso não é um mínimo máximo –
você pode aumentar o comprimento mínimo da senha para contas mais sensíveis).

88. Literatura de Referência

89. Obrigado!
bruno.dantas.net@gmail.com
@bdantasnet
linkedin.com/in/bdantas/