Incidens után lesz-e mit vizsgálni? Forensic readiness KKV-környezetben
A forensic readiness célja nem egy saját DFIR csapat felépítése, hanem annak előzetes biztosítása, hogy incidens esetén legyen használható napló, időrend, hozzáférés és megőrizhető technikai bizonyíték.
Egy biztonsági incidens után gyakran nem az az első probléma, hogy nincs elég elemzőeszköz.
Hanem az, hogy nincs elég jó adat ahhoz, hogy meg lehessen mondani, mi történt.
A forensic readiness ezért megelőző feladat. Nem azt jelenti, hogy minden KKV-nak saját digitális forensics laboratóriumot kell építenie. Azt jelenti, hogy még az incidens előtt gondoskodunk a szükséges naplókról, időszinkronról, hozzáférésről, megőrzésről és dokumentációról.
Miért fontos ez?
Egy incidensvizsgálat tipikus kérdései:
- melyik fiókkal történt a belépés;
- honnan érkezett;
- mikor történt;
- milyen jogosultságot használt;
- mely rendszereket érte el;
- változott-e konfiguráció;
- volt-e oldalirányú mozgás;
- történt-e adatletöltés vagy rendellenes forgalom;
- mikor kezdődött és mikor ért véget az esemény.
Ha a releváns logok egy része nincs engedélyezve, túl rövid ideig marad meg, vagy az órák nincsenek szinkronban, az eseménysor később csak részben rekonstruálható.
A NIST log management útmutatója is azt hangsúlyozza, hogy a naplók generálását, továbbítását, tárolását, hozzáférését és megőrzését szervezeti szinten kell tervezni, mert ezek az adatok az incidensek azonosítását és vizsgálatát is támogatják.
A forensic readiness nem azonos a SIEM-mel
Egy SIEM hasznos lehet, de nem old meg automatikusan minden readiness problémát.
Ha a forrásrendszer nem generálja a fontos eseményt, nincs mit begyűjteni.
Ha a logforrás neve vagy tulajdonosa nem ismert, az elemző nem tudja, mit kell még bekérni.
Ha a retention rövidebb, mint amennyi idő alatt az incidens kiderül, az esemény már eltűnhetett.
Ha minden adminisztrátor közös fiókot használ, a naplózott esemény személyhez rendelése problémás lehet.
A readiness tehát a teljes bizonyítási láncot nézi, nem csak a loggyűjtő terméket.
Minimum ellenőrzési lista
KKV-környezetben jó első baseline lehet ez a tíz kérdés.
1. Ismertek a kritikus logforrások?
Például:
- Entra ID / Microsoft 365 bejelentkezések;
- tűzfal és VPN;
- Windows eseménynaplók;
- szerverek;
- végpontvédelem;
- backup rendszer;
- virtualizáció;
- fontos üzleti alkalmazások;
- adminisztratív változtatások.
2. Van felelőse minden forrásnak?
Incidens közben nem ideális akkor kideríteni, ki tud hozzáférni egy adott audit naplóhoz.
3. Szinkronban vannak az órák?
A különböző rendszerek eseményeit időrendbe kell tudni helyezni. Jelentősebb eltérés nehezítheti a korrelációt.
4. Megfelelő a retention?
Nem létezik minden szervezetre egyetlen jó nap-szám. A szükséges megőrzés függ a kockázattól, a detektálási időtől, a jogi és üzleti követelményektől, valamint a platform képességeitől.
A fontos kérdés: az incidens tipikus észlelési idején túl is rendelkezésre áll-e a szükséges adat?
5. Kereshető a privileged aktivitás?
A rendszergazdai és magas jogosultságú változtatások különösen fontosak. Ha nem látható, ki módosított tűzfalszabályt vagy hozzáférést, az incident timeline hiányos maradhat.
6. Elkülönül a normál és rendellenes működés?
Már egyszerű baseline is sokat segít:
- tipikus bejelentkezési helyek;
- megszokott admin idősávok;
- normál szolgáltatáskapcsolatok;
- jellemző adatforgalmi irányok;
- rendszeres backup- és maintenance események.
Nem kell ehhez feltétlenül gépi tanulási modell.
7. Megőrizhető a bizonyíték kontrolláltan?
Incidens esetén fontos lehet egy logexport, image vagy más artifact eredeti állapotának megőrzése és integritásának dokumentálása. Hogy pontosan milyen eljárás szükséges, az ügy és a jogi környezet függvénye.
8. Dokumentált, honnan kérhető le az adat?
A „valaki tudja” nem jó incident response kontroll.
9. Van működő exportút?
Egy auditlog csak akkor használható, ha szükség esetén ténylegesen le tudjuk kérni és meg tudjuk őrizni.
10. Volt próba?
Egy egyszerű tabletop vagy célzott teszt megmutathatja, hogy a dokumentált logforrások közül melyik érhető el valójában.
Mit érdemes előre dokumentálni?
Egy minimális log/evidence registry mezői lehetnek:
- rendszer neve;
- logforrás;
- felelős;
- elérési mód;
- retention;
- időzóna / időszinkron;
- exportálási lehetőség;
- érzékenység;
- kapcsolódó incident runbook;
- utolsó validáció dátuma.
Ez nem bírósági chain-of-custody eljárás, és nem helyettesíti jogi vagy DFIR szakértő bevonását. Viszont jelentősen csökkenti annak esélyét, hogy az első valódi incidensnél derüljön ki: a legfontosabb adat már nincs meg.
Egy egyszerű readiness próba
Válassz egy kontrollált eseményt, például:
- admin bejelentkezés;
- VPN kapcsolat;
- tesztfiók sikertelen hitelesítése;
- engedélyezett konfigurációmódosítás.
Ezután próbáld végigkövetni több rendszerben:
- hol jelenik meg;
- mennyi idő után kereshető;
- tartalmaz-e elég információt;
- exportálható-e;
- ugyanaz-e az időbélyeg logikája;
- egy másik admin a dokumentáció alapján meg tudja-e ismételni.
A cél nem egy látványos dashboard. A cél az, hogy incidens esetén ne a bizonyítékgyűjtés infrastruktúráját kelljen először kitalálni.
Források
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-92: Guide to Computer Security Log Management
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response