SOC JE TU PRETO, ABY STE NIKDY NEMUSELI ZAŽIŤ ŠOK


#1 SOC JE TU PRETO, ABY STE NIKDY NEMUSELI ZAŽIŤ ŠOK

V dnešnej dobe je bezpečnosť systémov IT rozhodujúca z hľadiska kontinuity podnikania a inštitúcií. Stále viac obchodných manažérov si uvedomuje, že narušenie IT systémov spôsobuje finančné straty, často v miliónoch eur denne, a takisto stratu imidžu.

PRZEMYSŁAW KUCHARZEWSKI

Ako odhaliť kybernetické útoky, ako im čeliť, ako kategorizovať bezpečnostné incidenty, ako ich korelovať, aby organizácia mohla fungovať bez prerušenia? Na jednej strane existujú nástroje na odhaľovanie a zaznamenávanie neštandardných činností, niektoré sú dôsledkom predchádzajúcich činností a iba ich kombinácia umožňuje odhaliť nezrovnalosti alebo útok na informačné systémy. Niekedy bude potrebné oddeliť internú infraštruktúru od externej siete alebo niektoré systémy spoločnosti od zvyšku, aby sa zabránilo šíreniu škodlivého softvéru alebo úniku údajov smerom von. Vyžaduje si to vysokokvalifikovaných odborníkov, ktorí sú schopní vyvodiť závery z informácií z rôznych zdrojov a primerane reagovať na základe svojich skúseností.

S cieľom zabezpečiť najvyššiu úroveň bezpečnosti organizácie dochádza ku zriadeniu (alebo využívaniu služby externých spoločností) operačného strediska. Oznámenie v kombinácii s inými aspektmi umožňuje klasifikáciu incidentu ako TI.

(FOTO…) Krzysztof Strączkowski, Service Delivery Manager, Trecom

Zapojením sa do budovania SOC Trecom sme sa zamerali na presne definované operačné schopnosti. Na tomto základe sme definovali organizáciu tímu a procesy riešenia incidentov. Týmto spôsobom sme vytvorili súbor služieb, ktoré nie sú len doplnkom ponúkaných technológií. V rámci prispôsobovania služby prostrediu zákazníka stále vedieme dialóg, aby sme porozumeli architektúre IT monitorovaného prostredia. V prvom rade sa však musíme dozvedieť o vzťahoch medzi prvkami tohto prostredia, o úlohe IT systémov v obchodných procesoch, o rizikách vyplývajúcich z hrozieb a o ich vplyve na poslanie spoločnosti. Domnievame sa, že situačná informovanosť vyplývajúca zo znalosti chráneného prostredia umožňuje účinnú analýzu udalostí a prijatie vhodných opatrení v reakcii na bezpečnostné incidenty. V procese reakcie na incidenty sú potrebné aj kontaktné údaje vlastníkov procesov a zdrojov. Informácie získané v etape adaptácie služby SOC v prostredí zákazníka sa odrážajú v postupoch riešenia incidentov. SOC Trecom vyvinul metódy správania, ale vo väčšine prípadov musíme prispôsobiť naše postupy potrebám vyplývajúcim zo špecifických bezpečnostných požiadaviek každého klienta.
Ako to celé prebieha? Analýzu počiatočných udalostí robia analytici prvej línie (Tier 1) podľa konkrétnych postupov. Ak udalosti vyžadujú pokročilú analýzu, postúpia sa analytikom druhej línie (Tier2), ktorí sa tiež zaoberajú incidentmi, pretože proces reakcie na incidenty (IR) robia analytici druhej línie SOC. V odôvodnených prípadoch sú zapojení odborníci zodpovední za pokročilé operačné schopnosti (Avanced Capabilities). Tím operácií a riadenia (Operations and Management), ktorého úlohou je spravovať bezpečnostné systémy, môže podporovať reakciu na incidenty, monitorovanie systému a poskytovanie ďalších kontextových údajov bezpečnostného operačného centra (SOC – ang. Security Operating Center). SOC je centralizovaná jednotka, ktorá monitoruje a kvalifikuje útoky na podnikové informačné systémy (počnúc webovými stránkami, aplikáciami a systémami, databázami, dátovými centrami a jednotlivými servermi, sieťami, všetkými koncovými zariadeniami, ako sú telefóny, notebooky alebo tablety) a bojuje proti nim. SOC je v skutočnosti tím analytikov, ktorí pomocou špecializovaných nástrojov zisťujú, analyzujú, reagujú a hlásia a predovšetkým pôsobia proti bezpečnostným incidentom. Centrá bezpečnostných operácií fungujú 24 hodín denne, 7 dní v týždni, prijímajú správy od používateľov a monitorujú udalosti systému z pohľadu potenciálne bezpečnostných incidentov.
Čo sú bezpečnostné incidenty, tzv. Threat Incidents, často nazývané TI? TI sú analyzované udalosti (oznámenia), ktoré ohrozujú integritu, dôvernosť alebo dostupnosť IT systémov, informácie spracovávané, uložené a prenášané týmito systémami alebo ktoré porušujú alebo hrozia narušením bezpečnostných politík. Nie každá aplikácia je teda kvalifikovaná ako TI. Niekedy je to tiež prípad individuálnej bezpečnosti zákazníkov. Štruktúra strediska pre bezpečnosť prevádzky Trecom je znázornená na nasledujúcom diagrame.

 

