🔥 🚒 Planejando um exercício de Red Team
Este documento ajuda a informar o planejamento de red team ao contrastar com o estilo muito específico de red team descrito em Red Teams. Este método expressa vários vieses para otimizar o valor e o entusiasmo da blue team. Ele evita especificamente tentativas de motivar por punição do red team.
Revise as perguntas abaixo para testar se o seu planejamento de red team foi minuciosamente pensado para o valor da sua blue team.
❌ Motivações negativas
A seguir estão razões comuns para conduzir um exercício de red team. Elas têm qualidades prejudiciais ao moral ou à coesão da equipe. Um exercício pode ser a ferramenta errada para seus objetivos.
- Provar a insegurança de outra organização
- Exibir dominância sobre um grupo de pessoas
- Provar ou defender um ponto por meio de choque e pavor
- Enumerar e descobrir o maior número possível de vulnerabilidades
- Testar se mecanismos simples de detecção estão funcionando
👍 Partes interessadas
Nada seria mais desperdiçado do que um exercício sem patrocínio ou acompanhamento da liderança ou de influenciadores. Garanta que os aprendizados de um exercício sejam defendidos por um grupo entusiasmado de partes interessadas. Garanta que esse grupo esteja informado e possa gerar impulso.
- Defina expectativas e um responsável / proprietário conhecido para conduzir os resultados do exercício
- Garanta abertura para mudanças e tenha patrocínio alinhado para conduzir a mudança.
- A organização é um participante disposto neste exercício?
- Os participantes estariam abertos a qualquer calibração de risco ou a uma revisão do seu roadmap atual?
- Existe uma dívida significativa que teria precedência sobre quaisquer descobertas do Red Team?
- As descobertas do Red Team serão tão previsíveis que um exercício nem era necessário para começar?
📅 Estimativas de tempo
Você pode projetar a quantidade de tempo a alocar desde esta fase de planejamento até o final de uma fase de mitigação, ou algo entre os dois. As expectativas de tempo dependem fortemente das decisões tomadas para cada fase.
- Planejamento (Semanas/Meses): Planejar a execução geral, preenchendo as lacunas deste documento.
- Ataque (Minutos/Semanas): Integração do red team e criação ativa do incidente.
- Resposta (Horas/Semanas): Se o incidente for descoberto, a duração da resposta imediata.
- Tabletop (Dias/Semanas): Se o incidente não for descoberto, a duração da resposta forçada ou do tabletop.
- Resposta a Incidentes (Curto Prazo) (Dias/Semanas): O tempo para remover o acesso do red team, corrigir qualquer vulnerabilidade descoberta e eliminar o adversário.
- Revelação do Red Team (Horas): Exibir as ações do Red Team para calibrar as realidades de RI.
- Resposta a Incidentes (Post Mortem) (Horas/Dias): Organização das lições aprendidas e apresentação ampla.
- Mitigação de Longo Prazo (Semanas/Meses): Conclusão das lições aprendidas mais difíceis, refatoração e crescimento antes de considerar o próximo red team.
👪 Pessoas
Identifique todas as pessoas que podem precisar saber dos planos e segredos do Red Team. É aqui que você vai querer mitigar qualquer risco de "Break Glass" e ter detalhes de contato prontos para um desvio do exercício devido a emergências.
- Empresas de consultoria: Você contratará uma parte externa como red team?
- Recursos internos: Funcionários internos atuarão como red team?
- Quem é responsável por (neste caso, reter) um chamado à polícia?
- Quem é responsável pelas relações públicas / comunicações recebidas?
- Quem é responsável pelas interações com clientes?
- Quem é o recurso de notificação de violação? (interno / advogado externo)
- Quem é o "Game Master" geral que conduzirá os problemas e será a fonte final de bom julgamento?
📉 Estratégia
Decida onde você vai acumular seu valor a partir dessa experiência. Há tradeoffs em todos os lugares que podem não resolver o que você está tentando resolver com um exercício.
- Os defensores em potencial estão cientes de que um red team deve ser esperado em algum momento?
- Eles deveriam estar? Você precisa definir essa expectativa?
- Você também anunciará uma janela na qual um red team deve ser esperado?
- Isso causará uma excitação saudável e um sprint de preparação?
- Os atacantes serão fortemente guiados com "cheating", ou será de forma livre?
- Esse tradeoff diz respeito ao valor da resposta a incidentes e à descoberta de vulnerabilidades.
- A equipe foi informada de que haverá regras rígidas sobre humilhação?
- Você quer evitar qualquer sentimento de que isso é uma punição por segurança ruim.
- A equipe foi informada de que isso é um presente para a blue team, e não uma punição por segurança ruim? Ou seja, isso não é um teste, é um sparring?
- Reforçando esse ponto. Garanta que se saiba que este é um valioso ciclo de feedback, não um ciclo de desempenho de funcionários.
- Foi selecionado um método específico ou uma "kill chain" realista para estruturar o exercício?
- Seu objetivo é simular um incidente em um risco com muitas mitigações, ou em um risco com muito menos telemetria / medidas preventivas?
- Durante cada fase, qual é o "break glass"? Como você anuncia amplamente qual é a verdade e o que precisa acontecer em seguida, caso um red team dê errado e cause uma interrupção?
- Em que circunstâncias você quer "cancelar" o red team?
- Considere quando ele estiver naturalmente completo, quando interferência externa exigir uma parada, ou quando a experiência não for mais valiosa para os participantes.
🔧 Desenho do ataque
Um ataque representa os riscos que você está tentando mitigar, o incidente que você está tentando lidar, ou os indivíduos que você espera incluir na resposta. Todas essas decisões têm ônus de planejamento que são úteis de identificar o mais cedo possível.
- O ataque realmente precisa de muita experiência e esforço, ou você pode fazer recriações simples de um ataque para descobrir? Partes externas são mesmo necessárias?
- Onde o ataque deve começar na kill chain? (Ou seja, cedo: spear phishing, ou tarde: movimento lateral com administrador de domínio)
- Quais credenciais / acesso físico / documentação são necessários para apoiar o início do ataque? Quem os fornecerá? Há implicações de segurança que precisam ser acompanhadas depois?
- Se o red team tiver sucesso cedo, eles devem começar um teste de penetração ou uma avaliação de vulnerabilidades? Devem tentar ser pegos?
- O atacante deve se passar por um adversário específico, ou por um método de ataque?
- Se o red team for detectado, haverá um plano B ou um segundo ataque? O red team recorrerá a um teste de penetração?
- Onde e como o red team documentará seus comportamentos? Eles precisam ser capturados para qualquer tabletop de acompanhamento e para confirmar a remediação e as lições aprendidas. Você consegue coletar um histórico do bash? Um TCP dump? Anotações manuais?
- Os métodos do Red Team serão baseados na realidade? Eles estão usando métodos que não estão disponíveis para um atacante realista?
🚨 Resposta a incidentes
Se você consegue prever o quão maduro será o seu processo de resposta, pode manipular a resposta para obter maior benefício. Uma equipe de resposta imatura pode ser fortemente guiada pelo Game Master, ou uma equipe de resposta madura pode ser deixada sozinha para identificar pontos de atrito na coordenação e na comunicação.
- Existe um método ou plano de coordenação específico que a resposta a incidentes deve seguir? Por exemplo, a agenda e o método descritos em Security Breach 101 ou An Incident Response Plan for Startups
- A resposta a incidentes precisará se unir naturalmente, para que você possa eliminar o atrito no processo?
- A resposta a incidentes se unirá artificialmente para forçar a resposta pretendida como prática?
- Você vai querer escalar o incidente artificialmente para poder controlar a resposta a incidentes?
- Quem fará a ponte de comunicação com o Red Team, se houver perguntas honestas da Blue Team? (Por exemplo: "Achamos que encontramos uma violação separada")
- Quem documentará os pontos problemáticos do Red Team enquanto a Blue Team mitiga? ("Vocês ficaram removendo nossos beacons e foi difícil voltar, não esperávamos que vocês encontrariam todos de uma vez!")
- Se a resposta a incidentes não estiver progredindo em tempo hábil, quem ou como os indicadores serão vazados para a Blue Team?
- Isso será feito em um formato de tabletop?
- As mitigações de curto prazo / medidas preventivas de longo prazo estão sendo coletadas como parte da sua resposta a incidentes?
🔍 Revelação do Red Team
A Blue Team terá todos os tipos de perguntas para o red team. Esse pode ser um momento de entusiasmo se for feito corretamente. Manter esse relacionamento saudável é fundamental. O red team deve ser visto como um parceiro de sparring inestimável. Melhor ainda, um coelho para perseguir.
- As ações do Red Team durante a fase de ataque estão muito bem documentadas e compreendidas?
- O processo de resposta a incidentes perdeu alguma ação substancial do Red Team?
- Existem IOCs ou artefatos que ainda estão em beaconing ou que podem ser descobertos no futuro?
- Algum backdoor ou outras alterações em risco sobreviveram à resposta a incidentes?
- Quão minuciosa foi a investigação e a contenção da Blue Team?
💀 Post Mortem
Um post mortem de alta qualidade informará meses de trabalho de segurança planejado no roadmap e calibrará todos em uma missão por meio de uma experiência compartilhada.
- Houve um processo completo de entrevistas ou debriefing com todos os participantes do exercício?
- Todos os itens de mitigação de acompanhamento foram coletados centralmente e priorizados com base no sentimento de valor dos participantes?
- Esses sentimentos estão sendo sintetizados e apresentados de volta aos participantes?
- Você tem uma reunião reservada para apresentá-los?
- Quem os apresentará?
- O Red Team está disponível para comentar esses sentimentos ou para responder perguntas?
- Os participantes estão sendo recompensados por participarem?
- Eles têm tempo suficiente para debriefing e discussão?
- Isso é uma calibração valiosa em relação aos riscos práticos?
👶 Exercícios pequenos
Você pode manter um exercício pequeno e com envolvimento mínimo de outras pessoas. Seja criativo.
Simplesmente faça um membro da equipe simular um incidente que você acha que poderia responder com sucesso. Por exemplo, você pode instalar um software que tenha funcionalidade de atualização automática e fingir que é malware. Então você "caçaria" o "C&C", que seria apenas o seu beacon de atualização. Por exemplo, você consegue provar que ele está isolado neste host, e não em outros?
Ou, peça a um membro da equipe que faça uma "alteração não autorizada" e monte uma linha do tempo do incidente que documente o evento e quais acompanhamentos importariam.
Apenas certifique-se de documentar suas descobertas, suas lições e seus acompanhamentos para apresentar aos outros. Red teams não são valiosos se suas lições ficarem isoladas, e eles não precisam ser complicados.