Computer Associates CZ, s.r.o. Pob ežní 3, Praha 8

Security Management - Cesta k bezpeþné infrastruktuĜe IT Computer Associates CZ, s.r.o. PobĜežní 3, 186 00 Praha 8

1 Security Management Jedním z nejdĤležitČjších IT témat je i nadále bezpeþnost. Podniky musí mnohem intenzivnČji než dĜíve chránit rostoucí poþet rĤzných zdrojĤ a spravovat další interní a externí uživatele. SouþasnČ jsou vystaveni stále poþetnČjším útokĤm a jiným z hlediska bezpeþnosti rozhodujícím jevĤm. Široké spektrum potenciálních uživatelĤ informaþních zdrojĤ podnikĤ sahá od pracovníkĤ pĜes zákazníky a konkurenty až k obávaným hackerĤm. Jednoduchý patchwork z bezpeþnostních kontrol proto již delší dobu nestaþí. Požadováno je spíše obsáhlejší Ĝešení, které usnadĖuje proaktivní management bezpeþnostního prostĜedí. Odvracení útokĤ na informaþní zdroje a udržení produktivity pracovníkĤ vyžaduje na všech úrovních bezpeþností infrastruktury reakce zamČĜené na potĜeby. Jakmile bude instalováno, bude obsáhlé Ĝešení pro Security Management nabízet nejrĤznČjší užitek: menší náklady, dobu výpadkĤ a ztráty produktivity a lepší dodržování smČrnic. Když podnik ví, že jsou jeho informaþní aktiva a zdroje bezpeþné, mĤže se plnČ koncentrovat na svĤj obchodní provoz.

1.1

Bezpeþnost – souþást celku

Spoleþnost Computer Associates (CA) poskytuje svými eTrust Security Management Ĝešeními svou expertizu v oblasti management softwaru také pro problémy dnešního managementu bezpeþnosti. Silný management bezpeþnosti, jaký nabízí eTrust Security Management, je pĜedpokladem k zachování rozsáhlého pĜehledu o stále komplexnČjších bezpeþnostních prostĜedích. Jde o to zajistit, aby bezpeþností data byla využitelná pro rozhodnutí, v pĜípadČ potĜeby rychle získat odpovČdi na kritické otázky a na základČ tČchto odpovČdí moci cílenČ a proaktivnČ jednat. To je cesta k ochranČ aktiv a informací celého podniku – nezávisle na obchodím modelu nebo na struktuĜe podniku.

2 Nový standard pro Vaši bezpeþnost: management eTrust Security Management Ĝešení od spoleþnosti CA nabízejí flexibilitu, která je nezbytná k pĜizpĤsobení bezpeþnostních opatĜení obchodním požadavkĤm Vašeho podniku. Díky automatizaci, zjednodušení a racionalizaci procesĤ a také zviditelnČní reálného þasu mnoha každodenních bezpeþnostních jevĤ mohou být v pravý þas pĜijímána ta pravá opatĜení. Tímto zpĤsobem se zvyšuje operativní efektivita a lze tlumit náklady a rizika. SouþasnČ je zajištČno dodržování pĜedpisĤ. K Ĝešením eTrust Security Management spoleþnosti CA patĜí oblasti Ĝešení eTrust™ Identity and Access Management, eTrust™ Threat Management a eTrust™ Security Information Management. Tato Ĝešení nabízejí celistvý základ pro všechny bezpeþností aspekty. Je možné je plynule vzájemnČ integrovat a spolupracovat s již dostupnými bezpeþnostními systémy. Lze tak dosahovat dalších úspor nákladĤ a vylepšené úrovnČ bezpeþnosti. eTrust Identity and Access Management x

Nabízí efekty úspor.

x

Vylepšuje produktivitu uživatelĤ.

x

UsnadĖuje dodržování pĜedpisĤ.

S eTrust Identity and Access Management je možné prostĜednictvím zadávacích, implementaþních a kontrolních funkcí efektivnČ spravovat identity uživatelĤ a pĜístupová oprávnČní. Digitální identity je možné spravovat po celou dobu jejich životního cyklu. Dále jsou k dispozici nástroje jako automatizované pracovní postupy a schvalovací procesy, pĜidČlování zdrojĤ na základČ uživatelĤ, zabezpeþený pĜístup, Single Sign-On a samosprávní funkce. Bezpeþnost aplikací, které jsou podnik kritické, je rozsáhle chránČna – nezávisle na provozním systému, platformČ a podnikovém softwaru, a nezávisle na tom, zda zdroje pocházejí ze sítČ nebo jsou distribuovány heterogenními systémy. eTrust Identity and Access Management Ĝešení nabízejí výkonné kontrolní funkce pro dodržování bezpeþnosti dat, pro zabránČní neoprávnČným pĜístupĤm a pro dodržování pĜedpisĤ. Centrální Ĝízení a konzistentní prosazování smČrnic podporuje redukci nákladĤ, operativní efektivitu a snižování rizik. Tato Ĝešení navíc nabízejí nejsilnČjší dostupnou ochranu jak pĜed interními, tak i pĜed externími narušeními bezpeþnosti a zajišĢují tak i dodržování pĜedpisĤ. Security and Protection of Information 2005

141

eTrust Threat Management x UmožĖuje proaktivní snižování rizik. x Minimalizuje doby výpadkĤ systému. x Krátké doby odezvy díky centrálnímu Ĝízení. eTrust Threat-Management Ĝešení chrání Vaše systémy vysoce úþinnými preventivními opatĜeními a urychlenou reakcí na bezpeþnostní události. NejmodernČjší technologie odvracejí viry, spamy a závadné obsahy, které ohrožují Váš e-mailový styk a Vaše obchodní aplikace. Váš bezpeþností IT personál získává možnost identifikovat ve Vaší infrastruktuĜe hrozby a slabá místa. Lze tak pĜijímat vhodná opatĜení k tomu, aby se událostem dalo pĜedem zabránit.

eTrust Security Information Management x ZajišĢuje dostupnost bezpeþnostních dat pro rozhodnutí. x Zvyšuje pohotovost k obranČ. x Zvyšuje administrativní efektivitu a snižuje náklady. eTrust Security Information Management Ĝešení vytváĜejí z toku dat dodaných z rĤzných systémĤ a aplikací využitelné informace a solidní podklady pro rozhodnutí. Data jsou analyzována a roztĜídČna a poté pĜehlednČ znázornČna. Minimalizuje se tak riziko pĜerušení obchodních procesĤ a lze dodržovat pĜedpisy. eTrust Security Information Management Ĝešení Vám dopomohou k celkovému pĜehledu, který Vám poskytne úþinnou podporu pĜi kontrole nákladĤ, získávání podkladĤ pro rozhodnutí a pĜi zvyšování efektivity Vašeho bezpeþnostního managementu – neboĢ pĜi tom není nic dĤležitČjší než schopnost pĜijmout v pravou chvíli rozhodnutí.

3 eTrust Identity and Access Management: management „Who's Who” Správa uživatelĤ – tedy správa digitálních identit zamČstnancĤ, zákazníkĤ, obchodníkĤ a partnerĤ a jejich pĜístupových práv – pĜedstavuje pro podniky velkou výzvu. Pracovníci odpovČdní za bezpeþnost IT se musí dbát na postarat o to, aby interní uživatelé mohli co nejrychleji online aktivnČ a proaktivnČ pracovat. SouþasnČ musí být umožnČn pĜístup externích uživatelĤ a partnerĤ k podnikovým zdrojĤm, ovšem také kontrolován. Tento úkol je vysoce komplexní, neboĢ jediný uživatel mĤže potĜebovat pĜístup na velké množství platforem, systémĤ a aplikací. Zdržování pĜístupu externích zákazníkĤ a partnerĤ k obchodním systémĤm mohou zpĤsobit významné náklady. SouþasnČ však musí být také zajištČna ochrana citlivých podnikových dat. A k dodržování pĜedpisĤ musí být koneþnČ v rámci celého podniku prosazena silná bezpeþnostní smČrnice a pĜípadnČ musí docházet k protokolování (Audit Trail). eTrust™ Identity and Access Management Suite od spoleþnosti CA v souþasné dobČ nabízí rozsáhlé nástroje zadávání, implementaci a kontrole identit a pĜístupových práv. Tato Ĝešení umožĖují centrální a automatické vytváĜení uživatelských úþtĤ a pracovních tokĤ, poskytování IT a dalších zdrojĤ a souþasnČ snížení nákladĤ díky automatizovaným postupĤm. Navíc zvyšují produktivitu uživatelĤ integrovaným Single Sign-On a personalizovanými, na portále založenými samosprávnými funkcemi, mj. pro obnovování hesel. PodpoĜeny silnými mechanismy pĜístupových oprávnČní a archivem identit, který lze podrobnČ pĜizpĤsobit aktuálním a budoucím potĜebám, spravují eTrust nástroje k managementu identit digitální identity podniku ve všech jejich aspektech. Od prvního dne, kdy nový zamČstnanec zahájí svou práci, ozve se obchodní partner nebo zákazník reaguje na nabídku služeb, bude tento vztah transparentnČ a kontrolovanČ spravován. V pĜípadČ zmČny obchodní spolupráce budou automaticky provedeny nezbytné úpravy pro pĜístup k systému. Bude tak zamezeno „osiĜelým“ uživatelským úþtĤm, zbyteþnému hromadČní práv a narušením bezpeþnosti. eTrust Identity and Access Management Ĝešení mohou pro všechny platformy, provozní systémy a obchodní aplikace implementovat pĜísné pĜístupové smČrnice, lhostejno zda zdroje pocházejí ze sítČ nebo nikoli. Centrální management, personalizace zvyšující produktivitu a konzistentní aplikace smČrnic pĜispívají ke snížení nákladĤ. eTrust nástroje k Access Management jsou v souþasné dobČ nejsilnČjšími a nejproaktivnČjšími dostupnými bezpeþnostními Ĝešeními. Celopodnikovou kontrolou narušení pĜístupu nabízejí ochranu jak pĜed vnitĜními, tak pĜed vnČjšími napadeními.

142

Security and Protection of Information 2005

eTrust Identity and Access Management Ĝešení od spoleþnosti CA pĜedstavují základ efektivního auditování uživatelĤ a jejich pĜístupu k podnikovým zdrojĤm v souladu s ochranou dat. eTrust Identity and Access Management zahrnuje: x

eTrust™ Access Control - umožĖuje jednotnou, efektivní úpravu pĜístupu pro pĜidČlené platformy a provozní systémy. Toto Ĝešení nabízí kontrolu pĜístupu vycházející ze smČrnic, kterou se zjišĢuje, kteĜí uživatelé mají pĜístup k urþitým systémĤm, aplikacím a souborĤm, která oprávnČní právČ teć mají a v kterých dobách je pĜístup poskytován.

x

eTrust™ Admin - podporuje automatické pĜiĜazování IT a dalších zdrojĤ uživatelĤm, obnovování hesel uživateli samotnými a synchronizaci hesel pro On-Demand prostĜedí.

x

eTrust™ Single Sign-On - prostĜednictvím jednoúrovĖového pĜihlašovacího Ĝízení („Single Sign-On“) automatizuje bezpeþný pĜístup k aplikacím.

x

eTrust™ Site Minder - úpravou pĜístupu k webovým zdrojĤm a službám s flexibilními metodami oprávnČní k pĜístupu a vyhrazeným, odstupĖovaným oprávnČním chrání online investice a kritické webové služby podniku.

4 eTrust Threat Management: rozsáhlá ochrana pĜed negativními vlivy nejnovČjší technologie Podniky dnes chtČjí využívat výhod internetu a jejich prostĜednictvím rozšiĜovat popĜ. zdokonalovat své možnosti komunikace, aniž by se pĜitom vystavovaly možným útokĤm. Každý den se objevují nové umČle vykonstruované viry, které jsou schopné ochromit obchodní provoz podniku. Neodhalená napadení mohou zniþit datové zdroje, snížit produktivitu a poškodit dobré jméno spoleþnosti, jestliže napĜíklad zároveĖ infikují data obchodních partnerĤ nebo zákazníkĤ. Navzdory vyspČlým obranným technologiím jsou viry a další útoky i nadále velkým problémem. BČhem nČkolika málo vteĜin mĤže být úspČšným kybernetickým útokem zpochybnČna po léta budovaná identita znaþky, prvotĜídní služba zákazníkĤm a vysoká produktivita pracovníkĤ. eTrust Threat Management Ĝešení od spoleþnosti CA proaktivnČ rozeznávají, analyzují, varují a odstraĖují napadení v celém prostĜedí IT – a to efektivním zpĤsobem s pĜíznivými náklady. Protože k úþinné reakci na útok je nezbytné mít o nČm pĜesné znalosti, jsou Ĝešení spoleþnosti CA podporována CA Security Advisory Teamem, celosvČtovou sítí Rapid Response center, v nichž odborníci na bezpeþnost a profesionálové z technické podpory identifikují a izolují nové útoky – nezávisle na tom, kde se na síti objevily. V další etapČ mĤže být další šíĜení utlumeno s pomocí centralizovaného filtrování a implementace smČrnic. ěešení eTrust Threat Management chrání všechny kritické servery a pracovní stanice pĜed rozmanitými nebezpeþími z internetu tak, že závadné obsahy a e-mailové pĜílohy infikované viry jsou odchytávány již pĜi Gateway. Dochází tak k proaktivnímu zamezování porušení síĢových smČrnic. OdstraĖovány jsou koneþnČ i bezpeþnostní nedostatky, a to ještČ pĜed tím než mohou být útoþníky využity – a tak je zajištČn bezporuchový provoz. S eTrust Threat Management Ĝešeními od spoleþnosti CA mĤže podnik sledovat aktivní, upravitelnou strategii k pĜizpĤsobení své bezpeþnostní ochrany na nové situace a souþasnČ snížit náklady na bezpeþnostní management. eTrust Threat Management zahrnuje: x

eTrust™ Antivirus - nabízí výkonnou ochranu proti témČĜ všem formám nákladných virových útokĤ – od perimetrĤ až po PDA.

x

eTrust™ CA-Examine® Auditing - provádí automatické kontroly integrity systému pro z/OS. ěešení navíc poskytuje dĤležité informace pro systémovou bezpeþnost a integritu a pro kontrolní mechanismy, které lze v jiných zdrojích nalézt pouze stČží.

x

eTrust™ EZ Armor™ - obsahuje Personal Firewall, rozsáhlou antivirovou ochranu a ochranu proti škodlivým pĜílohám e-mailĤ a nabízí Vám tak provozuschopné bezpeþnostní Ĝešení proti velkému poþtu hrozeb z internetu. Toto a jiná Ĝešení z nabídky my-eTrust.com zjednodušují komplikovaný úkol chránit Vaši individuální soukromou sféru a zajistit Váš poþítaþ doma nebo na pracovišti proti dnešním nebezpeþím.

x

eTrust PestPatrol Anti-Spyware - rozeznává a odstraĖuje široké spektrum hrozeb nezpĤsobených viry a chrání v soukromí a pĜi práci používané PC pĜed neoprávnČnými pĜístupy, krádežemi informací a redukovaným výkonem systému.


143

x

eTrust™ Secure Content Manager - kombinuje v integrovaném Ĝešení ochranu proti rozmanitým nebezpeþím, jako jsou viry, spamy nebo nepovolené používání internetu zamČstnanci. eTrust Secure Content Manager nabízí obsáhlé a upravitelné Ĝešení pro ochranu obsahu.

x

eTrust™ Vulnerability Manager - umožní Vašemu podniku proaktivnČ a cílenČ odstraĖovat slabiny. Toto obsáhlé Ĝešení managementu slabin Vám poskytuje know-how, metodu a technologii, které potĜebujete k odstraĖování slabin pĜed tím, než jich budou moci využít hackeĜi, þervi a jiné hrozby.

5 eTrust Security Information Management: zdolat pĜíval informací V každém podniku zatím existují þetné bezpeþnostní systémy, které vyhledávají data prostĜednictvím bezpeþných zdrojĤ a vydávají pĜíslušná varovná hlášení. Každý z tČchto systémĤ generuje data rĤzným zpĤsobem a v rĤzných formátech. Rozdíly jsou dále i mezi místy uložení a pĜíjemci, jimž jsou zprávy zasílány. Tento nepĜetržitý tok dat a jevĤ, které jsou rozhodující pro bezpeþnost, z nekompatibilních systémĤ není nakonec možné zvládnout. Útržkovitý základ vede témČĜ nevyhnutelnČ k vícenásobnému zpracování úkolĤ, enormní režii, menší ochranČ a k nedostatku auditových požadavkĤ. S eTrust Security Information Management Ĝešeními od spoleþnosti CA podniky získávají úplnou kontrolu nad jejich bezpeþnostními informacemi a tedy i nad jejich bezpeþnostní infrastrukturou. V pĜípadČ tČchto inovaþních Ĝešen se používají vizualizace a nejmodernČjší forenzní analytické metody k tomu, aby se z nezpracovaných dat týkajících se fyzického a IT prostĜedí získaly solidní podklady pro rozhodnutí. Centrálním Ĝízením mĤže administrátor efektivním zpĤsobem realizovat integraci s jinými Ĝešeními a realizovat automatizaci úkolĤ a zvýšit bezpeþnost. NejdĤležitČjší však je, aby tyto nástroje pomáhaly zabraĖovat jevĤm, které by se mohly negativnČ projevit na prĤbČhu þinnosti, a aby Vám poskytovaly bezpeþnostní názory, které potĜebujete k dodržování smČrnic. eTrust Security Information Management zahrnuje:

144

x

eTrust™ 20/20™ - jedineþné Ĝešení, které data, jež jsou z hlediska bezpeþnosti významná, shromažćuje pĜes fyzické pĜístupy a technické IT pĜístupy ke zdrojĤm z celého podniku, koreluje, analyzuje a znázorĖuje v intuitivním uživatelském prostĜedí.

x

eTrust™ Network Forensics - eviduje nezpracovaná data síĢového provozu a pracuje s nejmodernČjšími forenzními metodami k tomu, aby provČĜilo dopady útokĤ na síĢ, interního zneužití dat a porušení bezpeþnostních nebo personálních smČrnic na Váš majetek.

x

eTrust™ Security Command Center - nabízí kompletní Ĝešení ke kontrole a správČ všech aspektĤ podnikové bezpeþnosti z jedné centrální Ĝídící konzole. Na základČ integrace základních bezpeþnostních a systémových dat, která jsou evidována za pomoci nejrĤznČjších technologií, poskytuje eTrust Security Command Center nástroje a schopnosti k tomu, aby bylo vybudováno nebo zlepšeno Security Operations Center – od identifikace až po odstranČní.


Cisco Network Admission Control Ivo NČmeþek [email protected] Cisco Systems Czech Republic s.r.o. V Celnici 10, 117 21 Praha

1 Proþ Cisco Network Admission Control ? Vysokým rizikem pro síĢ jsou nezabezpeþené stanice. Mohou to být stanice, které nemají aktivovanou a aktualizovanou antivirovou ochranu nebo nemají nainstalovány nezbytné opravy a aktualizace operaþního systému. Network Admission Control (NAC) ovČĜí, zda stanice, které se pĜipojují do sítČ, vyhovují bezpeþnostním pravidlĤm stanoveným ve firmČ. Stanice, které definovaným pravidlĤm vyhovují, mohou dostat neomezený pĜístup do sítČ. PĜístup stanic, které definovaným pravidlĤm nevyhovují, bude omezen síĢovým zaĜízením do té doby, než budou odstranČny nedostatky. Po odstranČní nedostatkĤ získá stanice opČt plný pĜístup do sítČ, viz obrázek 1.

