A maioria dos problemas de segurança começa muito antes do primeiro git init. Eles estão embutidos em decisões de arquitetura, suposições negligenciadas e requisitos ausentes. O planejamento é onde o desenvolvimento seguro deve começar - não porque é divertido, mas porque é barato. Pegar um modelo de autenticação quebrado em uma sessão de quadro branco é mais rápido do que corrigir uma brecha na produção dois sprints depois. Esta secção mostra-lhe como desenhar com a segurança em mente desde o início. Aprenderá a executar uma modelagem de ameaças leve que não seja ruim, escrever histórias de usuário focadas em segurança e classificar dados como um profissional. Nada de tretas. Não é necessário doutoramento.

Imagem de marcador de posição: Descrição da imagem: Fluxo da fase de conceção com ícones para modelação de ameaças, classificação de dados e modelos de histórias de utilizador seguras - sobrepostos num quadro de planeamento de sprint.

Modelação leve de ameaças para equipas de desenvolvimento - Não é necessário doutoramento ou um workshop de três dias

Não é necessário passar dias a construir árvores de ataque ou a realizar um workshop de modelação de ameaças com 14 intervenientes. Só precisa de parar e fazer as perguntas certas na altura certa.

O que é que pode correr mal?

Esta é a questão que interessa. O que acontece se um token vazar? Se alguém adulterar a entrada? Se um utilizador contornar um controlo do lado do cliente? Percorra os fluxos básicos da sua funcionalidade e abra buracos neles. Não está a desenhar para utilizadores ideais - está a defender-se contra abusos criativos. Mesmo 10 minutos de reflexão "e se" podem detetar falhas lógicas, validações em falta ou limites de confiança óbvios.

Ganhos rápidos: STRIDE-per-Feature, Sessões de quadro branco

Não precisa de modelar toda a sua aplicação. Basta ameaçar modelar as coisas novas. Experimente o STRIDE por funcionalidade. Tire cinco minutos e pergunte se a funcionalidade introduz falsificação, adulteração, fugas de informação, problemas de privilégios ou negação de serviço. Ou pegue num quadro branco e faça um esboço do fluxo de dados. Quem fala com o quê? Onde entra a informação do utilizador? Onde deve haver controlos? Ficará surpreendido com a quantidade de informação que conseguirá apanhar só por abrandar o ritmo e desenhar linhas.

Integrar a segurança nas histórias de utilizador e nos requisitos

A segurança não pode viver apenas nos documentos de arquitetura ou no backlog da equipa de segurança. Ela precisa de fazer parte do fluxo de trabalho de desenvolvimento - começando pela forma como se escrevem as histórias.

"Como utilizador, quero que os meus dados sejam..."

As histórias de utilizadores são um excelente local para incluir as expectativas. Não escreva apenas "Como utilizador, quero redefinir a minha palavra-passe". Tente "Como utilizador, quero que a redefinição da minha palavra-passe seja segura e protegida contra força bruta". Essa única frase desencadeia discussões sobre limitação de taxa, expiração de token e registo - antes de o código ser escrito. A segurança deve fazer parte da definição de "feito", e não uma reflexão tardia sobre o controle de qualidade.

Classificação de dados: Saber o que precisa de Fort Knox vs. um simples cadeado

Nem todos os dados são criados da mesma forma. Alguns campos - como os nomes de utilizador - são públicos. Outros, como os SSN ou os tokens de autenticação, necessitam de encriptação, controlo de acesso e registo rigoroso. Durante o planeamento, pergunte: que dados estamos a recolher? Onde é que são armazenados? Qual é o impacto em caso de fuga de informação? Identifique-os em conformidade. Isto ajuda-o a conceber protecções que correspondem ao risco. Não é necessária uma estratégia de governação de dados completa para começar - apenas um pouco de rotulagem e senso comum.

O desenvolvimento seguro não significa parar a inovação. Trata-se de fazer as perguntas certas desde o início, para não ter de corrigir as coisas difíceis mais tarde. 

Vamos passar para a fase de código e falar sobre como escrever uma lógica segura sem transformar cada pull request num incidente de segurança.