Segurança no DevOps (DevSecOps)

A segurança é uma parte importante DevOps. Mas como uma equipe sabe que é seguro? É realmente possível fornecer um serviço completamente seguro?

Infelizmente, a resposta é não. O DevSecOps é um esforço contínuo e contínuo que exige a atenção de todos na equipe. Embora o trabalho nunca seja realmente feito, as práticas que as equipes empregam para evitar e lidar com violações produzem sistemas tão seguros e resilientes quanto possível.

"Fundamentalmente, se alguém quiser entrar, ele está entrando... aceite isso. O que podemos dizer aos clientes é: número um, você está no meio do mundo, independentemente de ter ou não sido. Número dois, você quase certamente está descontrolado." – Michael Snowden, ex-diretor de NSA e CIA

A conversa de segurança

Teams que não têm uma estratégia formal de DevSecOps são incentivadas a iniciar o planejamento assim que possível. A princípio, pode haver alguma resistência dos membros da equipe que não agradecem totalmente as ameaças que existem. Outras pessoas talvez não sintam que a equipe está equipado para enfrentar o problema e que qualquer investimento especial seria uma distração desnecessária dos recursos de envio. No entanto, é necessário iniciar a conversa para criar um consenso sobre a natureza dos riscos, como a equipe pode atenuá-los e se a equipe precisa de recursos que não têm no momento.

Espere que os participantes traga alguns argumentos comuns, como:

  • Qual é a realidade da ameaça? Teams geralmente não agradecem o valor potencial dos serviços e dos dados que eles são cobrados pela proteção.
  • Nossa equipe é boa, certo? Uma discussão de segurança pode ser vista como dúvida na capacidade da equipe de criar um sistema seguro.
  • Não acho que isso seja possível. Esse é um argumento comum dos engenheiros de engenharia. Aqueles com experiência geralmente sabem melhor.
  • Nunca houve violação. Mas como você sabe? Como você sabe?
  • Infinito sobre o 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 deva ser balanceado com outras necessidades, ele não pode ser ignorado.

A mudança de mentalidade

A mudança de mentalidade para uma cultura de DevSecOps inclui um pensamento importante sobre não apenas evitar violações, mas pressupô-las também.

Componentes de estratégia de segurança

Há muitas técnicas que podem ser aplicadas na busca por sistemas mais seguros.

Impedindo violações Supondo violações
Modelos de ameaça Exercícios de jogos de guerra
Revisões de código Monitores de segurança central
Testes de segurança Testes de penetração de site ao vivo
SDL (ciclo de vida de desenvolvimento de segurança)

Cada equipe já deve ter pelo menos algumas práticas em prática para evitar violações. Escrever código seguro se tornou mais um padrão e há muitas ferramentas gratuitas e comerciais para auxiliar na análise estática e em outros recursos de teste de segurança.

No entanto, muitas equipes não têm uma estratégia para lidar com um mundo no qual supõem que serão violadas em algum momento. Isso pode ser difícil de reconhecer, especialmente ao ter conversas difíceis com o gerenciamento. O mais importante a se concentrar é que a prática de técnicas que pressuem violações ajuda a equipe a responder a perguntas sobre a segurança em seu próprio tempo, para que ela não tenha que descobrir tudo isso durante uma emergência de segurança real.

Perguntas comuns que a equipe precisa pensar:

  • Como detectaremos um ataque?
  • Como responderá se houver um ataque ou penetração?
  • Como nos recuperaremos de um ataque, como quando os dados foram vazados ou adulterados?

Principais práticas de DevSecOps

Há várias práticas comuns de DevSecOps que se aplicam a praticamente qualquer equipe.

Primeiro, as equipes devem se concentrar em melhorar seu tempo de detecção e tempo de recuperação média. Essas são métricas que indicam quanto tempo leva para detectar uma violação e quanto tempo leva para se recuperar, respectivamente. Eles podem ser acompanhados por meio de testes contínuos de site ao vivo de planos de resposta de segurança. Ao avaliar políticas potenciais, melhorar essas métricas deve ser uma consideração importante.

Teams também deve praticar a defesa em profundidade. Quando ocorre uma violação, isso geralmente faz com que o invasor tenha acesso a redes internas e tudo o que ele tem a oferecer. Embora seja ideal para impedi-los antes de chegar a esse ponto, uma política de assumir violações faria com que as equipes minimizassem a exposição de um invasor que já entrou.

Por fim, as equipes devem executar avaliações periódicas após a violação das práticas e dos ambientes. Depois que uma violação for resolvida, a equipe deverá avaliar o desempenho das políticas, bem como sua própria adesão a elas. Isso serve não apenas para garantir que as políticas sejam efetivas, mas também que a equipe está realmente seguindo-as. Cada violação, seja real ou em prática, deve ser vista como uma oportunidade de melhorar.

