Hálózati Operációs Rendszerek

1. Hálózati Operációs Rendszerek SIEM rendszerek 1

2. Tartalom • Bevezetés a SIEM rendszerekbe azok általános bemutatása • Tivoli Security Information And Event Manager • A szoftver célja (Naplózásból származó adatok össze gyűjtése és elemzése) • Működése • Előnyei és hátrányai • OSSIM 2

3. Bevezetés a SIEM rendszerekbe, azok általános bemutatása • Mit is jelent maga a rövidítés SIEM?SIEM (Security Information And Event Manager) egy olyan rendszert értünk, aminek a célja a szoftverek és hardver eszközök által generált riasztások, figyelmeztetések naplózása és analízise, valós időben. A szakirodalomban megjelenik a SIM (Security Information Manager) és SEM (Security Event Manager) rövidítések is, amiket össze szoktak keverni a SIEM-mel, mivel hasonló célokra használják ezeket is (a SIEM gyakorlatilag a két szoftver típus ötvözése, gyakorlatban nem is szokták külön-külön alkalmazni már őket). • A SIEM és hozzá hasonló rendszerek célja gyakorlatilag, hogy a hardver eszközöktől és szoftverekből jövő naplókat (eseményeket) központilag tárolják el és elemezzék ki azokat, ezáltal biztosítva azt, hogy a biztonságot veszélyeztető események, tevékenységek felfedezésre derülnek (illetve kiderüljön az, ha betörnek a rendszerünkbe). • A SIEM rendszerek gyakorlatilag biztonsági monitorozást valósítanak meg, amihez társul még részben a kockázat elemzés és a rendszer megbízhatóságának növelése. 3

4. Mi a motiváció? Miért van szükség SIEM rendszerekre? • Nyílván ha egy otthoni kis hálózatra gondolunk, illetve egy kis vállalkozás rendszerére (kevesebb mint 10-15 eszközt tartalmaz), ott nincs igazán szükség folyamatos valós idejű esemény analízisre (nyilván biztonságra mindenhol szükség van, viszont a költségeket tekintve valahol meg kell húzni a határt és egy SIEM rendszer kiépítése és üzemeltetése nem tartozik a legolcsóbb költségek közé). Itt általában néha beleszoktak nézni a napló fájlokba manuálisan, illetve egyszerűbb rendszerekkel szokás a biztonságot fen tartani. • Viszont ha már egy közép vagy nagy vállalati rendszerben gondolkodunk, ahol a rendszer mondjuk tartalmaz 50-100 (vagy még több) kliens gépet, továbbá különböző szolgáltatásokat nyújtó szervereket (gondoljunk például egyszerűen egy apache szerverre, ami mondjuk naponta 10 ezer embert szolgál ki), nagy földrajzi távolságokat ível át, különböző heterogén rendszerek összekapcsolásával stb....... hát ott már igen kevés rá az esély, hogy majd a rendszer adminisztrátorok manuálisan végig nézik minden egyes alrendszer napló fájlját, anomáliák és betörések után kutatva. Itt bizony már szükség van SIEM rendszerek alkalmazására. 4

5. SIEM főbb funkciói • Log consolidation, Log management • Log normalization • Correlation • Incident Management • Reporting • Asset management 5

6. Log consolidation, Log management • A log consolidation arról szól, hogy a különböző forrásból jövő napló fájlokat, eseményeket egy vagy több központi helyen tároljuk le. • Fontos követelmények az adatok tárolásával kapcsolatban: • Le legyen tárolva az eredeti formázatlan log is • Le legyen tárolva a normalizált log • Hatékonyan és gyorsan lehessen keresni adatokat nagy log mennyiségek tárolása esetén is • Lehessen a tárolót klaszterezni, külön üzemeltetni a SIEM többi részétől. • A gyakorlatban általában ezt relációs adatbázisok segítségével oldják meg. 6

7. Log normalization • A fogadott adatok feldolgozásának első lépése bármely SIEM rendszerben. • Normalizáció = A fogadott „nyers” napló adatok és események köztes, a rendszer által használt formába ültetése. Elsőre egyszerűnek hangzik, éppen ezért nézünk meg pár Log formátumot! 7

