V posledních letech je kladen velký důraz na bezpečnost informací, což v praxi znamená, že kromě zavádění procesních principů a kontrolních mechanizmů do řízení organizací se také zvyšují požadavky na samotné zabezpečení koncových uživatelských stanic a serverů. Pokud dojde k úniku informací, velmi často se tak stane vlivem selhání lidského faktoru a únik informací je nezřídkakdy spojen se značnou finanční újmou společnosti. Studie [1] uvádí, že celosvětově průměrné náklady ztráty jednoho záznamu jsou 142 USD. V USA jsou náklady na ztrátu jednoho záznamu až 204 USD. V nedávně době například pojišťovna Zurich byla potrestána pokutou ve výši 2,3 mil liber za ztrátu dat svých klientů [7], Banka HSBC pokutou ve výši 3 mil liber [8] nebo společnost Nationwide Building Society pokutou 1 mil liber [15]. Na vině je prostředí, které selhání lidského faktoru umožňuje. Některé studie uvádí, že až 85% počítačových podvodů ve společnosti mají na svědomí interní zaměstnanci [5]. Jedna studie dokonce uvádí, že ve vzorku 49 vnitřních útoků za 59% z nich stojí bývalí zaměstnanci [2]. Na straně uživatele se jedná především o koncové stanice a s nimi související zařízení. Na straně organizace a správy systémů se jedná o servery a sítě.

Pomoc pro obecné řízení bezpečnosti informací je možné hledat v mnoha standardech, normách, příručkách i odborné literatuře. Často se jedná o návody, na jaké oblasti se zaměřit a často jsou to návody v oblasti zavádění procesů a kontrol. Pokud jde o bezpečnost informací vztaženou na koncové stanice a servery, tam už mnoho obecných norem selhává.

V následující kapitole bude nejprve charakterizován možný koncept přístupu k řešení bezpečnosti. Poté, v další kapitole budou shrnuty výsledky dosavadního průzkumu a nakonec bude představen navrhovaný model řízení a kontroly bezpečnosti.

Co tvoří bezpečnost

Je-li auditorovi zadán úkol provést audit bezpečnosti koncových stanic a serverů ve společnosti, s ohledem na bezpečnost informací, jinými slovy, jestli z onoho PC či serveru může někudy uniknout informace do nepovolaných rukou, navíc, aby to nebylo možné zpětně dohledat a vyvodit odpovědnost, v takovém případě jsou možnosti auditora v tom podle čeho při auditu postupovat a jakou metodiku zvolit značně omezené. Při tomto úkolu je totiž nutné vzít v úvahu nejen technické zabezpečení konkrétní stanice, ale hodnocení provést v kontextu prostředí společnosti a dalších opatření i nad rámec konkrétní stanice (některá opatření mají na bezpečnost nepřímý, zprostředkovaný vliv) a dále navíc v kontextu určení rizikového profilu nebo úrovně potřebné bezpečnosti (různé stanice vyžadují různou úroveň zabezpečení).

Pro ilustraci, zjednodušeně řečeno, z obecného standardu, který se zabývá informační/IT bezpečností, se sice dozvíme například, že počítač má být zabezpečen heslem a že při jeho vyřazení máme vymazat obsah pevného disku. Toto jsou obecné věci, které běžného auditora napadnou, ale je i mnoho těch věcí, které ho bez předchozí zkušenosti nemají šanci napadnout nebo je musí při plánování auditu a vymýšlení auditních testů pracně dohledávat z mnoha nezávislých zdrojů. Pro ilustraci, například, jestli je možné získat přístup k informacím tím, že obejdeme heslo do OS nabootováním z jiného média, jaké jsou slabé stránky a co při auditu chtít vidět při hodnocení systému šifrování pevného disku nebo jaké jsou možnosti a aspekty hodné pozornosti auditora při zabezpečení USB portů, takovéto věci na jednom místě nenajdeme. Kromě toho, jinou úroveň zabezpečení bude vyžadovat PC vrátného a jinou úroveň PC vedoucího pracovníka pojišťovny.

