Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Implementace bezpečnostního standardu pro platební karty Diplomová práce
Autor:
Bc. Martin Měšťák, DiS. Informační technologie a management
Vedoucí:
Praha
Ing. Marcela Soldánová
Duben 2013
Prohlášení: Prohlašuji, ţe jsem tuto diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Jesenici u Prahy dne 15. dubna 2013
Martin Měšťák
Poděkování: Rád bych na tomto místě poděkoval vedoucí této diplomové práce paní Ing. Marcele Soldánové za vstřícný přístup a velmi konstruktivní připomínky. Dále děkuji mé rodině za trpělivost a podporu během celého mého studia.
Anotace Tato diplomová práce se zaměřuje na odvětví platebních karet, které aktuálně prochází prudkým rozvojem. Přes karetní systémy protékají miliardy korun ročně a platební karty pomalu a jistě nahrazují klasické metody hotovostních plateb. Objevují se nové technologie pro akceptaci platebních karet, které vyuţívají obchodníci pro zefektivnění svého byznysu a udrţení si konkurenceschopnosti. Tento bouřlivý rozvoj sebou ale přináší bezpečnostní hrozby a rizika, kterým se organizace pracující s platebními kartami snaţí čelit. Hlavním nástrojem pro sniţování těchto rizik v odvětví platebních karet je bezpečnostní standard pro platební karty PCI DSS, jehoţ implementace je ústředním tématem této práce. Vlastní obsah práce je rozdělen do 6 hlavních kapitol. První dvě kapitoly jsou pojaty popisně a jejich účelem je čitateli popsat problematiku bezpečnosti dle PCI DSS. Následující 4 kapitoly pojímám realizačně s důrazem kladeným na modelové příklady. Celá práce je prakticky orientovaná a můţe být nápomocná specialistům informační bezpečnosti nebo projektovým manaţerům při zajišťování souladu organizace s PCI DSS. Pro účely této práce jsem zvolil specifický přístup doporučení, jak by se dle mého nejlepšího vědomí mělo postupovat v cestě zajištění souladu s PCI DSS. Za dobu své praxe v odvětví platebních karet jsem viděl, zaţil a konzultoval více způsobů, jak stanovit co moţná nejefektivnější cestu dosaţení souladu s tímto standardem. Ve všech případech se jevilo uchopení této cesty formou projektu jako nejvhodnější. Zajištění souladu s PCI DSS projektovou formou tedy volím i pro tuto práci, nicméně zmiňuji pouze nutné projektové minimum tak, aby nedošlo k odsunu hlavního záměru práce do pozadí. Klíčová slova Informační bezpečnost, PCI DSS, bezpečnostní rámce, rozdělení karetních dat, kompenzační opatření, projekt, GAP analýza, analýza rizik, implementace poţadavků, udrţování bezpečnosti.
Annotation This graduation thesis is intended for the payment card industry, which is currently experiencing significant growth. Billions are running through payment card systems annually and payment cards are slowly but surely replacing classical methods of cash payments. New technologies for payment card acceptance are about to appear and are being used by merchants to make their businesses more effective and maintain competitive strength. This new developments also bring security threats and risks which put pressure on organisations involved in the payment card processing. The main tool for mitigating these risks is Payment Card Industry Data Security Standard (PCI DSS), the implementation of which is the focal point of this thesis. The body of this thesis is divided into six main chapters. The first two chapters are informational and their goal is to provide the reader with a description of information security according to PCI DSS. The next four chapters are practical and especially focused on the implementation to model samples. The whole thesis is practically oriented and it is conducive to both information security specialists and project managers in ensuring compliance with PCI DSS in their organizations. I have specifically tailored recommendations for the purposes of this thesis to provide best way to ensure compliance with PCI DSS. During my employment in payment card industry, I gained experience which allows me to determine the most effective way to achieve PCI DSS compliance. While there are many ways to become compliant with PCI DSS, I concluded the project way as the most effective. For the purposes of this thesis I have selected compliance with PCI DSS via the project way and summarized only the important points of the project methodology in order to prevent a deflexion from the main subject of the thesis. Key words Information security, PCI DSS, security frames, card data diversification, compensation controls, project, GAP analysis, risk analysis, implementation of requirements, security maintenance.
Obsah Úvod ........................................................................................................................................... 7 Zvolené metody zpracování ................................................................................................... 11 1 Legislativní a regulatorní rámce bezpečnosti .................................................................. 13 2 Problematika PCI DSS....................................................................................................... 17 2.1 Rozdělení karetních dat .................................................................................................. 18 2.2 Kompenzační opatření .................................................................................................... 19 3 PCI DSS projekt ................................................................................................................. 21 3.1 Projektový workshop ...................................................................................................... 21 3.2 Stanovení rozsahu projektu ............................................................................................ 23 3.2.1 Nástroje pro redukci scope ....................................................................................... 25 3.2.2 Demonstrace na modelových příkladech .................................................................. 29 4 Analytická fáze projektu .................................................................................................... 35 4.1 Cíle gap analýzy ............................................................................................................. 36 4.2 Plán nápravných opatření ............................................................................................... 37 4.3 Provedení analýzy rizik .................................................................................................. 37 5 Implementační fáze projektu............................................................................................. 42 5.1 Vybudování a udrţování bezpečné sítě .......................................................................... 43 5.2 Ochrana dat drţitelů karet .............................................................................................. 47 5.3 Vedení programu zranitelnosti ....................................................................................... 51 5.4 Zavedení důkladných opatření pro kontroly přístupů..................................................... 55 5.5 Pravidelné monitorování a testování infrastruktury ....................................................... 60 5.6 Udrţování pravidel informační bezpečnosti ................................................................... 64 5.7 Implementační roadmapa ............................................................................................... 66 6 Finalizace projektu ............................................................................................................. 68 6.1 Prokázání souladu s PCI DSS......................................................................................... 68 6.2 Formální ukončení projektu ........................................................................................... 70 6.3 Udrţování souladu s PCI DSS ........................................................................................ 71 Závěr ........................................................................................................................................ 73 Seznam použité literatury ...................................................................................................... 76 Seznam použitých tabulek, obrázků, diagramů .................................................................. 78 Seznam použitých zkratek ..................................................................................................... 79
6
Úvod Kybernetické podvody společně s krádeţemi identity jsou problémy, které kaţdým rokem ve světě narůstají. Je ironií, ţe věci, které mají náš ţivot učinit jednodušším a zlepšit naší produktivitu, zároveň způsobují, ţe je zločin rovněţ jednodušší a pohodlnější. Kriminálníci se stali technicky zdatnými a objevili moţnosti získání značného mnoţství peněz za
cenu
nízkého
rizika
odhalení.
Neautorizovaný
průnik
do
firemní
databáze
nebo phishingový útok (např. kdyţ se útočník snaţí získat citlivé údaje nebo hesla k systémovým účtům) z pohodlí domova je v mnoha ohledech přitaţlivější, neţ přepadení banky či obchodu, kde zároveň hrozí, ţe bude někdo zraněn či dokonce zabit. Vezmeme-li v úvahu typ napadené instituce, důmyslnost útoků a v neposlední řadě i štěstí, pak takový kybernetický útok můţe být mnohonásobně lukrativnější neţ ono vyloupení banky. Důsledkem toho můţe být zcizení hotovosti nebo citlivých informací, které mohou mít pro instituci strategický význam. Ţijeme v době, kdy lidé a instituce stále více vyuţívají informační technologie pro řízení svého obchodu a zároveň ukládají stále větší mnoţství informací. To je důvod, proč je nyní důleţitější víc neţ kdy předtím učinit správné kroky k zavedení funkčních procesů informační bezpečnosti. Informační bezpečnost nepředstavuje nic jiného, neţ soubor nejlepších praktik a oborově přijatých pravidel (sociálních, technických a procesních), jak sníţit rizika spojená s neoprávněným zacházením nebo zneuţitím citlivých informací. Pokud jsou tyto informace nezabezpečené, nastane jejich únik a následné zneuţití, pak je to vţdy pro jednotlivce, instituci, ale i ekonomiku obecně špatná zpráva. Probíhající ekonomická krize způsobila, ţe se instituce začaly více zaobírat bezpečností svých dat. Jedním z těchto důsledků byla a stále jsou vysoká rizika v oblasti řízení citlivých informací. Jak je známo, většina institucí se za účelem překonání této nesnadné ekonomické doby uchýlila k finančním škrtům a rozpočtovým omezením. Na druhou stranu tyto instituce začaly více investovat do bezpečnostních kontrol a zavádění opatření, která by jim pomohla sníţit rizika výskytu bezpečnostních incidentů nad citlivými daty.
7
Tato cesta má určitě smysl a svojí důleţitost, neboť instituce nečelí pouze rostoucímu objemu kybernetických útoků zvenčí, ale i neustále se proměňujícímu se ekonomickému prostředí a masovému propouštění, které u zaměstnanců vyvolává pocit nejistoty. Tato nejistota má za následek např. vynášení celých databází citlivých dat nebo pokusy o narušení bezpečnosti instituce. Jsou to právě interní zaměstnanci, zejména experti a administrátoři citlivých systémů, kteří představují jednu z největších bezpečnostních hrozeb. V případě, ţe tito zaměstnanci nejsou profesně uspokojeni nebo dojde k jejich propuštění, např. z důvodu finančních úspor, pak by instituce měla počítat se zvýšeným rizikem moţných bezpečnostních incidentů. Zoufalí lidé dělají zoufalé věci a tak případný dopad incidentů spáchaných ať uţ stávajícími nebo bývalými zaměstnanci bývá zpravidla velmi významný. Toto je jedna ze stránek probíhající ekonomické krize, které se dotýkají pole informační bezpečnosti. Mohl bych zde uvést více příkladů, jak vysoká je hodnota funkční informační bezpečnosti v neklidných ekonomických dobách, nicméně toto není předmětem této diplomové práce. V odvětví platebních karet jsou podvody a datové úniky často zaměřené na informace o platebních kartách zákazníků a tím je ohroţena reputace celého odvětví. Dle poslední zprávy1 Evropské komise, týkajícího se podvodů na poli bezhotovostního platebního styku, dosahují ztráty způsobené podvody s platebními kartami v eurozóně aţ do výše 1 miliardy EUR. V ročním horizontu tyto podvody zasahují přibliţně 500 000 obchodníků jeţ akceptují platební karty (dále jen „obchodníci“). Toto je hlavním důvodem, proč se karetní společnosti Visa, Mastercard, American Express, Dinners Club a Japan Credit Bureau (dále jen „asociace“) spojily za účelem vytvoření jednotného bezpečnostního standardu pro platební karty (dále jen „PCI DSS2“). Odvětví platebních karet v podstatě podniklo proaktivní krok k udrţení víry veřejnosti v bezpečnost platebních karet, jakoţto důvěryhodných platebních prostředků. Na internetu nalezneme velké mnoţství zpráv, grafů a studií, které se zabývají bezpečností v odvětví platebních karet. V odborných kruzích asi nejznámější studií a zároveň
1 2
Zdroj: ec.europa.eu/internal_market/payments/docs/fraud/implementation_report_en.pdf [cit. 30.6.2012]. Payment Card Industry Data Security Standard (Bezpečnostní standard v odvětví platebních karet).
8
nejcitovanější je „PCI DSS Compliance Trends Study3“, kterou od roku 2007 vydává americký nezávislý institut Ponemon. V této studii jsou detailně srovnávány různé faktory ovlivňující bezpečnost citlivých dat o platebních kartách (dále jen „karetní data“). Takřka ve všech těchto dosud vydaných ročenkách se dozvíme o narůstajícím počtu incidentů spojených s bezpečností platebních karet. To není věc nijak nová, nicméně stejně důleţitá jsou uvedená fakta o niţším podílu těchto incidentů u institucí4, které dosáhly souladu s poţadavky PCI DSS. Pokud si vezmeme k ruce poslední vydání z roku 2011, pak zde čísla hovoří následovně: 64% ze všech oslovených institucí uvedly, ţe za uplynulý rok u nich nevznikl ţádný takový incident. Tyto instituce byly v souladu s PCI DSS. Naopak u institucí, které nedosáhly souladu s PCI DSS, byla tato procentuální část značně niţší, celkově 38%. Nejen tyto, ale i další statistiky v odvětví platebních karet jasně dokládají důleţitost implementace bezpečnostních pravidel dle PCI DSS. Soulad s PCI DSS je často zaměňován s pojmem „PCI Compliance“. Tento pojem se vryl do paměti odborné veřejnosti a jeho podstata je často zaměňována. PCI compliance představuje soulad se všemi bezpečnostními standardy v odvětví platebních karet. Kromě PCI DSS existují i další bezpečnostní standardy, např. pro platební aplikace nebo pro zařízení pracující s PIN. Důvodem, proč se na tyto standardy ve své práci nezaměřuji je, ţe z PCI DSS vycházejí. Mým záměrem je čitateli poskytnout co moţná nejvíce přidané hodnoty ve smyslu mých doporučení pro implementaci. Z tohoto důvodu volím právě PCI DSS, které zastřešuje veškeré aspekty informační bezpečnosti nad oblastí karetních dat. Hlavním cílem této práce je poskytnout praktická doporučení, jak projektovou cestou zajistit soulad s PCI DSS. Ačkoliv je dosaţení souladu s PCI DSS povinné pro všechny instituce, které pracují s karetními daty, rozhodl jsem doporučení v této práci demonstrovat na modelových případech obchodníků. Pro tento účel jsem vybral dva typy obchodníků dle úrovňového rozdělení asociací (viz příloha č. 1). Jako prvního obchodníka jsem zvolil obchodní řetězec, který je typicky obchodníkem nejvyšší úrovně 1 a vyniká sloţitou infrastrukturou s velkým mnoţstvím procesů. Jako druhého obchodníka jsem zvolil hotel. Hotely ve většině případů spadají do nejniţší úrovně 4 a z pohledu datových toků mají méně komplikovanou infrastrukturu. Nicméně se jedná o nejvíce rizikovou skupinu obchodníků 3
Zdroj: https://www.imperva.com/lg/lgw.asp?pid=440 [cit. 30.6.2012]. Zpracovatelské banky, obchodníci a další poskytovatelé sluţeb, kteří zpracovávají, ukládají nebo přenášejí karetní data. 4
9
s vysokým počtem případů úniku karetních dat. Z pohledu implementace poţadavků PCI DSS je přístup k tomuto typu obchodníků odlišný, kdy se bezpečnostní poţadavky zajišťují v jiném pořadí. Tato práce pracuje s některými obecně známými pojmy (jako je šifrování nebo PIN), které jiţ nejsou dále rozepisovány. Předpokladem je, ţe čtenář bude disponovat vyšší mírou informační gramotnosti. Zároveň konstatuji, ţe v práci je pouţito velké mnoţství odborných termínů, které pro lepší přehlednost rovněţ zmiňuji v kapitole Seznam pouţitých zkratek. V naší ani ve světové literatuře není mnoho titulů, které by se speciálně zabývaly problematikou PCI DSS. To je důvodem menšího mnoţství pouţité literatury pro tvorbu této práce. Tuto skutečnost se snaţím kompenzovat doporučeními z vlastní praxe.
10
Zvolené metody zpracování Z pohledu zpracování bylo mým záměrem zvolit co moţná nejjednodušší formu podání popisované problematiky. Snahou bylo psát tuto práci populárně a čtivě, coţ v některých pasáţích nebylo vzhledem ke sloţitosti problematiky dost dobře moţné. V práci je primárně zacíleno na realizační přístup vycházející z praktického poznání popisované problematiky. V první kapitole blíţe představuji oblast legislativního a regulatorního rámce popisované oblasti, tj. informační bezpečnosti. V druhé kapitole uvádím základní informace a pojmy, které jsou s hlavní popisovanou problematikou spojené. U těchto dvou kapitol byla zvolena čistě popisná forma zpracování. Důvodem pro tento výběr byl záměr předat čitateli základní informace o problematice bezpečnosti, které jsou třeba objasnit před započetím čtení odborných kapitol. V kapitolách 3 a 5 představuji projekt, jehoţ cílem je provedení analytických a implementačních aktivit směrem k zajištění bezpečnosti dle PCI DSS. Pro tyto kapitoly byl zvolen realizační přístup při vyuţití dvou obecných metod zpracování: - analýza - rozkládám celek zkoumané oblasti na jednotlivé části tak, aby hlubší poznání částí a vazeb umoţnilo celek lépe poznat. Metodu analýzy pouţívám u kapitol č. 4.1 a č. 4.3; - syntéza - vyuţívám tuto metodu v kapitole č. 5 ve smyslu slučování jednotlivých poţadavků PCI DSS a oblastí implementace do jednoho celku. Při zpracování a řešení dané problematiky u dalších kapitol jsem vyuţil metod abstrakce, indukce, komparace a dedukce. Analýza, jakoţto nejpouţívanější metoda zpracování této práce předpokládá, ţe v kaţdé zkoumané oblasti je určitý systém a platí určité zákonitosti. Cílem analýzy je pak tento systém, jeho jednotlivé prvky a jejich vzájemné vazby poznat a odhalit principy jeho fungování. Induktivní úsudky pouţívané v této diplomové práci umoţňují dojít k podstatě popisované problematiky, stanovit zákonitosti, které umoţňují formulaci obecnějších závěrů platných pro popisovanou oblast. Od obecnějších tvrzení, závěrů a soudů přecházím k méně obecným pomocí dedukční metody. Abstrakce, jako myšlenkové oddělení nepodstatných vlastností jevu od podstatných, umoţňuje zjistit vlastnosti a vztahy v oblasti informační bezpečnosti dle PCI DSS. Obsahem této práce je i komparativní analýza dvou typů vybraných obchodníků, která se zaměřuje na klíčové
11
aspekty implementace jednotlivých poţadavků PCI DSS. Hlavním kritériem při tomto srovnání je odlišnost infrastruktury a procesů. Druhým kritériem je náchylnost obchodníka k případným útokům na karetní data, kdy hotely obecně představují nejrizikovější skupinu obchodníků s častými případy úniků karetních dat. Celkově tato diplomová práce popisuje tři úrovně kaskádovitého přístupu. V první úrovni popisuji projekt. Ve druhé úrovni pokračuji popisem metod zajištění souladu s PCI DSS na úrovni projektu. Poslední úroveň se zaměřuje na detailní popis implementace na modelových příkladech.
12
1 Legislativní a regulatorní rámce bezpečnosti Ještě předtím, neţli se v této práci začnu zabývat problematikou PCI DSS, povaţuji za důleţité zmínit, jak je pole informační bezpečnosti (zejména v oblasti platebního styku) legislativně a regulativně upravováno. Rozhodl jsem se proto věnovat první kapitolu této práce
právě
této
oblasti,
a
to
hned
ze
dvou
důvodů.
Prvním
důvodem
je, ţe tato problematika je ve svojí podstatě příliš konkrétní na to, aby mohla být začleněna do úvodní kapitoly. Druhým a důleţitějším důvodem je, ţe zákony a regulatorní normy jsou pomyslným vrcholem ledovce, od kterého se odvíjí samotné poţadavky na zkvalitnění procesů informační bezpečnosti. Tudíţ je vhodné čtenáři přiblíţit tuto oblast dříve, neţ bychom se zaměřili na konkrétní regulatorní normu, kterou je v našem případě PCI DSS. Legislativní rámce: Z českého právního řádu bych v prvé řadě uvedl zákon č. 40/2009 Sb., trestní zákoník, který v §234 a §236 stanovuje, co představuje neoprávněné opatření elektronického platebního prostředku či jeho padělání. Dále zde máme zákon č. 229/2002 Sb., o finančním arbitrovi, který hraje významnou roli ve věci ochrany spotřebitele a nový zákon o platebním styku č. 284/2009 Sb., který zavádí zvýšenou odpovědnost poskytovatele elektronického platebního prostředku za neautorizovanou5 transakci. U tohoto zákona nastal významný posun ve spoluúčasti drţitele platebního prostředku, který za neautorizovanou transakci odpovídá pouze do výše 150 eur, zbytek hradí banka. Nesmí se však jednat o podvodné jednání či nedbalost drţitele platebního prostředku, jako např. pozdní oznámení ztráty či odcizení platební karty, aj. Pokud hovoříme o české legislativě zasahující pole informační bezpečnosti, pak zmíním dva stěţejní zákony. Prvním je zákon č. 101/2000 Sb., o ochraně osobních údajů. Tento zákon je zaměřený na ochranu osobních údajů občanů České republiky proti jejich zneuţití či neoprávněné manipulaci v rámci jejich sběru a zpracování. Dohledem nad dodrţováním tohoto zákona je pověřen Úřad pro ochranu osobních údajů, který byl pro plnění tohoto zákona zřízen. Hlavním úkolem dohledových nástrojů tohoto úřadu je monitoring a zajištění dodrţování tohoto zákona fyzickými a právnickými osobami. V praxi to můţe představovat různé formy auditních kontrol datových přenosů, zpracování osobních dat a způsob, 5
Autorizace představuje proces ověření, zda konkrétní platební karta není stoplistovaná a zda je kryta dostatečnými finančními prostředky na bankovním účtu.
13
jak je s nimi manipulováno. Tyto aktivity by měly probíhat pouze v rozsahu, na který byl dán vlastníkem údajů souhlas a zároveň za předem dohodnutým účelem. Druhým je zákon č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti. Tento zákon upravuje podmínky přístupu fyzické osoby k utajovaným informacím dle jejich předchozí klasifikace. Tato klasifikace se dělí do 4 stupňů: vyhrazené, důvěrné, tajné a přísně tajné. Pro stupeň utajení „vyhrazené“ zaměstnavatel ověřuje u fyzické osoby zletilost, způsobilost k právním úkonům a trestní bezúhonnost. Významu dalších stupňů utajení potom odpovídá i rozsah úkonů v řízení prováděném Národním bezpečnostním úřadem. Nakonec nelze nezmínit nový zákon o trestní odpovědnosti právnických osob č. 418/2011 Sb., o trestní odpovědnosti právnických osob a řízení proti nim platný od 1.2.2012. Jeho účel je postihovat kriminální jednání právnických osob, a to i za předpokladu, ţe se nezjistí, která konkrétní osoba se trestného činu dopustila. Dále dosáhnout na majetky právnických osob získaných trestnou činností a jejich postih za jednání osob pro ní pracujících. Jako preventivní opatření k naplnění podstaty tohoto zákona lze uvaţovat nad: - zavedením dostatečných interních kontrolních mechanismů na všech zaměstnaneckých úrovních instituce, které budou důsledně dodrţovány. Tyto kontrolní mechanismy by měly být systematicky a pravidelně kontrolovány; - vykonáváním veškerých činností instituce pouze kvalifikovanými zaměstnanci s odpovídajícími znalostmi a zkušenostmi, coţ klade velké nároky na personální nábor. Regulatorní rámce: V případě regulací záleţí na typu podnikatelské činnosti, kterou ta či ona konkrétní instituce provozuje. Mezi nejznámější regulatorní normy související s informační bezpečností patří: - SOX (Sarbanes Oxley) - norma, která se zabývá průhledností finančních a účetních informací. Stanovuje poţadavky na způsob jejich zaznamenávání, monitorování a zveřejňování. V USA je tato norma ukotvena v právním řádu; - HIPPA (Health Instance Portability and Accountability Act) - norma, která upravuje podmínky pro přenos a uchovávání osobních údajů ve zdravotnictví. HIPPA má dvě
14
části, z nichţ zejména část druhá má za cíl zajistit bezpečný přenos a ukládání citlivých dat o pacientech. V USA je tato norma rovněţ ukotvena v právním řádu. - ISO/IEC 17799 - technická norma doporučující nejlepší praktiky v řízení informační bezpečnosti a zároveň definuje konkrétní opatření pro její zajištění. - ISO/IEC 27001 - tato norma představuje řídící rámec pro zajištění bezpečnosti jakoţto kontinuálního procesu řízení rizik nad konkrétními citlivými informacemi. Zároveň poskytuje metodický rámec pro řízení informační bezpečnosti a definuje procesy výběru vhodných bezpečnostních opatření. - BS 7799-3 - britská norma, která definuje veškeré aspekty související s řízením informačních rizik. Nicméně je prokázáno na neustále se zvyšujícím počtu úniku citlivých informací, ţe velké mnoţství institucí je nečinných nebo neúspěšných v zavádění těchto norem a z nich vycházejících adekvátních bezpečnostních opatření. Předpokládám, ţe si kaţdý z nás dokáţe udělat představu nad významem slova „zabezpečit“. Zabezpečujeme systémy, zkvalitňujeme kontrolní procesy, abychom tak sníţili riziko úniku nebo zneuţití aktiva6.
Mnoho institucí však spoléhá na regulatorní normy v domnění,
ţe řešení poţadavků z nich vycházejících jim bezpečnost zajistí. Jejich zájem bývá typicky zaměřen na to, jak projít auditem7 nebo assessmentem8, aby tak vyhověly poţadavkům regulátora. Pokud u nich k útoku dojde, pak je jejich častou reakcí věta „Jak jsme mohli být napadeni, kdyţ jsme v souladu s tou či onou bezpečnostní normou?“. Proto je důleţité si uvědomit, ţe zajištění souladu s regulatorními normami nám samotnou bezpečnost nezajistí. V procesu řízení informační bezpečnosti nám tento soulad představuje sice nezbytný krok, ale zdaleka ne postačující. V okamţiku posouzení prostředí s konkrétní regulatorní normou zjistíme, zda jsou procesy a bezpečnostní opatření nastaveny dle jejich poţadavků.
6
Cenné a strategické informace, databáze, sestavy dat, hardwarové komponenty, servery, pracovní stanice atd., které si díky své hodnotě zaslouţí přiměřený stupeň ochrany. Pro účely této práce budu hovořit pouze o citlivých datech jako aktivech. 7 Hlavním úkolem auditu informačního systému je porovnání reálné situace vůči situaci, která je poţadovaná bezpečnostní politikou nebo odvětvovou normou. 8 Prověření souladu instituce s konkrétní regulatorní normou dle předem definovaného rozsahu prověrky.
15
Nicméně informační bezpečnost je v první řadě kontinuální proces, který si klade za cíl kontinuální zlepšování celého systému. Tento cyklus je v kontextu informační bezpečnosti nazýván PDCA9. S ohledem na PDCA cyklus je stanovena metodika pro řízení bezpečnosti informací ISMS10, která je v základu posuzována vţdy podle tří základních hledisek: - dostupnosti - aby aktiva byla dostupná v případě potřeby; - důvěrnosti - aby aktiva byla přístupná pouze oprávněným osobám; - integrity - aby aktiva nebyla změněna nebo podvrţena. Z toho tedy lze usuzovat, ţe zneuţití aktiv není pouze otázkou jejich vyzrazení, ale rovněţ porušení integrity (data jsou neúplná nebo podvrţená) a dostupnosti (data, která jsou sice v pořádku, ale nelze se k nim z nějakého důvodu dostat). Ačkoliv PCI DSS, ale i SOX nebo HIPPA nejsou zákony, tak jsou v mnoha ohledech efektivnější. Je jasné, ţe nesoulad či nedodrţování těchto norem nezpůsobí uvěznění, nicméně můţe způsobit nemalé penalizace či ztrátu licence k provozování konkrétní činnosti. V případě PCI DSS, pokud by některým institucím byla odebrána licence na operace s platebními kartami z důvodu nezajištění souladu s tímto standardem, mohlo by to drasticky ovlivnit jejich podnikatelskou činnost. V krajních případech by se mohla i zvýšit míra rizika moţného bankrotu celé instituce.
9
Cyklus - Plánuj,dělej,kontroluj, jednej (Plan,Do,Check and Act). Information Security Management System (systém řízení bezpečnosti informací).
10
16
2 Problematika PCI DSS Kdyţ jsem se zamýšlel nad strukturou a dalším obsahem této práce, došel jsem k závěru, ţe druhou kapitolu bych měl věnovat obecným informacím o této problematice. Pokud bych tuto část vynechal, čtenář by nemusel správně pochopit podstatu některých pasáţí a mohl by být v uvedených zkratkách a pojmech ztracen. Uvádím tedy pouze popisné minimum, nezbytné pro potřeby čtenáře. Pokud by se čtenář chtěl dozvědět více o celé problematice, její historii či PCI bezpečnostních programech asociací, pak se odkazuji na svou bakalářskou práci s názvem Bezpečnostní standardy pro platební karty v kapitole Seznam pouţité literatury11. Bezpečnostní standard PCI DSS (Payment Card Industry Data Security Standard) představuje mezinárodní pravidla, jejichţ plnění je vyţadováno asociacemi. Vztahuje se na veškeré instituce, které zpracovávají nebo uchovávají karetní data. Tento standard institucím nabízí konkrétní řešení pro sniţování a minimalizaci informačních rizik nad oblastmi s karetními daty. Jako instituce, která manipuluje s karetními daty, si můţeme poloţit otázku „Proč máme řešit nějaké PCI DSS?“. Jednoduchou odpovědí bude, ţe je to vyţadováno. V případě, ţe soulad s tímto standardem nezajistíme, pak nám hrozí penalizace ze strany asociací. Pokud postmortem analýza12 ukáţe, ţe naše instituce byla v čase bezpečnostního incidentu v souladu s PCI DSS, pak asociace garantují tzv. „safe-harbor“13. Jakkoliv je vyvarování se penalizacím významné, tak stále největším plusem souladu s PCI DSS zůstává vědomí, ţe systémová/síťová IT infrastruktura (dále jen „infrastruktura) nad karetními daty a procesy spojenými s platebními kartami jsou bezpečné. Rovněţ i marketingové oddělení instituce ocení zajištění tohoto souladu, protoţe jméno instituce bude následně zveřejněno na webovém seznamu certifikovaných institucí kaţdé z asociací. V rámci propagace své instituce se na něj mohou odkazovat.
11
Zdroj: Měšťák, Martin. Bezpečnostní standardy v odvětví platebních karet [online]. Praha, 2011, 2012-12-09 [cit. 2012-12-09]. Dostupné z: http://is.bivs.cz/th/16539/bivs_b/. Bakalářská práce. Bankovní institut. 12 Analýza, která je prováděná po potvrzeném bezpečnostním incidentu, jejíţ výstupem je zpráva o incidentech. 13 Pojem vytvořený asociacemi, který garantuje, ţe asociace nebudou instituci postiţenou bezpečnostním incidentem penalizovat.
17
2.1 Rozdělení karetních dat Poţadavky
PCI
DSS
se
vztahují
na
veškeré
systémové
komponenty14,
které jsou implementovány nebo propojeny s prostředím karetních dat. Toto se typicky týká velkého mnoţství IT systémů v rámci cílového prostředí. Abychom byli schopni karetní data ochránit, je nejprve důleţité porozumět jejich rozdělení, a kde se nacházejí. PCI DSS rozeznává dvě skupiny karetních dat. První skupinou jsou data drţitelů karet, kde je ukládání povoleno za předpokladu, ţe jsou dodrţeny poţadavky PCI DSS třídy č. 315. Druhou skupinou jsou citlivá ověřovací data, jeţ představují kritické datové elementy a není povoleno jejich ukládání. Citlivá ověřovací data jsou pro útočníky velmi cenná, jelikoţ jim umoţňují generovat falešné platební karty a s jejich pomocí provádět podvodné transakce. Následuje tabulka č. 1, která obě skupiny karetních dat detailněji rozepisuje. Tabulka č. 1 - Skupiny karetních dat Data držitelů karet zahrnují
Citlivá ověřovací data zahrnují
Číslo karty (PAN)16
Data z magnetického proužku
Jméno držitele karty
CAV2/CVC2/CVV2/CID17
Servisní kód
PIN18
Datum expirace
PIN Blok
Zdroj: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml [cit. 20. 4. 2012].
PCI DSS se uplatňuje všude tam, kde se PAN zpracovává, uchovává nebo přenáší. PAN představuje určující faktor v aplikovatelnosti poţadavků PCI DSS. Pokud se PAN neukládá, nezpracovává nebo nepřenáší, pak se tyto poţadavky neuplatňují. Toto má svojí logiku a uvedu jednoduchý příklad. Podle tabulky č. 1 vidíme, ţe hodnota PIN patří do skupiny citlivých ověřovacích dat, tudíţ není povoleno jeho ukládání. Poloţme si otázku „k jakému účelu nám bude samotný PIN, pokud neznám číslo karty, ke které náleţí“? Odpovědí bude, ţe samotný PIN nemá pro útočníka ţádnou hodnotu, 14
Jakékoliv síťové zařízení, server nebo aplikace operující v prostředí, kde se pracuje s karetními daty. Poţadavky na ochranu uloţených dat drţitelů karet. 16 Primary Account Number (číslo platební karty). 17 CAV 2 (ověřovací hodnota platební karty pouţívaná JCB), CVC2 (ověřovací kód platební karty pouţívaný Mastercard), CVV2 (ověřovací hodnota karty pouţívaná Visa), CID (identifikační číslo karty pouţívané American Express). 18 Osobní identifikační číslo. 15
18
a tudíţ to není citlivý údaj. Citlivým údajem se PIN stává v momentě, kdy je asociován s PANem a je zde jistota, ţe se oba údaje váţí k jedné kartě. Toto byl pouze demonstrující příklad aplikovatelnosti PCI DSS na konkrétní datový element. Jiná situace by byla, kdyby PIN samotný byl uloţen v systémech. V tomto případě by jeho samotné
uloţení
rovněţ
nebylo
v rozporu
s PCI
DSS.
Nicméně
i tak bych doporučoval zabezpečit místo jeho uloţení, pokud by mezi servery obsahující PIN a PAN byla technická nebo personální (např. jeden administrátor s oprávněním přístupu k oběma serverům) vazba. Samozřejmě, ţe vţdy závisí na úhlu pohledu konkrétního auditora nebo hodnotitele bezpečnosti, zda a do jaké míry vezme ony logické vazby v potaz z pohledu míry rizika. Ačkoliv tabulka č. 1 určuje, jaká data se mohou ukládat a která nikoliv, doporučuji nejprve zváţit, zda karetní data vůbec ukládat. Pokud uţ data drţitelů karet ukládáme (z důvodu regulatorních, legislativních nebo obchodních), pak na začátek doporučuji provést analýzu jejich výskytu a následně zváţit moţnosti, jak jejich výskyt minimalizovat. Pokud se nám to podaří, můţeme tak významně sníţit finanční náklady potřebné na implementaci bezpečnostních opatření a zároveň sníţit míru rizika moţného úniku karetních dat. Další moţnost je outsourcing karetního zpracování nebo např. datových skladů s karetními daty na nějakého poskytovatele sluţeb. Implementační tým by tak měl zváţit, na straně jedné, náklady na tento outsourcing a na straně druhé, náklady na pořízení bezpečnostních opatření na místě. Pokud by byla zvolena forma outsourcingu, pak je vţdy důleţité mít na paměti, ţe vstup do vztahu s dodavatelem, který předem nedeklaruje soulad s PCI DSS, představuje značné riziko a jistý nesoulad s PCI DSS.
2.2 Kompenzační opatření Často nastane situace, ţe instituce nemůţe splnit konkrétní poţadavek PCI DSS z důvodů technických, procedurálních nebo legislativních. Za této situace můţe být zvaţováno tzv. kompenzační opatření. Kompenzační opatření mohou být vyuţita u většiny poţadavků PCI DSS s výjimkou poţadavku na neukládání citlivých ověřovacích dat po autorizaci. Primárně by takové opatření mělo vyhovovat náročnosti původního poţadavku a poskytovat obdobnou úroveň ochrany.
19
Je důleţité, aby veškerá pouţitá kompenzační opatření byla řádně zdokumentovaná, a to jak pro případ kontroly asociací, tak pro případ případné forenzní analýzy19. Efektivita kompenzačních opatření je závislá na specifikách prostředí, kde je opatření implementováno. Zde doporučuji mít na paměti, ţe ne kaţdé kompenzační opatření bude efektivní
v kaţdém
karetním
prostředí.
Vţdy
by
měla
předcházet
analýza,
zda je opatření vhodné a zároveň, zda jeho implementací sníţíme bezpečnostní riziko minimálně na stejnou úroveň původního poţadavku PCI DSS. Jako příklad mohu uvést poţadavek ukládat data drţitelů karet na zálohovací média v šifrované formě. Za předpokladu, ţe v našem prostředí není moţné šifrovat, a tedy dosáhnout naplnění tohoto poţadavku, mohu zvolit alternativní postup. Po analýze situace lze dojít k názoru, ţe vhodným kompenzačním opatřením můţe být např. uloţení zálohovacích médií do trezoru, ke kterému bude mít klíč pouze omezený okruh osob. Měním tedy způsob zabezpečení z logického na fyzický. To nám poskytne minimálně stejnou míru bezpečnosti, jako kdyby tato média byla volně přístupná, data na nich šifrovaná a šifrovací klíč20 pro dešifrování měl rovněţ omezený počet osob. V tomto bodě ukončuji popisnou část této práce tvořící potřebný základ pro pochopení následujících kapitol, které jiţ pojednávají o samotných realizačních aktivitách.
19
Forenzní analýza je investigativní postup pouţívaný k vyšetřování incidentů nad karetními daty, který si asociace mohou u zvláště závaţných incidentů vyţádat. 20 Informace, která určuje průběh šifrovacího algoritmu. Při šifrování, klíč specifikuje transformaci zprávy do šifrovaného textu, při dešifrování je tomu naopak.
20
3 PCI DSS projekt Jakýkoliv aspekt práce, který vyţaduje zdroje, čas či úsilí, by měl být zpracovaný ve formě projektu. Pokud bychom se za dosaţením souladu s PCI DSS vydali neprojektovou cestou, pak to můţe způsobit komplikace a hůř - následky na celý program řízení bezpečnosti dle PCI DSS.
Prvotní
zajištění
souladu
s PCI
DSS
není
moţno
chápat
jako
proces,
který by bylo moţné řídit „obchodně“. Tento úkol vyţaduje začlenění mnoha pracovních rolí z různých firemních úseků, a proto povaţuji jeho uchopení projektovou formou (zejména u větších institucí) jako nejvhodnější. Na začátku bychom si měli zajistit kvalifikovaného projektového manaţera, jehoţ hlavní úlohou bude dohlíţet nad celým projektem, který bude mít za cíl dosaţení souladu s PCI DSS (dále jen „PCI projekt“). Poté, co je projektový manaţer jmenován, měl by být jasně definován projektový plán (časování, kapacity a odhad nákladů). Jako první projektovou aktivitou by měl být projektový workshop.
3.1 Projektový workshop Zahajovacího projektového workshopu by se měl účastnit projektový manaţer, osoba zodpovědná za finanční krytí projektu, projektový tým, specialisti informační bezpečnosti a další IT pracovníci, kteří budou definovat hranice rozsahu cílového karetního prostředí.
Cíle projektu a zároveň i jeho plánované aktivity by měly být na tomto workshopu detailně diskutovány a schváleny. Zde uvádím stručný přehled agendy, jeţ by se měla na workshopu probrat: - způsob předávání informací mezi členy projektového týmu a nastavení pravidelných projektových schůzek; - vyjasnění a schválení cílů PCI projektu; - ujasnění povinností a projektových rolí; - kapacity členů týmu v MDs21;
21
ManDay (člověkoden) je pomyslná jednotka produkce. Je to práce, kterou můţe jeden člověk vykonat za jeden pracovní den.
21
- způsob výběru a definování výběrových kritérií pro QSA22 (za předpokladu, ţe je pro provedení assessmentu najmut); - schválení stupně informování vedení instituce (ve smyslu stanovení periodicity reportingu a svolávání řídící komise PCI projektu); - definování, kdo z projektového týmu se zúčastní assessmentu a v jaké míře; - získání potvrzení, ţe bude dodrţen doporučení postup implementace (viz kapitola č. 4.1) během celého implementačního cyklu. Po ukončení zahajovacího workshopu (moţno chápat jako projektový „kickoff“23) by projektový manaţer měl shromáţdit získané informace a přenést je do „zahajovacího dokumentu projektu24“. Zahajovací dokument projektu bude slouţit pro informační podporu PCI projektu v rámci všech jeho fází a zároveň bude podkladem pro jednání řídících a schvalovacích komisí instituce. Tento dokument by měl minimálně obsahovat následující kategorie: - profil projektu; - cíl projektu; - projektové role včetně kapacit v MDs; - eskalační a schvalovací procedury projektu; - dodávky projektu; - projektový a časový plán projektu; - benefity a rizika projektu; - popis interních a externích dodávek; - poţadované zdroje a finanční náročnost projektu;
22
Qualified Security Assessor - auditor, který je certifikovaný na provádění PCI DSS assessmentu. Úvodní projektová schůzka která zaručuje, ţe projekt startuje v kontrolované a organizované podobě. 24 Vzorovou šablonu zahajovacího dokumentu projektu lze např. zde: http://www.berr.gov.uk/files/file42722.doc [cit. 20. 6. 2012]. 23
22
získat
- mechanismy zjišťování kvality projektu. Tyto aspekty by měly být v zahajovacím dokumentu projektu popsány do takové míry detailu, aby kaţdý z projektového týmu měl jasnou představu o své roli a zodpovědnostech. Ideální je pro tento účel pouţít tzv. RACI25 tabulku, kterou mohu z mé vlastní praxe doporučit.
3.2 Stanovení rozsahu projektu Jakmile počáteční workshop proběhl, tak by projektový tým měl mít základní orientaci v problematice a cílech projektu. Dalším krokem bude jednoznačné stanovení rozsahu projektu, které je přímo úměrné stanovení rozsahu prostředí, jehoţ soulad budeme oproti PCI DSS posuzovat. Většina institucí „bojuje“ uţ s tímto druhým krokem, tj. identifikovat, kde přesně a v jakých systémech se karetní data nacházejí. Pro rozsah posuzovaného prostředí se v odvětví platebních karet ujal pojem „scope26“, který budu pro účely této práce pouţívat. Správné stanovení scopu karetního prostředí je věcí zcela zásadní. Od něho se budou odvozovat veškeré projektové dodávky a pouze tato definovaná část bude porovnávána oproti poţadavkům PCI DSS. Toto jsou důvody, proč by měl projektový manaţer v druhé fázi svolat další workshop s příslušnými specialisty, ve kterém se jasně stanoví hranice scopu, vztahy s dodavateli a další závislosti. Lze konstatovat, ţe v rámci běhu projektu se můţe scope měnit, nicméně pokud se na něj na začátku projektu dostatečně zaměříme, pak se v budoucnu dají očekávat pouze menší odchylky. Samozřejmě se stanovením scopu jsou spjatá i rizika, která nelze dopředu odhadnout. Hovořím např. o změně nařízení asociací, legislativních změnách, úpravách znění PCI standardů, apod. Toto vše můţe v budoucnu nějakým způsobem scope ovlivnit a tím i výši finančních nákladů potřebných pro zajištění dodávek. Přejděme nyní k samotnému stanovení scopu našeho karetního prostředí. Jak jiţ bylo řečeno, soulad s PCI DSS je vyţadován všude, kde se pracuje minimálně s PAN. To se týká všech 25
Jedná se o jednoduchý nástroj pouţívaný k identifikaci a individuální zodpovědnosti za konkrétní aktivitu v rámci projektu. „R“ značí kdo danou činnost vykonává. „A“ značí kdo nese za splnění odpovědnost. „C“ značí s kým je třeba konzultovat. „I“ koho je třeba informovat. Vzorovou šablonu RACI tabulky lze získat např. zde: http://racichart.org/wp-content/uploads/2012/04/RACI-Template.xlsx [cit. 20. 6. 2012]. 26 Rozsah vymezení veškerých míst, systémů a procesů, kde se pracuje s karetními daty. S tím souvisí i moţná identifikace všech externích dodavatelů, kteří mají přístup ke karetním datům instituce nebo mohou ohrozit jejich bezpečnost.
23
počítačových systémů, aplikací, serverů a síťových zařízení, které se přímo podílejí na karetním zpracování. Zároveň můţeme hovořit o jednotlivých obchodních procesech, funkcích a vztazích s dodavateli. Dodavatele není třeba do scopu přímo zahrnovat (pokud dodavatel nesdílí část infrastruktury posuzované instituce), nicméně je potřeba smluvní cestou zajistit jejich hmotnou a finanční odpovědnost za bezpečnost karetních dat. Jako příklad mohu uvést např. externí společnost, která provádí vzdálenou údrţbu našeho kritického systému27 s karetními daty nebo společnost, která provádí fyzickou likvidaci duplicitní dokumentace obsahující PAN. V kaţdém případě je třeba zanalyzovat, zda neexistují dodavatelé, kteří by měli k našim karetním datům přístup, či by mohli v rámci smluvních dodávek ovlivnit jejich bezpečnost. Prostředí karetních dat lze primárně charakterizovat jako část infrastruktury instituce, přes kterou putují data drţitelů karet nebo citlivá ověřovací data. K prvkům infrastruktury patří switche28, firewally29, routery30, bezdrátové AP31, IDS/ISP32 a další bezpečnostní zařízení. Do kategorie serverů spadají webservery, souborové servery, aplikační servery, log servery, databázové servery a mailové servery. Aplikacemi se rozumí veškeré aplikace pracující s karetními daty, které jsou dodané, instalované a podporované poskytovateli sluţeb. Abychom měli maximální přehled o rozsahu toků karetních dat, navrhuji provést následující kroky: - ve spolupráci s IT architekty identifikovat a zdokumentovat veškerý výskyt karetních dat v našich systémech. Současně s tím ověřit, ţe se ţádná karetní data nenacházejí mimo definované prostředí naší instituce, kde se ukládají, zpracovávají nebo přenášejí karetní data (dále jen “karetní prostředí“). - do scope zahrnout veškerá karetní data v našem karetním prostředí do chvíle, neţ jsou outsourcována, znehodnocena nebo smazána.
27
Systémy, které představují strategická aktiva instituce nebo se prostřednictvím nich zpracovává, ukládá či přenáší velké mnoţství citlivých dat. 28 Síťové prvky, které propojují jednotlivé síťové segmenty. 29 Síťové zařízení, které zabezpečuje síťový provoz a definuje pravidla pro komunikaci mezi sítěmi. 30 Síťové prvky, které přeposílají datové pakety (bloky dat) ke konkrétnímu cíli. 31 Access Point (přístupový bod výchozí bezdrátové komunikace). 32 Intrusion Detection/Protection System (systém detekce narušení).
24
- uchovat veškerou dokumentaci a výsledky prokazující, ţe scope byl kvalifikovanou osobou (např. QSA) schválen a lze se na ně při příštích assessmentech odkazovat. - ve chvíli, kdy jsou veškerá umístění karetních dat známa, pouţít výsledky k ověření, ţe scope je odpovídající. Výsledkem toho by měly být diagramy toků karetních dat v infrastruktuře a dále diagram procesů nad karetními daty.
3.2.1 Nástroje pro redukci scope Uţ ve fázi stanovení rozsahu je vhodné uvaţovat o jeho moţné redukci. Vhodným doporučením pro tuto redukci jsou dvě techniky - síťová segmentace a tokenizace. Nejedná se přímo o poţadavky PCI DSS, ale jsou to techniky umístěné na nejvyšším stupni tzv. nejlepších praktik pro efektivní dosaţení souladu s tímto standardem. Síťová segmentace: Obecně lze konstatovat, ţe síťovou segmentací izolujeme karetní systémy od zbytku sítě. Na níţe uvedeném obrázku č. 1 demonstruji příklad cíleného izolování systémů, které pracují s karetními daty do menšího síťového perimetru. Oddělíme tak síťové prostředí, v němţ se zpracovávají karetní data od zbytku okolní sítě. Takto se lze vyvarovat principu tzv. „olejové skvrny“. Olejová skvrna trefně naznačuje, ţe vše, co není segmentováno od něčeho, co je v rozsahu, tak do něj automaticky spadá. Bez odpovídající segmentace sítě je předmětem hodnocení souladu s PCI DSS celá síť, a to i včetně systémů, které s karetními daty přímo nepracují. Vhodnou segmentací tak můţeme docílit sníţení: - rozsahu hodnocení shody s PCI DSS; - nákladů a problémů souvisejících s realizací a udrţováním kontrolních opatření dle PCI DSS; - rizik pro naší instituci (ve smyslu konsolidace karetního prostředí do menších, snázeji kontrolovanějších úseků).
25
Obrázek č. 1 - Příklad segmentování sítě PŘED SEGMENTACÍ SÍTĚ
Internet Mobilní uživatelé
Všechny stanice a bezdrátové sítě jsou v rozsahu požadavků PCI DSS
Router
Bezdrátový Přístupový bod (AP)
Uživatelské stanice
Firewall
Veškeré systémy „otevřené“ do veřejných sítí jsou v rozsahu požadavků PCI DSS
Webserver
Organizační LAN
Všechny servery jsou v rozsahu požadavků PCI DSS
E-mailový server
Databázový server Aplikační server
Korporátní servery
Auditní log server
E-commerce Databázový server E-commerce server
PO SEGMENTACI SÍTĚ
Internet
Všechny stanice které přistupují ke karetním datům jsou v rozsahu požadavků PCI DSS
Pokud nejsou karetní data přítomna v bezdrátovém perimetru, pak je tento perimetr mimo rozsah PCI DSS.
Mobilní uživatelé Router Bezdrátový Přístupový bod (AP)
Veškeré systémy „otevřené“ do veřejných sítí jsou v rozsahu požadavků PCI DSS
Firewall
Uživatelské stanice
Webserver
Routery
Organizační LAN
E-mailový server Korporátní servery
PCI DSS LAN
Databázový server Aplikační server
Auditní log server
Zdroj: vlastní tvorba.
26
E-commerce Databázový server E-commerce server
Všechny systémy ukládající nebo zpracovávající karetní data jsou v rozsahu požadavků PCI DSS
Rozhodnutí pro řešení síťové segmentace a její návrh by měl být v kaţdém případě diskutován se síťovými inţenýry, kteří by měli být nezbytnou součástí projektového týmu. Tito odborníci jsou schopni navrhnout logický model síťového rozdělení, který se uskutečňuje nastavením hardwarových firewallů a routerů se silnou přístupovou kontrolou. Vytvoření síťového diagramu nám v kaţdém případě pomůţe plně pochopit efektivnost příslušné síťové segmentace z hlediska izolace karetního prostředí.
Tokenizace: Jako další nástroj pro redukci rozsahu PCI DSS můţeme hovořit o tzv. tokenizaci. Tokenizace je proces, kdy dochází k nahrazení PANu náhodně vygenerovanou dynamickou hodnotou, tzv. tokenem. De-tokenizace je zase opačný proces obnovující PAN ze sdruţeného tokenu na základě poţadavku oprávněné osoby. Bezpečnost kaţdého tokenu spoléhá výhradně na nemoţnosti odvodit původní PAN. Obrázek č. 2 - Příklad řešení tokenizace PŘED TOKENIZACÍ
PANy
PANy
Platební terminál
Platební aplikace
PANy
Databázový server
PANy
Uživatelské aplikace
- v rozsahu PCI DSS Uživatelské aplikace
PO TOKENIZACI
PANy
Tokeny
Platební terminál
Platební aplikace PANy
Tokeny
Databázový server
Tokeny Uživatelské aplikace
Tokeny - v rozsahu PCI DSS Uživatelské aplikace
Tokenizační server
Zdroj: vlastní tvorba.
27
- mimo rozsah PCI DSS
Výše uvedený obrázek č. 2 přibliţuje tokenizační proces. PANy jsou vţdy izolovány v jednom bezpečném systému a do okolního síťového prostředí jsou vysílány uţ jen tokeny, které nemají citlivou povahu. Přínosy tokenizace jsou jednoznačně ve sníţení počtu systémů, kam PANy putují, coţ má za následek významné sníţení moţnosti úniku karetních dat. Následující principy souvisejí s vyuţitím tokenizace a její vztah k PCI DSS: - tokenizační řešení nám nenahradí poţadavek na řešení a dodrţování poţadavků PCI DSS, pouze redukuje rozsah karetního prostředí. - velmi důleţitá je kontrola efektivnosti tokenizačního řešení. Vţdy bychom se měli ujistit, ţe získání nebo rekonstrukce PANu ze systémů (které jsme díky aplikaci tokenizačního řešení vyčlenili mimo rozsah) není moţné. - tokenizační systémy bychom měly zabezpečit prostřednictvím silných přístupových kontrol a pravidelně funkčnost těchto kontrol monitorovat. Před samotným výběrem tokenizačního řešení doporučuji provést finanční vyhodnocení a analýzu rizik nad karetní oblastí, jejíţ výsledky by měly představovat podklad pro rozhodnutí o případné implementaci (detailněji se analýze rizik věnuji v kapitole č. 4.3). U finančního vyhodnocení je cílem získat jistotu, ţe implementací tohoto řešení skutečně náklady sníţíme. Na jedné straně porovnáváme výši nákladů za implementaci tokenizačního řešení oproti výši nákladů za implementaci standardních bezpečnostních opatření dle PCI DSS. Na straně druhé porovnáváme odhad nákladů na jejich provoz a údrţbu. Po vyhodnocení analýzy rizik bychom měli získat ujištění, ţe pravděpodobnost hrozby moţného napadení karetních dat v uvaţované oblasti je vysoká, stejně tak případný finanční dopad incidentu. Ať uţ se jedná o segmentaci nebo o tokenizaci, pro redukci scope je důleţitým předpokladem jasně porozumět potřebám samotného karetního zpracování. Omezení přístupu ke karetním datům vlivem segmentace nebo eliminaci jejich nadbytečnosti v ostatních systémech můţe mít za následek změnu dlouhodobých provozních a obchodních praktik. Toto je dobré
28
mít na paměti před tím, neţ budeme vůbec nad podobným řešením uvaţovat. Doporučuji předem přikročit k analýze moţných dopadů takovéto implementace do provozních a obchodních procesů.
3.2.2 Demonstrace na modelových příkladech Jiţ v úvodní kapitole jsem zmínil, ţe se kromě obecných doporučení pro implementaci zaměřím i na konkrétní demonstraci na dvou typech obchodníků. V této kapitole si představme konkrétní stanovení scope, jehoţ výstupem bude síťový a procesní diagram. Na oba
tyto
diagramy
se
budu
v dalších
částech
této
práce
odkazovat,
stejně tak, jako by to měla dělat instituce při implementaci poţadavků PCI DSS. Obchodní řetězec: Model obchodního řetězce má strukturu několika menších maloobchodních prodejen, dvou velkých supermarketů a jednoho e-commerce33 portálu. Ze síťového pohledu evidujeme plochou síť34 s několika typy komunikačních linek dle výše uvedených typů poboček. Obrázek č. 3 - Síťový diagram obchodního řetězce A
B
Minimarkety 1
C
D
E
Supermarkety
Webhosting
Samoobslužné terminály
POS terminály
POS terminály
Webserver
2
VSAT modem PBX PSTN ADSL modem
Router
3
Satelite HUB
Firewall
Kancelářské PC
4
Privátní linka O2
Podniková LAN
VSAT
Internet
5
Notebook - office
Souborový server
3D Secure server
Autorizační centrum
Zdroj: Vlastní tvorba. 33 34
Internetová akceptace platebních karet zaloţena na řešení 3-D Secure. V síťovém perimetru, přes který putují karetní data není pouţitá ţádná síťová segmentace.
29
Síťový diagram na obrázku č. 3 představuje finální stanovení scope u obchodního řetězce, kde byla odstíněna okolní infrastruktura, přes kterou se karetní data nezpracovávají. Vzhledem k tomu, ţe detailnější srovnání jednotlivých částí infrastruktury oproti PCI DSS bude provedeno v dalších kapitolách práce, představme si nyní tuto infrastrukturu pouze obecně. Maloobchodní prodejny jsou umístěné v oblastech, kde je celkově problém zajistit datovou konektivitu pro platební terminály, které zajišťují akceptaci platebních karet (dále jen „POS“). Proto byl zvolen způsob spojení POS na autorizační centrum prostřednictvím satelitního připojení. Samoobsluţné terminály pouţité v supermarketech vyuţívají komutované linky (vytáčeného spojení) a transakční tok obsahující karetní data putuje přes privátní linku od společnosti O2. Naopak POS jsou připojeny do veřejné sítě, resp. do internetu. Nakonec zde máme ecommerce platební portál, kde si zákazníci mohou objednat zboţí online. Tento portál je umístěn na vzdáleném hostingu35 u externí společnosti. Komunikace mezi webovým portálem a 3D-Secure serverem v autorizačním centru probíhá standardně přes internet. Nicméně uţ jen z principu e-commerce se obchodník do styku s karetními daty klientů vůbec nedostane. Z webového portálu je klient přesměrován na 3D-Secure server autorizačního centra, kde teprve tam zadává údaje o své platební kartě. Obecně se od ecommerce platebních řešení očekává vysoký stupeň zabezpečení proti krádeţi peněţních prostředků a podvodům různého druhu36. Celkově jsou tedy terminály jediným místem interakce s karetními daty ve fyzické formě u obchodního řetězce. Jak jiţ bylo zmíněno, PCI DSS se zaměřuje na veškeré aspekty bezpečnosti karetních dat, tedy i provozní a personální. Poté, co byl definován síťový rozsah, je třeba stanovit rozsah provozní. Vycházejme ze síťového diagramu a u veškerých systémů na něm zobrazených si identifikujme procesy viz dále uvedený procesní diagram (obrázek č. 4). Zajímají nás samozřejmě pouze ty procesy, které mohou mít dopad do bezpečnosti karetních dat. 35
Sluţba, kterou si klient pronajímá „vlastní místo na internetu“, za účelem provozování svých stránek, elektronického úloţiště, atd. 36
Zdroj: Suchánek Petr. E-commerce, vyd. Express : 2012. ISBN: 978-80-86929-84-2.
30
Obrázek č. 4 - procesní diagram obchodního řetězce A
1
B
C
D
Minimarkety
E
Supermarkety Prodej
Prodej
2
Recepce
Internet
3
Fyzické dokumenty + účtenky z terminálů
4
5
Autorizační centrum
Zdroj: Vlastní tvorba.
V prvé řadě se jedná o obsluhu POS v maloobchodních prodejnách a supermarketech. POS po provedené transakci tisknou dva typy účtenek. První účtenka je pro klienta, kde je PAN zkrácený (je vytištěno pouze prvních šest a poslední čtyři číslice z PANu) a dle PCI DSS není třeba jí proto zabezpečovat. Druhá účtenka obsahuje PAN v plném tvaru a je poţadavkem zpracovatelské
banky
tyto
účtenky
uchovávat
pro
účely
případných
reklamací.
U maloobchodních prodejen jsou ukládány v zamykatelných skříních a v supermarketech v trezorech. Hotel: Model infrastruktury hotelu jsem se snaţil v maximální míře přiblíţit skutečnosti. V zásadě zde máme dvě části, kamennou (pobočkovou) a online. Zatímco kamenná část má dvě provozovny osazené POS terminály a jedním recepčním systémem, část online je osazena pouze webovým serverem pro provozování online booking systému. Celkově tu tedy máme dva rezervační systémy, kde je mezi nimi následující rozdíl:
31
- online booking systém - přijímá objednávky klientů z internetu. Klient je s vystavením konkrétní objednávky poptáván o zadání údajů o své platební kartě. Následně po vystavení objednávky putují veškerá osobní a karetní data do recepčního systému hotelu. - recepční systém hotelu - řídí prodej hotelových kapacit na místě a na online rezervačním systému. Přijímá a řídí objednávky hostů a uchovává veškeré údaje o klientech po dobu nezbytně nutnou pro vyřízení objednávky. Obrázek č. 5 - Síťový diagram hotelu A
B
Webhosting
C
D
E
IT Servisní organizace
Podniková síť Recepční PC
1 Webserver
Recepční PC
Recepční PC
Support PC POS terminál
RDP
2
POS terminál
POS terminál
Podniková LAN
Tcp/IP
Internet POS terminál
3
Notebook - office
ADSL Autorizační centrum
Firewall
Router/AP (NAT)
Recepční PC
Microsoft SBS 2011 + Exchange
Zdroj: Vlastní tvorba.
Jak je patrné z výše uvedeného síťového diagramu (obrázek č. 5), kamenná část hotelu obsahuje jednu lokální síť, do které je kromě POS terminálů zapojen i recepční systém. POS terminály komunikují s autorizačním centrem prostřednictvím internetu. Recepční systém je provozován na Microsoft SBS37 serveru, který mimojiné zastává funkci emailového serveru. Lokální síť je otevřená do internetu pouze na jednom místě, a to na straně routeru, který jako jediný má veřejnou IP adresu38. Ta je přidělena na venkovní rozhraní routeru
37
Microsoft Windows Small Business Server 2011 - Systém navrţený pro potřeby a finanční moţnosti malých firem. Představuje dostupné řešení typu „vše v jednom“, které pomáhá zajistit efektivnější chod instituce. Nabízí pokročilé funkce pro správu sítě a emailového serveru. Dále pak podporuje databáze, vzdálenou správu, sdílení souborů a tiskáren. 38 IP (Internet protokol) - Unikátní číslo identifikující počítač v počítačové síti. Rozeznáváme interní (vnitřní) IP adresu a veřejnou IP adresu. Rozdíl mezi nimi je ten, ţe vnitřní IP je určena pro lokální PC v lokální síti. Naopak veřejná IP je dostupná z celého internetu.
32
a počítače v podnikové síti jsou skryty za jeho NATem39. Router rovněţ vyuţívá funkci AP40, na který se bezdrátově připojuje notebook manaţera hotelu. Správu celé infrastruktury provádí IT servisní organizace buď na místě, nebo vzdáleně prostřednictvím RDP41. Na druhé straně zde máme online booking systém, který je umístěn na webovském serveru externího hostingu. Komunikace s recepčním systémem probíhá přes internet. Jeho správu a vývoj provádí sama hostingová společnost. Obrázek č. 6 - Procesní diagram hotelu A
B
C
D
1
E
Obsluha recepce
Externí správci sítě
Obsluha recepce
Trezor s účtenkami
2
Internet
Obsluha recepce
Manažer hotelu
3
Autorizační centrum
Router/AP (NAT)
Rezervační systém/ e-mailový / souborový server
Zdroj: Vlastní tvorba.
Z procesního pohledu (obrázek č. 6 výše) jsou prvotní místa interakce opět POS a pak sám online booking systém. Účtenky z POS existují podobně jako u obchodního řetězce ve dvou variantách. Varianta účtenky, obsahující plný PAN se ukládá v trezoru obsluhou recepce vţdy po ukončení směny. Online booking systém odesílá karetní data do recepčního systému, který je uchovává po dobu trvání objednávky a pobytu klienta. Recepční systém je chráněn definicí přístupů v několika rovinách pravomocí a hesly pracovníků hotelu. Nicméně z provozních důvodů ve své databázi uchovává karetní data.
39
Network Address Translation - Překladač IP adres. Pouţívá se z důvodů omezení potřebného počtu veřejných IP adres a k zajištění bezpečnosti komunikace mezi veřejnou (internetem) a vnitřní sítí. 40 Access Point - Přístupový bod k bezdrátové síti Wi-Fi (Wireless-Fidelity), ke kterému se klienti bezdrátově připojují. 41 Remote Desktop Protokol - Protokol, který umoţňuje ovládat počítač vzdálenou cestou prostřednictvím připojení k jeho desktop prostředí.
33
V případě ukládání PAN si hotel vyhrazuje právo jej uchovat pro účely např. pro pozdější náhrady škody za poškození vybavení hotelu. Hotel v případě rezervace prostřednictvím online booking systému pouţívá tzv. ruční vstup na POS. Princip ručního vstupu je v přímém vkládání karetních dat do POS bez fyzické existence karty. Zde je bohuţel běţnou praxí, ţe pracovníci recepce bezprostředně po provedeném ručním vstupu neodstraňují CAV2/CVC2/CVV2/CID z recepčního systému.
34
4 Analytická fáze projektu Za analytickou fázi projektu lze povaţovat provedení tzv. Gap (nebo také diferenční) analýzy. Gap analýza je charakteristická shromaţďováním informací na základě kontrol existujících politik, pohovorů s projektovými specialisty a technickým zhodnocením systémů, které zahrnuje: - síťové komponenty, jako jsou firewally, switche, routery, bezdrátové AP a další síťové bezpečnostní zařízení; - webové, databázové, autentifikační, DNS42, mailové, proxy 43a NTP44 servery; - veškeré aplikace, které pracují s karetními daty, vč. Interních a externích webových aplikací. Tato analýza se samozřejmě zaměřuje i na stávající obchodní procesy a na jejich soulad s PCI DSS, konkrétně s třídami č. 9 aţ 12 (viz kapitoly č. 5.4 a č. 5.6). Pohovory zasahující tuto oblast by měly být vedeny s pracovníky, kteří jsou za procesy přímo zodpovědní. V případě našich modelových případů se jedná o obsluhu recepce hotelu nebo o prodavače obsluhující POS terminály, příp. managementem (smlouvy s dodavateli aj.). Během gap analýzy vychází QSA nebo specialista zodpovědný za provedení PCI DSS assessmentu (dále jen „hodnotitel“) z předem definovaného scope. Prochází síťový a procesní diagram a jejich příslušné pasáţe diskutuje s projektovým týmem. Zároveň identifikuje, jaké z poţadavků se budou kontrolovat a aplikovat v závislosti na scope a typu obchodní činnosti. Příkladem můţe být model obchodního řetězece. Při gap analýze hodnotitel pravděpodobně dojde k závěru, ţe tento obchodník neprovádí ţádný softwarový vývoj aplikací,
které by pracovaly
s karetními
daty.
To
bude
důvodem,
ţe
hodnotitel
poţadavek č. 645 PCI DSS přejde a obchodník se nebude v rámci přípravy na assessment poţadavky této třídy jakkoliv zabývat.
42
Domain Name System (Systém doménových jmen) - Nástroj pro převod doménových jmen (např. www.pcisecuritystandards.org) na veřejné IP adresy (72.3.223.78) a naopak. 43 Server, který dělá prostředníka při hypertextové komunikaci klienta se servery na Internetu. 44 Server, na kterém běţí NTP (Network Time Protocol) pro synchronizaci vnitřních hodin, který zajišťuje, aby všechny počítače v síti měly stejný čas (z pohledu bezpečnosti je NTP důleţité při monitoringu a forenzních analýzách). 45 Vývoj a udrţování bezpečných systémů a aplikací.
35
4.1 Cíle gap analýzy Hlavním cílem gap analýzy je získat jasnou představu o tom, kde se v současné chvíli nacházejí zranitelnosti a nedostatky oproti PCI DSS. Instituce můţe následně stanovit vhodná opatření k nápravě těchto nedostatků. Shromáţděné informace v rámci této analýzy by měly být analyzovány za účelem: - identifikace oblastí nesouladu instituce s PCI DSS (případně ISO 27001); - identifikace klíčových procesů, které mají být dále detailněji analyzovány; - identifikace, jaký objem práce je třeba uskutečnit k dosaţení souladu s PCI DSS; - stanovení priorit implementace jednotlivých poţadavků PCI; - zjištění, zda přijatá či plánovaná nápravná opatření nejsou kontra produktivní. Příkladem mohou být příliš dlouhá a sloţitá přístupová hesla do systémů, jejichţ délka naopak způsobí sníţení bezpečnosti (vzhledem k jejich sloţitosti hrozí riziko, ţe si je pracovníci budou psát a vylepovat); - diskuze s QSA nad smyslem pouţití kompenzačních opatření u konkrétních systémů a procesů; - zjištění, jaké poţadavky PCI DSS nejsou z jejich podstaty na instituci aplikovatelné; - vytvoření seznamu všech dotazovaných osob; - vytvoření seznamu zkoumané dokumentace; Gap analýza by měla být nezbytnou součástí dosaţení souladu s PCI DSS. Nicméně forma jejího provedení nepředpokládá přímé kontroly systémů, logů, fyzického zabezpečení na místě (jak se provádí během assessmentu). To je hlavním důvodem, proč výstup z gap analýzy nemusí jasně vystihovat skutečný stav bezpečnosti konkrétního systému nebo procesu. Můţe tak vzniknout riziko, ţe se při finálním assessmentu ukáţe, ţe informace získané během gap analýzy neodpovídají skutečnosti. S tím je třeba počítat a předem si s hodnotitelem stanovit postup (např. u kritických systémů je lépe se dohodnout na přímé kontrole systémů namísto pohovorů).
36
4.2 Plán nápravných opatření Veškeré výsledky z gap analýzy by měly být řádně zdokumentovány ve formě přehledné zprávy. Z této zprávy by měl vycházet plán nápravných opatření pro samotnou implementaci, který by měl obsahovat minimálně následující: - plán implementace, vč. podrobných doporučení, časových rámců pro odstraňování nálezů, potřebných finančních a lidských zdrojů; - návrhy řešení nálezů, které vzešly z konzultací projektových specialistů s hodnotitelem; - roadmapu,
která
stanovuje
prioritizovaný
přístup
k odstraňování
nálezů
identifikovaných během gap analýzy; - veškeré
oblasti,
kde
se
plánuje
implementovat
kompenzační
opatření.
Tato kompenzační opatření budou zároveň ověřována během analýzy rizik. Samotný plán nápravných opatření by měl být vytvořen projektovým analytikem ve spolupráci s projektovým managerem a hodnotitelem. Hodnotitel by měl závěrem potvrdit jeho správnost a efektivnost navrhnutých řešení. Na závěr fáze gap analýzy by měl projektový manager předloţit zprávu z gap analýzy managementu a řídící komisi projektu a nechat si schválit plán nápravných opatření. Toto schválení je zásadní, jelikoţ by management měl být před startem implementace obeznámen se všemi riziky a finančními náklady. Pokud management plán nápravných opatření schválí, pak můţeme přikročit k samotné implementaci.
4.3 Provedení analýzy rizik Před provedením analýzy rizik je důleţité si krátce představit oblast risk managementu, kde samotná analýza rizik představuje nejdůleţitější část. Podstatou risk managementu je identifikace, kvantifikace a zvládání rizik, které se vyskytují ve zkoumaném prostředí. V našem případě toto prostředí představuje předem definovaný scope projektu. Samotný pojem riziko lze chápat jako pravděpodobnost, ţe konkrétní jev bude mít negativní dopad na instituci. Riziko by mělo být měřitelné v závislosti na svém dopadu a pravděpodobnosti,
ţe nastane.
Abychom
tyto
rizika
dokázali
zvládat,
obvykle
je potřebujeme s předstihem a co moţná nejlépe poznat, neboť to nám umoţní podniknout takové kroky, které daná rizika minimalizují.
37
Procesy risk managementu (viz příloha č. 2) by v kaţdém případě měly být vnímány procesně, dle jiţ zmíněného PDCA cyklu. V rámci PDCA cyklu se na pravidelné bázi hodnotí vyspělost procesů risk managementu, na jejichţ základě se navrhuje optimální úroveň analýzy rizik. PCI DSS explicitně vyţaduje provádění procesů risk managementu, je to jeden z přímých poţadavků tohoto standardu. K tomu je ale třeba doplnit, ţe tyto procesy představují základní kámen celé informační bezpečnosti a lze je určitým způsobem nadřadit nad ostatní poţadavky PCI DSS. To je hlavním důvodem, proč analýze rizik věnuji samostatnou kapitolu a nezmiňuji ji v následující kapitole č. 5 Implementační fáze projektu. Obecně by měl vţdy existovat vztah mezi hodnotou aktiva a nákladů, které je potřeba investovat do opatření sniţující rizika nad tímto aktivem. U PCI DSS to neplatí doslova, jelikoţ typ aktiva za nás určily sami asociace bez ohledu na jeho hodnotu. Vše se točí kolem PAN, případně dalších datových elementů, které jsou s PAN ve spojení. Naším cílem v projektu bude nastavit procesy prevence moţných incidentů kolem PAN, které nebudou mít charakter reaktivní46, ale proaktivní47. Není záměrem této práce popsat veškeré procesy risk managementu, jak je zobrazeno v příloze č. 2, protoţe by to výrazně přesáhlo její rozsah. V této práci se zaměřím pouze na to nejdůleţitější, a to je analýza rizik, včetně dílčích procesů hodnocení rizik. Přejděme nyní k analýze rizik samotné, která představuje kontrolní metodu, s jejíţ pomocí jsou jednotlivá rizika včas vyhledána, rozpoznána a vyhodnocena. Nás budou primárně zajímat rizika související s klíčovými procesy kolem PAN, osobami a IT sluţbami v prostředí našeho scope. Během projektové fáze, která se zabývá analýzou rizik bychom měli provést následující kroky: - svolat workshop pro identifikaci rizik. Cílem tohoto workshopu by měla být identifikace všech rizik ohroţujících PAN v rámci předem definovaného scope; - vytvořit tabulku rizik zahrnující všechna identifikovaná rizika; - ohodnotit rizika ve smyslu stanovení míry závaţnosti kaţdého z nich. Pro účely analýzy rizik dle PCI DSS tuto míru získáme násobkem hodnot pravděpodobnosti a dopadu. 46
Reaktivní přístup řeší bezpečnostní incidenty teprve poté, co nastanou. Tento přístup je tedy často spojen s vynakládáním výrazných finančních nákladů na opravu škod za incident. 47 Proaktivní přístup pravidelně rizika analyzuje, vyhodnocuje a nakonec navrhne opatření, které zabrání, aby k bezpečnostnímu incidentu vůbec došlo.
38
Součástí ohodnocení kaţdého z rizik je i způsob jeho zvládání, jinými slovy, jak s rizikem po jeho ohodnocení naloţit; - stanovit si akceptovatelnou míru závaţnosti rizika a zanést hodnoty jeho závaţnosti do matice rizik; Představme si tyto kroky a realizaci analýzy rizik na praktickém příkladu. V současné chvíli předpokládejme, ţe proběhl workshop pro identifikaci rizik a veškerá tato rizika byla zapsána do tabulky rizik. S ohledem na modelové příklady hotelu a obchodního řetězce jsem tuto tabulku vytvořil a ohodnotil míru závaţnosti kaţdého z rizik (viz příloha č. 3). Po fázi tohoto ohodnocení doporučuji stanovit akceptovatelnou míru rizika. Tato míra nám bude určovat, jaká rizika jsou pro nás vzhledem k míře závaţnosti akceptovatelná a která nikoliv. Pokud by míra závaţnosti u konkrétního rizika byla vyhodnocena jako akceptovatelná, neznamená to, ţe bychom se tímto rizikem přestali zabývat. Takové riziko musí být na pravidelné bázi monitorováno a jeho míra přezkoumávána, abychom si byli jisti, ţe se nám jeho závaţnost postupem času nezvýšila. Diagram č. 1 - Matice rizik
Zdroj: Vlastní tvorba.
39
Výše uvedený diagram č. 1 zobrazuje matici, do které jsem zanesl hodnoty míry závaţnosti jednotlivých rizik z tabulky v příloze č. 3. Zároveň jsem zakreslil akceptovatelnou míru závaţnosti. Toto zakreslení je uţitečné jednak pro fázi plánování, a dále jako součást zprávy pro management. Z matice na obrázku č. 8 vyplývá, ţe bychom se měli zaměřit na řešení rizik č. 1, 13, 29, 4, 25, 17, 26 a 3. Při volbě způsobu jejich zvládání doporučuji si vţdy poloţit 3 otázky: - „Co?“ Co chci zvládat (ve smyslu zvolení konkrétního rizika); - „Jak?“ Jaký zvolím způsob zvládání rizika (outsourcing rizika, sníţení jeho míry významnosti, atd.); - „Čím?“
Konkrétní
opatření
(při
zvolené
metodě
zvládání
rizika
sníţením
jeho významnosti zvolíme konkrétní nápravné opatření - např. implementace šifrování pro zajištění důvěrnosti PAN). Poté, co získáme odpovědi na uvedené otázky, nastartujeme proces zvládání rizik, který bude na pravidelné bázi revidován a míra zbytkového rizika přezkoumávána. Pro proces zvládání rizik můţeme v zásadě vyuţít některé z těchto moţností: - riziko snížit. Ke sníţení rizika dochází implementací vhodných opatření, které by měly docílit toho, ţe sníţíme riziko na akceptovatelnou úroveň. - riziko přijmout. Riziko přijímáme, pokud vyhodnotíme, ţe by náklady na zavedení nápravného opatření převýšily moţné následky plynoucí z rizika nebo např. neexistují technická opatření pro jeho sníţení. Pokud nemáme jinou moţnost, neţ riziko akceptovat, pak je důleţité nastavit procedury reakce na incident, abychom v co největší míře zmírnili jeho případný dopad. - vyhnout se riziku. Pokud jsou rizika plynoucí z určité činnosti příliš velká nebo náklady vynaloţené na nutná opatření převyšují přínosy z této činnosti, je řešením se této činnosti zcela vyhnout. - riziko přesunout. V některých případech je výhodnější se riziku zcela vyhnout prostřednictvím jeho přenesení např. na dodavatele, který se s konkrétním rizikem vypořádá efektivněji (např. outsourcing konkrétní činnosti na dodavatele nebo sjednání pojištění, které poskytne rizikové krytí).
40
Povaţuji za důleţité zmínit, ţe procesy risk managementu jsou prostřednictvím našeho projektu pouze nastartovány. Je třeba stanovit si časové rámce na jejich opětovné přezkoumávání. Tímto přezkoumáním bychom měli dostat odpovědi např. na otázky typu: - změnila, či nezměnila se nám míra závaţnosti námi identifikovaných rizik?; - je moţné, ţe nám přibyla nová rizika z důvodu rozšíření scope našeho karetního prostředí?; - není na čase zpřísnit, či zmírnit akceptovatelnou míru závaţnosti?; - funguje nám původní strategie zvládání rizik?. Finálním krokem po provedené analýze rizik je připravení zprávy pro management. Tato zpráva je důleţitá zejména z pohledu schvalování peněţních prostředků potřebných pro naší strategií zvládání rizik. Jasné uvedení seznamu všech rizik, popsání způsobu jejich identifikace a ohodnocení je nutným základem, aby management mohl rozhodnout, zda finanční prostředky budou na zvolenou strategii zvládání rizik poskytnuty. Obecně nejlepší formou představení zprávy je prezentace. Takováto prezentace dává prostor pro sdílení kolektivního povědomí o představované problematice a rovněţ pro případné zjištění souvisejících rizik. Ukázku vzorové prezentace uvádím v příloze č . 4, která opět vychází z tabulky rizik v příloze č. 3. Provedení takovéhoto představení rizik je rovněţ důleţité i z důvodu našeho krytí. Za předpokladu, ţe by management přidělení finančních prostředků na zvládání rizik neschválil a následně došlo k bezpečnostnímu incidentu, pak je management ten, kdo předem riziko moţného incidentu akceptoval.
41
5 Implementační fáze projektu Tato kapitola se zaměřuje na detaily implementačních úkonů, které musí být podniknuty k tomu, abychom vyhověli nezbytnému minimu PCI DSS. V této projektové fázi není zamýšleno jednoduše implementovat celý standard, ale logicky jen ty poţadavky, které nám indikovala gap analýza jako nálezy. Před samotnou implementací doporučuji vzít v úvahu výsledky z provedené analýzy rizik a s hodnotitelem konzultovat pouţití moţných kompenzačních opatření. Takovým kompenzačním opatřením vycházejícím z vyhodnocení rizik by mohl být např. outsourcing rizika, které skýtá nezajištění konkrétního poţadavku PCI DSS. Diagram č. 2 - Oblasti a třídy požadavků PCI DSS OBLASTI IMPLEMENTACE
TŘÍDY POŢADAVKŮ
1. Vybudování a udržování bezpečné sítě
1. Instalace a udrţování konfigurace firewallu 2. Nepouţívat výchozí nastavení pro systémová hesla a jiné bezpečnostní parametry od dodavatele
2. Ochrana dat držitelů karet
3. Ochrana uloţených dat drţitelů karet 4. Šifrování karetních dat při přenosu po otevřených veřejných sítích
3. Vedení programu zranitelnosti
5. Pouţívání a pravidelné aktualizace antivirových programů 6. Vývoj a udrţování bezpečných systémů a aplikací 7. Omezení přístupu k datům drţitelů karet jen podle potřeby
4. Zavedení důkladných opatření pro kontroly přístupu
8. Přidělení jedinečného ID kaţdé osobě s přístupem k počítači 9. Omezení fyzického přístupu k datům drţitelů karet
5. Pravidelné monitorování a testování infrastruktury
10. Monitoring a sledování přístupů k síťovým zdrojům a datům drţitelů karet 11. Pravidelné testování bezpečnostních systémů a procesů
6. Udržování pravidel informační bezpečnosti
12. Pravidla bezpečnosti informací pro zaměstnance a dodavatele
Zdroj: Vlastní tvorba.
Přejděme nyní k rozdělení poţadavků PCI DSS a jejich samotné implementaci. Diagram č. 2 zobrazuje rozdělení standardu do 6 oblastí, k nimţ náleţí 12 tříd poţadavků. Následující podkapitoly budou reprezentovány právě těmito oblastmi, kde kromě obecných doporučení
42
představím opět přímou demonstraci na modelových případech obchodního řetězce a hotelu. V závěru kapitoly představím návrh postupu implementace jednotlivých poţadavků.
5.1 Vybudování a udržování bezpečné sítě Oblast budování a údrţby bezpečné sítě je specifikovaná dvěma čistě technologickými poţadavky. První poţadavek řeší problematiku instalace a nastavení síťových prvků a druhý tvorbu bezpečné konfigurace nad těmito prvky. Požadavek č. 1 - Instalace a udržování konfigurace firewallu Jedním z nejkritičtějších elementů PCI DSS je koncept izolování síťové infrastruktury a systémů, přes které se zpracovávají karetní data. Pod tuto oblast spadají následující zařízení: firewally, routery, switche, operační systémy48, systém řízení databáze a aplikace. Nejdůleţitějším doporučením pro poţadavek č.1 je zváţit pouţití VLAN49, které fyzicky izolují
datový
přenos
karetních
dat.
Ze
síťového
hlediska
tímto
docílíme,
ţe pouze takto izolovaná část infrastruktury bude zahrnuta do našeho scope. Zároveň je uţitečné si stanovit postup, jakým způsobem bude při assessmentu demonstrován proces řízení změn nad síťovými komponentami. Tento proces zahrnuje popis: - způsobu změn v konfiguraci síťových zařízení; - plánování jejich důkladných kontrol; - změn jejich konfigurací; - schvalovacího procesu na provedení konfigurací a kontrol; - plánu reakce na incident a způsobu návratu k původním konfiguraci zařízení (v případě softwarové poruchy způsobené nevhodnou konfigurační změnou). Typy na implementaci: - Zhodnotit moţnosti pouţití síťové segmentace (viz kapitola č. 3.2.1); - Zřízení standardů pro bezpečnou konfiguraci síťových zařízení včetně procesů na kontrolu změn; 48
Operační systém je softwarový prostředník mezi hardwarem (technickým vybavením počítače) a konkrétním programem, který uţivatel pouţívá. 49 Zkratka pro virtuální síť. VLAN slouţí k logickému rozdělení sítě nezávisle na jejím fyzickém uspořádání. Pomocí VLAN lze síť segmentovat na menší sítě uvnitř fyzické struktury původní sítě.
43
- Standardy pro konfiguraci síťových zařízení by měly zahrnovat omezení spojení mezi jakýmkoliv systémovými komponentami v prostředí našeho scope a externími sítěmi, které nejsou v naší správě a nemůţeme je konfigurovat. - Implementace DMZ50 pro omezení příchozí datové komunikace pouze na autorizované externí systémové komponenty. - Neodhalování směrovacích a interních IP adres neautorizovaným stranám. Pro tento účel lze vyuţít implementací NAT, jeţ ovládá firewall či router. Pokud tyto informace firewall „nezamaskuje“, je zde riziko jejich odhalení a následného pokusu přístupu do sítě ze zfalšované IP adresy. Demonstrace implementace požadavku č. 1 na modelových příkladech: Při pohledu na infrastrukturu obchodního řetězce (obrázek č. 3) je třeba si nejprve identifikovat místa, kde dochází k prvotní interakci s PAN. Těmito místy jsou POS terminály v maloobchodní prodejně (segment A1 na obrázku č.3), dále hostingovaný Webserver (segment B2) a samoobsluţné/POS terminály (segment D1). Z pohledu moţné redukce scope navrhuji segmentovat a odstínit samoobsluţné a POS terminály (segment D1) od okolní podnikové LAN, do dedikované VLAN. Dalším krokem bude nastavení ACL51 na úrovni firewalu (segment B3) a routeru (segment D3) pouze na IP adresy pro komunikaci, a nad těmito dvěma síťovými zařízeními zřídit procesy řízení bezpečné konfigurace zařízení. V případě hotelu nás bude zajímat pouze podniková síť (segmenty D a E na obrázku č.5). Zde jsou místem interakce s PAN prakticky všechna zobrazená zařízení, tj. recepční stanice, notebook a SBS server. Síťová segmentace zde nemá prakticky význam a bude nás zajímat výhradně router/AP (segment C3). Současný stav je takový, ţe všechny stanice a server (segmenty D a E) mají veřejné IP adresy, a tudíţ je zde riziko útoku z veřejné sítě.
50
Demilitarizovaná zóna. Část sítě, která kontroluje a řídí spojení mezi veřejnou sítí (např. internet) a vnitřními sluţbami. 51 ACL (Access control list) je seznam oprávnění, který určuje, kdo nebo co můţe přistupovat k určitému systému a jaké operace v něm můţe provádět. Typicky se ACL nachází na firewallech nebo routerech, kde ACL povoluje datovou komunikaci plynoucí pouze např. z autorizovaných IP adres.
44
Naším cílem bude nastavit na zmíněném routeru NAT tak, abychom veřejné IP adresy omezili pouze na adresu routeru a veškerá zařízení v podnikové síti se za NATem skryla. Samozřejmostí je následné nastavení procesů řízení bezpečné konfigurace zařízení, a to nejen na tomto routeru, ale i na firewallu (segment B3).
Požadavek č. 2 - Nepoužívat výchozí nastavení pro systémová hesla a jiné bezpečnostní parametry od dodavatele Tento poţadavek se zejména IT administrátorům můţe zdát samozřejmý. Pravdou ale je, ţe ponechání výchozích hesel od výrobce na úrovni systémových komponent je častou realitou. Mnozí výrobci dodávají systémové komponenty s jiţ přednastavenými přístupovými údaji. Důvodem je usnadnit koncovému zákazníkovi instalaci zařízení. V praxi se však bohuţel stává, ţe instituce neprovedou základní kontroly nastavení před nasazením systémové komponenty do produkce. V případě, ţe je tato komponenta nainstalována, aniţ by nejprve došlo ke změně výchozích hesel, pak se tato komponenta vystavuje zvýšenému riziku neautorizovaného průniku do nastavení. Útočníci tak získají snadný přístup do systému nebo do nastavení systémových komponent, protoţe výchozí hesla jsou jim dobře známa a jejich výčet lze pohodlně najít na internetu. Lze konstatovat, ţe pouţití výchozího nastavení přihlašovacích údajů představuje totéţ, jako zakoupení drahého zámku k vlastním vchodovým dveřím a následné poskytnutí kopií klíčů útočníkům. Abychom tomu zabránili, je třeba zaměřit se na veškeré systémové komponenty v našem scope a zajistit, ţe výchozí hesla byla změněna. S tím se pojí další povinnost, a to je odstranění veškerých uţivatelských účtů za předpokladu, ţe neexistuje legitimní důvod pro jejich existenci.
45
Typy na implementaci: - U všech systémových komponent měnit výchozí hesla před instalací do produkce, tj. ještě předtím, neţ je naimplementujeme do našeho karetního prostředí.
Lze zváţit
zavedení jiného autentifikačního52 mechanismu zaloţeného např. na čipové kartě. - Vytvoření konfiguračních postupů pro všechny systémové komponenty, které budou obsahovat řešení všech známých bezpečnostních ohroţení, včetně způsobů reakce v případě jejich výskytu. - Veškeré administrativní přístupy, které nejsou prováděny prostřednictvím konzole, by měly vyuţívat šifrovaného přístupu (např. při připojování na vzdálený terminál systémové komponenty nepouţívat Telnet53, ale SSH54). Demonstrace implementace požadavku č. 2 na modelových příkladech: Prvním krokem, který je třeba učinit, je informovat IT personál o povinnosti okamţité změny výchozího hesla jakékoliv nově pořízené systémové komponenty určené pro nasazení do našeho scope. V případě externích dodavatelů platí, ţe bychom je měli o této povinnosti vhodně informovat. Nicméně udrţování bezpečnosti jimi provozovaných systémových komponent, které jsou součástí našeho scope, jiţ vychází z poţadavku č. 12 PCI DSS. V případě obchodního řetězce hovoříme o hostingové společnosti provozující e-commerce web server (segment B1 na obrázku č.3) a k němu asociovaný 3D secure server nacházející se v autorizačním centru (segment C5). U obchodního řetězce bych doporučoval zaměřit se na vytvoření bezpečných konfiguračních postupů a postupů reakce na incident u routeru (segment D3), firewallu (segment B3) a veškerých systémových komponent zapojených do podnikové LAN (segment D3).
52
Autentifikace představuje proces ověření identity subjektu, který ţádá o přístup do konkrétního systému či systémové komponenty. Pokud je osoba autentifikována, můţe proběhnout její autorizace. Klasickým způsobem autentifikace je prostřednictvím jména a hesla. 53 Telnet - Komunikační protokol pouţívaný v počítačových sítích, který pomocí stejnojmenné aplikace umoţňuje uţivateli připojení ke vzdálenému počítači. Nevýhodou Telnetu je absence šifrování datového toku. 54 Zabezpečený komunikační protokol, který byl navrţen jako náhrada za Telnet a další jemu podobné komunikační protokoly. SSH umoţňuje bezpečnou komunikaci mezi dvěma počítači, ve smyslu zajištění bezpečné autentifikace a šifrování přenášených dat při průchodu přes nedůvěryhodné sítě.
46
Pokud jde o POS a samoobsluţné terminály samotné, pak tato zařízení nespadají do rozsahu PCI DSS. Zde se očekává, ţe tyto terminály budou PCI PTS55 certifikované a nebude nutné se v této fázi jejich bezpečností jakkoliv zabývat. U hotelu je situace podobná. Zajistíme tvorbu bezpečných konfiguračních postupů a postupů reakce na incident u koncových stanic v podnikové LAN (mimo POS), dále pak u routeru (segment C3 na obrázku č. 5) a Firewallu (segment B3). Pokud jde o SBS server (segment E3), zde se ukládá větší mnoţství dat o drţitelích karet, z tohoto důvodu je třeba tento systém povaţovat za kritický. Na úrovni tohoto serveru doporučuji zajistit autentifikaci prostřednictvím čipové
karty
nebo
implementovat
nějakou
formu
dvou-faktorové
56
autentifikace . U hotelu je třeba věnovat pozornost IT servisní organizaci, která vzdáleně přistupuje prostřednictvím konzole na aktivní síťové prvky a SBS server. Zde je třeba zajistit, aby toto vzdálené připojení probíhalo šifrovaně. Ačkoliv o zabezpečení komunikační cesty hovoří aţ poţadavek č. 4, je třeba si uvědomit, ţe zde neprobíhá přenos karetních dat, pouze vzdálená administrace. Nicméně je zde riziko moţného útoku na uvedené systémové komponenty (včetně kritického systému), přes které jiţ karetní data putují, či jsou uloţena.
5.2 Ochrana dat držitelů karet V této oblasti se zaměříme na logickou ochranu dat drţitelů karet během jejich ukládání a přenosu. Tato oblast je reprezentována dvěma poţadavky. Požadavek č. 3 - Ochrana uložených dat držitelů karet Tento poţadavek se zaměřuje na šifrování dat drţitelů karet, případně jejich přeměnění do zkráceného tvaru. Nad těmito ochranami stojí vrstva bezpečného řízení ţivotního cyklu šifrovacích klíčů. Pokud útočník například obejde bezpečnostní mechanismy sítě a získá přístup k datům drţitelů karet, která budou šifrovaná, pak bez relevantních šifrovacích klíčů budou pro něj nepouţitelná.
55
Payment Card Industry Payment Secure Transactions (bezpečnostní standard pro zařízení procesující PIN). Metoda autentifikace zaloţená na dvou zcela nezávislých faktorech - např. na něčem, co uţivatel zná (PIN, aj.) a něčem, co fyzicky vlastní (autentifikační token, aj.). 56
47
Aţ se v rámci projektu budeme zabývat otázkou jejich zabezpečení, pak doporučuji zváţit moţnost tato data (kde to bude moţné) vůbec neuchovávat. Toto samozřejmě souvisí s detailní analýzou obchodních procesů navázaných na operace s daty o drţitelích karet, o které jsem se jiţ zmiňoval v předchozích kapitolách. Naším úkolem bude zanalyzovat veškerá místa v rámci našeho scope a identifikovat všechna úloţiště dat drţitelů karet. Z pohledu elektronického ukládání se mezi tato místa řadí úloţiště logů aplikací, souborů historie, obsahu databází, dočasných souborů, transakčních dat, logů síťových zařízení a serverů. Záměrně hovořím o datech o drţitelích karet, nikoliv o karetních datech jakoţto dvou skupinách, protoţe poţadavek č. 3 zakazuje ukládání citlivých ověřovacích dat. Zde je na místě zváţit pouţití metody maskování či zkracování PAN. Zkracování je metoda, kdy dochází k odstranění větší části PAN tak, aby bylo eliminováno riziko jeho zneuţití a zároveň, aby zbylá část byla dostatečně vypovídající pro obchodní účely. U metody zkracování představuje prvních šest a poslední čtyři číslice maximální počet, který lze z PAN zobrazit. Metoda maskování je odlišná v tom, ţe se PAN uchovává v plném tvaru, nicméně jeho výstup (např. na obrazovce, faktuře nebo na účtence) je uţ ve tvaru zkráceném. Záměrem pouţití těchto metod je učinit PAN mimo rozsah poţadavků PCI DSS. Typy na implementaci: - Neukládat citlivá ověřovací data (ani v šifrované formě); - Ukládat data drţitelů karet v minimální moţné míře nezbytné pro obchodní aktivity; - Zváţit pouţití metody tokenizace (viz kapitola č. 3.2.1); - Maskovat či zkracovat PAN; - Chránit šifrovací klíče, které jsou pouţívané pro šifrování dat drţitelů karet; - Provádět pravidelné obměny šifrovacích klíčů, které exspirovaly. Demonstrace implementace požadavku č. 3 na modelových příkladech: U obou modelových příkladů bych doporučoval postupovat v následujících několika krocích. Nejprve provést analýzu veškerých moţných úloţišť dat drţitelů karet v rámci našeho scope. Následně s pracovníky, kteří mají v pracovní gesci pracovat s těmito daty v konkrétních úloţištích ověřit, zda je bezpodmínečně nutné, aby zde měli PAN v plné formě.
48
Pokud se naskytne moţnost eliminace PAN, či jeho zkrácení, učiňme tak. Ve zbylých místech bychom měli PAN vhodnou formou zabezpečit. U modelu obchodního řetězce se zaměříme na souborový server a kancelářské PC (segment D4 na obrázku č. 3). Na souborovém serveru je pro reklamační účely potřeba drţet plný PAN. Zde ochranu PAN zajistíme prostřednictvím implementace odolné kryptografie společně s nastavením procesu bezpečného řízení ţivotního cyklu šifrovacích klíčů. Dle získaných informací od pracovníků obchodního řetězce není nutné, aby se na této stanici zobrazovaly PAN v plném tvaru, postačí zkrácená forma. Pracovníci vyuţívající této stanice si stahují PAN ze souborového serveru. Naším cílem tedy bude zvolit takovou aplikaci, která by PAN na souborovém serveru šifrovala a zároveň obsahovala algoritmus pro výstup maskovaného PANu. Takové aplikace na trhu jsou, nicméně záleţí na finančních moţnostech obchodníka. Platí, ţe by tato aplikace měla být PA DSS57 certifikovaná, minimálně proto, ţe nám tak zastřeší většinu poţadavků PCI DSS na souborovém serveru. V opačném případě doporučuji poskytnout potřebný adresář s PAN ze souborového serveru pro sdílení jednotlivým stanicím a zároveň v bezpečnostní politice instituce stanovit povinnost, ţe veškeré operace spojené s ukládáním PAN musí probíhat pouze na tomto sdíleném disku. Následně doporučuji o této povinnosti informovat prostřednictvím informačního programu o bezpečnosti karetních dat (více viz poţadavek č. 1258 PCI DSS). U hotelu je situace obdobná, kritickým místem je SBS server, na kterém běţí rezervační systém hotelu. Zde je nutné zabezpečit databázi s PAN prostřednictvím odolné kryptografie. Vzhledem k tomu, ţe pracovní náplní recepčních je vkládat PAN do recepčního PC, bude nutné zajistit, aby se PAN vkládal pouze na úroveň SBS serveru, nikoliv stanice samotné. Na trhu jsou běţně k dostání aplikace rezervačních systémů, které umoţňují šifrování na úrovni lokální databáze a zároveň mají webové rozhraní pro vkládání PAN. Toto rozhraní si lze představit jako softwarového agenta komunikujícího s rezervačním systémem přes webové rozhraní. Pracovníci recepce vloţí PAN do tohoto rozhraní a ten je následně odeslán a bezpečně uloţen v databázi rezervačního systému. Na druhou stranu je přes toto rozhraní moţné zobrazit konkrétní pan z uvedené databáze oproti vloţení 57 58
Payment Aplication Data Security Standard (bezpečnostní standard pro platební aplikace). Pravidla bezpečnosti informací pro zaměstnance a dodavatele.
49
jména a příjmení drţitele karty. Je důleţité, aby autentifikace do tohoto rozhraní byla v souladu s poţadavkem č. 859. Požadavek č. 4 - Šifrování karetních dat při přenosu po otevřených veřejných sítích Veškeré příchozí a odchozí datové toky obsahující karetní data a putující přes veřejné sítě musí být šifrovány. To je podstata poţadavku č. 4, který nařizuje pouţít zabezpečených protokolů a technologií, jako např. TLS/SSL60, IPSec61, WPA262 pro zajištění ochrany přenášených dat. Typy na implementaci: - Šifrovat veškeré toky karetních dat přes veřejné sítě prostřednictvím výše uvedených šifrovacích protokolů, které pro bezpečnostní funkce vyuţívají odolné kryptografie63. U bezdrátových sítí je v současné době stále hojně vyuţíván bezpečnostní protokol WEP64, který díky snadnému prolomení není doporučován, tj. jeho pouţití nám nezaručí soulad s poţadavkem č. 4.1.1. - Nikdy nezasílat PAN v nešifrovaném mailu. V kaţdém případě je důleţité ověřit, zda je odolná kryptografie uţívána, kdykoliv jsou data drţitelů karet posílána technologiemi pro zasílání zpráv koncovým uţivatelem. Demonstrace implementace požadavku č. 4 na modelových příkladech: V případě komunikace POS směrem na autorizační centrum je u obou obchodníků zajištěna ochrana datového toku prostřednictvím SSL. Data se šifrují na úrovni POS a dešifrují
59
Přidělení jedinečného ID kaţdé osobě s přístupem k počítači. TLS (Transport Layer Security) a jeho předchůdce SSL (Secure Sockets Layer) jsou šifrovací protokoly, které umoţňují ochranu komunikace na internetu. Do rozsahu ochrany TLS/SSL spadají sluţby jako WWW, elektronická pošta a další. 61 IPsec je bezpečnostní rozšíření IP protokolu, které je zaloţené na šifrování datových paketů přenášených přes síť a bezpečné autentifikaci. 62 WPA 2 (Wi-Fi Protected Access 2) je šifrovací protokol pouţívaný v bezdrátových sítích. Tento protokol šifruje přenášené datové pakety a zároveň ověřuje, zda nedošlo ke změně šifrovacího klíče. Velkou výhodou tohoto protokolu je, ţe ověřuje uţivatele a pomáhá zjišťovat, aby přístup k bezdrátové síti získali pouze autorizovaní uţivatelé. 63 Kryptografie zaloţená na odvětvově akceptovaných algoritmech spolu s délkami odolných šifrovacích klíčů a správnými postupy managementu klíčů. K příkladům odvětvově testovaných a akceptovaných standardů a algoritmů kódování patří AES (128 bitů a více), TDES (kódy o minimálně dvojnásobné délce), RSA (1024 bitů a více), ECC (160 bitů a více) a ElGamal (1024 bitů a více). 64 WEP (wireless encryption protokol) je starší metoda zabezpečení bezdrátové sítě, která slouţí k podpoře starších zařízení, ale není nadále doporučována. Zabezpečení protokolem WEP však lze snadno umoţnit prolomení šifrování datového toku. 60
50
aţ v systémech autorizačního centra. Během cesty nedochází na ţádném místě k dešifrování přenášeného kryptogramu65, tudíţ tuto část datové komunikace můţeme vynechat. U obchodního řetězce vidíme dvě části infrastruktury, na které bychom se měli dle poţadavku č. 4 zaměřit. V prvním případě se jedná o webserver (segment B2 na obrázku č. 3) umístěný na vzdáleném hostingu. Zde lze vyuţít SSL/TLS zabezpečení na aplikační vrstvě a dešifrování provádět aţ na úrovni 3D secure serveru v autorizačním centru (segment C5). Druhou částí je podniková LAN (segment D3). Zde doporučuji zajistit šifrování komunikace na síťové vrstvě pomocí protokolu IPsec. V případě hotelu postupujeme podobně. Budeme šifrovat datovou komunikaci v podnikové LAN (segment D2 na obrázku č. 5) prostřednictvím protokolu IPSec. Dále zabezpečíme komunikaci od webserveru (segment A1) po autorizační centrum (segment A3) prostřednictvím SSL/TLS na aplikační vrstvě. Závěrem se zaměřme na router/AP (segment C3). Představme si situaci, kdy se manaţer hotelu připojuje s notebookem (segment E 3) do internetu bezdrátově přes AP, které zároveň slouţí jako výchozí brána do podnikové sítě se systémovými komponenty. V tomto případě doporučuji v prvé řadě zváţit vypnutí bezdrátového perimetru AP a připojovat onen notebook metalicky, tj. přes datový kabel. Pokud by ze strany vedení vznikl poţadavek na zachování bezdrátového perimetru, pak je třeba na úrovni AP nastavit šifrování tohoto perimetru prostřednictvím WPA2. Zároveň by měla být zajištěna patřičná míra fyzické bezpečnosti (dle poţadavku č. 766 PCI DSS), aby se k uvedenému AP nedostala neautorizovaná osoba a neprovedla reset nastavení. Tímto resetem by došlo ke smazání veškerých bezpečnostních nastavení a moţnosti přistoupit k nastavení zařízení prostřednictvím výchozího hesla od výrobce (více viz poţadavek č. 2).
5.3 Vedení programu zranitelnosti Oblast vedení programu zranitelnosti je nejrozsáhlejší oblastí PCI DSS. Obsahuje celkem 3 třídy poţadavků, jejíchţ cílem je zajistit pouţívání antivirových programů, udrţování bezpečných systémových komponent a omezení přístupu k datům drţitelů karet. 65 66
Šifrovaná data. Omezení přístupu k datům drţitelů karet jen podle potřeby.
51
Požadavek č. 5 - Používání a pravidelné aktualizace antivirových programů Antivirové programy poskytují první linii obrany proti neţádoucímu softwarovému kódu. Poţadavek č. 5 nařizuje, aby se na kaţdé stanici nebo serveru, kde se nachází nebo ze které se přistupuje ke karetním datům, vyskytoval antivirový program. Antivirový program by měl podléhat pravidelné aktualizaci. V některých izolovaných prostředích, jako jsou například bankomaty, je velice obtíţné udrţovat antivirový program aktualizovaný. V podobných případech se jako kompenzační opatření jeví pouţití např. whitelistingové aplikace67 s centrálním řízením dohledu a správy logů. Implementací a pouţívání whitelistingové aplikace nám zároveň ve velké míře pomůţe pokrýt poţadavek č. 1068 PCI DSS u systému, na kterém se nachází. Typy na implementaci: - Instalovat antivirové programy na všechny systémy (uţivatelské stanice a servery) ve scope; - Zajistit, aby virové databáze byly pravidelně aktualizované; - Zajistit, aby byl pouţitý antivirový software schopen generovat auditní logy. U těchto logů je zároveň potřeba ověřit dobu jejich ukládání, aby byla v souladu s poţadavkem č. 10.769 PCI DSS. Demonstrace implementace požadavku č. 5 na modelových příkladech: Na všech stanicích a serverech u obou obchodníků by měl běţet antivirový program a zároveň by měla být zajištěna jeho pravidelná aktualizace. U kritických systémů, jakými jsou souborový server (segment D4 na obrázku č. 3) a SBS server (segment E3 na obrázku č. 5) bych doporučoval zváţit odpojení linky do internetu a řešit aktualizace manuální cestou. Tato cesta by představovala stáhnutí aktualizací na jiné stanici neţ je ta, na níţ běţí kritický systém. Následovalo by otestování této aktualizace minimálně na přítomnost viru a její následná distribuce prostřednictvím paměťových médií do kritických systémů. Rovněţ lze zváţit moţnost implementace zmíněné whitelistingové aplikace. 67
Whitelistingové aplikace zajišťují monitoring změn a kontrolu integrity definovaného SW. Současně tento typ aplikací hlídá spouštění přesně definovaných procesů. Samotná funkce whitelistingu umoţňuje definici procesů, které jsou pouţívány pro standardní běh instalovaných aplikací a zároveň zajišťuje blokování jakéhokoliv neautorizovaného procesu. Tento způsob ochrany je velmi vhodný ve stabilním prostředí (např. v bankomatu), kdy není ţádoucí, aby byla několikrát denně aktualizována virová databáze. 68 Monitoring a sledování přístupů k síťovým zdrojům a datům drţitelů karet. 69 Uchovávat historii auditních záznamů nejméně jeden rok, přičemţ minimálně tři měsíce musí být bezprostředně k dispozici pro analýzu (například online, archivovaná nebo obnovitelná ze záloh).
52
Požadavek č. 6 - Vývoj a udržování bezpečných systémů a aplikací Pod tímto poţadavkem je instituce povinna zajistit aktuálnost veškerých softwarových záplat na všech koncových stanicích a serverech. Vhodné softwarové záplaty jsou takové, které byly výrobcem software vyhodnoceny k zajištění souladu se stávajícími bezpečnostními nastaveními. Součástí poţadavku č. 6 je i vedení evidence testování těchto záplat před jejich nasazením do produkce. Pokud instituce provádí vývoj aplikací, které jsou součástí karetního zpracování, pak se lze hned od začátku vyhnout četným zranitelnostem prostřednictvím pouţití metod bezpečného vývoje a technik bezpečného programování. Typy na implementaci: - Zajistit,
aby
veškeré
systémové
komponenty
a
veškerý
software
ve
scope
měly nainstalované aktuální bezpečnostní záplaty. Nejzazší povolený termín pro instalaci bezpečnostních záplat vyhodnocených výrobcem jako kritické je jeden měsíc; - Zavedení procesu identifikace nově odhalených bezpečnostních zranitelností; - Vytvořit proces bezpečného vývoje softwarových aplikací, které se podílejí na karetním zpracování; - Pravidelné školení vývojářů ve smyslu identifikace zranitelností a jejich řešení během vývoje; - Vytvoření
postupů
na
kontroly
změn
systémových
komponent.
Tyto
postupy
by měly zahrnovat: - oddělení testovacího a produkčního prostředí; - nepouţívání provozních dat (obsahujících PAN) pro testování a vývoj; - otestování testovacích dat a účtů před jejich nasazením do produkce. - U veřejně přístupných webových aplikací zajistit, ţe jejich firewall je instalován jako detektor a jako systém prevence útoků vůči této aplikaci.
53
Demonstrace implementace požadavku č. 6 na modelových příkladech: Ani jeden z obchodníků neprovádí aplikační vývoj. V tomto případě doporučuji pouze poţadovat po dodavatelích platebních řešení, např. hotel booking systému (segment A1 na obrázku č. 6) a e-commerce portálu (segment B1 na obrázku č. 4), aby při vývoji a údrţbě těchto webových aplikací dodrţovali pravidla bezpečného vývoje, např. dle metodiky OWASP70. Požadavek č. 7 - Omezení přístupu k datům držitelů karet jen podle potřeby Abychom dosáhli soulad s tímto poţadavkem, pak bychom měli zdokumentovat všechny specifické pracovní role. Cílem je zajistit, aby přístup ke karetním datům měl pouze autorizovaný personál. Zároveň je poţadována existence systémů a procesů, které omezují přístup dle systému „need to know71“ a pracovní náplně. Toto oddělení rolí nám pomůţe zajistit, ţe nikdo v instituci nebude mít přístup a práva k celému systému karetního zpracování. Typy na implementaci: - Omezení
přístupu
k systémovým
komponentám
a
datům
drţitelů
karet
pouze
na autorizované osoby. Uţivatelská oprávnění by měla být nastavena na co nejmenší moţnou úroveň podle toho, co pracovník skutečně potřebuje ke své práci. - Zavedení pravidelných kontrol přidělování oprávnění jednotlivým osobám dle jejich funkce a klasifikace pracovní pozice. Demonstrace implementace požadavku č. 7 na modelových příkladech: U obou obchodníků provedeme v prvním kroku zdokumentování všech pracovních rolí, tj. pracovníků, kteří přistupují a pracují s karetními daty v rámci našeho scope. U kaţdé této role se zdokumentuje úroveň nutných přístupových práv do systémových komponent. Následně bychom měli zajistit start pravidelných kontrol přístupových práv u těchto pracovníků. Cílem těchto kontrol je revize jejich privilegií na pravidelné časové bázi a odstraňování jiţ nepouţívaných uţivatelských účtů. Proces ţádostí o přidělení přístupových práv by měl být zformalizován a měla by existovat nějaká forma evidence všech ţádostí. 70
Open Web Application Security Project. Systém, kdy jsou přístupová práva poskytnuta jen k tomu mnoţství karetních dat a privilegií, které jsou potřebné k výkonu práce. 71
54
Největší riziko skýtá neefektivní nastavení procesu pravidelných kontrol. Můţe dojit k situaci, kdy bude zaměstnanci změněna pozice či pracovní náplň, nicméně práva do systémové komponenty mu zůstanou. Těmto případům je třeba předcházet a pravidelným kontrolám přístupových privilegií přisoudit patřičnou důleţitost. U případu hotelu se situace komplikuje tím, ţe je infrastruktura spravována IT servisní institucí (segment B1 na obrázku č. 5). Pracovníci této instituce se mohou dostat prakticky kamkoliv a mohou představovat váţné bezpečnostní riziko. V tomto případě vidím dvě moţné varianty. První varianta skýtá zamyšlení se nad přijmutím relevantního interního pracovníka, který by prováděl správu infrastruktury namísto této externí instituce. Druhou variantou je smluvní zakotvení hmotné a finanční zodpovědnost za bezpečnost aktiv, tj. nikoliv pouze karetních dat, ale i samotných systémových komponent, které tato externí instituce spravuje. Součástí procesu pravidelných kontrol by měla existovat dohoda o co nejmenším počtu aktivních účtu pro účely externí správy.
5.4 Zavedení důkladných opatření pro kontroly přístupů Oblast kontrol přístupů obsahuje 2 třídy poţadavků, které se zaměřují na přidělování jedinečných identifikátorů a omezení fyzických přístupů k datům drţitelů karet. Požadavek č. 8 - Přidělení jedinečného ID každé osobě s přístupem k počítači Ačkoliv je poţadavek č. 8 primárně postaven na poţadavcích pro řízení uţivatelských účtů a hesel, tak z mého pohledu je důleţité nejprve zajistit vytvoření politiky informační bezpečnosti. Tato politika by kromě jiného měla obsahovat popis způsobu, jak ţádat o přidělení ID do kritických systému a do systému řízení hesel. Přidělení jedinečné identifikace zajistí, aby kaţdý z pracovníků byl jedinečně zodpovědný za veškeré své aktivity v konkrétním systému. Zavedením takového procesu zajistíme, ţe aktivity mající vliv na karetní data jsou prováděny autorizovanými uţivateli, které je moţné vysledovat. V systémových komponentách by měla existovat jednoznačná identifikace uţivatele, jakékoliv sdílení účtu doporučuji zakázat. Typy na implementaci: - Kaţdému z uţivatelů (přistupujícím k systémovým komponentám nebo datům drţitelů karet) přidělit jedinečné ID;
55
- Implementovat dvou-faktorovou autentifikaci v případě vzdáleného přístupu zaměstnanců, správců sítě nebo jiných třetích stran do síťového perimetru v našem scope; - Zabezpečit, aby veškerá hesla do systémových komponent byla nečitelná během přenosu a zajistit jejich ukládání pomocí odolné kryptografie; - Zajistit proces na ověření totoţnosti uţivatele před resetem hesla; - Nastavit hesla pro nové uţivatele na jedinečnou hodnotu. Zároveň by systémová komponenta měla vyţadovat změnu hesla po prvním přihlášení uţivatele. - Odstranit nebo deaktivovat účty neaktivních uţivatelů nejméně jednou za 90 dní. - U přístupových hesel by měly být zajištěny minimálně následující poţadavky: - délka hesla nejméně 7 znaků; - pouţití hesel obsahujících numerické a alfabetické znaky; - zajištění, aby systémová komponenta poţadovala změnu hesla po 90 dnech. - zajištění,
aby
systémová
komponenta
neumoţnila
změnu
hesla,
které jiţ bylo uţivatelem ve stejném tvaru jednou pouţito. - Omezení opakovaných pokusů o přístup do systémové komponenty uzamčením uţivatelského účtu po více jak 6ti neúspěšných pokusech. Doba blokace účtu by měla být nastavena minimálně na 30 min. - Systémová komponenta by měla vyţadovat opětovné přihlášení uţivatele po 15 minutách nečinnosti. Demonstrace implementace požadavku č. 8 na modelových příkladech: Poţadavek č. 8 bezprostředně navazuje na řízení přístupových účtů dle poţadavku č. 7. V této chvíli je třeba nastavit bezpečnostní úroveň autentifikace oprávněných účtů do systémových komponent dle poţadavku na řízení přístupů uvedený v tipech výše. V případě obchodního řetězce se jedná primárně o pracovníky prodeje minimarketů (segment A1 na obrázku č. 4), supermarketů (segment D1) a jejich autentifikačních údajů do svých stanic. Všechny stanice mají lokální účty, kde je třeba nastavit politiku hesel lokálně. U politiky hesel doporučuji vyţadovat délku hesla nezbytnou pro zajištění souladu s PCI DSS. Délka hesla delší neţ poţadovaných 7 znaků můţe být kontraproduktivní. Můţe
56
nastat situace, ţe si je pracovníci budou vzhledem k sloţitosti hesel jejich znění poznamenávat a vystavovat na veřejném místě. Lokální politika hesel by měla dále zajišťovat, ţe nebude povolena změna hesla, které jiţ bylo ve stejném tvaru zadáno a dále, aby byla poţadovaná jeho změna po 90 dnech. Nyní k hotelu. Zde se primárně zaměříme na jiţ zmiňované webové rozhraní pro komunikaci se SBS serverem (segment E3 na obrázku č. 5). Toto rozhraní lze pouţít i pro úpravu údajů o klientech a samozřejmě i PAN, tj. kromě důvěrnosti můţe být narušena i jejich integrita. Je tedy důleţité, aby přístup k rozhraní splňoval poţadavky poţadavku č. 8. Na recepčních PC tedy bude existovat dvojí forma autentifikace, jednak do PC a pak do webového rozhraní pro přístup k databázi PAN na SBS serveru. Pokud jde o přístupy do jednotlivých recepčních PC, zde by šlo vyuţít pouţité platformy operačního systému na tomto serveru. SBS server běţí na platformě Windows Server s podporou active directory72. V tomto případě doporučuji vytvořit doménovou politiku v rámci active directory pro veškeré recepční PC. Takto lze pohodlně
řídit
restrikce
a
nastavení
všech
doménovým
účtům
z jednoho
místa, tj. na úrovni SBS serveru. Požadavek č. 9 - Omezení fyzického přístupu k datům držitelů karet Pro zajištění tohoto poţadavku bychom měli v první části monitorovat fyzický přístup do oblastí, kde se pracuje s karetními daty a zároveň mít nastavené procesy evidence těchto přístupů. Toto se primárně týká externích zaměstnanců a návštěvníků, u kterých bude nutné zajistit procesy zamezující nekontrolovanému či nepozorovanému pohybu v karetním prostředí. Taková aktivita můţe významně zvýšit riziko moţného úniku karetních dat či sníţení míry bezpečnosti v tomto prostředí. Pro řešení druhé části poţadavku č. 9 bychom se měli zaměřit na fyzickou bezpečnost médií, která obsahují data o drţitelích karet, ve smyslu jejich distribuce, ukládání a likvidace. Typy na implementaci: - Zajištění pouţívání odpovídajících vstupních kontrol (např. čtečky přístupů) do karetního prostředí;
72
Active Directory (nebo také doménový kontrolér) - komponenta platformy Microsoft Windows Server, která administrátorům umoţňuje nastavovat politiku, instalovat programy na mnoho počítačů nebo aplikovat kritické aktualizace v celé struktuře instituce. Active Directory ukládá své informace a nastavení v centrální organizované databázi.
57
- Monitorování fyzických přístupů do místností a sálů, kde se nacházejí kritické systémy. Tento monitoring by měl probíhat prostřednictvím kamer, kde doba uchování záznamů by neměla být kratší neţ 3 měsíce; - Omezení fyzického přístupu k síťovým přípojkám, prostřednictvím nichţ se lze infiltrovat do sítě. Doporučuji se správci sítě konzultovat moţnost aktivování těchto přípojek pouze za předpokladu předem schválené písemné ţádosti; - Jasně odlišit zaměstnance a návštěvníky. Návštěvníci by měli být označeni visačkami s nápisem „visitor/návštěvník“; - Před vstupem návštěvníka do karetního prostředí by měla proběhnout nejprve jeho autentifikace (např. předloţením občanského průkazu) a následně by mohl vstoupit do karetního prostředí; - Pohyb návštěvníka v karetním prostředí by měl probíhat pouze v doprovodu odpovědného pracovníka; - Kontrola fyzické bezpečnosti místa, kam se ukládají zálohovací média, papírové dokumenty nebo účtenky obsahující data drţitelů karet; - Záloţní média klasifikovat a označit jako „důvěrná/confidental“. Důvodem je jasná identifikace citlivosti uloţených dat drţitelů karet; - Posílat záloţní média prostřednictvím bezpečného kurýra nebo jinou dodávkovou metodou, která můţe být přesně sledována. Výjimkou je, pokud je PAN obsaţený na těchto médiích učiněn nečitelným pomocí jedné z následujících metod: - maskováním (ponechání pouze posledního čtyřčíslí z PANu); - pouţitím odolné kryptografie. - Udrţovat přísnou kontrolu nad přístupností a ukládáním médií; - Zničit média a papírové dokumenty obsahující data drţitelů karet, pokud jiţ nejsou potřeba z provozních nebo legislativních důvodů.
58
Demonstrace implementace požadavku č. 9 na modelových příkladech: U obchodního řetězce, konkrétně u části supermarketu (segment D2 na obrázku č. 4) evidujeme dvě oblasti fyzické bezpečnosti, na které je třeba se z pohledu poţadavku č. 9 zaměřit. První oblastí je systém recepce, kterou si lze představit jako vnější bezpečnostní bariéru proti případnému neautorizovanému vstupu do karetního prostředí. U recepce se v první řadě doporučuji zaměřit na vstupní kontroly. Nejprve provést evidenci návštěvy v knize návštěv. Dále vydat standardní návštěvnickou kartičku, kterou bude mít návštěvník umístěnu na viditelném místě po celou dobu jeho návštěvy. Následně recepcí telefonicky uvědomit odpovědného pracovníka o příchodu návštěvy a poţádat o vyzvednutí návštěvníka na recepci. Teprve v doprovodu odpovědného pracovníka můţe návštěvník vstoupit do karetní oblasti. Odpovědný pracovník by se měl snaţit nespustit návštěvníka z dohledu a dohlíţet na jeho aktivity po celou dobu jeho přítomnosti v karetní oblasti. Účelem tohoto dohledu je v maximální moţné míře minimalizovat rizika spojená s neautorizovaným získáním dat drţitelů karet. Při odchodu návštěvníka by měla být provedena evidence zápisem do knihy návštěv společně s vrácením návštěvnické kartičky. Druhou oblastí jsou fyzické přístupy ke kritickému systému (segment D4 na obrázku č. 3), které by měly být omezeny na minimální mnoţství pracovníků. Prostory, kde se kritický systém nachází, musí být monitorovány a doba uchovávání záznamu by měla dosahovat nejméně 3 měsíců. Z pohledu systémových komponent je třeba dále zajistit fyzickou bezpečnost firewallu (segment B 3 na obrázku č. 3) a routeru (segment D3). Hlavním úkolem bude zvolit vhodnou formu fyzické ochrany tak, aby se minimalizoval přístup k síťovým přípojkám u těchto zařízení. Můţeme hovořit o zamknutí těchto komponent do samostatné místností osazené čtečkou přístupových karet nebo jejich umístění do bytelného a uzamykatelného racku. Poslední věcí bude zaměřit se na pohyb a úschovu fyzických a papírových dokumentů obsahujících PAN. Konkrétně se jedná o obchodnické účtenky z POS. Tyto účtenky jsou pravidelně sváţeny z maloobchodních prodejen do supermarketu a zde se ukládají na bezpečném místě v trezoru (segment D3 na obrázku č. 4). Takto zvolená forma je z pohledu PCI DSS vyhovující. Opět zde platí, ţe přístup do trezoru by měl mít pouze nezbytně nutný počet pracovníků.
59
U hotelu bychom měli nastavit stejný reţim recepce, jako u obchodního řetězce. Kritický rezervační systém běţící na SBS serveru (segment E3 na obrázku č. 6) je nutné umístit do oddělené místnosti opět monitorované kamerovým systémem s dobou ukládání minimálně 3 měsíců. Dále zde máme router/AP (segment C3 na obrázku č. 6), zde je třeba opět zajistit jeho umístění ideálně v samostatné místnosti, případně v racku. Situace se můţe komplikovat tím, ţe router je rovněţ AP. Existuje zde spíše provozní riziko, ţe při separaci AP do oddělené místnosti by radiové záření tvořící bezdrátový parametr nemuselo přejít přes zeď. Toto je samozřejmě spíše okrajový problém. Z pohledu ukládání fyzických dokumentů pracovníci hotelu ukládají veškerou citlivou dokumentaci (podobně jako u supermarketu) do trezoru. Mezi tuto dokumentaci se řadí faktury za ubytování, obchodnické účtenky z POS a příleţitostně i platební karty, které hoteloví hosté během svého ubytování na pokojích zapomněli.
5.5 Pravidelné monitorování a testování infrastruktury Pátá oblast implementace je reprezentovaná 2 třídami poţadavků. Tyto poţadavky se zaměřují na monitorování aktivit nad kritickými zařízeními a provádění různých typů testů s cílem odhalit slabá místa v infrastruktuře. Požadavek č. 10 - Monitoring a sledování přístupů k síťovým zdrojům a datům držitelů karet Důleţitou součástí zajištění bezpečnosti dle PCI DSS je zaznamenávání a vyhodnocování aktivit uţivatelů v systémových komponentách s cílem odhalit události, které by mohly bezpečnost ohrozit. Bezpečnostní monitoring je jedním z důleţitých prvků systému řízení rizik nad karetní oblastí. Schopnost sledovat činnost pracovníků má rozhodující význam pro prevenci, detekci a minimalizaci dopadů průniků do karetního prostředí. Na tomto místě je příhodné zdůraznit, ţe implementace monitorovacích nástrojů představuje pro většinu institucí velkou výzvu. Často se stává, ţe tyto nástroje jsou nastavené špatně, neefektivně nebo ţe jsou vyhodnocovány mylné události tzv. „false-positive73“. Můţe se rovněţ stát, ţe přemíra false-positive událostí můţe operátora přetíţit a ten poté ztrácí schopnost se v událostech orientovat. V takových situacích není operátor schopen události správně interpretovat a můţe nastat situace, ţe přehlédne skutečný incident. Z těchto důvodů
73
Situace, kdy je korektní aktivita v systému z nějakého důvodu povaţována za bezpečnostní incident.
60
doporučuji zváţit najmutí externí firmy, která zajistí implementaci a hlavně konzultaci nad otázkami kolem procesní části řešení. Typy na implementaci: - Implementovat automatizovaný monitoring na sledování aktivit uţivatelů, který bude vyhodnocovat minimálně následující události: - všechny individuální přístupy k datům drţitelů karet; - všechny aktivity prováděnými administrátory; - veškeré přístupy k logům, které generuje automatizovaný monitorovací nástroj; - neplatné pokusy o logický přístup do systémových komponent; - mazání a vytváření objektů na systémové úrovni; - Synchronizovat čas ve všech systémových komponentách a kritických zařízeních. Lze vyuţít protokol pro synchronizaci síťového času NTP74; - Uchovávat historii auditních logů alespoň po dobu 1 roku s tím, ţe po dobu nejméně třech měsíců budou okamţitě k dispozici pro forenzní analýzu. Demonstrace implementace požadavku č. 10 na modelových příkladech: U poţadavku č. 10 budeme mít situaci u obou obchodníků z pohledu scope jednoduchou, protoţe se zaměříme pouze na zabezpečení kritických systémů. Avšak jak jsem jiţ zmínil v obecném povídání u poţadavku č. 10, implementace systému monitoringu událostí není záleţitostí jednoduchou a vyţaduje podporu zkušeného konzultanta. V případě hotelu tedy budeme implementovat monitoring na úrovni souborového serveru a u obchodního řetězce na úrovni SBS serveru. Tento výběr má své opodstatnění, jelikoţ na ostatních stanicích se data drţitelů karet neukládají a veškeré operace s karetními daty probíhají aţ na úrovni kritického systému, byť řízení můţe probíhat z uţivatelských stanic. Je však důleţité, aby všechny systémové komponenty měly synchronizovaný čas nejlépe pomocí NTP protokolu. Monitorovací software by měl být nastaven tak, aby zaznamenával veškeré přístupy do kritického systému, aktivity administrátorů nad kritickým systémem
74
Network Time Protokol - Protokol pro synchronizaci času.
61
a neplatné pokusy o logický přístup. Veškeré záznamové logy by měly být uchovávány po dobu nejméně 3 měsíců, a to nejlépe na jiném místě, neţ je kritický systém. Požadavek č. 11 - Pravidelné testování bezpečnostních systémů a procesů Abychom splnili poţadavek č. 11, měli bychom demonstrovat, jak IT pracovníci pravidelně testují perimetr naší sítě. Několikrát zmiňovaný čtvrtletní sken zranitelnosti, který se zaměřuje na testování průniku z vnějšku do našeho scope, je zde vyţadován. Poţadavek č. 11 se obecně zaměřuje na různé typy bezpečnostních kontrol vnějšího a vnitřního síťového perimetru tak, aby pravidelně odráţely měnící se infrastrukturu. Veškeré nálezy z těchto bezpečnostních testů a skenů by měly být řešeny v rámci standardních incident management procesů. Typy na implementaci: - Testovat přítomnost AP minimálně na čtvrtletní bázi, a to jak autorizovaných, tak neautorizovaných; - Provádět interní skeny zranitelnosti síťové infrastruktury v našem scope. Proaktivní identifikace
a
odstraňování
zranitelností
sniţuje
pravděpodobnost
potencionálního
kompromitování systémových komponent nebo dat drţitelů karet; - Provádět externí sken zranitelnosti. Toto skenování musí být prováděno prostřednictvím ASV, a to nejméně jednou za měsíc a zároveň po významných změnách infrastruktury; - Provádět penetrační testy zaměřené na průnik do síťové a aplikační vrstvy síťových komponent. Cílem penetračních testů je simulace útoku útočníků s cílem zjištění, jak hluboko do karetního prostředí by se útočník mohl dostat. Tímto způsobem lze získat lepší porozumění o potencionální míře rizika spojené s aktuálním provozovanými bezpečnostními opatřeními; - Pouţití systémů detekce a průniku do systémových komponent s včasným varováním bezpečnostnímu personálu o potencionálním narušení bezpečnosti; - Pouţití specializovaného software pro sledování integrity souborů obsahujících data drţitelů karet před jejich neautorizovanými modifikacemi (např. jiţ zmiňovaný whitelisting).
62
Demonstrace implementace požadavku č. 11 na modelových příkladech: Veškerá infrastruktura by měla být kontrolována prostřednictvím interních a externích skenů zranitelnosti a penetračních testů, a to u obou modelových obchodníků. Externí sken zranitelnosti by se v případě obchodního řetězce měl zaměřit na veřejné IP adresy všech systémových komponent, které se nacházejí v podnikové LAN (segment D3 na obrázku č. 3). Výhodou externích skenů je, ţe se nemusí provádět na místě, ale kdekoliv, kde se ASV připojí k internetu. Pokud se podíváme na část minimarketů, zde se rovněţ klade otázka, zda externí sken aplikovat. Jak jsem jiţ uvedl u poţadavku č. 4, POS a samoobsluţné terminály vyuţívají šifrování komunikace prostřednictvím SSL/TLS. Šifrovaný tunel je tvořen naaplikační vrstvě terminálů a ukončen aţ v autorizačním centru. I kdyby útočník komunikaci odchytl, tak z ní bez relevantního privátního klíče nic nevyčte. Zde tedy riziko neevidujeme, a proto ani sken neaplikujeme. Externí skeny zranitelnosti doplní jejich interní varianta, pomocí které budeme testovat interní perimetr sítě. Pro tyto účely lze vyuţít software typu např. Nessus nebo Spider Scan. Společně s interními skeny zranitelnosti bychom jednou ročně měli na celou infrastrukturu obchodního řetězce aplikovat penetrační testy. U tohoto typu skenů ale upozorňuji, ţe jejich provedení je časově a hlavně výkonnostně velmi náročné. Před jejich provedením je na místě provést analýzu kritických obchodních procesů a skenování časově naplánovat tak, abychom se v maximální míře vyhnuli ovlivnění chodu infrastruktury a systémů. V případě hotelu mohu konstatovat stejná doporučení jako u obchodního řetězce. Je zde pouze jeden jediný rozdíl, a to je v rozsahu provedení externích skenů zranitelnosti. Infrastruktura hotelu je unikátní tím, ţe veškeré systémové komponenty v podnikové síti jsou skryty za NAT, který je nastaven na routeru/AP (segment C3 na obrázku č. 5). Tudíţ existuje pouze jedna jediná veřejná IP adresa viditelná z internetu. Právě tuto IP adresu prověříme externím skenem. Případné nálezy z bezpečnostních skenů doporučuji řešit v rámci standardních procesů incident managementu. Pro účely auditu je důleţité, abychom byli schopni předloţit aktuální zprávy ze všech poţadovaných typů skenů s uvedením všech systémových komponent a u nich nalezených zranitelností.
63
5.6 Udržování pravidel informační bezpečnosti Poslední oblastí implementace je udrţování pravidel informační bezpečnosti. Jedná se o oblast čistě procesní s cílem udrţování silné bezpečnostní politiky instituce. Požadavek č. 12 - Pravidla bezpečnosti informací pro zaměstnance a dodavatele Podstatou poţadavku č. 12 je udrţování pevné bezpečnostní politiky v celé společnosti a seznamovat personál s tím, co po nich PCI DSS vlastně vyţaduje. Bezpečnostní politika je základní pilíř, na kterém stojí ISMS dle PCI DSS. Její kvalitní definice je velice důleţitá. Za předpokladu, ţe nejsou jednoznačně definovány odpovědnosti klíčových rolí a zaměstnanců instituce, pak můţe nastat v systému budování informační bezpečnosti zmatek. Samotný ISMS by měl být vystavěn na stabilních základech, kde propracovaná bezpečnostní politika hraje klíčovou roli. Tvorba a řízení bezpečnostní politiky pokrývá převáţnou část poţadavku č. 12, zbylá část se zaměřuje na řízení vztahů s dodavateli a pravidelném školení zaměstnanců. Typy na implementaci: - Provádět pravidelné procesy risk managementu (viz kapitola č. 4.3); - Vytvoření, udrţování, šíření a zveřejnění bezpečnostních pravidel všem zaměstnancům instituce. Záměrně hovořím o instituci, nejenom pouze o karetním prostředí. Důvodem je, ţe bezpečnostní politika vyţadovaná PCI DSS by měla korespondovat s bezpečnostní politikou celé instituce; - Vypracovat
pravidla
pro
správné
pouţívání
koncových
technologií,
jako např. pro flashdisky, PDA asistenty, laptopy, atd; - Přidělení odpovědnosti za řízení informační bezpečnosti konkrétnímu pracovníku nebo týmu; - Zavést program pro šíření bezpečnostního povědomí o bezpečnosti karetních dat. Součástí tohoto programu by mělo být kaţdoroční přezkoušení všech zaměstnanců pracujících v karetním prostředí; - Vytvořit postupy prověrek potencionálních zaměstnanců. Jako příklad takové prověrky můţe být poţadavek na dodání výpisu z čistého rejstříku, či dodání referencí od předchozích zaměstnavatelů;
64
- V případě, ţe jsou karetní data sdílena s poskytovateli sluţeb, dodavateli a dalšími externími subjekty, kteří mohou ovlivnit bezpečnost karetních dat, pak je třeba smluvně zajistit jejich hmotnou a finanční odpovědnost za bezpečnost karetních dat. - Vytvořit a dodrţovat pohotovostní plán pro případ incidentu. Cílem je mít nastavené procesy tak, abychom byli schopni efektivně a hlavně bez zbytečného prodlení reagovat na incident spojený s karetními daty. Demonstrace implementace požadavku č. 12 na modelových příkladech: Primárním a neodmyslitelným poţadavkem vycházejícím z poţadavku č. 12 bude vytvoření bezpečnostní politiky, která bude všem pracovníkům, kteří se v karetním prostředí pohybují, jednoznačně definovat, co smí a co ne. Tato bezpečnostní politika by měla být v synergii s programem informačního povědomí o PCI DSS, u kterého je důleţité zvolit vhodnou formu šíření informací pracovníkům. Ze své zkušenosti doporučuji zvolit formu prezentace. Lze tak vytvořit interaktivní prostředí mezi pracovníky a zároveň prostor vysvětlení nejasných oblastí kolem bezpečnostních poţadavků. Na roční bázi je důleţité ověřit, zda zaměstnanci plně porozuměli základním poţadavkům pro ochranu karetních dat, které vycházejí ze samotného programu informačního povědomí. Vhodná forma testování je např. elearningový test, případně test ústní. Dalším neméně důleţitým poţadavkem bude zajistit přenesení hmotné a finanční odpovědnosti za bezpečnost karetních dat na dodavatele, kteří ke karetním datům přistupují nebo mohou ovlivnit jejich bezpečnost. U obchodního řetězce se jedná jednak o společnost, která poskytuje sluţby webového hostingu, kde obchodnímu řetězci běţí e-commerce portál (segment B1 na obrázku č. 5) a dále pak autorizační centrum (segment C5). U hotelu se rovněţ jedná o autorizační centrum (segment A3 na obrázku č. 6) a dále o IT servisní instituci (segment C1). Kromě toho, ţe smluvní odpovědnost byla na tyto dodavatele přenesena, je rovněţ vhodné na tyto dodavatele vyvinout tlak, aby si v co nejkratší době zajistili svůj soulad s PCI DSS.
65
5.7 Implementační roadmapa Předtím, neţ se v projektu pustíme do samotné implementace, je vhodné si stanovit tzv. „implementační roadmapu“. Tuto roadmapu si můţeme představit jako výsledek z provedené analýzy nad poţadavky PCI DSS. Tato analýza nám pomůţe stanovit ty poţadavky PCI DSS, které jsou z hlediska míry rizika nejkritičtější, tj. ty, které bychom měli implementovat přednostně. Diagram č. 3 - Implementační roadmapa Risk
Milník
Cíl
Kritické poţadavky
1. Odstranění citlivých ověřovacích dat a omezení ukládání dat držitelů platebních karet
Snížení míry závažnosti klíčových rizik spojených s ukládáním dat, jež v karetním odvětví způsobily nejvíce incidentů. Stěžejním kamenem tohoto milníku je provedení analýzy rizik
2. Ochrana síťového perimetru (vč. perimetru bezdrátové sítě)
Snížení míry závažnosti rizik na koncových a vstupních bodech do síťového perimetru karetního prostředí
3. Zabezpečení platebních aplikací
Nastavení bezpečnostních kontrol a opatření pro ochranu aplikací, které pracují s karetními daty
4. Monitoring a kontrola přístupů do kritických systémů
Monitoring aktivit uživatelů v kritických aplikacích + kontrola přidělování přístupových práv do systémů, které pracují s karetními daty
Poţadavky s niţší prioritou
5. Zabezpečení dat držitelů karet
6. Udržování pravidel informační bezpečnosti
Nastavení bezpečnostních mechanismů pro ukládání dat držitelů karet
Nastavení politik zacházení s karetními daty vč. edukace uživatelů, kteří s těmito daty pracují
Implementační pořadí
12.1.1, 3.2, 9.10, 1.1.2, 3. 2
12.1, 12.8, 1.1.3, 1.2, 1.3, 9.1, 2.1, 2.3, 4.1, 4.2, 5.1, 5.2, 1.4 , 11.2, 11.3, 11.4
12.1, 2.2, 6.1, 6.2, 6.3, 6.5, 6.4, 6.6, 2.4
7.1, 7.2, 11.1, 11.5, 8.1, 8.2, 8.3, 8.4, 8.5, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 12.1, 12.5, 12.9
3.3, 3.4, 3.5, 3.6, 9.9, 12.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8
1.1, 6.4, 12.3, 12.4, 12.5, 12.6, 12.7, 12.1, 12.2
Zdroj: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_PCI_DSS_1_2.pdf [cit. 13. 10. 2012]; vlastní úpravy.
Výše uvedený diagram č.3 zobrazuje implementační roadmapu, s jejíţ pomocí budeme schopni plánovat implementaci nápravných opatření dle PCI DSS. Tuto roadmapu jsem
66
vytvořil na základě doporučení PCI-SSC75 a mých zkušeností z praxe. Výhodou této roadmapy je podpora finančního a operativního plánování v rámci projektu a tvorba srozumitelného jazyka kolem poţadavků PCI DSS. Při implementační fázi projektu nebo jejím plánování doporučuji postupovat kaskádovitě dolů dle sloupce „Implementační pořadí“, kdy zpravidla a logicky začínáme jiţ zmíněnou analýzou rizik.
75
Payment Card Industry Security Standards Council. PCI SSC je globální fórum a normotvorná instituce pro PCI standardy.
67
6 Finalizace projektu Po implementační fázi projektu zbývá uţ jen jeho finalizace, kterou můţeme rozdělit do třech souvisejících a návazných částí: - prokázáním souladu s PCI DSS; - formálním ukončením PCI projektu; - nastavením procesů na udrţování souladu s PCI DSS. Tato projektová fáze je nesmírně důleţitá zejména proto, ţe v části prokázání souladu deklarujeme výsledky celého našeho implementačního snaţení. Neméně důleţité je i následné uzavření projektu společně s nastavením procesů udrţování souladu s PCI DSS. Obě tyto fáze spolu úzce souvisejí a mají za cíl zejména zajistit podporu vedení instituce pro nastartování pravidelných procesů ochrany karetních dat. Uvedeným třem částem se detailněji věnuji v následujících kapitolách.
6.1 Prokázání souladu s PCI DSS Za účelem deklarace plného souladu s PCI DSS musí kaţdá instituce podstoupit kaţdoroční assessment, který zjišťuje, zda jsou bezpečnostní opatření správně implementovaná a fungují efektivně. Typ assessmentu závisí na typu instituce a počtu transakcí platebních kartou za rok od čehoţ se odvíjejí i validační kritéria definovaná asociacemi (viz příloha č. 1). Obecně jsou rozeznávány dvě metody prokázání souladu: - provedení assessmentu prostřednictvím externího QSA na roční bázi (výstupem je RoC76); - sebehodnocení shody s PCI DSS (výstupem je SAQ77) prostřednictvím interních specialistů bezpečnosti. V případě nedodrţení těchto validačních kritérií mohou být instituce ze strany asociací sankcionovány. Tyto sankce ze strany asociací mohou existovat v několika podobách: - zvýšení poplatků za karetní zpracování;
76 77
Auditní zpráva z provedeného on-site assessmentu, kterou vytváří QSA. Self-Assessment Questionaire - dotazník vlastního ohodnocení oproti PCI DSS.
68
- penalizace za nesplnění validačních kritérií; - penalizace za únik či zneuţití karetních dat (pokud asociace zjistí, ţe v době incidentu nebyla instituce v souladu s PCI DSS); - ztráta licence na provozování karetního zpracování. Jak bylo zmíněno výše, soulad s PCI DSS se prokazuje prostřednictvím provedení assessmentu nebo sebehodnotící shody. V určitém pohledu se tak opět vracíme do analytické fáze projektu, kdy byla provedena Gap analýza pouze s tím rozdílem, ţe nálezy v této fázi identifikované jiţ byly odstraněny během implementace. Cílem assessmentu je tedy ověřit, ţe stav našeho karetního prostředí po implementační fázi projektu splňuje nezbytné minimum vyţadované PCI DSS. Toto nezbytné minimum se liší od instituce k instituci, kdy kaţdá z nich má jiné procesy, odlišné cesty toků karetních dat a celkově jinou infrastrukturu. Zároveň zde hraje významnou roli počet transakcí platební kartou za rok, který určuje onen typ assessmentu. Z projektového hlediska doporučuji provést následující kroky: - svolat další workshop s projektovým týmem a hodnotitelem. Na tomto workshopu dohodnout časování assessmentu, kapacitní zastoupení specialistů a další nezbytné náleţitosti (přístupy k systémům, místnost na konzultace, atd.); - koordinovat zajištění nezbytných kroků přípravy auditu, které byly dohodnuty v rámci workshopu; - provést assessment; - vytvořit a vyplnit příslušný dokument (RoC nebo SAQ); - reportovat soulad asociacím a své zpracovatelské bance (za předpokladu dosaţení poţadovaného stupně souladu s PCI DSS). Samotný assessment by neměl být pojat pouze jako procházení jednotlivých poţadavků PCI DSS a zjišťování, zda je ta či ona konkrétní systémová komponenta nebo proces v souladu s PCI DSS. Tento postup lze povaţovat za nedostatečný a doporučuji jej doplnit o obecnější pohled na moţná rizika spojená s auditovanou systémovou komponentou. Cílem tohoto přístupu je identifikovat jiné vektory moţného útoku na bezpečnost karetních dat.
69
Důleţitou součástí assessmentu je jeho příprava. Je třeba zmínit, ţe celý proces je časově a kapacitně náročný a vyţaduje důsledné plánování ze strany projektového manaţera. V příloze č. 4 ukazuji typické rozloţení agendy PCI DSS assessmentu vč. zmínění obvyklé pracovní role, která by měla být hodnotiteli k dispozici při kontrole konkrétní oblasti. Jakmile je assessment dokončen, měl by hodnotitel vytvořit výstupní zprávu (ve formě RoC nebo SAQ), která by měla jasně popisovat způsob assessmentu, scope, kdo se na assessmentu podílel a hlavně stav našeho souladu karetního prostředí s PCI DSS. Tato zpráva je určena managementu instituce a pro účely deklarace souladu s PCI DSS zpracovatelské bance. Předání informací o výsledcích assessmentu by mělo být vnímáno jako otevřený a transparentní proces. Lze konstatovat, ţe skoro kaţdý auditní proces kromě nálezů zároveň identifikuje příleţitosti pro zlepšení, o kterých by měl být zejména management jasně informován. Často při finálním assessmentu nastává situace, ţe jsou identifikovány další nálezy, které nebyly během Gap analýzy identifikovány. Tato situace není nijak výjimečná a je třeba, aby tyto nálezy byly v auditní zprávě jasně popsány. Cílem projektového manaţera by mělo být zajištění řádné analýzy těchto nálezů a urychlené provedení jejich nápravy.
6.2 Formální ukončení projektu Lze uvaţovat o ukončení projektu za předpokladu, ţe jeho cíle byly dosaţeny. V našem případě jde především o zajištění souladu s PCI a následné předání informace o dosaţení souladu zpracovatelské bance. Z projektového hlediska je důleţité, aby ukončení projektu proběhlo formálně. Touto cestou se eliminuje nebezpečí vzniku dalších nových poţadavků na projektový tým nebo jeho část. Nedílnou součástí bude vyhodnocení celého projektu, coţ pomůţe vytěţit z projektu a jeho průběhu pro instituci maximum. Toto vyhodnocení by mělo být zpracováno do závěrečné zprávy o projektu pro management, ve které by měly být mimo jiné zmíněny dvě podstatné věci: - revalidace souladu s PCI DSS probíhá na roční bázi a je jí tedy nutné zohlednit v budoucím projektovém portfoliu;
70
- řízení bezpečnosti dle PCI DSS je kontinuální proces. Aby byla zajištěna patřičná úroveň bezpečnosti a aby instituce byla schopná efektivně reagovat na případné incidenty, je třeba zajistit pravidelné mimo projektové procesy řízení bezpečnosti. V závěrečné zprávě o projektu je tedy důleţité zmínit rizika, odhad nákladů a kapacit nutných pro tyto mimo projektové aktivity. Cílem je získat od managementu potvrzení, ţe proces udrţování souladu s PCI DSS bude v budoucnu pokračovat.
6.3 Udržování souladu s PCI DSS Jak jsem jiţ uvedl dříve, implementování nápravných opatření za účelem dosaţení souladu s PCI DSS je pouze začátkem celého procesu. Udrţování souladu s PCI DSS vyţaduje, aby instituce
přijala
nekompromisní
bezpečnostní
opatření,
která
jsou
udrţována,
monitorována a permanentně zlepšována. Ačkoliv je soulad s PCI DSS revidován na roční bázi, lze si představit, kolik změn architektury a infrastruktury proběhne během roku. Na příkladu monitoringu kritického systému lze demonstrovat poměrně jasnou linii mezi implementací, řízením rizik a udrţováním souladu s PCI DSS. Jednoduše řečeno, poţadavkem PCI DSS je, aby se implementoval monitorovací nástroj, který bude sledovat aktivitu uţivatelů v kritickém systému. V rámci procesu řízení rizik vybereme, které aktivity jsou rizikově významné a měly by být monitorovány a které nikoliv. V posledním kroku, tedy udrţování souladu s PCI DSS, nastavíme pravidelný proces vyhodnocování. Obecně při zvaţování způsobu, jak pojmout udrţování souladu s PCI DSS doporučuji začít s tzv. mapováním. Mapování je princip, který nám poskytne klíčové detaily o: - poţadavku PCI DSS - tj. přesné znění poţadavku, který je s pravidelnou aktivitou spojen‚ např. jiţ zmíněné skenování zranitelnosti (poţadavek č. 11.2); - frekvenci - tj. indikaci, jak často by se aktivita měla provádět (opět, v případě skenů zranitelnosti to je jednou za 3 měsíce); - akci - tj. indikaci způsobu a místa provedení (v případě externích skenů zranitelnosti jsou to veřejné IP adresy pouţívané v místě instituce); - vlastníkovi - tj. indikaci, kdo je na provedení aktivity alokován; - popisu - tj. poskytnutí doplňujících informací týkajících se plánované aktivity.
71
Výstup z mapování nám poskytne jasný přehled o tom, jaké aktivity je třeba provádět, jak často a kdo by měl být za jejich provedení zodpovědný. Tento přehled je uţitečný zejména pro účely operativního plánování a alokaci zdrojů. Opět platí, ţe by management měl být s těmito výstupy seznámen. Pochopení managementu, proč je nutné soulad s bezpečnostními normami udrţovat není vţdy jednoduchou úlohou. Primárním zájmem managementu většinou je zajistit soulad s regulatorními poţadavky a veškeré další aktivity spojené s řízením bezpečnosti jsou pojímány s nepatřičnou prioritou. Důvodem tohoto přístupu je fakt, ţe bezpečnost jako taková negereneruje finanční benefity. Proto získání podpory vedení pro řízení ISMS, přidělení dostatečných kapacit a finančního rozpočtu je obecně jednou z největších výzev celé informační bezpečnosti. Dobrou zprávou je, ţe se tento postoj pomalu, ale jistě mění s přibývajícími zprávami o útocích na citlivá data.
72
Závěr PCI DSS je standardem, který hraje důleţitou roli v obchodní sféře. Počet transakcí provedených platební kartou rok od roku roste a moderní metody elektronických plateb sniţují význam plateb hotovostních. Většina bezpečnostních norem je postavena na dobrovolné bázi a instituce si sami určují, jaká nápravná opatření se budou realizovat a jaká nikoliv. V tomto ohledu je PCI DSS normou, která přesně definuje obsah bezpečnostních opatření a rozsah scope. Problematika PCI compliance je známá jiţ několik let a je důleţitá z mnoha důvodů, kdy ţádný nepřevaţuje jiný. Kaţdý z těchto důvodů spadá pod jeden nebo dva základní pilíře - důvěra spotřebitele a bezpečné obchodní operace. Spotřebitelé vkládají velkou důvěru v ty, kteří pracují s jejich karetními daty v rámci jejich kaţdodenní obchodní rutiny. Ačkoliv většina z nás vyuţívá pohodlí spojené s dnešními formami elektronického obchodu, děláme tak s očekáváním, ţe transakce jsou vykonávány bezpečně. Pravdou je, ţe v dnešním světě spotřebitel bez větších problémů změní dodavatele platebních sluţeb, pokud není spokojen se zabezpečením svých citlivých informací. Tito dodavatelé si to dobře uvědomují a snaţí provádět obchodní operace v bezpečném prostředí. Na poţadavcích PCI DSS není nic nestandardního. Ačkoliv poţadavky tohoto standardu hovoří konkrétně, způsob jejich implementace je větší měrou odvislý od konkrétního prostředí. Stává se téţ, ţe se jeho výklad spojí s jistým nepochopením dokonce i u specialistů s praxí v informační bezpečnosti. Toto nepochopení můţe mít za následek zvýšené či duplicitní investice do bezpečnostních opatření, špatné nastavení kontrolních procesů a v konečném důsledku i neúspěch v dosaţení souladu s PCI DSS. Věřím, ţe tato práce představuje teoretický a praktický základ jak pro implementaci poţadavků PCI DSS, tak pro udrţování jeho souladu. Mým cílem bylo zaměřit se zejména na praktickou část implementace, kterou jsem doplnil o modelové příklady. Díky těmto modelovým příkladům bude čtenář schopen lépe pochopit podstatu jednotlivých poţadavků a představit si jejich vyuţití v konkrétní situaci.
73
Prvním kritériem pro zvolený typ modelových obchodníků byla odlišnost infrastruktury a procesů, které obchodníci provádějí. Tím byla čtenáři poskytnuta přidaná hodnota ve smyslu praktické demonstrace v odlišném obchodním a technickém prostředí. Druhým kritériem byla rizikovost obchodníka z pohledu četnosti útoků na karetní data. Oba modelové případy spadají do kategorie spíše menších obchodníků, kde případná ztráta nebo únik karetních dat můţe vyústit aţ v úpadek celé instituce. Tito menší obchodníci většinou představují pro útočníky snadné cíle, protoţe mají omezené zdroje, nedostatek pracovníků s hlubšími technickými znalostmi a jejich hlavní aktivity se zaměřují primárně na udrţení profitability. Tato fakta mají za následek neřízenost informačních rizik, nedostatečnou bezpečnostní kulturu a tudíţ značnou náchylnost k bezpečnostním incidentům. Tímto druhým kritériem shrnuji důleţitost implementace ISMS vycházejícího z PCI DSS u této skupiny obchodníků. Z pohledu výkladu PCI DSS směrem k obchodníkům pociťuji určitý nesoulad. Na jednu stranu asociace kontinuálně zpřísňují validační kritéria pro obchodníky, coţ je vzhledem k narůstající četnosti útoků logickým krokem, na druhou stranu nedostatečně vysvětlují důleţitost celé problematiky. Zejména ne zcela souhlasím se způsoby podávání informací o celé problematice PCI standardů a dále s konkrétními doporučeními, jak zahrnout poţadavky PCI DSS do bezpečnostní kultury instituce. Faktem je, ţe odvětví platebních karet nedokáţe efektivně vstřebat celou problematiku PCI standardů vzhledem k jejich sloţitosti v takovém časovém horizontu, jak by si asociace představovaly. Mým osobním názorem je, ţe doporučený postup by měl být v systematickém doporučování implementace jednotlivých poţadavků PCI DSS a dle těchto doporučení následně validační kritéria definovat. Zmíněná doporučení by měla vycházet z expertního odhadu závaţnosti jednotlivých rizik dle PCI SSC s ohledem na informace o aktuálních formách kybernetických napadení, které mají asociace k dispozici. Abych uvedl konkrétní příklad, prvním takovým doporučením ze strany asociací by mohlo být provedení redukce scope, tj. omezení výskytu dat o drţitelích karet v systémech na minimum a zváţení příslušné úrovně síťové segmentace. Následně na těchto doporučeních stanovit závazný mandát a poskytnout institucím dostatečný čas na jeho splnění.
74
Nicméně realitou dneška jsou poţadavky na zajištění plného souladu s PCI DSS ze strany asociací, coţ zejména pro menší obchodníky představuje mnohdy nadlidský úkol. To má za následek určitý odpor k celé problematice informační bezpečnosti nehledě na jiţ zmíněný fakt, ţe obchodníci většinou nemají znalosti o informační bezpečnosti, natoţ o PCI DSS. V důsledku toho si odmítají zajistit finančně nákladné konzultace od externích konzultantů nebo QSA a raději akceptují riziko, ţe incident nastane, neţ aby problematiku PCI DSS aktivně řešily. Pokud bych měl shrnout důleţitost jednotlivých kapitol této práce, nelze říci, ţe některá svojí důleţitostí převyšuje jinou. Nicméně zejména z pohledu implementace a udrţování souladu s PCI DSS bych vyzdvihl kapitolu č. 4.3 „Provedení analýzy rizik“, jakoţto nejdůleţitějšího poţadavku celého standardu. Jak jiţ bylo naznačeno v úvodní kapitole, cílem této práce bylo popsat způsob, jak projektovou cestou zajistit soulad s PCI DSS. Tento úmysl byl směrován zejména na demonstraci na modelových případech. Jsem přesvědčen, ţe se mi tento cíl podařilo splnit. Ačkoliv jsem pro účely této práce vybral jako modelové příklady dva typy obchodníků, můţe být tato práce vodítkem zajištění souladu s PCI DSS i u ostatních organizací, jako jsou banky nebo různí poskytovatelé sluţeb s přístupem ke karetním datům.
To je
důvod,
proč jsem v úvodu kaţdé z kapitol nejdříve popsal problematiku a doporučení obecně pouţitelná pro všechny relevantní instituce. Závěrem si na základě vlastní praxe dovolím konstatovat, ţe úroveň informační bezpečnosti v institucích pomalu roste. Důvodem je uvědomění si skutečnosti, ţe informace jsou a stále budou nejcennějším aktivem, které si zaslouţí být chráněno. Pokud bychom se zaměřili pouze na odvětví platebních karet v České republice, pak má na zvyšování této úrovně velkou zásluhu výbor PCI DSS pod Sdruţením pro bankovní karty, jehoţ jsem aktivním členem.
75
Seznam použité literatury Tištěná literatura: 1. BRADLEY, Anthony and Tony BRADLE. PCI Compliance: Understanding and Implement PCI Data Security Standards, vyd. Syngress : 2007. ISBN-10: 1-59749-165-9. 2. CREECH, Jason and Matthew ALDERMAN. IT compliance, vyd. Wiley : 2009. ISBN:978-0-470-66535-0. 3. MĚŠŤÁK, Martin. Bezpečnostní standardy v odvětví platebních karet [online]. Praha, 2011,
2012-12-09
[cit.
2012-12-09].
Dostupné
z:
http://is.bivs.cz/th/16539/bivs_b/.
Bakalářská práce. Bankovní institut. 4. SUCHÁNEK, Petr. E-commerce, vyd. Express : 2012. ISBN: 978-80-86929-84-2. 5. WILLIAMS, Branden and Anton CHUVAKIN. PCI Compliance, Third Edition: Understand
and
Implement
Effective
PCI
Data
Security
Standard
Compliance,
vyd. Syngress : 2009. ISBN: 978-1-59749-499-1.
Elektronické zdroje: 1. PCI DSS Compliance Trends Study, [cit. 30.6.2012]; Dostupný z WWW:
. 2. PCI DSS (PCI Data Security Standard), [cit. 20. 4. 2012]; Dostupný z WWW: < https://www.pcisecuritystandards.org/security_standards/index.php>. 3. Project initiation document, [cit. 20. 6. 2012]; Dostupný z WWW: . 4. PCI Standard.cz, [cit. 20. 4. 2012]; Dostupný z WWW: . 5. RACI chart template, [cit. 20. 6. 2012]; Dostupný z WWW: .
76
6. Report on fraud regarding non cash means of payments in the EU, [cit. 30.6.2012]; Dostupný z WWW: <ec.europa.eu/internal_market/payments/docs/fraud/implementation_report_en.pdf>. 7. Risk Management Best Practices - ISO/IEC 27005, [cit. 13. 10. 2012]; Dostupný z WWW: . 8. Úrovňové rozdělení asociací pro obchodníky, [cit. 19. 9. 2012]; Dostupný z WWW: . Právní předpisy a ISO normy: 1. BS 7799-3:2006. Informační technologie - Britská norma definující způsoby řízení rizik informací v rámci životního cyklu ISMS. 2. ISO/IEC 17799:2000. Informační technologie - Mezinárodní norma definující soubor postupů pro řízení informační bezpečnosti. 3. ISO/IEC 27001:2005. Informační technologie - Mezinárodní norma definující způsoby zajištění systému řízení bezpečnosti informací. 4. Zákon č. 229/2002 Sb., o finančním arbitrovi. 5. Zákon č. 284/2009 Sb., o platebním styku. 6. Zákon č. 101/2000 Sb., o ochraně osobních údajů. 7. Zákon č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti. 8. Zákon č. 418/2011 Sb., o trestní odpovědnosti právnických osob a řízení proti nim. 9. Zákon č. 40/2009 Sb., trestní zákoník.
77
Seznam použitých tabulek, obrázků, diagramů Seznam pouţitých tabulek: Tabulka č. 1 - Skupiny karetních dat
18
Seznam pouţitých obrázků: Obrázek č. 1 - Příklad segmentování sítě
26
Obrázek č. 2 - Příklad řešení tokenizace
27
Obrázek č. 3 - Síťový diagram obchodního řetězce
29
Obrázek č. 4 - Procesní diagram obchodního řetězce
31
Obrázek č. 5 - Síťový diagram hotelu
32
Obrázek č. 6 - Procesní diagram hotelu
33
Seznam pouţitých diagramů: Diagram č. 1 - Matice rizik
39
Diagram č. 2 - Oblasti a třídy poţadavků PCI DSS
42
Diagram č. 3 - Implementační roadmapa
66
78
Seznam použitých zkratek ACL
ACL
(Access
control
list)
je
seznam
oprávnění,
který
určuje,
kdo nebo co můţe přistupovat k určitému systému a jaké operace v něm můţe
provádět.
Typicky
se
ACL
nachází
na
firewallech
nebo routerech, kde ACL povoluje datovou komunikaci plynoucí pouze např. z autorizovaných IP adres. Active Directory
Active Directory je komponenta platformy Microsoft Windows Server, která administrátorům umoţňuje nastavovat politiku, instalovat programy na mnoho počítačů nebo aplikovat kritické aktualizace v celé struktuře instituce. Active Directory ukládá své informace a nastavení v centrální organizované databázi.
Aktiva
Cenné a strategické informace, databáze, sestavy dat, hardwarové komponenty, servery, pracovní stanice atd., které si díky své hodnotě zaslouţí přiměřený stupeň ochrany. Pro účely této práce budu hovořit pouze o citlivých datech jako aktivech
AP
Access Point - Přístupový bod k bezdrátové síti Wi-Fi (Wireless-Fidelity), ke kterému se klienti bezdrátově připojují.
Assessment
Prověření souladu instituce s konkrétní regulatorní normou dle předem definovaného rozsahu prověrky.
ASV
PCI DSS Approved Scanning Vendor - Společnost, která je certifikovaná pro provádění externích skenů zranitelnosti.
Audit IS
Hlavním úkolem auditu informačního systému je porovnání reálné situace vůči situaci, která je poţadovaná bezpečnostní politikou nebo odvětvovou normou.
Autorizace
Proces
ověření,
zda
konkrétní
platební
karta
není
stoplistovaná
a zda je kryta dostatečnými finančními prostředky na bankovním účtu. CAV2/CVC2/CVV2/CID
CAV 2 (ověřovací hodnota platební karty pouţívaná JCB), CVC2 (ověřovací kód platební karty pouţívaný MasterCard), CVV2 (ověřovací hodnota karty pouţívaná Visa), CID (identifikační číslo karty pouţívané American Express).
79
DMZ
Demilitarizovaná zóna. Část sítě, která kontroluje a řídí spojení mezi veřejnou sítí (např. internet) a vnitřními sluţbami.
DNS
Domain Name System (Systém doménových jmen) - Nástroj pro převod doménových jmen (např. www.pcisecuritystandards.org) na veřejné IP adresy (72.3.223.78) a naopak.
Dvoufaktorová autentifikace
Metoda autentifikace zaloţená na dvou zcela nezávislých faktorech např. na něčem, co uţivatel zná (PIN, aj.) a něčem, co fyzicky vlastní (autentifikační token, aj.).
E-commerce
Internetová akceptace platebních karet zaloţena na řešení 3-D Secure.
firewally
Síťové zařízení, které zabezpečuje síťový provoz a definuje pravidla pro komunikaci mezi sítěmi.
Forenzní analýza
Forenzní analýza je investigativní postup pouţívaný k vyšetřování incidentů nad karetními daty, který si asociace mohou u zvláště závaţných incidentů vyţádat.
hosting
Sluţba, kterou si klient pronajímá „vlastní místo na internetu“, za účelem provozování svých stránek, elektronického úloţiště, atd.
IDS/ISP
Intrusion Detection/Protection System (systém detekce narušení).
Instituce
Zpracovatelské
banky,
obchodníci
a další poskytovatelé
sluţeb,
kteří zpracovávají, ukládají nebo přenášejí karetní data
IP adresa
IP (Internet protokol) - Unikátní číslo identifikující počítač v počítačové síti. Rozeznáváme interní (vnitřní) IP adresu a veřejnou IP adresu. Rozdíl mezi nimi je ten, ţe vnitřní IP je určena pro lokální PC v lokální síti. Naopak veřejná IP umoţňuje dostupnost z celého internetu.
IPsec
IPsec je bezpečnostní rozšíření IP protokolu, které je zaloţené na šifrování datových paketů přenášených přes síť a bezpečné autentifikaci.
ISMS
Information Security Management System (systém řízení bezpečnosti informací).
80
Kickoff
Úvodní
projektová
schůzka
která
zaručuje,
ţe
projekt
startuje
v kontrolované a organizované podobě. Kritický systém
Systémy,
které
představují
strategická
aktiva
instituce
nebo se prostřednictvím nich zpracovává, ukládá či přenáší velké mnoţství citlivých dat. Kryptogram
Šifrovaná data.
MDs
ManDay (člověkoden) je pomyslná jednotka produkce. Je to práce, kterou můţe jeden člověk vykonat za jeden pracovní den.
Microsoft SBS
Microsoft Windows Small Business Server 2011 - Systém navrţený pro potřeby a finanční moţnosti malých firem. Představuje dostupné řešení typu „vše v jednom“, které pomáhá zajistit efektivnější chod instituce. Nabízí pokročilé funkce pro správu sítě a emailového serveru. Dále pak podporuje databáze, vzdálenou správu, sdílení souborů a tiskáren.
NAT
Network Address Translation - Překladač IP adres. Pouţívá se z důvodů omezení potřebného počtu veřejných IP adres a k zajištění bezpečnosti komunikace mezi veřejnou (internetem) a vnitřní sítí.
NTP
Server, na kterém běţí NTP (Network Time Protocol) pro synchronizaci vnitřních hodin, který zajišťuje, aby všechny počítače v síti měly stejný čas (z pohledu bezpečnosti je NTP důleţité při monitoringu a forenzních analýzách).
NTP
Network Time protokol - Protokol na synchronizaci času.
Obchodník úrovně 1
Obchodníci zpracovávající více neţ 6 miliónů transakcí platební kartou za rok.
Obchodník úrovně 2
Obchodníci zpracovávající více neţ 1 milión a méně neţ 6 miliónů transakcí platební kartou za rok.
Obchodník úrovně 3
Obchodníci zpracovávající více něţ 20,000 a méně neţ 1 milion internetových transakcí za rok.
81
Obchodník úrovně 4
Obchodníci zpracovávající méně neţ 20,000 internetových transakcí ročně a všichni další obchodníci zpracovávající do 1 miliónu transakcí platební kartou za rok.
Odolná kryptografie
Kryptografie zaloţená na odvětvově akceptovaných algoritmech spolu s délkami odolných šifrovacích klíčů a správnými postupy managementu klíčů. K příkladům odvětvově testovaných a akceptovaných standardů a algoritmů kódování patří AES (128 bitů a více), TDES (kódy o minimálně dvojnásobné délce), RSA (1024 bitů a více), ECC (160 bitů a více) a ElGamal (1024 bitů a více).
Assessment
Interní ověření (audit) shody s PCI DSS na místě.
Operační systém
Operační systém je softwarový prostředník mezi hardwarem (technickým vybavením počítače) a konkrétním programem, který uţivatel pouţívá.
Instituce
Zpracovatelské
banky,
obchodníci
a další poskytovatelé
sluţeb,
kteří zpracovávají, ukládají nebo přenášejí karetní data. OWASP
Open Web Application Security Project.
PA DSS
Payment Aplication Data Security Standard (bezpečnostní standard pro platební aplikace).
PAN
Primary Account Number (číslo platební karty).
PCI DSS
Payment Card Industry Data Security Standard (Bezpečnostní standard v odvětví platebních karet).
PCI DSS požadavek č. 3
Poţadavky na ochranu uloţených dat drţitelů karet.
PCI DSS požadavek č. 6
Vývoj a udrţování bezpečných systémů a aplikací.
PCI DSS požadavek č. 7
Omezení přístupu k datům drţitelů karet jen podle potřeby.
PCI DSS požadavek č. 8
Pravidla bezpečnosti informací pro zaměstnance a dodavatele.
PCI DSS požadavek č. 10.7
Uchovávat historii auditních záznamů nejméně jeden rok, přičemţ minimálně tři měsíce musí být bezprostředně k dispozici pro analýzu (například online, archivovaná nebo obnovitelná ze záloh).
82
PCI DSS požadavek č. 12
Pravidla bezpečnosti informací pro zaměstnance a dodavatele.
PCI PIN
Payment Card Industry Personal Identification Number (bezpečnostní standard pro zacházení s osobním identifikačním číslem (PIN) vycházející z normy ISO9564-3 pro řízení PIN).
PCI PTS
Payment Card Industry Payment Secure Transactions (bezpečnostní standard pro zařízení procesující PIN).
PCI SSC
Payment Card Industry Security Standards Council. PCI SSC je globální fórum a normotvorná instituce pro PCI standardy.
PDCA
Cyklus - Plánuj,dělej,kontroluj, jednej (Plan,Do,Check and Act).
Phishingový útok
Phishing představuje podvodnou činnost, např. kdy se útočník snaţí získat citlivé údaje (hesla k systémům, čísla platebních karet a nebo údaje k nim) prostřednictvím elektronické komunikace.
Plochá síť
V síťovém perimetru, přes který putují karetní data není pouţitá ţádná síťová segmentace.
Poskytovatelé služeb úrovně 1
Poskytovatelé sluţeb zpracovávající více neţ 300,000 transakcí platební kartou za rok.
Poskytovatelé služeb úrovně 2
Poskytovatelé sluţeb zpracovávající méně jak 300,000 transakcí platební kartou za rok.
Post-mortem analýza
Analýza, která je prováděná po potvrzeném bezpečnostním incidentu, jejíţ výstupem je zpráva o incidentech.
Proaktivní přístup
Proaktivní přístup pravidelně rizika analyzuje, vyhodnocuje a nakonec navrhne opatření, které zabrání, aby k bezpečnostnímu incidentu vůbec došlo.
PROXY
Server, který dělá prostředníka při hypertextové komunikaci klienta se servery na Internetu.
83
QSA
Qualified Security Assessor - auditor, který je certifikovaný na provádění PCI DSS assessmentu.
RACI
Jedná se o jednoduchý nástroj pouţívaný k identifikaci a individuální zodpovědnosti za konkrétní aktivitu v rámci projektu. „R“ značí kdo danou činnost vykonává. „A“ značí kdo nese za splnění odpovědnost. „C“ značí s kým je třeba konzultovat. „I“ koho je třeba informovat. Vzorovou šablonu RACI
tabulky
lze
získat
např.
zde:
http://racichart.org/wp-
content/uploads/2012/04/RACI-Template.xlsx [cit. 20. 6. 2012]. RDP
Remote Desktop Protokol - Protokol, který umoţňuje ovládat počítač vzdálenou cestou prostřednictvím připojení k jeho desktop prostředí.
Reaktivní přístup
Reaktivní přístup řeší bezpečnostní incidenty teprve poté, co nastanou. Tento přístup je tedy často spojen s vynakládáním výrazných finančních nákladů na opravu škod za incident.
ROC
Auditní zpráva z provedeného assessmentu, kterou vytváří QSA.
Routery
Síťové prvky, které přeposílají datové pakety (bloky dat) ke konkrétnímu cíli.
Rozsah (stanovení)
Vymezení veškerých míst, systémů a procesů, kde se pracuje s karetními daty. S tím souvisí i jasná identifikace všech externích dodavatelů, kteří mají přístup ke karetním datům instituce nebo mohou ohrozit jejich bezpečnost.
Safe harbour
Pojem vytvořený asociacemi, který garantuje, ţe asociace nebudou instituci postiţenou bezpečnostním incidentem penalizovat.
Scope
Rozsah vymezení veškerých míst, systémů a procesů, kde se pracuje s karetními daty. S tím souvisí i moţná identifikace všech externích dodavatelů, kteří mají přístup ke karetním datům instituce nebo mohou ohrozit jejich bezpečnost.
SAQ
Self-Assessment Questionaire - dotazník vlastního ohodnocení oproti PCI DSS.
SAQ-D
Nejrozsáhlejší typ dotazníku vlastního ohodnocení, který v sobě obsahuje všech 196 poţadavků PCI DSS.
84
Switch
Síťové prvky, které propojují jednotlivé síťové segmenty.
Systémové komponenty
Jakékoliv síťové zařízení, server nebo aplikace operující v prostředí, kde se pracuje s karetními daty.
Šifrovací klíč
Informace, která určuje průběh šifrovacího algoritmu. Při šifrování, klíč specifikuje transformaci zprávy do šifrovaného textu, při dešifrování je tomu naopak.
TLS/SSL
TLS (Transport Layer Security) a jeho předchůdce SSL (Secure Sockets Layer) jsou šifrovací protokoly, které umoţňují ochranu komunikace na internetu. Do rozsahu ochrany TLS/SSL spadají sluţby jako WWW, elektronická pošta a další.
VLAN
Zkratka pro virtuální síť. VLAN slouţí k logickému rozdělení sítě nezávisle na jejím fyzickém uspořádání. Pomocí VLAN lze síť segmentovat na menší sítě uvnitř fyzické struktury původní sítě.
WEP
WEP (wireless encryption protokol) je starší metoda zabezpečení bezdrátové sítě, která slouţí k podpoře starších zařízení, ale není nadále doporučována. Zabezpečení protokolem WEP však lze snadno umoţnit prolomení šifrování datového toku.
Whitelisting
Whitelistingové aplikace zajišťují monitoring změn a kontrolu integrity definovaného SW. Současně tento typ aplikací hlídá spouštění přesně definovaných procesů. Samotná funkce whitelistingu umoţňuje definici procesů, které jsou pouţívány pro standardní běh instalovaných aplikací a zároveň zajišťuje blokování jakéhokoliv neautorizovaného procesu. Tento způsob
ochrany
je
velmi
vhodný
ve
stabilním
prostředí
(např. v bankomatu), kdy není ţádoucí, aby byla několikrát denně aktualizována virová databáze. WPA2
WPA 2 (Wi-Fi Protected Access 2) je šifrovací protokol pouţívaný v bezdrátových sítích. Tento protokol šifruje přenášené datové pakety a zároveň ověřuje, zda nedošlo ke změně šifrovacího klíče. Velkou výhodou tohoto protokolu je, ţe ověřuje uţivatele a pomáhá zjišťovat, aby přístup k bezdrátové síti získali pouze autorizovaní uţivatelé.
85
Příloha č. 1 Úrovňové rozdělení asociací pro obchodníky Úroveň
1.
Kritéria pro obchodníky Obchodníci zpracovávající více neţ 6 miliónů transakcí za rok prostřednictvím všech platebních kanálů (POS, e-commerce, emailové a telefonické objednávky).
4.
Úroveň
Vyžadováno: - roční assessment provedený prostřednictvím QSA nebo certifikovaným auditorem bezpečnosti; - externí čtvrtletní prověrka zranitelnosti systémů;
Obchodníci zpracovávající 1 aţ 6 miliónů transakcí za rok prostřednictvím všech kanálů.
Vyžadováno: - vyplnění dotazníku vlastního ohodnocení SAQ prostřednictvím vyškoleného pracovníka; - externí čtvrtletní prověrka zranitelnosti systémů.
Obchodníci zpracovávající 20000 aţ 1 milion e-commerce transakcí za rok.
Vyžadováno: - vyplnění dotazníku vlastního ohodnocení SAQ; - externí čtvrtletní prověrka zranitelnosti systémů.
Obchodníci zpracovávající méně neţ 20000 Visa e-commerce transakcí ročně. Všichni další obchodníci zpracovávající do 1 miliónu transakcí za rok prostřednictvím všech platebních kanálů.
Doporučeno: - vyplnění dotazníku vlastního ohodnocení SAQ; - externí čtvrtletní prověrka zranitelnosti systémů.
2.
3.
Ověřovací kritéria
1.
Kritéria pro poskytovatele služeb Poskytovatelé sluţeb zpracovávající více neţ 300000 Visa transakcí za rok prostřednictvím všech kanálů.
Ověřovací Kritéria Vyžadováno: - roční assessment provedený prostřednictvím QSA; - externí čtvrtletní prověrka zranitelnosti systémů.
2.
Poskytovatelé sluţeb zpracovávající méně jak 300000 Visa transakcí za rok prostřednictvím všech kanálů.
Vyžadováno: - vyplnění dotazníku vlastního ohodnocení SAQ; - externí čtvrtletní prověrka zranitelnosti systémů.
Zdroj: http://www.visaeurope.com/en/businesses__retailers/payment_security.aspx [cit. 19. 9. 2012];
86
Příloha č. 2 Risk management dle ISO/IEC 27005
Zdroj: http://www.modulo.com/risk-management-iso31000-iso27005 [cit. 13. 10. 2012]; vlastní úpravy.
87
Příloha č. 3 Tabulka rizik
Zdroj: Vlastní tvorba.
88
Příloha č. 4 Prezentace risk managementu - manažerské shrnutí
89
90
Zdroj: Vlastní tvorba.
91
Příloha č. 5 Rozsah assessmentu Den 1.
2.
3.
4.
5.
6.
7.
8.
9.
Oblast PCI DSS assessmentu Bezpečnost firewallu Bezpečnost routerů, switchů a konfiguračních standardů Bezpečnost bezdrátových sítí Server security Bezpečnost mobilních zařízení Bezpečnost vzdáleného přístupu k systémovým komponentám Politika ukládání, mazání a přesunu dat držitelů karet Ochrana citlivých autentifikačních dat Bezpečné zobrazování karetních dat (v elektronické a papírové podobě) Management šifrovacích klíčů Bezpečný přenos karetních dat prostřednictvím veřejné sítě a emailu Ochrana proti virům a jinému nežádoucímu software Bezpečnostní záplaty systémových komponent Bezpečný vývoj a testování Bezpečný vývoj webových aplikací Management konfiguračních změn Přidělování jedinečného ID pracovníkům Přístupový management + deregistrace uživatelů ze systémových komponent Management hesel Fyzická bezpečnost karetního centra (recepce, atd.) Fyzická bezpečnost zálohovacích médií a IT komponent Fyzická bezpečnost papírových dokumentů, které obsahují data držitelů karet Monitoring a sledování přístupů Bezpečnostní testování systémových komponent IDS/ISP Bezpečnostní politiky, zodpovědnosti a procesy Program informačního povědomí pro zaměstnance Procesy analýzy a řízení rizik Procesy náboru zaměstnanců Smlouvy s dodavateli Plány reakce na incident Plány kontinuity podnikání Procedury záloh kritických systémů
Požadovaná pracovní role Síťoví inţenýři Síťoví inţenýři Síťoví inţenýři nebo lokální IT podpora Systémoví inţenýři Pracovníci informační bezpečnosti Pracovníci informační bezpečnosti Pracovníci informační bezpečnosti + koncoví pracovníci Pracovníci informační bezpečnosti + koncoví pracovníci Pracovníci informační bezpečnosti + IT architekti Pracovníci informační bezpečnosti + IT architekti Pracovníci informační bezpečnosti + síťoví inţenýři IT podpora IT podpora případně systémoví inţenýři IT vývojáři IT vývojáři případně web designéři Systémoví inţenýři Systémoví inţenýři Pracovníci informační bezpečnosti + systémoví inţenýři Pracovníci informační bezpečnosti Security Security + pracovníci informační bezpečnosti Security + pracovníci informační bezpečnosti Pracovníci informační bezpečnosti Systémoví inţenýři IT security Pracovníci informační bezpečnosti Pracovníci informační bezpečnosti Pracovníci informační bezpečnosti Pracovníci lidských zdrojů a inf. bezpečnosti Koncoví pracovníci Pracovníci informační bezpečnosti Koncoví pracovníci + pracovníci inf. bezpečnosti IT security + systémoví inţenýři
Zdroj: Vlastní tvorba.
92