Obr 1: Network Admission Control Network Admission Control pomáhá správcĤm sítČ udržovat stanice v aktualizovaném stavu. V první fázi programu jde zejména o aktualizaci anitivirové ochrany a bezpeþnostních oprav v operaþním systému, v dalších fázích budou možnosti NAC výraznČ širší.


145

2 Co je NAC a jaké jsou jeho souþásti? NAC je technologický program firmy Cisco Systems. Na programu spolupracuje Ĝada partnerských firem, v první fázi zejména dodavatelé antivirové ochrany. V první fázi zahájily spolupráci v programu firmy Cisco Systems, Trend Micro, NAI (McAfee) a Symantec. Podporu programu ohlásily firmy IBM, Microsoft, CA a nČkolik desítek dalších. Program je otevĜený, zapojují se do nČj nepĜetržitČ další firmy. ěešení má nČkolik souþástí: x

Cisco Trust Agent (CTA). Tento software zjišĢujČ informace o koncové stanici a pĜedává je autentizaþnímu serveru.

x

AV klient. Antivirový software pĜedává Cisco Trust Agentu informace o stavu antivirové ochrany. Mezi tyto informace patĜí verze scan engine, verze DAT souboru, aktivace online antivirové ochrany apod.

x

Cisco Security Agent (CSA). CSA chrání koncovou stanici a CTA pĜed napadením a nedovolenou manipulací. PĜedává Trust Agentu rozšíĜené informace o operaþním systému, napĜíklad o instalovaných hotfixech a opravných souborech.

x

PĜístupová síĢová zaĜízení (smČrovaþe, pĜepínaþe, VPN koncentrátory, PIX firewally, bezdrátové AP). Dávají podnČt k vyhodnocení stavu koncové stanice, komunikují s autentizaþním serverem, omezují pĜístup nevyhovujících stanic do sítČ.

x

Autentizaþní server (Cisco Secure ACS verze 3.3). Na tomto serveru definuje správce pravidla pro vyhodnocování stavu koncových stanic.

x

Policy server antivirové ochrany. Server od AV dodavatele vyhodnocující stav antivirové ochrany na stanici a formulující pravidla, kterým musejí vyhovovat stanice z hlediska antivirové ochrany.

x

Server pro správu a monitorování (Cisco Works SIMS pro NAC). Monitoruje souþásti NAC, zaznamenává události a vyhodnocuje je.

Nezbytnými souþástmi NAC jsou CTA, pĜístupové síĢové zaĜízení a autentizaþní server. Ostatní souþásti jsou volitelné.

146


3 Jak funguje Network Admission Control ? Zakladní princip je znázornČn na obrázku 2. Na stanici je nainstalován software Cisco Trust Agent (CTA). PĜi pĜipojování do sítČ naváže hraniþní zaĜízení komuikaci s CTA a vyzve jej k provČĜení stavu stanice. Informace o stavu stanice pĜedá CTA pĜes hraniþní síĢové zaĜízení [1] autentizaþnímu (AAA) serveru [2]. Autentizaþní server provČĜí pĜedané informace. PĜi vyhodnocování se mĤže ACS obrátit na policy servery dodavatelĤ aplikací [2a]. Autentizaþní server informace vyhodnotí [3] a pĜedá pokyn hraniþnímu zaĜízení sítČ [4]. Hraniþní zaĜízení podle pokynĤ autentizaþního serveru povolí, omezí nebo zablokuje pĜístup stanice do firemní sítČ [5]. Obvykle povolí pĜístup do služebního segmentu, odkud je možné zajistit nápravu stavu koncové stanice. Pokyny mĤže pĜedat uživatelĤm pĜes svoje rozhraní CTA [6], pĜípadnČ mĤže být uživatel pĜesmČrován na služební web stránky. Poté, co je stav stanice napraven (napĜíklad se aktualizuje antivirový DAT soubor a aktivuje se online antivirová ochrana), provede CTA nové vyhodnocení stavu stanice a uživatel mĤže získat plný pĜístup do sítČ. Další vyhodnocování se provádí v pravidelných intervalech.

Obr 2: Princip þinnosti NAC


147

4 Jak se dá využít Network Admission Control ? NAC mĤžeme využít v mnoha scénáĜích, napĜíklad: x

Na poboþkách provČĜíme stanice pĜed pĜístupem do centra na hraniþním smČrovaþi, pĜipojujícím poboþku do WAN sítČ.

x

Stanice provČĜíme pĜed pĜístupem do sítČ pĜes VPN.

x

Stanice provČĜíme pĜed pĜístupem do sítČ pĜes telefonní spojení (dial-up).

x

ProvČĜíme stanice pĜed pĜístupem do sítČ pĜes bezdrátový access point.

x

Stanici provČĜíme pĜed pĜístupem do lokální sítČ na LAN pĜepínaþi, ke kterému je stanice pĜipojena.

x

PĜed pĜístupem do Internetu provČĜíme stanice na hraniþním smČrovaþi nebo firewallu.

x

ProvČĜíme stav stanic pĜipojujících se z laboratorních segmentĤ na smČrovaþi, oddČlujícím laboratorní segment od firemní sítČ.

5 Fáze programu Technologie NAC je implementována ve tĜech fázích. PostupnČ se bude rozšiĜovat podpora operaþních systémĤ, aplikací, hraniþních zaĜízení i funkce technologie. Fáze vývoje NAC shrnuje následující tabulka: Fáze 1 (od 7/2004)

Fáze 2 (polovina roku 2005)

Fáze 3

Hraniþní síĢové zaĜízení

SmČrovaþe 83x-72xx

PĜepínaþe Catalyst, koncentrátory VPN3000 (v4.7)

PIX, WLAN AP

Podpora CTA

Windows NT, 2000, XP

Windows 2003, Linux, Solaris

IP telefony, MaC, HPUX, AIX

Integrace aplikací

Antiviry

Další aplikace

Další aplikace

Autentizace

L3 EAP/UDP

L2 EAP/802.1x

HTTP/SSL

ZaĜízení bez CTA

Spoleþné omezení

RĤzná pravidla

Stažení appletu

Vynucení pravidel

L3 ACL

VLAN, PACL

QoS

6 Odkazy [ 1 ] http://www.cisco.com/go/selfdefend [ 2 ] http://www.cisco.com/go/nac

148


ěešení spoleþnosti Crypto AG pro zabezpeþení rádií Dr. Richard Weber and Axel Hosemann, Crypto AG ERICSSON, spol. s r.o. Sokolovská 79 þp. 192, 186 00 Praha 8

1 ProstĜedí uživatele 1.1

Systémový koncept

Následující obrázek vysvČtluje systémové zakotvení ěešení zabezpeþení rádií HC-7665 a HC-2650. Existují tĜi typy zaĜízení, které mají pĜístup k HC-7665/2650: V oblasti „Setup“ (Nastavení) existuje stĜedisko Ĝízení, které pĜenáší šifrovaná data zabezpeþení do SDC (Security Data Carrier – Smarcard, Nosiþ zabezpeþovacích dat – Chytrá karta). SDC mĤže být zapojen do HC7665/2650 k vložení nových dat do databáze zabezpeþení jednotky. Jako budoucí rozšíĜení systému bude zaĜízení zajištČného generování decentralizovaného klíþe užiteþné obzvláštČ v taktickém scénáĜi. Místní ovládaný osobní poþítaþ mĤže být použit pro nastavení s jistými omezeními. Pro místní správu je k disposici server sítČ web v rámci jednotky. PĜístup s pomocí standardního prohlížeþe existuje, jestliže ten server sítČ web byl zmocnČn správcem zabezpeþení. Každá akce na webovém serveru musí pĜinutit uživatele k pĜihlášení v zavedeném MMI (Man Machine Interface, rozhraní þlovČk – stroj). V oblasti „ěízení“ jsou všechna zaĜízení a Ĝídící poþítaþe, které Ĝídí HC-7665/2650. Pro úþely Ĝízení na dálku v nastavení systému je na zadní stranČ zaĜízení konektor nabízející spojení pĜes IEEE 802.3E, RS-232 nebo RS485. Výbava pro Ĝízení na dálku mĤže provozovat to zaĜízení prostĜednictvím jazyka pĜíkazové Ĝádky (command line language). Existuje definovaný soubor povolených pĜíkazĤ vydávaných na dálku v zabezpeþeném prostĜedí. PĜístup vzdáleného Ĝadiþe musí být zmocnČn správcem zabezpeþení. PĜenosný poþítaþ (laptop) mĤže být propojen s konektorem na pĜední stranČ jako lokální dohlížecí prvek. V tomto pĜípadČ je zadní propojení ukonþeno (RS-232 a RS-485). V oblasti „Provoz“ jsou standardní komunikaþní zaĜízení (sluchátko, poþítaþ jako digitální koncové zaĜízení (Data Terminal Equipment, DTE), VF rádiové zaĜízení). HC-7665/2650 budou sluþitelné zpĤsobem, který nevyžaduje modifikace existující výbavy.

Obr 1: PĜehled systému HC-7665 / 2650


149

2 Konfigurace systému 2.1

Zabezpeþení rádia s HC-2650 x

Šifrování hlasu na VKV/UKV/VF.

x

Poloduplex.

x

ÚplnČ sluþitelné s novou architekturou zabezpeþení Crypto.

x

Všechny zabezpeþovací parametry a parametry IT (Information Technology, informatika) mohou být vymČnČny prostĜednictvím zaĜízení SDC.

x

Datová komunikace je možná s interním modemem (STANAG 4285).

x

Mód s analogovým hlasem není v tomto pĜípadČ interoperabilní (=schopný pracovat spoleþnČ) s HC265 (=pĜedchĤdce systému HC-2650; pouze hlas).

x

Pro zákazníky, kteĜí nemají jednotky HC-265 .

Obr 2: Sestava komunikace a správy s HC-2650 Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na vloženém MMI samotné jednotky.

150


2.2

Šifrování rádia HC-2650/HC-265 x

Šifrování hlasu na VKV/UKV/VF.

x

Poloduplex.

x

Veškerá digitální komunikace je založena na algoritmu unikátním pro urþitého zákazníka (HCA-480).

x

Digitální data jsou sluþitelná s novou architekturou zabezpeþení Crypto; pĜídavné parametry HC-265 mohou být Ĝízeny rozšíĜeným MMI.

x

Všechny zabezpeþovací parametry a parametry IT mohou být vymČnČny prostĜednictvím zaĜízení SDC; výjimka – mezi HC-2650 a HC-265 parametry nemohou být vymČnČny!

x

Datová komunikace je možná s interním modulem (STANAG 4285).

x

Mód s analogovým hlasem je interoperabilní s HC-265.

x

Systém by mČl být prodán jen tČm zákazníkĤm, kteĜí již mají jednotky HC-265.

Obr 3: UspoĜádání komunikace a Ĝízení HC-2650 / HC-265 Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na MMI samotné jednotky.


151

2.3

Šifrování dat s HC-7665 x

Šifrování dat na VKV/UKV/VF.

x

Plný duplex.

x

Komunikace založená na algoritmu unikátním pro urþitého zákazníka (HCA-480).

x

Instalace a administrace zabezpeþení je sluþitelná s novou architekturou zabezpeþení Crypto.

x

Soubor komunikaþních klíþĤ (CK) systému HC-7660 je sluþitelný s HC-7665.

x

MMI je zmČnČn pro správu CK systému HC-7665.

x

Všechny zabezpeþovací parametry a parametry IT mohou být vymČnČny s jinými HC-7665 prostĜednictvím zaĜízení SDC.

x

Mohou být þteny pĤvodní chytré karty HC-7660.

x

Na pĤvodní karty zaĜízení HC-7660 lze provádČt záznam.

x

Datová komunikace je možná s vnČjším modemem.

x

Není podporován žádný hlasový mód.

x

ZaĜízení by mČlo být prodáváno jen jako jednokanálová šifrovací jednotka interoperabilní s HC-7660.

x

Náhrada zaĜízení HC-7660 je možná díky možnosti montáže do police.

Obr 4: UspoĜádání komunikace a Ĝízení HC-7665 / HC-7660 Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na MMI samotné jednotky.

152


Outsourcing kontrol a auditĤ fyzické ostrahy a bezpeþnostní studie F.S.C. BEZEýNOSTNÍ PORADENSTVÍ, a. s. Vítkovická 20, 702 00 Ostrava Tel.: 596 617 044-45; Fax.: 596 638 499 E-mail: [email protected]

1 Úvod Bezpeþnostní systém prochází kontinuálním vývojovým procesem, který je dĤsledkem trvalého rozvoje vČdy a techniky, postupĤ a zkušeností. Na základČ tČchto výsledkĤ se v souþasné dobČ prosazuje externí zajištČní bezpeþnosti, tzv. outsourcing. Mezi þinnosti zajišĢované externím zpĤsobem patĜí také: x

kontroly a audity fyzické ostrahy;

x

zpracování bezpeþnostních studií.

Výše citované oblasti, kterým je vČnován tento þlánek, vyžadují vysokou odbornost, odpovČdnost a povČdomí o bezpeþnostním systému jako celku.

2 Outsourcing kontrol a auditĤ fyzické ostrahy Podstatou bezpeþnosti je zajištČní funkþního systému ochrany osob, majetku a informací. Jednou ze souþástí bezpeþnostního systému je þinnost fyzické ostrahy (dále jen „FO“), která dnes nahrazuje vlastní zamČstnance orgánĤ státu a organizací. V dĤsledku absence právních pĜedpisĤ v oblasti FO je nutné nastavit jednoznaþná pravidla mezi pĜíslušnými subjekty prostĜednictvím smlouvy a schválením interních pĜedpisĤ, které efektivnČ upravují její þinnost v pĜíslušné míĜe. Výše citované dokumenty musí být v souladu s platnými právními a interními pĜedpisy a normami. Za úþelem dodržování striktnČ definovaných postupĤ a eliminace rizika selhání lidského faktoru je nezbytné provádČt kontroly FO nejlépe v nepravidelných lhĤtách. Cílem samotných kontrol není nalézat jen nedostatky, ale pĜedevším trvale zvyšovat kvalitu poskytovaných služeb FO.

2.1

Výhody outsourcingu kontrol a auditĤ fyzické ostrahy

Outsourcing kontrol a auditĤ FO má pĜedevším tyto pĜednosti: x

nezávislost na poskytovateli FO;

x

objektivnost (neexistence místních vazeb a ani vazeb na dodavatelích);

x

komplexní pohled na bezpeþnostní systém;

x

úspornost finanþních prostĜedkĤ (nejsou vynaloženy pro platy vlastních zamČstnancĤ);

x

Ĝešení deficitu pracovních pozic, zabývajících se kontrolní þinností;

x

nepravidelnost kontrol;

x

zajišĢování kontrol specialisty vyškolenými v oboru;

x

znalost smČrnic pro výkon FO a smluvních podmínek;

x

prokazatelnost závČrĤ z kontrol zdokumentováním.

Základem pro provedení samotných kontrol a auditĤ je obeznámení auditorĤ s objektem a jeho specifikami, a následné zpracování postupĤ, které jsou závazné pro provádČní periodických i hloubkových kontrol a auditĤ.


153

Dle þasového þlenČní mohou být kontroly a audity jednorázového nebo periodického typu. Kontroly a audity se zpravidla zamČĜují na kvalitu výkonu, plnČní smluvnČ garantovaných podmínek pro zajišĢování FO a definovaných povinností zamČstnancĤ FO. Kontroly a audity FO Ĝeší tuto problematiku komplexnČ, tj. vþetnČ vazeb na technická zabezpeþení a režimovou ochranu. Souþástí prĤbČhu kontroly nebo auditu je posouzení rozsahu a zpĤsobu výkonu FO, aktuálnosti zpracovaných bezpeþnostních dokumentací a dalších podmínek pro její výkon. Výstupem kontroly nebo auditu je nejen pĜehled neshod (nedostatkĤ), ale také nápravná doporuþení pro další práci s dodavatelem. V rámci standardních kontrol a auditĤ se zejména posuzuje: x

pochĤzková þinnost FO;

x

režim vstupu a vjezdu;

x

úroveĖ vystupování zamČstnancĤ FO k návštČvníkĤm objektu;

x

znalost základních povinností;

x

úroveĖ vedení záznamĤ o prĤbČhu služby;

x

stĜídání stanovišĢ a smČn;

x

znalost opatĜení požární ochrany (dále jen „PO“) a bezpeþnosti a ochrany zdraví pĜi práci (dále jen „BOZP“);

x

vybavení zamČstnancĤ FO a stanovišĢ FO;

x

postup pĜi vzniku mimoĜádných událostí a krizových situací.

2.2

Kontroly a audity zajišĢované spoleþností F.S.C. BEZPEýNOSTNÍ PORADENSTVÍ, a. s.

Za úþelem kvalitního provedení kontrolního výkonu je zpracována vlastní metodika, která se neustále aktualizuje a pĜizpĤsobuje novým poznatkĤm a trendĤm. Samotný kontrolní systém se dle metodiky aplikuje individuálnČ a berou se v úvahu veškeré zvláštnosti pĜíslušných subjektĤ. Metodika je souþástí dokumentace managementu jakosti spoleþnosti certifikované dle ýSN EN ISO 9001: 2001. Dle dohody s objednatelem jsou pĜi kontrolní nebo auditní þinnosti FO provádČny penetraþní testy, napĜ. v podobČ: x

neoprávnČného vstupu þi vjezdu;

x

odloženého zavazadla;

x

požadavku na služby, které ostraha nesmí zajišĢovat;

x

vynášení majetku bez povolení;

x

pĜekonání technického zabezpeþení.

Dle požadavkĤ klienta je možné rozsah kontrol nebo auditĤ rozšíĜit na další oblasti, které lze ovČĜit souþasnČ s kontrolou FO, napĜ.:

154

x

funkþnost a rozsah technického zabezpeþení a vedení provozní dokumentace;

x

dodržování zásad PO a BOZP;

x

dodržování ekologických pĜedpisĤ;

x

dodržování režimových opatĜení zamČstnanci objednatele;

x

úroveĖ zpracování bezpeþnostních dokumentací a jejich aktuálnost.


RovnČž je možné využít nČkterý z dalších bezpeþnostních auditĤ, které F.S.C. nabízí: x

audit fyzické bezpeþnosti;

x

audit informaþní bezpeþnosti;

x

audit ochrany osobních údajĤ;

x

audit ochrany utajovaných skuteþností;

x

audit krizového Ĝízení;

x

audit havarijního plánování;

x

audit souþasného stavu ochrany osob, majetku a informací;

x

audit BOZP a PO;

x

audit shody dokumentace objektové bezpeþnosti.

3 Bezpeþnostní studie Podstatou souþasného pohledu na bezpeþnost je integrace dílþích bezpeþnostních opatĜení, a proto je vhodné vzájemnou souþinnost technického zabezpeþení, režimových opatĜení a FO navrhnout již v pĜedprojektové pĜípravČ, a to v bezpeþnostní studii. Dle již platných norem ýSN EN Ĝady 5013 pro poplachové systémy je bezpeþnostní studie (bezpeþnostní posouzení) základním podkladem pro zpracování projektové dokumentace. Výše uvedeného cíle je možné dosáhnout prostĜednictvím nezávislého pĜístupu bez vazby na instalaþní firmy a dodavatele bezpeþnostních technologií. Tento zpĤsob zpracování zaruþuje zavedení funkþního bezpeþnostního systému a pĜedevším úsporu finanþních prostĜedkĤ pĜi jeho realizaci.

3.1

ZpĤsob zpracování bezpeþnostní studie

Nový návrh bezpeþnostních opatĜení není možné provést bez zjištČní stávajícího stavu, provedení analýzy rizik a vzájemných konzultací. Bezpeþnostní studie Ĝeší tuto problematiku v níže uvedených krocích: x

