Segurança da inovação

A inovação é a força vital de uma organização na era digital e tem de estar ativada 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 desenvolver aplicações com o método DevOps ou DevSecOps para inovar rapidamente sem esperar pela agenda tradicional do navio de cascata que pode demorar meses ou anos entre lançamentos.

O desenvolvimento de novas capacidades e aplicações requer o cumprimento com êxito de três tipos de requisitos diferentes:

• Desenvolvimento empresarial (Dev): a sua aplicação tem de satisfazer as necessidades empresariais e dos utilizadores, que muitas vezes estão a evoluir rapidamente.
• Segurança (Sec): a sua aplicação tem de ser resiliente a ataques de atacantes em rápida evolução e tirar partido das inovações nas defesas de segurança.
• Operações de TI (Ops): a sua aplicação tem de ser fiável e ter um desempenho eficiente.

Unir estes três requisitos e criar uma cultura partilhada é extremamente importante, mas muitas vezes desafiante. Os líderes de desenvolvimento, TI e equipas de segurança têm de trabalhar em conjunto para impulsionar esta mudança. Para obter mais informações, veja o imperativo de liderança: misturar as culturas.

Veja o seguinte vídeo para saber mais sobre o método 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 de desenvolvimento rápida e ágil que combina desenvolvimento e operações em conjunto num processo de DevOps . Aprendemos que 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. Integrar a segurança no processo cria um processo de DevSecOps .

Proteger por estruturação e deslocamento para a esquerda

À medida que as organizações adotam o DevOps e outras metodologias de inovação rápidas, a segurança tem de ser um thread tecido em toda a tapeçaria da organização e dos respetivos processos de desenvolvimento. A integração da segurança no final do processo é dispendiosa e difícil de corrigir.

Altere a segurança restante na linha cronológica para integrá-la na visualização, conceção, implementação e operação de serviços e produtos. À medida que as equipas de desenvolvimento mudam para o DevOps e adotam tecnologias de cloud, a segurança tem de fazer parte dessa transformação.

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

O DevOps expandiu o modelo de desenvolvimento tradicional (pessoas, processo e tecnologia) para incluir equipas de operações. Esta alteração reduziu o atrito que resultou da separação das equipas de desenvolvimento e operações. Da mesma forma, o DevSecOps expande o DevOps para reduzir o atrito de equipas de segurança separadas ou diferentes.

O DevSecOps é a integração da segurança em todas as fases do ciclo de vida do DevOps desde o início da ideia até à visualização, design arquitetónico, desenvolvimento iterativo de aplicações e operações. As equipas têm de se alinhar simultaneamente com objetivos de velocidade de inovação, fiabilidade e resiliência de segurança. Com compreensão mútua e respeito mútuo pelas necessidades uns dos outros, as equipas trabalharão primeiro nas questões mais importantes, seja qual for a origem.

A metodologia Organizar do Cloud Adoption Framework fornece mais contexto sobre as estruturas de DevSecOps numa organização. Para obter mais informações, veja Compreender a segurança da aplicação e as funções DevSecOps.

Porquê o DevSecOps?

O DevOps traz agilidade, o DevSecOps traz agilidade segura.

Quase todas as organizações do planeta tentam desenvolver 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 tomaram conhecimento desta mudança para aplicações personalizadas e estão a atacar cada vez mais aplicações personalizadas durante os ataques. Estas novas aplicações são muitas vezes origens ricas de valiosa propriedade intelectual que contêm novas ideias valiosas que ainda não são uma mercadoria no marketplace.

Proteger esta inovação requer que as organizações resolvam potenciais falhas de segurança e ataques no processo de desenvolvimento e na infraestrutura que aloja as aplicações. Esta abordagem aplica-se tanto à cloud como ao local.

Os atacantes podem explorar as fraquezas em:

