Difference: NGI_ITSSC6 (1 vs. 7)

• Data/orario di inizio
  • A seconda della disponibilità decidere se fare tutti i siti in un'unica soluzione o dividerli

• Da dove è stato eseguito il job (WMS e/o UI)? Avvalersi dell'ausilio della NGI che gestisce i WMS chiedendo informazioni a grid-operationslists.infn.it (specificare l'attività SSC6)

Esempio raccolta timestamp per l'intero fiesystem:

find / -xdev -print0 | xargs -0 stat -c "%Y %X %Z %A %U %G %n" > timestamps.dat

timeline-decorator.py < timestamps.dat | sort -n > timeline.txt (timeline-decorator.py in calce)

• VO usata (infngrid) e compatibilità con le varie policy di MaxCPU/WallTime

• • Possono essere d'ausilio ai siti?

Come verranno notificati i siti

Una mail alla lista di sicurezza (contatto CSIRT in GOCDB) dei siti coinvolti verrà inviata dal sistema che tiene traccia delle simulazioni.

• VO usata (infngrid) e compatibilità con le varie policy di MaxCPU/WallTime
  • Limitazioni con la durata del proxy (24h) e quella del job in esecuzione sulla coda cert
  • VO alternative non su coda cert? (Es. gridit)
• Test di comunicazione fra il coordinamento dell'incidente (NGI_IT) ed i contatti di sicurezza dei siti coinvolti
  • Via ticket rt (mail alla vostra lista grid-sec)

• Uso del "central banning"
  • Attività di configurazioni richieste per l'integrazione dei CE coinvolti nel sistema centrale

Cos'e' il security service challenge

Il security service challenge è una simulazione di un incidente di sicurezza che viene eseguito con l'intento di analizzare la capacità di siti, NGI e EGI CSIRT nella risposta agli incidenti di sicurezza sulla base della procedura ufficiale EGI.

Tutte le informazioni forensi trovate dovranno dunque essere riportate sulla base del modello previsto dalla porcedura stessa.

Scenario: uso improprio di credenziali grid rubate

Poichè l'uso improprio di credenziali grid rubate rappresenta una potenziale minaccia per l'intera infrastruttura, lo scenario che si è pensato di usare è appunto quello di un job autenticato ed autorizzato ad essere eseguito sui worker nodes di un sito grid. I siti avranno dunque a che fare con un certificato x509 DN di un utente usato per generare della credenziali grid al fine di eseguire dei job che simuleranno le tipiche attività di un malware.

Cosa ci si aspetta dai siti coinvolti

Il sito coinvolto nella simulazione dovrà comportarsi come se si trattasse di un normale incidente con le seguenti eccezioni:

1. Nessuna sanzione (es. esclusione anche temporanea) della VO coinvolta
2. Tutte le comunicazioni devono essere inviate in maniera esclusiva all'apposito indirizzo mail predisposto (si prega di non usare abuse(at)egi.eu)

Le informazioni più rilevanti ai fini della risoluzione dell'incidente possono essere riassunte nelle risposte alle seguenti domande

Rete

• Nel WN in cui i job sono in esecuzione vi sono delle connessioni aperte sospette? Se si verso quali IP?
• Il sito si avvale di un servizio (es. netflow) che possa mettere in evidenza connessioni di questo tipo?

Contenimento

• Il processo riconducibile al "malware" appartiene ad un batch job o ad una shell interattiva?
• Da dove è stato eseguito il job (WMS e/o UI)? Avvalervi dell'ausilio della NGI che gestisce i WMS chiedendo informazioni a grid-operationslists.infn.it (specificare l'attività SSC6)
• Da quanto tempo il job è in esecuzione (es. YYYY:MM:DD hh:mm)?
• Come posso fare per escludere il DN?

Analisi malware

• Si riesce a trovare il malware e a capirne le funzionalità?

Utilità per i siti

Lista di pratiche, procedure e setup utili ai siti nello svolgimento della simulazione

Service reference card dei servizi grid coinvolti

• Computing element
• Worker node

Esclusione centralizzata del DN coinvolto

Durante la simulazione è possibile provare la funzionalità di "central banning" operata dalla NGI. Dopo aver concordato la cosa fra NGI e siti coinvolti, alcune configurazioni si rendono necessarie nei siti. Tali configurazioni differiscono a seconda dell'uso o meno del servizio Argus come sistema di autenticazione per i job grid.

Per ulteriori informazioni fare riferimento alla guida Central banning setup for sites.

Approccio sommario ma veloce all'analisi forense

Informazioni utli ad un'analisi "quick and dirty" possono essere trovate nella presentazione (allegata in calce) fatta da un esperto di EGI CSIRT allo scorso forum tecnico EGI. Un modo di procedere molto semplice e immediato di procedere nella raccolta di informazioni utili viene descritto unitamente ad uno script python capace di "ripulire" i timestamps vari presi presentandoli in modo più intuitivo per la lettura di eventi riconducibili all'attività sospetta.

Spunti di discussione con i siti coinvolti nella simulazione

• Uso del "central banning"
  • Attività di configurazioni richieste per l'integrazione dei CE coinvolti nel sistema centrale
• Esempi pratici di estrazione di "timestamps" come indicati nel pdf allegato
  • Possono essere d'ausiolio ai siti?

Scheda informativa sul security service challenge 6 (ssc6)

-- GiuseppeMisurelli - 2013-11-18