Klasifikace informací v korporátním prostředí

Podobné dokumenty
Řešení DocTag pro klasifikaci dokumentů. Matej Kačic

ehealth Day 2016 Jak zavést účinná organizační a technická opatření pro řízení bezpečnosti

GDPR SNADNO.info. Ing. Lukáš Přibyl, předseda NSMC Network Security Monitoring Cluster

Návrh vyhlášky k zákonu o kybernetické bezpečnosti. Přemysl Pazderka NCKB

Bezpečnostní politika společnosti synlab czech s.r.o.

Proč ochrana dat a informací není běžnou součástí každodenního života? Martin HANZAL SODATSW spol. s r.o.

Návrh zákona o kybernetické bezpečnosti. Přemysl Pazderka Národní centrum kybernetické bezpečnosti Národní bezpečnostní úřad p.pazderka@nbu.

Strategie Implementace GDPR. Michal Zedníček ALEF NULA, a.s.

Z P Ů S O B P Ř Í S T U P U K Z A J I Š T Ě N Í S O U L A D U S E Z Á K O N E M O K Y B E R N E T I C K É B E Z P E Č N O S T I V C L O U D O V É M P

Potřebujeme kybernetickou bezpečnost? Jak chráníme informační aktiva?

SIEM Mozek pro identifikaci kybernetických útoků. Jan Kolář , Praha, Cyber Security konference 2014

CHECK POINT INFINITY END TO END BEZPEČNOST JAKO ODPOVĚĎ NA GDPR

Zkušenosti z nasazení a provozu systémů SIEM

Audit ICT. KATALOG služeb. Ing. Jiří Štěrba

Bezpečnostní aspekty informačních a komunikačních systémů KS2

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant

ISSS. Ochrana citlivých dokumentů. v prostředí státní správy. Tomáš Hlavsa

Obecné nařízení o ochraně osobních údajů

CO OBCE MOHOU UDĚLAT PRO GDPR UŽ NYNÍ?

Zákon o kybernetické bezpečnosti základní přehled. Luděk Novák ludekn@ .cz,

Bezpečností politiky a pravidla

1. Organizace dokumentu. 2. Zabezpečení jako priorita. 3. Cloudová infrastruktura Hybrid Ads

ČESKÁ TECHNICKÁ NORMA

Směrnice. Záměrná a standardní ochrana osobních údajů. Platnost a účinnost od: Mgr. Milan KRÁL

Státní pokladna. Centrum sdílených služeb

ANECT & SOCA GDPR & DLP. Ivan Svoboda / ANECT / SOCA. Lenka Suchánková / PIERSTONE. Petr Zahálka / AVNET / SYMANTEC

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů

DOCUMENT MANAGEMENT TOOLKIT

Úvod - Podniková informační bezpečnost PS1-2

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb.

V Brně dne 10. a

DATOVÉ SCHRÁNKY - SOUČÁST ICT ŘEŠENÍ TELEFÓNICA O2. Pavel Smolík Top Account Manager

Shoda s GDPR do 4-6 měsíců! Sen či utopie?

10. setkání interních auditorů v oblasti průmyslu

Implementace GDPR v prostředí Krajského úřadu Zlínského kraje a příspěvkových organizací zřizovaných Zlínským krajem

Podmínky ochrany osobních údajů

Legislativní smršť v roce2018 a její vliv na kybernetickou a informační bezpečnost Ing. Aleš Špidla

PRIVACY POLICY. Issued / vydáno dne: Written by / vypracoval: Mgr. Michaela Škrabalová. Revised by / revidoval: ---

BEZPEČNOSTNÍ ROLE. a jejich začlenění v organizaci

Fyzická bezpečnost, organizační opatření. RNDr. Igor Čermák, CSc.

JAK ZAČÍT S GDPR V PODMÍNKÁCH MALÉ OBCE. konference

Enterprise Mobility Management AirWatch & ios v businessu

ELEKTROWIN a. s. Politika společnosti. Interní materiál spol. ELEKTROWIN a.s.

(2) Zásady bezpečnostní politiky jsou rozpracovány v návrhu bezpečnosti informačního systému

Enterprise Mobility Management & GDPR AirWatch - představení řešení

Platná od Bezpečnostní politika. Deklarace

MANAGEMENT KYBERNETICKÉ BEZPEČNOSTI

