Cum construiești un plan de răspuns la incidente care funcționează?

Majoritatea organizațiilor nu eșuează la răspunsul la incidente pentru că le lipsesc instrumentele. Eșuează pentru că nimeni nu a convenit în avans cine face ce, și primul incident real devine o ședință în loc de răspuns.

Începe cu fazele, nu cu playbookul

NIST SP 800-61 stabilește patru faze: pregătire, detectare și analiză, conținere/eradicare/recuperare, și activitate post-incident. Ordinea asta contează. Echipele adoră să sară direct la conținere pentru că se simte productiv, dar dacă nu ai făcut munca de pregătire, nu cunoști destul de bine propria rețea pentru a conține ceva curat.

Pregătirea înseamnă inventare de active care sunt de fapt curente, nu foaia de calcul din 2022. Înseamnă a ști fereastra de reținere a jurnalelor (dacă e 7 zile și atacatorul a avut 30 de zile de timp de ședere, ai pierdut deja cronologia). Înseamnă instrumente forenzice pre-deployate — Velociraptor, KAPE, sau chiar o procedură documentată tar/dd pentru imagini de disc — ca să nimeni nu-și descarce instrumente pe un host compromis în mijlocul unui incident activ.

Definește niveluri de severitate înainte să le ai nevoie

O SEV1 (exfiltrare activă de date, detonare de ransomware, compromisiune de domain admin) are nevoie de un răspuns diferit decât o SEV3 (malware izolat pe o singură stație de lucru neimportantă). Scrie asta ca o matrice: impact vs. domeniu vs. încredere. Atribuie fiecărui nivel de severitate un timp de răspuns necesar și o cale de escaladare. Dacă comandantul de incident pentru o SEV1 e aceeași persoană care trebuie să aprobe fiecare comandă de cumpărare de 500 de dolari, ai construit o cută în propriul proces de urgență.

Rolul comandantului de incident nu e opțional

O persoană conduce incidentul. Nu inginerul cel mai senior implicit — persoana cea mai potrivită să coordoneze, să deleghe, și să ia decizii de conținere sub presiune. Această persoană nu neapărat atinge o tastatură în timpul răspunsului; ei urmăresc cronologia, gestionează comunicarea cu serviciul juridic și conducerea, și decid când să tragă linia pentru a izola un segment sau a deconecta un sistem.

Fără acest rol, îți vezi cinci oameni SSH'd în aceeași cutie, niciunul nevorbitulunora cu ceilalți, și nimeni nu capturează memoria volatilă înainte ca cineva să restarteze mașina pentru a "vedea dacă o rezolvă".

Decizii de conținere care contează cu adevărat

Apelul cel mai greu în majoritatea incidentelor e: izolează acum, sau observă puțin mai mult pentru a înțelege domeniul? Retragerea accesului la rețea prea devreme îi avertizează pe atacator în continuă mișcare laterală și distruge șansa de a-i vedea următoarea mutare. Așteptarea prea mult timp lasă ransomware-ul să termine criptarea partajelor.

Un mijloc rezonabil: folosește segmentarea rețelei și izolarea EDR (CrowdStrike, Defender for Endpoint, SentinelOne toate acceptă asta) pentru a tăia un host de la mișcarea laterală în timp ce-l ții pornit pentru captură de memorie. Oprirea completă ar trebui să fie ultimă soluție — ucide dovezi volatile și, pentru cazuri de ransomware, poate declanșa comportament anti-forenzic încorporat în unele payload-uri.

Goluri de logging pe care le vei regreta în cursul, nu înainte

Windowsul Event Log implicit nu e suficient. Dacă nu ai Sysmon deployat cu o configurație decent (configurile baseline ale SwiftOnSecurity sau ale lui Olaf Hartong sunt un punct de plecare solid), vei fi reconstruind copaci de procese din fragmente. Pe partea rețelei, jurnalele NetFlow sau Zeek contează mai mult decât majoritatea organizațiilor realizează până nu au nevoie să răspundă