Téma na tento článek nosím v hlavě už dlouhou dobu. Jenže jsem si nebyl jistý, zda už mám dostatek znalostí, abych o tom mohl napsat. Probral jsem to ale s pár lidmi a nakonec jsem se osmělil.
Chtěl bych se s vámi podělit o to, jak se dívám na životní cyklus bezpečnosti. Jsem spíše praktik a věci si vymýšlím/upravuji často podle sebe. Samozřejmě, že pokud najdete v něčem chybu (nebo způsob, jak to rozšířit), budu moc rád, když mi napíšete.
Podle mne, než člověk vůbec může začít řešit bezpečnost, měl by vědět, že má bezpečně udělané zálohy („Zálohování – jak nepřijít o data při útoku hackera (teorie)“ a „Zálohování – jak nepřijít o data při útoku hackera (praxe)“). Věřím totiž, že jakákoliv síť může být prolomena (sítí v celém článku označuji síť jako takovou včetně počítačů, serverů a síťových zařízení). A je potřeba s tím už takto počítat (zkuste vygooglit „assume breach“).
Na bezpečnost nahlížím jako na následující 4 kroky/fáze:
Restrikce
Fáze, které se věnuje každý. Ať již vědomě nebo nevědomě. Jsou to právě věci jako nízká uživatelská oprávnění, silná hesla, správně nastavené programy, firewall, blokované weby, antiviry, aktualizace, zakázané spouštění aplikací.
Cílem je nemít v síti ostudnou chybu (něco, co by způsobilo jednoduché prolomení sítě během pár minut), útočníkovi co nejvíce ztížit prolomení sítě a zároveň síť neudělat úplně nepoužitelnou pro uživatele.
Jaké restrikce používáme my
Jak jsem psal v článku „Standardizace – děláme IT jako Baťa cvičky“, snažíme se mít všude stejná nastavení a zabezpečení (lépe se nám to spravuje, ladí a udržuje). Zde je výčet technologií, které používáme (možná nebude úplně kompletní, lovím to z paměti).
Síťové restrikce/nastavení: dělení na VLANy, VPN, WPA2 Enterprise – založený na certifikátech, UTM (FortiGate), DHCP snooping, ARP inspection, 802.1X, DNSSEC (již brzy 😊).
Hostitelské restrikce/nastavení: SRP (software restriction policies), AD best practises (napíšu článek), princip nejnižších už. oprávnění (Principle of least privilege), antivirus (ESET vč. HIPS), firewall, vynucení silných hesel, tierování (viz Zabezpečení sítě: Tierování a PAW), silná hesla (viz „Správa hesel“ a „Správa hesel 2“), šifrování (Bitlocker), UAC (User access control).
Monitorování
Ve fázi restrikce jsme nastavili věci co nejlépe, abychom prolomení sítě ztížili. Avšak ať budeme mít síť jakkoliv nastavenou, vždy existuje možnost, že bude (nebo již je) prolomena. Otázkou tedy je, jak zjistit, že došlo ke kompromitaci sítě. Restrikce většinou pouze pasivně brání proti prolomení. Nemáme z nich zpětnou vazbu, zda již došlo k jejich překonání.
Když v rychlosti prolítnete Google a budete vyhledávat „jak dlouho trvá zjistit průnik“ („how long does it take to detect breach“), tak narazíte na spoustu článků, kde se časy poměrně liší. Já zkusím vyjít z dokumentu „M-Trends report 2018“. Průměrná celosvětová doba detekce průniku do sítě v roce 2017 byla 101 dní. To je strašně moc času! I pár hodin/dní by stačilo na to, aby útočník získal, co chce. Takhle zůstává útočník v síti ještě déle a může kontrolovat veškeré kroky / rozhodnutí / chování společnosti.
Obecně si myslím, že ten průměr může být i horší. Je řada firem, co průnik nenahlásí. A také řada firem, co o tom, že jsou kompromitované, ještě neví.
Není tedy asi tak těžké pochopit, že monitorování je třeba. Těžší je to však s realizací – JAK a CO monitorovat, aby to mělo smysl. V poslední době hodně slýchám o SIEM. U velkých korporací je to asi standard již řadu let. Přijde mi, že SIEM postupně proniká i k firmám o tisících/stovkách počítačů. Obchodníci na to pějí chválu (je to jejich práce). Ze strany techniků zase slyším, že je těžké SIEM zaintegrovat do sítě a jsou ze SIEMu zahlcení velkým množstvím dat.
Vsuvka o „velkém množství dat“
Posbírat data v současné době není problém – umí to skoro každý program. Co však lidi okolo mne řeší je, že neví, co se získanými daty dělat. Neví, které události (informace) jsou důležité a vyžadují reakci. Nebo naopak, které jsou pouze informativní a znamenají běžný stav. Pokud jste se někdy pokusili „vyčistit“ prohlížeč událostí (event viewer), určitě víte, že to není jednoduché. Událostí je tam hromada. Některé jsou důležité, i když jsou typu „informace“. Jiné jsou zbytečné, i když jsou typu „chyba“.
Obdobný příklad. V únoru jsem byl na školení od ESETu k ERAv6. Sešli se zde hlavně lidi z našeho oboru správy sítě. Školili nás interní technici ESETu. Řada lidí již používá centrální ERA server a všímavě se ptali techniků z ESETu, co mají v ERA sledovat (jaké reporty používat). Za den totiž do ERA napadají stovky událostí a jeden se v tom lehce ztratí. Přitom naprostá většina událostí je pouze informativní a není třeba na ně reagovat (např. antivirus zachytil virus v mailu – Ok, problém vyřešen. Netřeba reagovat. Ani uživatele není za co kárat, nemůže ovlivnit to, že mu někdo poslal virus.). Technici však na otázku nedokázali odpovědět. Oni sice znali bezchybně svůj produkt, ale nejspíše nikdy nepracovali jako správci sítě – tzn., neznali potřeby správců, aby jim dokázali poradit.
S takovou situací se setkávám docela často. Např. náš nový systém pro správu hesel má snad „milion“ nastavení, rozsáhlý manuál, ale nikdo nám neřekne, jak nejlépe si ten systém nastavit (koukl by nám přes rameno, jak pracujeme a rovnou vysypal z rukávu, jak jej používat). Myslím, že je to škoda, protože toto by byla obrovská přidaná hodnota prodejce.
Můj názor na velké množství dat
My také používáme ESET ERA a podobné systémy, které sbírají velké množství dat (událostí). Tyto systémy pak mají nějaké předdefinované reporty. Na nich mi však vadí, že jsou pro naše potřeby „ukecané“. V reportech je spousta informací, které jsou pro nás zbytečné (slouží spíš pro prezentaci manažerům, aby byl pocit, že IT oddělení pracuje 😊).
Pokud každý den někdo musí procházet šestistránkový report, kde jen jeden nebo dva řády jsou důležité, tak mám strach, že postupem času otupí a pravděpodobně něco přehlédne. Také je nezábavné číst reporty stále dokola každý den. A ve výsledku někdo musí zaplatit čas toho člověka, který data v reportu vyhodnocuje.
Naše reporty jsem ořezal
Naše reporty jsou proto „ořezané“. Obsahují pouze důležité informace, na které je třeba reagovat. Často tak ráno dorazí do e-mailu prázdné reporty, protože se v prostředích za předchozí den nestalo nic, co by vyžadovalo reakci. A když tam něco je, kolegové to rovnou vyřeší. Je menší pravděpodobnost, že se něco přehlédne. Lépe se i kontroluje, že je vše hotovo. Zabere to méně času a pro zákazníka je služba při obdobné kvalitě výrazně levnější.
Samozřejmě, že tím „ořezáním“ může dojít k tomu, že se neodhalí nějaký problém (reporty se snažíme stále zlepšovat). Řekl bych však, že tu bude platit Paretovo pravidlo. Za 20 % námahy (a tudíž i ceny) jsme schopni odhalit 80 % incidentů. Naši zákazníci sice chtějí mít co nejvyšší zabezpečení, ale nejsem si jist, zda by byli ochotni zaplatit 5 x více (nejsou to tajné organizace nebo finanční instituce 😊).
Jaké systémy používáme
Pro monitorování stavu sítě a detekci průniku máme zatím následující technologie:
- Monitorovací systém Solarwinds RMM: naše „nevlastní dítě“, které jsme si z velké části přepsali. Díky němu neustále vidíme, co se děje v sítích našich zákazníků. Do systému jsme si dopsali i pár bezpečnostních kontrol. Jak jsme se k němu dostali + co vše umí, jsem psal v článcích: „Monitorovací systém: jak jsem zjistil, že jej potřebujeme“ a „Monitorovací systém: co všechno s ním dokážeme“
- ERA (ESET Remote Administrator): sever pro centrální správu ESET antivirů. Antiviry ze všech počítačů zde hlásí svůj stav a stahují si skupinové politiky. Pokud útočník použije při útoku, byť jen jedinou známou škodlivou aplikaci, dozvíme se o tom a můžeme ihned reagovat.
- FortiAnalyzer – centrální úložiště dat o síťovém provozu a zároveň jejich analyzátor. Zde sbíráme data ze všech bezpečnostních FortiGate routerů a detekujeme nežádoucí provoz (proxy servery, botnety, zásah IPS, zakázané aplikace).
- Síťové skeny – naše vlastní rozšíření monitorovacího systému. U zákazníků se neustále provádí ARP/nmap skeny sítě a nalezená zařízení se pak kontrolují oproti naší databázi. Jedním z cílů je odhalit cizí zařízení v síti.
- Autoruns sken – opět naše rozšíření k monitorovacímu systému. Každý den zkontroluje veškeré aplikace a knihovny, které se automaticky v systému načítají (založeno na Autoruns od Sysinternals). Ověří je oproti Virustotal.com (aktuálně oproti 56 antivirům).
- PATRAM – náš informační systém. Sbírá data z ostatních monitorovacích systémů a kontroluje je, že plní svou práci (zdali sledují, co sledovat mají, každé zařízení je vidět ve všech systémech atd.😊).
V budoucnu máme v plánu začít nasazovat i honeypoty. Myslím, že by to byl velice účinný systém odhalování nežádoucího chování v síti – není důvod, proč by v private VLAN (nebo dokonce MGMT VLAN) mělo docházet k port skenům, nebo pokusům o přihlášení na honeypot (o kterém ani nikdo neví, že tam je 😊). Avšak asi to znáte: práce je hodně, času málo. Snad se nám to brzy podaří.
Reakce
Když při monitorování sítě zjistíme, že došlo k jejímu prolomení, musíme začít reagovat. Ideálně bychom měli mít již dopředu sepsané směrnice/postupy, jak v takových případech postupovat. Reakce na incident je pak rychlejší, rovnou konáte místo toho, abyste teprve začali přemýšlet, co s tím. Také bychom měli zajistit důkazy (nejspíše informovat úřady a PČR) a zjistit:
- jak k průniku došlo,
- jak dlouho je síť prolomená,
- k čemu všemu se útočníci dostali (data, systémy, zařízení),
- co vše útočníci v síti provedli (jaké zanechali backdoory).
A následně je třeba připravit plán, jak dostat síť opět do důvěryhodného stavu.
Moc rád bych se vám zde více rozepsal s praktickými informacemi, ale sám jich mám málo, abych o tom dokázal psát. Tyto incidenty zatím řešíme ad-hoc. Myslím, že tohle je oblast, na kterou se teď budeme muset zaměřit. Přes léto bych se měl účastnit školení „Computer Hacking Forensic Investigator“, snad vám pak budu moci o tématu napsat více.
Poučení
Poté, co dostaneme síť opět do důvěryhodného stavu, je třeba:
- Zavést nové, nebo upravit stávající restrikce, aby se prolomení sítě neopakovalo. Stejně tak můžeme přidat i restrikce, které zabrání/ztíží pohyb útočníka v síti (eskalaci privilegií).
- Měli bychom se zamyslet, zda jsme mohli monitorovacími systémy zachytit útok/prolomení sítě dříve. Adekvátně podle toho systémy upravit.
Zlepšovat restrikce a monitorování bychom samozřejmě měli průběžně s tím, jak se dozvídáme nové věci, učíme nové technologie.
Jako v předchozím bodě nemám pro tento bod žádnou praktickou kuchařku. Nové technologie u nás implementuje postupně, jak jen to čas dovolí. Hodně nám pomohla standardizace. Díky ní stačí technologii odladit u jednoho zákazníka a pak ji můžeme zapnout u všech. Nové technologie implementuje většinou na naše náklady – bereme to jako nezbytnou formu zlepšování služeb. Je s tím hodně práce, ale vidíme, že se to vrací v podobě spokojených zákazníků a hrdosti na svoji práci.
Závěr
Když se zpětně ohlédnu za článkem, asi bych jej měl nejspíše přejmenovat na „monitorování a velké množství dat“, protože jsem se této kapitole věnoval nejvíce času. Asi to téma vnímám jako věc, kterou řeší řada lidí okolo mne. Snad i pro vás to bylo přínosné.
Budu proto moc rád, když mi pomůžete dále rozšířit obzory a napíšete mi, jak to funguje u vás, jak se stavíte k bezpečnosti, co řešíte nejčastěji nebo s jakými výzvami se potýkáte.
Já se pokusím článek postupně doplňovat, podle toho, na co si vzpomenu, co mi napíšete, co nového se naučím.
Mějte prima den a co nejbezpečnější síť, na které se jejím uživatelům dobře pracuje 😊.
PS: Vydal jsem článek o monitorovací technologii se skvělým poměrem cena/výkon, kterou jsem si dlouho přál. Honeypot: efektivní a levný způsob detekce útoků v LAN.