Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Problematika vulnerability managementu a jeho řešení v korporaci
BAKALÁŘSKÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Aplikovaná informatika
Autor: Filip Stehno
Vedoucí bakalářské práce: Ing. Ladislav Luc Praha, květen 2021
Poděkování
Rád bych poděkoval vedoucímu mé práce Ing. Ladislavovi Lucovi za trpělivost a odborné konzultace.
Abstrakt
V práci bude popsán vulnerability management v kontextu informační bezpečnosti. Cílem práce bude vytvoření automatizace procesu správy zranitelností v rámci IT infrastruktury vybrané korporace. Přínosem této práce bude analýza procesu správy zranitelnosti ve velké společnosti a následný návrh a realizace automatizace. Práce bude strukturovaná do teoretické a praktické části. Teoretická část bude obsahovat uvedení do bezpečnosti, seznámení se zranitelnostmi, popis vulnerability managementu a osvědčených postupů, jak se řeší. Praktická část se zaměří na IT prostředí konkrétní společnosti a návrh a řešení procesu řízení zranitelností pomocí automatizace.
Klíčová slova
zranitelnost, řízení, bezpečnost, kyberprostor, hrozba
JEL klasifikace
O20, O30, O31
Abstract
The vulnerability management in the context of information security will be described in this thesis. The aim of the thesis is creating automatization process of vulnerability management within IT infrastructure of chosen corporation. The main contribution of this thesis will be the analysis of vulnerability management within large corporation followed by proposition of automation implementation. The thesis will be divided into theoretical and practical part. Theoretical part will contain introduction into security and vulnerability, description of vulnerability management and proven procedures that deal with vulnerability management. Practical part will focus on IT environment of a specific company and proposition of managing process of vulnerability management by means of automation.
Keywords
vulnerability, management, security, cyberspace, threat
JEL Classification
O20, O30, O31
Obsah
Úvod ... 7
1 IT bezpečnost ... 8
1.1 Bezpečnost IS/ICT ... 8
1.2 Kybernetická bezpečnost ... 10
1.2.1 Kyberprostor ... 11
1.2.2 Kybernetická hrozba a útok ... 12
2 Vulnerability management ...16
2.1 Proces správy zranitelností ... 18
2.1.1 Identifikace... 18
2.1.2 Hodnocení ...19
2.1.3 Řešení ...19
2.1.4 Hlášení ...19
2.2 Zranitelnost ... 20
2.2.1 Osvědčené postupy ... 22
3 Vulnerability management v T-Mobile Czech Republic a.s. ... 23
4 Automatizace vulnerability managementu v T-Mobile Czech Republic a.s. ... 25
4.1 Specifikace požadavků... 26
4.1.1 Funkční požadavky ... 26
4.1.2 Nefunkční požadavky ... 26
4.2 Návrh ... 27
4.2.1 Databáze ... 27
4.2.2 Skript ... 30
4.3 Implementace ... 31
4.4 Demonstrace ... 35
4.5 Nasazení ... 39
4.6 Údržba ... 40
4.7 Hodnocení ...41
Závěr ... 43
Použitá literatura ... 44 Přílohy ... I Příloha A: Zdrojový kód vyvinutého skriptu ... I Příloha B: SQL příkazy potřebné pro vytvoření databáze ... I
Seznam zkratek
BP bakalářská práce
FIS Fakulta informatiky a statistiky IT information technology
ICT information and communications technology CVSS common vulnerability scoring system
WAF web application firewall DoS denial of service
DDoS distributed denial of service XSS cross-site scripting
IS information systems SQL structured query language
CVE common vulnerabilities and exposures OTRS Open-source Ticket Request System
dCERT Deutsche Telekom computer emergency response team API application programming interface
CSV comma-separated values
CISO chief information security officer PoC proof of concept
Úvod
Vymezení tématu a důvod výběru tématu
Tématem mé práce je problematika vulnerability managementu a jeho řešení v korporaci.
Zabývám se také kybernetickou bezpečnosti, kyberprostorem a hrozbami s nimi spojenými.
Moje motivace k výběru tohoto tématu byla zejména rozšíření mých znalostí tykající se kyberbezpečnosti, a hlavně vulnerability managementu. Jeho základy jsem měl šanci získat v rámci mého zaměstnaní jako speciality IT bezpečnosti v T-Mobile Czech Republic a.s.
Z toho pramení i výběr mojí praktické části spojené s automatizací vulnerability managementu v T-Mobilu.
T-Mobile jsem si vybral, protože skupina Deutsche Telekom stále rozšiřuje svoje působení v rámci kybernetické bezpečnosti. Český T-Mobile díky tomu disponuje oddělením IT bezpečnosti, které v době psaní práce čítá již přes 50 zaměstnanců. Takto velké bezpečností oddělení není dle mého názoru v Česku příliš běžné a je porovnatelné pouze s pár společnostmi zaměřujících se výhradně na kybernetickou bezpečnost. Kvůli vysoké míře spolupráce mezi operátory v Deutsche Telekom, a jejich sdílené divizi s názvem Telekom Security, je možné mezinárodně spolupracovat na bezpečnosti celé skupiny, ale také kooperovat na významných B2B zakázkách po celém světě a plně tak využívat synergií napříč jednotlivými teamy.
Cíl práce
V práci bude popsán vulnerability management v kontextu informační bezpečnosti. Cílem práce bude vytvoření automatizace procesu správy zranitelností v rámci IT infrastruktury vybrané korporace. Přínosem této práce bude analýza procesu správy zranitelnosti ve velké společnosti a následný návrh a realizace automatizace. Práce bude strukturovaná do teoretické a praktické části. Teoretická část bude obsahovat uvedení do bezpečnosti, seznámení se zranitelnostmi, popis vulnerability managementu a osvědčených postupů, jak se řeší. Praktická část se zaměří na IT prostředí konkrétní společnosti a návrh a řešení procesu řízení zranitelností pomocí automatizace.
Způsob dosažení cíle
Pro naplnění vytyčených cílů bude nezbytné nejdříve z literatury získat teoretické znalosti o IT bezpečnosti, vulnerability managementu a způsobech jeho řešení. Následně budu muset nastudovat prostředí T-Mobile Czech Republic a.s. a projít způsoby, kterými je v T-Mobilu vulnerability management řešen. Poté provést jejich analýzu a určit, která oblast je nejvíce neefektivní a skýtá největší prostor pro automatizaci. Vybrat vhodné zpracování a uložení dat pro účely automatizace a následně ji za dodržení stanovených podmínek realizovat.
1 IT bezpečnost
V literatuře se můžeme setkat s mnoha oblastmi týkajících se počítačové bezpečnosti. Já jsem nejčastěji narazil na bezpečnost IS/ICT, kybernetickou bezpečnost a bezpečnost informací. Jednotlivé pojmy mají mnoho definic. Níže uvádím základní popis těchto oblastí:
• Bezpečnost informací – Zabývá se tím, jak bezpečně pracovat s informaci ve všech formách, nejen v digitální. [5]
• Bezpečnost IS/ICT – Chrání informační systémy, informační technologie, komunikační technologie, digitální data, informace a služby. [5]
• Kybernetická bezpečnost – Zaobírá se bezpečností v kyberprostoru. Kyberprostor je globální síť tvořená zařízeními, které využívají síťové protokoly a vzájemně spolu komunikují. [8]
1.1 Bezpečnost IS/ICT
Bezpečnost IS/ICT je oblast zabývající se ochranou počítačů, počítačových sítí, aplikací a dat ve společnosti. Přesněji jsou to strategie a technologie které mají za úkol znemožnit neoprávněný přístup, poškození nebo krádež IS/ICT prostředků a dat. Obecně řečeno chrání IS/ICT aktiva společnosti. [5]
Hrozby IS/ICT bezpečnosti se nejčastěji rozdělují do následujících skupin [5]:
• Přírodní a fyzické – požáry, přírodní katastrofy, výpadky elektřiny apod.
• Technické a technologické – hardwarové poruchy, softwarové chyby, malware
• Lidské
o Neúmyslné – nedbalost nebo neznalost při výkonu činnosti o Úmyslné
▪ Zvenku – hackeři
▪ Zevnitř – zaměstnanci nebo návštěvy
Hrozby není možné úplně odstranit, a proto je cílem bezpečnosti IS/ICT vytváření opatření, které povedou k odstranění zranitelností a tím k minimalizaci hrozeb. Bezpečnost je považována za efektivní, když je dopad a pravděpodobnost vzniku bezpečnostního incidentu snížena na pro management firmy přijatelnou úroveň. [5]
Průzkumy z roku 2019 [9] ukazují, že téměř všechny společnosti s alespoň 10 zaměstnanci mají nasazené nějaké bezpečnostní prvky. Vzhledem k rozsáhlosti ICT infrastruktury dnešních společností může být financování IS/ICT bezpečnosti velmi nákladné.
Z dlouhodobého hlediska se ji nevyplatí podceňovat, protože bezpečnostní incidenty bývají pro společnosti likvidační. Likvidace může být nejen na základě nákladů na samotný incident, ale například i zhoršením reputace firmy a následným odlivem zákazníků. [9]
Obrázek 1: ICT bezpečnost ve firmách (Zdroj: [9])
Eurostat ve firmách v roce 2019 provedl dotazníkové šetření tykající se bezpečnosti informačních a komunikačních technologií. Z Obrázek 1 můžeme vyčíst že 92 % společností, které mají více než 10 zaměstnanců a sídlí v Evropské unii mají nasazeno alespoň jedno bezpečnostní opatření za účelem zajištění integrity, autentičnosti, dostupnosti a tajnosti jejich informací a ICT systémů. Každá třetí organizace má zdokumentované ICT bezpečnostní opatření nebo postupy. Téměř čtvrtina firem tyto dokumenty vytvořila nebo provedla jejich kontrolu během uplynulých 12 měsíců. Okolo 61 % evropských společností informuje zaměstnance o jejich povinnostech v rámci ICT bezpečnosti. Jedna z pěti společnosti je pojištěna proti ICT bezpečnostním incidentům a 13 % podniků zaznamenalo problémy v důsledku bezpečnostních incidentů souvisejících s ICT. [9]
Na Obrázek 2 vidíme, že 92 % společností používá alespoň jedno ICT bezpečnostní opatření.
Nejčastějším (87 %) ICT bezpečnostním prvkem byla aktualizace a udržování aktuálnosti softwaru. Druhým nejčastějším opatřením (76 %) je vynucení silného hesla. Zálohování dat na geograficky jiném místě nebo v cloudu využívá také 76 % společností. Dalším často nasazovaným prvkem, který připívá k vyšší bezpečnosti je řízení přístupů v síti, toto opatření má nasazeno 65 % organizací. Méně, než polovina společností (45 %) ukládá logy nasbírané během bezpečnostního incidentu pro pozdější analýzu a pouze 42 % firem využívá virtuální privátní síť. Společnosti dále v menším počtu využívají šifrování dat, dokumentů a emailů (38 %), ICT bezpečnostní testy (35 %) a řízení rizik v ICT (33 %). Identifikaci a autentizaci uživatele pomocí biometriky využívá jen 10 % společností. [9]
Obrázek 2: ICT bezpečnostní opatření využitá ve společnostech (Zdroj: [9])
1.2 Kybernetická bezpečnost
Kybernetická bezpečnost nemá jednu pevně danou definici. Dle mého názoru nejpřesnější definice je popsána v dokumentu [10], kde je kybernetická bezpečnost definována takto:
„Kybernetická bezpečnost představuje souhrn organizačních, politických, právních, technických a vzdělávacích opatření a nástrojů směřujících k zajištění zabezpečeného, chráněného a odolného kyberprostoru v České republice, a to jak pro subjekty veřejného a soukromého sektoru, tak pro širokou českou veřejnost. Kybernetická bezpečnost pomáhá identifikovat, hodnotit a řešit hrozby v kyberprostoru, snižovat kybernetická rizika a eliminovat dopady kybernetických útoků, informační kriminality, kyberterorismu a kybernetické špionáže ve smyslu posilování důvěrnosti, integrity a dostupnosti dat, systémů a dalších prvků informační a komunikační infrastruktury. Hlavním smyslem kybernetické bezpečnosti je pak ochrana prostředí k realizaci informačních práv člověka.“ [10]
Výše uvedená definice se omezuje pouze na kyberbezpečnost v České republice. Nicméně kyberprostor nelze geograficky omezovat, protože je globální a neomezený a na to by se při implementaci kybernetické bezpečnosti nemělo zapomínat. [7]
Obecně se dá kyberbezpečnost vymezit následovně:
• Jejím cílem je ochrana ICT technologii, aplikací, dat a uživatelů. Dosahuje toho za pomoci softwarových, hardwarových, edukačních a zákonných prostředků. [7]
• ICT systémy a služby zohledňující kybernetické hrozby a útoky jsou připraveny řešit jejich následky a efektivně naplánovat případnou obnovu všech funkcí. [7]
Na rozdíl od IS/ICT bezpečnosti se kyberbezpečnost neomezuje pouze na bezpečnost organizací, ale zahrnuje také uživatele kyberprostoru. Všechna zařízení, která jsou součástí kyberprostoru, se mohou stát cílem kybernetického útoku.
1.2.1 Kyberprostor
Kyberprostor je globální síť bez hranic vytvořená za pomocí ICT technologií. Propojuje a umožňuje komunikaci mezi všemi zařízeními. Toho je docíleno s využitím síťových protokolů a tím se vytváří prakticky neomezený virtuální prostor jinak zvaný jako kyberprostor. Možnosti celosvětové interakce zařízení pak využívají uživatelé jednotlivých zařízení. [7]
Kyberprostor je neuchopitelný, čistě nehmotný a virtuální, ale existuje jen díky technologiím, které se vyskytují v reálném světě. Není tedy možné ho jednoduše odstranit či zakázat, je možné ho pouze omezit. Pokud by v jedné zemi vyšel zákon zakazující kyberprostor, tak ho prakticky nebude možné vymáhat. Kdyby ale vznikl zákon zakazující všechny technologie, díky kterým kyberprostor existuje, zanikl by společně s nimi i kyberprostor. [7]
Kyberprostor lze rozdělit do tří vrstev [7]:
• Fyzická – Samotný název napovídá, že obsahuje fyzické zařízení a síťově prvky v kyberprostoru. Které jsou dále kategorizovány například podle geografického rozdělení.
• Logická – Skládá se z logických síťových komponentů. Ty jsou virtuální a patří do nich logické propojení mezi jednotlivými prvky, kde prvek může být jakékoliv zařízení v kyberprostoru a logickým propojením jsou myšleny síťové komunikační protokoly.
• Sociální – Ta zahrnuje pojmy kybernetická identita a osobnost. Kybernetická identita je identifikována pomocí IP adresy, emailové adresy, telefonního čísla nebo jiných virtuálních identifikátorů. Osobnost je pak reálný člověk. Mezi kybernetickou identitou a osobností platí vazba M : N. Jedna osoba může mít více emailových adres a zároveň jednu emailovou adresu může využívat více lidí.
Druhým způsobem rozdělení kyberprostoru je podle dostupnosti dat. Takto ho můžeme rozdělit do tří skupin [7]:
• Surface Web – To jsou data a služby, která jsou běžně dostupná všem uživatelům pomocí vyhledávačů. Studie [13] uvádí, že jenom 0,03 % dat přístupných z internetu je dohledatelných pomocí vyhledavačů.
• Deep Web – V této skupině jsou data, která nelze vyhledat pomocí vyhledavačů, ale není k jejich přístupu potřeba žádné speciální zařízení nebo aplikace. Jsou to soubory chráněny heslem, neindexované části webových stránek, zdravotní záznamy, soubory uložené v privátních cloudech, ale také například emailové schránky a mnoho dalších. Podle studie [13] je tato skupina více jak 500krát větší než Surface Web.
• Dark Web – Tyto data, kromě toho že je nelze vyhledat pomocí vyhledávačů, nejsou ani přístupná bez speciálního softwaru. Jsou to data šířena pomocí peer to peer sítí, které se v tomto kontextu nazývají dakrnety. Data jsou šířena tímto způsobem, protože v dakrnetu neexistuje žádná kontrola či cenzura a všichni uživatele jsou v něm téměř anonymní. Tím pádem je to ideální místo k šíření nelegálního obsahu
a služeb. Na Dark Webu si můžete objednat například DDoS útok na vámi vybraný cíl, hacknutí emailové schránky či facebookového účtu a mnoho dalšího.
1.2.2 Kybernetická hrozba a útok
Kybernetická hrozba může způsobit únik informace, narušení integrity, potlačení služby nebo nelegitimní použití. [24]
Jirovský popisuje skupiny hrozeb takto [25]:
• Únik informací je situace, kdy osobě nebo společnosti jsou ukradeny neveřejné informace.
• Narušení integrity je stav, kdy dojde k manipulaci s daty, což znamená, že data jsou buď upravena, úplně zničena nebo poškozena.
• Potlačení služby znamená, že službu někdo úmyslně poškozuje a braní tak tomu, aby byla využívána.
• Nelegitimní použití představuje neoprávněný přístup nebo neoprávněné využití informací.
Na Obrázek 3 můžeme vidět vztahy mezi jednotlivými hrozbami.
Obrázek 3: Vztahy mezi kybernetickými hrozbami (Zdroj: 25)
Kybernetické hrozby se dají rozdělit podle několika kritérií. Prvním kritériem je zdroj hrozby, kterým může být [11]:
• Útok – Jedná se například o hrozby, kdy zaměstnanec schválně manipuluje s daty, mění konfigurace systému, vynáší data ven z firmy, ale spadají sem i kybernetické útoky, protože každý kybernetický útok je vědomá činnost nějakého člověka.
• Lidský omyl – Osoba se stane příčinou hrozby omylem. Nejčastěji se jedná o náhodně smazaná nebo zveřejněná interní data, zničený hardware nebo jakékoliv neodborné zacházení s informační technikou.
• Chyba softwaru – Software může například obsahovat chybu, která způsobí jeho neočekávané zhroucení.
• Chyba hardwaru – Může dojít například k chybě pevného disku z důvodu opotřebení materiálu.
• Zásah vyšší moci – To jsou například povodně, výpadek proudu po úderu blesku, požár a obecně všechny přírodní události nebo katastrofy.
Hrozby lze též klasifikovat na vnitřní, to jsou hrozby pocházející zevnitř organizace, a vnější, to jsou hrozby jejichž zdroj původu je mimo organizaci. Více podrobné rozdělení je ovšem podle cíle [7]:
• Důvěrnost informací – Cílem útoku je získání neveřejných informací například pomocí ukradených přístupových údajů.
• Celistvosti dat – Jde o útoky, které cílí na zhoršení použitelnosti a kvality dat.
Například jsou to útoky, které poškozují integritu databáze nebo vyvolávají chyby v systémech tak, aby systém sám poškodil data, která zpracovává.
• Dostupnost dat – Cílem útoku je způsobit nedostupnost dat. Toho lze docílit například pomocí DoS nebo DDoS útoků, které službu nebo systém poskytující data přetíží a data se tak stanou pro uživatele nedostupná. Útok může být veden také na fyzické uložiště dat. Mezi ně například patří vloupání se do serverovny nebo útok na přívod elektrické energie.
• Člověk – Cílem útoku je zneužití lidského faktoru a jeho rozhodování na základě emocí. K tomu se využívají techniky sociálního inženýrství, které spočívají v oklamání uživatele na základě vyvolaní důvěry nebo strachu. Následně dojde k odcizení přístupových údajů, osobních údajů, instalaci malwaru nebo jiné podvodné činnosti.
• Technologie – To jsou útoky, které cílí na zneužití konkrétních zranitelností hardwaru, databází, síťových prvků, aplikací a všech ostatních technologiích.
• Proces – Tyto útoky cílí na zneužití chyb v pracovním postupu.
Motivace útočníka je jedním z kritérii, které se využívají k roztřídění kybernetických útoků.
Každý útočník musí mít nějakou motivaci, aby útok vykonal. Finance jsou velmi častým důvodem k útoku. Konkrétně útočník mohl dostat zaplaceno za útok na nějaký subjekt, nebo útočí z vlastní vůle a má vidinu zisku cenných informací. Za útokem může ovšem stát i potřeba konkurenční výhody, nebo jen čistě touha po získání respektu a dokázání si svých schopností. Neobvyklý není ani útok z pomsty nebo neplnění závazku. [7]
Jedním z výše zmíněných typů útoku je DoS popřípadě DDoS. To jsou útoky cílící na přetížení služby nebo systému. [29] DoS je útok vykonaný z jedno zařízení, které dokáže vyčerpat prostředky oběti. Proti těmto útokům existuje jednoduchá obrana, a tou je takzvaný blacklisting. Jedná se o automatické zamítnutí veškeré komunikace z jednoho konkrétního zdrojového zařízení (IP adresy) na cílový server. Obrana proti DDoS útoku je složitější. Jedná se o koordinovaný útok z mnoha zařízení na jeden cíl. Zde blokace podle zdrojových IP adres nepomůže, protože se jejich seznam neustále mění. Provoz vygenerovaný útočníky musí být hlouběji analyzován a pro úspěšnou obranu je potřeba najít pro útočníky charakteristický rys, kterým je lze odlišit od standartních uživatelů. Například se může jednat o zdrojový port, cílový port, obsah packetů nebo mohou všechny zdrojové adresy útočníků pocházet z jedné země. Na základě nalezeného rysu je poté potřeba provést filtrování provozu na zařízení, které je pod útokem. Až poté se stane zařízení opět dostupné pro uživatelele.
Druhým zmíněným typem útoku je sociální inženýrství. Nejčastějším příkladem sociálního inženýrství je phishing. [27] Jedná se o emaily, ve kterých se jejich odesílatel vydává za někoho jiného. Například se může vydávat za insitituci, kamaráda nebo kohokoliv, kdo může v příjemci vzbudit důvěru. Druhým způsobem je naopak přivést oběť uměle do stresové situace a donutit jí k rychlému a nerozvážnému rozhodnutí. V obou případech je cílem útoku příjemce podvést a získat například přístup k jeho údajům nebo mu nahrát do zařízení malware. Obrana proti phishingu vyžaduje, aby byl uživatel neustále pozorný a zachoval si přiměřenou míru paranoie. Konkrétně je potřeba, aby se vždy pozorně podíval na adresu odesílatele emailu, přečetl si adresu odkazu předtím, než na něj klikne, nevyplňoval bezmyšlenkovitě kamkoliv své údaje a případné přílohy před otevřením oskenoval antivirem. Hlavně při jakémkoliv podezření kontaktoval údajného odesílatele a zeptal se, jestli mu danou zprávu opravdu poslal on. Sociální inženýrství je ovšem mnohem rozsáhlejší oblast. Spadá do něj například i útoky, kdy se útočník před pracovníkem infolinky vydává za někoho jiného a dokáže tak získat přístup například k cizímu bankovnímu účtu. Obecně jsou to útoky cílící na člověka a jeho rozhodování na základě emocí. Každá veřejně dostupná informace o oběti může být zneužita útočníkem. Obecně tedy platí, že čím méně informací jde o osobě na internetu dohledat, tím lépe. Zvýšená pozornost by měla být věnována informacím, které se dají dohledat na sociálních sítích. Ty jsou pro útočníky nejčastější zdroj informací. [26]
Posledním zmíněným pojmem je malware. To je software, který byl navržen tak, aby se v zařízení ukryl nebo škodil. Existuje mnoho druhů malwaru, jedním z nich je například trojský kůň, což je malware ukrytý uvnitř standartního programu. Na první pohled se tváří jako normální program, ale po jeho nainstalování se vytvoří zadní vrátka, která dávají útočníkovi možnost ovládat infikované zařízení. Zatímco trojského koně si musí uživatel, nainstalovat sám, počítačoví červi se replikují sami. Jejich cílem je za co nejkratší čas infikovat co největší počet zařízení. Hodně známým počítačovým červem je WannaCry. To je červ spadající do skupiny ransomware. Jeho cílem je zašifrovat všechna přístupná data, aby byla pro jejich uživatele nečitelná. Následně je uživateli nabídnuto, že pokud zaplatí útočníkovi určitou finanční částku, budou jeho data dešifrována a jemu se tím k nim obnoví přístup. [28]
Michelle Moore ve svém článku [30] uvádí trendy kybernetických hrozeb v roce 2020.
Zmiňuje například, že phishingové útoky jsou čím dál tím sofistikovanější, a to už jen díky tomu, že útočníci začínají využívat strojové učení k vytváření smysluplnějších obsahu podvodných emailu. Dalším trendem, který zmiňuje, je cryptojacking. Ten spočívá v infikování oběti malwarem, který využije maximum výpočetního výkonu oběti k těžení kryptoměn ve prospěch útočníka. Dle mého názoru je také zajímavá informace, že auta bez řidiče sice ještě nejsou běžná věc, ale aut disponujících připojením k internetu je čím dál tím více. Automobilky tuto novou vlastnost jejich automobilů využívají a rychle vyvíjejí mnoho nových funkcí. Lákají jimi nové zákazníky a snaží se tak získat konkurenční výhodu. Bohužel kromě nových zákazníků láká rychle vyvinutý a pořádně neotestovaný software i útočníky, kteří zde vidí mnoho nových příležitostí k zneužití. [30]
2 Vulnerability management
Vulnerability management, překládán jako správa zranitelností, se obecně definuje jako neustále běžící proces, který identifikuje, kategorizuje, třídí a řeší zranitelnosti IT aktiv.
U každé zranitelnosti je posouzena její závažnost a riziko, které kvůli dané zranitelnosti pro společnost vzniká. Následně jsou zranitelnosti dle firmou stanovených pravidel seřazeny k řešení podle závažnosti a rizika. Po seřazení by mělo dojít ideálně k zavedení protiopatření doporučeného tvůrci nebo komunitou. Z opodstatněných důvodů může dojít k akceptaci rizika, ke které by se mělo přistupovat pouze v případě, kdy existuje konkrétní důvod, proč nelze doporučený postup aplikovat. Případně lze k akceptaci přistoupit, když náklady na opravu jsou vyšší než riziko, které by díky nim bylo odstraněno. Cílem vulnerability managementu je nalézt zranitelnosti v co nejkratším čase a opravit je dřív, než budou zneužity. [17]
Zranitelnosti v síti organizace jsou pro útočníky tím nejžádanějším cílem. Tyto zranitelnosti mohou být zneužity k neautorizovanému přístupu. Jakmile útočník pronikne do systému, může začít vyhledávat čísla kreditních karet, zdravotní záznamy, osobní informace a obecně vše, co má na černém trhu nějakou hodnotu. Kromě dat, která jsou uložena přímo na kompromitovaném stroji, může útočník využít ovládnutý stroj jako vstupní bod do interní sítě a vést z něj útoky na další stroje, které předním byly chráněny firewallem. V neposlední řadě útočníkem ovládaný stroj může být zneužit jako prostředník k útoku na další organizace. [20]
Nové zranitelnosti jsou bezpečnostními specialisty nacházeny s rozdílnou četností v závislosti na kvalitě a komplexitě programů prakticky neustále. Může jít o chyby obsažené přímo v kódu aplikací nebo jejich nesprávnou konfigurací. Toto následně vede k riziku zneužití chyby útočníkem. Proto by se správou zranitelností měly zabývat všechny organizace, nehledě na jejich velikost nebo oblast ve které působí. Nasazením vulnerability managementu bude mít podnik aktuální přehled o zranitelných strojích v jejich infrastruktuře a míře rizika, které se díky těmto zranitelnostem vystavuje. [19]
Organizace SANS v dubnu 2019 provedla průzkum [22] ohledně pozornosti, kterou firmy věnují zranitelnostem v jejich IT infrastruktuře. Dotazovány byly firmy různých velikostí od malých s méně jak 100 zaměstnanci až po nadnárodní korporace s více než 100 000 zaměstnanci. Největší pokrok oproti průzkumu z roku 2015 [23] lze pozorovat v oblasti pravidelnosti skenování infrastruktury. Více jak polovina (57,5 %) společností provádí skeny na měsíční a téměř čtvrtina společnosti (24,9 %) provádí skeny ještě častěji, a to na týdenní bázi. [22]
Z Obrázek 4 lze vyčíst, že 83,8 % firem se věnuje správě zranitelností. Z toho 54,7 % má s řešením spojený oficiální proces a 29,1 % firem zranitelnosti řeší bez oficiálního procesu.
Necelých 15 % společností v současnosti nemá stanovený postup vztahující se ke správě zranitelností, ale plánuje ho vytvořit během následujících dvanácti měsíců. Pouze 1,5 % firem se stále nevěnuje zranitelnostem jejich systémů a ani se jimi neplánuje v budoucnosti zabývat. [22]
Obrázek 4: Využití vulnerability managementu ve firmách (Zdroj: [22])
Stanovení rizika může být velmi obtížné, pokud společnost neví, jaký má zranitelnost dopad na jejich systém. Proto je při určování rizika uvažováno více kritérii. Na Obrázek 5 můžeme vidět, že tím nejčastějším (81,2 %) je závažnost stanovená pomocí CVSS. Hned na druhém místě (66,2 %) je důležitost systému pro chod firmy. Čím kritičtější systém pro firmu je, tím je jakákoliv jeho zranitelnost pro firmu rizikovější a musí být řešena s vyšší prioritou. Více jak polovina společností (53,6 %) využívá také hodnocení zranitelnosti obdržené z informačních kanálů o hrozbách a zranitelnostech. Poslední podstatnou okolností je podle průzkumu vyjádření vývojářů a jimi stanovená výše rizika zranitelnosti. [22]
Obrázek 5: Faktory využité při stanovení rizika plynoucího ze zranitelnosti (Zdroj: [22])
Obrázek 6: Přehled, jaký podíl společností spouští authenticated skeny (Zdroj: [22])
Authenticated skeny jsou skeny, kdy skener má přístup do systému a může skenovat i časti systému, které jsou pro nepřihlášeného uživatele skryté. Tento druh skenu je doporučován, protože zvyšuje přesnost a snižuje čas potřebný na ověření pravosti skenem nalezených zranitelností. Důležité ovšem je, aby na sken byl vyhrazený speciální uživatel, který má pouze oprávnění, která jsou nezbytná k provedení skenu. Na Obrázek 6 lze vidět, že skoro třetina (30,3 %) organizací takto skenuje všechna svá zařízení. Druhá třetina (34,9 %) využívá tento typ skenu na všech systémech s architekturou klient-server. Firem, které nevyužívají skeny s přístupem do systému, je pouze 15,2 %. [22]
2.1 Proces správy zranitelností
Proces správy zranitelností můžeme rozdělit do 4 navazujících kroků, které se opakují v nekonečném cyklu.
2.1.1 Identifikace
Identifikace zranitelností se obvykle provádí za pomoci skenovacích nástrojů. Tyto nástroje jsou schopné pouze detekovat zranitelnosti uložené ve své databázi, kterou je proto potřeba pravidelně aktualizovat. Frekvence a rozsah aktualizací se liší v závislosti na produktu.
Výběr kvalitního skeneru je klíčový pro správnou funkci vulnerability managementu. Proces skenování začíná tím, že správce skeneru vloží rozsah IP adres, které mají být oskenované, do skeneru. Skener poté dokáže zjistit jaká zařízení se v daném rozsahu nacházejí, jaké mají otevřené porty a jaké služby na daných zařízeních běží. Získané informace porovná se svojí databází zranitelností a vyzkouší, jestli jsou jím evidované zranitelnosti na zařízeních aktivní. Velmi důležitým předpokladem pro relevantní výsledky skenu je umístění skeneru v síti. Skener musí být v zóně, ze které má prostup na všechny zařízení. Pokud to není možné, skener by měl mít přístup alespoň na všechny produkční systémy, které jsou nezbytné pro fungování společnosti. Sken by měl být vhodně naplánován mimo dobu nejvyššího vytížení systémů a sítě. Většinou je vhodné ho provádět mimo pracovní dobu a servisní údržbu. [20]
2.1.2 Hodnocení
Skenery mají vysokou přesnost, ta ale určitě nedosahuje 100 %, proto je nutné důkladně ověřit, že nalezené zranitelnosti jsou detekované správně a na strojích se opravdu nacházejí.
Jakmile je zranitelnost potvrzena, následuje vyhodnocení její závažnosti. K posouzení závažnosti napomáhají různé indexy. Tím nejznámějším je CVSS. Indexy vznikají na základě obtížnosti zneužití, co zneužitím případný útočník získá a dalších faktorech. Indexy nezahrnují kontext zranitelnosti v rámci společnosti. Společnost sama musí vyhodnotit důležitost systému s ohledem na to, jestli je zranitelný stroj kritický pro společnost, dostupný z internetu a dalších vlastností. Tímto úkolem je obvykle pověřeno oddělení IT bezpečnosti, které všechny dostupné informace musí spojit dohromady a finalizovat seznam zranitelných zařízení. Tento seznam je seřazen sestupně podle závažnosti a určuje pořadí, v jakém budou zranitelnosti řešeny. [17]
2.1.3 Řešení
Společnost má na výběr z dlouhodobé řešení, krátkodobé řešení a akceptace. Může dojít i ke kombinaci těchto řešení. Nejlepší, ale ne vždy aplikovatelné, je řešení dlouhodobé, které spočívá v úplném odstranění zranitelnosti opravou aplikace nebo rekonfigurací. Nemožnost aplikace dlouhodobého řešení může být zapříčiněna například expirací licence, nekompatibilitou nové verze aplikace s jinými aplikacemi nebo nepřijatelnou výši nákladů na aktualizaci. [17]
Krátkodobé řešení se využívá v případě, kdy vývojáři nevydali záplatu, která zranitelnost opravuje. V tomto případě většinou vývojáři vydají doporučená opatření, která vedou k omezení zranitelnosti. Využívá se také v případě, kdy se blíží ukončení aplikace a nevyplatí se do ní již více investovat. Krátkodobá řešení spočívají v snížení rizika zneužití nebo dopadu zneužití na aplikaci. Toho lze dosáhnout například rekonfigurací systému, vypnutím některých funkcí nebo u webových aplikací ochranou pomocí WAF. [17]
Poslední možností je akceptace rizika. Ta může nastat po aplikování krátkodobého řešení, kdy je riziko sníženo na přijatelnou úroveň a dojde tak k částečné akceptaci. V tom případě se z krátkodobého řešení může stát dlouhodobé, protože již není vyžadována oprava.
Opakem je úplná akceptace, ke které se přistupuje, když řešení zranitelnosti je nákladnější než incident, který díky ní může vzniknout nebo zranitelnost z nějakého konkrétního důvodu nelze řešit. [17] V obou případech firma zanese zranitelnost do registru rizik. Ten obsahuje všechna akceptovaná rizika a ke každému riziku je evidován minimálně popis, dopad, výše rizika, od kdy do kdy je riziko akceptováno, pokud je akceptováno jen dočasně, kdo je jeho vlastníkem a plán obnovy pro případ zneužití zranitelnosti. [21]
2.1.4 Hlášení
Stav jednotlivých zranitelností by měl být neustále sledován a všechny podstatné změny by měly být hlášeny stakeholderům. Jen tak bude zaručeno, že zranitelnost nebude opomenuta. Obzvláště u hodně kritických zranitelností nebo u zranitelností které postihují mnoho strojů, je klíčové dohlédnout na to, aby byla oprava dotažena do úplného konce.
Osoby zodpovědné za opravu musí nahlásit bezpečnostnímu oddělení, že oprava byla
dokončena. Bezpečnostní tým následně spustí sken na dříve zranitelné stroje a teprve až sken potvrdí, že stroje už nejsou zranitelné, může být zranitelnost považována za opravenou.
Pokud by sken opět nalezl zranitelnost, která je od správců nahlášená jako opravená, je nutné ověřit, zda byla oprava provedena správně. Může se ovšem stát, že sken odhalí i nové nebo dříve opravené chyby. V tomto případě je nutné opět projít celým procesem. [17]
2.2 Zranitelnost
Chyby jsou běžná součást lidského život a člověk se jich dopouští i během vytváření, nasazování a používání softwaru. Chyby nejsou samy o sobě zranitelnostmi, abychom je mohli za zranitelnosti považovat, je nutné, aby existoval způsob, jak je zneužít k neoprávněným operacím. [7]
Zranitelnosti mohou být zneužity mnoha způsoby. Těmi nejčastějšími jsou SQL injection, přetečení paměti, XSS a různé veřejně dostupné exploity. Existují dva seznamy nejčastějších a nejzávaznějších zranitelností. Ten první [33] je od organizace OWASP a eviduje 10 nejčastějších a zároveň nejzávažnějších zranitelností aplikací. Poslední verze je z roku 2017 a má na prvním místě kategorii injection. První místo znamená, že by se vývojáři měli na tento druh zranitelnosti co nejvíce zaměřit a udělat vše pro to, aby jejich kód nebyl vůči tomuto útoku zranitelný. Injection zranitelnost spočívá v tom, že aplikace dostatečně nekontroluje vstupy od uživatele a uživatel je tím pádem schopný jí podstrčit příkaz nebo dotaz. Tím je útočník schopen spustit na serveru svoje příkazy a v těch nejhorších případech dokonce úplně převzít kontrolu nad strojem, nebo pomocí upravených dotazů získat data, ke kterým by neměl mít přístup. Oba scénáře mohou být pro firmu likvidační, s čímž také koresponduje umístění tohoto typu zranitelnosti na první místo. Na druhém místě jsou zranitelnosti spojené s nefunkčním ověřováním. Nesprávně implementované přihlašování a správa relací jsou velmi častým problémem dnešních aplikací. Útočník je poté schopný prolomit hesla, klíče, nebo tokeny relací k dočasnému nebo trvalému převzetí kontroly nad cizími účty. Třetí skupina zahrnuje zranitelnosti, které způsobují nedostatečnou ochranu citlivých dat. Nedostatečná ochrana spočívá v ukládání dat v čisté podobě bez jakéhokoliv šifrování, šifrování slabým algoritmem, který může být snadno prolomen, nedostatečně chráněnými privátními klíči, nebo příliš krátkými klíči. Útočník si tak při získaní přístupu může nešifrovaná data přečíst buď ihned, nebo po vynaložení malého úsilí. Správně by citlivá data měla být uložena tak, aby ani při jejich případném úniku nebyla čitelná. [33]
Druhý seznam [34] vytváří organizace MITRE a je v principu stejný jako již zmiňovaný seznam. Akorát místo 10 zranitelností jich uvádí 25. Poslední verze vyšla v roce 2020 a na jejím prvním místě je XSS. Zde můžeme mezi jednotlivými seznamy pozorovat rozdíl, protože seznam od OWASPu umístil XSS až na páté místo. Zranitelnost typu XSS jsou stejně jako u injection zranitelností zaviněny nedostatečnou kontrolou vstupu od uživatele. Tento vstup je pak využit při generovaní stránky a aplikace nezabraní, aby v obsahu vstupu byl prohlížečem spustitelný kód. Kód se následně uživateli pří zobrazení stránky spustí a ve většině případů odešle id jeho relace útočníkovi a ten tak získá kontrolu nad jeho účtem. Na druhém místě v seznamu můžeme najít zranitelnosti spojené s pamětí aplikace. Jedná se o chyby v kódu, kdy jsou opět nedostatečně ošetřené vstupy a při zadání jiného, než očekávaného vstupu dojde k chybě aplikace a ta se může například zhroutit, nebo si přespat
část své paměti. Zmíním ještě třetí místo, na kterém je obecná kategorie nedostatečné validace vstupů. Do té spadají všechny zranitelnosti, které nemají svojí vlastní skupinu a tykají se útoku založených na vstupu od uživatele. Například se jedná o zranitelnost, kdy uživatel může pří nákupu zboží zadat jakékoliv množství zboží chce. Může tak zadat i záporné množství, čímž může dojít ke zhroucení aplikace. [34]
Výše zmíněné seznamy obsahují pouze kategorie zranitelností, ale neobsahují konkrétní zranitelnosti softwaru. K tomu slouží veřejné databáze a tou největší je CVE [35] od společnosti MITRE. Přispět do této databáze může kdokoliv, od bezpečnostního speciality, přes vývojáře zranitelného softwaru, až po obyčejného uživatele, který může nahlásit podezřele chování. Hodně vývojářů nabízí finanční odměny při nalezení chyby v jejich aplikaci a tím tak podporují zveřejňování nalezených zranitelností. Každá zranitelnost evidovaná v CVE má svoje unikátní identifikační číslo, podle kterého se dá snadno dohledat.
Každý záznam o zranitelnosti by měl obsahovat krátký popis, odkazy na doporučení, jak zranitelnost odstranit, zranitelnou verzi aplikace a CVSS skóre. Vývojáři si často nechají vystavit CVE identifikační číslo pro novou zranitelnost, ale záznam o ní nechají uveřejnit až po vytvoření opravy nebo alespoň postupu ke snížení rizika. Tím předcházejí zneužívání zranitelnosti jejich aplikace bez neexistujícího způsobu opravy. [36]
CVSS je celosvětově uznávaný standard vytvořený společností FIRST, který se využívá ke specifikaci závažnosti zranitelnosti. Celkové skóre se skládá ze základního, dočasného a enviromentálního skóre. Základní skóre postihuje znaky zranitelnosti, které jsou konstantní a nemění se. Dočasné zahrnuje vlastnosti zranitelnosti, které se mohou v průběhu času měnit. Enviromentální pracuje s rysy, které jsou specifické pro uživatelovo prostředí. Na Obrázek 7 můžeme vidět, že výsledné celkové skóre se pohybuje v rozsahu od 0,0 do 10,0 a vzniká ze základního skóre na které se následně může uplatnit dočasné nebo enviromentální. Kromě skóre ke každé zranitelnosti vznikne i speciálně formátovaný text, který obsahuje každou hodnotu využitou při výpočtu. [37]
Další důležitou vlastností zranitelnosti je existence veřejně dostupného exploitu. To je program, který je přesně navržený tak, že mu jen stačí zadat cíl a on už sám dokáže vykonat celý postup pro zneužití zranitelnosti. Nebezpečná podkategorie exploitu, proti kterému neexistuje ochrana, je zero-day zranitelnost. Mezi útočníky je obzvláště ceněná z důvodu vysoké míry úspěšnosti a nízké možnosti detekce při využití k případnému útoku.
Obrázek 7: Proces vytváření CVSS skóre (Zdroj: [37])
2.2.1 Osvědčené postupy
Základem úspěšného vulnerability managementu je kvalitní inventář IT aktiv. Přesněji úplný, detailní a aktuální seznam zařízení, aplikací a jejich správců. Jen tak může bezpečnostní oddělení efektivně skenovat a řešit zranitelnosti v podnikové infrastruktuře.
Jedním z kroků k udržení kvalitní databáze, je zavedení povinnosti instalace agenta na každé zařízení v síti. Nainstalovaný agent bude tuto databázi periodicky aktualizovat a nahlašovat veškeré aplikace a změny provedené na zařízeních. [42]
Důležité je také, aby skenovací nástroj byl vhodný pro danou společnost. Měl by být schopný detekovat zranitelnosti na všech systémech, které jsou pro společnost kritické. Neměl by mít vysokou míru falešně pozitivních nálezů, a hlavně by měl být pravidelně aktualizován.
Skenovací systém, jehož dodavatel neposkytuje časté aktualizace databáze detekovatelných zranitelností, je nedostatečným přínosem pro bezpečnost firmy. Podstatné je mít co možná nejaktuálnější databázi, aby byl bezpečností tým schopen detekovat zranitelnosti dříve, než je naleznou a zneužijí útočníci. Důležitým faktorem je také umístění skenovacího nástroje v síti. Pokud skenovací nástroj nebude mít neomezený síťový prostup na všechna zařízení, budou jeho výsledky nepřesné a bude poskytovat neúplný přehled zranitelností v podnikové síti. Skenování by mělo probíhat pravidelně a ideálně by měla být na denní bázi oskenována alespoň část infrastruktury. [43]
Firma by si měla stanovit pro ní nejkritičtější systémy a na nich by kromě normálních skenů měly probíhat také authenticated skeny. Ty jsou přesnější a dokážou odhalit i zranitelnosti, které jsou pro skeny bez přihlášeného uživatele skryté. [42]
Klíčem k úspěšnému odstraňování zranitelností je jejich prioritizace. Správce zranitelné technologie musí znát prioritu opravy jednotlivých zranitelností. Není dobré správce zahltit rovnou celým seznamem zranitelností. Postupné dávkování od nejkritičtějších zranitelností má za účinek rychlejší snížení rizika. [42]
Mezi velkými firmami ve světě získává stále více na popularitě program Bug Bounty, který přináší velmi dobré výsledky v oblasti zabezpečení. V principu pozívá etické hackery, aby hledali chyby na webech provozovatele programu a získali finanční odměnu. Chybu je nutné prakticky předvést pomocí PoC, při kterém nesmí dojít k ohrožení služeb. Program nenahrazuje skenery, ale funguje jako jejich doplněk. Se získaným PoC se následně pracuje téměř stejně jako v případě nalezení chyb ze skeneru. Rozdíl je, že chyba musí být manuálně ověřena analytikem a stejně tak i její případná oprava musí potvrzena manuálním testováním. [44]
3 Vulnerability management v T-Mobile Czech Republic a.s.
Společnost T-Mobile Czech Republic a.s. je český mobilní operátor spadající do telekomunikační skupiny německé společnosti Deutsche Telekom. Jeho největším polem působnosti je poskytování mobilního připojení, kde už má téměř 6,2 milionu zákazníků.
Kromě telekomunikačních služeb nabízí v rámci B2B segmentu i komplexní ICT řešení, od provozování a implementace celé ICT infrastruktury až po bezpečnostní dohled. [38]
Problematika vulnerability managementu je v T-Mobilu značně komplikovaná a nepřehledná. Společnost je totiž po akvizicích nedokonale spojena z mnoha společností, z nichž největší byly GTS Czech Republic a T-Systems Czech Republic. K vyšší komplexnosti přispělo i personální propojení a sdílení systémů se společností Slovak Telekom. Na harmonizaci se intenzivně pracuje, ale je to dlouhodobý a nákladný proces. Jednou ze současných obtíží je neexistence jedné úplné centrální databáze všech IT aktiv. Existuje pouze několik fragmentovaných databázích, které nejsou vždy zcela aktuální a ani úplné.
Z výše uvedených důvodů není proto nasazení vulnerability managementu ukázkově plynulé, jednoduché a časově nenáročné. Nedostatky jsou kompenzovány intenzivní prací bezpečnostních analytiků, kteří dopátrávají chybějící informace a mapují nedokumentované části sítě. Jakékoliv automatizované zpracování výsledků bezpečnostních skenů je nemožné. Správce skeneru zasílá nalezené zranitelnosti k řešení do ticketovacího systému OTRS, kde každý požadavek manuálně zpracovávají analytici.
Dohledové centrum vyvíjí konstantní tlak na správce systému a nabízí konzultace v oblasti bezpečnosti tak, aby docházelo k co nejrychlejším opravám. OTRS je primární nástroj bezpečnostního dohledu. V něm je zaznamenám veškerý postup analytiků, následná komunikace ve firmě a časová osa jednotlivých akcí. Slouží také jako nástroj pro dohlédnutí na řádné dokončení životního cyklu jednotlivých nálezů od detekce po finální opravu. Také je využíván například k auditu jednotlivých akcí.
Známka toho, že T-Mobile začíná brát vulnerability management vážně, je, že spustila veřejný Bug Bounty program [40]. Ten spočívá v tom, že externí hackeři nahlašují zranitelnosti, které naleznou na vybraných webových portálech. Bezpečnostní dohled nahlášení shromažďuje v OTRS a pokud se jim chybu podle hackerova postupu podaří zopakovat, zahájí s nimi standartní vulnerability management proces. Během něj stanoví závažnost nálezu a případnou výši odměny, kterou následně, společně s umístěním na zeď slávy, hackerovi vyplatí.
Poslední část, která zabírá analytikům nejvíce času, je preventivní hlášení zranitelností správcům systému. Vzhledem k nepřehlednosti sítě a nekompletním výsledkům skenování, se jedná o nejefektivnější způsob. Jako vstup jsou využity dCERT bezpečnostní doporučení z mateřské firmy Deutsche Telekom. Jak můžete vidět na Obrázek 8, z každého doporučení v podobě emailu se v OTRS vytvoří ticket. Těchto doporučení může během jednoho dne dorazit desítky, protože dCERT nesleduje pouze nové zranitelnosti, ale také jejich
aktualizace. Jediný filtr, který je možný nastavit, je na základě CVSS skóre. Ten má T-Mobile nastavený na 7,0. Doporučení nelze filtrovat na aktuálně používané technologie. Analytik po obdržení doporučení nejprve zkontroluje, jestli se jedná o novou zranitelnost.
Aktualizace je zajímají jen v případě, kdy si nějaký správce vyžádá více informací. Následně v excelových tabulkách začne vyhledávat, jestli T-Mobile zranitelný software provozuje a pokud ano, tak obdržené doporučení přepošle na jeho správce. K doporučení přidá prosbu o sdělení, jestli je jím spravována verze aplikace zranitelná a pokud ano, tak kdy a jak bude opravena. Případně pokud nemůže být opravena, tak prosí o sdělení důvodu, proč tomu tak je. V případě ignorace prosby je ticket po 48 hodinách eskalován.
Po provedení analýzy statistik ticketovacího systému, jsem identifikoval, že nejdéle trvající operací v rámci procesu adresování dCERT doporučení je vyhledávání správce softwaru.
Tato operace v průměru zabere analytikovi na jeden ticket 15 minut. Analytik této činnosti, při průměrném zpracování 8 ticketů denně, věnuje denně 2 hodiny. Druhou nejdéle trvající činností je procházení ticketů a kontrolování, jestli se jí správce zranitelnosti věnuje. Každá kontrola v průměru zabere 2 minuty a analytik musí takto denně projít průměrně 20 ticketu.
Z toho vychází, že touto činností stráví denně 40 minut. Naopak jako nejméně časově náročné se ukázalo každodenní potvrzení přijetí nových doporučení. Tím analytik stráví průměrně 1 minutu denně.
Současný stav je značně neefektivní z důvodu neautomatizovaného zpracování informací a klade obrovské nároky na práci a čas analytiků. Nejsou k dispozici žádné specializované nástroje, které by zefektivnili práci a většina informací je zanesena v tabulkách Excel.
Obrázek 8: Ukázka dCERT doporučení v OTRS (Zdroj: autor)
4 Automatizace vulnerability managementu v T-Mobile Czech Republic a.s.
Tato část práce se zabývá automatizací aktuálně neefektivních částí procesu vulnerability managementu v T-Mobilu. Konkrétně jeho části směřování preventivních doporučení.
Velký potenciál pro zlepšení se nachází v těchto částech:
• Pokročilé automatické třídění a rozpoznání nově přijatých zranitelností. Rozlišování aktualizací a jejich kategorizace.
• Vyřazení všech zpráv týkajících se nerelevantních a nepoužívaných technologií ihned po přijetí.
• Migrace a transformace současného stavu záznamů z tabulkových procesorů Excel do databáze SQL. Tím se umožní dramatický nárůst v efektivitě vyhledávání.
Pokročilý relační databázový model rozšíří schopnosti vyhledávací logiky a umožní přesné zacílení zasílaných informací o zranitelnostech.
• Schopnost databázového enginu v porovnání s tabulkovým procesorem umožní vykonávat souběžně vícero databázových operací a tím dojde k navýšení výkonu zpracování.
• Automatické zasílání předem definovaným adresátům povede k dalšímu zkrácení doby dodání informací nezbytných pro opravu systémů a ve výsledku zapříčiní snížení pravděpodobnosti provedení úspěšného útoku.
• Vytvoření integrace pro součinnost s ticketovacím systémem bezpečnostních analytiků dohledového centra a implementace automatického odlišení zpracovaných ticketů.
• Automatické upozornění na nutnost eskalace v případě neobdržení odpovědi.
Cílem automatizace je, aby po její implementaci došlo k znatelnému uvolnění zdrojů analytiků, které by mohly být relokovány k posílení ostatních oblastí působení dohledového centra. Analytici by měli následně mít v oblasti vulnerability managementu pouze funkci konzultační, dohledovou a eskalační. To je dle mého názoru optimální a preferovaný stav.
Na automatizaci budu pracovat sám a jelikož celý vývoj bude proveden v rámci této bakalářské práce s pěvně danými požadavky, využiji k vývoji vodopádový model, který rozdělím do těchto na sebe navazujících částí:
1. Specifikace požadavků 2. Návrh
3. Implementace 4. Demonstrace 5. Nasazení 6. Údržba 7. Hodnocení
4.1 Specifikace požadavků
V této fázi specifikuji všechny funkční a nefunkční požadavky. Pro úspěšné ukončení projektu bude muset automatizace splňovat všechny z nich.
4.1.1 Funkční požadavky
Automatizace musí splňovat následující funkční požadavky:
1. Skript automaticky zpracuje pouze nové dCERT doporučení.
2. Skript automaticky zjistí, kterého softwaru se doporučení týká.
3. Skript dohledá, jestli zranitelný software je v T-Mobilu využíván.
4. Skript bude ignorovat určitou míru rozdílnosti v názvech softwaru v dCERT doporučeních a seznamu spravovaných technologii.
5. Skript odešle upozornění na správce emailem.
6. Skript odešle upozornění pouze na ty správce, kterých se zranitelnost týká.
7. Skript odešle na každého správce upozornění na konkrétní zranitelnost pouze jednou.
8. Odeslané upozornění bude obsahovat přílohu, ve které bude původní dCERT doporučení k dané zranitelnosti.
9. Při vytváření těla upozornění bude využita šablona.
10. Šablona pro tělo upozornění bude upravitelná.
11. V OTRS ticketu bude záznam o všech odeslaných upozorněních v rámci jednoho dCERT doporučení.
12. Seznam správců softwaru bude uložený v databázi.
13. Seznam spravovaného softwaru bude uložený v databázi.
14. Mezi správcem a softwarem bude platit vazba M : N.
15. Ke každému správci bude evidovaná emailová adresa a jméno správce.
16. Ke každému softwaru bude evidován jeho název.
17. Skriptem zpracované tickety budou odlišeny.
18. Skript bude mít konfigurovatelné připojení do databáze.
19. Skript bude mít konfigurovatelné připojení na OTRS API.
20. Skript najednou zpracuje tickety v daném časovém rozsahu.
21. Skript bude mít konfigurovatelnou adresu odesílatele.
22. V OTRS budou zvýrazněné tickety, které vyžadují zásah analytika.
4.1.2 Nefunkční požadavky
Automatizace musí splňovat následující nefunkční požadavky:
1. Skript bude napsaný v jazyce Python.
2. Skript bude mít vlastní PostgreSQL databázi.
3. Skript bude mít v OTRS vlastního uživatele, který bude mít práva jen na dCERT doporučení.
4. Databázový uživatel, využívaný skriptem, bude mít pouze čtecí práva na OTRS databázi.
5. Hesla uživatelů, které skript využívá, budou mít minimálně 14 znaků.
6. Skriptu bude trvat zpracovaní doporučení přijatých během posledních 24 hodin maximálně 60 sekund.
4.2 Návrh
V této kapitole popisuji návrh struktury databáze, postup migrace dat z excelu do databáze, a specifikuji, jak bude fungovat automatizační skript.
4.2.1 Databáze
Pro migraci dat z excelu do databáze bude vytvořená nová PostgreSQL databáze.
Na Obrázek 9 můžeme vidět relační model dat, který bude využitý v nové databázi, ze kterého můžeme vyčíst, že databáze se bude skládat ze 4 tabulek. Z Obrázek 9 lze také vyčíst vlastnosti jednotlivých tabulek jako třeba které atributy budou primární klíče, ty jsou označené velkým písmenem P, a které budou cizí klíče, ty jsou označené velkým písmenem F. Popřípadě může být atribut současně cizí klíč a primární klič, tyto atributy jsou označeny kombinaci obou již zmíněných písmen tedy PF. Dále můžeme vidět, že u některých atributů je červená hvězdička, což znamená, že tato pole jsou povinná a nesmí obsahovat prázdnou hodnotu. Následně můžeme vyčíst, že mezi tabulkami team a team_soft_rel platí vazba 1 : N a mezi tabulkou software a team_soft_rel platí také vazba 1 : N. Z toho vyplívá, že team_soft_rel je relační tabulka, která eviduje, jaké technologie týmy spravují. Poslední 1 : N vazba ve schématu je mezi tabulkami software a vulnerability.
Obrázek 9: Relační model dat v nové databázi (Zdroj: autor)
První databázová tabulka se jmenuje software a bude sloužit jako seznam softwaru, který může být spravován. Pokud technologie nebude v tomto seznamu, nemůže být přidělena žádnému týmu a nebudou na její zranitelnosti odesílány notifikace. Seznam atributů
Tabulka 1: Atributy databázové tabulky software (Zdroj: autor) Název Typ Vlastnosti Popis
name varchar primární klíč název softwaru
Druhá databázová tabulka má název team a bude obsahovat seznam všech týmu, kterým může být přidělená do správy technologie. Pokud tým není zaveden v této tabulce, tak na něj skript nebude moct odesílat notifikace. Seznam atributů můžeme vidět v Tabulka 2.
Tabulka 2: Atributy databázové tabulky team (Zdroj: autor) Název Typ Vlastnosti Popis
email varchar primární klíč emailová adresa, na kterou mají být zasílané upozornění (obvykle týmový alias).
name varchar povinné pole název týmu nebo správce, který bude přijímat upozornění
owner varchar povinné pole
jméno zaměstnance, který bude kontaktován v případě jakékoliv nejasnosti spojené s daným týmem. (obvykle manažer týmu, nebo správce aliasu)
queue varchar nepovinné pole název fronty, kterou tým využívá v korporátním ticketovacím nástroji
phone varchar nepovinné pole pokud tým drží pohotovost, tak zde bude jejich pohotovostní telefonní číslo
Třetí tabulka má název vulnerability a bude sloužit jako evidence již nahlášených zranitelností. Po odeslání první notifikace bude zranitelnost zaevidována do této tabulky.
Skript bude před odesláním notifikace vždy kontrolovat, jestli již v této tabulce neexistuje záznam o zpracovávané zranitelnosti. Pokud ano, nebudou ve spojitosti s ní odeslané žádné další notifikace. Seznam atributů můžeme vidět v Tabulka 3.
Tabulka 3: Atributy databázové tabulky vulnerability (Zdroj: autor)
Název Typ Vlastnosti Popis
otrs_ticket int část složeného primárního klíče
identifikační číslo ticketu, který obsahuje dCERT upozornění na zranitelnosti uvedenou v poli soft_name
soft_name varchar
část složeného primárního klíče, cizí klíč odkazují do tabulky software na atribut name
konkrétní název softwaru, ve spojitosti, s kterým bylo odeslané upozornění na zranitelnost, která byla obsažena v ticketu s dCERT doporučením, jehož identifikační číslo je uvedeno v poli otrs_ticket
title varchar povinné pole název ticketu s dCERT
doporučením
score numeric
povinné pole, celkem maximálně 3 cifry z toho jedna za desetinnou čárkou
CVSS skóre uvedené v dCERT doporučení
Poslední tabulka se jmenuje team_soft_rel a bude obsahovat informace o tom, jaké technologie týmy spravují. Pokud zde tým nebude uvedený jako správce technologie, nebude dostávat upozornění na zranitelnosti, které se jí týkají. Jedná se o relační tabulku, která eviduje vazbu mezi tabulkami team a software. Seznam atributů můžeme vidět v Tabulka 4.
Tabulka 4: Atributy databázové tabulky team_soft_rel (Zdroj: autor)
Název Typ Vlastnosti Popis
team_email varchar
část složeného primární klíče, cizí klíč odkazující do tabulky team na atribut email
emailová adresa týmu, který spravuje software uvedený v atributu soft_name
soft_name varchar
část složeného primární klíče, cizí klíč odkazující do tabulky software na atribut name
konkrétní název softwaru, který spravuje tým, jehož emailová adresa je uvedená v atributu team_email
Všechny excelové soubory s informacemi o správcích softwaru budou spojeny do jednoho souboru, ve kterém bude zaručena unikátnost každého záznamu. Následně tento soubor bude rozdělen do tří soboru tak, aby každý vyhovoval svými daty jedné konkrétní tabulce.
První bude obsahovat data, která budou následně importována do tabulky team. Druhá bude obsahovat data pro tabulku software a poslední bude obsahovat informace, kdo spravuje, jaký software a ten bude nahrán do team_soft_rel tabulky.
4.2.2 Skript
Skript bude napsaný v jazyce Python. Bude objektově orientovaný a strukturovaný do několika souborů. V každém souboru bude deklarována maximálně jedna třída. Skript bude také obsahovat tři konfigurační soubory. První bude určen pro nastavení parametrů pro připojení do databází. Druhý bude pro nastavení parametrů pro připojení na OTRS API a v posledním se bude nastavovat adresa odesílatele upozornění, adresa, kam má být odeslána skrytá kopie každého upozornění, název fronty, kam jsou tříděny dCERT doporučení, počet minut, kolik maximálně může být ticket starý, a do jaké fronty má být skript po zpracování přesunut, aby byl odlišen od nezpracovaných ticketů. Šablona textu upozornění bude uložena v samostatném textovém souboru.
Po spuštění skript nejdříve v OTRS databázi vyhledá tickety ve frontě, která bude nastavená v konfiguračním souboru, které nebudou starší než limit daný v konfiguračním souboru.
V této frontě budou jen tickety vytvořené z přijatých dCERT doporučení. Bude následovat kontrola, jestli je doporučení nové nebo se jedná jen o aktualizaci. To se rozliší pomocí předmětu emailu, který musí začínat textem „[New]“. Pokud bude potvrzeno, že se jedná o novou zranitelnost, začne postupné zpracování ticketu. Nejdříve bude z ticketu vyextrahován seznam zranitelného softwaru. Z něho bude následně odebrána verze a zůstane jen jeho název. Poté bude název porovnán se seznamem názvů softwaru uloženým v tabulce software. Porovnání proběhne pomocí fuzzy logiky, kde minimální výše shody bude nastavená na 89 %. Při nalezení shody bude zkontrolováno, jestli už daná zranitelnost nebyla zpracována a pokud ne, tak se dohledají všichni správci daného softwaru a odešle se jim emailem upozornění. V předmětu upozornění bude číslo ticketu, který obsahuje původní dCERT doporučení a název zranitelného softwaru. Tělo upozornění se načte ze šablony uložené v textovém souboru a v příloze emailu bude původní dCERT doporučení.
Každé upozornění bude ve skryté kopii odesláno na adresu OTRS, která bude nastavená v konfiguračním souboru. Důvodem je, aby byl v OTRS u každého ticketu záznam o všech upozorněních, které ve spojitosti s ním byly odeslány. Po odeslání všech notifikací bude ticket pro odlišení od nezpracovaných ticketů přesunut přes OTRS API do nastavené fronty a bude o něm přidán záznam do databázové tabulky vulnerability.
4.3 Implementace
Celá implementace bude probíhat v testovacím prostředí, které se skládá z aplikačního serveru a databázového serveru. Oba servery mají jako operační systém nainstalovaný CentOS 7.8. Na aplikačním serveru je spuštěn OTRS ve verzi 6.0.17, který využívá Perl ve verzi 5.16.3 a Apache ve verzi 2.4.6. Na databázovém serveru je nainstalovaný PostgreSQL server ve verzi 9.6.18.
Pro umožnění strojového vyhledávání ve správcích softwaru bylo nezbytné, aby data z manuálně administrovaných excelových tabulek byla přenesena do relační databáze. Pro tento účel jsem vytvořil na databázovém serveru novou PostgreSQL databázi robot_tridic se schématem robot. Schéma robot je naimplementováno v souladu s relačním modelem, který je popsán v předešlé kapitole. Seznam tabulek, které databáze obsahuje, a ER diagram, vygenerovaný aplikací DBeaver ve verzi 7.0.3, můžeme vidět na Obrázek 10.
Příkazy využité při vytváření schématu jsou dostupné v Příloha B:.
Obrázek 10: Seznam tabulek a ER diagram databáze robot_tridic. (Zdroj: autor)
V databázích byli vytvořeni dva nový databázoví uživatelé. Prvním je uživatel robot_tridic, který je nastavený jako vlastník celé databáze robot_tridic. Druhý je uživatel otrs_ro, který má práva na čtení dat z OTRS databáze a skript ho využívá pro získávání dat uložených v ticketech.
Další skriptem využívaný uživatelem má název marvin. Jedná se o aplikačního uživatele, který byl vytvořen za účelem umožnění komunikování s OTRS API, které je využito pro přesouvání ticketů. Uživatel má práva pouze na fronty, které jsou nezbytné ke zpracování ticketů.
Do OTRS byl nainstalován eskalační modul, který automaticky zvýrazňuje tickety, u kterých více jak 2 dny nedošlo k žádné akci.
