10 mandamentos de segurança de aplicativos

Enquanto a segurança de aplicativo dissemina-se em quase todos os aspectos de segurança de TI, hoje, muitas empresas têm dificuldade em implementar programas de segurança de aplicativo sustentáveis, que ofereçam benefícios claros para o negócio. Uma desconexão geral entre objetivos de segurança e os motivos lucráveis de equipes de desenvolvimento pode causar um conflito insuperável entre times de segurança da informação e desenvolvedores, com líderes de linha de negócio prontos para ficar do lado das equipes de desenvolvimento geradoras de dinheiro, em 9 de 10 casos.

E é por isso que tanto da segurança de aplicativos acaba não passando pelo crivo de tecnologias de segurança e pelos Top 10 itens do OWASP (Open Web Application Security Project). Muitos dos segredos do sucesso envolvem políticas inteligentes, educação e delegação entre desenvolvedores e o encorajamento de melhores processos de negócio sem causar ruptura no fluxo de trabalho diário.

1. Não executarás segurança de aplicativo na velocidade do negócio.

Não há nada pior para segurança de aplicativo do que o excesso de confiança exibido quando um especialista diz aos desenvolvedores ou ao líder da linha de negócio para reformular, completamente, os processos pelo bem da segurança, disse Bill Pennington, diretor de estratégia da WhiteHat Security.

“Você precisa conhecer o ritmo e cadência do negócio e, então, fazer com que as soluções de segurança se encaixem nisso”, disse ele. “Do contrário, você não conseguirá implementar absolutamente nada”.

Ele conta a história de um cliente que, uma vez, foi abordado por um consultor de segurança, que disse aos desenvolvedores e líderes do negócio que eles deveriam testar, completamente, todos os códigos antes da implementação, um processo que poderia acrescentar cinco dias ao processo cada vez um código fosse lançado. O líder da linha de negócio disse ao executivo: “nós lançamos códigos toda quarta-feira” e o consultor disse que o negócio não poderia mais ser assim. “E ele respondeu: ‘Não. Nós lançamos códigos toda quarta-feira’”, contou Pennington. “Você precisa se encaixar na forma como a empresa e seu cliente fazem negócio”.

Uma das melhores maneiras de começar a entrar em sincronia é entender melhor a forma como desenvolvedores trabalham antes de fazer decretos, disse Chris Eng, vice-presidente de pesquisa da Veracode.

“Aprenda como a equipe de desenvolvimento trabalha para que você possa ajudar sem ser excessivamente perturbador”, disse ele. “Por exemplo, se eles utilizam scrum ágil, aprenda como esse método funciona e onde faz mais sentido inserir segurança”.

2. Não arquitetarás segurança.

Pode causar uma reação interessante defender a arquitetura segura de aplicativos, porém, John Jacott, da Coverity, aconselha a desconstruir esta mentalidade.

“A maioria dos aplicativos que vejo, atualmente, é raramente ‘arquitetado’. Eles crescem por meio de métodos ágeis ou em cascata”, disse Jacott, diretor de soluções de segurança da empresa. “O que você deve fazer é mostrar aos desenvolvedores, desde cedo e com frequência, as consequências de se ter segurança fraca e deixar que eles pensem a respeito.”
Jacott diz que a maioria das arquiteturas de segurança é ineficiente porque tende ao gerenciamento meticuloso.

“Elas não dão poder aos constituintes, permitindo que eles mesmos criem aplicativos mais seguros”, completou.

Eng concorda que a preparação e a educação de defensores de segurança em equipes de desenvolvimento irá gerar mais ROI no futuro.

“É a única maneira para que a expertise em segurança cresça em grandes organizações”, disse ele. “Encontre um líder de tecnologia ou arquitetura e treine-o para identificar padrões comuns de ataques e erros de código.”

3. Expandirás tuas metodologias de teste.

O teste de aplicativo é o alicerce sobre o qual práticas sólidas de segurança de aplicativo são criadas. Se suas metodologias de teste forem instáveis, toda a estrutura será abalada.

“Mantenha-se em dia com as mais recentes taxonomias, porque elas tendem a refletir o que é mais importante no espaço de ameaças”, disse Eng. “Por exemplo, se seu teste de penetração foi desenvolvido com base no Top 10 do OWASP de 2007, você deve atualiza-lo”.