8. Log normalization – Window event log 8

9. Log normalization – Apache access.log fájlból 127.0.0.1 - - [10/Apr/2007:10:39:11 +0300] "GET / HTTP/1.1" 500 606 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:39:11 +0300] "GET /favicon.ico HTTP/1.1" 200 766 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 139.12.0.2 - - [10/Apr/2007:10:40:54 +0300] "GET / HTTP/1.1" 500 612 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 139.12.0.2 - - [10/Apr/2007:10:40:54 +0300] "GET /favicon.ico HTTP/1.1" 200 766 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:53:10 +0300] "GET / HTTP/1.1" 500 612 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:54:08 +0300] "GET / HTTP/1.0" 200 3700 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:54:08 +0300] "GET /style.css HTTP/1.1" 200 614 "http://pti.local/" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:54:08 +0300] "GET /img/pti-round.jpg HTTP/1.1" 200 17524 "http://pti.local/" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:54:21 +0300] "GET /unix_sysadmin.html HTTP/1.1" 200 3880 "http://pti.local/" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:54:51 +0300] "GET / HTTP/1.1" 200 34 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:54:51 +0300] "GET /favicon.ico HTTP/1.1" 200 11514 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:54:53 +0300] "GET /cgi/pti.pl HTTP/1.1" 500 617 "http:/contact.local/" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 127.0.0.1 - - [10/Apr/2007:10:54:08 +0300] "GET / HTTP/0.9" 200 3700 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:58:27 +0300] "GET / HTTP/1.1" 200 3700 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:58:34 +0300] "GET /unix_sysadmin.html HTTP/1.1" 200 3880 "http://pti.local/" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 217.0.22.3 - - [10/Apr/2007:10:58:45 +0300] "GET /talks/Fundamentals/read-excel-file.html HTTP/1.1" 404 311 "http://pti.local/unix_sysadmin.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)" 9

10. Log normalization – Syslog Aug 18 10:23:57 server1 syslog: [0]:Monitor process [389288] has started Aug 18 10:23:57 server1 radiusd[389288]: [0]:Local database (AVL) built. Aug 18 10:23:57 server1 radiusd[389288]: [0]:Authentication process started : Pid= 549082 Port = 1812 Aug 18 10:23:57 server1 radiusd[389288]: [0]:Accounting process started : Pid= 643188 Port = 1813 Aug 18 10:23:57 server1 radiusd[643188]: [0]:Socket created [15] Aug 18 10:23:57 server1 radiusd[643188]: [0]:Bound Accounting socket [15] Aug 18 10:23:57 server1 radiusd[549082]: [0]:Socket created [15] Aug 18 10:23:57 server1 radiusd[549082]: [0]:Bound Authentication socket [15] Aug 18 10:24:07 server1 radiusd[643188]: [1]:*** Start Process_Packet() *** Aug 18 10:24:07 server1 radiusd[643188]: [1]:Code 4, ID = 96, Port = 41639 Host = 10.10.10.10 Aug 18 10:24:07 server1 radiusd[643188]: [1]:ACCOUNTING-START - sending Accounting Ack to User [ user_id1 ] Aug 18 10:24:07 server1 radiusd[643188]: [1]:Sending Accounting Ack of id 96 to 10.10.10.10 (client1.ibm.com) Aug 18 10:24:07 server1 radiusd[643188]: [1]:send_acct_reply() Outgoing Packet: Aug 18 10:24:07 server1 radiusd[643188]: [1]: Code = 5, Id = 96, Length = 20 Aug 18 10:24:07 server1 radiusd[643188]: [1]:*** Leave Process_Packet() *** Aug 18 10:24:13 server1 radiusd[643188]: [2]:*** Start Process_Packet() *** Aug 18 10:24:13 server1 radiusd[643188]: [2]:Code 4, ID = 97, Port = 41639 Host = 10.10.10.10 Aug 18 10:24:13 server1 radiusd[643188]: [2]:ACCOUNTING-STOP - sending Accounting Ack to User [ user_id1 ] Aug 18 10:24:14 server1 radiusd[643188]: [2]:Sending Accounting Ack of id 97 to 10.10.10.10 (client1.ibm.com) Aug 18 10:24:14 server1 radiusd[643188]: [2]:send_acct_reply() Outgoing Packet: Aug 18 10:24:14 server1 radiusd[643188]: [2]: Code = 5, Id = 97, Length = 20 Aug 18 10:24:14 server1 radiusd[643188]: [2]:*** Leave Process_Packet() **

