especialização em segurança da informação segurança em aplicações 4. processo...

Especialização em Segurança da Informação

Segurança em Aplicações4. Processo Desenvolvimento Seguro

Márcio Aurélio Ribeiro [email protected]

http://si.lopesgazzani.br/docentes/marcio/

Márcio Moreira 4. Processo de Desenvolvimento Seguro – slide 2Segurança em Aplicações

Cenário atual

Volume de ataques

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

0

50000

100000

150000

200000

250000

300000

350000

400000

3107

5997

1230

125

092

5460

775

722

6800

019

7892

1600

80 2225

2835

8343

1428

44

Tipos de ataques de 2010

12% 6%

57%

22%3%

Worm DoS Invasão Web ScanFraude Outros

Fonte: www.cert.br/stats/incidentes/ Fonte: www.cert.br/stats/incidentes/2010-jan-dec/total.html

http://www.cert.br/stats/incidentes/

http://www.cert.br/stats/incidentes/2010-jan-dec/total.html


Quantidade de vulnerabilidades

Por Indústria

TI

Vendas

Educação

Redes Sociais

Telecom

S.Financeiros

Saúde

Seguros

Bancos

Outras

0 5 10 15 20 25

Por porte

37%

32%

31%

Grande Médias Pequenas

Fonte: www.whitehatsec.com/home/resource/stats.html Fonte: www.whitehatsec.com/home/resource/stats.html

http://www.whitehatsec.com/home/resource/stats.html



Qualificação dos ataques

Camadas exploradas Tipos de ataques

Fonte: www.sans.org/top-cyber-security-risks/trends.php

xSite Script

Vazamento

Spoofing

xSite Request

Autorização fraca

SQL InjectionLocalização previsível

Fixação de sessão

Força bruta

Outras

0% 20% 40% 60% 80%

Fonte: www.whitehatsec.com/home/resource/stats.html

http://www.sans.org/top-cyber-security-risks/trends.php

http://www.sans.org/top-cyber-security-risks/trends.php



Impactos gerados pelos ataques

Prejuízos com fraudes

2001 2002 2003 2004 2005 2006 20070

50

100

150

200

250

18

54

126

68

183198

239

Valores em Milhões de Us$

Fontes dos ataques

Fonte: www.nist.org/news.php?extend.254

80%

20%

Internos Externos

Fonte: CSI/FBI citado por:http://taosecurity.blogspot.com/2009/05/insider-threat-myth-documentation.html

Us$70M de custos de resposta, sendoUs$406K devido a acesso não autorizado

Us$2,8M de custosde resposta

http://www.nist.org/news.php?extend.254





http://taosecurity.blogspot.com/2009/05/insider-threat-myth-documentation.html




Alvos e ferramentas de segurança

Produto:Devemos desenvolver com

segurança eGarantir a segurança da

aplicação desenvolvida Processo:

Para isto precisamos de um processo seguro

Pessoas:As pessoas precisam

pensar, usar e multiplicar os princípios de segurança

Ferramentas & Ambientes:Devem atender as

premissas de segurança


Processo de desenvolvimento seguro

Princípios:Segurança por projeto

O software deve se projetado, arquitetado e implementado para ser resistente aos ataques

Segurança por defaultConsiderar o ambiente de produção inseguroUsar privilégios mínimos e só disponibilizar o necessário

Segurança no desenvolvimento e produçãoFerramentas e guias de segurança devem ser disponibilizados

aos usuários finais e administradores da aplicaçãoComunicações

Em caso de descoberta de vulnerabilidades comunicar claramente o cliente quais ações a serem tomadas


Ciclo de vida de vulnerabilidades

Fonte: Pascal Meunier, Overview of Secure Programming, 2004, http:cerias.purdue.edu


Modelagem de negócio

O que fazer?Identificar diretivas estratégicas de segurançaIdentificar necessidades de segurançaRevisar o processo de negócio sob a ótica da segurançaFaça uma modelagem de ameaças e riscos no nível de

negócioClassifique os processos de negócio quanto à

segurança

Como fazer?Acrescentar as atividades acima nas atividades do

processo de modelagem


Requisitos

Os requisitos de segurança e privacidade devem ser definidos e especificadosClassifique as informações quanto à segurançaDeixe claro o que os casos de uso e os atores podem e

não podem fazer em termos de segurança Os papéis e responsabilidades de segurança

devem ser especificadosA norma internacional ISO/IEC 15408 (Common

Criteria):É usada para definir os requisitos de uma aplicaçãoMas, também é utilizada para avaliar a segurança de

