Je třeba si uvědomit, že každý SW prochází zpravidla během svého vývoje několika různými prostředími. Běžně se jedná o vývojové, testovací a produkční prostředí. Vzhledem k tomu, že testovací prostředí se může ve velkých společnostech dále dělit na integrační a akceptační, jsme postaveni před poměrně nelehký úkol: zajistit zachování důvěrnosti, integrity a dostupnosti informačních aktiv během celého životního cyklu vývoje softwaru a to ve všech těchto čtyřech prostředích. Podívejme se nyní společně na největší rizika, kterým musíme čelit.

Riziko: narušení důvěrnosti

Hrozba: Únik důvěrných dat z vývojového a testovacího prostředí. Je zajímavé, že zatímco data v produkčním prostředí bývají velice často chráněna a společnosti vydávají nemalé prostředky na jejich ochranu, tak ve vývojovém a testovacím prostředí tomu tak není. Podle průzkumu, který provedla společnosti Compuware a organizace Ponemon Institute, používá většina společností při vývoji a testování aplikací skutečná data.

Opatření: Ve vývojovém a testovacím prostředím nepracovat s reálnými daty. Pokud je to možné, mělo by se provést jejich zneplatnění, např. formou kódování, scrambling, apod. V opačném případě musí být před přenesením skutečných dat do vývojového nebo testovacího prostředí zajištěn souhlas vlastníka. Vlastník by měl být s rizikem úniku důvěrných dat prokazatelně seznámen, toto riziko akceptovat a s testováním nad reálnými daty souhlasit. Podepisování nejrůznějších NDA je sice možné, ale v praxi vás to stejně před únikem důvěrných dat neochrání.

Riziko: narušení integrity

Hrozba: Neupravený konfigurační soubor může způsobit, že server z vývojového nebo testovacího prostředí bude komunikovat přímo se serverem z produkčního prostředí. Může se tak snadno stát, že např. požadavek na smazání vybraných záznamů se místo na DB serveru v testovacím prostředí provede na DB serveru v produkčním prostředí. Pokud se na tuto skutečnost nepřijde včas, může to mít pro společnost zcela katastrofální následky.

Opatření: Jako vhodné řešení se jeví oddělit od sebe vývojové, testovací a produkční prostředí a to tak, aby servery z jednoho prostředí nemohly komunikovat se servery z druhého prostředí.

Hrozba: Osoba s přístupem do produkčního i testovacího prostředí může provést úmyslný nebo úmyslný a z pohledu společnosti nežádoucí zásah do SW vybavení a dat

Opatření: Vývojářský tým by měl mít přístup pouze do vývojového a integračního prostředí, neboť nemá dělat nic jiného než unitní a integrační testy. Testovací tým by měl mít přístup zase jen do akceptačního prostředí.

Hrozba: Osoba s přístupem do více prostředí si může splést prostředí v jakém pracuje a provést nežádoucí změnu v SW vybavení a datech.

Opatření: Pokud chce společnost toto riziko co nejvíce eliminovat, je asi nejlepším řešením zablokovat uživateli po dobu testování přístup do konkrétní aplikace v produkčním prostředí a po skončení testů mu ho zase odblokovat. Vzhledem k tomu, že se každé testování velice pečlivě plánuje (předpokládám, že váš Plán testování obsahuje všechny náležitosti), tak kdo a kdy bude testovat je v dostatečném časovém předstihu známo a tak by pro vás neměl být problém účet testera do aplikace v produkčním prostředí zablokovat. Je na test managerovi, aby si ověřil a zajistil, že přístupy testerů do aplikace v testovacím prostředí jim budou aktivovány až poté, co jim bude zablokován přístup do aplikace v produkčním prostředí. Výhodou tohoto řešení je, že pracovník se nemusí nikam stěhovat a může testování provádět ze svého pracoviště. Tímto způsobem lze výrazně ušetřit, neboť není nutné budovat speciální pracoviště a vybavovat ho dalšími počítači, které by byly navíc mimo testování nevyužity.

Opatření: Přístup do testovacího prostředí umožnit jen z počítačů, které budou umístěny v chráněných a oddělených prostorách společnosti. Na takové pracoviště se bude muset pracovník před započetím testu dostavit. V praxi se bohužel ukazuje, že ani přesun pracovníka na jiný počítač není dostatečnou zárukou. Je možné si to vysvětlit tím, že většina kancelářských prostor vypadá úplně stejně, takže za chvíli pracovník už ani neví, kde že to vlastně sedí.