posouzení stávajícího stavu;

x

analýza rizik;

x

návrh technického zabezpeþení;

x

návrh systému režimové ochrany;

x

návrh systému FO;

x

kalkulace nákladĤ na realizaci navrhovaných opatĜení.

Bezpeþnostní studie rovnČž obsahuje množství pĜíloh, napĜ.: x

schémata rozmístČní prvkĤ zabezpeþení;

x

pĜíslušná bodová hodnocení pro stanovení míry rizika;

x

grafy znázorĖující úroveĖ rizika;

x

požadavky na bezpeþnostní technologie.


155

Návrh technického zabezpeþení i dalších bezpeþnostních opatĜení je možné zpracovat ve více variantách, a to vþetnČ kalkulace nákladĤ. Po schválení bezpeþnostní studie je pak možné vybranou variantu rozpracovat dĤkladnČji a použít ji jako zadávací dokumentaci pro výbČr dodavatele technického zabezpeþení. Ve fázi výbČru dodavatele lze tímto zpĤsobem uspoĜit náklady ve zpracování projektové dokumentace technického zabezpeþení, kterou pak zpracuje až vybraný dodavatel realizace technického zabezpeþení pro konkrétní technologii. Tento požadavek vyhovuje i ustanovením zákona þ. 40/2004 Sb., o veĜejných zakázkách, ve znČní pozdČjších pĜedpisĤ, dle kterých nemá zadávací dokumentace obsahovat konkrétní technologie.

Mezi základní výhody zpracování bezpeþnostních studií nezávislou poradenskou firmou patĜí: x

komplexní pohled na bezpeþnostní systém (nejen z pohledu instalaþní firmy);

x

omezení komerþních zájmĤ dodavatelĤ bezpeþnostních technologií;

x

návrh zabezpeþení na základČ analýzy rizik;

x

využití zkušeností z návrhĤ obdobných bezpeþnostních systémĤ;

x

využití specialistĤ pĜíslušných profesí;

x

aplikace aktuálních poznatkĤ o bezpeþnostních technologiích a možnostech jejich integrace.

Další þinnosti navazující na zpracování bezpeþnostních studií

3.2

Zpracovaná bezpeþnostní studie je základním dokumentem pro provedení navazujících þinností, které jsou podstatné pro kvalitní a funkþní zavedení bezpeþnostních opatĜení. V rámci zachování kontinuity návrhu bezpeþnostního systému je vhodné zajistit zpracovatelské úkoly dodavatelským subjektem. Navazující dokumentace: x

zadávací dokumentace pro výbČr dodavatelĤ a projektové dokumentace systémĤ technického zabezpeþení (CCTV, EZS, EPS ...);

x

bezpeþnostní dokumentace (provozní Ĝád bezpeþnostních systémĤ, dokumentace objektové bezpeþnosti apod.).

Navazující þinnosti: x

odborné posouzení nabídek uchazeþĤ zaslaných do soutČže;

x

technický dozor pĜi realizaci zabezpeþení;

x

odborná pĜejímka díla;

x

inspekce technického zabezpeþení v pĜedem stanovených periodách.

4 ZávČr Úþinná ochrana osob, majetku a informací je stále více podporována pĜíslušnými právními pĜedpisy a normami, které je nutné aplikovat vhodným zpĤsobem. Realizace požadavkĤ platných právních pĜedpisĤ a norem vyžaduje seriózní a kvalifikovaný pĜístup výrobcĤ a dodavatelĤ, jenž je nadĜazen vlastním zájmĤm. Dodržet tento požadavek za všech okolností je ve vČtšinČ pĜípadĤ problematický a praktické zkušenosti potvrzují, že zapojení nezávislé firmy do procesu zajištČní vhodných bezpeþnostních opatĜení je pĜínosem. Uvedené poznatky jsou výsledkem více než 7-mi leté zkušenosti specialistĤ F.S.C. z již realizovaných bezpeþnostních kontrol a auditĤ, a zpracovaných bezpeþnostních studií. Za úþelem poskytování kvalitních služeb se klade také dĤraz na kontinuální kvalifikaþní a profesní rĤst zamČstnancĤ spoleþnosti, z nichž je Ĝada soudními znalci, þi uznávanými specialisty v oboru. F.S.C. uplatĖuje prezentované produkty u vČtšiny orgánĤ státu, vþetnČ Ministerstva obrany ýR, a organizací. Na vyžádání je spoleþnost pĜipravena poskytnout pĜehled referencí. Další informace jsou uvedeny na adrese www.fsc-ov.cz a na stánku C2 v pavilonu G2 BrnČnského výstavištČ na veletrhu IDET 2005.

156


Nasazení nástroje pro dohled bezpeþnosti David C. HÁJÍýEK GiTy, a. s., [email protected]

1 Úvod Tento þlánek se zabývá problematikou sledování incidentĤ a jejich zpČtnou prokazatelností v IT prostĜedí. Jako zdroj volí log síĢových zaĜízení. ýlánek je pĜípadovou studií popisující jednu z implementací takového systému. ZároveĖ v þlánku nezapomínáme na další dĤležité souþásti budování komplexního bezpeþnostního systému – zajištČní integrity a þasové autenticity logĤ.

2 Od dat k informacím 2.1

Pozice logu

Analýza logu, která je detekþní souþástí Ĝízení bezpeþnosti, se dá bez nadsázky považovat za neopomenutelnou souþást snažení bezpeþnostních správcĤ. Bez detekce není reakce a pochopitelnČ ani následných preventivních krokĤ. Opomeneme-li speciální pĜípady, kdy provozovateli informaþního systému pĜímo þi nepĜímo vyplývá povinnost auditní þi log soubory zpracovávat a uchovávat (napĜ. zákon þ. 148/1998 Sb.), zpravidla se setkáme se zájmem specialistĤ odpovČdných za bezpeþnost logy pro jejich þinnost využívat. Bohužel ne všude je toto odhodlání dovedeno do zdárného konce a nezĜídka konþí jen zbožným pĜáním. Kupodivu klíþovým okamžikem k eliminaci takové situace je rozhodnutí a odhodlání Ĝešit. Protože potĜeba nevzniká na manažerských pozicích, ale v úrovni „vojákĤ v poli,“ pĜedchází rozhodnutí pĜesvČdþení odpovČdných osob. V závČsu na nČm ovšem nalézáme nutnost alokace potĜebných zdrojĤ. Nutno dodat, že v pĜípadČ, na který se zamČĜíme dosahují investice sedmiciferné þástky. Zopakujme však, že pĜes nesnadnost manipulace s log soubory plynoucí z jejich rĤznorodosti a objemu, kterých dosahují, jde o nepostradatelnou souþást každé organizace, odrážející jejich historii a kulturu. Zatímco jejich využíváním dostává tým odborníkĤ kvalitní a užiteþné informace, jejich ztrátou naopak nejenže ztrácí náskok pĜed útoþníky, jejich zcizením dokonce dává významnou výhodu do jejich rukou. Logy však nemají pouze momentální informaþní hodnotu, ale jsou dĤležité zpČtnČ, pro sledování trendĤ a vývoje situace. Z toho dĤvodu je nezbytné se zamČĜit také na jejich bezpeþnost v kontextu uchovávání, tedy na zajištČní jejich dostupnosti, integrity, dĤvČrnosti a v neposlední ĜadČ nepopiratelnosti autorství jejich vzniku, po urþené þasové období.

2.2

Jak log zpracovat

Ve spoustČ organizací, které využívají log záznamy pro Ĝízení bezpeþnosti je možné se setkat s nástroji rĤzných úrovní a kvalit. Od produktovČ orientovaných programĤ dodávaných výrobcem (Cisco, Symantec, Enterasys, aj.) se pĜes pomocníky z dob poþítaþovČ „dĜevních“ (grep, sed...) dostáváme až k systémĤm, které mají ambice být platformovČ a produktovČ nezávislými a zpracovávat log soubory bez ohledu na výrobce zaĜízení, ze kterých pocházejí. Takové nástroje pochopitelnČ staví na principech normalizace logĤ, což znamená syntaktické a sémantické zvládnutí logĤ všech podporovaných zaĜízení na softwarové úrovni. Jedním z takových je i ISM verze 5.2 (Intellitactics Security Manager, www.intellitactics.com, hodnocení viz Gartner group Magic quadrant), který jsme zvolili pro naši pĜípadovou studii díky jeho vyspČlosti v dobČ realizace projektu. Vzhledem k charakteru log souborĤ nedochází pĜi normalizaci k žádné ztrátČ ani zkreslení informace. Na obrázku þ. 1 je vidČt, jakým jak jsou log data sbírána a zpracována.


157

SbČr dat

Normalizace

Analýza

Prezentace

Datové zdroje

•Syslog •SNMP •SMTP •FTP •SCP •…

Surová data

Parsovaná data

Sumární data

Incidenty

Tok dat Postup prĤzkumu

Obrázek 1: PrĤbČh dat systémem Vyjdeme-li z obrázku þ. 1, surovými daty jsou oznaþovány záznamy v pĤvodní podobČ. Pro pĜehlednost jsou uchovávána pro každé zaĜízení zvlášĢ, a to v adresáĜové struktuĜe /var/nsm/raw/{device}/. Z uvedené struktury je patrné, že v tomto pĜípadČ bylo zvoleno Ĝešení na UNIX/LINUX platformČ (konkrétnČ RHEL 3). Jejich uchování je nezbytné pro následné prokazování, pĜípadnČ pro komunikaci s výrobcem zaĜízení, napĜíklad pĜi Ĝešení reklamací. Na obrázku þ. 2 je systém zálohování zakreslen pouze jako jedna samostatná komponenta. Celý zpĤsob zálohování a následného získávání dat je mnohem komplikovanČjší. Vedle zálohovacího zaĜízení s dostateþnou kapacitou je tĜeba definovat politiku Ĝešící uchovávání dat a logiku, která bude politiku realizovat v praxi. V našem systému jsou na prezentaþních serverech instalováni agenti jejichž þinnost se aktivuje požadavkem uživatele na data stáĜí vČtšího, než ta, která jsou na serveru skuteþnČ pĜítomna. Agent potom z centrálního archivu pĜesune požadovaná data na prezentaþní server a jeho aktivita pokraþuje až po úspČšném ukonþení operace agenta. Pro uchovávání dat bude dĤležitou informací objem dat. LogĤ mohou dennČ v organizaci vzniknout až gigabyty. PĜi archivování surových dat mĤžeme dosáhnout komprese až 1:10. Sumární data (viz obrázek 1) nám zvýší objem na cca 15 % pĤvodní velikosti a budeme-li pĜedpokládat, že pouze 5 % všech dat jsou skuteþnČ incidenty (tedy spolu se sumárními daty ukládány v databázi), dostáváme se ke kompresi 1:5 (v našem pĜípadČ bylo dosaženo skuteþného pomČru 1:6). I tato velikost je však nezanedbatelná. V našem pĜípadČ je zachování pĤvodního záznamu dĤležité rovnČž z dĤvodu zajištČní detekce integrity záznamu a þasové autenticity. Celkové Ĝešení je totiž koncipováno tak, že využívá další z komponent – nezávislou þasovou autoritu. Jak je u GiTy zvykem, pro tyto úþely využívá vlastního robustního Ĝešení – služeb elektronického notáĜe. Výhody tohoto pĜístupu oproti prostého Time Stampingu, pĜípadnČ kolektivního svČdectví bylo již mnohokráte vysvČtleno (dokonce i v rámci této konference – viz [1]). Nezávislá þasová autorita oznaþí záznam informací o dobČ jejich vzniku (resp. o dobČ, v jejímž okamžiku již jistČ existovala). ýasová autentizace mĤže probíhat v zásadČ dvČma základními zpĤsoby:

158

1.

centrálnČ – na serveru, který shromažćuje data – pro skupinu záznamĤ rĤzných zaĜízení dohromady, a to v þasových intervalech,

2.

individuálnČ – data z každého zaĜízení, jehož log je využíván, projdou samostatnČ, v pravidelných intervalech komponentou þasového serveru.


Centrální oznaþování logu neklade tak vysoké nároky na jednotlivá síĢová zaĜízení, která mají log posílat, ani na úpravu jejich software. Realizace centrálního þasového razítkování je zjednodušeno navíc vlastnostmi nástroje ISM. Podklady pro þasové razítko je možné vzít z adresáĜe /var/nsm/summary/, pĜípadnČ z /var/nsm/parsed/{date}/. Druhý ze jmenovaných adresáĜĤ obsahuje soubory s log záznamy rozdČlenými dle pravidel normalizátorĤ a informacemi pĜiĜazenými jednotlivým promČnným. První ze jmenovaných adresáĜĤ v sobČ skrývá sumární informace. Varianta druhá, pĜestože první je šetrnČjší k výkonu a kapacitám serveru provádČjícímu sbČr dat, dovoluje zajistit dĤvČryhodnost (resp. nepopiratelnost pĤvodu). DĤvČryhodnost (a potažmo integrita) je garantována tím, že nČkterá ze zaĜízení vlastní dvojici podpisových klíþĤ a certifikát. Komplikací mĤže být nesnadnost implementace, velký objem dat a fakt, že logika a architektura nČkterých zaĜízení takový zásah neumožĖuje. Realizátor se navíc musí zabývat otázkou, která ze zaĜízení je skuteþnČ smysluplné takto vybavit. Vzhledem k našim potĜebám jsme zvolili centrální þasové razítkování. Celkové schéma je potom znázornČno na obrázku þ. 2. Jak je z nČj patrné, je zajištČna þasová autenticita. V nČkterých pĜípadech dĤvČrnost a dĤvČryhodnost a tím pádem integrita, aþkoliv to z obrázku nevyplývá.

Obrázek 2: Topologie systému (varianta 1) Systém v takovéto konfiguraci bohužel nedokáže zajistit ani dĤvČrnost veškeré komunikace, protože nČkterá zaĜízení tuto možnost nenabízejí. V pĜípadČ dĤvČryhodnosti je situace podobná. Bohužel není možné se obecnČ vyhnout ani pĜípadĤm, kdy útoþník pĜedstírá IP adresu nČkterého ze zaĜízení a posílá mystifikující informace. Výše uvedené pĜekážky mĤže odbourat realizace systému ve variantČ 2 þasového razítkování. Problém rovnČž bude tvoĜit možnost škodlivé aktivity administrátora. Ta je však Ĝešitelná vhodnou distribucí pĜístupových zpráv a rozesláním informace o vybraných operacích (pĜihlášení s úþtem administrátora, vytvoĜení uživatele, zmČna pĜístupových práv k urþitým souborĤm a pod.) na více jiných zaĜízení v síti schopných tuto zprávu pĜijmout. Po propojení systému s nČkterým z nástrojĤ Ĝady „Vulnerability Scanners“ (napĜíklad NESSUS), kterým se však v tomto þlánku nebudeme zabývat, nám zbývá už jen utkat se s otázkou, jak log správnČ interpretovat a prezentovat.


159

2.3

Jak log interpretovat a prezentovat

Tato kapitola bude velmi struþná. Jejím obsahem jsou dvČ dĤležitá schémata. Prvním z nich je korelaþní model nástroje ISM (obrázek þ. 3)

Security Data

Available

Knowledge Bases

IntelliTaxonomy

MultiDimensional

Feature

Alert Managemen

Correlation

Feature Map

Alert

Algorithms

Institutional Knowledge Tax. Mapping

Creation DOS

recon

compromise

misuse

exploit

insecure

auth

anomaly

error

virus

Traffic Flow Aggregated

RDBMS

(Summary Store)

Auto Assessment

Window

Compressed

(Parsed Store)

Tab Delimited

Incident Response …

Correlation^2 Normalized

Assurance Views

…

Bitstream

Compressed

(Raw Store)

Bitstream …

Acquisition

Obrázek 3: Korelaþní model nástroje ISM Je na nČm uveden zpĤsob, jakým jsou data z logu pĜemČĖovány v informace. Po jeho pochopení a akceptaci má þtenáĜ pĜehled o tom, které informace mĤže od popisovaného prostĜedí oþekávat, a které naopak systém poskytnout neumí. Druhým je prĤmČrný þas a postup aktivit od vzniku a následné detekce útoku, až po jeho klasifikaci a, pochopitelnČ, zabránČní dalším škodám.

160


Obrázek 4: TCT - Time Critical Targeting (pĜevzato z mateirálĤ spoleþnosti Intellitactics) Obrázek þ. 4 je, pĜiznejme si optimistickým, odhadem efektivity práce bezpeþnostního týmu a dob odezvy (pochopitelnČ pĜi použití kombinace vhodných nástrojĤ). PomĤže þtenáĜi posoudit efektivitu investic vynaložených na vybudování bezpeþnostního dohledového prostĜedí.

3 ZávČr ZávČrem lze Ĝíci snad jen tolik, že vše skuteþnČ souvisí se vším. Neberme to však jako konstatování nihilistické – naopak. Díky architektuĜe, kterou jsme bČhem projektu vybudovali, má zákazník nyní jen malý a finanþnČ velice zajímavý krĤþek k realizaci PKI (digitální podepisování a šifrování s využitím veĜejného klíþe). Nezbývá než zopakovat, že bezpeþnost je skuteþnČ nikdy nekonþícím procesem. ObzvlášĢ jde-li o vaše data.

[1]

David C. HÁJÍýEK: Electronic notary services, Security and Protection of Information 2003, Technical Report, Military Academy in Brno, April 2003, Czech Republic, ISBN: 80-85960-50-8, page 55 - 59


161

162


Šifrovací brány arbitrem bezpeþné výmČny dat

ICZ a.s., divize informaþní bezpeþnosti [email protected]

Princip budování zabezpeþeného kanálu, jež tvoĜí základ komunikaþní bezpeþnosti, je dnes bČžnČ používanou technologií. Pro zajištČní datového spoje pomocí mechanismĤ kryptografie existuje velké množství specializovaných HW zaĜízení a programových nástrojĤ. Veškerá tato Ĝešení jsou však tČsnČ svázána s použitou komunikaþní cestou. Šifrovací brána je oproti bČžným komunikaþním šifrátorĤm aktivním zaĜízením v informaþním systému. Je to prvek, jehož prostĜednictvím lze realizovat procedury pro uvolnČní a pĜedání informací mimo hranice systému a naopak i procedury pro pĜíjem a verifikaci informací do systému vstupujících z vnČjšího prostĜedí. Základním principem zaĜízení je aplikaþní šifrování pĜenášených dat, které je na jedné stranČ doplnČno o funkce pro import a export dat z konkrétních aplikací v informaþním systému. Na druhé stranČ zaĜízení jsou však data exportována a importována ve formátu šifrovaných souborĤ, které mohou být automatizovanČ þi manuálnČ pĜedávány do dalších nezávislých systémĤ napĜíklad prostĜednictvím datového média. PĜi vhodné implementaci tak získáme prostĜedek, který umožní pĜedávání dat ve tvaru obecných datových souborĤ mezi navzájem oddČlenými systémy a zároveĖ poskytující mechanismy zajištČní integrity a utajení dat spoleþnČ s jejich automatickým vstupem do aplikaþních modulĤ uvnitĜ IS.

