Para construir um aplicativo seguro, você não pode esperar até o fim para “testar a segurança nele”. Para as equipes que seguem métodos Agile como Scrum, isso significa que você tem que achar uma maneira de aumentar a segurança em Sprints. Aqui vai como fazê-lo:

Sprint Zero

É preciso incluir alguns passos básicos de segurança no Sprint Zero:

1. Escolha da plataforma – quando estiver escolhendo seu framework de aplicação e linguagem, tire um tempo para entender as funções de segurança que eles fornecem. Em seguida, dê uma olhada nas bibliotecas de segurança como Apache Shiro (um framework de autenticação, gerenciamento de sessões e de controle de acesso), Google KeyCzar (criptografia), e o OWASP Java Encoder (proteção XSS) para preencher eventuais lacunas.
2. Requisitos de privacidade de dados e conformidade – certifique-se de que você compreende os dados que precisam ser protegidos e auditados para fins de conformidade (incluindo PII), e o que você terá de provar aos auditores de conformidade.
3. Treinamento de desenvolvimento de segurança – verifique o nível de habilidade da equipe. Preencha, conforme necessário, com treinamento em codificação segura. Se você não puder pagar a formação, confira os seminários gratuitos SAFECode sobre codificação segura.
4. Codificando as orientações e as diretrizes de revisão do código – considere onde a segurança se encaixa e dê uma olhada nas diretrizes do CERT de codificação segura em Java.
5. Abordagem de teste – planeje o teste unitário de segurança em seu pipeline de integração contínua. Escolha uma ferramenta de análise estática e conecte-a na Integração Contínua também. Faça planos para testes pen ou outros gates/reviews de segurança mais tarde no desenvolvimento.
6. Atribuição de um lead de segurança – alguém da equipe que tenha experiência e treinamento em desenvolvimento seguro (ou quem vai começar o treinamento extra no desenvolvimento seguro) ou alguém da infosec, que atuará como a pessoa chave em avaliações de risco, sessões de modelagem de ameaças de lead, coordenar o teste pen e a digitalização e triagem das vulnerabilidades encontradas, fazer a triagem de novos desenvolvedores até a velocidade.
7. Incidente de resposta – pense sobre como a equipe vai ajudar os ops a responderem às falhas e aos incidentes de segurança.

Primeiros Sprints

Os primeiros Sprints, nos quais você começa a trabalhar no design e na construção da plataforma, e a ter ideias-chave para interfaces e pontos de integração, é quando o attack surface da aplicação aumenta rapidamente.

Você precisa fazer com que a modelagem de ameaças entenda os riscos de segurança e se certificar de que está lidando com eles corretamente.

Comece com as quatro questões básicas de modelagem de ameaças do Adam Shostack:

1. O que você está construindo?
2. O que pode dar errado?
3. O que você vai fazer sobre isso?
4. Você fez um trabalho aceitável em 1-3?

Fornecendo recursos (de forma segura)

Muitos trabalhos de desenvolvimento são negócios “normais”, oferecendo recursos que são muito parecidos com os outros que você já fez: outra tela, outra chamada de API, outro relatório ou outra tabela. Existem algumas preocupações básicas de segurança que você precisa ter em mente quando estiver fazendo esse trabalho. Certifique-se de que os problemas capturados por seus testes de segurança ou ferramentas de análise estática sejam revisados e corrigidos. Fique atento às revisões de código para o uso adequado dos frameworks e das bibliotecas e para o erro e a manipulação de exceção e codificação defensiva.

Tire um tempo extra quando uma história de segurança vier à tona (um novo recurso de segurança ou uma mudança de requisitos de segurança ou de privacidade), e pense em histórias de abuso sempre que você estiver trabalhando em um recurso que trata de algo importante como dinheiro, dados confidenciais, segredos ou funções de comando e controle.

Trabalho pesado

Você precisa pensar em segurança a qualquer momento em que estiver fazendo o trabalho pesado: refatoração em larga escala, atualização de código do framework ou canalização de segurança ou plataforma de tempo de execução, introdução de uma nova API ou integração com um novo sistema. Só quando você estiver construindo o primeiro build do app, gaste um tempo extra com a modelagem de ameaças e seja mais cuidadoso em testes e em avaliações.

Sprints de segurança

Em algum ponto mais tarde no desenvolvimento, pode ser necessário executar um Sprint de segurança ou hardening Sprint – para ter o app pronto para o lançamento da produção, ou para lidar com os resultados de um teste pen, de verificação de vulnerabilidade, de auditoria de segurança ou para limpar depois uma violação de segurança.

Isso poderia envolver todos ou apenas alguns da equipe. Poderia incluir rever e corrigir vulnerabilidades encontradas em testes pen ou digitalização. Verificar vulnerabilidades em componentes open source e de terceiros, e aplicar patches neles. Trabalhar com ops para revisar e endurecer a configuração de tempo de execução. Atualize e verifique o seu plano de resposta a incidentes, ou melhore a sua revisão de código ou práticas de modelagem de ameaças, ou reveja e melhore os testes de segurança. Ou todos os acima.

Adição de segurança em Sprints – apenas faça

A adição de informações de segurança a Sprints não tem que ser difícil ou custar muito. Com esta abordagem simplificada, você terá um longo caminho para a construção de software seguro. E se você quiser ir mais fundo em como a segurança pode se encaixar em Sprints, você pode experimentar o SDL da Microsoft para o Agile.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/03/putting-security-into-sprints.html