11. Log normalization • És a példákon kívül még sok más log formátumról beszélhetnénk (log a4j-re gondoljunk csak, és egyéb szabványokra, ahol a formátum is variálható tetszés szerint). És akkor még nem beszéltünk egyedi alkalmazásokról egyedi logokkal! (Bár manapság már ilyen kevés van). • Minden jó SIEM rendszer támogat minden ismertebb napló formátumot, továbbá vagy konfiguráción keresztül, vagy programozható API-val támogatja további napló adatok feldolgozását. • Következő probléma itt még: Mi az amit kiemeljünk a naplókból/eseményekből és mi az, ami már haszontalan adat számunkra? • Ha túl kevés adat jön be lehet nem detektáljuk a biztonsági incidenst, ha túl sok, akkor meg sok idő, amíg a rendszer feldolgozza az eseményeket. • Általánosan 7 értéket „dimenziót” szoktak eltárolni 11

12. Log normalization – 7 dimenzió • WHEN - Mikor történt az esemény • WHO – Ki az aki az eseményt kiváltotta • WHAT – Mi az esemény (mit csinál?) • WHERE – Melyik eszközön, gépen történt az esemény • ON WHAT – Megadja, hogy melyik gépen, fájlon, stb. történt az esemény • WHERE FROM – Honnan került kiváltásra az esemény • WHERE TO – Hová ment az esemény 12

13. Correlation • A SIEM feldolgozás folyamatának következő lépcső foka. • Megvannak a normalizált eseményeink. Ez azonban gyakran nem elég! • Például:Egy belső támadás történt a rendszerben egy ismeretlen felhasználói névvel. Ekkor fontos lehet megtudni, hol járt még ez a felhasználó a rendszerben, kihozta létre és így tovább.. • Ez csak úgy tehető meg, ha az összefüggő eseményeket összekapcsoljuk, illetve tudjuk azt, hogy mely események kapcsolódnak össze. Ez a korreláció. • A korreláció bonyolult statisztikai és mesterséges intelligenciai algoritmusok segítségével jön létre. 13

14. Incident Management • Incident management esetén gyakorlatilag arról beszélünk, hogy mi történjen, amikor a rendszer egy behatolást észlel, illetve hogy szabjuk testre, hogy mi számít behatolásnak és mi nem. • Minden SIEM támogatja policyk létre hozását, amik segítségével lehetőség van arra, hogy testre szabhassunk az alapvető biztonsági riasztásokat és újakat hozhassunk létre. Itt általában lehetőség an prioritás megadására is. • Ezenkívül lehetőség van beállítani, hogy milyen közegeken történjen riasztás egy-egy incidensnél: e-mailben, sms-ben, stb. • Fontos a szabályok pontos letisztázása egy SIEM rendszer kiépítésekor! • http://www.sans.org/reading_room/whitepapers/auditing/successful-siem-log-management-strategies-audit-compliance_33528 14

15. Reporting • Minden jó SIEM rendszerben lehetőség van arra, hogy különféle jelentéseket készítsünk. Ezek lehetnek különböző gyakoriságúak. • A jelentések általában a bekövetkezett apróbb incidensekről szólnak, amiknek nem tulajdonítunk olyan nagy jelentőséget. • Például egy hónapon belül a hibás bejelentkezések száma stb. • Itt is beszélhetünk automatizált jelentés készítésről, kiküldésről és saját jelentések készítéséről – ezek megléte rendszerről, rendszerre változik. 15

16. Asset Management • Asset management kapcsán a rendszerünkben lévő gépek és hálózatok nyilvántartásáról van szó. • Ez általában minden SIEM rendszerben benne van, hiszem a SIEM kliens programokat managelni kell. 16

