01/01/2010 - OISF Suricata, Into The Boxes, Visa OTP e Classificação de Ameaças do WASC

2010 está movimentado! Seguem algumas novidades interessantes do primeiro dia do ano:

• A "Open Information Security Foundation" acaba de lançar a primeiríssima versão pública do SURICATA - um novo conceito em IDS open source que pretende revolucionar o mercado! O meu grande amigo e ex-colega de trabalho Breno Silva Pinto trabalha ativamente como desenvolvedor do projeto OISF - que é fundado pelo DHS americano. Entre as funcionalidades do Suricata, estão: Multi-Threading
  Automatic Protocol Detection (HTTP,TLS,FTP, and SMB). HTTP Gzip Decompression, Standard Input Methods, Unified2 Compatibility, Flow Variables e HTTP Logging Module.

• Harlan Carvey e Don Weber lançaram um Magazine Online chamado Into the Boxes (pdf) sobre Forense e Resposta a Incidentes - os assuntos tratados nesta edição são: 1 - a chave de registro UserAssist e suas mudanças no Win 7 e 2008 R2 (incluindo link para download da ferramenta User Asssit do Diddlier Stevens); 2 - Análise de Memória usando o utilitário crash no Linux RedHat; Dicas como não jogar fora o adaptador SATA->USB daquele seu disco externo antigo; cuidados ao usar o FTK Imager; Entrevista sobre PCI com o Carvey.

• Nova geração de cartões VISA terá KeyPad, LCD e gerador de 'one time password' - Falando em PCI, tecnologia similar já é usada na Holanda há anos e deve diminuir sensivelmente a fraude online para os portadores deste tipo de cartão.

• A versão 2.0 do Threat Classification do WASC (Web Application Security Consortium) foi publicada - até o momento objetivo estão classificados 33 categorias de ataques como Cross-Site Scripting, Buffer Overflow, Remote File Inclusion e 15 vulnerabilidades como Improper Input Handling e Information Leakage - que podem levar ao comprometimento de um site, seus dados e seus usuários.
  
  

(In)Segurança em Desenvolvimento de Software e o modelo BSIMM

[ Update: 29/09/2010 ]

O Fabrício Braz divulgou sua tradução para o português do BSSIM:

http://softwareseguro.blogspot.com/2010/09/build-security-in-manturity-model-em.html

[ Post Original: 14/03/2009 ]

O Marcelo Souza fez um post muito interessante sobre segurança em desenvolvimento e o modelo BSIMM, publicado por Gary McGraw, Brian Chess e Sammy Migues.

"O BSIMM (Building Security In - Maturity Model), um modelo de maturidade focado em segurança de software. O modelo foi elaborado com base em iniciativas de segurança de 9 empresas diferentes, entre elas Adobe, EMC, Google e Microsoft. Utilizando um arcabouço de sua autoria denominado SSF (Software Security Framework), que aponta domínios e práticas comuns das iniciativas em segurança de software, o grupo conduziu pesquisas nas empresas participantes e utilizou os dados obtidos para construção do modelo.

O modelo lista 110 atividades divididas em 12 práticas dos 4 domínios do SSF. Cada prática pode receber até o nível 3 de maturidade. Totalmente livre (licença Creative Commons), o modelo pode ser obtido neste link (requer registro), ou acessado interativamente aqui."

Normalmente estes modelos são muito teóricos, mas o BSIMM me pareceu suficientemente específico e mais próximo da realidade. Me lembrou em certos aspectos os guias do NIST e do CERT, - cuidado você pode desanimar quando ler o primeiro ítem da lista: "Apoio da Alta Administração"...

O BSIMM é um esforço de organização e categorização de um problema complicadíssimo que é o desafio em desenvolver, manter, comprar, integrar e utilizar softwares de forma segura. Isto é tão difícil que é necessário todo interesse, apoio, priorização e investimento para que uma empresa alcançe um nível real razoável em qualquer das 12 práticas dos 4 domínios do Software Security Framework (Governança, Inteligência, Ciclo de Desenvolvimento e Implementação). Para uma empresa grande e com processos viciados é quase como um idoso aprender a falar outra língua fluentemente - pode demorar décadas (que ele não viverá).