• Processo de desenvolvimento: Os atacantes podem encontrar pontos fracos no processo de conceção da aplicação, por exemplo, utilizando encriptação fraca ou sem encriptação para comunicações. Ou os atacantes podem encontrar fraqueza na implementação da estrutura, por exemplo, o código não valida a entrada e permite ataques comuns, como a injeção de SQL. Além disso, os atacantes podem implantar portas traseiras no código que lhes permite voltar mais tarde a explorar no seu ambiente ou no ambiente do cliente.
• Infraestrutura de TI: Os atacantes podem comprometer os elementos de ponto final e infraestrutura em que o processo de desenvolvimento está alojado através de ataques padrão. Os atacantes também podem realizar um ataque em várias fases que utiliza credenciais roubadas ou software maligno para aceder à infraestrutura de desenvolvimento a partir de outras partes do ambiente. Além disso, o risco de ataques à cadeia de fornecimento de software torna fundamental integrar a segurança no seu processo para ambos:
• Proteger a sua organização: A partir de código malicioso e vulnerabilidades na cadeia de fornecimento de código fonte
• Proteger os seus clientes: A partir de quaisquer problemas de segurança nas suas aplicações e sistemas, o que pode resultar em danos de reputação, responsabilidade ou outros impactos negativos no negócio na sua organização

A jornada de DevSecOps

A maioria das organizações considera que o DevOps ou o DevSecOps para qualquer determinada carga de trabalho ou aplicação é, na verdade, um processo de duas fases, em que as ideias são primeiro incubadas num espaço seguro e depois lançadas para produção e iterativa e continuamente atualizadas.

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 é criada, validada e preparada para utilização inicial de produção. Esta fase começa com uma nova ideia e termina quando a primeira versão de produção cumpre os critérios mínimos de produto viável (MVP) para:
  • Desenvolvimento: A funcionalidade cumpre os requisitos mínimos de negócio
  • Segurança: As capacidades cumprem os requisitos de conformidade regulamentar, segurança e segurança para utilização de produção
  • Operações: A funcionalidade cumpre os requisitos mínimos de qualidade, desempenho e suporte para ser um sistema de produção
• DevOps: Esta fase é o processo de desenvolvimento iterativo contínuo da aplicação ou carga de trabalho que permite a inovação e melhoria contínuas

O imperativo de liderança: Misturar as culturas

Cumprir estes três requisitos requer a intercalação destas três culturas para garantir que todos os membros da equipa valorizam todos os tipos de requisitos e trabalham em conjunto no sentido de objetivos comuns.

Integrar estas culturas e objetivos numa verdadeira abordagem de DevSecOps pode ser um desafio, mas vale a pena o investimento. Muitas organizações experimentam um elevado nível de atrito em mau estado de funcionamento devido ao desenvolvimento, operações de TI e equipas de segurança que trabalham de forma independente, criando problemas com:

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

Apesar de ter alguns problemas é normal e esperado com o novo desenvolvimento, os conflitos entre equipas muitas vezes aumentam drasticamente o número e a gravidade destes problemas. Os conflitos ocorrem, muitas vezes porque uma ou duas equipas têm uma vantagem política e substituem repetidamente os requisitos de outras equipas. Com o tempo, as questões negligenciadas aumentam em volume e seriedade. Não resolvido, esta dinâmica pode piorar com o DevOps à medida que a velocidade de tomar decisões aumenta para satisfazer a rápida evolução das necessidades empresariais e das preferências dos clientes.

A resolução destes problemas requer a criação de uma cultura partilhada que valoriza os requisitos de desenvolvimento, seg e ops que são suportados pela liderança. Esta abordagem permitirá que as suas equipas trabalhem melhor em conjunto e ajudarão a resolver os problemas mais urgentes num determinado sprint, quer estejam a melhorar a segurança, a estabilidade operacional ou a adicionar funcionalidades empresariais críticas.

Técnicas de liderança

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

1. Ninguém ganha todos os argumentos: Os líderes devem garantir que nenhuma mentalidade domina todas as decisões que possam causar um desequilíbrio que impacte negativamente o negócio.

2. Espere melhorias contínuas, não 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 de um dia para o outro. É um percurso contínuo com progresso incremental.