Bezpečnost koncových stanic a serverů netvoří pouze konfigurace operačního systému a politik, což je možné zkontrolovat automatizovaně nějakým nástrojem typu „skener zranitelností“, ale skládá se z mozaiky a kombinace mnoha domén typu šifrování, Data Loss Prevention (DLP), Patch Management, Disaster Recovery, Asset Management, Life Cycle Management, systém autentizace, monitoring, mix preventivních, detektivních a následných opatření, dokumentace, nebo vůbec definice úrovně bezpečnosti ve vztahu k uživatelskému pohodlí, nákladům a zpracovávaným datům a mnoho dalšího. Tato práce se zabývá tvorbou metodiky nebo normy, která přistoupí k mozaice zmíněných oblastí jako ke komplexnímu celku.

Normy pro řízení a kontrolu bezpečnosti

Průzkumem bylo zjištěno, že různé přístupy k bezpečnosti koncových stanic a serverů v kontextu informační bezpečnosti můžeme hledat jak v uznávaných normách, tak v literatuře zabývající se touto oblastí.

Mezi nejznámější standardy, normy, procesní rámce a metodiky (dále jen „norma“) pro řízení různých aspektů IT patří COBIT, ITIL, ISO/IEC 20000 a ISO/IEC 27000 [10]. Kromě těchto hlavních standardů se používají i méně známé, často úžeji specializované, jako například Val IT, INTOSAI, PRINCE 2 nebo PMBOK. Některé dnes používané standardy jako například Sarbanes-Oxley (SOX), Six Sigma, COSO, Balanced Scorecard, CMMI a další určené pro řízení a měření výkonnosti, rizik nebo procesů organizace nebyly svými autory originálně určeny přímo pro řízení IT, bývají obvykle přijaty na obecné podnikové úrovni, ale díky dnešní provázanosti IT a businessu velmi často do IT zasahují. Důležité je nezapomenout, že do IT zasahují i různé právní normy. V České republice to jsou například zákon o ochraně osobních údajů, o elektronickém podpisu, některé paragrafy trestního zákoníku, atd. V mezinárodním prostředí, respektive u amerických společností stojí za zmínku například Patriot Act a HIPAA.

Jak je vidět, norem určených pro řízení IT nebo do řízení IT zasahujících existuje mnoho. Normy se liší zejména ve svém rozsahu, tedy jestli se jedná spíše o obecnou normu pro obecné řízení nebo takovou, která se věnuje IT detailům. Dále se normy liší v tom, jestli jsou primárně zavedeny v IT nebo se do IT promítají z obecného podnikového řízení. Rozdělení norem podle tohoto měřítka je patrné z obrázku 1.

Obrázek 1. Kategorizace standardů podle míry jejich obecnosti a využití pro IT. Zdroj: Zpracováno na základě analýzy autora.

Z těch nejrozšířenějších standardů využívaných v oblasti IT, ISO/IEC 27000 se používá všude tam, kde je třeba zavést systém pro řízení bezpečnosti informací. Tento standard je často používán společnostmi, které potřebují mít jistotu nebo potřebují někomu prokázat (partnerům, regulačním orgánům, atd.), že jimi zpracovávané informace a data jsou zpracovávány a uchovávány bezpečně. Pro řešení našeho problému je ale tato norma příliš obecná.

Další známou normou v řízení IT je ITIL. ITIL se zaměřuje na služby. Potřebujeme-li řídit vybranou oblast v IT jako například dodávky software, řízení projektů, klientské centrum, Help Desk, a další, pak je vhodné se poohlédnout po specializované normě, která se dané oblasti přímo věnuje, jako například právě ITIL nebo ISO/ IEC 20000. Představme si řízení sofistikovaného klientského centra (Call Center) zahrnujícího systémy pro Incident Management a Problem Management – bez použití jednoho z těchto standardů by to bylo obtížné. Bezpečnost koncových stanic a serverů ale ani jedna z těchto norem v potřebném detailu a úhlu pohledu neřeší, přestože se zabývají něčím, co by bez počítačů a serverů nemohlo existovat.