Estratégias para atenuar ameaças

A lista de possíveis ameaças a um sistema é tão substancial que não é possível enumerar tudo. Alguns problemas de segurança ocorrem devido a problemas em dependências como sistemas operacionais e bibliotecas, portanto, mantê-los atualizados é essencial. Outros ocorrem devido a bugs no código do sistema que exigem uma análise cuidadosa para encontrar e corrigir. O gerenciamento de segredo ruim é a causa de muitas violações, assim como a engenharia social. É uma boa prática pensar sobre os diferentes tipos de falhas de segurança e o que eles significam para o sistema.

Vetores de ataque

Considere um cenário em que um invasor obteve acesso às credenciais de um desenvolvedor. O que eles podem fazer?

Privilege Ataque
Eles podem enviar emails? Colegas de phish
Eles podem acessar outros máquinas? Fazer logoff, mimikatz, repetir
Eles podem modificar a origem Injetar código
Eles podem modificar o processo de build/versão? Injetar código, executar scripts
Eles podem acessar um ambiente de teste? Se um ambiente de produção tiver uma dependência no ambiente de teste, explore-o
Eles podem acessar o ambiente de produção? Tantas opções...

Como a equipe azul pode se defender contra isso?

  • Armazenar segredos em cofres protegidos
  • Remover contas de administrador local
  • Restringir SAMR
  • Credential Guard
  • Remover servidores com home-home duplo
  • Assinaturas separadas
  • Autenticação multifator
  • Estações de trabalho com acesso privilegiado
  • Detectar com atp & Central de Segurança do Azure

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
  • As credenciais usadas em ambientes de não produção compartilhados também

Use uma hierarquia de cofres para eliminar a duplicação de segredos. Considere também como e quando os segredos são acessados. Algumas são usadas no tempo de implantação ao criar configurações de ambiente, enquanto outras são acessadas em tempo de execução. Os segredos de tempo de implantação normalmente exigem uma nova implantação para escolher novas configurações, enquanto os segredos de tempo de run-time são acessados quando necessário e podem ser atualizados a qualquer momento.

As plataformas têm recursos de armazenamento seguros para gerenciar segredos em pipelines de CI/CD e ambientes de nuvem, como o Azure Key Vault e GitHub Actions.

Ferramentas úteis

  • Central de Segurança do Azure é ótimo para alertas de infraestrutura genéricos, como para malware, processos suspeitos etc.
  • Ferramentas de análise de código-fonte para SAST (teste de segurança de aplicativo estático).
  • GitHub segurança avançada para análise e monitoramento de repos.
  • mimikatz extrai senhas, chaves, códigos de pino, lsass.exetíquetes e muito mais da memória de , o serviço LSASS no Windows. Ele requer apenas acesso administrativo ao computador ou uma conta com o privilégio de depuração habilitado.
  • O BloodHound cria um grafo das relações em um ambiente do Active Directory. Ela pode ser usada pela equipe vermelha para identificar facilmente vetores de ataque que são difíceis de identificar rapidamente.

Exercícios de jogos de guerra

Uma prática comum na Microsoft é participar de exercícios de jogos de guerra. Esses 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 a função de um invasor. Eles tentam modelar ataques do mundo real para encontrar lacunas na estratégia de segurança. Se eles puderem explorar alguma, também demonstrarão o impacto potencial de suas violações.

A equipe azul assume a função da DevOps equipe. Eles testam a capacidade de detectar e responder aos ataques da equipe vermelha. Isso ajuda a aprimorar o reconhecimento da situação e medir o impacto de & preparação da estratégia de DevSecOps.

Evoluindo uma estratégia de jogos de guerra

Um dos motivos pelos quais os jogos de guerra são tão eficazes na segurança é que eles motivam a equipe vermelha a encontrar e explorar problemas. Provavelmente será muito mais fácil do que o esperado no início. Teams que não tentou ativamente atacar seus próprios sistemas geralmente não estão cientes do tamanho e da quantidade de falhas de segurança disponíveis para os invasores. Isso pode ser desmoralizador para a equipe azul a princípio, pois eles serão executados repetidamente. Felizmente, o sistema e as práticas devem evoluir ao longo do tempo, de forma que a equipe azul vença consistentemente.

Preparando-se para jogos de guerra

Antes de iniciar os jogos de guerra, a equipe deve cuidar dos problemas que puder encontrar por meio de uma passagem de segurança. Este é um ótimo exercício a ser executar antes de tentar um ataque, pois fornecerá uma experiência de linha de base com a comparação de todos depois que a primeira exploração for encontrada posteriormente. É bom começar identificando vulnerabilidades por meio de uma revisão manual de código e ferramentas de análise estática.

Organizando equipes

