Olá, pessoal da segurança da informação, o que vocês estão fazendo para proteger sua equipe de DevOps?

DevOps, aplicações sem servidor e contêineres são apenas alguns dos avanços mais recentes no conjunto de ferramentas de um desenvolvedor. Para as equipes de desenvolvimento, isso significa que o tempo de lançamento no mercado (TTM) é mais rápido — especialmente para equipes ágeis. Então, como e o que as equipes de operações de segurança estão fazendo para garantir que a segurança acompanhe esse rápido desenvolvimento? A maioria está tentando incorporar um engenheiro de segurança em suas equipes de desenvolvimento — o que é um ótimo primeiro passo —, mas existem várias camadas que você precisa proteger para garantir que sua organização esteja protegida além do código-fonte.

DevOps ou DevSecOps representam um grande avanço, mas a adoção (e implementação) do DevOps ainda é difícil para muitas organizações. Mesmo que uma organização já tenha implementado o DevSecOps, ainda existem preocupações importantes que toda equipe de segurança precisa levar em consideração.

Independentemente do tamanho da organização — de uma pequena startup de tecnologia a uma empresa global — a implantação rápida é fundamental para manter uma vantagem competitiva. A segurança deve fornecer os direitos necessários para que sua equipe de desenvolvimento execute suas tarefas. Tanto os desenvolvedores quanto as equipes de segurança precisam poder instalar quaisquer ferramentas, bibliotecas etc. quando necessário.

Você já ouviu falar sobre NPM sendo comprometido Certo? E quanto a... Arch Linux? PythonQuais controles de segurança você implementou para detectar e prevenir esse tipo de ataque em sua organização?

Monitore todos os ambientes.

As equipes de segurança têm uma série de preocupações que precisam ser abordadas diariamente, desde a segurança de pacotes de terceiros comprometidos até problemas em seus sistemas de produção. Mas e os ambientes de implantação? Os ambientes de controle de qualidade? Você os monitora tão bem quanto monitora a produção? Deveria.

Em muitas situações (mas não necessariamente como uma boa prática), um ambiente de desenvolvimento ou de controle de qualidade é uma duplicação de um ambiente comprovadamente eficiente (como o de produção). Isso significa que esse ambiente pode ter produção Dados que suas equipes de segurança devem conhecer. Esses ambientes de desenvolvimento devem ter os mesmos controles de segurança, ou controles semelhantes, que os ambientes de produção e devem ser monitorados (e registrados) da mesma forma que qualquer sistema de produção.

Existem muitos outros controles que você pode adicionar, mas o importante é garantir que sua equipe esteja monitorando esses ambientes com precisão e tenha visibilidade de quaisquer alterações feitas em qualquer ambiente.

Se seus ambientes de desenvolvimento ou controle de qualidade estiverem repletos de dados que não são de produção, ainda assim existem riscos dos quais você precisa estar ciente.

Chaves, tokens, CI/CD, meu Deus!

Seus desenvolvedores têm acesso aos seus ambientes de CI/CD (integração contínua e entrega contínua) para compilação e implantação? Eles têm acesso a ambientes de desenvolvimento, seja localmente ou na AWS/Azure/GCP/etc.?

Se você respondeu sim, então precisa garantir que está monitorando de perto a atividade de seus desenvolvedores (especialmente em seus sistemas locais)! Basta visitar um site malicioso ou cair em um golpe de phishing para correr sério risco.

Se seus desenvolvedores acessam recursos baseados em nuvem, eles geralmente usam um conjunto de credenciais ou chaves de acesso/secretas para acessar esses ambientes. Adivinhe onde elas são armazenadas? Isso mesmo, no sistema local deles. Aqui está uma lista rápida de locais para procurar:

CLI da AWS: ls ~/.aws ~/.aws/credentials ~/.aws/config CLI do Azure: $HOME/.azure (*nix e macOS) %USERPROFILE%\.azure (Windows)

Se essas credenciais nas máquinas dos seus desenvolvedores forem comprometidas, as consequências para sua organização podem ser devastadoras. Um agente malicioso pode modificar seus ambientes de CI/CD e alterar sua base de código sem ser detectado nos binários ou bibliotecas compilados.

Além disso, você deve impedir que os desenvolvedores enviem segredos acidentalmente para os repositórios. Existem várias maneiras de detectar isso, mas uma delas é usar segredos do git da AWS.

Certifique-se de que sua equipe de segurança entenda onde os segredos são armazenados, como são usados e quais as consequências de não monitorar ou alertar sobre o possível uso indevido dessas credenciais.

Conteinerização

À medida que as organizações migram para contêineres, computação sem servidor e infraestrutura como código, as equipes de segurança da informação devem trabalhar em conjunto com as equipes de desenvolvimento para estabelecer um repositório interno de contêineres que seja monitorado continuamente pela equipe de segurança. Se um novo pacote ou biblioteca for necessário, certifique-se de que um engenheiro de segurança (da sua equipe de desenvolvimento) revise o código antes de integrá-lo à branch principal. Além disso, você deve começar a implementar a varredura automatizada dos seus repositórios para ajudar a identificar quaisquer segredos potenciais deixados em commits e para identificar bibliotecas de terceiros vulneráveis que estejam sendo importadas ou usadas no seu produto.

Equipe de desenvolvimento + segurança

Imagine que você faz parte de uma equipe de desenvolvimento e alguém de outro departamento chega e diz que seu trabalho é péssimo e que há falhas de segurança por toda parte. Como você reagiria? Provavelmente não muito bem, principalmente se você acha que seu código é bom!

Esse tipo de interação com as equipes de desenvolvimento acontece o tempo todo, e precisamos abordar esse problema de forma diferente. É por isso que precisamos integrar engenheiros de segurança às nossas equipes de desenvolvimento. Esse engenheiro deve ser capaz de identificar problemas de segurança, criar itens de backlog (tickets) e trabalhar (codificar) nesses itens. Esse profissional-chave é tanto um desenvolvedor quanto um especialista em segurança dentro da equipe de desenvolvimento.

Agora, imagine receber feedback de um colega de equipe. A reação do restante da equipe de desenvolvimento seria mais compreensiva, e eles teriam uma linha direta de comunicação — o que inclui a construção de um relacionamento de longo prazo entre desenvolvedores e segurança. À medida que se sentem mais à vontade, os desenvolvedores restantes da equipe não querem sobrecarregar o colega com mais trabalho. Então, você acha que eles vão levar o tempo necessário ou parar para pensar sobre a implementação? Eu acho que sim.

Além disso, esse engenheiro de segurança deve ser envolvido nas discussões com o gerente/proprietário do produto e o arquiteto desde os estágios iniciais, pois ele é o profissional de segurança de fato e deve participar das decisões iniciais de design que podem impactar a forma como seu produto lida com a segurança (pense em autenticação, segredos compartilhados, comunicações, etc.).

Resumindo

Todos os profissionais de segurança estão ocupados. Há muitos alertas e poucas horas no dia. Mesmo que não possamos responder a todos os alertas, os membros da equipe do centro de operações de segurança (SOC) precisam entender qual é a missão de sua organização, onde estão os ativos críticos e o que procurar nesse cenário de ameaças em constante evolução. Ao trabalhar com as equipes de desenvolvimento, podemos ajudar a proteger nossas respectivas organizações e começar a incorporar a segurança em nosso ciclo de vida de desenvolvimento.