PCI DSS - PCI Security Standards Council

Transkript

PaymentCardIndustry (PCI)
Data Security Standard
Odvětví platebních karet (PCI)
Standard bezpečnosti dat (DSS)
Requirements and Security
Assessment Procedures
Požadavky a postupy posouzení
bezpečnosti
Verze3.1
Duben 2015
Změny v dokumentu
Datum
Verze
Říjen
2008
1.2
Červenec
2009
1.2.1
Popis
Zavedení standardu PCI DSS v1.2 v dokumentu “Požadavky Standardu bezpečnosti dat PCI a
postupy posouzení bezpečnosti“ („PCI DSS Requirements and SecurityAssessmentProcedures”)
zrušením nadbytečných informací v různých dokumentech, a provedením obecných i
specifických změn podle dokumentu Postupy bezpečnostního auditu (PCI DSS Security Audit
Procedures v1.1). Úplné informace viz dokument PCI Standard bezpečnosti dat - Přehled změn
od verze 1.1 k 1.2 (PCI Data Security Standard SummaryofChangesfrom PCI DSS Version 1.1 to
1.2).
Strana
Přidání věty, která byla nesprávně zrušena při přechodu z PCI DSS v1.1 na v1.2
5
Oprava „pak“ (then) na „než“ (than) v postupu testování, 6.3.7.a a 6.3.7.b
32
Odstranění šedivého zabarvení pro sloupce „Zavedeny“ (In place) a „Nezavedeny“ (Not in
place)v testovacích postupech 6.5.b
33
Pracovní tabulka náhradního řešení – Vzor (Compensating Controls Worksheet – Example)
upraven text na začátku stránky „Použijte tuto tabulku k definování náhradního řešení pro
jakýkoli požadavek, označený jako „Zavedeny“ prostřednictvím náhradního řešení“.
64
Říjen 2010
2.0
Aktualizovány a zavedeny změny verze 1.2.1. Podrobněji v „PCI DSS – Summary of Changes
from PCI DSS Version 1.2.1 to 2.0“ (PCI DSS – Seznam změn PCI DSS verze 1.2.1. do 2.0)
Listopad 2013
3.0
Aktualizace v2.0. Viz PCI DSS – Summary of Changes from PCI DSS Version 2.0 to 3.0.
Duben 2015
3.1
Aktualizace v3.0. Viz PCI DSS – Podrobněji v „Summary of Changes from PCI DSS Version 3.0
to 3.1“ (PCI DSS – Seznam změn PCI DSS verze 3.0 do 3.1)
Payment Card Industry (PCI) Data Security Standard, v3.1
© 2006-2015 PCI Security Standards Council, LLC. All Rights Reserved.
strana2
Duben 2015
Obsah
Změny v dokumentu .......................................................................................................................................................................... 2
Úvod a přehled Standardu bezpečnosti dat PCI DSS ...................................................................................................................... 5
Další materiály k PCI DSS........................................................................................................................................................................................... 6
Aplikace požadavků standardu PCI DSS .......................................................................................................................................... 8
Vztah mezi PCI DSS a PA-DSS ........................................................................................................................................................ 10
Aplikace standardu PCI DSS pro PA-DSS ................................................................................................................................................................ 10
Aplikace standardu PCI DSS pro dodavatele platebních aplikací ............................................................................................................................ 10
Rozsah požadavků standardu PCI DSS.......................................................................................................................................... 11
Segmentace sítě .. ..................................................................................................................................................................................................... 12
Bezdrátové technologie ............................................................................................................................................................................................. 12
Spolupráce se „třetími stranami“ – poskytovateli služeb / Outsourcing .................................................................................................................... 13
Doporučené postupy implementace požadavků PCI DSS do běžného provozu ......................................................................... 14
Pro hodnotitele: Výběr vzorků provozních zařízení / systémových komponent ......................................................................... 16
Kontrola náhradních řešení............................................................................................................................................................. 17
Pokyny a obsah dokumentu Zpráva o shodě................................................................................................................................. 18
Postup vyhodnocení požadavků PCI DSS ..................................................................................................................................... 18
Podrobné požadavky a postupy posouzení bezpečnosti PCI DSS............................................................................................... 19
Vybudování a udržování bezpečné sítě a systémů ............................................................................................................................................... 20
Požadavek 1: Instalovat a udržovat konfiguraci firewallů za účelem ochrany dat držitelů karet .............................................................................. 20
Požadavek 2: Nepoužívat výchozí nastavení od dodavatele pro systémová hesla a jiné bezpečnostní parametry ................................................ 29
Ochrana dat držitelů karet ....................................................................................................................................................................................... 37
Požadavek 3: Chránit uchovávaná data držitelů karet .............................................................................................................................................. 37
Požadavek 4: Zašifrovat přenos dat držitelů karet po otevřených veřejných sítích .................................................................................................. 50
Udržování programu kontroly zranitelnosti ........................................................................................................................................................... 55
Požadavek 5: Chránit všechny systémy proti malware a pravidelně aktualizovat antivirový software nebo programy............................................ 55
Požadavek 6: Vyvíjet a udržovat bezpečné systémy a aplikace ............................................................................................................................... 60
Zavedení přísných opatření a kontrol přístupů .................................................................................................................................................... 73
Požadavek 7: Omezit přístup k datům držitelů karet jen podle oprávněné potřeby .................................................................................................. 73
Požadavek 8: Identifikovat a autentizovat přístup k systémovým komponentám ..................................................................................................... 76
Požadavek 9: Omezit fyzický přístup k datům držitelů karet ..................................................................................................................................... 85
strana3
Duben 2015
Pravidelné monitorování a testování sítí ............................................................................................................................................................... 95
Požadavek 10: Sledovat a monitorovat všechny přístupy k síťovým zdrojům a datům držitelů karet ...................................................................... 95
Požadavek 11: Pravidelně testovat bezpečnostní systémy a procesy ................................................................................................................... 103
Udržování politiky bezpečnosti informací ........................................................................................................................................................... 111
Požadavek 12: Udržovat politiku zaměřenou na bezpečnost informací pro všechny pracovníky .......................................................................... 111
Požadavek A.1: Poskytovatelé sdíleného hostingu musí chránit prostředí dat držitelů karet ................................................................................. 122
Příloha B: Náhradní řešení ............................................................................................................................................................ 125
Příloha C: Pracovní tabulka náhradního řešení ........................................................................................................................... 126
Příloha D: Segmentace a výběru vzorků provozních objektů/systémových komponent .......................................................... 128
strana4
Duben 2015
Úvod a přehled Standardu bezpečnosti dat PCI DSS
Standard bezpečnosti dat odvětví platebních karet (Payment Card Industry Data Security Standard – PCI DSS) byl vyvinut za účelem podpořit a
posílit bezpečnost dat držitelů karet, resp. údajů o platební kartě a k usnadnění globálního přijetí jednotných opatření k zabezpečení uvedených
dat. Standard PCI DSS poskytuje základní technické a provozní požadavky vytvořené k ochraně dat držitelů karet (kartového účtu). PCI DSS se
vztahuje na všechny subjekty podílející se na zpracování platebních karet – včetně obchodníků, zpracovatelů (procesorů), acquirerů, vydavatelů a
poskytovatelů služeb, a dalších subjektů, které uchovávají, zpracovávají nebo přenášejí data držitelů karet (CHD – Cardholder data) a/nebo citlivá
autentizační data (SAD – Sensitive authentication data). Dále je uveden stručný přehled 12 bezpečnostních požadavků standardu PCI DSS.
PCI Standard bezpečnosti dat - přehled
Vybudování a udržování
bezpečné sítě a systémů
1.
Instalovat a udržovat konfiguraci firewallůza účelem ochrany dat držitelů karet
2.
Nepoužívat výchozí nastavení od dodavatele pro systémová hesla a jiné
bezpečnostní parametry
3.
Chránit uchovávaná data držitelů karet
4.
Zašifrovat přenos dat držitelů karet po otevřených veřejných sítích
5.
Chránit všechny systémy proti malware a pravidelně aktualizovat antivirový
software nebo programy
Ochrana dat držitelů karet
Udržování programu
kontroly zranitelnosti
Zavedení přísnýchopatření a
kontrol přístupů
Pravidelné monitorování a
testování sítí
Udržování politiky
bezpečnosti informací
6.
Vyvíjet a udržovat bezpečné systémy a aplikace
7.
Omezit přístup k datům držitelů karet jen podle oprávněné potřeby
8.
Identifikovat a autentizovat přístup k systémovým komponentám
9.
Omezit fyzický přístup k datům držitelů karet
10.
Sledovat a monitorovat všechny přístupy k síťovým zdrojům a datům držitelů karet
11.
Pravidelně testovat bezpečnostní systémy a procesy
12.
Udržovat politiku zaměřenou na bezpečnost informací pro všechny pracovníky
strana5
Duben 2015
Tento dokument, Požadavky a postupy posouzení bezpečnosti PCI Standardu bezpečnosti dat (PCI Data Security Standard Requirements and
Security Assessment Procedures) spojuje 12 požadavků PCI DSS a odpovídající testovací postupy do nástroje revize bezpečnosti. Je navržen
pro využití při vyhodnocování shody se standardem PCI DSS jako součást procesu revize subjektu. Následující části manuálu poskytují podrobné
zásady a doporučené postupy pro posouzení subjektů, pro přípravu, provedení a zpracování výsledkůvyhodnocenídle standarduPCI DSS.
Požadavky PCI DSS a revizní postupy začínají na straně 21.
Standard PCI DSS představuje minimální informace k požadavkům ochrany dat držitelů karet (kartového účtu) a může být rozšířen dodatečnými
kontrolami a postupy k dalšímu snížení rizika a takéna základě vyhovění místním, regionálním a kartovým pravidlům a zákonům a regulacím.
Navíc legislativní nebo regulatorní požadavky mohou vyžadovat specifickou ochranu osobních údajů nebo jiných datových prvků (například jméno
držitele karty). PCI DSS nenahrazuje místní nebo regionální zákony, vládní regulace nebo jiné právní požadavky.
Další materiály k PCI DSS
Internetové stránky Rady pro bezpečnostní standardy PCI (PCI Security Standards Council, PCI SSC) (www.pcisecuritystandards.org) obsahují
řadu dalších materiálů k využití subjekty, které se zabývajíposuzováním PCI DSS, včetně:

Dokumenty:
o
PCI DSS – Přehled změn od verze 2.0 na 3.0 (PCI DSS – Summary of Changes from PCI DSS version 2.0 to 3.0)
o
PCI DSS Stručný přehled (PCI DSS Quick Reference Guide)
o
PCI DSS a PA-DSS Slovník termínů, zkratek a akronymů (PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms)
o
Doplňující informace a návody (Information Supplements and Guidelines)
o
Postup prioritizace k PCI DSS (Prioritized Approach for PCI DSS)
o
Zprávao shodě (ROC) a instrukce k vyplnění (Report on Compliance (ROC) Reporting Template and Reporting Instructions )
o
Dotazníky pro vlastní vyhodnocení (SAQ), instrukce a návody pro SAQ (Self-assessment Questionnaires (SAQs) and SAQ
Instructions and Guidelines)
o
Osvědčení o shodě (AOC) (Attestations of Compliance (AOCs))

Často kladené otázky (Frequently Asked Questions (FAQs))

PCI pro internetové stránky drobných obchodníků (PCI for Small Merchants website)

PCI školení a informativní webináře (PCI training courses and informational webinars)

Seznam Kvalifikovanýchhodnotitelů bezpečnosti a Schválených poskytovatelů skenů(List of Qualified Security Assessors (QSAs) and
Approved Scanning Vendors (ASVs))

Seznam schválených zařízení dle PTS a ověřených platebních aplikací dle PA-DSS (List of PTS approved devices and PA-DSS validated
payment applications)
strana6
Duben 2015
Informace o výše uvedených materiálech k PCI DSS jsou k dispozici na www.pcisecuritystandards.org.
Poznámka:Dokument Doplňující informace
a návody doplňujeí požadavky PCI DSS a
poskytuje další poznatky a doporučení
vedoucí k dosažení bezpečnosti dle
požadavků PCI DSS - ale nenahrazují,
neruší ani nerozšiřují standard PCI DSS
ani žádný z jeho požadavků.
strana7
Duben 2015
Aplikace požadavkůstandardu PCI DSS
Standard PCI DSS je závazný pro všechny subjekty při zpracování platebních karet – včetně obchodníků, zpracovatelů (procesorů), subjektů
zajišťujících kartové transakce obchodníkům (acquirerů), vydavatelů platebních karet (issuerů) a poskytovatelů služeb. PCI DSS se vztahuje také
na všechny další subjekty, které uchovávají, zpracovávají nebo přenášejí data držitelů karet a/nebo citlivá autentizační data.
Data držitele karty a citlivá autentizačních data jsou definována dle následující tabulky:
Data držitele karet zahrnují:
Citlivá autentizační data

Kompletní data(uložená na
magnetickém proužku nebo
ekvivalent na čipu)
Jméno držitele karty

CAV2/CVC2/CVV2/CID

Datum ukončení platnosti

PINy /PIN bloky

Servisní kód

Číslo karty (PAN,Primary Account
Number)

Číslo karty (PAN) je určujícím faktorem pro data držitele karet. Pokud se uchovává, zpracovává nebo přenáší jméno držitele karty,
servisní kód a/nebo datum ukončení platnosti spolu s číslem karty (PAN), nebo jsou jinak tyto údaje přítomny společně s údaji držitelů karet
(CDE – Cardholder Data Environment), musejí být chráněny v souladu se všemi příslušnými požadavky PCI DSS.
Standardy PCI DSS se vztahují na organizace,, kde údaje o účtu /čísle platební karty (data držitele karty a/nebo citlivá autentizační data) jsou
uchovávana, zpracovávana nebo přenášena. Některé požadavky PCI DSS se mohou také vztahovat na organizace, které outsourcovaly své
platební operace nebo správu prostředí CDE1.Organizace, které outsourcovali správu svéhoprostředí CDE nebo platební operace
prostřednictvím třetích stran, jsou zodpovědné za zajištění,zdaúdaje o účtu / čísle platební karty jsou třetí stranou chráněny podle příslušných
požadavků PCI DSS.
Tabulka na následující straně uvádí obecně používané prvky dat držitelů karet a citlivých autentizačních dat, bez ohledu na to, zda je jejich
uchovávání povoleno nebo zakázáno, a zda musí být každý datový prvek chráněn. Výčet v této tabulce není vyčerpávající, je však
předkládán jako příklad různých typů požadavků uplatňovaných na každý datový prvek.
1
V souladu s programem bezpečnosti dat u jednotlivých platebních společností (VISA, MasterCard, apod.)
strana8
Duben 2015
Data o účtu
(kartovém)
Data držitelů
karet
Citlivá
autentizační
data 2
Datový prvek
Ukládání
povoleno
Znečitelnění uchovávaných dat o kartě
podle Požadavku 3.4
Číslo karty (PAN)
Ano
Ano
Jméno držitele karty
Ano
Ne
Servisní kód
Ano
Ne
Datum konce platnosti karty
Ano
Ne
kompletní data z magnetického
proužku nebo čipu3
Ne
Podle Požadavku 3.2 nelze uchovávat
CAV2/CVC2/CVV2/CID4
Ne
PIN/PINů5
Ne
Požadavky 3.3 a 3.4 standardu PCI DSS se vztahují pouze na číslo karty (PAN). Je-li PAN uchováván s dalšími prvky dat držitele karty, pouze
číslo karty musí být učiněno nečitelným podle Požadavku 3.4 standardu PCI DSS.
Citlivá autentizační data (SAD) nesmí být po autorizaci uchovávána, a to ani v zašifrovaném tvaru. To platí, i když se číslo karty v prostředí
nevyskytuje. Organizace by měly kontaktovat své acquirery nebo přímo jednotlivé platební brandy (kartové společnosti) k získání informace, zda
se mohou citlivá autentizační data uchovávat před autorizací, na jak dlouho, a na požadavky týkající se jejich užití a ochrany.
2
3
4
5
Citlivá autentizační datanesmí být po autorizaci uchovávána (dokonce ani v zašifrované formě).
Úplná data obsažená na magnetickém proužku, ekvivalent dat uložených na čipu nebo v jiné formě nosiče.
Tří-čislicová nebo čtyř-číslicová hodnota vytištěná na přední nebo zadní straně platební karty
PIN (osobní idetifikační číslo/PersonalIdentificationNumber) zadané držitelem karty během transakce za přítomnosti karty a/nebo zašifrovaný
PIN blokátor obsažený v transakčním záznamu.
strana9
Duben 2015
Vztah mezi PCI DSS a PA-DSS
Aplikace standardu PCI DSS pro PA-DSS
(PA-DSS - Payment Application DSS, Standard bezpečnosti dat platebních aplikací)
Používání aplikace, která je ve shodě se Standardem bezpečnosti dat Platebních aplikací (PA-DSS), ještě samo o sobě nezaručuje, že subjekt je
ve shodě s celým standardem PCI DSS, neboť tato aplikace musí být implementována do prostředí, které je ve shodě s požadavky PCI DSS a
podle Implementačního průvodce standardu PA-DSS (“PA-DSS Implementation Guide”) poskytnutým dodavatelem platební aplikace.
Všechny aplikace, které uchovávají, zpracovávají nebo přenášejí data držitelů karet jsou v rozsahu (scope) pro posouzení dle PCI DSS daného
subjektu, včetně aplikací, které byly validovány podle PA-DSS. Posouzení dodržování požadavků PCI DSS by mělo ověřit, zdaplatební aplikace
validovaná podle požadavků PA-DSS je náležitě konfigurována a bezpečně implementována podle požadavků PCI DSS. Pokud u platební
aplikace dojde k úpravě (customization), bude během posouzení požadavků PCI DSS vyžadován hloubkový přezkum, neboť aplikace již nemusí
představovat tu verzi, která byla validována dle požadavkůPA-DSS.
Požadavky PA-DSS jsou odvozeny z Požadavků a postupů posouzení bezpečnosti PCI DSS (“PCI DSS Requirements and Security Assessment
Procedures”)(definovaných v tomto dokumentu). Standard PA-DSS popisuje detailně požadavky na platební aplikaci, které musí být splněny tak,
aby bylo docíleno shody s požadavky PCI DSS u zákazníka.
Bezpečná platební aplikace, implementovaná v prostředí, které je ve shodě s požadavky PCI DSS, bude minimalizovat možné bezpečnostní
narušení vedoucí ke kompromitování čísla karty, dat magnetického proužku nebo čipu, a kódů pro ověření karty (CAV2, CID, CVC2, CVV2), PINů
a PIN bloků, a také omezí dopad ničivých účinků podvodů plynoucích z takovýchto narušení.
“PA-DSS Program Guide” (Průvodce programem požadavků PA-DSS”) Zda se požadavky PA-DSS vztahují na danou platební aplikaci lze ověřit
v manuálu “PA-DSS Program Guide” (Průvodce programem požadavků PA-DSS”), který je k dispozici na www.pcisecuritystandards.org.
Aplikace standardu PCI DSS pro dodavatele platebních aplikací
Požadavky PCI DSS se mohou vztahovat na dodavatele platebních aplikací, pokud dodavatel uchovává, zpracovává nebo přenáší data držitelů
karet nebo má přístup k datům držitelů platebních karet u svých zákazníků (například v roli poskytovatele služeb).
strana10
Duben 2015
Rozsah požadavků standardu PCI DSS
Bezpečnostní požadavky PCI DSS platí pro všechny systémové komponenty zahrnuté nebo napojené na prostředí dat držitelů karet. Prostředí dat
držitelů karet (CDE - Cardholder data environment) sestává z pracovníků, procesů a technologií, které uchovávají, zpracovávají nebo přenášejí
data držitelů karet nebo citlivá autentizační data. “Systémové kompotnenty” obsahují síťová zařízení, servery, počítače a aplikace. Příklady
systémových komponent mimo jiné zahrnují:

Systémy zajišťující bezpečnostní služby (např. autentizační servery), usnadňující segmentaci (např. vnitřní firewally) nebo mající dopad na
bezpečnost prostředí dat držitelů karet (např. rozlišení jmen nebo přesměrovací servery,web redirection servers).

Virtualizační komponenty, jako jsou virtuální stroje, virtuální přepínače/routery, virtuální zařízení, virtuální aplikace/pracovní stanice
(desktops) a hypervisory (Pozn. překl.: monitory virtuálních strojů)

Síťové komponenty včetně,ale nikoli výlučně, např. firewallů, přepínačů, routerů, bezdrátovýchmíst přístupu, síťových zařízení a dalších
bezpečnostních zařízení.

Servery (různé), mimo jiné pro internet, aplikace, databáze, autentizaci, e-mailovou poštu, proxy, Network Time Protocol( NTP) a Domain
Name Server ( DNS).

Aplikace zahrnující všechny zakoupené nebo na míru upravené vlastní aplikace, včetně interních a externích aplikací (na přiklad internet).

Všechny ostatní komponenty a zařízení umístěná uvnitř nebo napojená na prostředí dat držitelů karet (CDE).
Prvním krokem posouzení shody s požadavky standardu PCI DSS je přesné určení rozsahu posuzování. Minimálně jednou ročně a před výročním
posouzenímby měl hodnocený subjekt potvrdit správnost rozsahu posouzení dle PCI DSS, a to identifikováním všech míst a toků dat držitelů karet
a zajistit, že všechny systémy napojené do prostředí dat držitelů karet nebo při kompromitaci ovlivňující toto prostředí (např. autetizační servery),
budou zahrnuty do rozsahu posouzení PCI DSS. Pro potvrzení přesnosti a vhodnosti rozsahu posouzení PCI DSS, proveďte následující kroky:
o
Posuzovaný subjekt identifikuje a dokumentuje ve svém prostředí výskyt všech dat držitelů karet; ověří, že žádná data držitelů karet se
nevyskytují mimo právě definované prostředí dat držitelů karet (cardholder data environment, CDE).
o
Jakmile jsou všechnyvýskyty dat držitelů karet identifikovány a dokumentovány, subjekt ověří, že rozsah PCI DSS je odpovídající (např.
výsledkem může být diagram nebo seznam výskytů dat držitelů karet).
o
Subjekt vezme v úvahu jakákoli data držitelů karet nalézající se v rozsahu posouzení PCI DSS a v části prostředí dat držitelů karet. Pokud
subjekt identifikuje data, která ještě nejsou zahrnuta do prostředí dat držitelů karet, taková data musí být bezpečně vymazána, migrována
(přesunuta) do současně definovaného prostředí dat držitelů karet nebo musí být prostředí dat držitelů karet předefinováno, aby takováto
data obsahovalo.
o
Subjekt uchová dokumentaci prokazující, jak byl rozsah PCI DSS určen. Dokumentace bude uchována pro přezkum hodnotitelem a/nebo
jako reference pro příští výroční posouzení souladu s požadavky PCI DSS.
Při každém posouzení shody s PCI DSS je hodnotitel povinen ověřit, zda rozsah vyhodnocení je správně definován a dokumentován.
strana11
Duben 2015
Segmentace sítě
Segmentace sítě, nebo izolace (segmentování), prostředí dat držitelů karet od zbytku sítě subjektu není požadavkem PCI DSS. Nicméně se velmi
doporučuje jako metoda, která může omezit:

Rozsah posouzení shody s požadavky PCI DSS

Náklady na posouzení shody s požadavky PCI DSS

Náklady a obtíže spojené s realizací a udržováním kontroly požadavků PCI DSS

Rizika pro organizaci (omezením formou konsolidace dat držitelů karet do menšího počtu lépe kontrolovatelných umístění)
Bez odpovídající síťové segmentace (někdy označované jako tzv. „flat network“) je předmětem posouzení souladu s požadavky PCI DSS celá síť.
Síťové segmentace lze dosáhnout pomocí celé řady fyzických nebo logických prostředků, jako jsou správně konfigurované interní síťové firewally,
routery se seznamem silných kontrol přístupů nebo pomocí jiných technologií, které omezují přístup k určitému segmentu sítě. Pokud má být
systémová komponenta mimo rozsahposouzení PCI DSS, musí být náležitě izolována (segmentována) od prostředí dat držitelů karet, aby v
případě kompromitování této komponenty nedošlo k narušení bezpečnosti prostředí dat držitelů karet.
Důležitým předpokladem redukce rozsahu prostředí dat držitelů karet je jasné porozumění obchodním potřebám a procesům týkajícím se
uchovávání, zpracování nebo přenosu dat držitelů karet. Omezením dat držitelů karet na co nejmenší počet umístění eliminací nadbytečných dat
a konsolidací dat nezbytných, může vyžadovat změnu dlouhodobých provozních/obchodních postupů.
Vytvoření diagramu toku dat držitelů karet napomůže plnému pochopení toku všech dat držitelů karet a zajistí, že příslušná síťová segmentace
bude efektivní z hlediska izolace prostředí dat držitelů karet.
Pokud je zavedena síťová segmentace a bude použita ke zmenšení rozsahu posouzení požadavků PCI DSS, musí hodnotitelověřit, zda je
segmentace dostatečná ke snížení rozsahuvyhodnocení. Z celkového pohledu adekvátní síťová segmentace odděluje systémy, které uchovávají,
zpracovávají nebo přenášejí data držitelů karet od těch, které tyto úkony neprovádějí. Ačkoliv adekvátnost specifické implementace síťové
segmentace je velmi rozmanitá a závisí na řadě faktorů, jako jsou konfigurace dané sítě, použité technologie a další možná kontrolní opatření.
Příloha D: Segmentace a výběr vzorků zařízení/systémových komponentůposkytuje více informací o dopadu segmentace sítě a výběru vzorků na
rozsah posouzení dle požadavků PCI DSS.
Bezdrátové technologie
Pokud je použita bezdrátová technologie k uchovávání, zpracování nebo přenášení dat držitelů karet (např. POS transakce na prodejním místě,
„line-busting”– pozn. překl.: interaktivní nákup v obchodě s pomocí tabletů) nebo pokud je bezdrátová lokální síť (WLAN) součástí dat držitelů
karet neboje na ně napojena, platí zde požadavky a testovací postupy standardu PCI DSSpro bezdrátové prostředí a musí být provedeny (např.
Požadavky 1.2.3, 2.1.1, a 4.1.1). Před zavedením bezdrátové technologie by měl subjekt důkladně zvážit nezbytnost této technologie ve vztahu k
riziku. Zavedení bezdrátových technologií zvažujte pouze pro přenos jiných než citlivých dat.
strana12
Duben 2015
Spolupráce se „třetími stranami“ – poskytovateli služeb / Outsourcing
U poskytovatelů služeb je vyžadováno podstoupení každoročního vyhodnocení v jejich provozu, musí být provedeno ověření shody s požadavky u
všech systémových komponent v prostředí dat držitelů karet.
Poskytovatelé služeb nebo obchodníci mohou využít třetí stranu - poskytovatele služeb, která pro ně bude uchovávat, zpracovávat nebo přenášet
data držitelů karet nebo bude spravovat komponenty jako např. routery, firewally, databáze, fyzické zabezpečení a/nebo servery. V takovém
případě to může mít vliv na bezpečnost prostředí dat držitelů karet.
Strany musí jasně identifikovat služby a systémové komponenty, které jsou zahrnuty do rozsahu posouzení požadavků PCI DSS u poskytovatele
služeb, specifické požadavky PCI DSS pokryté u poskytovatele služeb a další požadavky, u kterých mají odpovědnost za jejich zařazení do
vlastního přezkoumání standardu PCI DSS zákazníci poskytovatele služeb. Například, poskytovatel hostingu má zřetelně definovat, které z jeho
IP adres budou skenovány jako součást procesu v jejich čtvrtletnímskenování zranitelnosti, a za které IP adresy má odpovědnost jeho zákazník,
aby je zahrnul do svéhovlastního čtvrtletníhoskenování.
Poskytovatelé služeb jsou zodpovědní za prokázání souladu s PCI DSS a mohou být požádáni kartovými společnostmi, aby tak učinili.
Poskytovatelé služeb by měli kontaktovat svého acquirera a/nebo kartovou společnost, aby určili vhodný způsob ověření shody.
Pro třetí strany - poskytovatele služeb se nabízejí dvě možnosti, jak ověřovat shodu:
1) Roční posouzení: Poskytovatelé služeb mohou provést roční posouzení shody s PCI DSS sami a předložit potvrzení svým zákazníkům
jako důkaz shody, nebo
2) Posouzení (vícenásobné) na vyžádání: Pokud poskytovatelé služeb nepodstoupí vlastní roční posouzení shody s PCI DSS, budou si
muset nechat své služby prověřit na žádost zákazníků a/nebo se účastnit posouzení shody s PCI DSS spolu s každým ze svých
zákazníků a výsledky jednotlivýchhodnocení poskytnout příslušnému zákazníkovi(zákazníkům).
Pokud třetí strana podstoupí svoje vlastní posouzení shody s PCI DSS měla by poskytnout svým zákazníkům adekvátní důkazy potvrzující, že
rozsah posouzení shody s PCI DSS poskytovatele služby pokryl služby vztahující se ke konkrétnímu zákazníkovi a že relevantní požadavky PCI
DSS byly přezkoumány a shledány účinnými. Specifický typ důkazů poskytnutý poskytovatelem služeb svým zákazníkům bude záviset na
smlouvě uzavřené mezi těmito stranami. Například, poskytnutí osvědčení AOC (Attestation of Compliance, Osvědčení o shodě) a/nebo
odpovídající části zprávy poskytovatele služeb ROC (Report on Compliance, Zpráva o shodě) (upravené vzhledem k ochraně důvěrných
informací) může poskytnout všechny nebo některé informace.
Obchodníci a poskytovatelé služeb musí navíc spravovat a monitorovat shodu s PCI DSS všech přidružených třetích stran – poskytovatelů služeb,
které mají přístup k datům držitelů karet. Podrobnosti viz Požadavek 12.8 v tomto dokumentu.
strana13
Duben 2015
Doporučené postupy implementace požadavků PCI DSS do běžného provozu
K zajištění stálého a náležitého provádění bezpečnostní kontroly měly by být požadavky PCIDSSimplementoványdoběžných provozních procesů
(Business-as-usual, BAU) jako součástcelkovébezpečnostní strategiesubjektu. Subjektu to umožníprůběžně sledovatúčinnost
svýchbezpečnostních kontrolaudržovat svéprostředí ve shodě sPCIDSSmezijednotlivými vyhodnoceními dle PCIDSS. Příkladytoho, jakzačlenit
PCIDSSdoběžných provozních procesů mimo jiné zahrnují:
1. Monitorování řízení zabezpečení – jako jsou firewally, systémy detekce průniků / systémy prevence průniků (intrusion-detection
systems/intrusion-prevention systems, IDS/IPS),monitorování integrity souborů (file-integrity monitoring, FIM), anti-virové programy (AV),
kontrola přístupů, apod. – k zajištění jejich efektivní a předpokládané činnosti.
2. Zajištění, že všechna selhání v řízení zabezpečení jsou detekována a je na ně včasně reagováno. Procesy reagování na selhání v řízení
zabezpečení by měly zahrnovat:

Obnovení řízení zabezpečení

Identifikování příčin selhání

Identifikace a řešení jakýchkoli bezpečnostních problémů, které zapříčinily selhání řízení zabezpečení

Implementace opatření (jako jsou procesní nebo technické kontroly) k prevenci opakování příčin selhání

Obnovení monitorování řízení zbezpečení, třeba rozšířeným monitorováním po určité období k ověření efektivního fungování řízení
3. Přezkum změn v prostředí (například při doplnění nových systémů, změnách konfigurace systému nebo sítě) před dokončením změny, a
provedením následujících kroků:

Určete možný dopad na rozsah PCI DSS (například nové pravidlo firewallu, které povoluje spojení mezi systémem v prostředí dat
držitele karet a dalším systémem, může vyvolat zahrnutí dalšího systému nebo sítě do rozsahu PCI DSS).

Identifikujte požadavky PCI DSS vztahující se na systémy nebo sítě ovlivněné změnami (například je-li nový systém v rozsahu PCI
DSS, bude se muset konfigurovat podle standardů konfigurace systému, včetně FIM (file-integrity monitoring), AV (anti-virus), záplat
(patches), auditovatelných záznamů (audit logging), apod., a bude se muset přidat do čtvrtletního plánu skenovánízranitelnosti).

Aktualizujte rozsah posouzení dle PCI DSS a implementujte příslušné bezpečnostní kontroly.
4. Změny v organizační struktuře (například sloučení společností nebo akvizice) by měly vést k formálnímu přezkumu jejich vlivu na rozsah
posouzení a požadavky PCI DSS.
5. Provádění pravidelných přezkumů a komunikace k potvrzení skutečnosti, že požadavky PCI DSS jsou stále účinné a pracovníci dodržují
bezpečné postupy. Pravidelné prověrky by měly zahrnovat všechna zařízení a místa, včetně prodejních míst,datových center, apod., a
zahrnovat prověrku systémových komponent (nebo vzorků systémových komponent), aby se ověřilo, že požadavky PCI DSS jsou stále
účinné – například byly uplatněny konfigurační standardy, záplaty a antivirové programy jsou aktuální, auditovatelné záznamy (audit logs)
byl prověřeny, apod. Frekvence pravidelných přezkumů by měla být určena subjektem, na základě velikosti a komplexnosti jeho prostředí.
Tyto přezkumy také mohou ověřit, zda je udržována příslušná evidence – například auditovatelné logy, zprávy o skenovánízranitelnosti,
prověrky firewallů, apod. –a posloužit k usnadnění přípravy subjektu na dalšívyhodnoceníshody.
strana14
Duben 2015
6. Přezkum hardwarových a softwarových technologií by měl proběhnout nejméně jednou ročně, aby se ověřilo, že jsou i nadále podporovány
dodavatelem a vyhovují bezpečnostním požadavkům subjektu, včetně PCI DSS. Pokud se zjistí, že technologie nejsou nadále
dodavatelem podporovány nebo již nevyhovují bezpečnostním požadavkům subjektu, subjekt musí připravit plán nápravy, a to podle
potřeby včetně výměny technologie.
Kromě výše uvedených postupů může organizace zvážit oddělení povinností pracovníků s bezpečnostními funkcemi, takže bezpečnostní a/nebo
auditorské funkce jsou odděleny od funkcí provozních. Napříkladv prostředí, kdy jeden pracovník vykonává vícenásobné role (na přiklad
administrátorské a bezpečnostní operace) povinnosti mohou být přiřazeny takovým způsobem, aby nikdo neměl celkovou odpovědnost (end-toend) za procesy bez nezávislé kontroly. Například odpovědnost za konfiguraci a odpovědnost za schvalování změn by měly být přiřazeny různým
osobám.
Poznámka: Tyto osvědčené postupy pro implementaci PCI DSS do běžných provozníchprocesů jsou
poskytnuty pouze jako doporučení a vysvětlení a nenahrazují aninerozšiřují požadavky PCI DSS.
strana15
Duben 2015
Pro hodnotitele: Výběr vzorků provozních zařízení/systémových komponent
Výběr vzorků (sampling) hodnotitelům (assessors)usnadníposouzení u velkého počtu provozních zařízení a/nebo systémových komponent.
I když jeprohodnotitele přijatelnévybrat vzorky provozních zařízení/systémových komponentjako součást jejichpřezkumu shodyPCIDSS u
subjektu, pro subjekt není přijatelnéaplikovat požadavkyPCIDSSpouze navzorekjejichprostředí(například požadavkyna
čtvrtletnískenovánízranitelnostiplatí provšechny komponentysystému). Stejně taknení přijatelnéprohodnotitele
přezkoumatpouzevzorekpožadavkůstandardu PCIDSS.
Vzhledem k celkovémurozsahu a složitostiposuzovaného prostředí, můžehodnotitel nezávisle zvolitreprezentativní vzorkyprovozních zařízení/
systémových komponents cílem posouditsoulad subjektu s požadavkyPCIDSS. Tyto vzorky musí býtdefinovány nejprvepro provozníobjekt apak
pro systémové komponentyv rámci každéhovybraného provozního zařízení. Vzorkymusíbýtreprezentativnímvýběremze všechdruhů a umístění
provozních zařízení, stejně jako ze všechdruhůsystémovýchkomponentv rámci vybraných provozních objektů. Vzorkymusí být
dostatečněrozsáhlé, abyposkytlyhodnotiteli jistotu, že kontrolní opatření jsou implementována podle očekávání.
Příklady provozních zařízenímimo jiné zahrnují kanceláře subjektu, obchody, sklady, umístění frančíz, zpracovávací zařízení, datová centra a
další typy zařízení v různých lokalitách. Vzorky by měly zahrnovat systémové komponenty za každé vybraný provoznízařízení. Například pro
každé vybrané provozní zařízení je třeba uvažovat různé operační systémy, funkce a aplikace, které se nacházejí v prověřované oblasti.
Například hodnotitel můžedefinovat v rámci provozního zařízenívzorek, který zahrne servery Sun provozující software Apache, servery Windows
provozující databázi Oracle, systémy hlavních počítačů provozující historické (legacy) aplikace pro zpracování karet, servery přenosu dat
provozující HP-UX a Linux servery provozující MySQL. Pokud jsou všechny aplikace provozovány pod jedinou verzí operačního systému
(například Windows 7 nebo Solaris), vzorek by měl zahrnovat škálu aplikací (například databázové servery, webové servery, servery přenosu dat).
Při nezávislém výběru vzorků provozníchobjektů/ systémových komponent by měli hodnotitelé brát v úvahu následující:

Pokud jsou uplatňovány standardní, centralizované bezpečnostní a provozní procesy a kontroly požadavků PCI DSS, které zajišťují
důslednost a kterými se každé provozní zařízení / systémová komponenta musí řídit, může být vzorek menší než je nezbytné pro případ,
kdy nejsou uplatňovány žádné standardní procesy / kontroly. Vzorek musí být dostatečně rozsáhlý, aby poskytnul hodnotiteli postačující
ujištění, že je každé provozní zařízení/ systémová komponenta konfigurována podle standardního procesu. Hodnotitel musí ověřit,
zdastandardizované, centralizované kontroly jsou implementovány a pracují efektivně.

Pokud existuje a je uplatňován více než jeden typ standardního bezpečnostního a/nebo provozního procesu (například u různých typů
provozních zařízení/ systémových komponent), musí být vzorek dostatečně rozsáhlý, aby zahrnoval provozní zařízení/systémové
komponenty zajišťované jednotlivými typy procesu.

Pokud nejsou zavedeny žádné standardní procesy a kontroly požadavků standardu PCI DSS a každé provozní zařízení/ systémová
komponenta je řízena nestandardními procesy, musí být vzorek dostatečně rozsáhlý, aby se hodnotitel ujistil, že každéprovozní zařízení/
systémová komponenta má přiměřeně implementovány požadavky PCI DSS.
strana16
Duben 2015

Vzorky systémových komponent musí zahrnovat každý používaný typ a kombinaci. Například je-li vzorkována aplikace, vzorek musí
zahrnovat všechny verze a platformy pro každý typ aplikace.
Pro každé využití výběru vzorků, hodnotitel musí:

Dokumentovat důvody rozhodnutí pro výběr techniky a velikost vzorku,

Dokumentovat a ověřit standardizované procesy dle PCI DSS a kontroly použité k určení velikosti vzorku, a

Vysvětlit jaká je vypovídající hodnota vzorkua jeho reprezentativnost vzhledem k celkovému množství.
Hodnotitelmusí zdůvodnit výběr vzorků při každém vyhodnocení. Má-li se použít metoda výběruvzorků, pak se musí pro každéposouzení použít
odlišné vzorky pro provozní zařízenía systémové komponenty.
Další informace viz také:
Dodatek D: Segmentace a výběr vzorků provozních zařízení/ systémových komponent.
Kontrola náhradních řešení
Každoročně musí být každá kontrola náhradního řešení(Compensating Control) dokumentována, revidována a ověřena hodnotitelem a zahrnuta
do předložené Zprávy o shodě (Report on Compliance, ROC), podle Přílohy B: Kontrola náhradních řešení a Přílohy C: Výkaz kontroly náhradních
řešení.
Pro každou kontrolu náhradního řešení musí být vyplněnPracovní tabulka náhradního řešení/Compensating Controls Worksheet(Příloha C:).
Navíc by výsledky kontroly měly být dokumentovány ve Zprávě o shodě, ROC, v odpovídající sekci požadavků PCI DSS.
Další podrobnosti o „kontrole náhradních řešení“ viz výše uvedené Přílohy B a C.
strana17
Duben 2015
Pokyny a obsah dokumentu Zpráva o shodě
Pokyny ke Zprávě o shodě (Report on Compliance, ROC) a její obsah je nyní popsán v šabloně pro PCI DSS ROC (PCI DSS ROC Reporting
Template).
Šablona pro PCI DSS ROC musí být použita jako šablona pro vytvoření Zprávy o shodě, ROC. Hodnocený subjekt by měl při tvorbě zprávy
dodržovat požadavky každé kartové společnosti (VISA, MasterCard atp.), aby zajistil, že každá kartová společnost uzná status shody daného
subjektu. Kontaktujte jednotlivé kartové společnosti nebo acquirera za účelem zjištění požadavků a pokynů.
Postup vyhodnocení požadavků PCI DSS
1. Potvrďte rozsah posouzeníPCI DSS.
2. Proveďte posouzení PCI DSS v prostředí, pro každé prostředí uplatněte testovacích postupy.
3. Dokončete příslušnou zprávu o posouzení(tj. Dotazník vlastního hodnocení, Self-AssessmentQuestionnaire (SAQ) nebo Zprávu o shodě,
Report on Compliance (ROC)), včetně dokumentace všech kontrol náhradních řešení, podle příslušných vysvětlení a instrukcí PCI.
4. Dokončete Osvědčení o shodě (AttestationofCompliance) pro poskytovatele služeb nebo obchodníky v celé šíři. Osvědčení o shodě je
dostupné na internetových stránkách PCI SSC.
5. Předložte dotazníky SAQ neboZprávu o shodě (ROC) a Osvědčení o shodě, spolu s dalšími vyžadovanými dokumenty – jako jsou ASV
skenovací zprávy – svému acquirerovi (za obchodníky) nebo kartové společnosti nebo jinému vyžadujícímu subjektu (za poskytovatele
služeb).
6. V případě potřeby proveďte nápravu všech požadavků, které nebyly v průběhu posouzení v souladu a poskytněte aktualizovanou zprávu
strana18
Duben 2015
Podrobné požadavky a postupy posouzení bezpečnosti PCI DSS
Pro požadavky a postupyposouzení bezpečnostiPCI DSS jsou záhlaví jednotlivých sloupců tabulky definována následovně:

PCI DSS Požadavky – Tento sloupec definuje požadavky Standardu bezpečnosti dat (DSS); shoda s PCI DSS bude validována
(ověřena) vůči těmto požadavkům.

Testovací Procedury– V tomto sloupci jsou uvedeny procesy, které musí hodnotitel provést, aby ověřil, zda požadavkům PCI DSS bylo
vyhověno a jsou účinné.

Vysvětlení– Tento sloupec popisuje záměr nebo bezpečnostní hledisko v pozadí každého požadavku PCI DSS. Tento sloupec obsahuje
pouze vysvětlení a jeho smyslem je umožnit porozumění záměru každého požadavku. Vysvětlení v tomto sloupci nenahrazuje ani
nerozšiřuje požadavky PCI DSS a testovací postupy.
Poznámka: Požadavky PCI DSS nejsou pokládány za splněné, pokud nebyly implementovány kontroly nebo se jejich dokončení plánuje někdy v
budoucnosti. Po té, co určité otevřené nebo nesplněné položky jsou subjektem vyřešeny, hodnotitel pak znovu vyhodnotí, zda náprava je úplná a
že všem požadavkům bylo vyhověno.
Další zdroje informací k dokumentování vyhodnoceníPCI DSS jsou na internetových stránkách PCI SSC:

Ohledně instrukcí k vyhotovení Zprávy o shodě (ROC), odkazujeme na Šablonu pro PCI DSS ROC (PCI DSS ROC Reporting Template).

Ohledně instrukcí k vyhotovení Dotazníku pro vlastní vyhodnocení(SAQ), odkazujeme naPCI DSS Instrukce a návody pro SAQ(PCI DSS
SAQ Instructions and Guidelines).

Ohledně instrukcí k předložení Zprávy o ověření shody s PCI DSS, odkazujeme na Osvědčení o shodě s PCI DSS (PCI DSS Attestations
of Compliance).
strana19
Duben 2015
Vybudování a udržování bezpečné sítě a systémů
Požadavek 1: Instalovat a udržovat konfiguraci firewallů za účelem ochrany dat držitelů karet
Firewally jsou zařízení, která kontrolují autorizované datové přenosy mezi firemní sítí (interní) a nedůvěryhodnými sítěmi (externími), i přenosy
do/z citlivých oblastí v rámci důvěryhodné interní sítě subjektu. Příkladem citlivé oblasti v rámci důvěryhodné sítě subjektu je prostředí dat držitelů
karet.
Firewall prověřuje veškeré síťové přenosy a blokuje ty, které nesplňují stanovená bezpečnostní kritéria.
Všechny systémy musí být chráněny před neautorizovaným přístupem z nedůvěryhodných sítí, ať již jde o přístupy do systému prostřednictvím
internetu (jako je e-commerce), přístup zaměstnanců k internetu prostřednictvímwebového prohlížeče na stolních počítačích, přístupy
zaměstnanců k e-mailům, vyhrazená spojení typu „business to business“, přístupy prostřednictvím bezdrátových sítí nebo jiných zdrojů. Často
zdánlivě bezvýznamné cesty z/do nedůvěryhodných sítí mohou představovat nechráněné cesty do klíčových systémů. Firewally jsou klíčovým
ochranným mechanismem jakékoliv počítačové sítě.
Jiné systémové komponenty mohou vykonávat funkčnost firewallu, za předpokladu, že vyhovují minimálním požadavkům na firewally
definovaných v Požadavku 1. Pokud jsou jiné systémové komponenty použity v rámci prostředí dat držitelů karet k zajišťování funkčnosti firewallu,
pak musí být zahrnuty v rozsahu a vyhodnocování dle Požadavku 1.
PCI DSS Požadavky
1.1Zavést konfigurační standardy pro
firewally a routery, které zahrnují
následující kroky:
Testovací Procedury
1.1 Přezkoumat konfigurační standardy firewallů a routerů a
další dokumentaci specifikovanou níže a ověřit, že
standardy jsou kompletní a implementovány dle
následujících kroků:
Vysvětlení
Firewally a routery jsou klíčové komponenty
architektury, které řídí vstup do sítě a výstup ze
sítě. Jsou to softwarová nebo hardwarová
zařízení, která blokují nežádoucí přístup a
spravují autorizovaný přístup do sítě a výstup ze
sítě.
Konfigurační pravidla a postupy pomohou zajistit,
aby první obrannálinie organizace (kterou firewall
představuje) zůstala při ochraně jeho dat odolná.
1.1.1 Formální proces schvalování a
testování všech síťových připojení a
změny konfigurací firewallů a routerů
1.1.1.a Prověřit dokumentované postupy a ověřit, zda existuje
formální proces pro testování a schválení všech bodů:
 Síťová spojení
 Změny v konfiguraci firewallu a routeru
1.1.1.b Dotázat se odpovědného pracovníka ohledně vzorku
síťového spojení a prověřit záznamy, zda síťová spojení byla
schválena a otestována.
Dokumentovaný a implementovaný proces pro
schvalování a testování všech spojení a změn
firewallů a routerů napomůže při prevenci
bezpečnostních problémů způsobených
nesprávnou konfigurací sítě, routeru nebo
firewallu.
Bez formálního odsouhlasení a testování změn by
nemusely být aktualizovány záznamy o změnách,
což by mohlo vést k rozporuplnosti mezi
strana20
Duben 2015
PCI DSS Požadavky
1.1.2 Aktuální diagram sítě
identifikující všechna spojení mezi
prostředím dat držitelů karet a dalšími
sítěmi, včetně sítí bezdrátových.
1.1.1.c Identifikovat vzorek aktuálních změn provedených u
konfigurace firewallu a routeru, porovnat jej se záznamem
změny a dotázat se odpovědného pracovníka, zda změny byly
schváleny a ověřeny.
dokumentací sítě a skutečnou konfigurací.
1.1.2.aPrověřit diagram(-y) a prohlédnout konfigurace sítě a
ověřit, zda existuje aktuální diagram sítě a zda dokumentuje
všechna spojení na data držitelů karet, včetně všech
bezdrátových sítí.
Diagramy sítí popisují, jak jsou sítě konfigurovány
a identifikují umístění všech síťových zařízeních.
1.1.2.bDotázat se odpovědných pracovníků a ověřit, zda
diagramy jsou udržovány aktuální.
1.1.3 Aktuální diagram zobrazující
všechny toky dat držitelů karet napříč
systémy a sítěmi.
1.1.3Zkontrolovat diagram toku dat a dotázat se pracovníků,
zda diagram:
 znázorňuje všechny toky dat držitelů karet napříč systémy
a sítěmi,
 je udržován aktuální a aktualizuje se podle potřeby při
změnách prostředí.
1.1.4 Požadavky na firewall na
každém internetovém připojení a mezi
každou demilitarizovanou zónou
(DMZ) a zónou vnitřní sítě.
Vysvětlení
1.1.4.aZkontrolovat konfigurační standardy firewallu a ověřit,
zda zahrnují požadavky na firewall na každém internetovém
připojení a mezi každou demilitarizovanou zónou (DMZ)
a zónou vnitřní sítě.
1.1.4.bOvěřit, zda aktuální diagram sítě je konzistentní s
konfiguračními standardy firewallu.
Bez aktuálních síťových diagramů by zařízení
mohla být přehlédnuta a nevědomky vynechána z
bezpečnostních kontrol implementovaných pro
PCI DSS a ponechána zranitelná vůči zneužití.
Diagramy toků dat držitelů karet identifikují
umístění všech dat držitelů karet, která se
uchovávají, zpracovávají nebo přenášejí v rámci
sítě.
Diagramy sítě a toku dat držitelů karet
napomáhají organizaci porozumět a udržovat
přehled o rozsahu jejího prostředí, a to
znázorněním toků dat držitelů karet napříč sítěmi
a mezi jednotlivými systémy a zařízeními.
Použití firewallu na každém internetovém
připojení do (a ze) sítě a mezi každou
demilitarizovanou zónou (DMZ) a vnitřní sítí
umožňuje organizaci monitorovat a řídit přístup a
minimalizovat možnost, aby zlovolný jedinec
získal přístup do vnitřní sítě prostřednictvím
nechráněného připojení.
1.1.4.c Prověřit konfigurace sítí a ověřit, že firewall je umístěn
u každého internetového připojení a mezi každou
demilitarizovanou zónou (DMZ) a zónou vnitřní sítě, a to podle
dokumentovaných konfiguračních standardů a diagramů sítě.
strana21
Duben 2015
PCI DSS Požadavky
1.1.5Popis skupin, rolí a odpovědností
pro správu síťových komponent
1.1.5.aOvěřit, zda konfigurační standardy firewallů a routerů
zahrnují popis skupin, rolí a odpovědností pro správu
komponent sítě.
1.1.5.bDotázat se pracovníků zodpovědných za správu
komponent sítě, a potvrdit, že role a odpovědnosti jsou
přiřazeny v souladu s dokumentací.
1.1.6 Dokumentování a provozní
zdůvodnění používání veškerých
povolených služeb, protokolů a portů,
včetně dokumentování
bezpečnostních charakteristik
implementovaných pro protokoly
považované za nezabezpečené.
Příklady nezabezpečených služeb,
protokolů a portů jsou mimo jiné FTP,
Telnet, POP3, IMAP, a SNMP v1 a v2.
1.1.6.a Ověřit, zda konfigurační standardy firewallů a routerů
zahrnují dokumentovaný seznam všech služeb, protokolů a
portů včetně provozního zdůvodnění každého z nich –
například hypertextový přenosový protokol (HTTP, hypertext
transfer protocol) a protokoly Secure Sockets Layer (SSL),
Secure Shell (SSH) a Virtual Private Network (VPN).
1.1.6.b Identifikovat nezabezpečené přípustné služby,
protokoly a porty a ověřit, zda jsou bezpečnostní prvky
dokumentovány pro každou službu.
1.1.6.cPrověřit firewallové a routerové konfigurace, a ověřit,
zda dokumentované bezpečnostní prvky jsou implementovány
pro každou nezabezpečenou službu, protokol a port.
Vysvětlení
Tento popis rolí a přidělení odpovědnosti
zajišťuje, že pracovníci si jsou vědomi, kdo je
odpovědný za bezpečnost všech komponent sítě
a že ti, kdo jsou pověřeni správou komponent si
jsou vědomi své odpovědnosti. Pokud nejsou role
a odpovědnosti formálně přiděleny, zařízení by
mohla zůstat nespravovaná.
K napadení často dochází vzhledem k
nepoužívaným nebo nezabezpečeným službám a
portům a četné organizace nezáplatují zranitelná
místa svých služeb, protokolů a portů, které
nepoužívají (i když zranitelná místa jsou stále
přístupná). Srozumitelným definováním a
dokumentováním služeb, protokolů a portů, které
jsou nezbytné pro jejich činnost mohou
organizace zajistit, že všechny ostatní služby jsou
deaktivovány nebo odstraněny.
Pokud jsou nezabezpečené služby, protokoly a
porty nezbytné pro zabezpečení provozu, mělo by
být riziku spojenému s těmito protokoly jasně
porozuměno a organizací akceptováno. Použití
protokolů by mělo být zdůvodněné a měly by být
dokumentovány a implementovány bezpečnostní
prvky umožňující těmto protokolům bezpečné
použití. Pokud tyto nezabezpečené služby,
protokoly a porty nejsou nezbytné pro
zabezpečení provozu, měly by být deaktivovány
nebo odstraněny.
strana22
Duben 2015
PCI DSS Požadavky
1.1.7 Požadavek revize firewallových a
routerových sad nejméně každých šest
měsíců
Vysvětlení
1.1.7.a Ověřit, zda konfigurační standardy firewallů a routerů
vyžadují přezkum souborů firewallových a routerových
pravidel nejméně každých šest měsíců.
Tento přezkum dává organizaci příležitost, aby
nejméně každého půl roku odstranila jakákoli
nepotřebná, zastaralá nebo nesprávná pravidla a
zajistila, že všechna pravidla povolují jen
autorizované služby a porty, které jsou v souladu
s dokumentovanými provozními důvody.
1.1.7.bZkontrolovat dokumentaci vztahující se k ověření
souborů pravidel a dotažte se odpovědných pracovníků, zda
jsou soubory firewallových a routerových pravidel
přezkoumány nejméně každých šest měsíců.
1.2Vytvořit firewallovou a routerovou
konfiguraci, která omezuje připojení
mezi nedůvěryhodnými sítěmi a
jakýmikoliv systémovými komponentami
v prostředí dat držitelů karet.
1.2Prověřit konfigurace firewallů a routerů a provést následující
kroky k ověření, zda připojení jsou omezena mezi
nedůvěryhodnými sítěmi a systémovými komponentami v
prostředí dat držitelů karet:
Poznámka: „Nedůvěryhodná síť” je
jakákoliv síť, která je externí pro sítě
náležející posuzovanémusubjektu
a/nebo která se vymyká subjektu
z možností kontroly nebo řízení.
1.2.1 Omezit příchozí i odchozí
přenosy na ty, které jsou nezbytné pro
prostředí dat držitelů karet, a zejména
odmítnout všechny ostatní přenosy.
Organizace s vysokým výskytem změn v
souborech firewallových a routerových pravidel
mohou zvážit provádění těchto přezkumů ještě
častěji, aby soubory pravidel
odpovídalyprovozním potřebám.
Je nezbytné, aby se instalovala ochrana sítě,
mezi interní, důvěryhodnou sítí a jakoukoli
nedůvěryhodnou sítí, která je externí a/nebo která
se vymyká subjektu z možností kontroly nebo
řízení. Jestliže není toto opatření správně
implementováno, znamená to, že subjektu bude
hrozit neautorizovaný přístup ze strany zlovolných
jedinců nebo softwaru.
Aby funkčnost firewallu byla účinná, musí být
správně konfigurován, aby řídil a/nebo
omezovalpřenosy dovnitř nebo ven ze sítě
subjektu.
1.2.1.a Zkontrolovat konfigurační standardy firewallů a routerů
a ověřit, zda identifikují příchozí i odchozí přenosy nezbytné
pro prostředí dat držitelů karet.
1.2.1.bZkontrolovat konfigurační standardy firewallů a routerů
a ověřit, zda omezují příchozí i odchozí přenosy pouze na ty,
které jsou nezbytné pro prostředí dat držitelů karet.
1.2.1.c Zkontrolovat konfigurační standardy firewallů a routerů
a ověřit, zda ostatní příchozí i odchozí přenosy jsou
odmítnuty; například s použitím příkazu„zakázat všechny”
nebo implicitním odmítnutím po příkazu povolit.
Tento požadavek je zacílen na znemožnění
přístupu zlovolným jedincům do sítě subjektu
prostřednictvím neautorizovaných IP adres nebo
použitím služeb, protokolů nebo portů
neautorizovaným způsobem (například odesláním
dat získaných z vaší sítě ven na nedůvěryhodný
server.)
Implementování pravidla, které odmítne jakýkoli
provoz dovnitř i ven, který není potřebný pro
specifický účel, zabrání vzniku zranitelností, které
by umožnily nezamýšlené nebo potenciálně
škodlivé komunikace dovnitř nebo ven.
strana23
Duben 2015
PCI DSS Požadavky
1.2.2 Zabezpečit a synchronizovat
konfigurační soubory routerů.
Vysvětlení
1.2.2.a Zkontrolujte konfigurační standardy routerů a ověřte,
zda jsou zabezpečeny před neautorizovaným přístupem.
Pokud spuštěné (nebo aktivní) konfigurační
soubory routeru obsahují aktuální, bezpečné
nastavení, start-up soubory (které jsou používány
při re-startu nebo bootování routerů) musí být
aktualizovány se stejným bezpečnostním
nastavením, aby se zajistilo použití těchto
nastavení při spuštění start-up konfigurace.
1.2.2.b Zkontrolovat konfigurace routerů a ověřit, zda jsou
synchronizovány – například běžící (nebo aktivní) konfigurace
se shoduje s konfigurací při startu (start-up konfigurace,
používaná při bootování, spouštění zařízení).
Vzhledem k tomu, že se konfigurační soubory
start-upu spouštějí jen příležitostně, jsou tyto
často opomíjeny a nejsou aktualizovány. Když se
router restartuje a zavádí se konfigurace startupu, která nebyla aktualizována se stejným
bezpečnostním nastavením jako je pro spuštěnou
konfiguraci, může to vyvolat oslabení pravidel,
cožmůže umožnit zlovolným jedincům přístup do
sítě.
1.2.3 Instalovat perimetrové (hraniční)
firewally mezi všemi bezdrátovými
sítěmi aprostředím dat držitelů karet a
konfigurovat tyto firewally tak, aby
odmítaly nebo povolovaly (pokud jsou
takové přenosy nutné z provozních
důvodů) pouzeautorizované přenosy
mezi bezdrátovým prostředíma
prostředím dat držitelů karet.
1.2.3.a Zkontrolovat konfigurace firewallů a routerů a ověřit
existenci perimetrových firewallů mezi všemi bezdrátovými
sítěmi a prostředím dat držitelů karet.
1.2.3.b Ověřit, zdafirewally odmítají nebo povolují (pokud jsou
takové přenosy nutné z provozních důvodů) pouze
autorizované přenosy mezi bezdrátovým prostředím a
prostředím dat držitelů karet.
Známá (nebo neznámá) implementace a
zneužívání bezdrátové technologie v rámci sítě je
obvyklou cestou k podvodnému získání přístupu k
síti a k datům držitelů karet. Jestliže je instalováno
nějaké bezdrátové zařízení nebo síť bez vědomí
subjektu, mohl by zlovolný jedinec snadno a
„nepozorovaně“ proniknout do sítě. Jestliže
firewally neomezují přístup z bezdrátových sítí do
prostředí platebních karet, podvodníci, kteří získali
neautorizovaný přístup do bezdrátové sítě, se
mohou snadno připojit do prostředí platebních
karet a proniknout k informacím o účtech.
Firewally musí být instalovány mezi všemi
bezdrátovými síti a prostředí platebních karet, bez
ohledu na účel prostředí, ke kterému je
bezdrátová síť připojena. To může zahrnovat
mimo jiné korporátní sítě, obchodní prodejny,
hostitelské sítě, skladové prostředí, apod.
strana24
Duben 2015
PCI DSS Požadavky
1.3 Zakázat přímý veřejný přístup mezi
internetem a jakoukoliv systémovou
komponentou v prostředí dat držitelů
karet.
Vysvětlení
1.3 Prověřit konfigurace firewallů a routerů – kromě jiného
hraniční router na internetu, router a firewall demilitarizované
zóny (DMZ), segment držitelů karty v DMZ, perimetrový router a
segment interní sítě držitelů karty – a provést následující kroky
s cílem určit, že neexistuje žádný přímý přístup mezi internetem
a systémovými komponenty v interním segmentu držitelů karet:
Smyslem firewallu je spravovat a kontrolovat
veškerá připojení mezi veřejnými systémy a
vnitřními systémy, zejména s těmi, které
uchovávají, zpracovávají nebo přenášejí data
držitelů karet. Jestliže je povolen přímý přístup
mezi veřejnými systémy a prostředím s daty
držitelů karet, je ochrana poskytovaná firewallem
obcházena, a systémové komponenty
uchovávající data držitelů karet mohou být
ohroženy průnikem.
1.3.1Implementovat demilitarizovanou
zónu (DMZ), abyste omezili příchozí
přenosy jen na systémové
komponenty, které poskytují
autorizované veřejně přístupné služby,
protokoly a porty.
1.3.1Zkontrolovat konfigurace firewallů a routerů a ověřit, zda
je implementována demilitarizovaná zóna (DMZ) za účelem
omezení příchozích přenosů pouze na systémové
komponenty, které poskytují autorizované veřejně přístupné
služby, protokoly a porty.
Demilitarizovaná zóna (DMZ) je částí sítě, která
řídí spojení mezi internetem (nebo jinou
nedůvěryhodnou sítí) a službami, které
organizace potřebuje, aby byla přístupná
veřejnosti (jako např. webový server).
1.3.2Omezit příchozí internetové
přenosy na IP adresy v rámci
demilitarizované zóny (DMZ).
příchozí internetové přenosy jsou omezeny na IP adresy v
rámci demilitarizované zóny (DMZ).
Tato funkčnost má zabránit zlovolným jedincům v
přístupu do vnitřní sítě subjektu z internetu nebo
použitím služeb, protokolů nebo portů
neautorizovaným způsobem.
1.3.3Nepřipustit žádné přímé spojení
příchozích nebo odchozích připojení
mezi internetem a prostředím dat
držitelů karet.
nejsou povolena přímá příchozí ani odchozí připojení pro
přenosy mezi internetem a prostředím dat držitelů karet.
Kontrola všechpříchozích a
odchozíchpřipojeníumožňuje přezkoumat a omezit
přenosyna základězdrojové a/nebocílové adresy,
jakož i přezkoumat ablokovatnežádoucíobsah,
čímž se
zabránínefiltrovanémupřístupumezinedůvěryhodn
ýmadůvěryhodnýmprostředím. To napomůže
zabránit např. zlovolným jedincům posílat data,
která získali uvnitř vaší sítě ven na externí
nedůvěryhodný server v nezabezpečené síti.
strana25
Duben 2015
PCI DSS Požadavky
Vysvětlení
1.3.4 Implementovat anti-spoofingová
opatření k detekci a blokování
padělaných zdrojových IP adres před
vstupem do sítě. (Pozn. překl.:
Spoofing je vytvoření falešné zdrojové
IP adresy.)
1.3.4 Zkontrolovat konfigurace firewallů a routerů a ověřit, zda
jsou implementována anti-spoofingová opatření, například
interní adresy nemohou být předány z internetu do
demilitarizované zóny (DMZ).
Paket obvykle obsahujeIPadresupočítače, který
jej původněposlal, aby ostatní počítačev síti
poznali, odkudpaketpřišel. Zlovolní jedincisečasto
snažízfalšovat (spoofing) (neboli napodobovat)
odesílacíIP adresu, aby se cílový
systémdomníval, žepaketpochází z
důvěryhodnéhozdroje.
Filtrování paketů,přicházejícíchdo
sítě,pomáhámimo jinézajistit,
žepaketynejsou"zfalšované", aby předstíraly, že
jsou zasílány z vlastní vnitřnísítěorganizace.
1.3.5Nepovolit neautorizované odchozí
přenosy z prostředí dat držitelů karet
na internet.
přenosy z prostředí dat držitelů karet na internet jsou
explicitně autorizována.
Veškeré přenosy odcházející z prostředí dat
držitelů karet by měly být vyhodnoceny, aby se
zajistilo, že jsou dodržována ustanovená,
autorizovaná pravidla. Připojení musí projít
inspekcí, aby se přenosy omezily pouze na
autorizovanou komunikaci (například omezením
zdrojových/cílových adres/portů, a/nebo
blokováním obsahu).
1.3.6 Implementovat kontrolu stavu
integrity (stateful inspection) známou
též jako dynamická filtrace paketů. (To
jest do sítě jsou připuštěna pouze
„navázaná” připojení.)
firewall vykonává kontrolu stavu integrity (stateful inspection),
tj. dynamickou filtraci paketů. (Do sítě mají být připuštěna
pouze „navázaná” připojení, a to pouze tehdy, jsou-li spojenas
dříve ustanovenou relací (session).
Firewall, ktery provádí kontrolu stavu integrity
paketu (stateful inspection), uchovává jeho „stav“
(neboli „status“) pro každé připojení
prostřednictvím firewallu. Díky uchovávání „stavu“
firewall ví, zda zdánlivá odpověď na předchozí
připojení je skutečná platná, autorizovaná
odpověď (protože si „pamatuje“ status každého
připojení) nebo zda se jedná o podvodný přenos
snažící se oklamat firewall, aby získal souhlas s
připojením.
strana26
Duben 2015
PCI DSS Požadavky
Vysvětlení
1.3.7 Umístit systémové komponenty
uchovávající data držitelů karet (jako
jsou databáze) do interní zóny sítě
oddělené od DMZ a jiných
nedůvěryhodných sítí.
systémové komponenty uchovávající data držitelů karet jsou v
interní zóně sítě, oddělené od DMZ a jiných nedůvěryhodných
sítí.
Jsou-li data držitelů karet umístěna uvnitř DMZ, je
přístup k těmto informacím pro externí útočníky
snadnější, protože musejí pronikat menším
množstvím vrstev. Zajištěnísystémových
komponent, které uchovávají data držitelů
karetvzóně interní sítě, oddělené
odDMZadalšíchnedůvěryhodnýchsítípomocífirewa
llu,může zabránitneoprávněnésíťové komunikaci v
přístupu k systémovým komponentám.
Poznámka: Smyslem tohoto Požadavku není
pokrýt uchovávání dat držitelů karet v přechodné
paměti.
1.3.8Nezpřístupňovat soukromé IP
adresy a informace o přesměrování
(routing) neutorizovaným stranám.
Poznámka:Metody k maskování IP
adresování mohou zahrnovat, kromě
jiného:
 Network Address Translation (NAT)
(překlad síťových paketů)
 Umístěním serverů, obsahujících
data držitelů karet za proxy
servery/firewally nebo schránky
obsahu (content cages)
 Odstranění nebo filtrování cest
nabídky(reklamy) pro soukromé sítě.
které využívají registrované
adresování
 Interní použití pomocí adresového
prostoru RFC 1918 místo
registrovaných adres.
1.3.8.a Zkontrolovat konfigurace firewallů a routerů a ověřit,
zda jsou účinné metody zabraňující odhalení soukromé IP
adresy a informací o přesměrování z interních sítí na internet.
1.3.8.bDotázat se pracovníků a ověřit v dokumentaci, zda
jakékoli zpřístupnění soukromé adresy IP a informací o
přesměrování na externí subjektyje autorizováno.
Omezenízveřejněníinterních nebo privátních
IPadresje nezbytné, aby se zabránilo hackerovi v
získání IP adresy vnitřní sítě a pomocí této
informace získat přístup do sítě.
Metody používané pro splnění záměru tohoto
požadavku se může lišit v závislosti na
používáníspecifickésíťové technologie.
Napříkladkontrolypoužívanéke splnění tohoto
požadavkumohou být odlišnépro sítěIPv4 než pro
sítěIPv6.
strana27
Duben 2015
PCI DSS Požadavky
1.4Instalovat osobní firewallový software
na jakýkoliv mobilní a/nebo
zaměstnancem vlastněné zařízení, které
se připojuje na internet mimo síť
(například laptopy používané
zaměstnanci), a které jsou také užívány
k přístupu do sítě. Konfigurace firewallů
zahrnují:
 Specifická konfigurační nastavení
jsou definována pro osobní
firewallový software.
 Osobní firewallový software musí být
aktivně spuštěn.
 Osobní firewallový software nesmí
být pozměnitelný uživatelem
mobilního a/nebo zaměstnancem
vlastněného zařízení.
1.5 Zajistit, aby bezpečnostní politiky a
operační procedury pro řízení firewallů
byly dokumentovány,používánya
známyvšemdotčenýmstranám.
1.4.aZkontrolovat politiky a konfigurační standardy a
ověřit, zda:
 Osobní firewallovýsoftware je požadován pro všechna
mobilní a/nebo zaměstnancem vlastněná zařízení, která se
připojují k internetu mimo síť (například laptopy používané
zaměstnanci) jsou-li mimo síť, a která se také používají
k přístupu do sítě.
 Osobní firewallový software je konfigurován k aktivnímu
spuštění.
 Osobní firewallový software je konfigurován tak, aby nebylo
pozměnitelné uživatelem mobilních a/nebo zaměstnancem
vlastněných zařízení.
1.4.bPrověřit vzorek mobilního a/nebo zaměstnancem
vlastněného zařízení a ověřit, zda:
 Osobní firewallový software je instalován a konfigurován
podle specifického konfiguračního nastavení organizace.
 Osobní firewallový software je aktivně spuštěn.
 Osobní firewallový software není pozměnitelný uživatelem
mobilního a/nebo zaměstnancem vlastněného zařízení.
1.5Zkontrolovat dokumentaci a dotázat se pracovníků a ověřit,
zda jsou bezpečnostní politiky a operační procedury pro řízení
firewallů:
 dokumentovány,
 používány,
 známé všem dotčeným stranám.
Vysvětlení
Přenosná výpočetní zařízení, kterým je povoleno
se připojitna internet z vnějšku korporátního
firewallu jsou zranitelnější vůči internetovým
hrozbám. Použití osobního firewallového softwaru
napomáhá chránit zařízení před internetovými
útoky, které mohou využít zařízení k získání
přístupu k systémům a datům organizace jakmile
je zařízení znovu připojeno k síti.
Specifická nastavení konfigurace firewallu jsou
určena organizací.
Poznámka: Smysl tohoto požadavku se vztahuje
na počítače vlastněné zaměstnancem a
organizací. Systémy, které nemohou být
spravovány politikou společnosti, představují
slabou stránku perimetru (hranice) a poskytují
příležitost, kterou zlovolný jedinec může zneužít.
Umožnění nedůvěryhodným systémům, aby se
připojily ksítiorganizacemůže vést k povolení
přístupuútočníkůma dalším zlovolným uživatelům.
Pracovníci si musí být vědomi bezpečnostní
politiky a operačních procedur k zajištění trvalé
správy firewallů a routerů k prevenci
neautorizovaného přístupu k síti.
strana28
Duben 2015
Požadavek 2: Nepoužívat výchozí nastavení od dodavatelepro systémová hesla a jiné bezpečnostní
parametry
Osoby konající ve zlém úmyslu (z hlediska subjektu jak externí, tak interní zlovolní jedinci) často užívají defaultní (výchozí) dodavatelská hesla i
jiná dodavatelská defaultní (výchozí) nastavení k narušení systémů. Tato hesla a nastavení jsou komunitám hackerů dobře známa a lze je snadno
odhalit prostřednictvím veřejně dostupných informací.
PCI DSS Požadavky
Vysvětlení
2.1Vždy změnit výchozí (defaultní)
nastavení od dodavatelů a odstranit
nebo deaktivovat zbytečné defaultní účty
před instalací systému do sítě.
2.1.aVybrat vzoreksystémových komponent, apřihlásit se na
zařízení (s pomocí správce systému) a do
aplikacívyužívajícívýchozíúčty od dodavatelea ověřit, zda byla
změněna VŠECHNA defaultní hesla (včetně těch používaných
pro operačními systémy, software poskytující bezpečnostní
služby, aplikační a systémové účty, POS terminály a řetězce
SNMP Community strings). K vyhledání účtů a hesel od
dodavatelů využít manuály dodavatele a zdroje na Internetu.
Zlovolní jedinci (z hlediska organizace jak externí,
tak interní) často používají defaultní (výchozí)
nastavení dodavatele, jména účtů a hesla k
narušení software operačního systému, aplikací a
systémů, na kterých jsou nainstalovány. Protože
tato výchozí nastavení jsou často publikována a
jsou mezi hackery dobře známa, změnou těchto
nastaveníjsou systémyméněnáchylné k útoku.
2.1.b U vzorku systémových komponent ověřit, zda všechny
zbytečné defaultní účty (včetně účtů používaných pro operační
systémy, bezpečnostní software, aplikace, systémy, POS
terminály, SNMP apod.) jsou odstraněny nebo deaktivovány.
I kdyždefaultní (výchozí) účetnení určenk
používání, změnouvýchozíhoheslana
odolnéunikátníheslo aposléze deaktivace
účtuzabránímezlovolnému jedinci opětovné
zapnutíúčtuazískání přístupus defaultním heslem.
To se vztahuje na VŠECHNA defaultní
hesla, kromě jiných i na ta, používaná
pro operační systémy, software
poskytující bezpečnostní služby,
aplikační a systémové účty, terminály
POS (poin-of-sale), řetezce SNMP
(Simple Network Management Protocol)
Community strings (Pozn. překl.: Obdoba
hesel pro přístup do statistik routeru.)
apod.
2.1.c Dotázat se pracovníků a zkontrolovat podpůrnou
dokumentaci, zda:
 Všechna hesla dodavatelů (včetně defaultních hesel pro
operační systémy, software poskytující bezpečnostní
služby, POS terminály, řetězce SNMP community strings
apod.) jsou změněna před instalací systému do sítě.
 Zbytečné defaultní účty (včetně účtů používaných pro
operační systémy, bezpečnostní software, aplikace,
systémy, POS terminály, SNMP apod.) jsou odstraněny
nebo deaktivovány před instalací systému do sítě.
strana29
Duben 2015
PCI DSS Požadavky
2.1.1 U bezdrátových technologií
připojených na prostředí data držitelů
karet nebo přenášejících data držitelů
karet, změnit VŠECHNA výchozí
nastavení od dodavatelů bezdrátových
technologiÍ, mimo jiné také výchozí
bezdrátové šifrovací klíče, hesla a
řetězce SNMP community strings.
2.1.1.aDotázat se odpovědných pracovníků a zkontrolovat
podpůrnou dokumentaci, zda:
 Defaultní (výchozí) šifrovací klíče byly při instalaci
změněny.

Šifrovací klíče jsou změněny pokaždé, když někdo se
znalostí klíčů opustí společnost nebo změní funkci.
2.1.1.b Dotázat se pracovníků a zkontrolovat politiky a
procedury, zda:
 Je při instalaci vyžadována změna defaultních řetězců
SNMP community strings.
Vysvětlení
Nejsou-libezdrátové sítěimplementoványs
dostatečnou bezpečnou konfigurací(včetně změny
výchozíchnastavení), mohoubezdrátoví špioni
odposlouchávat přenosy, snadno zachytitdata
aheslaasnadno vstoupita zaútočit nasíť.
Kromě toho, protokol pro výměnuklíčůprostarší
verzešifrování802.11x(Wired Equivalent Privacy,
neboliWEP)byl prolomenamůže
způsobitneúčinnost šifrování. Firmwarepro
zařízeníby mělo býtaktualizováno,
abypodporovalobezpečnějšíprotokoly.
 Je při instalaci vyžadována změna defaultních hesel/
heslových frází na přístupových bodech.
2.1.1.cZkontrolovat dokumentaci dodavatele a přihlášení
(login) na bezdrátová zařízení a ověřit s pomocí
administrátora, zda:
 Nejsou používány defaultní řetězce SNMP community
strings.
 Nejsou používána defaultní (výchozí) hesla/ heslové
fráze na přístupových bodech.
2.1.1.dZkontrolovat dokumentaci dodavatele, prověřit
nastavení bezdrátové konfigurace a ověřit, zda firmware v
bezdrátových zařízeních je aktualizováno tak, aby
podporovalo odolné šifrování pro:
 autentizaci po bezdrátových sítích
 přenos po bezdrátových sítích.
2.1.1.eZkontrolovat dokumentaci dodavatele, prověřit
nastavení bezdrátové konfigurace a podle situaceověřit, zda
další bezpečnostní bezdrátová defaultní nastavení dodavatele
byla změněna.
strana30
Duben 2015
PCI DSS Požadavky
Vysvětlení
2.2 Vyvinout konfigurační standardy pro
všechny systémové komponety. Ujistit
se, zda tyto standardy řeší všechny
známé bezpečnostní zranitelnosti a jsou
konzistentní s všeobecně platnými
zpřísněnými standardy ochrany systémů
v odvětví.
2.2.aZkontrolovat konfigurační standardy systémů organizace
pro všechny typy systémových komponent a ověřit, zda tyto
konfigurační standardy jsou konzistentní s všeobecně platnými
zpřísněnými standardy ochrany systémů v odvětví.
V mnoha operačních systémech, databázích a
podnikových aplikacích existují známé slabiny, a
tudíž existují také známé způsoby konfigurace
takových systémů, aby se opravila zranitelná
místa v oblasti bezpečnosti. Na pomoc těm, kteří
nejsou odborníky na bezpečnost, vytvořily
bezpečnostní organizace doporučení k vyššímu
zabezpečení systémů a radí, jak slabiny překonat.
Zdroje zpřísněných standardů ochrany
systémů v odvětví zahrnují mimo jiné:
 Center for Internet Security (CIS)
 International Organization for
Standardization (ISO)
 SysAdmin Audit Network Security
(SANS) Institute
 National Institute of Standards
Technology (NIST)
2.2.b Zkontrolovat politiky, dotázat se pracovníků a ověřit, zda
konfigurační standardy systémů jsou aktualizovány při
identifikaci nových zranitelností, jak je definováno v Požadavku
6.1.
2.2.c Zkontrolovat, politiky, dotázat se pracovníků a ověřit, zda
konfigurační standardy systémů jsou aplikovány při konfiguraci
nových systémů a ověřeny, že jsou účinné před instalováním
systému do sítě.
2.2.d Ověřit, zda konfigurační standardy systémů zahrnují
následující procedury pro všechny typy systémových
komponent:
Příklady zdrojů vysvětlující konfigurační standardy
jsou mimo jiné: www.nist.gov, www.sans.org, a
www.cisecurity.org, www.iso.org, a dále
dodavatelé produktů.
Konfigurační standardy systémů musí být
udržovány aktuální, aby zajistily u nově
identifikovaných slabin jejich opravu před
instalováním systému na síť.
 Změnit všechna defaultní (výchozí) nastavení dodané
dodavateli a eliminace nepotřebných defaultních
(výchozích) účtů
 Implementovat na každém serveru pouze jednu primární
funkci, aby se zabránilo současné existenci funkcí, které
požadují různé bezpečnostní úrovně, na stejném serveru.
 Umožnit pouze nezbytné služby, protokoly, démony apod.,
které jsou vyžadovány systémem (Pozn. překl.: Démon je
program běžící v pozadí.).
 Implementovat dodatkové bezpečnostní prvky pro všechny
požadované služby, protokoly nebo démony pokládané za
nezabezpečené.
 Konfigurovat bezpečnostní parametry systému k prevenci
zneužití.
 Odstranit všechny zbytečné funkčnosti, jako jsou skripty,
drivery, prvky, subsystémy, souborové systémy a zbytečné
webové servery.
strana31
Duben 2015
PCI DSS Požadavky
2.2.1Implementovat pouze jednu
primární funkci na každém serveru,
aby se na jednom serveru zabránilo
spolupráci funkcím, které vyžadují
různé úrovně bezpečnosti. (Např.
internetové servery, databázové
servery a DNS by měly být
implementovány na oddělených
serverech.)
Vysvětlení
2.2.1.aVybrat vzorek systémových komponent, přezkoumat
konfigurace systému a ověřit, zda je na každém serveru
implementována pouze jedna primární funkce.
Pokudserverufunkce, které vyžadují různé úrovně
zabezpečení,jsou umístěny nastejném serveru,
úroveň zabezpečenífunkcís
vyššímibezpečnostními potřebami bude snížena v
důsledkupřítomnostifunkcí s nižšíbezpečnostní
úrovní. Navíc serverové funkces nižšíúrovní
zabezpečenímohou vyvolatbezpečnostníslabiny
udalších funkcína stejném serveru. Tím, že se
zvážípotřebyzabezpečenírůznýchserverovýchfunk
cí,jako součástkonfiguračních standardů
systémuasouvisejících procesů, mohou
organizacezajistit, žefunkce, které vyžadují různé
úrovně zabezpečenínebudouexistovatna stejném
serveru.
2.2.1.bJsou-li použity virtualizační technologie, přezkoumat
konfigurace systému a ověřit, zda je implementována pouze
jedna primární funkce na každé virtuální systémové
komponentě nebo zařízení.
Poznámka: Kde jsou použity
virtualizační technologie, implementujte
pouze jednu primární funkci na každé
virtuální systémové komponentě.
2.2.2 Aktivovat pouze nezbytné služby,
protokoly, démony, apod., které jsou
zapotřebí k vykonávání funkce
systému.
2.2.2.a Vybrat vzorek systémových komponent a přezkoumat
aktivované systémové služby, démony a protokoly a ověřit,
zda jsou povoleny pouze nezbytné služby nebo protokoly.
2.2.3 Implementovat dodatečné
bezpečnostní prvky na jakékoli
požadované služby, protokoly nebo
démony, které jsou považovány za
nezabezpečené – použijte např.
bezpečné technologie jako jsou SSH,
S-FTP, TLS, nebo IPSec VPN k ochraně nezabezpečených služeb,
jako jsou NetBIOS, sdílení souborů,
Telnet, FTP, apod.
2.2.3.aPřezkoumat nastavení konfigurace a ověřit, zda jsou
bezpečnostní prvky dokumentovány a implementovány pro
všechny nezabezpečené služby, démony nebo protokoly.
2.2.2.b Identifikovat jakékoli aktivované nezabezpečené
služby, démony nebo protokoly, dotázat se pracovníků a
ověřit, zda je jejich existence je oprávněná podle
dokumentovaných konfiguračních standardů.
Jak je uvedeno v Požadavku 1.1.6, existuje
mnoho protokolů, které mohu být vyžadovány
provozní činností (nebo je standardně, defaultně
aktivuje) a které jsou běžně využívané zlovolnými
jedinci k průniku do sítě. Zařazení tohoto
požadavku jako součást konfiguračních standardů
organizace a souvisejících procesů zajistí, že jsou
povoleny pouze nezbytné služby a protokoly.
Zavedení bezpečnostních prvků před tím, než
jsou nové servery nasazeny, zabrání instalování
serverů do prostředí s nezabezpečenými
konfiguracemi.
Zajištěním, aby všechny nezabezpečené služby,
protokoly a démoni byly dostatečně zabezpečeny
příslušnými bezpečnostními prvky, znesnadníme
zlovolným jedincům využít běžně používaných
bodů k průniku do sítě.
strana32
Duben 2015
PCI DSS Požadavky
Poznámka:SSL a dřívější verze TLS
není považována za silnou (odolnou)
šifrovací metodu a nemůže být nadále
využívána po 30.6.2016. Pokud do
tohoto data existují implementace použití
protokolu SSL nebo dřívější verze
protokolu TLS, je nutné mít formálně
vypracovanou mitigaci rizik a migrační
plán.
S okamžitou platností se v případě nové
implementace nesmí použít SSL nebo
dřívější verze protokolu TLS.
POS POI terminály (a SSL/TLS koncové
body do kterých jsou zapojeny), které
mohou být ověřeny jako nenáchylné
ke všem známým zneužitím pro SSL a
dřívější verzi TLS, mohou nadále
používat tento bezpečnostní
mechanismus po 30.6.2016.
2.2.4 Konfigurovat bezpečnostní
parametry systému k zabránění
zneužití.
Vysvětlení
2.2.3.bPro POS POI terminály (a SSL/TLS koncové body do
kterých jsou připojeny) využívající SSL a/nebo dřívější verze
TLS, u kterých subjekt potvrzuje, že nejsou citlivé proti
jakýmkoliv známým zneužitím, pro zmiňované protokoly:
Viz odvětvové standardy a osvědčené postupy
pro odolnou (silnou) kryptografii a
zabezpečenéprotokoly (např. NIST SP 800-52 a
SP 800-57, OWASP, atd.).
Potvrdit, že subjekt má dokumentaci (např. dokumentace
poskytovatele, detaily systémové/síťové konfigurace, atd.) která
potvrzuje, že zařízení nejsou citlivá proti jakýmkoliv známým
zneužitím pro SSL a dřívější verzi TLS.
S ohledem na používání SSL/dřívejší verze
TLS: Subjekt používající SSL a dřívější verzi TLS
musí pracovat na tom,aby začal co nejdříve
využívat pouze odolné (silné) šifrovací protokoly.
Kromě toho nesmí být SSL a dřívější verze TLS
implementována do nového prostředí. V době
uveřejnění tohoto dokumentuje obtížné zneužít v
prostředí POS POI známé zranitelnosti. Přesto se
mohou kdykoliv objevit nové zranitelnosti a jena
organizaci, aby siudržela přehled o aktuálních
trendech zranitelnosti a určila, jestije nebo
nenínáchylná k jakýmkoli známým zneužitím.
2.2.3.c.Pro všechna ostatní prostředí používající SSL a/nebo
dřívější verzi TLS:
Přezkoumat, zda obsahuje dokumentovaná verze Mitigace rizik
a Migrační plánnásledující:

Popis použití včetně toho, jaká data jsou přenášena,
typ a číslo systému, který používá a/nebo podporuje
SSL/dřívější verzi TLS, typ prostředí;

Výsledky analýzy rizik a řízení snižování rizik;

Popis procesů promonitorování nových zranitelností
týkajících se SSL/a dřívější verze TLS;

Popis procesů řízení změn, které jsou
implementovány, aby zajistily, že SSL/dřívejší verze
TLS nebude implementována do nového prostředí;

Přehled projektu migračního plánu zahrnující finální
migraci s datem nejpozději do 30.6.2016.
2.2.4.a Dotázat se správců (administrátorů) systému a/nebo
bezpečnostních manažerů a ověřit, zda jsou seznámeni
s obvyklými nastaveními bezpečnostních parametrů pro
systémové komponenty.
2.2.4.b Zkontrolovat konfigurační standardy systémů a ověřit,
zda zahrnujíobvyklá nastavení bezpečnostních parametrů.
2.2.4.cVybrat vzorek systémových komponent, přezkoumat
obecné bezpečnostní parametry a ověřit, zda jsou správně
nastaveny a v souladu s konfigurací.
Další pokyny k použití SSL a dřívější verze TLS
naleznete na PCI SSC Information Supplement
Migrating from SSL and Early TLS (dodatečné
informace migrace z SSL/dřívější verze TLS).
Konfigurační standardy systémů a
souvisejícíprocesyby se mělyvýslovně zaměřit na
bezpečnostní nastaveníaparametry, kteréjsou
známy jako bezpečnostní rizika u každého
použitého typusystému.
Abybyly systémybezpečněkonfigurovány,
pracovníci odpovědní
zakonfiguracia/neboadministraci systémůmusíbýt
seznámeni skonkrétními bezpečnostními
parametrya nastaveními, kterése vztahujík
určitému systému.
strana33
Duben 2015
PCI DSS Požadavky
Vysvětlení
2.2.5Odstranit všechny nepotřebné
funkčnosti, jako jsou například skripty,
drivery (řadiče), prvky, subsystémy,
souborové systémy a nepotřebné
webové servery.
2.2.5.aVybrat vzorek systémových komponent, přezkoumat
konfigurace a ověřit, zda jsou odstraněny všechny
nepotřebné funkčnosti (například skripty, drivery, prvky,
subsystémy, souborové systémy, atd.).
Zbytečné funkce mohou poskytnout zlovolným
jedincům další příležitosti k získání přístupu do
systému. Odstraněním zbytečných funkcionalit se
může organizace soustředit na zabezpečení
funkcí, které jsou zapotřebí a snížit riziko, že
budou zneužity neznámé funkce.
2.2.5.b. Zkontrolovat dokumentaci a bezpečnostní parametry
a ověřit, zda jsou povolené funkce dokumentovány a
podporují bezpečnou konfiguraci.
2.2.5.c. Zkontrolovat dokumentaci a bezpečnostní parametry
a ověřit, zda na vzorku systémových komponent jsou
přítomny pouze dokumentované funkčnosti.
2.3 Šifrovat všechny nekonzolové
administrativní přístupy. Využívat
technologie jako například SSH, VPN
nebo TLS pro správu sítě a další
nekonzolové administrativní přístupy.
Poznámka: SSL a dřívější verze TLS
není považována za silnou (odolnou)
šifrovací metodu a nemůže být nadále
využívána po 30.6.2016. Pokud do
tohoto data existují implementace použití
protokolu SSL nebo dřívější verze
protokolu TLS, je nutné mít formálně
vypracovanou mitigaci rizik a migrační
plán.
implementace nesmí použít SSL nebo
dřívější verze protokolu TLS.
POS POI terminály (a SSL/TLS koncové
body do kterých jsou zapojeny), které
mohou být ověřeny jako nenáchylné
ke všem známým zneužitím pro SSL a
dřívější verzi TLS, mohou nadále
2.3 Vybrat vzorek systémových komponent a ověřit, zda
nekonzolový administrativní přístup je zašifrován provedením
následujících kroků:
2.3.a Prověřit přihlášení správce do každého systému,
zkontrolovat konfigurace systémů a ověřit, zda je před
vyžádáním správcovského hesla aktivována metoda
odolného šifrování.
2.3.b Prozkoumat služby a soubory parametrů v systémech a
zjistit, zda nejsou pro nekonzolové přístupy dostupné příkazy
pro dálkové přihlášení pro Telnet a další nezabezpečené
vzdálené přihlašování (login).
2.3.c Prověřit přihlášení administrátora (log on) na každý
systém a ověřit, zda přístup administrátora do rozhraní
spravovaného z internetu je zašifrován odolnou kryptografií.
2.3.d Zkontrolovatdokumentaci dodavatele, dotázat se
personálu aověřit, zda je implementována odolná
kryptografiepro použitou technologiiv souladu s odvětvovými
osvědčenými postupy a/nebo doporučenímidodavatele.
Zahrnutím výše uvedeného do standardů vyššího
zabezpečení systémůa procesů má dopad na
specifické bezpečnostní implikace spojené se
zbytečnými funkcemi (například
odstranění/deaktivaci FTP nebo webového
serveru, jestliže takový server nebude ony funkce
vykonávat).
Jestliže nekonzolová správa(včetně dálkové)
nepoužívábezpečnou autentizaciašifrovanou
komunikaci, citlivéinformace na
administrativníaprovozníúrovni (jako jsou jména a
heslaadministrátora)mohou být odhalena špiony.
Zlovolný jedinec by mohltyto informace použít
kpřístupu na síť, stát sesprávcem aukrást data.
Nezašifrované protokoly(jako jsou HTTP, telnet,
atd.) nemajíšifrované
přenosynebopřihlašovacíúdaje (logon), takže je
pro špiona snadné zachytittuto informaci.
Mají-li být protokoly pokládány za “odolně
zašifrované” (“strong cryptography”), musí být
zavedeny s odpovídajícími odolnými klíči a
správou klíčů podle typu použité technologie.
(Odkazujeme na “odolné šifrování” v PCI DSS a
PA-DSS Glossary Terms,Abbreviations, and
Acronyms, tj. v českém překladu: PA-DSS:
Slovník termínů, zkratek a akronymůa odvětvové
standardy a osvědčené postupy jako NIST SP
800-52 a SP 800-57, OWASP, atd).
S ohledem na používání SSL/dřívejší verze
TLS: Subjekt používající SSL a dřívější verzi TLS
strana34
Duben 2015
PCI DSS Požadavky
používat tento bezpečnostní
2.3.e Pro POS POI terminály (a SSL/TLS koncové body do
kterých jsou připojeny) využívající SSL a/nebo dřívější verze
TLS, u kterých subjekt potvrzuje, že nejsou citlivé proti
jakýmkoliv známým zneužitím, pro zmiňované protokoly:
Potvrdit, že subjekt má dokumentaci (např. dokumentace
poskytovatele, detaily systémové/síťové konfigurace, atd.) která
potvrzuje, že zařízení nejsou citlivá proti jakýmkoliv známým
zneužitím pro SSL a dřívější verzi TLS.
2.3.f Pro všechna ostatní prostředí používající SSL a/nebo
dřívější verzi TLS:
Přezkoumat, zda obsahuje dokumentovaná verze Mitigace rizik
a Migrační plán následující:
2.4 Udržovat soupis systémových
komponent, které jsou v rozsahu PCI
DSS.

Popis použití včetně toho, jaká data jsou přenášena,
typ a číslo systému, který používá a/nebo podporuje
SSL/dřívější verzi TLS, typ prostředí;

Výsledky analýzy rizik a řízení snižování rizik;

Popis procesů pro monitorování nových zranitelností
týkajících se SSL/a dřívější verze TLS;

implementovány, aby zajistily, že SSL/dřívejší verze
TLS nebude implementována do nového prostředí;

Přehled projektu migračního plánu zahrnující finální
migraci s datem nejpozději do 30.6.2016.
2.4.a Zkontrolovat soupis systému a ověřit, zda je udržován
seznam hardware a software a obsahuje pro každou položku
popis funkce/použití.
2.4.bDotázat se pracovníků a ověřit, zda dokumentovaný
soupis je udržován aktuální.
2.5Zajistit, aby bezpečnostní politiky
aprovozní postupy prosprávudefaultního
(výchozího) nastavení oddodavatelůa
2.5Zkontrolovatdokumentaci, dotázat se personálu a ověřit, zda
jsoubezpečnostní politiky aprovozní postupy
prosprávuvýchozího nastavení (defaultů) oddodavatelůa
Vysvětlení
musí pracovat na tom,aby začal co nejdříve
využívat pouze odolné (silné) šifrovací protokoly.
Kromě toho nesmí být SSL a dřívější verze TLS
implementována do nového prostředí. V době
uveřejnění tohoto dokumentuje obtížné zneužít v
prostředí POS POI známé zranitelnosti. Přesto se
mohou kdykoliv objevit nové zranitelnosti a je na
organizaci, aby si udržela přehled o aktuálních
trendech zranitelnosti a určila, jesti je nebo
nenínáchylná k jakýmkoli známým zneužitím.
naleznete na PCI SSC Information Supplement
Migrating from SSL and Early TLS (dodatečné
informace migrace z SSL/dřívější verze TLS).
Udržováníaktuálního soupisu
všechsystémovýchkomponent
umožníorganizacipřesněa
efektivnědefinovatrozsah jejichprostředípro
zavedení (implementaci) kontrolPCIDSS.
Bezsoupisu by některésoučásti systémumohly
býtzapomenuty, aneúmyslněvyloučeny
zkonfiguračních standardůorganizace.
Pracovnícisi musí být vědomia provádět
bezpečnostní politiky adenníprovoznípostupy,
které zajistí, že výchozí nastavení (defaulty)
strana35
Duben 2015
PCI DSS Požadavky
dalšíchbezpečnostních parametrůbyly
dokumentovány,používánya
dalšíbezpečnostní parametry:
2.6Poskytovatelé sdíleného hostingu
musí chránit hostingové prostředí a data
držitelů karet každého subjektu. Tito
poskytovatelé musí splňovat specifické
požadavky, jak je detailně popsáno v
Příloze A: Dodatečné požadavky PCI
DSS na poskytovatele sdíleného
hostingu (Additional PCI DSS
Requirements for Shared Hosting
Providers).
2.6Provést testovací postupy A.1.1 až A.1.4,kteréjsou detailně
popsány v Příloze A: Dodatečné požadavky PCI DSS na
poskytovatele sdíleného hostingu (Additional PCI DSS
Requirements for Shared Hosting Providers), ohledně
posouzení PCI DSS u poskytovatelů sdíleného hostingu a
ověřit, zda poskytovatelé sdíleného hostingu chrání hostingové
prostředí a data svých subjektů (obchodníků a poskytovatelů
služeb).
 dokumentovány,
 používány a
 jsou známy všem dotčenýmstranám.
Vysvětlení
oddodavatelů adalšíbezpečnostní
parametryjsouplynuleřízeny, aby se předcházelo
nezabezpečným konfiguracím.
Tento požadavek se týká poskytovatelů hostingu,
kteří poskytují sdílené prostředí hostingu na
stejném serveru většímu počtu klientů. Pokud jsou
všechna data na stejném serveru a pod kontrolou
v jediném prostředí, často se nastavení na těchto
sdílených serverech nedají spravovat jednotlivými
klienty a dovolují klientům, aby přidávali
nezabezpečené funkčnosti a skripty, které mají
vliv na bezpečnost prostředí všech ostatních
klientů; tím se zlovolným jedincům umožňuje
narušit data jednoho klienta a tak získat přístup k
datům všech ostatních klientů. Viz Příloha A
ohledně podrobných požadavků.
strana36
Duben 2015
Ochrana dat držitelů karet
Požadavek 3: Chránit uchovávaná data držitelů karet
Metody ochrany,jako například šifrování, krácení, maskování a transformace dat (hashing), jsou kritické komponenty ochrany dat držitelů karet.
Pokud neoprávněná osoba obejde ostatní kontrolní opatření síťové bezpečnosti a získá přístup k šifrovaným datům, bez správných šifrovacích
klíčů, data jsou pro nínečitelná a nepoužitelná. Jako možnosti snížení potencionálního rizika by měly být zváženy další efektivní metody ochrany
uložených dat. Metody minimalizace rizika zahrnují například neukládání dat držitelů karet, pokud to není absolutně nezbytné, krácení dat držitelů
karet, pokud není nutné celé číslo karty (PAN) a neposílání nechráněných čísel karet (PAN) s použitím koncovýchtechnologií odesílání zpráv, jako
jsou e-maily a okamžité odesílání zpráv.
Informujte se v dokumentu PCI DSS a PA-DSS Slovníček pojmů, zkratek a zkratkových slov ohledně definic „odolné kryptografie” a dalších
termínů PCI DSS.
PCI DSS Požadavky
3.1 Minimalizovat uchovávání dat
držitelů karet prostřednictvím politik,
procedur a procesů ukládání a mazání,
které zahrnují alespoň následující body
pro veškeré uchovávání dat držitelů
karet:
 Omezit ukládané množství a dobu
uložení dat jen na nutný rozsah
požadovaný pro právní, regulační
a/nebo provozní účely
 Procesy pro bezpečné mazání dat
jakmile nejsou zapotřebí
 Specifické požadavky na uchovávání
dat držitelů karet
3.1.aZkontrolovat politiky, procedury a procesy ukládání a
mazání dat a ověřit, zda zahrnují alespoň následující body pro
všechna data držitelů karet (CHD):
 Omezení množství ukládání data dobu jejich uchování jí
dle právních, regulačních a/nebo provozních požadavků na
uchovávání dat.
 Specifické požadavky na uschovávání dat držitelů karet
(například data držitelů karet mají být uchovávána po X
období z Y provozních důvodů)
 Bezpečné vymazání dat držitelů karet, jakmile nejsou
zapotřebí z právních, regulační nebo provozních důvodů
 Čtvrtletní proces na identifikování a bezpečné mazání
uchovávaných dat držitelů karet, které přesahují definované
požadavky na uchovávání.
Vysvětlení
Formální politika uchovávání dat určuje, která
data musí být uchovávána a kde tato data mají
být uchovávána, aby mohla být bezpečně
zničena nebo vymazána jakmile již nebudou
zapotřebí.
Z dat držitele karty, která smějí být uchovávána
po autorizaci, jsou číslo karty (PAN), které je
uloženo v nečitelné podobě), datum ukončení
platnosti karty, jméno držitele karty a servisní
kód.
Pochopení, kde se nachází úložiště dat držitelů
karetjenezbytné, abymohlabýtsprávně
zachovánanebo odstraněna, pokud již nejsou
strana37
Duben 2015
PCI DSS Požadavky
 Čtvrtletní proces na identifikování a
bezpečné mazání uchovávaných dat
držitelů karet, které přesahují
definované požadavky na
uchovávání.
3.1.bDotázat se pracovníků a ověřit, zda:
 Všechna úložiště uchovávaných dat držitelů karet jsou
zahrnuta v procesech uchovávání a mazání dat.
 Existuje čtvrtletní automatický nebo manuální proces na
identifikování a bezpečné mazání uložených dat držitelů
karet.
Vysvětlení
potřebná. Aby bylo možné
definovatpříslušnépožadavky na uchovávání,
subjekt musí nejprvepochopitsvé vlastní
provoznípotřeby, stejně jako všechny právní
aregulační povinnosti, které se vztahují kjejich
odvětví, a/nebokterése vztahujíktypu
uchovávaných dat.
 Čtvrtletní automatický nebo manuální proces se provádí nad
všemi úložišti dat držitelů karet.
3.1.cU vzorku systémových komponent, která uchovávají data
držitelů karet:
 Zkontrolovat soubory a systémové záznamy a ověřit, zda
uchovávaná data nepřekračují požadavky definované
v politice uchováváni dat.
 Prověřit mechanismus vymazání dat a ověřit, zda jsou data
bezpečně vymazávána.
Identifikaceavymazáníuloženýchdat,
kterápřekročilasvoustanovenoudobu
uchovávání,zabraňujezbytečnémuuchovávánídat
, kterájiž nejsou zapotřebí. Tento proces můžebýt
automatickýnebomanuálnínebokombinací
obojího. Napříkladby bylo možné
provéstprogramovou proceduru
(automatickounebo manuální) anajít aodstranit
dataa/nebomanuálně přezkoumat oblastiukládání
dat.
Implementace bezpečných metod vymazávání
zajistí, že data nebudou moci býti obnovena po
té, co již nebudou déle zapotřebí.
Pamatujte si: Co nepotřebujete,
neuchovávejte!
3.2 Po autorizaci neuchovávat citlivá
autentizační data (ani v zašifrovaném
tvaru). Jsou-li přijatacitlivá autentizační
data, po ukončení autorizačního
procesuzajistěte, aby se data nedala
obnovit.
Pro vydavatele a společnosti, které
podporují služby vydávání karet je
přípustné uchovávat citlivá autentizační
data, pokud:
 Existuje provozní opodstatnění
3.2.aU vydavatelů a/nebo společností, které podporují služby
vydávání karet a uchovávají citlivá autentizační data,
přezkoumat politiky, dotázat se pracovníků a ověřit, zda existuje
dokumentované provozní opodstatnění pro uchovávání citlivých
autentizačních dat.
Citlivá autentizační data sestávají z úplných dat
z magnetického proužku stopy, kódu ověření
karty a údajích o PINu. Uchovávání citlivých
autentizačních dat po autorizaci je zakázáno!
Tato data jsou velmi ceněna zlovolnými jedinci,
neboť jim umožňují generovatpadělané platební
karty a vytvářet podvodné transakce.
3.2.bProvydavatelea/nebospolečností, které podporují služby
vydávání karet auchovávají citliváautentizační data,
zkontrolovat úložiště dat a konfigurace systému a ověřit, zda
jsou citliváautentizační data zabezpečena.
Subjekty, kterévydávajíplatební kartynebokteré
vykonávajínebo podporujíslužbyvydávání karet,
budoučastovytvářeta
kontrolovatcitliváautentizační datajako
strana38
Duben 2015
PCI DSS Požadavky
 Data jsou bezpečněuložena.
Citlivá autentizační data obsahují data
uvedená v následujících Požadavcích
3.2.1 až 3.2.3:
3.2.cPro všechny ostatní subjekty, jsou-li přijata citlivá
autentizační data přezkoumat politiky a procedury, zkontrolovat
konfigurace systému a ověřit,zda data nejsou uchovávána po
autorizaci.
Vysvětlení
součástfunkcevydávání karet. Společnostem,
které provádějí, umožňují nebo podporují služby
vydávání (karet), je umožněno ukládat citlivá
autentizačních dat POUZE, KDYŽ mají legitimní
provozní potřeby taková data uchovávat.
Povšimněte si, že všechny požadavky standardu
PCI DSS se vztahují na vydavatele, a jedinou
výjimkou pro vydavatele a zpracovatele je, že
citliváautentizační data mohou býtuchovávána
existuje-li legitimní důvod k jejich uchovávání.
Legitimním důvodem může být nezbytnost pro
provádění zajišťovaných funkcí pro vydavatele, a
nikoli pro usnadnění (vlastní činnosti).Všechna
taková data musí být bezpečně uložena a
v souladu se všemi požadavky PCI DSS a
specifickými požadavky platebních brandů.
3.2.dPro všechny ostatní subjekty, jsou-li přijata citlivá
autentizační data, přezkoumat procedury, zkontrolovat procesy
pro bezpečné vymazání dat a ověřit, zda se data nedajíobnovit.
3.2.1 Neukládat úplný obsah žádné
stopy (magnetického proužku
umístěného na zadní straně karty nebo
ekvivalentní data obsažená v čipu
nebo jinde) po autorizaci. Tato data
jsou alternativně označována jako
úplná stopa, stopa, stopa 1, stopa 2 a
data magnetického proužku.
Poznámka:Za normálního průběhu
provozu může být zapotřebí uchovat
následující datové prvky z magnetického
proužku:
 Jméno držitelů karet,
 Číslo karty (PAN),
 Datum ukončení platnosti,
 Service code
Za účelem minimalizace rizika ukládat
pouze ty datové prvky potřebné pro
provoz.
3.2.1 U vzorku systémových komponent zkontrolovat zdroje
dat včetně, alenikoli výlučně, následujícíchbodů a ověřit, zda
kompletní obsah žádné stopy magnetického proužku na rubu
karty není za žádných okolností uchováván po autorizaci:
Subjektům, které nevydávají karty, není dovoleno
uchovávat citlivá autentizační data po autorizaci.
Jestliže jsou uchovávána úplná data ze stopy,
může zlovolný jedinec, který tato data získá,
reprodukovat platební karty a provést podvodné
transakce.
 Příchozí transakční data
 Všechny vstupy/logy (například transakční, historie,
odstraňování chyb, chyby)
 Soubory s historií
 Trasovací soubory
 Některá databázová schémata
 Obsah databází.
strana39
Duben 2015
PCI DSS Požadavky
3.2.2 Neukládat ověřovací kód/hodnotu
(card verification code/value)
(trojmístné nebo čtyřmístné číslo na líci
nebo rubu platební karty) používané
k verifikaci transakcí bez přítomnosti
karty po autorizaci.
3.2.2 U vzorku komponent systému zkontrolovat zdroje dat
včetně, ale nikoli výlučně, následujících bodů a ověřit, zda
trojmístný nebo čtyřmístný verifikační kód nebo hodnota
verifikace karty vytištěné na líci karty nebo na podpisovém
proužku (údaje CVV2, CVC2, CID, CAV2) nejsou uchovávány
po autorizaci:
odstraňování chyb, chybové)
Vysvětlení
Účelem ověřovacího kódu karty je chránit
transakce prováděné bez přítomnosti karty
(„card-not-present"), tj. transakce s internetovými
nebo písemnými objednávkami / telefonickými
objednávkami (MO/TO), kde není přítomen ani
spotřebitel ani karta.
Jestliže jsou tato data ukradena, zlovolný jedinec
může provést podvodné internetové transakce a
transakce MO/TO
(Pozn. překl.: MO/TO - písemné a telefonické
objednávky, včetně internetových).
 Některá databázová schémata
3.2.3 Neuchovávat osobní identifikační
číslo (PIN) ani zašifrovaný PIN blok po
autorizaci.
3.2.3 U vzorku komponent systému zkontrolovat zdroje dat
včetně, ale nikoli výlučně, následujících bodů a ověřit, zda PINy
a šifrované PIN bloky nejsou uchovávány po autorizaci:
odstraňování chyb, chybové)
Tyto hodnoty by měly být známy jen majiteli karty
nebo bance, která kartu vydala. Jestliže jsou tato
data ukradena, může zlovolný jedinec provádět
podvodné transakce na základě PINu (například
výběry z bankomatu).
 Některá dadatabázová schémata
3.3 Maskovat PAN, pokud je zobrazován
(maximálně lze se zobrazit prvních šest
a poslední čtyři číslice), takže pouze
pracovníci s legitimním provozním
důvodem mohou vidět celé číslo karty,
PAN.
Poznámky:Tento požadavek
nenahrazuje přísnější požadavky platné
pro zobrazení dat držitelů karet—
například právní požadavky nebo
3.3.aZkontrolovatpísemné politiky a postupy
promaskovánízobrazení čísel karet (PAN) a ověřit:
 Seznam rolí, kterépotřebují přístup kzobrazeníplnéhočísla
karty,je dokumentováno, spolu slegitimní
provoznípotřeboukaždé rolemíttakový přístup.
 Číslo karty musíbýt při zobrazenímaskovánotak, žepouze
pracovnícislegitimní provoznípotřeboumohouvidět celé číslo
karty.
 Všechny ostatnírole, které nemajívýslovné oprávněnípro
zobrazení plného čísla kartymusí vidětpouzemaskovaná
čísla karet.
Zobrazení úplného čísla karty na místech, jako
jsou počítačové obrazovky, stvrzenky z
platebních karet, faxy nebo papírové sestavy,
může umožnit získání těchto dat
neautorizovanými jedinci, kteří je využijí k
podvodu. Zajištění toho, aby celé číslo karty bylo
zobrazeno pouze těm, kteří mají legitimní
provozní potřebu pro zobrazení celého čísla karty
minimalizuje riziko, že neoprávněné osoby získají
přístup k číslu karty.
Tento požadavek se vztahuje na ochranu čísla
strana40
Duben 2015
PCI DSS Požadavky
požadavky brandu platebních karet pro
stvrzenky na prodejních místech (POS).
3.3.bZkontrolovat konfigurace systému a ověřit, zda celé číslo
karty se zobrazuje pouze pro uživatele/role s dokumentovanou
provozní potřebou a zda číslo karty je maskováno pro všechny
ostatní požadavky.
Vysvětlení
karty, které je zobrazenona obrazovce, na
papírových stvrzenkách, sestavách apod., a
nesmí být zaměněn s Požadavkem 3.4 na
ochranu čísla karty při jeho
uchovávánív souborech, databázích, atd.
3.3.cZkontrolovat zobrazení čísla karty (například na
obrazovce, na papírové stvrzence) a ověřit, zda čísla karet jsou
při zobrazení dat držitelů karet maskována a zda pouze ti
pracovníci s legitimní provozní potřebou mohou vidět celé číslo
karty.
strana41
Duben 2015
PCI DSS Požadavky
3.4Učinit číslo karty (PAN) nečitelným
všude, kde se uchovává (včetně
přenosných digitálních médií, záložních
médií, přihlašovacích vstupů/logů)
použitím kteréhokoliv z následujících
přístupů:
 “One-way hash” (jednosměrné
hashování) vycházející z odolné
kryptografie (hash musí zahrnovat
celé číslo karty)
 “Truncation” - Zkrácení/odříznutí
(hashování nelze použít k náhradě
odříznuté části čísla karty)
 Indexové tokeny a jednorázová hesla
TAN (TANy musí být bezpečně
uloženy)
 Silná kryptografie s příslušnými
procesy a postupy managementu
klíčů
Poznámka: Pro podvodníka je relativně
jednoduché rekonstruovat původní číslo
karty, pokud mají přístup jak
3.4.aZkontrolovat dokumentaci systému užívaného k ochraně
čísla karty (PAN) včetně dodavatele, typu systému/procesu a
šifrovacích algoritmů (podle situace) a ověřit, zda je číslo karty
učiněno nečitelným pomocí jedné z následujících metod:
 One-way hashes: Jednosměrná funkce zajišťující integritu
vycházející z odolné kryptografie
 Zkrácení/odříznutí
 Indexové tokeny a pady, přičemž pady musí být bezpečně
ukládány
 Odolná kryptografie s příslušnými procesy a procedurami
správy klíčů.
3.4.b Zkontrolovat několik tabulek nebo souborů a získat vzorek
uložených dat a ověřit, zda je číslo karty učiněno nečitelným (to
jest neuloženým v čisté textové podobě).
3.4.cZkontrolovat vzorek výměnných médií (například záložních
pásek) a potvrdit, zda je číslo karty učiněno nečitelným.
3.4.dZkontrolovat vzorek auditních záznamů a potvrdit, zda je
číslo karty učiněno nečitelným nebo odstraněno ze záznamů.
Vysvětlení
Musejí být chráněna všechna čísla karet uložená
v primárních úložištích (v databázích nebo v
otevřených souborech, jako jsou tabulky
textových souborů) i v neprimární úložištích
(zálohy, auditní protokoly (audit logs), protokoly
chyb nebo odstraňování poruch).
Funkce “One-way hash”, vycházející z odolného
šifrování, učiní číslo karty nečitelným. Funkce
“hash”jsou vhodné v případech, kdy nemáme
potřebu obnovit původní číslo karty (jednosměrné
hashování je nevratné). Doporučuje se, i když to
v současné době není požadavkem, aby byla
přidána další, náhodná hodnota k datům držitele
karty před hashováním, aby se snížila možnost
útočníka porovnat data oproti tabulkám, resp.
odvodit číslo karty z předem vypočítaných hodnot
hashů.
Smyslem krácení je uchovávání pouze části čísla
karty (ne větší část než prvních šest a posledních
čtyř číslic).
Indexový token je šifrovací token, který nahrazuje
číslo karty (PAN), založený na daném indexu pro
nepředvídalelnou hodnotu. Jednorázový pad je
strana42
Duben 2015
PCI DSS Požadavky
k odříznutému číslu karty tak k jeho
hashované verzi. Pokud jsou v prostředí
subjektuy přítomny hashovaná i
odříznutá verze stejného čísla karty,
musí se zavést dodatečné kontroly, aby
se zajistilo, že hashovaná i odříznutá
verze nemohou být korelovány
k rekonstrukci původního čísla karty.
3.4.e Pokud je v prostředí subjektu přítomna hashovaná i
zkrácená verze stejného čísla karty,je nutné
přezkoumatimplementované kontroly,aby se ověřilo, zda
nemůže být hashovaná a zkrácená verze čísla karty korelována
tak, aby bylo rekonstruováno původní (originální) číslo karty
(PAN).
Vysvětlení
systém, ve kterém se používá náhodně
generovaný soukromý klíč pouze jednou k
zašifrování zprávy, která je následovně
dešifrována s použitím odpovídajícího
jednorázového padu a klíče.
Záměrem odolného šifrování (jak je definováno
ve Slovníku termínů, zkratek a akronymů PCI
DSS a PA-DSS, PCI DSS and PA-DSS Glossary
of Terms, Abbreviations, and Acronyms) je
šifrování založené na algoritmu s odolnými
šifrovacími klíči, testovanými a akceptovanými v
odvětví (nikoli vlastními nebo “doma vytvořenými”
algoritmy).
Korelací hashové a zkrácené verze daného čísla
karty by zlovolný jedinec mohl snadno odvodit
původní hodnotu čísla karty. Kontroly, které
zabraňují korelaci těchto dat, napomohou zajistit,
že původní číslo karty zůstane nečitelné.
3.4.1 Pokud je použito šifrování disku
(a ne databázové šifrování na úrovni
sloupce nebo souboru), logický přístup
musí být spravován oddělené a
nezávisle na kontrolních autentizačních
a přístupových mechanismech
vlastního operačního systému
(například nepoužívat lokální databáze
uživatelských účtů nebo ověřovací
3.4.1.a Pokud je použito šifrování disku, přezkoumat
konfiguraci, prověřit autentizační proces a ověřit, zda logický
přístup k zašifrovaným souborům systému je implementován
prostřednictvím mechanismu, který je oddělen od
mechanismů vlastního operačního systému (například
nepoužívat lokální databáze uživatelských účtů nebo
ověřovací údaje (credentials) pro login do sítě).
Záměrem tohoto požadavku je řešit
akceptovatelnost šifrování na úrovni disku pro
znečitelnění dat držitelů karet. Šifrování na úrovni
disku zašifruje celý disk/partition na počítači a
automaticky dešifruje informace, požaduje-li je
některý autorizovaný uživatel. Mnohá řešenína
šifrování disků vstupují do operací čtení/zápis
(read/write) a provádějí příslušné šifrovací
transformace bez jakékoli zvláštní pozornosti
strana43
Duben 2015
PCI DSS Požadavky
Vysvětlení
údaje (credentials) pro login do sítě).
Dešifrovací klíče nesmí být spojeny
s uživatelskými účty.
3.4.1.bPřezkoumat procesy, dotázat se pracovníků a ověřit,
zda kryptografické klíče jsou bezpečně uloženy (například na
výměnných médiích, která jsou adekvátně chráněna silnou
kontrolou přístupu).
uživatele kromě toho, že na začátku relace dodá
heslo nebo heslovou frázi. Na základě těchto
charakteristik šifrování disku, nemůže pro
zajištění souladu s tímto požadavkem:
1) používat stejný autentizátor účtu uživatele jako
operační systém, nebo
2) používat dešifrovací klíč, který je spojennebo
odvozen od systémového lokálního účtu
uživatele databáze nebo od ověřovacích
údajů (credentials) pro login do sítě.
Úplné zašifrování disku pomáhá ochránit data
v případě fyzické ztráty disku a může být proto
vhodný pro přenostná zařízení uchovávající data
držitelů karet.
3.4.1.c Zkontrolovat konfigurace, prověřit procesy a ověřit,
zda data držitelů karet na výměnných médiích jsou
zašifrována, kdykoliv jsou ukládána.
Poznámka: Pokud není šifrování disku použito k zašifrování
výměnných médií, pak data uložená na těchto médiích bude
třeba učinit nečitelnými některou jinou metodou.
strana44
Duben 2015
PCI DSS Požadavky
3.5Dokumentovat a implementovat
procedury k ochraně klíčů používaných k
zabezpečení uchovávaných dat držitelů
karet proti odhalení a zneužití.
3.5 Zkontrolovat politiky a procedury ke správě klíčů a ověřit,
zda jsou specifikovány procesy k ochraně a proti odhalení a
zneužití klíčů používaných k šifrování dat držitelů karet a tyto
procesy zahrnují kromě jiného alespoň následující postupy:
Omezit přístup k šifrovacím klíčům na co
nejnižší možný počet administrátorů
(správců).
 Přístupkeklíčůmje omezen naco nejmenšípočetsprávců.
 Klíče pro šifrování klíčů jsoupřinejmenším stejně odolné
jakoklíče pro šifrování dat, která chrání.
 klíče pro šifrování klíčů jsou uloženyodděleně odklíčů pro
šifrování dat.
 Klíčejsou bezpečně uloženy na co nejmenším
počtumožnýchmístaforem.
Poznámka: Tento požadavek se
vztahuje na klíče používané k šifrování
uložených dat držitelů karet a také se
vztahují na klíče pro šifrování klíčů,
používaných k ochraně klíče pro
šifrování dat držitelů karet – takovéto
klíče pro šifrování musí být přinejmenším
tak odolné jako klíče pro šifrování dat.
Vysvětlení
Šifrovací klíče musejí být silně chráněny, protože
ten, kdo získá přístup, bude moci dešifrovat data.
Klíče pro šifrování klíčů, jsou-li užity, musí být
nejméně tak odolné jako je klíč šifrující data, aby
se zajistila správná ochrana klíče, který šifruje
data, a zároveň jako data šifrovaná oním klíčem.
Požadavek na ochranu klíčů před prozrazením a
zneužitím se vztahuje jak na klíče šifrující data,
tak na klíče šifrující klíče. Protože jeden klíč
šifrující klíče může umožnit přístup k mnoha
klíčům šifrující data, klíč šifrující klíče vyžaduje
přísnáochranná opatření.
3.5.1Omezit přístup k šifrovacím
klíčům na co nejnižší počet
administrátorů (správců).
3.5.1Prověřit seznamy uživatelských přístupů a ověřit, zda
přístup ke klíčům je omezen jen na nezbytné minimum
administrátorů (správců).
Jen velmi málo lidí by mělo mít přístup ke
šifrovacím klíčům (což snižujepotenciální riziko
pro zpřístupnění dat držitelů
karetneoprávněnýmiosobami), obvykle jen ti, kteří
mají odpovědnosti správce klíčů (key custodian).
3.5.2Uchovávejte soukromé šifrovací
klíče používané k šifrování/dešifrování
dat držitelů karet vždy v jedné (nebo
více) z následujících možností:
3.5.2.aZkontrolovat dokumentované procedury a ověřit, zda
šifrovací klíče používané k šifrování/dešifrování dat držitelů
karet se vyskytují vždy v jedné (nebo více) z následujících
možností:
Šifrovací klíče musejí být uchovávány bezpečně,
aby se zabránilo neautorizovanému nebo
zbytečnému přístupu,který by mohl vyústit ve
zpřístupnění dat držitelů karet.
 Zašifrovanésklíčempro šifrování
klíčů, který je přinejmenším
stejněodolnýjako klíčpro šifrování dat,
akterý je uloženodděleně odklíčepro
šifrování dat.
 V rámcibezpečnéhošifrovacího
prostředku(např. jako je
hardwarovýšifrovací modul Host
 Zašifrovanésklíčempro šifrování klíčů, který je přinejmenším
stejněodolný jako klíčpro šifrování dat, akterý je
uloženodděleně odklíčepro šifrování dat.
 V rámcibezpečnéhošifrovacího prostředku(např. jako je
hardwarový šifrovací modul Host Security Module(HSM),
nebo zařízení point-of-interaction schválené PTS)
 Jakokomponentyklíčů (key components) nebo sdílené klíče
(key shares), v souladusmetodoupřijímanou v odvětví.
Není záměrem, aby klíče pro šifrování klíčů byly
šifrovány, ale musí být chráněny před vyzrazením
a zneužitím, jak definuje Požadavek 3.5. Jsou-li
použity klíče pro šifrování klíčů, uložení klíčů pro
šifrování klíčů na fyzicky a/nebo logicky
oddělených místech od klíčů pro šifrování dat
snižuje riziko neoprávněného přístupu k oběma
strana45
Duben 2015
PCI DSS Požadavky
Security Module(HSM), nebo zařízení
point-of-interaction schválené PTS)
 Jakominimálně dvě komponenty plné
délky (full-length key components)
nebo sdílené klíče (key shares), v
souladusmetodoupřijímanou v
odvětví.
Poznámka: Pro veřejné klíče (public
keys) není vyžadováno jejich uchovávání
jedné z těchto možností.
3.5.2.bZkontrolovat konfigurace systému a místo uložení klíčů
a ověřit, zda šifrovací klíče pro používané k
šifrování/dešifrování dat držitelů karet se vyskytují vždy v
jedné (nebo více) z následujících možností:
Vysvětlení
klíčům.
 Zašifrované klíčem pro šifrování klíčů
 V rámcibezpečnéhošifrovacího prostředku(např. jako je
hardwarový šifrovací modul Host Security Module(HSM),
nebo zařízení point-of-interaction schválené PTS)
 Jakoklíčové komponenty (key components) nebo sdílené
klíče (key shares), v souladusmetodoupřijímanou v
odvětví.
3.5.2.cKdykoli jsou použity klíče pro šifrování klíčů
zkontrolovat konfigurace systémů a místa uložení klíčů a
ověřit:
 Klíče pro šifrování klíčů jsou přinejmenším stejněodolné
jako klíče pro šifrování dat, které chrání
 Klíče pro šifrování klíčů jsou uloženyodděleně odklíčů pro
šifrování dat.
3.5.3 Ukládat šifrovací klíče na co
nejmenším počtumíst.
3.6Kompletně dokumentovat a
implementovat všechny procesy správy
klíčů a procedury pro šifrovací klíče
užívané k šifrování dat držitelů karet,
včetně následujících bodů:
Poznámka: Pro správu klíčů jsou
3.5.3 Zkontrolovat umístění uchovávání klíčů, prověřit
procesy a ověřit, zda kódy jsou uloženy na co nejmenším
počtumíst.
3.6.aDoplňková testovací procedura platná pouze pro
poskytovatele služeb:Pokud poskytovatel služeb sdílí klíče se
svými zákazníky pro přenos nebo uchovávání dat držitelů karet,
zkontrolovat dokumentaci, kterou poskytovatel předal svým
zákazníkům a ověřit, zda zahrnuje pokyny, jak bezpečně
přenášet, uchovávat a aktualizovat klíče zákazníků, v souladu
s Požadavky 3.6.1 až 3.6.8. níže.
Uchovávání šifrovacích klíčů na co nejmenším
počtu možných míst pomáhá organizaci udržovat
přehled a monitorovat všechna umístění klíčů a
minimalizovat potenciální možnost odhalení klíčů
neoprávněnými osobami.
Způsob, jakým se šifrovací klíče spravují, je
rozhodující částí bezpečnosti kryptografického
řešení. Dobrý proces správy klíčů, ať manuální
nebo automatizovaný jako součást šifrovacího
produktu, je založen na standardech odvětví a
věnuje se všem hlavním elementům uvedeným
strana46
Duben 2015
PCI DSS Požadavky
dostupné četné odvětvové standardy
z různých zdrojů včetně NIST, který lze
nalézt na http://csrc.nist.gov.
3.6.bZkontrolovat procedury a procesy pro klíče používané k
šifrování dat držitelů karet a provést následující kroky:
Vysvětlení
v bodech 3.6.1 až 3.6.8.
Poskytování poradenství zákazníkům, jak
bezpečně přenášet, uchovávat a aktualizovat
šifrovací klíče může zabránit špatné správě klíčů
nebo jejich zpřístupnění neoprávněným osobám.
Tento požadavek se týká klíčů používaných pro
šifrování uložených dat držitelů karet, a
veškerých příslušných klíčů pro šifrování klíčů.
Poznámka: Testovací procedura 3.6.a je
dodatečnou procedurou, která je platná pouze
v případě, že je hodnocen poskytovatel služeb.
3.6.1 Generování odolných šifrovacích
klíčů
3.6.1.a Ověřit, zda procedury správy klíčů specifikují, jak
generovat odolné klíče.
3.6.1.b Prověřit metody generování klíčů a ověřit, zda jsou
generovány odolné klíče.
3.6.2 Bezpečná distribuce šifrovacích
klíčů
3.6.2.a Ověřit, zda procedury správy klíčů specifikují, jak se
mají klíče bezpečně distribuovat.
3.6.2.b Prověřit metody pro distribuci klíčů a ověřit, zda klíče
jsou bezpečně distribuovány.
3.6.3 Bezpečné uchovávání šifrovacích
klíčů
3.6.4 Změnašifrovacích klíčů za klíče,
které dosáhly konce svého šifrovacího
období (např. po uplynutí definovaného
časového období a/nebo po vytvoření
3.6.3.a Ověřit, zda procedury správy klíčů specifikují, jak
bezpečně uchovávat klíče.
Kryptografické řešení musí generovat odolné
klíče, jak jsou definovány v PCI DSS a PA-DSS
Slovníku termínů, zkratek a akronymů, PA-DSS
Glossary of Terms, Abbreviations, and
Acronyms) pod heslem „Odolná kryptografie“.
Použití odolných šifrovacích klíčů významně
zvýší úroveň zabezpečení zašifrovaných dat
držitelů karet.
Kryptografické řešení musí klíče bezpečně
distribuovat, což znamená, že klíče jsou
distribuovány pouze správcům identifikovaným
v bodu 3.5.1., a nikdy se nesmí distribuovat v
otevřené formě.
3.6.3.b Prověřit metody pro uchovávání klíčů a ověřit, zda
klíče jsou bezpečně uchovávány.
Kryptografické řešení musí klíče bezpečně
uchovávat, například zašifrovat je klíčem pro
šifrování klíčů. Uchovávání klíčů bez náležité
ochrany může poskytnout přístup útočníkům a
vést k dešifrování a odhalení dat držitelů karet.
3.6.4.a Ověřit, zda procedury správy klíčů zahrnují
definovanou dobu platnosti každého používaného typu klíče
(cryptoperiod) a definují proces pro změnu klíče na konci
definované doby platnosti klíče.
Kryptografické období je časový úsek, během
kterého určitý šifrovací klíč může být použit ke
svému definovanému účelu. Při definování
kryptografické období zvažte mimo jiné odolnost
strana47
Duben 2015
PCI DSS Požadavky
určitého objemu šifrovaného textu
daným klíčem), jak bylo jest definováno
odpovídajícím dodavatelem aplikace
nebo vlastníkem klíče, a odpovídá
nejlepším postupům a doporučení
(např. NIST Special Publication 80057).
3.6.4.b Dotázat se pracovníků a ověřit, zda jsou klíče měněny
na konci definované doby platnosti klíče.
3.6.5 Stažení nebo náhrada (např. po
archivaci, zničení a/nebo odvolání)
klíčů, je-li to nutné, pokud integrita
klíčů byla oslabena (např. odchod
zaměstnanců znalých části otevřeného
textu klíče), nebo je podezření na
kompromitování klíčů.
3.6.5.a Ověřit, zda procedury správy klíčů specifikují procesy
pro následující případy:
Poznámka: Pokud se mají uchovávat
prošlé nebo nahrazené šifrovací klíče,
pak tyto klíče musí být bezpečně
archivovány (např. použitím klíče
k šifrování klíčů). Archivované šifrovací
klíče mohou být použity pouze za účelem
dešifrování/ověření.
Vysvětlení
souvisejícího algoritmu, velikost nebo délku klíče,
riziko prozrazení a citlivost šifrovaných dat.
Pravidelná obměna šifrovacích klíčů při dosažení
konce jejich kryptografického období je nezbytný
imperativ k minimalizaci rizika, že někdo šifrovací
klíče získá a bude schopen data dešifrovat.
 Odstranění nebo nahrazení klíčů pokud byla jejich
integrita oslabena.
 Náhradupři zjištění nebo podezření na kompromitování
klíčů.
 Pro operace šifrování nejsou použity žádné klíče, které
byly uchované po jejich platnosti nebo náhradě.
3.6.5.bDotázat se pracovníků a ověřit, zda byly následující
procesy implementovány:
 Klíče jsou podle potřeby odstraněny nebo nahrazeny,
pokud byla integrita klíčů oslabena, včetně situace, kdy
společnost opustí zaměstnanec znalý klíče.
Klíče, které již nejsoupoužíványnebo zapotřebí,
nebo klíče, které byly kompromitovány nebo je
podezření na jejich kompromitování, by mělybýt
zrušenya/nebo zničeny, aby se zajistilo, že klíče
již nelzepoužít. Je-litřeba, aby klíče byly
uchovány (například na podporuarchivovaných,
šifrovaných dat), tytoklíčemusí být odolně
chráněny.
Šifrovací řešení by
mělozajistitausnadnitprocesnahrazeníklíčů,
kteréjsou připraveny na výměnu, nebo je známo,
že byly kompromitovány nebo je podezření na
jejich kompromitování.
 Klíče jsou nahrazeny pokud byly kompromitovány nebo
je podezření na jejich kompromitování.
 Žádné klíče uchovávané po jejich neplatnosti nebo
náhradě nejsou používány pro šifrovací operace.
3.6.6Je-li použito manuální správy
šifrovacích klíčů v otevřené formě,
takové operace musí být spravovány
s využitím rozdělení znalostí a duální
kontroly.
Poznámka: Příklady manuálních operací
správy klíčů zahrnují mimo jiné např.
generování klíčů, přenos, zavádění,
ukládání a zničení.
3.6.6.a Ověřit, zda manuální procedury managementu klíčů
v otevřené formě specifikuji procesy pro využití následujících
opatřeních:
 Rozdělení znalostí o klíčích, takže části klíčů jsou pod
kontrolou dvou nebo tří lidí, kdy každý zná jen svou část
klíče a společně rekonstruují klíč celý; A
 Duální kontrola klíčů, takže k provedení operace správy
klíčů jsou vyžadováninejméně dva pracovníci a jedna
osoba nemá přístup k autentizačním materiálům
(například hesla nebo klíče).
Rozdělení znalostí a dvojí kontrola klíčů se
používá k zabránění přístupu jednoho pracovníka
k celému klíči. Tuto kontrolu lze obvykle aplikovat
u manuálních systémů šifrování klíčů nebo tam,
kde správu produktu neimplementuje šifrovací
produkt.
Rozdělení znalostí je metoda,ve které jsou
dvěnebo více osobsamostatně vlastní části
klíčůajednotlivé části klíčů nenesou žádnou
znalost o původnímšifrovacímklíči.
strana48
Duben 2015
PCI DSS Požadavky
3.6.6 b Dotázat se pracovníků a/nebo prověřit procesy a
ověřit, zda otevřené klíče jsou spravovány prostřednictvím:
 rozdělení znalostí, a
Vysvětlení
Duálníovládánívyžadujedvě nebo více osobk
provedení funkce, ajedna osoba nemá přístup k
autentizačním materiálům toho druhého.
 duální kontrolou.
3.6.7Prevence neautorizované náhrady
šifrovacích klíčů.
3.6.7.a Ověřit, zda postupy správy klíčů specifikují procesy k
zabránění neautorizované náhrady klíčů.
3.6.7.b Dotázat se pracovníků a/nebo prověřit procesy a
ověřit, zda je zabráněno neautorizované náhradě klíčů.
3.6.8 Požadavek pro správce
kryptografických klíčů na formální
prohlášení, že chápou svoji
odpovědnost správce a akceptují ji.
3.7Ujistit se, že bezpečnostní politiky
aprovozní postupy
proochranuuloženýchdat držitelů
karetjsou dokumentovány, používánya
3.6.8.a Ověřit, zda procedury správy klíčů specifikují procesy
pro správce klíčů prohlášení (písemné nebo elektronické), že
chápou svoji odpovědnost správce a akceptují ji.
3.6.8.b Prověřit dokumentaci nebo jinou evidenci prokazující,
že správci klíčů prohlásili (písemně nebo elektronicky), že
chápou svoji odpovědnost správce a akceptují ji.
3.7Zkontrolovatdokumentaci, dotázat se pracovníků a ověřit,
zda jsoubezpečnostní politiky aprovozní postupy
proochranuuloženýchdat držitelů karet:
• dokumentovány,
• používají se, a
• jsou známyvšem dotčenýmstranám.
Kryptografické řešení by nemělo umožnit ani
akceptovat nahrazení klíčů pocházejících z
neautorizovaných zdrojů nebo neočekávaných
procesů.
Tento proces zajistí, aby se pracovník, který
jedná jako správce klíčů, zavázal ke své roli
správce klíčů a chápal své povinnosti a
akceptoval je.
Pracovníci si musí být vědomi bezpečnostní
politiky a dokumentovaných provozních postupů
pro správu zabezpečeného úložiště dat držitelů
karet a musí je průběžně dodržovat.
strana49
Duben 2015
Požadavek 4: Zašifrovat přenos dat držitelů karet po otevřených veřejných sítích
Citlivé informace musí být zašifrovány během přenosu po sítích, které jsou snadno přístupné pro osoby konající ve zlém úmyslu. Špatně
konfigurované bezdrátové sítě a zranitelná místa v zastaralých šifrovacích programech a autentizačních protokolech mohou být trvalými cíli osob,
konajících ve zlém úmyslu, které tato zranitelná místa zneužívají k získání privilegovaného přístupu do prostředí dat držitelů karet.
PCI DSS Požadavky
4.1 Používat odolnou kryptografii a
bezpečnostní protokoly (jako například TLS,
IPSEC nebo SSH, apod.) k ochraně citlivých
dat držitelů karet během přenosu po
otevřených veřejných sítích, včetně
následujících bodů:
 Přijatelné jsou pouze důvěryhodné klíče a
certifikáty.
 Používané protokoly podporují pouze
bezpečné verze a konfigurace.
 Odolnost šifrování odpovídá použité
šifrovací metodologii.
Poznámka: SSL a dřívější verze TLS není
považována za silnou (odolnou) šifrovací
metodu a nemůže být nadále využívána po
30.6.2016. Pokud do tohoto data existují
implementace použití protokolu SSL nebo
dřívější verze protokolu TLS, je nutné mít
formálně vypracovanou mitigaci rizik a migrační
plán.
implementace nesmí použít SSL nebo dřívější
verze protokolu TLS.
POS POI terminály (a SSL/TLS koncové body
do kterých jsou zapojeny), které mohou být
ověřeny jako nenáchylné ke všem známým
4.1.a Identifikovat všechna místa, kde jsou data
držitelů karet přenášena nebo přijímána po
otevřených veřejných sítích. Zkontrolovat
dokumentované standardy a porovnat je s
konfigurací systémů a ověřit, zda jsou použity
bezpečné protokoly a odolné šifrování na všech
místech.
4.1.b Přezkoumat dokumentované politiky a
procedury a ověřit, zda jsou specifikovány procesy
pro následující body:
 Přijímání pouze důvěryhodných klíčů
a/nebo certifikátů
 Použité protokoly podporují pouze
bezpečné verze a konfigurace (tj.
nedůvěryhodné klíče a/nebo certifikáty
nejsou podporovány)
 Implementace používá pouze správnou
odolnost šifrování odpovídající použité
šifrovací metodologii
4.1.c Vybrat a prověřit vzorek příchozích a
odchozích přenosů, jak jsou přijímány, a ověřit,
zda jsou data držitelů karet během přenosu
zašifrována pomocí odolného šifrování.
4.1.d Zkontrolovat klíče a certifikáty a ověřit, zda
jsou akceptovány pouze důvěryhodné klíče
a/nebo certifikáty.
Vysvětlení
Citlivé informace musejí být během přenosu veřejnými
sítěmi zašifrované, protože pro zlovolné jedince je
snadné a běžné, že data na cestě zachytí a/nebo
odkloní.
Bezpečnýpřenosdat držitelů karetvyžaduje
použitídůvěryhodnýchklíčů/certifikátů, bezpečnýprotokol
pro přenos asprávnou šifrovací odolnostk zašifrovánídat
držitelů karet. Požadavky na připojení odsystémů,
kterénepodporujípožadovanou odolnost šifrováníakteré
by vedly knezabezpečenémupřipojení, by neměly být
přijaty.
Povšimněte si, že některé implementace protokolu (jako
např. SSL, SSH verze 1.0 a dřívější verze TLS ),
obsahují známá slabá místa, jež může narušitel využít k
získání kontroly nad dotčeným systémem. Při použití
jakéhokoli protokolu se ujistěte, že je konfigurován pro
použití pouze zabezpečené konfigurace a verze k
zabránění nezabezpečeného spojení – například
používání pouze důvěryhodných certifikátů a podpora
pouze odolného šifrování (nepodporování slabých
potencionálně nebezpečných protokolů nebo metod).
.
Ověření, zda jsou certifikáty důvěryhodné (například
nemají prošlou dobu platnosti a jsou vydány
důvěryhodným zdrojem) napomůže zajistit integritu
bezpečného spojení.
strana50
Duben 2015
PCI DSS Požadavky
zneužitím pro SSL a dřívější verzi TLS, mohou
nadále používat tento bezpečnostní
Příklady otevřených veřejných sítí, kromě
jiných:
 Internet,
 Bezdrátové technologie, včetně 802.11 a
Bluetooth
 Mobilní technologie, například Globální
Systém pro Mobilní komunikaci (GSM),
Code division multiple access (CDMA)
 General Packet Radio Service (Mobilní
datová rádiová služba, GPRS).
 Satelitní komunikace.
4.1.e Zkontrolovat konfiguraci systému a ověřit,
zda je implementován protokol, který používá
pouze bezpečné konfigurace a nepodporuje
nezabezpečené verze nebo konfigurace.
4.1.f Zkontrolovat konfiguraci systému a ověřit,
zda je implementována správná odolnost šifrování
pro použitou metodologii šifrování. (Zkontrolovat
doporučení dodavatele/ osvědčené postupy.)
Vysvětlení
Obecně by webová stránkaURLměla začínat znaky
"HTTPS" a/neboby měl webový
prohlížečzobrazitikonu visacího zámkuněkdev
okněprohlížeče. Mnoho
dodavatelůcertifikátuTLStaké poskytuje dobře
viditelnouověřující pečeť - známá také
jako"bezpečnostní pečeť", “pečeť bezpečné
stránky” nebo " pečeťdůvěryhodného zabezpečení"
- která může nabízet po kliknutí na pečeť zobrazení
informacío internetové stránce.
4.1.g Pro implementaci TLS zkontrolovat
konfigurace systému a ověřit, zda je umožněn
protokol TLS vždy, když jsou data držitelů karet
odesílánanebo přijímána:
 “HTTPS” se zobrazuje jako protokol
prohlížeče Universal Record Locator (URL),
a
 Data držitelů karet jsou vyžadována pouze
tehdy, pokud se jako součást URL
objeví“HTTPS”.
strana51
Duben 2015
PCI DSS Požadavky
Vysvětlení
4.1.h Pro POS POI terminály (a SSL/TLS koncové
body do kterých jsou připojeny) využívající SSL
a/nebo dřívější verze TLS, u kterých subjekt
potvrzuje, že nejsou citlivé proti jakýmkoliv
známým zneužitím, pro zmiňované protokoly:
Viz odvětvové standardy a osvědčené postupy pro
odolnou (silnou) kryptografii a bezpečné protokoly (např.
NIST SP 800-52 a SP 800-57, OWASP, atd.).
Potvrdit, že subjekt má dokumentaci (např.
dokumentace poskytovatele, detaily
systémové/síťové konfigurace, atd.) která
potvrzuje, že zařízení nejsou citlivá proti
jakýmkoliv známým zneužitím pro SSL a dřívější
verzi TLS.
S ohledem na používání SSL/dřívejší verze TLS:
Subjekt používající SSL a dřívější verzi TLS musí
pracovat na tom,aby začal co nejdříve využívat pouze
odolné (silné) šifrovací protokoly. Kromě toho nesmí být
SSL a dřívější verze TLS implementována do nového
prostředí. V době uveřejnění tohoto dokumentuje obtížné
zneužít v prostředí POS POI známé zranitelnosti. Přesto
se mohou kdykoliv objevit nové zranitelnosti a je na
organizaci, aby si udržela přehled o aktuálních trendech
zranitelnosti a určila, jesti je nebo nenínáchylná k
jakýmkoli známým zneužitím.
naleznete na PCI SSC Information Supplement Migrating
from SSL and Early TLS (dodatečné informace migrace
z SSL/dřívější verze TLS).
strana52
Duben 2015
PCI DSS Požadavky
Vysvětlení
4.1.iPro všechna ostatní prostředí používající SSL
a/nebo dřívější verzi TLS:
Přezkoumat, zda obsahuje dokumentovaná verze
Mitigace rizik a Migrační plán následující:
4.1.1 Zajistit, aby bezdrátové sítě přenášející
data držitelů karet nebo připojené na
prostředí dat držitelů karet užívaly nejlepší
odvětvové postupy (například IEEE 802.11i)
k implementaci silného šifrování pro
autentizaci a přenos.
Poznámka: Používání WEP jako bezpečnostní
kontroly je zakázáno.

Popis použití včetně toho, jaká data jsou
přenášena, typ a číslo systému, který
používá a/nebo podporuje SSL/dřívější
verzi TLS, typ prostředí;

Výsledky analýzy rizik a řízení snižování
rizik;

Popis procesů pro monitorování nových
zranitelností týkajících se SSL/a dřívější
verze TLS;

implementovány, aby zajistily, že
SSL/dřívejší verze TLS nebude
implementována do nového prostředí;

Přehled projektu migračního plánu
zahrnující finální migraci s datem
nejpozději do 30.6.2016.
4.1.1 Indentifikovat všechny bezdrátové sítě
přenášející data držitelů karet nebo připojené na
prostředí dat držitelů karet. Zkontrolovat
dokumentované standardy a porovnat je
s nastavením konfigurací systému a ověřit
následující body u všech indentifikovaných
bezdrátových sítí:
 V odvětví osvědčené postupy (například
IEEE 802.11i) jsou použity k implementaci
odolného šifrování pro autentizaci a přenos.
Zlovolní uživatelé využívají volně a široce dostupné
nástroje k zachycování bezdrátových komunikací. Použití
odolného šifrování může napomoci omezit zachycení a
zpřístupnění citlivých informací v celé bezdrátové síti.
Odolné šifrování pro autentizaci a přenos dat držitelů
karet je vyžadováno, aby se podvodníkům znemožnil
přístup k bezdrátové síti nebo využití bezdrátové sítě k
průniku do jiných vnitřních sítí nebo dat.
 Slabé šifrování (například WEP, SSL ) není
použito jako bezpečnostní kontrola pro
autentizaci a přenos.
strana53
Duben 2015
PCI DSS Požadavky
4.2 Nikdy neposílat nechráněná čísla karet
(PANs) technologiemi pro zasílání zpráv
koncovým uživatelem (například e-mail, rychlá
textová komunikace (instant messaging), SMS
chat, apod.).
4.2.a Jsou-li k odeslání dat držitelů karet použity
technologie pro zasílání zpráv koncovým
uživatelem, prověřit procesy pro odesílání čísel
karet a ověřit, zda je užívána odolná kryptografie,
kdykoliv jsou data držitelů karet posílána
technologiemi pro zasílání zpráv koncovým
uživatelem.
4.2.b Přezkoumat dokumentované politiky a ověřit
existenci politiky určující, že nechráněná
(nešifrovaná) čísla karet (PANs) nesmí být
zasílána technologiemi pro zasílání zpráv
koncovým uživatelem.
4.3Ujistit se, zda bezpečnostní politiky
aprovozní postupy prošifrovánípřenosůdat
držitelů karetbyly dokumentovány,používánya
4.3 Zkontrolovatdokumentaci a dotázat se
pracovníků a ověřit, zda jsou bezpečnostní politiky
aprovozní postupy proochranu přenosu dat
držitelů karet:
•dokumentovány,
•používají se, a
• jsou známyvšem dotčenýmstranám.
Vysvětlení
E-mail, rychlá textová komunikace (instant messaging),
SMS a chat mohou být snadno zachyceny odposlechem
paketů (packet-sniffing) při doručování po vnitřních nebo
veřejných sítí. Nepoužívejte tyto komunikační nástroje k
zasílání čísel karet, pokud nejsou konfigurovány tak, aby
zaručily odolné šifrování.
Dále v případě, že subjekt požaduje číslo karty (PAN)
prostřednictvím technologií pro zasílání zpráv, tento
subjekt musí zajistit vhodný nástroj nebo metodu
k ochraně čísel karet (PANs) za použití silného
(odolného) šifrování, nebo je nutné čísla karet (PANs)
učinit nečitelnými před samotným zasláním.
Pracovníci si musí být vědomi bezpečnostních politik a
provozních postupů pro správu zabezpečeného přenosu
dat držitelů karet a musí je průběžně dodržovat.
strana54
Duben 2015
Udržováníprogramu kontroly zranitelnosti
Požadavek 5: Chránit všechny systémy proti malware a pravidelně aktualizovat antivirový software nebo
programy
Závadný software, běžně označovaný jako „malware“ - včetně virů, červů a trojských koní, se dostává do sítě během mnoha podnikem
schválených činností, včetně elektronické pošty zaměstnanců a používání internetu zaměstnanci nebo přenosných počítačů a paměťových
zařízení, což dále umožňuje zneužívání zranitelných míst systémů. Antivirový software se musí používat na všech systémech běžně
postihovaných závadným softwarem, aby se tak chránily před současnými a stále se vyvíjejícími hrozbami závadného softwaru. Jako doplnění k
antivirovému software se mohou zvažovat doplňková antivirová řešení; nicméně taková doplňková antivirová řešení nenahrazují nezbytnost
nasazení antivirového software.
PCI DSS Požadavky
5.1 Nainstalovat antivirový software na
všechny systémy běžně postihované
závadným softwarem (zejména na
osobní počítače a servery).
5.1.1 Zajistit, aby antivirové programy
byly schopné detekovat všechny
známé druhy závadného softwaru,
odstranit jej a chránit před ním.
Vysvětlení
5.1 U vzorku systémových komponent zahrnujícího všechny
typy operačních systémů běžně napadaných závadným
softwarem ověřit, zda antivirový software je nasazen, pokud
existuje aplikovatelná antivirová technologie.
Vyskytuje se stálý proud útoků s dostatečně
popsanými zranitelnými místy, často nazývaným
„Den nula“ (útok, který zneužívá dříve známé
zranitelnosti), proti jinak bezpečným systémům.
Bez antivirového softwarového řešení, které je
pravidelně aktualizováno, mohou tyto nové formy
závadného software napadnout a vyřadit vaši síť
nebo vést ke kompromitování dat.
5.1.1 Přezkoumat dokumentaci dodavatelů a zkontrolovat
antivirové konfigurace a ověřit, zda antivirové programy:
Je třeba se chránit proti VŠEM druhům a formám
závadného softwaru.
 Detekují všechny známé typy závadného softwaru,
 Odstraňují všechny známé typy závadného softwaru, a
 Chrání proti všem známým typům závadného softwaru.
(například viry, trojské koně, červy, spyware, adware,
rootkits).
Příklady typů závadného softwaru zahrnují viry, trojské koně,
červy, spyware, adware a rootkits.
strana55
Duben 2015
PCI DSS Požadavky
5.1.2
Prosystémy, které jsoupovažovány za
běžně neovlivňované škodlivým
softwarem,
provéstpravidelnévyhodnocení a
identifikovatavyhodnotitvyvíjející
sehrozby ze stranymalware a ověřit,
zdatyto systémy
inadálenevyžadujíantivirový software.
5.1.2 Dotázat se pracovníků aověřit, zda vyvíjející sehrozby
ze stranymalwarejsou sledoványa vyhodnocovány u systémů,
které nejsouv současné doběpovažovány za běžně
neovlivňované škodlivým softwarem, aby se potvrdilo,zdatyto
systémy i nadálenevyžadujíantivirový software.
Vysvětlení
Typicky, sálové počítače, mid-range
počítače(napříkladAS/400) apodobné
systémynemusíbýt v současné doběběžněcílem
neboovlivněnymalwarem. Nicméně, odvětvové
trendy u škodlivého softwaru se mohou
rychleměnit, takže je důležité, aby si organizace
byly vědomynových malware, které by mohly mít
vliv na jejichsystémy - například tím,
žesledujíoznámenídodavatelebezpečnostníchaant
ivirovýchdiskusních skupin, aby určily,
zdajejichsystémy mohou býtpodhrozbounového
arozvíjejícího semalware.
Trendy uškodlivéhosoftwaruby měly být
zahrnutydoidentifikace novýchbezpečnostních
zranitelností, azpůsoby, jak řešit nové trendyby
měly být podle potřeby
začleněnydokonfiguračních
standardůspolečnostiaochranných mechanismů.
5.2 Zajistit, aby všechny antivirové
mechanismy byly spravovány podle
 byly udržovány aktuální
 prováděly pravidelné skeny
 generovaly auditní protokoly (audit
logs), které jsou uchovávány podle
Požadavku 10.7 PCI DSS.
5.2.aZkontrolovat politiky a procedury a ověřit, zda antivirový
softwareadefinice jsou udržovány v aktuálním stavu.
5.2.b Zkontrolovat antivirové konfigurace,
včetněhlavníinstalacesoftwarua ověřit, zda
jsouantivirovémechanismy:
 nakonfigurovány tak, abyprovádělyautomatické aktualizace,
a
 nakonfigurovány tak, abyprovádělypravidelné skeny.
5.2.cZkontrolovat vzorek systémových komponent, včetně
všech typů operačních systémů běžně postihovaných
závadným softwarem a ověřit, zda
Účinnost i toho nejlepšího antivirového řešení je
omezena, jestliže není udržováno aktuální pomocí
aktuálních bezpečnostních aktualizací, souborů s
podpisy nebo ochranou proti malware.
Auditní protokoly poskytují možnost monitorovat
aktivity virů a malware a reakci na anti-malware.
Proto je nezbytné, aby anti-malwarové řešení bylo
konfigurováno tak, aby generovalo auditní
protokoly (audit logs) a tyto logy byly zpracovány
v souladu s Požadavkem 10.
 je aktuální antivirový software a definice,
 jsou prováděny periodické skeny.
5.2.d Zkontrolovat antivirovou konfiguraci, včetně hlavní
instalace softwaru, a vzorek systémových komponent a ověřit,
zda
 je aktivováno generování záznamů (logů) antivirového
softwaru, a
strana56
Duben 2015
PCI DSS Požadavky
Vysvětlení
 jsou tyto záznamy uchovávány v souladu s Požadavkem
10.7 PCI DSS.
strana57
Duben 2015
PCI DSS Požadavky
5.3Zajistit, abyantivirové mechanismy
byly aktivníanemohly být deaktivovány
nebo změněnyuživateli, pokud to není
výslovněschválenovedením a to
případod případu ana omezenoudobu.
Poznámka: Antivirové řešenímůže být
dočasně deaktivováno pouze v
případě,že existuje
legitimnítechnickápotřeba, je to
schválenovedeníma topřípad odpřípadu.
Pokud má být ze zvláštního důvodu
deaktivována antivirová ochrana, musí to
býtformálněschváleno. Během doby, po
kterou neníantivirová ochranaaktivní,
může být také nutné implementovat další
bezpečnostníopatření.
Vysvětlení
5.3.a Zkontrolovat antivirové konfigurace,
včetněhlavníinstalacesoftwaruavzoreksystémových komponent,
a ověřit, zda antivirový softwarejeaktivně spuštěn.
Antivirový software, který je neustále spuštěn a
není možné jej změnit,poskytnetrvalouochranu
předškodlivým softwarem.
5.3.bZkontrolovat antivirovékonfigurace,
včetněhlavníinstalacesoftwaruavzorkusystémových komponent,
a ověřit, zda antivirový softwarenemůže být deaktivován nebo
změněnuživateli.
Použití politiky, založené na kontrolách všech
systémů s cílem zajistit, aby ochrana proti
malware nemohla být změněnanebo
deaktivována, napomůže zabránit zneužití
systémovýchslabinpředzneužitímškodlivým
softwarem.
5.3.cDotázat seodpovědnýchpracovníků, prověřit procesy a
ověřit, zdaantivirový softwarenemůže být deaktivován nebo
změněnuživateli, pokud to není výslovněschválenovedením a to
případod případu ana omezenoudobu.
Během doby, kdyneníantivirová ochranaaktivní,
může být také nutné implementovat další
bezpečnostníopatření napříkladodpojenínechráněnéhosystémuz
internetu zatímco je antivirová ochrana
deaktivována, apoté, cojeantivirová ochrana
obnovena, znovu spustit úplný sken.
strana58
Duben 2015
PCI DSS Požadavky
aprovozní procedury
proochranusystémůprotimalwarubyly
dokumentovány, používánya
5.4 Zkontrolovatdokumentaci, dotázat se pracovníků a ověřit,
zda jsou bezpečnostní politiky aprovozní postupy proochranu
systémů před malwarem:
Vysvětlení
Pracovníci si musí být vědomi bezpečnostních
politik a provozních postupů, aby zajistili, že
systémy jsou trvale chráněny před malwarem.
 dokumentovány,
 používají se, a
 jsou známyvšem dotčenýmstranám.
strana59
Duben 2015
Požadavek 6: Vyvíjet a udržovat bezpečné systémy a aplikace
Bezohlední jedinci využívají bezpečnostní slabiny, aby získali privilegovaný přístup do systému. Mnohé z těchto slabin jsou opraveny
bezpečnostními záplatami, které poskytl dodavatel a které musejí být instalovány těmi subjekty, jež systémy spravují. Všechny nejdůležitější
systémy musejí mít všechny odpovídající verze softwarových záplat, aby byla zajištěna ochrana před využitím a zneužitím dat držitelů karet
podvodníky a zákeřným softwarem.
Poznámka: Odpovídající softwarové záplaty jsou takové záplaty, které byly vyhodnoceny a dostatečně testovány ke zjištění, zdanejsou v konfliktu
se stávajícími bezpečnostními konfiguracemi. U interně vyvinutých aplikací je možné se vyhnout četným zranitelným místům, pokud se používají
standardní procesy vývoje systémů a techniky bezpečného vývoje.
PCI DSS Požadavky
6.1 Zavést proces identifikace
bezpečnostních slabin s použitím
uznávaných vnějších zdrojů obezpečnostních
zranitelnostech, a přiřazení rizikového
ohodnocení nově odhaleným bezpečnostním
zranitelnostem (například “vysoká”, “střední”,
“nízká”).
Poznámka:Rizikové ohodnocení má být založeno
na osvědčených postupech, jakož i na
posouzenípřípadného dopadu. Například kritéria
pro ohodnocenít zranitelnostimohou
zahrnovatzváženízákladníhoskóre CVSS,
a/nebotřídění podledodavatele,
a/nebotypuuvažovaných systémů.
Metodyproohodnocenízranitelnostiapostup
hodnocenítrizika sebudelišit
podleprostředíorganizaceastrategie hodnocení
rizika. ohodnocení rizika by
mělominimálněidentifikovatvšechnyzranitelnostipov
ažované v daném prostředí za"vysoké riziko".
Vedle ohodbnocení rizikamohou být
zranitelnostipovažovány za"kritické" v případě,
žepředstavujíbezprostředníohrožení prostředí, mají
dopad na kritické systémya/nebo mají za
následekpotenciální zkompromitování pokud
nejsou řešeny. Mezi příkladykritickýchsystémů
uvést bezpečnostnísystémy, zařízení asystémy s
přístupem veřejnosti, databázea dalšísystémy,
které uchovávají, zpracovávají nebopřenášejídata
držitelů karet.
6.2 Zajistit, aby veškeré systémové
6.1.a Zkontrolovatpolitiky a procedury a ověřit, zda jsou
procesy definoványpronásledující body:
 Identifikace nových bezpečnostních zranitelností.
 Přiřazeníhodnocení rizik ke zranitelnostem, kterézahrnují
všechny zranitelnosti ohodnocené jako „s vysokým
rizikem“ nebo „kritické“
 Použití uznávaných externích zdrojů pro informace
obezpečnostníchzranitelnostech.
6.1.bDotázat seodpovědnýchpracovníků aověřit procesy,
zda:
 Jsou identifikovány novébezpečnostní zranitelnosti
 Ohodnocení rizika zranitelnosti je přiřazeno ke
zranitelnostem s identifikací"s vysokým rizikem" a
"kritické".
 Procesy identifikující nové bezpečnostní
zranitelnostipoužívají uznávané externí zdroje k získání
informací obezpečnostníchzranitelnostech.
6.2.a Zkontrolovat politiky a procedury týkající se instalace
Vysvětlení
Záměrem tohoto požadavku je, aby organizace
udržovaly aktuální přehled o nových zranitelnostech,
které mohou mít dopad na jejich prostředí .
Zdroje informací o zranitelnostech by měly být
důvěryhodné a často zahrnují webové stránky
dodavatele, diskusní skupiny v odvětví, mailing
listsnebo RSS kanály.
Poté, co organizace identifikuje novou zranitelnost,
která by mohla ovlivnit její prostředí, riziko, které
zranitelnost představuje musí být ohodnoceno a
klasifikováno. Organizace proto musí mít
nastavenu// zavedenou metodu pro průběžné
hodnocení zranitelností a přiřazenu klasifikaci těmto
zranitelnostem. Toho se nedosáhne prostřednictvím
skenování ASV nebo vnitřním skenem zranitelnosti,
spíše to vyžaduje proces aktivního sledování zdrojů
informací o zranitelnosti.
Klasifikace rizika (například jako " vysoké", "střední"
nebo "nízké") umožňuje organizacím identifikovat ,
stanovit priority a rychleji reagovat na nejzávažnější
rizika a snížit pravděpodobnost, že nejvíce rizikové
zranitelnosti budou zneužity.
Vyskytuje se stálý proud útoků s využitím široce
strana60
Duben 2015
PCI DSS Požadavky
komponenty a veškerý software byl chráněn
před známými zranitelnostmi a byly
nainstalovány nejnovější bezpečnostní
záplaty dodané dodavatelem. Instalovat
nejzávažnější bezpečnostní záplaty do
jednoho měsíce od zpřístupnění.
Poznámka: Kritickébezpečnostní záplatyby
měly být identifikovány podleprocesu
klasifikace rizik definovanéhov
Požadavku6.1.
6.3 Vyvíjet interní a externí softwarové
aplikace (včetně internetového
administrativního přístupu k aplikacím) dle
 V souladu se standardem PCI DSS
(například bezpečná autentizace, tj.
ověření identity, a přihlašování, logování)
 Podle osvědčených standardů v odvětví
a/nebo osvědčených postupů.
 Zapracování informační bezpečnosti do
celého cyklu vývoje softwaru.
Poznámka: Toto se vztahuje na všechen
software vyvíjený interně a také na dodaný
na zakázku třetí stranou.
Vysvětlení
bezpečnostních záplat a ověřit, zda jsou definovány procesy
pro následující body:
publikovaných zranitelných míst, často nazývané
„Den nula“ (“zero day”, útok, který zneužívá dříve
neznámé zranitelnosti), proti jinak bezpečným
systémům. Pokud nejsou implementovány
nejnovější záplaty na kritických systémech co
nejdříve, může zlovolný jedinec využít tato
zranitelná místa k útoku nebo vypnutí systému nebo
získat přístup k citlivým datům.
 Instalace příslušných kritických bezpečnostních záplat
dodaných dodavatelem v průběhu jednoho měsíce.
 Instalace příslušných bezpečnostních záplat dodaných
dodavatelem v průběhu odpovídajícího časového rámce
(například v průběhu tří měsíců).
6.2.b U vzorku systémových komponent a souvisejícího
softwaru porovnat seznam bezpečnostních aktualizací
instalovaných v každém systému s nejnovějším seznamem
bezpečnostních záplat od dodavatele SW a ověřit
následující body:
 Příslušné kritické bezpečnostní záplaty dodaných
dodavatelem jsou instalovány v průběhu jednoho měsíce
od zpřístupnění.
 Všechny příslušné bezpečnostní záplaty dodaných
dodavatelem jsou instalovány v průběhu odpovídajícího
časového rámce (například v průběhu tří měsíců).
6.3.a Zkontrolovat písemné procesy vývoje softwaru
a ověřit, že procesy vycházejí z osvědčených standardů v
odvětví a/nebo osvědčených postupů.
6.3.b Zkontrolovat písemné procesy vývoje softwaru
a ověřit, že informační bezpečnost je zahrnuta do celého
životního cyklu.
6.3.c Zkontrolovat písemné procesy vývoje softwaru
a ověřit, že softwarové aplikace jsou vyvíjeny ve shodě se
standardy PCI DSS.
Prioritizace záplat pro kritickou infrastrukturu
zajišťuje, že kritické systémy a zařízení jsou
chráněny proti zranitelnosti co nejdříve poté, co je
záplata zveřejněna. Zvažte přednostní instalaci
záplat tak, aby bezpečnostní záplaty pro kritické
nebo rizikové systémy byly nainstalovány během 30
dnů, a jiné méně rizikové záplaty byly nainstalovány
během 2-3 měsíců.
Tento požadavek se vztahuje na příslušné záplaty
pro veškerý instalovaný software.
Bez zahrnutí bezpečnosti během definice
požadavků, návrhu, analýzy a testovací fáze
softwarového vývoje, mohou být bezpečnostní
zranitelnosti neopatrně nebo zlovolně zavedeny do
provozního prostředí.
Získání přehledu o tomu, jak jsou citlivá data
v aplikaci zpracovávána – včetně jejich uchovávání,
přenosu a zpracování v paměti – může napomoci
k identifikaci, kde musí být data chráněna.
6.3.d Dotázat se softwarových vývojářů a ověřit, že jsou
písemné procesy pro vývoj software implementovány.
strana61
Duben 2015
PCI DSS Požadavky
Vysvětlení
6.3.1 Odstranit vývojové, testovací a/nebo
běžné aplikační účty, uživatelská ID a hesla
před uvedením aplikace do produkčního
stavu nebo před předáním uživateli.
6.3.1 Zkontrolovat písemné procesy vývoje softwaru,
dotázat se odpovědných pracovníků a ověřit, zda
předprodukční a/nebo běžné aplikační účty, uživatelská
ID, a/nebo hesla jsou odstraněna před uvedením aplikace
do provozu nebo jeho předání uživateli.
Vývojové, testovací a/nebo zakázkové aplikační
účty, uživatelská ID a hesla by měla být odstraněna
z provozního kódu před uvedením aplikace do
provozu nebo jejímu předání uživateli, neboť tyto
prvky mohou prozradit informace o funkčnosti
aplikace. Znalost takových informací může usnadnit
kompromitaci aplikace a souvisejících dat držitelů
karet.
6.3.2 Prověřit programový kód, připravený
na zakázku, před jeho uvedením do
provozu nebo předáním zákazníkům a
identifikovat možné zranitelnosti programu
(s použitím buď manuálních nebo
automatizovaných procesů) s využitím
minimálně následujících kroků:
6.3.2.a Zkontrolovat písemné procesy vývoje softwaru,
dotázat se odpovědných pracovníků a ověřit, zda celý kód
vyvíjené aplikace je prověřen (s použitím manuálního
nebo automatického procesu) podle následujících bodů:
Bezpečnostní zranitelnosti v na zakázku
připravených programových kódech jsou běžně
využívány zlovolnými osobami k získání přístupu do
sítě a kompromitování dat držitelů karet.
 Změny kódujsou přezkoumány jinými
osobami než autorem původního
programu a osobami se znalostmi o
technikách prověřování kódu a
bezpečných programátorských
postupů.
 Prověrky kódu zajistí, že program je
vyvinut v souladu s postupy
bezpečného programování.
 Příslušné opravy jsou implementovány
před uvedením do provozu.
 Změny v kódu aplikace jsou prověřeny jinými
pracovníky než autorem původního kódu a
pracovníky se znalostmi o technikách prověřování
kódu apliakceí a bezpečných programovacích
postupů.
Prověrka kódu má být prováděna osobami se
znalostmi a zkušenostmi v technikách prověřování
kódu a má být prováděna jinými osobami než
autory původního programu, aby se zajistil nezávislý
a objektivní přezkum
 Prověření kódu zajistí, že program je vyvinut podle
doporučení k bezpečnému programování (viz
Požadavek 6.5 PCI DSS).
Opravachyb v programech před nasazením
programu doprodukčníhoprostředí,nebo jeho
uvolnění kzákazníkům,zabraňuje programu, aby
vystavilprostředípotenciálnímu zneužití.
Jetakémnohem obtížnějšíanákladnější opravovat
vadný program poté, cobyl nasazennebo uvolněn
doprodukčního prostředí.
 Příslušné opravy jsou implementovány před
uvolněním do provozu.
 Výsledky prověření kódujsou vyhodnoceny
aschválenyvedením před uvedením do provozu.
 Výsledky prověrky
kódujsoupřezkoumányaschválenyvede
nímpřed uvedením do provozu.
Zahrnutí formálního přezkoumánía odsouhlasení
vedením před nasazením kódu pomáhá zajistit, že
kód byl schválenabyl vyvinutvsouladu s politikami a
procedurami.
strana62
Duben 2015
PCI DSS Požadavky
Poznámka: Tento požadavek na prověření
kódu se vztahuje na všechny upravené
programy (interní i čelící veřejné doméně),
jako součást životního cyklu vývoje systému.
Vysvětlení
6.3.2.b Vybrat vzorek posledních změn zákaznické
aplikace a ověřit, zda kód programuzákaznické aplikace je
prověřen podle výše uvedeného Požadavku 6.3.2.a.
Prověření kódu programů může být
provedeno poučeným interním personálem
nebo třetí stranou. Webové aplikace také
podléhají dodatečným kontrolám, pokud čelí
veřejné doméně, k řešení trvalých hrozeb a
zranitelnosti po implementaci, podle definice
v Požadavku 6.6 PCI DSS.
6.4 Dodržovat postupy pro řízení změn a
procedury pro všechny změny systémových
komponent. Postupy musejí obsahovat
následující:
6.4.1 Oddělit vývojová/testovací prostředí
od provozního prostředí a vymáhat toto
oddělení kontrolou přístupu.
6.4 Zkontrolovat politiky a procedury a ověřit, zda jsou
definovány následující body:
 Vývojová/testovací prostředí jsou oddělena od
provozního prostředí, se zavedenými kontrolami přístupu
k posílení jejich oddělení.
 Musí existovat oddělení povinností mezi pracovníky
přidělenými k vývojovému/testovacímu prostředí a
pracovníky přidělenými k provoznímu prostředí.
 Provozní data (živá čísla karet) nejsou používána pro
testování nebo vývoj.
 Testovací data a účty jsou odstraněny před aktivací
provozního systému.
 Procedury pro řízení změn vztahující se na implementaci
bezpečnostních záplat (patches) a modifikaci softwaru
jsou dokumentovány.
6.4.1.a Zkontrolovat dokumentaci sítě, konfigurace
síťových zařízení a ověřit, zda vývojová/testovací prostředí
jsou oddělena od provozního (provozních) prostředí.
6.4.1.b Zkontrolovat nastavení kontrol přístupu a ověřit,
zda jsou zavedeny kontroly přístupu k posílení oddělení
mezi vývojovým/testovacím prostředím a prostředím
provozním (provozními).
Bez řádně dokumentovaných a implementovaných
kontrol řízení změn by mohly být nevědomky nebo
úmyslně opomenuty nebo znefunkčněny
bezpečnostní charakteristiky, mohly by se objevit
neobvyklé jevy ve zpracování nebo by mohl být
zanesen podvodný kód.
Vzhledem ke stále se měnícímu vývojovému a
testovacímu prostředí, tato prostředí mají tendenci
být méně bezpečné než provozní prostředí. Bez
adekvátního oddělení těchto prostředí může být
provozní prostředí, a data držitelů karet, vystaveno
kompromitování vzhledem k méně striktním
bezpečnostním konfiguracím a možným
zranitelnostem v testovacím nebo vývojovém
prostředí.
strana63
Duben 2015
PCI DSS Požadavky
6.4.2
Oddělit odpovědností mezi prostředím
vývojovým/testovacím a provozním.
6.4.3 Produkční data (živá čísla karet)
nejsou používána pro testování nebo vývoj.
Vysvětlení
6.4.2 Prověřit procesy, dotázat se pracovníků přidělených
k vývojovému/testovacímu prostředí a pracovníků
přidělených k provoznímu prostředí a ověřit, zda je
zavedeno oddělení povinností mezi pracovníky
přidělenými k vývojovému/testovacímu prostředí a
pracovníky přidělenými k provoznímu prostředí.
Snížení počtu pracovníků s přístupem do
provozního prostředí a dat držitelů karet
minimalizuje riziko a napomáhá k omezení přístupu
jen na ty jednotlivce, kteří potřebují tento přístup.
6.4.3.a Prověřit testovací procesy, dotázat se pracovníků
a ověřit, zda jsou zavedeny procedury zajišťující, aby
produkční data (živá čísla karet) nebyla používána pro
Bezpečnostní kontroly nejsou obvykle tak přísné ve
vývojovém nebo testovacím prostředí. Používání
provozních dat poskytuje zlovolným jedincům
příležitost k získání neoprávněného přístupu
k provozním datům (data držitelů karet).
Záměrem tohoto požadavku je zajistit oddělení
vývojových a testovacích funkcí od provozních
funkcí. Např. vývojář může použít účet na úrovni
administrátora se zvýšenými pravomocemi pro
použití ve vývojové prostředí, a může používat
oddělený účet s uživatelskou úrovní v provozním
prostředí.
6.4.3.b Zkontrolovat vzorek testovacích dat a ověřit, zda
nejsou provozní data (živá čísla karet) používána pro
6.4.4
Testovací data a účty jsou odstraněny před
uvedením do produkčního provozu.
6.4.4.a Prověřit testovací procesy, dotázat se pracovníků
a ověřit, zda jsou odstraněna testovací data a účty před
uvedením do produkčního provozu.
6.4.4.b Prověřit vzorek testovacích dat a účtů z
produkčních systémů nedávno instalovaných nebo
aktualizovaných a ověřit, zda byly odstraněny testovací
data a účty před uvedením do produkčního provozu.
Testovací data a účty by měly být odstraněny
z provozního programu dříve než se aplikace stane
aktivní, neboť tyto prvky mohou prozradit informace
o funkčnosti aplikace nebo systému. Držení
takových informací může usnadnit kompromitování
systému a souvisejících dat držitelů karet.
strana64
Duben 2015
PCI DSS Požadavky
6.4.5 Procedury řízení změn pro
implementaci bezpečnostních záplat
(patchů) a modifikaci softwarumusí
obsahovat následující kroky:
6.4.5.a Zkontrolovat dokumentované procedury řízení
změn vztahující se k implementování bezpečnostních
záplat a modifikaci softwaru a ověřit, zda jsou definovány
procedury pro:
Vysvětlení
Pokudnejsou změny správně řízeny, účinek
softwarových aktualizacíabezpečnostních záplat,
nemusí býtplně realizovánamůže mítnezamýšlené
důsledky.
 Dokumentace dopadu.
 Dokumentované schválení změn pověřenými
stranami.
 Provedení funkčního testování a ověření, zda změny
nemají nepříznivý účinek na bezpečnost systému.
 Procedury návratu (roll back).
6.4.5.b Dotázat se odpovědných pracovníků ohledně
vzorku systémových komponent a určit nedávné
změny/bezpečnostních záplaty (patches). Vysledovat tyto
změny a zpětně je porovnat s odpovídající dokumentaci
řízení změn. Pro každou změnu přezkoumejte a proveďte
6.4.5.1 Dokumentace dopadu.
6.4.5.1 Ověřit, zda dokumentace dopadu je zahrnuta
v dokumentaci řízení změn pro každou změnu ve
vzorku.
Dopad změny má být dokumentován, aby všechny
dotčené strany mohly plánovat odpovídající
provozní změny.
6.4.5.2 Dokumentované schválení změn
pověřenými stranami.
6.4.5.2 Ověřit, zda dokumentované schválení
pověřenými stranami je zaznamenáno pro každou
změnu ve vzorku.
Schválení pověřenou stranou prokazuje, že změny
jsou legitimní a schválená změna uznána
organizací.
6.4.5.3 Provést funkční otestování a
ověřit, zda změny nemají nepříznivý
dopad na bezpečnost systému.
6.4.5.3.a Pro každou změnu ve vzorku ověřit, zda bylo
provedeno funkční testování pro ověření, že změny
nemají nepříznivý účinek na bezpečnost systému.
Provést funkční testování a ověřit, zda bezpečnost
prostředí není snížena po implementováním změny.
Testování má ověřit, zda všechny existující
bezpečnostní kontroly zůstaly zavedeny nebo jsou
nahrazeny stejně silnými kontrolami nebo jsou po
změně prostředí posíleny.
6.4.5.3.b Pro změnu v aplikačním kódu ověřit, zda
všechny aktualizace jsou testovány na shodu s
Požadavkem 6.5 PCI DSS před nasazením do provozu.
6.4.5.4 Procedury návratu (roll back).
6.4.5.4 Ověřit, zda procedury návratu jsou připraveny
pro každou změnu ve vzorku.
Pro každou změnu by měla být dokumentována
procedura návratu pro případ, že se změna
nepovede, nebo nepříznivě ovlivní bezpečnost
aplikace nebo systému, a mohl být tak proveden
návrat do předchozího stavu.
strana65
Duben 2015
PCI DSS Požadavky
6.5 Zabránit obecným programátorským
zranitelnostem v procesech vývoje programů
zahrnutím následující bodů:
 Školení vývojářů v technikách
bezpečného programování včetně
způsobů, jak se vyvarovat obecně
zranitelným místům a pochopit, jak jsou
citlivá data zpracovávána v paměti.
 Vyvíjet aplikace podle návodů
bezpečného programování.
Poznámka: Zranitelná místa, jejichž seznam
je uveden v bodech 6.5.1 až 6.5.10, byla
v odvětví rozšířena a řešena osvědčenými
postupy v době vydání této verze standardu
PCI DSS. Vzhledem k aktualizaci
osvědčených postupů pro řízení zranitelnosti
(například Průvodce OWASP, SANS CWE
Top 25, CERT Secure Coding, apod.), musí
být pro tyto požadavky použity osvědčené
postupy.
6.5.a Zkontrolovat politiky a procedury vývoje softwaru a
ověřit, zda je pro vývojáře vyžadováno školení technik
bezpečného programování, které vycházejí z osvědčených
postupů a návodů.
6.5.b Dotázat se vzorku vývojářů a ověřit, zda jsou
seznámeni s technikami bezpečného programování.
6.5.cZkontrolovatzáznamy oškolení a ověřit, zda vývojáři
softwaruabsolvovali školenío technikch bezpečného
programování,včetně toho, jaksevyhnout
běžnýmzranitelnostem v programováníapochopení toho,
jaksecitlivá datazpracovávají vpaměti.
6.5.d. Ověřit, zda jsou zavedeny procesy k ochraně aplikací
před minimálně následujícími zranitelnostmi:
Vysvětlení
Aplikační vrstva nese vysoké riziko a může být cílem
vnitřních i externích hrozeb.
Požadavky 6.5.1 až 6.5.10 představují
minimálníkontroly, které mají být zavedeny a
organizace by měly zavést relevantní postupy pro
bezpečné programování ve vazbě na jejich
konkrétní technologické prostředí.
Aplikační vývojáři by měli být vyškoleni k identifikaci
a řešení problémů ve vztahu obecným
progamovacím zranitelnostem. Pracovníci poučení v
postupech bezpečného programování budou
minimalizovat počet bezpečnostních zranitelností
vyvolaných nedostatečnými programovacími
praktikami. Školení vývojářů se může konat interně
(in-house) nebo třetími stranami a mělo by se
zaměřit na použité technologie.
Jak se v odvětví mění osvědčené postupy
bezpečného programování, měly by se také
aktualizovat organizační postupy programování a
školení vývojářů by mělobýt rovněžaktualizovános
ohledem na novéhrozby - napříkladútoky na paměť.
Zranitelnosti uvedené vbodech 6.5.1až6.5.10tvoří
minimální základnu.Je naorganizaci, aby i
nadáledržela kroks
trendyzranitelnostiazačlenilapříslušná opatřenído
svýchbezpečných programátorských postupů.
strana66
Duben 2015
PCI DSS Požadavky
Vysvětlení
Poznámka: Níže uvedené Požadavky 6.5.1 až 6.5.6 se vztahují na všechny aplikace (interní nebo externí).
6.5.1 Vsunutí vlastního kódu (Injection
flaws), zejména vložení SQL. Uvážit také
příkazy vložení vlastního kódu do příkazu
OS, LDAP a Xpath a další vsunutí (injection
flaws).
6.5.1 Zkontrolovat politiky a procedury vývoje software,
dotázat se odpovědných pracovníků a ověřit, zda ochrana
proti vsunutí vlastního kódu (Injection flaws) je řešena
programátorskými postupy, které zahrnují:
 Ověření vstupů k ujištění, že uživatelská data
nemohou modifikovat význam příkazů a dotazů.
 Využití parametrizovaných dotazů.
Vsunutí vlastního kódu, zejména vsunutí SQL, je
obecně používaná metoda pro napadení aplikace.
Vsunutí kódu se vyskytuje při zaslání dat dodaných
uživatelem do interpretu jako součást příkazu nebo
dotazu. Nepřátelská data útočníka přiměje
interpreter k vykonání nezamýšlených příkazů, nebo
ke změně dat a umožní útočníkovi napadnout
komponenty uvnitř sítě prostřednictvím aplikace,
iniciovat útok jako je přetečení bufferu, nebo odhalit
důvěrné informace i aplikační funkčnosti serveru.
Informace by měly být ověřeny dříve, než jsou
poslány do aplikace - například zkontrolováním
všech abecedních znaků, smíšení abecedních a
numerických znaků atd.
6.5.2 Přetečení vyrovnávací paměti (Buffer
overflow)
přetečení vyrovnávací paměti (bufferu) je řešeno
programátorskými postupy, které zahrnují:
 Ověření hranice vyrovnávací paměti (bufferu)
 Zkrácení vstupních řetězců
6.5.3 Nezabezpečené kryptogafické
úložiště
nezabezpečené kryptogafické úložiště je řešeno
programátorskými postupy, které:
 Zabraňují nedostatkům v šifrování.
 Používají odolný šifrovací algoritmus a klíče.
K přetečení vyrovnávací paměti dojde, pokud
aplikace nemá odpovídající kontroly hranic své
vyrovnávací paměti. To může způsobit přetečení
informací z vyrovnávací paměti do paměti provozní.
Pokud k tomuto dojde, útočník může vložit
podvodný kód na konec vyrovnávací paměti a po té
přesunout podvodný kód do provozní paměti
přetečením vyrovnávací paměti. Podvodný kód je po
té spuštěn a často umožní útočníkovi vzdálený
přístup do aplikace a/nebo infikovaného systému.
Aplikace, které nevyužívají funkce odolného
šifrování ke správnému uchovávání dat, jsou
vystaveny zvýšenému riziku kompromitování a
odhalení autntikačních ověřovacích údajů a/nebo
dat držitelů karet. Pokud je útočník schopen zneužít
slabý šifrovací proces, pak může také získat
nezašifrovaný text zakódovaných dat.
strana67
Duben 2015
PCI DSS Požadavky
Vysvětlení
6.5.4 Nezabezpečené komunikace
nezabezpečené komunikace jsou řešeny
programátorskými postupy, které řádně autentizují a šifrují
všechnu citlivou komunikaci.
Aplikace, které nedostatečně šifrují přenosy v síti s
použitím odolné kryptografie jsou vystaveny
zvýšenému riziku kompromitování a odhalení dat
držitelů karet. Pokud je útočník schopen zneužít
slabý šifrovací postup, pak může také získat
kontrolu nad aplikací nebo dokonce získat
nezašifrovaný přístup k zakódovaným datům.
6.5.5 Nesprávné zpracování chyb
nesprávné zpracování chyb je řešeno programátorskými
postupy, které neumožňují únik informací chybnými
zprávami (například vracením generických místo
specifických údajích o chybách).
Z aplikace mohou uniknout informace o její
konfiguraci, vnitřní činnosti nebo jiné důvěrné
informace různými problémy aplikace. Útočníci
využívají tuto slabost ke krádeži citlivých dat nebo
zkompromitují celý systém. Pokud zlovolný jedinec
může vytvořit chybu, kterou aplikace nezpracuje
správně, může pak získat podrobné informace o
systému, vytvořit přerušení „odmítnutí služby“,
způsobit chybu zabezpečení nebo výpadek serveru.
Například zpráva „zadáno nesprávné heslo“
poskytne útočníkovi informaci, že zadané ID bylo
správné a že se může soustředit na odhalení hesla.
Použijte obecnější chybovou zprávu, jako „data
nemohou být ověřena“.
6.5.6 Všechny zranitelnosti s vysokým
rizikem („high risk“) identifikovat v procesu
identifikace zranitelnosti (jak definován v
Požadavku 6.1 PCI DSS).
dotázat seodpovědných pracovníků a ověřit, zda
programátorské postupy řeší zranitelnosti s vysokým
rizikem („high“), které mohou ovlivnit aplikaci, jak je
vedeno v Požadavku 6.1 PCI DSS.
Všechny zranitelnosti identifikované v organizaci při
procesuposuzovánírizik zranitelnosti(definované v
Požadavku 6.1) jako"vysoké riziko", a které by
mohlyovlivnit aplikaci, by měly býtidentifikovány a
řešenyv průběhuvývoje aplikace.
strana68
Duben 2015
PCI DSS Požadavky
Poznámka: Požadavky 6.5.7 až 6.5.10, uvedené níže, se vztahují na webové aplikace a aplikační interfejsy
(interní nebo externí).
6.5.7 Cross-site scripting (XSS).
(Pozn. překl.: Jde o metodu narušení
internetových stránek využitím
bezpečnostních chyb ve skriptech,
především o neošetřené vstupy).
programátorské postupy řeší cross-site scripting (XSS),
které:
 Ověřují všechny parametry před jejich vložením
 Využívají “context-sensitive escaping”.
Vysvětlení
Webové aplikace, jak vnitřní tak externí (čelící
veřejné doméně), představují unikátní bezpečnostní
riziko, vyplývající z jejich architektury a také z jejich
relativně snadné kompromitace (poškození) a jejího
častého výskytu.
Závady v XSSse projeví pokud aplikace odešle
uživatelemdodaná datanawebový prohlížeč, aniž by
nejdříve ověřila nebo zašifrovala jejich obsah.
XSSumožňuje
útočníkůmspustitskriptvprohlížečioběti, kteří se pak
mohou zmocnit relace uživatele, narušit webové
stránky, případnězavéstčervy, atd.
strana69
Duben 2015
PCI DSS Požadavky
Vysvětlení
6.5.8 Nesprávná kontrola přístupu (access
control) (např. nezabezpečené přímé
odkazy na objekty, opomenutí omezit
přístup na URL, převody adresářů
(directory traversal), a opomenutí omezit
přístup uživatele k funkcím).
nesprávná kontrola přístupu – jako jsou nezabezpečené
přímé odkazy na objekty, opomenutí omezit přístup na
URL a převody adresářů – je řešena programátorskými
postupy, které:
Přímé odkazy na objekty se vyskytují v případech,
kdy vývojář vystaví referenci na interní implementaci
objektu (například soubor, adresář, záznam v
databázi nebo klíč) jako URL nebo ve tvaru
parametru. Útočníci mohou zmanipulovat takovéto
reference a umožnit přístup k dalším objektům bez
autorizace.
 Správná autentizace uživatelů
 Ošetření vstupů
 Nezpřístupňování odkazů na interní objekty
uživatelům
 Uživatelská rozhraní nepovolují přístup k
nepovoleným funkcím.
Systematicky uplatněte kontrolu přístupu v
prezentační vrstvě a provozní logice pro všechny
URL. Často jediným způsobem, jak aplikace chrání
citlivé funkčnosti, je zabráněním zobrazení odkazů
nebo URL neautorizovaným uživatelům. Útočníci
mohou využít této slabosti k přístupu a provedení
neautorizovaných operací přímým přístupem na
takové URL.
Útočník může být schopný vysledovat a pohybovat
se ve struktuře adresářů internetové stránky
(převody adresářů, directory traversal) a získat tak
přístup k neautorizovaným informacím a také získat
další znalosti o činnosti stránky pro pozdější
vytěžování.
Pokud uživatelské rozhraníumožňujepřístup
kneoprávněnýmfunkcím, tentopřístupby mohlvést
k získání přístupu nepovolanými
osobamikprivilegovanýmověřovacím
údajůmnebodatům držitelů karet. Pouze
autorizovaníuživatelé by mělimít možnostpřístupu
napřímé odkazy naobjekty kcitlivýmzdrojům.
Omezenípřístupuk datovýmzdrojůmpomůže
ochránitdata držitelů karet od jejich zpřístupnění
neoprávněnýmzdrojům.
6.5.9 Padělaný požadavek z prohlížeče
(Cross-site request forgery, CSRF)
požadavek Cross-site request forgery (CSRF) je řešen
programátorskými postupy, které zajišťují, aby se aplikace
nespoléhaly na autorizační ověřovací údaje a tokeny
předávané automaticky od prohlížečů.
Útok CSRF přinutí prohlížeč přihlášené oběti odeslat
před-autorizační požadavek na zranitelnou webovou
aplikaci, která pak umožní útočníkovi provést
jakoukoli stav měnící operaci, kterou je oběť
oprávněna provést (například aktualizaciúdajů o
účtu, provádění nákupynebodokonceautentizaci v
rámci aplikace).
strana70
Duben 2015
PCI DSS Požadavky
6.5.10Přerušované ověření identity
(autentizace)a správa relace
Poznámka: Požadavek6.5.10je pokládán za
osvědčený postup do 30. června2015, po
tomto datu se stávápožadavkem.
přerušovaná atentizacea správa relace je řešena
programátorskými postupy, které obecně zahrnují:
 Flagging session tokens, tj. označení tokenů relace
(např. cookies) jako “bezpečné”
Vysvětlení
Bezpečná autentizacea správa relacebrání
neoprávněnýmjedincům v kompromitování
legitimních ověřovacích údajů k účtům, klíčům
nebotokenům relace, kteréby
jinakumožnilyútočníkovipřevzítidentituoprávněného
uživatele.
 Nevystavovat ID relace na URL
 Vložit vhodná časová omezení (time-outs) a rotovat
ID relace po úspěšném přihlášení.
strana71
Duben 2015
PCI DSS Požadavky
Vysvětlení
6.6 U veřejně přístupných webových aplikací
(čelící veřejnému přístupu, „public-facing“)
průběžně reagovat na nové hrozby a
zranitelná místa a zajištění, aby byly tyto
aplikace byly chráněny před známými útoky
pomocí kterékoli z těchto metod:
 Prověřovat veřejně přístupné webové
aplikaceprostřednictvím manuálních nebo
automatizovaných nástrojů nebo metod
pro posouzení bezpečnostní zranitelnosti
aplikací, nejméně jednou za rokapo
jakýchkoli změnách
6.6 U veřejně přístupných webových aplikací zajistit, aby
byla uplatněna některá z následujících metod:
 Zkontrolovat dokumentované procesy, dotázat se
odpovědných pracovníků a zkontrolovat záznamy o
vyhodnocení bezpečnosti aplikací a ověřit, zda veřejně
přístupné webové aplikace (public-facing“) jsou
prověřovány - prostřednictvím manuálních nebo
automatizovaných nástrojů nebo metod pro vyhodnocení
bezpečnostních zranitelností aplikací - a to následovně:
- Nejméně jednou ročně
- Po jakékoliv změně
- Organizací, která se specializuje na bezpečnost
aplikací
- Nejméněvšechny zranitelnosti popsané v
Požadavku 6.5 jsou zahrnuty v posuzování
- Všechny zranitelnosti jsou opraveny
- Aplikace je po opravách znovu vyhodnocena
 Zkontrolovat nastavení konfigurací systému, dotázat se
odpovědných pracovníků a ověřit, zdaje zavedeno
automatické technické řešení detekuje a zabraňuje
internetovým útokům (například firewally webových
aplikací), a to následovně:
- Je umístěno před webovou veřejně přístupnou
aplikací k detekci a prevenci internetových útoků.
- Je aktivně spuštěno a aktuální.
- Generuje auditní logy.
- Je konfigurováno buď na blokování webovýchútoků
nebo na generování varování, které je okamžitě
prověřeno
Útoky na veřejně přístupné webové aplikace jsou
běžné a špatně naprogramované webové aplikace
usnadňují cestu útočníkům k získání přístupu k
citlivým datům a systémům. Tento požadavek na
přezkum aplikací nebo instalování firewallu
webových aplikací má za cíl snížit počet průniků do
veřejně přístupných webových aplikací vlivem
špatného programování nebo postupu při správě
aplikace.
Poznámka: Toto posouzení není totéž
jako skenování zranitelnosti provedené
podle Požadavku 11.2.
 Instalovat automatické technické řešení
detekující a zabraňující webovým útokům
(například webové aplikační firewally)
před veřejně přístupnými webovými
aplikacemi k neustálé kontrole veškeré
komunikace.
6.7 Zajistit, aby bezpečnostní politiky
aprovozní postupypro
vývojaúdržbubezpečných systémůa aplikací
byly dokumentovány,používánya
6.7 Zkontrolovatdokumentaci, dotázat se pracovníků a
ověřit, zda jsou bezpečnostní politiky aprovozní postupy
provývojaúdržbubezpečných systémůa aplikací:
 dokumentovány,
 Manuální nebo automatické nástroje nebo
metody pro vyhodnocení bezpečnostní
zranitelnosti aplikací prověřují a/nebo testují
zranitelnost aplikace.
 Firewall webových aplikací filtruje a blokuje
nepodstatné komunikace v aplikační vrstvě.
Správně nakonfigurovaný firewall webové
aplikace použitý v kombinaci s firewallem
oddělujícím síť brání proti útoku na aplikační
vrstvu, pokud aplikace nejsou řádně
naprogramovány nebo konfigurovány. Toho
může být dosaženo pomocí kombinace
technologií a procesů. Řešení založené na
procesní bázi musí mít mechanismy umožňující
včasnou reakci na varování, aby bylo dosaženo
záměru tohoto požadavku, kterým jepředcházení
útokům.
Poznámka: „Organizace, která se specializuje na
bezpečnost aplikací”, může být buďto třetí osoba,
společnost, nebo interní organizace, pokud se
hodnotící specializuje na bezpečnost aplikací a
může doložitnezávislost na vývojovém týmu.
Pracovnícisi musí být vědomia provádět
následujícíbezpečnostní politiky aprovozní postupy
pro průběžné zajištěníbezpečného vývojea ochrany
systémů a aplikacípředzranitelnostmi.
strana72
Duben 2015
Zavedení přísných opatření a kontrol přístupů
Požadavek 7: Omezit přístup k datům držitelů karet jen podle oprávněné potřeby
Pro zajištění přístupu ke kritickým datům pouze pro autorizované pracovníky musí existovat systémy a procesy omezující přístup podle oprávněné
potřeby („Need to know“) a podle pracovní náplně a odpovědnosti.
Přístup „Need to know” znamená, že přístupová práva jsou poskytnuta jen k minimálnímu množství dat a privilegiím, které jsou potřebné k výkonu
práce.
PCI DSS Požadavky
7.1 Omezit přístup k systémovým
komponentám a datům držitelů karet
jen na ty osoby, jejichž práce takový
přístup vyžaduje.
7.1.1 Definovat potřeby přístupu
prokaždou roli, včetně:
 Systémové komponentya
zdrojových dat, ke kterým
každá role musí mít přístup
pro svou pracovní funkci
7.1Zkontrolovat dokumentovanou politiku pro kontrolu přístupu a
ověřit, zda politika zahrnuje Požadavky 7.1.1 až 7.1.4 podle
 Definování potřeby přístupu a přiřazení oprávněníprokaždou
roli
 Omezení přístupu podle oprávnění uživatelovaID na minimum
oprávnění nezbytných proplněnípracovních povinností
 Přiřazenípřístupuzaloženého naklasifikaci apracovní
funkcijednotlivých pracovníků
 Dokumentovanéschválení(elektronické nebopísemné)
oprávněnýmiosobamiproveškerý přístup,
včetněseznamuschválených specifickýchoprávnění.
7.1.1 Vybratvzorekrolíaověřit, zda jsouprojednotlivé
roledefinoványpotřebypřístupu a zahrnují:
 Systémové komponentyadatovézdroje, kterékaždá
rolepotřebujepro přístupk jejichpracovnímu zařazení
 Identifikaceoprávnění nezbytných prokaždou
rolikplněnípracovních povinností.
 Úroveň oprávnění
požadovaných pro přístup ke
zdrojům (například uživatel,
administrátor, apod.).
Vysvětlení
Čím více lidí má přístup k datům držitelů karet, tím
je větší riziko zneužití účtu uživatele k podvodu.
Omezení přístupu na osoby s oprávněnými
provozními důvody přístupu pomáhá organizaci
předcházet špatnému zacházení s daty držitelů
karet v důsledku nezkušenosti nebo zlého úmyslu.
K omezení přístupu k datům držitelů karet pouze na
ty jednotlivce, kteří potřebují takový přístup, je
nejprve nutné definovat přístupové potřeby pro
každou roli (například administrátor, pracovník call
centra, správce úložiště), po té
systémy/zařízení/data, ke kterým každá role
potřebuje přístup a úroveň oprávnění, kterou každá
role musí mít k efektivnímu vykonávání svěřených
pracovních povinností. Poté, co jsou definovány role
a odpovídající přístupy, může být jednotlivcům
přidělen přístup.
strana73
Duben 2015
PCI DSS Požadavky
7.1.2 Omezit přístup k
privilegovaným účtům k omezení
míry oprávnění pro vykonávání
pracovních povinností
7.1.2.a Dotázat se pracovníků, odpovědných
zapřidělovánípřístupu a ověřit, zda přístup k privilegovaným
uživatelským účtům je:
 přiřazen pouzek rolím, které se specificky vyžadují pro
privilegovaný přístup
 omezen pouze na minimální oprávnění nezbytná pro
plněnípracovních povinností.
7.1.2.b VybratvzorekID uživatelůsprivilegovaným přístupema
dotázat se odpovědnýchřídících pracovníků a ověřit,
zdapřiřazenáoprávnění jsou:
 nezbytná profunkcidaného pracovníka
 omezena pouze na minimální oprávnění nezbytná pro
plněnípracovních povinností.
Vysvětlení
Při přiřazováníprivilegovanéhoIDje
důležitépřiřaditjednotlivcůmpouzeoprávnění, které
potřebují k výkonusvé práce(dále jen "minimální
oprávnění"). Napříkladadministrátorovidatabáze
nebosprávciúložištěby nemělabýt přiřazenastejná
oprávnění, jakosprávci celéhosystému.
Přiřazeníminimálních oprávnění pomáhá
zabránituživatelůmbezdostatečnýchznalostíoaplikaci
nesprávněnebonáhodně změnitnastaveníaplikace
nebo změnitbezpečnostní nastavení. Zavedení
minimálních oprávnění také napomáhá
minimalizovatrozsahškod, pokud neoprávněná
osobazískápřístup kuživatelským ID.
7.1.3 Přiřadit přístup podle
klasifikace jednotlivých pracovních
míst a funkcí.
7.1.3 Vybratvzorekuživatelských ID, dotázat se
odpovědnýchřídících pracovníků a ověřit, zdajsou oprávnění
přiřazenapodle klasifikace jednotlivých pracovních míst a funkcí.
Jakmilejsou potřeby definovány podle uživatelských
rolí(podlePCIDSSPožadavku7.1.1), je snadné
přidělitjednotlivcůmpřístuppodle klasifikace jejich
pracovních míst a funkcí pomocíjižvytvořenýchrolí.
7.1.4 Vyžadovat dokumentovaný
souhlas autorizovanými stranami
specifikující požadovaná
oprávnění.
7.1.4 Vybratvzorekuživatelských ID a porovnat je se
dokumentovanými souhlasy a ověřit, zda:
Dokumentovaný souhlas (například písemněči
elektronicky) zajišťuje, že osoby s přístupema
privilegii jsou známyaschválenyvedením, a že jejich
přístup je nezbytný projejichpracovní funkci.
 existují dokumentované souhlasy pro přiřazená oprávnění
 souhlas byl udělen autorizovanými stranami
 jednotlivá oprávnění odpovídají rolím přiřazeným
jednotlivcům.
7.2 Zavést systém kontroly přístupu
pro systémové komponenty, který
omezuje přístup na základě provozní
potřeby uživatelů a pokud není
vydáno zvláštní povolení, je
nastaven na „zakázat vše“ (“deny
all”).
7.2 Prověřit nastavení systému a dokumentaci dodavatele a ověřit,
zda je implementován systém kontroly přístupu dle následujících
bodů:
Tento systém kontroly přístupu musí
zahrnovat následující kroky:
7.2.1 Pokrytí všech systémových
komponent
7.2.1 Potvrdit, zda systémy kontroly přístupu jsou zavedeny pro
všechny systémové komponenty.
Bezmechanismuomezenípřístupuna základě
provozních potřeb
uživatelů,můžebýtuživatelinevědomkyumožněn
přístupk datům držitelů karet.Systém kontroly
přístupu automatizuje procesomezení
přístupuapřiřazeníoprávnění. Navíc, výchozí
nastavení „zakázat vše“ zajišťuje, že nikomu není
povolen přístup, pokud není nastaveno pravidlo
povolující takovýto přístup.
Poznámka: Některé systémy kontroly přístupu jsou
nastavenyna “povolit vše ("allow-all"),
umožňujícípřístup do té doby, dokud není vloženo
strana74
Duben 2015
PCI DSS Požadavky
7.2.2 Přidělit oprávnění
jednotlivcům na základě klasifikace
pracovní náplně a funkce.
7.2.2 Potvrdit, zda systémy kontroly přístupu jsou konfigurovány
tak, aby vyžadovaly přidělení oprávnění jednotlivcům na základě
klasifikace pracovní náplně a funkce.
7.2.3 Výchozí (defaultní) nastavení
„zakázat vše”.
7.2.3 Potvrdit, zda systémy kontroly přístupu mají Výchozí
nastavení „zakázat vše”.
aprovozní postupy proomezení
přístupuk datům držitelů karet byly
7.3 Zkontrolovatdokumentaci, dotázat se pracovníků a ověřit, zda
jsou bezpečnostní politiky aprovozní postupy proomezení
přístupuk datům držitelů karet:
 dokumentovány,
Vysvětlení
pravidlo toto neumožňující.
Pracovníci si musí být vědomi a provádět
následující bezpečnostní politiky a provozní
postupy, které zajistí, že přístup je průběžné
kontrolován na základě znalostních potřeb uživatelů
a minimálních oprávnění.
strana75
Duben 2015
Požadavek 8: Identifikovat a autentizovat přístup k systémovým komponentám
Přidělení jedinečné identifikace (ID) každé osobě s přístupem zajišťuje evidenci přístupů a činností jednotlivých osob a jejich konkrétní
odpovědnost. Je-li takováto odpovědost zavedena, akce na kritických datech a systémech jsou prováděny, a mohou být vysledovány,
k jednotlivým známým a autorizovaným uživatelům a procesům.
Účinnost hesla je do značné míry závislá na návrhu a implementaci ověřovacího systému - zejména, jak často mohou být provedeny pokusy o
zadání hesla útočníkem a metody zabezpečení pro ochranu uživatelských hesel v místě vstupu, při přenosu a při uchovávání.
Poznámka: Tyto požadavky se vztahují na všechny účty, včetně účtů míst prodeje (point-of-sale), s administrativními oprávněními, a všechny účty
používané k prohlížení nebo přístupu k datům držitelů karet nebo k přístupům do systémů s daty držitelů karet. Do těchto požadavků jsou
zahrnuty i účty dodavatelů a dalších třetích stran (například pro podporu nebo údržbu).
Požadavky 8.1.1, 8.2, 8.5, 8.2.3 až 8.2.5, a 8.1.6 až 8.1.8 nejsou však určeny k aplikaci na uživatelské účty v rámci platební aplikace v místě
prodeje (point-of-sale), které mají současně přístup pouze k jednomu číslu karty k provedení jednotlivé transakce (např. účet pokladníka).
PCI DSS Požadavky
8.1 Definování a implementace politik a
postupů pro zajištění řádné správy
identifikace uživatele pro uživatele, kteří
nejsou zákazníky, a správci všech
systémových komponent podle
8.1.a Přezkoumat procedury a potvrdit, zda definují procesy pro
každou z položek níže uvedených v Požadavcích 8.1.1 až 8.1.8.
8.1.b Ověřit, zda jsou implementovány procedury pro správu
identifikace uživatele, provedením následujících kroků:
8.1.1 Přidělit všem uživatelům
jedinečné uživatelskéID před
umožněním jejich přístupu k
systémovým komponentám nebo
datům držitelů karet.
8.1.1 Dotázat se administrativních pracovníků, aby potvrdili,
zda jsou všem uživatelům přidělena jedinečná uživatelská ID
pro přístup k systémovým komponentám nebo datům držitelů
karet.
8.1.2 Řídit přidávání, mazání a změny
uživatelských ID, ověřovacích údajů
(credentials) a dalších objektů
identifikace.
8.1.2 U vzorku privilegovaných uživatelských ID a běžných
uživatelských ID zkontrolovat přidružená nastavení
autorizačních a monitorovacích systémů a ověřit, zda každé
uživatelské ID a privilegované uživatelské ID bylo
implementováno pouze s těmi právy, které byly schváleny
v dokumentovaném souhlasu.
Vysvětlení
Zajištěním, aby byl každý uživatel jednoznačně
identifikován — namísto používání jednoho ID pro
několik zaměstnanců — může organizace
stanovovat odpovědnost za činnost a uchovávat
auditní záznam pro každého jednotlivého
zaměstnance. To napomůže rychlejšímu vyřešení
problému a jeho omezení , pokud dojde ke zneužití
nebo se objev zlý úmysl.
K zajištění, aby uživatelské účty s umožněným
přístupemk systémům měly všechny
platnéauznávanéuživatele, stabilní procesy
musířídit všechnyzměnyuživatelských ID adalších
ověřovacích údajů (autentizaci),
včetněpřidánínovýchuživatelských jmenazměny
nebo zrušenístávajících jmen.
strana76
Duben 2015
PCI DSS Požadavky
8.1.3 Ihned zrušit přístup každému
uživateli, jehož oprávnění k přístupu
byl ukončeno.
Vysvětlení
8.1.3.a Vybrat vzorek uživatelů, kterým bylo
ukončenooprávnění k přístup v posledních šesti měsících a
prověřit aktuální seznam uživatelských přístupů – jak pro
místní tak vzdálený přístup – a ověřit, zda jejich uživatelská ID
byla deaktivována nebo odstraněna z aktuálního seznamu
uživatelských přístupů.
Jestliže nějaký zaměstnanec opustí společnost a má
stále přístup k síti přes svůj uživatelský účet, hrozí
možnost výskytu neoprávněného nebo zlovolného
přístupu k datům držitelů karet – buď od bývalého
zaměstnance nebo zlovolného uživatele, který
zneužije starší a/nebo nepoužívaný účet. K
zabránění neautorizovaného přístupu musí být při
ukončení pracovního poměru zaměstnance rychle
(jak jen to je možné) zrušeny ověřovací údaje
(credentials) uživatele a další ověřovací metody.
8.1.3.bOvěřit, zdavšechnyfyzické metody ověřování, jako
jsoučipové karty, tokeny, atd., byly vrácenynebo deaktivovány.
8.1.4 Odstranit/deaktivovat neaktivní
uživatelské účty během 90 dní.
8.1.4 Prověřit účty uživatelů a ověřit, zda jsou účty neaktivní
více než 90 dní buďto odstraněny nebo deaktivovány.
Účty, které se nepoužívají pravidelně, jsou často
cílem útoků, neboť je méně pravděpodobné, že
jakékoli změny (jako je změna hesla) budou
zpozorovány. Proto mohou být takové účty snadněji
zneužity a využity pro přístup k datům držitelů karet.
8.1.5 Spravovat uživatelská
IDpoužívanádodavateli pro přístup k
systémovýmkomponentám, a jejich
podpořenebo údržbě,
pomocívzdáleného přístupu dle
8.1.5.a Dotázat se pracovníků asledovatprocesypro
správuúčtůpoužívanýchdodavateli pro přístup,podporu, nebo
údržbusystémových komponent aověřit, zdaúčty
používanédodavateliprovzdálený přístupjsou:
Pokud dodavatelům povolíte přístup do vaší sítě 24
hodiny po 7 dnů v týdnu (24/7) v případě, že
potřebují podporovat vaše systémy, zvyšuje se tak
šance neautorizovaného přístupu, a to buď od
uživatele v prostředí dodavatele nebo od zlovolného
jedince, kteří najdou a použijí tento stále připravený
externí bod vstupu do vaší sítě. Povolením přístupu
pouze na potřebnou dobu, a jeho deaktivací jakmile
již nebude zapotřebí, napomůžete předcházet
zneužití spojení.
 Povolit pouzepo nezbytnou
potřebnoudobua deaktivovat je
pokud nejsou používána.
 Monitorovat je během jejich
používání.
8.1.6 Omezit opakované pokusy o
přístup do systému uzamčením
uživatelského jména (ID) po více než
maximálně 6 pokusech.
 Deaktivovány, když se nepoužívají
 Povolenypouze v případě, kdy jsou dodavatelem
zapotřebí, a deaktivovány, kdyžnejsou používány.
8.1.5.b Dotázat se pracovníků asledovatprocesy a ověřit, zda
účty pro vzdálený přístup dodavatele jsou při jejich používání
monitorovány.
8.1.6.a U vzorku systémových komponent získat a prověřit
nastavení systémové konfigurace a ověřit, zda autentizační
parametry jsou nastaveny tak, aby uživatelský účet vyžadoval
uzamčení po maximálně šesti neúspěšných pokusech o
přihlášení.
8.1.6.b Doplňková testovací procedura platná pouzepro
poskytovatele služeb: Přezkoumat interní procesy a
zákaznickou / uživatelskou dokumentaci, prověřit
implementované procesy a ověřit, zda účty uživatelů, kteří
Monitorování přístupu dodavatele poskytuje záruku,
že dodavatelé přistupují jen do nezbytných systémů
a pouze ve schválených časových obdobích.
Není-li zaveden mechanismus pro zablokování účtu
(lock-out), může se útočník dlouhodobě pokoušet
uhádnout heslo pomocí manuálních nebo
automatických nástrojů (například „rozbitím hesla“),
dokud nedosáhne úspěchu a nezíská přístup k účtu
uživatele
Poznámka: Testovací procedura 8.1.6 b je
strana77
Duben 2015
PCI DSS Požadavky
Vysvětlení
nejsou zákazníci, jsou dočasně uzamčeny po maximálně šesti
neúspěšných pokusech o přihlášení.
8.1.7 Nastavit dobu uzamčení na
nejméně 30 minut nebo dokud
administrátor uživatele neaktivuje.
8.1.7 U vzorku systémových komponent získat a prověřit
nastavení systémové konfigurace a ověřit, zda parametry
hesel jsou nastaveny tak, aby vyžadovaly po uzamčení
uživatelského účtu setrvání jeho uzamčení po dobu nejméně
30 minut nebo do doby, než je účet správcem resetován.
Pokud byl účet zablokován proto, že se někdo
soustavně snaží uhádnout heslo, kontroly s
odkladem reaktivace těchto účtů znemožní
podvodníkovi, aby se nepřetržitě snažil uhádnout
heslo (bude muset čekat minimálně 30 minut, než
bude účet reaktivován). Dále, musí-li být reaktivace
vyžádána, může správce nebo helpdesk ověřit, zda
se jedná o opravdový účet vlastníka požadujícího
reaktivaci.
8.1.8 Pokud byla relace nečinná déle
než 15 minut, požadovat po uživateli
opakovanou autentizaci pro reaktivaci
terminálu nebo relace.
8.1.8 U vybraných systémových komponent získat a prověřit
nastavení systémové konfigurace a ověřit, zda čas maximální
povolené nečinnosti systému/relace byl nastaven na
maximálně 15 minut.
Když uživatelé odejdou od spuštěného terminálu
spřístupem ke kritickým systémovým komponentám
nebo datům držitelů karet, může v uživatelově
nepřítomnosti terminál použít někdo jiný, což má za
následek neautorizovaný přístup k účtu a/nebo
zneužití účtu.
Opětovná autentizacemůže být použitabuďna úrovni
systémuk ochraněvšech relacíspuštěnýchna tomto
terminálu nebonaúrovni aplikace.
8.2 Kromě přidělení jedinečného
uživatelského ID, zajistit řádnou správu
ověření pro uživatele, kteří nejsou
zákazníky, a administrátory na všech
systémových komponentách využitím
nejméně jedné z následujících metod k
ověření všech uživatelů:
 Něco, co znáte – jako je heslo nebo
heslová fráze
 Něco, co vlastníte – jako je token
nebo čipová karta
 Něco, kým jste – například
biometrika.
8.2 Ověřit, zda jsou uživatelé ověřováni pomocí jedinečného
uživatelského ID a další autentizace(například pomocí
hesla/heslové fráze) pro přístup do prostředí dat držitelů karet, a
provést následující body:
 Prověřit dokumentaci popisující použité metody ověření.
 Pro každý použitý typ metody ověření a pro každý typ
systémové komponenty sledovat ověření a prověřit, zda
ověření funguje v souladu se dokumentovanou metodou
(metodami) ověřění.
Tyto metody ověření, použijí-li se spolu s
jedinečným uživatelským ID, napomáhají ochraně
uživatelskéhoID před kompromitováním, neboť
jedinec pokoušející se o kompromitaci potřebuje
znát jak jedinečné uživatelské ID, tak heslo (nebo
jiné použité ověření). Povšimněte si, že digitální
certifikát je platná volba pro “něco, co vlastníte”,
pokud je jedinečný pro daného uživatele.
Vzhledem k tomu, že prvním krokem, který zlovolný
jedinec učiní ke kompromitaci systému, je zneužití
slabého nebo neexistujícího hesla, je důležité
implementovat vhodný proces pro správu
ověřovácích pravidel.
strana78
Duben 2015
PCI DSS Požadavky
8.2.1Použitsilného šifrování
učinívšechny ověřovací údaje(jako jsou
hesla/heslové fráze) nečitelnéběhem
přenosuaukládání navšechny
systémové komponenty.
8.2.1.a Zkontrolovatdokumentaci dodavateleanastavení
konfigurace systému a ověřit, zdaheslajsoupři přenosu a
uchovávání chráněna odolnou kryptografií.
8.2.1.bU vzorkusystémových komponentzkontrolovatsoubory s
hesly a ověřit, zdahesla jsouběhem uchovávání nečitelná.
8.2.1.c U vzorkusystémových
komponentzkontrolovatpřenosydat a ověřit, zdahesla
jsouběhem přenosu nečitelná.
8.2.1.d Doplňková testovací procedura platná pouze
proposkytovatele služeb: Prověřit soubor s hesly aověřit, zda
hesla (uživatelů, kteří nejosu zákazníky) jsouv době
uchovávání nečitelná.
Vysvětlení
Mnoho síťových zařízení a aplikací přenáší
nezašifrované, čitelné heslo po síti a/nebo také
uchovává hesla v nezašifrované podobě. Zlovolný
jedinec může během přenosu snadno zachytit
nezašifrované nebo čitelné heslo pomocí
„čmuchacího zařízení” („sniffer“), nebo může přímo
proniknout k nezašifrovaným heslům v souborech,
kde jsou uchovávána, a využít tato data k získání
neautorizovaného přístupu.
Poznámka: Testovací procedura8.2.1.d a
8.2.1.e je dodatečnou procedurou, která je platná
pouze v případě, že je hodnocen poskytovatel
služeb.
8.2.1.e Doplňková testovací procedura platná pouze
proposkytovatele služeb: Prověřit přenosydat aověřit, zda
hesla (uživatelů, kteří nejsu zákazníky) jsouběhem přenosu
nečitelná.
8.2.2Ověřit identitu uživatele před
změnoujakýchkoli ověřovacích údajů
(authentication credentials) – například
provedením resetování hesla,
poskytnutím
novýchtokenůnebogenerovánímnových
klíčů.
8.2.2 Prověřit ověřovacípostupy pro změnuověřovacích údajů,
prověřit administrátory bezpečnosti a prověřit, zda při
požadavku uživatele na resetování ověřovacího údaje
telefonicky, e-mailem, po internetu nebo jinou metodou bez
osobního kontaktu, je před změnou ověřovacího údaje
ověřena uživatelova identita.
Mnozí podvodníci používají „sociální inženýrství“ —
například telefonují na helpdesk a jednají jako
legitimní uživatelé — za účelem změny hesla, aby
mohli využívat ID jiného uživatele. Zvažte zavedení
„tajné otázky“, kterou může zodpovědět pouze
oprávněný uživatel, aby mohli administrátoři lépe
identifikovat uživatele před novým nastavením hesla
nebo modifikací ověřovacích údajů.
strana79
Duben 2015
PCI DSS Požadavky
8.2.3 Hesla/heslové fráze musí
vyhovovat následujícím podmínkám:
 Vyžadovat jako minimální délku
hesla nejméně 7 (sedm) znaků.
 Obsahovat jak numerické, tak
abecední znaky.
Alternativně, hesla/heslové fráze
musímítsložitosta odolnost,která je
alespoň rovnocennáparametrům
uvedenýchvýše.
8.2.3a U vzorku systémových komponent přezkoumat
nastavení konfigurace systému a ověřit, zda parametry
uživatelských hesel jsou nastaveny tak, aby vyžadovaly
minimálně následující odolnost/složitost:
 Požadovat jako minimální délku hesla nejméně 7 (sedm)
znaků.
 Obsahovat jak numerické, tak abecední znaky.
8.2.3.bDoplňková testovací procedura platná pouze
proposkytovatele služeb:
Přezkoumat interní procesy a zákaznickou/uživatelskou
dokumentaci a ověřit, zda hesla (uživatelů, kteří nejsu
zákazníky), splňují minimálně následující odolnost/složitost:
 Požadovat jako minimální délku hesla nejméně 7 (sedm)
znaků.
 Obsahovat jak numerické, tak abecední znaky.
Vysvětlení
Silná hesla/heslové fráze jsou první linií obrany sítě,
protože zlovolný jedinec se často snaží nejprve najít
účty se slabými nebo neexistujícími hesly. Pokud
jsou hesla krátká a jednoduchá, lze je uhádnout, a je
relativně snadné pro zlovolného jedince najít
takovéto slabé účty a ohrozit síť pod rouškou
platného uživatelského ID.
Tento požadavek stanoví, že pro hesla/heslové
fráze by se mělo používat minimálně sedm znaků a
to jak číselné, tak abecední znaky. V případech, kdy
toto minimum nelze splnit z důvodu technických
omezení, mohou jednotlivé subjekty použít
"ekvivalentní odolnost" k auditnímu vyhodnocení
alternativ. Standard NIST SP 800-63-1 definuje
"entropii" jako "míru obtížnosti uhádnout nebo určit
heslo nebo klíč." Můžeme odkázat na tento a další
dokumenty, které popisují "entropii hesla", pro více
informací o příslušné hodnotě entropie a pro
pochopení ekvivalentní variability(zranitelnosti)
odolnosti hesla pro různé formáty hesla/heslové
fráze.
Poznámka: Testovací procedura8.2.3.b je
8.2.4Změnituživatelská hesla/heslové
fráze nejméně jednouza 90 dní.
8.2.4.a U vzorku systémových komponent přezkoumat
nastavení konfigurace systému a ověřit, zda parametry hesel
jsou nastaveny tak, aby vyžadovaly změnuuživatelských hesel
nejméně jednou za každých 90 dní.
8.2.4.bDoplňková testovací procedura platná pouze
Hesla/heslové fráze, které jsou platné po dlouhou
dobubeze změnyposkytují zlovolným jedincůmvíce
časupracovat narozbití hesla/heslové fráze.
Přezkoumat interní procesy a zákaznickou/uživatelskou
dokumentaci a ověřit, zda:
 Hesla uživatelů, kteří nejosu zákazníky, se musí
pravidelněměnit; a
 Uživatelům, kteří nejsou zákazníky, musí být poskytnuty
pokyny, kdy a za jakých okolností si musíheslazměnit.
strana80
Duben 2015
PCI DSS Požadavky
Vysvětlení
8.2.5 Neumožnit jednotlivci zadání
nového hesla/heslové fráze, které je
stejné jako kterékoliv z posledních čtyř
hesel/heslových frází naposledy
použitých.
8.2.5.a U vzorku systémových komponent získat a přezkoumat
nastavení konfigurace systému a ověřit, zda parametry hesel
jsou nastaveny tak, aby vyžadovaly nové heslo, které nebude
stejné jako čtyři naposledy použitá hesla.
Neuchovává-li se historie hesel, účinnost změny
hesel je snížena, protože předchozí hesla lze znovu
a znovu používat. Požadavek, aby hesla nemohla
být po určitou dobu znovu použita, snižuje
pravděpodobnost, že hesla která byla uhádnuta
nebo hrubou silou prolomena, budou použita v
budoucnosti.
8.2.6 Nastavitheslo/heslovou frázi
proprvní použití,a
přiresetu,najedinečnou hodnotupro
každého uživatele, apo prvním
použitíokamžitězměnit.
8.2.5.b Doplňková testovací procedura platná pouze
proposkytovatele služeb: Přezkoumat interní procesy a
zákaznickou/uživatelskou dokumentaci a ověřit, zda
heslauživatelů, kteří nejsou zákazníky, jsou nastavena tak, aby
nebyla stejná jako čtyři naposledy použitá hesla.
8.2.6 Zkontrolovat procedury s hesly, prověřit
bezpečnostnípracovníky a ověřit, zdahesla proprvní použití
unových uživatelů,a resetovanáheslaustávajících uživatelů,
jsou nastavenanajedinečnou hodnotupro každého
uživateleazměněnapo prvním použití.
Jestliže je pro každého nového uživatele použito
stejné heslo, může toto heslo znát nebo snadno
zjistit bývalý zaměstnanec nebo zlovolný jedinec a
použít je pro přístup k účtům.
8.3Začlenit dvoufaktorové ověření
identity(autentizaci) pro vzdálený přístup
do sítě pocházející z vnějšku sítě pro
pracovníky (včetně uživatelů a
administrátorů) a třetí osoby, (včetně
přístupu dodavatelů podpory nebo
údržby).
8.3.a Zkontrolovat systémové konfiguraceproserveryvzdáleného
přístupua systémy a ověřit, zda dvoufaktorové ověření
(autentizace)je vyžadována pro:
Dvoufaktorové ověření (autentizace) vyžaduje dvě
formy ověření v případě rizikovějšího přístupu,
například přístupy z vnějšku sítě.
 Všechnyvzdálenépřístupy ze strany zaměstnanců
 Všechny vzdálenépřístupy ze strany třetích
stran/dodavatelů(včetně přístupu k aplikacím asystémovým
komponentámpro účelypodporya údržby).
Poznámka: Dvoufaktorové ověření
(autentizace) vyžaduje, aby pro ověření
byly použity dvě ze tří ověřovacích
metod (viz PCI DSS Požadavek 8.2
ohledně popisu autentizačních metod).
Použití jednoho faktoru dvakrát (např.
použití dvou různých hesel) není
považováno za dvoufaktorové ověření.
8.3.bPrověřitvzorekpracovníků (např. uživatele a správce)se
vzdáleným přístupemdo sítěaověřit, zdajsou používány
nejménědvě ze tří ověřovacích metod.
Tento požadavek se vztahuje na všechny
pracovníky – včetně obecných uživatelů,
administrátorů a dodavatelů (pro podporu a údržbu)
se vzdáleným přístupem k síti - kde takový přístup
může vést k přístupu do prostředí dat držitelů karet.
Příkladydvoufaktorovýchtechnologiízahrn
ujcíí vzdálené ověření adial-in
službu(RADIUS,Rremote Authentication
and Dial-In Service) s toikeny;
řadičterminálového přístupu prosystém
řízení přístupu(TACACS, Terminal
Access Controller Access Control
Jedná-li se o vzdálený přístup do sítě subjektu, která
má odpovídající segmentaci, kdy vzdálený uživatel
nemůže získat přístup nebo ovlivnit prostředí dat
držitelů karet, nebude vyžadována dvoufaktorové
ověření (autentizace) pro vzdálený přístup do
uvedené sítě. Nicméně dvoufaktorové ověření
(autentizace) je vyžadována pro vzdálený přístup do
sítí s přístupem do prostředí dat držitelů karet, a je
doporučována pro všechny vzdálené přístupy do sítí
subjektu.
strana81
Duben 2015
PCI DSS Požadavky
Vysvětlení
8.4.a Zkontrolovatpostupy, dotázat se pracovníků a ověřit, zda
ověřovací procedury apolitikyjsou distribuoványvšem uživatelům.
Vytvoření komunikačních postupů pro stanovení
hesla/autentizace tak aby všem uživatelům zmíněná
politika pomáhala lépe porozumět a následně se jí
uživatelé mohli řídit. Například návod na výběr
odolných hesel může obsahovat návrhy, jak si
pracovníci mohou vybrat těžko uhádnutelná hesla,
která neobsahují slova ze slovníku a která
neobsahují informace o uživateli (například ID
uživatele, jména členů rodiny, datum narození,
apod.). Návod na ochranu přihlašovacích údajů
může zahrnovat doporučení nezapisovat si hesla
nebo neukládat je v nezabezpečených souborech, a
být na pozoru před zlovolnými jedinci, kteří se
mohou pokusit využít jejich heslo (například
zavoláním zaměstnanci a požádat ho o jeho heslo,
aby volající mohl "Odstranit problém").
System) s tokeny; a další technologie,
které umožňují dvou-faktorovéověření
(autentizaci).
8.4 Dokumentovatakomunikovat
ověřovací procedury a politiky všem
uživatelům, včetně:
 Pokyny kvýběrusilnýchpřihlašovacích
údajů
 Návod, jakby měluživatel chránit své
přihlašovací údaje
 Pokynynepoužívatdřívepoužitá hesla
 Pokynyke změněhesla,
pokudexistujepodezření, že hesloby
mohlo být ohroženo.
8.4.b Přezkoumat ověřovací procedury a politiky, kteréjsou
distribuoványuživatelůmaověřit, zda zahrnují:




Návod kvýběru odolných přihlašovacích údajů
Návod, jakby uživatelé měli chránit svépřihlašovací údaje.
Pokynypro uživatele, abynepoužívalidřívepoužitá hesla
Pokynyke změněhesel, pokud existujepodezření, že hesloby
mohlo být ohroženo.
8.4.c Dotázat se vzorku uživatelů a ověřit, zda jsou obeznámeni
s ověřovacími postupy a politikami.
Pokyn uživateli ke změně hesla, pokud existuje
možnost, že heslo již není bezpečné, může zabránit
zlovolným uživatelům použít legitimní heslo k
získání neoprávněného přístupu.
8.5 Nepoužívat skupinová, sdílená ani
generická ID , hesla nebo jiné
ověřovacích metody dle následujících
bodů:
 Generická ID uživatelejsouzakázána
neboodstraněna.
 SdílenáID uživatele se nepoužívají
pro systémové administrátory a další
kritické funkce. .
 Sdílená agenerickáID
uživatelenejsoupoužívána k
administracijakýchkoli systémových
8.5.a U vzorkusystémových komponent prověřit seznam
uživatelských ID a ověřit následující body:

Generická ID uživatele jsou deaktivována nebo
odstraněna.

SdílenáID uživateleneexistujípro aktivity administrátorů
systému a další kritické funkce.

Sdílená a generická ID uživatele nejsou používána k
administraci jakýchkoli systémových komponent.
Jestliže větší počet uživatelů sdílí stejné ověřovací
údaje (například uživatelský účet a heslo), je
nemožné vysledovat přístupy do systému a aktivitu
jednotlivců. To zase zabrání subjektu přiřadit
odpovědnost za akce jednotlivce, nebo provést
efektivní odhlášení, neboť daná akce by mohla být
provedena kýmkoli ze skupiny, kdo má znalosti o
ověřovacích údajích.
8.5.b Prověřit ověřovací pravidla/postupy a ověřit, zda použití
skupinových a sdílených hesel a/nebo jiných ověřovacích metod
je výslovně zakázáno.
strana82
Duben 2015
PCI DSS Požadavky
komponent.
8.5.1 Doplňková testovací procedura
platná pouze proposkytovatele
služeb:
Poskytovatelé služebsevzdáleným
přístupemdo
prostorzákazníka(například pro
podporuPOSsystémůnebo serverů)
musí používatunikátníautentizací
ověřovací údaje (například hesla/fráze)
pro každého zákazníka.
Vysvětlení
8.5.cDotázat se správců systému a ověřit, zda skupinová a
sdílená ID a/nebo hesla nebo jiné ověřovací metody nebudou
distribuovány, ani když jsou vyžadovány.
8.5.1 Doplňková testovací procedura platná pouze
Zkontrolovat autentizační politiky apostupy, dotázat se
pracovníků a ověřit, zda jsou pro přístupke
každémuzákazníkovi použita různá ověřování (autentizace).
Poznámka:Tento požadavek je platný pouze
Aby se zabrániloohroženívíce
zákazníkůkvůlipoužitíjedné sady ověřovacích údajů
(credentials), dodavatelé s účty vzdálených
přístupůdoprostředízákazníkaby mělipoužít
různéověřovací údaje pro jednotlivézákazníky.
Technologie, jako jsou
napříkladdvoufaktorovémechanismy, které
poskytujíjedinečné ověřovací údaje prokaždé
připojení(například prostřednictvímheslana jedno
použití) by mohlarovněž splňovatzáměrtohoto
požadavku.
Poznámka: Tento
požadaveknenízamýšlen pro
poskytovatelesdíleného
hostingupřistupující kjejich
vlastnímuhostingovémuprostředí, kde se
vyskytují četnější prostředízákazníků.
Poznámka: Požadavek8.5.1je pokládán
za osvědčený postup do 30. června2015,
po tomto datu se stávápožadavkem.
8.6Pokud jsoupoužity jiné ověřovací
mechanismy(například
fyzickénebologickébezpečnostnítokeny,
čipové karty, certifikáty, atd.),
použitítěchtomechanismůmusí
býtpřiřazeno následovně:
 Ověřovacímechanismy musíbýt
přiřazenyk jednotlivémuúčtuanesmí
být sdílenymezi víceúčty.
 Musíbýt zavedenyfyzickéa/
nebologickékontroly,aby bylo
zajištěno, žepouze určenýúčetmůže
použíttento mechanismusk získání
přístupu.
8.6.a Zkontrolovat ověřovací politiky a procedury a ověřit,
zdaprocedurypropoužívání ověřovacích mechanismů, jako jsou
fyzické bezpečnostní tokeny, čipové karty acertifikáty,jsou
definoványa zahrnují body:
 Ověřovací mechanismyjsou přiřazeny kindividuálnímuúčtu
anejsou sdílenymezi víceúčty.
 Fyzikálnía/nebologickékontroly jsou definovány, aby zajistily,
že pouze určenýúčetmůžete použíttento mechanismusk
získání přístupu.
Pokud ověřovacímechanismy, jako jsou tokeny,
čipové karty, a certifikáty,mohou být použityvíce
účty, můžebýtnemožné identifikovatjedincepomocí
ověřovacího
mechanismu.Sfyzickýmia/nebologickými
kontrolami(například PIN, biometrické
údajeneboheslo) k jednoznačné
identifikaciuživateleúčtubude možno zabránit
neoprávněnýmuživatelům v získání
přístupuprostřednictvím
použitísdílenéhomechanismu ověření.
strana83
Duben 2015
PCI DSS Požadavky
Vysvětlení
8.6.b Dotázat se pracovníků a ověřit, zda jsouověřovací
mechanismypřiřazenyk účtuanejsou sdílenymezi víceúčty.
8.6.c Zkontrolovatnastavení systémové konfigurace
a/nebofyzickýchkontrol, podle potřeby, a ověřit, zda jsou
implementovány kontroly s cílem zajistit, abyjen určený účetmohl
použíttento mechanismusk získání přístupu.
8.7Všechny přístupyke každé
databáziobsahujícídata držitelů
karet(včetně přístupů aplikace ,
administrátory a všichny
ostatníuživatele)jsouomezeny
následovně:
 Všechnypřístupy uživatelů k
databázím,
uživatelskédotazyauživatelskéčinnost
i naddatabázemi musí být prováděny
prostřednictvímprogramovýchmetod.
 Pouze administrátoři databázímají
možnostpřímopřistupovatk databázím
nebovytvářet dotazy nad nimi.
 IDaplikaceprodatabázové aplikace
mohou být použity pouze samotnou
aplikací(a nikolijednotlivými uživateli
nebojinými procesy mimo aplikaci).
aprovozní postupy pro identifikaci a
ověřování byly dokumentovány,
používánya
8.7.a Přezkoumat nastavení konfigurace databáze a aplikace a
ověřit, zda všichni uživatelé jsou ověřeni před přístupem.
8.7.b Zkontrolovatnastavení konfiguracedatabázeaaplikace a
ověřit, zdavšechny uživatelsképřístupy k databázím,
uživatelskédotazyauživatelskéčinnostinaddatabázemi (například
přesuny, kopírování,mazání) jsou
prováděnypouzeprostřednictvímprogramovýchmetod(například
prostřednictvím uložených procedur).
8.7.c Zkontrolovatnastavení kontroly přístupu k
databázianastavení konfiguracedatabázových aplikací a ověřit,
zda přímý přístup uživatele k databázi nebodotazy nad
databázíjsou omezeny na administrátory databáze.
Jestliže neexistuje ověření uživatele pro přístup do
databází a aplikací, zvyšuje se možnost
neautorizovaného nebo podvodného přístupu a
takový přístup nemůže být protokolován, protože
uživatel nebyl ověřen a není tedy systému znám.
Také přístup do databáze by měl být poskytován jen
prostřednictvím programových metod (například
prostřednictvím uložených procedur) namísto
přímého přístupu koncových uživatelů do databáze
(s výjimkou administrátora databáze, DBA - Data
Base Administrator, který může potřebovat přímý
přístup do databáze za účelem plnění svých
správcovských povinností).
8.7.d Zkontrolovatnastavení kontroly přístupu k databázi a
nastavení konfiguracedatabázových aplikací a ID databázových
aplikací a ověřit, zda ID aplikací mohou být použity pouze
aplikacemi (a nikoliv individuálními uživateli nebo jinými
procesy).
zda bezpečnostní politiky aprovozní postupy proidentifikaci a
ověřováníjsou:
Pracovníci si musí být průběžně vědomi
bezpečnostní politiky a provozních postupů pro
řízení identifikace a autorizace.
 dokumentovány,
strana84
Duben 2015
Požadavek 9: Omezit fyzický přístup k datům držitelů karet
Jakýkoliv fyzický přístup k datům nebo systémům, které uchovávají data držitelů karet, poskytuje příležitost přístupu jednotlivce k zařízením nebo
datům a možnost vyjmout nebo „duplikovat “ tyto systémy, by měl být vhodně omezen. Pro účely Požadavku 9 označuje termín „pracovník (onsite
personnel)“ zaměstnance na plný i částečný úvazek, zaměstnance na dobu určitou, dodavatele a konzultanty, kteří jsou přítomni v prostorách
subjektu. Pojem „návštěvník“ (visitor) odkazuje k dodavateli, hostovi někoho z přítomných pracovníků, servisní pracovníky nebo komukoli, kdo
potřebuje vstoupit do objektu na krátkou dobu, obvykle ne déle než na jeden den. Pojem „média“ označuje všechna papírová a elektronická média
obsahující data držitelů karet.
PCI DSS Požadavky
9.1 Používat odpovídající kontroly vstupu
do objektu za účelem omezení a
monitorování fyzického přístupu
k systémům v prostředí dat držitelů karet.
9.1.1 Používat videokamery a/nebo
jiné mechanismy kontroly přístupu
k monitorování individuálního fyzického
9.1 Ověřit existenci kontroly fyzické bezpečnosti pro každou
počítačovou místnost, datové centrum a další fyzické oblasti se
systémy v prostředí dat držitelů karet.
 Ověřit, zda je přístup kontrolován čtečkami visaček nebo
jinými zařízeními včetně autorizovaných visaček a
uzamykáním na klíč.
 Sledovat pokus správce systému přihlásit se na terminálech
pro náhodně vybrané systémy v prostředí držitelů karet a
ověřit, zda jsou „zamčené” a neumožňují neautorizované
použití.
9.1.1.a Ověřit, zda jsou používány videokamery a/nebo jiné
mechanismy kontroly přístupu k monitorování jednotlivých
fyzických přístupů do citlivých oblastí a odchodů z nich.
Vysvětlení
Bez kontrol fyzického přístupu, jako jsou systémy
visaček a kontroly dveří, by mohly neautorizované
osoby získat přístup do objektu a mohly by zcizit,
narušit nebo zničit kritické systémy a data držitelů
karet.
Uzamčením přihlašovacích obrazovek terminálů
zabraňuje neautorizovaným osobám získat přístup
k citlivým informacím, pozměnit systémové
konfigurace, zanést do sítě zranitelná místa nebo
zničit záznamy.
Při vyšetřování narušení fyzické bezpečnosti
mohou tyto kontroly pomoci při identifikaci osob,
které fyzicky vstoupily do citlivých oblastí, a také
strana85
Duben 2015
PCI DSS Požadavky
přístupu do citlivých oblastí. Revidovat
získaná data a korelovat je (najít
vztah) s dalšími vstupy. Ukládat
záznamy nejméně na tři měsíce, není-li
zákonem jinak omezeno.
9.1.1.b Ověřit, zda videokamery a/nebo mechanismy kontroly
přístupu jsou chráněny před manipulací nebo deaktivací.
kdy vstoupily nebo odešly.
9.1.1.c Ověřit, zda videokamery a/nebo kontrolní mechanismy
přístupu jsou přezkoumánya zda data z kamer nebo jiných
mechanismů jsou uložena nejméně na tři měsíce.
Příklady citlivých oblastí zahrnují místnosti
databázových serverů společnosti, prostory zázemí
(back office) v maloobchodě, kde jsou uchovávána
data držitelů karet, a prostory úložišť pro velké
objemy dat držitelů karet. Každá organizace by
měla identifikovat citlivé oblasti, aby zajistila
implementování odpovídajících kontrol fyzického
monitorování.
9.1.2Dotázat se odpovědných pracovníků, prověřit místa
přístupů k veřejně přístupným síťovým konektorům a ověřit, zda
jsou zavedeny fyzické a/nebo logické kontroly k omezení
přístupu k veřejně přístupným síťovým konektorům.
Omezení přístupu k síťovým konektorům (nebo
síťovým portům) znemožní útočníkům, aby se
připojili do snadno dostupných síťových konektorů
a získali přístup k interním síťovým zdrojům.
Poznámka: „Citlivá oblast” odkazuje na
jakékoliv datové centrum, serverovou
místnost nebo jakákoliv jinou oblast se
systémy, které uchovávají, zpracovávají
nebo přenášejí data držitelů karet.
Vyloučeny jsou oblasti pro styk s
veřejností (public-facing), kde jsou
přítomny pouze terminály prodejního
místa, jako například pokladny
v maloobchodě.
9.1.2 Implementovat fyzické a/nebo
logické kontroly a omezit přístup k
veřejně přístupným síťovým
konektorům.
Vysvětlení
Například, síťovékonektoryumístěnéve
veřejných
prostoráchaprostoráchpřístupnýchpro
návštěvníky by mohly být deaktivovány a
aktivovány pouze tehdy, je-lipřístup k
sítivýslovně autorizován. Alternativně,
procesyby měly být implementovány tak,
aby návštěvníci mohli vstoupit do oblastí
s aktivnímisíťovýmikonektory vždy pouze
s doprovodem.
Zločinci,snažící sezískatfyzický přístup kcitlivé
oblasti,sečasto pokoušejí deaktivovat
neboobejítmonitorovací kontroly. Chcete-li
ochránittyto kontroly před manipulací,
videokameryby mohlybýt umístěnytak, aby
bylymimo dosaha/nebo mohou býtmonitorovány,
aby byla zjištěna neoprávněná manipulace.
Podobněby mohlybýt mechanismy kontroly
přístupumonitoroványnebomítnainstalovánu
fyzickouochranu, aby se zabránilo
jejichpoškozenínebo deaktivaci zlovolnými jedinci.
Jsou-li použity logickénebofyzické kontroly,
nebokombinace obou, měly bybýtdostatečné k
tomu, aby zabránilyjednotlivci nebozařízení,
kteřínejsouvýslovně autorizováni, připojení k síti.
strana86
Duben 2015
PCI DSS Požadavky
Vysvětlení
9.1.3 Omezit fyzický přístup k bodům
bezdrátového přístupu, bránám
(gateways), ručním zařízením
(handheld devices), síťovému /
komunikačnímu hardwaru a
telekomunikačním linkám.
9.1.3 Zkontrolovat, zda fyzický přístup k bodům bezdrátového
přístupu, bránám, ručním zařízením, síťovému/komunikačnímu
hardwaru a telekomunikačním linkám je příslušně omezen.
Bez zabezpečení přístupu k bezdrátovým
komponentám a zařízením by zlovolní uživatelé
mohli využít neobsluhovaná bezdrátová zařízení
společnosti pro přístup k síťovým zdrojům nebo
dokonce připojit svá vlastní zařízení do bezdrátové
sítě a získat tak neautorizovaný přístup. Navíc,
zabezpečení síťového a komunikačního hardwaru
zabrání zlovolným uživatelům narušení sítové
komunikace nebo fyzického připojení vlastních
zařízením k drátovým síťovým zdrojům.
9.2 Vyvinout postupy ke snadnému
odlišení místních pracovníků a
návštěvníků, které zahrnují:
 Identifikaci pracovníků anávštěvníků
(například přiřazením visaček)
 Změny na požadavky přístupu
 Zrušení nebo ukončení identifikace
končících pracovníků a návštěvníků
s prošlou platností (jako jsou ID
visačky).
9.2.a Přezkoumat dokumentované procesy a ověřit, zda jsou
definovány procedury pro identifikaci a rozlišení mezi pracovníky
a návštěvníky.
Ověřovací procedury zahrnují následující body:
 Identifikace mezi pracovníky a návštěvníky (například
přiřazením visaček),
 Změna přístupových požadavků a
 Zrušení identifikace končících pracovníků a návštěvníků
s prošlou platností (jako jsou ID visačky).
Identifikací autorizovaných návštěvníků, aby byli
snadno odlišitelní od pracovníků, zabraňuje
neautorizovaným návštěvníkům v povolení přístupu
do oblastí obsahující data držitelů karet.
9.2.bZkontrolovat používané identifikační metody (jako je systém
visaček) a sledovat procesy pro identifikaciarozlišovánímezi
pracovníky anávštěvníky a ověřit, zda:
 Návštěvníci jsoujasněoznačeni, a
 Je snadnérozlišitmezi pracovníky anávštěvníky.
9.2.c Ověřit, zda přístup k identifikačnímu procesu (jako je systém
visaček) je omezen na autorizované pracovníky.
9.3Kontrolovat fyzický přístup pracovníků
kcitlivým oblastem podle následujících
bodů:
 Přístupmusí být autorizován azaložen
nafunkcijednotlivýchúloh.
 Přístup jezrušenihned po
ukončeníavšechny
mechanismyfyzického přístupu, jako
9.3.aU vzorku pracovníků sfyzickým přístupem do citlivých
oblastí, dotázat seodpovědnýchpracovníků, prověřitseznamy pro
řízení přístupu a ověřit, zda:
 Přístup do citlivých oblastí je povolen.
 Je vyžadováno přístupprofunkcejednotlivých úloh.
9.3.bSledovatpřístup pracovníků do citlivých oblastí a ověřit, zda
všichni pracovníci jsou autorizováni před tím, než je jim udělen
přístup.
Kontrolafyzickéhopřístupu do citlivých oblastí
pomáhá zajistit, aby byl udělen přístup pouze
autorizovaným pracovníkům slegitimní
provoznípotřebou.
Pokud pracovníci opustíorganizaciměly by býtpři
jejichodchodu okamžitě(co nejdříve) vrácenynebo
zakázány všechnyfyzicképřístupovémechanismy,
aby bylo pracovníkům zabráněno v
strana87
Duben 2015
PCI DSS Požadavky
jsouklíče, přístupové karty, atd., jsou
vrácenynebo deaktivovány.
9.4Zavést procedury pro identifikaci a
autorizaci návštěvníků.
Vysvětlení
9.3.c
Vybratvzoreknedávnoukončenýchzaměstnancůapřezkoumatsezn
amy kontroly přístupu a ověřit, zda pracovnícinemajífyzický
přístup do citlivých oblastí.
získánífyzického přístupu do citlivých oblastí poté,
co jejichzaměstnání skončilo.
9.4Ověřte, zda autorizace návštěvníků a kontroly přístupu jsou
zavedeny následovně:
Kontrolynávštěvníkůjsou důležitépro
sníženíschopnostinepovolanýchazlovolných
jednotlivcůzískat přístupdo objektu(a
potenciálněkdatům držitelů karet).
Procedury by měly zahrnovat
9.4.1 Návštěvníci jsoupřed vstupem
autorizováni, a jsou stále
doprovázenivprostorách, kde jsou
zpracovávána nebouchoovávánadata
držitelů karet.
9.4.1.aSledovatprocedury, dotázat se pracovníků aověřit, zda
návštěvníci musí být autorizováni dříve, nežje jim
povolenpřístup, a jsou stále doprovázenivprostorách, kde jsou
zpracovávána nebouchovávánadata držitelů karet.
Kontrolynávštěvníkůzajišťují, že návštěvníci
jsouidentifikovatelníjako návštěvníci, takže
pracovníci mohousledovatjejich činnost, aže
jejichpřístupjeomezenjen nadobu
trváníjejichlegitimnínávštěvy.
9.4.2Návštěvníci jsouidentifikováni a
jsou jim vydány visačkynebojiné
označení, které má dobu platnosti
aviditelně je odlišuje od místních
pracovníků.
9.4.1.bSledovat použitívisaček návštěvníkůnebojiného označení
a ověřit, zda fyzický token neumožňujebez doprovodupřístup do
fyzických prostor, kde jsou zpracovávána nebouchovávánadata
držitelů karet.
Zajištěním vrácení visaček návštěvníkůpouplynutí
doby platnosti
neboukončenínávštěvyzabraňujezlovolným
jednotlivcům použít dříve autorizované
průkazyzískatfyzický přístupdo budovypoté, co
jejich návštěvaskončila.
9.4.2.a Sledovatlidiv objektu a ověřit používání visaček
návštěvníkůnebojiného označení, azdajsounávštěvníci
snadnoodlišitelní od pracovníků.
9.4.2.b Ověřit, zda visačkám návštěvníkůnebo
jinýmidentifikacím skončí platnost.
9.4.3 Návštěvnícijsou požádáni, aby
odevzdali visačkyneboidentifikacipřed
opuštěnímobjektuneboke dni ukončení
jejich platnosti.
9.4.3Prověřitnávštěvníkyopouštějícíobjekt a ověřit, zda jsou
požádáni, aby při odchodu nebo ukončení platnosti odevzdali
svévisačkynebo jinou identifikaci.
9.4.4 Udržovat záznam o vstupu (log)
návštěvníků do objektu, místností s
počítači a datových center, kde jsou
zpracovávána nebouchovávánadata
držitelů karet.
9.4.4.aOvěřit, zda se záznam o vstupu návštěvníka používá k
záznamu fyzického přístupu návštěvníka do objektu i do
místností s počítači a datových center, kde jsou uchovávána
nebo přenášena data držitelů karet.
V záznamu o vstupu (logu)
dokumentovat jméno návštěvníka,
firmu, kterou reprezentuje a místního
pracovníka autorizujícího fyzický
Protokol o návštěvnících
(log),dokumentujícíminimum
informacíonávštěvníkovi, se jednoduše a levně
udržuje amůže napomoci při identifikacifyzického
přístupudo budovynebo místnosti,
apotenciálníhopřístupuk datům držitelů karet.
9.4.4.b Ověřit, zda záznam obsahuje:
 jméno návštěvníka,
 firmu
 pracovníka autorizujícího fyzický přístup.
strana88
Duben 2015
PCI DSS Požadavky
přístup.
Tento záznamu o vstupu (log) uchovat
nejméně po tři měsíce, pokud zákon
nestanovuje jinak.
9.5 Fyzicky zabezpečit všechna média.
9.5.1 Zálohovaná média ukládat na
bezpečném místě, pokud možno mimo
objekt, jako například v náhradním
nebo záložním místě nebo
v komerčním objektu pro ukládání.
Bezpečnost umístění revidovat
nejméně jednou ročně.
9.6 Pro jakékoli druhy médií udržovat
přísnou kontrolu vnitřní i vnější
distribuce, včetně následujících
požadavků:
9.6.1 Klasifikovat média tak, aby mohla
být identifikována citlivost dat.
Vysvětlení
9.4.4.c Ověřit, zda je záznam uchováván nejméně po tři
měsíce.
9.5 Ověřit, zda procedury pro ochranu dat držitelů karet zahrnují
kontrolu fyzického zabezpečení všech médií (včetně, nikoliv
výlučně, například počítačů, výměnných elektronických médií,
papírových stvrzenek, papírových sestav a faxů).
Kontroly fyzického zabezpečení médií mají zabránit
neautorizovaným osobám v získání přístupu k
datům držitelů karet na každém typu média. Data
držitelů karet jsou náchylná k neoprávněnému
zobrazení, kopírování nebo naskenování, pokud
nejsou chráněna po celou dobu, kdy jsou na
přenosných médiích, vytištěna nebo ponechána na
něčím pracovním stole.
9.5.1.a Sledovat fyzickou bezpečnost místa ukládání k
potvrzení, zda je ukládání záložních médií bezpečné.
Jestliže jsou záložní kopie, které obsahují data
držitelů karet, uchovávány v nezabezpečeném
objektu, mohou se snadno ztratit, být odcizeny
nebo zkopírovány k podvodným účelům.
9.5.1.b Ověřit, zda je bezpečnost místa pro ukládání
přezkoumána nejméně jednou ročně.
Pravidelné přezkoumání objektu pro ukládání
umožňujeorganizaciřešit
identifikovanébezpečnostní problémy včas, a
minimalizovat tak potenciální riziko.
9.6 Ověřit, zda existují politiky pro kontrolu distribuce médií a tyto
politiky pokrývají všechna distribuovaná média včetně těch, která
jsou distribuována jednotlivcům.
9.6.1 Ověřit, zda všechna média jsou klasifikována tak, aby
mohla být identifikována citlivost dat.
Procedury a procesy napomáhají k ochraně médií
s daty držitelů karet, která jsou distribuována
vnitřním a/nebo externím uživatelům. Bez takových
postupů se mohou data ztratit nebo mohou být
ukradena a využita k podvodným účelům.
Je důležité, aby média byla identifikována a jejich
klasifikace byla snadno rozeznatelná. Média, která
nejsou identifikována jako důvěrná, nemusí být
adekvátně chráněna nebo se mohou ztratit nebo
být zcizena.
Poznámka:Toneznamená, žemédiamusí
mítpřipojenštítek "Důvěrné"; záměrem je, aby
organizace identifikovalamédia, kteráobsahují
citlivéúdaje,takže je lzechránit.
strana89
Duben 2015
PCI DSS Požadavky
Vysvětlení
9.6.2 Zasílat média bezpečným
kurýrem nebo jinou zasílací metodou,
která může být přesně sledována.
9.6.2.a Dotázat se pracovníků, zkontrolovat záznamy a ověřit,
zda všechna média zaslaná mimo objekt jsou evidována a
odeslána bezpečným kurýrem nebo jinou zasílací metodou,
která může být sledována.
Média mohou být ztracena nebo ukradena, jestliže
jsou zaslána způsobem, kdy není možné sledovat,
například běžnou poštou. Pro doručení jakéhokoli
média, které obsahuje data držitelů karet,
používejte služby bezpečného kurýra, abyste mohli
využít jeho systémy sledování k udržování
přehledu o pohybu zásilky.
9.6.2.bVybrat ze sledovacích protokolů čerstvý vzorek ze
všechmédií za několik dnů zásilek zaslaných mimo objekt
aověřit, zda podrobnosti o sledováníjsou dokumentovány.
9.6.3 Zajistit, aby management schválil
všechna média, která jsou přesouvána
mimo bezpečnou oblast (včetně médií
distribuovaných jednotlivcům).
9.7 Udržovat přísnou kontrolu nad
ukládáním a dostupností médií.
9.7.1 Správně udržovat inventarizační
záznamy všech médií a provádět
inventarizaci médií nejméně jednou
ročně.
9.8 Zničit média, když jich již není
zapotřebí z provozních ani právních
důvodů, dle následujících kroků.
9.6.3Vybrat ze sledovacích protokolů čerstvý vzorek ze
všechmédií za několik dnů zásilek zaslaných mimo objekt. Z
kontroly protokolů a dotázání se odpovědných pracovníků
ověřit, zda je získána správná autorizace managementem,
kdykoli jsou média přesouvána mimo bezpečnou oblast (včetně
médií distribuovaných jednotlivcům).
9.7Získat a zkontrolovat politiku pro kontrolu ukládání a údržby
kopií všech médií a ověřit, zda politika vyžaduje periodickou
inventarizaci médií.
9.7.1Přezkoumat inventarizační záznamy médií a zkontrolovat,
že periodická inventarizace médií je prováděna nejméně jednou
ročně.
9.8 Zkontrolovat politiku periodické likvidace médií a ověřit, zda
pokrývá všechna média a definuje požadavky dle následujících
kroků:
 Papírové kopiemateriálů musíbýt rozřezány na kousky,
spálenyneborozdrcenytak, že lze důvodně předpokládat,že
kopie materiálůnelzerekonstruovat.
 Skladovacíkontejnery používané promateriály, které majíbýt
zničeny, musí být zabezpečeny.
 Data držitelů karetna elektronickýchmédiích musí být učiněny
nezrekonstruovatelné (např. prostřednictvím bezpečného
mazacího programuv souladu se standardemuznávaným v
odvětví probezpečné mazání nebo fyzickým zničením média).
Bez pevně stanoveného firemního
procesuzajišťujícího, aby všechny pohyby médií
byly schválenypřed tím, než je médium přesunuto
mimo bezpečnou oblast, média nebudou
sledovánanebovhodněchráněna, ajejich umístění
nebude známé, což povedeke ztrátěnebo
odcizenímédia.
Bez pečlivých inventarizačních metod a kontrol
ukládání by se mohlo stát, že ztracená nebo
ukradená média nebudou zjištěna po neomezenou
dobu.
Pokud nejsou média inventarizována, pak
ukradená nebo ztracená média nemusí být zjištěna
po dlouhou dobu nebo vůbec.
Nejsou-li učiněny kroky ke zničení informací
obsažených na pevných discích, přenosných
jednotkách, na CD/DVD nebo na papíře před jejich
odstraněním, zlovolní jedinci mohou z vyhozených
médií získat informace, které povedou ke
kompromitování dat. Například zlovolní jedinci
mohou použít techniku známou jako „prohlížení
popelnic“ („dumpster diving“), kdy prohledávají
odpadkové koše a popelnice a vyhledávají
informace, které mohou použít k zahájení útoku.
Zajištěnímskladovacíchkontejnerů, používaných
promateriály, kterése mají zničit, se
strana90
Duben 2015
PCI DSS Požadavky
9.8.1 Rozřezat, spálit nebo rozdrtit
fyzické kopie materiálů tak, aby data
držitelů karet nemohla být
zrekonstruována.
9.8.1.a Dotázat se pracovníků a zkontrolovat procedury a ověřit,
zda papírové kopie jsou rozřezány na kousky,
spálenyneborozdrceny tak, že lze důvodně předpokládat, že
kopie materiálůnelzerekonstruovat.
Zabezpečit skladovacíkontejnery
používané pro materiály, které mají být
zničeny.
9.8.1.b Zkontrolovat skladovací kontejnery používané pro
materiály, které obsahují informace určené ke zničení a ověřit,
zda jsou kontejnery zabezpečeny.
9.8.2 Učinit data držitelů karet na
elektronických médiích
neobnovitelnými tak, aby data držitelů
karet nemohla být zrekonstruována.
9.8.2 Ověřit, zda data držitelů karet na elektronických médiích
jsou učiněna neobnovitelnými (např. prostřednictvím
bezpečného mazacího programu v souladu se
standardemuznávaným v odvětví probezpečné mazání nebo
jiným fyzickým zničením média).
9.9 Chránitzařízení, která snímají data
platebníchkaret prostřednictvím
příméfyzické interakceskartou, před
manipulacíasubstitucí (nahrazením).
9.9 Zkontrolovat dokumentované politiky a procedury a ověřit,
zda zahrnují:
 Udržováníseznamuzařízení.
 Provádět pravidelněprohlídku zařízení a prozkoumat, zda s
ním nebylo manipulovánonebo nebylo nahrazeno.
 Školenípracovníků, aby si byli vědomipodezřelého chovánía
nahlásilinedovolenou manipulacinebo náhraduzařízení.
Poznámka: Tyto požadavky se
vztahujínačtecí
zařízeníkaretpoužívaných přitransakcích
za přítomnosti karet(to znamená, že
karta je protažena nebo vložena) v místě
prodeje. Tento požadavekneníurčen k
aplikaci pro zařízení, které využívá
manualní vkládání dat jako jsou
počítačové klávesnicea POSklávesnice.
Poznámka: Požadavek9.9je pokládán za
osvědčený postup do 30. června2015, po
tomto datu se stávápožadavkem.
Vysvětlení
zabraňujezmocnění se citlivých informací, při sběru
vlastních materiálů. Například, kontejnery s
materiálem určeným k rozdrcení by měly mít
zámek, aby se zabránilo přístupu k jeho obsahu
nebo fyzickou zábranu,
zabraňujícípřístupukobsahu kontejneru.
Příklady metod pro bezpečné zničení
elektronických medií zahrnují bezpečné smazání,
demagnetizaci nebo fyzické zničení (jako je
rozemletí nebo rozdrcení pevných disků).
Zločincise pokoušejíukrástdata držitelů karet
krádeží a/nebomanipulací sečtecím
zařízenímkaretaterminálů. Například se budou
snažitukrástzařízení,aby se mohli naučit, jak do něj
proniknout, ačasto se
snažínahraditlegitimnízařízení zařízením
podvodným, které jimposíláinformace
oplatebníkartěpokaždé, kdyžje karta vložena.
Zločincise také snažípřipojit komponenty pro
"skimming" zvnějškuzařízení, které jsou určeny
kzachycení údajů z platební kartyještě před tím,
než je karta vložena do zařízení. Například
připojenímdodatečné čtečky karet nad
legitimníčtečku karettak, aby údaje platebních karet
byly zachycenydvakrát: jednou komponentou
zločinceapaklegitimní komponentou zařízení.Tímto
způsobem transakcemůžebýt dokončenabez
přerušení, zatímco zločinecsiběhem
procesu"naskimuje" (načte) údaje oplatebníkartě.
Tento požadavekse doporučuje, alenení
vyžadován pro zařízení, které využívá manuální
vkládání dat, jako jsou počítačové klávesnice a
POS klávesnice.
Dalšíosvědčené postupy vprevenciskimmingujsou
k dispozici nainternetových stránkáchPCISSC.
strana91
Duben 2015
PCI DSS Požadavky
9.9.1Udržovat aktuální seznam
zařízení. Seznam by měl
zahrnovatnásledující body:
 Značku a modelzařízení
 Umístěnízařízení(např.
adresamístaneboobjektu, kdese
zařízení nachází)
 Sériové číslozařízení nebo jiný
způsobunikátníidentifikace.
9.9.1.a Zkontrolovat seznamzařízení a ověřit, zda obsahuje:
 Značku amodelzařízení
 Umístěnízařízení(např. adresamístanebo objektu, kdese
zařízení nachází)
 Sériové číslozařízení nebo jiný způsobunikátníidentifikace.
9.9.1.b Vybratvzorekzařízeníze seznamua sledovat zařízení
aumístěnízařízenía ověřit, zda je seznampřesný aaktuální.
9.9.1.cDotázat se pracovníků aověřit, zda je seznam
zařízeníaktuální, kdyžjsou zařízenípřidána, přemístěna,
vyřazena z provozu, atd.
9.9.2 Pravidelně
kontrolovatpovrchyzařízení a detekovat
neoprávněnou manipulaci(např.
přidánískimmeru-nelegální čtečky
9.9.2.aZkontrolovatdokumentovanéprocedury a ověřit, zda
procesyjsou definovány tak, aby obsahovaly následující body:
 Procedurypro provedení prohlídky zařízení
 Frekvenci kontrol.
Vysvětlení
Vedení aktuálního seznamu zařízení napomáhá
organizacisledovat, kde by se zařízenímělo
nacházeta rychleurčit, zdazařízeníchybí nebo
jeztraceno.
Způsob udržování seznamuzařízení může být
automatizováno(například systémempro
správuzařízení) nebo manuálně (například
dokumentace pomocí
elektronickýchnebopapírových záznamů). Pro
putovní zařízení (“na cestě”)můžeme namísto
umístění uvést jména pracovníků, jimž byla
zařízenípřidělena.
Pravidelnéprohlídkyzařízení
napomohouorganizacímrychlejidetekovatneoprávn
ěnou manipulaci nebovýměnuzařízení, a
tímminimalizovatpotenciální
strana92
Duben 2015
PCI DSS Požadavky
karetdozařízení) nebovýměnu(např.
kontrolousériového číslanebojiné
vlastnostizařízeníověřit, zda zařízení
nebylovyměněno zapodvodnézařízení).
Poznámka: Příkladypříznaků, které
naznačují, že se zařízenímmohlo
býtmanipulovánonebo bylo nahrazeno,
jsou neočekávanépřílepky
nebokabelyzapojené dozařízení,
chybějící
nebozměněnébezpečnostníštítky,
zlomenénebo jinak barevné krytynebo
změny v sériovém čísle zařízenínebojiné
vnějšíznaky.
9.9.2.bDotázat seodpovědnýchpracovníků,sledovatpostupy
prohlídek a ověřit:
 Pracovníci si jsou vědomipostupů pro prohlídkyzařízení.
 Všechna zařízeníjsoupravidelně prohlížena a jsou hledány
důkazy omanipulaciasubstituci (nahrazení).
Vysvětlení
dopadpoužívánípodvodnýchzařízení.
Typ prohlídkybudoue záviset nazařízení, například
fotografie zařízení, okterémje známo, žeje
bezpečné,mohou být použity pro srovnání
aktuálního vzhledupřístrojesjeho původním
vzhledem, aby se zjistilo, zdase vzhled změnil.
Další možnostímůžebýt
použitíbezpečnéhopopisovače, jako jeznačkovač
viditelný pod UV zářením, k
označenípovrchůzařízeníaotvorů vzařízení, takže
jakákolivneoprávněná manipulacenebo
výměnabudezřejmá.
Zločincičastonahradívnějšíkrytzařízení, aby skryli
manipulaci, atyto metodymohou
napomociodhalittakovéto činnosti.
Dodavatelézařízenímohoubýttakéschopni
poskytnoutbezpečnostnípokyny a návody, jak
napomoci rozhodnutí, zda bylo se
zařízenímmanipulováno.
Četnost prohlídekbude záviset na faktorech, jako je
umístěnízařízeníazda je zařízení obsluhováno
nebobez dozoru. Napříkladzařízení, ponechaná ve
veřejných
prostoráchbezdohledupracovníkůorganizace,moho
umítčastějšíprohlídky než zařízení, kterájsou
umístěna vzabezpečenýchoblastech nebo jsou-li
přístupnéveřejnosti pod dohledem. Typ
ačetnostprohlídek bude určenaobchodníkem, jak
jsou definovány v ročnímprocesu analýze rizik.
strana93
Duben 2015
PCI DSS Požadavky
Vysvětlení
9.9.3Zajistit školenípropracovníky, aby
si byli vědomipokusů omanipulaci se
zařízením nebo jejich výměně.
Školeníby mělozahrnovatnásledující
body:
9.9.3.aPrověřit školící materiály pro pracovníky v místě prodeje a
ověřit, zda jsou školení v následujících bodech:
 Ověřitidentitujakýchkoli osobtřetí strany, kteří tvrdí, že jsou
pracovníci opravy nebo údržby, před udělením přístupuk
provedení opravyneboúdržbyzařízení.
Zločinci se často představují jako pracovníci
pověření údržbou za účelem získání přístupu k
POS zařízením. Všechny třetí strany, požadující
přístup k zařízením, by měly být vždy ověřeny před
umožněním přístupu - například kontrolou u vedení
nebo telefonicky ověřit se společností zajišťující
údržbu POS zařízení (například dodavatel nebo
acquirer). Mnozí zločinci se budou snažit oklamat
pracovníky oblečením pro svou roli (např. nošením
boxu s nářadím a pracovním oblečením), a mohou
být také dobře informováni o umístění zařízení,
takže je důležité, aby pracovníci byli vyškoleni a
vždy se chovali v souladu s procedurami.
 Ověřitidentitujakýchkoli osobtřetí
strany, kteří tvrdí, že jsou
pracovníci opravy nebo údržby,
před udělením přístupuk
provedení
opravyneboúdržbyzařízení.
 Neinstalovat, nevyměňovat ani
nevracetzařízeníbezověření.
 Být si vědom
podezřeléhochováníkolemzařízení
(např. pokusyneznámýchosob o
odpojenínebootevřenízařízení).
 Hlásit podezřeléchovánía
známkymanipulace se zařízením
nebo jeho výměnu (substituci)
příslušnýmpracovníkům(například
manažerovinebobezpečnostnímu
pracovníkovi).
 Být si vědom podezřeléhochováníkolemzařízení(např.
pokusyneznámýchosob o odpojenínebootevřenízařízení).
 Hlásit podezřeléchovánía známkymanipulace se zařízením
nebo jeho výměnu příslušnýmpracovníkům(například
manažerovinebobezpečnostnímu pracovníkovi).
9.9.3.bDotázat se vzorkupracovníků v místě prodeje a ověřit,
zda absolvovali školení a jsou si vědomi procedurpronásledující
body:
 Ověřeníidentityjakýchkoliosob třetích stran, kteří tvrdí, že
jsou pracovníci opravy nebo údržby,před udělením
přístupuk provedení změnneboúdržbyzařízení.
 Být si vědom podezřeléhochováníkolemzařízení(např.
pokusyneznámýchosob o odpojenínebootevřenízařízení).
Dalším trikem, kteří zločinci rádi používají, je
zaslání "nového" systému POS s pokynem jej
zaměnit za legitimní systém a "vrácení" legitimního
systému na zadanou adresu. Zločinci mohou
dokonce poskytnout zpáteční poštovné, protože by
velice rádi dostali do svých rukou tato zařízení.
Pracovníci vždy musí ověřit u svého manažera
nebo dodavatele, že zařízení je legitimní a pochází
z důvěryhodného zdroje, a to ještě před instalací
nebo jeho použitím v provozu.
 Hlásit podezřeléchovánía známkymanipulace se zařízením
nebo jeho výměnu příslušnýmpracovníkům(například
manažerovinebobezpečnostnímu pracovníkovi).
9.10Zajistěte, aby bezpečnostní politiky
aprovozní procedury
proomezenífyzického přístupuk datům
držitelů karetbyly
zda jsou bezpečnostní politiky aprovozní postupy
proomezenífyzického přístupuk datům držitelů karet:
 dokumentovány,
Pracovnícisi musí být průběžné
vědomibezpečnostních politikaprovozních
postupůproomezenífyzického přístupuk datům
držitelů karetasystémům v prostředí datům držitelů
karet.
strana94
Duben 2015
Pravidelné monitorování a testování sítí
Požadavek 10: Sledovat a monitorovat všechny přístupy k síťovým zdrojům a datům držitelů karet
Logovací mechanismy a schopnost sledovat uživatelské aktivity jsou kritické pro prevenci, odhalování nebo minimalizaci dopadu narušení
(kompromitaci) dat. Přítomnost záznamů ve všech prostředích umožňuje důkladné sledování, varování a analýzu, pokud nastanou potíže. Bez
záznamů aktivity v systému je odhalení příčiny narušení velmi obtížné.
PCI DSS Požadavky
10.1Implementovat auditní záznamy pro
spojení všech přístupů k systémovým
komponentám s jednotlivými
individuálními uživateli.
10.1Ověřit pozorováním a dotázat se správce systému
(administrátora), zda:
10.2 Implementovat automatizované
auditní záznamy pro všechny systémové
komponenty pro rekonstrukci
následujících událostí:
10.2Prostřednictvím pohovorů s odpovědnými pracovníky,
prověřením auditních záznamů a zkontrolováním nastavení
auditních záznamů provést následující kroky:
10.2.1 Všechny individuální přístupy
uživatele k datům držitelů karet
 Auditní záznamy jsou spuštěny a aktivovány pro systémové
komponenty.
 Přístup k systémovým komponentám je spojenys jednotlivými
uživateli.
10.2.1 Ověřit, zda všechny individuální přístupy k datům držitelů
karet jsou zaznamenány.
Vysvětlení
Má rozhodující význam, abychom měli zavedený
proces nebo systém, který spojuje přístup
uživatele snavštívenými komponentami systému.
Tento systém generuje auditní protokoly a
poskytuje možnost zpětně vysledovat podezřelou
aktivitu až ke konkrétnímu uživateli.
Generování auditních záznamů podezřelých
aktivit varuje administrátora systému, odešle data
do jiných monitorovacích mechanismů (například
do systémů detekce průniku) a poskytne protokol
historie k následnému sledování po případném
incidentu. Odpojení od následujících událostí
umožní organizaci identifikovat a vysledovat
potenciální zákeřné činnosti.
Zlovolní jedinci mohou získat znalosti o
uživatelském účtu s přístupem do systému v
prostředí dat držitelů karet, nebo mohou vytvořit
nový neautorizovaný účet, aby měli přístup k
datům držitelům karet. Záznam o všech
jednotlivých přístupech k datům držitelů karet
může identifikovat účet, který byl kompromitován
nebo zneužit.
strana95
Duben 2015
PCI DSS Požadavky
Vysvětlení
10.2.2 Všechny akce jednotlivců
provedené s kořenovými nebo
administrativními privilegii
10.2.2 Ověřit, zda všechny akce podniknuté libovolným
jednotlivcem s kořenovými nebo administrativními privilegii jsou
zaznamenávány.
Účty se zvýšenými privilegii, jako je
„administrátorský“ nebo „kořenový” účet, mají
zvýšený potenciál dopadu na bezpečnost nebo
operační funkčnost systému. Bez záznamu o
provedených činnostech není organizace schopna
vysledovat důsledek plynoucí z administrativní
chyby nebo zneužití oprávnění zpět ke specifické
akci nebo jednotlivci.
10.2.3 Přístup ke všem auditním
záznamům
10.2.3 Ověřit, zda přístup ke všem auditním záznamům je
zaznamenán.
Zlovolní uživatelé se často pokoušejí změnit
auditní záznamy k zakrytí svých akcí. Záznam o
přístupech umožňuje organizaci vysledovat
všechny nekonzistence nebo potenciální
ovlivňování auditních záznamů až na individuální
účet. Zpřístupnění protokolůidentifikujícíchzměny,
dodatkyaodstraněnímůžepomocivystopovatkrokyp
rovedenéneoprávněnou osobou.
10.2.4 Neplatné pokusy o logický
přístup
10.2.4 Ověřit, zda jsou zaznamenávány neplatné pokusy o
logický přístup.
Zlovolní uživatelé se budou v síti často pokoušet o
opakovaný přístup do cílových systémů. Násobné
neplatné pokusy o login (přístup) může indikovat
pokusy neautorizovaného uživatele o „brutální
sílu“ nebo uhádnutí hesla.
10.2.5Použitíazměny identifikačních a
autentizačních mechanismů – mimo
jiné vytváření novýchúčtůa zvyšování
privilegií - a všechny změny,
doplněnínebovymazáníúčtůskořenový
mineboadministrativnímiprivilegii
10.2.5.aOvěřit, zda je zaznamenáváno použití mechanismů
identifikace a autentizace.
Bez znalosti toho, kdo byl přihlášen v době
incidentu, není možné identifikovat účet, který
k tomu mohl být použit. Dále se zákeřní uživatelé
mohou pokusit zmanipulovat autentizační kontroly
s úmyslem je obejít nebo platný účet učinit
anonymním.
10.2.6 Inicializace, vypnutí nebo
pozastavení auditních záznamů
10.2.6 Ověřit, zda jsou zaznamenávány následující body:
10.2.5.b Ověřit, zda jsou zaznamenávána všechna zvýšení
privilegií.
10.2.5.c Ověřit, zda jsou zaznamenávány všechny změny,
doplněnínebovymazání
jakýchkoliúčtůskořenovýmineboadministrativnímiprivilegii.
 Inicializace auditních záznamů
 Vypnutí nebo pozastavení auditních záznamů.
Společným postupem zákeřných uživatelů je
vypnutí (nebo pozastavení) auditních záznamů
před provedením nelegálních činností, aby se
vyhnuli odhalení. Inicializace auditních záznamů
může indikovat, že záznamová funkce byla
uživatelem vypnuta k utajení jejich akcí.
strana96
Duben 2015
PCI DSS Požadavky
Vysvětlení
10.2.7 Vytvoření a mazání objektů na
systémové úrovni
10.2.7 Ověřit, zda je zaznamenáváno vytváření a mazání objektů
na systémové úrovni.
Zákeřný software, jako je malware, často vytváří
nebo nahrazuje objekty na systémové úrovni na
cílovém systému, aby mohl řídit určitou funkci
nebo operaci v systému. Pokud jsou vytvářeny
(auditní) záznamy při vytvářeníneboodstraňování
objektůna úrovni systému, jako
jsoudatabázovétabulky nebouložené procedury,
bude snadnějšíurčit, zdatakovéto změny byly
schváleny.
10.3 Zaznamenat alespoň následující
položky auditních záznamů pro všechny
systémové komponenty za každou
událost:
10.3 Pomocí pohovorů a sledováním auditních záznamů pro
každou auditovatelnou událost (od Požadavku 10.2) provést
následující:
10.3.1 Identifikace uživatele
10.3.1 Ověřit, zda je identifikace uživatele zahrnuta v položkách
záznamů.
10.3.2 Typ události
10.3.2 Ověřit, zda je typ události zahrnut v položkách záznamů.
10.3.3 Datum a čas
10.3.3 Ověřit, zda datum a časové razítko jsou zahrnuty v
položkách záznamů.
10.3.4 Indikace úspěchu nebo selhání
10.3.4 Ověřit, zda indikace úspěchu nebo selhání je zahrnuta v
položkách záznamů.
10.3.5 Původ události
10.3.5 Ověřit, zda původ události je zahrnut v položkách
záznamů.
10.3.6 Identita nebo název dotčených
dat, systémové komponenty nebo
zdroje.
10.3.6 Ověřit, zda identita nebo název dotčených dat, systémové
komponenty nebo zdroje jsou zahrnuty v položkách záznamů.
Zaznamenáním těchto údajů o auditovatelných
událostech podle Požadavku 10.2 může být
případný průnik rychle identifikován i
s dostatečnými podrobnostmi, abychom věděli,
kdo, co, kde a jak se stalo.
strana97
Duben 2015
PCI DSS Požadavky
10.4 S použitímtechnologie časové
synchronizace, synchronizovat všechny
hodiny a časy kritických systémů a
zajistit, aby následující kroky byly
implementovány pro získání, distribuci a
ukládání času.
10.4 Zkontrolovat standardy konfigurací a procesů a ověřit, zda je
implementována a aktualizována technologie časové
synchronizace podle PCI DSS Požadavků 6.1 a 6.2.
Poznámka: Jedním z příkladů
technologie časové synchronizace je
Protokol síťového času (Network Time
Protocol, NTP).
10.4.1 Kritické systémy mají správný a
shodný čas.
Vysvětlení
Časová synchronizační technologie se používá
pro synchronizování hodin na více systémech.
Nesprávnou synchronizací hodin může být složité
až nemožné porovnávat auditní záznamy (logy)
z různých systémů a určit přesnou posloupnost
událostí (což je základem pro forenzní analýzu
v případě narušení). Pro forenzní týmy prošetřující
incident je přesnost a konzistentnost času napříč
všemi systémy a čas každé činnosti rozhodující
pro určení, jak byly systémy kompromitovány.
10.4.1.a Zkontrolovat proces pro přijímání, distribuci a
uchovávání správného času v rámci organizace a ověřit, zda:

Pouze označený centrální časový server (servery) přijímá
časové signály z externích zdrojů, a časové signály
z externích zdrojů vycházejí z atomových hodin nebo UTC
(Coordinated Universal Time).

Pokud se vyskytuje více než jeden určený časový server, pak
servery spolupracují jeden s druhým, aby zachovaly přesný
čas.

Systémy přijímají časové informace pouze z určených
centrálních časových serverů.
10.4.1.b Prověřit nastavení časových systémových parametrů u
vzorku systémových komponent a ověřit, zda:
10.4.2Časové údaje jsou chráněny.

Pouze označený centrální časový server (servery) přijímá
časové signály z externích zdrojů, a časové signály
z externích zdrojů vycházejí z atomových hodin nebo UTC.

Pokud se vyskytuje více než jeden určený časový server, pak
určený centrální časový server (servery) spoluprace jeden s
druhým, aby zachovaly přesný čas.

Systémy přijímají časové informace pouze z určených
centrálních časových serverů.
10.4.2.a Zkontrolovat systémové konfigurace a nastavení
časové synchronizace a ověřit, zda přístup k časovým údajům je
omezen pouze na pracovníky s provozní potřebou přístupu k
časovým údajům.
strana98
Duben 2015
PCI DSS Požadavky
Vysvětlení
10.4.2.b Zkontrolovat systémové konfigurace, nastavení časové
synchronizace a záznamů, a procesy a ověřit, zda jsou jakékoli
změny nastavení času na kritických systémech logovány,
monitorovány a prověřovány.
10.4.3 Nastavení času jsou přijímána
z časových zdrojů akceptovatelných
v odvětví.
10.5 Zabezpečit auditní záznamy tak,
aby nemohly být měněny.
10.4.3 Zkontrolovat systémové konfigurace a ověřit, zda časový
server (servery) přijímá aktualizace ze zvláštních odvětvím
akceptovatelných externích zdrojů (pro zabránění zlomyslné
změny času). Tyto změny mohou být volitelně šifrovány
symetrickým klíčem, a mohou být vytvořeny kontrolní seznamy
specifikující IP adresy klientských počítačů pro kontrolu při
aktualizaci času (pro zabránění neautorizovaného použití
interních časových serverů).
10.5 Dotázat se systémových administrátorů, zkontrolovat
systémové konfigurace a povolení, a ověřit, zda auditní záznamy
jsou zabezpečené, aby nemohly být změněny, a to následovně:
Podvodník, který pronikl do sítě, se často pokusí
editovat auditní protokol, aby skryl svou aktivitu.
Bez adekvátní ochrany auditních protokolů nelze
zaručit jejich úplnost, přesnost a integritu a auditní
protokoly mohou být jako nástroj vyšetřování bez
užitku.
10.5.1 Omezit prohlížení auditních
záznamů na ty, kteří to potřebují ke své
práci.
10.5.1 Prohlížet soubory s auditními záznamy mohou pouze ti,
kdo je potřebují ke své práci.
10.5.2 Chránit soubory auditních
záznamů před neautorizovanými
modifikacemi.
10.5.2 Aktuální soubory auditních záznamů jsou chráněny před
neautorizovanými modifikacemi mechanismy kontroly přístupu,
fyzickým oddělením a/nebo oddělením sítí.
Adekvátní ochrana auditních protokolů zahrnuje
silnou kontrolu přístupu (omezuje přístup k
protokolům jen na osoby, které je potřebují znát,
pravidlo “need to know”) a použití fyzického nebo
síťového oddělení, aby se daly protokoly hůře
najít a změnit).
10.5.3 Pohotově zálohovat soubory
auditních záznamů na centralizovaný
záznamový server nebo médium, které
se obtížně pozměňuje
10.5.3 Aktuální soubory auditních záznamů jsou bezodkladně
zálohovány na centralizovaný záznamový server nebo médium,
které se obtížně pozměňuje.
Okamžité zálohovánízáznamů na centrálníserver
protokolů,nebo na médium, kterélze
obtížnězměnit,uchovávázáznamychráněné, i když
bude systémgenerováníprotokolů kompromitován.
strana99
Duben 2015
PCI DSS Požadavky
10.5.4 Zápis protokolů pro technologie,
které jsou v kontaktu s vnějším
prostředím, na bezpečný,
centralizovaný záznamový server nebo
na zařízení pro media.
Vysvětlení
10.5.4 Protokoly pro technologie, které jsou v kontaktu s vnějším
prostředím (například bezdrátové technologie, firewally, DNS,
maily) jsou zapisovány na bezpečný, centralizovaný interní
záznamový server nebo médium.
Záznamem auditních protokolů z technologií,
které čelí vnějšímu prostředí („external-facing“),
jako jsou bezdrátové technologie, firewally, DNS a
poštovní servery, se snižuje riziko, že tyto
protokoly budou ztraceny nebo pozměněny, neboť
jsou na vnitřní síti bezpečnější.
Záznamymohoubýt zapisovány přímo,
nebopřeneseny čikopíroványzexterních systémů,
dobezpečnéhovnitřního systémunebo na médium.
10.5.5 Použít software pro sledování
integrity souborů nebo software
zjišťující změny v protokolech, aby bylo
zajištěno, že existující data protokolů
nemohou být změněna bez
vygenerování varování (ačkoliv přidání
nových dat by varování spustit
nemělo).
10.6 Revidovat protokoly a bezpečnostní
události pro všechny systémové
komponenty a identifikovat anomálie
nebo podezřelé aktivity.
10.5.5 Zkontrolovat nastavení systému, monitorování souborů a
výsledků monitorovacích aktivit a ověřit, zda je používán software
pro sledování integrity souborů nebo software zjišťující změny v
záznamech protokolů.
10.6 Provést následující kroky:
Poznámka: Nástroje pro sběr, analýzu a
výstrahy mohou být využity v rámci
vyhovění tohoto požadavku.
Systémy monitorování integrity souborů nebo
systémy zjišťující změny kontrolují změny
kritických souborů a oznamují, když jsou takové
změny pozorovány. Pro účely monitorování
integrity souborů subjekt obvykle monitoruje
soubory, které se pravidelně nemění, ale kde
změna naznačuje, že mohly být napadeny
(kompromitovány).
K mnoha porušením dochází o dny nebo měsíce
dříve, než jsou detekovány. Pravidelný přezkum
protokolů pracovníky
neboautomatickýmiprostředky
napomůžeidentifikovataaktivněřešitneoprávněný
přístup kprostředí datdržitelů karet.
Proces přezkumu protokolu nemusí být manuální.
Použití nástrojů pro sběr, analýzu a výstrahy
může usnadnit proces identifikováním událostí v
protokolu, které se musí prověřit.
strana100
Duben 2015
PCI DSS Požadavky
10.6.1Prozkoumatnásledující
bodynejméně jednou denně:
 Všechny bezpečnostníudálosti
 Protokolyovšechsystémových
komponentách, které uchovávají,
zpracovávají nebopřenášejí data
držitelů karet
(CHD)a/neboSADProtokolyvšech
systémovýchkomponent
 Protokolyvšechserverůasystémovýc
h komponent, které vykonávají
funkce zabezpečení(například
firewally, systémydetekce
narušení/prevence proti
narušenísystémů(IDS/IPS),
autentizaceserverů, přesměrující
servery pro e-commerce, atd.).
10.6.1.aZkontrolovatbezpečnostnípolitiky aprocedury a ověřit,
zda procedury jsou definoványpropřezkoumánínásledující bodů
nejménějednou denně, a to buď manuálně
nebopomocínástrojůprotokolu:
 Všechny bezpečnostníudálosti
 Protokolyovšechsystémových komponentách, které
uchovávají, zpracovávají nebopřenášejí data držitelů karet
(CHD)a/neboSAD
 Protokolyvšech systémovýchkomponent
 Protokolyvšechserverůasystémových komponent, které
vykonávají funkce zabezpečení(například firewally,
systémydetekce narušení/prevence proti
narušenísystémů(IDS/IPS), autentizaceserverů, přesměrující
10.6.1.bSledovat procesya dotázat se pracovníků a ověřit,
zdajsou následující body prověřeny nejméně jednou denně:
 Všechny bezpečnostní události
 Protokolyovšechsystémových komponentách, které
uchovávají, zpracovávají nebopřenášejí data držitelů karet
(CHD)a/neboSAD
Vysvětlení
K mnoha porušením dochází o dny nebo měsíce
dříve, než jsou detekovány. Denní kontrola
protokolů minimalizuje množství času i vystavení
vůči možnému narušení.
Je nezbytný
dennípřezkumbezpečnostníchudálostí,
napříkladoznámenínebovýstrahy, které identifikují
podezřeléneboneobvykléaktivity, i
protokolůzkritickýchsystémových komponent
aprotokolůze systémů, které vykonávají
bezpečnostní funkce, jako jsou firewally, IDS/IPS,
systémy monitorováníintegrity souborů(FIM), atd.
k identifikaci potenciálníchproblémů. Všimněte si,
žestanovení"bezpečnostní události"se bude
lišitpro každou organizaci, a mohou se brát v
úvahudaný typtechnologie, umístění a funkčnost
zařízení. Organizacemohou také
chtítzachovatzákladní linii"normálního" provozu a
napomoci tak k identifikacianomálníhochování.
 Protokolyvšech systémovýchkomponent
 Protokolyvšechserverůasystémových komponent, které
vykonávají funkce zabezpečení(například firewally,
systémydetekce narušení/prevence proti
narušenísystémů(IDS/IPS), autentizaceserverů, přesměrující
10.6.2 Sledovat
pravidelnězáznamyvšech
ostatníchsystémových komponent
podle politiky
organizaceastrategieřízení rizik, podle
stanovenéhoročníhoposouzení
rizikorganizace.
10.6.2.aZkontrolovatbezpečnostnípolitiky a procedury a ověřit,
zda jsou definoványprocedury propravidelné sledování
protokolůvšechostatních systémových komponent - a to
buďručně nebo pomocínástrojůprotokolu -založenéna
politikáchorganizaceastrategieřízení rizik.
10.6.2.bZkontrolovatdokumentaci kposouzení rizikorganizace,
dotázat se pracovníkůaověřit, zda sledování
jeprováděnovsouladu s politikouorganizaceastrategieřízení rizik.
Záznamypro všechny
ostatnísystémovékomponenty by také
mělybýtpravidelně přezkoumávány za
účelemzjištěnínáznaků možnýchproblémů
nebopokusůo získánípřístupu k
citlivýmsystémůmprostřednictvímméněcitlivýchsys
témů. Četnost vyhodnocováníby měla být
stanovena v ročnímposouzení rizik subjektu.
strana101
Duben 2015
PCI DSS Požadavky
10.6.3
Vyhodnotitvýjimkyaanomáliezjištěné při
procesu přezkumu.
Vysvětlení
10.6.3.a Zkontrolovat bezpečnostní politiky a procedury a ověřit,
zda jsou definovány procedury pro posuzování výjimek a
anomálií, identifikovaných během prověřování.
Pokudvýjimkyaanomáliezjištěnéběhem
procesupřezkumu protokolů nejsou
vyhodnocovány, subjekt si nemusí
býtvědomnepovolenýchapotenciálněškodlivýchčin
ností,které se vyskytujív rámci jeho vlastní sítě.
10.6.3.b Prověřitprocesya dotázat se pracovníků a ověřit, zda je
prováděno vyhodnocenívýjimekaanomálií.
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).
10.7.a Zkontrolovat bezpečnostní politiky a procedury a ověřit, zda
definují následující body:
 Politiku uchovávání auditních protokolů
 Procedury pro uchovávání auditních protokolů nejméně jeden
rok, přičemž minimálně tři měsíce musí být dostupné online.
10.7.b Dotázat se pracovníků, zkontrolovat auditní protokoly a
ověřit, zda auditní protokoly jsou uchovány nejméně po dobu
jednoho roku.
10.7.c Dotázat se pracovníků, sledovat procesy a ověřit, zda jsou
protokoly okamžitěk dispozicipro analýzu za minimálně tři poslední
měsíce.
10.8Zajistit, aby bezpečnostní politiky a
provozní procedury pro monitorování
veškerého přístupu k síťovým zdrojům a
datům držitelů karet jsou
dokumentovány, používány a známy
všem dotčeným stranám.
10.8Zkontrolovatdokumentaci a dotázat se pracovníků a ověřit, zda
bezpečnostní politiky aprovozní postupy pro monitorování
veškerého přístupu k síťovým zdrojům a datům držitelů karet jsou:
 dokumentovány,
Zachovávání protokolů po dobu nejméně jednoho
roku je důležité proto, že často nějakou dobu trvá,
než se zjistí, že došlo nebo dochází k narušení, a
tato doba poskytuje vyšetřovatelům dostatečně
dlouhou historii protokolů, aby se dala lépe
stanovit délka doby potenciálního napadení a
potenciálně postiženého systému(-ů). Když má
subjekt okamžitě k dispozici protokoly za tři
měsíce, může rychle identifikovat a minimalizovat
dopad narušení dat. Uchovávání protokolů mimo
objekt může zabránit jejich snadné dostupnosti,
což povede k delším časovým prodlevám, než
budou obnovena data protokolů, provedena
analýza a identifikovány napadené systémy nebo
data.
Pracovnícisi musí být průběžné
vědomibezpečnostních politika denních
provozních procedurpro monitorování veškerého
přístupu k síťovým zdrojům a datům držitelů karet
a provádět je.
strana102
Duben 2015
Požadavek 11: Pravidelně testovat bezpečnostní systémy a procesy
Zranitelná místa jsou průběžně odhalována jak osobami konajícími ve zlém úmyslu, tak výzkumníky, a jsou způsobena novým softwarem.
Systémové komponenty, procesy a zakázkový software by měly být často testovány, aby bezpečnostní kontroly stále odrážely měnící se
prostředí.
PCI DSS Požadavky
11.1 Zavést procesy k otestování
přítomnosti bodů bezdrátového přístupu
(802.11), a čtvrtletně detekovat a
identifikovat všechny autorizované a
neautorizované body bezdrátového
přístupu.
Poznámka: Metody, které mohou být
použity, zahrnují mimo jiné skeny
bezdrátových sítí, technické/logické
inspekce systémových komponent a
infrastruktury, kontrolu přístupu do sítě
(Network Access control, NAC), nebo
bezdrátové IDS/IPS.
Metody, které budou použity, musí
dostatečně detekovat a identifikovat jak
autorizovaná tak neautorizovaná zařízení.
Vysvětlení
11.1.a Zkontrolovat politiky a provozní procedury a ověřit, zda
jsou definovány procesy pro čtvrtletní detekci a identifikaci
autorizovaných i neautorizovaných bodů bezdrátového
přístupu.
Implementace a/nebo zneužití bezdrátové technologie
v síti je jednou z nejobvyklejších cest, jak zlovolní
uživatelé získávají přístup do sítě a k datům držitelů
karet. Jestliže je bezdrátové zařízení nebo síť
instalována bez vědomí společnosti, může to dovolit
útočníkovi, aby snadno a „neviditelně“ pronikl do sítě.
Neautorizované bezdrátové zařízení může být skryto
uvnitř nebo připojeno k systému nebo jiné systémové
komponentě, nebo může být připojeno přímo k portu
sítě nebo síťovému zařízení, jako je přepínač nebo
router. Každé takové neautorizované zařízení může
vést k neautorizovanému přístupovému bodu do
prostředí.
11.1.b Ověřit, zda metodologie je adekvátní pro detekci a
identifikaci neautorizovaných bodů bezdrátového přístupu,
včetně alespoň následujících kroků:
 Karty WLAN vložené do systémových komponent
 Přenosná nebo mobilní bezdrátová zařízení připojená na
systémové komponenty k vytvoření bodu bezdrátového
přístupu (například prostřednictvím USB, apod.)
 Bezdrátová zařízení připojená na síťový port nebo síťové
zařízení.
11.1.c V případě, že je prováděno bezdrátové
skenování,zkontrolovat výstup z posledních bezdrátových
skenů a ověřit, zda:
 Autorizované a neautorizované body bezdrátového
přístupu jsou identifikovány, a
 Skan je prováděn nejméně čtvrtletně pro všechny
systémové komponenty a objekty.
11.1.d Je-li využíváno automatické monitorování (například
bezdrátové IDS/IPS, NAC, apod.), ověřit, zda konfigurace
bude generovat varování a informovat obsluhu.
Znalost o tom,kterábezdrátová zařízeníjsou
autorizována můžepomoci administrátorům rychle
identifikovatneautorizováná bezdrátová zařízení,
areakce
naidentifikacineautorizovanýchbezdrátovýchpřístupov
ých bodů napomáháproaktivněminimalizovat
vystavení prostředí držitelů karet zlovolným jedincům.
Vzhledem ke snadnosti, s jakou může být bezdrátový
přístupový bod k síti připojen, vzhledem k obtížnosti
detekce jeho přítomnosti a ke zvýšenému riziku, jaké
představují neautorizovaná bezdrátová zařízení,
musejí být tyto procesy prováděny, i když existují
pravidla, která používání bezdrátové technologie
zakazují.
Velikost a komplexnost určitého prostředí bude
určovat odpovídající nástroje a postupy k poskytnutí
dostačující k ujištění, že podvodné bezdrátové
přístupy nebyly do prostředí instalovány.
strana103
Duben 2015
PCI DSS Požadavky
Vysvětlení
11.1.1 Udržovat seznam autorizovaných
bodů bezdrátového přístupu, včetně
dokumentovaného provozního
zdůvodnění.
11.1.1 Zkontrolovatdokumentovanézáznamy aověřit,
zdajeudržován seznamautorizovanýchbodů bezdrátového
přístupu a provozní zdůvodnění je dokumentováno pro
všechnyautorizované body bezdrátového přístupu.
11.1.2 Zavést proceduryreakce na
bezpečnostní událostivpřípadě zjištění
neautorizovanéhobodu bezdrátového
přístupu.
11.1.2.aZkontrolovat plán odezvy organizace na incident
(Požadavek 12.10) a ověřit, zda definuje a vyžaduje reakci v
případě, že je detekován neautorizovaný bod bezdrátového
přístupu.
Například: V případě osamoceného prodejního
kiosku v nákupním centru (shopping mall), kde
jsou všechny komunikační komponenty uschovány
v tamper-resistant a tamper-evident pouzdře, bude
dostačující provést podrobnou fyzickou prohlídku
samotného kiosku k ujištění, že podvodné
bezdrátové přístupy nebyly připojeny nebo
nainstalovány. Nicméně v prostředí s
vícenásobnými body (např. ve velkých obchodních
centrech, zákaznických call centrech, místnosti
serverů nebo datových centrech) je obtížné
provést podrobnou fyzickou prohlídku.V takovém
případě mohou být kombinovány četné metody pro
splnění požadavků; jako je provedení fyzické
prohlídky systému ve spojení s výsledky
bezdrátových analyzátorů.
11.1.2.bDotázat se odpovědnýchpracovníků a/nebo prověřit
nedávnébezdrátovéhoskenovánía souvisejícíodpovědi a
ověřit, zda jsou přijata opatření v případě odhalení
neautorizovaného bodu bezdrátového přístupu.
strana104
Duben 2015
PCI DSS Požadavky
11.2 Provádět skeny externí a interní
zranitelnosti nejméně jednou za čtvrtletí a
po jakékoliv významné změně v síti
(například instalace nových systémových
komponent, změny v topologii sítě, změna
firewallových pravidel, upgrade produktu).
11.2 Zkontrolovat reporty skenů a podpůrnou dokumentaci a
ověřit, zda interní a externí skeny na zranitelnosti jsou
prováděny podle následujících bodů:
Poznámka: V procesu čtvrtletních skenů
se mohou kombinovat reporty z více
skenů, aby se prokázalo, že všechny
systémy byly skenovány a všechny
příslušnézranitelnostibyly posouzeny. Může
být vyžadována další dokumentace k
ověření, že neopravené zranitelnosti jsou
v řešení.
Vysvětlení
Sken zranitelnosti je kombinace automatického
nebo manuálního nástroje, technik, a/nebo metod
spouštěný na externích i interních síťových
zařízeních a serverech, který má odhalit
potenciální zranitelná místa, která by mohla být
vyhledána a zneužita zlovolnými jedinci.
Existují třitypyskenovánízranitelnostipotřebné
proPCI DSS:
 Interní
čtvrtletnískenovánízranitelnostikvalifikovanými
pracovníky (není vyžadováno použití PCI SSC
Schváleného dodavatele skenování
(ApprovedScanningVendor, ASV)
 Externíčtvrtletnískenovánízranitelnosti, které
musíbýt provedenoASV
Pro první shodu s PCI DSS není
vyžadováno, aby byly úspěšně dokončeny
skeny za čtyři čtvrtletí, pokud hodnotitel
ověří, že
 Vnitřní a vnějšískenovánípodle
potřebypovýznamných změnách
Jakmile jsou tyto nedostatky identifikovány, subjekt
je opraví a opakuje skenování, dokud nejsou
všechny zranitelnosti opraveny.
1) poslední výsledek skanu byl úspěšný,
2) subjekt má dokumentované politiky a
procedury vyžadující čtvrtletní skenování, a
Identifikace a řešení zranitelnosti včas snižuje
pravděpodobnost zneužití zranitelnosti a
potenciálního narušení systémových komponent
nebo dat držitelů karet.
3) zranitelnosti zjištěné ve výsledku skenu
byly opraveny, jak je prokázáno
v opakovaném skenu.
V letech následujících po prvním přezkumu
PCI DSS musí být absolvovány úspěšné
čtvrtletní skeny.
11.2.1 Provádět čtvrtletní interní skeny
zranitelnosti a podle potřeby opakované
skeny, dokud “vysoce rizikové (High risk)”
zranitelnosti (identifikované v Požadavku
6.1) nejsou vyřešeny. Skeny musí
provádět kvalifikovaný pracovník.
11.2.1.a Prověřit reporty skenů a ověřit, zda během
posledních 12 měsících došlo ke čtyřem čtvrtletním skenům.
Proces pro identifikování zranitelnosti interních
systémů vyžaduje, aby skeny zranitelnosti byly
prováděny čtvrtletně. Zranitelnosti představující
největší riziko v prostředí (například označované
jako „High“ v souladu s Požadavkem 6.1) musí být
řešeny s nejvyšší prioritou.
strana105
Duben 2015
PCI DSS Požadavky
Vysvětlení
11.2.1.b Prověřit reporty skenů a ověřit, zda proces skenů
zahrnuje opětovné skeny, dokud nejsou vyřešeny všechny
“vysoce rizikové (High risk)” definované v Požadavku 6.1.
Vnitřní skeny zranitelnosti mohou být prováděny
kvalifikovanými, interními pracovníky, kteří jsou v
rozumné míře nezávislí na systémových
komponentách, které se mají skenovat (například
administrátor firewallu by neměl být zodpovědný za
skenování firewallu), nebo si subjekt může zvolit,
aby interní sken zranitelnosti byl proveden firmou
specializující se na skenování zranitelnosti.
11.2.1.c Dotázat se pracovníků a ověřit, zda sken byl
proveden kvalifikovaným interním zdrojem (zdroji) nebo
kvalifikovanou třetí stranou, a jde-li o takový případ, existuje
organizační nezávislost hodnotitele (nemusí být QSA ani
ASV).
11.2.2 Provádět čtvrtletní externí skeny
zranitelnosti prostřednictvím Schváleného
dodavatele skenování (ASV),
schváleného Radou PCI pro
bezpečnostní standardy (PCI SSC).
Proveďte opakované skenování, dokud
se nedosáhne uspokojivého skenu.
Poznámka: Čtvrtletní sledování externí
zranitelnosti musí být prováděno
Schváleným dodavatelem skenování (ASV)
schváleným Radou pro bezpečnostní
standardy(Payment Card Industry Security
Standards Council, PCI SSC).
Odkazujeme na ASV Program Guide
uveřejněný na internetových stránkách PCI
SSC ohledně odpovědnosti zákazníka za
skenování, přípravu skenování atd.
11.2.3Provádět interní a externí skeny, a
podle potřeby opětovné skeny, po každé
významné změně. Skeny musí být
prováděny kvalifikovanou osobou.
11.2.2.a Prověřit zprávy o čtyřech posledních externích
skenech na zranitelnosti a ověřit, zda během posledních 12
měsících došlo ke čtyřem čtvrtletním externím skenům
zranitelnosti.
Vzhledem k tomu, že externí sítě jsou ve větším
riziku narušení, čtvrtletní skenování externí
zranitelnosti musí být provedeno Schváleným
dodavatelem skenování PCI DSS (ASV).
11.2.2.b Prověřit výsledky každého čtvrtletního testu a
opětovných skenů a ověřit, zda vyhovují požadavkům
Průvodce programu ASV (ASV Program Guide) (například
žádná zranitelnost se nezařadila výše než 4.0 podle CVSS
a nedošlo k automatickým chybám).
11.2.2.c Prověřit reporty skenů a ověřit, zda skeny byly
dokončeny Schváleným dodavatelem skenování (ASV),
schváleným Radou PCI SSC.
11.2.3.a Prověřit a provést korelaci dokumentace kontroly
změn a reportů skenů a ověřit, zda systémové komponenty,
podléhající významným změnám byly skenovány.
11.2.3.b Prověřitreporty skenůa ověřit, zda proces
skenování zahrnuje opakované skeny, dokud:
 Pro externí skeny neexistují zranitelnosti, které by byly
označeny více než 4.0 podle CVSS.
 Pro interní skeny, všechny „High-risk“ zranitelnosti
definované v PCI DSS Požadavku 6.1. jsou vyřešeny.
Určení toho, co představuje významnou změnuje
vysoce závislána konfiguracidanéhoprostředí.
Pokudaktualizacenebo modifikaceby mohla
umožnitpřístupk datům držitelů karetnebo
ovlivnitbezpečnostdatdržitelů karet, pak to
můžebýtpovažováno zavýznamné.
Skenování prostředí po jakékoli významné změně
zajišťuje, aby změny byly provedeny tak, aby v
důsledku změny nebyla narušena
(kompromitována) bezpečnost prostředí. Všechny
strana106
Duben 2015
PCI DSS Požadavky
11.2.3.c Potvrdit, zda byl sken proveden kvalifikovaným
interním zdrojem (zdroji) nebo kvalifikovanou externí třetí
stranou, a jde-li o tento případ, zda existuje organizační
nezávislost hodnotitele (nemusí být QSA ani ASV).
11.3 Implementovatmetodiku propenetrační
testování, které zahrnujenásledující body:
 Testování je založeno na
přístupechpenetračníhotestování
přijatém v oboru(např. NISTSP800-115)
11.3Zkontrolovatmetodiku penetračníhotestování, dotázat se
odpovědných pracovníků a ověřit, zda je
metodikaimplementována a zahrnuje následující body:
 Jezaložena na přístupechpenetračníhotestování přijatém v
oboru(např. NISTSP800-115)
 Zahrnujepokrytípro celé ohraničené
prostředí dat držitelů karetakritických
systémů
 Zahrnujepokrytípro celé ohraničené prostředí dat držitelů
karetakritických systémů
 Zahrnuje interní i externí testování sítě
 Obsahujetestypro ověřenísegmentaceakontroly pro
snižovánírozsahu
 Obsahujetestypro
ověřenísegmentaceakontroly pro
snižovánírozsahu
 Definujepenetrační testyaplikačnívrstvy,
kterézahrnujíminimálnězranitelnostiuve
denév Požadavku6.5
 Definujepenetrační testysíťovévrstvy,
které zahrnujíkomponenty
podporujícísíťovéfunkce a takéoperační
systémy
 Zahrnujepřezkoumáníaposouzeníhroze
b azranitelnostíběhemposledních 12
měsíců
 Interní i externí testování sítě
 Definujepenetrační testyaplikačnívrstvy,
kterézahrnujíminimálnězranitelnostiuvedenév
Požadavku6.5
 Definujepenetrační testysíťovévrstvy, které
zahrnujíkomponenty podporujícísíťovéfunkce a
takéoperační systémy
 Zahrnujepřezkoumáníaposouzeníhrozeb
azranitelnostíběhemposledních 12 měsíců
 Určujeuchovávánívýsledkůtestovánípenetraceavýsledků
nápravných akcí.
 Určujeuchovávánívýsledkůtestovánípen
etraceavýsledků nápravných akcí.
Poznámka: Tato aktualizace Požadavku
11.3je pokládána za osvědčený postup do
30. června2015, po tomto datu se
stávápožadavkem. Požadavky na
penetrační testování z verze PCI DSS v2.0
musí být plněny dokud nebude zavedena
verze 3.
Vysvětlení
systémové komponenty ovlivněné změnou musí
být skenovány.
Záměrem testu průniku je simulování útoku v
situaci reálného světa s cílem identifikovat, jak
daleko by útočník mohl proniknout do prostředí. To
umožňuje subjektu získat lepší porozumění pro
jeho potenciální míry rizika a vytvořit strategiina
obranuproti útokům.
Testy průniků do sítě se liší od skenů zranitelnosti
v tom, že testy průniků jsou aktivní proces, který
může zahrnovat zneužívání identifikovaných
zranitelností. Provádění skenu zranitelnosti může
být jedním z prvních kroků, který tester průniku
provede, aby plánoval strategii testování, ačkoli to
není jediný krok. I když test zranitelnosti
nedetekuje známé zranitelnosti, tester průniku
získá dostatek znalostí o systému k identifikaci
možných bezpečnostních slabin.
Testování průniku je obecně vysoce manuální
proces. I když se mohou použít automatizované
nástroje, tester využije své znalosti systému k
průniku do prostředí. Často tester seřadí několik
typů zneužití s cílem prolomení se vrstvami
obrany. Například pokud tester nalezne prostředek
k získání přístupu k aplikačnímu serveru, použije
po té tento kompromitovaný server jako výchozí
bod nového útoku s využitím zdrojů, ke kterým má
server přístup. Tímto způsobem je tester schopen
simulovat metody využívané útočníkem k
identifikování oblastí potenciální zranitelnosti
prostředí.
Penetrační techniky testováníse budou lišitpro
různéorganizace,atyp, hloubku
asložitosttestováníbude závisetnakonkrétním
prostředíaposouzení rizikorganizace.
strana107
Duben 2015
PCI DSS Požadavky
11.3.1 Proveďte externí test penetrace
nejméně jednou ročně a po jakékoliv
významné změně infrastruktury nebo
aktualizace či modifikace aplikace (jako
například upgrade operačního systému,
podsíť přidaná k prostředí nebo webový
server přidaný k prostředí).
11.3.1.aZkontrolovatrozsahpráce avýsledkůz
nejnovějšíhoexterníhopenetračního testu a ověřit, zda
penetrační testováníse provádítakto:
 Podledefinované metodiky
 Nejménějednou ročně
 Povšech významných změn v prostředí.
11.3.1.b Ověřit, zdatest
bylprovedenkvalifikovanýminternímzdrojemnebokvalifikovan
ouexterní třetí stranou, a je-lito
případné,existujeorganizačnínezávislost testera(nemusí být
QSAneboASV).
11.3.2 Proveďte interní test penetrace
nejméně jednou ročně a po jakékoliv
významné změně infrastruktury nebo
aktualizace či modifikace aplikace (jako
například upgrade operačního systému,
podsíť přidaná k prostředí nebo webový
server přidaný k prostředí).
11.3.2.a Zkontrolovatrozsahpráce avýsledkůz
nejnovějšíhointerníhopenetračního testu a ověřit, zda
penetrační testováníse provádínásledovně:
 Podledefinované metodiky
Vysvětlení
Penetrační testyprováděnév pravidelných
intervalechapovýznamnýchzměnáchprostředí
jeproaktivníbezpečnostníopatření, kterépomáhá
minimalizovatpotenciálnípřístup k prostředí dat
držitelů karet zlovolnými jedinci.
Určení toho, co představuje
významnáaktualizacenebozměna,je silně závisléna
konfiguracidanéhoprostředí.
Pokudaktualizacenebo modifikaceby mohla
umožnitpřístupk datům držitelů karetnebo
ovlivnitbezpečnostprostředí datdržitelů karet, pak
by to mohlobýtpovažováno
zavýznamné.Prováděnípenetračních
testůpoaktualizacesítěamodifikaciposkytuje záruku,
že kontroly, o nichž se předpokládá se, žejsou
zavedeny, poaktualizacinebo modifikaci
stáleefektivněpracují.
 Nejméně jednou ročně
 Povšech významných změn v prostředí.
11.3.2.b Ověřit, zdatest
bylprovedenkvalifikovanýminternímzdrojemnebokvalifikovan
ouexterní třetí stranou, a je-lito
případné,existujeorganizačnínezávislost testera (nemusí být
QSAneboASV).
11.3.3 Zneužitelnézranitelnostizjištěné v
průběhupenetračníchtestůjsouopravenya
testováníse zopakuje a ověří
provedenéopravy.
11.3.3 Zkontrolovatvýsledky penetračních testů a ověřit,
zdazjištěné zneužitelnézranitelnostibyly opravenyaže
opakovanétestovánípotvrdilo, žezranitelnostbyla opravena.
strana108
Duben 2015
PCI DSS Požadavky
Vysvětlení
11.3.4Pokudsegmentacese používá k
oddělení prostředí držitelů karet odjiných
sítí, provádětpenetrační testynejméně
jednou ročněapo každé změně kontroly
/metodysegmentace a ověřit, zda metody
segmentacejsoufunkční a efektivní, a
oddělují všechny systémy mimo rozsah
od systémů vprostředí dat držitelů karet
(CDE).
11.3.4.aZkontrolovat kontroly segmentacea přezkoumat
metodikypenetračníhotestování a ověřit, zda jsou
definovány procedury penetračníhotestování k otestování
všech metodsegmentace a potvrdit, zda jsou funkční a
efektivní, a oddělujívšechny systémy mimo rozsah od
systémů v prostředí dat držitelů karet (CDE).
Penetrační testováníjedůležitým nástrojempro
potvrzení, žejakékoliv zavedená segmentace
oddělující prostředí datdržitelů karet od ostatních
sítí jeefektivní. Penetrační testování by se mělo
zaměřitnakontroly segmentace, a to jakz
vnějškusítětak izevnitřsítě subjektu,
alemimoprostředí datdržitelů karet, aby se
potvrdilo, že penetrace není schopna překonat
kontrolu segmentace.Napříkladtestování
sítěa/neboskenováníotevřenýchportů, a ověřit že
neexistuje propojení mezi sítěmi v rozsahu a mimo
rozsah.
11.3.4.bZkontrolovatsi výsledkyz nejnovějšíhopenetračního
testu a ověřit, zda:
 Jepenetrační testování k ověření kontroly segmentace
provedenonejméně jednou ročněapo každé změně
kontroly / metody segmentace.
 Penetrační testování pokrývávšechny používané
kontroly/metody segmentace.
 Penetrační testování ověřuje,
zdakontroly/metodysegmentacejsoufunkční a efektivní,
a oddělují všechny systémy mimo systémy v prostředí
dat držitelů karet (CDE).
11.4 Používat techniky detekce a/nebo
prevence narušení k detekování a/nebo
předcházení narušení v sítě. Monitorovat
všechny přenosy na hranici prostředí
držitelů dat a také na kritických místech v
prostředí držitelů karet, a varovat
pracovníky ohledně podezření z narušení.
11.4.aZkontrolovatkonfiguraci systémůasíťových diagramů a
ověřit, zda jsou nasazeny techniky(jako je detekce
narušenísystémůa/nebosystémyprevence proti narušení) k
monitorováníveškeré komunikace:
Udržovat všechny detekční i preventivní
software (engines) aktualizované.
11.4.b Zkontrolovat konfiguraci systémů a dotázat se
odpovědných pracovníků a potvrdit, zda detekce narušení a/
nebo techniky prevence narušení varují pracovníky před
podezřelými průniky.
 Na hranici prostředí datdržitelů karet
 Vkritickýchbodech vprostředí datdržitelů karet.
11.4.c Zkontrolovat IDS/IPS konfigurace a dokumentaci
dodavatele a ověřit, zda techniky detekce a/nebo prevence
narušení jsou konfigurovány, udržovány a aktualizovány podle
pokynů dodavatele k zajištění optimální ochrany.
Detekce průniku a/nebo techniky prevence před
průnikem (jako jsou IDS/IPS) porovnávají přenosy
komunikace vstupující do sítě se známými
„podpisy“ a/nebo chování tisíců typů narušení
(nástroje hackerů, trojské koně a další typy
malware), a odesílá výstrahy a/nebo zastaví
pokusy při jejich výskytu. Bez proaktivního přístupu
k detekci neautorizované aktivity, by útoky na
počítačové zdroje (nebo zneužití těchto zdrojů)
mohly proběhnout v reálném čase bez povšimnutí.
Bezpečnostní výstrahy generované těmito
technikami by měly být monitorovány, aby mohly
být zastaveny pokusy o průnik.
strana109
Duben 2015
PCI DSS Požadavky
11.5 Nasadit mechanismus detekce změn
(například nástroje monitorování integrity
souborů) pro varování pracovníků před
neautorizovanými modifikacemi (včetně
změn, doplnění a odstranění) kritických
systémových souborů, konfiguračních
souborů nebo obsahových souborů; a
konfigurovat software k provedení
porovnání kritických souborů nejméně
jednou týdně.
Poznámka: Pro účely detekce změn jsou
kritické soubory obvykle ty, které se
pravidelně nemění, ale jejich modifikace
může signalizovat narušení nebo riziko
narušení systému. Mechanismy detekce
změn, jako jsou produkty monitorování
integrity souborů, jsou obvykle dodávány
s předkonfigurovanými kritickými soubory
pro odpovídající operační systém. Další
kritické soubory, jako například ty pro
zakázkové aplikace, musí být vyhodnoceny
a definovány subjektem (to jest
obchodníkem nebo poskytovatelem
služeb).
11.5.1 Implementovatproces k reakci na
každé upozorněnígenerované
mechanismem detekce změn.
aprovozní procedurypro monitorování
bezpečnostiatestování byly
11.5.a Ověřit používání mechanismu detekce změn v rámci
prostředí dat držitelů karet sledováním systémových
nastavení a monitorovaných souborů, jakož i přezkumem
výsledků monitorování.
Příklady souborů, které by měly být monitorovány:
 Systémové spustitelné soubory (k interpretování
programů, executables).
 Spustitelné soubory aplikace (executables)
 Konfigurace a soubory parametrů
 Centrálně uložené, historické nebo archivované,
trasovací (log) a auditní soubory
 Další kritické soubory určené subjektem (například
pomocí vyhodnocení rizika nebo jinými způsoby).
Vysvětlení
Řešení detekce změn, jako jsou nástroje pro
monitorování integrity souborů (file-integrity
monitoring, FIM) kontrolují změny, doplnění a
odstranění kritických souborů a informují, jakmile
jsou takové změny detekovány. Jestliže nejsou
náležitě implementovány řešení detekce změn a
výstupy monitorovány, zlovolný jedinec by mohl
přidat, vymazat či změnit obsah konfiguračního
souboru, programy operačního systému nebo
soubory aplikace k interpretování programů
(executables). Neautorizované změny, nejsou-li
detekovány, by mohly způsobit neúčinnost
bezpečnostních kontrol a/nebo mít za následek, že
budou data držitelů karet odcizena bez jakéhokoli
patrného dopadu na obvyklé zpracování.
11.5.b Ověřit, zda mechanismy jsou konfigurovány tak, aby
varovaly pracovníky při neautorizovaných modifikacích
(včetně změn, doplnění a odstranění) kritických souborů a
minimálně jednou týdně provádět porovnání kritických
souborů.
11.5.1 Dotázat se odpovědných pracovníků a ověřit, zda
všechna varování jsouzkoumánaa řešena.
11.6 Zkontrolovatdokumentac a dotázat se pracovníků a
ověřit, zda bezpečnostní politiky aprovozní postupy pro
monitorování bezpečnosti a testování jsou:
Pracovnícisi musí být vědomiaprůběžně naplňovat
bezpečnostní politikyaprovozní procedurypro
monitorováníbezpečnostiatestování.
 dokumentovány,
strana110
Duben 2015
Udržování politiky bezpečnosti informací
Požadavek 12: Udržovat politiku zaměřenou na bezpečnost informací pro všechny pracovníky
Silná bezpečnostní politika nastavuje bezpečnostní tón v celém subjektu a seznamuje pracovníky s tím, co se od nich očekává. Všichni pracovníci
si musí být vědomi citlivosti dat a své odpovědnosti za jejich ochranu. Pro účely Požadavku 12, termín „pracovníci” označuje zaměstnance na plný
i částečný úvazek, zaměstnance na dobu určitou, smluvní strany a konzultanty, kteří jsou “rezidenti” v sídle subjektu nebo mají přístup k datům
držitelů karet.
PCI DSS Požadavky
Vysvětlení
12.1 Zavést, vydat, udržovat a šířit
bezpečnostní politiku.
12.1 Zkontrolovat politiku bezpečnosti informací a ověřit, zda
je politika vydána a rozšířena ke všem relevantním uživatelům
(včetně dodavatelů a obchodních partnerů).
Politika bezpečnosti informací společnosti vytváří
„cestovní mapu“ pro implementaci
bezpečnostních opatření na ochranu jejích
nejcennějších aktiv. Všichni zaměstnanci by si
měli uvědomovat citlivost dat a svoji odpovědnost
za jejich ochranu.
12.1.1 Přezkoumatbezpečnostní
politikunejméně jednou
ročněaaktualizovat politiku při
změněprostředí.
12.1.1 Ověřit, zda politika bezpečnostniinformacíje
prověřena nejméně jednou ročněapodle potřeby
aktualizována, aby odrážela změny vobchodních cílechnebo
rizika prostředí.
Bezpečnostní hrozby a metody ochrany se rychle
vyvíjejí. Bez aktualizace bezpečnostní politiky tak,
aby reflektovala relevantí změny, nejsou řešena
nová ochranná opatření v boji proti těmto
hrozbám.
12.2 Zavést proces vyhodnocování rizik,
který:
 je prováděn nejméně jednou ročně a
po významné změně prostředí (např.
nabytí, fúze, přemístění, atd.).
 identifikuje kritická aktiva, hrozby a
zranitelná místa a
 vyúsťuje ve formální dokumentovanou
analýzu rizik.
12.2.a Ověřit, zdakaždoroční proces vyhodnocení rizik je
dokumentován tak, že:

identifikuje kritická aktiva, hrozby a zranitelnosti

vyúsťuje ve formální dokumentovanou analýzu rizik,
12.2.b Prověřit dokumentaci vyhodnocení rizik a ověřit, zda
proces vyhodnocení rizik je prováděn nejméně jednou ročně a
po významné změně prostředí.
Příklady metodologie vyhodnocenírizik
zahrnují, kromě jiného, OCTAVE, ISO
27005 and NIST SP 800-30.
Vyhodnocení rizik umožňuje organizaci
identifikovat hrozby a spojené zranitelnosti, které
jsou potencionálně schopné negativně ovlivnit její
činnost. Po té se mohou efektivně alokovat zdroje
k implementování kontrol snižující
pravděpodobnost a/nebo potenciální dopad
realizace hrozby.
Provádění vyhodnocení rizik nejméně jednou
ročně a po významné změně prostředí umožňuje
organizaci udržovat aktuální organizační změny a
vyvíjející se hrozby, trendy a technologie.
strana111
Duben 2015
PCI DSS Požadavky
12.3 Vyvinout uživatelskou politiku pro
kritické technologie a definovat správné
používání těchto technologií.
Vysvětlení
12.3 Zkontrolovat politiky pro kritické technologie, a dotázat se
odpovědných pracovníků a ověřit, zda následující politiky jsou
implementovány a používané zaměstnanci a následuje:
Politiky pro užívání pracovníky mohou buď
zakázat využívání určitých zařízení a jiných
technologií, je-li to v souladu s politikou
společnosti, nebo mohou poskytovat pracovníkům
návod k jejich správnému používání a
implementaci. Nejsou-li politiky pro užívání
zavedeny, zaměstnanci mohou používat
technologie v rozporu s politikou společnosti, a
tím umožní zlovolným jedincům získat přístup ke
kritickým systémům a datům držitelů karet.
Poznámka:
Příkladykritickýchtechnologiízahrnují,
kromě jiného, vzdálený
přístupabezdrátové technologie,
notebooky, tablety, přenosnámédia,
používání e-mailu apoužívání internetu.
Zajistěte, aby politiky používání
vyžadovaly následující kroky:
12.3.1 Výslovné schválení pověřenými
stranami.
12.3.1 Ověřit, zda uživatelská pravidla zahrnují procesy k
získání výslovného souhlasu od pověřených stran
k používání technologií.
Pokud by se pro implementaci těchto technologií
nevyžadovalo řádné schválení, nějaký pracovník
by mohl nevědomky implementovat řešení k
zajištění určité provozní potřeby a otevřít přitom
obrovskou díru, která by vydala kritické systémy a
data na pospas zlovolným jedincům.
12.3.2 Autentizace pro užívání
technologie
12.3.2 Ověřit, zda uživatelské politiky zahrnují procesy pro
autentizování veškerého užívání technologií uživatelským ID
a heslem nebo jinou autentizací (například token).
Je-li technologie implementována bez
řádnéautentizace (ověření identity, tj.
uživatelskými ID a hesla, tokeny, VPN apod.),
mohou zlovolní jedinci snadno využít tuto
nechráněnou technologii k přístupu do kritických
systémů a k datům držitelů karet.
12.3.3 Seznam všech takovýchto
zařízení a pracovníků s přístupem
12.3.3 Ověřit, zda uživatelské politiky definují seznam všech
zařízení a pracovníků autorizovaných k užívání těchto
zařízení.
Zlovolní jedinci mohou narušit fyzickou
bezpečnost a umístit svá vlastní zařízení do sítě
jako „zadní vrátka“.Pracovníci mohou také
obcházet postupy a sami instalovat zařízení.
Přesná inventarizace s řádným označením
zařízení umožňuje rychlou identifikaci
neschválených instalací.
strana112
Duben 2015
PCI DSS Požadavky
12.3.4 Metoda, jak přesněasnadno
určitvlastníka, kontaktní informace
aúčel(např. označování, kódovánía/
neboinventarizacezařízení)
12.3.4 Ověřit, zda uživatelské politiky definují metodu k
přesnému označování a snadnému určení vlastníka
zařízení, kontaktních informací a účelu (například
označováním, kódováníma/neboinventarizacízařízení).
Vysvětlení
Zlovolní jedinci mohou narušit fyzickou
bezpečnost a umístit svá vlastní zařízení do sítě
jako „zadní vrátka“.Pracovníci mohou také
obcházet postupy a sami instalovat zařízení.
Přesná inventarizace s řádným označením
zařízení umožňuje rychlou identifikaci
neschválených instalací.
Zvažte zavedení oficiálních pravidel pro
pojmenování zařízení a zaprotokolujte všechna
zařízení s prováděnými inventárními kontrolami.
Využijte logického označování samolepkami s
informacemi jako jsou kódy, vztahující se k
vlastníkovi zařízení, kontaktním informacím a
účelu.
12.3.5 Přijatelné použití technologie
12.3.5 Ověřit, zda uživatelské politiky definují pro technologii
přijatelné využití.
12.3.6 Akceptovatelné umístění v síti pro
technologie
12.3.6 Ověřit, zda uživatelské politiky definují pro
technologie přijatelné umístění v síti.
12.3.7 Seznam společností schválených
produktů
12.3.7 Ověřit, zda uživatelské politiky vyžadují seznam
společností schválených produktů.
12.3.8 Automatické odpojení relace u
technologií s dálkovým přístupem po
stanovené době nečinnosti
12.3.8.a Ověřit, zda uživatelské politiky vyžadují automatické
odpojení relace u technologií s dálkovým přístupem po
stanovené době nečinnosti.
12.3.8.bZkontrolovatkonfigurace protechnologie vzdáleného
přístupu aověřit, zda se relacevzdáleného
přístupuautomatickyodpojípo určitédobě nečinnosti.
12.3.9 Aktivace technologií s dálkovým
přístupem pro dodavatele a obchodní
partnery pouze tehdy, pokud to
dodavatelé a obchodní partneři
potřebují, s okamžitou deaktivací po
použití.
12.3.9 Ověřit, zda uživatelské politiky vyžadují aktivaci
technologií s dálkovým přístupem používaných dodavateli a
obchodními partnery pouze tehdy, pokud to dodavatelé a
obchodní partneři potřebují, s okamžitou deaktivací po
použití.
Když společnost definuje akceptovatelné pracovní
využití a umístění společností schválených
zařízení a technologií, je lépe schopna řídit a
kontrolovat mezery v konfiguracích a operačních
kontrolách, a zajistit, aby nebyla otevřena žádná
„zadní vrátka“, kterými by mohli zlovolní jedinci
získat přístup do kritických systémů a k datům
držitelů karet.
Technologie se vzdáleným přístupem jsou často
právě takovými „zadními vrátky“ do kritických
systémů a k datům držitelů karet. Odpojením
technologií se vzdáleným přístupem v době, kdy
se nepoužívají (například technologií užívaných k
podpoře vašich systémů dodavateli vašich POS
terminálů nebo jinými dodavateli nebo obchodními
partnery), se přístup a riziko pro sítě minimalizují.
strana113
Duben 2015
PCI DSS Požadavky
12.3.10 Při přístupu pracovníků k datům
držitelů karet prostřednictvím technologií
s dálkovým přístupem zakázat
kopírování, přesuny a uchovávání dat
držitelů karet na lokálních pevných
discích a výměnných elektronických
médiích, pokud to není výslovně
povoleno pro definovaný provozní účel.
12.3.10.a Ověřit, zda uživatelské politiky při přístupu k datům
držitelů karet přes technologie s dálkovým přístupem
zakazují kopírování, přesuny nebo uchovávání dat držitelů
karet na lokální pevné disky a výměnná elektronická média.
12.3.10.b Pro pracovníky s oprávněným pověřením ověřit,
zda používané politiky vyžadují ochranu dat držitelů karet
v souladu s Požadavky PCI DSS.
Kdejeprovozní potřeba oprávněna, musí
politiky použitívyžadovat ochranu dat
vsouladu s platnýmipožadavkyPCIDSS.
12.4 Zajistit, aby bezpečnostní politika a
procedury jasně definovaly odpovědnost
v oblasti bezpečnosti informací pro
všechny pracovníky.
12.5 Jednotlivci nebo týmu přidělit
následující odpovědnosti za řízení
bezpečnosti informací:
12.4.a Ověřit, zda bezpečnostní politiky jasně definují
odpovědnost v oblasti bezpečnosti informací pro všechny
pracovníky.
12.4.b Dotázat se vzorku odpovědných pracovníků a ověřit,
zda rozumí bezpečnostní politice.
12.5 Zkontrolovat politiky a procedury bezpečnosti informací a
ověřit, zda:

Formální svěření bezpečnosti informací hlavnímu
bezpečnostnímu pracovníkovi (Chief Security Officer)
nebo jinému členovi vedení obeznámenému
s problematikou bezpečnosti.

Následující odpovědnosti bezpečnosti informací jsou
specificky a formálně přiděleny:
12.5.1 Zavést, dokumentovat a
distribuovat bezpečnostní politiky a
procedury.
12.5.1 Ověřit, zda odpovědnost za vytvoření, dokumentaci a
distribuci bezpečnostních politik a procedur je formálně
přidělena.
12.5.2 Monitorovat a analyzovat
bezpečnostní varování a informace a
distribuovat k příslušným pracovníkům.
12.5.2 Ověřit, zda odpovědnost za sledování a analýzu
bezpečnostních varování a distribuci informací je formálně
přidělena odpovídajícímu řídícímu pracovníkovi
zodpovědného za informační bezpečnost a provozní
jednotku.
Vysvětlení
Pro zajištění, aby si všichni pracovníci byli vědomi
své povinnosti neuchovávat ani nekopírovat data
držitelů karet na jejich lokální osobní počítače
nebo jiná média, politika by měla jasně zakazovat
takové činnosti, kromě pracovníků, kteří byli
explicitně k tomuto autorizováni. Uchovávání a
kopírování dat držitelů karet na lokální pevné
disky nebo jiná média musí být v souladu se
příslušnými požadavky PCI DSS.
Bez jasně definovaných bezpečnostních rolí a
přiřazených odpovědností by se mohly objevit
nekonsistentní interakce s bezpečnostní
skupinou, které by mohly zavinit nezabezpečenou
implementaci technologií nebo používání
zastaralých nebo nezabezpečených technologií.
Každý pracovník nebo tým s odpovědností za
správu bezpečnosti informací by si měl být jasně
vědom svých odpovědností a odpovídajících
úkolů, na základě specifické politiky. Bez této
odpovědnosti mohou mezery v procesech otevřít
přístup ke kritickým zdrojům a datům držitelů
karet.
strana114
Duben 2015
PCI DSS Požadavky
12.5.3 Zavést, dokumentovat a
distribuovat procedury reakce a
eskalace bezpečnostních událostí pro
zajištění včasného a efektivního řešení
všech situací.
12.5.3 Ověřit, zda odpovědnost za vytvoření, dokumentaci a
distribuci procedur reakce a eskalace bezpečnostních
událostí je formálně přidělena.
12.5.4 Spravovat uživatelské účty,
včetně přidávání, mazání a modifikací.
12.5.4 Ověřit, zda odpovědnost za správu (přidávání,mazání
a modifikaci) uživatelských účtů a řízení autentizake je
formálně přidělena.
12.5.5 Monitorovat a kontrolovat
všechny přístupy k datům.
12.5.5 Ověřit, zda odpovědnost za sledování a kontrolu
všech přístupů k datům je formálně přidělena.
12.6 Implementovat formální program
bezpečnostního povědomí, který všechny
pracovníky informuje o významu
bezpečnosti dat držitelů karet.
12.6.1 Školit pracovníky po nástupu a
nejméně jednou ročně.
Poznámka: Metody se mohou měnit
v závislosti na roli pracovníků a jejich
úrovně přístupu k datům držitele karet.
12.6.a Přezkoumat program bezpečnostního povědomí a
ověřit, zda poskytuje povědomí všem pracovníkům o významu
bezpečnosti dat držitelů karet.
12.6.b Ověřit procedury a dokumentaci programu
bezpečnostního povědomí a provést následující kroky:
12.6.1.a Ověřit, zda program bezpečnostního povědomí
poskytuje četné metody komunikace povědomí a vzdělávání
pracovníků (například plakáty, dopisy, vzkazy, webový
trénink, porady a propagace).
12.6.1.b Ověřit, zda se pracovníci účastní školení
o bezpečnosti po nástupu a nejméně jednou ročně.
Vysvětlení
Jestliže nejsou pracovníci poučeni o své
odpovědnosti v oblasti bezpečnosti, mohou
implementované bezpečnostní ochranné
prostředky a procesy v důsledku chyb nebo
úmyslných akcí pracovníků ztratit svou účinnost.
Jestliže program bezpečnostního povědomí
neobsahuje roční školení k obnově znalostí,
mohou být klíčové bezpečnostní procesy a
procedury zapomenuty nebo obcházeny, což
vede k tomu, že jsou vystaveny nebezpečí kritické
zdroje a data držitelů karet.
12.6.1.cDotázat se vzorku pracovníků a ověřit, zda dokončili
školeníajsou si vědomidůležitostizabezpečení datdržitelů
karet.
12.6.2 Vyžadovat od pracovníků
nejméně jednou ročně potvrdit, že četli a
pochopili bezpečnostní politiku a
procedury.
12.6.2 Ověřit, zda program bezpečnostního povědomí,
vyžaduje od pracovníků nejméně jednou ročně potvrdit,
písemně nebo elektronicky, zda četli a pochopili
bezpečnostní politiku.
Vyžadování potvrzení od pracovníků v písemné
nebo elektronické formě napomáhá zajistit, že
přečetli bezpečnostní politiky/procedury, a že se
zavázali tato pravidla dodržovat.
strana115
Duben 2015
PCI DSS Požadavky
Vysvětlení
12.7 Hodnotit potencionální pracovníky
před přijetím, aby se minimalizovala rizika
útoků z interních zdrojů. (Například
posuzování zázemí zahrnuje historii
předchozích zaměstnání, trestní rejstřík,
úvěrovou historii a prověření referencí.)
12.7 Konzultovat s managementem úseku lidských zdrojů a
ověřit, zda kontroly zázemí pracovníků probíhají (v rámci
omezení danými místními zákony) před přijetím u pracovníků,
kteří budou mít přístup k datům držitelů karet nebo prostředí
dat držitelů karet.
Důkladné prověřování minulosti před přijetím
potenciálních pracovníků, u kterých se očekává,
že obdrží přístup k datům držitelů karet, snižuje
riziko neautorizovaného použití čísla platební
karty (PAN) a jiných dat držitelů karet osobami s
pochybnou nebo kriminální minulostí.
12.8Prostřednictvímsledování, přezkumu politika
proceduraprověřením podpůrnédokumentace ověřit,
zdaprocesyjsouimplementovány pro řízeníposkytovatelů
služeb, s nimiž jsou data držitelů karetsdílena,nebokteří by
mohlimít vliv nabezpečnostdat držitelů karet (například
zařízení pro ukládání záložních pásek, spravované
poskytovateli služeb jako jsou webhostingové společnosti
nebo poskytovatelé bezpečnostních služeb, kteří přijímají data
pro účely modelování podvodů, atd.), dle následujících bodů:
Jestliže obchodník nebo poskytovatel služeb sdílí
data držitelů karet s poskytovatelem služeb,
vynutí se určité požadavky od těchto dodavatelů
služeb, k zajištění ochrany těchto dat.
12.8.1 Ověřit, zda je veden seznam poskytovatelů služeb.
Udržování přehledu o tom, kdo jsou poskytovatelé
služeb, identifikuje místo, kde potenciální riziko
přesahuje hranice organizace.
Poznámka: Pro potencionální pracovníky,
jako jsou například pokladní v obchodech,
kteří mají přístup vždy jen k jedné kartě při
provádění transakce, je tento požadavek
pouhým doporučením.
12.8Udržovat a implementovat politikya
procedurypro řízeníposkytovatelů služeb,
s nimiž jsou data držitelů karetsdílena,
nebokteří by mohlimít vliv
nabezpečnostdat držitelů karet, podle
12.8.1 Vést seznam poskytovatelů
služeb.
strana116
Duben 2015
PCI DSS Požadavky
12.8.2 Udržovat písemnou smlouvu,
která zahrnuje ujednání, že
poskytovatelé služeb jsou zodpovědní
za bezpečnost dat držitelů karet, kterými
poskytovatelé služeb disponují nebo
jinakuchovávají, zpracovávají
nebopřenášejíjménemzákazníka,
nebodoté míry, žeby mohli mít
vlivnabezpečnostprostředí dat držitelů
karetzákazníka.
12.8.2Prověřitpísemnédohodyapotvrdit, zda obsahují
ujednání ze stranyposkytovatelůslužeb, že jsou odpovědniza
bezpečnostdat držitelů karet, kterýmiposkytovatelé
služebdisponujínebo jinak uchovávají, zpracovávají
nebopřenášejíjménemzákazníka, nebodoté míry, žeby mohli
mít vliv na bezpečnostprostředí dat držitelů karetzákazníka.
Potvrzení poskytovatelů služeb dokládá jejich
závazek zachovávat náležitou bezpečnost dat
držitelů karet, která dostávají od svých klientů.
12.8.3 Ověřit, zda politiky a procedury jsou dokumentovány
a realizovány včetně řádného duediligence před zapojením
jakkéholiv poskytovatele služeb
Tento proces zajišťuje, aby organizace důkladně
interně prošetřila každé uzavřením závazku
poskytovatele služeb, což představuje analýzu
rizik ještě před tím, než s poskytovatelem služeb
naváže formální vztah.
Poznámka: Přesné zněníujednáníbude
závisetnadohodě mezi oběmastranami, s
uvedením podrobností o poskytované
službě a odpovědnostmi každé strany.
Ujednání nemusíobsahovatpřesné znění
uvedené v tomto požadavku.
12.8.3 Zajistit, aby byl zaveden proces
zapojení poskytovatelů služeb, včetně
due diligence před uzavřením závazku.
Vysvětlení
V souvislostisPožadavkem12.9, tento
požadavekpísemné dohody meziorganizacemi a
poskytovateli služeb je určenna podporujednotné
úrovněporozumění mezistranamiosvých
příslušnýchodpovědnostech dle standardu
PCIDSS.
Napříkladsmlouvamůžeobsahovatpříslušnépožad
avky PCIDSS, které musí být dodržoványjako
součástposkytované služby.
Specificképrocesy a cíle due diligence se budou
lišitpro každou organizaci. Příkladyke
zváženímohou zahrnovatposkytovatelovy postupy
pro podávání zpráv, procedury oznamování
narušení a reakce na incidenty, podrobnosti
otom, jakjsouodpovědnosti standardu PCIDSS
rozdělenymezi jednotlivéstrany,
jakposkytovatelověřujeshoduse standardem PCI
DSSajaké důkazybudou poskytovány, atd.
strana117
Duben 2015
PCI DSS Požadavky
12.8.4 Udržovat program k monitorování
statutu shody poskytovatele služeb se
standardem PCI DSS nejméně jedenkrát
ročně.
12.8.4 Ověřit, zda hodnocený subjekt udržuje program, který
monitoruje status shody jeho poskytovatele služeb se
standardem PCI DSS nejméně jedenkrát ročně.
12.8.5Udržovatinformaceo tom,
kterépožadavkyPCI DSS
jsouspravovanékaždým
poskytovatelemslužeb, akteréjsou
řízenysubjektem.
12.8.5Ověřit, zda subjektudržujeinformaceo tom,
kterépožadavkyPCIDSSspravujíjednotlivíposkytovatelé
služebakteréjsou řízenysubjektem.
Vysvětlení
Znalost statutu shody poskytovatele služeb se
standardem PCI DSS, poskytuje ujištění a
povědomí, zda poskytovatel služeb dodržuje
stejné požadavky, jaké musí plnit vaše
organizace. Pokud poskytovatel služeb nabízí
různé služby pak by se měl tento požadavek
vztahovat jen na služby dodané klientovi, a na
služby v rozsahu hodnocení standardu PCI DSS
klienta.
Specifické informace, které subjekt vede, budou
záviset na konkrétní dohodě s jejich poskytovateli
služeb, typu služeb, atd. Záměrem je, aby
posuzovaný subjekt porozuměl, u kterých
požadavků PCI DSS se dohodl s poskytovateli
služeb na jejich dodržování.
strana118
Duben 2015
PCI DSS Požadavky
12.9 Doplňková testovací procedura
platná pouze proposkytovatele služeb:
Poskytovatelé služebpísemně
potvrdízákazníkům, žejsou odpovědniza
bezpečnostdat držitelů karet, které
poskytovatel služebmá v držení nebojinak
uchovává, zpracovávánebo přenáší
jménemzákazníka,nebo v rozsahu, který
by mohl mít vlivnabezpečnostprostředí dat
držitelů karetzákazníka.
Poznámka: Tento požadavekje pokládán
za osvědčený postup do 30. června2015,
po tomto datu se stávápožadavkem.
12.9 Doplňková testovací procedura platná pouze
Přezkoumat politiku a procedury poskytovatele služeba
prověřit písemné předlohy dohod a potvrdit, zda
poskytovatelslužbypísemně potvrzuje zákazníkům, že
budedodržovatvšechny příslušné požadavkyPCIDSS v
rozsahuposkytovatele služeb držení, přístupu
nebojinéhouchovávání, zpracovávánínebo přenášení dat
držitelů karetzákazníkanebocitlivýchautentizačních dat, nebo
jménemzákazníka spravujících prostředí dat držitelů
karetzákazníka.
Poznámka: Přesné zněníujednáníbude
závisetnadohodě mezi oběmastranami, s
uvedení podrobností o poskytované
službě a odpovědnostmi každé strany.
Ujednání nemusíobsahovatpřesné znění
uvedené v tomto požadavku.
Vysvětlení
Poznámka: Tento požadavek se uplatňuje pouze
tehdy, pokud je posuzovaný subjekt
poskytovatelem služeb.
Ve spojení s Požadavkem 12.8.2, tento
požadavek je určenna podporujednotné
úrovněporozumění mezistranamiosvých
příslušnýchPCIDSSodpovědnostech. Potvrzení
poskytovatelů služeb dokládá jejich závazek
zachovávat náležitou bezpečnost dat držitelů
karet, která dostávají od svých klientů.
Měl by být dohodnuto, jakým
způsobemposkytovatel služby poskytnea předá
písemné potvrzenímezi poskytovatelem ajeho
zákazníky.
Interní politiky a procedury poskytovatele
služebvztahující sek jehoprocesu zapojení
zákazníkaa všechny používané šablony pro
písemnésmlouvyby měly obsahovat ustanovení o
zodpovědnosti poskytovatele dodržovat
požadavkyPCIDSS směrem ke svým zákazníkům.
Způsob, kterým poskytovatel služeb poskytuje
písemé potvrzení,musí být dohodnut mezi
poskytovatelem a jeho zákazníkem.
12.10 Implementovat plán odezvy při
incidentech. Být připraven neprodleně
reagovat na narušení systému.
12.10 Zkontrolovat plán odezvy a související procedury a
ověřit, zda je subjekt připraven okamžité odezvy na narušení
systému, provedením následujících bodů:
Bez důkladného plánu odezvy, který je náležitě
rozeslán, přečten a odpovědnými stranami
pochopen, by mohl zmatek a nejednotná reakce
způsobit další přerušení provozu společnosti na
delší dobu, zbytečnou expozici vůči veřejným
médiím a také nové právní závazky.
strana119
Duben 2015
PCI DSS Požadavky
12.10.1 Vytvořit plán odezvy, který bude
implementován v případě narušení
systému. Zajistit, aby plán řešil
minimálně následující body:
 Role, odpovědnosti, komunikační a
kontaktní strategie v případě
narušení včetně minimálně
vyrozumění kartových brandů
 Specifické procedury odezvy na
incidenty
 Procedury obnovení a zachování
kontinuity provozu
 Procesy zálohování dat
 Analýza legálních požadavků na
zprávy o narušení
 Pokrytí a reakce všech kritických
systémových komponent
 Odkazy nebo zahrnutí procedur
odezvy na incident od kartových
brandů.
12.10.1.a Ověřit, zda plán odezvy zahrnuje:
 Role, odpovědnosti, komunikační a kontaktní strategie v
případě narušení včetně minimálně vyrozumění
kartových brandů
 Specifické procedury odezvy na incidenty
Vysvětlení
Plán odezvy na incidenty by měl být důkladný a
měl by obsahovat všechny klíčové prvky
umožňující, aby společnost mohla v případě
narušení, které by mohlo mít dopad na data
držitelů karet, účinně reagovat.
 Procedury obnovení a zachování kontinuity provozu
 Procesy zálohování dat
 Analýza legálních požadavků na zprávy o narušení
(například zákon státu Kalifornie Bill 1386, který
požaduje vyrozumění postižených zákazníků v případě
aktuálního nebo domnělého narušení u jakéhokoliv
podniku, který má v databázi obyvatele Kalifornie)
 Pokrytí a reakce všech kritických systémových
komponent
 Odkazy nebo zahrnutí procedur odezvy na incident od
kartových brandů.
12.10.1.b Dotázat se pracovníků a prověřit dokumentaci z
nějakého vzorku dříve hlášeného incidentu nebo varování a
ověřit, zda byly dodrženy dokumentované plány odezvy a
procedury odezvy na incidenty.
12.10.2 Testovat plán nejméně jednou
ročně.
12.10.2 Ověřit, zda je plán testován nejméně jednou ročně.
Bez řádného testování mohou být vynechány
klíčové kroky, které by mohly zvýšit míru ohrožení
během incidentu.
12.10.3 Určit konkrétní pracovníky, kteří
budou k dispozici 24 hodin 7 dní v týdnu
(24/7), aby reagovali na varování.
12.10.3 Ověřit prostřednictvím sledování, přezkoumat
politiky a dotázat se odpovědných pracovníků, zda vybraní
pracovníci jsou dostupní na bázi 24/7 k odezvě na incidenty
detekcejakýchkoliv projevů neautorizované aktivity, zjištění
neautorizovaného bodu bezdrátového přístupu, kritického
varování (IDS) a/nebo hlášení neautorizované změny
kritického systému nebo změn obsahu souborů.
Bez vyškoleného a snadno dostupného týmu pro
reakci na incidenty by se mohly zvýšit škody na
síti a kritická data a systémy by mohly být
„zamořeny“ v důsledku nesprávného zacházení
s cílovými systémy. To může ztížit zdárné
vyšetřování prováděné po incidentu.
12.10.4 Poskytnout pracovníkům,
odpovídající za odezvu na narušení
bezpečnosti, příslušné školení.
politiky a dotázat se odpovědných pracovníků, zda
pracovníci, odpovídající za odezvu na narušení bezpečnosti,
jsou pravidelně školeni.
strana120
Duben 2015
PCI DSS Požadavky
12.10.5 Zahrnout varování z
bezpečnostních monitorovacích
systémů, které se týká kromě jiného
detekce narušení, prevence narušení,
firewallů a sledování integrity souborů.
12.10.5 Ověřit prostřednictvím sledování a přezkoumat
procesy, které monitorují a reagují na varování
z bezpečnostních monitorovacích systémů, zda jsou pokryty
v plánu odezvy.
Tyto monitorovací systémy jsou určeny
k zaměření na potenciální rizika pro data, mají
kritický význam pro provedení rychlých akcí, a
musejí být zahrnuty do procesů odezvy na
incidenty.
12.10.6 Vyvinout proces modifikace a
zdokonalení plánu odezvy podle
získaných poučení a přihlédnutím k
vývoji v oboru.
politiky a dotázat se odpovědných pracovníků, zda existuje
proces modifikace a vývoje plánu odezvy podle získaných
poučení a přihlédnutím k vývoji v oboru.
Zapracování „získaných poučení“ do plánu
odezvy pomáhá
udržetplánaktuálníaschopnýreagovat nanové
hrozbya bezpečnostnítrendy.
Vysvětlení
strana121
Duben 2015
Příloha A: Dodatečné požadavky PCI DSS na poskytovatele sdíleného hostingu
Požadavek A.1: Poskytovatelé sdíleného hostingu musí chránit prostředí dat držitelů karet
Jak uvádí Požadavek 12.8 a 12.9, všichni poskytovatelé služeb s přístupem k datům držitelů karet (včetně poskytovatelů sdíleného hostingu) musí
dodržovat standard PCI DSS. Kromě toho Požadavek 2.6 uvádí, že poskytovatelé sdíleného hostingu musí chránit hostingové prostředí a data
každého subjektu. Tudíž poskytovatelé sdíleného hostingu musí navíc splnit požadavky v této Příloze.
PCI DSS Požadavky
A.1Chránit hostingové prostředí a data
každého subjektu (tj. obchodníka,
poskytovatele služby nebo jiného
subjektu) podle bodůA.1.1 až A.1.4:
Poskytovatel hostingu musí splnit tyto
požadavky i všechny ostatní relevantní
sekce standardu PCI DSS.
A.1Zejména při posuzování PCI DSS poskytovatele sdíleného
hostingu ověřit, zda poskytovatelé sdíleného hostingu chrání
hostingové prostředí a data subjektů (obchodníků a poskytovatelů
služeb), vybrat vzorek serverů (Microsoft Windows a
Unix/Linux)z reprezentativního vzorku obchodníků a poskytovatelů
služeb, a provést kroky A.1.1 až A.1.4 níže:
Vysvětlení
Příloha A standardu PCIDSSjeurčena pro
poskytovatele sdíleného hostingu, kteří
chtějí poskytovat svým
obchodníkůma/neboposkytovatelůmslužeb
zákazníkůmprostředím hostingu v souladu
se standardemPCIDSS.
Poznámka: I když poskytovatel hostingu
může splnit tyto požadavky, není
zaručena shoda v jejich dodržování
subjektem, který využívá poskytovatele
hostingu. Každý subjekt musí vyhovět
požadavkům PCI DSS a náležitě
ověřovat shodu jejich dodržování.
A.1.1Zajistit, aby měl subjekt
v kompetenci pouze své vlastní
procesy, které mají přístup k prostředí
dat držitelů karet.
A.1.1 Pokud poskytovatel sdíleného hostingu umožní subjektům
(například obchodníkům nebo poskytovatelům služeb) spouštět
vlastní aplikace, ověřit, zda přístup do těchto aplikačních procesů je
možný pouze pomocí jedinečného ID pro daný subjekt. Například:
 Žádný subjekt v systému nemůže používat sdílené ID uživatele
webového serveru.
Je-liobchodníkovineboposkytovateli služeb
umožněnospouštět vlastní
aplikacenasdíleném serveru, tyto by měly
být spouštěny pod uživatelským jménem
IDobchodníkanebo poskytovatele služeb,
spíše než podprivilegovaným uživatelem.
 Všechny CGI skripty používané subjektem musí být vytvořeny
a spouštěny pod jedinečným uživatelským ID subjektu.
strana122
Duben 2015
PCI DSS Požadavky
A.1.2Omezit přístup a
oprávněníkaždéhosubjektu pouze na
jeho vlastní prostředí dat držitelů karet.
A.1.2.a Ověřit, zda uživatelské jméno ID jakéhokoliv aplikačního
procesu není privilegovaný uživatel (kořenový
přístup/administrátor).
A.1.2.bOvěřit, zda každý subjekt (obchodník, poskytovatel služby)
má oprávnění ke čtení, zápisu nebo spouštění pouze pro soubory a
adresáře, které vlastní nebo pro nezbytné systémové soubory
(přístup omezen prostřednictvím oprávnění k systémovým
souborům, seznamům kontroly přístupu, funkce chroot, jailshell,
atd.).
Vysvětlení
Chcete-li zajistit, aby přístup aoprávnění
byla omezenatak,
žekaždýobchodníkneboposkytovatel
služebmápřístup pouzeke svémuvlastnímu
prostředí, zvažte následující body:
1.
Zvýhodnit uživatelské ID webového
serveru obchodníka neboposkytovatele
služeb;
2.
Privilegia uživatelského ID na
webovém serveru obchodníka
neboposkytovatele služeb;
A.1.2.c Ověřit, zda uživatelé subjektu nemají přístup k zápisu do
sdílených systémových binárních kódů.
3.
Udělená oprávněníčíst,
zapisovataspouštět soubory;
A.1.2.d Ověřit, zda prohlížení logů je omezeno na vlastnící subjekt.
4.
Udělenáoprávnění zapisovat
dosystémovýchbinárních souborů;
5.
Udělenáoprávnění k
souborůmprotokolů (log files)
obchodníkaa poskytovatele služeb; a
6.
Kontrolyk zajištění toho,
abyjedenobchodníknebo poskytovatel
služebnemohlmonopolizovatsystémové
zdroje.
Důležité: Soubory subjektu nesmí být sdíleny skupinou.
A.1.2.eZajistit, aby žádný subjekt nemohl monopolizovat serverové
zdroje k využívání zranitelných míst (například chyba, usměrnění
chodu a podmínky restartu, což vše může vést například
k přetečení vyrovnávací paměti, buffer overflows) a ověřit, zda je
dodržováno omezení používání těchto systémových zdrojů:
 Prostor na disku
 Šířka pásma
 Paměť
 CPU
A.1.3 Zajistit, aby přihlašovací a auditní
záznamy byly aktivované a jedinečné
pro prostředí dat držitelů karet každého
subjektu a konzistentní s PCI DSS
Požadavkem 10.
A.1.3 Ověřit, zda poskytovatel sdíleného hostingu aktivoval
přihlašování (logging) následujícím způsobem pro prostředí
každého obchodníka a poskytovatele služby:
 Logy jsou aktivovány pro společné aplikace třetí strany.
 Logy jsou aktivní již podle výchozího nastavení (defaultu).
Logyby měly býtk dispoziciv prostředí
sdílenéhohostingu, takže obchodnícia
poskytovatelé služebmajípřístup k
logůmspecifických projejichprostředí dat
držitelů karet, amohou je prohlížet.
 Logy jsou k dispozici ke sledování subjektu, který je vlastní.
 Umístění logů je zřetelně komunikováno subjektu, který je
vlastní.
strana123
Duben 2015
PCI DSS Požadavky
A.1.4Umožnit, aby procesy umožnily
včasné forenzní šetření v případě
narušení u jakéhokoli obchodníka nebo
poskytovatele služby.
A.1.4 Ověřit, zda poskytovatel sdíleného hostingu vytvořil politiku,
umožňující v případě narušení včasné forenzní šetření postižených
serverů.
Vysvětlení
Poskytovatelé sdíleného hostingu musí
mítprocesyposkytují rychloua snadnou
odezvuv případě, žeje
potřebaforenzníhošetření narušení, a to až
na odpovídající úroveň údajů tak,aby byly
k dispozici
údajejednotlivéhoobchodníkanebo
poskytovatelem služeb.
strana124
Duben 2015
Příloha B: Náhradní řešení
Náhradní řešení může být zvažováno pro většinu požadavků PCI DSS, pokud subjekt nemůže splnit
požadavek přesně tak, jak je stanoven, a to z důvodu legitimních technických nebo dokumentovaných
provozních překážek, avšak dostatečně zmírnil riziko spojené s požadavkem zavedením náhradního
řešení.
Náhradní řešení musí splňovat následující kritéria:
1. Splňovat smysl a vyhovovat náročnosti původního požadavku PCI DSS.
2. Poskytovat obdobnou úroveň ochrany jako původní požadavek PCI DSS a dostatečně eliminovat
riziko, proti němuž byl konstruován původní požadavek PCI DSS. (Vysvětlení smyslu každého
požadavku PCI DSSviz materiál Porozumnění záměru požadavků - Navigation PCI DSS)
3. Být „nad rámec” dalších požadavků PCI DSS. (Být ve shodě s ostatními požadavky PCI DSS není
náhradní řešení).
Při posuzovánínáhradního řešení „nad rámec” zvážit následující:
Poznámka: Body a) až c) níže jsou míněny pouze jako příklady. Všechna náhradní řešení musí být
revidována a potvrzena ohledně dostatečnostihodnotitelem, který zpracováváposouzení dle PCI DSS.
Efektivita náhradního řešení závisí na specifikách prostředí, v němž je řešeníimplementováno, ostatních
bezpečnostních kontrolních opatření a konfiguraci náhradního řešení. Společnosti by si měly
uvědomovat, že konkrétní náhradní řešenínebude efektivní v každém prostředí.
a) Stávající požadavky PCI DSS NEMOHOU být považovány za náhradní řešení, jestliže jsou pro
hodnocenou položku již požadovány. Například hesla pro neterminálový administrativní přístup
musí být odesílána šifrovaná ke zmírnění rizika narušení správcovských hesel v nešifrovaném
(clear) textu. Subjekt nemůže použít jiné požadavky PCI DSS na heslo (uzamčení neoprávněné
osoby, komplexní hesla, atd.) ke kompenzaci absence šifrovaných hesel, protože tyto jiné
požadavky nezmírňují riziko narušení hesla v nešifrovaném (clear) textu. Další kontrolou hesel
jsou již PCI DSS požadavky pro sledovanou položku (hesla).
b) Stávající požadavky PCI DSS MOHOU být považovány za náhradní řešení, jestliže jsou
požadovány pro jinou oblast, ale nejsou vyžadovány pro hodnocenou položku. Například
dvoufaktorová autentizace (ověření identity) je PCI DSS požadavek pro vzdálený přístup.
Dvoustupňová autentizacez interní sítě může být rovněž považována za náhradní řešenípro
neterminálový administrativní přístup, když přenos šifrovaných hesel nemůže být podporován.
Dvoustupňová autentizace může být přijatelným náhradním řešením, pokud (1) splňuje smysl
původního požadavku řešením rizika narušení správcovských hesel v nešifrovaném (clear) textu;
a (2) je odpovídajícím způsobem nastavena v bezpečném prostředí.
c) Stávající požadavky PCI DSS mohou být kombinovány s novými kontrolami a stát se náhradním
řešením. Například jestliže společnost není schopna učinit data držitelů karet nečitelnými podle
požadavku 3.4 (například zašifrováním), náhradním řešením může být zařízení nebo kombinace
zařízení, aplikací a kontrol řešících vše následující: (1) interní síťovou segmentaci; (2) filtrování IP
adres nebo MAC adres; a (3) dvoustupňovou autentizaci v rámci interní sítě.
4. Být si vědomi dalších rizik, které mohou být vyvolány nedodržením požadavků PCI DSS.
Hodnotitel musí důkladně vyhodnotit náhradní řešeníběhem každého ročního posuzování dle PCI DSS a
potvrdit tak, že každé náhradní řešeníadekvátně řeší riziko, proti němuž byl konstruován původní
požadavek PCI DSS podle bodů 1 - 4 výše. Pro udržení shody musí být zavedeny procesy a kontroly,
které zajistí, že náhradní řešení zůstane efektivní i po ukončení posuzování.
strana125
Listopad 2013
Příloha C: Pracovní tabulka náhradního řešení
Tuto tabulku používejte k definování náhradního řešenípožadavku, u kterého je využito náhradního
řešení ke splnění požadavku PCI DSS.Uvědomte si, že náhradní řešeníby mělo být také dokumentováno
ve Zprávě o shodě v sekci odpovídajícího požadavku PCI DSS.
Poznámka: Pouze společnosti, které podstoupily analýzu rizik a mají legitimní technologické nebo
dokumentované provozní obtíže, mohou při plnění shody uvažovat o náhradním řešení.
Číslo a definice požadavku:
Požadovaná informace
1. Omezení
Sestavit seznam omezení znemožňující
shodu s původním požadavkem.
2. Cíl
Definovat cíle původního požadavku,
identifikovat cíl splněného náhradním
řešením.
3. Identifikované
riziko
Identifikovat jakéhokoliv další rizika
způsobená absencí původní kontroly.
4. Definice
Náhradního řešení
Definovat náhradní řešení a vysvětlit
způsob, jakým jsou řešeny cíle
původního požadavku a případná
zvýšená rizika.
5. Ověření
Definovat, jak bude náhradní řešení
ověřeno a testováno.
6. Správa
Definovat uplatňované procesy a
kontrolních opatření na správu
náhradního řešení.
Vysvětlení
Stránka126
November 2013
Pracovní tabulka náhradního řešení – Vzor
Tuto tabulku používejte k definici náhradního řešení pro jakýkoliv požadavek, kde bylo zaškrtnuto „ANO
prostřednictvím náhradního řešení.
Číslo požadavku:8.1.1—Jsou všichni uživatelé identifikováni jedinečným uživatelským jménem, než jim
je umožněn přístup k systémovým komponentům nebo datům držitelů karet?
Požadovaná informace
Vysvětlení
1. Omezení
Sestavit seznam omezení
znemožňující shodu
s původním požadavkem.
Společnost XYZ využívá samostatné Unix Servery
bez LDAP. Jako takové každý vyžadují „kořenové”
heslo. Není možné, aby Společnost XYZ
spravovala „kořenové” heslo, ani není
realizovatelné přihlašovat všechny „kořenové”
aktivity každým uživatelem.
2. Cíl
Definovat cíle původního
požadavku, identifikovat cíl
splněného náhradním
řešením.
Cíl požadavku jedinečných hesel je dvojí. Není
z bezpečnostního hlediska považováno za
přijatelné sdílet přihlašovací údaje ke vstupu.
Sdílené heslo navíc znemožňuje definitivní určení
osoby zodpovědné za konkrétní akci.
3. Identifikované
riziko
Identifikovat jakéhokoliv
další rizika způsobená
absencí původní kontroly.
Další riziko způsobuje systému kontroly přístupu
nezajištění jedinečných ID pro všechny uživatele,
které tak není možné spolehlivě vysledovat.
4. Definice
Definovat náhradní řešení a
vysvětlit způsob, jakým jsou
řešeny cíle původního
požadavku a případná
zvýšená rizika.
Společnost XYZ bude požadovat, aby se všichni
uživatelé přihlašovali do serverů využitím svých
přihlašovacích účtů a pomocí příkazu „sudo“ ke
spuštění jakýchkoliv administrátorských příkazů. To
umožňuje využití privilegií nastavených ke
„kořenovému“ účtu ke spuštění předdefinovaných
příkazů, Provádění je bezpečnězaznamenáno. Tím
způsobem mohou být všechny uživatelské aktivity
sledovány dle jednotlivých uživatelských účtů, aniž
by bylo „kořenové“ heslo sdíleno uživateli.
5. Ověření
Definovat, jak bude náhradní
řešení ověřeno a testováno.
Společnost XYZ dokazuje hodnotiteli, že příkaz
„sudo“ je nastaven správně a využívá „sudoers“
soubor, který může spouštět pouze předdefinované
příkazy stanovenými uživateli a všechny aktivity
prováděné těmito jednotlivci jsou zaznamenávány
a umožňují tak identifikaci osoby, která provádí
akce pod kořenovými privilegii.
6. Správa
Definovat uplatňované
procesy a kontrolních
opatření na správu
náhradního řešení.
Společnost XYZ dokumentuje procesy a procedury,
aby zajistila, že konfigurace „sudo“ se nebudou
měnit, narušovat ani odstraňovat a neumožní se
tak jednotlivcům provádění kořenových příkazů bez
možnosti identifikace, vysledování nebo přihlášení
jednotlivce.
Stránka127
November 2013
Příloha D:Segmentace a výběru vzorků provozních objektů/systémových komponent
Page 128
November 2013

PCI DSS - PCI Security Standards Council

Transkript

Podobné dokumenty

PCI Repafast ® Tixo - Severní stavební, as

PCI Repafast ® Fluid - Severní stavební, as