Eng sugere três grandes atividades de atualização que as empresas devem envolver em suas práticas de testes. A primeira e mais importante, comece criando um inventário de aplicativos e classificando os mais críticos aos negócios para avaliação de riscos durantes os testes.

Depois, as organizações devem executar análises estáticas em todos os aplicativos de médio e alto risco em desenvolvimento, com prioridade direcionada à remediação de vulnerabilidades de médio e alto impacto antes que esses aplicativos entrem em produção. Por fim, as empresas devem implementar mecanismos de descoberta para encontrar todos os aplicativos web no perímetro e executar o escaneamento dinâmico de pré-autenticação, mais uma vez, remediando vulnerabilidades de médio e alto impacto encontradas no processo.

4. Não surpreenderás equipes de desenvolvimento.

Ninguém gosta de surpresa, especialmente desenvolvedores que têm de, inesperadamente, esperar para colocar algo no ar devido a testes de segurança que eles sequer sabiam que eram exigidos, disse Jacott.

“Cada controle, como este teste de segurança, dever ser bem divulgado, patrocinado pelo tipo mais alto de CXO e ser bem compreendido e aceito”, disse ele. “Se não houver aceitação, a culpa é sua; você não está falando a língua deles. Testes-surpresa são apenas punições.”
Se as surpresas estão pegando desenvolvedores desprevenidos, ao menos faça bom uso delas para promover práticas de desenvolvimento mais seguras e sustentáveis logo no início do processo. Em outras palavras, ajude equipes de desenvolvimento e segurança a aprenderem com os próprios erros conforme seguem em frente.

“Em minha opinião, quando isso acontece, pode, na verdade, se tornar uma ferramenta muito poderosa dentro da organização para dizer ‘gostaríamos de implementar testes de segurança mais cedo ou de encontrar formas diferentes de envolver segurança nos primeiros estágios, o que irá nos prevenir contra essas surpresas’”, disse Diana Kelley, estrategista de segurança de aplicativo da IBM. “Se ficarmos bons nisso e continuarmos fazendo isso ao longo do tempo, teremos menos surpresas em testes de aprovação em pré-produção. E, teremos a possibilidade de lançar aplicativos muito mais robustos”.

5. Testarás os aplicativos em produção.

Testes de segurança de aplicativo não devem parar em QA [Controle de Qualidade], disse Pennington, que disse que existem três motivos importantes para que as organizações testem os aplicativos, regularmente, em produção.

Em primeiro lugar, já havia muitos aplicativos legados lançados em ambientes muito antes de segurança de aplicativo entrar em cena. Em segundo, os aplicativos muitas vezes ficam diferentes em produção do que eram em QA.

“Servimos 13.000 websites hoje e 10% deles são um conjunto de QA/produção”, disse ele. “Ainda temos de encontrar vulnerabilidades comuns aos dois”.

Mas, mais importante, o terceiro fator é que o conhecimento sobre como explorar e encontrar vulnerabilidades muda com o tempo.

“Se eu examinar uma base de código em QA, hoje, eu sei apenas o que sei hoje”, disse ele. “Uma semana depois, alguém surge com alguma loucura e temos uma nova forma de explorar injeções SQL que não conhecíamos antes”.

6. Não permitirás que estruturas substituam o bom senso.

As estruturas são ferramentas extremamente valiosas para os desenvolvedores e até oferecem ferramentas importantes para ajudar a melhorar a segurança do aplicativo. Mas, assim como toda ferramenta, elas também têm falhas, disse Ken Pickering, diretor de desenvolvimento de inteligência de segurança para a Core Security.

“É ótimo que as pessoas usem estruturas, que oferecem diversas precauções de segurança e podem proteger contra ataques de injeção e coisas do tipo”, disse ele. “No entanto, a maioria das pessoas não atualiza as estruturas com a mesma frequência que atualizam aplicativos. Essas enormes estruturas também têm seus defeitos”.

Geralmente, estas estruturas estão propícias a grandes invasões por questões de permissão de usuário.

