Aplicando a abordagem do Ciclo de Vida de Desenvolvimento Contínuo de Segurança (SDL Contínuo)

A inovação é a força vital de uma organização na era digital e precisa ser habilitada e protegida. A segurança da inovação protege os processos e os dados da inovação contra ciberataques. A inovação na era digital assume a forma de desenvolvimento de aplicações utilizando o método DevOps ou DevSecOps . Essa abordagem permite que as organizações inovem rapidamente sem esperar por cronogramas tradicionais de navios em cascata que podem levar meses ou anos entre os lançamentos.

Os recursos e aplicativos bem-sucedidos atendem a três tipos diferentes de requisitos:

• Funcional (Dev): Seu aplicativo deve atender às necessidades dos negócios e dos usuários, que geralmente estão evoluindo rapidamente.
• Seguro (seg): Seu aplicativo deve ser resiliente a ataques de invasores em rápida evolução e aproveitar as inovações em defesas de segurança.
• Confiável (Ops): Seu aplicativo deve ser confiável e ter um desempenho eficiente.

A fusão destes três requisitos e a criação de uma cultura partilhada é extremamente importante, mas muitas vezes um desafio. Os líderes das equipes de desenvolvimento, TI e segurança devem trabalhar juntos para impulsionar essa mudança.

Assista ao vídeo a seguir para saber mais sobre o método DevSecOps para inovação rápida e segura.

Integre a segurança durante todo o ciclo de vida do desenvolvimento

É fundamental integrar a segurança durante todo o ciclo de vida do desenvolvimento para identificar e corrigir rapidamente o design, o código e outros problemas desde o início, enquanto as pessoas estão trabalhando nessa parte do processo. Essa abordagem evita correções mais caras e difíceis mais tarde que podem causar uma grande quantidade de retrabalho.

Os riscos de segurança (e a necessidade de mitigá-los) podem ocorrer em qualquer ponto do ciclo de vida do desenvolvimento:

• Design – Certifique-se de que o design não permita naturalmente que invasores obtenham facilmente acesso não autorizado à carga de trabalho, seus dados ou outros ativos de negócios na organização.
• Código – Certifique-se de que a escrita (e reutilização) de código não permita que invasores assumam facilmente o controle do aplicativo para executar ações não autorizadas que prejudiquem clientes, funcionários, sistemas, dados ou outros ativos de negócios. Os desenvolvedores também devem trabalhar em um ambiente seguro que não permita que invasores assumam o controle sem o conhecimento deles.
• Compilar e implantar – Certifique-se de que os processos de integração contínua e implantação contínua (CI/CD) não permitam que usuários não autorizados alterem o código e permitam que invasores o comprometam.
• Executar – Certifique-se de que o ambiente que executa o código (nuvem, servidores, dispositivos móveis, outros) siga as práticas recomendadas de segurança entre pessoas, processos e tecnologia para evitar que invasores comprometam e abusem da carga de trabalho. Esse processo inclui a adoção de práticas recomendadas bem estabelecidas, configurações de linha de base de segurança e muito mais.
• Arquitetura e governança Zero Trust – Todos esses estágios devem seguir os princípios do Zero Trust para assumir violação (assumir compromisso), verificar explicitamente a confiança e conceder o menor privilégio necessário para cada conta de usuário, identidade de máquina/serviço e componente do aplicativo.

O que é DevSecOps?

A inovação tecnológica é frequentemente desenvolvida no contexto de uma abordagem de desenvolvimento rápida, enxuta e ágil que combina desenvolvimento e operações em um processo de DevOps e integrar a segurança nesse processo é fundamental para mitigar os riscos para o processo de inovação, o crescimento da organização e os ativos existentes na organização. A integração da segurança no processo cria um processo DevSecOps .

Seguro desde a conceção e deslocando para a esquerda

À medida que as organizações adotam DevOps e outras metodologias de inovação rápida, a segurança deve ser um fio condutor em toda a tapeçaria da organização e seus processos de desenvolvimento. Integrar a segurança no final do processo é caro e difícil de corrigir.

