Controles DevSecOps

O DevSecOps aplica segurança de inovação integrando processos e ferramentas de segurança no processo de desenvolvimento de DevOps.

Como o DevOps em si é uma disciplina emergente com um alto grau de variações de processo, o DevSecOps bem-sucedido depende da compreensão e da integração cuidadosa da segurança no processo de desenvolvimento. A adição de segurança deve começar com alterações de baixo atrito no código, nos processos de desenvolvimento e na infraestrutura que hospeda a carga de trabalho. Concentre-se primeiro nas mudanças com o maior efeito positivo na segurança, ao mesmo tempo em que sobrecarrega os processos e as habilidades de DevOps.

Esta documentação analisa cada estágio de um processo de DevOps de integração contínua e entrega contínua (CI/CD) e quais controles de segurança recomendamos integrar primeiro.

Planear e desenvolver

Normalmente, o desenvolvimento moderno segue uma metodologia de desenvolvimento ágil. O Scrum é uma implementação de metodologia ágil que tem todo sprint começando com uma atividade de planejamento. A introdução da segurança nesta parte do processo de desenvolvimento deve centrar-se nos seguintes aspetos:

• Modelagem de ameaças para visualizar o aplicativo através da lente de um invasor em potencial
• Plug-ins de segurança do IDE e ganchos de pré-confirmação para verificação de análise estática leve em um ambiente de desenvolvimento integrado (IDE).
• Revisões por pares e padrões de codificação seguros para identificar padrões de codificação de segurança eficazes, processos de revisão por pares e ganchos de pré-confirmação.

Não é obrigatório adicionar todas essas etapas. Mas cada etapa ajuda a revelar problemas de segurança cedo, quando eles são muito mais baratos e fáceis de corrigir.

Modelação de ameaças

A modelagem de ameaças é, sem dúvida, a prática de segurança mais importante. Ele oferece resultados imediatos e ajuda a estabelecer uma mentalidade de segurança nos desenvolvedores para melhorar a segurança em todos os seus projetos futuros.

A modelagem de ameaças é um conceito simples, embora possa ser detalhado e técnico, se necessário. A modelagem de ameaças revela e documenta uma visão de segurança realista do seu aplicativo que inclui:

• Como os invasores podem abusar do design do aplicativo
• Como corrigir vulnerabilidades
• Quão importante é corrigir problemas

A modelagem de ameaças efetivamente coloca você na mentalidade de um atacante. Ele permite que você veja o aplicativo através dos olhos de um invasor. Você aprende como bloquear tentativas antes que os invasores possam fazer qualquer coisa a respeito. Se sua equipe tiver personas de usuário no design, você poderá tratar o invasor como uma persona de usuário hostil.

Existem abordagens publicadas para modelagem de ameaças que vão desde métodos simples de perguntas e respostas até análises detalhadas baseadas em ferramentas. Você pode basear sua abordagem em metodologias como o modelo STRIDE ou a modelagem de ameaças OWASP.

Modelagem de ameaças: Comece simples

Como algumas abordagens à modelagem de ameaças podem ser demoradas e exigem habilidades, recomendamos começar com uma abordagem mais simples usando perguntas básicas. Os métodos mais simples não são tão completos, mas iniciam o processo de pensamento crítico e ajudam-no a identificar rapidamente os principais problemas de segurança.

Os seguintes métodos de perguntas simples irão ajudá-lo a começar:

• Método de perguntas simples da Microsoft: Este método faz perguntas técnicas específicas projetadas para revelar erros comuns de design de segurança.
• Modelagem de ameaças OWASP: Este método se concentra em fazer perguntas simples e não técnicas para iniciar o processo de modelagem de ameaças.

Você pode usar uma ou ambas as abordagens, dependendo do que funciona melhor para sua equipe.

Quando sua equipe se sente mais confortável com o processo, ela pode aplicar técnicas mais avançadas do ciclo de vida de desenvolvimento de segurança da Microsoft. E eles podem integrar ferramentas de modelagem de ameaças, como a ferramenta de modelagem de ameaças da Microsoft, para obter insights mais profundos e ajudar a automatizar o processo.

