Incorporando Segurança na Funcionalidade Durante a Fase de Design

É emocionante como diferentes disciplinas podem ser unidas para tornar os processos mais eficientes. Em 2009, o termo DevOps foi criado para abordar a fricção entre as equipes de Desenvolvimento e Operações. Como resultado, a indústria começou a unir ambas as equipes para que a equipe de desenvolvimento fosse responsável por todo o ciclo, desde a escrita de código até a implantação em produção. Afinal, quem entenderia melhor as complexidades do que as pessoas que as desenvolveram?

Após essa mudança, vimos recursos sendo entregues rapidamente e o tempo de lançamento para novos recursos diminuindo rapidamente. O DevOps também serviu como a base para muitas outras práticas como MLOps, DataOps, GitOps e, sem dúvida, muitas outras surgiram.

Hoje falaremos sobre uma dessas práticas com a qual muitos de vocês podem estar familiarizados chamada DevSecOps (Desenvolvimento de Operações de Segurança). Então, o que é DevSecOps?

A segurança tem sido tradicionalmente tratada como uma reflexão tardia, com equipes entregando recursos em produção primeiro e depois correndo para implantar remediações de segurança durante uma revisão de segurança ou um incidente. Com o aumento dos ciberataques, da cadeia de suprimentos e de outros ataques sofisticados, a indústria rapidamente percebeu que, assim como desenvolvimento e operações, a segurança também deveria ser parte do processo. Ela deve ser incorporada ao ciclo de vida do desenvolvimento o mais cedo possível, pois abordar a segurança mais tarde pode ser caro (tanto do ponto de vista da arquitetura quanto das operações).

Agora, vamos discutir como isso pode ser aplicado em várias etapas do nosso ciclo de vida de desenvolvimento para que o código que estamos enviando não seja apenas eficiente, mas também seguro.

Normalmente, o processo de envio de um recurso envolve:

1. Desenvolvimento – onde o recurso é construído
2. Distribuição – onde os artefatos são criados e preparados para entrega
3. Implantação – onde o recurso é liberado no ambiente de produção

Vamos discutir as etapas que podemos tomar para melhorar a postura de segurança do recurso que estamos construindo durante a fase de desenvolvimento.

Na fase de desenvolvimento, um recurso passa por uma revisão de design, codificação e, em seguida, uma revisão de pull request. Como parte da revisão de design, o proprietário do recurso discute como são os contratos da API, que tipo de bancos de dados estamos usando, estratégias de indexação, caching, experiência do usuário, e assim por diante (não é uma lista exaustiva). Na cultura de segurança em primeiro lugar, também é importante realizar modelagem de ameaças.

Realizar Modelagem de Ameaças

Simplesmente, modelagem de ameaças é “o processo de identificar vulnerabilidades, realizar uma avaliação de riscos e implementar as mitigacões recomendadas para que a postura de segurança dos produtos/organizações não seja comprometida.”

Vamos ver um exemplo para entender isso. Imagine que você está desenvolvendo uma API que:

• Lista produtos em seu catálogo de produtos.
• Busca por um produto ou tipo de produto.

GET /api/products?search=laptop

​

Um modelo de ameaças pode ser parecido com isso:

Isso é algo que podemos considerar ao analisar os pontos finais do produto. A melhor parte é que você não precisa ser um especialista em segurança para reconhecer essas vulnerabilidades.

Ferramentas como as ferramentas de modelagem de ameaças da Microsoft e os Dragões de Ameaças da OWASP podem ajudar a identificá-las.

Exemplo de um Modelo de Ameaças na Ferramenta de Modelagem de Ameaças da Microsoft

Vista de Análise

A vista de análise da ferramenta de modelagem de ameaças mostra diferentes ataques que podem ocorrer na API.

Revisar o modelo de ameaças com sua equipe pode funcionar como uma sessão de brainstorming para identificar e mitigar o maior número possível de lacunas de segurança.

• Usos criptográficos fracos. Por exemplo, o uso de SHA1 ou MD5 é considerado fraco. CA530 é um exemplo de um aviso que o C# cria quando são usadas funções de hash fracas no código.
• Ataques de injeção SQL. CA2100 é um exemplo que verifica se o código é suscetível a ataques de injeção
• Senhas codificadas, mecanismos de autenticação e autorização fracos e configurações incorretas de infraestrutura também podem ser detectados com analisadores estáticos.

Existem ferramentas existentes neste espaço também. SonarQube, CodeQL, Analisador Roslyn, Verificação de Dependências OWASP e Snyk têm algumas ótimas opções neste espaço.

A integração de análise estática nos pipelines de compilação também é importante. Oferece vantagens como:

• Experiência consistente de detecção de vulnerabilidades para seus desenvolvedores.
• Melhora a postura de segurança do seu serviço, pois toda implantação de produção deve passar por essas etapas.

Revisões de Código de um Ponto de Vista de Segurança

Enquanto as revisões de código tradicionalmente se concentram em identificar bugs e garantir as melhores práticas, é importante avaliá-las também de uma perspectiva de segurança . Considerando as implicações de segurança de cada solicitação de recebimento, você pode prevenir proativamente ameaças futuras e proteger a integridade de sua aplicação.

Conclusão

Para concluir, com a crescente sofisticação no cenário de cibersegurança, é importante considerar asegurança nas fases iniciais em vez de deixá-la para o final. Como parte deisso, incorpore modelagem de ameaças e análise estática automatizada em seu ciclo de desenvolvimento regular.

Nos próximos artigos, discutiremos quais práticas de segurança podemos incorporar durante a distribuição, que envolve a verificação de imagens de contêiner, testes dinâmicos de segurança de aplicações (DAST) e assinatura de artefatos para proteger o serviço contra ataques da cadeia de suprimentos.