Další normy jako Balanced Scorecard, COSO, INTOSAI, SPSPR, HIPAA, PMBOK, PRINCE se sice v IT často používají, ale zaměřují na jiné oblasti a jsou rovněž příliš obecné. Normy typu SEA, GLBA, Basel, SOX a další sice bezpečnost informací nepřímo vyžadují (například hrozí astronomickými sankcemi za problémy plynoucí z nedostatečných kontrol v oblasti dat mající podstatně negativní vliv na finanční zdraví podniku), ale v kontextu koncových stanic a serverů, kde k úniku nebo změně informace může dojít, ji samy neřeší. Vhodným kandidátem v této oblasti je například COBIT [4]. Bohužel ale ani ten není dokonalý.

COBIT je procesní standard, který dává do souvislosti procesy v oblasti IT, zdroje a informační kriteria napříč různými doménami. COBIT je dnes jedním z nejrozšířenějších standardů v této oblasti [10] a zjednodušeně řečeno, jeho komplexnost spočívá v tom, že se snaží zabývat vším, co ve společnosti nějakým způsobem s IT souvisí. V COBITu se tedy setkáme jak například s definicí rizik internetového bankovnictví, popisem kontrol v rámci změnového řízení, tak i například s kontrolami týkajícími se zabezpečení chodu IT po personální stránce. Je to rámec, který se používá k řízení IS/ICT infrastruktury, procesů a procedur pomocí měřitelných kontrol. Přestože se jedná o jakýsi „slabikář“ IT auditora, jednoduchý „návod“ pro zmíněnou a často auditovanou oblast bezpečnost informací v souvislosti s uživatelskými koncovými zařízeními a servery neposkytuje. V některých oblastech jako například bezpečnost desktopů, notebooků, serverů, což jsou spíše technické záležitosti než procesy, tedy není moc dobře použitelný. Navíc COBIT vyžaduje hluboké znalosti a roky praxe, komplexní znalost COBITu vyžaduje navíc i znalost „IT Assurance Guide“ [9] a „IS Standards, Guidelines and Procedures for Auditing and Control Professionals“ [11], dokumenty rozvíjející obsah COBITu, což je cca 900 stran odborného a provázaného textu, tedy zřejmě nic pro běžného, obecného auditora.

V oblasti literatury můžeme snahu o komplexnější přístup k bezpečnosti najít například v článku [14], ve kterém autoři vyjmenovávají řadu prvků vystupujících v celkovém obrazu bezpečnosti, ale popis je pouze v obecné rovině. V článku [13] se autor zabývá tím, co vůbec bezpečnost je a dívá se na ni především z pohledu řízení přístupu. Autor článku [3] kritizuje klasický pohled na bezpečnost a zabývá se požadavky na bezpečnost koncových stanic v souvislosti s konceptem SOA.

Bezpečnost v dynamickém 3D modelu

Jak už bylo zmíněno, řízení a kontrola bezpečnosti uživatelských koncových stanic a serverů by se neměla zaměřovat pouze na samotnou konfiguraci operačního systému a nainstalovaných aplikací nebo nejen na samotné procesy obsluhující IT, ale měla by vzít v úvahu širší okolí. Navrhovaný model zobrazený v obrázku 2 se na bezpečnost dívá ze tří úhlů.

Obrázek 2. Dynamický model 3D bezpečnosti. Zdroj: autor.

Osa Y

V první řadě je potřebné určit požadavky na bezpečnost nebo rizikový profil posuzované stanice (osa Y). Požadavky na bezpečnost jsou různé mezi společnostmi, odvětvími, ale i v rámci jedné firmy. Finanční průmysl a zdravotnictví jsou charakteristické vysokými požadavky na bezpečnost. Naproti tomu, firma zabývající se vývozem komunálního odpadu zřejmě nebude mít požadavky tak vysoké. Notebook finančního ředitele má pro chod firmy jistě větší význam než stolní počítač skladníka a potřebuje tak být lépe zabezpečený.