1 Aplikaþní potĜeby Použití šifrovacích bran má význam pĜedevším v oblasti pĜedávání utajovaných informací mezi nezávislými systémy, které jsou vzájemnČ propojeny prostĜednictvím nezabezpeþené komunikaþní linky. Šifrovací brána slouží v takovém pĜípadČ jednak jako nástroj pro uplatnČní požadavkĤ integrity a utajení pĜenášených dat, ale hlavním pĜínosem Ĝešení je však možnost implementace dalších funkcí, potĜebných pro vyĜešení problematiky bezpeþné implementace procedur na uvolĖování a pĜíjem informací z prostĜedí mimo hranice vlastního informaþního systému. Z uvedených skuteþností tedy vyplývá, že šifrovací brána není urþena jako náhrada komunikaþního šifrátoru, který zpravidla propojuje rĤzné þásti jednoho informaþního systému. Brána bude vždy pracovat ve funkci ochranného hraniþního prvku mezi rĤznými informaþními systémy.

2 Možnosti využití Pro využití šifrovacích bran existují dvČ základní možnosti jejich nasazení: x

První možností využití je zajištČní bezpeþné výmČny utajovaných (citlivých) dat mezi rĤznými systémy za souþasného požadavku realizace pĜenosu prostĜednictvím nezabezpeþeného spoje.

x

Druhou možností je nasazení brány za úþelem bezpeþné realizace procedur uvolĖování neutajovaných dat ze systému zpracovávajícího utajované skuteþnosti do neutajovaného prostĜedí.


163

3 Návrh architektury Crypto Gateway

Transmit module

External environment

Encrypt

Encryption and verification module

Verification

Transmit Path

Encryption Device

Export module Procedural block

Communication block

Application server Database

Signalization and quarantine module

Logs

Splitting device

Receive module

Receive Path

Verification

Decrypt

System management server

Decryption and verification module

Procedural block

Communication block

Import module

Šifrovací brána musí být aktivním zaĜízením v informaþním systému, které je vybudováno na dĤvČryhodné výpoþetní základnČ a pro svou práci využívá dĤvČryhodný (nejlépe certifikovaný) kryptografický prostĜedek. VnitĜní architektura zaĜízení musí umožĖovat pĜenos informací obČma smČry a zajistit, že se tyto smČry nemohou vzájemnČ ovlivĖovat. Základní rozdČlení vnitĜní architektury je proto na pĜijímací a odesílací cestu.

3.1

PĜijímací cesta

PĜijímací cesta zajišĢuje vstup informací z vnČjšího prostĜedí do interních aplikací. Na tento vstup jsou kladeny podmínky pĜedevším pro zajištČní integrity vstupních dat. PĜijímací cesta je rozdČlena do tĜí samostatných modulĤ, které spolu vzájemnČ komunikují metodou pĜedávání dat na lokálním souborovém systému. PĜijímací cesta ve zkratce plní následující funkce: 1.

Bezpeþný vstup dat.

2.

Dešifrování a verifikace integrity pĜijatých dat.

3.

Procedurální testy datové integrity.

4.

Import dat do vnitĜních aplikací.

Vlastní vstup dat do šifrovací brány je realizován „pĜijímacím modulem“. Tento modul aktivním zpĤsobem naþítá data dovnitĜ šifrovací brány napĜíklad z externího datového média nebo jiného oddČlovacího zaĜízení. Data nelze aktivnČ vkládat z vnČjšího prostĜedí dovnitĜ šifrovací brány, ale vstup musí být vždy Ĝízen pĜijímacím modulem. Architektura pĜijímacího modulu je navržena tak, aby vlastní realizace vstupu nemohla ohrozit funkcionalitu dalších þástí zaĜízení. PĜijatá data jsou pĜedána „Dešifrovacímu a verifikaþnímu modulu“. Tento modul má za úkol zajistit, že pĜijatá data budou správnČ dešifrována a garantovat, že byla odeslána autorizovaným odesílatelem a nebyla v prĤbČhu pĜenosu modifikována. Tyto úlohy jsou realizovány pomocí standardních kryptografických mechanismĤ a veškeré pĜípadné chyby mají za následek pĜedání pĜijatých dat signalizaþnímu a karanténnímu modulu. SprávnČ dešifrovaná a zkontrolovaná data jsou pĜedána importnímu modulu. Tento modul je prakticky závislý na konkrétní implementaci zaĜízení. Modul se skládá z procedurálního a komunikaþního bloku, které od sebe oddČlují þásti, jež jsou zodpovČdné za vlastní import dat do konkrétní aplikace a za realizaci procedur zajišĢující aplikaþní integritu pĜijatých dat. V praktické realizaci bude komunikaþní blok vkládat pĜedpĜipravená data pomocí napĜ. ODBC rozhraní do databáze nČkterého aplikaþního serveru v IS. Procedurální blok naproti tomu bude kontrolovat formát pĜijatých dat, rozsah hodnot a provádČt další funkce jako napĜíklad antivirovou kontrolu. Veškeré nestandardní stavy a chyby dat zjištČné pĜi kontrolách zpĤsobí pĜedání dat signalizaþnímu modulu. 164


3.2

Odesílací cesta

Realizace odesílací cesty musí zajistit, že nedojde k nežádoucímu pĜenosu informací z vnitĜku systému mimo jeho hranice. Tento požadavek je zajištČn tak, že vlastní implementace poskytuje vysokou míru záruk toho, že veškerá data, která opouští odesílací cestu jsou adekvátním zpĤsobem zašifrována. To v prostĜedí certifikovaných systémĤ znamená, že na výstupu odesílací cesty jsou pouze informace zašifrované certifikovaným kryptografickým prostĜedkem a tedy se nachází ve tvaru neutajovaných dat. V takovém pĜípadČ zĤstává rizikem implementace pouze možnost porušení pravidla need-to-know, protože dešifrovací klíþe se nachází jen v cílovém systému, který musí být rovnČž certifikován na zpracování informací stupnČ utajení, který je do tohoto systému prostĜednictvím šifrovací brány zasílán. Odesílací cesta ve zkratce plní následující funkce: 1.

Export dat z aplikací.

2.

Procedurální testy datové integrity.

3.

Šifrování a podpis odesílaných dat.

4.

Bezpeþný výstup dat.

Vstup dat do odesílací cesty zajišĢuje „exportní modul“. Tento modul je tČsnČ svázán s konkrétní implementací obdobnČ jako modul importní. Modul se opČt skládá z procedurálního a komunikaþního bloku. Komunikaþní blok exportního modulu je obdobný stejnému bloku v modulu importním. Hlavní úlohou exportního modulu je zajistit, že pĜijatá data jsou získávána ze správného zdroje a nejsou výsledkem nČjakého nežádoucího datového toku (napĜ. z dĤvodu zavirování sítČ). Procedurální blok exportního modulu je nejkritiþtČjší þástí celé šifrovací brány. ZpĤsob realizace tohoto bloku má zásadní vliv na záruky, že se mimo hranice IS dostanou pouze požadovaná data. Modul je zodpovČdný za verifikaci aplikaþní konzistence odesílaných dat. Návrh musí zajistit, že tyto testy jsou provádČny s dostateþnou mírou záruk spolehlivosti. V pĜípadČ výskytu chyb pĜi provádČných testech jsou pĜenášená data pĜedána signalizaþnímu modulu. Šifrovací a verifikaþní modul má za úkol odesílaná data pĜevést do tvaru vhodného pro transport. Prakticky to znamená, že jsou datové soubory pĜevedeny do tvaru archivu, který je zašifrován a podepsán. K archivu pak mĤže být pĜi použití PKI pĜipojeno napĜ. CRL, þi jiná data potĜebná pro realizaci kryptografických operací na pĜijímací stranČ. Po pĜevedení dat do transportního tvaru provede modul jejich následnou verifikaci, která musí zajistit, že data jsou opravdu správnČ zašifrována a podepsána. NáslednČ jsou data v transportním tvaru pĜedána odesílacímu modulu, jehož úkolem je zajistit bezpeþný výstup dat ze zaĜízení šifrovací brány. Aktivita na výstupu musí být vyvolána pouze na stranČ šifrovací brány. Praktickou realizací je ukládání výstupních dat na externí datové médium, þi jejich automatizované pĜedávání na bezpeþné oddČlovací zaĜízení.

4 VnitĜní dohled Šifrovací brána je kritickým prvkem systému, protože má k dispozici mechanismy pro realizaci pĜenosĤ dat mimo hranice systému. Dalším kritickým faktorem je skuteþnost, že realizuje funkce, jejichž výsledek rozhoduje o tom, jaká data lze ze systému uvolnit a naopak zda data, která do systému vstupují nemohou systému provoznČ uškodit. Z tČchto dĤvodĤ je nutnou podmínkou bezpeþného provozu implementace mechanismu dohledu v reálném þase. Tento dohled musí zajistit neprodlené odesílání auditních dat mimo vlastní zaĜízení, aby v pĜípadČ útoku nemohlo dojít k jejich zniþení. Tuto funkcionalitu v pĜípadČ šifrovací brány zajišĢuje „karanténní a signalizaþní modul“, který je navázán na systém centrálního dohledu IS. Modul pĜi bČžném provozu prĤbČžnČ odesílá logové informace na systém centrálního dohledu. V pĜípadČ výskytu chyby v prĤbČhu testĤ ostatních modulĤ zajišĢuje informování dohledu a úschovu dat, která chybu zpĤsobila pro pozdČjší vyhodnocení. V pĜípadČ výskytu kritické situace je modul zodpovČdný za odeslání alertu a vypnutí zaĜízení.


165

166


SSL VPN VUMS DataCom RozšíĜená 15, Praha 8, 182 00, tel.:+420-284688680, mail: [email protected]

1 Úvod PĜístup k informacím 24x7 je dnes samozĜejmým požadavkem.Cesta k jeho zajištČní však pĜináší Ĝadu otázek a komplikací. Ideální Ĝešení by mČlo vypadat následovnČ, viz obrázek 1.

Obrázek 1. Požadavky na pĜístup k informacím Každý uživatel by mČl mít pĜístup k libovolné aplikaci a to kdykoliv, odkudkoliv a z libovolného zaĜízení. To vše bezpeþnČ, jednoduše a s maximálním využitím všeho co je k dispozici. Není problém zajistit pĜístup pro omezenou skupinu uživatelĤ s firemním notebookem a VPN klientem. RovnČž lze zajistit univerzální pĜístup za cenu implementace portálu a vývoje webových aplikací. Taková Ĝešení však splní vždy jen þást výše uvedených kriterií a to z dĤvodu omezení stávajících technologií.

2 SSL VPN V souþasné dobČ se stále více prosazuje technologie SSL VPN, která dokáže splnit všechny výše uvedené požadavky. Protokol Secure Socket Layer byl vyvinut spoleþností Netscape. Jeho základními úkoly jsou zabezpeþení dat šifrováním a ovČĜení totožnosti uživatele. Dnes je SSL respektive HTTPS souþástí prakticky všech webových prohlížeþĤ. Proto se þasto mluví o SSL VPN jako „client-less“ technologii, jinými slovy klienta VPN zastoupí webový prohlížeþ. SSL se nijak zásadnČ neliší od technologie IPSec, používá prakticky stejné algoritmy pro šifrování i obdobné mechanismy pro ovČĜování uživatele. SSL je však protokol vložený mezi TCP/IP a aplikaþní vrstvou, viz obrázek 2. Z toho vyplývá nČkolik vČcí. V prvé ĜadČ jednoduchost a univerzálnost používání. Odpadají problémy napĜíklad s pĜekladem adres (NAT). Na druhé stranČ, díky tomu, že má k aplikacím „blíže“, dokáže nabídnout mnohem vČtší granularitu z hlediska definování bezpeþnostních pravidel pĜístupu. Mimo jiné lze pĜesnČ definovat URL pro webový pĜístup.


167

Obrázek 2. IPSec a SSL z pohledu modelĤ OSI a TCP/IP Velice þasto se SSL VPN srovnává s technologií IPSec. Jedná se o jeho náhradu? Ano, ale ne ve všech pĜípadech. Jako pomĤcku pro výbČr vhodné technologie lze použít následující tabulku, viz tabulka 1.

Typ aplikace

Typ zaĜízení

Vzdálená síĢ

Typ spojení

Typ VPN

Poboþky

Firemní

Ve správČ, dĤvČryhodná

Permanentní

IPSec

Mobilní zamČstnanci

Firemní i cizí

Cizí, nedĤvČryhodná

Mobilní

SSL VPN

PartneĜi a zamČstnanci, extranet

Cizí

Cizí, nedĤvČryhodná

Mobilní

SSL VPN

Tabulka 1. Volba SSL VPN a IPSec Pokud se jedná o permanentní spojení mezi centrálou a poboþkou, bezpochyby je správnou volbou IPSec. V pĜípadČ, že se jedná o pĜístup mobilních uživatelĤ nebo uživatelĤ, které nemáme pĜímo pod kontrolou (dodavatelé, odbČratelé atd.), tady nabízí SSL VPN Ĝadu výhod. Toto srovnání je však nedostateþné. SSL VPN pĜináší Ĝešení nejen vzdáleného pĜístupu, ale i extranetu. Odpadá nutnost vytvoĜení DMZ, vývoje webového rozhraní pro aplikace, implementace portálu apod.

2.1 Výhody SSL VPN Podívejme se na jednotlivé body v obrázku 1. Co si pod nimi lze pĜedstavit a do jaké míry se jedná o realitu? 2.1.1

Libovolný uživatel

IPSec VPN vyžaduje instalaci klienta. To není problém u vlastních zamČstnancĤ. Dohodnout se však na instalaci nČjakého software na cizí zaĜízení (dodavatele, odbČratele atd.) je v mnoha pĜípadech neĜešitelné. I v pĜípadČ, že partner takový požadavek akceptuje, zprovoznit dva IPSec VPN klienty na jednom PC je v naprosté vČtšinČ pĜípadĤ témČĜ nemožné. 2.1.2

Libovolné místo

Uživatel mĤže pĜistupovat k informacím pomocí SSL VPN kdekoliv se dokáže pĜipojit k internetu – wireless hot-spot, internetová kavárna. PĜístup je pomocí HTTPS na portu 443, který není prakticky nikde blokován. Jak jsme zmiĖovali dĜíve, HTTPS rovnČž nemá problém s pĜekladem adres.

168


2.1.3

Libovolné zaĜízení

SSL je podporován všemi webovými prohlížeþi. Výhod SSL VPN mĤže využívat libovolné zaĜízení s browserem ( PC, notebook, PDA, mobilní telefon atd.). Druhým aspektem pak je i vlastnictví zaĜízení, viz bod 1. 2.1.4

Libovolná aplikace

Zde je mezi technologií IPSec a SSL VPN nejvČtší rozdíl. IPSec zpĜístupĖuje síĢ, z pohledu aplikací je prakticky transparentní. SSL VPN funguje jako aplikaþní brána. Uživatel naváže spojení pomocí prohlížeþe s SSL VPN bránou. Ta ukonþuje HTTPS a smČrem do vnitĜní sítČ komunikuje daným aplikaþní protokolem. Musí tudíž rozumČt podporovaným aplikacím. To není problém pro webové aplikace, lepší Ĝešení pak podporují sdílení souborĤ eventuálnČ nČkteré další. V principu však není možné vytvoĜit aplikaþní bránu pro veškeré existující aplikace. StejnČ tak ne každá aplikace mĤže mít webové rozhraní. Využívá se jednoduchý nápad. Klienti vČtšiny aplikací (SAP, CITRIX, PC Anywhere atd.) komunikují pĜes konkrétní TCP nebo UDP porty. Staþí tedy odchytit na vzdáleném zaĜízení komunikaci na tČchto portech, zabalit ji do HTTPS a na druhé stranČ ji pak transparentnČ rozbalit, viz obrázek 3. To už však prohlížeþ nedokáže. Na vzdáleném zaĜízení tedy musí bČžet „klient“, který daný provoz bude odchytávat. Padá tedy pojetí „bez klienta“? Ano, ale ne docela. Díky tomu, že se jedná v podstatČ o lokální pĜesmČrování a používá se JAVA nebo ActiveX plug-in o velikosti v Ĝádu stovek KB, lze ho dynamicky nahrát pĜi navazování spojení a po ukonþení jej stejným zpĤsobem odstranit. RovnČž je možné pĜesmČrovat i veškerou síĢovou komunikaci na tĜetí vrstvČ a získat úroveĖ pĜístupu jako u IPSec. Tímto zpĤsobem lze zajistit podporu opravdu libovolné aplikace.

Obrázek 3. Podpora klient-server aplikací Pro úplnost je vhodné poznamenat, že v tomto bodČ jsou i nejvČtší rozdíly mezi jednotlivými výrobci. U mnohých je podpora aplikací omezena napĜíklad pouze na TCP aplikace apod. 2.1.5

Bezpeþnost

Z hlediska zabezpeþení pĜenosu je SSL VPN velmi obdobné jako IPSec, stejné šifrování atd. Z hlediska granularity pĜístupu je zde naprosto zásadní rozdíl. IPSec pĜedstavuje L3 pĜístup. U SSL VPN lze definovat velice detailnČ, kdo a kam mĤže a to dynamicky, pro každé jednotlivé spojení. Typické ovČĜení a pĜidČlení role uživateli pak probíhá v následujících krocích. JeštČ pĜed samotným pĜihlášením je provČĜeno zda uživatel disponuje digitálním certifikátem, z jakého zaĜízení pĜistupuje (cizí, vlastní), v jakém stavu je dané PC, zda má aktuální antivir, nahrané bezpeþnostní záplaty atd. Na základČ toho lze i odmítnout ovČĜení uživatele, tj. uživatel nedostane možnost se pĜihlásit, nebo bude požadován konkrétní zpĤsob ovČĜení, tĜeba pomocí tokenu. Pak je uživateli pĜidČlena role platná pouze pro toto konkrétní spojení. Role zahrnuje detailní pĜístupová práva. V pĜíštím spojení se mohou zmČnit, tĜeba na základČ Security and Protection of Information 2005

169

toho, že uživatel neprovedl update antiviru. DĤležitá je i fáze odhlášení. Na vzdáleném PC zĤstává vždy Ĝada doþasných souborĤ. Ty je potĜeba odstranit. To vše je možné s využitím možností ActiveX nebo JAVA (obdobnČ fungují napĜíklad Windows update). Tyto možnosti jsou úzce integrovány do SSL VPN brány. Jako další krok v oblasti bezpeþnosti je dnes integrace na úrovni API s výrobci personálních firewallĤ (Sygate, TrendMicro atd.). Samostatnou kapitolu tvoĜí i úroveĖ bezpeþnosti samotného produktu – ICSA a EAL certifikace, provedení v souladu s FIPS standardy atd. 2.1.6

Jednoduchost

Zde je mínČna pĜedevším jednoduchost z pohledu uživatele. Ten nemusí nic instalovat nebo konfigurovat. Používá prostĜedí, které je pro nČj známé – prohlížeþ eventuálnČ nativního klienta dané aplikace. Z pohledu správce se vše nastavuje centrálnČ na úrovni SSL VPN brány. Zde má správce Ĝadu nástrojĤ na definování pravidel a pĜidČlování rolí. SamozĜejmostí je možnost definovat rĤzné úrovnČ pĜístupu pro správce, možnost logování veškerých událostí a nezávislého auditu.Samostatnou kapitolu tvoĜí i jednoduchost zpĜístupnČní vnitĜních aplikací.Odpadá nutnost pĜizpĤsobení aplikací pro web, vytváĜení DMZ, replikace serverĤ do DMZ, jejich patch management atd. Na minimum se redukuje i potĜeba technického supportu. 2.1.7

Snadná integrace

ěada firem má ve své síti implementováno AAA Ĝešení, adresáĜové služby atd. Bylo by nesmyslné Ĝešit totéž znovu pro SSL VPN. Nutností je jednoduché navázání na to, co je k dispozici – LDAP, RADIUS, NIS, RSA atd. 2.1.8

Vysoká dostupnost

