Segurança em DevOps (DevSecOps)

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

"Fundamentalmente, se alguém quer entrar, está a entrar, aceita isso." O que dizemos aos clientes é: em primeiro lugar, você está na luta, quer tenha pensado que estava ou não. Número dois, você quase certamente está penetrado." -- Michael Hayden, ex-diretor da NSA e da CIA

A conversa sobre 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 por parte 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 um desperdício e uma distração da implementação de funcionalidades. No entanto, é necessário começar a conversa para construir um consenso sobre a natureza dos riscos, como a equipe pode mitigá-los e se a equipe precisa de recursos que não tem atualmente.

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

• Quão real é a ameaça? Muitas vezes, as equipas não apreciam o valor potencial dos serviços e dados que estão encarregados de proteger.
• Nosso time é bom, não é? Uma discussão sobre segurança pode ser percebida como uma dúvida na capacidade da equipe de construir um sistema seguro.
• Não acho que isso seja possível. Este é um argumento comum dos engenheiros juniores. Aqueles com experiência geralmente sabem melhor.
• Nunca fomos violados. Mas como saber? Como você saberia ?
• Debates intermináveis sobre valor. O DevSecOps é um compromisso sério que pode ser percebido como uma distração do trabalho das funcionalidades principais. Embora o investimento em segurança deva ser equilibrado com outras necessidades, não pode ser ignorado.

A mudança de mentalidade

A cultura DevSecOps requer uma mudança importante de mentalidade. Não só precisa de impedir violações, mas também de assumir as violações.

Componentes da estratégia de segurança

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

Todas as equipas já devem ter pelo menos algumas práticas em vigor para prevenir 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 outros recursos de teste de segurança.

No entanto, muitas equipas carecem de uma estratégia que assuma que as violações do sistema são inevitáveis. Supor que você foi violado pode ser difícil de admitir, especialmente quando se tem conversas difíceis com a gerência, mas essa suposição pode ajudá-lo a responder a perguntas sobre segurança no seu próprio tempo. Você não quer descobrir tudo durante uma emergência de segurança real.

As perguntas comuns a serem analisadas incluem:

• Como você vai detetar um ataque?
• Como você vai reagir 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

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

Primeiro, concentre-se em melhorar o tempo médio para deteção e tempo médio para recuperação. Essas métricas indicam quanto tempo leva para detetar uma violação e quanto tempo leva para recuperar, respectivamente. Eles podem ser rastreados por meio de testes contínuos no local de planos de resposta de segurança. Ao avaliar políticas potenciais, melhorar essas métricas deve ser uma consideração importante.

Pratique a defesa em profundidade. Quando uma violação acontece, os atacantes podem ter acesso a redes internas e a tudo o que está dentro delas. Embora seja ideal parar os atacantes antes que chegue a esse ponto, uma política que assume intrusões motiva as equipes a minimizar a exposição de um invasor que já entrou.

Por fim, realize avaliações pós-incidente regularmente das suas práticas e ambientes. Depois que uma violação for resolvida, sua equipe deve avaliar o desempenho das políticas, bem como sua própria adesão a elas. As políticas são mais eficazes quando as equipas as seguem. Todas as violações, reais ou praticadas, devem ser vistas como uma oportunidade para melhorar.

Estratégias para mitigar ameaças

Há demasiadas ameaças para enumerá-las todas. Algumas brechas de segurança são devidas a problemas em dependências, como sistemas operativos e bibliotecas, por isso é fundamental mantê-las atualizadas. Outros são devido a bugs no código do sistema que exigem uma análise cuidadosa para encontrar e corrigir. A má gestão secreta é 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 elas significam para o sistema.

Vetores de ataque

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

Como sua equipe pode se defender contra esses vetores?

• Armazene segredos em cofres protegidos
• Remover contas de administrador local
• Restringir SAMR
• Guarda de credenciais
• Remover servidores de hospedagem dupla
• Subscrições separadas
• Autenticação multifator
• Estações de trabalho de acesso privilegiado
• Detectar com ATP e Microsoft Defender para Cloud

Gestão de segredos

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

• Senhas, chaves e tokens
• Chaves de conta de armazenamento
• Certificates
• 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 adotar novas configurações, ao passo que 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 seguro 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 for Cloud é ótimo para alertas de infraestrutura genéricos, 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.
• mimikatz extrai senhas, chaves, códigos PIN, tickets e muito mais da memória da Local Security Authority Subsystem Service, o Subsistema de Autoridade de Segurança Local no Windows. Requer apenas acesso de administrador à máquina ou uma conta com o privilégio de depuração ativado.
• O BloodHound cria um gráfico das relações dentro de um ambiente do Ative 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 jogos de guerra

Uma prática comum na Microsoft é se envolver em exercícios de jogos 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 equipa vermelha assume o papel de agressor. Eles tentam modelar ataques do mundo real para encontrar lacunas na segurança. Se puderem explorar alguma, também demonstram o impacto potencial das suas violações.