Opatření: Jednotlivá prostředí od sebe odlišit např. odlišnou barvou okna, změnou promptu, titulku okna, jiným pozadím pracovní plochy apod.. Bohužel, stejně jako v předchozím případě i zde se ukazuje, že toto opatření v praxi selhává, protože v okamžiku, kdy mají testeři současný přístup do více prostředí a mezi jednotlivými prostředími se přepínají, vždy se najde někdo, kdo se splete. Toto opatření lze nasadit snad jen jako doplněk k předchozím opatřením, samo o sobě riziko moc nesnižuje.

Riziko: narušení dostupnosti

Hrozba: Nežádoucí síťová komunikace iniciována servery z vývojového nebo testovacího prostředí může vést až k zahlcení produkčních serverů a síťové infrastruktury.

Opatření: Jako vhodné řešení se jeví oddělit od sebe vývojové, testovací a produkční prostředí. To lze provést např. za použití firewallů a nastavení příslušných pravidel spočívající v povolení komunikaci pouze pro konkrétní IP adresu, protokol a port.

Závěr: Je zajímavé, že ač společností investují nemalé prostředky do vybudování jednotlivých prostředí, tak jejich zabezpečení spočívající v implementaci vhodných opatření věnují minimální nebo vůbec žádnou pozornost. A jak výše uvedená rizika zvládáte vy ve vaší společnosti?

Related posts:

1. Testovací log
2. Testovací scénář
3. Testovací případ

Bezpečnost obecně je chápána jako ochrana něčeho před poškozením, zničením, ztrátou nebo zcizením. Informační bezpečnost si potom můžeme dle výše uvedené definice vyložit jako ochranu informace před poškozením, zničením, ztrátou nebo zcizením. V odborné literatuře se však místo poškození informace používá pojem narušení integrity, o zničení informace se hovoří jako o narušení dostupnosti a ztráta nebo zcizení informace zase bývá označována jako narušení důvěrnosti.

Abychom měli úplně jasno, měli bychom vědět z jakých částí se skládá informační systém. Uvažujme proto takto. DATA se obvykle nacházejí na nějakém MÉDIU (HD, CD, DVD, flash disk). Abychom s médiem mohli pracovat, potřebujeme k tomu nějaký HW (osobní počítač, server). Ten sám o sobě nestačí, musí na něm být nainstalován nějaký SW (OS, APLIKACE). Pokud mají být data přístupná pro více uživatelů, jsou obvykle uložena na nějakém serveru a přistupuje se k nim prostřednictvím SÍTĚ (LAN, MAN, WAN). Všechno je umístěno v nějakých PROSTORÁCH a  o celý systém se někdo stará a někdo ho používá. Ano, jsou to LIDÉ.

Mimochodem touto naprosto jednoduchou úvahou jsme vlastně provedli to, čemu se odborně říká dekompozice informačního systému a identifikace aktiv. Pokud vás napadají ještě nějaká další aktiva, vězte, že budou patřit do některé z těchto skupin:

• DATA
• MEDIA
• HW
• SW
• SÍŤ
• PROSTORY
• LIDÉ

Pokud máme zavést vhodná opatření k zajištění bezpečnosti informací, je zřejmé, že budeme muset odpovídajícím způsobem chránit všechna výše uvedená aktiva a zajistit bezpečnost informací během celého jejich životního cyklu. Podívejme se proto znovu na aktiva, která jsme si již identifikovali a zamysleme se nad tím, jak jejich bezpečnost zajistit.

Personální bezpečnost

Představují lidé, kteří IS spravují a používají, pro informace nějaké nebezpečí? Jistěže ano. Uvádí se, že až 80% bezpečnostních incidentů je způsobeno vlastními zaměstnanci. Z těchto důvodů je třeba vybírat kvalitní lidi, udržet si je, provádět jejich školení, hodnocení a v případě nutnosti se věnovat i jejich propouštění. Této problematice se věnuje personální bezpečnost.

Fyzická bezpečnost

V prostorách společnosti se nachází HW, média, lidé a ty je třeba chránit nejen před přírodními hrozbami, jako je například oheň nebo voda, ale i před fyzickými útočníky. Ochranu těchto hmotných aktiv má obecně na starost fyzická bezpečnost.