Mude a segurança para a esquerda na linha do tempo para integrá-la na previsão, design, implementação e operação de serviços e produtos. À medida que as equipes de desenvolvimento mudam para DevOps e adotam tecnologias de nuvem, a segurança deve fazer parte dessa transformação.

No modelo cascata, a segurança era tradicionalmente uma porta de qualidade após o término do desenvolvimento.

O DevOps expandiu o modelo de desenvolvimento tradicional (pessoas, processos e tecnologia) para incluir as equipes de operações. Essa mudança reduziu o atrito resultante da separação das equipes de desenvolvimento e operações. Da mesma forma, o DevSecOps expande o DevOps para reduzir o atrito de equipes de segurança separadas ou díspares.

O DevSecOps é a integração da segurança em todos os estágios do ciclo de vida do DevOps, desde o início da ideia até a previsão, o design arquitetônico, o desenvolvimento iterativo de aplicativos e as operações. As equipes devem se alinhar simultaneamente aos objetivos de velocidade de inovação, confiabilidade e resiliência de segurança. Com compreensão mútua e respeito mútuo pelas necessidades uns dos outros, as equipas trabalham primeiro nas questões mais importantes, seja qual for a fonte.

A metodologia Organize do Cloud Adoption Framework fornece mais contexto sobre estruturas DevSecOps em uma organização. Para obter mais informações, consulte Compreender a segurança do aplicativo e as funções DevSecOps.

Porquê DevSecOps?

DevOps traz agilidade, DevSecOps traz agilidade segura.

Quase todas as organizações do planeta procuram o desenvolvimento de software para obter uma vantagem competitiva através da inovação. Proteger o processo de DevOps é fundamental para o sucesso da organização. Os atacantes perceberam essa mudança para aplicativos personalizados e estão cada vez mais atacando aplicativos personalizados durante seus ataques. Estas novas aplicações são muitas vezes fontes ricas de propriedade intelectual valiosa que contêm novas ideias valiosas que ainda não são uma mercadoria no mercado.

Proteger essa inovação requer que as organizações abordem possíveis fraquezas de segurança e ataques no processo de desenvolvimento e na infraestrutura que hospeda os aplicativos. Essa abordagem deve ser aplicada aos recursos locais e na nuvem.

Os atacantes podem atingir seus objetivos explorando fraquezas no processo de desenvolvimento, na infraestrutura subjacente para cargas de trabalho ou em ambos:

• Ataques de desenvolvimento usando fraquezas no processo de design e desenvolvimento de aplicativos. Por exemplo, os invasores podem encontrar código que não valida a entrada (permitindo ataques comuns como injeção de SQL) ou podem achar que o aplicativo usa criptografia fraca (ou nenhuma criptografia) para comunicações. Além disso, os invasores podem implantar backdoors no código que lhes permite retornar mais tarde para acessar ativos em seu ambiente ou no ambiente de seu cliente.
• Ataques de infraestrutura que comprometem elementos de endpoint e infraestrutura nos quais o processo de desenvolvimento está hospedado usando ataques padrão. Os invasores também podem realizar um ataque de vários estágios que usa credenciais roubadas ou malware para acessar a infraestrutura de desenvolvimento de outras partes do ambiente.

Além disso, o risco de ataques à cadeia de suprimentos de software torna fundamental integrar a segurança em seu processo para:

• Protegendo sua organização contra código mal-intencionado e vulnerabilidades em sua cadeia de suprimento de código-fonte
• Proteger os seus clientes de quaisquer problemas de segurança nas suas aplicações e sistemas, que possam resultar em danos à reputação, responsabilidade ou outros impactos negativos nos negócios da sua organização

A jornada do DevSecOps

A maioria das organizações acha que DevOps ou DevSecOps para qualquer carga de trabalho ou aplicativo é, na verdade, um processo de duas fases. As ideias primeiro incubam em um espaço seguro e depois são liberadas para produção como um produto mínimo viável (MVP). Eles são então iterativa e continuamente atualizados.

Este diagrama mostra o ciclo de vida deste tipo de abordagem de fábrica de inovação:

A inovação segura é uma abordagem integrada para ambas as fases:

• Incubação de ideias onde uma ideia inicial é construída, validada e preparada para uso inicial na produção. Esta fase começa com uma nova ideia e termina quando a primeira versão de produção atende aos critérios de produto mínimo viável (MVP) para:
  • Desenvolvimento: a funcionalidade atende aos requisitos mínimos de negócios
  • Segurança: os recursos atendem aos requisitos de conformidade regulamentar, segurança e proteção para uso em produção
  • Operações: A funcionalidade atende aos requisitos mínimos de qualidade, desempenho e capacidade de suporte para ser um sistema de produção
• DevOps: esta fase é o processo de desenvolvimento iterativo contínuo do aplicativo ou carga de trabalho que permite inovação e melhoria contínuas

O imperativo da liderança: misturar as culturas

Atender a esses três requisitos requer a fusão dessas três culturas para garantir que todos os membros da equipe valorizem todos os tipos de requisitos e trabalhem juntos em prol de objetivos comuns.

Integrar essas culturas e objetivos juntos em uma verdadeira abordagem DevSecOps pode ser um desafio, mas vale a pena o investimento. Muitas organizações experimentam um alto nível de atrito insalubre das equipes de desenvolvimento, operações de TI e segurança que trabalham de forma independente, criando problemas com:

• Entrega de valor lenta e baixa agilidade
• Problemas de qualidade e desempenho
• Problemas de segurança

Embora ter alguns problemas seja normal e esperado com o novo desenvolvimento, os conflitos entre as equipes geralmente aumentam drasticamente o número e a gravidade desses problemas. Os conflitos ocorrem, muitas vezes porque uma ou duas equipas têm uma vantagem política, e repetidamente anulam os requisitos de outras equipas. Com o tempo, as questões negligenciadas crescem em volume e gravidade. Se não for resolvida, essa dinâmica pode piorar com o DevOps à medida que a velocidade de tomada de decisões aumenta para atender à rápida evolução das necessidades de negócios e das preferências dos clientes.

Resolver esses problemas requer a criação de uma cultura compartilhada que valorize os requisitos de dev, sec e ops apoiados pela liderança. Essa abordagem permitirá que suas equipes trabalhem melhor juntas e ajudem a resolver os problemas mais urgentes em qualquer sprint, seja melhorando a segurança, a estabilidade operacional ou adicionando recursos críticos de negócios.

Técnicas de liderança

Estas técnicas-chave podem ajudar a liderança a construir uma cultura partilhada:

1. Ninguém ganha todos os argumentos: os líderes devem garantir que nenhuma mentalidade domine todas as decisões que possam causar um desequilíbrio que impacte negativamente o negócio.
2. Espere a melhoria contínua, não a perfeição: os líderes devem definir uma expectativa de melhoria contínua e aprendizagem contínua. A criação de um programa DevSecOps bem-sucedido não acontece da noite para o dia. É uma jornada contínua com progresso incremental.
3. Celebre interesses comuns e valores individuais únicos: garanta que as equipes possam ver que estão trabalhando para resultados comuns e que cada indivíduo forneça algo que os outros não conseguem. Todos os tipos de requisitos têm a ver com a criação e proteção do mesmo valor comercial. O desenvolvimento está tentando criar novo valor, enquanto as operações e a segurança estão tentando proteger e preservar esse valor, contra diferentes cenários de risco. Os líderes em todos os níveis da organização devem comunicar essa semelhança e como é importante atender a todos os tipos de requisitos para o sucesso imediato e a longo prazo.
4. Desenvolver a compreensão compartilhada: Todos na equipe devem ter uma compreensão básica de:
   • Urgência do negócio: a equipe deve ter uma imagem clara da receita em jogo. Essa exibição deve incluir a receita atual (se o serviço estiver offline) e a receita futura potencial afetada por um atraso na entrega de aplicativos e recursos. Este ponto de vista deve basear-se diretamente nos sinais das partes interessadas da liderança.
   • Riscos e ameaças prováveis: Com base nas informações da equipe de inteligência de ameaças, se houver, a equipe deve estabelecer uma noção das ameaças prováveis que o portfólio de aplicativos enfrentará.
   • Requisitos de disponibilidade: a equipe deve ter um senso compartilhado dos requisitos operacionais, como tempo de atividade necessário, vida útil esperada do aplicativo e requisitos de solução de problemas e manutenção, por exemplo, aplicação de patches durante o serviço on-line.