Jedno zaĜízení pĜedstavuje single point of failure, kritické místo. Pro Ĝešení, které má fungovat 24x7 je nutná podpora vysoké dostupnosti. Jinými slovy zaĜízení musí být schopno pracovat v clusteru, v ideálním pĜípadČ i v geografickém clusteru. To znamená, že jednotlivá zaĜízení mohou být umístČna v rĤzných lokalitách. Výpadek celé jednoho zaĜízení nebo i celé lokality pak neznamená výpadek služby.

3 ZávČr SSL VPN dokáže vyĜešit prakticky veškeré požadavky na bezpeþný pĜístup. Jde o ideální Ĝešení pro mobilní uživatele, aĢ už vlastní nebo cizí. PĜináší i zvýšenou bezpeþnost. Mezi výrobci jsou však výrazné rozdíly a je nutné si dĤkladnČ ovČĜit, nejlépe podle pĜedchozích bodĤ, co je skuteþnČ podporováno. Další informace k této problematice lze najít na http://www.juniper.net/products/ssl/.

170


Kompletní Ĝízení rizik Využívání Ĝízení zranitelnosti a hrozeb

Vladimír Brož [email protected] McAfee, Inc. www.mcafee.com

1 Shrnutí Níže poskytujeme celkový pĜehled vývoje bezpeþnostních hrozeb pro firmy. Zkoumáme, jakým zpĤsobem rĤzné organizace reagují na novou povahu tČchto hrozeb z hlediska strategie, integrace a proaktivního chování. Požadavky na bezpeþnost, které vyplynuly z tohoto strategického pĜístupu, upozorĖují stále více vedoucí pracovníky na nutnost revidovat zpĤsob, jakým pĜidČlují bezpeþnostní zdroje na ochranu kriticky dĤležitých informací.

2 Úvod Jak bylo zjištČno ve výzkumu provedeném spoleþností Q&A Research okolo 75% ze 300 dotazovaných IT manažerĤ vČĜí, že jsou jejich poþítaþové sítČ zabezpeþeny lépe než pĜed rokem. PĜesto 81% z tČchto respondentĤ zastupujících spoleþnosti s roþními pĜíjmy pĜesahujícími 30 milionĤ dolarĤ potvrdilo nárĤst poþtu útokĤ. Okolo 20% respondentĤ prohlásilo, že se do poþítaþové sítČ jejich spoleþností dokázali dostat hackeĜi. Statistiky ukazují známou story. Zlí lidé se snaží proniknout do poþítaþĤ velkých i malých spoleþností a poškodit je. DobĜí lidé pokraþují v neúnavné práci - pĜedvídají a reagují na hrozby tak, jak se postupnČ objevují. S tím, jak se blížíme polovinČ desetiletí, dochází ke konvergenci urþitých trendĤ. ZásadnČ se mČní povaha hrozeb, kterým organizace þelí. Stále více vedoucích pracovníkĤ je nuceno mČnit zpĤsob, jakým vybírají bezpeþnostní Ĝešení pro správu a omezování rizik asociovanými s tČmito hrozbami.

3 MČnící se povaha bezpeþnostních hrozeb StejnČ jako vše v digitálním svČtČ i úþinnost, sofistikovanost a efektivita škodlivých programových kódĤ roste geometrickou Ĝadou. Firemní sítČ musí být schopné reagovat nejen na stále vČtší poþet útokĤ, ale také na zvyšující se pestrost hrozeb, které se pĜetváĜejí. VytváĜejí hybridní kmeny virĤ, þervĤ, phishing emaily, nebo jiné škodlivé projevy hackerské aktivity. Moderní viry mohou sloužit jako základna pro spuštČní þervĤ, þervy mohou shromažćovat informace pro podvodné phishing emaily. Je stále obtížnČjší udržovat jasné a þisté kategorie pro zaĜazení jednotlivých typĤ hrozeb. Veškeré hrozby se rovnČž stávají po technické stránce inteligentnČjší a nezávislejší. Škodlivé aktivity se zautomatizovaly do té míry, že jediný hacker mĤže mít mnohonásobnČ vČtší vliv než pĜed pouhým rokem a pĤl. (Tento vliv je dále umocnČn vzrĤstající závislostí firem na síĢových procesech uvnitĜ organizací a mezi organizacemi a zákazníky.) A v neposlední ĜadČ se komunita hackerĤ rozrostla (nebo možná dospČla) mimo pĤvodní generaci hackerĤ, jejichž zájem spoþíval pouze v narušení funkce nČjaké organizace, aby se tím mohli chlubit nebo prokázat svou programátorskou dovednost. Nejrychleji rostoucí segment hackerské komunity je pohánČn zištnými motivy. HackeĜi své schopnosti využívají pro aktivity, jejichž úspČch se mČĜí ztrátami jejich obČtí. Dá se to považovat za profesní kriminalizaci jednotlivých segmentĤ hackerské komunity. Výsledkem tČchto trendĤ je, že stále vČtší procento hrozeb, kterým jsou organizace vystaveny, je realizováno cílenČjším a strategiþtČjším zpĤsobem.


171

4 Zvyšující se potĜeba nového typu reakce V posledních mČsících se hodnČ mluvilo a psalo o potĜebČ vyvinout pĜístup k zabezpeþení na bázi Protection-inDepth™. Avšak ménČ bylo uþinČno pro skuteþnou implementaci integrované a proaktivní strategie firemní bezpeþnosti. Podle nedávného prĤzkumu Harris Interactive mezi spoleþnostmi ze seznamu FORTUNE 1000 existuje stále velká mezera mezi tím, co firmy Ĝíkají, že dČlají, a skuteþnČ pĜijatými opatĜeními pro snížení rizika. VČtšina z dotazovaných vrcholových manažerĤ udČlila svým organizacím prĤmČrnou známku 2 pĜi popisu schopnosti reagovat na pĜirozené i lidmi zpĤsobené katastrofy. Hodnocení manažerĤ zodpovČdných za každodenní bezpeþnostní záležitosti bylo však zcela jiné. Pouze 58 % prohlásilo, že jsou lépe pĜipraveni než pĜed rokem.

5 Proþ je tomu tak? OdpovČć je spojena s nástrahami, vztahujícími se k nejbČžnČjším postupĤm, které v oblasti zabezpeþení svých þinností organizace používají. VČtšina bezpeþnostních þinností spoþívá v nákupu a rozmístČní širokého spektra jednoúþelových Ĝešení v reakci na specifické hrozby, které se již projevily. PĜestože bylo vyvinuto urþité úsilí pĜi integraci tČchto Ĝešení, jsou stále pĜíliš rĤznorodé, a pĜedstavují Ĝadu taktických investic a aktivit, jejichž Ĝízení je nároþné na þas i pracovní sílu. To pomáhá vysvČtlit, proþ bylo ve studii vydané IDC zjištČno, že poptávka po odbornících na zabezpeþení informací celosvČtovČ poroste v pĜíštích nČkolika letech o 14 % za rok. (Tzn. dvakrát rychleji než je celkový nárĤst pracovních míst v celé oblasti IT.) V poslední benchmarkové studii spoleþnosti Nemertes Research byla vČtšina dotazovaných IT manažerĤ nespokojená s dobou, která trvá antivirovému programu než detekuje novou virovou epidemii a vyhlásí poplach. Respondenti naznaþili, že zpĤsoby vyhledávání, které umožní zkrátit þas mezi zjištČním a reakcí na potenciální hrozby, jsou hlavní prioritou pro firemní IT komunitu. Aby bylo možné reagovat na novou generaci hrozeb pro firemní systémy, je zapotĜebí nová životaschopná alternativa, které nebude: •

taktická,

•

jen þistČ reaktivní,

•

nároþná na pracovní sílu.

Zvyšující se poþet a stále vČtší sofistikovanost hrozeb pro firemní sítČ vyžadují, aby organizace vytvoĜily a trvale aktualizovaly zásady zabezpeþení sítČ, bezpeþnostní postupy a technologická Ĝešení. Vyžaduje se tedy integrovaný a proaktivní pĜístup k Ĝízení životního cyklu bezpeþnostních hrozeb, který bude cílenČ pĜedcházet incidentĤm a bezvadnČ pracovat se systémy, jež dynamicky Ĝídí a reagují na systémová rizika. S vhodnými integrovanými a proaktivními bezpeþnostními strategiemi mohou organizace získat víceúrovĖové obranné systémy, které inteligentnČ pĜidČlují zdroje podle hodnoty a úrovnČ zranitelnosti majetku. Dobrým výchozím bodem je integrace Ĝízení zranitelnosti (VM – vulnerability management) s Ĝešeními IPS.

6 ZaþlenČní Ĝízení zranitelnosti Pro Ĝízení bezpeþnostních síĢových rizik musí být organizace schopná objevit, inventarizovat a stanovit priority jednotlivých souþástí sítČ. Dále musí organizace shromáždit a analyzovat znalosti o hrozbách a dát je do souvislosti s jednotlivými síĢovými zaĜízeními. PotĜebný je rovnČž systém sledování a podávání zpráv o manuálních i automatických nápravných opatĜeních, provedených s cílem identifikovat rizika. VM umožĖuje systematickou analýzu toho, jak rĤzné složky rizika ovlivĖují firemní digitální prostĜedky. UmožĖuje organizacím identifikovat, stanovovat priority a omezovat rizika na základČ rovnice ohrožení majetku ze které vyplyne, jak jsou konkrétní síĢové komponenty pro spoleþnost dĤležité. Pro zavedení strategie VM je nezbytné porozumČt základním složkám rizika.

172


Pro úþely této zprávy je riziko definováno následující rovnicí: Riziko = hodnota majetku u zranitelnost u hrozba Pojmy zranitelnost a hrozba netechniþtí manažeĜi a vedoucí pracovníci þasto používají jako synonyma pro riziko. To vysvČtluje taktický (založený na Ĝešení na jednom místČ) pĜístup k zabezpeþení, který je pĜijímán v mnoha oborech. Zranitelnost se vztahuje k aktuálnímu rozmístČní specifických hodnot vzhledem ke specifickým hrozbám. NapĜíklad, pokud je router špatnČ nakonfigurován nebo na nČm není nainstalována záplata na obranu pĜed známým virem nebo þervem, je zranitelný vĤþi této hrozbČ. Hrozby se vztahují k rozdČlení škodlivých programových kódĤ, událostí a incidentĤ. Identifikace nových virĤ (nebo nových verzí þi kmenĤ virĤ) bude napĜíklad pĜispívat k poþtu hrozeb, o kterých musí organizace vČdČt a být pĜipravena je omezit. Existují známé a neznámé hrozby. Pro potĜeby strategického Ĝízení rizika je dĤležité mít jasnou pĜedstavu: •

o tom, jaké informace jsou kriticky dĤležité pro þinnost spoleþnosti;

•

o míĜe, v jaké jsou kritické prostĜedky zranitelné útokem;

•

o povaze skuteþných hrozeb - aktivního úsilí - vzhledem k pĜístupu, poškození nebo jinému narušení digitálního majetku.

Pochopení závislostí mezi tČmito tĜemi promČnnými je základem pro rozhodnutí, jak na denním základČ co nejlépe omezit a reagovat na rizika, se kterými se spoleþnosti setkávají. To reprezentuje základní odchylku od tradiþních standardních provozních postupĤ vČtšiny bezpeþnostních organizací.

7 Vyzdvihnutí imperativĤ Ĝízení VM mČní bezpeþnost z magické aktivity, reagující na specifické incidenty a pĜedstavuje základ, ze kterého lze zavádČt více proaktivní strategii tak, aby se zajistilo, že jsou pro kritické prostĜedky, aplikace a procesy vyþlenČny bezpeþnostní zdroje soumČĜitelné s jejich významem pro organizaci. NejdramatiþtČjším dĤsledkem úspČšného zavedení VM bude obnova normálního stavu v bojovém prostoru informaþní bezpeþnosti. Schopnost proaktivnČ identifikovat oblasti slabých (vysoce rizikových) míst, spíš než následná reakce na zuĜící poplach, mĤže eliminovat atmosféru ohrožení, která vzniká kdykoliv dojde k sebemenšímu incidentu. Rozumná strategie VM umožĖuje organizacím stanovit racionální úrovnČ tolerance rizik a pĜimČĜenČ Ĝídit odezvu na tato rizika. Dovoluje organizacím vytvoĜit zvládnutelnou politiku bezpeþnosti založenou na kvalitČ majetku, který musí být chránČn, a pĜidČlení odpovídajících zdrojĤ na základČ solidního porozumČní úrovnČ rizika pro organizaci.

„Spoleþnosti, které zavedou proces Ĝízení zranitelnosti zaznamenají o 90 % ménČ úspČšných útokĤ …“ Mark Nicolett, Gartner

8 PĜemostČní mezery mezi techniky a managementem Skuteþné snížení zatížení odborníkĤ na zabezpeþení pĜedstavuje integrace a automatizace iniciativ VM a IPS. Pokud chtČjí organizace identifikovat kriticky dĤležitá zaĜízení, musí stanovit priority jednotlivých aplikací a vybavení. Musí také identifikovat veškerý majetek, který je vysoce zranitelný. K dispozici jsou automatická Ĝešení, která umožní stanovit priority majetku a identifikovat rozsah a závažnost zranitelnosti síĢového zaĜízení. Na základČ standardních a na míru upravených pravidel umožĖují tato Ĝešení stanovit priority majetku rozlišením mezi servery a pracovními stanicemi, mezi místními a síĢovými aplikacemi. Toto Ĝešení napĜíklad ohodnotí zaĜízení, na kterém bČží sada webových serverĤ, výše než kanceláĜský poþítaþ sloužící jednomu uživateli. PĜi spolupráci s Ĝešeními IPS, jsou systémy VM schopné dynamicky reagovat na informace o potenciálních síĢových hrozbách a automaticky aktualizovat schopnosti IPS. ýím více nápravných akcí provádí IPS automaticky, tím ménČ lidských nebo manuálních zásahĤ je zapotĜebí. To umožĖuje uspoĜit lidské i technické zdroje a vČnovat je opodstatnČným aktivitám Ĝízení výjimek. VytvoĜení propojení mezi VM (identifikujícím systémy, jež musí být chránČny v první ĜadČ a co nejlépe) a ve spojení se strategií IPS (peþlivČ vyváženou pro vynucování dynamických zásad zabezpeþení v rĤzných þástech sítČ rĤznými avšak vhodnými zpĤsoby) se mĤže významnČ zlepšit bezpeþnostní pozice firem za souþasného omezení rozsahu potĜebných lidských a technických zdrojĤ.


173

174


Návrh infrastruktury PKI Ladislav Šolc Microsoft ýeská a Slovenská republika Aspekty, které významnČ ovlivĖují práci s digitálními certifikáty jsou napĜíklad zákony, interní pravidla, standardy a software. V praxi je to systém digitálních certifikátĤ, certifikaþních autorit a dalších registraþních autorit, které ovČĜují a potvrzují identitu každé strany, která je souþástí elektronických transakcí. Standardy pro PKI se stále rozvíjejí. I pĜes to, je infrastruktura PKI široce rozšíĜená jako základ elektronické komerce a bezpeþné komunikace. Podniková infrastruktura obsahuje celou Ĝadu aplikací, technologií a scénáĜĤ, které závisejí na používání digitálních certifikátĤ. PĜedtím, než se zaþnou digitální certifikáty používat, je nutné naplánovat a implementovat infrastrukturu veĜejných klíþĤ (PKI, Public Key Infrastructure). To zahrnuje celou Ĝadu krokĤ. Z þistČ technolo-gického pohledu jde zejména o konfiguraci jednotlivých parametrĤ, plánování hierarchie certifikaþních autorit, šablon a vlastností certifikátĤ, s ohledem na aktuální požadavky organizace. Zcela zásadní vČcí je potom vytvoĜení plánu pro implementaci, správu a zabezpeþení PKI.

1 Základní pohled na proces návrhu PKI V organizacích se používá velké množství rĤzných technologií, které jsou zcela zásadní pro její správný chod. MĤže jít napĜíklad o výmČnu informací o veĜejných zakázkách, vzdálený pĜístup k citlivým informacím, elektronický obchod a podobnČ. Správná implementace PKI, resp. certifikaþních služeb pro vydávání a správu digitálních certifikátĤ, nabízí cestu, jak tyto kritické interní i externí procesy zabezpeþit. Implementovaná infrastruktura PKI umožní napĜíklad toto: x

DigitálnČ podepisovat dokumenty a aplikace.

x

Ochránit elektronickou poštu pĜed neoprávnČným prohlížením.

x

Zabezpeþit komunikaci mezi poþítaþi, i když jsou spojené pĜes nezabezpeþenou síĢ ( napĜ. Internet, bezdrátová síĢ).

x

RozšíĜit a zlepšit ovČĜení identity uživatelĤ (napĜíklad pomocí þipových karet).

I v pĜípadČ, že Vaše organizace již má nČjak implementovánu PKI nebo její þást, je dobré projít proces plánování a návrhu. Je tak možné identifikovat, jaké požadavky již jsou vyĜešeny nebo stále þekají na vhodnou technologii.

2 Základní kroky v návrhu PKI 2.1

Požadavky na digitální certifikát

Jedním z prvních krokĤ je stanovení požadavkĤ na digitální certifikáty. Základní požadavky na digitální certifikáty se mohou rozdČlit podle následujících oblastí: Použité aplikace a technologie x

Aplikace mají specifické požadavky na délky klíþĤ, úþel za kterým byl certifikát vydán, konkrétní hodnoty v atributech certifikátu a podobnČ.

x

PĜíklady aplikací: Elektronická pošta a technologie S/MIME (NapĜ. Microsoft Outlook). Šifrování souborového systému (Encrypted File System). Šifrovaná komunikace mezi poþítaþi (SSL, IPSEC, PPTP).


175

Certifikáty pro uživatele a poþítaþe x

Certifikáty jsou vydávány za úþelem identifikace do rĤzných systémĤ nebo pro použití v rĤzných aplikacích.

x

PĜíklady použití uživatelských certifikátĤ: PĜihlášení do adresáĜové služby Microsoft Active directory pomocí þipové karty. Podepisování a šifrování elektronické pošty (napĜ. Microsoft Exchange a Outlook). PĜístup k webovému serveru pomocí šifrované komunikace (SSL, TLS). Zabezpeþení pĜístupu k bezdrátové síti (802.1X, RADIUS, Active Directory).

x

PĜíklady použití certifikátĤ pro poþítaþe: OvČĜení identity serveru a stanice. Zabezpeþená komunikace pomocí protokolĤ IPSEC. Zabezpeþení pĜístupu k bezdrátové síti (802.1X, RADIUS, Active Directory). Zabezpeþení pĜístupu k podnikové síti (802.1X, RADIUS, Active Directory).

VytvoĜení pravidel a postupĤ pro práci s digitálními certifikáty x

2.2

Certifikáty jsou vydávány za urþitým úþelem, urþitým identitám a na urþitou dobu. Životní cyklus certifikátu, pĜípady, kdy dojde k ztrátČ nebo zkompromitování, odpovČdné role pro vydávání a zneplatnČní certifikátĤ, zálohu a obnovu klíþĤ a mnoho dalších podrobností, je nutné velmi peþlivČ popsat a stanovit pravidla a postupy pro práci s certifikáty.

Návrh hierarchie certifikaþních autorit

Pro správné a bezpeþné fungovaní aplikací, které využívají certifikátĤ, je nutné vytvoĜit hierarchii vzájemnČ propojených certifikaþních autorit. PKI je zpravidla velmi komplexní a proto potĜebuje vícevrstvé uspoĜádání složené z tzv. koĜenové autority (Root CA) a jedné nebo více podĜízených autorit (Subordinate CA). Tyto autority jsou potom odpovČdné za vydávání, ovČĜování, obnovování a zneplatnČní certifikátĤ. Typické kroky pĜi návrhu hierarchie a implementace certifikaþních autorit (CA): Návrh Infrastruktury Certifikaþních autorit x