Otázkou je, jak vytvořit metodiku pro určení požadavku na bezpečnost, tj. jestli posuzované PC nebo server potřebují být zabezpečené velmi nebo jen minimálně. Ke kategorizaci požadavků na bezpečnost můžeme přistoupit z několika pohledů. Odvětví působnosti firmy (banka versus pekařství) nebo důležitost stanice z hlediska provozu firmy (server řídící výrobní linku versus PC oddělení průzkumu trhu) jsou jedny z pohledů, další jsou například důležitost uložených informací (server, na kterém jsou data business inteligence versus server provozu jídelny), charakter uložených informací s ohledem na jejich publicitu (osobní informace versus archiv veřejného denního tisku), charakter uložených informací s ohledem na finance podniku (data účetnictví a platebního styku versus veřejná data webového serveru) a mnoho dalších přístupů. Některé z faktorů ovlivňujících požadavky na bezpečnost mají oporu přímo v zákoně. Nedodržení povinností daných zákonem ve vztahu k datům, kterých se zákon týká má pro podnik horší následky než u dat, která oporu v zákoně nemají. Těmi faktory jsou například podpora ochrany osobních údajů v ČR zákoně o ochraně osobních údajů [18], v USA podpora ochrany finančních a účetních dat v zákoně Sarbanes-Oxley [21], ochrana osobních údajů v zákoně Gramm-Leach-Bliley Act (GLBA) [17] nebo ochrana zdravotních údajů v zákoně Health Insurance Portability and Accountability Act (HIPAA) [20], v ČR podpora ochrany účetních údajů v zákoně o účetnictví [19], atd. Při stanovování požadavků na bezpečnost je nutné si uvědomit, že díky globalizaci se na nás může vztahovat i zahraniční legislativa [12].

V obecné rovině je vhodné zaměřit se na základní parametry informační bezpečnosti jak jsou definovány například v InfoSec Triangle [16], kterými je důvěrnost, dostupnost, integrita. Autoři [6] k těmto základním vlastnostem informací přidávají ještě přístup a autentizace, soukromí, vlastnictví, uchování dat a auditovatelnost. Dalším vodítkem pro stanovení požadavků na bezpečnost může být Cobit Cube [4, strana 25], která požadavky dělí na účinnost, hospodárnost, důvěrnost, integritu, dostupnost, shodu (compliance) a spolehlivost.

V okamžiku, kdy máme nadefinovanou úroveň požadované bezpečnosti, můžeme se přesunout na osu X, která zobrazuje opatření v mnoha různých doménách.

Osa X

Abychom zabezpečili požadovanou úroveň bezpečnosti, je potřebné nebo žádoucí přijmout různá opatření z různých domén, jejichž znázornění je v našem modelu na ose X.

Příkladem domén jsou šifrování, systém Data Loss Prevention (DLP), ochrana před napadením, Patch Management, Disaster Recovery, Asset Management, Life Cycle Management, systém autentizace, monitoring, mix preventivních, detektivních a následných opatření, dokumentace, atd.

Tento koncept si můžeme ukázat na praktickém příkladu. Například PC vrátného zřejmě nebude nutné zabezpečovat šifrováním pevného disku, protože na něm nejspíš nebudou žádné důležité informace a jeho PC ani nebude kriticky důležité. PC vrátného jsme totiž v předchozím kroku ohodnotili nízkými požadavky na bezpečnost a těm odpovídají jen základní bezpečnostní požadavky jako například aktualizovaný operační systém zabezpečený heslem, zapnuté logování událostí pokusů o přihlášení a jeho PC umístěné do oddělené virtuální LAN. PC pracovníka provozního oddělení bychom ale už mohli chtít zabezpečit šifrováním, protože se na něm mohou vyskytovat důležité informace. Notebook finančního ředitele budeme chtít nejen zabezpečit šifrováním, ale v rámci šifrování budeme požadovat například šifrování celého disku, pre-boot autentizaci a navíc centrální správu šifrovaného klienta a analogicky přísnější mix opatření i z dalších domén jako DLP, životní cyklus aktiva a další. Počítač pracovníka vstupujícího do majetkového registru osob nebo počítač pojistného matematika budeme patrně chtít kromě již uvedeného navíc vybavit systémem DLP, který rovněž může mít několik úrovní komplexnosti. Tento princip je zobrazen na následující tabulce.

