Cultivando uma cultura DevSecOps: exemplos reais

Ao longo da jornada contínua de implementação e evolução de um modelo DevSecOps, compartilhar conquistas e aprendizados pode ajudar todos a melhorar. Confira exemplos de organizações que adotaram o DevSecOps e trabalharam para alcançar níveis mais avançados de maturidade.

DevSecOps na Auth0

• Criando uma experiência sem atritos para desenvolvedores de nuvem

• Aproveitando a análise de dados

• Priorizando riscos desde o início do SDL

• Capacitação colaborativa e práticas de desenvolvimento flexíveis

Desde os primeiros dias, a Auth0 aproveita amplamente a infraestrutura de nuvem da AWS para oferecer soluções de gerenciamento de identidade a seus clientes. Com o rápido crescimento da organização, tanto em tamanho quanto em serviços oferecidos, a Auth0 precisou enfrentar o desafio de manter a segurança de sua infraestrutura de nuvem. Duncan Godfrey, diretor sênior de Segurança e Conformidade, participou recentemente do podcast The Secure Developer e falou sobre a estratégia da empresa para proteger esse ambiente.

Uma equipe dedicada à segurança na nuvem da Auth0 é responsável por proteger o ambiente da AWS. Para evitar que a equipe adotasse uma mentalidade tradicional de SecOps, a automação com foco em monitoramento foi considerada essencial. Segundo Godfrey: “O objetivo dessa equipe é garantir que coletemos dados de todos os aspectos e recantos possíveis da AWS e os reunamos para análise”. Com esse foco, a equipe mantém contato com os times de desenvolvimento que trabalham no modelo DevOps. Essa colaboração com as equipes de DevOps permite alcançar uma visibilidade geral maior. 

Para a Auth0 e sua equipe de segurança na nuvem, é fundamental criar uma experiência sem atritos para os desenvolvedores. A integração da segurança começa no início do SDL, com um formulário breve que ajuda a definir o nível de colaboração necessário com a equipe de segurança. Funcionalidades de alto risco, como a exposição de endpoints públicos, contam com um envolvimento mais intenso da equipe de segurança. “Trabalhamos com as equipes para, de preferência, definir os requisitos e implementar os controles adequados desde o início. Assim, conseguimos criar um software seguro e, no fim, executar mais alguns testes”, explica Godfrey.

A cultura geral da Auth0 é claramente pautada pela capacitação colaborativa. Os desenvolvedores têm liberdade para criar software da maneira que melhor atende às suas necessidades, sem deixar de demonstrar maturidade nas práticas de segurança. Isso ajudou a Auth0 a continuar adotando novas tecnologias e, ao mesmo tempo, manter uma postura de segurança sólida.

DevSecOps na Segment

• Colocando-se no lugar dos desenvolvedores

• Adotando infraestrutura como código para viabilizar o DevSecOps

• Garantindo que as novas ferramentas sejam fáceis de usar pelos desenvolvedores

• Especialistas integrados a equipes multidisciplinares

Em um episódio recente do podcast The Secure Developer, Leif Dreizler e Eric Ellett falaram sobre a importância que a Segment, provedora de plataforma de dados de clientes, atribui à colaboração entre as equipes de desenvolvimento, segurança e operações. A Segment não trabalha com sprints em toda a organização; em vez disso, as equipes atuam de forma independente. Ainda assim, por meio de um modelo consultivo, a equipe de segurança se integra desde o início do processo de desenvolvimento para oferecer recursos de modelagem de ameaças e revisão de design.

Na Segment, a empatia faz parte da cultura da equipe de segurança. A empresa adota o conceito de “colocar-se no lugar dos desenvolvedores”. Ellett explicou que a equipe de segurança se esforça para entender como seus processos afetam outras áreas da organização. Por exemplo, quando a empresa quis implementar a autenticação multifator, Dreizler passou um trimestre integrado à equipe de desenvolvimento. Isso dá à equipe de segurança um contexto valioso sobre os desafios enfrentados pelos desenvolvedores e o que eles estão tentando proteger.