Outro recurso útil é o guia de modelagem de ameaças para desenvolvedores.

Plug-ins de segurança do IDE e ganchos de pré-confirmação

Os desenvolvedores se concentram na velocidade de entrega, e os controles de segurança podem tornar o processo mais lento. Normalmente, a lentidão ocorre se as verificações de segurança começarem no pipeline. Um desenvolvedor descobre sobre a vulnerabilidade potencial depois de enviar o código para o repositório. Para acelerar o processo e dar feedback imediato, vale a pena adicionar etapas como plug-ins de segurança do IDE e ganchos de pré-confirmação.

Os plug-ins de segurança do ambiente de desenvolvimento integrado (IDE) identificam diferentes problemas de segurança durante o processo de desenvolvimento no ambiente IDE familiar do desenvolvedor. Os plug-ins podem fornecer feedback imediato se houver um risco potencial de segurança no código escrito do desenvolvedor. Os plug-ins também podem revelar riscos na biblioteca ou pacote de terceiros. Dependendo do IDE escolhido, muitos plug-ins de código aberto ou comerciais estão disponíveis e são fornecidos por empresas de segurança.

Outra opção a considerar é usar uma estrutura de pré-confirmação se o sistema de controle de versão permitir. Uma estrutura de pré-confirmação fornece scripts de gancho Git que ajudam a identificar problemas antes que um desenvolvedor envie código para revisão de código. Um exemplo é a pré-confirmação que você pode configurar no GitHub.

Revisão por pares e padrões de codificação seguros

As solicitações pull são padrão no processo de desenvolvimento. Parte do processo de pull request são revisões por pares que geralmente revelam defeitos não descobertos, bugs ou problemas relacionados a erros humanos. É uma boa prática ter um campeão de segurança ou um colega de equipe de segurança experiente que possa orientar o desenvolvedor durante o processo de revisão por pares antes de criar uma solicitação pull.

As diretrizes de prática de codificação segura ajudam os desenvolvedores a aprender princípios essenciais de codificação segura e como eles devem ser aplicados. Existem práticas de codificação seguras disponíveis, como práticas de codificação segura OWASP para incorporar com práticas gerais de codificação.

Confirmar o código

Normalmente, os desenvolvedores criam, gerenciam e compartilham seu código em repositórios como GitHub ou Azure Repos. Essa abordagem fornece uma biblioteca central de código controlada por versão para os desenvolvedores colaborarem facilmente. No entanto, habilitar muitos colaboradores em uma única base de código também corre o risco de serem introduzidas alterações. Esse risco pode levar a vulnerabilidades ou incluir involuntariamente credenciais ou tokens em commits.

Para lidar com esse risco, as equipes de desenvolvimento devem avaliar e implementar um recurso de varredura de repositório. As ferramentas de varredura de repositório executam análise estática de código no código-fonte dentro dos repositórios. As ferramentas procuram vulnerabilidades ou alterações de credenciais e sinalizam quaisquer itens encontrados para correção. Esse recurso atua para proteger contra erros humanos e é uma salvaguarda útil para equipes distribuídas onde muitas pessoas estão colaborando no mesmo repositório.

Gestão de dependências

Até 90% do código em aplicativos atuais contém elementos de, ou é baseado em, pacotes externos e bibliotecas. Com a adoção de dependências no código-fonte, é essencial lidar com potenciais riscos. Muitas bibliotecas de terceiros têm sérios problemas de segurança. Além disso, os desenvolvedores não seguem consistentemente o melhor ciclo de vida e mantêm as dependências atualizadas.

Certifique-se de que sua equipe de desenvolvimento saiba quais componentes incluir em seus aplicativos. Eles vão querer baixar versões seguras e atualizadas de fontes conhecidas. E eles vão querer ter um processo para manter as versões atualizadas. Sua equipe pode usar ferramentas como o projeto OWASP Dependency-Check, WhiteSource e outros.