Logická bezpečnost

Ke zpracování dat je obvykle nutný nějaký SW, běžně se jedná o aplikaci, databázi a operační systém. Pokud má být zajištěna důvěrnost, integrita a dostupnost dat, je potřeba k nim řídit přístup, což má na starost logická bezpečnost.

Komunikační bezpečnost

Data jsou přenášena po síti a ta může být útočníkem odposlouchávána nebo může být zahlcena. Ochranu proti těmto hrozbám má na starost komunikační bezpečnost.

Organizační bezpečnost

Řízení bezpečnosti, ustanovení odpovědnosti a povinnosti jednotlivých skupin a osob v organizaci nejčastěji formou bezpečnostní politiky a bezpečnostních standardů má na starost organizační bezpečnost, někdy nazývaná též jako administrativní bezpečnost.

Z výše uvedeného vyplývá, že ochrana informací vyžaduje zavedení vhodných opatření na úrovni fyzické, logické, personální, komunikační a organizační bezpečnosti. To, jaká opatření by to přesně měla být, je možné zjistit jen na základě analýzy rizik, které bych se rád věnoval v některém svém dalším článku.

Related posts:

1. Informační bezpečnost: životní cyklus informace
2. Bezpečnost-náklady-použitelnost
3. Vývojové-testovací-produkční prostředí a rizika

Nežádoucí odhalení (Disclosure), modifikace (Alteration) nebo zničení (Destruction) určitých informací může vést k finanční ztrátě, poškození dobrého jména společnosti a v nejhorším případě i k ohrožení života jejich zaměstnanců nebo klientů. Z těchto důvodů je nutné informace před narušením důvěrnosti (Confidentality), dostupnosti (Availability) a integrity (Integrity) odpovídajícím způsobem chránit a to během celého jejich životního cyklu.

Vždy je třeba zvážit, jak vysoký stupeň ochrany si daná informace opravdu zaslouží.  tj. jaký soubor opatření na úrovni organizační, logické a fyzické bezpečnosti je třeba přijmout. Především proto, že zavedení těchto opatření bude něco stát a přinese určitá omezení při práci s informacemi. Stanovit skutečně odpovídající úroveň ochrany je možné jedině na základě detailní analýzy rizik. Vzhledem k tomu, že v praxi není dost dobře možné, aby si každý vlastník informace prováděl analýzu dopadů, hrozeb a zranitelností sám, protože na to většinou nemá čas a často ani odpovídající znalosti, je běžné, že vrcholový management společnost nechá za tímto účelem provést analýzu rizik.

Cílem takové analýzy je identifikace informací, které společnost zpracovává a dále určení hrozeb, které by mohly ohrozit důvěrnost, integritu a dostupnost těchto informací. Pro jednotlivé typy informací se poté na základě takto provedené analýzy rizik určí formou nějakého závazného dokumentu klasifikační stupně a zároveň se pro jednotlivé klasifikační stupně rozhodne o zavedení příslušných opatření, které musí všichni zaměstnanci dodržovat, aby byla zajištěna důvěrnost, integrita a dostupnost těchto informací.

Dostupnost a důvěrnost
Pokud budeme klást důraz jen na zajištění dostupnosti a důvěrnosti informací bez ohledu na zajištění jejich integrity, může dojít k situaci, že informace jsou sice oprávněné osobě dostupné v okamžiku, kdy je potřebuje, avšak tato osoba nemá žádnou záruku, že nedošlo k jejich nežádoucí modifikaci.

Veškerá pozornost byla soustředěna jen na zajištění dostupnosti a důvěrnosti a otázka integrity byla podceněna.

Důvěrnost a integrita
Pokud budeme klást důraz jen na zajištění důvěrnosti a integrity informací bez ohledu na zajištění jejich dostupnosti, může dojít k situaci, že informace jsou sice dostatečně chráněny proti nežádoucí modifikaci a vyzrazení, ale nejsou dostupné v okamžiku, kdy s nimi oprávněná osoba potřebuje pracovat.

Veškerá pozornost byla soustředěna jen na zajištění integrity a důvěrnosti a otázka dostupnosti byla podceněna.