Mas o foco na colaboração não para por aí. Ellett explicou que também há planos para iniciativas semelhantes no sentido inverso. A ideia é convidar pessoas de outras áreas da organização para trabalhar junto à equipe de segurança e entender sua realidade. Dreizler afirmou: “Acho que esse deveria ser o objetivo do DevSecOps. Assim como no DevOps, em que profissionais de operações aprendem a programar, hoje toda a infraestrutura da Segment é código.”

A Segment também acredita firmemente em criar um “caminho pavimentado”. Um dos princípios que orientam a equipe de segurança é: “Os desenvolvedores usariam esta ferramenta?”. Em outras palavras, há um foco intenso em garantir que a facilidade de uso favoreça a adoção dos controles de segurança. Segundo Dreizler, o objetivo final é: “Tornar o mais fácil possível para as pessoas fazerem o que é certo.”

Com essa abordagem colaborativa e empática, a Segment conseguiu desenvolver uma forte cultura de colaboração na organização. É um exemplo de como concretizar a promessa do DevSecOps, alinhando todas as funções em torno do objetivo de fazer o que é melhor para a organização.

A 10X Banking adota o DevSecOps

• Transparência sobre vulnerabilidades de segurança em toda a organização

• Reuniões diárias de alinhamento entre equipes para reunir todos

• Aproveitando a automação para gerenciar a implantação de código seguro

• Usando um jogo de cartas de modelagem de ameaças para envolver as partes interessadas

Neil Drennan, da 10x Future Technologies, participou de um episódio recente do podcast The Secure Developer, apresentado por Guy Podjarny. Drennan compartilhou como a organização usa estratégias de comunicação essenciais para aumentar o engajamento nas práticas de segurança enquanto desenvolve a primeira plataforma bancária nativa da nuvem. Da transparência e comunicação eficaz à colaboração nas atividades diárias e às medidas de segurança proativas, a 10x se concentra em tornar a segurança parte das responsabilidades de todos.

Durante a conversa, Guy e Neil começaram a explorar como a 10x promove a colaboração entre as equipes externas de segurança e as equipes internas de plataforma. Neil explicou que, na 10x, todos podem consultar o estado atual das vulnerabilidades monitoradas pelas ferramentas implementadas no ambiente. “Quando usamos ferramentas e recebemos alertas sobre vulnerabilidades encontradas, essas informações ficam abertas e transparentes para todos. Qualquer pessoa da equipe pode consultar o estado atual das vulnerabilidades em toda a organização”, afirma Drennan. Essa transparência é essencial para garantir que todas as equipes entendam seu papel na responsabilidade compartilhada de entregar software seguro.

Mas a colaboração vai além da visibilidade das vulnerabilidades atuais. Com reuniões diárias de alinhamento que reúnem profissionais de diferentes equipes da empresa, a 10x garante que diversas perspectivas sejam consideradas ao discutir vulnerabilidades de segurança. Neil contou: “Analisamos [as vulnerabilidades atuais] em nossas reuniões diárias com todas as equipes. Não se trata apenas de uma questão funcional de entrega. Todos se reúnem todas as manhãs para tratar de aspectos funcionais, não funcionais e de segurança.” Drennan destacou que essa estratégia é especialmente importante para lidar com um cenário de ameaças cada vez mais dinâmico.

Drennan explicou melhor a eficácia dessas interações: “Acho que isso ajuda muito as equipes a serem mais eficazes. Manter um canal de comunicação aberto entre elas é extremamente importante”. Isso reforça o conceito de responsabilidade compartilhada pelo software seguro e garante que ele faça parte da cultura da organização. É uma ótima maneira de a 10x promover mais empatia e entendimento entre as diferentes funções da empresa.

Neil também explicou como a 10x garante que a segurança seja considerada desde o início do pipeline de entrega por meio da modelagem de ameaças. No relatório State of DevOps de 2019, a Puppet identificou que iniciativas colaborativas de modelagem de ameaças têm um impacto muito significativo na postura geral de segurança de uma organização. Para garantir o envolvimento das partes interessadas nessa atividade essencial, a 10x usa jogos de cartas de modelagem de ameaças para identificar ameaças de acordo com o modelo STRIDE. “Reunir as equipes para jogar com seus baralhos e explorar diferentes cenários de vulnerabilidades de segurança é uma forma muito envolvente de estimular o interesse por segurança e fazer com que pensem continuamente nas questões certas”, afirma Drennan.