Naplánování základních vlastností (umístČní, úþel a další).

x

VýbČr modelu dĤvČry (interní nebo externí provozovatel CA, vzájemné propojení rĤzných CA).

x

Definování rolí v dĤvČryhodném prostĜedí (správci autorit, odpovČdné role za žádosti, schvalování a vydávání certifikátĤ, záloha a obnova informací a další).

x

Konvence názvĤ certifikaþních autorit (na vydaných certifikátech je jméno autority a v budoucnosti mĤže tato informace ovlivnit dĤvČru v samotnou službu).

x

UmístČní klíþĤ a databáze certifikaþní autority (klíþe musí být zabezpeþeny, napĜíklad hardwarovými moduly, databáze mohou þasem pĜekroþit volné místo na systémových oblastech).

RozšíĜení hierarchie o více úrovní

176

x

PĜi plánování hierarchie dojde z pravidla ke zjištČní, že není vhodná jen jediná certifikaþní autorita.

x

Požadavkem na rozšíĜení mĤže být napĜíklad geografická rozdČlení, velké množství certifikátĤ pro rĤzné úþely, spojení s další organizací a podobnČ.


2.3

Stanovení vlastností certifikátĤ

Po implementaci infrastruktury CA je možné zaþít s definicí vlastností jednotlivých certifikátĤ. Vlastnosti musí odpovídat potĜebám uživatelĤ a bezpeþnostním požadavkĤm organizace. Které kroky je nutné použít pĜi stanovení vlastností certifikátĤ? VýbČr nebo vytvoĜení potĜebných šablon x

Certifikáty se vydávají na základČ šablon s definovanými vlastnostmi.

x

Jde o stanovení délky klíþĤ, zálohu klíþĤ, dobu platnosti a podobnČ.

x

Ne každá certifikaþní autorita nabízí možnost tvorby vlastních šablon.

Zabezpeþení certifikátĤ x

Je dobré rozdČlit rĤzným rolím oprávnČní pro žádost o certifikát, schválení certifikátu, vydání certifikátu a zneplatnČní certifikátu.

x

Nastavení oprávnČní a pokus o zmČnu by mČlo podléhat auditu.

2.4

Plán pro práci s certifikáty

Jakmile je dokonþena konfigurace vlastností certifikátĤ, je možné certifikáty vydávat. Je však nutné, aby byl vytvoĜen plán správu certifikátu bČhem jejich životního cyklu. Následující oblasti by mČl plán pro práci s certifikáty rozhodnČ zahrnovat: ZpĤsob žádosti o certifikát a zpĤsob obnovení vydaného certifikátu x

Žádost o certifikát mĤže probíhat nČkolik zpĤsoby. V prostĜedí PKI založeném na systému Windows Server 2003, má uživatel možnost žádat o certifikát sám, mĤže jej získat automaticky nebo za nČj požádá držitel speciální role

x

Žádat je možné prostĜednictvím webového formuláĜe, speciální aplikace, skriptu nebo automaticky s využitím systémových politik.

x

Automatické vydávání certifikátĤ je možné i pro poþítaþe ve firemní síti.

x

Potom, co je žádost uskuteþnČna, je možné certifikát vydat ihned (využívá se pĜed-ovČĜení protokolem Kerberos), nebo poþkat na schválení odpovČdnou rolí.

Propojení uživatelských úþtĤ s certifikáty x

AdresáĜové služby, jako je Active Directory, obsahují velké množství informací o uživatelských úþtech v jednotlivých atributech. I certifikáty mohou být uloženy v jednom z tČchto atributĤ. Ostatní aplikace zaþlenČné do adresáĜové služby, tak mohou certifikáty jednoduše využít.

VytvoĜení pravidel pro zneplatnČní certifikátĤ x

Každodenní realitou je ztráta certifikátĤ nebo dalších citlivých þástí. Je proto velmi þastým požadavkem zneplatnit vydané certifikáty, ještČ dĜíve, než vyprší jejich doba platnosti. V tomto kroku se musí stanovit, kde se budou nacházet seznamy zneplatnČných certifikátĤ, jak se s nimi bude pracovat a jakou roli budou hrát pĜi provozování PKI služeb

Plán pro zálohu a obnovu certifikátĤ, jejich klíþĤ a dalších údajĤ x

StejnČ jako zálohování certifikaþní databáze, je nutné zálohovat informace o certifikátech. Jde pĜedevším o vlastní seznamy vydaných certifikátĤ, jejich klíþĤ a seznamy zneplatnČných certifikátĤ.

x

NČkteré certifikáty, napĜíklad certifikáty vydané za úþelem šifrování, mají jiná pravidla pro zálohování. U tČchto certifikátĤ se zálohují (archivují) privátní klíþe bezprostĜednČ po vydání tak, aby v pĜípadČ ztráty mohl být privátní klíþ obnoven. Uživatel potom mĤže dešifrovat potĜebné informace. Pro obnovu privátních klíþĤ je zpravidla tĜeba administrativnČ ošetĜit, kdo bude mít potĜebná oprávnČní. MĤže to být i více samostatných osob.


177

3 Nasazení PKI Návrh, plán, testování v laboratoĜi a pilotní projekt je hotov. Je tedy možné zaþít s implementací PKI do produkþního prostĜedí. Disciplinovaný pĜístup pĜi nasazování PKI je naprosto základním pĜedpokladem úspČchu bezpeþného prostĜedí a fungujících aplikací. 1.

Naplánování jednotlivých milníkĤ

2.

Instalace služeb certifikaþních autorit

3.

Konfigurace CDP a AIA

4.

Šablony certifikátĤ

5.

Pravidla pro vydávání a revokování certifikátĤ

6.

Systémová pravidla pro PKI, skupinové politiky

7.

UmístČní CRL

8.

VytvoĜení rolí pro správu CA

9.

Vydávání certifikátĤ

Dá se Ĝíci, že vČtšina þasu vČnovaná PKI se sestává z plánování. Vlastní implementace technologií zabere podstatnČ ménČ þasu a v pĜípadČ prostĜedí Microsoft Windows Server 2003 jde také o minimální investice do softwarového vybavení. Proto je dĤraznČ doporuþeno dokonþit proces plánování pĜed tím, než se zaþne s implementací PKI. Certifikaþní služby v produktu Microsoft Windows Server 2003 splĖují všechny požadavky, které mĤže pĜinést proces plánování PKI. V souþasné dobČ probíhá certifikace Common Criteria na úroveĖ EAL4+. Jednou významnou výhodou je také to, že tyto služby jsou standardní souþástí produktu a není tedy tĜeba platit za další softwarové vybavení nebo licence. To pĜedstavuje proti ostatním komerþním Ĝešením podstatné snížení investic. Leckdy i v Ĝádech miliónĤ korun.

4 Další zdroje: [1]

Public key infrastructure overview – http://www.microsoft.com/pki/

[2]

Public Key Infrastructure for Windows Server 2003 – http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

[3]

Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure – http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.msp x

178


Bezpeþnost a moderní databázové systémy Petr Paukner Oracle Czech, s.r.o. Konsolidace aplikací a dat se stává prvoĜadým cílem celé Ĝady organizací. Tuto tendenci umožĖuje neustále se zvyšující výpoþetní výkon a pĜenosová kapacita sítí, spolu s moderními pamČĢovými systémy. PĜednosti konsolidace jsou zĜejmé a patĜí k nim, kromČ jiného, snížené náklady na IT infrastrukturu a lepší prostĜedí pro podporu rozhodování (business inteligence). Zlepšuje se však v konsolidovaném prostĜedí také bezpeþnost? Je opravdu možné mít pod kontrolou ochranu osobních údajĤ? Nebyl jeden ze základních principĤ zabezpeþení informaþních systémĤ – princip poskytovat pouze informace nutné pro vykonávání urþité þinnosti – jen dĤsledkem pĜedchozí fragmentace dat v distribuovaných systémech? Rychlý nárĤst uživatelĤ z relativnČ malých skupin provČĜitelných zamČstnancĤ, pĜistupujících k aplikacím v rámci lokálních sítí, k souþasnému stavu, kdy þasto pĜistupují tisíce uživatelĤ k systémĤm pĜes internet, uþinil správu identit klíþovou komponentou bezpeþnostní architektury. Navíc se objevují stále nové požadavky na vyšší míru zabezpeþení vývoje a provozu aplikací z hlediska bezpeþnosti. NČkteré z tČchto požadavkĤ jsou dĤsledkem zmČn v infrastruktuĜe organizací, jiné jsou diktovány novými legislativními požadavky. K tČm patĜí napĜíklad požadavky na ochranu osobních údajĤ, povinnost informovat zákazníka (obþana) o možném ohrožení osobních dat, ochrana informací o pacientech (HIPAA) a v neposlední ĜadČ zákony zajišĢující vyšší transparentnost mezinárodního obchodního a podnikatelského prostĜedí (napĜ. zákon Sarbanes-Oxley). V uplynulých letech se dramaticky zvýšila informovanost o problematice ochrany informací, ale souþasnČ se také výraznČ rozšíĜila potenciální ohrožení informaþních systémĤ. Všichni zúþastnČní, tvĤrci aplikací, dodavatelé, integrátoĜi, zákazníci i jejich partneĜi by mČli vČnovat zvýšenou pozornost problematice Ĝízení pĜístupĤ, prokazatelnosti a bezpeþnému provozu informaþních systémĤ. V tomto þlánku se budeme zabývat možnostmi, které jim k tomu poskytují moderní databázové systémy.

1 Dodavatelé databází a bezpeþnost Bezpeþnost se stala dĤležitým prvkem pĜi koncipování prvních komerþních relaþních databází firmami Oracle a IBM na konci osmdesátých let. PĜední dodavatelé si vytvoĜili pracovní skupiny se zákazníky s vysokými nároky na bezpeþnost. Toto vzájemné ovlivĖování umožnilo vytvoĜit z relaþních databází jednu z nejbezpeþnČjších komponent informaþních technologií. Urþitou formu záruky bezpeþnosti nabízených databázových systémĤ poskytuje zákazníkĤm propracovaný systém nezávislých bezpeþnostních certifikací, které dosvČdþují soulad s mezinárodními kriterii (napĜ. Common Criteria, ISO 15 408). Moderní databázové systémy poskytují rozšíĜené bezpeþnostní funkce typu konceptu virtuální privátní databáze, odstupĖovaného auditingu, enkrypce vybraných dat, bezpeþných aplikaþních rolí a globálního aplikaþního kontextu. Pro zvýšení bezpeþnosti celé infrastruktury IS Ĝeší moderní databáze také problematiku silné autentizace uživatelĤ a komponent v síti a enkrypce dat pĜi pĜenosech. V neposlední ĜadČ je bezpeþnost databází tČsnČ spjata s komplexní správou identit uživatelĤ.

2 Správa identit uživatelĤ Správa identit je proces, pomocí kterého je Ĝízen proces kompletního životního cyklu bezpeþné identifikace uživatelĤ a komponent IS v dané organizaci. Správou identit se nejþastČji chápe správa aplikaþních uživatelĤ, kde jednotlivé kroky zahrnují vytvoĜení úþtu, pozastavení jeho platnosti, zmČnu pĜístupových práv a zrušení úþtu. Správa identit se však neomezuje jen na uživatele, ale zahrnuje i síĢové entity – zaĜízení, procesy, aplikace, zkrátka vše co potĜebuje interagovat v síĢovém prostĜedí. Entity Ĝízené správou identit mohou zahrnovat i uživatele mimo organizaci, napĜ. zákazníky, obchodní partnery, ale také webové služby. Bezpeþnostní politiky Ĝídící pĜístupová práva mohou být konsistentnČ aplikována na všechny uživatele všech aplikací za pĜedpokladu, že jsou uživatelé spravováni v jednom centralizovaném a zabezpeþeném úložišti (repository). Správa identit (Identity Management) pĜedstavuje dne s u pĜedních dodavatelĤ databází (tj. Oracle, IBM a Microsoft) integrovanou komponentu správy infrastruktury. Správa identit dnes zpravidla zahrnuje adresáĜové služby (na standardu LDAP), nástroje pro integraci adresáĜĤ, služby poĜízení a vybavení. ProstĜedí Oracle


179

Identity Management navíc poskytuje napĜíklad nástroje pro možnost delegování administrátorských þinností, autentizaþní a certifikaþní služby a integrovanou certifikaþní autoritu. Klíþové požadavky na správu identit jsou: x

Robustnost a škálovatelný výkon.

x

Snadná integrace s aplikacemi a službami.

x

Nástroje pro centrální správu uživatelĤ a síĢových entit.

x

Soulad s otevĜenými standardy.

x

Interoperabilita s Ĝešeními jiných dodavatelĤ (napĜ. certifikaþními autoritami).

3 ěízení pĜístupĤ, prokazatelnost a odpovČdnost Konsolidace dat a pĜistup pĜes internet umožĖují organizacím využívat témČĜ neomezené možnosti pro zvyšování efektivity, ale pĜinášejí také nové bezpeþnostní problémy. RozšíĜené možnosti pĜístupu k datĤm vyžadují jemnČ odstupĖovaná pĜístupová práva. Organizace dnes mají þasto omezené informace o uživatelích, kteĜí pĜistupují k jejich systémĤm. Dokonce i v pĜípadČ, že tyto informace mají, mĤže být pro organizace obtížné zcela zabránit uživatelĤm pĜistupovat k informacím v rozporu s bezpeþnostními pravidly dané organizace. Je proto dĤležité mít k dispozici nástroje, které umožĖují Ĝídit pĜístup k citlivým informacím a zamezit nepovolenému pĜístupu k takovým informacím. Moderní relaþní databázové systémy proto umožĖují omezit pĜístup pouze k urþitým ĜádkĤm databázových tabulek. Co to ve skuteþnosti znamená? Tradiþní databázové systémy urþovaly pĜístupová práva na úrovni objektĤ (tabulek). Moderní integrované komponenty (napĜ. Oracle Label Security) umožĖují vynucenČ omezit pĜístup k pouze k urþitým ĜádkĤm vybraných sloupcĤ databázových tabulek. NapĜíklad obsahuje-li nČkterá databázová tabulka data o zamČstnancích a jejich platech, umožĖuje tento mechanismus omezit pĜístup daného zamČstnance jen na Ĝádku obsahující jeho vlastní údaje (v pĜípadČ managerĤ napĜ. jen na jejich podĜízené). Tento mechanismus se mĤže zapínat automaticky v situaci, kdy je vyžadován pĜístup k informaci o platech a být vypnut u dotazĤ, které nevyžadují žádnou chránČnou informaci. Správa úrovní pĜidČlených pĜístupových práv (security clearances) je propojena se správou identit, v jejichž adresáĜích se také informace o pĜístupových právech udržuje. To umožĖuje zjednodušení aplikací s tím, že bezpeþnostní pravidla chránící citlivé informace jsou realizována uvnitĜ databáze a nekomplikují vrstvu aplikací. OdstraĖuje se tím napĜíklad tradiþní problém nedostateþné ochrany dat, v pĜípadČ, že se k nim pĜistupuje analytickým nástrojem mimo aplikace, které se doposud staraly o zabezpeþení.

4 Auditing Další úrovní ochrany je auditing, který umožĖuje vylepšit ochranu informaþních systémĤ ve vetší hloubce. NČkteré aplikace mají speciální požadavky na evidování þasu a identity osob, zpĜístupĖovaných dat a zaznamenání pĜípadných modifikací. Zaznamenávání informací z prĤbČžného auditingu je nejužiteþnČjším nástrojem pro detekci anomálií a poskytování dat k forenzním analýzám. UmožĖuje také zajistit požadavek nepopiratelnosti pĤvodu jednotlivých transakcí nebo událostí. Databáze typu IBM DB2 a Oracle poskytují pokroþilé vestavČné auditovací nástroje, umožĖující jednotný pohled na standardní informaci z auditu a podrobnČjší informace, jdoucí až na úroveĖ jednotlivých update, delete a insert operací. Také auditovací mechanismy jsou dnes zpravidla svázány s identitami uživatelĤ udržovanými a adresáĜových službách správy identit. Problematika auditingu vystupuje do popĜedí zvláštČ pĜi pĜechodu na moderní 3-vrstvé aplikace. VČtšina tČchto aplikací totiž autentizuje uživatele proti stĜední vrstvČ (aplikaþnímu serveru nebo transakþnímu monitoru), která se poté pĜipojuje k databázi jako privilegovaný super-uživatel, který vykonává všechny aktivity iniciované koncovými uživateli. Souþasné databázové systémy proto ve spojení s aplikaþními servery (IBM WebSphere, Oracle Aplication Server) poskytují zachování identity skuteþného koncového uživatele i pĜes stĜední vrstvu. Tím mĤže být zajištČn konsistentní auditing všech akcí uživatelĤ bez ohledu na to, pĜes jaké vrstvy infrastruktury byly vykonány.

180


5 Proxy autentizace Možná nejdĤležitČjší bezpeþnostní vlastností v prostĜedí 3-vrstvých architektur je schopnost autentizovat identitu uživatelĤ pĜes proxy komponentu až do databáze. Každá komponenta stĜední vrstvy mĤže mít delegováno právo autentizace a vykonávání operací pro specifickou skupinu koncových uživatelĤ (informaþní portál, elektronický obchod, intranetový business intelligence portál atd.). Proxy autentizace umožĖuje implementovat model „omezené dĤvČryhodnosti“ pro jednotlivé servery stĜední vrstvy a tím odstranit problém plnČ privilegované stĜední vrstvy. To znamená, že je možné pĜiĜadit vyšší práva vybraným aplikaþním serverĤm (napĜ. umístČným uvnitĜ firemního prostĜedí chránČného firewallem) a omezit práva ostatních serverĤ (a jejich uživatelĤ). Pro úþely takovéto autentizace je možné využít rozšíĜení pomocí jednoznaþného jména uživatele (Distinguished Name), pĜípadnČ plných digitálních certifikátĤ (X.509). Proxy autentizace aplikaþních uživatelĤ je zvláštČ cenná pro prostĜedí e-business aplikací s tisíci uživateli, protože zajišĢuje chránČný pĜístup k datĤm na úrovni jednotlivých uživatelĤ a vyhovuje také vysokým nárokĤm a výkon a robustnost takového prostĜedí.

6 Ochrana databází v síĢovém prostĜedí Nástroje zabezpeþení databází v síti umožĖují organizacím vytváĜet Ĝešení, která zajišĢují komunikaci mezi databázemi chránČnými komunikaþními kanály a dovolují selektivnČ enkryptovat data v databázích. Distribuované databáze poskytují jistou míru ochrany svým fyzickým oddČlením. Informace spravované jednotlivými jednotkami (obchod, marketing, výroba, distribuce atd.) jsou þasto zpracovávány separátními databázemi – vznikají tak povČstné „ostrovy informací“. Toto oddČlení þasto omezuje možnost plnČ využít informaþní bohatství dané organizace napĜíklad pro analytické úþely. Zvyšování hodnoty konsolidovaných dat pro oprávnČné uživatele zvyšuje však bohužel i jejich hodnotu v pĜípadČ jejich zneužití pĜi neoprávnČném pĜístupu. Moderní databáze využívají kombinované schéma zajištČní autentizace, pĜístupových práv a auditu, spojené s integrovanými mechanismy automatické enkrypce dat pĜenášených v síti a mechanismĤ silné autentizace. VestavČné algoritmy pro enkrypci a integritu dat nevyžadují využívání certifikaþní autority. S každou novou verzí databází od pĜedních dodavatelĤ jsou podporovány nejnovČjší enkrypþní mechanismy. Posledním doplĖkem provČĜeným v IT prĤmyslu je standard AES (Advanced Encryption Standard). Podporovány jsou obvykle standardy AES, RC4, 3DES, MD5 a SHA1.