Tabulka 1. Vztah mezi požadavky na úroveň bezpečnosti a opatřeními v různých doménách. Zdroj: autor.

Vyšší úrovni požadavků na bezpečnost odpovídá „přísnější“ mix opatření z různých domén. Různá úroveň požadované bezpečnosti zachycená na ose Y se promítá do různého mixu opatření v rámci různých domén na ose X.

Osa Z

Přijetí opatření ke zvýšení bezpečnosti různých zařízení vede ke zvýšení bezpečnosti celého systému, tedy do jisté míry k vyšší úrovni jeho bezpečnostní vyspělosti. Různé úrovně bezpečnostní vyspělosti systému jsou zobrazeny na ose Z.

Důležité je nezapomenout na to, že přijetím opatření ke zvýšení bezpečnosti práce nekončí. Po přijetí opatření je nutné vyhodnotit jeho účinnost. Tím se dostáváme zpět k požadavkům na bezpečnost. Mezi zjištěním nedostatku, přijetím opatření a jeho vyhodnocením mohou uběhnout týdny, měsíce nebo dokonce i roky. Během implementace se může ukázat, že navržené opatření není realizovatelné nebo jen za cenu a úsilí, které převyšuje jeho přínos. Než se dostaneme k vyhodnocení účinnosti opatření nebo už dokonce během implementace opatření se může změnit situace v podniku, a tím i požadavky na bezpečnost, a v takovém případě je mnohdy potřebné se vrátit na začátek cyklu, tedy na osu Y.

Postup práce s modelem lze shrnout tak, že při implementaci modelu do praxe se postupuje v uzavřeném cyklu. Nejprve je potřebné stanovit požadavky na bezpečnost nebo rizikový profil posuzované stanice (osa Y). K tomuto je vhodné využít postup, který má oporu v metodice. Na to navazuje stanovení, realizace a kontrola bezpečnostních opatření (osa X). Kombinace různých opatření z různých domén zachycených na ose X, respektive úspěšnost jejich implementace, se promítá do úrovně vyspělosti systému bezpečnosti (osa Z). Systém bezpečnosti je potřebné vyhodnocovat a na aktuální situaci v oblasti bezpečnosti reagovat aktualizací požadavků na bezpečnost na ose Y. Tím se cyklus řízení bezpečnosti podle tohoto dynamického modelu 3D bezpečnosti uzavírá.

Závěr

Cílem práce navazující na toto pojednání je vytvořit metodiku nebo návod (guideline), podle kterého bude běžný auditor schopen úspěšně a komplexně zpracovat úkol auditu koncových stanic a serverů, především v kontextu principů informační bezpečnosti a specialista nebo manažer bezpečnosti jejich bezpečnost řídit. Navržený model, který mimo jiné rozšiřuje model ITGPM katedry informačních technologií v oblasti bezpečnosti, se tedy dívá na bezpečnost koncových stanic a serverů nejen z pohledu technické konfigurace, ale navíc v kontextu dalších opatření i nad rámec konkrétní stanice, dále v kontextu určení rizikového profilu nebo úrovně potřebné bezpečnosti a nakonec i v kontextu hodnocení vyspělosti řízení bezpečnosti. Model bude zpracován s pomocí analytických metod a jeho funkčnost ověřena dotazníkovým šetřením.