Tecnologia de DevOps: como mudar para a esquerda na segurança

A segurança é responsabilidade de todos. A pesquisa do relatório State of DevOps 2016 (PDF em inglês) mostra que as equipes de alto desempenho passam 50% menos tempo corrigindo problemas de segurança do que as de baixo desempenho. Ao integrar melhor os objetivos de segurança das informações (InfoSec) ao trabalho diário, as equipes podem alcançar níveis mais altos de desempenho de entrega de software e criar sistemas mais seguros. Essa ideia também é conhecida como mudança para a esquerda, porque as preocupações, incluindo questões de segurança, são abordadas anteriormente no ciclo de vida do desenvolvimento de software (isto é, deixadas em um diagrama de programação da esquerda para a direita).

No desenvolvimento de software, há pelo menos estas quatro atividades: projetar, desenvolver, testar e lançar. Em um ciclo de desenvolvimento de software tradicional, os testes (incluindo os de segurança) acontecem após a conclusão do desenvolvimento. Isso geralmente significa que uma equipe descobre problemas significativos, incluindo falhas de arquitetura, que são caros de corrigir.

Depois que os erros são descobertos, os desenvolvedores precisam encontrar os fatores de contribuição e como corrigi-los. Em sistemas de produção complexos, geralmente não é uma causa única. Em vez disso, costuma haver uma série de fatores que interagem para causar um erro. Defeitos que envolvem segurança, desempenho e disponibilidade são caros e demorados para serem solucionados. eles geralmente exigem mudanças na arquitetura. O tempo necessário para encontrar o erro, desenvolver uma solução e testar completamente a correção é imprevisível. Isso pode aumentar ainda mais as datas de entrega.

A entrega contínua se baseia no conceito de qualidade do produto ao longo do processo. Como W. Edgar Deming diz nos 14 pontos para a transformação do gerenciamento: "pare de depender da inspeção para alcançar a qualidade. elimine a necessidade de inspeção em massa incorporando qualidade no produto". Nesse modelo, em vez de adotar uma abordagem totalmente em fases, os desenvolvedores trabalham com especialistas em segurança e testes para projetar e fornecer trabalhos em pequenos lotes durante todo o ciclo de vida do produto.

A pesquisa da DevOps Research and Assessment (DORA) (PDF em inglês) mostra que as equipes podem alcançar melhores resultados fazendo da segurança parte do trabalho diário de todos em vez de fazer os testes de segurança no final do processo. Isso significa integrar testes e controles de segurança no trabalho diário de desenvolvimento, controle de qualidade e operações. O ideal é que grande parte desse trabalho possa ser automatizada e colocada no pipeline de implantação. Ao automatizar essas atividades, é possível gerar provas sob demanda para demonstrar que seus controles estão funcionando de forma eficaz. Essas informações são úteis para auditores, avaliadores e qualquer outra pessoa que trabalhe no fluxo de valor.

Como implementar uma qualidade de segurança aprimorada

Mudar o processo de revisão de segurança para "esquerda" ou antes no ciclo de vida de desenvolvimento de software requer várias alterações em relação aos métodos tradicionais de segurança da informação, mas não é um desvio significativo dos métodos tradicionais de desenvolvimento de software em uma inspeção mais detalhada.

Envolver a InfoSec no design de software

A equipe da InfoSec precisa participar da fase de design de todos os projetos. Quando um design de projeto começa, uma revisão de segurança pode ser adicionada como um fator limitante para liberar o design para o estágio de desenvolvimento. Esse processo de revisão pode representar uma alteração fundamental no processo de desenvolvimento. Essa alteração pode exigir treinamento do desenvolvedor. Também pode ser necessário aumentar a equipe da InfoSec e fornecer suporte organizacional para a mudança. Ainda que a inclusão da InfoSec possa representar uma mudança na sua organização, incluir novos interessados no design não é um novo conceito e precisa ser adotado ao considerar os benefícios.

Desenvolver ferramentas aprovadas por segurança

Fornecer aos desenvolvedores bibliotecas e ferramentas pré-aprovadas que incluam entrada da equipe da InfoSec pode ajudar a padronizar o código do desenvolvedor. O uso do código padrão facilita a revisão do código pela equipe da InfoSec. O código padrão permite que os testes automatizados verifiquem se o desenvolvedor está usando bibliotecas pré-aprovadas. Isso também pode ajudar a escalonar a entrada e a influência da InfoSec, porque essa equipe normalmente tem pouco trabalho em comparação com desenvolvedores e testadores.

Desenvolver testes automatizados

