1

O processo de segurança em desenvolvimento, que não é ISO 15.408Wagner Elias

Gerente de Pesquisa e Desenvolvimento

ISSA Day - São Paulo - 31 de Agosto 2010

2

Por que Segurança em Desenvolvimento?

3

Investimentos em correção de software

4

Estatísticas de falhas em software

Segundo o NIST

92% das vulnerabilidades de segurança estão em software

Segundo o Gartner

75% dos incidentes são causados por falha de software

5

Conformidade

Atendimento a regulamentações e padrões

PCI (Payment Card Industry Data Security Standard)

Atendimento ao Requisito 6: Desenvolver e manter sistemas e aplicações seguras

Transparência e facilidade para auditorias

Atendimento a auditorias de sistemas e de segurança

6

Principais Erros

7

Usar ISO/IEC 15.408 ou Commom Criteria como base

Estes padrões não tem como objetivo a implementação ou avaliar um processo de Segurança em Desenvolvimento

Foco em Produto Pronto

Objetivo principal é certificar produto de software e não um sistema de gestão ou processo

8

Por que só o Brasil associa esta norma a segurança em desenvolvimento de software?

9

Alguém conhece um case de implementação de SDL que tenha usado estes padrões como base?

ISO/IEC 15.408

SDL Case

10

Abordagem baseada apenas em testes

Apenas testes não resolvem

Testes no Desenvolvimento

Unitário

Integrado

Aceitação

Testes de Segurança

Testes Black-Box (Pentest/Análise de Vulnerabilidades)

Revisão de Código

11

Abordagem baseada apenas em documentação

Documentação é um bom caminho para atendimento a determinas regulamentações, mas é apenas parte do processo

Tipos de Documentação

Políticas

Cartilhas de Boas Práticas

Checklists

12

O Caminho Certo

13

Processo de desenvolvimento de softwareProcesso Claro e Estabelecido

Controle de Versão

Documentação

Controle de Demandas e Bugs

Bug Tracking

Testes e Gestão de Build

Testes de Qualidade de Software

Integração Contínua

14

Conscientização e Capacitação

Conscientização

Gestores

Envolvidos no desenvolvimento e contratação de software

Capacitação

Dos envolvidos na gestão do desenvolvimento em SDL

Dos desenvolvedores em boas práticas de desenvolvimento seguro

Dos testadores em testes de segurança

15

Desenvolvimento de Software

Requerimentos

Requisitos claros de segurança e privacidade

Modelagem de Ameaças

A modelagem de ameaças irá apresentar uma visão clara dos riscos associados ao software e um plano de ação para tratamento dos riscos

Arquitetura Segura

É essencial que toda a arquitetura de suporte ao software tenha os requisitos adequados de segurança

16

Revisão de Software

Revisão de Design e Arquitetura

Verificar se os requisitos de design e arquitetura foram atendidos

Revisão de Código

A revisão de código é importante para o desenvolvimento de um bom código e pode identificar fraquezas da equipe de desenvolvimento

Testes de Segurança

Os testes irão verificar se o software tem níveis de segurança aceitáveis para serem disponibilizados

17

Software Implementado

Fortalecimento do ambiente de produção

Hardening dos ativos que suportam o software em produção

Gestão de Vulnerabilidades

Após a implementação do processo é necessário acompanhar e tratar as vulnerabilidades que o software pode apresentar

Gestão de Mudanças

Com o software em produção é preciso estabelecer um processo claro de resposta a possíveis incidentes e tratamento de vulnerabilidades identificadas

18

Conclusões

19

Conclusões

Segurança em desenvolvimento é muito mais que compliance

Não existe um produto que implemente segurança em desenvolvimento

Não existe desenvolvimento seguro sem um bom processo de desenvolvimento de software

Esqueçam a ISO/IEC 15.408/Common Criteria ela não é para segurança em desenvolvimento

20

Referências para SDL

Microsoft SDL

http://www.microsoft.com/security/sdl/

OWASP OpenSAMM

http://www.opensamm.org/

BSIMM

http://bsimm2.com/resources/

21

Blog: http://wagnerelias.comTwitter: http://www.twitter.com/welias