BlueHat Security Briefings v8

  • Article
Eu (Fernando Cima falando aqui) raramente vou a conferências de segurança - acho que a minha última tinha sido a RSA Conference de 2006 em San Jose, que foi tão ruim que a melhor coisa lá foi o guia de restaurantes do Bruce Schneier. Mas desta vez os astros conspiraram, e aproveitando o fato de estar em Seattle a trabalho e o cancelamento de uma reunião permitiram que eu estivesse nos dias 16 e 17 de Outubro na BlueHat Security Briefings - Fall 2008.
image

O nome "BlueHat" vem da história do evento, que foi inspirado no BlackHat Security Briefings que acontece anualmente em Las Vegas. Com o número de funcionários indo à BlackHat passando da centena, a Microsoft viu que ficava mais barato trazer os palestrantes para Redmond e fazer um evento similar fechado para os funcionários. Como o crachá dos funcionários é azul (como o meu ao lado, diferente dos terceirizados que usam crachá laranja) surgiu a BlueHat Security Briefings.

Esta edição foi a primeira aberta para convidados (não-palestrantes) externos, e também a primeira a ser conteúdo transmitido ao vivo, que ficará depois disponível publicamente no site Technet. Assim como a BlueHat o foco das palestras é fundamentalmente em código seguro: vulnerabilidades, técnicas de exploração, teste, revisão de código, etc.

Algumas impressões minhas sobre o evento:

  • Com a adoção maciça de plataformas Web, todas rodando em cima de script e código gerenciado, buffer overflows parecem ser coisa do passado. Não são, claro, mas o foco agora parece estar em vulnerabilidades como XSS, CSRF e injeção de SQL/XML.
  • Outro foco foi em questões de concorrência. Uma palestra muito interessante da iSEC mostrou como várias funcionalidades fornecidas pelos frameworks de aplicação Web, como por exemplo variáveis de sessão, não são thread-safe e podem ser exploradas remotamente caso o atacante envie múltiplas requisições web no timing correto. Os efeitos dependem da aplicação e podem variar de um simples ataque de negação de serviço até fraude financeira. Como se proteger - entendendo o nível de proteção e isolamento de cada recurso e programando cada transação de forma correta. Mais um ponto a ser checado em futuros code reviews...
  • A modelagem de ameaças (threat modeling) evolui muito desde o seu formato inicial - fortemente baseado nas threat trees do Edward Amoroso - até as diversas formas atuais. No evento Adam Shostack mostrou a evolução do lado da Microsoft e a nova ferramenta de modelagem de ameaças, e foi interessante ver Danny Dhillon mostrando a abordagem da EMC.
  • No final houve uma discussão uma discussão constrastando as práticas de desenvolvimento seguro com o uso de Web Application Firewalls (WAFs). Isto é um assunto que mereceria um post por si só, mas para resumir: várias empresas e agora regulações como a PCI-DSS propalam os WAFs como substitutos da necessidade de se desenvolver aplicações seguras. Não importaria que um processo de desenvolvimento seguro não tivesse sido seguido e a aplicação Web tivesse mesmo vulnerabilidades conhecidas, um WAF impediria um atacante de explorar estas vulnerabilidades e garantiria a segurança.

Do ponto de vista de custo sem dúvida os WAFs são mais baratos que implementar um processo de desenvolvimento seguro. Do ponto de vista de benefício todos concordam que no final nenhuma mitigação substitui a correção da vulnerabilidade. A grande pergunta então é - a proteção dos WAFs é o suficiente?

Minha opinião é que a resposta para a maioria das organizações é "não". A variedade de vulnerabilidades já é tão grande (vide por exemplo as questões de concorrência comentadas acima) que os WAFs parecem parar mesmo somente os ataques mais triviais. Além disso o tempo joga contra os WAFs, já que a tendência é que os práticas de desenvolvimento seguros fiquem cada vez mais baratas com o aumento da automação e dos recursos nativos nas plataformas, e os WAFs cada vez menos eficientes com a automação e o aumento da complexidade dos ataques.

Ainda assim WAFs parecem ter um apelo irresistível em organizações com a arquitetura (e a cultura) de segurança baseada em defesas de rede. XSS é um problema? Coloca um firewall na frente. Injeção de SQL? Ora isso é trabalho para o firewall. É uma abordagem cada vez mais defasada em relação a  realidade mas popular o suficiente para garantir um bom mercado para os WAFs nos próximos anos.