Sziasztok!
Van egy működő kereskedelmi SIEM rendszerünk, ami a hálózati forgalmat figyeli jelenleg, viszont nem gyűjti a kliensekről a naplókat. E mellé van egy vírusvédelmi rendszerünk is. E mellé szerintetek van értelme még egy SIEM rendszert (ez a Wazuh lenne) beüzemelni a felhasználók gépeit terhelni az agent-ével? Több felé próbáltam utána nézni, én nem találtam meggyőző érvet (inkább a mostani SIEM-nek kellene tárhelyet bővíteni és bővíteni a tárolandó adatok körét). Olyat is láttam, hogy egy log gyűjtő szerver összeszedi a naplókat és tárolja (NXlog-gal), és ezt elemzi a SIEM. Várom a javaslatokat!
- 540 megtekintés
Hozzászólások
Már a kérdés is elég sok problémát 'elárul', de lássuk:
Röviden: nincs, több SIEM-mel csak magadat (illetve a SOC csapatot) szivatod. És várhatóan az üzemeltetési kölségek is többszöröződnének...
Bővebben:
Attól függ, mi a jelenlegi, és mirt nem gyűjt naplókat?
Sőt: egyátalán nem gyűjt, vagy csak a kliensekről nem?
De az is fontos hány kliensről beszélünk, és mekkora (Event Per Sec /Flow Per Minute) SIEM-ről?
Kliensekről egyébként direktben nem is szokták ám gyűjteni, mert az nagyon drága móka...
és ugye a kliensek jellgükből adodóan nincsenek is mindig live kapcsolatban a SIEM-mel.
Tehát mindenképp kell valami buffer - azaz köztes loggyűjtés/elemzés/szűrés szokott lenni a megoldás.
És/Vagy: komolyabb helyeken lokális EDR fut a klienseken, aminek eleve van központi log gyűjtő megoldása, ahonnan csak a problémás 'eseteket' küldi a SIEM-nek.
szerk: én a kliensek alatt a desktopokat értettem, ha te a szervereket és a hálózati eszközöket is, akkor kicsit más a helyzet:
- Linux/Unix szerverek, és hálózati eszközök (általában) alapból tudnak remote syslog-ot, azoknál ez a bevett módszer.
- Windows-ok esetén a Microsoft saját log gyűjtő (WEC) megoldása, amire ugyan kell valamilyen agent, hogy eljusson végül a SIEM-re, de így nem kell minden serverre agent.
- A hozzászóláshoz be kell jelentkezni
A kliensek Windows-os munkaállomások (kb. 2000 darab), amiknek én a naplóállományait gyűjteném a hálózati sávszél eléggé változó, belól még megvan a Gbit, de több telephelyról kb 30-50-es gépparknál max. a 100Mbit felém. Én talán amit ezekről naplóznék, az néhány mappa (TEMP, Windows teljes, vagy részbeni struktúrája, user saját mappája), illetve szokatlan tevékenységek, illetve felhasználói ki- és bejelentkezések.
A mostani SIEM naplózza a hálózati tevékenységet. Egy log gyűjtó szervert gondoltam annak a buffernak (Oracle Linux alapú syslog szerver), amit írtál. EDR-t próbáltam feléleszteni (de sajnos ESXi-m nincs, a fizikai Dell vason meg nem volt hajlandó felállni rendesen (pedig CentOS-re volt telepítve az image-ben, a support meg nem tudott segíteni, mert nem támogatott platformra akartam felvarázsolni).
Windows log gyűjtésre NXlog-ra gondoltam (vagy az Edoceo winlogd-je).
- A hozzászóláshoz be kell jelentkezni
Én talán amit ezekről naplóznék, az néhány mappa (TEMP, Windows teljes, vagy részbeni struktúrája, user saját mappája
Háát, a naplózás nem egészen így működik :)
Windows-on vannak Security logok, Applikációs logok, ezeket 'szokás' gyűjteni. Ezeken belül lehet még severity-re szűrni, de: ha tovább megyünk, akkor már kell valami extra pl sysmon, ami audit szerű megoldást kínál, de az is fel kell tudni konfigurálni rendesen, hogy érjen valamit.
És akkor jöhet a számolgatás, hogy mindez mekkora EPS-t fog eredményezni.
2000 munkaállomásról ha csak a security eventeket gyűjtöd, az is lesz vagy 20K peak EPS. De ha audit eventeket is szeretnél (pl sysmon), akkor akár 200K is lehet! Ezt nem egyszerű (és főleg nem olcsó) sem 'bufferelni', de még gyűjteni sem. Ezért szokták csak az EDR, Defender filterezett és közponsotsított logjait gyűjteni, és nem direktben a kliensekről.
persze, ha ez (audit) kell, ezt is lehet, csak ahhoz már rendesen megtervezett gyűjtés kell, nem csak úgy puffneki küldjünk valamit a SIEM-be.
ilyenre az NXLog kiváló megoldás lehet, főleg ha már eleve használjátok.
illetve szokatlan tevékenységek
És azt ki dönti el, hogy mi a szokatlan??! - bármi is, azt már nevezhetjük EDR-nek ;)
- A hozzászóláshoz be kell jelentkezni
Ezt a puff neki hozzáállást nem érti meg a kolléga, hogy így nem lehet ... A másik, hogy jelenleg csak én követem a működő SIEM-ünk bejegyzéseit is, tehát csak azért, hogy ott neki legyen egy Dashboard, de igazából az Icinga-t sem figyelik, hogy melyik szerveren melyik szolgáltatás hasal el, vagy melyik szerver állt le, ez is felesleges (a Wazuh-t azért akarja, mert szerinte akkor nagyobb biztonságban leszónk, hamarabb kapunk értesítést az incidensekról, meg hogy az mihez kapcsolódó kontrollt takar), csinálok benne lekérdezéseket, stb. Ahhoz bele kell jobban ásni magát a Windows lelki világába, eldönteni, hogy mit akar és hogyan védeni. A mostani SIEM adatait nézve másodpercenként ennyi gépnál is iszonyatos mennyiségű információ esik be.
Az Symantec EDR-t meg nem bírtam életre kelteni, mint máshol írtam (ESXi hiányában sem Proxmox alatt, sem fizikai vasra téve).
Amíg a kliens gépek (nem vírusvédelemre gondolok, mert az van, de finomhangolva nincsenek a gépek), vagy az épületben lévő hálózat nincsenek megfelelően belülről védve, én először azzal foglalkoznék, mert jelentősen lehetne vala naplózandó eseményt és problémát csökkenteni ...
- A hozzászóláshoz be kell jelentkezni
eldönteni, hogy mit akar és hogyan védeni
Azt azért gondolom nem kell magyarázni, hogy a SIEM semmi ellen nem 'véd'. Ez 'csak' jelzi, ha már megtörtént a baj, vagy jobb esetben már azt is, ha gyanús tevékenység zajlik. A legfontosabb különbségek a nem működő és a jól működő SIEM-ek között:
- Egyátalán észreveszi/jelzi-e ha 'baj' van? :)
- Ha igen, milyen gyorsan jelez? Azonnal? órákkal később? vagy csak másnap?
- Mekkora a false false positive rate?
a gakorlatban sajnálatos módon a legtöbbször az van, hogy:
- megvesznek egy terméket,
- berőffentik a default rule-készlettel,
Persze kell 7x24-es ügyelet is mellé, ezért néhány szerencsétlen folyamatosan - jó esetben lelkesen - elemzi a jelzéseket, amik persze 99% false pozitívak, és nagyságrendekkel több van belőlük, mint amennyit elemezni tudnának. -> security theater.
Az egésznek így semmi értelme, de ezzel kipipálták a 'kötelezettségeket'... meg munkát adtak pár embernek, és termelik a GDP-t ;)
szerintem.
- A hozzászóláshoz be kell jelentkezni
ne értsd félre, és főleg ne vedd magadra, de a kérdéseidből egyértelműen az jön le, hogy nálatok egyátalán nincs értelmes IT security - de talán még lehet hogy üzemeltetés sem :(
Ha az a 2000 kliens valós szám, akkor itt eléggé nagy bajok vannak/lesznek. Egyekkora IT-val rendelkező cégnél ilyen kérdéseknek fel sem szabadna merülni... a random siem megoldások ad-hoc telepítése helett ilyen esetben egy átfogó - az egész IT-ra kiterjedő - megoldási terv kellene... És csak egy kockázatelemzés, egyetertés, majd döntéshozatal és felelősség vállalás után elkezdeni bármiféle 'beavatkozást'
szerintem.
- A hozzászóláshoz be kell jelentkezni
Az csak a hatalmas szerencse, h. ekkora szervezetlen szervezetben még nem szabadult el semmi ransomware eddig.
- A hozzászóláshoz be kell jelentkezni
Vagy nem tudnak róla. Esetleg nem írják ki nagy betűkkel a céges faliújságra (Linkedin, FB stb.).
- A hozzászóláshoz be kell jelentkezni
(ez a Wazuh lenne) beüzemelni a felhasználók gépeit terhelni az agent-ével?
Ez önmagában sem túl jó ötlet, az az agent az sajanos eléggé butácska.
Inventory management-nek, és/vagy compliance szempontból talán érdekes lehet - ha nincs jobb megoldás.
De a 'loggyűjtés' része az több sebből vérzik, látszik hogy csak toldozzák-foldozzák az elavult forkolt kódokat.
bővebben lásd:
Előnye, hogy ingyenes és open-source, de ez csak akkor előny, ha hajlandó vagy belefejleszteni ;)
legtöbben azonban csak ingyen akarnak Enterprise megoldást. De ez - jelen állapotában - biztosan nem az.
- A hozzászóláshoz be kell jelentkezni
Azt láttam, a másik témában, hogy nem egy zseni ...
Egyébként én az inventory management-nek a GLPI-t tenném be, mivel több rétűbb, jobban használható, mivel hardver és szoftver leltért is tudsz benne csinálni (arról nem is beszélve, hogy ticketing-re is haználható, meg sok minden másra). Eddig a hálózati nyomtatókról nem sikerólt sehogyan sem begyűjteni vele a számlálóállásokat, pedig az jó lenne.
Én sem érzem annak, de hadakozok a kollégával, mert szerinte jó (igaz még nem láttam tőle a teszt rendszerén épkézláb beállítást) ...
- A hozzászóláshoz be kell jelentkezni
Még az egy SIEM-nek se mindig látom a létjogosultságát. :) Mondjuk ha tárterület eladásban lenne érdekeltségem, akkor propagálnám, de nem ez a helyzet.
- A hozzászóláshoz be kell jelentkezni
Nagy céges hálózatnál pedig biztosan van (főleg több telephelynél, és mást már nem is írok ...). Az biztos, hogy a világ tárterúletét fel tudja használni. Főleg ha mondjuk egy illetéktelen használatból eredően visszamenőleg kellenének egy eszközről naplók mondjuk visszamenőleg x évre.
- A hozzászóláshoz be kell jelentkezni
Az, hogy bizonyos eseményekről visszamenőleg több évre kellenek logok (törvényi kötelezettség miatt), nem keverendő össze a SIEM-mel, az teljesen más eset. És jellemzően olyankor nem egy eszköz minden logja kell, hanem egy/több adott rendszer bizonyos típusú logjai. Ez pedig nem (csak) gyűjtési, hanem archiválási kérdés is. A SIEM tipikusan sok mindent gyűjt, nem annyira célzottan, és ebből az adathalmazból próbál kiemelni dolgokat (jellemzően előre megadott minták alapján), illetve korreláltatni több eszköz hasonló logjai alapján, ugyanakkor pont a tárterület miatt ezeket nem fogja évekig tárolni (nagy rendszereknél már egy negyedév tárolás is komoly kihívás tud lenni).
- A hozzászóláshoz be kell jelentkezni
Ha teszem azt, van egy rendőrsági megkeresés, hogy a cég egyik gépét használták a nyomozás szerint egy bűntény kapcsán akár évvel ezelőtt, akkor mondhatom azt, hogy ennyi időre visszamenőleg nem tárolok naplóállományokat (12 év alatt kétszer volt ilyen).
De ha mégis tárolni akarok bejelentkezési naplót, vagy hogy mit csináltak az adott gépen, milyen hálózati forgalma volt az eszköznek, milyen megoldás javasolt?
- A hozzászóláshoz be kell jelentkezni
Ilyen naplózáshoz a világ tárterülete és teljesítménye nem lenne elég. Nem is ír ilyesmit elő semmilyen törvény. A rendőrség ha megkeres ilyennel egy sima céget, akkor örülnek, ha tud adatot szolgáltatni, de nem kötelessége. Ráadásul ezt nem SIEM-mel, hanem netflow mentéssel tudod megoldani, normális esetben egy eszköz sem naplózza (ami a SIEM-be menne) ilyen részletességgel a hálózati forgalmát.
Évekkel ezelőtt kellett foglalkoznom egy kis helyi ISP-vel. A feladat az volt, hogy annak a törvényi kötelezettségnek meg kellene felelniük, miszerint ha valamelyik ügyfél csúnyaságot csinál, meg kell tudniuk mondani, ki volt az adott IP mögött (asszem 5 évig). Persze sima NAT mögött volt vagy 1000 ügyfél (nem egyetlen IP cím, mielőtt...), minden naplózás nélkül. Ebből nyilván nem lehet megmondani, ki volt. Ameddig kinyomoztam, hogy a meglévő eszközeiken miképp tudok nekik determinisztikus NAT-ot beállítani, addig üzembe állítottam egy "naplózó" szervert, ami a NAT-ot végző router-ekből jövő netflow-t tárolta. Erre az ezer ügyfélre havi 1 TB netflow adat keletkezett, átlagosan 600 Mbps forgalom mellett. Szóval a buxát nagyra kellene nyitni, ha ilyesmit szeretnél 10 éves viszonylatban kereshető formában tárolni egy komolyabb netes forgalmú cégnél.
Mondjuk ugyan ezt a megoldást (determinisztikus NAT) fel lehet használni forrás számítógép azonosítására, és akkor "csak" azt kell dokumentálni, hogy az adott időben melyik gépnek mi volt a belső IP címe (amit meg akár RADUS-szal meg lehet oldani, és akkor dinamikus is maradhat a címkiosztás, nem kell még csak DHCP oldalon sem rögzíteni a címeket), és ki-mikor-melyik gépen volt bejelentkezve. Ez meg a Windows naplóban megvan (AD esetén a DC-ken ráadásul, nem egyesével a gépeken). Ez jelentősen kevesebb adat tárolása, akár hosszú távon, mint a tényleges forgalom tárolása ilyen részletességgel.
- A hozzászóláshoz be kell jelentkezni
De ha mégis tárolni akarok bejelentkezési naplót,
eleve ilyet senki nem 'akar', de van aki kötelzve van rá ;) Ők sem 'akarják', de nekik kötelező ;)
És ennek az ég világon semmi köze a SIEM-hez, ez 'csak' központi log gyűjtés/archiválás kérdése.
Persze, minden SIEM alapja a központi log gyűjtés, de nem az archiválás! itt általában csak rövidebb időre vannak tárolva a begyűjtött logok.
Flow és/vagy hálózati forgalom pedig még egy nagyságrenddel kevesebb ideig.
pl: eventek/logok hónapokig, netflow: csak napokig. - ez egy átlagos SIEM 'retention policy'-ja.
persze egy QRadar-ban (aminek még storage tiering-je sincs) is lehet annyi tárhelyet összehozni, hogy évekig tudjál tárolni mindent is, csak azt nem akarod majd kifizetni sem hardver-ben, sem licence-ben! ;)
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni