DFIR · Incident response
Preserva evidenze di incidente senza esporre contenuti sensibili
Durante un incidente, le organizzazioni devono agire rapidamente: contenere, analizzare, documentare, correggere e dimostrare cosa è stato fatto. In questa fase screenshot, log esportati, hash locali e cartelle condivise possono diventare fragili, difficili da verificare o contestabili in fase di revisione.
Per chi è pensato
- Security team
- Incident responder
- MSP e MSSP
- Cyber insurer
- Consulenti forensi
- Team IT interni
- Organizzazioni che devono preservare evidenze durante o dopo un incidente
Input tipici
- Incident report e timeline
- Hash sospetti e file di interesse
- Cartelle rilevanti
- Log esportati (EDR, SIEM, sistema, applicativi)
- Screenshot e dump
- Evidenze di remediation (before / after)
- Note DFIR
- Baseline precedenti per confronto
Output CertiSigma
- Incident evidence package
- Manifest delle evidenze incluse
- Attestazioni hash T0 / T1 / T2
- Compare report (delta vs baseline)
- Remediation before / after evidence
- Bundle verificabile da terzi
- Materiali di catena di custodia
- Link o istruzioni di verifica pubblica
Correlazione, non conclusione automatica
Un match hash non prova da solo l'esfiltrazione. Può però supportare una correlazione forense quando viene letto nel contesto investigativo corretto, con catena di custodia documentata e baseline ricostruibile.
CertiSigma aiuta a preservare e rendere verificabili elementi che altrimenti resterebbero dispersi tra file locali, screenshot, esportazioni e dichiarazioni interne, riducendo la fragilità del materiale evidenziale.
Cosa CertiSigma NON prova qui
- Che un match hash con un file noto-malevolo dimostri da solo l'esfiltrazione
- Che la timeline ricostruita sia esaustiva o priva di lacune
- Che il responsabile dell'incidente sia identificato
- Che la remediation eseguita sia sufficiente o conforme a un'eventuale notifica obbligatoria
- L'efficacia o l'integrità degli strumenti EDR / SIEM da cui provengono i log esportati