Segundo o BSSIM, uma medição máxima de "maturidade" do modelo seria 12*4*3 = 144. O perigo é que as pessoas tenderão a se basear nesta medida para considerar mais seguro um projeto/software/empresa que alcance uma pontuação alta em um assessment do BSSIM.

Isto funciona até o próximo deslize mínimo de uma destas empresas envolvidas que estão implementando o modelo e todos os esforços, conquista de "compliance" e melhores práticas ou "nível de maturidade" vão embora. Alguns exemplos: SDL Microsoft, ex-PCI da Heartland (obtido em Abril e revogado ontem), ou a metodologia de outros participantes do BSSIM - Adobe por exemplo - que deixou o Reader PDF sem correção crítica por 15 dias...

Isto nos mostra quão longe realmente estamos de uma melhora significativa, e quanto este esforço - apesar de louvável - tem como maior mérito a conscientização dos próprios responsáveis e envolvidos pela segurança do desenvolvimento de softwares, e talvez uma falsa sensação de segurança para quem tem o "seu" na reta (CSO, CIO, C[A-Z]O), que ficarão felizes com uma pontuação alta no BSSIM.

Se compararmos este cenário com a facilidade que um atacante - bem preparado, com tempo e alvo fixo em mente - consegue explorar falhas de design, implementação, configuração e/ou programação de um destes controles, entendemos o porque do uso do termo "guerra assimétrica" para descrever ataques perpetrados por hackers.

Parafraseando o Kevin Mitnick: Uma empresa precisa conhecer, encontrar e corrigir todos os erros de segurança (e ainda detectar, encontrar e tentar prender o atacante) , um hacker só precisa encontrar e explorar uma falha. Ou seja, do ponto de vista do atacante, 143 = 0.

E pra piorar, já que a "Alta Administração" não vai apoiar por falta de interesse, investimento, compreensão e prioridade, enquanto você não consegue se esmerar nas 110 atividades listadas, se prepare para continuar a responder a muitos incidentes de segurança e esteja com sua equipe de computação forense sempre a postos e bem treinada... =)

Fases de um Ataque: Stealth

[ 17/02/2009 - Update: ]

O Bruce Schneier se pronunciou sobre o tema, baseado também no caso da Logic Bomb da Fannie Mae. (Obrigado ao Marcelo e Lucas pelo link).

[ 12/02/2009 - Update: ]

O blog sobre forensics do Sans Institute publicou um artigo sobre "Logic Bombs", citando o caso da Fannie Mae, dentre outros, vale a pena conferir. Eles também fizeram algumas colocações interessantes para evitar ser vítima deste tipo de ataque - resumindo:

- Conheça, controle e revise os acessos aos seus sistemas de informação
- Utilize o princípio do mínimo privilégio - como base para a distribuição de acessos.
- Garanta que a revogação de privilégios seja um processo rápido e automatizado.
- Leve a sério ameaças de empregados insatisfeitos

Eu acrescentaria à esta lista:

- Monitore e audite os acessos administrativos ( não conte com a sorte =)

[ 03/02/2009 ]

Em 1998 um artigo de Alan Boulanger chamado "Catapults and Grappling Hooks, The Tools and Techniques of Information Warfare" apresentou uma divisão até então inédita das fases comumente utilizadas durante um ataque computacional. São elas: 1. reconnaissance, 2. probe, 3. toehold, 4. advancement, 5. stealth, 6. listening post, and 7. takeover.

Cada uma das fases descritas é proporcionada ou auxiliada pela fase anterior e de forma direta ou indireta prepara o atacante para a execução da próxima.

Onze anos depois, as fases conceituais não mudaram muito, mas certamente a motivação dos atacantes e a importância das diferentes fases para que estes alcancem seus objetivos são sempre variáveis.