Ao se concentrar nos pilares de pessoas, processos e tecnologia, a 10x implementou práticas diferenciadas que criaram uma cultura de segurança em torno da entrega de software. Sua abordagem mostra como os três elementos trabalham juntos de forma colaborativa para garantir que a 10x entregue software eficiente, confiável e seguro.

Promovendo uma cultura DevSecOps na Datadog

• Eliminando barreiras e integrando a segurança às etapas do pipeline de entrega

• Integrando profissionais de segurança às equipes de desenvolvimento para promover empatia e responsabilidade compartilhada

• Segurança como colaboradora funcional na automação do pipeline

A Datadog é um exemplo de como a busca por automação e integração da segurança ao pipeline depende de começar pelas questões relacionadas às pessoas. A empresa criou um programa para promover empatia entre áreas isoladas e estimular uma colaboração melhor. Também envolveu a equipe de segurança como colaboradora ativa na automação e nas ferramentas do pipeline. Quando participou do podcast The Secure Developer, Douglas DePerry era diretor de Segurança de Produto da Datadog e compartilhou algumas das abordagens inovadoras da empresa para resolver esses desafios essenciais de DevSecOps.

A tentativa de adotar uma maneira mais rápida e eficiente de desenvolver software muitas vezes não funciona. Quando você faz deploy em produção dezenas de vezes por dia, é impossível revisar tudo. A Datadog integrou engenheiros de segurança às equipes de desenvolvimento, às vezes por algumas semanas, às vezes por meses. Para a empresa, aumentar a conscientização é uma prioridade. Também é importante mostrar que a segurança é responsabilidade de todos: “Deixe-me ajudar a corrigir alguns desses problemas pequenos ou bugs de segurança” e ensinar e aprender ao longo do processo.

Segundo DePerry: “A equipe de segurança precisa escrever mais código. É preciso automatizar mais. É assim que você multiplica a capacidade da equipe e consegue acompanhar a velocidade de implantação do código”. Uma das maneiras como a Datadog enfrentou esse desafio foi desenvolvendo uma ferramenta sob medida para suas necessidades, que ajuda a equipe de segurança a fornecer às equipes de desenvolvimento orientações práticas e tarefas de correção com base no código que elas escreveram.

A Datadog já havia investido em uma ferramenta de análise estática de segurança (SAST). Inicialmente, a ferramenta foi adotada para demonstrar conformidade, mas, infelizmente, não atendia às necessidades da empresa nem se integrava bem ao pipeline de DevOps existente. Então, a equipe inovou e criou sua própria ferramenta para realizar análises SAST e de análise de composição de software (SCA). DePerry contou: “Demos à ferramenta o nome pouco criativo de Middleware. Essencialmente, ela era uma estrutura à qual podíamos adicionar plugins. Criamos um plugin de análise estática e outro para identificar vulnerabilidades em dependências.”

DePerry também nos disse: “você precisa se concentrar naquilo que vai atingir você primeiro; mas como decidir isso de verdade? Acho que, quanto mais você conseguir fazer isso — porque medir certas coisas ainda é difícil e isso pode tornar a tarefa muito complicada ou sujeita a erros —, mais a previsão, quando feita corretamente, pode ajudar.”

Cultura cloud native na Pivotal

• A importância de tornar a segurança parte da mudança cultural nas transformações cloud native

• Crie diretrizes de segurança, não barreiras, para orientar os desenvolvedores pelo caminho seguro

• A aproximação entre desenvolvedores e profissionais de segurança para promover empatia e responsabilidade compartilhada

A adoção de DevSecOps e a transformação para tecnologias cloud native muitas vezes caminham juntas. Para garantir que a organização consiga se adaptar a esses novos paradigmas sem comprometer a segurança, também é preciso passar por uma transformação cultural. A segurança, por sua vez, deve abandonar a ideia de implementar controles como barreiras no pipeline de entrega. Muito disso pode ser alcançado promovendo empatia e responsabilidade compartilhada entre desenvolvedores e profissionais de segurança.