“Muita gente escreve REST APIs ou pontos de integração no banco de dados, e eu percebi que, metade das vezes, eles estão completamente abertos”, disse Pickering. “Por todo o esforço que as pessoas põem em inputs de UI, forçando tudo para a camada de dados SPRING, elas se prendem em estrutura REST porque é mais fácil conceder acesso e todos os dados tendem a passar por muito das permissões de usuário. É um tipo de invasão em muitas situações”.

7. Colocarás as vulnerabilidades em contexto.

Quando os testes, inevitavelmente, revelam vulnerabilidades, os profissionais de segurança não agem da melhor maneira ao pressionar por remediação com a mesma urgência para cada bug.

“Não conclua que todas as vulnerabilidades de um determinado tipo são equivalentes”, alerta Eng. “Não veja segurança em um vácuo; em vez disso, avalie as vulnerabilidades em um contexto apropriado. Não faça alarde por puro hábito”.

Profissionais de segurança devem agir como conselheiros, não como supervisores autoritários exigindo ações. Isto significa, antes de tudo, oferecer informações objetivas sobre as vulnerabilidades existentes e documentação sobre a severidade e o impacto de cada uma delas, disse ele.

“Deixe que os responsáveis pelo negócio deem a palavra final – e que sejam responsabilizados se decidirem ignorar o alerta de segurança”, concluiu Eng.

8. Não darás acesso desenfreado a dados de consumidores aos desenvolvedores

Fortes princípios de controle de acesso não são apenas códigos que os desenvolvedores devem colocar nos aplicativos, são um lema que devem levar para a vida e para o trabalho dentro do ambiente de desenvolvimento, disse Pickering.

“É um problema complicado porque é um problema de negócio, que também tem impacto técnico”, disse Pickering, que alerta que permitir que os desenvolvedores tenham acesso irrestrito aos dados de consumidores abre um novo universo de riscos corporativos. “Sempre houve esta grande desconexão entre os criadores de conteúdo e o pessoal de infraestrutura, por isso, manter os direitos de acesso atualizados e gerenciados com exatidão sempre foi um problema complexo.”

9. Usarás WAF com um plano.

WAF – ou web application firewall – conseguiram uma má reputação no mundo de segurança de aplicativos como um Bandaid ineficaz para práticas de códigos fracos, mas Pennington disse que ele passou a ver WAF como uma ferramenta inestimável se utilizado de forma estratégica.
“Não considero uma caixa mágica que guarda a solução para todos os meus problemas, eu considero um ponto de reforço”, disse ele.

Assim, para exemplificar, se uma organização lançou um código e está em produção, mas uma vulnerabilidade de injeção SQL é descoberta durante os testes, pedir que os desenvolvedores larguem o que estiverem fazendo para consertar o problema é impraticável.

“Você interrompe o negócio, o fluxo de trabalho e eles acabam perdendo o lançamento daquela próxima função de bilhões de dólares e culpam você”, disse ele. “Se você tiver um firewall de aplicativo web, você pode colocar uma regra em vigor e bloquear aquele ataque de injeção SQL, mitigando o risco e dizendo, ‘Desenvolvedores, por favor, consertem isso na próxima vez que lançarem o código, daqui um ou dois meses”.

10. Não culparás os desenvolvedores

Pode ser muito fácil para a equipe de segurança chegar aos desenvolvedores e dizer “seu bebê é feio”, disse Jacott. Mas, não é assim que a segurança de aplicativo é feita.

“Muitos profissionais de segurança amam culpar os desenvolvedores e dizer que eles são burros, que não sabem o que estão fazendo”, disse Pennington. “Você precisa trabalhar com eles com espirito de colaboração. É assim que se alcança o objetivo, no amplo contexto do negócio, de lançar o código dentro do prazo”.

Quanto mais chances você tiver de ganhar capital político e conseguir amigos ao longo do caminho, maiores suas chances de sucesso, disse Jacott, que passou muito tempo no papel do antagonista antes de aprender o quão mais fácil é jogar pelas regras dos desenvolvedores.

“Hoje, levanto as mangas e me junto a eles: sou uma pessoa integral na equipe, com tecnologia integral nos processos e a solução para os problemas, em vez de um problema na solução deles”, disse ele.