SOCA & Zákon o kybernetické bezpečnosti. od teorie k praxi. Ivan Svoboda & SOCA AFCEA CERT/SOC

CO OBCE MOHOU UDĚLAT PRO GDPR UŽ NYNÍ?

EMBARCADERO TECHNOLOGIES. Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů.

Bezpečnostní témata spojená se Zákonem o kybernetické bezpečnosti

Řízení kybernetické a informační bezpečnosti

Není cloud jako cloud, rozhodujte se podle bezpečnosti

GORDIC a GDPR? Připraveno!

Kybernetická bezpečnost MV

Cyber Security GINIS. Ing. Igor Štverka GORDIC spol. s r. o.

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o.

Kybernetická bezpečnost resortu MV

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o.

TSB a kybernetická bezpečnost SMB a jím ovládaných subjektů

Audit ICT. KATALOG služeb. Ing. Jiří Štěrba

POŽADAVKY NA SMLOUVY S DODAVATELI

Jak by měl vedoucí pracovník prosazovat zásady kybernetické bezpečnosti. Ing. Jiří Sedláček Chief of Security Experts

POLITIKA ZPRACOVÁNÍ A OCHRANY OSOBNÍCH ÚDAJŮ

Fyzická bezpečnost z hlediska ochrany utajovaných informací

Zavádění PKI infrastruktury v organizaci - procesní aspekty. Vlastimil Červený, Kateřina Minaříková Deloitte Advisory, s.r.o.

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

ISMS. Bezpečnostní projekt. V Brně dne 10. října 2013

Dopady GDPR a jejich vazby

Co obce mohou udělat pro GDPR už nyní. Medlov, Mgr. Miroslava Sobková

Informační bezpečnost. Dana Pochmanová, Boris Šimák

Politika ochrany osobních údajů

nová bezpečnostní identita nejen pro zákon pro skutečnou ochranu

BEZPEČNOSTNÍ POLITIKA INFORMACÍ

V Olomouci dne 25. května Politika ochrany osobních údajů Gymnázia, Olomouc, Čajkovského 9

Politika bezpečnosti informací

Úvod - Podniková informační bezpečnost PS1-1

GDPR compliance v Cloudu. Jiří Černý CELA

Posuzování na základě rizika

Kybernetická bezpečnost

Bezpečnostní monitoring v praxi. Watson solution market

Klíčové aspekty životního cyklu essl

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

POMŮCKA K AUDITU BEZPEČNOSTNÍCH OPATŘENÍ PODLE ZÁKONA O KYBERNETICKÉ BEZPEČNOSTI. Verze 2.1

Olga Přikrylová IT Security konzultant / ITI GDPR. Ochrana osobních údajů

Co je a co není implementace ISMS dle ISO a jak měřit její efektivnost. Ing. Václav Štverka, CISA Versa Systems s.r.o.

Enterprise Mobility Management AirWatch - představení řešení. Ondřej Kubeček březen 2017

GDPR v sociálních službách

Management informační bezpečnosti

GDPR, osobní rozvoj a vzdělávání zaměstnanců

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků

Ochrana osobních údajů Implementace GDPR

Normy ISO/IEC NISS. V Brně dne 7. listopadu 2013

Monitorování a audit databází v reálném čase. Ing. Jan Musil IBM Česká republika

Bezepečnost IS v organizaci

2. setkání interních auditorů ze zdravotních pojišťoven

Organizační opatření, řízení přístupu k informacím

Identity Manager 4. Poskytujte okamžitý přístup ke zdrojům v rámci celého podniku

Systémová analýza a opatření v rámci GDPR

Transkript:

v korporátním prostředí je jedním ze základních pilířů systémů řízení informační bezpečnosti. Chceme-li informace organizace účinně a efektivně chránit, musíme nejen definovat kategorie a bezpečnostně- -organizační pravidla pro zacházení s nimi, ale především musíme vědět, které konkrétní dokumenty chránit. Článek poskytuje praktické poznatky z implementace klasifikace informací a její návaznosti na bezpečnostní normy, požadavky zákona o kybernetické bezpečnosti a regulativy GDPR. Zaměříme se na přínosy klasifikace informací v rámci procesu budování bezpečnosti v podnikovém prostředí a následnou implementaci bezpečnostních technologií, na detekci a prevenci úniku informací a bezpečnostního monitoringu. Uvedeme příklady správného nasazení klasifikace a ukážeme, jak vhodný nástroj zvyšuje bezpečnostní podvědomí (security awarness) a vynutitelnost procesu klasifikace v prostředí společnosti. Úvod Snaha chránit informace, aby se nedostaly do nepovolaných rukou, existovala již ve starověku. Tato skutečnost dala vzniknout řadě šifrovacích mechanismů, které si kladly jediný cíl chránit citlivou informaci před nepřítelem. Přestože dříve byly předmětem utajení zejména vojenské informace, s rozvojem informačních a komunikačních technologií se dnes žádná firma neobejde bez toho, aniž by musela chránit svoje know-how v podobě informací. S rostoucím objemem zpracovávaných informací a zvyšujícími se náklady na ochranu před stále sofistikovanějšími útoky se zvyšuje i potřeba tyto informace třídit, tj. klasifikovat. Modely klasifikace se používaly nejprve pro vládní a vojenské účely (např. model Bell LaPadula [8] nebo Biba [9], který cílil i na ochranu integrity) a kategorizovaly informace od nejvíce citlivých úrovní (přísně tajné) až po ty nejméně důvěrné (veřejné nebo neklasifikované). Na základě příslušných bezpečnostních prověrek uživatelů byl následně řízen přístup ke klasifikovaným informacím. Masivní rozšíření systémů klasifikace i mimo vládní a vojenský sektor zajistil standard ISO/IEC 27001 (resp. předchůdce BS 7799-2), který považuje klasifikaci aktiv za jeden ze základních pilířů informační bezpečnosti. Standard vyžaduje, aby veškeré zpracovávané informace byly klasifikovány do zvolených úrovní (s ohledem na jejich hodnotu, právní požadavky, citlivost a kritičnost). Dále musí být stanoven postup značení informací, zacházení s nimi a určena pravidla pro ukládání a manipulaci s nimi. Na klasifikaci informací pamatuje i česká legislativa. V rámci zákona č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti, se setkáváme se čtyřmi definovanými kategoriemi informací Přísně tajné, Tajné, Důvěrné a Vyhrazené. Zákon jasně stanovuje i požadavky na ochranu těchto informací a podmínky, za kterých je možné se s nimi seznamovat. Dalším příkladem je zákon o kybernetické bezpečnosti, resp. na něj navazující vyhláška 12