Steve White, CISO de campo da Pivotal (hoje uma subsidiária da VMWare), participou recentemente do podcast Secure Developer. No episódio, compartilhou algumas de suas ideias sobre transformação para a nuvem, o papel da segurança no pipeline de DevSecOps e como aproximar as equipes de segurança e desenvolvimento pode levar a melhores resultados. Steve dedica boa parte do tempo a trabalhar com líderes e executivos de segurança na arquitetura de segurança de engenharia. Ele também conduz workshops práticos com representantes de diferentes áreas de DevSecOps, ajudando-os a entender a realidade da segurança cloud native.

Um elemento fundamental para transformar uma organização com a adoção de DevSecOps é ir além do foco exclusivo em ferramentas. “O primeiro princípio da mudança nessa área é que não se trata apenas de uma mudança tecnológica, embora algumas mudanças na tecnologia sejam necessárias. É uma mudança de cultura e de perspectiva que, em última análise, é a parte mais importante do que precisa acontecer na segurança da informação, assim como já aconteceu no restante da empresa”, compartilhou White. Isso reconhece que o DevOps promoveu muitas mudanças culturais às quais a segurança também precisa se adaptar.

Uma das principais perspectivas que os profissionais de segurança têm dificuldade para adotar é como incorporar práticas de segurança ao pipeline. White afirmou: “Gosto de dizer que estamos deixando as barreiras para adotar diretrizes de segurança, certo? Daqui para a frente, a função da segurança na empresa deve ser oferecer essas proteções — como uma rede de segurança. Há uma diretriz superior e outra inferior que impedem você de ultrapassar limites realmente perigosos, mas, dentro delas, você tem liberdade.” Essa visão destaca um ponto essencial para que a segurança adote o movimento DevOps de forma confiável e, principalmente, compatível.

Outra forma de conquistar a confiança dos desenvolvedores envolvidos na entrega de software é promover empatia. Quando profissionais de segurança e desenvolvedores trabalham juntos no dia a dia, podem construir confiança e valorizar o trabalho uns dos outros. White explicou: “Quando falo em trabalhar em dupla, gostaria que fosse como na programação em pares: duas pessoas diante de uma tela, resolvendo um problema juntas. Se uma delas for engenheira de segurança e a outra, desenvolvedora de funcionalidades, as duas aprendem muito e contribuem bastante para a conversa.”

Em resumo, White aborda alguns dos princípios fundamentais de qualquer cultura DevSecOps. Em alguns casos, a adoção de DevSecOps impulsiona a adoção de cloud native; em outros, é a adoção de DevSecOps que impulsiona a transformação para a nuvem. Fica fácil perceber como as duas caminham juntas. As organizações devem reconhecer essa relação e se preparar para adotar ambas como parte de uma grande mudança cultural, aproveitando o valor que cada uma pode gerar para o negócio.

DevSecOps na Cisco/Duo

• Leve a segurança até o pipeline, “onde as pessoas já estão”

• Antecipe a segurança para definir as diretrizes de projeto ao identificar novas oportunidades tecnológicas

• As métricas precisam ser mais sofisticadas e voltadas à melhoria contínua

A cultura DevSecOps se baseia na eficiência em todo o pipeline: permitir que os desenvolvedores avancem do backlog à implantação com o máximo de eficiência. Para que a segurança faça parte do pipeline de verdade, as práticas seguras precisam ser integradas sem atritos. Para isso, antecipar a definição das diretrizes de segurança ajuda a facilitar o trabalho dos desenvolvedores desde o início da programação das funcionalidades desejadas. Porém, se não for possível medir com eficácia o impacto dessas práticas na postura de segurança, fica muito difícil justificar sua permanência no pipeline.

