Univerzita Hradec Králové Fakulta informatiky a managementu

Diplomová práce
Vedoucí práce: Mgr. Josef Horálek Ph.D.
Odborný konzultant: Ing. Lukáš Vízner, Autocont a.s.
Hradec Králové Záí 2018
Prohlášení:
Prohlašuji, e jsem diplomovou práci zpracoval samostatn a s pouitím uvedené
literatury.
Podkování:
Dkuji vedoucímu diplomové práce Mgr. Josef Horálek Ph.D. za metodické
vedení práce a Ing. Lukáš Vízner za cenné rady pi implementaci.
Anotace
Nebezpeí krádee a zneuití informací je v dnešní dob bnou záleitostí, o to
více to platí pro kybernetické prostedí. V pípad, e organizace vlastní a
pouívá software jako je IDS nebo komplexnjší SIEM monitorující aktivitu a s ní
spojené hrozby, které picházejí z vení, a snaí se proniknout do infrastruktury,
mohlo by se zdát, e má takka vyhráno. V dnešním svt je stejn tak kritické
nasazení software monitorující aktivitu uvnit sít. Predikce a analýza lidského
chování je ale velmi obtíná a z toho pramení i znaná problematika pro zvolení
optimálních nástroj. Jedním z úinných nástroj pro tyto úely je modul
uivatelské behaviorální analýzy, který je nadstavbovým produktem pro nkteré
z nabízených SIEM systém. Díky uití strojového uení je schopen se stále uit
a snáze odhadnout zmny nebo problémy v infrastruktue.
Tato diplomová práce má jako hlavní cíl pedstavení princip a moností uití
uivatelské behaviorální analýzy v systémech SIEM. První kapitola je vnována
bezpenosti, standardm ISO a vymezení legislativního rámce R pro tuto
problematiku. Druhá kapitola pojednává o detailním definování systém SIEM,
jejich funkcionalit a logické stavb. Tetí kapitola pibliuje konkrétní SIEM
aplikace, které jsou zkoumány v praktické ástí práce – IBM Security QRadar
SIEM a AlienVault OSSIM/ USM. Kapitola tvrtá obsahuje komparaci obou
zvolených SIEM aplikací. Pátá kapitola pibliuje principy uivatelské
behaviorální analýzy a strojového uení. Kapitola šestá pedstavuje konkrétní
implementace SIEM a s tím spojené UBA moduly. Kapitola sedmá se vnuje
shrnutí poznatk práce. Závrená práce je vnována doporuení a celkovým
závrm.
Annotation
Title: User behavior analytics in the SIEM systems
In today’s society, the potential for theft or misuse of an organization’s precious information is a constant threat that increases exponentially in the cyber world. Some organizations are already using software such as IDS or the more complex SIEM, monitoring activity and threats coming from the outside of the infrastructure. Unfortunately, under the current circumstances this is simply not enough. Developing the software’s ability to predict and analyze the behavior in the infrastructure is just as important as monitoring incoming traffic. For prediction and analysis, there are several applications able to identify possible threats. I’ve chosen the module for user behavioral analysis which is integrated for some of the available SIEM systems. This module is able to use machine learning principles in order to deliver the sharpest predictions for the user’s behavior and communication within the intranet and is constantly learning new behavioral patterns as the user changes. The purpose of this master’s thesis is to introduce the principles of user behavioral analysis and its uses. The first chapter explains the whole security content valid for the context of security information as well as the “Law of cyber security.” The second chapter acts as a deep scope into the functionality of the SIEM systems and the logical syntax it has. The third chapter describes the concrete SIEM applications, which are lately used for the purposes of implementation of UBA. The fourth chapter delves into comparing the IBM Security QRadar SIEM and AlienVault OSSIM/ USM. The fifth chapter defines the principles of user behavior analysis, and machine learning. The sixth chapter introduces the implementation of the SIEM, its UBA modules and presents both defined and custom use cases. The seventh chapter serves as a summary of the first six chapters. The final chapter is dedicated to the recommendations
Obsah
2.2.2 ISO 27001 (Information security management systems) .......................... 9
2.2.3 ISO/IEC 27002 (Information technology and security techniques) ....12
2.2.4 ISO/IEC 27003 (Information security management systém and implementation guidance) ...................................................................................................13
2.2.5 ISO/IEC 27004 Measurement .............................................................................13
3 Security Information and Event management ..............................................................18
3.1 Log management ..............................................................................................................19
3.4.5 Log storage .................................................................................................................25
4.1 Architektura IBM Security QRadar SIEM ................................................................28
5 AlienVault OSSIM ......................................................................................................................31
6.1.1 QRadar .........................................................................................................................35
6.1.2 AlienVault ...................................................................................................................37
7 Uivatelská behaviorální analýza .......................................................................................41
8.1.2 Princip kolekce dat o uivatelích v UBA QRadaru ......................................48
8.1.3 Instalace AlienVault OSSIM ..................................................................................54
8.2 Uití modulu uivatelské behaviorální analýzy na vestavném Use case ..57
8.2.1 Vlastní Use case – login failure ...........................................................................64
8.2.2 Vlastní Use Case – uivatelská zmna na serveru .......................................66
9 Zhodnocení praktické ásti (shrnutí výsledk) ............................................................70
10 Závry a doporuení ...............................................................................................................71
11 Seznam pouité literatury .....................................................................................................73
Obrázek 1 - Maslowova pyramida poteb, pevzato (Salado & Nilchiani, 2013) ........ 3
Obrázek 2 - Pehled ISO 27k family, pevzato a upraveno (ISO/IEC 27001, 2018) .. 9
Obrázek 3 -PDCA cyklus pro ISMS, pevzato a upraveno (ISO/IEC 27001, 2018) ...10
Obrázek 4 - Blokové schéma, pevzato (NÚKIB, 2018) ......................................................15
Obrázek 5 - Architektura SIEM, pevzato a upraveno (Miller, 2011) ............................18
Obrázek 6- Proces zpracování událostí v SIEM, pevzato a upraveno (Miller, 2011) ...................................................................................................................................................................21
Obrázek 7 - Podoba raw logu generovaného zdrojovým zaízením, vlastní
zpracování ............................................................................................................................................22
2011) ......................................................................................................................................................25
Obrázek 10 - QRadar architektura, pevzato a upraveno (IBM corp., 2018) .............29
Obrázek 11- QRadar console, vlastní zpracování (2018)...................................................30
Obrázek 12- USM appliance, pevzato a upraveno (AlienVault, 2018) ........................31
Obrázek 13- AlienVault architektura, pevzato a upraveno (AlienVault, 2018) .......33
Obrázek 14 -QRadar – instalace, vlastní zpracování ............................................................46
Obrázek 15 - QRadar – web konzole, vlastní zpracování ...................................................47
Obrázek 16 - QRadar – proces sbru dat UBA, pevzato a upraveno (IBM corp., 2018)
...................................................................................................................................................................48
Obrázek 18 - QRadarUBA – GUI2, vlastní zpracování ..........................................................49
Obrázek 19 - QRadar UBA nastavení pes GUI, vlastní zpracování ................................50
Obrázek 20 - QRadar – ML app – User analytics, vlastní zpracování .............................51
Obrázek 21 - QRadar – ML app – User activity by category, vlastní zpracování .......52
Obrázek 22 - QRadar – ML app – Risk posture, vlastní zpracování ................................53
Obrázek 23 - QRadar – ML app – Activity distribution, vlastní zpracování ................53
Obrázek 24 - QRadar – ML app – Peer Group, vlastní zpracování ..................................53
Obrázek 25 - AlienVault OSSIM instalace, vlastní zpracování ..........................................54
Obrázek 26 - AlienVault OSSIM – web konzole, vlastní zpracování ...............................55
Obrázek 27 - Konverzace s AlienVault SW expertem, vlastní zpracování ...................55
Obrázek 28 - GUI AlienVault OSSIM – Netflow, vlastní zpracování ................................56
Obrázek 29 - Use case – prvotní skóre, vlastní zpracování ...............................................58
Obrázek 30- Use case – asová osa rizikových aktivit, vlastní zpracování ..................58
Obrázek 31 - Use case – prvotní spider graf, vlastní zpracování.....................................59
Obrázek 32 -Zasílání událostí pomocí logrun skriptu, vlastní zpracování ..................59
Obrázek 33 - Use case – zmna v aktivitách, vlastní zpracování .....................................60
Obrázek 34 - Nebezpené IP adresy – IBM X-force, vlastní zpracování .......................60
Obrázek 35 - Use case, nárst skóre a dashboard, vlastní zpracování .........................61
Obrázek 36 - Use case – seznam spuštných pravidel, vlastní zpracování .................61
Obrázek 37 - Use case – pekroení limitu pro generování offense, vlastní zpracování ...................................................................................................................................................................62
Obrázek 38 - Use case – rozpis rizikových aktivit uivatele, vlastní zpracování ......62
Obrázek 39 -Use case, modifikace spider grafu – zvýšení aktivity, vlastní zpracování ...................................................................................................................................................................63
Obrázek 40 - Use Case – generování offense, UBA modul, vlastní zpracování ..........63
Obrázek 41 - Use case – generování offense, prostedí QRadaru, vlastní zpracování ...................................................................................................................................................................63
Obrázek 42 - Use case – vytvoené pravidlo pro monitoring login failure, vlastní
zpracování ............................................................................................................................................64
Obrázek 44 - Use case – rozpis rizikových aktivit uivatele, vlastní zpracování ......65
Obrázek 45 - Use Case – generování offense, UBA modul, vlastní zpracování ..........65
Obrázek 46 - Use case – vytvoené pravidlo pro sledování zmny na serveru, vlastní
zpracování ............................................................................................................................................66
Obrázek 47 - Use Case – pidání uivatele do skupiny doménových administrátor,
vlastní zpracování ..............................................................................................................................67
Obrázek 50 - Use case – seznam podezelých aktivit, vlastní zpracování ...................68
Obrázek 51 - Use case – spider graf po spuštní group pravidla, vlastní zpracování ...................................................................................................................................................................69
Obrázek 52 - Use case – historie bezpenostních incident, vlastní zpracování ......69
Seznam tabulek
Tabulka 2 - System requirements – AlienVault, pevzato a upraveno (AlienVault
2018) ......................................................................................................................................................37
1
1 Úvod
Bezpenost vprostedí internetu a sním spojenými informaními systémy je tématem, kterému je pikládána stále vtší dleitost. Dle nkterých zdroj je kybernetický útok tetí nejastjší hrozbou, hned po zemtesení a jiných extrémních klimatických jevech. Pokud je organizace schopna se úspšn chránit ped útoky vedené zvení, má napl vyhráno. Mnohdy je ale stejn tak dleité mít síovou infrastrukturu zabezpeenou jak proti útokm zvenku, tak proti tm zevnit. Technologie SIEM je schopná sbírat data ze všech zdrojových zaízení vintranetu a díky analýze vreálném ase je schopna redukovat šanci vzniku potencionálního bezpenostního incidentu na minimum. Avšak vpípadech, kdy se jedná o nebezpené chování uvnit infrastruktury, je nutné, aby byla funkcionalita tchto analytických prvk posunuta na další úrove. Jedním zmoných ešení je aplikování princip uivatelské behaviorální analýzy. Tyto principy eší uivatelské interakce a komunikaci uvnit infrastruktury. Pedstavený modul UBA je schopen vytvoit jakýsi vzorek normálního chování a posléze definovat odchylky, které mohou poukazovat na hrozbu uvnit sít.
Vrámci mého psobení ve firm Autocont a.s. mi byla nabídnuta monost pokraovat vproblematice SIEM systém a definování pokroilých modul, které nabízí. Téma jsem pijal, jeliko jsem se problematikou SIEM systém zaobíral i ve své bakaláské práci, a je to hlavní náplní mé práce ve firm.
Hlavním cílem práce je definovat pouití princip uivatelské behaviorální analýzy a tuto skutenost demonstrovat na konkrétních zvolených SIEM aplikacích a rovn komparace tchto modul mezi sebou zhlediska jejich funkcionality. Samotná práce je rozdlena do 10 kapitol vetn úvodu a závru. Úvodní ást pibliuje problematiku SIEM systém, uivatelské behaviorální analýzy a také pojednává o struktue a cílech diplomové práce. První kapitola je vnovaná bezpenosti a ilegislativním restrikcím vyplývajícím zaktualizované vyhlášky Zákona o kybernetické bezpenosti. Krom zákona jsou zde definovány také standardy ISO 27000, které úzce souvisí sSIEM systémy. Druhá kapitola je vnovaná blišímu seznámení slogickou strukturou a funkcionalitou SIEM systém. Tetí a tvrtá kapitola jsou vnovaný konkrétním SIEM aplikacím, které byly vybrány pro pozdjší implementaci a demonstrování princip UBA a sním spojenými use case. Pátá kapitola pedstavuje komparaci mezi vybranými SIEM aplikacemi – IBM Security QRadar SIEM a AlienVault USM/OSSIM, a to dle pesn definovaných parametr. Šestá kapitola definuje funkcionalitu uivatelské behaviorální analýzy a sní spojenou metodou strojového uení. Sedmá kapitola obsahuje poznatky zimplementace a zavádní UBA modulu pro SIEM aplikace. Vkapitole osmé jsou shrnuty poznatky zpráce. Poslední je závrená ást pojednávající o dosaených cílech a monostech pro další výzkum.
2
Diplomová práce obsahuje adu cizích pojm, které se asto obtín pedkládají do eštiny zdvodu absence adekvátních peklad. Tyto pojmy jsou z pravidla vysvtleny pímo vtextu práce.
3
Bezpenost je všudypítomným faktorem, který lidstvo provází od jeho poátk.
ejí dleitost meme nalézt i v Maslowov pyramid poteb (Salado, Nilchiani,
2013) kde bezpenost figuruje hned v dalším stupni po uspokojení bazálních
poteb jako je poteba jíst i pít. Nyní pokud je opomenut základní faktor poteby
bezpeí a pesuneme se na asové ose do pítomnosti, pedstavuje otázka
bezpenosti stále dleitjší téma a jeho významnost má s pechodem do
informaní spolenosti gradující tendenci. Smutnou pravdou však je, e vtšina
organizací faktor bezpenosti ve své infrastruktue znan podceuje, co me
mít dopad na potencionálních ztrátách informací a dat, pokud bude na takovou
infrastrukturu útok skuten podniknut.
4
Ne bude pistoupeno ke konkrétním aspektm bezpenosti a jejich klasifikaci,
je nutné nejprve definovat, co to bezpenost je. Bezpenost lze definovat vícero
zpsoby, nicmén z obecné sémantické definice lze vyvodit, e bezpenost je
stav, kdy nehrozí ádné nebezpeí, není mu nikdo vystaven nebo je mu
poskytnuta ochrana ped nebezpeím, i je nepochybný zaruený a
dvryhodný. (Mareš, 2017)
Z dílí definice lze usoudit, e vymezení bezpenosti je provádno v negativním
smyslu, tudí lze oekávat pítomnost negativních vliv nebo neho, co
bezpený stav narušuje.
Jak ji bylo zmínno, bezpenost je nutné klasifikovat dle segmentu uití –
mnohdy je termín „bezpenost“ nahrazován anglickým ekvivalentem „security
and safety,“ tato skutenost je pisuzována absenci diferenciace mezi tmito
dvma pojmy (ve slovnících je jeden definován druhým).
Nyní bude definována klasifikace bezpenosti, jejich název se mnohdy odvíjí od
jejího charakteru, tak jak je definován dle Zemanovy definice bezpenosti.
(Zeman, 2002)
• Vojenská,
• ekonomická,
• ekologická,
• sociální,
• lidská,
• informaní,
• kybernetická…
V rámci této práce není nutné vymezovat všechna zmínná odvtví, ve kterých
lze na pojem bezpenosti narazit. Mnohdy lze bez pedchozího definování
odhadnout, ím se daná oblast zabývá, a od eho lovka nebo jinou instituci
chrání.
Pro kontext práce jsou klíové dv poslední vymezené sféry bezpenosti –
informaní a kybernetická. Tyto dv oblasti budou nyní blíe specifikovány, aby
bylo moné pozdji porozumt celkové problematice vytyené v práci.
(Zeman, 2002, str. 11)
Citlivé informace musí být bezpen uchovány, nesmí být zmnny, pesunuty
nebo upravovány bez povolení. Informaní bezpenost je vytvoena tak, aby byla
schopná zvládat rizika vycházející z analýzy rizik. Ve svt informací me být
rizikem i hrozbou takka cokoliv. Zmínná bezpenost se snaí chránit
dvrnost (confidentiality), integritu a dostupnost (availability) informací a
systémových dat, ped tmi, který by k nim nemli mít pístup nebo s nimi mají
nekalé úmysly. Princip výše zmínné ochrany je asto adresován jako CIA Triad
of information security (Dardick, 2010). Bohuel brzy pestala tato triáda být
v komplexní problematice bezpenosti informací dostaující, tudí bylo nutné
rozšíitdefinici o další nezbytné atributy, z eho se posléze vyvinul tzv. Parker
hexad (Dardick, 2010), který krom ji zmínných obsahuje navíc ješt vlastnictví
(possession), autentinost (authenticity) a prospšnost (utility).
Nyní budou definovány dílí principy Parker hexad.
• Confidentiality,
o Potvrzení o pístupy k informacím pouze pro ty, kteí k nim mají mít
pístup.
• integrity,
o Zaruená ucelenost všech metod a princip v kadém okamiku.
• availability,
o Míra, s jakou jsou obsaené informace dostupné a zárove
relevantní.
• posession,
• authenticity,
pro rozhodování v procesu autentity informací a dat.
• utility.
daných informací nebo dat.
(Dardick, 2010, s. 6-65)
Definování kybernetické bezpenosti nelze provést zcela jednoznan, ba co víc,
spousty souasných publikací uívají pojmu „cyber security“ v kontextu znané
similarity s „information security.“ Je pravda, e pro vtšinu incident z prostedí
kybernetické bezpenosti to platí, stejn jako lze aplikovat principy „CIA“ na
vtšinu jejich incident.
Jednou z definic me být ta, jak je vysvtlena dle Merriam-Webster: „measures
taken to protect a computer or computer system (as on the Internet) against
unauthorized access or attack.” (Merriam-Webster, 2018) Rozdílnou interpretaci
pak pedstavuje definice od ITU (International Telecomunications Union):
kybernetická bezpenost je kolekcí nástroj, politik, bezpenostních koncept,
pístup risk managementu, preventivních akcí, tréninku, best practise a
v neposlední ad technologiemi, které lze pouít pro ochranu kybernetického
prostedí a dleitých uivatelských i firemních dat a informací.
Z výše zmínných definic jasn vyplývá vzrstající dleitost ešení problematiky
asociované s kybernetickou bezpeností. Tuto skutenost podporuje i následující
fakt zmínný autory von Solms a van Niekerk v lánku From information security
to cyber security. (Von Solms a Van Niekerk, 2013) Velká Británie stanovila
kybernetickou bezpenost jako jednu z nejvyšších priorit a vylenila více ne 650
milion liber na program vnující se kybernetické bezpenosti vetn
asociovaných hrozeb.
jako je tomu u informaní bezpenosti tzn. Confidentiality, availability, integrity.
Jak ji ale bylo zmínno díve, nejedná se o synonyma. Rozdíl lze vysledovat na
tom, co by mla daná bezpenost chránit. Vdy se jedná o ochranu aktiva (cenné
komodity), nicmén v pípad informaní bezpenosti je definice ochrany aktiva
zahrnuta napí všemi aspekty informace samotné. Ochrana v kontextu
informaní bezpenosti se nevztahuje pouze na technologie, ICT infrastrukturu
nebo informace, které nejsou pomocí informaních technologií zaznamenávány
nebo zpracovány. Naproti tomu kybernetická bezpenost má za úkol chránit
konkrétní osobu, zájmy celé spolenosti nebo kritickou národní infrastrukturu.
V podstat se dá íct, e v tomto pípad do této problematiky spadá kdokoliv
nebo jakýkoliv asset (aktivum), dosaitelné v kyber prostoru. (Von Solms a Van
Niekerk, 2013 & Rowe, Lunt & Ekstrom, 2011)
Z toho dvodu lze usoudit, e kybernetická bezpenost není analogií informaní
bezpenosti. Pedevším z dvodu nutné ochrany nejen asset, nicmén i kyber
prostoru jako takového.
ISO, které se danou problematikou hluboce zaobírají, pedevším pak standardy
ISO 27k family. Tyto standardy budou v další ásti práce zmínny a definovány.
7
Ne bude pistoupeno k definování jednotlivých druh standard relevantních pro
kontext informaní bezpenosti, budou nejprve objasnna základní terminologie.
ISO (International organization for standardization) – je mezinárodní organizací
zabývající se standardizací a vytváením norem. Sdruuje experty napí celým
svtem a ítá 162 národních certifikaních autorit. Jejím hlavním úkolem je
sdílení znalostí a na základ nich vytváet mezinárodní normy, pedstavující
doporuené ešení pro rznou problematiku. (About ISO, 2017)
IEC (International Electrotechnical Commission) – jinak známá jako mezinárodní
elektrotechnická komise, je organizací publikující mezinárodní standardy pro
elektrické a elektronické produkty, systémy a sluby. Její publikace slouí jako
základ pro mezinárodní standardizaci a rovn jako v pípad standard ISO
slouí jako uritá záruka kvality, pokud jej organizace vlastní. Komise IEC úzce
spolupracuje s ISO a také s ITU (International Telecommunication Union)
pedevším z dvodu zamezení redundancím nebo duplicitních standard.
(About IEC, 2017)
Standard ISO je sdruením doporuení a best practises, které pomáhají
optimálním zpsobem ešit problematiku týkající se produkt, slueb nebo
systém za úelem dodret uritou úrove kvality, bezpenosti a efektivnosti.
Hlavní výhodou vyuití ISO standard je jeho výpovdní hodnota. V pípad, e
daná organizace vlastní výše zmínné standardy, lze pedpokládat, e se jedná
o dvryhodnou firmu, nebo jsou jeho produkty, sluby nebo firemní procesy
optimalizovány. Zatím bylo vydáno 21989 standard a s tím souvisejících
dokument. (About ISO, 2017)Standardy ISO 27000 family
Sdruení standard ISO v rámci rodiny 27000 je nejdleitjším souhrnem
v kontextu s ešením bezpenosti informací. V minulosti byly uívány standardy
BS 7799 a ISO 17799, které jsou v souasné dob nahrazeny výše zmínným.
V následující ásti práce budou definovány základní charakteristiky jednotlivých
standard rodiny ISO 27000.
Mezinárodní standardy pro management systém zprostedkovávají model, díky
kterému je moné efektivn nastavit, operovat a ídit systém. Tento model
zaleuje klíové postupy a charakteristiky, které byly vyzkoumány a
odsouhlaseny experty, kteí jsou souástí díve zmínných „ISO bodies.“ Pro
oblast informaní bezpenosti je v rámci ISO definován velmi dleitý pojem,
resp. rámec krok, vedoucí k optimalizované podob informaního procesu.
Pojem ISMS (Information Security Management Systém) je zmiován napí
všemi standardy ISO 27k family. S jeho pomocí lze vytvoit a implementovat
rámec, který bude úinným zpsobem spravovat dleité assety v rámci firemní
infrastruktury.
Následuje výet Standard ISO, jinak nazývaných také jako ISMS standardy:
• ISO/IEC 27000, Information security management systems — Overview
and vocabulary
Requirements
• ISO/IEC 27003, Information security management system implementation
guidance
• ISO/IEC 27006, Requirements for bodies providing audit and certification
of information security management systems
• ISO/IEC 27007, Guidelines for information security management systems
auditing
• ISO/IEC TR 27008, Guidelines for auditors on information security controls
• ISO/IEC 27009, Sector-specific application of ISO/IEC 27001 —
Requirements
inter-organizational communications
telecommunications organizations based on ISO/IEC 27002
• ISO/IEC 27013, Guidance on the integrated implementation of ISO/IEC
27001 and ISO/IEC 200001
• ISO/IEC 27014, Governance of information security
• ISO/IEC TR 27015, Information security management guidelines for
financial services
economics
• ISO/IEC 27017, Code of practice for information security controls based
on ISO/IEC 27002 for cloud services
9
• ISO/IEC 27018, Code of practice for protection of personally identifiable
information (PII) in public clouds acting as PII processors
• ISO/IEC 27019, Information security management guidelines based on
ISO/IEC 27002 for proces control systems specific to the energy utility
industry
(ISO/IEC 27000, 2018)
Obrázek 2 - Pehled ISO 27k family, pevzato a upraveno (ISO/IEC 27001, 2018)
Pro úely této práce jsou dleité pedevším standardy ISO 27001, ISO 27 002,
ISO 27 003 a ISO 27 004. Tyto standardy jsou rovn klíové v kontextu Zákona
o kybernetické bezpenosti (181/2014 Sb.) a vyhlášky o kybernetické
bezpenosti 82/2018 Sb., který bude definován v následující ásti práce.
2.2.2 ISO 27001 (Information security management systems)
Mezinárodní norma má primárn poskytovat podporu pro ustavení, zavádní,
provozování, monitorování, udrování a zlepšování systému managementu
bezpenosti informací (Information Security Management Systém i ISMS).
Akceptace ISMS jakoto strategické rozhodnutí je podmínno cíli, potebami
organizace, pouívanými procesy, velikostí a strukturou organizace a poadavky
na bezpenost.
Norma ISO/IEC 27001 poskytuje celistvý model pro zavedení princip popsaných
také ve smrnici OECD, upravující hodnocení rizik, navrení a implementaci
bezpenostních princip, management bezpenosti a optovné hodnocení
bezpenosti. Aplikace ISMS je klíová pro kontext definování poadavk pro
ISMS, vytváí pímou podporu a rovn cílené vedení za úelem vzniku,
implementace a kontinuálního zlepšování ISMS.
10
Principy ISMS vychází z tzv. PDCA modelu (Plan-Do-Check-Act), který me být
souhrnn aplikován na všechny procesy ISMS.
Obrázek 3 -PDCA cyklus pro ISMS, pevzato a upraveno (ISO/IEC 27001, 2018)
• Plánování (ustavení ISMS)
Je nutné definovat politiky ISMS, cíle, procesy a postupy asociované
s managementem rizik a zlepšováním bezpenosti informací takovým
zpsobem, aby bylo v dostatené míe zajištno plnní v souladu s celkovou
politikou a cíli organizace.
• Implementace a provozování ISMS
Zavádní a vyuívání politiky ISMS, jejich opatení, proces a postup.
• Monitorování a pezkoumání ISMS
Proces explorace, který posuzuje kvalitu zavedení ISMS oproti ji definovaným
cílm a politice organizace. Souástí je i reportování dosaených výsledk
vedení organizace k pezkoumání.
• Udrování a zlepšování ISMS
Akceptování opatení k napravení a preventivním opatení, které jsou zaloeny
na výsledcích interního auditu ISMS, pezkoumání systému ízení vedením
organizace a snaha o proces kontinuálního a efektivního zlepšování ISMS.
Jeliko je tento standard klíový pro kontext práce, bude nyní podrobnji
definován.
11
Ustavení ISMS je podmínno definováním rozsahu a hranic, které závisejí na
konkrétních poadavk a rys innosti spolenosti, její struktury, technologické
vybavenosti, lokality nebo vlastnných aktiv. Tyto hranice jsou stejní pro další
krok, ve kterém je stanovena politika ISMS, mimo jiné obsahující rámec
ustanovující smr ízení, zásady inností asociované s informaní bezpeností.
Politika rovn musí brát v potaz poadavky kladené organizací, veškerá
legislativní restrikce nebo poadavky regulatorní povahy a rovn je nutné
vytvoit vazby na stejní ásti strukturu organizace a její risk management.
Management rizik je v kontextu implementace ISMS klíový, z toho dvodu je
nutné, aby byl jednoznan uren pístup organizace k této problematice. V prvé
ad zvolit vhodnou metodiku pro evaluaci rizik, vytvoit kriteriální atributy pro
schválení rizik a urit, jaké jsou jejich úrovn. Je nutné, aby bylo moné danou
metodiku v budoucnu porovnávat a také opakovat na rzné procesy.
Po definování nezbytných politik je dalším logickým krokem implementace a
provozování ISMS. V tomto bod je ji formulován základní rámec vetn politik
managementu rizik a bezpenosti informací jako takových, nyní budou vysloveny
konkrétní plány, jak zvládat konkrétní druhy výskytu rizik v dané organizaci.
Podle odsouhlasených plán je pak celý podnik, v kontextu ISMS, ízen. Velmi
dleitým faktorem je rovn zvyšování povdomí o dané problematice, vedení
školení a zavedení postup nebo preemptivních proces pro vasnou detekci a
reakci na bezpenostní události nebo reagování na bezpenostní incidenty.
Nyní jsou ji veškeré nezbytné procesy implementovány, nicmén v rámci ISMS
princip opírajících se o ji zmínný PDCA cyklus, je pro zajištní kontinuálního
zlepšování nutné systém monitorovat a revalidovat ji implementovaný systém,
aby byla zajištna jeho aktuálnost. Monitorování a pezkoumání ISMS je klíové
hned z nkolika hledisek, tím nejvíce transparentním je vasná detekce
zpracování, identifikace procentuálního zastoupení úspšného zamezení
bezpenostních hrozeb a vzniku bezpenostních incident nebo validace
správné funkcionality. Pezkoumávání implementace a jejich stejních ástí je
klíové pro definování nedostatk a moných vylepšení pro další „run.“
V kontextu monitoringu a validace je rovn stejní provádní interních audit
ISMS v pedem definovaných intervalech a výstupy tchto mení a zjištní
dkladn zaznamenat pro budoucí vyuití.
Poslední fází dle PDCA cyklu je v kontextu ISMS jeho udrování a zlepšování.
Tato fáze se týká pedevším optimálního managementu zmn na základ
zjištných nedostatk v pedchozí fázi monitoringu. Rovn je nutné provádt
innosti preventivní povahy a stále projednávat innosti a návrhy na optimalizaci
pro zvyšování a na stanovenou úrove. Tato fáze obsahuje definování
zodpovdnosti a garance naplnní stanovených poadavk a pedpokládaných
cíl.
Za pedpokladu, e jsou dodreny všechny stejní postupy v rámci procesu
zavádní ISMS, je moné oekávat zlepšení v oblastech:
12
ochrany od zaátku procesu,
správného aplikování,
bezpenostních rizik pro dleité organizaní assety a jejich následné
monitorování pro optimalizování efektivity.
Pro dostatené porozumní problematiky je nutné definovat také další standardy
z rodiny 27 000. Tyto standardy jsou stejní pro správnou implementaci
bezpenostního ešení. Dodefinovány budou standardy, které se pímo týkají
Zákona o kybernetické bezpenosti, který je nedílnou souástí této práce.
Na rozdíl, od ji zmínného standardu ISO/IEC 27001 jsou však nkteré spíše
doporuujícího charakteru.
techniques)
Tento mezinárodní standard je vytvoen pro organizace, které jej mohou pouít
jako dokument poskytující návod bhem implementace kontrolních proces
asociovaných s ISMS, zmínném ve standardu ISO/IEC 27001. Standard je
moné pouít pro jakýkoliv druh organizace, a u v ziskovém i neziskovém
prostoru, pro rzn veliké organizace. Standard se zabývá pedevším výbrem
adekvátních bezpenostních kontrol, které budou stejní pro implementaci
ISMS.
„ISO/IEC 27002 is a code of practice – a generic, advisory document, not a formal
specification such as ISO/IEC 27001. It recommends information security
controls addressing information security control objectives arising from risks to
the confidentiality, integrity and availability of information. Organizations that
adopt ISO/IEC 27002 must assess their own information security risks, clarify
their control objectives and apply suitable controls (or indeed other forms of risk
treatment) using the standard for guidance.“
(ISO/IEC 27002, 2013)
Z citace týkající se definování standardu tak, jak je zapsána na oficiálních
stránkách, je zejmé jasné vymezení a rozdíl mezi standardy 27001 a 27002.
Standard ISO/IEC 27002 je svou povahou asto nazýván také jako guideline,
nebo není tak striktní v procesu výbru vhodných nástroj, jako je tomu u
ISO/IEC 27001, a plní spíše podprnou funkci.
Norma se opírá o principy CIA triády, která byla definována ji v kapitole vnující
se informaní bezpenosti.
(ISO/IEC 27002, 2013)
implementation guidance)
Standard ISO/IEC 27003 je, jako všechny standardy z 27k family, úzce spjatý
s implementací ISMS a asto se odkazuje na standardy ISO/IEC 27000 a
ISO/IEC 27001. Jako v pedchozím pípad, i zde se standard snaí spíše
navrhnout doporuení, monosti a povolení, úelem dokumentu není poskytnutí
celkového vedení jako v pípad ISO/IEC 27001. Spíše, ne na samotnou
implementaci je tento standard navren jako pomoc pro optimalizaci
managementu a monitoringu probíhající ji po úspšné implementaci ISMS.
Krom ji zmínných je rovn zamen na správné pojetí PDCA cyklu a s ním
spjaté klíové atributy jako jsou:
• plánování procesu zavedení ISMS
a jejich aplikace nebo definice potebných poadavk pro naplnní
podstaty standardu
ISMS
adekvátním zpsobem zhodnotit stav informaní bezpenosti a posoudit
efektivitu systému spravujícím informaní bezpenost v organizaci. Jeho úelem
je nalezení optimálních metrik, díky kterým bude moné naplnit poadavky
stanovené v ISO/IEC 27001. Obsahem standardu je mimo jiné:
• monitoring a mení výkonnostních aspekt bezpenosti informací
• monitoring a mení efektivity ISMS vetn s ním asociovaných proces
a kontrol
(ISO/IEC 27004, 2017)
Po zdárném definování potebných standard bude nyní definován Zákon o
kybernetické bezpenosti, který významn ovlivnil celý koncept vnímání
informaní bezpenosti u nás.
2.3 Zákon o kybernetické bezpenosti
Zákon o kybernetické bezpenosti (181/2014 Sb.) vešel v platnost na zaátku
roku 2015. Svou podstatou podporuje implementování princip informaní
bezpenosti, ISO 27k, a tudí i SIEM systému. Implementace by mla probíhat
v souladu s ízením organizace a tak, aby nedocházelo ke stetu mezi
legislativními poadavky a primárními cíli organizace. Povinné zavedení princip
definovaných v zákon jsou pedepisovány pro kritickou informaní
infrastrukturu, ta je dle Wolters Kluwer definována jako „prvek nebo systém prvk
kritické infrastruktury v odvtví komunikaních a informaních systém v oblasti
kybernetické bezpenosti.“ Povinnost vzniká kadé organizaci spadající pod
zákony . 127/2005 Sb. (Zákon o elektronických komunikacích), . 240/200 Sb.
(Krizový zákon) a . 317 (Odvtví veejné správy).
(Krmá, 2013; Wolters Kluwer R, 2014)
ZKB je regulaním legislativním nástrojem v oblasti bezpenosti informaních
technologií.
Zákon prošel v roce 2017 novelizací, která se týkala pedevším:
• zavádní nových institut,
• zavedení nových povinných orgán a osob,
• nové úpravy povinností pi uzavírání smluv mezi orgány veejné moci a
poskytovateli cloud computingu,
• rozšíení povinností pi bezpenostních událostech a incidentech,
• rozšíení pravomocí národního a vládního CERT,
• zízení nového ústedního orgánu – NÚKIB.
15
Jak je vidt z pedchozího pehledu o zmnách v zákon, veškerými procesy
týkající se kybernetické a informaní bezpenosti na území eské republiky se
zabývá tzv. NÚKIB (Národní úad pro kybernetickou a informaní
bezpenost). Tento úad vznikl v roce 2017 na základ zákona . 205/2017 Sb.
v kontextu zmn zákona . 181/2014 Sb. (Zákon o kybernetické bezpenosti).
Hlavními innostmi tohoto správního orgánu pro kybernetickou bezpenost jsou:
• píprava bezpenostních standard,
• výzkum a s tím spojený vývoj v oblasti kybernetické bezpenosti,
• ochrana informací citlivé povahy z oblasti informaních komunikaních
systém,
(NÚKIB, 2018)
Obrázek 4 - Blokové schéma, pevzato (NÚKIB, 2018)
V souasné dob probíhá jednání o nové vyhlášce o kybernetické bezpenosti,
ta byla naposledy projednávána 19.1.2018. Tato vyhláška zatím ješt nenabyla
legislativní úpravou a je moné, e se bude ve své finální podob trochu lišit,
nicmén je u te jasné, e zmna se bude pedevším týkat níe uvedených
oblastí:
16
• obsah bezpenostních opatení, rozsah jejich zavedení,
• typy, kategorie a hodnocení významnosti kybernetických bezpenostních
incident,
• náleitosti oznámení o provedení reaktivního opatení a jeho výsledku,
• vzor oznámení kontaktních údaj a jeho formu a
• zpsob likvidace dat, provozních údaj, informací a jejich kopií.
(NÚKIB, 2018)
V tomto kontextu je pro tuto práci klíová problematika zaznamenána pedevším
v hlav 2, § 11 - §14. Tyto paragrafy blíe specifikují ízení zmn, ízení pístupu,
vývoj s údrbou a zvládání kybernetických bezpenostních událostí a incident.
Všechny zmínné oblasti lze vyešit vhodnou implementací SIEM technologie.
Jednotlivé paragrafy z hlavy 2 budou nyní blíe rozebrány.
ízení zmn
management zmn u informaního a komunikaního systému. Je nutné
zabezpeit manipulaci s informacemi o ízení systém, analýzách rizik, up-to-
date bezpenostní politiku a dokumentaci, testování optimálního nastavení
systém, zálohování zmn pro obnovu dat v pípad problému. Paragraf dále
specifikuje proces rozhodování pro penetraní testování zmínných systém a
další postup v pípad zjištní nedostatk.
ízení pístupu
ízení pístupu je specifikováno povinností pro zodpovdnou osobu nebo orgán
pijmout opatení zajišující omezení pístupu k citlivým údajm, zejména
takových, která slouí pro úely autorizace a autentizace. Dále je pedepisována
povinnost ídit pístup na základ skupin a rolí, uití jedineného identifikátoru
pro pístup do systému (dohlíet na dodrování autentizaních postup u
zamstnanc), omezení privilegií na nejvyšší monou mez nezbytnou
k provádní pracovních úkon, zavedení bezpenostních opatení pro všechny
pístroje pistupujících do prostedí informaního nebo komunikaního systému
a v neposledním pípad pezkoumávání nastavení pístupové politiky v pevn
daných asových intervalech. V pípad zjištní porušení stanovených pravidel
je nutné zakroit a uinit rázné kroky v podob odebrání pístupových práv nebo
rekonfiguraci bezpenostní politiky. Veškeré provedené kroky, tj. pidlení a
odebrání pístupových práv musí být v souladu se zákonem, zaznamenáno pro
úely pozdjší analýzy.
Akvizice, vývoj a údrba
Tento paragraf je svou podstatou seznamem povinných poloek, které je poteba
dodret v rámci kontinuálního zlepšování a údrby pro komunikaní a informaní
systémy. Mimo jiné specifikuje povinnost ídit rizika dle postup definovaných
v zákon, ízení zmn a stanovení optimálních bezpenostních poadavk, které
jsou do procesu vývoje a údrby zahrnuty. V rámci vývoje je nutné zajistit
bezpenost také pro testovací data a testovat v bezpeném prostedí., a
v pípad kdy se jedná o testování jakékoliv významné zmny, bude tato zmna
nejdív otestována, ne bude nasazena do provozu.
Zvládání kybernetických bezpenostních událostí a incident
Paragraf pedepisuje implementaci bezpenostního zaízení dle poadavk
stanovených v zákon:
bezpenostních událostí a incident,
• definuje odpovdnost a postupy pro prbnou detekci a pro zvládání
kybernetických incident,
esenciálních pro kvalitní analýzu bezpenostního incidentu,
• zajistí detekci bezpenostních událostí a v pípad výskytu pedepisuje
zpsob manipulace dále v zákon,
• pikazuje vasné nahlašování bezpenostních událostí lidem, kteí pijdou
s touto problematikou do styku,
• vytváí povinnost pro posuzování bezpenostních událostí dle
stanovených postup a nutnost rozhodování o jejich transformaci na
bezpenostní incidenty,
bezpenostního incidentu,
a vyhodnotí úinnost jeho vyešení, pípadn stanoví oblasti, které je
nutné zlepšit pro zamezení opakování bezpenostního incidentu.
Zvládání bezpenostních událostí a incident je svou povahou nejblíe k SIEM
tématice. Ve výše zmínných bodech definovaných tímto paragrafem lze jasn
vidt principy, které jsou v SIEM systémech pouívány. Tyto principy budou nyní
definovány, aby byla zejmá nutnost pouití této technologie.
18
Po definování nezbytných náleitostí týkající se standard spravujících
informaní bezpenost a zákonu implementovaném pro správu kritické
infrastruktury státu, budou nyní objasnny dílí principy SIEM (Security
Information and Event management).
Technologie SIEM byla ji zmínna v kontextu ISO standard 27000, který se
jeho optimalizací a funkcionalitou zabývá. SIEM je díky svým funkcím rovn
doporuen v rámci Zákona o kybernetické bezpenosti. Jeho dleitost vzrstá
pedevším z dvodu nutnosti ochrany informací nejen velkých organizací.
Bezpenostní management událostí a informací je ešením na vzrstající poet
heterogenních a stále komplexnjších prostedí a technologií. Pokud je vzat
v potaz fakt, e tyto technologie budou monitorovány a bude proveden sbr
informací jejich chování, výsledná data budou svou rznorodostí, mnostvím a
povahou pi nejmenším velmi obtín pouitelné pro další analýzu.
SIEM technologie se svým uitím adí k pomrn novým technologiím, pesto
jsou její principy známy ji delší dobu, i kdy v diferenciované podob. Ped
vznikem samotného SIEMu zde byly technologie SIM (Security Information
Management) a SEM (Security event management). V obou pípadech se
jednalo o management citlivých informací nebo událostí generovaných
koncovými zaízeními. S tím, jak se technologie, infrastruktury a systémy stávaly
sloitjšími, bylo nutné zvýšit funkcionalitu a celkovou komplexnost technologie.
Absence tchto vlastností byla vyešena slouením dvou technologií.
Obrázek 5 - Architektura SIEM, pevzato a upraveno (Miller, 2011)
19
pijímaných dat. Tyto principy budou nyní definovány.
• Log management
Management logovacích záznam v SIEM systému je iniciován konfigurací
datových uzl v IT infrastruktue/ systému. ím lépe je mapování infrastruktury
rozmístno – jsou monitorovány kritické uzly, tím pesnjší je obraz, který je
získán z relevantních událostí aplikací (log). Události jsou zasílány do
centralizované databáze, která je spravována SIEM aplikací. SIEM aplikace
databáze nejprve rozadí pomocí parseru a znormalizuje je. Data zasílaná do
databáze jsou, jak ji bylo zmínno, vysoce heterogenní a je jich obrovské
mnoství. Koncová zaízení mohou být poítae bící na rzných operaních
systémech – Linux, UNIX, Windows. Jiná zaízení mohou pedstavovat switche,
firewally, systémy na detekování vniknutí (IDS), systémy zajištující vzdálený
pístup, nebo proxy servery. Tyto rozliné systémy pocházejí od rzných druh
výrobc, co se bohuel asto promítá v syntaxi a stavb log. ešení je závislé
na konkrétním druhu koncového zaízení, a u se jedná o uití syslogových
klient, které budou zasílat informace nebo je moné vyuít ji peddefinované
parsery, pípadn customizovaný syslog klient software, který je nabízen od
SIEM výrobce.
Po úspšných prvotních krocích jsou události uschovány pro další poteby
v budoucnu. SIEM je schopen události organizovat, ukládat, obnovovat a
archivovat pro splnní auditních poadavk spolenosti. Krom ji zmínných
funkcí, jsou data také pouívána pro poteby analýzy. SIEM se pyšní takka real-
time analýzou událostí a data miningem zkoumajícím celkové zdraví a
bezpenostní status infrastruktury. ím více koncových zaízení bude zasílat své
události do SIEM systému, tím kompletnjší a pesnjší bude obraz vypovídající
o stavu firemní síové infrastruktury.
20
3.2 IT Regulatory Compliance
Poté, co jsou všechny dleitá koncová zaízení síové infrastruktury napojena a
zasílají své logovací záznamy, je nutné vytvoit set pravidel a filtr. Pravidla jsou
typu boolean a zastávají funkci kontroly. Kontrolují picházející události, zda
neobsahují informaci vymykající se normálu. Pokud je zjištno porušení pravidel
v oblasti identifikace OS, autentizace, aktualizace IDS systém, nesrovnalosti
s obvyklým asem nebo geografickou polohou uivatele, to vše me být
podntem k dalšímu prošetení. Spuštní pravidla je ve vtšin pípad
vytvoením offense (bezpenostního incidentu). Vytvoení filtr je moné vícero
zpsoby. V první ad je moné si zakoupit výrobcem ji peddefinovanou adu
filtr, jedná se zejména o filtraci dle nejastji uívaných atribut, které logy
obsahují tzn. uivatelské jméno, zdroj logovacích záznam, zdrojová nebo cílová
IP adresa, zdrojový nebo cílový port, pouitý protokol, … V pípad, e je nutné
vytvoit filtry specifitjší povahy, odvíjí se povaha filtru zejména podle dané
problematiky. V neposlední ad obsahují SIEM systémy také system reporting,
který je dleitý pedevším v kontextu auditingu a validace úrovn ešení.
3.3 Event Correlation
Korelace událostí obdrených do systému SIEM je pidanou hodnotou, díky které
je SIEM technologie tak ádaná a efektivní. Proces korelace událostí je do jisté
míry procesem uení, díky kterému bude systém schopen rozpoznávat
potencionální hrozby, piem je schopen vzít v potaz rozlinou škálu
promnných. Vzniklý problém ve firemní nebo kritické infrastruktue me být
zpsoben x initeli, a je mnohdy velmi obtíné zohlednit všechny faktory
pispívající k této skutenosti. Korelaní engine SIEM je schopen prošetit, zváit
a korelovat i události, které nemají na první pohled pímou souvislost
s problémem, nicmén mohou íci a objasnit další skutenosti o stavu zdraví
síové infrastruktury. Bude stanoveno nkolik hypotéz vysvtlující problém
v infrastruktue. Dalším krokem je ji lidský faktor, který vybere nejlepší monou
variantu na základ dostupných informací a skuteností.
Po definování dílích ástí SIEM bude nyní blíe piblíen celý proces zpracování
dat a architektura SIEM.
21
Obrázek 6- Proces zpracování událostí v SIEM, pevzato a upraveno (Miller, 2011)
3.4 Architektura SIEM
Jak je moné vidt na piloeném schématu, SIEM uívá pi procesu zpracování
událostí vícero nástroj. Všechny souásti celku musí bezchybn kooperovat,
jinak dochází k chybám a pádu celého systému. Je nutné zmínit, e komplexnost
ešení se liší velikostí a sloitostí od implementace k implementaci. Nkterá
zavedení mohou obsahovat i další souásti vnující se forenzním analýzám nebo
korelacím, avšak níe zmínné souásti musí být pítomny a správn
nadefinovány v kadé implementaci, jsou sice schopny pracovat samostatn,
nicmén SIEM jako celek nebude fungovat dle oekávání.
• Source Device (zdrojová zaízení
• Parsing Normalization
• Rule engine
• Correlation engine
• Log storage
3.4.1 Source device
Pod pojmem zdrojového zaízení si lze pedstavit cokoliv, co zasílá informace o
svých aktivitách do SIEM systému. Níe jsou zmínny nkterá zdrojová zaízení,
která bývají asto souástí firemní infrastruktury:
• routery,
• switche,
• firewally,
• appliance,
• aplikace,
• operaní systémy.
Napojení zdrojových zaízení je esenciální pro adekvátní výstup v SIEM systému,
v pípad absence nebude SIEM schopen analyzovat, co se dje v síové
infrastruktue a nebude moné predikovat, reagovat a zabránit vzniku
bezpenostních událostí a bezpenostního incidentu. Objem dat, který je
generován ve firemní infrastruktue, je obrovský. Takka kadé kliknutí myší
v prostedí webového prohlíee iniciuje transport datových packet uvnit i vn
sít. Veškerá tato komunikace musí být správn zachycena a zasílána do SIEM
aplikace, která bude schopná generovat relevantní výstupy týkající se zdraví
systému.
Na druhou stranu, pokud bude monitorována kadá souást systému, me se
nalezení problému rovnat hledání jehly v kup sena. Z toho dvodu je nutné
definovat dleitost jednotlivých zdroj na základ dleitosti, kterou
v infrastruktue hrají a jak asto zasílají své informace do SIEM aplikace. Výše
zmínné je kritické pro vytvoení optimálního prostedí pro real-time analýzu,
kterou SIEM pouívá.
Obrázek 7 - Podoba raw logu generovaného zdrojovým zaízením, vlastní zpracování
3.4.2 Log collection
Kolekce událostí je krokem, kdy jsou data, týkající se povdomí o infrastruktue,
transportovány do SIEM aplikace pro vyhodnocení. Penos se týká všech
zaízení, která jsou na SIEM napojena, proto je stejním krokem definovat
pouze ty, které jsou pro zjištní stavu infrastruktury stejní. V kontextu zpsobu
penosu existuje nkolik moných variant v závislosti na druhu SIEM systému,
nicmén tmi nejuívanjšími a nejzákladnjšími jsou metody push a pull. Kadá
z tchto metod má své výhody a nevýhody, ty budou nyní blíe definovány.
23
Metoda push je metodou, která se vyznauje pedevším snadným
konfigurováním v SIEM systému. V zásad staí definovat koncový pijíma, na
který se posléze odkazuje zdrojové zaízení, aby do nj mohlo zasílat logovací
události. Dobrým píkladem je napíklad uití syslogu pro zasílání informací. Je
definována IP adresa a DNS syslog pijímae, který v tomto pípad je napojen
nebo je souástí SIEMu. SIEM jako takový není v procesu získávání logovacích
událostí zapojen, koncové zaízení samo zasílá tyto data do systému nebo
aplikace. Absence participace SIEM skýtá jistá nebezpeí – znanou nevýhodou
push metody je, e pro transport dat je vtšinou uit UDP protokol, u které je
moné, e ne všechny datové packety dorazí do cílové destinace. V pípad
nedostaten definované autorizaní politiky je moné, e v pípad
kybernetického útoku dojde k pepsání nebo nahrazení nkterých informací, za
úelem zkreslit pohled na systémové zdraví. Tzv. man in the middle je technikou,
která se pro falsifikaci datových packet hojn pouívá. K prevenci ped tmito
útoky je nutné znát, jaká zdrojová zaízení jsou v infrastruktue zastoupena a jaké
generují záznamy.
3.4.2.2 Pull metoda
Metoda pull se od ji zmínné push liší pedevším v tom, e samotný proces
získávání logovacích záznam je iniciován samotným SIEM systémem. SIEM
zašle dotaz na koncové zaízení, ze kterého jsou posléze transferována data do
systému. Nevýhodou této metody je moná ztráta schopnosti real-time analýzy.
Záznamy lze z koncových zaízení vytahovat v intervalech, které se nastaví,
avšak v pípad píliš dlouhé prodlevy nebudou informace o infrastruktue
aktuální. Eliminaci by mohlo pedstavit adekvátní nastavení spouštní pull
mechanismu na kadých pár vtein.
Po definování metod kolekce budou nyní piblíeny principy kolekce v rámci
pednastavených politik a kolekce nestandardních typ log.
Z dvodu existence obrovského mnoství koncových zaízení je nkolik
zpsob, jak pimt SIEM, aby správn etl logovací záznamy z koncových
zaízení. Tím nejjednodušším je existence ji výrobcem peddefinovanými
metodami pro vtšinu známých zaízení a software (Oracle, Linux, Windows …),
bohuel, ne vdy existuje snadné ešení. V pípad, e je pracováno s ním, co
ješt SIEM nezná, jsou dv monosti. Je moné uití sekundární aplikace, která
transformuje výstup na nco, co je SIEM schopen peíst – jako v pípad uití
syslogových aplikací, nebo je nutné vytvoit novou definici, podle které budou
dleité informace od neznámého koncového zaízení pijímány. Druhá zmínná
metoda bude nyní blíe specifikována.
Vytvoení sbrové metody na míru konkrétní aplikaci nebo zaízení je procesem,
který je mnohdy na delší dobu, ne by se mohlo zdát. V první ad je nutné
24
prozkoumat syntaxi, v jaké jsou logovací záznamy zasílány a také, zda si udrí
jednotnou formu po celou dobu zasílání. Pokud je splnna homogenní podoba
formátování, pichází na adu vytvoení regulárních výraz, které budou souástí
parserové extenze. Extenze musí být nadefinována pesn na atributy, které je
poteba ze zdroje log získat, ím více takovýchto atribut v záznamu je, tím
horší je správn nadefinovat parser. Proces parsování log je pedmtem další
ásti práce.
Jak lze vidt výše, jak metoda push, tak pull mají svá nesporná pozitiva pi
správném uití. V praxi se systém setkává s nespotem rzných koncových
zaízení, z toho dvodu se pro sbr vtšinou pouívá kombinace vícero metod
dohromady v závislosti na druhu koncového zaízení, frekvencí, s jakou je nutné
z nj získávat nebo generovat informace a objemem dat, jaký bude do SIEM
systému zasílat.
3.4.3 Normalization and parsing of logs
V tomto okamiku u jsou koncová zaízení napojena na SIEM aplikaci, do které
zasílají své logovací záznamy. Nicmén problém spoívá v syrovém naturálním
stavu záznam, které SIEM neumí peíst. Z toho dvodu je uit proces, pi
kterém jsou všechny píchozí záznamy pevedeny na jednotný formát, tento
proces se nazývá normalizace. Bhem normalizování je mimo jiné moné pouít
ji zmínný parser, který ze záznamu dokáe vyfiltrovat pouze dleité atributy a
informace, které jsou stejní pro zvýšení povdomí o síové infrastruktue.
3.4.4 Rule engine and correlation engine
Efektivita analýzy log z koncových zaízení je do jisté míry závislá na kadé ze
stejních souástí SIEM. Tento engine pod sebou zdruuje funkcionalitu
korelaních proces – tyto procesy fungují na bázi pravidel. Korelaní procesy
jsou jedním z prvl, který posouvá analýzu a predikci na další úrove. Korelaní
stroj je toti schopen vzít v potaz desítky atribut a vyvozovat díky tomu
pesnjší predikce bhem bezpenostních událostí a incident. Informace pro
korelaní analýzu pocházejí z normalizovaných dat, kterými je SIEM plnn. Mimo
zkoumání širšího kontextu problému je korelaní stroj schopen také pomrn
dobré redukce false positive, zejména díky srovnávání tolika atribut. Korelaní
stroj se opírá o definovaný ruleset pravidel, který rovn usnaduje manipulaci
s píchozími záznamy. Pravidla jsou definována jakoto „what – if“ podmínky
s datovým typem boolean. Konkrétní typ pravidel se liší v závislosti na prostedí,
ve kterém je SIEM zprovoznn. Pravidla mohou být jednoduchá nebo
komplexnjší, dle poteby a mohou do sebe vnoovat další pravidla s nimi
asociované. V pípad naplnní podmínky je moné v rámci SIEM aplikace
nadefinovat rozdílné spektrum odezvy. Spuštní pravidla je dvodem pro
otevení tzv. offense (bezpenostního incidentu), které je pak nutné prošetit
25
pomocí ji zmínného korelaního stroje a rovn také konzultantem spravující
prostedí SIEM.
piloeném schématu pedstavující postup pi pihlašování pes úet
s administrátorskými pravomocemi.
3.4.5 Log storage
Log storage je prvek SIEM, který je nezbytnou souástí architektury. Pi
mnoství, s jakým jsou generovány objemy dat je nutné, aby byla tato data nkde
skladována a mohla být pouita pro pozdjší vyuití. Úloišt však krom
pijatých logovacích záznam ukládá také operace týkající se transakcí nebo
systémové povahy. Uloené záznamy slouí pro úely interního auditu (dodrení
politiky o povinné délce uchování dat) a analýz pi výskytu bezpenostní události
i incidentu.
SIEM je schopen uchovávat píchozí záznamy temi níe rozvedenými zpsoby:
• Database
Nejvíce vyuívaným zpsobem pro ukládání dat v SIEM je jednoznan
databáze. Z pravidla jsou uívány klasické druhy databázových platforem jako je
Microsoft SQL, Oracle nebo MySQL. Nejvtší výhoda uití databáze tkví
26
v relativn jednoduché interakci a zptného vytaení uloených dat z databáze
pro úely analýz. Výkonnostní parametry jako je rychlost pístupu nebo
vyhledávání v databázi se pak odvíjí od kvality hardwarových komponent, které
jsou v implementaci uity.
Druhý zmínný zpsob, flat text file, je v podstat textový soubor, který je
peveden do formátu, který je více „user-friendly.“Jednotlivé informace jsou
oddleny njakým druhem parseru, a u se jedná o árku, stedník nebo teku.
itelnost patí k nesporným výhodám této metody, nicmén tato metoda má i své
nevýhody. Za tu nejvtší by se dala povaovat nemonost scalování pro vtší
infrastrukturu, rovn je logické, e s pibývajícím mnostvím dat se bude pímou
úmrou zvyšovat reakní as pi tení nebo zápisu dat do souboru a bezpenost
soubor je v porovnání s databází také výrazn niší.
Posledním zpsobem ukládání záznam je do soubor uívající binární formát,
který je na rozdíl od jiných druh textových soubor pro uivatele neitelný, díky
emu má tato varianta lepší bezpenostní aspekt. Krom toho je uíván pi
penosu (zpravidla protokol TCP) kontrolní souty, které díky zptné kontrole ji
zmínný bezpenostní aspekt ješt umocují.
3.4.6 Monitoring
Je finální ástí v anatomii SIEM, piem se jedná o metodu interakce se
záznamy, které jsou uloené v SIEM systému. V moment, kdy jsou záznamy
normalizovány a procesovány, je nutné udlat nco uitené s informativními
výstupy, které jsou z log získány. Souástí SIEM technologie je také uivatelský
interface, ve kterém je moné vizuáln interagovat se získanými daty. Díky
slouení informací ze všech pipojených koncových zaízení je mnohem lehí
analyzovat data nebo vytváet ruleset aplikovatelný na rzné ásti infrastruktury
dle poteby.
Po detailním definování SIEM princip a funkcionality jeho architektury budou
nyní zmínny konkrétní SIEM aplikace, které budou souástí pípadových studií
v praktické ásti práce. Pro úely práce byly vybrány níe zmínné SIEM
aplikace:
Tyto aplikace byly vybrány na základ vyhovujících kritérií v oblasti
škálovatelnosti, výkonu, a pedevším z dvodu aplikace princip user behavior
analysis (behaviorální analýzy), která jakoto modulární souást tchto SIEM
aplikací bude stejním pilíem této práce. Jako další kritérium pro zvolení lze
zmínit také vysoké skóre v Gartnerov magickém tyúhelníku pro problematiku
SIEM. QRadar byl zvolen jako nejlepší volba ji nkolik let za sebou a kvalitativní
skóre AlienVaultu rovn kadým rokem stoupá. Posledním kritériem bylo
vytvoení kontrastu mezi komerním a open-source SIEM ešením a korelovat
kvalitu jejích funkcionality.
IBM Security QRadar SIEM je komerním SIEM ešením distribuované firmou
IBM. Pedchozím distributorem byla firma Q1 Labs. IBM integrovala QRadar do
svého portfolia, co pineslo zvýšení funkcionality v rámci propojení s dalšími
dílími systémy, zvýšení škálovatelnosti ešení.
QRadar bí na operaním systému Red hat enterprise Linux 7 64 bit. Aktuáln
se pouívá QRadar verze 7.3.1.
Samozejmostí ešení je vysoká škálovatelnost implementace, a u se jedná o
nasazení fyzických i virtuálních appliance, rozliné škály dostupného hardware
nebo rozdlení infrastruktury na více lokací.
Pro úel práce není zcela stejní definovat konkrétní implementace QRadaru
nebo uité appliance, z toho dvodu bude pouze zmínna architektura a
výkonnostní aspekty mající vliv na optimální fungování modulu uivatelské
analýzy, který bude souástí praktické ásti práce.
V pípad zájmu o konkrétní implementace je moné nahlédnout do bakaláské
práce, která je nepímým pedchdcem této práce.
4.1 Architektura IBM Security QRadar SIEM
Pro vtší pehlednost je architektura QRadaru rozdlena na nezbytné a volitelné
logické prvky. Nezbytné logické prvky jsou nenahraditelné pro optimální
funknost, kdeto voliteln nasaditelné prvky jsou schopny zvýšit funkcionalitu
konkrétních souástí systému nebo zrychlit jejich procesování.
Nezbytné logické prvky
• Data Node
zpracování dat v prostedí IBM Security QRadar SIEM.
Obrázek 10 - QRadar architektura, pevzato a upraveno (IBM corp., 2018)
Pod pojmem flow collector si lze pedstavit komponentu sbírající datový tok
z infrastruktury, datové packety, které jsou sbírány, pedstavují komunikaci nebo
kooperaci port a IP adres komunikující pomocí konkrétního protokolu
(TCP/UDP, SFTP, …). V závislosti na konkrétním druhu kolektoru je pak tato ást
schopna rozpoznávat identitu datových packet a do 4. nebo i 7. ISO/OSI vrstvy.
Tento proces je dleitý pro tvorbu QRadar asset a zvyšování povdomí o
pvodu komunikace v síti. Kolektory jsou rovn schopny sbírat informace mimo
infrastrukturu.
Event collector plní funkci kolekce log ze zdrojových zaízení a u lokálních
nebo vzdál