Segurança de inovação

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 desenvolvimento de aplicativos usando o método DevOps ou DevSecOps para inovar rapidamente sem esperar pelo cronograma de remessa em cascata tradicional, que pode levar meses ou anos entre versões.

O desenvolvimento de novos recursos e aplicativos exige o cumprimento bem-sucedido de três tipos de requisitos diferentes:

• Desenvolvimento de negócios (Dev): seu aplicativo precisa atender às necessidades dos negócios e dos usuários, que muitas vezes evoluem rapidamente.
• Segurança (Sec): seu aplicativo precisa ser resiliente a ataques de invasores que evoluem rapidamente e aproveitar as inovações nas defesas de segurança.
• Operações de TI (Ops): seu aplicativo precisa ser confiável e funcionar com eficiência.

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. Para saber mais, confira Imperativo de liderança: misturar as culturas.

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

O que é o DevSecOps?

A inovação tecnológica é frequentemente desenvolvida no contexto de uma abordagem rápida de desenvolvimento lean e ágil que combina o desenvolvimento e as operações em um processo de DevOps. Aprendemos que integrar a segurança a esse processo é essencial para reduzir os riscos no processo de inovação, no crescimento da organização e nos ativos existentes da 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.

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.

O DevSecOps é a integração da segurança em cada fase do ciclo de vida de DevOps, desde o início da ideia até a previsão, o design arquitetônico, o desenvolvimento iterativo do aplicativo 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 a compreensão e o respeito mútuos pelas necessidades de cada equipe, as equipes trabalharão nos problemas mais importantes primeiro, seja qual for a origem.

A metodologia Organizar 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 se aplica tanto à nuvem quanto ao ambiente local.

Os invasores podem explorar pontos fracos:

• No processo de desenvolvimento: os invasores podem encontrar pontos fracos no processo de design do aplicativo, por exemplo, com uso de pouca ou nenhuma criptografia para comunicações. Ou podem encontrar um ponto fraco na implementação do design, por exemplo, o código não valida a entrada e permite ataques comuns como injeção de SQL. Além disso, os invasores podem implantar portas dos fundos no código que permitem que eles retornem posteriormente para explorar seu ambiente ou o ambiente do cliente.
• Infraestrutura de TI: os invasores podem comprometer os elementos de ponto de extremidade e de infraestrutura nos quais o processo de desenvolvimento está hospedado por meio de 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:
• Proteger sua organização: de código mal-intencionado e vulnerabilidades na cadeia de fornecimento de código-fonte
• Proteger seus clientes: de qualquer problema de segurança em seus aplicativos e sistemas, o que pode resultar em danos à reputação, responsabilidade ou outros prejuízos comerciais em sua organização

A jornada DevSecOps

A maioria das organizações descobre que o DevOps ou o DevSecOps para uma carga de trabalho ou aplicativo específico é, na verdade, um processo de duas fases, em que as ideias primeiro são incubadas em um espaço seguro e, em seguida, liberadas para a produção e atualizadas de forma interativa e contínua.

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

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. Essa fase começa com uma nova ideia e termina quando a primeira versão de produção atende aos critérios de MVP (produto mínimo viável) 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
• Problemas 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.

A solução desses problemas requer a criação de uma cultura compartilhada que atenda aos requisitos de desenvolvimento, segurança e operações com suporte da 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. Desenvolver 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 visão deve incluir a receita atual (se o serviço estiver offline) e uma possível receita futura que será afetada por um atraso na entrega de aplicativos e recursos. Isso deve se basear diretamente em sinais dos stakeholders de 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. É essencial 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 aprimorar a segurança, por exemplo, considerando a forma e o motivo de um invasor tentar comprometer um aplicativo e localizar e corrigir bugs de segurança importantes, eles estão no caminho certo.
   • Conflito não saudável: observe atritos que tirem mais valor do que protegem. Isso 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. Isso é análogo a um evento físico, por exemplo, um show em que o orçamento do evento inclua a segurança física como padrão. 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 terão que navegar complexidades e desafios nessa jornada. Esta seção descreve alguns desafios comuns que as organizações costumam enfrentar.

• As mudanças na educação e na cultura são etapas iniciais críticas:você vai para a 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 capacitando os 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.