uma aplicação pronta


Common Criteria – Conceitos 1

TOE - Target Of Evaluation:Sistema a ser avaliado

PP - Protection Profile:Padrão de segurança (definido pelo mercado) que um

tipo de aplicação precisa ter

SFR - Security Functional Requirements:Especificação dos requisitos funcionais de segurança

ST - Security Target:Propriedades de segurança de cada elemento do TOE

avaliado contra os SFR


Common Criteria – Conceitos 2

SAR - Security Assurance Requirements:Que medidas tomadas no desenvolvimento e na

avaliação para garantir os requisitos de segurança da aplicação

EAL – Evaluation Assurance Level:Nível de segurança do ST e do TOE (sistema).Valores de 1 a 7, especificados pelo PP.

Padrão ISO: 1 a 4, Exemplo: Windows 2000 (EAL4).Os níveis de 5 a 7 são muito rígidos, normalmente

usados por agências de segurança governamental.


Como usar a CC no desenvolvimento?

Use padrões (PP) como guia Especifique os requisitos de segurança (SFR) Especifique como garantir a segurança (SAR) Mantenha todos ambientes com no mínimo EAL3 Analise e projete a implementação dos SFR Use boas práticas de programação Teste a implementação dos SFR usando os SAR

Gere evidências de aderências à normaSe o TOE for crítico, utilize entidades certificadoras para

avaliar a segurança


Como usar a CC em aplicações prontas?

Levante o padrão (PP) aplicável Levante os SFR da aplicação e dos ambientes

(desenvolvimento e produção) Teste se os SFR foram implementados

adequadamenteUtilizando os níveis de EAL1 a EAL3Os níveis superiores requerem testes durante o

desenvolvimento Realize testes de penetração e de ataques que

forem aplicáveis Verifique as evidências apresentadas dos SAR


Referências e exemplos da CC

Referências:Common Criteria portalCommon Criteria – parte 1 (modelo geral)Common Criteria – parte 2 (funcionalidades)Common Criteria – parte 3 (garantias)

Exemplos de uso:Especificação dos Requisitos de Segurança do

Lotus Notes da EMPRESA XProtection Profile – Controlled Access - NSAWindows 2000 – Security Target

http://www.commoncriteriaportal.org/





Análise & Projeto

Faça a modelagem de ameaças a nível de componentes(ativo ameaça risco) & requisitos projeto

Defina e revise a segurança da arquitetura Crie guias de análise e projeto seguros Crie e use padrões de projeto seguro

Camadas, parâmetros fortemente tipados, menor privilégio e minimize as áreas de exposição

Documente as áreas de exposição Defina critérios para eliminar vulnerabilidades


Implementação

Use padrões de codificação e testesIsto evita a introdução de novas vulnerabilidades

Use ferramentas de testes de segurançaExistem ferramentas que testam até a entrada de dados

inválidos para as APIs e interfaces de rede

Use ferramentas de varredura estática de códigoAlgumas ferramentas podem detectar fluxos de código que

resultam em vulnerabilidades

Faça revisõesTreine os desenvolvedores para fazer revisões e eliminar

vulnerabilidades


Equipe de Implementação

Inclua nos treinamentos os padrões de segurança Faça treinamentos por perfil: gerente de projeto,

arquiteto, analista, desenvolvedor, testador, etc. Apoie iniciativas de melhorias de padrões Tenha um especialista em segurança na equipe Disponibilize o conhecimento existente

Escrevendo código seguroModelagem de ameaçasPadrões de projetoGuias de melhores práticas


Um pequeno descuido Blaster Duas linhas de código C no RPCSS (CERT Blaster):

while (*pwszTemp != L'\\')*pwszServerName++ = *pwszTemp++;

Levaram a:>15 milhões de computadores infectados 3.3M de chamados de suporte em Set/2003 (volume normal

relacionado a vírus é de 350K)Muita repercussão negativa “Isto aumentará o nível de frustração ao ponto que várias

organizações irão contemplar seriamente alternativas à Microsoft”. Gartner Group

“É realmente recomendado ter cautela aqui. Os esforços [de segurança da Microsoft] foram sinceros, mas não estou certo se foram sinceros o suficiente.” Forrester Research

Fonte:Microsoft – TechEd 2005 - José Antonio das Neves Neto

http://www.cert.org/advisories/CA-2003-20.html

http://www.cert.org/advisories/CA-2003-20.html