Lacnejší outsourcing?

Prečo sa organizácie rozhodnú presunúť SOC mimo svojej organizácie? Dva dôvody – prvým sú kompetencie, druhým sú peniaze. Príkladom môže byť desaťčlenný tím s dennými a nočnými zmenami, s manažérom, ktorý riadi celú jednotku, ktorého náklady na potrebné výmeny a školenie zamestnancov sa odhadujú priemerne na úrovni medzi 50 000 a 70 000 eur v závislosti od regiónu krajiny
a kompetencií zamestnancov. Môže si každá organizácia dovoliť také výdavky? Nie – určite nie široko chápaný stredne veľký podnik a dokonca ani veľký domáci subjekt. Niečo iné sú medzinárodné korporácie so štandardizovanými technológiami a IT zariadeniami, ktoré môžu udržiavať takýto subjekt vo svojich štruktúrach a pôsobiť ako „poistka“ v ich ekosystéme IT pokrývajúcom mnoho krajín.

(FOTO…) Michał Horubała, Security Operations Center Architect, eSecure Sp. z o. o.

Srdcom SOC Trecom je systém SecureVisio poľskej spoločnosti eSecure. 
Tento produkt nám umožňuje ľahkú integráciu do bezpečnostných systémov našich klientov, tvorbu databázy CMDB monitorovaného prostredia, analýzu rizík, riešenie incidentov a správu zraniteľností. Nevyžadujeme, aby naši zákazníci nakupovali alebo používali konkrétne riešenia IT zabezpečenia. Analýza udalostí a detekcia incidentov však vyžaduje vhodné zdroje údajov. Monitorované siete musia byť preto vybavené systémami poskytujúcimi indikátory incidentov. Sú to riešenia Endpoint Security alebo EDR, systémy IDS/IPS, systémy na analýzu sieťového prenosu, skenery zraniteľnosti a systémy riadenia triedy SIEM/log. V závislosti od potrieb prostredia a bezpečnosti môžeme využívať zákaznícke systémy alebo poskytovať riešenia z našej ponuky (aj pri fakturácii predplatného).

