Integrando Segurança na Funcionalidade Durante a Fase de Design

É empolgante como diferentes disciplinas podem ser combinadas 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 se moveu em direção à união dessas duas equipes, de modo que a equipe de desenvolvimento fosse responsável por todo o ciclo, desde a escrita do código até a implantação em produção. Claro, 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 para o mercado de novos recursos diminuindo rapidamente. O DevOps também serviu como base para muitas outras práticas, como MLOps, DataOps, GitOps, e sem dúvida muitas mais surgiram.

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

A segurança tem sido tradicionalmente tratada como um pensamento posterior, com equipes enviando recursos para 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 da cibersegurança, 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 deve fazer parte do processo. Ela deve ser incorporada ao ciclo de vida do desenvolvimento o mais cedo possível, porque 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 entregando não seja apenas eficiente, mas também seguro.

Normalmente, o processo de entrega de uma funcionalidade envolve:

1. Desenvolvimento – onde a funcionalidade é construída
2. Distribuição – onde os artefatos são criados e preparados para entrega
3. Implantação – onde a funcionalidade é liberada no ambiente de produção

Vamos discutir os passos que podemos tomar para aprimorar a postura de segurança da funcionalidade que estamos construindo durante a fase de desenvolvimento.

Na fase de desenvolvimento, uma funcionalidade passa por uma revisão de design, codificação e, em seguida, uma revisão de solicitação de pull. Como parte da revisão de design, o proprietário da funcionalidade 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

Apenas para 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 dar 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 algo assim:

Esses são aspectos que podemos considerar ao analisar os endpoints do produto. A melhor parte é que você não precisa ser um especialista em segurança para reconhecer essas vulnerabilidades.

Ferramentas como Microsoft Threat modeling tools e OWASP Threat Dragons podem ajudar a identificá-las.

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

Visão de Análise

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

Revisar o modelo de ameaça com sua equipe pode atuar 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 hash fracas no código.
• Ataques de injeção de SQL. CA2100 é um exemplo que verifica se o código é suscetível a ataques de injeção.
• Senhas hardcoded, mecanismos de autenticação e autorização fracos e configurações incorretas de infraestrutura também podem ser detectados com analisadores estáticos.

Existem também ferramentas existentes neste espaço. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check e Snyk têm algumas ótimas ofertas neste espaço.

A integração de análise estática nos pipelines de construçã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 porque cada implantação de produção deve passar por essas etapas.

Revisões de código do ponto de vista da segurança

Embora as revisões de código tradicionalmente se concentrem na identificação de bugs e garantia das melhores práticas, é importante avaliá-las também do ponto de vista da segurança. Considerando as implicações de segurança de cada solicitação de extração, 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 de isso, incorpore modelagem de ameaças e análise estática automatizada em seu ciclo de desenvolvimento regular.

No próximo artigos, discutiremos quais práticas de segurança podemos incorporar durante a distribuição, que envolvem a varredura de imagens de contêiner, teste de segurança de aplicativos dinâmicos (DAST) e assinatura de artefatos para proteger o serviço contra ataques à cadeia de suprimentos.