Neste post pretendo apresentar três casos em que a fase stealth de ataques publicamente conhecidos foi fundamental, deixando claro os perigos inerentes ao não reconhecimento tempestivo das fases anteriores, o que acarreta invariavelmente em grandes perdas financeiras diante de atacantes bem preparados e motivados.

1) Em 2005, um ataque extremamente sofisticado culminou no escândalo com roteiro de filme - incluindo suicídio de um engenheiro envolvido na trama - ocorrido com a operadora GSM grega Vodafone-Panafon. A bem executada fase stealth do ataque permitiu que os perpetradores grampeassem o celular de mais de 100 figuras públicas da Grécia durante vários meses.

2) A HeartLand - empresa que recentemente divulgou ser vítima de um ataque stealth elaborado que possibilitou o maior vazamento de dados de cartão de créditos da história, ocorrido em 2008 - precisou de 3 equipes de investigação e mais de 2 meses depois de um alerta da Visa para descobrir que o sniffer responsável pela captura dos dados estava escondido em espaço não alocado do disco de seus servidores.

3) Na Fannie Mae - empresa de hipotecas sob administração do governo americano desde setembro de 2008 - um ex-administrador de sistemas contratado implantou em 4000 de seus servidores UNIX uma bomba relógio que iria remover o acesso dos demais administradores e apagar (wipe) vários terabytes de dados críticos da empresa, em 31/01/2009. Por sorte, o plano foi descoberto antes porque o esforço stealth deste atacante interno foi baixo, ele apenas incluiu várias linhas em branco dos scripts de manutenção dos servidores antes de digitar seus comandos maliciosos. Se a mesma sofisticação dos casos 1) e 2) tivesse sido utilizada, o impacto seria altíssimo.

TOP 25 CWE/SANS - Problemas de Segurança em Programação (Prós e Contras)

Programar é uma tarefa relativamente simples, mas desenvolver produtos complexos de forma segura e garantir que sua implementação/configuração não irá incluir riscos associados tem se mostrado uma tarefa dificílima de se conseguir. Não é a toa que recentemente o tema de Segurança em Desenvolvimento tem crescido fortemente dentro da comunidade de Segurança da Informação.

Recentemente, o CWE e o SANS Institute divulgaram uma lista dos 25 erros piores erros de programação do ponto de vista da segurança.

A iniciativa não é nova (vide OWASP Top 10, 19 Sins book, e as específicas de linguagens como Java, C, Perl, PHP, ...) , mas claro que é bastante válida - desde que usada com critério.

Algumas críticas interessantes (obrigado, Lucas) foram colocadas por alguns especialistas na área de desenvolvimento seguro, como Gary McGraw - que compilou uma interessante lista de 11 principais motivos do porque listas de "top 10" (ou 25) devem ser avaliadas com cautela.

Alguns pontos interessantes da crítica de McCgraw (tradução livre):

• 1 - Executivos não dão a mínima para erros técnicos
• 3 - Listas de Vulnerabilidades ajudam mais aos auditores do que aos desenvolvedores
• 6 - Listas de erros se modificam de acordo com a mudança da tecnologia
• 9 - Métricas construídas sobre listas "Top N" são enganadoras.

16/01/2009 Update - a OWASP acusa o SANS Institute de plágio.

Saiu a nova edição da INSECURE MAGAZINE

Apesar do excesso de propagandas, a Insecure Magazine é uma excelente leitura, como sempre, nesta edição de Julho/2008 existem artigos sobre os seguintes temas:

• O Futuro da Segurança (informação como foco)
• Segurança do fluxo de dados dentro na empresa
• Identificação de Falhas e Análise de Risco Técnica através Modelagem de Ameaças
  
• Riscos em VoIP
• Construindo WLANs seguras por menos de 300 dólares
• Engenharia Reversa em Malwares: os dois lados da moeda.
• Soluções de segurança 'end-point'
• Hackeando Second Life
• Update OpenSSL do Debian: quando boas intenções dão errado.