Stacioni i punës së përdoruesit është pika më e cenueshme e infrastrukturës përsa i përket sigurisë së informacionit. Përdoruesit mund të marrin një letër në emailin e tyre të punës që duket se është nga një burim i sigurt, por me një lidhje në një sajt të infektuar. Ndoshta dikush do të shkarkojë një mjet të dobishëm për punë nga një vend i panjohur. Po, ju mund të gjeni dhjetëra raste se si malware mund të depërtojë në burimet e brendshme të korporatës përmes përdoruesve. Prandaj, stacionet e punës kërkojnë vëmendje të shtuar, dhe në këtë artikull ne do t'ju tregojmë se ku dhe çfarë ngjarjesh duhet të ndërmerrni për të monitoruar sulmet.
Për të zbuluar një sulm në fazën më të hershme të mundshme, Windows ka tre burime të dobishme të ngjarjeve: Ditari i ngjarjeve të sigurisë, Regjistri i monitorimit të sistemit dhe regjistrat e predhave të energjisë.
Regjistri i ngjarjeve të sigurisë
Ky është vendndodhja kryesore e ruajtjes për regjistrat e sigurisë së sistemit. Kjo përfshin ngjarjet e hyrjes/daljes së përdoruesit, aksesin në objekte, ndryshimet e politikave dhe aktivitete të tjera të lidhura me sigurinë. Sigurisht, nëse konfigurohet politika e duhur.
Numërimi i përdoruesve dhe grupeve (ngjarjet 4798 dhe 4799). Në fillim të një sulmi, malware shpesh kërkon përmes llogarive lokale të përdoruesve dhe grupeve lokale në një stacion pune për të gjetur kredencialet për marrëdhëniet e tij të dyshimta. Këto ngjarje do të ndihmojnë në zbulimin e kodit keqdashës përpara se ai të vazhdojë dhe, duke përdorur të dhënat e mbledhura, të përhapet në sisteme të tjera.
Krijimi i një llogarie lokale dhe ndryshimet në grupet lokale (ngjarjet 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 dhe 5377). Sulmi gjithashtu mund të fillojë, për shembull, duke shtuar një përdorues të ri në grupin e administratorëve lokalë.
Përpjekjet për hyrje me një llogari lokale (ngjarja 4624). Përdoruesit e respektuar hyjnë me një llogari domeni dhe identifikimi i një hyrjeje nën një llogari lokale mund të nënkuptojë fillimin e një sulmi. Ngjarja 4624 përfshin gjithashtu hyrje nën një llogari domeni, kështu që kur përpunoni ngjarje, duhet të filtroni ngjarjet ku domeni është i ndryshëm nga emri i stacionit të punës.
Një përpjekje për t'u identifikuar me llogarinë e specifikuar (ngjarja 4648). Kjo ndodh kur procesi po ekzekutohet në modalitetin "run as". Kjo nuk duhet të ndodhë gjatë funksionimit normal të sistemeve, kështu që ngjarje të tilla duhet të kontrollohen.
Bllokimi/zhbllokimi i stacionit të punës (ngjarjet 4800-4803). Kategoria e ngjarjeve të dyshimta përfshin çdo veprim që ka ndodhur në një stacion pune të mbyllur.
Ndryshimet e konfigurimit të murit të zjarrit (ngjarjet 4944-4958). Natyrisht, kur instaloni softuer të ri, cilësimet e konfigurimit të murit të zjarrit mund të ndryshojnë, gjë që do të shkaktojë rezultate false. Në shumicën e rasteve, nuk ka nevojë të kontrolloni ndryshime të tilla, por definitivisht nuk do të dëmtojë të dini rreth tyre.
Lidhja e pajisjeve Plug'n'play (ngjarja 6416 dhe vetëm për Windows 10). Është e rëndësishme t'i kushtoni vëmendje kësaj nëse përdoruesit zakonisht nuk lidhin pajisje të reja me stacionin e punës, por pastaj befas e bëjnë.
Windows përfshin 9 kategori auditimi dhe 50 nënkategori për rregullim të imët. Grupi minimal i nënkategorive që duhet të aktivizohen në cilësimet:
Identifikimi / Shkëputja
- Logon;
- Logoff;
- Mbyllja e llogarisë;
- Ngjarje të tjera Logon/Logoff.
Menaxhimi i llogarisë
- Menaxhimi i llogarisë së përdoruesit;
- Menaxhimi i Grupit të Sigurisë.
Ndryshimi i politikës
- Ndryshimi i Politikës së Auditimit;
- Ndryshimi i Politikës së Autentifikimit;
- Ndryshimi i politikës së autorizimit.
Monitorimi i sistemit (Sysmon)
Sysmon është një mjet i integruar në Windows që mund të regjistrojë ngjarje në regjistrin e sistemit. Zakonisht duhet ta instaloni veçmas.
Të njëjtat ngjarje, në parim, mund të gjenden në regjistrin e sigurisë (duke aktivizuar politikën e dëshiruar të auditimit), por Sysmon ofron më shumë detaje. Cilat ngjarje mund të merren nga Sysmon?
Procesi i krijimit (ID 1 i ngjarjes). Regjistri i ngjarjeve të sigurisë së sistemit mund t'ju tregojë gjithashtu kur filloi një *.exe dhe madje të tregojë emrin dhe rrugën e nisjes. Por ndryshe nga Sysmon, ai nuk do të jetë në gjendje të tregojë hash-in e aplikacionit. Softueri me qëllim të keq mund të quhet edhe notepad.exe i padëmshëm, por është hash-i që do ta nxjerrë atë në dritë.
Lidhjet e rrjetit (ID-ja e ngjarjes 3). Natyrisht, ka shumë lidhje rrjeti dhe është e pamundur të mbash gjurmët e të gjithave. Por është e rëndësishme të kihet parasysh se Sysmon, ndryshe nga Regjistri i Sigurisë, mund të lidhë një lidhje rrjeti me fushat ProcessID dhe ProcessGUID dhe tregon portin dhe adresat IP të burimit dhe destinacionit.
Ndryshimet në regjistrin e sistemit (ID-ja e ngjarjes 12-14). Mënyra më e lehtë për të shtuar veten në autorun është të regjistroheni në regjistër. Regjistri i Sigurisë mund ta bëjë këtë, por Sysmon tregon se kush i bëri ndryshimet, kur, nga ku, ID e procesit dhe vlerën e mëparshme të çelësit.
Krijimi i skedarit (ID-ja e ngjarjes 11). Sysmon, ndryshe nga Regjistri i Sigurisë, do të tregojë jo vetëm vendndodhjen e skedarit, por edhe emrin e tij. Është e qartë se nuk mund të mbani gjurmët e gjithçkaje, por mund të kontrolloni disa drejtori.
Dhe tani ajo që nuk është në politikat e Regjistrit të Sigurisë, por është në Sysmon:
Ndryshimi i kohës së krijimit të skedarit (ID 2 i ngjarjes). Disa malware mund të mashtrojnë datën e krijimit të një skedari për ta fshehur atë nga raportet e skedarëve të krijuar së fundi.
Ngarkimi i drejtuesve dhe bibliotekave dinamike (ID-të e ngjarjeve 6-7). Monitorimi i ngarkimit të DLL-ve dhe drejtuesve të pajisjes në memorie, kontrollimi i nënshkrimit dixhital dhe vlefshmërisë së tij.
Krijo një thread në një proces që po funksionon (ID 8 i ngjarjes). Një lloj sulmi që gjithashtu duhet të monitorohet.
Ngjarjet RawAccessRead (ID-ja e ngjarjes 9). Operacionet e leximit të diskut duke përdorur ".". Në shumicën dërrmuese të rasteve, një aktivitet i tillë duhet të konsiderohet jonormal.
Krijo një transmetim skedari me emër (ID-ja e ngjarjes 15). Një ngjarje regjistrohet kur krijohet një transmetim skedari me emër që lëshon ngjarje me një hash të përmbajtjes së skedarit.
Krijimi i një tubi dhe lidhjeje me emër (ID-ja e ngjarjes 17-18). Ndjekja e kodit me qëllim të keq që komunikon me komponentë të tjerë përmes tubit të emërtuar.
Aktiviteti WMI (ID 19 i ngjarjes). Regjistrimi i ngjarjeve që krijohen kur hyni në sistem nëpërmjet protokollit WMI.
Për të mbrojtur vetë Sysmon, duhet të monitoroni ngjarjet me ID 4 (Sysmon ndalon dhe fillon) dhe ID 16 (ndryshimet e konfigurimit të Sysmon).
Regjistrat e Power Shell
Power Shell është një mjet i fuqishëm për menaxhimin e infrastrukturës së Windows, kështu që shanset janë të larta që një sulmues ta zgjedhë atë. Ekzistojnë dy burime që mund të përdorni për të marrë të dhënat e ngjarjeve të Power Shell: regjistri i Windows PowerShell dhe regjistri i Microsoft-WindowsPowerShell/Operational.
Regjistri i Windows PowerShell
Ofruesi i të dhënave është ngarkuar (ID-ja e ngjarjes 600). Ofruesit e PowerShell janë programe që ofrojnë një burim të dhënash që PowerShell të shikojë dhe menaxhojë. Për shembull, ofruesit e integruar mund të jenë variablat e mjedisit të Windows ose regjistri i sistemit. Shfaqja e furnitorëve të rinj duhet të monitorohet në mënyrë që të zbulohet në kohë aktiviteti keqdashës. Për shembull, nëse shihni WSMan që shfaqet midis ofruesve, atëherë ka filluar një sesion i largët i PowerShell.
Microsoft-WindowsPowerShell / Regjistri operacional (ose MicrosoftWindows-PowerShellCore / Operational në PowerShell 6)
Regjistrimi i modulit (ID-ja e ngjarjes 4103). Ngjarjet ruajnë informacione për secilën komandë të ekzekutuar dhe parametrat me të cilët është thirrur.
Regjistrimi i bllokimit të skriptit (ID-ja e ngjarjes 4104). Regjistrimi i bllokimit të skriptit tregon çdo bllok të kodit PowerShell të ekzekutuar. Edhe nëse një sulmues përpiqet të fshehë komandën, ky lloj i ngjarjes do të tregojë komandën PowerShell që është ekzekutuar në të vërtetë. Ky lloj ngjarje mund të regjistrojë gjithashtu disa thirrje API të nivelit të ulët që po kryhen, këto ngjarje zakonisht regjistrohen si Verbose, por nëse një komandë ose skrip i dyshimtë përdoret në një bllok kodi, ai do të regjistrohet si një ashpërsi paralajmëruese.
Ju lutemi vini re se pasi mjeti të konfigurohet për të mbledhur dhe analizuar këto ngjarje, do të kërkohet kohë shtesë e korrigjimit për të reduktuar numrin e pozitivëve të rremë.
Na tregoni në komente se çfarë regjistrash mbledhni për kontrollet e sigurisë së informacionit dhe cilat mjete përdorni për këtë. Një nga fushat tona të fokusit janë zgjidhjet për auditimin e ngjarjeve të sigurisë së informacionit. Për të zgjidhur problemin e mbledhjes dhe analizimit të regjistrave, ne mund të sugjerojmë t'i hedhim një vështrim më të afërt , i cili mund të kompresojë të dhënat e ruajtura me një raport 20:1 dhe një shembull i instaluar i tij është i aftë të përpunojë deri në 60000 ngjarje në sekondë nga 10000 burime.
Burimi: www.habr.com