php conference brasil 2011 - desenvolvendo seguro (do rascunho ao deploy)

Desenvolvendo Seguro

(do rascunho ao

deploy)

Erick Belluci Tedeschi @ericktedeschi

Erick Belluci Tedeschi

- Analista de Segurança da Informação

- Ex desenvolvedor

- PHPzeiro nas horas vagas

- Web Security Researcher

- Motociclista

- Guitarreiro

Agenda

• Estatísticas

• Cenário atual

• Motivação

• OpenSAMM?

• Governance

• Construction

• Verification

• Deployment

Estatísticas e memes! 73 Percent of Organizations Have Been Hacked At Least

Once In The Last 24 Months Through Insecure Web

Application

Fonte: http://www.barracudalabs.com/wordpress/index.php/2011/02/08/73-percent-

of-organizations-have-been-hacked-at-least-once-in-the-last-24-months-through-

insecure-web-applications/

Estatísticas e memes! Mais da metade das aplicações Web não passam nos

testes de segurança antes do deploy

Fonte:http://www.eweek.com/c/a/Security/More-than-Half-of-Web-Apps-Fail-Security-

Audit-Prior-to-Deployment-542967/

Security firm finds hacker forums offer n00b hackers

training, lulz

Fonte: http://www.imperva.com/news/news.html

Na mídia

Na mídia Security firm finds hacker forums offer n00b hackers

training, lulz

Hackers forums provide sense of community, information

security intelligence

Fonte: http://www.imperva.com/news/news.html

Na mídia Security firm finds hacker forums offer n00b hackers

training, lulz

Hackers forums provide sense of community, information

security intelligence

Hackers Share Attack Techniques, Beginner Tutorials on

Online Forum

Fonte: http://www.imperva.com/news/news.html

ZIDRUMERAMALDITOS HACKERSZ

QUEREM DOMINAR O MUNDO NAO VOU

MAIS PODER NEM PENSAR EM PÚBLICO

SE NÃO VÃO ME OWNAR

Na mídia “The good news is that developers are learning from their

mistakes quickly. More than 90 percent of the software

that failed the audit the first time addressed the issues and

passed a subsequent test within one month. Security

products were fixed even faster, becoming “acceptable” in

just three days”

Fonte: http://www.eweek.com/c/a/Security/More-than-Half-of-Web-Apps-Fail-

Security-Audit-Prior-to-Deployment-542967/

Cenário atual 1/3

• Cliente envia o briefing

• Desenvolvedor materializa os requisitos, testa, e faz

deploy no servidor de produção do cliente

• …ou entrega pacote para o cliente

Cenário atual 2/3 • Definição e requisitos de negócio (funcionais e não

funcionais)

• Inception/Brainstorming

• Estórias

• Área de desenvolvimento materializa os requisitos

transformando em software/aplicação.

• Equipe de QA realiza testes de acordo com

requisitos / eventualmente realiza stress test.

• Equipe de Operações faz o deploy da aplicação em

produção.

Cenário atual 3/3 • Área de negócio demanda novo projeto

• Inception/Brainstorming

• Estórias

• Área de desenvolvimento materializa os requisitos

transformando em software/aplicação.

• Equipe de QA realiza testes de acordo com

requisitos / eventualmente realiza stress test.

• Equipe de segurança realiza teste de penetração.. ui

• Equipe de Operações faz o deploy da aplicação em

produção.

Motivação Redução de Custo efetivo do projeto

Motivação

- Credibilidade

- Conformidade

- Prazo (tempo = dinheira)

- Maturidade do processo de desenvolvimento

Software Assurance

Maturity Model

Software Assurance Maturity Model

Software Assurance Maturity Model

• Estabelecer um programa que garanta

a segurança da informação

• Definição de metas de segurança

• Análise de risco (ativos, ameaças,

vulnerabilidades)

• Métricas e feedback sobre o programa

de segurança

Software Assurance Maturity Model

• Requisitos legais

• Normas e padrões internos/externos

• Compliance/Auditoria

• Adoção e compreensão do programa

por todos os envolvidos

Software Assurance Maturity Model

• Treinamento para colaboradores

• Guidelines

• Baselines

Software Assurance Maturity Model

• Modelagem de ameaças inerente ao

projeto

• VIP (Very Important)

Software Assurance Maturity Model

• Requisitos de segurança baseados nas

funcionalidades da aplicação e

alinhados com o programa de

segurança.

Software Assurance Maturity Model

• Foco em modelagem e

desenvolvimento de software seguro

• Design Pattern para problemas de

Segurança

• Utilizar libs (pecl, pear, classes*,

gem’s, cpan’s) historicamente seguras.

• Infraestrutura segura

Software Assurance Maturity Model

• Permite a identificação de

vulnerabilidades a nivel de arquitetura

antes de o software ser desenvolvido.

• Desenho do fluxo de dados para

informações críticas.

Software Assurance Maturity Model

• Inspeção do código para procurar

vulnerabilidades de segurança

• Automação

• Teste unitário para requisitos de

segurança

Software Assurance Maturity Model

• Inspeção do código em tempo de

execução

• Estabelecer um processo para

execução de testes de penetração

baseado nas implementações e

requisitos

Software Assurance Maturity Model

• Resposta a incidentes

• Bugtrack/abuse

• Coletar métricas sobre o incidente

Software Assurance Maturity Model

• Hardening?

• Ambiente de desenvolvimento com

hardening aplicado + “debug mode=on”

Software Assurance Maturity Model

• Documentação de instalação/operação

• Processos de backup/restore

• Disaster recovery

Software Assurance Maturity Model

• As praticas não possuem uma ordem sequencial

ou cronológica

• Cada prática possui 3 níveis de maturidade

• Modelos/exemplos de programas para tipos de

organização

Perguntas?

^$ (EOL)

Agradecimentos

Rafael Lachi \o/

Cássia P. Melo <3