Segurança no DevOps (DevSecOps)

A segurança é parte essencial do DevOps. Mas como uma equipe sabe se um sistema é seguro? É realmente possível entregar um serviço totalmente seguro?

Infelizmente, a resposta é não. O DevSecOps é um esforço contínuo que exige a atenção de todos em operações de desenvolvimento e TI. Embora o trabalho nunca seja realmente feito, as práticas empregadas pelas equipes para evitar e lidar com violações podem ajudar a gerar sistemas com a máxima segurança e resiliência.

"Essencialmente, se alguém desejar entrar, conseguirá... isso é um fato. Dizemos aos clientes: número um, você está na disputa, mesmo que não soubesse disso. Número dois, é quase certo que você seja infiltrado." -- Michael Hayden, ex-diretor da NSA e da CIA

A conversa sobre segurança

As equipes sem uma estratégia formal do DevSecOps são incentivadas a começar o planejamento o quanto antes. No início, pode haver resistência dos membros da equipe sem total consciência das ameaças que existem. Outros podem não sentir que a equipe está equipada para enfrentar o problema e que qualquer investimento especial seria uma distração desperdiçada dos recursos de entrega. No entanto, é necessário iniciar a conversa para criar um consenso quanto à natureza dos riscos, como a equipe pode atenuá-los e se a equipe precisa de recursos ausentes no momento.

Espere que os céticos levantem alguns argumentos comuns, como:

• O quanto a ameaça é real? Muitas vezes, as equipes não estimam o valor potencial dos serviços e dos dados que estão encarregadas de proteger.
• Nossa equipe é boa, certo? Uma discussão sobre segurança pode ser encarada como uma dúvida sobre a capacidade da equipe de criar um sistema seguro.
• Não acho que isso seja possível. Esse é um argumento comum entre engenheiros juniores. Aqueles com experiência geralmente sabem melhor das coisas.
• Nunca sofremos uma violação. Mas como você sabe disso? Como você saberia?
• Debates intermináveis sobre valor. O DevSecOps é um compromisso sério que pode ser percebido como uma distração do trabalho principal do recurso. Embora o investimento em segurança precise ser equilibrado com outras necessidades, ele não pode ser ignorado.

A mudança de mentalidade

A cultura do DevSecOps exige uma mudança importante de mentalidade. Você precisa evitar violações, mas também supor que existem.

Componentes de estratégia de segurança

Existem muitas técnicas a serem aplicadas em busca de sistemas mais seguros.

Prevenção de violações	Presumir violações
Modelos de ameaça	Exercícios de jogo de guerra
Revisões de código	Monitores de segurança central
Testes de segurança	Testes de penetração de site dinâmico
SDL (Security Development Lifecycle)

Todas as equipes já devem ter pelo menos algumas práticas em vigor para evitar violações. Escrever código seguro tornou-se mais padrão e há muitas ferramentas gratuitas e comerciais para ajudar na análise estática e em outros recursos de teste de segurança.

Mas, muitas equipes carecem de uma estratégia que pressuponha que as violações do sistema são inevitáveis. Talvez seja difícil admitir que você foi violado, especialmente em meio a conversas difíceis com a gerência, mas essa suposição pode ajudá-lo a tirar dúvidas sobre segurança em seu próprio ritmo. Você não deseja descobrir tudo isso durante uma emergência de segurança real.

Perguntas comuns para reflexão incluem:

• Como detectar um ataque?
• Como você responderá se houver um ataque ou penetração?
• Como se recuperar de um ataque, por exemplo, quando os dados são vazados ou adulterados?

Principais práticas do DevSecOps

Há várias práticas comuns do DevSecOps que se aplicam a praticamente todas as equipes.

Primeiro, procure melhorar o tempo médio de detecção e o tempo médio de recuperação. Essas métricas indicam quanto tempo leva para detectar uma violação e quanto tempo leva para recuperar, respectivamente. É possível acompanhá-las com testes contínuos no local ativo dos planos de resposta de segurança. Ao avaliar políticas em potencial, é importante considerar como aprimorar essas métricas.

Pratique a defesa em profundidade. Quando ocorre uma violação, os invasores podem obter acesso a redes internas e o que está contido nelas. Embora o ideal seja deter os invasores antes de chegarem a esse ponto, uma política que supõe violações leva as equipes a minimizar a exposição de um invasor que já conseguiu entrar.

Por fim, faça avaliações periódicas pós-violação de práticas e ambientes. Após solucionar uma violação, sua equipe deve avaliar o desempenho das políticas e sua própria adesão a elas. As políticas são mais eficazes quando as equipes de fato as cumprem. Toda violação, real ou praticada, deve ser vista como uma oportunidade de melhoria.

Estratégias para mitigar ameaças