Concentrar-se apenas nas vulnerabilidades de dependência ou no seu ciclo de vida não é suficiente. Também é importante abordar a segurança dos feeds de pacotes. Existem vetores de ataque conhecidos que têm como alvo sistemas de gerenciamento de pacotes: typosquatting, comprometimento de pacotes existentes, ataques de substituição e outros. Portanto, a administração responsável do gerenciamento de pacotes deve lidar com esses riscos. Para obter mais informações, consulte Três maneiras de reduzir o risco ao usar feeds de pacotes privados.

Testes de segurança de aplicativos estáticos

Depois que sua equipe aborda bibliotecas de terceiros e gerenciamento de pacotes, é essencial mudar o foco e melhorar a segurança do código. Há diferentes maneiras de melhorar a segurança do código. Você pode usar plug-ins de segurança do IDE. Ou você pode conectar análises estáticas incrementais, pré-confirmar e confirmar verificações, conforme discutido anteriormente. Também é possível fazer uma verificação completa do código-fonte para detetar erros perdidos nas etapas anteriores. É necessário, mas pode levar horas ou até dias para digitalizar um grande bloco de código. Assim, esta abordagem pode atrasar o desenvolvimento e introduzir encargos.

Mas uma equipe deve começar em algum lugar ao implementar práticas de varredura de código estático. Uma maneira é introduzir a análise de código estático dentro da integração contínua. Este método verifica a segurança assim que as alterações de código acontecem. Um exemplo é o SonarCloud. Ele envolve várias ferramentas de teste de segurança de aplicativos estáticos (SAST) para diferentes idiomas. A SonarCloud avalia e rastreia a dívida técnica com foco na manutenção. Ele analisa a qualidade e o estilo do código e tem verificadores específicos de segurança. Mas existem muitas outras ferramentas comerciais e de código aberto disponíveis no mercado.

Para garantir que o ciclo de feedback seja eficaz, é crucial ajustar a ferramenta. Você deseja minimizar os falsos positivos e fornecer feedback claro e acionável sobre os problemas a serem corrigidos. Além disso, é bom implementar um fluxo de trabalho, o que impede que o código seja confirmado na ramificação padrão se houver descobertas. Você gostaria de cobrir as descobertas de qualidade e segurança. Assim, a segurança torna-se parte da experiência de teste de unidade.

Oleodutos seguros

O DevOps leva a automação a outro nível, porque tudo no ciclo de vida do desenvolvimento passa por um pipeline. A integração contínua e a entrega contínua (CI/CD) são uma parte fundamental dos ciclos de desenvolvimento modernos. No CI/CD, sua equipe mescla o código do desenvolvedor em uma base de código central em um cronograma regular e executa automaticamente compilações padrão e processos de teste.

Os gasodutos de infraestrutura são uma parte central do desenvolvimento. Mas o uso de pipelines para executar scripts ou implantar código em ambientes de produção pode introduzir desafios de segurança exclusivos. Você quer garantir que seus pipelines de CI/CD não se tornem vias para executar códigos mal-intencionados, permitir que credenciais sejam roubadas ou dar aos invasores qualquer área de superfície para acesso. Você também quer garantir que apenas o código que sua equipe pretende liberar seja implantado.

As equipes de DevOps devem garantir que implementam os controles de segurança adequados para o pipeline. Dependendo da plataforma escolhida, existem diferentes orientações sobre como lidar com os riscos. Para obter mais informações, consulte Protegendo pipelines do Azure.

Compilar e testar

Muitas organizações usam pipelines de compilação e liberação para automatizar e padronizar os processos de criação e implantação de código. Os pipelines de lançamento permitem que as equipes de desenvolvimento façam alterações iterativas em seções de código rapidamente e em escala. As equipes não precisarão gastar grandes quantidades de tempo reimplantando ou atualizando ambientes existentes.

O uso de pipelines de liberação também permite que as equipes promovam o código a partir de ambientes de desenvolvimento, passando por ambientes de teste e, finalmente, até a produção. Como parte da automação, as equipes de desenvolvimento devem incluir ferramentas de segurança que executam scripts e testes automatizados ao implantar código em ambientes de teste. Os testes devem incluir testes de unidade em recursos de aplicativos para verificar vulnerabilidades ou pontos de extremidade públicos. Os testes garantem acesso intencional.

Testes dinâmicos de segurança de aplicativos

Em um modelo clássico de desenvolvimento em cascata, a segurança era normalmente introduzida na última etapa, antes de ir para a produção. Uma das abordagens de segurança mais populares é o teste de penetração ou teste de caneta. O teste de penetração permite que uma equipe olhe para o aplicativo de uma perspetiva de segurança de caixa preta, como em, mais próxima de uma mentalidade de invasor.

Um teste de penetração consiste em vários pontos de ação, um dos quais é o teste dinâmico de segurança de aplicativos (DAST). O DAST é um teste de segurança de aplicativo Web que encontra problemas de segurança no aplicativo em execução, vendo como o aplicativo responde a solicitações especialmente criadas. As ferramentas DAST também são conhecidas como scanners de vulnerabilidade de aplicativos da Web. Um exemplo é uma ferramenta de código aberto, OWASP Zed Attack Proxy (ZAP). Ele encontra vulnerabilidades no aplicativo Web em execução. Existem diferentes maneiras de varredura OWASP ZAP: uma varredura de linha de base passiva ou uma verificação completa, dependendo da configuração.

A desvantagem do teste de caneta é que leva tempo. Um teste de caneta completo pode levar até várias semanas e, com a velocidade do desenvolvimento de DevOps, esse prazo pode ser insustentável. Mas ainda vale a pena adicionar uma versão mais leve do teste de caneta durante o processo de desenvolvimento para descobrir problemas perdidos pelo SAST e outras etapas. Ferramentas DAST como OWASP ZAP podem ajudar.

Os desenvolvedores integram o OWASP ZAP no pipeline como uma tarefa. Durante a execução, o scanner OWASP ZAP gira no contêiner e faz sua varredura e, em seguida, publica os resultados. Essa abordagem pode não ser perfeita, porque não é um teste de penetração completo, mas ainda é valiosa. É mais uma medida de qualidade no ciclo de desenvolvimento para melhorar a postura de segurança.

Validação da configuração na nuvem e análise da infraestrutura

Além de digitalizar e proteger o código para aplicativos, certifique-se de que os ambientes em que você implanta aplicativos também sejam seguros. Ambientes seguros são fundamentais para organizações que querem avançar em ritmo acelerado, inovar e usar novas tecnologias. Ambientes seguros também ajudam as equipes a criar novos ambientes rapidamente para experimentação.

Os recursos do Azure permitem que as organizações criem padrões de segurança a partir de ambientes, como a Política do Azure. As equipas podem utilizar a Política do Azure para criar conjuntos de políticas. Os conjuntos de políticas impedem a criação de determinados tipos de carga de trabalho ou itens de configuração, como endereços IP públicos. Esses guarda-corpos permitem que as equipes experimentem dentro de um ambiente seguro e controlado, equilibrando inovação e governança.

Uma das maneiras pelas quais o DevOps pode colocar desenvolvedores e operações em sintonia é oferecer suporte à conversão da infraestrutura existente em uma abordagem de infraestrutura como código.

Infraestrutura como código (IaC) é o gerenciamento de infraestrutura (redes, máquinas virtuais, balanceadores de carga e topologia de conexão) em um modelo descritivo. O IaC usa o mesmo modelo de controle de versão que a equipe de DevOps usa para o código-fonte. Como o princípio do mesmo código-fonte gera o mesmo binário, um modelo IaC gera o mesmo ambiente toda vez que é aplicado. O IaC é uma prática chave de DevOps que é usada com entrega contínua.

O DevSecOps desloca a segurança para a esquerda e mostra que a segurança não se resume à segurança de aplicativos, mas também à segurança de infraestrutura. Uma das maneiras pelas quais o DevSecOps oferece suporte à segurança da infraestrutura é incluir a verificação de segurança antes que a infraestrutura seja implantada na nuvem. À medida que a infraestrutura se tornava código, você aplicava as mesmas ações de segurança à infraestrutura que a segurança do aplicativo. Existem ferramentas de segurança disponíveis para executar a verificação de segurança da infraestrutura com base na estratégia IaC escolhida.