č. 316/2014 Sb., která nařizuje, aby dotčené subjekty stanovily bezpečnostní politiku i pro klasifikaci aktiv. Běžně se můžeme setkat také s dělením dle zákona č. 101/2000 Sb., o ochraně osobních údajů. Ten kromě třídy osobních údajů definuje i tzv. citlivé osobní údaje, na jejichž sběr, zacházení a ochranu se vztahují přísnější opatření. Poslední jmenovaný zákon je stále předmětem velkých diskusí, protože od 25. května 2018 vstoupilo v platnost nařízení (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů (angl. General Data Protection Regulation, dále jen GDPR), které se pro řadu společností stalo pádným argumentem, proč se zajímat, jaké osobní údaje firma zpracovává, jak s nimi zachází a kde všude se vlastně v informačním systému vyskytují. Toho lze dosáhnout mimo jiné i pomocí implementace systému klasifikace, případně dalších bezpečnostních technologií, jak si ukážeme v následujícím textu. Jak vypadají klasifikační schémata? Klasifikovat je možné všechna ICT aktiva společnosti. U fyzických aktiv, jako je např. hardware, SW aktiv a služeb, je atributem klasifikace zpravidla dostupnost. U informačních aktiv, o kterých se budeme bavit dále, je to právě důvěrnost, která rozlišuje aktiva do jednotlivých tříd. Tyto třídy jsou pak definovány v tzv. klasifikačním schématu. Dle našich zkušeností nebývá definice klasifikačního schématu problémem. Ten nastává až s jeho prosazením do každodenního života společnosti. Organizace si pomocí vnitřního předpisu určí tři až pět tříd/kategorií, do kterých informace klasifikuje. Kritériem pro třídění bývá nejen důvěrnost, ale i přístup. Pro pojmenování tříd se nejčastěji používají následující označení a charakteristiky: Veřejné, neklasifikované označení pro nejnižší úroveň, která je popisována jako informace určené ke zveřejnění (webové stránky organizace, marketingové a informační materiály, letáky, informace z veřejných zdrojů). Přístup neoprávněných uživatelů k této třídě nemá negativní dopad na organizaci. Interní, pro vnitřní potřebu charakterizovány jako informace přístupné všem zaměstnancům nebo vybrané skupině, ale nikomu vně organizace bez souhlasu odpovědné osoby, kterou bývá vlastník informací. Typickým zástupcem jsou interní informace důležité pro provoz, vnitřní uspořádání a činnost organizace, vnitřní předpisy apod. Chráněné, citlivé, důvěrné informace vyžadující vyšší stupeň ochrany určené pouze vybraným jednotlivcům nebo skupinkám zaměstnanců (management, obchodní oddělení, systémoví administrátoři atd.), nesmí být volně přístupné ostatním zaměstnancům ani subjektům vně společnosti. Do této kategorie spadají osobní údaje, strategické informace a informace obchodního charakteru. U schémat, která mají více než tři stupně, bývá navíc definována samostatná kategorie pro osobní údaje nebo existuje více úrovní s vyšším stupněm ochrany (obchodní tajemství, přísně důvěrné, vysoce citlivé ). Součástí definic jsou i pravidla pro označování je určeno, které třídy a jak musí být viditelně označeny. V praxi se pak vkládá označení do záhlaví/zápatí dokumentu, těla nebo předmětu e-mailu, do výstupů z informačních systémů atd. Jak to běžně chodí v praxi V rámci implementací ISMS se u našich klientů většinou setkáváme se třemi stupni klasifikace informací: veřejné, interní a chráněné (konkrétní pojmenování kategorií se může lišit, případně jich může být i více). Do kategorie veřejných informací spadají všechny informace (dokumenty), které jsou ze své povahy primárně určeny ke zveřejnění. Typicky se jedná o reklamní a marketingové materiály a údaje na webových stránkách určené k prezentaci firmy a jejích služeb nebo zboží. Tyto informace nemusí být z pohledu důvěrnosti nijak chráněny. Do kategorie interních informací patří všechny informace, u kterých je žádoucí, aby zůstaly pouze v perimetru firmy, tj. 13

jsou určeny pro zaměstnance, případně další subjekty nebo osoby, které jsou vázány příslušnými dohodami o mlčenlivosti (NDA), a tyto informace potřebují např. ke splnění svých smluvních (dodavatelských) závazků. Pro tuto třídu klasifikace již musí být nastavena bezpečnostní pravidla, která zajistí odpovídající ochranu při přenosu a ukládání. Je to např. povinnost ukládání do úložišť s řízeným a monitorovaným přístupem, používání šifrování při zasílání vně organizace (e-mailem) nebo šifrování na discích notebooků či v jiných mobilních zařízeních. Do kategorie chráněných informací patří citlivé informace, u nichž není žádoucí šíření napříč celou organizací, protože jsou určeny jen pro vybraný okruh osob (např. management, vývojové oddělení, oddělení nákupu apod.). Pro tyto informace se již nastavují relativně přísná bezpečnostní opatření, která zahrnují povinná šifrování jak při uložení, tak i při různých formách přenosu, ukládání listinných dokumentů v trezorech, povinnou skartaci apod. Úskalí implementace Při implementaci schémat do praxe se setkáváme s celou řadou problémů. Na jedné straně je to nízké bezpečnostní povědomí uživatelé nevědí, jak klasifikovat a značit, nebo klasifikují nesprávně. V extrémních případech nejsou zaměstnanci schopni ani správně vyjmenovat příslušné stupně nebo označují dokumenty vlastními (i vymyšlenými) stupni. Řešením jsou pravidelná školení, která mohou být časově a někdy i organizačně náročná. U složitějších (mnohostupňových) schémat může činit potíže schopnost uživatelů mezi jednotlivými stupni rozlišovat: Je daný dokument citlivý nebo vysoce citlivý? Kam zařadit dokument obsahující strategické obchodní informace a zároveň i osobní údaje? Zde je kladen velký důraz na co nejpřesnější vymezení jednotlivých tříd. Nasazení může komplikovat i neochota klasifikaci používat, zejména označovat jednotlivé dokumenty odpovídající kategorií. Příčinou bývá nejasná či nevyžadovaná odpovědnost za označení dokumentu nebo jde jednoduše o laxnost zaměstnanců a jejich nadřízených. Pomoci může vložení značek přímo do organizačních šablon. Řada informací však vzniká i mimo tyto formální šablony (neformální dokumenty, e-maily, data v systémech, skenovaná data, ). Za komplikaci je považován i velký objem historických, tudíž neklasifikovaných dat. V tom případě se zpětná manuální klasifikace neprovádí, pouze je určeno datum, od kterého se všechny nově vzniklé informace klasifikují. Dříve vzniklé dokumenty se pak klasifikují při otevření nebo dalším použití. Na základě zkušeností se zaváděním klasifikačních schémat do praxe doporučujeme zvážit následující best practice: Klasifikační schéma definovat jednoduše a jednoznačně. Následně ke každé třídě stanovit pravidla pro vkládání značek a ochranu v celém životním cyklu (kdy a čím šifrovat, kam ukládat, jak posílat mimo chráněný vnitřní perimetr, jak likvidovat). Nesmí být opomenuto zahrnutí nejen elektronické, ale i fyzické podoby informací. Uživatele pravidelně školit, v rámci školení používat modelové příklady. Dbát na důslednou kontrolu a vynucování dodržování (kontrola nadřízenými, prověrka v rámci interního auditu, namátkové kontroly bezpečnostním manažerem). Z porušování vnitřních pravidel vyvozovat závěry. Značky zapracovat do všech firemních šablon i do používaných interních systémů a aplikací (pokud to umožňují). Definovat odpovědnost za klasifikaci a jmenovitě i osobu, na kterou se uživatelé mohou obrátit při řešení problémů s používáním klasifikace (bezpečnostní manažer, bezpečnostní správce, ). Stanovit klasifikaci pro nejčastěji používané skupiny informací tak, aby měli uživatelé zjednodušeno rozhodování, např. projektová dokumentace chráněné, pracovní smlouvy osobní údaje, web společnosti veřejné, SAP citlivé atd. Zavedením klasifikace informací a jejím vynucením se bude zabývat následující kapitola. Jak vynutit klasifikaci informací? Pro prosazení best practice v prostředí organizace doporučujeme využít vhodný nástroj pro klasifikaci informací. Nasazením nástroje odpadá nutnost neustálého školení uživatelů, kontroly dodržování a bonusem navíc je zvýšená efektivnost nástrojů, jako je DLP (Data Loss Prevention). Integrace se systémem pro sběr a vyhodnocení přijatých událostí a jejich následná pokročilá korelace s událostmi jiných systémů umožní identifikovat provozní a bezpečnostní problémy. Tyto systémy se označují zkratkou SIEM (Security Information and Event Management). Další integrací může být napojení na systémy pro řízení přístupu dat, které se označují zkratkou RMS (Right Management System). V praxi tyto systémy fungují tak, že uživatel může volitelně pro nějaký soubor s nižší klasifikací vybrat zabezpečení pomocí RMS, čímž je soubor zašifrován a klíč k odšifrování obdrží jen vybraní uživatelé, případně skupiny uživatelů. U vyšších klasifikačních stup- 14

ňů je toto zabezpečení vynucováno klasifikačním nástrojem. Obě integrace pak přispívají k celkovému přehledu organizace o tom, kde všude se nacházejí citlivé informace a jak je s nimi zacházeno. To může být velmi cenným vstupem k plnění požadavků opatření GDPR. K dalším nesporným výhodám nasazení nástroje patří možnosti hromadné a automatizované klasifikace dříve vzniklých dokumentů. Vhodný nástroj by měl mít vysokou míru konfigurovatelnosti tak, aby byl schopen pokrýt co nejvíce požadavků vyplývajících z bezpečnostních politik, firemních směrnic, norem či zákonů a nařízení. Mezi hlavní požadavky na tento nástroj patří: Snadná definice vlastních tříd klasifikace. Nastavení a změna podoby vizuální značky značku je nutné nastavit dle firemních grafických šablon. Často je nutné dát uživateli na výběr, jakou grafickou šablonu pro konkrétní dokument použije. Nastavení podoby DLP značky v metadatech dokumentu. Tento řetězec je třeba definovat nezávisle na použitém jazyce a zároveň musí být unikátní v rámci společnosti. Nastavení vynucení šifrování v závislosti na klasifikačním stupni. Je nutno podporovat různé možnosti šifrování, např. nativní šifrování balíku MS Office, zip nebo napojení na systémy pro řízení přístupu. Vedení auditních záznamů o klasifikaci dokumentu. Granulace nastavení na základě členství v určité doménové skupině. Možnosti (před)klasifikace šablon dokumentů. Logování událostí z procesu klasifikace přímo na systémy typu SIEM tak, aby bylo možné vytvářet korelace, které identifikují neklasifikující uživatele, polohu a práci s chráněnými daty či reklasifikaci z vyššího klasifikačního stupně na nižší. Klasifikace dat typu in use Za data typu in use považujeme ta, která jsou aktivně používána. Jako příklad můžeme uvést nově vytvářené dokumenty, stávající dokumenty, které aktivně používáme, nebo data uložená v e-mailech či kalendářích. Klasifikace těchto typů dat je možno dosáhnout jednoduchým nástrojem, který bude klasifikovat dokument při jeho otevření, uložení či vytisknutí. Pod klasifikací je myšleno vložení vizuální značky a zároveň vhodného řetězce do metadat dokumentu. Nástroj by měl uživateli umožnit úmyslnou reklasifikaci (tj. změnu stupně klasifikace) s tím, že předchozí klasifikace zůstává uložena v historii spolu se jménem uživatele, který změnu provedl, a datem a časem změny. Při reklasifikaci musí uživatel uvést důvod změny klasifikace. Při fungování nástroje rozlišujeme různé režimy klasifikace: 1. Pasivní rozhraní pro klasifikaci je uživateli přístupné v menu, ale uživatel není o nutnosti klasifikace při ukládání dokumentu / odesílání e-mailu nijak notifikován. 2. Volitelný při ukládání dokumentu / odesílání e-mailu / tisku se v případě, že dokument není klasifikován, aktivuje okno, které uživateli nabídne klasifikační menu a upozorní ho na požadavek. 3. Povinný při ukládání nebo tisku dokumentu / odesílání e-mailu se v případě, že dokument není klasifikován, aktivuje okno, které uživateli nabídne klasifikační menu a upozorní ho na nutnost klasifikace. Dokument bez provedení klasifikace nelze uložit / e-mail nelze odeslat. 15

Celý proces klasifikace dat by měl fungovat tak, že při ukládání nebo tisku neoklasifikovaného dokumentu nástroj zkontroluje, zda je dokument již oklasifikován. Jestliže není, nabídne uživateli možnost jej oklasifikovat v závislosti na zvoleném režimu klasifikace. Obdobným způsobem probíhá klasifikace e-mailů, kdy je vynucována pouze klasifikace odeslaných e-mailů. Příchozí e-maily jsou klasifikovány automaticky na základě již klasifikovaného e-mailu konverzace nebo manuálně při otevření či uložení e-mailu. Klasifikace historických dat ( data in-rest ) Jak jsme již zmínili v teoretickém úvodu, velkou komplikací jsou historická a neklasifikovaná data. V jediné společnosti můžou existovat miliony dokumentů, které řadíme do kategorie data in rest. Jediným řešením, jak správně klasifikovat historická data, je určení pravidel, která na základě obsahu identifikují, do jaké klasifikační třídy data patří. Pravidla jsou definována na základě expertní znalosti analytika podrobně obeznámeného se situací ve společnosti. Příkladem může být pravidlo, které kontroluje počet různých rodných čísel obsažených v jednom dokumentu. Když je počet nalezených rodných čísel vyšší než stanovený limit (např. 5), jedná se o seznam osob, potažmo zákazníků. Pokud tento příklad zevšeobecníme, neobejdeme se bez vyhledávání v dokumentu např. na základě regulárních výrazů včetně určení počtu výskytů. Dále potřebujeme k výsledkům vyhledávaní (hledaný řetězec a jeho počet) přidat váhu a poté je zkombinovat pomocí výrokové logiky do větších a komplexních pravidel. Tím získáme poměrně silný prostředek pro klasifikaci historických dat. Často se stává, že pravidla nejsme schopni navrhnout tak, aby byla úplně jednoznačná. Musíme tedy mít prostředek na to, aby systém klasifikaci navrhoval a zároveň návrh předal na schválení vlastníkovi dat, který na základě svého rozhodnutí dokument klasifikuje. Na závěr nám již stačí daná data oklasifikovat a uložit tak, aby nebylo změněno datum poslední modifikace. Klasifikace v middleware a v cloudu Při nasazení klasifikace ve firemním prostředí se mnohokrát střetáváme se situací, kdy dokumenty nejsou vytvářeny přímo na stanici uživatele, ale jsou vytvářeny v informačním systému nebo v cloudu. Příkladem může být situace, kdy uživatel vyplní webový formulář a poté mu informační systém vygeneruje dokument nebo externí dodavatel nahrává naskenované dokumenty do datového skladu. Také klasifikace dokumentů v prostředí cloudu je velmi problematická. Mezi hlavní zástupce cloudových řešení patří Microsoft Office 365 nebo Google Docs. Řešením je napojení informačních systémů, middleware či cloudových služeb na klasifikační službu, která vygenerovaný nebo v cloudu vytvořený dokument oklasifikuje, přidá metadata a vygeneruje události pro návazné systémy (např. systém pro centrální zpracování logů) či pro systémy typu SIEM. Integrace na klasifikační službu je zajištěna pomocí webového rozhraní pracujícího na principu REST (REpresentational State Transfer), což je v dnešní době jednodušší i mnohokrát preferovaná forma integrace, kde jednotlivé stavy aplikace a chování jsou vyjádřeny pomocí klíčové abstrakce unikátně identifikované URL adresou. Reprezentací klíčové abstrakce mohou být XML, HTML či data ve formátu JSON a definované operace nad těmito daty. Návaznost klasifikace na technologie Základem implementace klasifikace informací je úspěšná identifikace (nebo nalezení) informací, stanovení pravidel pro klasifikaci a adaptace procesů pro manipulaci s informacemi včetně jejich monitorování a ochrany. Existuje celá řada technologií, které pomáhají organizaci při implementaci klasifikace a vynucování stanovených procesů. Pro nalezení oblastí (např. datových úložišť), kde se nacházejí informace, je možné použít manuální analýzu infrastruktury a procesů společnosti, případně lze identifikaci provést poloautomatizovaně použitím některé z dostupných technologií. DLP technologie a klasifikační nástroje dokážou procházet datová úložiště a síťový tok, kde automatizovaně prohledávají obsah souborů a dokážou identifikovat hledané informace dle definovaných pravidel. Proces definice těchto pravidel může být komplikovaný a často není možné technologicky (např. regulárními výrazy) zajistit jejich správnou kategorizaci. Proto je často potřebné výsledky manuálně kontrolovat. Po jejich nalezení a případné kontrole je možné je automaticky klasifikovat a označit. DLP technologie dále pomáhají vynucovat stanovená pravidla pro zacházení s informacemi a zároveň chránit citlivé informace. Správná definice DLP politik je zásadním krokem v prevenci před úmyslným i neúmyslným únikem, předchází ji ale složitá analýza. Kontinuální klasifikace dat (e-mailů, souborů, dokumentů, ) zejména koncovými uživateli přispívá k jasné identifikaci citlivých informací pomocí detekce klasifikační značky nebo tagu na koncové stanici, na úložištích nebo v síťovém toku. Problémem při ochraně citlivých informacích můžou být systémy, které nejsou připraveny na klasifikaci a označování dat. Jsou jimi např. databáze, různé monitorovací nástroje nebo přenosná zařízení. Ochrana informací uložených 16

v databázových systémech je možná např. technologií databázového FW, která dokáže dle definované politiky kontrolovat přístup k chráněným datům. Prezenční vrstva nad databází (např. webová aplikace) musí být ale chráněna separátně stejně jako přístup k databázi, přenos dat (komunikace) atd. Ochrana dat na koncových stanicích uživatelů a na přenosných zařízeních je velice komplikovaná, zejména u zařízení, která opouštějí zabezpečenou infrastrukturu společnosti. Zásadou jsou samozřejmě best practice v ochraně koncových stanic (AV, DLP klient, silná bezpečnostní politika a informovanost uživatelů), pomoci ale mohou i RMS systémy, které na základě klasifikace a stanovené politiky řídí práva přístupu k těmto informacím. Monitorování neautorizovaného přístupu může být vhodnější než preventivní omezení přístupu. Jsou-li informace klasifikované, označování dat a stanovení správné DLP politiky přináší možnost monitorovat aktivity s citlivými informacemi (např. vytváření dokumentů, zasílání citlivých informací e-mailem, kopírování, přístup k sdíleným úložištím apod.). Tyto informace lze získávat z DLP systému, klasifikačního nástroje, RMS systému apod. Zejména v případě nasazení nástroje SIEM můžou být na základě definovaných pravidel identifikovány a vyhodnocovány bezpečnostní incidenty vedoucí k úniku a zneužití chráněných informací. Závěr Při nasazování klasifikace informací ve firemním prostředí se vždy snažíme pokrýt všechna místa, kde dokumenty vznikají (stanice, cloud, automaticky generované dokumenty z informačního systému). Na těchto místech se snažíme vynutit klasifikaci, což znamená, že uživatelé nemají jinou možnost než daná data klasifikovat, přičemž speciální postavení v procesu klasifikace mají historická data. Vynucení klasifikace či automatická klasifikace historických dat se v žádném případě neobejde bez vhodného nástroje, který by měl být jakýmsi spojovatelem mezi klasifikací informací, ochranou ztráty dat a vyhodnocováním incidentů v systému SIEM. Ing. Matej Kačic Matej Kačic Matej.Kacic@aec.cz Maroš Barabas Maros.Barabas@aec.cz Hana Vystavělová Hana.Vystavelova@aec.cz Absolvent FIT VUT v Brně včetně doktorského studia, kde se zaobírá bezpečností informačních systémů a bezdrátových sítí. Je členem skupiny Security@FIT na VUT v Brně, přednáší na akademické půdě a věnuje se publikační činnosti. Od roku 2013 pracoval jako Security Consultant ve společnosti AEC v divizi technologií, kde zastává roli architekta bezpečnosti, a od roku 2017 roli vedoucího divize technologií. Hlavně se pohybuje v oblasti návrhu a auditu bezpečné síťové infrastruktury. Mezi jeho nosné technologie se řadí NG firewally, NBA a sandboxy. V posledních dvou letech zastává roli product ownera nástroje DocTag určeného pro klasifikaci dokumentů. Ing. Maroš Barabas, Ph.D. Vystudoval FIT VUT v Brně, kde získal doktorát v oblasti síťové behaviorální bezpečnosti. Od roku 2012 pracuje ve společnosti AEC, kde začal na pozici bezpečnostního konzultanta, vedl divizi bezpečnostních technologií a v současné době na pozici vedoucího produktového managementu zodpovídá za strategii produktového portfolia AEC. Má bohaté zkušenosti v oblasti návrhu bezpečných architektur, tvorby strategie bezpečnosti a v posledních letech se soustřeďuje na pokročilé technologie, budování SOC center a šíření bezpečnostního povědomí na konferencích, workshopech a na univerzitách. Mgr. Hana Vystavělová Vedení projektů v oblasti bezpečnosti IS, vedení týmu, strategie a řízení projektů, metodické vedení. Audity systémů řízení dle ISO/IEC 27001, analýza rizik, analýza současného stavu informační bezpečnosti, audit IS, tvorba bezpečnostní dokumentace, řízení kontinuity činností, havarijní plánování, implementace bezpečnostních opatření a jejich zavedení do prostředí organizace, systémy řízení informační bezpečnosti, projektové řízení, klasifikace informací a implementace nástrojů pro její vynucování, bezpečnost ve vývoji SW (SSDLC). POUŽITÉ ZDROJE [ 1 ] BS 7799-2:1999: Information Security Management, Part 2: Specification for Information Security Management Systems, (April 2001). [ 2 ] [2] ISO/IEC 27001:2013: Information technology Security techniques Information security management systems Requirements, International Organization for Standardization, Geneva, Switzerland. [ 3 ] Zákon č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti [ 4 ] Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů [ 5 ] Vyhláška č. 316/2014 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti [ 6 ] Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů [ 7 ] Nařízení (EU) 2016/679 General Data Protection Regulation Obecné nařízení o ochraně osobních údajů [ 8 ] Bell, D. E. LaPadula, L. J.: Secure Computer Systems: Unified Exposition and Multics Interpretation, Report MTR-2997 Rev. 1, MITRE Corporation, Bedford, Mass, 1976. [ 9 ] [9] Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153, The Mitre Corporation, June 1975. 17