Segurança no DevOps (DevSecOps)

A segurança é uma parte fundamental do DevOps. Mas como uma equipe sabe se um sistema é 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 requer a atenção de todos nas operações de TI e de desenvolvimento. Embora o trabalho nunca seja realmente feito, as práticas que as equipes empregam para evitar e lidar com violações podem ajudar a produzir sistemas tão seguros e resilientes quanto possível.

Fundamentalmente, se alguém quer entrar, vai entrar... é preciso aceitar isso. O que dizemos aos clientes é: primeiro, você está na luta, quer tenha pensado que estivesse ou não. Número dois, você quase certamente foi hackeado." - Michael Hayden, ex-diretor da NSA e CIA

A conversa de segurança

As equipes que não têm uma estratégia formal de DevSecOps são incentivadas a começar a planejar o mais rápido possível. No início, pode haver resistência dos membros da equipe que não apreciam totalmente as 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 transporte. 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 atualmente.

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

• Quão real é a ameaça? As equipes geralmente não apreciam o valor potencial dos serviços e dos dados que são encarregados de proteger.
• Nossa equipe é boa, certo? Uma discussão de segurança pode ser percebida como dúvida na capacidade da equipe de criar um sistema seguro.
• Acho que isso não é possível. Esse é um argumento comum de engenheiros juniores. Aqueles com experiência geralmente sabem melhor.
• Nunca fomos violados. Mas como você sabe? Como você saberia ?
• Debates intermináveis sobre valor. DevSecOps é um compromisso sério que pode ser percebido como uma distração do desenvolvimento principal de funcionalidades. Embora o investimento em segurança deva ser equilibrado com outras necessidades, ele não pode ser ignorado.

A mudança de mentalidade

A cultura DevSecOps requer uma mudança importante na mentalidade. Não só você precisa evitar violações, mas pressupõe-as também.

Componentes de estratégia de segurança

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

Todas as equipes já devem ter pelo menos algumas práticas em vigor para evitar violações. Escrever código seguro tornou-se mais um 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.

No entanto, muitas equipes não têm uma estratégia que pressupõe que as violações do sistema sejam inevitáveis. Supondo que você tenha sofrido uma violação de segurança, pode ser difícil admitir, especialmente ao ter conversas difíceis com a gestão, mas essa suposição pode ajudá-lo a responder perguntas sobre segurança no seu próprio ritmo. Você não quer descobrir tudo durante uma emergência de segurança real.

As perguntas comuns a serem pensadas incluem:

• Como você detectará um ataque?
• Como você responderá se houver um ataque ou penetração?
• Como você se recuperará 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, concentre-se em 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 se recuperar, respectivamente. Eles podem ser acompanhados por meio de testes de site ao vivo contínuos de planos de resposta de segurança. Ao avaliar possíveis políticas, melhorar essas métricas deve ser uma consideração importante.

Pratique a defesa em profundidade. Quando ocorre uma violação, os invasores podem obter acesso a redes internas e tudo dentro delas. Embora seja ideal parar os invasores antes de chegarem tão longe, uma política de pressupor violações leva as equipes a minimizar a exposição de um invasor que já conseguiu entrar.

Por fim, realize avaliações periódicas após incidentes de violação de suas práticas e ambientes. Depois que uma violação for resolvida, sua equipe deverá avaliar o desempenho das políticas, bem como sua própria adesão a elas. As políticas são mais eficazes quando as equipes realmente as seguem. Cada violação, real ou praticada, deve ser vista como uma oportunidade de melhorar.

Estratégias para atenuar ameaças

Há muitas 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 up-to-date é fundamental. Outras são devido a bugs no código do sistema que exigem uma análise cuidadosa para localizar e corrigir. A má gestão de segredos é a causa de muitas violações, assim como a engenharia social. É uma boa prática pensar sobre o tipo diferente de falhas de segurança e o que 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?

Como sua equipe pode se defender desses vetores?

• Armazenar segredos em cofres protegidos
• Remover contas de administrador local
• Restringir SAMR
• Protetor de Credenciais
• Remover servidores com casa dupla
• Assinaturas separadas
• Autenticação multifator
• Estações de trabalho de acesso privilegiado
• Detectar com Advanced Threat Protection (ATP) e Microsoft Defender for Cloud

Gerenciamento de segredos

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

• Senhas, chaves e tokens
• Chaves da conta de armazenamento
• Certificados
• Credenciais também usadas em ambientes compartilhados de não 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, enquanto outros são acessados em tempo de execução. Os segredos de implantação normalmente exigem uma nova implantação para aplicar novas configurações, enquanto os segredos de execução 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 o GitHub Actions.

Ferramentas úteis

• O Microsoft Defender para Nuvem é ótimo para alertas genéricos de infraestrutura, como malware, processos suspeitos etc.
• Ferramentas de análise de código-fonte para SAST (teste de segurança de aplicativo estático).
• Segurança avançada do GitHub para análise e monitoramento de repositórios.
• Mimikatz extrai senhas, chaves, PINs, tíquetes e muito mais da memória do lsass.exe Serviço de Subsistema da Autoridade de Segurança Local no Windows. Isso 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. Ele pode ser usado pela equipe vermelha para identificar facilmente vetores de ataque que são difíceis de identificar rapidamente.

Exercícios de jogo de guerra