Okrem finančných problémov existujú aj časové náklady a problémy s budovaním správneho tímu v organizácii. Projekt spustenia jednotky SOC v rámci organizácie zvyčajne trvá 18 až 24 mesiacov. Trh kybernetickej bezpečnosti je zaplavený novými technológiami a trpí nedostatkom správnych ľudí v tejto špecializácii. Úloha zorganizovať jednotku a vybaviť tím technológiami na splnenie stanovených úloh je výzvou, ktorú je veľmi ťažké splniť. Riziko nesprávnych rozhodnutí vo fázach definovania misie, plánovania, organizácie, prevádzkových možností a výberu vhodných technológií je veľmi vysoké a dôsledky týchto rozhodnutí môžu byť veľmi nákladné.

Stojí to za to chrániť vašu infraštruktúru a údaje týmto spôsobom? Údaje sú najcennejšou hodnotou organizácií. Predstavte si, čo by sa stalo, keby údaje o transakciách so zákazníkmi unikli z banky, keby telekomunikačný operátor prišiel o informácie o samotných zákazníkoch aj o ich telefónnych číslach, keby z výskumného strediska automobilky unikli informácie o nových výskumných a vývojových prácach na novom modeli motora…

#2 SOC JE TU PRETO, ABY STE NIKDY NEMUSELI ZAŽIŤ ŠOK

Ako funguje SOC Trecom v praxi
Ukazovateľ incidentu

Systém Snort bol implementovaný do klientskej siete dočasne. Zákazník využíval v poslednom čase naše služby. Nevyžadujeme od našich klientov, aby používali konkrétne riešenia zabezpečenia IT. Analýza udalostí a detekcia incidentov však vyžaduje vhodné zdroje údajov. Jednou z týchto požiadaviek je dostupnosť systémov triedy IDS / IPS v sieti klienta, ktoré sú jedným zo zdrojov indikátorov incidentov. Klient sa rozhodol kúpiť riešenie, ale v tejto fáze bol len v procese výberu riešení a prípravy obstarávania. Sensor Snort v jednej zo sledovaných sietí hlásil udalosť „DNS request for known malware do-main”.
Udalosť bola automaticky zaregistrovaná v systéme riadenia incidentov, ktorý obohatil údaje o informácie o prvkoch infraštruktúry zákazníka, ktoré boli problémom ovplyvnené. V tejto fáze to boli iba oznámenia, za ktoré sú zodpovední analytici SOC prvej línie. Vzhľadom na umiestnenie hostiteľa (zóna DMZ – ang. DeMilitarized Zone, priame vystavenie útokom, vážne následky), ktoré boli ovplyvnené udalosťou a jej význam pre organizáciu, systém automaticky označil oznámenie ako „kritickú“ prioritu.

Monitorovanie a výber udalostí – I. línia SOC

Analytik, ktorý v súlade s postupmi okamžite začal pracovať na oznámení, dospel už vo fáze overovania základných informácií k záveru, že ide o incident. Hostiteľ, ktorý odoslal podozrivú žiadosť na server DNS, bol WEB server organizácie umiestnený v sieti DMZ.
Žiadosť sa týkala domény chickenkiller.com. Informácie z databázy MISP a rýchle vyhľadávanie na stránkach Google naznačujú, že doména je súčasťou bezplatnej služby DNS a často sa používa na kriminálne účely. WEB server by, samozrejme, nemal posielať podobné dotazy DNS. Tieto informácie postačovali na kvalifikáciu oznámenia ako incidentu a jeho postúpenie druhej línii SOC.

Analýza incidentu – II. línia SOC

Po prijatí správy si analytik druhej línie SOC uvedomil, že na webovom serveri, ktorý bol predmetom incidentu, bolo identifikovaných niekoľko závažných zraniteľných miest. Tieto zraniteľné miesta boli zistené pred dvoma týždňami a informácie o nich boli poskytnuté klientovi. Žiaľ, konfigurácia servera v čase incidentu ešte nebola opravená. Rýchla kontrola nástrojom nikto potvrdila, že server WEB stále používa veľmi zastaranú verziu Apache a starú aplikáciu WordPress.