Michael Hanley, CISO da Cisco e ex-diretor da Duo Security, participou do podcast The Secure Developer e compartilhou algumas das abordagens adotadas pela Cisco/Duo para enfrentar esses desafios. Michael chegou à Cisco com a aquisição da Duo, em 2018, e passou cinco anos liderando as iniciativas de segurança da empresa. Suas ideias sobre integrar a segurança às ferramentas que os desenvolvedores já usam, antecipar a definição de diretrizes de segurança e reunir métricas relevantes são fruto dessa ampla experiência.

Ao desenvolver uma cultura DevSecOps, muitas organizações pensam nas ferramentas necessárias para acelerar o pipeline. No início do movimento DevOps, o foco era automatizar tudo: commits de código acionavam builds automatizados, a promoção do código iniciava testes de regressão automatizados e assim por diante. No entanto, a segurança tradicionalmente tem dificuldade para oferecer processos e ferramentas que se encaixem nesse modelo e, como resultado, acaba criando mais atrito.

Esse atrito frustra os desenvolvedores e pode dificultar a adoção de práticas seguras. Hanley contou que, na Duo, o foco era integrar a segurança às ferramentas já existentes. Ele nos disse: “...vamos até onde é mais fácil para nossos engenheiros trabalharem e interagimos com eles dessa forma. Por exemplo, usamos os mesmos sistemas de tickets que já utilizamos para controle de código-fonte e para o restante do acompanhamento de engenharia. Costumamos trabalhar bastante com nossas equipes de engenharia nesses mesmos espaços para facilitar as coisas para elas.” A ideia de encontrar as pessoas onde elas já trabalham e integrar a segurança às ferramentas que conhecem é uma maneira poderosa de construir uma verdadeira cultura DevSecOps.

Hanley também comentou outro conceito importante para levar a segurança ao pipeline: antecipar sua atuação. Embora essa ideia não seja nova, as equipes de segurança precisam antecipar cada vez mais seu trabalho em uma cultura DevSecOps. “...se eu mapear isso em relação ao ciclo de desenvolvimento de software que temos na Duo, diria que, no ponto mais inicial, a equipe de laboratório participa para identificar estrategicamente novas oportunidades tecnológicas, mas também para definir desde cedo como devem ser os parâmetros de um bom projeto de segurança...”, disse Hanley.

Essa abordagem é importante e muito inovadora. Ao definir as diretrizes de segurança antes mesmo de uma história de usuário entrar no backlog, as organizações garantem que os desenvolvedores tenham requisitos de segurança documentados desde a fase mais inicial do pipeline. Assim, o trabalho de projetar a segurança não afeta a capacidade de entregar código rapidamente. A segurança passa a viabilizar o trabalho, pois os desenvolvedores conseguem passar mais rápido da definição dessas diretrizes para a programação. Além disso, não precisam se preocupar com a possibilidade de deixar passar aspectos de segurança que se tornariam falhas a corrigir em sprints futuras.

Como uma organização pode saber se essas abordagens estão produzindo o efeito desejado? É aí que as métricas são fundamentais. “Em geral, tenho um grande problema com métricas de segurança e com a simples contagem de bugs... elas não são sofisticadas o suficiente para descrever muitos programas, especialmente o nosso”, disse Hanley. Muitas organizações enfrentam essa dificuldade. Uma simples contagem de bugs em aberto não oferece contexto. Quantas versões foram lançadas e geraram essas vulnerabilidades? Se o número de vulnerabilidades é baixo, isso significa que a segurança melhorou ou que a aplicação não é testada há muito tempo? Os programas de métricas precisam considerar mais contexto.

Hanley contou que a Cisco/Duo usa um modelo de maturidade para medir o sucesso do programa. “O modelo de maturidade que usamos na Duo combina elementos do BSIMM e do SAMM... tentamos identificar as principais métricas que ele gera, como o percentual de atividades com pelo menos cobertura parcial e o percentual com cobertura completa”, explicou Hanley.

Ele também mencionou outro conceito fundamental sobre métricas que todas as organizações devem considerar. Hanley explicou que a abordagem da equipe ajudou a manter o foco em um modelo de melhoria contínua. Muitas iniciativas de segurança fracassam porque buscam alcançar metas astronômicas e pouco realistas. Em vez disso, ao focarmos na melhoria, e não apenas em atingir um objetivo, abrimos espaço para erros, adaptação e inovação. Assim, fica mais fácil demonstrar o valor das práticas de segurança para o negócio.