Uma prática comum na Microsoft é se envolver em exercícios de jogo de guerra. Estes são eventos de teste de segurança em que duas equipes são encarregadas 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 segurança. Se eles podem explorar qualquer um, eles também demonstram o impacto potencial de suas violações.

A equipe azul assume a função da equipe de DevOps. Eles testam sua capacidade de detectar e responder aos ataques da equipe vermelha. Isso ajuda a aprimorar a conscientização situacional e medir a prontidão e a eficácia da estratégia de DevSecOps.

Evoluir uma estratégia de jogos de guerra

Jogos de guerra são eficazes em proteger a segurança porque motivam a equipe vermelha a encontrar e explorar problemas. Provavelmente será muito mais fácil do que o esperado no início. As equipes que não tentaram ativamente atacar seus próprios sistemas geralmente não sabem o tamanho e a quantidade de falhas de segurança disponíveis para os invasores. A equipe azul pode ser desmoralizada no início, já que eles serão atropelados repetidamente. Felizmente, o sistema e as práticas devem evoluir ao longo do tempo, de modo que a equipe azul ganhe consistentemente.

Preparar-se para jogos de guerra

Antes de começar os jogos de guerra, a equipe deve cuidar de quaisquer problemas que possa encontrar através de um passe de segurança. Este é um ótimo exercício a ser executado antes de tentar um ataque, pois fornecerá uma experiência de referência para todos compararem depois que a primeira brecha de segurança for encontrada. Comece identificando vulnerabilidades por meio de uma revisão manual de código e ferramentas de análise estática.

Organizar equipes

As equipes vermelhas e azuis devem ser organizadas por especialidade. O objetivo é criar as equipes mais capazes para cada lado, a fim de executar da forma mais eficaz possível.

A equipe vermelha deve incluir alguns engenheiros e desenvolvedores com foco em 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 internamente, muitas empresas fornecerão esse serviço junto com a orientação.

A equipe azul deve ser composta por engenheiros focados em operações que tenham uma compreensão profunda dos sistemas e logs disponíveis. Eles têm a melhor chance de detectar e abordar comportamentos suspeitos.

Executar jogos de guerra iniciais

Espere que o time vermelho seja eficaz nos primeiros jogos de guerra. Eles devem ser capazes de obter êxito através de ataques bastante simples, como encontrar segredos mal protegidos, injeção de SQL e campanhas de phishing bem-sucedidas. Reserve muito tempo entre as rodadas para aplicar correções e comentários sobre políticas. Isso vai depender da organização, mas você não quer começar a próxima rodada até que todos estejam confiantes de que a rodada anterior foi explorada ao máximo.

Jogos de guerra em andamento

Após algumas rodadas, a equipe vermelha precisará contar com técnicas mais sofisticadas, como XSS (Cross-Site Scripting), explorações de desserialização e vulnerabilidades de sistemas. Trazer especialistas de segurança externos em áreas como o Active Directory pode ser útil para abordar vulnerabilidades mais obscuras. Neste momento, a equipe azul não só deve ter uma plataforma fortalecida para defender, mas também deve fazer uso de registros de log abrangentes e centralizados para investigação forense pós-violação.

"Os defensores pensam em listas. Os invasores pensam em grafos. Desde que isso seja verdade, os atacantes ganham." - John Lambert (MSTIC)

Com o tempo, a equipe vermelha levará muito mais tempo para alcançar objetivos. Quando o fizerem, isso frequentemente exigirá a descoberta e o encadeamento de várias vulnerabilidades, resultando em um impacto limitado. Através do uso de ferramentas de monitoramento em tempo real, a equipe azul deve começar a capturar tentativas no momento em que ocorrem.

Guidelines

Jogos de guerra não devem ser gratuitos para todos. É importante reconhecer que o objetivo é produzir 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 dano. 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-alvo.
3. As regras de senso comum se aplicam a ataques físicos. Embora a equipe vermelha seja encorajada a ser criativa com ataques não técnicos, como engenharia social, eles 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. A lição pode ser compartilhada sem alienar ou constranger um membro da equipe com quem todos precisam continuar trabalhando.

Regras de engajamento

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

1. Não afete a disponibilidade de nenhum sistema.
2. Não acesse dados externos do cliente.
3. Não enfraqueça significativamente as proteções de segurança ativas em qualquer serviço.
4. Não execute intencionalmente ações destrutivas em relação a nenhum recurso.
5. Proteger credenciais, vulnerabilidades e outras informações críticas obtidas.

Entregáveis

Quaisquer riscos de segurança ou lições aprendidas devem ser documentados em uma lista de pendências de itens de reparo. O 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. Riscos graves devem ser resolvidos o mais rápido possível, enquanto problemas menores podem ter um prazo de duas iterações.

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

Lições aprendidas na Microsoft

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

• Jogos de guerra são uma maneira eficaz de transformar a cultura DevSecOps e manter a segurança como prioridade.
• Ataques de phishing são muito eficazes para invasores e não devem ser subestimados. O impacto pode ser contido limitando o acesso à produção e exigindo autenticação de dois fatores.
• O controle do sistema de engenharia leva ao controle de tudo. Certifique-se de controlar rigorosamente o acesso ao agente de build/liberação, à fila, ao pool e à definição.
• Pratique a defesa em profundidade para dificultar a ação dos atacantes. Cada barreira que eles precisam transpor os retarda e oferece outra oportunidade de capturá-los.
• Nunca cruze os domínios de confiança. A produção nunca deve confiar em nada no ambiente de teste.

Próximas etapas

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