Reakcia na incident – II. línia SOC

Analytik druhej línie pomocou zavedeného komunikačného kanála informoval klienta o pravdepodobnej udalosti a o potrebe ďalších krokov. Žiaľ, SOC nedisponoval prihlasovacími údajmi pre podozrivý server. Spravovala ho externá spoločnosť. Z dôvodu pravdepodobnosti konfliktu záujmov bolo rozhodnuté pred zapojením do systému riadenia stiahnuť obsah pevného disku zariadenia a začať zaznamenávať sieťovú prevádzku v segmente DMZ. Rovnaký systém, aký sa použil pre senzor Snort, sa použil na zaznamenanie pohybu. S cieľom stiahnuť obsah pevného disku bol na miesto vyslaný odborník vybavený postupom a nástrojmi na získanie materiálu. Pretože sídlo klienta bolo na odľahlom mieste, dojazd z najbližšej pobočky Trecom mal trvať asi 2 hodiny. So súhlasom klienta sa rozhodlo o odpojení servera od siete, kým sa neskopírovali údaje. Medzitým sa zmenila konfigurácia firewallu tak, aby úplne prerušila možnosť komunikácie zóny DMZ so sieťou LAN. Bolo tiež rozhodnuté vytvoriť kópiu obsahu iného počítača umiestneného v tej istej zóne – SMTP servera. Kopírovanie trvalo ďalších päť hodín. Po zabezpečení materiálu bola kontaktovaná spoločnosť spravujúca server a správca bol informovaný o podozrení o vzniku incidentu. Správca poskytol prihlasovacie údaje analytikovi SOC, ktorý mohol na diaľku začať skúmať systém skôr, ako sa jeho obsah dostal do laboratória SOC Trecom vo Varšave. Na serveri bol identifikovaný vnorený adresár, ktorý pravdepodobne obsahuje škodlivý súbor. Môže to naznačovať pokus o narušenie systému, aby sa server mohol neskôr použiť na iný účel – napríklad na phishingovú kampaň. Ďalšia analýza mala trvať najmenej niekoľko dní a mohla sa vykonať na kópii údajov v laboratóriu SOC. Preto bolo rozhodnuté preinštalovať operačný systém servera a všetky aplikácie, aby sa rýchlo obnovili jeho funkcie.
Ďalší výskum ukázal, že súbor nájdený na serveri sa skutočne použil v jednej z phishingových kampaní (útočník si ho pravdepodobne stiahol z domény chickenkiller.com – odtiaľ pochádza DNS žiadosť). Súbor obsahoval škodlivý kód typu ransomware). Na druhom stroji z DMZ sa nezistili žiadne známky vlámania. Protokoly však naznačujú pokus o prieskum. Z tohto dôvodu bolo klientovi odporúčané preinštalovať serverový softvér. Ďalšia analýza mala trvať najmenej niekoľko dní a mohla sa vykonať na kópii údajov v laboratóriu SOC.
fPo ukončení incidentu a príprave správy sa zorganizovalo stretnutie s cieľom sledovať postup reakcie na incident, vyvodiť závery a prijať možné úpravy postupov. Pozornosť sa venovala nedostatku kontaktných údajov na správcu webového servera v databáze SOC a nedostatku informovanosti zákazníkov o potrebe prihlasovania a hesiel pre všetky jeho systémy. Analyzovala sa možnosť zmeny root hesla pomocou fyzického prístupu k serveru. Zistilo sa, že v tejto konkrétnej situácii to nebolo opodstatnené, ale bolo prijaté rozhodnutie zahrnúť postup zmeny hesla v systéme Linux do súboru postupov dostupných odborníkom v tejto oblasti.
Klient dostal správu o incidente do dvoch dní od ukončenia práce. Správa obsahovala podrobný opis incidentu, zaznamenané oneskorenia pri opravovaní zistených zraniteľností a informačné medzery.