Algumas Verdades Difíceis de Admitir

Vale a pena ler o artigo 11 Truths We Hate do Admit , escrito pelo Rich Mogull do blog Securosis. Estas "verdades" são coisas que muitos de nós já há algum tempo no mercado já sabemos, mas que poucas vezes são colocadas em termos tão claros. Alguns dos pontos que eu achei mais interessantes:

¦ "Fornecedores são como políticos - eles mentem para nós porque nós pedimos"

Como muitas organizações não sabem exatamente o que precisam, partem para a forma mais fácil de fazer uma RFP: pedir tudo. Isso inclui exigir que um produto suporte todas as 30 RFCs que remotamente tocam aquele tema, exigir todas as certificações possíveis para o produto, incluindo a Common Criteria. Tudo isso é claro garantindo a interoperabilidade com 10 sistemas operacionais diferentes e suportando todos os bancos de dados existentes no mundo.

Em resposta a este jogo de "pedir tudo", os fornecedores contra-atacam com a tática de "prometer tudo". Como resultado, depois de uma eventual compra temos todos os estágios de Kübler-Ross: negação, cólera, negociação, depressão, e por fim a aceitação que o produto que ele adquiriu faz só aquilo mesmo.

¦ "Nós somos terríveis em conversar entender aqueles que nos pagam"

Em me lembro disso toda ver em que encontro um Dr. No conduzindo a segurança de uma empresa...

¦ "Segurança de rede é o resultado de um equívoco, e não algo que valha a pena perpetuar"

Ah nada mais verdadeiro. Soluções como firewall, VPN, gateways, etc. existem basicamente porque os protocolos de comunicão que utilizamos foram criados em uma época onde segurança não era considerada nos requisitos, e que por isso não implementam características como autenticação mútua, encriptação e integridade dos dados.

A medida em que a infrastrutura de rede está sendo comoditizada e colocada fora do controle da organização, e que estamos movendo para protocolos como IPsec e SSL/TLS, estas soluções estão rapidamente perdendo a importância. Por que usar uma VPN se eu já posso acessar o meu dado ou aplicação nativamente de forma segura usando HTTPS ou RDP com SSL? Por que usar um IDS de rede se todo o meu dado está passando encriptado na rede? São perguntas que vão ficar cada mais mais comuns nos próximos anos.

Já em um post no blog de SDL da Microsoft uma outra verdade: desenvolvimento seguro não é um tema nada sexy. Na verdade é incrivelmente chato. Outras áreas em segurança da informação tem essa aura de desafio e emoção, como mostra o reality show mostrando uma equipe de testes de penetração, mas ninguém jamais filmaria um grupo de desenvolvedores construindo um modelo de ameaças. Ou fazendo uma revisão de código. Mataria o telespectador de tédio.

A nossa experiência em eventos é similar. No TechEd basta programar uma palestra sobre "como quebrar xxx" [insira o nome do produto] e a sala enche. Já uma sessão sobre "desenvolvimento seguro" vai ter talvez 20% do público. Precisamos de alguma forma de tornar isso mais atraente.

Comments

• Anonymous
  February 27, 2008
  Concordo contigo; Eventos presenciais sobre desenvolvimento seguro devem direcionados para um público específico. Em minha palestra no TechEd 2007 (Desenvolvimento Seguro p/ Windows Vista), haviam poucas pessoas, a maioria da área de segurança e poucos desenvolvedores de fato. Entretanto, no último webcast (Desenvolvimento Seguro p/ ASP.NET), com foco em uma linguagem, tivemos 77 participantes desenvolvedores, recorde até o momento :-). Acredito que a idéia para divulgar o tema seja direcionar para a suíte Visual Studio, com foco em cada linguagem (ASP.NET, VB.NET, C#, etc). Do ponto de vista didático, esta abordagem é mais eficiente.