A equipe azul assume o papel da equipe de DevOps. Eles testam sua capacidade de detetar e responder aos ataques da equipa vermelha. Isso ajuda a melhorar a consciência situacional e medir a prontidão e a eficácia da estratégia DevSecOps.

Evolua uma estratégia de jogos de guerra

Os jogos de guerra são eficazes para fortalecer 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 equipas que não tentaram ativamente atacar os seus próprios sistemas geralmente desconhecem o tamanho e a quantidade de falhas de segurança disponíveis para os atacantes. A equipa azul pode ficar desmoralizada no início, já que será repetidamente derrotada. Felizmente, o sistema e as práticas devem evoluir ao longo do tempo de forma a que a equipa azul ganhe consistentemente.

Prepare-se para jogos de guerra

Antes de iniciar os jogos de guerra, a equipe deve cuidar de quaisquer problemas que possam encontrar através de um passe de segurança. Este é um ótimo exercício para executar antes de tentar um ataque, pois fornecerá uma experiência de linha de base com a qual todos podem comparar depois que a primeira exploração for encontrada mais tarde. Comece identificando vulnerabilidades por meio de uma revisão manual de código e ferramentas de análise estática.

Organizar equipas

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

A equipe vermelha deve incluir alguns engenheiros e desenvolvedores preocupados com a 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 internos, muitas empresas prestam esse serviço juntamente com a mentoria.

A equipe azul deve ser composta por engenheiros com espírito operacional que tenham um profundo conhecimento dos sistemas e registros disponíveis. Eles têm a melhor chance de detetar e abordar comportamentos suspeitos.

Execute os primeiros jogos de guerra

Espere que a equipa vermelha seja eficaz nos primeiros jogos de guerra. Eles devem ser capazes de ter sucesso por meio de ataques bastante simples, como encontrar segredos mal protegidos, injeção de SQL e campanhas de phishing bem-sucedidas. Reserve bastante tempo entre as rodadas para aplicar correções e comentários sobre políticas. Isso vai variar de acordo com a organização, mas tu não queres começar a próxima rodada até que todos estejam confiantes de que a rodada anterior foi explorada por tudo o que poderia render.

Jogos de guerra em curso

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. Trazer especialistas externos em segurança em áreas como o Ative Directory pode ser útil para atacar explorações mais obscuras. Neste momento, a equipa azul não só deverá ter uma plataforma reforçada para defesa, mas também fará uso de registos abrangentes e centralizados para análise forense pós-violação.

"Os defensores pensam em listas. Os atacantes pensam em gráficos. Enquanto isso for verdade, os atacantes ganham." -- John Lambert (MSTIC)

Com o tempo, a equipa vermelha vai demorar muito mais tempo a atingir os objetivos. Quando o fazem, muitas vezes será necessário descobrir e encadear várias vulnerabilidades para ter um impacto limitado. Através do uso de ferramentas de monitorização em tempo real, a equipa azul deve começar a detetar tentativas em tempo real.

Guidelines

Os jogos de guerra não devem ser um free-for-all. É 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. Tanto o time vermelho quanto o azul não farão mal. Se o potencial de causar danos for significativo, deve ser documentado e abordado.
2. A equipa vermelha não deve comprometer mais do que o necessário para capturar os ativos-alvo.
3. As regras de bom senso aplicam-se aos ataques físicos. Embora a equipe vermelha seja incentivada 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 a trabalhar.

Regras de contratação

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

1. Não afete a disponibilidade de nenhum sistema.
2. Não aceda a dados de clientes externos.
3. Não enfraqueça significativamente as proteções de segurança existentes em qualquer serviço.
4. Não execute intencionalmente ações destrutivas contra quaisquer recursos.
5. Proteja credenciais, vulnerabilidades e outras informações críticas obtidas.

Resultados

Quaisquer riscos de segurança ou lições aprendidas devem ser documentados em uma lista de pendências de itens de reparo. As equipes devem definir um contrato de nível de serviço (SLA) para a rapidez com que os riscos de segurança serão abordados. Os riscos críticos devem ser abordados o mais rapidamente possível, enquanto os problemas menores podem ter um prazo de dois sprints.

Um relatório deve ser apresentado a toda a organização com as lições aprendidas e vulnerabilidades encontradas. É uma oportunidade de aprendizagem para todos, por isso 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.

• Os jogos de guerra são uma maneira eficaz de mudar a cultura DevSecOps e manter a segurança em primeiro lugar.
• Os ataques de phishing são muito eficazes para os atacantes 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 compilação/lançamento, fila, pool e definição.
• Pratique a defesa em profundidade para dificultar a vida dos atacantes. Cada limite que têm de ultrapassar atrasa-os e oferece outra oportunidade para os apanhar.
• Nunca cruze domínios de confiança. A produção nunca deve confiar em nada na fase de teste.

Próximos passos

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