Site Meter BlueHat Security Briefings v8 - Negócio de Risco - Site Home - TechNet Blogs

Negócio de Risco

Blog do Time de Segurança da Microsoft Brasil

BlueHat Security Briefings v8

BlueHat Security Briefings v8

  • Comments 6
  • Likes
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.

Comments
  • Cima, Djalma, Abu,

    Excelentes posts. Incluído ao meu (pequeno) grupo de favoritos no safari, digo, IE. :-)

    abraço,

    Teófilo.

  • Cima,

    A formatação ficou muito ruim neste post.

    Testei em varios navegadores, incluindo IE7, e aparece com parte do texto escondida ...

    Não dá para ler direito ...

    Abraços

  • Leandro, falha nossa. O HTML já deve estar corrigido, veja se funciona aí.

  • Cima, devia ter passado lah no lounge de speakers/vip para dar um oi, puxa vida.

    eu particularmente, gostei muito da palestra de fuzzing no segundo dia.

    abs

  • Oi LE, eu não sabia de tão ilustre presença no evento! Na próxima vez que estiver em Seattle me avise para combinarmos algo.

    Eu não consegui vaga oficial no segundo dia do evento (devido ao registro em cima da hora!) então fiquei na sala de overflow ao lado vendo pelo telão. Eu gostei também da sessão de fuzzing, especialmente do trabalho para reduzir o número de iterações necessárias.

    Quem viu a sessão também certamente ficou muito mais impressionado com quem quer que tenha descoberto a vulnerabilidade MS08-067 no serviço Server. Este serviço teve com certeza muito mais do que as 500 mil iterações de fuzzing recomendadas, além de ter passado por todo tipo de análise de código estática e code review que se possa imaginar. Como é que ainda assim a vulnerabilidade permaneceu lá? Food for thought...

    - Fernando Cima

  • Web Application firewall ou os firewalls de camada 7 não podem resolver os problemas de segurança de aplicações mal construidas. não há como o firewall saber o que é danoso ou não, visto que o mesmo dado trafegado pode ser um texto em um wiki de assunto técnico (inócuo) ou um sql injection em uma aplicação bancaria.

    Do lado do desenvolvedor não é criado muito trabalho extra para implementar segurança, bastando que ele estaja ciente das más práticas a evitar. E os requisitos mais funcionais de segurança podem ser incluidos no framework utilizado para que não tenha que ser reimplementado o tempo todo...

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment