O processo DevSecOps

Há várias práticas que precisam ser integradas ao ambiente DevSecOps e a pontos estratégicos ao longo do pipeline. Os processos definidos para essas práticas devem garantir que a segurança esteja incorporada ao desenvolvimento de forma a capacitar os desenvolvedores, sem criar obstáculos para implantações em ritmo acelerado.

Redução dos atritos na entrega

Um conceito que surgiu com o sucesso da Netflix e vem sendo adotado como estratégia para a cultura DevSecOps é a ideia da “estrada pavimentada”. Esse conceito se refere à criação de um caminho com o mínimo de atrito para levar o software da concepção à produção. Portanto, decisões que possam afetar ou influenciar os processos de entrega devem levar em conta se ajudam os desenvolvedores ou criam impedimentos à entrega. Os impedimentos devem ser minimizados ou, de preferência, totalmente evitados.

Um aspecto importante para estabelecer uma cultura de DevSecOps é eliminar o atrito entre as equipes, cultivando a empatia.

Para adotar essa abordagem, é preciso o apoio de várias áreas da organização, mas tudo começa na liderança executiva. Se os líderes de negócios não conduzirem a mudança cultural, ela simplesmente não acontecerá. A liderança deve promover, de cima para baixo, a adoção dos princípios da estrada pavimentada em todos os níveis da empresa. Os valores corporativos devem deixar claro que todos são responsáveis por entregar produtos seguros aos clientes com agilidade. A partir daí, fica mais fácil priorizar práticas que simplifiquem a entrega de software.

Modelagem de ameaças

O Relatório de Insights DevSecOps de 2020 constatou que a modelagem de ameaças tem um impacto significativamente positivo na confiança geral da equipe quanto à segurança do código. Infelizmente, há muito tempo essa atividade é considerada bastante trabalhosa. Por isso, com a adoção de abordagens DevOps/DevSecOps pelas organizações, a modelagem de ameaças costuma ficar de fora das práticas de segurança. No entanto, não se deve ignorar o impacto que ela tem no desenvolvimento.

Em essência, a modelagem de ameaças analisa o software planejado para identificar o que poderia dar errado caso um invasor o atacasse. O objetivo dessa análise é informar à equipe de desenvolvimento quais controles de segurança devem ser considerados na implementação. Tradicionalmente, a modelagem de ameaças abrange todo o contexto da aplicação. Nesse processo, costuma-se recorrer a diagramas de fluxo de dados, estruturas detalhadas de análise de ameaças e metodologias prescritivas para priorizá-las.

Em um modelo DevSecOps, porém, metodologias de modelagem de ameaças que consomem muito tempo e recursos são um obstáculo. Ainda assim, é possível adotar uma abordagem simplificada no pipeline. O DevSecOps costuma aproveitar práticas do desenvolvimento ágil, como o gerenciamento do backlog do produto. Em vez de projetar um sistema inteiro, novos recursos e melhorias são incluídos no backlog por meio de histórias de usuário. Esses elementos independentes e gerenciáveis são fundamentais para viabilizar o desenvolvimento em ritmo acelerado. As organizações podem abordar a modelagem de ameaças da mesma forma.

Em vez de tratar a modelagem de ameaças como um processo que precisa ser aplicado a uma aplicação monolítica, é possível implementar práticas simples no backlog. Ao escrever uma nova história de usuário, inclua também uma breve descrição das ameaças que ela introduz ou afeta. Identifique as funcionalidades ou os dados confidenciais envolvidos na história. Com essas informações disponíveis para os desenvolvedores no backlog, a modelagem de ameaças cumpre seu papel e pode até acelerar o desenvolvimento de cada história.

Controle de versão, metadados e orquestração

Em um mundo automatizado, a única constante é a mudança, que precisa ser consistente e rastreável. Para acompanhar todas as mudanças, o DevSecOps precisa garantir um controle de versões adequado e imutável. Toda ação precisa ter uma versão, assim como o código, para permitir uma recuperação rápida. Convertidas em metadados, as mudanças podem ser acompanhadas e medidas com eficiência pelas equipes de operações.

O software de orquestração não só oferece uma maneira reproduzível de implantar a infraestrutura, como também fornece uma grande quantidade de metadados sobre cada tarefa. Esses metadados podem ser usados pelo próprio software de orquestração e também como fonte confiável para as ferramentas integradas. Com o controle de versões, o software de orquestração se torna uma fonte poderosa de informações para todas as equipes de operações.

Conformidade

Implementar iniciativas de conformidade não precisa ser um exercício baseado em papel. Em vez disso, as organizações podem criar metadados que representem os requisitos de conformidade e integrá-los diretamente aos ativos. Esses metadados também podem ser usados para automatizar políticas de segurança, por meio da identificação de ativos com tags que, por sua vez, permitem implementar a arquitetura de segurança desejada, como o zoneamento.

Essa abordagem viabiliza a conformidade em escala. Por exemplo, ela pode tornar realidade a capacidade de responder a uma violação em até 72 horas, conforme as novas regras do GDPR. Ao incluir os requisitos de conformidade no código do DevSecOps, o processo de desenvolvimento passa a viabilizar o programa de conformidade.

Arquitetura de segurança

A arquitetura de segurança se baseia em um conjunto de princípios específicos de cada empresa. Esses princípios dependem do tipo de dado processado, embora um conjunto de diretrizes de alto nível possa orientar a entrega de software para práticas mais seguras. As organizações que adotam um modelo DevSecOps precisam garantir que existam processos para estabelecer e atualizar continuamente essas arquiteturas. Isso permite desenvolver com mais agilidade e segurança.

Incorporar esses princípios à cultura DevSecOps e disponibilizá-los no backlog permite que os gerentes de produto integrem a segurança ao planejamento e à arquitetura de suporte sem atritos. Se houver algum desvio devido a processos de negócio e/ou à falta de recursos, ele deve ser registrado, e o risco associado, considerado. Esses desvios podem ser tratados como qualquer outro bug e acompanhados até a resolução.

Gerenciamento de incidentes

A resposta a incidentes de segurança não deve ser improvisada nem feita sem planejamento. É essencial criar fluxos de trabalho, planos de ação, playbooks e runbooks com antecedência. Isso garante uma resposta consistente, reproduzível e mensurável. O gerenciamento de incidentes deve usar os metadados para simplificar esse processo e ajustar as métricas para destacar o tempo necessário para reimplantar um ativo comprometido. Os processos definidos nos playbooks devem abranger todos os tipos de incidentes. Assim como o DevSecOps integra diferentes funções, os processos que o implementam também devem fazer isso. Portanto, o gerenciamento de incidentes deve ter um nível de abstração que permita tratar incidentes operacionais e de segurança com a mesma estrutura. Essa é outra medida eficaz para reforçar a cultura de responsabilidade compartilhada, essencial ao DevSecOps.

Depois de formalizados, os playbooks podem ser integrados ao pipeline de CI/CD para automatizar sua execução. No DevSecOps, a busca proativa e preventiva por ameaças, junto à detecção e resposta contínuas a ameaças e vulnerabilidades, resulta em menos incidentes graves e mais ações de mitigação. Testes de penetração, exercícios de red team e programas de recompensa por bugs oferecem uma camada adicional de mitigação contra o risco de violações. Embora a detecção contínua seja muito positiva, as organizações precisam evitar a fadiga de alertas. Para isso, devem estabelecer ciclos de feedback que promovam a melhoria contínua do monitoramento e mais automação na avaliação e resposta aos alertas.

Avaliações proativas de segurança

Por mais avançada que seja a metodologia DevSecOps de uma organização, ainda é necessário identificar vulnerabilidades ativamente. Testes de penetração é um termo usado com frequência para se referir à identificação abrangente de vulnerabilidades em um escopo definido. O red team é diferente porque costuma se concentrar mais em reproduzir as motivações e táticas reais de um invasor. Por exemplo, enquanto um teste de penetração pode buscar identificar todas as páginas de uma aplicação vulneráveis a ataques de injeção de SQL, uma avaliação de red team talvez identifique apenas uma ou duas páginas vulneráveis e use essas vulnerabilidades para explorar ainda mais a aplicação.

Testes de penetração

Os testes de penetração costumam ser a primeira etapa de maturidade no gerenciamento de vulnerabilidades em aplicações. O objetivo é identificar áreas de uma aplicação que possam estar vulneráveis a algum tipo de ataque. Idealmente, essas avaliações oferecem visibilidade abrangente da postura de segurança geral e ajudam a corrigir vulnerabilidades de risco. No entanto, obter uma visão completa das vulnerabilidades da aplicação pode levar tempo. Por isso, no DevSecOps, embora esses testes sejam um requisito básico de higiene de segurança, eles costumam ser realizados após a entrada em produção.

Red team

As avaliações de red team costumam ser realizadas por organizações com alto nível de maturidade. Elas são uma etapa adicional aos testes de penetração. Em uma abordagem de red team, o objetivo não é identificar o maior número possível de vulnerabilidades. Em vez disso, ela se baseia em objetivos e se aproxima mais da abordagem que um invasor adotaria. O escopo normalmente não se limita a uma única aplicação: abrange todos os sistemas do ambiente. Isso permite que a organização entenda como vulnerabilidades em vários sistemas podem ser combinadas para viabilizar um ataque. Também oferece mais contexto sobre o impacto esperado de um ataque bem-sucedido. Por isso, essas avaliações exigem mais experiência e habilidades mais diversificadas do que os testes de penetração tradicionais. À medida que a abordagem DevSecOps de uma empresa amadurece, ela pode considerar incluir exercícios de red team em suas práticas regulares de higiene de segurança.

Programas de recompensa por bugs

Nos últimos anos, os programas de recompensa por bugs também ganharam bastante atenção, em parte graças à disponibilidade de programas colaborativos. Esses programas definem escopos, requisitos e métodos de comunicação para que hackers externos tentem identificar vulnerabilidades no ambiente de uma organização. Em troca do cumprimento dessas regras, os hackers recebem uma “recompensa” pelas vulnerabilidades que comunicarem à organização.

Embora os programas de recompensa por bugs sejam uma ótima forma de incentivar terceiros a comunicar vulnerabilidades de maneira responsável e ofereçam uma camada adicional de identificação, eles não devem substituir os testes de penetração. Em geral, os pesquisadores de segurança que participam desses programas não têm os interesses da organização como prioridade. Eles não buscam identificar vulnerabilidades de forma abrangente; a maioria procura apenas as descobertas mais graves, que rendem as maiores recompensas.

Inteligência de ameaças

À medida que mais componentes do ambiente são definidos e documentados como código, também aumenta a visibilidade da inteligência de ameaças. Muitas organizações têm dificuldade para identificar seus ativos de TI de modo que consigam relacionar as informações de inteligência de ameaças recebidas aos ativos do ambiente. Ao criar processos que alimentem os recursos de inteligência de ameaças com metadados do pipeline DevSecOps, a organização pode garantir que as informações certas sejam coletadas, aplicadas e tratadas de acordo com a prioridade de risco adequada.