Data Security Standard Standard bezpečnosti dat (DSS)

Transkript

Payment Card Industry (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
Verze 3.0
Listopad 2013
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 Security Assessment
Procedures”) 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 Summary of Changes from 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.
Payment Card Industry (PCI) Data Security Standard, v3.0
© 2006-2013 PCI Security Standards Council, LLC. All Rights Reserved.
strana 2
Listopad 2013
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 ....................................................................................................................................................................................... 35
Požadavek 3: Chránit uchovávaná data držitelů karet .............................................................................................................................................. 35
Požadavek 4: Zašifrovat přenos dat držitelů karet po otevřených veřejných sítích .................................................................................................. 48
Udržování programu kontroly zranitelnosti ........................................................................................................................................................... 50
Požadavek 5: Chránit všechny systémy proti malware a pravidelně aktualizovat antivirový software nebo programy............................................ 50
Požadavek 6: Vyvíjet a udržovat bezpečné systémy a aplikace ............................................................................................................................... 54
Zavedení přísných opatření a kontrol přístupů ..................................................................................................................................................... 66
Požadavek 7: Omezit přístup k datům držitelů karet jen podle oprávněné potřeby .................................................................................................. 66
Požadavek 8: Identifikovat a autentizovat přístup k systémovým komponentám ..................................................................................................... 69
Požadavek 9: Omezit fyzický přístup k datům držitelů karet ..................................................................................................................................... 79
strana 3
Listopad 2013
Pravidelné monitorování a testování sítí ............................................................................................................................................................... 88
Požadavek 10: Sledovat a monitorovat všechny přístupy k síťovým zdrojům a datům držitelů karet ...................................................................... 88
Požadavek 11: Pravidelně testovat bezpečnostní systémy a procesy ..................................................................................................................... 96
Udržování politiky bezpečnosti informací ........................................................................................................................................................... 104
Požadavek 12: Udržovat politiku zaměřenou na bezpečnost informací pro všechny pracovníky .......................................................................... 104
Požadavek A.1: Poskytovatelé sdíleného hostingu musí chránit prostředí dat držitelů karet ................................................................................. 114
Příloha B: Náhradní řešení ............................................................................................................................................................ 117
Příloha C: Pracovní tabulka náhradního řešení ........................................................................................................................... 118
Příloha D: Segmentace a výběru vzorků provozních objektů/systémových komponent.......................................................... 120
strana 4
Listopad 2013
Ú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. 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ů
Ochrana dat držitelů karet
Udržování programu
kontroly zranitelnosti
Zavedení přísných opatření a
kontrol přístupů
Pravidelné monitorování a
testování sítí
Udržování politiky
bezpečnosti informací
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
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
strana 5
Listopad 2013
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 standardu PCI 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 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 identifikačních osobních informací 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áva o 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ých hodnotitelů 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)
strana 6
Listopad 2013
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ů.
strana 7
Listopad 2013
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ů), finančních
institucí a poskytovatelů služeb, a také všech dalších subjektů, 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:
Citlivá autentizační data
Data držitele karet zahrnují:

Číslo karty (PAN, Primary Account
Number)

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) 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 a prostředí, 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í CDE 1. Organizace, které outsourcovali správu svého prostř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.)
strana 8
Listopad 2013
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 čipu 3
Ne
Podle Požadavku 3.2 nelze uchovávat
CAV2/CVC2/CVV2/CID 4
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í data nesmí 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/Personal Identification Number) 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.
strana 9
Listopad 2013
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, zda platební 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).
strana 10
Listopad 2013
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ých mí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ím by 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 budou zahrnuta 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šechny vý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.
strana 11
Listopad 2013
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 rozsah posouzení 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í hodnotitel ověřit, zda je
segmentace dostatečná ke snížení rozsahu vyhodnocení. 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 nebo je na ně napojena, platí zde požadavky a testovací postupy standardu PCI DSS pro 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.
strana 12
Listopad 2013
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ím skenování zranitelnosti a za které IP adresy má odpovědnost zákazník, aby je
zahrnul do svého vlastního čtvrtletního skenování.
Pro třetí strany - poskytovatele služeb se nabízejí dvě možnosti, jak ověřovat shodu:
1) Mohou provést posouzení shody s PCI DSS samy a předložit potvrzení svým zákazníkům jako důkaz shody, nebo
2) Pokud nepodstoupí vlastní posouzení shody s PCI DSS, budou si muset nechat své služby prověřit během posouzení shody s PCI DSS u
každého ze svých zákazníků.
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.
strana 13
Listopad 2013
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 PCI DSS implementovány do běžných provozních
procesů (Business-as-usual, BAU) jako součást celkové bezpečnostní strategie subjektu. Subjektu to umožní průběžně sledovat účinnost svých
bezpečnostních kontrol a udržovat své prostředí ve shodě s PCI DSS mezi jednotlivými vyhodnoceními dle PCI DSS. Příklady toho, jak by PCI
DSS mělo být začleněno do běž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. Měly by se provádět pravidelné přezkumy 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í.
strana 14
Listopad 2013
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.
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říklad v 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ích procesů jsou
poskytnuty pouze jako doporučení a vysvětlení a nenahrazují ani nerozšiřují požadavky PCI DSS.
strana 15
Listopad 2013
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ž je pro hodnotitele přijatelné vybrat vzorky provozních zařízení / systémových komponent jako součást jejich přezkumu shody PCI DSS u
subjektu, pro subjekt není přijatelné aplikovat požadavky PCI DSS pouze na vzorek jejich prostředí (například požadavky na čtvrtletní skenování
zranitelnosti platí pro všechny komponenty systému). Stejně tak není přijatelné pro hodnotitele přezkoumat pouze vzorek požadavků standardu
PCI DSS.
Vzhledem k celkovému rozsahu a složitosti posuzovaného prostředí, může hodnotitel nezávisle zvolit reprezentativní vzorky provozních zařízení /
systémových komponent s cílem posoudit soulad subjektu s požadavky PCI DSS. Tyto vzorky musí být definovány nejprve pro provozní objekt a
pak pro systémové komponenty v rámci každého vybraného provozního zařízení. Vzorky musí být reprezentativním výběrem ze všech druhů a
umístění provozních zařízení, stejně jako ze všech druhů systémových komponent v rámci vybraných provozních objektů. Vzorky musí být
dostatečně rozsáhlé, aby poskytly hodnotiteli 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ůže definovat 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ích objektů / 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, zda
standardizované, 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.
strana 16
Listopad 2013

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 vzorku a jeho reprezentativnost vzhledem k celkovému množství.
Hodnotitel musí zdůvodnit výběr vzorků při každém vyhodnocení. Má-li se použít metoda výběru vzorků, 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ěn Pracovní 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.
strana 17
Listopad 2013
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. Pokud je to nutné, proveďte nápravu všech chybějících položek.
4. Dokončete příslušnou zprávu o posouzení (tj. Dotazník vlastního hodnocení, Self-Assessment Questionnaire (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.
5. Dokončete Osvědčení o shodě (Attestation of Compliance) 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.
6. Předložte dotazníky SAQ nebo Zprá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).
strana 18
Listopad 2013
Podrobné požadavky a postupy posouzení bezpečnosti PCI DSS
Pro požadavky a postupy posouzení bezpečnosti PCI 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 na PCI 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).
strana 19
Listopad 2013
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ím webové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.1 Zavést konfigurační standardy pro
firewally a routery, které zahrnují
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,
strana 20
Listopad 2013
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.
což by mohlo vést k rozporuplnosti mezi
dokumentací sítě a skutečnou konfigurací.
1.1.2.a Prověř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.b Dotá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.3 Zkontrolovat 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.a Zkontrolovat 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.b Ověř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ě.
strana 21
Listopad 2013
PCI DSS Požadavky
1.1.5 Popis skupin, rolí a odpovědností
pro správu síťových komponent
1.1.5.a Ověřit, zda konfigurační standardy firewallů a routerů
zahrnují popis skupin, rolí a odpovědností pro správu
komponent sítě.
1.1.5.b Dotá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.
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.c Prověř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.
strana 22
Listopad 2013
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í
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.b Zkontrolovat 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.2 Vytvoř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.2 Prověř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ému subjektu
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ídaly
provozní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 omezoval
př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.b Zkontrolovat 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.
strana 23
Listopad 2013
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 a prostř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ů) pouze autorizované přenosy
mezi bezdrátovým prostředím a
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, zda firewally 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.
strana 24
Listopad 2013
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.
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:
Vysvětlení
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.1 Implementovat 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.1 Zkontrolovat 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.2 Omezit 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.3 Nepř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šech příchozích a odchozích připojení
umožňuje přezkoumat a omezit přenosy na
základě zdrojové a/nebo cílové adresy, jakož i
přezkoumat a blokovat nežádoucí obsah, čímž se
zabrání nefiltrovanému přístupu mezi
nedůvěryhodným a důvěryhodným prostř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.
strana 25
Listopad 2013
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.)
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 obsahuje IP adresu počítače, který
jej původně poslal, aby ostatní počítače v síti
poznali, odkud paket přišel. Zlovolní jedinci se
často snaží zfalšovat (spoofing) (neboli
napodobovat) odesílací IP adresu, aby se cílový
systém domníval, že paket pochází z
důvěryhodného zdroje.
Filtrování paketů, přicházejících do sítě, pomáhá
mimo jiné zajistit, že pakety nejsou "zfalšované",
aby předstíraly, že jsou zasílány z vlastní vnitřní
sítě organizace.
1.3.5 Nepovolit 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 spojena
s 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.
strana 26
Listopad 2013
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ů karet v
zóně interní sítě, oddělené od DMZ a dalších
nedůvěryhodných sítí pomocí firewallu, může
zabránit neoprá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.8 Nezpří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.b Dotá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í subjekty je autorizováno.
Omezení zveřejnění interních nebo privátních IP
adres je 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říklad kontroly
používané ke splnění tohoto požadavku mohou
být odlišné pro sítě IPv4 než pro sítě IPv6.
strana 27
Listopad 2013
PCI DSS Požadavky
1.4 Instalovat 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ány a
známy všem dotčeným stranám.
1.4.a Zkontrolovat 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 (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.b Prověř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.5 Zkontrolovat 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řipojit na 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 k síti organizace může vést k povolení
přístupu útočníkům a 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.
strana 28
Listopad 2013
Požadavek 2: Nepoužívat výchozí nastavení od dodavatele pro 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.1 Vž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.a Vybrat vzorek systémových komponent, a přihlásit se na
zařízení (s pomocí správce systému) a do aplikací využívající
výchozí účty od dodavatele a 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émy mé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í) účet není určen k
používání, změnou výchozího hesla na odolné
unikátní heslo a posléze deaktivace účtu
zabráníme zlovolnému jedinci opětovné zapnutí
účtu a získání přístupu s 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ě.
strana 29
Listopad 2013
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.a Dotá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-li bezdrátové sítě implementovány s
dostatečnou bezpečnou konfigurací (včetně
změny výchozích nastavení), mohou bezdrátoví
špioni odposlouchávat přenosy, snadno zachytit
data a hesla a snadno vstoupit a zaútočit na síť.
Kromě toho, protokol pro výměnu klíčů pro starší
verze šifrování 802.11x (Wired Equivalent
Privacy, neboli WEP) byl prolomen a může
způsobit neúčinnost šifrování. Firmware pro
zařízení by mělo být aktualizováno, aby
podporovalo bezpeč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.c Zkontrolovat 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.d Zkontrolovat 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.e Zkontrolovat dokumentaci dodavatele, prověřit
nastavení bezdrátové konfigurace a podle situace ověřit, zda
další bezpečnostní bezdrátová defaultní nastavení dodavatele
byla změněna.
strana 30
Listopad 2013
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.a Zkontrolovat 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.
strana 31
Listopad 2013
PCI DSS Požadavky
2.2.1 Implementovat 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.a Vybrat 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.
Pokud serveru funkce, které vyžadují různé
úrovně zabezpečení, jsou umístěny na stejném
serveru, úroveň zabezpečení funkcí s vyššími
bezpečnostními potřebami bude snížena v
důsledku přítomnosti funkcí s nižší bezpečnostní
úrovní. Navíc serverové funkce s nižší úrovní
zabezpečení mohou vyvolat bezpečnostní slabiny
u dalších funkcí na stejném serveru. Tím, že se
zváží potřeby zabezpečení různých serverových
funkcí, jako součást konfiguračních standardů
systému a souvisejících procesů, mohou
organizace zajistit, že funkce, které vyžadují různé
úrovně zabezpečení nebudou existovat na
stejném serveru.
2.2.1.b Jsou-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, SSL, nebo IPSec VPN k ochraně nezabezpečených služeb,
jako jsou NetBIOS, sdílení souborů,
Telnet, FTP, apod.
2.2.3 Přezkoumat nastavení konfigurace a ověřit, zda
bezpečnostní prvky jsou dokumentovány a implementovány
pro všechny nezabezpečené služby, démony nebo protokoly.
2.2.4 Konfigurovat bezpečnostní
parametry systému k zabránění
zneužití.
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.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ě.
Konfigurační standardy systémů a souvisejících
procesů by se měly výslovně zaměřit na
(Pokračování na další straně)
strana 32
Listopad 2013
PCI DSS Požadavky
2.2.4.b Zkontrolovat konfigurační standardy systémů a ověřit,
zda obsahují obvyklé bezpečnostní parametry.
2.2.4.c Vybrat vzorek systémových komponent, přezkoumat
obecné bezpečnostní parametry a ověřit, zda jsou správně
nastaveny a v souladu s konfigurací.
2.2.5 Odstranit 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.a Vybrat 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.).
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 SSL/TLS pro správu sítě a další
nekonzolové administrativní přístupy.
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í.
Vysvětlení
bezpečnostní nastavení a parametry, které jsou
známy jako bezpečnostní rizika u každého
použitého typu systému.
Aby byly systémy bezpečně konfigurovány,
pracovníci odpovědní za konfiguraci a/nebo
administraci systémů musí být seznámeni s
konkrétními bezpečnostními parametry a
nastaveními, které se vztahují k určitému
systému.
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.
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 autentizaci a šifrovanou
komunikaci, citlivé informace na administrativní a
provozní úrovni (jako jsou jména a hesla
administrátora) mohou být odhalena špiony.
Zlovolný jedinec by mohl tyto informace použít k
přístupu na síť, stát se správcem a ukrást data.
Nezašifrované protokoly (jako jsou HTTP, telnet,
atd.) nemají šifrované přenosy nebo přihlašovací
údaje (logon), takže je pro špiona snadné zachytit
tuto 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.
strana 33
Listopad 2013
PCI DSS Požadavky
2.3.d Zkontrolovat dokumentaci dodavatele, dotázat se
personálu a ověřit, zda je implementována odolná
kryptografie pro použitou technologii v souladu s odvětvovými
osvědčenými postupy a/nebo doporučeními dodavatele.
2.4 Udržovat soupis systémových
komponent, které jsou v rozsahu PCI
DSS.
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.b Dotázat se pracovníků a ověřit, zda dokumentovaný
soupis je udržován aktuální.
provozní postupy pro správu defaultního
(výchozího) nastavení od dodavatelů a
dalších bezpečnostních parametrů byly
dokumentovány, používány a známy
všem dotčeným stranám.
2.5 Zkontrolovat dokumentaci, dotázat se personálu a ověřit,
zda jsou bezpečnostní politiky a provozní postupy pro správu
výchozího nastavení (defaultů) od dodavatelů a další
bezpečnostní parametry:
2.6 Poskytovatelé 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.6 Prové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ým stranám.
Vysvětlení
(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ů.)
Udržování aktuálního soupisu všech systémových
komponent umožní organizaci přesně a efektivně
definovat rozsah jejich prostředí pro zavedení
(implementaci) kontrol PCI DSS. Bez soupisu by
některé součásti systému mohly být zapomenuty,
a neúmyslně vyloučeny z konfiguračních
standardů organizace.
Pracovníci si musí být vědomi a provádět
bezpečnostní politiky a denní provozní postupy,
které zajistí, že výchozí nastavení (defaulty) od
dodavatelů a další bezpečnostní parametry jsou
plynule ří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ů.
strana 34
Listopad 2013
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ých technologií 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
provozní účely.
• Procesy pro bezpečné mazání dat
jakmile nejsou zapotřebí.
3.1.a
Zkontrolovat politiky, procedury a procesy ukládání a mazání
dat a ověřit, zda zahrnují alespoň následující body:
• Právní, regulační a provozní požadavky 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ů
• Pokrytí všech úložišť dat držitelů karet
• Č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ů
karet je nezbytné, aby mohla být správně
strana 35
Listopad 2013
PCI DSS Požadavky
• Specifické požadavky na uchovávání
dat držitelů karet.
• Č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.b Dotá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.
• Čtvrtletní automatický nebo manuální proces se provádí nad
všemi úložišti dat držitelů karet.
3.1.c U 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.
Vysvětlení
zachována nebo odstraněna, pokud již nejsou
potřebná. Aby bylo možné definovat příslušné
(Pokračování na další straně)
požadavky na uchovávání, subjekt musí nejprve
pochopit své vlastní provozní potřeby, stejně jako
všechny právní a regulační povinnosti, které se
vztahují k jejich odvětví, a/nebo které se vztahují
k typu uchovávaných dat.
Identifikace a vymazání uložených dat, která
překročila svou stanovenou dobu uchovávání,
zabraňuje zbytečnému uchovávání dat, která již
nejsou zapotřebí. Tento proces může být
automatický nebo manuální nebo kombinací
obojího. Například by bylo možné provést
programovou proceduru (automatickou nebo
manuální) a najít a odstranit data a/nebo
manuálně přezkoumat oblasti uklá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řijata citlivá autentizační
data, po ukončení autorizačního procesu
zajistěte, aby se data nedala obnovit.
3.2.a U 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.
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í
• Data jsou bezpečně uložena.
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í generovat padělané platební
karty a vytvářet podvodné transakce.
3.2.b Pro vydavatele a/nebo společností, které podporují služby
vydávání karet a uchová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í karty nebo které
vykonávají nebo podporují služby vydávání karet,
budou často vytvářet a kontrolovat citlivá
autentizační data jako součást funkce vydávání
strana 36
Listopad 2013
PCI DSS Požadavky
Citlivá autentizační data obsahují data
uvedená v následujících Požadavcích
3.2.1 až 3.2.3:
3.2.c Pro 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í
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ýt uchová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.d Pro 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.
Subjektům, které nevydávají karty, není dovoleno
uchovávat citlivá autentizační data po autentizaci.
strana 37
Listopad 2013
PCI DSS Požadavky
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). 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.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.
3.2.1 U vzorku systémových komponent zkontrolovat zdroje
dat včetně, ale nikoli výlučně, následujících bodů 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:
Vysvětlení
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í.
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é)
Úč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
strana 38
Listopad 2013
PCI DSS Požadavky
Vysvětlení
3.2.3 Neuchovávat osobní identifikační
číslo (PIN) ani zašifrovaný PIN blok.
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:
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).
odstraňování chyb, chybové)
• 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
požadavky brandu platebních karet pro
stvrzenky na prodejních místech (POS).
3.3.a Zkontrolovat písemné politiky a postupy pro maskování
zobrazení čísel karet (PAN) a ověřit:
• Seznam rolí, které potřebují přístup k zobrazení plného čísla
karty, je dokumentováno, spolu s legitimní provozní
potřebou každé role mít takový přístup.
• Číslo karty musí být při zobrazení maskováno tak, že pouze
pracovníci s legitimní provozní potřebou mohou vidět celé
číslo karty.
• Všechny ostatní role, které nemají výslovné oprávnění pro
zobrazení plného čísla karty musí vidět pouze maskovaná
čísla karet.
3.3.b Zkontrolovat 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.
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
karty, které je zobrazeno na 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.c Zkontrolovat 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.
strana 39
Listopad 2013
PCI DSS Požadavky
3.4 Uč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)
3.4.a Zkontrolovat 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.c Zkontrolovat 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.
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ů.
strana 40
Listopad 2013
PCI DSS Požadavky
• Silná kryptografie s příslušnými
procesy a postupy managementu
klíčů
3.4.d Zkontrolovat vzorek auditních záznamů a potvrdit, zda je
číslo karty učiněno nečitelným nebo odstraněno ze záznamů.
Poznámka: Pro podvodníka je relativně
jednoduché rekonstruovat původní číslo
karty, pokud mají přístup jak
k odříznutému číslu karty tak k jeho
hashované verzi. Pokud jsou v prostředí
subjektu y 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.
Vysvětlení
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
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
strana 41
Listopad 2013
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.b Př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 spojen nebo
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.
strana 42
Listopad 2013
PCI DSS Požadavky
3.5 Dokumentovat a implementovat
procedury k ochraně klíčů používaných k
zabezpečení uchovávaných dat držitelů
karet proti odhalení a zneužití.
Omezit přístup k šifrovacím klíčům na co
nejnižší možný počet administrátorů
(správců).
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.
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:
• Přístup ke klíčům je omezen na co nejmenší počet správců.
• 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ženy odděleně od klíčů pro
šifrování dat.
• Klíče jsou bezpečně uloženy na co nejmenším počtu
možných míst a forem.
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.1 Omezit přístup k šifrovacím
klíčům na co nejnižší počet
administrátorů (správců).
3.5.1 Prověř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žuje potenciální riziko
pro zpřístupnění dat držitelů karet neoprávněnými
osobami), obvykle jen ti, kteří mají odpovědnosti
správce klíčů (key custodian).
3.5.2.a Uchová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.a Zkontrolovat 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é s klíčem pro šifrování klíčů, který je
přinejmenším stejně odolný jako klíč pro šifrování dat, a
který je uložen odděleně od klíče pro šifrování dat.
• V rámci bezpečného šifrovacího prostředku (např. jako je
šifrovací modul Host Security Module (HSM), nebo zařízení
point-of-interaction schválené PTS)
• Jako komponenty klíčů (key components) nebo sdílené
klíče (key shares), v souladu s metodou př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
klíčům.
• Zašifrované s klíčem pro šifrování
klíčů, který je přinejmenším stejně
odolný jako klíč pro šifrování dat, a
který je uložen odděleně od klíče pro
šifrování dat.
strana 43
Listopad 2013
PCI DSS Požadavky
• V rámci bezpečného šifrovacího
prostředku (např. jako je šifrovací
modul Host Security Module (HSM),
nebo zařízení point-of-interaction
schválené PTS)
• Jako minimálně dvě komponenty
plné délky (full-length key
components) nebo sdílené klíče (key
shares), v souladu s metodou
př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í.
Vysvětlení
3.5.2.b Zkontrolovat 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í:
• Zašifrované klíčem pro šifrování klíčů
• V rámci bezpečného šifrovacího prostředku (např. jako je
šifrovací modul Host Security Module (HSM), nebo
zařízení point-of-interaction schválené PTS)
• Jako klíčové komponenty (key components) nebo sdílené
klíče (key shares), v souladu s metodou přijímanou v
odvětví.
3.5.2.c Kdykoli 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ženy odděleně od klíčů
pro šifrování dat.
3.5.3 Ukládat šifrovací klíče na co
nejmenším počtu míst.
3.6 Kompletně 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ů:
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čtu míst.
3.6.a Doplňková testovací procedura 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
strana 44
Listopad 2013
PCI DSS Požadavky
Poznámka: Pro správu klíčů jsou
dostupné četné odvětvové standardy
z různých zdrojů včetně NIST, který lze
nalézt na http://csrc.nist.gov.
3.6.b Zkontrolovat 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íčů.
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.3.a Ověřit, zda procedury správy klíčů specifikují, jak
bezpečně uchovávat klíče.
3.6.3.b Prověřit metody pro uchovávání klíčů a ověřit, zda
klíče jsou bezpečně uchovávány.
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í
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.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.
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.
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ě.
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.
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
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.
strana 45
Listopad 2013
PCI DSS Požadavky
Vysvětlení
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:
Klíče, které již nejsou používány nebo zapotřebí,
nebo klíče, které byly kompromitovány nebo je
podezření na jejich kompromitování, by měly být
zrušeny a/nebo zničeny, aby se zajistilo, že klíče
již nelze použít. Je-li třeba, aby klíče byly
uchovány (například na podporu archivovaných,
šifrovaných dat), tyto klíče musí být odolně
chráněny.
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í.
• Odstranění nebo nahrazení klíčů pokud byla jejich
integrita oslabena.
• Náhradu př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.b Dotá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.
Šifrovací řešení by mělo zajistit a usnadnit proces
nahrazení 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.6 Je-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áni nejméně dva pracovníci a jedna
osoba nemá přístup k autentizačním materiálům
(například hesla nebo klíče).
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
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 osob samostatně vlastní části klíčů a
jednotlivé části klíčů nenesou žádnou znalost o
původním šifrovacím klíči.
Duální ovládání vyžaduje dvě nebo více osob k
provedení funkce, a jedna osoba nemá přístup k
autentizačním materiálům toho druhého.
• duální kontrolou.
3.6.7 Prevence 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íčů.
Kryptografické řešení by nemělo umožnit ani
akceptovat nahrazení klíčů pocházejících z
strana 46
Listopad 2013
PCI DSS Požadavky
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.7 Ujistit se, že bezpečnostní politiky a
provozní postupy pro ochranu uložených
dat držitelů karet jsou dokumentovány,
používány a známy všem dotčeným
stranám.
Vysvětlení
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íčů.
neautorizovaných zdrojů nebo neočekávaných
procesů.
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.
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.
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.7 Zkontrolovat dokumentaci, dotázat se pracovníků a ověřit,
zda jsou bezpečnostní politiky a provozní postupy pro ochranu
uložených dat držitelů karet:
• dokumentovány,
• používají se, a
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.
strana 47
Listopad 2013
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
SSL/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.
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.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.
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í
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řenos dat držitelů karet vyžaduje
použití důvěryhodných klíčů/certifikátů, bezpečný
protokol pro přenos a správnou šifrovací odolnost
k zašifrování dat držitelů karet. Požadavky na
připojení od systémů, které nepodporují
požadovanou odolnost šifrování a které by vedly k
nezabezpečenému připojení, by neměly být
přijaty.
Povšimněte si, že některé implementace
protokolu (jako např. SSL verze 2.0 a SSH verze
1.0 a TLS 1.0), 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 u
protokolu TLS v1.1, nebo vyšší verze, může být
zváženo získání certifikátů od uznávané, veřejné
certifikační autority, pokud podporují odolné
šifrování. 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í.
strana 48
Listopad 2013
PCI DSS Požadavky
Vysvětlení
4.1.g Pro implementaci SSL/TLS zkontrolovat konfigurace
systému a ověřit, zda je umožněn protokol SSL/TLS vždy, když
jsou data držitelů karet vysílána nebo přijímána:
Obecně platí, že webová stránka URL by měla
začínat znaky "HTTPS" a/nebo webový prohlížeč
zobrazí ikonu visacího zámku někde v okně
prohlížeče. Mnoho dodavatelů certifikátu SSL také
poskytuje velmi viditelnou ověřující pečeť - někdy
je jí říká "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.
• “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 “HTTPS” objeví jako součást URL.
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.
4.2 Nikdy neposílat nechráněná čísla
karet (PANs) technologiemi pro zasílání
zpráv koncovým uživatelem (například email, rychlá textová komunikace (instant
messaging), chat, apod.).
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
• Slabé šifrování (například WEP, SSL version 2.0 nebo
starší) není použito jako bezpečnostní kontrola pro
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.3 Ujistit se, zda bezpečnostní politiky a
provozní postupy pro šifrování přenosů
dat držitelů karet byly dokumentovány,
stranám.
přenosu dat držitelů karet:
• dokumentovány,
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.
E-mail, rychlá textová komunikace (instant
messaging) 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í.
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.
strana 49
Listopad 2013
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.
strana 50
Listopad 2013
PCI DSS Požadavky
5.1.2
Pro systémy, které jsou považovány za
běžně neovlivňované škodlivým
softwarem, provést pravidelné
vyhodnocení a identifikovat a
vyhodnotit vyvíjející se hrozby ze
strany malware a ověřit, zda tyto
systémy i nadále nevyžadují antivirový
software.
Vysvětlení
5.1.2 Dotázat se pracovníků a ověřit, zda vyvíjející se hrozby
ze strany malware jsou sledovány a vyhodnocovány u
systémů, které nejsou v současné době považovány za
běžně neovlivňované škodlivým softwarem, aby se potvrdilo,
zda tyto systémy i nadále nevyžadují antivirový software.
Typicky, sálové počítače, mid-range počítače
(například AS/400) a podobné systémy nemusí
být v současné době běžně cílem nebo ovlivněny
malwarem. Nicméně, odvětvové trendy u
škodlivého softwaru se mohou rychle měnit, takže
je důležité, aby si organizace byly vědomy nových
malware, které by mohly mít vliv na jejich systémy
- například tím, že sledují oznámení dodavatele
bezpečnostních a antivirových diskusních skupin,
aby určily, zda jejich systémy mohou být pod
hrozbou nového a rozvíjejícího se malware.
Trendy u škodlivého softwaru by měly být
zahrnuty do identifikace nových bezpečnostních
zranitelností, a způsoby, jak řešit nové trendy by
měly být podle potřeby začleněny do
konfiguračních standardů společnosti a
ochranných mechanismů.
5.2 Zajistit, aby všechny antivirové
mechanismy byly spravovány podle
následujících bodů:
• 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.a Zkontrolovat politiky a procedury a ověřit, zda antivirový
software a definice jsou udržovány v aktuálním stavu.
5.2.b Zkontrolovat antivirové konfigurace, včetně hlavní
instalace softwaru a ověřit, zda jsou antivirové mechanismy:
• nakonfigurovány tak, aby prováděly automatické
aktualizace, a
• nakonfigurovány tak, aby prováděly pravidelné skeny.
5.2.c Zkontrolovat 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
• jsou tyto záznamy uchovávány v souladu s Požadavkem
10.7 PCI DSS.
strana 51
Listopad 2013
PCI DSS Požadavky
5.3 Zajistit, aby antivirové mechanismy
byly aktivní a nemohly být deaktivovány
nebo změněny uživateli, pokud to není
výslovně schváleno vedením a to případ
od případu a na omezenou dobu.
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áleno vedením a to případ od
případu. Pokud má být ze zvláštního
důvodu deaktivována antivirová ochrana,
musí to být formálně schváleno. Během
doby, po kterou není antivirová ochrana
aktivní, může být také nutné
implementovat další bezpečnostní
opatření.
Vysvětlení
5.3.a Zkontrolovat antivirové konfigurace, včetně hlavní
instalace softwaru a vzorek systémových komponent, a ověřit,
zda antivirový software je aktivně spuštěn.
Antivirový software, který je neustále spuštěn a
není možné jej změnit, poskytne trvalou ochranu
před škodlivým softwarem.
5.3.b Zkontrolovat antivirové konfigurace, včetně hlavní
instalace softwaru a vzorku systémových komponent, a ověřit,
zda antivirový software nemůže být deaktivován nebo změněn
už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ěna nebo
deaktivována, napomůže zabránit zneužití
systémových slabin před zneužitím škodlivým
softwarem.
5.3.c Dotázat se odpovědných pracovníků, prověřit procesy a
ověřit, zda antivirový software nemůže být deaktivován nebo
změněn uživateli, pokud to není výslovně schváleno vedením a
to případ od případu a na omezenou dobu.
Během doby, kdy není antivirová ochrana aktivní,
může být také nutné implementovat další
bezpečnostní opatření - například odpojení
nechráněného systému z internetu zatímco je
antivirová ochrana deaktivována, a poté, co je
antivirová ochrana obnovena, znovu spustit úplný
sken.
strana 52
Listopad 2013
PCI DSS Požadavky
provozní procedury pro ochranu systémů
proti malwaru byly dokumentovány,
stranám.
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,
strana 53
Listopad 2013
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í, zda nejsou 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ů o
bezpeč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 zranitelnosti mohou zahrnovat
zvážení základního skóre CVSS, a/nebo třídění
podle dodavatele, a/nebo typu uvažovaných
systémů.
Metody proohodnocení zranitelnosti a postup
hodnocenít rizika se bude lišit podle prostředí
organizace a strategie hodnocení rizika.
ohodnocení rizika by mělo minimálně identifikovat
všechny zranitelnosti považované v daném
prostředí za "vysoké riziko". Vedle ohodbnocení
rizika mohou být zranitelnosti považovány za
"kritické" v případě, že představují bezprostřední
ohrožení prostředí, mají dopad na kritické systémy
a/nebo mají za následek potenciální
zkompromitování pokud nejsou řešeny. Mezi
příklady kritických systémů uvést bezpečnostní
systémy, zařízení a systémy s přístupem
veřejnosti, databáze a další systémy, které
uchovávají, zpracovávají nebo přenášejí data
držitelů karet.
6.2 Zajistit, aby veškeré systémové
6.1.a Zkontrolovat politiky a procedury a ověřit, zda jsou
procesy definovány pro ná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 o
bezpečnostních zranitelnostech.
6.1.b Dotázat se odpovědných pracovní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í zranitelnosti
používají uznávané externí zdroje k získání informací o
bezpečnostních zranitelnostech.
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.
6.2.a Zkontrolovat politiky a procedury týkající se instalace
strana 54
Listopad 2013
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áplaty by
měly být identifikovány podle procesu
klasifikace rizik definovaného v Požadavku
6.1.
Vysvětlení
bezpečnostních záplat a ověřit, zda jsou definovány procesy
pro následující body:
Vyskytuje se stálý proud útoků s využitím široce
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 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.
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.
strana 55
Listopad 2013
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ů:
PCI DSS Požadavky
• Změny kódu jsou 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.
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 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).
Oprava chyb v programech před nasazením
programu do produkčního prostředí, nebo jeho
uvolnění k zákazníkům, zabraňuje programu, aby
vystavil prostředí potenciálnímu zneužití. Je také
mnohem obtížnější a nákladnější opravovat vadný
program poté, co byl nasazen nebo uvolněn do
produkčního prostředí.
• Příslušné opravy jsou implementovány před
uvolněním do provozu.
• Výsledky prověření kódu jsou vyhodnoceny a
schváleny vedením před uvedením do provozu.
• Výsledky prověrky kódu jsou
přezkoumány a schváleny vedením
př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álen a byl vyvinut v souladu s politikami
a procedurami.
strana 56
Listopad 2013
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.
6.3.2.b Vybrat vzorek posledních změn zákaznické
aplikace a ověřit, zda kód programu zákaznické aplikace
je prověřen podle výše uvedeného Požadavku 6.3.2.a.
Vysvětlení
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í.
strana 57
Listopad 2013
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
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.
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í.
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).
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.
strana 58
Listopad 2013
PCI DSS Požadavky
6.4.5 Procedury řízení změn pro
implementaci bezpečnostních záplat
(patchů) a modifikaci softwaru musí
obsahovat následující kroky:
Vysvětlení
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:
Pokud nejsou změny správně řízeny, účinek
softwarových aktualizací a bezpečnostních záplat,
nemusí být plně realizován a může mít nezamýš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.
strana 59
Listopad 2013
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.c Zkontrolovat záznamy o školení a ověřit, zda vývojáři
softwaru absolvovali školení o technikch bezpečného
programování, včetně toho, jak se vyhnout běžným
zranitelnostem v programování a pochopení toho, jak se
citlivá data zpracovávají v pamě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ělo být rovněž aktualizováno s
ohledem na nové hrozby - například útoky na
paměť.
Zranitelnosti uvedené v bodech 6.5.1 až 6.5.10 tvoří
minimální základnu. Je na organizaci, aby i nadále
držela krok s trendy zranitelnosti a začlenila
příslušná opatření do svých bezpečných
programátorských postupů.
strana 60
Listopad 2013
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.
strana 61
Listopad 2013
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).
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
procesu posuzování rizik zranitelnosti (definované v
Požadavku 6.1) jako "vysoké riziko", a které by
mohly ovlivnit aplikaci, by měly být identifikovány a
řešeny v průběhu vývoje aplikace.
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”.
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 XSS se projeví pokud aplikace odešle
uživatelem dodaná data na webový prohlížeč, aniž
by nejdříve ověřila nebo zašifrovala jejich obsah.
XSS umožňuje útočníkům spustit skript v prohlížeči
oběti, kteří se pak mohou zmocnit relace uživatele,
narušit webové stránky, případně zavést červy, atd.
strana 62
Listopad 2013
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žňuje přístup k
neoprávněným funkcím, tento přístup by mohl vést
k získání přístupu nepovolanými osobami k
privilegovaným ověřovacím údajům nebo datům
držitelů karet. Pouze autorizovaní uživatelé by měli
mít možnost přístupu na přímé odkazy na objekty k
citlivým zdrojům. Omezení přístupu k datovým
zdrojům pomůže ochránit data držitelů karet od
jejich zpřístupnění neoprávněným zdrojů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ákupy nebo dokonce autentizaci v
rámci aplikace).
strana 63
Listopad 2013
PCI DSS Požadavky
6.5.10 Přerušované ověření identity
(autentizace) a správa relace
Poznámka: Požadavek 6.5.10 je pokládán za
osvědčený postup do 30. června 2015, po
tomto datu se stává požadavkem.
Vysvětlení
přerušovaná atentizace a správa relace je řešena
programátorskými postupy, které obecně zahrnují:
Bezpečná autentizace a správa relace brání
neoprávněným jedincům v kompromitování
legitimních ověřovacích údajů k účtům, klíčům nebo
tokenům relace, které by jinak umožnily útočníkovi
převzít identitu oprávněného uživatele.
• Flagging session tokens, tj. označení tokenů relace
(např. cookies) jako “bezpečné”
• Nevystavovat ID relace na URL
• Vložit vhodná časová omezení (time-outs) a rotovat
ID relace po úspěšném přihlášení.
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é
aplikace prostřednictvím manuálních
nebo automatizovaných nástrojů nebo
metod pro posouzení bezpečnostní
zranitelnosti aplikací, nejméně jednou za
rok a po jakýchkoli změnách
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í internetový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.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, zda je 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í internetových
útoků nebo na generování varování.
Ú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.
• 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.
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žit nezávislost na vývojovém týmu.
strana 64
Listopad 2013
PCI DSS Požadavky
provozní postupy pro vývoj a údržbu
bezpečných systémů a aplikací byly
dokumentovány, používány a známy všem
dotčeným stranám.
Vysvětlení
6.7 Zkontrolovat dokumentaci, dotázat se pracovníků a
ověřit, zda jsou bezpečnostní politiky a provozní postupy pro
vývoj a údržbu bezpečných systémů a aplikací:
Pracovníci si musí být vědomi a provádět následující
bezpečnostní politiky a provozní postupy pro
průběžné zajištění bezpečného vývoje a ochrany
systémů a aplikací před zranitelnostmi.
• dokumentovány,
strana 65
Listopad 2013
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
pro každou roli, včetně:
• Systémové komponenty a
zdrojových dat, ke kterým
každá role musí mít přístup
pro svou pracovní funkci
7.1 Zkontrolovat 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í pro každou
roli
• Omezení přístupu podle oprávnění uživatelova ID na minimum
oprávnění nezbytných pro plnění pracovních povinností
• Přiřazení přístupu založeného na klasifikaci a pracovní funkci
jednotlivých pracovníků
• Dokumentované schválení (elektronické nebo písemné)
oprávněnými osobami pro veškerý přístup, včetně seznamu
schválených specifických oprávnění.
7.1.1 Vybrat vzorek rolí a ověřit, zda jsou pro jednotlivé role
definovány potřeby přístupu a zahrnují:
• Systémové komponenty a datové zdroje, které každá role
potřebuje pro přístup k jejich pracovnímu zařazení
• Identifikace oprávnění nezbytných pro každou roli k plně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.
strana 66
Listopad 2013
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 za přidělování
přístupu a ověřit, zda přístup k privilegovaným uživatelským
účtům je:
• přiřazen pouze k rolím, které se specificky vyžadují pro
privilegovaný přístup
• omezen pouze na minimální oprávnění nezbytná pro plnění
7.1.2.b Vybrat vzorek ID uživatelů s privilegovaným přístupem a
dotázat se odpovědných řídících pracovníků a ověřit, zda
přiřazená oprávnění jsou:
• nezbytná pro funkci daného pracovníka
• omezena pouze na minimální oprávnění nezbytná pro plnění
Vysvětlení
Při přiřazování privilegovaného ID je důležité přiřadit
jednotlivcům pouze oprávnění, které potřebují k
výkonu své práce (dále jen "minimální oprávnění").
Například administrátorovi databáze nebo správci
úložiště by neměla být přiřazena stejná oprávnění,
jako správci celého systému.
Přiřazení minimálních oprávnění pomáhá zabránit
uživatelům bez dostatečných znalostí o aplikaci
nesprávně nebo náhodně změnit nastavení aplikace
nebo změnit bezpečnostní nastavení. Zavedení
minimálních oprávnění také napomáhá
minimalizovat rozsah škod, pokud neoprávněná
osoba získá přístup k uživatelským ID.
7.1.3 Přiřadit přístup podle
klasifikace jednotlivých pracovních
míst a funkcí.
7.1.3 Vybrat vzorek uživatelských ID, dotázat se odpovědných
řídících pracovníků a ověřit, zda jsou oprávnění přiřazena podle
klasifikace jednotlivých pracovních míst a funkcí.
Jakmile jsou potřeby definovány podle uživatelských
rolí (podle PCI DSS Požadavku 7.1.1), je snadné
přidělit jednotlivcům přístup podle klasifikace jejich
pracovních míst a funkcí pomocí již vytvořených rolí.
7.1.4 Vyžadovat dokumentovaný
souhlas autorizovanými stranami
specifikující požadovaná
oprávnění.
7.1.4 Vybrat vzorek už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řístupem a
privilegii jsou známy a schváleny vedením, a že
jejich přístup je nezbytný pro jejich pracovní 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.
Bez mechanismu omezení přístupu na základě
provozních potřeb uživatelů, může být uživateli
nevědomky umožněn přístup k datům držitelů
karet.Systém kontroly přístupu automatizuje proces
omezení přístupu a př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
nastaveny na “povolit vše ("allow-all"), umožňující
přístup do té doby, dokud není vloženo pravidlo toto
neumožňující.
strana 67
Listopad 2013
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”.
7.3 Zajistit, aby bezpečnostní politiky
a provozní postupy pro omezení
přístupu k datům držitelů karet byly
7.3 Zkontrolovat dokumentaci, dotázat se pracovníků a ověřit, zda
jsou bezpečnostní politiky a provozní postupy pro omezení
přístupu k datům držitelů karet:
• dokumentovány,
Vysvětlení
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í.
strana 68
Listopad 2013
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řístupem k systémům měly všechny platné a
uznávané uživatele, stabilní procesy musí řídit
všechny změny uživatelských ID a dalších
ověřovacích údajů (autentizaci), včetně přidání
nových uživatelských jmen a změny nebo zrušení
stávajících jmen.
strana 69
Listopad 2013
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.
8.1.3.a Vybrat vzorek uživatelů, kterým bylo ukončeno
oprá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ů.
8.1.3.b Ověřit, zda všechny fyzické metody ověřování, jako
jsou čipové karty, tokeny, atd., byly vráceny nebo
deaktivovány.
Vysvětlení
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.4 Odstranit/deaktivovat neaktivní
uživatelské účty nejméně každých 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á ID
používaná dodavateli pro přístup k
systémovým komponentám, a jejich
podpoře nebo údržbě, pomocí
vzdáleného přístupu dle následujících
bodů:
8.1.5.a Dotázat se pracovníků a sledovat procesy pro správu
účtů používaných dodavateli pro přístup, podporu, nebo
údržbu systémových komponent a ověřit, zda účty používané
dodavateli pro vzdálený přístup jsou:
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 pouze po nezbytnou
potřebnou dobu a 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í
• Povoleny pouze 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ů a sledovat procesy 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 pro poskytovatele
služeb: Přezkoumat interní procesy a zákaznickou /
uživatelskou dokumentaci, prověřit implementované procesy a
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.
strana 70
Listopad 2013
PCI DSS Požadavky
Vysvětlení
ověřit, zda nezákaznické účty 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á autentizace může být použita buď na
úrovni systému k ochraně všech relací spuštěných
na tomto terminálu nebo na ú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.
strana 71
Listopad 2013
PCI DSS Požadavky
8.2.1 Použit silného šifrování učiní
všechny ověřovací údaje (jako jsou
hesla / heslové fráze) nečitelné během
přenosu a ukládání na všechny
systémové komponenty.
8.2.1.a Zkontrolovat dokumentaci dodavatele a nastavení
konfigurace systému a ověřit, zda hesla jsou při přenosu a
uchovávání chráněna odolnou kryptografií.
8.2.1.b U vzorku systémových komponent zkontrolovat
soubory s hesly a ověřit, zda hesla jsou během uchovávání
nečitelná.
8.2.1.c U vzorku systémových komponent zkontrolovat
přenosy dat a ověřit, zda hesla jsou během přenosu 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.
8.2.1.d Doplňková testovací procedura pro poskytovatele
služeb: Prověřit soubor s hesly a ověřit, zda zákaznická hesla
jsou v době uchovávání nečitelná.
8.2.1.e Doplňková testovací procedura pro poskytovatele
služeb: Prověřit přenosy dat a ověřit, zda zákaznická hesla
jsou během přenosu nečitelná.
8.2.2
Ověřit identitu uživatele před změnou
jakýchkoli ověřovacích údajů
(authentication credentials) – například
provedením resetování hesla,
poskytnutím nových tokenů nebo
generováním nových klíčů.
8.2.2 Prověřit ověřovací postupy pro změnu ověř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ů.
strana 72
Listopad 2013
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ít složitost a odolnost, která je
alespoň rovnocenná parametrům
uvedených výš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.
služeb:
Přezkoumat interní procesy a zákaznickou / uživatelskou
dokumentaci a ověřit, zda hesla pro uživatele, kteří nejsou
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.
8.2.4 Změnit uživatelská hesla /
heslové fráze nejméně každých 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ěnu uživatelských hesel
nejméně každých 90 dní.
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.
Hesla / heslové fráze, které jsou platné po dlouhou
dobu beze změny poskytují zlovolným jedincům více
času pracovat na rozbití hesla / heslové fráze.
služeb:
Přezkoumat interní procesy a zákaznickou / uživatelskou
dokumentaci a ověřit, zda:
• Hesla uživatelů, kteří nejsou 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í hesla změnit.
strana 73
Listopad 2013
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 Nastavit heslo / heslovou frázi
pro první použití, a při resetu, na
jedinečnou hodnotu pro každého
uživatele, a po prvním použití okamžitě
změnit.
služeb: Přezkoumat interní procesy a zákaznickou /
uživatelskou dokumentaci a ověřit, zda hesla už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, zda hesla pro první použití u nových
uživatelů, a resetovaná hesla u stávajících uživatelů, jsou
nastavena na jedinečnou hodnotu pro každého uživatele a
změněna po prvním použití.
8.3 Zač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é konfigurace pro servery
vzdáleného přístupu a systémy a ověřit, zda dvoufaktorové
ověření (autentizace) je vyžadována pro:
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.b Prověřit vzorek pracovníků (např. uživatele a správce) se
vzdáleným přístupem do sítě a ověřit, zda jsou používány
nejméně dvě ze tří ověřovacích metod.
• Všechny vzdá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 a systémovým
komponentám pro účely podpory a údržby).
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.
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ě.
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.
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.
strana 74
Listopad 2013
PCI DSS Požadavky
Vysvětlení
Příklady dvoufaktorových technologií
zahrnujcíí vzdálené ověření a dial-in
službu (RADIUS,Rremote Authentication
and Dial-In Service) s toikeny; řadič
terminálového přístupu pro systém řízení
přístupu (TACACS, Terminal Access
Controller Access Control System) s
tokeny; a další technologie, které
umožňují dvou-faktorové ověření
(autentizaci).
8.4 Dokumentovat a komunikovat
ověřovací procedury a politiky všem
uživatelům, včetně:
• Pokyny k výběru silných
přihlašovacích údajů
• Návod, jak by měl uživatel chránit
své přihlašovací údaje
• Pokyny nepoužívat dříve použitá
hesla
• Pokyny ke změně hesla, pokud
existuje podezření, že heslo by
mohlo být ohroženo.
8.4.a Zkontrolovat postupy, dotázat se pracovníků a ověřit, zda
ověřovací procedury a politiky jsou distribuovány všem
uživatelům.
8.4.b Přezkoumat ověřovací procedury a politiky, které jsou
distribuovány uživatelům a ověřit, zda zahrnují:
•
•
•
•
Návod k výběru odolných přihlašovacích údajů
Návod, jak by uživatelé měli chránit své přihlašovací údaje.
Pokyny pro uživatele, aby nepoužívali dříve použitá hesla
Pokyny ke změně hesel, pokud existuje podezření, že heslo
by 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.
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").
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živatele jsou
zakázána nebo odstraněna.
8.5.a U vzorku systé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živatele neexistují 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
strana 75
Listopad 2013
PCI DSS Požadavky
• Sdílená ID uživatele se nepoužívají
pro systémové administrátory a další
kritické funkce. .
• Sdílená a generická ID uživatele
nejsou používána k administraci
jakýchkoli systémových komponent.
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.
Vysvětlení
provedena kýmkoli ze skupiny, kdo má znalosti o
ověřovacích údajích.
8.5.c Dotá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
pro poskytovatele služeb:
8.5.1 Doplňková testovací procedura pro poskytovatele
služeb:
Poskytovatelé služeb se vzdáleným
přístupem do prostor zákazníka
(například pro podporu POS systémů
nebo serverů) musí používat unikátní
autentizací ověřovací údaje (například
hesla/fráze) pro každého zákazníka.
Zkontrolovat autentizační politiky a postupy, dotázat se
pracovníků a ověřit, zda jsou pro přístup ke každému
zákazníkovi použity různá ověřování (autentizace)
Poznámka: Tento požadavek není
zamýšlen pro poskytovatele sdíleného
hostingu přistupující k jejich vlastnímu
hostingovému prostředí, kde se vyskytují
četnější prostředí zákazníků.
Aby se zabránilo ohrožení více zákazníků vzhledem
k použití jedné sady ověřovacích údajů (credentials),
dodavatelé s účty vzdálených přístupů do prostředí
zákazníka by měli použít jiné ověřovací údaje pro
každého zákazníka.
Technologie, jako jsou například dvoufaktorové
mechanismy, které poskytují jedinečné ověřovací
údaje pro každé připojení (například prostřednictvím
hesla na jedno použití) by mohla rovněž splňovat
záměr tohoto požadavku.
Poznámka: Požadavek 8.5.1 je
pokládán za osvědčený postup do 30.
června 2015, po tomto datu se stává
požadavkem.
strana 76
Listopad 2013
PCI DSS Požadavky
8.6 Pokud jsou použity jiné ověřovací
mechanismy (například fyzické nebo
logické bezpečnostní tokeny, čipové
karty, certifikáty, atd.), použití těchto
mechanismů musí být přiřazeno
následovně:
• Ověřovací mechanismy musí být
přiřazeny k jednotlivému účtu a
nesmí být sdíleny mezi více účty.
• Musí být zavedeny fyzikální a/nebo
logické kontroly, aby bylo zajištěno,
že pouze určený účet může použít
tento mechanismus k získání
přístupu.
8.6.a Zkontrolovat ověřovací politiky a procedury a ověřit, zda
procedury pro používání ověřovacích mechanismů, jako jsou
fyzické bezpečnostní tokeny, čipové karty a certifikáty, jsou
definovány a zahrnují body:
• Ověřovací mechanismy jsou přiřazeny k individuálnímu účtu
a nejsou sdíleny mezi více účty.
• Fyzikální a/nebo logické kontroly jsou definovány, aby
zajistily, že pouze určený účet můžete použít tento
mechanismus k získání přístupu.
Vysvětlení
Pokud ověřovací mechanismy, jako jsou tokeny,
čipové karty, a certifikáty, mohou být použity více
účty, může být nemožné identifikovat jedince
pomocí ověřovacího mechanismu. S fyzickými
a/nebo logickými kontrolami (například PIN,
biometrické údaje nebo heslo) k jednoznačné
identifikaci uživatele účtu bude možno zabránit
neoprávněným uživatelům v získání přístupu
prostřednictvím použití sdíleného mechanismu
ověření.
8.6.b Dotázat se pracovníků a ověřit, zda jsou ověřovací
mechanismy přiřazeny k účtu a nejsou sdíleny mezi více účty.
8.6.c Zkontrolovat nastavení systémové konfigurace a/nebo
fyzických kontrol, podle potřeby, a ověřit, zda jsou
implementovány kontroly s cílem zajistit, aby jen určený účet
mohl použít tento mechanismus k získání přístupu.
8.7 Všechny přístupy ke každé databázi
obsahující data držitelů karet (včetně
přístupů aplikace , administrátory a
všichny ostatní uživatele) jsou omezeny
následovně:
• Všechny přístupy uživatelů k
databázím, uživatelské dotazy a
uživatelské činnosti nad databázemi
musí být prováděny prostřednictvím
programových metod.
• Pouze administrátoři databází mají
možnost přímo přistupovat k
databázím nebo vytvářet dotazy nad
nimi.
• ID aplikace pro databázové aplikace
mohou být použity pouze samotnou
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 Zkontrolovat nastavení konfigurace databáze a aplikace a
ověřit, zda všechny uživatelské přístupy k databázím,
uživatelské dotazy a uživatelské činnosti nad databázemi
(například přesuny, kopírování, mazání) jsou prováděny pouze
prostřednictvím programových metod (například prostřednictvím
uložených procedur).
8.7.c Zkontrolovat nastavení kontroly přístupu k databázi a
nastavení konfigurace databázových aplikací a ověřit, zda přímý
přístup uživatele k databázi nebo dotazy 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 Zkontrolovat nastavení kontroly přístupu k databázi a
nastavení konfigurace databázových aplikací a ID databázových
aplikací a ověřit, zda ID aplikací mohou být použity pouze
strana 77
Listopad 2013
PCI DSS Požadavky
aplikací (a nikoli jednotlivými uživateli
nebo jinými procesy mimo aplikaci).
provozní postupy pro identifikaci a
ověřování byly dokumentovány,
stranám.
Vysvětlení
aplikacemi (a nikoliv individuálními uživateli nebo jinými
procesy).
zda bezpečnostní politiky a provozní postupy pro identifikaci 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,
strana 78
Listopad 2013
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
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 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.
9.1.1.b Ověřit, zda videokamery a/nebo mechanismy kontroly
přístupu jsou chráněny před manipulací nebo deaktivací.
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ě.
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é
kdy vstoupily nebo odešly.
Zločinci, snažící se získat fyzický přístup k citlivé
oblasti, se často pokoušejí deaktivovat nebo obejít
monitorovací kontroly. Chcete-li ochránit tyto
kontroly před manipulací, videokamery by mohly
být umístěny tak, aby byly mimo dosah a/nebo
mohou být monitorovány, aby byla zjištěna
neoprávněná manipulace. Podobně by mohly být
mechanismy kontroly přístupu monitorovány nebo
mít nainstalovánu fyzickou ochranu, aby se
zabránilo jejich poškození nebo deaktivaci
zlovolnými jedinci.
strana 79
Listopad 2013
PCI DSS Požadavky
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í
9.1.1.c Ověřit, zda videokamery a/nebo kontrolní mechanismy
přístupu jsou monitorovány a 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.2 Dotá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.
Například, síťové konektory umístěné ve
veřejných prostorách a prostorách
přístupných pro návštěvníky by mohly
být deaktivovány a aktivovány pouze
tehdy, je-li přístup k síti výslovně
autorizován. Alternativně, procesy by
měly být implementovány tak, aby
návštěvníci mohli vstoupit do oblastí s
aktivními síťovými konektory vždy pouze
s doprovodem.
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.
Jsou-li použity logické nebo fyzické kontroly, nebo
kombinace obou, měly by být dostatečné k tomu,
aby zabránily jednotlivci nebo zařízení, kteří nejsou
výslovně autorizováni, připojení k síti.
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.
strana 80
Listopad 2013
PCI DSS Požadavky
9.2 Vyvinout postupy ke snadnému
odlišení místních pracovníků a
návštěvníků, které zahrnují:
• Identifikaci nových pracovníků nebo
ná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).
Vysvětlení
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.b Sledovat procesy pro identifikaci a rozlišování mezi
pracovníky a návštěvníky a ověřit, zda:
• Návštěvníci jsou jasně označeni, a
• Je snadné rozlišit mezi pracovníky a ná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.2.d Zkontrolovat používané identifikační metody (jako je systém
visaček), a ověřit, zda jasně identifikují návštěvníky, a že je
snadné rozlišit mezi pracovníky a návštěvníky.
9.3 Kontrolovat fyzický přístup
pracovníků k citlivým oblastem podle
• Přístup musí být autorizován a
založen na funkci jednotlivých úloh.
• Přístup je zrušen ihned po ukončení
a všechny mechanismy fyzického
přístupu, jako jsou klíče, přístupové
karty, atd., jsou vráceny nebo
deaktivovány.
9.4 Zavést procedury pro identifikaci a
autorizaci návštěvníků.
9.3.a U vzorku pracovníků s fyzickým přístupem k prostředí dat
držitelů karet, dotázat se odpovědných pracovníků, prověřit
seznamy pro řízení přístupu a ověřit, zda:
• Přístup do prostředí dat držitelů karet je povolen.
• Je vyžadováno přístup pro funkce jednotlivých úloh.
9.3.b Sledovat přístup pracovníků do prostředí dat držitelů karet
a ověřit, zda všichni pracovníci jsou autorizováni před tím, než je
jim udělen přístup.
9.3.c Vybrat vzorek nedávno ukončených zaměstnanců a
přezkoumat seznamy kontroly přístupu a ověřit, zda pracovníci
nemají fyzický přístup do prostředí dat držitelů karet.
9.4 Ověřte, zda autorizace návštěvníků a kontroly přístupu jsou
zavedeny následovně:
Procedury by měly zahrnovat
Kontrola fyzického přístupu do prostředí dat
držitelů karet pomáhá zajistit, aby byl udělen
přístup pouze autorizovaným pracovníkům s
legitimní provozní potřebou.
Pokud pracovníci opustí organizaci měly by být při
jejich odchodu okamžitě (co nejdříve) vráceny nebo
zakázány všechny fyzické přístupové mechanismy,
aby bylo pracovníkům zabráněno v získání
fyzického přístupu do prostředí dat držitelů karet
poté, co jejich zaměstnání skončilo.
Kontroly návštěvníků jsou důležité pro snížení
schopnosti nepovolaných a zlovolných jednotlivců
získat přístup do objektu (a potenciálně k datům
držitelů karet).
strana 81
Listopad 2013
Vysvětlení
9.4.1 Návštěvníci jsou před vstupem
autorizováni, a jsou stále doprovázeni
v prostorách, kde jsou zpracovávána
nebo uchoovávána data držitelů karet.
9.4.1.a Sledovat procedury, dotázat se pracovníků a ověřit, zda
návštěvníci musí být autorizováni dříve, než je jim povolen
přístup, a jsou stále doprovázeni v prostorách, kde jsou
zpracovávána nebo uchovávána data držitelů karet.
9.4.2 Návštěvníci jsou identifikováni a
jsou jim vydány visačky nebo jiné
označení, které má dobu platnosti a
viditelně je odlišuje od místních
pracovníků.
9.4.1.b Sledovat použití visaček návštěvníků nebo jiného
označení a ověřit, zda fyzický token neumožňuje bez doprovodu
přístup do fyzických prostor, kde jsou zpracovávána nebo
uchovávána data držitelů karet.
Kontroly návštěvníků zajišťují, že návštěvníci jsou
identifikovatelní jako návštěvníci, takže pracovníci
mohou sledovat jejich činnost, a že jejich přístup je
omezen jen na dobu trvání jejich legitimní
návštěvy.
PCI DSS Požadavky
9.4.2.a Sledovat lidi v objektu a ověřit používání visaček
návštěvníků nebo jiného označení, a zda jsou návštěvníci
snadno odlišitelní od pracovníků.
9.4.2.b Ověřit, zda visačkám návštěvníků nebo jiným
identifikacím skončí platnost.
9.4.3 Návštěvníci jsou požádáni, aby
odevzdali visačky nebo identifikaci
před opuštěním objektu nebo ke dni
ukončení jejich platnosti.
9.4.3 Prověřit návštěvníky opouštějící objekt a ověřit, zda jsou
požádáni, aby při odchodu nebo ukončení platnosti odevzdali
své visačky nebo 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 nebo uchovávána data
držitelů karet.
9.4.4.a Ověř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ý
přístup.
Tento záznamu o vstupu (log) uchovat
nejméně po tři měsíce, pokud zákon
nestanovuje jinak.
Zajištěním vrácení visaček návštěvníků po uplynutí
doby platnosti nebo ukončení návštěvy zabraňuje
zlovolným jednotlivcům použít dříve autorizované
průkazy získat fyzický přístup do budovy poté, co
jejich návštěva skončila.
Protokol o návštěvnících (log), dokumentující
minimum informací o návštěvníkovi, se jednoduše
a levně udržuje a může napomoci při identifikaci
fyzického přístupu do budovy nebo místnosti, a
potenciálního přístupu k 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.
9.4.4.c Ověřit, zda je záznam uchováván nejméně po tři
měsíce.
strana 82
Listopad 2013
PCI DSS Požadavky
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.
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ů).
Vysvětlení
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žňuje organizaci ř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:To neznamená, že média musí mít
připojen štítek "Důvěrné"; záměrem je, aby
organizace identifikovala média, která obsahují
citlivé údaje, takže je lze chránit.
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,
strana 83
Listopad 2013
PCI DSS Požadavky
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ů.
Vysvětlení
9.6.2.b Vybrat ze sledovacích protokolů čerstvý vzorek ze všech
médií za několik dnů zásilek zaslaných mimo objekt a ověřit,
zda podrobnosti o sledování jsou dokumentovány.
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.3 Vybrat ze sledovacích protokolů čerstvý vzorek ze všech
mé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).
Bez pevně stanoveného firemního procesu
zajišťujícího, aby všechny pohyby médií byly
schváleny před tím, než je médium přesunuto
mimo bezpečnou oblast, média nebudou
sledována nebo vhodně chráněna, a jejich
umístění nebude známé, což povede ke ztrátě
nebo odcizení média.
9.7 Zí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.1 Př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é kopie materiálů musí být rozřezány na kousky,
spáleny nebo rozdrceny tak, že lze důvodně předpokládat, že
kopie materiálů nelze rekonstruovat.
• Skladovací kontejnery používané pro materiály, které mají být
zničeny, musí být zabezpečeny.
• Data držitelů karet na elektronických médiích musí být učiněny
nezrekonstruovatelné prostřednictvím bezpečného mazacího
programu (v souladu se standardem uznávaným v odvětví pro
bezpečné mazání), nebo fyzickým zničením média.
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áleny nebo
rozdrceny tak, že lze důvodně předpokládat, že kopie materiálů
nelze rekonstruovat.
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.
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ím skladovacích kontejnerů, používaných
pro materiály, které se mají zničit, se zabraňuje
zmocně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řístupu k obsahu kontejneru.
Příklady metod pro bezpečné zničení
elektronických medií zahrnují bezpečné smazání,
strana 84
Listopad 2013
PCI DSS Požadavky
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 prostřednictvím bezpečného
mazacího programu v souladu se standardem uznávaným v
odvětví pro bezpečné mazání nebo jiným fyzickým zničením
média.
9.9 Chránit zařízení, která snímají data
platebních karet prostřednictvím přímé
fyzické interakce s kartou, před
manipulací a substitucí (nahrazením).
Poznámka: Tyto požadavky se vztahují
na čtecí zařízení karet používaných při
transakcích za přítomnosti karet (to
znamená, že karta je protažena nebo
vložena) v místě prodeje. Tento
požadavek není určen k aplikaci pro
zařízení, které využívá manualní
vkládání dat jako jsou počítačové
klávesnice a POS klávesnice.
9.9 Zkontrolovat dokumentované politiky a procedury a ověřit,
zda zahrnují:
• Udržování seznamu zařízení.
• Provádět pravidelně prohlídku zařízení a prozkoumat, zda s
ním nebylo manipulováno nebo nebylo nahrazeno.
• Školení pracovníků, aby si byli vědomi podezřelého chování a
nahlásili nedovolenou manipulaci nebo náhradu zařízení.
Poznámka: Požadavek 9.9 je pokládán
za osvědčený postup do 30. června
2015, po tomto datu se stává
požadavkem.
Vysvětlení
demagnetizaci nebo fyzické zničení (jako je
rozemletí nebo rozdrcení pevných disků).
Zločinci se pokoušejí ukrást data držitelů karet
krádeží a/nebo manipulací se čtecím zařízením
karet a terminálů. Například se budou snažit ukrást
zařízení, aby se mohli naučit, jak do něj proniknout,
a často se snaží nahradit legitimní zařízení
zařízením podvodným, které jim posílá informace o
platební kartě pokaždé, když je karta vložena.
Zločinci se také snaží připojit komponenty pro
"skimming" zvnějšku zařízení, které jsou určeny k
zachycení údajů z platební karty ještě před tím, než
je karta vložena do zařízení. Například připojením
dodatečné čtečky karet nad legitimní čtečku karet
tak, aby údaje platebních karet byly zachyceny
dvakrát: jednou komponentou zločince a pak
legitimní komponentou zařízení. Tímto způsobem
transakce může být dokončena bez přerušení,
zatímco zločinec si během procesu "naskimuje"
(načte) údaje o platební kartě.
Tento požadavek se doporučuje, ale není
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 v prevenci skimmingu
jsou k dispozici na internetových stránkách PCI
SSC.
9.9.1 Udržovat aktuální seznam
zařízení. Seznam by měl zahrnovat
• Značku a model zařízení
9.9.1.a Zkontrolovat seznam zařízení a ověřit, zda obsahuje:
•
Značku a model zařízení
• Umístění zařízení (např. adresa místa nebo objektu, kde se
zařízení nachází)
• Sériové číslo zařízení nebo jiný způsob unikátní
identifikace.
Vedení aktuálního seznamu zařízení napomáhá
organizaci sledovat, kde by se zařízení mělo
nacházet a rychle určit, zda zařízení chybí nebo je
ztraceno.
Způsob udržování seznamu zařízení může být
automatizováno (například systémem pro správu
strana 85
Listopad 2013
PCI DSS Požadavky
Vysvětlení
• Umístění zařízení (např. adresa
místa nebo objektu, kde se
zařízení nachází)
9.9.1.b Vybrat vzorek zařízení ze seznamu a sledovat umístění
zařízení a ověřit, zda je seznam přesný a aktuální.
zařízení) nebo manuálně (například dokumentace
pomocí elektronických nebo papí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.
• Sériové číslo zařízení nebo jiný
způsob unikátní identifikace.
9.9.1.c Dotázat se pracovníků a ověř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ě kontrolovat povrchy
zařízení a detekovat neoprávněnou
manipulaci (např. přidání skimmerunelegální čtečky karet do zařízení)
nebo výměnu (např. kontrolou
sériového čísla nebo jiné vlastnosti
zařízení ověřit, zda zařízení nebylo
vyměněno za podvodné zařízení).
9.9.2.a Zkontrolovat dokumentované procedury a ověřit, zda
procesy jsou definovány tak, aby obsahovaly následující body:
Poznámka: Příklady příznaků, které
naznačují, že se zařízením mohlo být
manipulováno nebo bylo nahrazeno, jsou
neočekávané přílepky nebo kabely
zapojené do zařízení, chybějící nebo
změněné bezpečnostní štítky, zlomené
nebo jinak barevné kryty nebo změny v
sériovém čísle zařízení nebo jiné vnější
znaky.
• Procedury pro provedení prohlídky zařízení
• Frekvenci kontrol.
9.9.2.b Dotázat se odpovědných pracovníků, sledovat postupy
prohlídek a ověřit:
• Pracovníci si jsou vědomi postupů pro prohlídky zařízení.
• Všechna zařízení jsou pravidelně prohlížena a jsou hledány
důkazy o manipulaci a substituci (nahrazení).
Pravidelné prohlídky zařízení napomohou
organizacím rychleji detekovat neoprávněnou
manipulaci nebo výměnu zařízení, a tím
minimalizovat potenciální dopad používání
podvodných zařízení.
Typ prohlídky budoue záviset na zařízení,
například fotografie zařízení, o kterém je známo, že
je bezpečné, mohou být použity pro srovnání
aktuálního vzhledu přístroje s jeho původním
vzhledem, aby se zjistilo, zda se vzhled změnil.
Další možností může být použití bezpečného
popisovače, jako je značkovač viditelný pod UV
zářením, k označení povrchů zařízení a otvorů v
zařízení, takže jakákoliv neoprávněná manipulace
nebo výměna bude zřejmá. Zločinci často nahradí
vnější kryt zařízení, aby skryli manipulaci, a tyto
metody mohou napomoci odhalit takovéto činnosti.
Dodavatelé zařízení mohou být také schopni
poskytnout bezpečnostní pokyny a návody, jak
napomoci rozhodnutí, zda bylo se zařízením
manipulováno.
Četnost prohlídek bude záviset na faktorech, jako
je umístění zařízení a zda je zařízení obsluhováno
nebo bez dozoru. Například zařízení, ponechaná
ve veřejných prostorách bez dohledu pracovníků
organizace, mohou mít častější prohlídky než
zařízení, která jsou umístěna v zabezpečených
oblastech nebo jsou-li přístupné veřejnosti pod
dohledem. Typ a četnost prohlídek bude určena
obchodníkem, jak jsou definovány v ročním
procesu analýze rizik.
strana 86
Listopad 2013
PCI DSS Požadavky
9.9.3 Zajistit školení pro pracovníky,
aby si byli vědomi pokusů o manipulaci
se zařízením nebo jejich výměně.
Školení by mělo zahrnovat následující
body:
• Ověřit identitu jakýchkoli osob třetí
strany, kteří tvrdí, že jsou
pracovníci opravy nebo údržby,
před udělením přístupu k
provedení opravy nebo údržby
zařízení.
• Neinstalovat, nevyměňovat ani
nevracet zařízení bez ověření.
• Být si vědom podezřelého chování
kolem zařízení (např. pokusy
neznámých osob o odpojení nebo
otevření zařízení).
• Hlásit podezřelé chování a
známky manipulace se zařízením
nebo jeho výměnu (substituci)
příslušným pracovníkům
(například manažerovi nebo
bezpečnostnímu pracovníkovi).
Vysvětlení
9.9.3.a Prověř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ěřit identitu jakýchkoli osob třetí strany, kteří tvrdí, že
jsou pracovníci opravy nebo údržby, před udělením
přístupu k provedení opravy nebo údržby zaří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.
• Neinstalovat, nevyměňovat ani nevracet zařízení bez
ověření.
• Být si vědom podezřelého chování kolem zařízení (např.
pokusy neznámých osob o odpojení nebo otevření
zařízení).
• Hlásit podezřelé chování a známky manipulace se
zařízením nebo jeho výměnu příslušným pracovníkům
(například manažerovi nebo bezpečnostnímu
pracovníkovi).
9.9.3.b Dotázat se vzorku pracovníků v místě prodeje a ověřit,
zda absolvovali školení a jsou si vědomi procedur pro
• Ověření identity jakýchkoli osob třetích stran, kteří tvrdí, že
jsou pracovníci opravy nebo údržby, před udělením
přístupu k provedení změn nebo údržby zařízení.
• Neinstalovat, nevyměňovat ani nevracet zařízení bez
ověření.
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.
• Být si vědom podezřelého chování kolem zařízení (např.
pokusy neznámých osob o odpojení nebo otevření
zařízení).
• Hlásit podezřelé chování a známky manipulace se
zařízením nebo jeho výměnu příslušným pracovníkům
(například manažerovi nebo bezpečnostnímu
pracovníkovi).
9.10 Zajistěte, aby bezpečnostní politiky
a provozní procedury pro omezení
fyzického přístupu k datům držitelů karet
byly dokumentovány, používány a známy
zda jsou bezpečnostní politiky a provozní postupy pro omezení
fyzického přístupu k datům držitelů karet:
• dokumentovány,
Pracovníci si musí být průběžné vědomi
bezpečnostních politik a provozních postupů pro
omezení fyzického přístupu k datům držitelů karet
a systémům v prostředí datům držitelů karet.
strana 87
Listopad 2013
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.1 Implementovat auditní záznamy pro
spojení všech přístupů k systémovým
komponentám s jednotlivými
individuálními uživateli.
10.1 Ověř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.2 Prostř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 spojeny s 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 s navš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.
strana 88
Listopad 2013
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ích
změny, dodatky a odstranění může pomoci
vystopovat kroky provedené 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.5 Použití a změ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í
nebo vymazání účtů s kořenovými
nebo administrativními privilegii
10.2.5.a
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.
PCI DSS Požadavky
Ověřit, zda je zaznamenáváno použití mechanismů identifikace a
autentizace.
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í nebo vymazání jakýchkoli účtů s kořenovými nebo
administrativními privilegii.
strana 89
Listopad 2013
PCI DSS Požadavky
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:
• Inicializace auditních záznamů
• Vypnutí nebo pozastavení auditních záznamů.
10.2.7 Vytvoření a mazání objektů na
systémové úrovni
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.2.7 Ověřit, zda je zaznamenáváno vytváření a mazání objektů
na systémové úrovni.
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ů.
Vysvětlení
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í.
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í nebo odstraňování
objektů na úrovni systému, jako jsou databázové
tabulky nebo uložené procedury, bude snadnější
určit, zda takovéto změny byly schváleny.
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.
strana 90
Listopad 2013
PCI DSS Požadavky
10.4 S použitím technologie č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.
strana 91
Listopad 2013
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áznamy chráněné, i když bude
systém generování protokolů kompromitován.
strana 92
Listopad 2013
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áznamy mohou být zapisovány přímo, nebo
přeneseny či kopírovány z externích systémů, do
bezpečného vnitřního systému nebo 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. Denní kontrola
protokolů minimalizuje množství času i vystavení
vůči možnému narušení.
Pravidelný přezkum protokolů pracovníky nebo
automatickými prostředky napomůže identifikovat
a aktivně řešit neoprávněný přístup k prostředí dat
drž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.
strana 93
Listopad 2013
PCI DSS Požadavky
10.6.1 Prozkoumat následující body
nejméně jednou denně:
• Všechny bezpečnostní události
• Protokoly o všech systémových
komponentách, které uchovávají,
zpracovávají nebo přenášejí data
držitelů karet (CHD) a/nebo SAD,
nebo které by mohly mít vliv na
bezpečnost dat držitelů karet (CHD)
a/nebo SAD
• Protokoly všech systémových
komponent
• Protokoly všech serverů a
systémových komponent, které
vykonávají funkce zabezpečení
(například firewally, systémy
detekce narušení / prevence proti
narušení systémů (IDS/IPS),
autentizace serverů, přesměrující
servery pro e-commerce, atd.).
10.6.1.a Zkontrolovat bezpečnostní politiky a procedury a ověřit,
zda procedury jsou definovány pro přezkoumání následující bodů
nejméně jednou denně, a to buď manuálně nebo pomocí nástrojů
protokolu:
• Protokoly o všech systémových komponentách, které
uchovávají, zpracovávají nebo přenášejí data držitelů karet
(CHD) a/nebo SAD, nebo které by mohly mít vliv na
bezpečnost data držitelů karet (CHD) a/nebo SAD
• Protokoly všech systémových komponent
• Protokoly všech serverů a systémových komponent, které
vykonávají funkce zabezpečení (například firewally, systémy
detekce narušení / prevence proti narušení systémů
(IDS/IPS), autentizace serverů, přesměrující servery pro ecommerce, atd.).
10.6.1.b Sledovat procesy a dotázat se pracovníků a ověřit, zda
jsou následující body prověřeny nejméně jednou denně:
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řezkum bezpečnostních
událostí, například oznámení nebo výstrahy, které
identifikují podezřelé nebo neobvyklé aktivity, i
protokolů z kritických systémových komponent a
protokolů 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ích problémů. Všimněte
si, že stanovení "bezpečnostní události" se bude
lišit pro každou organizaci, a mohou se brát v
úvahu daný typ technologie, umístění a funkčnost
zařízení. Organizace mohou také chtít zachovat
základní linii "normálního" provozu a napomoci
tak k identifikaci anomálního chování.
• Protokoly o všech systémových komponentách, které
uchovávají, zpracovávají nebo přenášejí data držitelů karet
(CHD) a/nebo SAD, nebo které by mohly mít vliv na
bezpečnost data držitelů karet (CHD) a/nebo SAD
• Protokoly všech systémových komponent
• Protokoly všech serverů a systémových komponent, které
vykonávají funkce zabezpečení (například firewally, systémy
detekce narušení / prevence proti narušení systémů
(IDS/IPS), autentizace serverů, přesměrující servery pro ecommerce, atd.).
10.6.2 Sledovat pravidelně záznamy
všech ostatních systémových
komponent podle politiky organizace a
strategie řízení rizik, podle
stanoveného ročního posouzení rizik
organizace.
zda jsou definovány procedury pro pravidelné sledování
protokolů všech ostatních systémových komponent - a to buď
ručně nebo pomocí nástrojů protokolu - založené na politikách
organizace a strategie řízení rizik.
10.6.2.b Zkontrolovat dokumentaci k posouzení rizik organizace,
dotázat se pracovníků a ověřit, zda sledování je prováděno v
souladu s politikou organizace a strategie řízení rizik.
Záznamy pro všechny ostatní systémové
komponenty by také měly být pravidelně
přezkoumávány za účelem zjištění náznaků
možných problémů nebo pokusů o získání
přístupu k citlivým systémům prostřednictvím
méně citlivých systémů. Četnost vyhodnocování
by měla být stanovena v ročním posouzení rizik
subjektu.
strana 94
Listopad 2013
PCI DSS Požadavky
10.6.3 Vyhodnotit výjimky a anomálie
zjištěné při procesu přezkumu.
zda jsou definovány procedury pro posuzování výjimek a
anomálií, identifikovaných během prověřování.
10.6.3.b Prověřit procesy a dotázat se pracovníků a ověřit, zda je
prováděno vyhodnocení výjimek a anomá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 k dispozici nejméně po dobu
jednoho roku.
10.7.c Dotázat se pracovníků, sledovat procesy a ověřit, zda
mohou být protokoly bezprostředně obnoveny pro analýzu za
minimálně tři poslední měsíce.
provozní procedury pro monitorování
veškerého přístupu k síťovým zdrojům a
datům držitelů karet jsou
10.8 Zkontrolovat dokumentaci, dotázat se pracovníků a ověřit, zda
bezpečnostní politiky a provozní postupy pro monitorování
veškerého přístupu k síťovým zdrojům a datům držitelů karet jsou:
• dokumentovány,
Vysvětlení
Pokud výjimky a anomálie zjištěné během
procesu přezkumu protokolů nejsou
vyhodnocovány, subjekt si nemusí být vědom
nepovolených a potenciálně škodlivých činností,
které se vyskytují v rámci jeho vlastní sítě.
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íci si musí být průběžné vědomi
bezpečnostních politik a denních provozních
procedur pro monitorování veškerého přístupu k
síťovým zdrojům a datům držitelů karet a provádět
je.
strana 95
Listopad 2013
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 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ůže pomoci administrátorům rychle
identifikovat neautorizováná bezdrátová zařízení, a
reakce na identifikaci neautorizovaných bezdrátových
pří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.
strana 96
Listopad 2013
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 Zkontrolovat dokumentované záznamy a ověřit, zda
je udržován seznam autorizovaných bodů bezdrátového
přístupu a provozní zdůvodnění je dokumentováno pro
všechny autorizované body bezdrátového přístupu.
11.1.2 Zavést procedury reakce na
bezpečnostní události v případě zjištění
neautorizovaného bodu bezdrátového
přístupu.
11.1.2.a Zkontrolovat 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.b Dotázat se odpovědných pracovníků a/nebo
prověřit nedávné bezdrátového skenová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.
strana 97
Listopad 2013
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ů:
Vysvětlení
Sken zranitelnosti je automatický nástroj 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ři typy skenování zranitelnosti potřebné
pro PCI DSS:
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é zranitelnosti byly posouzeny.
Může být vyžadována další dokumentace k
ověření, že neopravené zranitelnosti jsou
v řešení.
• Interní čtvrtletní skenování zranitelnosti
kvalifikovanými pracovníky (není vyžadováno
použití PCI SSC Schváleného dodavatele
skenování (Approved Scanning Vendor, ASV)
• Externí čtvrtletní skenování zranitelnosti, které
musí být provedeno ASV
• Vnitřní a vnější skenování podle potřeby po
významných změnách
Jakmile jsou tyto nedostatky identifikovány, subjekt
je opraví a opakuje skenování, dokud nejsou
všechny zranitelnosti opraveny.
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
1) poslední výsledek skanu byl úspěšný,
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.
2) subjekt má dokumentované politiky a
procedury vyžadující čtvrtletní skenování, a
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.
strana 98
Listopad 2013
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.3 Prová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ěřit reporty 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ěnu je
vysoce závislá na konfiguraci daného prostředí.
Pokud aktualizace nebo modifikace by mohla
umožnit přístup k datům držitelů karet nebo ovlivnit
bezpečnost dat držitelů karet, pak to může být
považováno za vý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
strana 99
Listopad 2013
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 Implementovat metodiku pro
penetrační testování, které zahrnuje
• Testování je založeno na přístupech
penetračního testování přijatém v oboru
(např. NIST SP800-115)
• Zahrnuje pokrytí pro celé ohraničené
prostředí dat držitelů karet a kritických
systémů
11.3 Zkontrolovat metodiku penetračního testování, dotázat
se odpovědných pracovníků a ověřit, zda je metodika
implementována a zahrnuje následující body:
• Je založena na přístupech penetračního testování přijatém
v oboru (např. NIST SP800-115)
• Zahrnuje pokrytí pro celé ohraničené prostředí dat držitelů
karet a kritických systémů
• Interní i externí testování sítě
• Zahrnuje interní i externí testování sítě
• Obsahuje testy pro ověření segmentace a kontroly pro
snižování rozsahu
• Obsahuje testy pro ověření segmentace
a kontroly pro snižování rozsahu
• Definuje penetrační testy aplikační vrstvy, které zahrnují
minimálně zranitelnosti uvedené v Požadavku 6.5
• Definuje penetrační testy aplikační
vrstvy, které zahrnují minimálně
zranitelnosti uvedené v Požadavku 6.5
• Definuje penetrační testy síťové vrstvy,
které zahrnují komponenty podporující
síťové funkce a také operační systémy
• Zahrnuje přezkoumání a posouzení
hrozeb a zranitelností během
posledních 12 měsíců
• Definuje penetrační testy síťové vrstvy, které zahrnují
komponenty podporující síťové funkce a také operační
systémy
• Zahrnuje přezkoumání a posouzení hrozeb a zranitelností
během posledních 12 měsíců
• Určuje uchovávání výsledků testování penetrace a
výsledků nápravných akcí.
• Určuje uchovávání výsledků testování
penetrace a výsledků nápravných akcí.
Poznámka: Tato aktualizace Požadavku
11.3 je pokládána za osvědčený postup do
30. června 2015, 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 v3.0.
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 strategii na
obranu proti ú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šit pro
různé organizace, a typ, hloubku a složitost
testování bude záviset na konkrétním prostředí a
posouzení rizik organizace.
strana 100
Listopad 2013
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.a Zkontrolovat rozsah práce a výsledků z
nejnovějšího externího penetračního testu a ověřit, zda
penetrační testování se provádí takto:
• Podle definované metodiky
• Nejméně jednou ročně
• Po všech významných změn v prostředí.
11.3.1.b Ověřit, zda test byl proveden kvalifikovaným
interním zdrojem nebo kvalifikovanou externí třetí stranou, a
je-li to případné, existuje organizační nezávislost testera
(nemusí být QSA nebo ASV).
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 Zkontrolovat rozsah práce a výsledků z
nejnovějšího externího penetračního testu a ověřit, zda
penetrační testování se provádí nejméně jednou ročně a po
jakékoliv významné změně prostředí:
Vysvětlení
Penetrační testy prováděné v pravidelných
intervalech a po významných změnách prostředí je
proaktivní bezpečnostní opatření, které pomáhá
minimalizovat potenciální přístup k prostředí dat
držitelů karet zlovolnými jedinci.
Určení toho, co představuje významná aktualizace
nebo změna, je silně závislé na konfiguraci daného
prostředí. Pokud aktualizace nebo modifikace by
mohla umožnit přístup k datům držitelů karet nebo
ovlivnit bezpečnost prostředí dat držitelů karet, pak
by to mohlo být považováno za významné.
Provádění penetračních testů po aktualizace sítě a
modifikaci poskytuje záruku, že kontroly, o nichž se
předpokládá se, že jsou zavedeny, po aktualizaci
nebo modifikaci stále efektivně pracují.
• Podle definované metodiky
• Nejméně jednou ročně
• Po všech významných změn v prostředí.
11.3.2.b Ověřit, zda test byl proveden kvalifikovaným
interním zdrojem nebo kvalifikovanou externí třetí stranou, a
je-li to případné, existuje organizační nezávislost testera
(nemusí být QSA nebo ASV).
11.3.3 Zneužitelné zranitelnosti zjištěné v
průběhu penetračních testů jsou
opraveny a testování se zopakuje a ověří
provedené opravy.
11.3.3 Zkontrolovat výsledky penetračních testů a ověřit,
zda zjištěné zneužitelné zranitelnosti byly opraveny a že
opakované testování potvrdilo, že zranitelnost byla
opravena.
strana 101
Listopad 2013
PCI DSS Požadavky
Vysvětlení
11.3.4 Pokud segmentace se používá k
oddělení prostředí držitelů karet od jiných
sítí, provádět penetrační testy nejméně
jednou ročně a po každé změně kontroly
/ metody segmentace a ověřit, zda
metody segmentace jsou funkční a
efektivní, a oddělují všechny systémy
mimo rozsah od systémů v rozsahu.
11.3.4.a Zkontrolovat kontroly segmentace a přezkoumat
metodiky penetračního testování a ověřit, zda jsou
definovány procedury penetračního testování k otestování
všech metod segmentace a potvrdit, zda jsou funkční a
efektivní, a oddělují všechny systémy mimo rozsah od
systémů v rozsahu.
Penetrační testování je důležitým nástrojem pro
potvrzení, že jakékoliv zavedená segmentace
oddělující prostředí dat držitelů karet od ostatních
sítí je efektivní. Penetrační testování by se mělo
zaměřit na kontroly segmentace, a to jak z vnějšku
sítě tak i zevnitř sítě subjektu, ale mimo prostředí
dat držitelů karet, aby se potvrdilo, že penetrace
není schopna překonat kontrolu segmentace.
Například testování sítě a/nebo skenování
otevřených portů, a ověřit že neexistuje propojení
mezi sítěmi v rozsahu a mimo rozsah.
11.3.4.b Zkontrolovat si výsledky z nejnovějšího
penetračního testu a ověřit, zda poslední penetračního
testování ověřuje kontroly segmentace:
• Je provedeno nejméně jednou ročně a po každé změně
kontroly / metody segmentace.
• Pokrývá všechny používané kontroly / metody
segmentace.
• Ověřuje, zda metody segmentace jsou funkční a
efektivní, a oddělují všechny systémy mimo rozsah od
systémů v rozsahu.
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í.
Udržovat všechny detekční i preventivní
software (engines) aktualizované.
11.4.a Zkontrolovat konfiguraci systémů a síťových diagramů
a ověřit, zda jsou nasazeny techniky (jako je detekce narušení
systémů a/nebo systémy prevence proti narušení) k
monitorování veškeré komunikace:
• Na hranici prostředí dat držitelů karet
• V kritických bodech v prostředí dat držitelů karet.
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.
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.
strana 102
Listopad 2013
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 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 Implementovat proces k reakci na
každé upozornění generované
mechanismem detekce změn.
provozní procedury pro monitorování
bezpečnosti a testování byly
dokumentovány, používány a známy všem
dotčeným stranám.
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 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 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
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í jsou zkoumána a řešena.
11.6 Zkontrolovat dokumentaci, dotázat se pracovníků a
ověřit, zda bezpečnostní politiky a provozní postupy pro
monitorování bezpečnosti a testování jsou:
• dokumentovány,
Pracovníci si musí být vědomi a průběžně
naplňovat bezpečnostní politiky a provozní
procedury pro monitorování bezpečnosti a
testování.
strana 103
Listopad 2013
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
12.1 Zavést, vydat, udržovat a šířit
bezpečnostní politiku.
12.1.1 Přezkoumat bezpečnostní politiku
nejméně jednou ročně a aktualizovat
politiku při změně prostředí.
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í vyhodnocení rizik.
Vysvětlení
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 Ověřit, zda politika bezpečnostni informací je
prověřena nejméně jednou ročně a podle potřeby
aktualizována, aby odrážela změny v obchodních cílech
nebo rizika prostředí.
12.2.a Ověřit, zda každoroční proces vyhodnocení rizik je
dokumentován a identifikuje aktiva, hrozby a zranitelná místa
a vyúsťuje ve formální vyhodnocení 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.
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.
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.
strana 104
Listopad 2013
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říklady kritických technologií
zahrnují, kromě jiného, vzdálený přístup a
bezdrátové technologie, notebooky,
tablety, přenosná média, používání emailu a použí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í.
strana 105
Listopad 2013
PCI DSS Požadavky
12.3.4 Metoda, jak přesně a snadno
určit vlastníka, kontaktní informace a
účel (např. označování, kódování a/nebo
inventarizace zaří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ím a/nebo inventarizací 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.b Zkontrolovat konfigurace pro technologie
vzdáleného přístupu a ověřit, zda se relace vzdáleného
přístupu automaticky odpojí 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í.
strana 106
Listopad 2013
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.
Kde je provozní potřeba oprávněna,
musí politiky použití vyžadovat ochranu
dat v souladu s platnými požadavky PCI
DSS.
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.
strana 107
Listopad 2013
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.c Dotázat se vzorku pracovníků a ověřit, zda dokončili
školení a jsou si vědomi důležitosti zabezpečení dat drž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.
strana 108
Listopad 2013
Vysvětlení
PCI DSS Požadavky
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í
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.8 Prostřednictvím sledování, přezkumu politik a procedur a
prověřením podpůrné dokumentace ověřit, zda procesy jsou
implementovány pro řízení poskytovatelů služeb, s nimiž jsou
data držitelů karet sdílena, nebo kteří by mohli mít vliv na
bezpečnost dat 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.8 Udržovat a implementovat politiky a
procedury pro řízení poskytovatelů služeb,
s nimiž jsou data držitelů karet sdílena,
nebo kteří by mohli mít vliv na bezpečnost
dat držitelů karet, podle následujících
bodů:
12.8.1 Vést seznam poskytovatelů
služeb.
strana 109
Listopad 2013
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
jinak uchovávají, zpracovávají nebo
přenášejí jménem zákazníka, nebo do té
míry, že by mohli mít vliv na bezpečnost
prostředí dat držitelů karet zákazníka.
12.8.2 Prověřit písemné dohody a potvrdit, zda obsahují
ujednání ze strany poskytovatelů služeb, že jsou odpovědni
za bezpečnost dat držitelů karet, kterými poskytovatelé
služeb disponují nebo jinak uchovávají, zpracovávají nebo
přenášejí jménem zákazníka, nebo do té míry, že by mohli
mít vliv na bezpečnost prostředí dat držitelů karet zákazníka.
Poznámka: Přesné znění ujednání bude
záviset na dohodě mezi oběma stranami,
s uvedením podrobností o poskytované
službě a odpovědnostmi každé strany.
Ujednání nemusí obsahovat př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.
12.8.3 Ověřit, zda politiky a procedury jsou dokumentovány
a realizovány včetně řádného due diligence před zapojením
jakkéholiv poskytovatele služeb
Vysvětlení
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ů.
V souvislosti s Požadavkem 12.9, tento
požadavek písemné dohody mezi organizacemi a
poskytovateli služeb je určen na podporu jednotné
úrovně porozumění mezi stranami o svých
příslušných odpovědnostech dle standardu PCI
DSS. Například smlouva může obsahovat
příslušné požadavky PCI DSS, které musí být
dodržovány jako součást poskytované služby.
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.
Specifické procesy a cíle due diligence se budou
lišit pro každou organizaci. Příklady ke zvážení
mohou zahrnovat poskytovatelovy postupy pro
podávání zpráv, procedury oznamování narušení
a reakce na incidenty, podrobnosti o tom, jak jsou
odpovědnosti standardu PCI DSS rozděleny mezi
jednotlivé strany, jak poskytovatel ověřuje shodu
se standardem PCI DSS a jaké důkazy budou
poskytovány, atd.
strana 110
Listopad 2013
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.5 Udržovat informace o tom, které
požadavky PCI DSS jsou spravované
každým poskytovatelem služeb, a které
jsou řízeny subjektem.
12.8.5 Ověřit, zda subjekt udržuje informace o tom, které
požadavky PCI DSS spravují jednotliví poskytovatelé služeb
a které jsou řízeny subjektem.
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í.
12.9 Doplňková testovací procedura
pro poskytovatele služeb: Poskytovatelé
služeb písemně potvrdí zákazníkům, že
jsou odpovědni za bezpečnost dat držitelů
karet, které poskytovatel služeb má v
držení nebo jinak uchovává, zpracovává
nebo přenáší jménem zákazníka, nebo v
rozsahu, který by mohl mít vliv na
bezpečnost prostředí dat držitelů karet
zákazníka.
12.9 Doplňková testovací procedura pro poskytovatele
služeb:
Přezkoumat politiku a procedury poskytovatele služeb a
prověřit písemné předlohy dohod a potvrdit, zda poskytovatel
služby písemně potvrzuje zákazníkům, že bude dodržovat
všechny příslušné požadavky PCI DSS v rozsahu
poskytovatele služeb držení, přístupu nebo jiného uchovávání,
zpracovávání nebo přenášení dat držitelů karet zákazníka
nebo citlivých autentizačních dat, nebo jménem zákazníka
spravujících prostředí dat držitelů karet zákazníka.
Poznámka: Tento požadavek je pokládán
za osvědčený postup do 30. června 2015,
po tomto datu se stává požadavkem.
Tento požadavek se uplatňuje tehdy, pokud je
posuzovaný subjekt poskytovatelem služeb. Ve
spojení s Požadavkem 12.8.2, tento požadavek je
určen na podporu jednotné úrovně porozumění
mezi stranami o svých příslušných PCI DSS
odpově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ůsobem
poskytovatel služby poskytne a předá písemné
potvrzení mezi poskytovatelem a jeho zákazníky.
Poznámka: Přesné znění ujednání bude
záviset na dohodě mezi oběma stranami,
s uvedení podrobností o poskytované
službě a odpovědnostmi každé strany.
Ujednání nemusí obsahovat přesné znění
uvedené v tomto požadavku.
strana 111
Listopad 2013
PCI DSS Požadavky
12.10 Implementovat plán odezvy při
incidentech. Být připraven neprodleně
reagovat na narušení systému.
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.2 Testovat plán nejméně jednou
ročně.
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ů:
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í
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.
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 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.
strana 112
Listopad 2013
Vysvětlení
PCI DSS Požadavky
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
detekce jaký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ů.
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.
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ů, včetně detekce
neautorizovaných bodů bezdrátového přístupů, 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žet plán aktuální a schopný
reagovat na nové hrozby a bezpečnostní trendy.
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.
strana 113
Listopad 2013
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.1 Chrá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.1 Zejmé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 PCI DSS je určena pro
poskytovatele sdíleného hostingu, kteří
chtějí poskytovat svým obchodníkům a/nebo
poskytovatelům služeb zákazníkům
prostředím hostingu v souladu se
standardem PCI DSS.
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.1 Zajistit, aby měl subjekt
v kompetenci pouze své vlastní
procesy, které mají přístup k prostředí
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-li obchodníkovi nebo poskytovateli
služeb umožněno spouštět vlastní
aplikace na sdíleném serveru, tyto by měly
být spouštěny pod uživatelským jménem
ID obchodníka nebo poskytovatele služeb,
spíše než pod privilegovaný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.
strana 114
Listopad 2013
PCI DSS Požadavky
A.1.2 Omezit přístup a oprávnění
každého subjektu pouze na jeho
vlastní prostředí dat držitelů karet.
Vysvětlení
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.b Ověř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.).
Chcete-li zajistit, aby přístup a oprávnění
byla omezena tak, že každý obchodník
nebo poskytovatel služeb má přístup pouze
ke svému vlastnímu prostředí, zvažte
1.
Zvýhodnit uživatelské ID webového
serveru obchodníka nebo
poskytovatele služeb;
2.
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ů.
Privilegia uživatelského ID na
webovém serveru obchodníka nebo
poskytovatele služeb;
3.
Udělená oprávnění číst, zapisovat a
spouš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 do
systémových binárních souborů;
5.
Udělená oprávnění k souborům
protokolů (log files) obchodníka a
poskytovatele služeb; a
6.
Kontroly k zajištění toho, aby jeden
obchodník nebo poskytovatel služeb
nemohl monopolizovat systémové
zdroje.
Důležité: Soubory subjektu nesmí být sdíleny skupinou.
A.1.2.e Zajistit, 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).
Logy by měly být k dispozici v prostředí
sdíleného hostingu, takže obchodníci a
poskytovatelé služeb mají přístup k logům
specifických pro jejich prostředí dat
držitelů karet, a mohou 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í.
strana 115
Listopad 2013
PCI DSS Požadavky
A.1.4 Umožnit, aby procesy umožnily
včasné forenzní šetření v případě
narušení u jakéhokoli obchodníka nebo
poskytovatele služby.
Vysvětlení
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ů.
Poskytovatelé sdíleného hostingu musí
mít procesy poskytují rychlou a snadnou
odezvu v případě, že je potřeba
forenzního šetření narušení, a to až na
odpovídající úroveň údajů tak, aby byly k
dispozici údaje jednotlivého obchodníka
nebo poskytovatelem služeb.
strana 116
Listopad 2013
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 DSS viz 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čnosti hodnotitelem, 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á autentizace z 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í.
strana 117
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í
Náhradního
řeš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ánka 118
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
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.
Společnost XYZ bude požadovat, aby se
všichni uživatelé přihlašovali ze svých stanic
do serverů pomocí příkazu SU (substitute
user). Ten umožňuje uživateli přístup ke
„kořenovému“ účtu a umožňuje provést akce
pod tímto účtem, zároveň však umožňuje
přihlášení v adresáři SU. Tak může být
prostřednictvím SU účtu každá uživatelova
akce vysledována, aniž by bylo „kořenové“
heslo“ sdíleno s uživateli.
5. Ověření
Náhradního
řešení
Definovat, jak bude
náhradní řešení ověřeno a
testováno.
Společnost XYZ dokazuje hodnotiteli, že
provedený příkaz SU se spouští a všechny
aktivity prováděné těmito jednotlivci
využívající tento příkaz jsou přihlášeni 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 SU
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ánka 119
November 2013
Příloha D: Segmentace a výběru vzorků provozních objektů/systémových
komponent
Page 120
November 2013

Data Security Standard Standard bezpečnosti dat (DSS)

Transkript

Podobné dokumenty

PCI Repafast ® Tixo - Severní stavební, as

PCI Repafast ® Fluid - Severní stavební, as