Há um excesso de ameaças para enumerar todas elas. Algumas falhas de segurança ocorrem devido a problemas em dependências como sistemas operacionais e bibliotecas, portanto, mantê-los atualizados é fundamental. Outras ocorrem devido a bugs no código do sistema que exigem uma análise cuidadosa para localizar e consertar. A má gestão de segredos é a causa de muitas violações, bem como a engenharia social. É uma ótima prática pensar sobre os tipos distintos de falhas de segurança e o seu significado para o sistema.

Vetores de ataque

Considere um cenário em que um invasor obteve acesso às credenciais de um desenvolvedor. O que é possível fazer?

Privilégio	Tráfego
Eles podem enviar emails?	Colegas de Phish
Eles podem acessar outros computadores?	Fazer logon, mimikatz, repetir
Eles podem modificar a fonte	Injetar código
Eles podem modificar o processo de compilação/liberação?	Injetar código, executar scripts
Eles podem acessar um ambiente de teste?	Se um ambiente de produção assumir uma dependência do ambiente de teste, explore-o
Eles podem acessar o ambiente de produção?	Há tantas opções...

Como sua equipe pode se defender contra esses vetores?

• Armazene segredos em cofres protegidos
• Remover contas do administrador local
• Restringir SAMR
• Credential Guard
• Remover servidores com hospedagem dupla
• Assinaturas separadas
• Autenticação multifator
• Estações de trabalho com acesso privilegiado
• Detectar com o ATP & Microsoft Defender para Nuvem

Gerenciamento de segredos

Todos os segredos devem ser armazenados em um cofre protegido. Os segredos incluem:

• Senhas, chaves e tokens
• Chaves de conta de armazenamento
• Certificados
• Credenciais usadas em ambientes compartilhados que também não são de produção

Você deve usar uma hierarquia de cofres para eliminar a duplicação de segredos. Considere também como e quando os segredos são acessados. Alguns são usados em tempo de implantação ao criar configurações de ambiente e outros são acessados em runtime. Os segredos de tempo de implantação costumam exigir uma nova implantação para obter novas configurações, enquanto os segredos de runtime são acessados quando necessário e podem ser atualizados a qualquer momento.

As plataformas têm recursos de armazenamento seguro para gerenciar segredos em pipelines de CI/CD e ambientes de nuvem, como Azure Key Vault e Ações do GitHub.

Ferramentas úteis

• O Microsoft Defender para Nuvem é ideal para alertas genéricos de infraestrutura, como malware, processos suspeitos etc.
• Ferramentas de análise de código-fonte para testes estáticos de segurança de aplicativos (SAST).
• Segurança avançada do GitHub para análise e monitoramento de repositórios.
• O mimikatz extrai senhas, chaves, códigos PIN, tíquetes e muito mais da memória do lsass.exe, o Serviço do Subsistema de Autoridade de Segurança Local no Windows. Ele só exige acesso administrativo ao computador ou uma conta com o privilégio de depuração habilitado.
• O BloodHound cria um gráfico dos relacionamentos em um ambiente do Active Directory. A equipe vermelha pode utilizá-lo para identificar facilmente vetores de ataque de difícil identificação rápida.

Exercícios de jogo de guerra

Uma prática comum da Microsoft é participar de exercícios de jogos de guerra. Estes são eventos de teste de segurança em que duas equipes têm a tarefa de testar a segurança e as políticas de um sistema.

A equipe vermelha assume o papel de invasor. Eles tentam usar como modelo os ataques reais para encontrar lacunas na segurança. Eles podem explorar e também demonstrar o impacto em potencial de suas violações.

A equipe azul assume a função da equipe do DevOps. Eles testam a capacidade de detectar e responder aos ataques da equipe vermelha. Isso ajuda a melhorar a consciência situacional e a avaliar a preparação e a eficácia da estratégia do DevSecOps.

Desenvolva uma estratégia de jogos de guerra

Os jogos de guerra são eficazes para reforçar a segurança porque motivam a equipe vermelha a localizar e explorar problemas. Provavelmente será muito mais fácil do que o esperado no início. As equipes que não tentam ativamente atacar seus próprios sistemas em geral não sabem o tamanho e a quantidade de lacunas de segurança disponíveis para os invasores. A equipe azul pode ficar desmoralizada no início porque será derrotada repetidas vezes. Felizmente, o sistema e as práticas devem evoluir com o tempo para que a equipe azul vença de modo consistente.

Prepare-se para jogos de guerra

Antes de iniciar os jogos de guerra, a equipe deve tratar problemas eventuais por meio de um passe de segurança. Este é um ótimo exercício a ser executado antes de tentar um ataque porque fornecerá uma experiência de linha de base para todos para comparação após encontrar a primeira exploração mais adiante. Comece identificando vulnerabilidades por meio de uma revisão manual de código e ferramentas de análise estática.

Organizar as equipes

Organize as equipes vermelha e azul por especialidade. A meta é criar as equipes mais capazes de cada lado para permitir a execução mais eficaz possível.