A criação de testes de segurança no processo de testes automatizados significa que o código pode ser testado continuamente em escala sem exigir uma revisão manual. Os testes automatizados podem identificar vulnerabilidades de segurança comuns e podem ser aplicados uniformemente como parte de um pipeline de integração contínua ou processo de compilação. Os testes automatizados exigem que você crie e desenvolva testes de segurança automatizados, inicialmente e como um esforço contínuo à medida que novos testes de segurança são identificados. Essa é outra oportunidade para escalonar a entrada da equipe da InfoSec.

Armadilhas comuns

Veja algumas armadilhas comuns que impedem as equipes de mudar a segurança para a esquerda:

  • Falha ao colaborar com a equipe da InfoSec. O maior erro é quando as equipes não colaboram com as equipes da InfoSec. A InfoSec é uma função de importância vital em uma era em que as ameaças são onipresentes e contínuas.
  • Subfaturamento de equipes da InfoSec. As equipes da InfoSec costumam ter poucos funcionários. James Wickett, engenheiro de segurança sênior da Verica, cita uma proporção de 1 pessoa da InfoSec por 10 pessoas de infraestrutura por 100 desenvolvedores em grandes empresas (link em inglês).
  • Integração tardia com a equipe da InfoSec. Em muitos casos, a InfoSec é envolvida apenas no final do ciclo de vida da entrega de software, quando geralmente é difícil e caro fazer alterações necessárias para melhorar a segurança.
  • Não conhecer os riscos de segurança comuns. Muitos desenvolvedores não estão cientes dos riscos de segurança comuns, como os 10 principais do OWASP (em inglês), e como evitá-los.

Maneiras de melhorar a qualidade da segurança

É possível melhorar o desempenho da entrega de software e a qualidade da segurança fazendo o seguinte:

  • Faça análises de segurança. Realize uma análise de segurança para todos os principais recursos e garanta que o processo de análise de segurança não diminua o desenvolvimento.
  • Crie um código pré-aprovado. Solicite que a equipe da InfoSec crie bibliotecas, pacotes, conjuntos de ferramentas e processos pré-aprovados e fáceis de usar para desenvolvedores e operações de TI.
  • Integre a análise de segurança a cada fase. Integre a InfoSec ao trabalho diário de todo o ciclo de vida da entrega de software. Isso inclui fazer com que a equipe da InfoSec forneça informações durante o design do aplicativo, participe de demonstrações de software e forneça feedback durante as demonstrações.
  • Teste a segurança. Teste os requisitos de segurança como parte do processo de teste automatizado, incluindo áreas em que o código pré-aprovado precisa ser usado.
  • Convide a InfoSec para demonstrações. Se você incluir a equipe da InfoSec nas demonstrações do seu aplicativo, elas poderão identificar pontos fracos relacionados à segurança antecipadamente, o que dá à equipe tempo suficiente para corrigir.

Formas de medir a qualidade da segurança

Com base nas formas mencionadas acima, é possível avaliar a segurança das seguintes maneiras.

Fator a testar O que medir Meta
Se os recursos passam por uma análise de segurança A porcentagem de recursos que passam por uma revisão de segurança no início do processo de design. Essa porcentagem aumenta com o tempo.
Se a revisão de segurança diminui o ciclo de desenvolvimento Quanto tempo a revisão adiciona ao processo de desenvolvimento. O tempo que as revisões de segurança demoram para diminuir até atingir o mínimo acordado.
Como a segurança é integrada ao ciclo de vida da entrega O grau de envolvimento da InfoSec em cada etapa do ciclo de vida da entrega de software. Por exemplo, é possível medir o número de revisões de segurança capturadas em cada um dos estágios do ciclo de vida do desenvolvimento de software (design, desenvolvimento, teste e lançamento). Esse valor aumenta até atingir um valor que sugira que a InfoSec esteja totalmente integrada ao ciclo de vida.
Se os testes automatizados cobrem os requisitos de segurança O envolvimento da equipe da InfoSec na criação de testes automatizados. À medida que a InfoSec recebe mais informações sobre o processo de teste, o número ou a porcentagem de requisitos de segurança incluídos no processo de teste automatizado. Essa porcentagem aumenta com o tempo.
O uso de bibliotecas, pacotes, conjuntos de ferramentas e processos pré-aprovados Inicialmente, se a InfoSec está envolvida no desenvolvimento de ferramentas. À medida que o trabalho avança, o número de bibliotecas, pacotes e conjuntos de ferramentas aprovados pela InfoSec disponíveis ou o número desses recursos usados pelas equipes de desenvolvimento e operações. O engajamento aumenta com o tempo até que a organização concorde que a supervisão de ferramentas da InfoSec esteja no nível correto. Da mesma forma, a porcentagem ou o número de ferramentas pré-aprovadas em uso aumenta até que a equipe use todas as ferramentas criadas ou aprovadas pela InfoSec.

A seguir