php conference brasil 2011 - desenvolvendo seguro (do rascunho ao deploy)
DESCRIPTION
PHP Conference Brasil 2011 - Desenvolvendo Seguro (do rascunho ao deploy)Apresentação do OpenSAMMTRANSCRIPT
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