É possível observar muitas mudanças, nas últimas décadas, quando se fala em segurança no desenvolvimento de software. Assistimos à explosão de aplicações web. Seguiu-se um aumento sem precedentes de falhas de segurança. Depois disso, ficou claro para todos que havia necessidade de controle de segurança sobre o processo de desenvolvimento de sistemas. As primeiras análises de segurança de aplicações que fiz, de 1998 até o início da década passada, revelavam falhas básicas, problemas de fácil exploração, e, muitas vezes, o desconhecimento total de segurança pela equipe de desenvolvimento.

O panorama hoje é outro. De uma forma geral, as equipes de desenvolvimento têm já uma visão de segurança um pouco melhor. Os esforços de treinamento em segurança, quase unânimes nas empresas, tem dado resultado. O controle de segurança, seja pelo escritório de segurança, seja no próprio processo de desenvolvimento, tem tornado as aplicações mais resistentes.

Ao mesmo tempo em que vejo essa evolução em cada análise que faço, observo também alguns problemas que não mudam, apesar da preocupação com a segurança da informação no desenvolvimento de software ser cada vez maior; apesar dos sistemas desenvolvidos ainda possuírem um número excessivo de falhas de segurança. Mesmo assim, as especificidades do processo de desenvolvimento, muitas vezes alijam o pessoal de segurança de controles mais efetivos sobre este. Não só falta conhecimento de segurança nas equipes de desenvolvimento: falta conhecimento sobre desenvolvimento nas equipes de segurança.

Este não é um artigo acadêmico ou científico. No meu trabalho ao longo destes anos, tive oportunidade de estar em contato com dezenas equipes de desenvolvimento e inúmeros gestores de segurança. Quero compartilhar com vocês alguns erros e recomendações que parecem constantes nesses casos.

1. Estamos no mesmo time

É muito comum ver a equipe de segurança e a equipe de desenvolvimento jogando em times separados. O desenvolvimento se ressente, porque vê o trabalho da equipe de segurança como mera crítica sobre o seu trabalho. A equipe de segurança se ressente porque quando chega o deadline do projeto, a direção acaba privilegiando a operação, ignorando as recomendações de segurança dadas. Só lembram-se da equipe de segurança quando acontece o ataque. E muitas vezes apenas para levar a culpa.

Seria uma ilusão simplista achar que existe uma saída fácil para isso. Não existe. Sempre haverá algum atrito entre essas áreas, como em diversas outras áreas na organização. Mas é importante haver o esforço consciente para não deixar o relacionamento degradar.

A equipe de segurança deve se esforçar para se colocar na posição de provedora de consultoria para o time de desenvolvimento. Deve se colocar como apoio para quando precisam de informações e dicas sobre segurança. Uma falha fatal é aparecer no processo de desenvolvimento só no final, pra dizer que tem problema. Isso realmente faz o papel da área de segurança se parecer com uma mera crítica.

2. Ensine o desenvolvedor a pensar no erro

Treinamento em segurança da informação é muito importante. Trata-se do melhor custo x benefício para aumento de segurança de sistemas. Um desenvolvedor que conheça os principais ataques e os principais mecanismos de falha, vai naturalmente levar isso em conta no desenvolvimento.

Mas existe um aspecto mais funcional: o desenvolvedor sempre vai pensar no sistema funcionando. Isso também é muito comum com engenheiros e projetistas. Quando se está criando algo, sempre pensamos na coisa funcionando. Mas para garantir a segurança temos que pensar na falha. Tudo funciona bem se estiver tudo certo. Mas e se algo der errado, como aquela função vai reagir? Mesmo que a equipe conheça os principais ataques, se não pensar no erro, vai acabar comprometendo a segurança.

3. Lembre-se que não depende só da equipe de segurança

Vamos colocar a coisa da forma mais simples possível: controlar a segurança no desenvolvimento de software é difícil porque controlar qualquer coisa no processo de desenvolvimento de software é difícil. Pode procurar: controlar custo, controlar prazo, controlar qualidade, pode escolher.  Por que é assim? Porque a grande maioria das empresas no Brasil, mesmo as de grande porte, ainda não tem um processo de desenvolvimento de sistemas efetivo.  Muitas tem metodologias lindamente redigidas. Quase todas não usam a metodologia.

O que o CSO deve fazer é cobrar a implantação de uma metodologia de desenvolvimento de sistemas. Qual metodologia? Qualquer uma. A que puder ser efetivamente implementada. Qualquer método é melhor que nenhum método. Num primeiro momento, não precisa nem ter requisitos de segurança por si, o mero fato de haver um método irá facilitar o controle sobre a qualidade do código produzido.

4. Quanto mais cedo, melhor

Incluir segurança depois do sistema pronto é muito mais caro. Algumas vezes é impossível. Como já falamos antes, fica com cara de mera crítica. Porém é fato que muitos dos testes de segurança só podem ser feitos sobre o sistema final. É recomendável fazer testes de segurança desde muito cedo no processo de desenvolvimento. Tão logo exista uma parte do sistema pronta, já se pode fazer um pen teste. Antes disso, já se pode fazer uma inspeção de código de segurança. Antes disso, ainda na fase de projeto é possível fazer uma análise funcional de segurança sobre a especificação do sistema.

Problemas identificados nas etapas iniciais não só são mais baratos de corrigir como acabam por agregar um fator de conhecimento. Uma vez que o desenvolvedor saiba que tal código não deve ser feito de tal maneira, por ser inseguro, irá evitar tal construção no restante do código.

5. Aponte os problemas específicos e as soluções

Dizer que o sistema apresenta segurança precária é mera crítica. Dizer que o código é confuso, que não há proteção contra o tal ataque, ainda não é específico o suficiente. Dizer que na linha 25 tem um problema e que situações similares devem ser corrigidas em todo o código ainda não é o ideal. Para corrigir todas essas observações indicadas será necessário algum julgamento por parte do desenvolvedor. Essa situação é similar àquela ou não? Esse mecanismo protege mesmo daquele ataque? Isso vai levar o desenvolvedor para uma área onde ele não se sente confortável. Ele não é o especialista em segurança: você é.

Correto é dizer que, nas linhas 32, 144 e 398, do arquivo xpto.java, e nas linhas 244 e 532 do arquivo foobar.java o desenvolvedor usou o componente X, da forma Y, enquanto deveria ter usado o componente Z, da forma W. De posse desta informação, é muito simples para o desenvolvedor encaixar o ajuste em sua rotina de manutenção corretiva.

Conclusão

O panorama é positivo hoje para a segurança no desenvolvimento de sistemas. Nunca tivemos plataformas de desenvolvimento tão seguras quanto as atuais. Nunca tantos desenvolvedores foram treinados em segurança. Nunca tivemos tantas ferramentas para apoiar o desenvolvimento seguro de aplicações. O desenvolvedor e a equipe de segurança, contam hoje com sistemas de análise funcional, tais como o GRC Manager da Módulo. Contam com ferramentas de inspeção de código de segurança como o AppScan, Fortify e, mais recentemente, a iniciativa brasileira Safeval. Contam com dezenas de ferramentas de invasão, como as ferramentas gratuitas do Owasp, o Acunetix e tantas outras.

O que falta mesmo para que a segurança no desenvolvimento deixe de ser um problema para ser uma solução é a união da equipe de desenvolvimento com a equipe de segurança. É o desenvolvimento aprender mais sobre segurança, mas a área de segurança aprender mais sobre desenvolvimento também.