A végpontvédelmi ajánlatokban ugyanaz a három betűszó ismétlődik, a gyártói anyagokban pedig gyakran összefolynak. Az EDR és az XDR technológia: a szoftver gyűjti az adatot és hajtja végre a beavatkozást. Az MDR szolgáltatás: elemzők nézik a riasztásokat, és a megállapodás szerint lépnek.
A különbség a beszerzésnél válik fontossá. Aki terméket vesz, eszközt kap, a riasztásokkal a saját embereinek kell foglalkozniuk. Aki szolgáltatást vesz, annak előre el kell döntenie, mit tehet meg a szolgáltató az ő jóváhagyása nélkül. Az alábbiakban előbb a három fogalmat vesszük sorra, utána azt, hogyan oszlik meg a munka és a döntés.
EDR: észlelés és reagálás a végponton
Az EDR (Endpoint Detection and Response) egy végponti ügynökre és egy központi elemzőrendszerre épül; az ügynök a munkaállomáson és a szerveren fut. Folyamatosan rögzíti, mi történik a gépen: melyik folyamat indult és mi indította, milyen parancssori paraméterekkel, milyen fájlt írt, melyik beállítást módosította, hová nyitott hálózati kapcsolatot. Ez a telemetria a felügyeleti konzolba kerül, ahol szabályok és viselkedési modellek elemzik.
Az észlelés eseményláncokra épül. Egy irodai dokumentum parancsértelmezőt indít, az kódolt szkriptet futtat, a szkript pedig egy ismeretlen címre csatlakozik. Az egyes lépések önmagukban hétköznapiak, sorban egymás után már gyanúsak. A klasszikus vírusirtóval való összevetést az EDR kiválasztásáról szóló cikk részletezi.
Mit tud tenni a végponton
- Leállít egy folyamatot, és karanténba teszi a hozzá tartozó fájlt.
- Hálózati szempontból izolálja a gépet. Ilyenkor a gép csak a felügyeleti konzollal tartja a kapcsolatot, így vizsgálható marad, de a támadó nem tud róla továbblépni.
- Távoli vizsgálati munkamenetet nyit, amelyben az elemző fájlokat gyűjthet és parancsokat futtathat.
- Visszamenőleg keres a tárolt telemetriában, például egy frissen közzétett kompromittálódási indikátor alapján.
Az EDR azt látja, ami azon a gépen történik, amelyen az ügynöke fut. Ha a támadó egy ellopott jelszóval egy felhőszolgáltatásba lép be, vagy egy olyan eszközön mozog, amelyre ügynök nem telepíthető (hálózati eszköz, nyomtató, régi rendszer), a konzolban ebből semmi nem jelenik meg.
XDR: több forrás egy elemzésben
Az XDR (Extended Detection and Response) az EDR telemetriáját más forrásokkal együtt elemzi. Tipikus források az e-mail-szűrő, az identitásszolgáltató bejelentkezési naplója, a tűzfal és a felhős munkaterhelések. A cél, hogy a különböző helyeken megjelenő jelek egyetlen eseményként, közös idővonalon álljanak össze.
Egy egyszerűsített példa: beérkezik egy adathalász levél, a címzett gépén a melléklet megnyitása után gyanús folyamat indul, egy órával később pedig ugyanazzal a fiókkal szokatlan helyről lépnek be egy felhőalkalmazásba. Külön eszközökben ez három riasztás lenne három konzolban, és az elemzőn múlna, hogy összekapcsolja őket. Az XDR egyetlen incidensbe fűzi a hármat, amelyből látszik, hogy a fiók és a gép ugyanahhoz a támadáshoz tartozik, és mindkettőn lépni kell.
A piacon két megközelítés él. Az egyik a gyártó saját termékeinek adatait köti össze, ezt gyakran natív XDR-nek hívják. A másik külső gyártók forrásait is fogadja szabványos interfészeken keresztül, erre a nyitott XDR elnevezés terjedt el. A határ a valóságban nem éles, ezért érdemes konkrétan megkérdezni, mely források köthetők be, és azokból milyen részletességű adat érkezik.
Hol a SIEM helye
A SIEM általános naplógyűjtő és korrelációs rendszer: szinte bármilyen forrást fogad, hosszú ideig megőrzi az adatot, és a megfelelőségi jelentéseket is ebből szokás készíteni. Az XDR kevesebb forrással dolgozik, viszont előre kidolgozott észlelésekkel és beépített válaszlépésekkel. Sok szervezetnél mindkettő megvan, és az XDR incidensei a SIEM-be is továbbmennek. A SIEM bevezetésének lépéseiről külön cikk szól.
MDR: amikor a riasztásokat szolgáltató figyeli
Az EDR és az XDR riasztásokat termel, és valakinek ezeket éjjel-nappal át kell néznie. Egy kisebb informatikai csapat ezt ritkán tudja vállalni, mert ügyeleti rend, gyakorlott elemzők és a platform alapos ismerete kell hozzá. Az MDR (Managed Detection and Response) ezt a munkát adja szolgáltatásként.
Az MDR egy EDR- vagy XDR-platformra épül. Nyújthatja maga a platform gyártója, vagy egy független szolgáltató, amely egy vagy több gyártó platformján dolgozik. A szolgáltatás tartalma a szerződésben rögzített leíráson múlik, a következő elemekből szokott összeállni:
- folyamatos figyelés és a riasztások előszűrése, vagyis a téves riasztások kiszűrése;
- a valósnak tűnő esetek kivizsgálása: mi történt, melyik gép és fiók érintett, meddig jutott a támadó;
- fenyegetésvadászat, amikor az elemzők riasztás nélkül keresnek a telemetriában ismert támadási mintákra, például laterális mozgásra;
- a megállapodott válaszlépések végrehajtása, vagy értesítés, ha a lépés a szervezet jóváhagyását igényli;
- írásos jelentés az esetről és rendszeres összefoglaló.
Az ajánlatokban a „figyelés” szó sokféle tartalmat takarhat. Előfordul, hogy csak annyit jelent, hogy a szolgáltató e-mailben továbbítja a súlyos riasztásokat, a vizsgálat és a beavatkozás pedig a szervezetre marad.
Ki dönt az izolálásról éjjel kettőkor
Éjjel kettőkor az elemző azt látja, hogy egy fájlszerveren egy folyamat sorban átírja a megosztott mappák fájljait, ami titkosításra utal. A szerver izolálása megállíthatja a kárt, de a szerver addig elérhetetlen, amíg valaki fel nem oldja. Ha az elemzőnek előbb telefonon jóváhagyást kell kérnie, és a listán szereplő ügyeletes nem veszi fel, a titkosítás közben halad. Ha viszont a szolgáltató mindent magától izolálhat, egy téves riasztás miatt reggel egy fontos rendszer állhat.
Erre az előre rögzített felhatalmazás ad választ, eszközcsoportonként és lépésenként. Egy lehetséges felosztás:
| Eszközcsoport | Folyamat leállítása, karantén | Hálózati izolálás |
|---|---|---|
| Munkaállomások | A szolgáltató önállóan, utólagos értesítéssel | A szolgáltató önállóan, azonnali értesítéssel |
| Általános szerverek | A szolgáltató önállóan, azonnali értesítéssel | Megerősített, aktív támadásnál önállóan, egyébként jóváhagyással |
| Kritikus rendszerek (tartományvezérlő, vállalatirányítási rendszer, a termelést kiszolgáló szerverek) | Jóváhagyással | Jóváhagyással, és rögzítve, mi történik, ha a megadott időn belül senki nem érhető el |
A táblázat mellé kell egy elérhetőségi lánc nevekkel, telefonszámokkal és helyettesekkel, és valakinek tudnia kell, hogyan oldható fel az izolálás. Ha az XDR identitásforrást is lát, a fiók letiltása vagy a munkamenetek visszavonása külön sort kap, mert egy vezetői vagy szolgáltatásfiók letiltása más következménnyel jár, mint egy munkaállomás izolálása. A felhatalmazást érdemes egy gyakorlaton kipróbálni, mielőtt egy valódi éjszakán derül ki, hogy a lista egyik száma már nem él.
Mi marad a szervezet saját feladata
Az MDR-szerződés a figyelést és a beavatkozás egy részét adja át a szolgáltatónak. Az alábbi négy területen a szervezet saját munkája nélkül a szolgáltató sem tud jól dolgozni, és a felelősség is a szervezetnél marad.
A lefedettség
Az elemző csak azt a gépet látja, amelyen ügynök fut. Az új gépeknek telepítéskor be kell kerülniük, a leselejtezetteknek ki kell kerülniük, és vezetni kell azoknak a gépeknek a listáját, amelyekre ügynök nem tehető. Ezek védelméről, például hálózati elkülönítéséről a szervezetnek kell gondoskodnia.
Az üzleti környezet
A szolgáltató nem tudja magától, melyik szerver kritikus, melyik távoli adminisztrációs eszközt használja jogosan az informatikai csapat, és mikor van tervezett karbantartás. Ha ezeket nem kapja meg, vagy feleslegesen riaszt, vagy olyan kivételeket kér, amelyek mögé a támadó is elbújhat. A kivételeket a szervezet hagyja jóvá, és időnként átnézi.
Az incidens a végponton túl
Az izolálással egy incidens elején járunk. A helyreállítás mentésből, a jelszavak cseréje, a belső és külső kommunikáció és a vezetői döntések a szervezetre tartoznak, ahogy a hatósági bejelentés is. A NIS2-irányelv hatálya alá tartozó szervezeteknél a jelentős incidensek bejelentése akkor is a szervezet kötelezettsége, ha a figyelést kiszervezte. Hogy az első órákban mi a teendő, azt az incidens utáni első 24 óráról szóló cikk írja le.
A javaslatok végrehajtása
Az MDR-jelentések gyakran rámutatnak egy javítatlan sebezhetőségre, egy túl széles jogosultságra vagy egy kikapcsolt naplózásra. A javítás az üzemeltetés dolga. A javaslatokat érdemes felelőssel és határidővel a saját feladatkezelőbe felvenni, és a következő jelentésnél ellenőrizni, melyik készült el.
Mit érdemes tisztázni egy MDR-szerződésben
Az ajánlatok a szolgáltatás elnevezésében hasonlítanak, a részletekben viszont sokban eltérnek. Ezeket a kérdéseket érdemes írásban rendezni:
- Mit jelent a reakcióidő: a riasztástól az elemző első lépéséig, az értesítésig vagy a beavatkozásig mért időt, és mennyi ez súlyossági szintenként.
- A válaszlépések felhatalmazása eszközcsoportonként, az előző fejezet szerint, és hogyan lehet ezt később módosítani.
- Az értesítés módja és sorrendje: telefon, e-mail vagy jegy, kit hívnak először, és mi történik, ha senki nem érhető el.
- Mely források tartoznak bele: csak a végpontok, vagy az identitás, a levelezés és a felhős szolgáltatások is.
- A fenyegetésvadászat része-e a szolgáltatásnak, milyen rendszerességgel, és készül-e róla jelentés.
- Hol ér véget a vizsgálat. A részletes forenzikus elemzés és a helyreállítás sok szerződésben már külön megbízás, ezt jobb előre tudni.
- Az adatok: hol tárolják a telemetriát, mennyi ideig, ki fér hozzá, és mi lesz vele a szerződés végén. Mivel a telemetria személyes adatot is tartalmaz (felhasználónevek, megnyitott fájlok, böngészési nyomok), adatfeldolgozói szerződés is kell.
- A hangolás rendje: ki kérhet és ki hagyhat jóvá kivételt, és hogyan követhető vissza egy kivétel oka.
Kapcsolódó szolgáltatás: Végpontvédelem (EDR/XDR) →