A equipe vermelha deve incluir alguns engenheiros e desenvolvedores preocupados com a segurança bem familiarizados com o código. Também é útil aumentar a equipe com um especialista em testes de penetração, se possível. Em caso de ausência de especialistas internos, muitas empresas oferecem esse serviço junto com a mentoria.

A equipe azul deve ser composta por engenheiros com mentalidade operacional com profundo conhecimento dos sistemas e registros disponíveis. Eles têm a melhor oportunidade de detectar e abordar comportamentos suspeitos.

Executar os primeiros jogos de guerra

Aguarde até que a equipe vermelha seja efetivada nos primeiros jogos. Eles devem ser capazes de ter êxito em meio a ataques simples, como encontrar segredos com baixa proteção, injeção de SQL e campanhas de phishing bem-sucedidas. Reserve um bom tempo entre as rodadas para aplicar correções e comentários sobre políticas. Isso varia de acordo com a organização, mas você só deseja começar a próxima rodada quando todos estiverem confiantes de que a rodada anterior foi minerada pelo seu valor.

Jogos de guerra em andamento

Após algumas rodadas, a equipe vermelha precisará contar com técnicas mais sofisticadas, como cross-site scripting (XSS), explorações de desserialização e vulnerabilidades do sistema de engenharia. Talvez seja útil trazer especialistas de segurança externos para áreas como o Active Directory para atacar explorações mais obscuras. A essa altura, a equipe azul não só deve ter uma plataforma reforçada para defender, mas também fará uso de registro abrangente e centralizado para perícia pós-violação.

"Os zagueiros pensam em listas. Os atacantes pensam em gráficos. Mesmo que isso seja verdade, os atacantes vencem." -- John Lambert (MSTIC)

Com o tempo, a equipe vermelha levará muito mais tempo para atingir os objetivos. Se isso ocorrer, será necessário um impacto limitado da descoberta e do encadeamento de várias vulnerabilidades. Com o uso de ferramentas de monitoramento em tempo real, a equipe azul deve começar a detectar tentativas em tempo real.

Diretrizes

Jogos de guerra não devem ser gratuitos para todos. É importante reconhecer que o objetivo é gerar um sistema mais eficaz executado por uma equipe mais eficaz.

Código de conduta

Aqui está um exemplo de código de conduta usado pela Microsoft:

1. As equipes vermelha e azul não causarão problemas. Se o potencial de causar danos for significativo, ele deverá ser documentado e abordado.
2. A equipe vermelha não deve comprometer mais do que o necessário para detectar os ativos de destino.
3. As regras de bom senso se aplicam aos ataques físicos. Embora a equipe vermelha seja incentivada a ser criativa com ataques não técnicos, como a engenharia social, elas não devem imprimir crachás falsos, assediar pessoas etc.
4. Se um ataque de engenharia social for bem-sucedido, não divulgue o nome da pessoa que foi comprometida. É possível compartilhar a lição sem alienar ou constranger um membro da equipe com quem todos precisam continuar a trabalhar.

Regras de envolvimento

Aqui estão exemplos de regras de contrato usadas pela Microsoft:

1. Não afeta a disponibilidade do sistema.
2. Não acesse dados de clientes externos.
3. Não enfraqueça demais as proteções de segurança em vigor em qualquer serviço.
4. Não execute de maneira intencional ações destrutivas em relação a recursos.
5. Proteja credenciais, vulnerabilidades e outras informações essenciais obtidas.

Resultados finais

Documente riscos de segurança ou lições aprendidas em uma lista de pendências de itens de reparo. As equipes devem definir um contrato de nível de serviço (SLA) para definir a rapidez com que os riscos de segurança serão tratados. Os riscos graves têm prioridade, enquanto os problemas secundários podem ter um prazo de dois sprints.

Apresente um relatório à organização inteira com lições aprendidas e vulnerabilidades encontradas. Esta é uma oportunidade de aprendizado para todos; portanto, aproveite-a ao máximo.

Lições aprendidas na Microsoft

A Microsoft pratica regularmente jogos de guerra e aprendeu muitas lições ao longo do percurso.

• Os jogos de guerra se mostram eficazes para mudar a cultura do DevSecOps e priorizar a segurança.
• Não subestime os ataques de phishing pois eles são muito eficazes para os invasores. Para conter o impacto, pode-se limitar o acesso à produção e exigir autenticação de dois fatores.
• O controle do sistema de engenharia leva ao controle de tudo. Controle estritamente o acesso ao agente de build/lançamento, fila, pool e definição.
• Pratique a defesa em detalhes para dificultar a vida dos invasores. Cada limite a ser violado torna-os mais lentos e oferece outra oportunidade de capturá-los.
• Nunca ultrapasse realms de confiança. Em testes, a produção não deve confiar em nada.

Próximas etapas

Saiba mais sobre o ciclo de vida de desenvolvimento de segurança e o DevSecOps no Azure.