As equipes vermelhas e azuis devem ser organizadas por especialização. A meta é criar as equipes mais capazes para cada lado a fim de executar da maneira mais eficaz possível.

A equipe vermelha deve incluir alguns engenheiros e desenvolvedores de segurança profundamente familiarizados com o código. Também é útil aumentar a equipe com um especialista em testes de penetração, se possível. Se não houver especialistas em casa, muitas empresas fornecerão esse serviço junto com a orientação.

A equipe azul deve ser feita por engenheiros com princípios operacionais que têm uma compreensão profunda dos sistemas e do registro em log disponível. Eles têm a melhor chance de detectar e lidar com comportamentos suspeitos.

Executando jogos de guerra antecipados

Espere que a equipe vermelha entre em vigor nos primeiros jogos de guerra. Eles devem ser capazes de obter êxito por meio de ataques bastante simples, como encontrar segredos mal protegidos, injeção de SQL e campanhas de phishing bem-sucedidas. Leve muito tempo entre as rodadas para aplicar correções e comentários sobre políticas. Isso varia de acordo com a organização, mas você não deseja iniciar a próxima rodada até que todos têm certeza de que a rodada anterior foi minerada para tudo o que vale a pena.

Jogos de guerra contínuos

Após algumas rodadas, a equipe vermelha precisará contar com técnicas mais sofisticadas, como XSS (cross-site scripting), explorações de desserlização e vulnerabilidades do sistema de engenharia. ele também ajudará a trazer especialistas externos de segurança adicionais em áreas como o Active Directory para atacar explorações mais obscurecidas. Neste momento, a equipe azul não deve ter apenas uma plataforma forte para defender, mas também usará o registro em log abrangente e centralizado para análise forense pós-violação.

"Os defensores pensam em listas. Os invasores pensam em grafos. Desde que isso seja verdadeiro, os invasores vencem." – John Lambert (MSTIC)

Ao longo do tempo, a equipe vermelha levará muito mais tempo para atingir os objetivos. Quando isso ocorrer, geralmente exigirá a descoberta e o encadeamento de várias vulnerabilidades para ter um impacto limitado. Com o uso de ferramentas de monitoramento em tempo real, a equipe azul deve começar a capturar em tempo real.

Diretrizes

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

Código de conduta

Veja um exemplo de código de conduta usado pela Microsoft:

  1. As equipes vermelha e azul não causarão danos. Se o potencial de causar danos for significativo, ele deverá ser documentado e resolvido.
  2. A equipe vermelha não deve comprometer mais do que o necessário para capturar ativos de destino.
  3. As regras de bom senso se aplicam a ataques físicos. Embora a equipe vermelha seja incentivada a ser criativo com ataques não técnicos, como engenharia social, eles não devem imprimir selos falsos, pessoas desagredas etc.
  4. Se um ataque de engenharia social for bem-sucedido, não divulgar o nome da pessoa que foi comprometida. A lição pode ser compartilhada sem desatar ou constranger o membro da equipe com quem todos precisam continuar trabalhando.

Regras de participação

Aqui está um exemplo de regras de participação usadas pela Microsoft:

  1. Não afetar a disponibilidade de nenhum sistema.
  2. Não acesse dados externos do cliente.
  3. Não adoeça significativamente as proteções de segurança in-locar em nenhum serviço.
  4. Não execute ações destrutivas intencionalmente em relação a nenhum recurso.
  5. Proteja credenciais, vulnerabilidades e outras informações críticas obtidas.

Resultados finais

Quaisquer riscos de segurança ou lições aprendidas devem ser documentados em uma lista de pendências de itens de reparo. Teams deve definir um SLA (contrato de nível de serviço) para a rapidez com que os riscos de segurança serão resolvidos. Os riscos graves devem ser resolvidos assim que possível, enquanto os problemas secundários podem ter um prazo de dois sprints.

Um relatório deve ser apresentado a toda a organização com lições aprendidas e vulnerabilidades encontradas. É uma oportunidade de aprendizado para todos, portanto, aproveitar ao máximo.

Lições aprendidas na Microsoft

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

  • Jogos de guerra são uma maneira realmente eficaz de alterar a cultura de DevSecOps e manter a segurança em mente.
  • Os ataques de phishing são muito eficazes para invasores e não devem ser menosprezados. O impacto pode ser contido limitando o acesso à produção e exigindo a autenticação de dois fatores.
  • O controle do sistema de engenharia leva ao controle de tudo. Certifique-se de controlar estritamente o acesso ao agente de build/versão, fila, pool e definição.
  • Praticar a defesa em profundidade para tornar mais difícil para os invasores. Cada limite que eles precisam violar os deixa mais lentos e oferece outra oportunidade para a captura.
  • Nunca cruze os realms de confiança. A produção nunca deve confiar em nada em teste.

Próximas etapas

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