7 Bezpeþnostní certifikace V oblasti bezpeþnosti bohužel neexistuje pĜímý ekvivalent srovnávacího benchmarku jako jsou napĜ. TPC benchmarky. NaštČstí však existují mezinárodní standardy typu International Common Criteria (ISO 15 408). Zákazníci vyžadují produkty a systémy, které umožní plnČní jejich cílĤ, vþetnČ zajištČní urþité úrovnČ zabezpeþení. Dodavatelé jsou nuceni navrhovat a vyvíjet bezpeþné systémy, které drží krok s rychle se mČnícím IT prostĜedím a bezpeþnostními hrozbami. Zcela zákonitČ se proto ozývají následující otázky: x

Jak si mohou zákazníci vybírat mezi produkty s ohledem na bezpeþnostní perspektivy?

x

Jaká jsou mČĜítka a standardy, pomocí kterých mohou být mČĜeny jednotlivé produkty z hlediska kvality jejich bezpeþnostních mechanismĤ?

x

Kde a jak lze nalézt potvrzení jednotlivých dodavatelĤ ohlednČ bezpeþnostní robustnosti jejich produktĤ?

Zde hrají dĤležitou roli bezpeþnostní ohodnocení (evaluace) a bezpeþnostní provČĜení pro stanovení hodnoty jednotlivých produktĤ z hlediska bezpeþnosti. Bezpeþnostní ohodnocení poskytuje formální mČĜítko, oproti kterému mĤže být daný produkt nebo systém certifikován, a tím potvrzeno, že splĖuje požadované mezinárodní bezpeþnostní standardy. Celý proces je provádČn nezávislými (avšak autorizovanými a akreditovanými) organizacemi. Jednotliví dodavatelé IT produktĤ vČnují rĤznou míru investic do iniciování a podpory procesĤ bezpeþnostního ohodnocování svých produktĤ. Výsledky takových certifikací pak nastavují uživatelĤm tČchto produktĤ úroveĖ dĤvČry v kvalitu designu, implementace a fungování vestavČných bezpeþnostních mechanismĤ. Systémoví integrátoĜi navíc získávají možnost vybrat vhodné komerþní produkty a integrovat je do systémĤ s požadovanou urþitou úrovní bezpeþnosti.


181

Mezinárodní Common Criteria for Information Technology Security Evaluation (þasto odkazovaná jen jako Common Criteria, pĜíp. CC) jsou výsledkem snahy o sjednocení (nejenom) amerických a evropských standardĤ. Výsledkem je, že tato kriteria byla pĜijata v roce 1999 jako mezinárodní ISO norma (ISO 15408), který nahrazuje starší US TCSEC a ITSEC kriteria. Common Criteria zjednodušila výše uvedené procesy a stala se proto celosvČtovým standardem s cílem vzájemného uznávání certifikátĤ podle CC kriterií jednotlivými þlenskými státy EU a NATO.

8 Shrnutí Moderní databázové systémy pozvedly Ĝešení bezpeþnosti dat na novou úroveĖ. Nezávislé bezpeþnostní certifikace na stranČ jedné a spolupráce dodavatelĤ databází a nároþnými uživateli na stranČ druhé pĜinášejí ovoce ve vyšší míĜe dĤvČryhodnosti databázových technologií. Robustní podpora nástrojĤ jako je integrovaná správa identit, jemnČ odstupĖovaný auditing, ochrana dat na úrovni Ĝádky, víceúrovĖová bezpeþnost, integrované certifikaþní autority a selektivní enkrypce dat v databázi jsou jen þástí bezpeþnostních mechanismĤ využívaných v moderních databázích. Provázaností uvedených mechanismĤ tvoĜí objektovČ-relaþní databáze ideální platformu pro vytváĜení a provoz zabezpeþených aplikací v dnešním komplexním prostĜedí svČta propojeného internetem.

182


Ochrana pĜístupu k aplikacím REKONix Karafiátová 60, Praha 10, 106 00, http://www.rekonix.cz

1 Úvod Každý den se setkáváme s problémem bezpeþnosti pĜístupu ke službám na našich serverech, aĢ už z vnitĜní sítČ nebo vzdálenČ pĜes internet. V osobním styku mĤžeme identifikovat druhou strany dle tváĜe nebo dle povČĜovacího dokumentu þi prĤkazu. V okamžiku, kdy dochází k elektronickému pĜístupu, je ovČĜení identity (identifikace, autentizace) obtížnČjší, protože identifikace mĤže být pravá nebo podvržená.

2 Metody ovČĜování identity uživatelĤ (autentizace) PĜístup statickými hesly, nejobvyklejší metoda autentizace uživatele, je založen na jménČ uživatele a k nČmu pĜíslušejícímu heslu. Dnes již tato autentizace není dostateþná a proto pĜicházejí pokroþilé metody autentizace. V tomto pĜíspČvku pĜedstavujeme produkt Stadrin®, který je založen na technologiích spoleþnosti VASCO® Data Security. PĜi ovČĜení identity uživatele statickým heslem je hlavním problém v mechanismu, jak udržet toto heslo v tajno-sti a zachovat tak jeho bezpeþnost. Protože heslo je hlavní ovČĜovací údaj uživatele, je tĜeba zajistit, že toto heslo zná pouze oprávnČný uživatel a nikdo jiný. Protože hesla jsou obvykle spravována samotnými uživateli, jsou þasto velmi slabá, pĜedevším pak založená na osobních údajích, jménech dČtí, zvíĜecích þi osobních miláþkĤ, datech narození a podobnČ. Tak je velmi snadné je uhodnout a zneužít. NČkdy je situace lepší a uživatelé si skládají hesla z kombinací slov, þísel a zkratek. Bohužel stále existuje hrozba odhalit hesla brutálními metodami útoku na ovČĜovací mechanismy podporovanými více þi ménČ dokonalými slovníkovými metodami. Se stále výkonnČjšími poþítaþi a rychlejšími sítČmi je tento zpĤsob snazší. Statické heslo je bezpeþné pouze pokud není nikde uchována jeho kopie, není zaznamenáno v digitální þi papírové podobČ nebo není pĜilepené na monitoru. I v pĜípadČ, že máme silné statické heslo a je bezpeþnČ uložené, problém není stále zažehnán, protože bezpeþnost mĤže být ohrožena dalšími faktory. Lze si snadno pĜedstavit trojského konČ, který zaznamenává naši aktivitu na klávesnici a odesílá tyto záznamy potenciálnímu útoþníkovi. Dalším rizikem je odposlouchávání síĢové komunikace a získání hesla, které je v ten okamžik posíláno v nezašifrované podobČ. ýasto staþí, když se nČkomu podíváme pĜes rameno a odeþteme, co zadává na klávesnici. Podobná je situace i v pĜípadČ, kdy používáme magnetické karty, smart karty nebo biometrická zaĜízení. Je to proto, že heslo které se pĜenáší od klienta k serveru pĜes komunikaþní kanál, je stále statické. Je možné Ĝešit tento problém? SamozĜejmČ, že ano! Pojćme se podívat, jak snadné je Ĝešení takové situace. Kdykoli potĜebujeme zvýšit bezpeþnost autentizace uživatele, mĤžeme použít dynamická (jednorázovČ použitá) hesla, tzv. OTP (One Time Password). S touto metodou ovČĜování se dnes bČžnČ setkáme v bankovním a finanþním sektoru, kde data mají skuteþnou vyþíslitelnou hodnotu. I v pĜípadČ, že je heslo vyzrazeno, nebo tĜeba odchyceno z klávesnice, není bezpeþnost kompromitována, protože pro každé další použití je generováno nové heslo. MĤžeme využít nČkolik metod (zpĤsobĤ, politik) pĜidČlování jednorázových hesel, vþetnČ pĜeddefinovaných sekvencí OTP, speciálních softwarových komponent nebo hardwarových autentizaþních kalkulátorĤ, které jsou dnes nepreferovanČjší metodou.

3 Zvýšení bezpeþnosti jednorázových hesel (OTP) Ke zvýšení bezpeþnosti OTP je možné rozšíĜit autentizaþní proces nČkolika dalšími faktory. NejþastČji se využívá PIN (Personal Identification Number) a výzva serveru (challenge). Pro ovČĜení, že jednorázové heslo skuteþnČ pochází od dĤvČryhodné strany, server po obdržení uživatelského jména vygeneruje výzvu (challenge), která vstupuje do procesu generování jednorázového hesla jako jeden z faktorĤ. Výzva je bČžnČ pĜenášena použitím stejného komunikaþního kanálu, ale pro zvýšení úrovnČ bezpeþ-nosti je možné použít jiné komunikaþní kanály, jako napĜíklad GSM SMS a podobnČ.


183

4 Možný kompromis Jiná úroveĖ autentizace pĜístupu je použití kompromisní metody. NejznámČjším systémem je použití pĜeddefinovaných hesel (rozdílných pro každého uživatele) které jsou organizovány do maticové struktury. ObecnČ se tato metoda nazývá „Grid Card“, kde každé políþko je reprezentováno oznaþením Ĝádku a sloupce. Každá tato buĖka obsahuje tzv. Quasi One Time Password (QOTP). Server po pĜijetí uživatelského jména vyšle výzvu (napĜíklad C4). Uživatel na základČ této výzvy použije heslo z matice QOTP a toto využije jako svoji identifikaci. V principu tento proces funguje jako autentizace dynamickým heslem.