5. Demonstrar e modelar o comportamento desejado: Os líderes devem modelar publicamente o comportamento que desejam de suas equipes. Por exemplo, mostre humildade, concentre-se em aprender e valorize as outras disciplinas. Outro exemplo é que os gerentes de desenvolvimento discutem o valor da segurança e dos aplicativos de alta qualidade ou os gerentes de segurança discutem o valor da inovação rápida e do desempenho dos aplicativos.
6. Monitore o nível de atrito de segurança: A segurança cria naturalmente atrito que retarda os processos. É fundamental que os líderes monitorem o nível e o tipo de atrito que a segurança gera:
   • Atrito saudável: Semelhante a como o exercício torna um músculo mais forte, integrar o nível certo de atrito de segurança no processo de DevOps fortalece a aplicação, forçando o pensamento crítico no momento certo. Se as equipes estão aprendendo e usando esses aprendizados para melhorar a segurança, por exemplo, considerando por que e como um invasor pode tentar comprometer um aplicativo e encontrando e corrigindo bugs de segurança importantes, então eles estão no caminho certo.
   • Atrito insalubre: Esteja atento ao atrito que impede mais valor do que protege. Esse atrito geralmente acontece quando bugs de segurança gerados por ferramentas têm uma alta taxa de falsos positivos ou falsos alarmes, ou quando o esforço de segurança para corrigir algo excede o impacto potencial de um ataque.
7. Integre a segurança no planejamento do orçamento: garanta que o orçamento de segurança seja alocado proporcionalmente a outros investimentos em segurança. Este conceito é análogo a um evento físico como um concerto, onde o orçamento do evento inclui a segurança física como norma. Algumas organizações alocam 10% do custo total para segurança como regra geral para garantir a aplicação consistente das práticas recomendadas de segurança.
8. Estabeleça metas compartilhadas: garanta que as métricas de desempenho e sucesso para cargas de trabalho de aplicativos reflitam as metas de desenvolvimento, segurança e operações.

Nota

Idealmente, essas equipes devem criar coletivamente essas metas compartilhadas para maximizar o buy-in, seja para toda a organização ou para um determinado projeto ou aplicativo.

Identificar o MVP do DevSecOps

Durante a transição de uma ideia para a produção, é fundamental garantir que a capacidade atenda aos requisitos mínimos, ou ao produto mínimo viável (MVP), para cada tipo de requisito:

• Os desenvolvedores (dev) se concentram em representar as necessidades de negócios para a entrega rápida de recursos que atendam às expectativas dos usuários, clientes e líderes de negócios. Identifique os requisitos mínimos para garantir que a capacidade ajude a tornar a organização bem-sucedida.
• Segurança (sec) traz foco para cumprir as obrigações de conformidade e defesa contra os atacantes que estão continuamente buscando ganhos ilícitos dos recursos da organização. Identifique os requisitos mínimos para atender aos requisitos de conformidade regulamentar, manter a postura de segurança e garantir que as operações de segurança possam detetar e responder rapidamente a um ataque ativo.
• As operações (ops) se concentram no desempenho, na qualidade e na eficiência, garantindo que a carga de trabalho possa continuar a entregar valor a longo prazo. Identifique os requisitos mínimos para garantir que a carga de trabalho possa ser executada e suportada sem exigir grandes alterações de arquitetura ou projeto no futuro previsível.

As definições para MVP podem mudar ao longo do tempo e com diferentes tipos de carga de trabalho, à medida que a equipe aprende em conjunto com sua própria experiência e com outras organizações.

Integre a segurança nativamente no processo

Os requisitos de segurança devem centrar-se na integração nativa com os processos e ferramentas existentes. Por exemplo:

• Atividades de projeto, como modelagem de ameaças, devem ser integradas à fase de projeto
• As ferramentas de verificação de segurança devem ser integradas aos sistemas de integração contínua e entrega contínua (CI/CD), como Azure DevOps, GitHub e Jenkins
• Problemas de segurança devem ser relatados usando os mesmos sistemas e processos de rastreamento de bugs, por exemplo, esquema de priorização, como outros bugs.

A forma como a segurança é integrada no processo deve ser continuamente melhorada à medida que as equipas aprendem e os processos amadurecem. As revisões de segurança e as avaliações de risco devem garantir que as mitigações sejam integradas nos processos de desenvolvimento de ponta a ponta, no serviço de produção final e na infraestrutura subjacente.

Para obter mais informações sobre DevSecOps, consulte Controles técnicos DevSecOps.

Dicas para navegar na viagem

A transformação requer a construção em direção a esse estado ideal de forma incremental em uma jornada. Muitas organizações têm que navegar pela complexidade e desafios nessa jornada. Esta seção descreve alguns dos problemas comuns que as organizações enfrentam.

• A educação e as mudanças culturais são passos iniciais críticos: você entra em guerra com o exército que tem. A equipe que você tem muitas vezes precisará desenvolver novas habilidades e adotar novas perspetivas para entender as outras partes do modelo DevSecOps. Esta mudança de educação e cultura requer tempo, foco, patrocínio executivo e acompanhamento regular para ajudar os indivíduos a compreender e ver plenamente o valor da mudança. A mudança drástica de culturas e competências pode, por vezes, explorar a identidade profissional dos indivíduos, criando potencial para uma forte resistência. É fundamental entender e expressar o porquê, o quê e como da mudança para cada indivíduo e sua situação.
• A mudança leva tempo: você só pode se mover tão rápido quanto sua equipe puder se adaptar às implicações de fazer as coisas de novas maneiras. As equipas terão sempre de fazer os seus trabalhos existentes enquanto se transformam. É fundamental priorizar cuidadosamente o que é mais importante e gerenciar as expectativas de quão rápido essa mudança pode acontecer. Concentrar-se em uma estratégia de rastreamento, caminhada, corrida, onde os elementos mais importantes e fundamentais vêm em primeiro lugar, servirá bem à sua organização.
• Recursos limitados: Um desafio que as organizações geralmente enfrentam no início é encontrar talentos e habilidades em segurança e desenvolvimento de aplicativos. À medida que as organizações começam a colaborar de forma mais eficaz, elas podem encontrar talentos ocultos, como desenvolvedores com mentalidade de segurança ou profissionais de segurança com experiência em desenvolvimento.
• Natureza mutável de aplicativos, código e infraestrutura: A definição técnica e a composição de um aplicativo estão mudando fundamentalmente com a introdução de tecnologias como serverless, serviços de nuvem, APIs de nuvem e aplicativos sem código, como Power Apps. Essa mudança está mudando as práticas de desenvolvimento, a segurança de aplicativos e até mesmo capacita não desenvolvedores a criar aplicativos.

Nota

Algumas implementações combinam operações e responsabilidades de segurança em uma função de engenheiro de confiabilidade de site (SRE).

Embora a fusão dessas responsabilidades em uma única função possa ser o estado final ideal para algumas organizações, isso geralmente é uma mudança extrema em relação às práticas, cultura, ferramentas e conjuntos de habilidades empresariais atuais.

Mesmo se você estiver visando um modelo SRE, recomendamos começar incorporando a segurança ao DevOps usando ganhos rápidos práticos e progresso incremental descritos nesta orientação para garantir que você esteja obtendo um bom retorno sobre o investimento (ROI) e atendendo às necessidades imediatas. Isso adicionará gradualmente responsabilidades de segurança ao seu pessoal de operações e desenvolvimento, o que aproxima seu pessoal do estado final de um SRE (se sua organização planeja adotar esse modelo mais tarde).

Próximos passos

Analise os controles técnicos do DevSecOps para obter orientações mais detalhadas sobre o DevSecOps.

Para obter informações sobre como a segurança avançada do GitHub integra a segurança em seus pipelines de integração contínua e entrega contínua (CI/CD), consulte Sobre a segurança avançada do GitHub.

Para obter mais informações e ferramentas sobre como a organização de TI da Microsoft implementou o DevSecOps, consulte Kit de ferramentas Secure DevOps.