Uma razão para a persistência deste cenário é que não existem padrões efetivos para o desenvolvimento de software seguro, ou melhor, não existem processos bem definidos visando este objetivo. Na verdade, apesar dos problemas, boa parte das organizações nem mesmo discute esta necessidade.

Por outro lado, várias empresas relevantes no mercado já se posicionaram num sentido positivo. A Microsoft, por exemplo, aplica desde 2005 a metodologia SDL (Security Development Lifecycle), de autoria própria. Felizmente, muitos desenvolvedores e gerentes de desenvolvimento já entendem a necessidade da segurança de software, e as iniciativas em busca da aplicação de modelos, guias e padrões têm sido crescentes. Um exemplo claro é o crescimento da comunidade em torno do projeto OWASP (Open Web Application Security Project).

Paralelamente, ao longo dos anos, tem se tornado cada vez mais evidente que desenvolver software seguro depende do resultado conjunto de pessoas e processos, e não somente de tecnologia. Outras experiências também mostraram que, mesmo sendo únicas, as organizações podem tirar bom proveito de práticas bem sucedidas de outras organizações, ao invés de simplesmente se basear em metodologias teóricas.

Tendo tudo isso em mente, um grupo de especialistas em segurança de software das empresas Cigital (Gary McGraw, Sammy Migues) e Fortify (Brian Chess) publicou 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.

Para entender e considerar o BSIMM positivo, deve-se levar em consideração pelo menos dois fatores:

• Apesar de utilizarem métodos diferentes, as empresas envolvidas na pesquisa empregam iniciativas de segurança que compartilham melhores práticas. O BSIMM condensou as atividades e boas idéias comumente aplicadas.
• Modelos de maturidade têm sido aplicados em diferentes áreas há muito tempo, com bom nível de disseminação. O BSIMM se apresenta num formato já consolidado e aceito internacionalmente.

O BSIMM não é um guia completo ou um “how-to”, mas pode ser um bom começo para aqueles que lidam com desenvolvimento e implantação de software, ou que de alguma forma dependem da confiabilidade dos aplicativos e programas que suportam o negócio de sua organização.

Muito tempo depois do memorável artigo de Marcus J. Ranum, entitulado The Six Dumbest Ideas in Comupter Security, Lenny Zeltser publica mais uma grande contribuição: How to Suck at Information Security.

Sugiro a leitura completa deste último, e aproveito para fazer comentários sobre alguns dos tópicos que concordo plenamente (tradução livre):

• Assumir que os usuários irão ler a política de segurança por uma mera solicitação: o resultado é óbvio, pois poucos irão ler um documento que para eles fará pouca diferença (ou só trará chateações, de seu ponto de vista). Nada mais recomendável que iniciativas de awareness frequentes, com palestras, material multimídia, teatros, etc. Estas sim podem se mostrar bem mais efetivas.
• Criar políticas de segurança que não podem ser garantidas: fazendo uma analogia bem simples, a “Lei Seca” seria com certeza muito mais efetiva se tivéssemos mais bafômetros nas ruas.
• Praticar políticas de segurança que não foram devidamente aprovadas: em outras palavras, quem foi que disse que a partir de hoje o Skype está bloqueado?
• Executar testes de vulnerabilidade, mas não acompanhar os resultados: esta é uma prática muito comum, mas que faz muita falta ao se criar indicadores. Normalmente se investe muito em network assessments e pen-tests, porém estes sempre devem envolver o trabalho posterior de correção.
• Adquirir produtos caros quando uma simples correção poderia consertar 80% do problema: um exemplo clássico é o uso de um WAF (web application firewall) para proteção de aplicações web com vulnerabilidades que poderiam ser corrigidas com muito menos recurso (pretendo falar mais sobre WAFs num post futuro).
• Banir o uso de discos USB externos e continuar sem restringir acesso à Internet: sem dúvida uma das maiores dores de cabeça quando se fala em vazamento de informações, os acessos a webmail e outros sites são apenas um pouco menos práticos em termos de transporte de dados que os milhares de pen-drives que circulam nas empresas ultimamente.
• Agir com superioridade frente aos colegas da área de redes, administração de sistemas e desenvolvimento: segurança da informação, por ser um processo, pode envolver todas as áreas de uma empresa, em especial as equipes de suporte e desenvolvimento. Soberba só dificulta o trabalho.
• Usar a mesma senha em sistemas que diferem quanto a exposição ao risco ou criticidade de dados: talvez isto seja algo a se pensar antes de implantar SSO (single-sign-on).