5 Reálné Ĝešení Na þeském i celosvČtovém trhu je Ĝada produktĤ, které v rĤzné šíĜi a na odlišných technologických platformách pĜinášejí Ĝešení autentizace jednorázovými hesly. Spoleþnost REKONix uvedla na celosvČtový trh vlastní produkt Stadrin® (http://www.stadrin.com) pro platformu operaþního systému Linux (Red Hat, Novell SuSE, aj.). Produkt je založen na široce rozšíĜené autentizaþní architektuĜe PAM (Pluggable Authentication Module). Tento produkt ve spojení s PAM architekturou pĜináší implementaci OTP do existujících systému bez nutnosti modifikace aplikací a služeb. Vrstva PAM byla zvolena pro její rozšíĜenost. Systém je založený na použití Stadrin® PAM modulu a autentizaþních kalkulátorech Digipass od spoleþnosti Vasco Data Security.

Obr 1: Základní typy tokenĤ firmy Vasco.

6 Autentizaþní kalkulátory Pro generování jedorázových hesel Stadrin® využívá širokou Ĝadu autentizaþních kalkulátorĤ spoleþnosti Vasco. Tyto kalkulátory bČžnČ nazýváme “tokeny”. Tokeny jsou vlastnČ terminály, které používá uživatel ke generování hesla pro autentizaþní proces. Vasco tokeny se používají po celém svČte již mnoho let a je tedy ovČĜená jejich odolnost proti zniþení, dlouhá životnost a nízká poruchovost. Jsou velmi vhodné pro denní používání. Úloha tokenu je držet uživatelovy specifické informace (jednoznaþný identifikátor) a generovat hesla pomocí šifrovacího algoritmu na základČ vstupních dat. Vstupními daty pro šifrovací algoritmus jsou unikátní uživatelské informace uložené v tokenu, data zadaná uživatelem z klávesnice a aktuální þas. Tato data vstupují jako parametry do 3DES šifrovacího algoritmu a výsledek je zobrazen na displeji tokenu (viz obrázek výše). Token je chránČn proti zneužití uživatelsky definovatelným PINem v závislosti na použitém tokenu.

7 Serverová strana Server využívá implementaci Stadrin® PAM modulu, který využívá databázi pro uložení uživatelských dat a informací o tokenech. Jako databázi lze zvolit úložištČ LDAP, MySQL nebo jinou datovou základnu dostupnou pĜes ODBC rozhraní. Úloha administrátora je nadefinovat vazby mezi tokeny a uživateli systému a pĜiĜazení metod autentizace jednotlivým službám, které chceme chránit. Je možné pĜiĜadit token více uživatelĤm a tak umožnit jedné fyzické osobČ pĜistupovat k sytému v rĤzných uživatelských þi administrátorských rolích. Systém mĤžeme nakonfigurovat pro využití tĜí autentizaþních metod – viz dále kap. 9, 10 a 11.

184


8 Metoda 1 Na bČžících systémech poskytujících služby a sdílené zdroje je možná autentizace statickým heslem. Je to standardní metoda autentizace použitá v PAM architektuĜe. Pro první krok pĜi implementaci je možné autentizovat jen vybrané uživatele (zvýšená bezpeþnost) pomocí tokenĤ a zbytek uživatelĤ autentizovat dosavadní metodou – statickým heslem. RozšíĜení autentizace použitím tokenĤ je velmi snadné a jednoduše jej dosáhneme zmČnou politiky ovČĜování hesel koneþných uživatelĤ.

9 Metoda 2 Metoda “Response Only” (RO). První z nabízených metod ovČĜování uživatelĤ hesly generovanými tokenem je režim “Response Only“ (pouze odpovČć). V pĜípadČ že uživatel používá svĤj token pro generování jednorázového hesla, po zapnutí zadá PIN, kalkulátor zobrazí na displeji jednorázové heslo. Toto heslo je poþítáno šifrovacím algoritmem na základČ jednoznaþného identifikátoru uživatele (tokenu) a aktuálního þasu. Variabilita hesla je pĜímo založena na þasovém þítaþi tokenu pĜi šifrovacím mechanismu. Každé generované heslo má životnost 36 sekund, resp. každých 36 sekund se generuje nové jednorázové heslo. Z toho plyne, že server musí udržovat správný aktuální þas, aby mohl korektnČ ovČĜovat hesla generovaná tokeny. Toto lze snadno zajistit bČžnČ dostupnou implementací NTP synchronizace þasu. StandardnČ lze jednorázové heslo generovat v rozsahu od 6-ti decimálních þíslic do 8-mi hexadecimálních znakĤ. Defaultní délka hesla pro Stadrin® je 8 decimálních þíslic. Délka hesla je uživatelsky definovatelná pĜi programování tokenu a lze ji na pĜání zákazníka zmČnit. Seed value

ýas +

DES / 3DES

Jednorázové heslo

Událost

Obr 2: Schema metody “Response Only” (RO).

10 Metoda 3 Metoda “Challenge/Response” (CR). Princip generování hesla je obdobný jako v pĜedešlém schématu. Zvýšení bezpeþnosti je založeno na dalším faktoru, který vstupuje do šifrovacího mechanismu pĜi generování hesla – tzv. výzvČ, kterou zobrazuje server pĜi zadání uživatelského jména. SamozĜejmostí je, že uživatelské heslo generované metodou Challenge/Response také trvá standardnČ 36 sekund. Z uživatelského pohledu autentizace zaþíná zadáním uživatelského jména do pĜihlašovacího dialogu. Poté dostane od serveru výzvu (challenge). Tuto výzvu zadá do tokenu pomocí integrované klávesnice. Na základČ tohoto údaje, jednoznaþného identifikátoru a þasu je pomocí šifrovacího algoritmu vygenerováno jednorázové heslo, které se zobrazí na displeji a uživatel jej použije pro pĜihlášení.


185

Seed Výzva

(ýas)

DES / 3DES

Jednorázové heslo

Obr 3: Schema metody “Challenge/Response” (CR).

11 Metoda 4 Message Authentication Code (MAC). Oproti metodám ovČĜováni uživatele uvedeným výše je tokeny spoleþnosti Vasco Data Security podporována ještČ jedna, spíše autorizaþní, metoda. V tomto pĜípadČ autentizaþní proces je pĜímo spojen s pĜenášenými daty. V prĤbČhu ovČĜování této metody je serverová strana v jednom okamžiku schopna ovČĜit identitu uživatele a zároveĖ autenticitu pĜenášených dat v rámci aplikace. Jako v pĜípadČ Challenge/Response metody, kde challenge je generována na stranČ serveru pomocí speciálního PAM modulu, lze do tokenu zadávat údaje až do délky 16-ti numerických þíslic pomocí integrované klávesnice. To znamená, že token mĤže generovat nČco jako digitální podpis transakce, který obsahuje jednak jednoznaþnou identifikaci uživatele a dále ovČĜení validity dat až do osmi pĜenášených položek. Tato metoda je používána pĜedevším ve finanþním sektoru.

12 Implementace systému Stadrin® Instalace autentizaþního systému Stadrin® je velmi jednoduchá díky instalaþnímu balíþku rpm, v jehož tvaru je dodáván. Program vyžaduje linux kernel 2.2 a vyšší a glibc minimálnČ verze 2.2. Jako úložištČ dat lze použít LDAP, MySQL nebo UnixODBC, které mohou být umístČny jak pĜímo na serveru se systémem Stadrin®, tak na jiných serverech pĜístupných protokolem TCP/IP. Po samotné instalaci se automaticky spustí skript, který uživatele provede základním nastavením programu. Nejprve zvolíme backend pro uložení informací o uživatelích a tokenech. Možnost umístČní databáze na vzdáleném serveru umožĖuje použití jedné centrální databáze pro všechny poþítaþe chránČné systémem Stadrin®. Všechny konfiguraþní údaje jsou umístČny v jediném souboru /etc/stadrin/stadrin.conf. Administrátor tak mĤže definovat umístČní úložištČ uživatelských dat, defaultní nastavení pĜihlašovacích metod vþetnČ parametrĤ, parametry pro synchronizaci uživatelských úþtu a další potĜebná nastavení. ZmČna autentizace jednotlivých aplikací se provádí pomocí textových konfiguraþních souborĤ autentizaþní vrstvy PAM, uložených zpravidla v adresáĜi /etc/pam.d výmČnou dosavadního autentizaþního modulu za PAM modul Stadrin®.

13 Definice uživatelĤ a tokenĤ Poslední þinnost, která nás pĜi instalaci a konfiguraci þeká, je import uživatelĤ a definic tokenĤ do databáze a jejich vzájemné pĜiĜazení. Pokud již máme v systému založeny uživatelské úþty mĤžeme je snadno naimportovat. V subsystému je možno definovati i uživatelé kteĜí nejsou vedeni jako systémoví, pĜedevším pak z dĤvodu možnosti autentizovat aplikaþní vrstvy jako je Apache, Tomcat apod. Databáze tokenĤ je plnČna z definiþních souborĤ, dodávaných spoleþnČ s tokeny, avšak z dĤvodu bezpeþnosti jinou transportní trasou. Úlohou administrátora je pĜiĜadit uživatelĤm tokeny a zajistit jejich distribuci. Zcela však odpadá password management.

14 ZávČr Stadrin® je velmi kvalitní a snadno použitelný nástroj pro zvýšení zabezpeþení systémĤ, jeho místo je tam, kde statická hesla nezajišĢují dostateþnou ochranu pĜed neautorizovaným pĜístupem. Autentizace jednorázovými hesly se dĜíve používala zejména v bankovních a finanþních institucích, kde jsou kladeny vysoké nároky na bezpeþnost, nyní však je tato metoda dostupná pro široké použití bez omezení. 186


Managed Security Services Tomáš Mezník [email protected] www.netguard.cz Bezpeþnost je slovo skloĖované dnes a dennČ ve všech pádech a v nejrĤznČjších souvislostech. Je to nutné, protože rizik a hrozeb na nás v kybernetickém prostoru þíhá opravdu požehnanČ. Kvalitní zabezpeþení informaþních systémĤ je tak otázkou pro zdatné profesionály. Tito jsou ale zpravidla drazí, nedostatkoví a kromČ zajištČní kontinuálního provozu jsou zapotĜebí nárazovČ. NicménČ i tak je možné zajistit bezpeþnost s vynaložením rozumných prostĜedkĤ a za pĜijatelných podmínek. ěešení se jmenuje Managed Security Services (dále jen MSS).

1 Popis služby MSS PĜedevším je zapotĜebí zdĤraznit, že MSS je právČ služba – nikoliv specializovaný produkt. V zásadČ se jedná o pĜenechání starostí a péþe o þást informaþní bezpeþnosti specializované firmČ. Jedná se tedy o formu outsourcingu. NicménČ nejde o þistý outsourcing, protože služba není implementována ve formČ „zadej a zapomeĖ“, ale zadavatel v jejím rámci získává nejen jistotu zabezpeþení, nýbrž také informace o stavu bezpeþnosti v rámci lokální sítČ a možnost sledovat její aktuální stav. Cílem služby je pĜevzít každodenní rutinní starosti o zajištČní bezpeþného provozu sítČ, dále pak nárazové aktivity v dobČ zvýšených nárokĤ (epidemie internetových þervĤ, velké DoS útoky þi další podobná rizika) a pĜedevším trvalé monitorování stavu bezpeþnosti a jeho Ĝízení. Služba má za cíl provádČt dohled a správu bezpeþnostních prvkĤ jako jsou firewally, antivirové programy, VPN, systémy detekce prĤniku host-based þi network-based apod. Služba MSS tedy pĜenáší – v oblasti bezpeþnosti monitoring, Ĝízení a odpovídající reakce (tedy zodpovČdnost za tyto þinnosti) – na externí tým profesionálĤ s tím, že ponechává interním pracovníkĤm dostateþný prostor volnosti a navíc jim dává celou Ĝadu hodnotných informací.

2 Výhody služeb MSS Oproti Ĝešení problematiky informaþní bezpeþnosti takĜíkajíc „svépomocí“ má využití služby MSS pro zadavatele nČkolik nezanedbatelných výhod: x

Odpadají starosti o každodenní rutinní zajišĢování informaþní bezpeþnosti.

x

Zadavatel získává jistotu, že o jeho zabezpeþení je postaráno 365x7x24 (365 dní v roce, 7 dní v týdnu, 24 hodin dennČ), což se interními silami zajišĢuje opravdu velmi obtížnČ.

x

Zadavatel se nemusí zabývat Ĝešením problémĤ v oblasti, která není jeho hlavním oborem – díky MSS se mĤže soustĜedit na vlastní obor þinnosti a celou problematiku informaþní bezpeþnosti mĤže pustit z hlavy.

x

Informaþní bezpeþnost není omezena nebo ohrožena odchody klíþových pracovníkĤ, neschopenkami þi jinými podobnými potížemi s tzv. „lidským faktorem“.

x

MSS jsou poskytovány na bázi Service Level Agreement (SLA), kterými se dodavatel zavazuje k dodržování smluvené úrovnČ poskytovaných služeb. MSS tak garantují pĜenos zodpovČdnosti na externího poskytovatele.

x

Na základČ svého zadání nebo požadovaného balíþku služeb získává zadavatel pĜesný pĜehled o aktuálním stavu informaþní bezpeþnosti v podobČ a formátu, které si vyžádá.

x

Zadavatel mĤže operativnČ dle aktuální situace (rozvoj firmy, zĜizování nových poboþek apod.) pružnČ mČnit své požadavky.

x

Zadavatel má jistotu, že se obrací na skuteþné profesionály, kteĜí se plnČ vČnují dané problematice.


187

x

Využití externích služeb výraznČ redukuje bezpeþnostní rizika, protože se snižuje hrozba opomenutí, pĜehlédnutí þi jednostranného pohledu.

x

Každý zásah do systému je možné monitorovat a srovnávat se stav pĜed zásahem a po nČm.

x

Cena za využití služby MSS je vždy nižší, než když problematiku informaþní bezpeþnosti Ĝešíte vlastními silami.

UpozorĖujeme, že služba MSS není jen pro velké spoleþnosti, ale také pro malé firmy, instituce nebo organizace, které potĜebují Ĝešit otázku informaþní bezpeþnosti, ale které si nemohou dovolit vlastní oddČlení nebo pracov-níka informaþní bezpeþnosti.

3 Pod praporem Symantecu V ýeské a Slovenské republice poskytuje jako první služby MSS spoleþnost NetGuard, a.s. (www.netguard.cz). Tato využívá vlastní dohledové centrum v kombinaci s osvČdþeným Ĝešením MSS od spoleþnosti Symantec, která je celosvČtovým lídrem v oblasti informaþní bezpeþnosti. Instalace MSS probíhá v závislosti na zvolené úrovni vybraných služeb a v závislosti na zvláštnostech infrastruktury zadavatele buć on-site (na místČ), nebo remote (vzdálenČ). ObČma zpĤsoby je možné instalovat následující služby: x

Monitored Firewall Service;

x

Monitored Host-Based IDS Service;

x

Monitored Network-Based IDS Service;

x

Monitored Internet Security Appliance Service;

x

Monitored and Managed Firewall Service;

x

Monitored and Managed Network-Based IDS Service;

x

Monitored and Managed Internet Security Appliance Service;

x

Managed Security Compliance Service;

x

Managed Internet Vulnerability Assessment Service.

Souþástí dodávaných MSS je také systém reakce na incidenty a vþasné výstrahy. Okamžitá reakce mĤže mít napĜíklad podobu zablokování nČkterých nebezpeþných pĜíloh v pĜípadČ virových epidemií, a to až do okamžiku vydání aktualizaþních ĜetČzcĤ. Vþasná výstraha v rámci systému Program for Global Notification on Emerging Threats pak pĜedstavuje varování na novČ objevené nebo vznikající hrozby. Toto je velmi dĤležitá souþást služby, protože pĜináší varování ve svČtČ, kdy o vzniku kalamity nebo velkého útoku (a o tom, zdali bude þi nebude úspČšný – stejnČ jako odpovČć na nČj) rozhodují minuty. Zadavatel má u Symantec MSS znaþnou svobodu volby, protože má možnost vybrat si z nČkterého z pĜedpĜipravených balíþkĤ služeb nebo si nechat vytvoĜit informaþní bezpeþnost „na míru“. Má také možnost využít celou paletu služeb MSS nebo jen jejich urþitou þást (kterou není schopen zajistit jinak, kterou považuje za klíþovou apod.). Díky rozhraní Secure Internet Interface (možnost použití v jakémkoliv prohlížeþi podporujícím 128bitové šifrování a java-skriptování) má zadavatel možnost sledovat v reálném þase stav bezpeþnosti a okamžité dopady prĤbČžnČ pĜijímaných opatĜení na ni. Krom výše uvedených všeobecných pĜedností MSS získává zadavatel se Symantec MSS ještČ následující výhody:

188

x

Stabilitu organizace, která je kótována na americké burze (NASDAQ: SYMC) a která dlouhodobČ vykazuje rĤst i finanþní zdraví.

x

Kredit, který Symantec dlouhodobČ a opakovanČ prokazuje na poli informaþní bezpeþnosti.

x

Technologický náskok pĜed konkurencí.


x

Díky lokální podpoĜe spoleþnosti NetGuard a.s. komplexní nabídku Ĝešení i služeb a zkušenosti v nejrĤznČjších oborech informaþní bezpeþnosti.

UpozorĖujeme ještČ, že aþ je MSS spoleþnosti NetGuard a.s. postavena na Ĝešení Symantec, jedná se o platformovČ nezávislou službu schopnou zajistit provoz Ĝešení od všech významnČjších svČtových dodavatelĤ. Jinými slovy: její implementace nemá na chod organizace žádný dramatický vliv.

4 PĜíklad: MSS a firewall K nejžádanČjším a nejvyužívanČjším službám z portfolia MSS patĜí Monitored/Monitored and Managed Firewall Services (monitorování nebo monitorování a správa firewallu). Je urþena pro každého, kdo si uvČdomuje, že firewall nestaþí pouze mít a používat, ale také prĤbČžnČ monitorovat, jím získaná data zpracovávat a analyzovat. A v neposlední ĜadČ pak na zjištČné skuteþnosti reagovat. Režim Monitored Firewall Services je urþen pro každého, kdo hledá výhody konstantního monitorování firewallu v reálném þase, ale z jakéhokoliv dĤvodu si chce ponechat kontrolu nad konfigurováním bezpeþnostních prvkĤ. Služba Monitored and Managed Firewall Services je pak urþena všem, kdo hodlají využít v plné míĜe služeb profesionálĤ a kdo se nechtČjí správČ bezpeþnostních prvkĤ vČnovat. V obou režimech je každopádnČ provádČna nepĜetržitá analýza incidentĤ i možných incidentĤ v reálném þase s cílem rozpoznat i nejsofistikovanČjší hackerské útoky. KromČ toho zadavatel získává možnost vzdálené konfigurace a zmČn pravidel stejnČ jako zmČn ve VPN þi systémovou i softwarovou podporu. Navíc získává pĜístup k Secure Internet Interface, kde mĤže v reálném þase sledovat stav bezpeþnosti. V pĜípadČ, že služba detekuje ohrožení, zákazník je upozornČn a NetGuard a.s. spolupracuje se zákazníkem na nápravČ problému. Aktivní zása-hy do konfigurace, aktualizace SW zaĜízení atd. provádí dle dohodnuté úrovnČ poskytované služby buć sám zadavatel, anebo firma NetGuard.


189

190


PĜípadová studie Ĝešení bezpeþnosti informaþního systému Ing. František Nemochovský [email protected] Unisys s.r.o. Italská 35, 120 00 Praha 2

1 Úvod ěešení bezpeþnosti by mČlo být nedílnou souþástí všech informaþních systémĤ, a to jak v podnikatelské sféĜe, tak i ve státní správČ. Stav v oblasti bezpeþnosti informaþních technologií se pokusil opakovanČ zmapovat prĤzkum stavu informaþní bezpeþnosti v ýeské republice, zpracovaný spoleþností Price Waterhouse Coopers za podpory Národního bezpeþnostního úĜadu a þasopisu Data Security Management. Výsledky tČchto prĤzkumĤ nebyly pĜíliš optimistické, i když ukázaly urþitý kladný posun. PĜesto však celkový stav Ĝešení bezpeþnosti informaþních technologií nelze považovat za uspokojivý. ObecnČ lze konstatovat, že ve vČtšinČ provozovaných informaþních systémĤ je implementována Ĝada bezpeþnostních opatĜení, jako jsou napĜíklad identifikace a autentizace uživatelĤ, antivirová ochrana, vytváĜení záloh, ochrana pĜed prĤnikem do systému z jeho okolí a další. Ve vČtšinČ pĜípadĤ však implementovaná bezpeþnostní opatĜení nepokrývají všechny související oblasti a Ĝešení bezpeþnosti nenaplĖuje všechna doporuþení norem na Ĝešení bezpeþnosti informaþních systémĤ. Pro Ĝadu informaþních systémĤ není zpracována bezpeþnostní politika nebo nebyla zpracována analýza rizik jako východiska pro Ĝešení bezpeþnosti informaþního systému.

2 Výchozí podmínky pro Ĝešení bezpeþnosti x

spoleþnost XXX je vzhledem k pĜedmČtu svého podnikání významnou souþástí ekonomické infrastruktury státu,

x

informaþní systém spoleþnosti XXX poskytuje informaþní podporu klíþovým procesĤm souvisejícím s hlavním pĜedmČtem jejího podnikání,

x

ztráta informaþní podpory klíþových procesĤ nebo únik citlivých informací z informaþního systému mohou vážnČ ohrozit podnikatelské aktivity a majetek spoleþnosti,

x

v informaþním systému spoleþnosti XXX byla implementována Ĝada bezpeþnostních opatĜení, jejichž cílem bylo zajistit dĤvČrnost a integritu informací a dostupnost služeb informaþního systému pro jeho uživatele,

x

doposud realizované Ĝešení bezpeþnosti však v plném rozsahu nenaplĖuje požadavky platné legislativy a norem v oblasti bezpeþnosti informaþních technologií,

x

provoz informaþního systému spoleþnosti XXX zabezpeþuje na smluvním základČ externí firma,

x

v informaþním systému spoleþnosti XXX nejsou zpracovávány utajované skuteþnosti, z tohoto dĤvodu nebylo nutné na Ĝešení bezpeþnosti aplikovat požadavky zákona þíslo 148/1998 Sb. o ochranČ utajovaných skuteþností,

x

výbČr dodavatele Ĝešení nepodléhal zákonu þíslo 40/2004 Sb. o veĜejných zakázkách,

x

v rámci spoleþnosti XXX nebyla definována struktura Ĝízení bezpeþnosti v rámci informaþního systému,

x

spoleþnost XXX nemá vlastní specialisty na Ĝešení bezpeþnosti informaþních technologií,

x

ve spoleþnosti XXX je na velmi dobré úrovni propracován systém vydávání, schvalování a distribuce interních firemních normativĤ,

x

Ĝešení bezpeþnosti informaþního systému mČlo podporu vedení spoleþnosti.


191

3 PrĤbČh Ĝešení bezpeþnosti informaþního systému Zahájení Ĝešení

3.1

Spoleþnost XXX se obrátila na firmu Unisys s žádostí o poskytnutí odborných služeb pĜi Ĝešení bezpeþnosti jejího informaþního systému. Firma Unisys doporuþila spoleþnosti XXX Ĝešit bezpeþnost jejího informaþního systému systémovČ, což v praxi znamenalo, že Ĝešení bezpeþnosti musí: x

být Ĝízeným procesem,

x

naplnit požadavky platné legislativy,

x

být v souladu s doporuþeními platných norem.

x

probíhat po jednotlivých etapách životního cyklu,

x

zahrnout i další související oblasti.

Vzhledem k rozsahu Ĝešení firma Unisys doporuþila spoleþnosti XXX zahájit Ĝešení bezpeþnosti jejího informaþního systému zpracováním studie proveditelnosti systémového Ĝešení, jejímž hlavním cílem bylo: x

zhodnocení stávajícího stavu Ĝešení bezpeþnosti informaþního systému jako východiska pro další Ĝešení bezpeþnosti,

x

ochrana investic již vložených do Ĝešení bezpeþnosti,

x

definování strategického cíle v oblasti bezpeþnosti informaþního systému,

x

návrh krokĤ vedoucích k dosažení definovaného strategického cíle,

x

definování zdrojĤ nutných pro dosažení definovaného strategického cíle,

x

zpracování a zhodnocení možných variant Ĝešení,

x

vytvoĜení kvalifikovaných podkladĤ pro strategické rozhodnutí managementu organizace o dalším Ĝešení bezpeþnosti informaþního systému.

Obr 1: Grafické znázornČní významu studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX

192


Forma spolupráce Ĝešitele a zadavatele

3.2

ěešitelem studie proveditelnosti systémového Ĝešení bezpeþnosti byla firma Unisys. K jejímu zpracování za svoji stranu spoleþnost XXX jmenovala vedoucího projektu, v jehož pĤsobnosti bylo zajistit i potĜebné kapacity specialistĤ spoleþnosti XXX, nezbytné ke zpracování úvodní studie. PĜed zahájením prací na studii proveditelnosti systémového Ĝešení bezpeþnosti byly definovány následující formy spolupráce: x

hodnocení stávajícího stavu Ĝešení bezpeþnosti probíhalo formou interview s tím, že hodnotitel vyžadoval od spoleþnosti XXX doložení nČkterých uvádČných skuteþností,

x

pĜed zpracováním jednotlivých tematických blokĤ studie se uskuteþnil workshop, na kterém specialisté firmy Unisys požadovali od zástupcĤ spoleþnosti XXX zodpovČzení otázek vztahujících se k Ĝešení tematického bloku a jejich eventuální prodiskutování,

x

specialisté firmy Unisys následnČ zpracovali tematický blok samostatnČ (s obþasnými operativními dotazy),

x

zpracovaný tematický blok byl pĜedán spoleþnosti XXX k pĜipomínkovému Ĝízení,

x

na závČr byla studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému oponována spoleþností XXX jako celek.

Lze konstatovat, že se tato forma spolupráce v praxi velmi osvČdþila, vedla k zapojení zástupcĤ spoleþnosti XXX do Ĝešení a ke zkrácení þasu, nezbytného ke zpracování studie.

Obsah studie proveditelnosti systémového Ĝešení bezpeþnosti

3.3

Studii proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX zpracoval Ĝešitelský tým specialistĤ Unisys s následujícím základním obsahem: x

výchozí stav pro další Ĝešení bezpeþnosti, -

zhodnocení souþasného stavu,

-

identifikace již implementovaných bezpeþnostních opatĜení,

x

návrh cílĤ v oblasti bezpeþnosti informaþního systému,

x

definování krokĤ vedoucích k dosažení cílĤ,

x

x

x

-

životní cyklus Ĝešení bezpeþnosti,

-

základní cíl a obsah prací každé etapy životního cyklu,

analýza variant Ĝešení, -

základní návrh obsahu služeb systémové integrace Ĝešení,

-

varianty zpĤsobu zajištČní služeb systémové integrace,

zdroje nezbytné k dosažení cílĤ, -

legislativa,

-

normy pro Ĝešení bezpeþnosti,

-

lidské zdroje,

-

þasové zdroje,

-

finanþní zdroje,

doporuþení a zdĤvodnČní varianty Ĝešení.


193

3.4

Další postup prací

Studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX: x

prošla interním pĜipomínkovým Ĝízením ve spoleþnosti XXX,

x

byla schválena pĜíslušníkem managementu spoleþnosti s potĜebnou schvalovací pravomocí,

x

v souþasné dobČ probíhá Ĝešení podle doporuþení studie Ĝešením první etapy životního cyklu, to je zpracováním bezpeþnostní politiky.

4 ZávČr Lze konstatovat, že zpracovaná studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX splnila své cíle, neboĢ: x

hodnocení stávajícího stavu konstatovalo, že dĤvČrnost a integrita informací spolu s dostupností služeb sytému jsou na urþité úrovni zabezpeþeny, tuto úroveĖ je však tĜeba zvýšit pĜedevším v oblasti splnČní doporuþení platných norem,

x

management spoleþnosti se ztotožnil s návrhem cílĤ v oblasti bezpeþnosti informaþního systému a doporuþenou variantou Ĝešení,

x

schválením studie proveditelnosti se management spoleþnosti XXX zavázal vyþlenit potĜebné zdroje pro navržené Ĝešení.

Analogický postup lze doporuþit i pro Ĝešení bezpeþnosti u obdobných informaþních systémĤ z následujících dĤvodĤ:

194

x

zpracování studie (aĢ již vlastními silami nebo specialisty externí firmy) není þasovČ ani finanþnČ pĜíliš nároþné,

x

již na poþátku Ĝešení je definován strategický cíl, ke kterému bude Ĝešení smČĜovat,

x

definování požadavkĤ na zdroje nezbytné k dosažení cíle na poþátku Ĝešení umožní analýzu, zda je v podmínkách organizace reálné je vyþlenit,

x

schválením studie se management organizace zavazuje vytvoĜit podmínky a vyþlenit zdroje nezbytné pro další Ĝešení,

x

další Ĝešení bezpeþnosti informaþního sytému podle navržených etap Ĝešení mĤže být sice v þase rozloženo podle dostupnosti pĜedevším finanþních prostĜedkĤ, bude však stále smČĜovat k dosažení definovaných cílĤ v oblasti bezpeþnosti informaþního systému.


Computer Associates CZ, s.r.o. Pob ežní 3, Praha 8

Recommend Documents