Com a adoção da nuvem, a conteinerização é uma abordagem popular que as equipes adotam nas decisões de arquitetura de aplicativos. Alguns dos repositórios de contêineres verificam imagens para capturar pacotes com vulnerabilidades conhecidas. Ainda existe o risco de um contêiner ter um software desatualizado. Devido a esse risco, é vital verificar o contêiner em busca de riscos de segurança. Existem muitas ferramentas de segurança comerciais e de código aberto que visam esta área e suportam uma integração estreita no processo de CD. As ferramentas de segurança ajudam as equipes a adotar DevSecOps para infraestrutura como código e, mais especificamente, aprender a usar contêineres.

Ir para a produção e operar

Quando a solução vai para a produção, é vital continuar a supervisionar e gerenciar o estado de segurança. Nesta fase do processo, é hora de se concentrar na infraestrutura de nuvem e na aplicação geral.

Verificação de configuração e infraestrutura

Para obter visibilidade sobre assinaturas de nuvem e configuração de recursos em várias assinaturas, use a solução de segurança de locatário do Azure da equipe AzSK.

O Azure inclui recursos de monitoramento e segurança. Esses recursos detetam e alertam quaisquer eventos ou configurações anômalas que exijam investigação e possível correção. Tecnologias como o Microsoft Defender for Cloud e o Microsoft Sentinel são ferramentas próprias que se integram nativamente nos ambientes do Azure. Essas tecnologias complementam o ambiente e as ferramentas de segurança de código. E as tecnologias fornecem monitoramento de segurança completo para que as organizações possam experimentar e inovar de forma rápida e segura.

Testes de penetração

O teste de penetração é uma prática recomendada para verificar se há vulnerabilidades na infraestrutura ou na configuração do aplicativo, o que pode criar fraquezas que os invasores podem explorar.

Muitos produtos e parceiros oferecem serviços de teste de penetração. A Microsoft fornece orientação para testes de penetração no Azure.

Os testes geralmente abrangem os seguintes tipos de teste:

• Testes em seus endpoints para descobrir vulnerabilidades
• Teste difuso (encontrar erros do programa fornecendo dados de entrada malformados) de seus endpoints
• Análise de portas dos pontos finais

Inteligência acionável

As ferramentas e técnicas nesta orientação oferecem um modelo de segurança holístico para organizações que desejam avançar no ritmo acelerado e experimentar novas tecnologias que visam impulsionar a inovação. Um elemento-chave do DevSecOps são os processos orientados por dados e eventos. Esses processos ajudam as equipes a identificar, avaliar e responder a riscos potenciais. Muitas organizações optam por integrar alertas e dados de uso em sua plataforma de gerenciamento de serviços de TI (ITSM). A equipe pode então trazer o mesmo fluxo de trabalho estruturado para eventos de segurança que eles usam para outros incidentes e solicitações.

Ciclos de comentários

Todas essas técnicas e ferramentas capacitam as equipes a encontrar e sinalizar riscos e vulnerabilidades que exigem investigação e resolução potencial. As equipes de operações que recebem um alerta ou descobrem um problema potencial quando investigam um tíquete de suporte precisam de uma rota de volta para a equipe de desenvolvimento para sinalizar itens para revisão. Um ciclo de feedback suave e colaborativo é vital para resolver problemas rapidamente e minimizar o risco de uma vulnerabilidade tanto quanto possível.

Um padrão comum para comentários é integrá-los a um sistema de gerenciamento de trabalho do desenvolvedor, como o Azure DevOps ou o GitHub. Uma organização pode vincular alertas ou incidentes a itens de trabalho para que os desenvolvedores planejem e aventurem. Esse processo fornece uma maneira eficaz para os desenvolvedores resolverem problemas em seu fluxo de trabalho padrão, incluindo desenvolvimento, teste e lançamento.