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.

Alguns pontos importantes na análise das estatísticas (adaptados do anúncio do CERT.br na lista certbr-anuncios):

• O total de notificações recebidas em 2008 foi de 222.528, o que representa um aumento de 39% em relação a 2007.
• As notificações de tentativas de fraude, em 2008, totalizaram 140.067, correspondendo a um aumento de 209% em relação a 2007.
• O aumento das tentativas de fraudes está relacionado, principalmente, ao crescimento nas notificações de quebra de direitos autorais através da distribuição de material pirata em redes P2P. Em 2008 este tipo específico chegou a 108.242, correspondendo a um crescimento de 600% em relação a 2007;
• Em 2008 houve um aumento, em relação a 2007, de 124% no número de notificações de casos de páginas falsas de bancos (phishing tradicional). Este aumento intensificou-se no segundo semestre de 2008, quando as notificações cresceram 104% em relação ao primeiro semestre.
• O crescimento no número de páginas falsas de bancos concentrou-se, principalmente, em páginas de bancos brasileiros, com aumento de 266% no ano em relação a 2007.
• Em 2008 ocorreu um aumento, nas notificações de ataques a servidores Web, de 149% em relação ao ano anterior. Estes ataques exploram vulnerabilidades em aplicações Web e, em alguns casos, visam a hospedagem de cavalos de tróia utilizados em fraudes ou de páginas falsas de instituições financeiras.

Seguem abaixo meus comentários e uma coletânea de links sobre segurança em Mac OS X:

• A lista de features de segurança do Leopard (Mac OS X 10.5) é bem vasta, e como usuário da plataforma posso dizer que a Apple conseguiu mantê-lo seguro e “usável” ao mesmo tempo.
• O sistema a princípio é mais imune a malware do que o seu concorrente de Redmond, porém sabemos que isso não passa de (in)segurança por obscuridade. A Apple chegou a divulgar a necessidade de uso de anti-vírus no final do ano passado, mas voltou atrás após “perceber” que isso estava indo de encontro à sua estratégia de marketing. Sugiro a instalação de anti-vírus e correlatos, no mínimo como medida preventiva, e já pensando nas prováveis ameaças futuras.
• Recomendo acompanhar o SecureMac e The Mac Security Blog. Este último, apesar de ser de uma empresa que desenvolve software de segurança para Macs, traz artigos interessantes, tais como uma compilação completa de notícias de 2008 sobre o tema.
• Recomendo também a leitura dos excelentes guias de segurança escritos pela Apple.

Pretendo escrever mais sobre o tema. Portanto, até o próximo post!

[ 26/01/2009 15:40 - Atualização ]

Não tinha percebido antes, mas o especialista em segurança Pedro Bueno, handler do ISC, postou recentemente o artigo Identifying and Removing the iWork09 Trojan. Leitura recomendada para quem ainda acha que anti-vírus no Mac é bobagem.

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).