🔥 🚒 Pianificare un esercizio Red Team

Questo documento aiuta a informare la pianificazione del red team mettendola a confronto con lo stile di red team molto specifico descritto in Red Teams. Questo metodo esprime diversi pregiudizi per ottimizzare il valore e l'entusiasmo del blue team. Evita specificamente i tentativi di motivare attraverso la punizione del red team.

Rivedi le domande qui sotto per verificare se la tua pianificazione del red team è stata accuratamente pensata per il valore del tuo blue team.

❌ Motivazioni negative

I seguenti sono motivi comuni per guidare un esercizio red team. Questi hanno qualità dannose per il morale o la coesione del team. Un esercizio potrebbe essere lo strumento sbagliato per i tuoi obiettivi.

• Dimostrare l'insicurezza di un'altra organizzazione
• Mostrare dominio su un gruppo di persone
• Dimostrare o sostenere un punto attraverso shock e stupore
• Elencare e scoprire quante più vulnerabilità possibile
• Testare se i semplici meccanismi di rilevamento funzionano

👍 Stakeholder

Niente potrebbe essere più dispendioso di un esercizio senza alcun patrocinio o seguito da parte della leadership o degli influencer. Assicurati che gli apprendimenti di un esercizio siano sostenuti da un gruppo entusiasta di stakeholder. Assicurati che questo gruppo sia informato e possa generare slancio.

• Stabilisci aspettative e un punto di riferimento/proprietario noto per guidare i risultati dell'esercizio
• Assicurati che ci sia apertura al cambiamento e che il patrocinio sia in fila per guidare il cambiamento.
• L'organizzazione è un partecipante volenteroso in questo esercizio?
• I partecipanti sarebbero aperti a qualsiasi calibrazione sul rischio, o a una revisione della loro roadmap attuale?
• C'è un debito significativo che avrebbe la precedenza su qualsiasi risultato del Red Team?
• I risultati del Red Team saranno così prevedibili che un esercizio non era necessario fin dall'inizio?

📅 Stime temporali

Puoi proiettare la quantità di tempo da allocare da questa fase di pianificazione, fino alla fine di una fase di mitigazione, o qualcosa nel mezzo. Le aspettative temporali dipendono fortemente dalle decisioni prese per ogni fase.

• Pianificazione (Settimane/Mesi): Pianificazione dell'esecuzione complessiva, colmando le lacune di questo documento.
• Attacco (Minuti/Settimane): Onboarding del red team e creazione attiva dell'incidente.
• Risposta (Ore/Settimane): Se l'incidente viene scoperto, la durata della risposta immediata.
• Tabletop (Giorni/Settimane): Se l'incidente non viene scoperto, la durata della risposta forzata o del tabletop.
• Incident Response (Breve Termine) (Giorni/Settimane): Il tempo per rimuovere l'accesso del red team, tappare qualsiasi vulnerabilità scoperta, eliminazione dell'avversario.
• Red Team Reveal (Ore): Mostrare le azioni del Red Team per calibrare le realtà dell'IR.
• Incident Response (Post Mortem) (Ore/Giorni): Organizzazione delle lezioni apprese e ampia presentazione.
• Mitigazione a Lungo Termine (Settimane/Mesi): Completamento delle lezioni apprese più difficili, refactoring e crescita prima di considerare il prossimo red team.

👪 Persone

Identifica tutte le persone che potrebbero aver bisogno di conoscere i piani e i segreti del Red Team. È qui che vorrai mitigare qualsiasi rischio di "Break Glass" e avere i dettagli di contatto pronti per un cambio di rotta da un esercizio a causa di eventuali emergenze.

• Società di consulenza: Assumerai una parte esterna come red team?
• Risorse interne: I dipendenti interni agiranno come red team?
• Chi è responsabile per (in questo caso, trattenere) una chiamata alla polizia?
• Chi è responsabile per le PR/Comunicazioni in entrata?
• Chi è responsabile per le interazioni con i clienti?
• Chi è la risorsa per la notifica delle violazioni? (interno/consulente esterno)
• Chi è il 'Game Master' complessivo che guiderà i problemi e sarà la fonte ultima di buon giudizio?

📉 Strategia

Decidi dove accumulerai il tuo valore da questa esperienza. Ci sono compromessi ovunque che potrebbero non grattare ciò che stai cercando di grattare con un esercizio.

• I potenziali difensori sono consapevoli che ci si dovrebbe aspettare un red team ad un certo punto?
  • Dovrebbero esserlo? Devi stabilire questa aspettativa?
• Annuncerai anche una finestra in cui ci si dovrebbe aspettare un red team?
  • Questo causerà un sano entusiasmo e uno sprint di preparazione?
• Gli aggressori saranno pesantemente guidati con 'cheating' (aiuti), o sarà libero?
  • Questo compromesso riguarda il valore della risposta agli incidenti e la scoperta di vulnerabilità.
• Il team è stato informato che ci saranno regole severe riguardo allo 'shaming' (vergogna)?
  • Vuoi evitare qualsiasi sensazione che questa sia una punizione per una scarsa sicurezza.
• Il team è stato informato che questo è inteso come un regalo per il blue team, non per punire una scarsa sicurezza? Cioè, non è un test, è un allenamento (sparring)?
  • Sottolineo questo punto. Assicurati che sia noto che questo è un prezioso ciclo di feedback, non un ciclo di performance dei dipendenti.
• È stato selezionato un metodo specifico o una "kill chain" realistica per inquadrare l'esercizio?
• Il tuo obiettivo è simulare un incidente in un rischio fortemente mitigato, o un rischio con molta meno telemetria/misure preventive?
• Durante ogni fase, qual è il "break glass"? Come annunci ampiamente qual è la verità e cosa deve succedere dopo, nel caso in cui un red team vada male e causi un'interruzione?
• In quali circostanze vuoi "annullare" il red team?
  • Considera quando è naturalmente completo, un'interferenza esterna richiede una chiusura, o quando l'esperienza non è più preziosa per i partecipanti.

🔧 Progettazione dell'Attacco

Un attacco rappresenta i rischi che stai cercando di mitigare, l'incidente che stai cercando di gestire, o gli individui che speri di includere nella risposta. Queste decisioni hanno tutti oneri di pianificazione che è utile identificare il prima possibile.

• L'attacco ha effettivamente bisogno di molta esperienza e sforzo, o puoi avere semplici ricreazioni di un attacco da scoprire? Le parti esterne sono addirittura necessarie?
• Dove dovrebbe iniziare l'attacco nella kill chain? (Ad es., presto: spear phishing, o tardi: movimento laterale con amministratore di dominio)
• Quali credenziali/accesso fisico/documentazione sono necessari per supportare l'inizio dell'attacco? Chi li fornirà? Ci sono implicazioni di sicurezza che devono essere seguite in seguito?
• Se il red team ha successo presto, dovrebbe iniziare un penetration test o una valutazione delle vulnerabilità? Dovrebbe cercare di essere scoperto?
• L'attaccante dovrebbe impersonare un avversario specifico o un metodo di attacco?
• Se il red team viene rilevato, ci sarà un piano di backup o un secondo attacco? Il red team ricorrerà a un penetration test?
• Dove e come documenterà il red team i propri comportamenti? Questi devono essere catturati per qualsiasi tabletop successivo e per confermare la remediation e la lezione appresa. Puoi raccogliere una cronologia di bash? Un dump TCP? Note manuali?
• I metodi del Red Team saranno basati sulla realtà? Stanno usando metodi che non sono disponibili per un attaccante realistico?