17. Tivoli Security Information And Event Manager céljai és funkciói • A szoftver fő célja a számítógépes rendszerek monitorozása és ellenőrzése üzleti és biztonsági szempontból • Lehetőség van az üzleti környezetnek megfelelő biztonsági házirend bevitelére és alkalmazására (ezáltal történik a rendszer ellenőrzése is) • Kritikus eseményekről jelentések készítése, szükség esetén riasztások kiküldése • http://www-01.ibm.com/software/tivoli/products/security-info-event-mgr/ 17

18. Tivoli Security Information And Event Manager általános működése 18

19. Tivoli Security Information And Event Manager általános működése 19

20. Tivoli Security Information And Event Manager általános működése 20

21. Tivoli Security Information And Event Manager általános működése • A szoftver begyűjti különböző hálózati eszközök, operációs rendszerek és alkalmazások napló fájljait, ezek alapján történik a rendszer eseményeinek feldolgozása. Az adatbegyűjtés folyamata: • A rendszer gépein egy ügynök program fut, aminek feladata, hogy a beállított esemény és felhasználói források alapján információt nyerjen ki a rendszerből • Az ügynökökkel a kapcsolatot egy standard vagy egy enterprise TSIEM szerver tartja a kapcsolatot. A kommunikáció titkosítva történik az ügynökök és a szerverek között • A szerver eltárolja az ügynöktől fogadott adatokat egy DB2 adatbázisba, majd ezeket az információkat normalizálja 7 dimenzió szerint: • WHEN - Mikor történt az esemény • WHO – Ki az aki az eseményt kiváltotta • WHAT – Mi az esemény (mit csinál?) • WHERE – Melyik eszközön, gépen történt az esemény • ON WHAT – Megadja, hogy melyik gépen, fájlon, stb. történt az esemény • WHERE FROM – Honnan került kiváltásra az esemény • WHERE TO – Hová ment az esemény • A normalizált eseményekhez írt házirendet illeszti az adatokra a szerver, szükség esetén riasztásokat generál és küld ki • Lehetőség van jelentések generálására és megtekintésére 21

22. Tivoli Security Information And Event Manager előnyei és hátrányai • Az eseménynormalizálásnak köszönhetően képes a rendszer máshonnan észlelt adatok összekapcsolására • Riasztások és jelentések automatizálása (leveszi a rendszeradminisztrátorok válláról a terhet, nem kell állandóan figyelni a szoftvert) • Lehetőség van több hónapra visszamenőleg kielemezni az adatokat (rendszerbővítéskor hasznos tud lenni) • Nagy erőforrás igényű – az események normalizálása és házirendek vizsgálata időigényes és sok erőforrást igényel • Nem lehetséges valósidejű megfigyelés és elemzés • Előre meghatározott felhasználói és esemény források – nincs lehetőség bővíteni, saját eseményforrásokat fejleszteni 22

23. OSSIM • OSSIM = Open Source SIEM • http://communities.alienvault.com/community/ • Van egy PRO változata is, ez már nem ingyenes. • Az egész OSSIM egy nyílt forrású szoftverekből felépülő megoldás (tartalmaz SNORT-ot, MYSQL-t használ, stb.) • Hasonlóan mint TSIEM esetén lehetőség van klaszterezni. • Nehezebb konfigurálni (sok heterogén konfigurációs feladat) • Nem annyira eszi meg viszont az erőforrásokat, és valós időben elemzi ki az adatokat! • Egy iso-val tölthető le, ami gyakorlatilag tartalmaz egy Ubuntu alapú saját operációs rendszert, aminek segítségével feltelepíthető maga a operációs rendszer és a szoftver is. 23

24. OSSIM • Csak Linux platformon fut. • Lehetőség van a korrelációt konfigurálni. • Dokumentáció nagyon hiányos! 24

25. Források, további hasznos linkek a témával kapcsolatban • http://en.wikipedia.org/wiki/Security_information_and_event_management • http://en.wikipedia.org/wiki/Security_event_manager • http://en.wikipedia.org/wiki/Security_information_management • http://www.sans.org/reading_room/ 25