Aplicando a abordagem do ciclo de vida de desenvolvimento de segurança contínua (SDL contínuo)

A inovação é a alma de uma organização na era digital e precisa ser incentivada e protegida. A segurança na inovação protege os processos e os dados de inovação contra ataques cibernéticos. A inovação na era digital assume a forma de desenvolver aplicações usando o método DevOps ou DevSecOps . Essa abordagem permite que as organizações inovem rapidamente sem esperar por programações tradicionais de navios em cascata que podem levar meses ou anos entre os lançamentos.

Núcleo do DevSecOps

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

  • Funcional (Dev): seu aplicativo deve atender às necessidades dos negócios e dos usuários, que geralmente estão evoluindo rapidamente.
  • Seguro (Sec): 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 junção desses três requisitos e a criação de uma cultura compartilhada são extremamente importantes, mas geralmente desafiadoras. Os líderes de desenvolvimento e as equipes de TI e segurança precisam trabalhar juntos para impulsionar essa mudança.

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

Integre a segurança em todo o ciclo de vida de desenvolvimento

É fundamental integrar a segurança em todo o ciclo de vida de desenvolvimento para identificar e corrigir rapidamente o design, o código e outros problemas no 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.

Diagrama do ciclo de vida de desenvolvimento de software com arquitetura Zero Trust e sobreposição de governança.

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 gravação (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 seu conhecimento.
  • Criar 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 de Confiança Zero – Todos esses estágios devem seguir os princípios de Confiança Zero para assumir violação (assumir comprometimento), verificar explicitamente a confiança e conceder o privilégio mínimo necessário para cada conta de usuário, identidade de máquina/serviço e componente de aplicativo.

O que é o DevSecOps?

A inovação tecnológica é frequentemente desenvolvida no contexto de uma abordagem de desenvolvimento rápido, enxuto 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 ao processo de inovação, ao crescimento da organização e aos ativos existentes na organização. A integração da segurança ao processo cria um processo de DevSecOps.

Seguro por design e mudança 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 que entrelaça toda a tapeçaria da organização e de seus processos de desenvolvimento. A integração da segurança mais tarde no processo é cara e difícil de corrigir.

Passe a segurança para a esquerda na linha do tempo a fim de integrá-la à concepção, ao 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 precisará fazer parte dessa transformação.

Segurança durante todo o processo

No modelo de cascata, a segurança era tradicionalmente um portão de qualidade após a conclusão do desenvolvimento.

O DevOps expandiu o modelo de desenvolvimento tradicional (pessoas, processos e tecnologia) para incluir as equipes de operações. Essa alteração reduziu o conflito que resultava da separação das equipes de desenvolvimento e de operações. Da mesma forma, o DevSecOps expande o DevOps para reduzir o atrito entre equipes de segurança separadas ou distintas.

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 projeto arquitetônico, o desenvolvimento iterativo de aplicativos e as operações. As equipes precisam alinhar-se simultaneamente às metas 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 equipes trabalham nas questões mais importantes primeiro, seja qual for a fonte.

A metodologia Organize do Cloud Adoption Framework fornece mais contexto sobre estruturas de DevSecOps em uma organização. Para saber mais, confira Entender a segurança do aplicativo e as funções de DevSecOps.

Por que DevSecOps?

O DevOps traz agilidade; o DevSecOps traz agilidade segura.

Quase todas as organizações do planeta estão examinando desenvolvimento de software para obter uma vantagem competitiva por meio da inovação. Proteger o processo de DevOps é essencial para o sucesso da organização. Os invasores perceberam essa mudança para aplicativos personalizados e estão aumentando os ataques a aplicativos personalizados durante seus ataques. Esses novos aplicativos geralmente são grandes fontes de propriedade intelectual valiosa que contêm novas ideias preciosas que ainda não estão disponíveis no mercado.

Proteger essa inovação exige que as organizações resolvam possíveis falhas de segurança e ataques ao processo de desenvolvimento e à infraestrutura que hospeda os aplicativos. Essa abordagem deve ser aplicada ao recurso local e na nuvem.

Oportunidades de invasor

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

  • Ataques de desenvolvimento utilizando pontos fracos no processo de design e desenvolvimento de aplicações. 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 portas traseiras no código que permite que eles retornem mais tarde para acessar ativos em seu ambiente ou no ambiente de seu cliente.
  • Ataques de infraestrutura que comprometem o ponto de extremidade e os elementos de infraestrutura nos quais o processo de desenvolvimento está hospedado usando ataques padrão. Os invasores também podem conduzir um ataque em várias fases que use credenciais roubadas ou malware para acessar a infraestrutura de desenvolvimento de outras partes do ambiente.

Além disso, o risco de ataques à cadeia de fornecimento de software torna essencial integrar a segurança ao seu processo para:

  • Protegendo sua organização contra códigos mal-intencionados e vulnerabilidades em sua cadeia de suprimentos de código-fonte
  • Proteger seus clientes de quaisquer problemas de segurança em seus aplicativos e sistemas, que podem resultar em danos à reputação, responsabilidade ou outros impactos negativos nos negócios em sua organização

A jornada DevSecOps

A maioria das organizações acha que DevOps ou DevSecOps para qualquer carga de trabalho ou aplicativo específico é, 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 atualizados iterativa e continuamente.

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

Fases do DevSecOps

A inovação segura é uma abordagem integrada para estas duas fases:

  • Incubação da ideia, em que uma ideia inicial é criada, validada e preparada para o 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 mínimos de produto viável (MVP) para:
    • Desenvolvimento: a funcionalidade atende aos requisitos comerciais mínimos
    • Segurança: recursos que atendem aos requisitos de conformidade normativa e de segurança para uso na produção
    • Operações: a funcionalidade atende aos requisitos mínimos de qualidade, desempenho e suporte para ser um sistema de produção
  • DevOps: essa fase é o processo de desenvolvimento iterativo contínuo do aplicativo ou da carga de trabalho que permite a inovação e a melhoria contínuas

Imperativo de liderança: misturar as culturas

Atender a esses três requisitos exige a mistura dessas três culturas para garantir que todos os membros da equipe valorizem todos os tipos de requisitos e trabalhem juntos rumo às metas comuns.

A integração dessas culturas e metas em uma abordagem verdadeira de DevSecOps pode ser desafiadora, mas vale o investimento. Muitas organizações passam por um alto nível de atrito pouco saudável entre as equipes de desenvolvimento, operações de TI e segurança que trabalham de forma independente, criando problemas com:

  • Lentidão na entrega de valor e baixa agilidade
  • Problemas com desempenho e qualidade
  • Questões de segurança

Embora ter alguns problemas seja normal e esperado em um novo desenvolvimento, os conflitos entre as equipes geralmente aumentam drasticamente o número e a gravidade desses problemas. Os conflitos ocorrem geralmente porque uma ou duas equipes têm uma vantagem política e substituem repetidamente os requisitos das outras equipes. Ao longo do tempo, os problemas negligenciados crescem em volume e gravidade. Quando não resolvida, essa dinâmica pode ficar pior com DevOps, pois a velocidade das decisões aumenta para atender à rápida evolução das necessidades de negócios e das preferências do cliente.

Resolver esses problemas requer a criação de uma cultura compartilhada que valorize os requisitos de desenvolvimento, desenvolvimento e operações apoiados pela liderança. Essa abordagem permitirá que suas equipes trabalhem melhor em conjunto e ajudarão a resolver os problemas mais urgentes em qualquer sprint, independentemente de estarem melhorando a segurança, a estabilidade operacional ou adicionando recursos de negócios críticos.

Técnicas de liderança

Estas técnicas-chave podem ajudar a liderança a cultivar uma cultura compartilhada:

  1. Ninguém vence todas as discussões: os líderes precisam garantir que nenhuma mentalidade dominará todas as decisões a ponto de causar um desequilíbrio que prejudique os negócios.
  2. Esperar a melhoria contínua, não a perfeição: os líderes devem definir uma expectativa de aperfeiçoamento e aprendizado contínuos. A criação de um programa de DevSecOps bem-sucedido não acontece da noite para o dia. Ela é uma jornada contínua com progresso incremental.
  3. Comemorar os interesses comuns e os valores individuais exclusivos: faça com que as equipes vejam que estão trabalhando para resultados comuns e que cada indivíduo contribui com algo que os outros não têm. Todos os tipos de requisito envolvem a criação e a proteção do mesmo valor comercial. O Desenvolvimento está tentando criar um valor; as Operações e a Segurança estão tentando proteger e preservar esse valor em cenários de risco diferentes. Os líderes de todos os níveis em toda a organização devem comunicar essa semelhança e o quão importante é atender a todos os tipos de requisitos para o sucesso imediato e de longo prazo.
  4. Desenvolva a compreensão compartilhada: todos na equipe devem ter uma compreensão básica de:
    • Urgência dos negócios: a equipe deve ter uma visão 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. Essa visão deve ser diretamente baseada em sinais dos stakeholders da liderança.
    • Riscos e ameaças prováveis: com base nas informações da equipe de inteligência contra ameaças, se houver, a equipe deve ter uma noção das prováveis ameaças que o portfólio de aplicativos enfrentará.
    • Requisitos de disponibilidade: a equipe deve ter um senso comum dos requisitos operacionais, como o tempo de atividade necessário, o tempo de vida esperado do aplicativo e os requisitos de solução de problemas e manutenção, por exemplo, a aplicação de patches enquanto o serviço está online.
  5. Demonstrar e modelar o comportamento desejado: os líderes devem servir de modelo publicamente para o comportamento que desejam ver em suas equipes. Por exemplo, mostre humildade, concentre-se no aprendizado e valorize outras disciplinas. Outro exemplo é os gerentes de desenvolvimento discutirem o valor da segurança e dos aplicativos de alta qualidade ou os gerentes de segurança discutirem o valor da rápida inovação e do desempenho do aplicativo.
  6. Monitorar o nível de atrito de segurança: é natural que a segurança crie um atrito que atrase os processos. É fundamental que os líderes monitorem o nível e o tipo de atrito que a segurança gera:
    • Atrito saudável: assim como o exercício fortalece um músculo, a integração do nível certo de atrito de segurança no processo de DevOps reforça o aplicativo 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.
    • Conflito não saudável: observe atritos que tirem mais valor do que protegem. Esse atrito geralmente acontece quando bugs de segurança gerados por ferramentas têm uma alta taxa de falsos positivos ou alarmes falsos, ou quando o esforço de segurança para corrigir algo excede o impacto potencial de um ataque.
  7. Integrar a segurança ao planejamento do orçamento: aloque orçamento de segurança 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 à segurança, como regra geral, para garantir a aplicação consistente de práticas recomendadas de segurança.
  8. Estabelecer metas compartilhadas: faça com que as métricas de desempenho e sucesso para cargas de trabalho de aplicativos reflitam metas de desenvolvimento, segurança e operações.

Observação

Idealmente, essas equipes devem criar coletivamente essas metas compartilhadas para maximizar a aceitação, seja por toda a organização, seja por determinado projeto ou aplicativo.

Identificar o MVP de DevSecOps

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

  • Os Desenvolvedores (devs) se concentram em representar as necessidades comerciais para a entrega rápida de recursos que atendam às expectativas de usuários, clientes e líderes de negócios. Identifique os requisitos mínimos para garantir que a capacidade ajudará no sucesso da organização.
  • A Segurança (sec) traz o foco para o cumprimento de obrigações de conformidade e a defesa contra os invasores que estão buscando continuamente um lucro ilícito sobre os recursos da organização. Identifique os requisitos mínimos para atender aos requisitos de conformidade regulatória, manter a postura de segurança e garantir que as operações de segurança poderão detectar 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 poderá continuar a fornecer valor em longo prazo. Identifique os requisitos mínimos para garantir que a carga de trabalho poderá ser executada e terá suporte sem a necessidade de alterações maciças na arquitetura ou no design no futuro próximo.

As definições de MVP podem mudar com o tempo e com tipos de carga de trabalho diferentes à medida que a equipe vai aprendendo com sua própria experiência e a de outras organizações.

Integrar a segurança nativamente ao processo

Os requisitos de segurança precisam se concentrar na integração nativa com o processo e as ferramentas existentes. Por exemplo:

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

A maneira como a segurança é integrada ao processo deve ser continuamente aprimorada à medida que as equipes vão aprendendo e o processo vai amadurecendo. As análises de segurança e as avaliações de risco devem garantir que as atenuações sejam integradas aos processos de desenvolvimento de ponta a ponta, ao serviço de produção final e à infraestrutura subjacente.

Para saber mais sobre o DevSecOps, confira Controles técnicos do DevSecOps.

Dicas para percorrer a jornada

A transformação requer a criação rumo a esse estado ideal incrementalmente em uma jornada. Muitas organizações precisam lidar com a complexidade e os desafios nessa jornada. Esta seção descreve alguns desafios comuns que as organizações costumam enfrentar.

  • 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 sua equipe muitas vezes precisará desenvolver novas habilidades e adotar novas perspectivas para entender as outras partes do modelo DevSecOps. Essa mudança na educação e na cultura leva tempo, exige foco, patrocínio executivo e acompanhamento regular para ajudar os indivíduos a entender totalmente e ver o valor da mudança. A mudança drástica em culturas e habilidades pode, às vezes, esbarrar na identidade profissional de indivíduos, o que cria um potencial de grande resistência. É essencial entender e expressar os motivos, as mudanças e as formas de mudança para cada indivíduo e sua situação.
  • A mudança leva tempo: a rapidez do seu movimento depende de como sua equipe pode se adaptar às implicações de fazer novas atividades de maneiras novas. As equipes sempre precisam fazer seus trabalhos existentes enquanto a transformação acontece. É fundamental priorizar cuidadosamente o que é mais importante e gerenciar as expectativas de quão rápido essa mudança pode ocorrer. Concentrar-se em uma estratégia de engatinhar, andar, correr, em que os elementos mais importantes e fundamentais vêm primeiro, ajudará sua organização.
  • Recursos limitados: um desafio que as organizações geralmente enfrentam no início é encontrar talentos e habilidades no desenvolvimento de aplicativos e de segurança. À medida que as organizações começam a colaborar com mais eficiência, elas podem encontrar talentos ocultos, como desenvolvedores com uma mentalidade de segurança ou profissionais de segurança com uma formação em desenvolvimento.
  • Mudança na natureza 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 “sem servidor”, serviços de nuvem, APIs de nuvem e aplicativos sem código, como os 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.

Observação

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

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

Mesmo que você esteja visando um modelo de SRE, recomendamos começar inserindo a segurança no DevOps usando vitórias rápidas práticas e o progresso incremental descrito nesta diretriz para ter certeza de que está obtendo um bom retorno sobre o investimento (ROI) e atendendo às necessidades imediatas. Isso adicionará de forma incremental as responsabilidades de segurança às suas operações e à equipe de desenvolvimento, o que colocará sua equipe mais próxima do estado final de uma SRE (se sua organização planejar adotar esse modelo mais tarde).

Próximas etapas

Examine os controles técnicos do DevSecOps para obter diretrizes mais detalhadas sobre o DevSecOps.

Para saber mais sobre como a segurança avançada do GitHub integra a segurança em seus pipelines de CI/CD (integração contínua e entrega contínua), confira Sobre a segurança avançada do GitHub.

Para saber mais e obter ferramentas sobre como a organização de TI da Microsoft implementou o DevSecOps, confira Secure DevOps Toolkit.