Testes

Revise código legado Faça testes de segurança nos componentes Faça testes de segurança da interface com usuário Faça testes de ataque e penetração no sistema

How to Break Software Security – Addison Wesley 2003 Faça testes de abuso dos SRF e SAR Faça testes que cubram código novo, código

alterado e código antigo Revise o modelo de ameaças (técnicas e negócio) Teste todo o modelo de ameaças Prepare o plano de resposta a ataques


Custo de correções de falhas

Fonte: Research by @Stake for IBM, publicado por Corsaire Limited em 2004

Fase

%


Distribuição

Crie baselines de distribuições segurasAtualize as bases de distribuição somente

através de ferramentas segurasPlaneje a integridade dos meios físicosDisponibilize chaves hash de verificaçãoInclua verificações de segurança no

ambiente antes de instalar o produtoPrepare material orientando o cliente e o

usuário sobre procedimentos de segurança


Gestão de configuração e mudança

Os elementos de segurança devem ser planejados, validados, verificados e corrigidos durante as mudanças

Revisar os requisitos das mudanças em face dos elementos de segurança

Garantir atualização da modelagem de ameaças

Garantir atualização da implementação dos novos elementos de segurança


Gerência de projetos

O gerente de projeto deve garantir a segurança durante o desenvolvimento

Deve garantir a execução das revisões e dos demais elementos do processo seguro

Deve validar os SFR, SAR e outras questões de segurança com o cliente

Executar a revisão final de segurança


Ambientes

Ambientes livres de ataquesDesenvolvimento, testes,

homologação e produçãoRedes, wireless, servidores,

acesso remoto, e-mail, impressão, atualização de SO, etc.

Cuidar da segurança física Planejar os procedimentos

de atualização Use:

Single Sign-On, políticas de grupos e processos de gestão de usuários e perfis

Mercado de Serviços de DiretóriosFonte: Microsoft TechEd 2005


Resumo do processo seguro•Identifique as diretrizes estratégicas de segurança•Identifique as necessidades de segurança•Revise o processo de negócio sob a ótica de segurança

Modelagem de Negócios

•Levante os requisitos de segurança e de garantia de segurança•Defina os papéis e responsabilidades de segurança•Combine os critérios de aceite de segurançaRequisitos•Analise as ameaças no nível de componentes•Defina e revise a arquitetura de segurança•Prepare os guias de segurança e treine a equipeAnálise & Projeto•Use padrões seguros de codificação •Faça revisões cruzadas•Teste a segurança das unidades e de varredura de códigoImplementação•Faça testes de segurança•Faça testes externos•Prepare o plano de resposta a ataquesTestes•Resolva os problemas críticos•Crie baslines de distribuições seguras em ambientes seguros•Prepare procedimentos de uso e administração seguros

Distribuição & Ambiente

•Faça análise de impacto de segurança das mudanças•Garanta a atualização dos artefatos de segurança•Avalie as lições aprendidas e refine o processo

Gestão de Projetos, Configuração & Mudanças


Fatores críticos de sucesso

Aplicação obrigatória do processoCapacitação dos desenvolvedoresDefinição das métricas de segurança

Estabeleça indicadores, métricas, objetivos e metas

Política de segurançaGrupo de segurançaEspecialista em segurança na equipeExecução das revisões (parcial e final)


Complexidade x Vulnerabilidades

Webserver market shareApache: 67%, MS-IIS: 25% (Fev/03)

Com SSL:Apache: 54%, MS-IIS: 35% (Set/02)

Fonte: CGI International

Windows Complexity

05

1015202530354045

Win3.1

(1990)

WinNT

(1995)

Win 95(1997)

NT 4.0(1998)

Win 98(1999)

NT 5.0(2000)

Win2K

(2001)

XP(2002)

Mil

lio

ns

of

Lin

es

Fonte: MicrosoftFonte: CERT/CC


Resultados da aplicação do processo

Microsoft Security Bulletin Search:1 vulnerabilidade no IIS 6 em dois anos1 vulnerabilidade no SQL 2000 em dois anos

Boletins Críticos + Importantesdivulgados após lançamento do produto


Processos em ascensão

MicrosoftSDL - Secure Development Life

OracleSDP - Secure Development ProcessOracle Software Security Assurance Process

IBMCLASP - Comprehensive, Lightweight Application

Security ProcessSUN

SDP - Secure Development Process

especialização em segurança da informação segurança em aplicações 4. processo...

Documents