As ideias que Hanley compartilhou com base em sua experiência na Duo refletem os desafios que qualquer organização pode enfrentar ao desenvolver uma cultura DevSecOps.

Segurança na nuvem com a 2nd Sight Lab

• Capacite os desenvolvedores ensinando as melhores práticas de segurança na nuvem

• Promova empatia entre desenvolvedores e profissionais de segurança

• A governança como parte da segurança na nuvem

Como a transformação para a nuvem ocupa o centro das estratégias de TI da maioria das organizações, os desafios de proteger esses ambientes podem se intensificar. Capacitar os desenvolvedores para aproveitar as tecnologias cloud native sem comprometer a segurança é um desafio. Também é fundamental garantir que as diferentes áreas da organização trabalhem juntas e compreendam o panorama geral para proteger ambientes complexos na nuvem. Por fim, monitorar o programa e aprender com os erros é essencial sempre que transformamos o negócio dessa maneira.

Guy Podjarny conversou com Teri Radichel, CEO da 2nd Sight Lab e autora de Cybersecurity for Executives in the Age of Cloud. Teri contou como entrou no universo da segurança na nuvem depois de sofrer uma violação em sua antiga empresa de desenvolvimento e hospedagem de aplicações web. A 2nd Sight Lab oferece treinamento e consultoria em segurança na nuvem. Grande parte do que Teri compartilhou não veio da perspectiva de implementar tecnologias de nuvem em uma única organização, mas de seu trabalho de consultoria com várias organizações.

Um desafio fundamental ao falar sobre nuvem e transformação para a nuvem é simplesmente definir o que significa nuvem. Nas palavras de Teri: “Algumas pessoas dizem que é apenas o computador de outra pessoa, mas eu sempre digo que é mais do que isso, porque, quando eu trabalhava em uma empresa de hospedagem gerenciada, também era o computador de metal de outra pessoa, certo?” Para algumas organizações, até mesmo o uso de soluções de software como serviço (SaaS) pode fazer parte da estratégia de nuvem.

Além da complexidade de entender o que é a nuvem, a natureza dinâmica das tecnologias cloud native faz com que os desenvolvedores assumam muita responsabilidade pela segurança. Teri comentou essa complexidade: “Se você é desenvolvedor e agora precisa criar redes ou configurar buckets do S3, balanceadores de carga ou CDNs, precisa pesquisar quais são as melhores práticas.” Para ajudar, ela deu uma recomendação aos desenvolvedores: “Existem os CIS Benchmarks, que mostram as melhores práticas para os três principais provedores de nuvem.”

É claro que outra chave para lidar com a complexidade da segurança na nuvem é fazer com que desenvolvedores e especialistas em segurança trabalhem juntos para compartilhar conhecimento, entender o trabalho uns dos outros e buscar um objetivo comum: criar software seguro. Radichel comentou que a segurança precisa assumir um papel ativo nesse processo. “Acho que a segurança tem uma função enorme que não envolve ficar com as mãos no teclado. Não se trata apenas de segurança de aplicações e de garantir que seu código não tenha uma vulnerabilidade de cross-site scripting. Segurança tem a ver com risco”, afirmou.

Por fim, em qualquer transformação de grande porte, também é extremamente importante garantir que os processos e procedimentos definidos sejam seguidos de forma consistente e que aprendamos com os erros. Radichel reconhece: “Mas as pessoas também cometem erros. Por isso, você precisa pensar na governança como um todo, na sua organização e em como estruturá-la para que as pessoas não possam cometer esses erros, certo?”

Em última análise, adotar o modelo de responsabilidade compartilhada de uma verdadeira cultura DevSecOps promove práticas melhores em toda a transformação para a nuvem. As observações e sugestões de Radichel demonstram a importância de todas as equipes envolvidas no pipeline de entrega trabalharem juntas, compartilharem conhecimento e se concentrarem em um objetivo comum.