Integrita a dostupnost
Pokud budeme klást důraz jen na integritu a dostupnost bez ohledu na zajištění důvěrnosti, můžeme se dostat do situace, že informace sice bude dostatečně chráněna proti nežádoucí modifikaci, ale dostane se i k osobě, která není oprávněna se s ní seznamovat.

Veškerá pozornost byla soustředěna jen na zajištění integrity a dostupnosti a otázka důvěrnosti byla podceněna.

Nyní se již můžeme zamyslet nad tím, jak souvisí požadavky na zajištění důvěrnosti, integrity a dostupnosti informací s předmětem podnikání a tedy i typem zpracovávaných informací a poskytovaných služeb. Z výše uvedeného vyplývá, že ve většině případů je třeba věnovat pozornost všem bezpečnostním atributům, ne vždy je však možné a efektivní věnovat všem atributům stejnou pozornost, protože každé opatření něco stojí. V praxi se tak klade na některý atribut větší důraz. Jako příklad si vezmeme např. transakční systém v bance. Je v celku logické, že bude kladen spíše větší důraz na integritu a dostupnost než na důvěrnost, to především proto, že veškeré transakce, které se uskutečňují v elektronické podobě, musí být správně a v požadovaném čase zaúčtovány. Důvěrnost je jistě také důležitá a její zajištění je navíc vyžadováno zákonem, nicméně možná ztráta plynoucí z narušení důvěrnosti je ve většině případů mnohem nižší, než ztráta způsobená narušením integrity nebo dostupnosti. Je tomu tak proto, že za únik informací o klientech nebo jejich transakcích, pokud se na to přijde, může být sice udělena pokuta, např. na základě série občanských stížností a rozhodnutí o náhradě škody, ale ta zdaleka nedosahuje výše možných ztrát v případě narušení integrity nebo dostupnosti.

Je třeba vzít v úvahu, že nejvyšší pokuta, kterou může úřad pro ochranu osobních údajů udělit právnické osobě je 5.000.000 Kč, v případě fyzické osoby 1.000.000 Kč. Položme si dále otázku, kolik pokut úřad za své existence jednotlivým firmám uložil a jaká byla výše těchto pokut. Zamysleme se také nad tím, jaká je nabídka a poptávka na trhu po produktech k zajištění dostupnosti a integrity a produktech pro zajištění důvěrnosti. Vezměme také v úvahu skutečnost, že zatímco v případě narušení dostupnosti informací se o tom jejich vlastník často hned dozví, tak v případě narušení integrity je šance na odhalení již mnohem nižší a v případě narušení důvěrnosti mohou informace z firmy dlouhodobě unikat a daná firma se o tom dokonce vůbec nemusí dozvědět, neboť konkurence těchto informací použije pro sebe. Lze se proto jen domnívat, že obdobný přístup k důvěrnosti, integritě a dostupnosti bude zaujímat nejspíš většina podniků, a nelze ho odmítat, protože má své jasné opodstatnění. Pokud jde o důvěrnost, ta je na prvním místě např. v armádě.

Poznámka: Důvěrnost (Confidentality), integrita (Integrity) a dostupnost (Availability) se označuje jako CIA triáda. Jejím opakem je DAD triáda: odhalení (Disclosure), modifikace (Alteration) nebo zničení (Destruction). Můžeme také říci, že vlastník usiluje o CIA a útočník o DAD.

Related posts:

1. CIA: Dostupnost
2. CIA: Integrita
3. CIA: Důvěrnost

O zničení (destruction) určitých informací se v informační bezpečnosti hovoří jako o narušení jejich dostupnosti (availability). Co to ale znamená, když výrobce u svého systému uvádí dostupnost 99,999%? Pokud jako základ vezmeme 365 dní v roce, tak jednoduchým výpočtem zjistíme, že systém může být až 5 minut za rok nedostupný.

Na první pohled se zdá, že dostupnost symbolizovaná pěti devítkami je dostatečná, musíme si ale uvědomit, že systémem se zde dost často myslí jen samotný HW, nikoliv operační systém a aplikace. U operačních systémů a aplikací se tyto parametry záměrně neuvádí a jejich výrobce radši žádné záruky ani neposkytuje nebo se omezuje na lakonické prohlášení, že systém je navrhnut pro běh 99,999%. Nicméně jsou to především OS a aplikace a v některých případech i síť, které dost často bývají hlavní příčinou nedostupnosti většiny IS. Nedostupnosti, která zdaleka překračuje výše proklamovanou hodnotu. A uživateli IS je víceméně jedno, co je onou příčinou, pro něj je nedostupný systém resp. jeho služby, kterých využívá.