3. Celebre interesses comuns e valores individuais exclusivos: Certifique-se de que as equipas conseguem ver que estão a trabalhar para resultados comuns e que cada indivíduo fornece 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á a tentar criar um novo valor, enquanto as operações e a segurança estão a tentar proteger e preservar esse valor, contra diferentes cenários de risco. Os líderes de todos os níveis em toda a organização devem comunicar esta comumidade e a importância de cumprir todos os tipos de requisitos para o sucesso imediato e a longo prazo.

4. Desenvolver compreensão partilhada: Todos os membros da equipa devem ter uma compreensão básica de:

   • Urgência empresarial: A equipa deve ter uma imagem clara das receitas em jogo. Esta vista deve incluir as receitas atuais (se o serviço estiver offline) e potenciais receitas futuras que serão afetadas por um atraso na entrega de aplicações e funcionalidades. Isto deve basear-se diretamente nos sinais dos intervenientes na liderança.
   • Riscos e ameaças prováveis: Com base na entrada da equipa de informações sobre ameaças, se estiver presente, a equipa deve estabelecer uma noção das ameaças prováveis que o portefólio de aplicações irá enfrentar.
   • Requisitos de disponibilidade: A equipa deve ter uma noção partilhada dos requisitos operacionais, como o tempo de atividade necessário, a duração esperada da aplicação e os requisitos de resolução de problemas e manutenção, por exemplo, a aplicação de patches durante o serviço online.

5. Demonstrar e modelar o comportamento pretendido: Os líderes devem modelar publicamente o comportamento que querem das suas equipas. Por exemplo, mostrar humildade, focar-se na aprendizagem e valorizar as outras disciplinas. Outro exemplo é que os gestores de desenvolvimento discutem o valor das aplicações de segurança e alta qualidade ou os gestores de segurança discutem o valor da inovação rápida e do desempenho da aplicação.

6. Monitorize o nível de fricção de segurança: A segurança cria naturalmente atrito que atrasa os processos. É fundamental que os líderes monitorizem o nível e o tipo de atrito gerados pela segurança:

   • Fricção saudável: Semelhante à forma 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 equipas estiverem a aprender e a utilizar essas aprendizagens para melhorar a segurança, por exemplo, tendo em conta o porquê e como um atacante pode tentar comprometer uma aplicação e encontrar e corrigir erros de segurança importantes, então estão no caminho certo.
   • Atrito em mau estado de funcionamento: Tenha em atenção a fricção que impede mais valor do que protege. Isto acontece frequentemente quando os erros de segurança gerados pelas ferramentas têm uma taxa de falsos positivos ou alarmes falsos elevados ou quando o esforço de segurança para corrigir algo excede o impacto potencial de um ataque.

7. Integrar a segurança no planeamento orçamental: Certifique-se de que o orçamento de segurança é alocado proporcionalmente a outros investimentos em segurança. Isto é análogo a um evento físico como um concerto em que o orçamento do evento inclui segurança física como norma. Algumas organizações atribuem 10% do custo total pela segurança como regra geral para garantir uma aplicação consistente das melhores práticas de segurança.

8. Estabelecer objetivos partilhados: Garanta que as métricas de desempenho e sucesso das cargas de trabalho de aplicações refletem os objetivos de desenvolvimento, segurança e operações.

Nota

Idealmente, estas equipas devem criar coletivamente estes objetivos partilhados para maximizar a compra, seja para toda a organização ou para um determinado projeto ou aplicação.

Identificar o MVP de DevSecOps

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

• Os programadores (programadores) focam-se em representar as necessidades empresariais para uma entrega rápida de capacidades que correspondam às expectativas dos utilizadores, clientes e líderes empresariais. Identifique os requisitos mínimos para garantir que a capacidade ajuda a tornar a organização bem-sucedida.
• A segurança (seg) concentra-se no cumprimento das obrigações de conformidade e na defesa contra os atacantes que procuram continuamente ganhos ilícitos dos recursos da organização. Identifique os requisitos mínimos para cumprir os requisitos de conformidade regulamentar, manter a postura de segurança e garantir que as operações de segurança podem detetar e responder rapidamente a um ataque ativo.
• As operações (operações) focam-se no desempenho, qualidade e eficiência, garantindo que a carga de trabalho pode continuar a fornecer valor a longo prazo. Identifique os requisitos mínimos para garantir que a carga de trabalho pode ser executada e suportada sem precisar de grandes alterações de arquitetura ou conceção num futuro próximo.

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

