Incidens után lesz-e mit vizsgálni? Felkészülés a digitális nyomok megőrzésére

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 szakmában forensic readinessnek nevezett, incidensvizsgálatra való felkészülés ezért megelőző feladat. Nem azt jelenti, hogy minden KKV-nak saját digitális forenzikai 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 naplók 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 naplókezelési ú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 felkészültség nem azonos a SIEM-mel

Egy SIEM hasznos lehet, de nem old meg automatikusan minden ilyen felkészültségi problémát.

Ha a forrásrendszer nem generálja a fontos eseményt, nincs mit begyűjteni.

Ha a naplóforrás neve vagy tulajdonosa nem ismert, az elemző nem tudja, mit kell még bekérni.

Ha a megőrzési idő 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 felkészülés ezért nemcsak a naplógyűjtő rendszerre terjed ki, hanem a teljes bizonyítási láncra.

Minimum ellenőrzési lista

KKV-környezetben jó első kiindulópont 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;
• mentési 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 megőrzési idő?

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 kiemelt jogosultságú 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 incidens idővonala hiányos maradhat.

6. Megkülönböztethető a megszokott és a rendellenes működés?

Már az is sokat segít, ha dokumentáltuk a megszokott működést:

• tipikus bejelentkezési helyek;
• megszokott rendszergazdai idősávok;
• normál szolgáltatáskapcsolatok;
• jellemző adatforgalmi irányok;
• rendszeres mentési és karbantartási 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 naplóexport, lemezkép vagy más technikai állomány 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ó incidenskezelési kontroll.

9. Ki lehet menteni a szükséges adatot?

Egy auditnapló 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ű asztali gyakorlat 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 napló- és bizonyítéknyilvántartás mezői lehetnek:

• rendszer neve;
• logforrás;
• felelős;
• elérési mód;
• megőrzési idő;
• időzóna / időszinkron;
• exportálási lehetőség;
• érzékenység;
• kapcsolódó incidenskezelési eljárás;
• utolsó validáció dátuma.

Ez nem bírósági bizonyítékkezelési (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ű felkészültségi 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:

1. hol jelenik meg;
2. mennyi idő után kereshető;
3. tartalmaz-e elég információt;
4. exportálható-e;
5. ugyanaz-e az időbélyeg logikája;
6. egy másik admin a dokumentáció alapján meg tudja-e ismételni.

A cél nem egy látványos műszerfal, hanem az, hogy incidens esetén ne akkor kelljen először kitalálni, honnan és hogyan gyűjthetők össze a szükséges bizonyítékok.

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