Ač je populární uvádět dostupnost systému v % za rok, je mnohem přesnější a praktičtější uvádět RTO (Recovery Time Objective) a RPO (Recovery Point Objective), kde:

• RTO vyjadřuje, za jak dlouho po výpadku musí být systém funkční, resp. jak dlouhý výpadek může být tolerován. Pro RTO rovno nule by to znamenalo vybudovat zcela redundantní infrastrukturu.
• RPO vyjadřuje, kolik práce resp. jaké množství dat může být ztraceno. Jde o to, že záloha je dejme tomu naplánována na 03:00 a v 09:00 dojde k havárii diskového pole. Změněny, které byly provedeny mezi 03:00 a 09:00 jsou tedy nenávratně ztraceny.

Dobu nedostupnosti (RTO) a ztrátu dat (RPO) je třeba od sebe odlišovat, když se provádí business impact analýza, od které se odvíjí návrh celé architektury řešení. Častou chybou je, že se uvažuje jen o RTO a na RPO se zcela zapomíná.

Jako logické řešení se nabízí v případě, kdy je požadována vysoká dostupnost, vše duplikovat. A duplikovat lze opravdu vše, od napájení přes HDD, které se zapojí jako RAID1, řadiče, až po celý počítač nebo síť. Ovšem v době, kdy je většina systémů postavena na vícevrstvé architektuře, to znamená duplikovat minimálně webový server, aplikační server a databázový server. Takový systém se stává potom nejen složitějším a tedy i náročnějším na správu, ale především se vzrůstající složitostí roste i počet míst, na kterých může dojít k selhání a celé řešení pak musí být schopno se samo vypořádat se závadou, která může vzniknout prakticky na kterémkoliv prvku nebo síťovém spojení mezi kterýmikoliv prvky.

Jestliže dostupnost každé komponenty je 99,999% potom dostupnost celého řešení lze matematicky vyjádřit jako třetí mocninu 99,999% (Počítáme s 99,999% dostupností pro každou komponentu, 99,999% dostupností pro jednoduchou konfiguraci a s 99,999% pro zdvojenou konfiguraci) což je 99,997% tedy výpadek o délce necelých 16 minut za rok.

Tohle však není až tak podstatné, protože se objevuje mnohem závažnější problém a to, že v okamžiku, kdy provedeme duplikaci celého řešení (jednu konfiguraci si označíme jako primární a druhou jako sekundární, někdy se používá termín aktivní a pasivní), musíme zajistit, že v případě výpadku kterékoliv primární komponenty dojde k přepnutí na sekundární komponentu a ta přejde z pasivního módu do aktivního. Jestliže má toto řešení fungovat, musí být navíc zajištěna synchronizace mezi komponentami, aby bylo možno obsloužit stávající uživatele systému, dokončit zpracování jejich transakcí a nové uživatele směrovat na právě aktivní komponentu. Ten, kdo bude takové řešení navrhovat, bude muset tyto stavy ošetřit a to jak v samotné aplikaci, tak i na síťové vrstvě, a toto není v žádném případě triviální úkol. Protože pokud tyto stavy neošetří, hrozí například tzv. Split Brain Syndrom, kdy by v důsledku ztráty komunikace mezi primární a sekundární konfigurací mohly začít obě části pracovat na sobě zcela nezávisle a po obnově spojení by pak každá část obsahovala jiná data a transakce a systém by nevěděl jak je sloučit. Byla by tak sice zajištěna vysoká dostupnost, ale narušena integrita.

Pozn.: Co se týká používání pojmů primární-sekundární vs. aktivní-pasivní, jde o to, zda duplikované komponenty jsou naprosto stejné nebo ne. V případě, že je použito v záložním řešení méně výkonných komponent je vhodnější hovořit o primární a sekundární části. Pojmy aktivní a pasivní zase naopak lépe vystihují stav, ve kterém se tyto dvě části nacházejí a je vhodnější je používat v případě naprosto identických komponent.

Related posts:

1. CIA: Důvěrnost-Integrita-Dostupnost
2. CIA: Integrita
3. CIA: Důvěrnost