Integrar a segurança de forma nativa no processo

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

• As atividades de conceção, como a modelação de ameaças, devem ser integradas na fase de conceção
• As ferramentas de análise de segurança devem ser integradas nos sistemas de integração contínua e entrega contínua (CI/CD), como o Azure DevOps, o GitHub e o Jenkins
• Os problemas de segurança devem ser comunicados com os mesmos sistemas e processos de controlo de erros, por exemplo, o esquema de atribuição de prioridades, como outros erros.

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 riscos devem garantir que as mitigações estão integradas nos processos de desenvolvimento ponto a ponto, no serviço de produção final e na infraestrutura subjacente.

Para obter mais informações sobre o DevSecOps, veja Controlos técnicos de DevSecOps.

Sugestões sobre como navegar no percurso

A transformação requer a criação para este estado ideal de forma incremental num percurso. Muitas organizações terão de navegar pela complexidade e desafios neste percurso. Esta secção descreve algumas das que as organizações enfrentam.

• As mudanças na educação e na cultura são passos iniciais críticos:vais para a guerra com o exército que tens. A equipa que tem terá muitas vezes de desenvolver novas competências e adotar novas perspetivas para compreender as outras partes do modelo de DevSecOps. Esta mudança de educação e cultura leva tempo, foco, patrocínio executivo e seguimento regular para ajudar os indivíduos a entender completamente e ver o valor da mudança. A mudança drástica de culturas e competências pode, por vezes, aproveitar a identidade profissional dos indivíduos, criando potencial para uma forte resistência. É fundamental compreender e expressar o porquê, o quê e como a mudança para cada indivíduo e a sua situação.
• A alteração demora tempo: Só pode mover-se o mais rápido possível para a sua equipa se adaptar às implicações de fazer coisas de novas formas. As equipas terão sempre de fazer os seus trabalhos existentes enquanto se transformam. É fundamental priorizar cuidadosamente o que é mais importante e gerir as expectativas da rapidez com que esta mudança pode acontecer. Concentrar-se numa estratégia de pesquisa, caminhada, execução, onde os elementos mais importantes e fundamentais estão em primeiro lugar, servirá bem a sua organização.
• Recursos limitados: Um desafio que as organizações normalmente enfrentam desde cedo é encontrar talento e competências no desenvolvimento de aplicações e segurança. À medida que as organizações começam a colaborar de forma mais eficaz, podem encontrar talentos ocultos, como programadores com uma mentalidade de segurança ou profissionais de segurança com formação em desenvolvimento.
• Natureza de mudança de aplicações, código e infraestrutura: A definição técnica e a composição de uma aplicação estão a mudar fundamentalmente com a introdução de tecnologias como sem servidor, serviços cloud, APIs na cloud e aplicações sem código, como o Power Apps. Esta mudança está a alterar as práticas de desenvolvimento, a segurança das aplicações e até permite que os não programadores criem aplicações.

Nota

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

Embora a fusão destas responsabilidades numa única função possa ser o estado final ideal para algumas organizações, esta é, muitas vezes, uma mudança extrema das práticas empresariais atuais, cultura, ferramentas e conjuntos de competências.

Mesmo que esteja a filtrar um modelo SRE, recomendamos que comece por incorporar segurança no DevOps através de vitórias rápidas práticas e progressos incrementais descritos nesta documentação de orientação para garantir que está a obter um bom retorno sobre o investimento (ROI) e a satisfazer as necessidades imediatas. Isto irá adicionar de forma incremental responsabilidades de segurança ao seu pessoal de operações e desenvolvimento, o que torna as suas pessoas mais próximas do estado final de uma SRE (se a sua organização planeia adotar esse modelo mais tarde).

Passos seguintes

Reveja os controlos técnicos de 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 nos pipelines de integração contínua e entrega contínua (CI/CD), veja Acerca da 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, veja Secure DevOps toolkit (Toolkit de DevOps Seguro).