PCI-DSS

Izvor: SIS Wiki

Skoči na: orijentacija, traži

Članovi tima:

Karlo Duganić

--Karlo.duganic 17:25, 2. studenog 2015. (CET)

Nikola Buković

--Nikola.bukovic 17:25, 2. studenog 2015. (CET)

Sadržaj

Uvod

PCI DSS

U današnje vrijeme kreditne kartice se sve više koriste, skoro svaki građanin posjeduje kreditnu karticu, a zadnjih godina trend je internet kupovina, te plaćanje preko interneta.
Uz velik porast inetrnet kupovine i plaćanjem kreditnim karticama, javlja se i velik problem s prijevarama i krađom. Prijevare putem kreditnih kartica i krađom putem neovlaštenog korištenja tuđih kreditnih kartica. Da bi kartično poslovanje bilo sigurnije, najveće kartične kuće su se udružile, i razvijena je norma PCI DSS (Payment Card Industry Data Security Standard) koja se sastoji od 12 zahtjeva koje organizacija mora ispunjavat kako bi bila usklađena sa PCI DSS standardom.

--Nikola.bukovic 16:18, 17. siječnja 2016. (CET)

Povijest

Osnivaći PCI DSS

PCI DSS standard nastao je 2004. godine u tome su sudjelovale četiri glavne tvrtke u području kartičnog poslovanja, a to su:

Visa,
MasterCard,
Discover,
American Express,

te tvrtke zajedno s JCB čine PCI odbor za sigurnosne standarde koji propisuje i upravlja PCI DSS standardom.

Standard PCI DSS izvorno je počeo kao 5 zasebnih različitih programa to su:

program za sigurnost kartičnih informacija tvrtke Visa (eng. Visa Card InformationSecurity Program),
program za zaštitu podataka tvrtke MasterCard (eng. MasterCard Site Data Protection),
smjernice za upravljanje sigurnosnim informacijama tvrtke American Express (eng.American Express Data Security Operating Policy),
program tvrtke Discover za sigurnost informacija i sukladnost (eng. Discover Informationand Compliance),
program tvrtke JCB za sigurnost podataka (eng. JCB Data Security Program).

PCI SSC-odbor za sigurnosne standarde

PCI odbor za sigurnosne standarde (eng. The Payment Card Industry Security Standards Council, PCI SSC) osnovan je 15. prosinca 2004. Godine te je tada objavljen Standard sigurnosti podataka industrije platnih kartica (PCI DSS). Prema [1]

Verzije standarda :

1. Verzija 1.0, 2004. Godine,

2. Verzija 1.1, rujan 2006. Godine,

3. Verzija 1.2, poboljšana prilagodljivost, pažnja posvećena novim rizicima i opasnostima listopad 2008. Godine,

4. Verzija 1.2.1, kolovoz 2009. Godine,

5. Verzija 2.0, listopad 2010. Godine,

6. Verzija 3.0 studeni 2013. Godine,

7. Verzija 3.1 travanj 2015. Godine. Ovo je verzija koja trenutno vrijedi. Prema [2]

--Nikola.bukovic 16:18, 17. siječnja 2016. (CET)

Razlike u odnosu na prijašnju verziju

PCI DSS verzije 3.1 ne donosi velike promjene kao što su to prijašnje verzije, ali promjene su jednako važne. Jedna od glavnih promjena koje su stupile na snagu novom verzijom standarda je fizička sigurnost POS(Point-of-sale) uređaja.

Jedna od bitnijih promjena stupila je na snagu 30.06.2015 kao skup pravila koja pokrivaju fizičke POS uređaje. Ti zahtjevi diktiraju korištenje inventurnih lista, inspekcija i treninga za zaštitu tih uređaja od neaturiziranog korištenja. Trgovci moraju nastavit održavati inventar koji dolazi u fizički kontakt sa platnom karticom. U inventurne liste potrebno je upisivati proizvođača, model, serijski broj i navedenu njegovu fizičku lokaciju. Isto tako zabranjuje se SSL protokol i raniji TLS, zahtjeva se migracija na TLS 1.2 i to od 13.6.2016. Godine.
Izvor [3]
--Nikola.bukovic 16:20, 17. siječnja 2016. (CET)

PCI standard sigurnosti

PCI standard sigurnosti su tehnički i operacijski zahtjevi koje je postavio PCI odbor za sigurnosne standarde u cilju zaštite vlasnika kartica.

PCI standard sigurnosti uključuje:

PCI Data Security Standard (DSS) - Standard sigurnosti podataka industrije platnih kartica široko je prihvaćen skup pravila i procedura namijenjenih za optimizaciju sigurnosti kreditnih, debitnih i novčanih kartičnih transakcija koji štiti vlasnike kartica protiv zlouporabe njihovih osobnih

PIN Transaction Security (PTS) - to je skup sigurnosnih zahtjeva koje moraju poštivati proizvođači uređaja koji se koriste za obradu PIN-ova korisnika kartica kao i druge kartične aktivnosti. Zahtjevi daju proizvođačima smjernice o tome kako uređaji moraju biti projektirani, proizvedeni i transportirani organizacijama koje ih koriste.

Payment Application Data Security Standard (PA-DSS)- Standard sigurnosti aplikacija industrije platnih kartica, vrijedi za bilo koju organizaciju koja je razvila programsko rješenje ili se bavi integriracijom kartičnih aplikacija. Takva programska rješenja se koriste u svrhu skladištenja, obrade ili prijenosa podataka korisnika kartica kao dio autorizacije kada su ti programi prodani, distribuirani ili licencirani trećim stranama.Izvor[4]

--Nikola.bukovic 16:19, 17. siječnja 2016. (CET)

Usklađivanje sa standardom PCI DSS

Najveće kartične organizacije, a ujedno i osnivaći PCI DSS standarda Visa, MasterCard, American Express, Discover, JCB zahtjevaju svim organizacijama koje spremaju, obrađuju ili prenose kartične podatke da se usklade sa standardom PCI DSS. To uključuje:

banke,
pružatelje usluga plaćanja karticama,
internet trgovce,
trgovce s fizičkim prodajnim mjestima.

Usklađivanje nije jednokratni proces, trgovci su dužni jednom godišnje obavit provjeru usklađenosti s standardom, kako bi u svakom trenutku bili usklađeni. Provjeru usklađenosti prodvodi kvalificirani procjenitelj sigurnosti. Ovisno to tome koliko je koja organizacija velika ona treba provesti potpuni PCI DSS upitnik za samoprocjenu (eng. Self-Assessment Questionnaire, SAQ), ili formalnu procjenu. Upitnik za samoprocjenu odnosi se na manje trgovce, dok se za veće obavlja projcena usklađenosti na lokaciji za usklađenost sa PCI DSS. Ako se pak podaci korisnika kartice prenose elektorničkim putem, tada se provodi kvartalno skeniranje, to je skeniranje svakih tri mjeseca, odnosi se na organizacije koje spremaju elektorničke podatke o karticama ili prenose podatke platne kartice putem aplikacije.

Svi trgovci i organizacije moraju poslati banci prihvatitelju potvrdu (eng. Attestation ofCompliance, AOC) o usklađenosti sa standardom PCI DSS. Ponekad treba i dodatno dostavit kvartalno skeniranje, upitnik za samoprocjenu ovisno o zahtjevima druge strane.

Organizacije najčešće ne prolaze provjeru usklađenosti sa standardom PCI DSS zbog toga što se događa da se podaci kao što je PIN čuva i nakon autorizacije, što nije u skladu sa standardom, ili se pak brojevi kartica čuvaju uz nedovoljne mjere zaštite.Izvor[5]

Prednosti usklađivanja sa standardom PCI DSS

Prednosti usklađivanja s PCI DSS standardom su:

Može donjeti koristi tvrtci,
Sustavi su sigurni,
Korisnici imaju povjerenja prilikom obavljanja transakcija,
Pomaže u sprečavanju narušavanja sigurnosti i integriteta

Ukoliko tvrtka nije usklađena sa standardom PCI DSS , ishod može biti vrlo loš za poslovanje te tvrtke. Jedan incident može narušit cijelo poslovanje, te do gubitka prodaje, a na kraju i pad dionica.Također moguće posljedice za tvrtku su tužbe, državne kazne i slično.
--Nikola.bukovic 16:19, 17. siječnja 2016. (CET)

Podjela subjekata prema PCI DSS

U standardu PCI DSS podjelu subjekata imamo na dva naćina, jedan je podjela pružatelja usluga, a druga je podjela prema razinama.Izvor[6]

Pružatelji usluga

1.Banka zaprimatelj (eng. Acquirer bank)-Banka zaprimatelj nalazi se na vrhu piramide odgovornosti i ona je odgovorna prema VISA-i i MasterCard-u za sigurnost poslovanja svojih trgovaca.

2.Trgovac (eng. Merchant)-Trgovac je ugovorno vezan za banku zaprimatelja i on je početna točka u lancu puta kartičnih podataka. Od prodajnog mjesta trgovca kartični podaci putuju kroz mrežu prema banci zaprimatelju.

3.Treće strane (eng. Third Parties)-U treće strane ubrajamo sve druge tvrtke koje su povezane s bankom i trgovcem te imaju u nekom dijelu uvid u kartične podatke. U ovu skupinu ubrajamo sve sustave za Internet naplatu (eng. Internet Payment Gateway sustav, IPG), sustave za usluge kartičnog plaćanja, tvrtke koje pružaju usluge poslužitelja internetskih stranica, telekom operatere, proizvođače sklopovlja, proizvođače programa, ponuđače usluga pohrane kartičnih podataka, servisere opreme i dr. Također u ovu skupinu spadaju i podizvođači usluga, npr. dostavne službe, ugovorno vezane tvrtke koje održavaju računalne sustave ili proizvode programe za naručitelja.

Prema razinama

1.Razina 1- U razinu 1 ubrajamo sve banke zaprimatelje, procesore za plaćanja (eng. payment processors),sustave za Internet naplatu (eng. Internet Payment Gateway) i one trgovce koji imaju više od 600,000 transakcija VISA kartica godišnje. Ova skupina dužna je jednom godišnje obaviti PCI DSS provjeru ovlaštenog revizora, kojeg odobrava PCI konzorcij. Također, potrebno je svaka tri mjeseca obaviti redovno skeniranje mreže, a jednom godišnje penetracijski test.

2.Razina 2- U razinu 2 ubrajamo sve subjekte koji ne spadaju u prvi, a pohranjuju, obrađuju ili prenose kartične podatke, te imaju od 120,000 do 600,000 kartičnih transakcija godišnje. Svi subjekti iz skupine druge razine dužni su jednom godišnje ispuniti atest koji predaju banci s kojom imaju ugovor. Također imaju obvezu obaviti mrežno skeniranje svaka 3 mjeseca.

3.Razina 3- ubrajamo sve subjekte koji pohranjuju, obrađuju ili prenose kartične podatke, ali imaju manje od 120,000 transakcija kartica godišnje. Svi subjekti iz skupine treće razine dužni su jednom godišnje ispuniti atest koji predaju banci s kojom imaju ugovor.

--Nikola.bukovic 16:19, 17. siječnja 2016. (CET)

PCI DSS u Hrvatskoj

PBZ Card u vlasništvu Privredne banke Zagreb svoje poslovanje je s standardom PCI DSS uskladila 2007. Godine Izvor[7]

Zagrebačka banka svoje je cijelokupno poslovanje uskladila s standardom PCI DSS do 15.1.2009. Godine. Izvor[8]

Splitska banka svoje je poslovanje uskladila s standardom PCI DSS, banka je usklađivanje s standardom porovela do 21. 5. 2010. Godine. Izvor[9]

Erste banka je također usklađena s standardom PCI DSS i to od 2013. Godine. Izvor[10]

--Nikola.bukovic 18:21, 17. siječnja 2016. (CET)

PCI DSS zahtjevi

Izgradnja i održavanje sigurne mreže i sustava

1. Postavljanje i održavanje konfiguracije firewall-a za zaštitu podataka vlasnika kartice

FireWall-ovi su uređaji koji kontroliraju promet dopušten između vlastite unutarnje i nepovjerljive vanjske mreže, kao i promet u osjetljivije dijelove unutarnje (povjerljive) mreže. Kao primjer osjetljivog dijela možemo uzeti prostor u kojem se čuvaju podaci vezani u kartično poslovanje. Zahtjevi untar ovog područja koji moraju bit zadovoljeni su:

1.1 Uspostaviti i implementirati firewall i ruter konfiguracije koje uključuju:

1.1.1 Formalni proces za odobravanje i testiranje svih mrežnih spajanja i promjena unutar konfiguracija firewall-a i rutera

1.1.2 Trenutni mrežni dijagram koji indentificira protok svih spajanja između okoline u kojoj se nalaze podatci vlasnika kartice i ostalih mreža, uključujući i bežične mreže

1.1.3 Trenutni dijagram koji prikazuje protok svih podataka vlasnika kartice kroz sustave i mreže

1.1.4 Zahtijeva se firewall na svakom internet spajanju između svakog DMZ-a i unutarnje zone mreže

1.1.5 Opis svih grupa, uloga i odgovornosti za menadžment mrežnih komponenti

1.1.6 Dokumentaciju za korištenje svih servisa, protokola, dopuštenih portova, uključujući i dokumentaciju implementiranih sigurnosnih značajki za nesigurne protokole

1.1.7 Zahtjeve za pregledom firewall-a i rutera, najmanje svakih šest mjeseci

1.2 Izgraditi konfiguracije firewall-a i rutera koje ne dupuštaju spajanja između nesigurnih mreža i svakog sustava komponenti u okolini u kojoj se čuvaju podaci vlasnika kartica

1.2.1 Ograničiti dolazni i odlazni promet na onaj koji je isključivo potreban za rad okoline podataka vlasnika kartica i posebno zabraniti sav ostali promet

1.2.2 Osigurati i sinkronizirati konfiguracijske dokumente rutera (da bi se spriječile neautorizirane promjene)

1.2.3 Instalirati opsežne firewall-ove između svih bežićnih mreža i okruženja podataka vlasnika kartica, konfigurirati navedene firewall-ove na odbijanje ili dopustiti promet jedino ukoliko je neophodan za poslovanje i dopustiti samo autoriziran promet

1.3 Zabraniti direktan javni pristup između interneta i neke sustavne komponente u okruženju podataka vlasnika kartica

1.3.1 Implementirati DMZ da bi se ograničio dolazni promet samo na sistemske komponente koje omogućuju autorizirane, javno dostupne servise, protokole i portove

1.3.2 Ograničiti dolazni internet promet prema IP adresama unutar DMZ-a

1.3.3 Ne dopustiti bilo kakvo direktno spajanje dolaznog ili odlaznog prometa između interneta i okruženja podataka vlasnika kartica

1.3.4 Implementirati mjere kriptiranja koje bi detektirale i bolkirale krivotvorene IP adrese dolaznih mreža

1.3.5 Ne dopustiti neautorizirani odlazni promet iz okoline podataka vlasnika kartica prema internetu

1.3.6 Implementirati dinamičko filtriranje paketa

1.3.7 Smjestiti sistemske komponente koje pohranjuju podatke vlasnika kartica u unutarnje mrežne zone, odvojene od DMZ-a ili ostalih nesigurnih mreža

1.3.8 Ne otkrivati privatne IP adrese i podatke o usmjerivanju neautoriziranim stranama

1.4 Instalirati osobni firewall na svaki mobilni uređaj i uređaj u vlasnišvu zaposlenika koji se spajaju na internet izvan poslovne mreže. Konfiguracija firewall mora uključivati: sprecifične konfiguracijske postavke definirane za osobne firewall programe, osobni firewall mora biti stalno aktivan, osobni firewall program ne smije se moći mijenjati od strane korisnika

1.5 Osigurati dokumentiranost sigurnosne politike i operacijskih procedura za upravljanje firewall-ima

2. Nekorištenje osnovnih (unaprijed postavljenih) lozinki i sigurnosnih parametara koji su definirani od strane proizvođača opreme

Zlonamjerni pojedinci često koriste unaprijed postavljene lozinke i ostale proizvođačeve postavke kako bi kompromitirali sustav. Navedene lozinke i postavke su dobro poznate u javnosti i vrlo lako se dolazi do njih. Kako bi se izbjegli takvi napadi prema PCI DSS-u zahtijeva se:

2.1 Promjena svih osnovnih proizvođačevih postavki i uklanjanje ili onemogućavanje nepotrebnih računa prije instaliranja sustava na mrežu

2.1.1 Za sva bežična okruženja spojena na okruženje podataka vlasnika kartica ili koja prenose podatke vlasnika kartica potrebna je promjena svih osnovnih postavki prilikom instalacije uređaja za bežično spajanje, uključujući postavljene osnovne enkripcijske ključeve, lozinke..

2.2 Razviti konfiguracijske standarde za sve komponente sustava. Osigurati da se pokriju sve poznate sigurnosne ranjivosti i da mogu biti konzistentne s industrijski prihvaćenim standardima zaštite. Mogu ih uključivati, ali ne moraju biti ograničeni na: ISO, NIST, SANS i slične standarde

2.2.1 Implementirati samo jednu osnovnu funkciju po serveru da bi se spriječile funkcije koje zahtijevaju različite sigurnosne razine od postojećih koje su na serveru

2.2.2 Omogućiti samo potrebne usluge, protokole i sl., koji su potrebni za funkcioniranje sustava

2.2.3 Implementirati dodatne sigurnosne značajke za neophodne usluge, protokole i ostale koji se smatraju nesigurnima, npr. koristiti tehnologije kao što su SSH, S-FTP, TLS ili IPSec VPN za zaštitu nesigurnih usluga, kao što su NetBIOS, file-sharing, Telnet, FTP i slični. *SSL i rane verzije TLS-a ne smiju se koristiti od 30.06.2016.

2.2.4 Konfigurirati parametre sustavske sigurnosti da se spriječi zloupotreba

2.2.5 Ukloniti sve nepotrebne funkcionalnosti, kao što su skripte, driveri, podsustavi, datotečni podsustavi i nepotrebne web servere

2.3 Kriptirati sve ne-konzolne administrativne pristupe koristeći snažne kripografske postupke. Koriste se tehonologije kao što su SSH, VPN ili TSL za web baziran menadžment i ostali ne-konzolni administrativni pristupi. *SSL i rane verzije TLS-a ne smiju se koristiti od 30.06.2016.

2.4 Održavati inventar sustavskih komponenti koji su u djelokrugu PCI DSS-a

2.5 Osigurati da su sigurnosna politika i operacijske procedure za organiziranje osnovnih postavki i ostalih sigurnosnih parametara dokumentirani i poznati svim uključenim stanama

2.6 Hosting provajderi moraju štititi svaki entitet i podatke vlasnika kartica

Zaštita podataka vlasnika kartice

3. Zaštita pohranjenih podataka vlasnika kartice

Metode zaštite, kao što su kriptiranje, haširanje i sl., su ključne komponente u zaštiti podataka vlasnika kartica. Metode za smanjenje rizika također uključuju: zabranu pohrane podataka vlasnika kartica (osim ako to nije obavezno), skraćenje informacija kao što je broj kartice (ako nije potreban cijeli) i neprosljeđivanje broja kartice porukama (elektroničkom poštom ili ostalim načinima slanja).

3.1 Zadržati pohranu podataka vlasnika kartice na najmanjoj razini primjenjujući:

- ograničavanje količine pohrane podataka i vremena zadržavanja podataka do onog koje je zahtijevano da bi se ispunili pravni, regulatorni i poslovni zahtjevi

- određivanje zahtjeva koji se tiču zadržavanja podataka vlasnika kartice

- procese za sigurno brisanje podataka kada više nisu potrebni

- proces (koji će se odvijati kvartalno) za identifikaciju i sigurno brisanje pohranjenih podataka vlasnika kartice koji prekoračavaju definirano zadržavanje

3.2 Zabranjuje se spremanje osjetljivih podataka o autentikaciji nakon autorizacije (moguća je pohrana podataka samo za tvrtke koje podržavaju usluge izdavanje ako postoji poslovno opravdanje za zadržavanje i podaci se spremaju na siguran način)

3.2.1 Zabranjeno je spremanje potpunog sadržaja tragova (npr. s magnetske trake, čipa i sl.) nakon autorizacije.

3.2.2 Zbranjeno je spremanje verifikacijskog koda kartice ili vrijednosti koja protvrđuje transakciju bez prisutnosti kartice, nakon autorizacije

3.2.3 Zabranjeno je spremanje osobnog identifikacijskog broja (PIN) ili kriptiranog PIN bloka nakon autorizacije

3.3 Potrebno je maskirati broj kartice prilikom prikazivanja

3.4 Prikazati broj kartice nečitljivim gdje god se sprema koristeći sljedeće metode: korištenje jednosmjerne hash funkcije, korištenje tokena, snažna kriptografija

3.4.1 Ako se koristi kriptiranje diska, logičkim pristupom mora se upravljati odvojeno i neovisno od operacije sustavne autentikacije i pristupa kontrolnim mehanizmima. Dekripcijski ključevi ne smiju biti povezani s korisničkim računom

3.5 Dokumentirati i izvršiti porcedure zaštite ključeva koji se koriste za sigurno spremanje podataka vlasnika kartica od otkrivanja i zloupotrebe

3.5.1 Ograničiti pristup kriptografskim ključevima na najmanji mogući broj korisnika

3.5.2 Spremati tajne i privatne ključeve koji se koriste za kriptiranje i dekriptiranje podataka u jednom od sljedećih oblika: 1. Kriptiranje ključem, 2. Kriptiranje sigurnim kriptografskim uređajem, 3. Kao najmanje dvije potpune komponente ključa u skladu s prihvaćenom metodom

3.5.3 Spremanje kriptografskih ključeva na najmanje mogućih lokacija

3.6 Potpuna dokumentacija i implementacija svih procesa upravljanih ključem i procedura za kriptiranje ključeva korištenih za enkripciju kartičnih podataka uključuju

3.6.1 Generiranje snažnih kriptografskih ključeva

3.6.2 Sigurnu distribuciju kriptografskih ključeva

3.6.3 Sigurnu pohranu kriptografskih ključeva

3.6.4 Promjenu ključeva kojima je istekao njihov kripto-period

3.6.5 Povlačenje ili zamjena ključeva na zahtjev

3.6.6 Prevencija neautorizirane izmjene kriptografskih ključeva

3.6.7 Zahtjev za čuvare kriptografskih ključeva da razumiju i prihvaćaju svoje dužnosti

3.7 Osiguravanje da su sigurnosna politika i operacijska procedura za zaštitu pohranjenih podataka dokumentirani i poznati svim članovima kojima su potrebni

4. Kriptiranje prijenosa podataka vlasnika kartice putem otvorenih, javnih mreža

Osjetljive informacije moraju biti kriptirane tijekom prijenosa putem mreža kojima je lak pristup. Loše konfigurirane bežične mreže i ranjivosti u enkripciji mogu biti mete za dobivanje privilegiranih informacija.

4.1 Korištenje snažnih kriptografskih i sigurnosnih protokola da bi se zaštitili osjetljivi podaci tijekom prijenosa preko otvorenih, javnih mreža uključujući: prihvaćanje samo ključeva i certifikata kojima vjerujemo, protokol koji se koristi podržava samo sigurne verzije i konfiguracije, snaga enkripcije mora biti primjerena metodologiji koja se koristi

4.1.1 Osiguravanje bežičih veza koje prenose podatke vlasnika kartica ili su spojene na okolinu u kojoj se podaci prenose, koriste najbolje standarde iz prakse, npr. IEEE 802.11i, za implementiranje snažne enkripcije za autentikaciju i prijenos

4.2 Nikada ne slati nezaštićene brojeve kartica raznim prijenosima kao što su e-mail, SMS, chat i sl.

4.3 Osigurati da sigurnosna politika i operacijske procedure kriptiranog prijenosa budu dokumentirane i dostupne korisnicima u procesu

Održavanje programa za upravljanje ranjivostima

5. Zaštita svih sustava od malwerea i redovito ažuriranje anti-virusnih programa

Osnovna zaštita od malwerea je anti-virusni program. Prema pravilniku, bez obzira na sve ostale mjere zaštite, anti-virusni program uvijek mora biti na svim uređajima. Točnije, definirano je:

5.1 Postaviti anti-virusni program na sve uređaje na koje može utjecati maliciozni kod

5.1.1 Osigurati da su anti-virusni programi sposobni detektirati, odstraniti i zaštititi uređaje od svih poznatih vrsta malicioznog koda

5.1.2 Za sustave za koje se očekuje da neće biti utjecaja malicioznog koda, potrebno je provoditi periodične evaluacije da bi se uvidjele prijetnje i da bi se procijenilo postoji li razlog za uvođenje anti-virusnog programa ili može i dalje funkcionirati bez njega

5.2 Osigurati da se svi anti-virusni mehanizmi održavaju na sljedeći način:

-uvijek je instalirana posljednja verzija,

-provode se periodična skeniranja,

-potrebno je generirati dnevnike provjera koji su definirani po PCI DSS standardu 10.7

5.3 Osigurati da su anti-virusni mehanizmi stalno aktivni i da se ne mogu isključiti ili promijeniti od strane korisnika, osim u slučaju kad je to specijalno odobreno od strane menadžmenta na ograničeni period

5.4 Osigurati da sigurnosna politika i operacijske procedure za zaštitu sustava od malwerea budu dokumentirane i dostupne korisnicima u procesu

6. Razvoj i održavanje sigurnosnih sustava i aplikacija

Napadači na sustav koriste poznate slabosti kako bi došli do željenih informacija ili željenog cilja. Proizvođači takve slabosti redovno uklanjaju i plasiraju kao nadogradnje. Za sprječavanje napadača u njihovom naumu potrebno je uvijek imati instaliranu zadnju dostupnu verziju i sve nadogradnje. Dodatni zahtjevi vezani uz razvoj i održavanje su:

6.1 Utvrđivanje procesa za indentifikaciju sigurnosnih slabosti koristeći provjerene vanjske izvore informacija o sigurnosnim slabostima i odrediti razinu rizika novo otkrivenih prijetnji

6.2 Utvrditi jesu li sve sustavne komponente i programi zaštićeni od svih poznatih slabosti. Instalirati kritične sigurnosne zakrpe najkasnije mjesec dana od izdavanja

6.3 Razviti sigurne unutarnje i vanjske aplikacije, na sljedeći način:

- u skladu sa PCI DSS-om,

- temeljeno na industrijskim standardima najbolje prakse,

- ukomponirati sigurnosne informacije kroz razvoj programa

6.3.1 Ukloniti razvoj, testiranja i aplikacijske račune (userID i lozinke) prije nego što aplikacija postane aktivna

6.3.2 Recenzirati kod zbog mogućih slabosti prije puštanja u produkciju ili korisnicima

6.4 Pratiti promjene kontrolnih procesa i procedura za sve promjene u sustavskim komponentama

6.4.1 Odvojiti razvojno/testno okruženje od produkcijskog okruženja i provoditi odvajanje s kontrolom pristupa

6.4.2 Odvojiti dužnosti između razvoja/testiranja i produkcijskog okruženja

6.4.3 Produkcijski podaci ne koriste se za testiranje i razvoj

6.4.4 Potrebno je uklanjanje testnih podataka i računa prije nego što sustav postane aktivan

6.4.5 Promjena proceduralnih kontrola za implementaciju sigurnosnih zakrpi i programa mora uključivati:

6.4.5.1 Dokumentaciju o utjecaju

6.4.5.2 Dokumentiranu odluku o promjeni od strane autorizirane osobe

6.4.5.3 Test sigurnosti da se potvrdi da promjene ne utječu na sigurnost sustava

6.4.5.4 Backup procedure

6.5 Odrediti česte ranjivosti u kodu prilikom razvoja programa

6.5.1 Nedostaci povezani uz injection, većinom SQL injection

6.5.2 Buffer overflows

6.5.3 Nesigurna kriptografska pohrana

6.5.4 Nesigurna komunikacija

6.5.5 Nepravilno rukovanje pogreškama

6.5.6 Sve visoko rizične slabosti indentificirane u procesu indentifikacije slabosti

6.5.7 XSS

6.5.8 Nepravilna kontrola pristupa

6.5.9 CSRF

6.5.10 Broken autentication and session menagment

6.6 Za javne web aplikacije , pronaći nove prijetnje i slabosti te osigurati zaštitu tim aplikacijama

6.7 Osigurati da sigurnosna politika i operacijske procedure za razvoj i održavanje sustava sigurnosti i aplikacija budu dokumentirane i dostupne korisnicima u procesu

Implementacija jakih mjera pristupa

7. Ograničiti pristup podacima vlasnika kartica po principu „need to know

Bitno je osigurati da samo autorizirane osobe mogu pristupiti ključnim podacima. Princip „Need to know“ se koristi kako bi se zajamčila prava pristupa samo najmanjoj količini podataka i privilegija koji su potrebni za izvršenje određenog zadatka.

7.1 Ograničiti pristup sustavskim komponentama i podacima vlasnika kartice samo onim pojedincima čiji posao zahtijeva takav pristup.

7.1.1 Definirati dozvole pristupa za svaku ulogu

7.1.2 Ograničiti pristup prema korisničkom ID-u na privilegije potrebne za obavljanje posla

7.1.3 Dodijeliti pristup baziran na poslovnoj klasifikaciji i funkciji svakog pojedinca

7.1.4 Zahtijevati dokumentirano odobrenje privilegija od strane autoriziranog osoblja

7.2 Utvrditi sustav za kontrolu pristupa sustavnim komponentama koji ograničava pristup s obzirom na korisnikov „Need to know“, i postavlja „deny all“, osim ako nije iznimno dopušteno. Ovaj sustav mora uključivati:

7.2.1 Pokrivenost svih sustavnih komponenti

7.2.2 Dodjela privilegija pojedincima s obzirom na njihovu poslovnu kvalifikaciju i funkciju

7.2.3 Zadanu postavku „deny-all“

7.3 Osigurati da sigurnosna politika i operacijske procedure za ograničavanje pristupa budu dokumentirane i dostupne korisnicima u procesu

8. Indentifikacija i autentikacija pristupa do sistemskih komponenata

Dodjeljivanje jedinstvene identifikacije (ID) svakoj osobi koja ima omogućen pristup osigurava da je svaki pojedinac osobno odgovoran za ono što radi. Moguće je pratiti rad svakog korisnika. Zahtjevi unutar ove skupine uključuju:

8.1 Definirati i primijeniti politike i procedure kako bi se osiguralo ispravno upravljanje identifikacijom korisnika za nepotrošačke korisnike i administratore na sve komponente sustava kako slijedi:

8.1.1 Dodijeliti svim korisnicima jedinstveni ID prije nego što im se dopusti pristup sustavskim komponentama ili podacima vlasnika kartice

8.1.2 Kontrolirati dodavanje, brisanje i modificiranje korisničkog ID-a i ostalih indentifikacijskih objekata

8.1.3 Trenutno zabraniti pristup za sve obrisane korisnike

8.1.4 Odstraniti sve korisnike koji su neaktivni više od 90 dana

8.1.5 Upravljati ID-ovima koje koriste dobavljači za pristup, podršku ili održavanje sustava pomoću udaljenog pristupa

8.1.6 Limitirati pristup korisnicima koji više od 6 puta pogriješe svoju lozinku

8.1.7 Postaviti vrijeme zaključavanja na minimalno 30 minuta ili dok administrator ne odobri korisnika

8.1.8 Ako je sesija neaktivna više od 15 minuta, potrebno je tražiti korisnika da se ponovo prijavi

8.2 Kao dodatak dodjeljivanju jedinstvenog ID-a, za prijavu je potrebno koristiti još neku od navedenih metoda:

- nešto što je osobno poznato, kao lozinka,

- nešto što posjedujete, kao što je token ili smart kartica,

- nešto što jesi, kao što su biometrijske odlike

8.2.1 Korištenje snažne kriptografije za prikazivanje svih autentikacijskih podataka, kako ne bi bile čitljive tijekom prijenosa i pohrane na svim komponentama sustava

8.2.2 Provjeriti identitet korisnika prije modificiranja autentikacijskih podataka

8.2.3 Lozinke moraju zadovoljavati sljedeće uvjete:

-zahtijevati minimalnu dužinu od sedam znakova,

-zahtijevati korištenje slova i brojki

8.2.4 Korisničke lozinke moraju se mijenjati minimalno svakih 90 dana

8.2.5 Ne dopuštati individualno postavljanje novih lozinki koje su jednake prijašnjima

8.2.6 Postaviti početnu lozinku samo za prvu prijavu, nakon koje mora biti zamijenjena

8.3 Koristiti dvofaktorsku autentikaciju za pristup s udaljene lokacije

8.4 Dokumentirati politiku autentikacije i procedure za sve korisnike

8.5 Ne smiju se koristiti grupni, dijeljeni ili generički ID-ovi, lozinke, autentikacijske metode i sl.

8.6 Gdje postoje drugi mehanizmi autentikacije (kao što su tokeni, smart kartice, certifikati i slično), potrebno je koristiti sljedeće metode:

-autentikacijska metoda mora biti dodijeljena individualnom računu i ne smije se dijeliti između drugih računa

8.7 Sav pristup bazi podataka koja zadrži podatke o vlasniku kartica mora biti ograničena na sljedeći način:

-samo administratori baze podataka mogu direktno pristupati ili postavljati upite nad bazom,

-ID aplikacije za bazu padataka može biti korišten samo od strane aplikacije

8.8 Osigurati da sigurnosna politika i operacijske procedure za indentifikaciju i autentikaciju budu dokumentirane i dostupne korisnicima u procesu

9. Ograničiti fizički pristup podacima

Svaki fizički pristup podacima ili sustavu koji sadrži podatke pruža priliku za manipuliranje podacima, brisanje, krađu i sl. Stoga je potrebno napraviti plan ljudi odgovornih za čuvanje spremišta podataka.

9.1 Koristiti odgovarajuće kontrole ulaza u objekt kako bi se mogao ograničiti i pratiti fizički pristup sustavu i podacima

9.1.1 Koristiti nadzorne kamere i/ili kontrolu pristupa za praćenje individualnog pristupa osjetljivim područjima. Analizirati prikupljene podatke i usporediti ih s ostalim unosima. Sve podatke potrebno je čuvati najmanje tri mjeseca, ako drugačije nije navedeno u zakonu

9.1.2 Implementirati fizičku i/ili logičku kontrolu da bi se ograničio pristup javno dostupnim mrežnim priključcima

9.1.3 Ograničiti fizički pristup bežičnim točkama spajanja, mrežnom/komunikacijskom hradveru, teleonskim linijama i sl.

9.2 Razviti procedure za jednostavno prepoznavanje između zaposlenog osoblja i posjetitelja

9.3 Kontrolirati fizički pristup zaposlenog osoblja osjetljivim područjima na sljedeće načine:

- pristup mora biti autoriziran i bazirati se na nekoj poslovnoj funkciji pojedinca,

- pristup mora biti trenutno zabranjen u slučaju završetka važenja dozvola i svi fizički pristupni mehanizmi kao što su ključevi, pristupne kartice i sl. moraju biti vraćene ili onemogućene

9.4 Provesti procedure indentifikacije i autorizacije posjetitelja. Procedure trebaju uključivati sljedeće:

9.4.1 Posjetitelji se moraju autorizirati prije ulaska i potrebno ih je pratiti cijelo vrijeme dok su u prostoru gdje se spremaju ili obrađuju podaci o vlasnicima kartica

9.4.2 Posjetitelji su identificirani i dodijeljena im je oznaka ili neka druga vrsta indentifikatora koja ima ograničeno vrijeme trajanja i omogućava prepoznavanje razlike između zaposlenika i posjetitelja

9.4.3 Posjetitelji su dužni predati oznaku prije izlaska iz ustanove ili na dan kada prestane važiti

9.4.4 Dnevnik posjetitelja se koristi za praćenje njihovog kretanja, kao i pregled pristupanja sobama s računalima, centrima s podacima i sl. Podatke je potrebno čuvati minimalno tri mjeseca ukoliko nije drugačije navedeno u zakonu

9.5 Potrebno je fizički osigurati sve medije

9.1.1 Spremati sigurnosne kopije na sigurne lokacije, najbolje izvan samog objekta u kojem se posao odvija. Sigurnost lokacije je potrebno povremeno kontrolirati

9.6 Održavati striktnu kontrolu unutranje ili vanjske distribucije medija

9.6.1 Klasificirati medije kako bi se mogla odrediti osjetljivost podataka

9.6.2 Prenositi medije isključivo putem sigurnih službi za prijenos ili drugim metodama koje se mogu pratiti

9.6.3 Svako iznošenje medija izvan sigurnih lokacija mora biti odobreno od strane visokog menadžmenta

9.7 Održavati striktnu kontrolu prostora za pohranu i medija

9.7.1 Održavati dnevnike u koje se upisuje oprema i provjeravati redovno odgovara li stvarno stanje

9.8 Uništiti medijske uređaje u slučaju da nisu više potrebni za poslovanje ili neke zakonske obveze

9.8.1 Uništiti, spaliti fizičke kopije materijala tako da ne mogu biti rekonstruirani podaci

9.9 Zaštititi uređaje koji prenose podatke za plaćanje

9.9.1 Održavati trenutnu listu uređaja koja uključuje:

- marku, model i uređaj,

- lokaciju uređaja,

- serijski broj uređaja ili neku drugu karakteristiku po kojoj ga je moguće indentificirati

9.9.2 Periodično kontrolirati površine uređaja da nije bilo napada na njih

9.9.3 Omogućiti trening za osoblje da bi se upoznalo s mogućnostima napada na uređaje za prijenos podataka o plaćanju

9.10 Osigurati da sigurnosna politika i operacijske procedure za ograničavanje fizičkog pristupa podacima budu dokumentirane i dostupne korisnicima u procesu

Redovito nadziranje i testiranje mreža

10. Pračenje i nadziranje svih pristupa mrežnim resursima i podacima vlasnika kartica

Mehanizmi prijave omogućuju praćenje korisnika te se na taj način mogu spriječiti, otkriti ili minimizirati opasnosti za podatke. Stoga je vrlo bitno imati dokumente koji prate rad.

10.1 Provoditi praćenje revizija koje povezuju sav pristup sustavnim komponentama svakog individualnog korisnika

10.2 Provoditi automatsko praćenje svih sustavnih komponenata kako bi se mogli odrediti sljedeći elementi:

10.2.1 Svi individualni pristupi podacima vlasnika kartica

10.2.2 Sve akcije izvršene s ulogom administratora

10.2.3 Pristup svim revizijama

10.2.4 Pogrešni pokušaji pristupa

10.2.5 Korištenje i promjene indentifikacijskih i autentikacijskih mehanizama

10.2.6 Inicijalizacija, zaustavljanje ili pauziranje unošenja revizija

10.2.7 Kreiranje i brisanje sistemskih objekata

10.3 Spremanje minimalno sljedećih revizija:

10.3.1 Indentifikaciju korisnika

10.3.2 Tip događaja

10.3.3 Vrijeme i datum

10.3.4 Indikaciju uspjeha ili neuspjeha

10.3.5 Svrhu događaja

10.3.6 Indentifikaciju ili ime podataka na kojeg se utjecalo, komponente sustava, ili resurs

10.4 Korištenje tehnologije vremenske sinkronizacije koja sinkronizira sva kritična sustavna vremena

10.4.1 Kritični sustavi imaju pravilno i konzistentno vrijeme

10.4.2 Vremenski podaci su zaštićeni

10.4.3 Postavke vremena se preuzimaju s industrijski prihvaćenih vremenskih izvora

10.5 Sigurno praćenje revizija tako da ne mogu biti izmijenjene

10.5.1 Ograničiti poglede revizija

10.5.2 Zaštititi revizije od neautoriziranih promjena

10.5.3 Kreirati sigurnosne kopije revizija

10.5.4 Voditi dnevnike za tehnologije usmjerene prema van na sigurnom, centraliziranom

10.5.5 Koristiti praćenje cjelokupnosti datoteka ili software koji će otkriti promjene na dnevnicima kako bi se osiguralo da postojeći uneseni podaci ne mogu biti promijenjeni bez upozorenja (iako se upozorenje ne bi trebalo pojaviti unošenjem novog podatka)

10.6 Recenziranje dnevnika i sigurnosnih slučaja za sve sustavne komponente kako bi se indentificirali nedostaci i sumnjiva aktivnost

10.6.1 Dnevno recenziranje sljedećih događaja:

- svih sigurnosnih događaja,

- dnevnika svih kritičnih sustava,

- dnevnika svih servera i sustavskih komponenata koje odrađuju funkciju sigurnosti

10.6.2 Recenzirati dnevnike ostalih sustavnih komponenti

10.6.3 Pratiti iznimke i nenormalnosti otkrivene tijekom procesa revizije

10.7 Zadržati podatke o revizijskim praćenjima barem godinu dana, s tim da minimalno tri posljednja mjeseca moraju biti trenutno dostupna za obradu

10.8 Osigurati da sigurnosna politika i operacijske procedure za praćenje svih pristupa mrežnim resursima i podacima budu dokumentirane i dostupne korisnicima u procesu

11. Redovito testirati sigurnost sustava i procesa

11.1 Provoditi procese za testiranje prisutnosti bežičnih pristupnih točaka, otkriti i identificirati sve autorizirane i neutorizirane pristupe na kvartalnoj bazi

11.1.1 Održavati inventar autoriziranih bežičnih pristupnih točaka

11.1.2 Provoditi indirektne procedure u slučaju neovlaštenog pristupa bežičnoj mreži

11.2 Pokrenuti skeniranje unutarnjih i vanjskih mrežnih ranjivosti najmanje svaka tri mjeseca ili nakon svake veće promjene na mreži

11.2.1 Odraditi kvartalno skreniranje unutarnjih ranjivosti dok god se ne riješe sve visoko rizične ranjivosti. Skeniranje mora odratiti ovlašteno osoblje

11.2.2 Izvršiti kvartalno skeniranje vanjskih mreža koristeći ASV koji je odobren od strane PIC SSC-a

11.2.3 Odraditi unutarnja i vanjska skeniranja nakon svake veće promjene

11.3 Provoditi metodologiju za testove penetracije

11.3.1 Izvoditi vanjski test penetracije

11.3.2 Izvoditi unutarnji test penetracije

11.3.3 Ispraviti i testirati pronađene greške

11.4 Koristiti detektor nadapada i tehnike za prevenciju upadanja na mrežu

11.5 Razviti mehanizam detekcije za nastale promjene koji obavještava osoblje o neautoriziranom pristupu

11.5.1 Provoditi procedure koje detektiraju alarme koji se javljaju u slučaju promjena

11.6 Osigurati da sigurnosna politika i operacijske procedure za sigurnosno nadziranje i testiranje budu dokumentirane i dostupne korisnicima u procesu

Održavati politiku sigurnosti informacija

12. Odžavanje pravilnika koji se odnosi na informacijsku sigurnost

Stroga sigurnosna politika postavlja sigurnosni ton za svaku osobu i informira osoblje što se očekuje od njih. Svi bi trebali biti svjesni koliko su osjetljivi podataci i koliko su oni odgovorni za njihovo štićenje.

12.1 Postaviti, objaviti, održavati i širiti politiku sigurnosti

12.1.1 Recenzirati sigurnosnu politiku minimalno jednom godišnje i obnoviti politiku prilikom promjene okoline

12.2 Provoditi proces procijene rizika

12.3 Razviti pravila korištenja kritičnih tehnologija i definirati njihovu ispravnu primjenu. Pravila korištenja moraju sadržavati sljedeće:

12.3.1 Odobrenje autoriziranog osoblja

12.3.2 Autentikaciju za korištenje tehnologije

12.3.3 Listu svih uređaja i osoblja koje im može pristupiti

12.3.4 Metode kojima se pravilno određuje vlasništvo, kontaktne informacije, i svrha

12.3.5 Dopuštene korisnike tehnologije

12.3.6 Prihvatljive lokacije za mrežnu tehnologiju

12.3.7 Listu dopuštenih proizvoda

12.3.8 Automatsko odspajanje sesija za udaljeni pristup tehnologija nakon određenog perioda

12.3.9 Aktiviranje udaljenog pristupa za vanjske partnere samo u vrijeme kad je to potrebno

12.3.10 Zabranjeno kopiranje, premještanje i spremanje važnih podataka prilikom udaljeng pristupa

12.4 Osigurati da sigurnosna politika i procedure jasno definiraju informacije o sigurnosnim obavezama za svo osoblje

12.5 Dodijeliti individualno ili timovima sljedeće sigurnosne obaveze:

12.5.1 Utvrditi, dokumentirati i distuibuirati sigurnosne politike i procedure

12.5.2 Nadzirati i analizirati sigurnosne alarme i informacije i distribuirati ih primjerenom osoblju

12.5.3 Utvrditi, dokumentirati i distribuirati odgovore na sigurnosne incidente i procedure u slučaju eskalacije da bi se osigurala valjana reakcija u tim situacijama

12.5.4 Administrirati račune, uključujući dodavanja, brisanja i modificiranja

12.5.5 Nadzirati i kontrolirati sve pristupe podacima

12.6 Provesti program svjesnosti o sigurnosti i važnosti podataka svim zaposlenicima

12.6.1 Obrazovati osoblje prilikom zaposlenja i barem jednom godišnje

12.6.2 Zahtijevati od osoblja barem jednom godišnje da su pročitali i razumjeli sigurnosnu politiku i procedure

12.7 Provjeriti potencijalno osoblje prije zaposlenja kako bi se smanjila mogućnost unutarnjih napada

12.8 Održavati i provoditi politiku i procedure za upravljanje davateljima usluga s kojima se dijele informacije o vlasnicima kartica ili mogu utjecati na podatke, treba primijeniti sljedeće:

12.8.1 Održavati listu davatelja usluga

12.8.2 Održavati pismeni dogovor oko procedura i odogvornosti za pristupanje podacima

12.8.3 Osigurati da je utvrđen proces za angažirane davatelje usluga koji uključuje odanost poslu za koji su angažirani

12.8.4 Održavati program za nadzor davatelja usluga, uskladiti status barem jednom godišnje o pridržavanju PCI DSS zahtjeva

12.8.5 Održavati informacije o tome koji su PCI DSS zahtjevi upravljani od svakog davatelja usluga, i kojima upravlja pojedinac

12.9 Dodatno davatelji usluga moraju podnijeti dokument korisnicima da su odgovorni za sigurnost podataka

12.10 Provoditi plan za slučaj incidenta

12.10.1 Kreirati plan kako bi se moglo trenutno reagirati u slučaju potrebe

12.10.2 Testirati plan jednom godišnje

12.10.3 Postaviti osoblje koje će biti dostupno 24/7 i odgovarati za alarme

12.10.4 Pružiti pravilan trening osoblja za prikazivanje njihovih sigurnosnih obaveza

12.10.5 Uključiti alarme iz sigurnosnih sustava kontrole, uključujući detekciju napada, firewall-ove i sustave za praćenje cjelokupnosti datoteka

12.10.6 Razviti proces za izmjenu i razvijanje plana za upravljanje incidentima

Izvor[11] --Karlo.duganic 18:38, 10. prosinca 2015. (CET)

Cijena uvođenja/neuvođenja PCI DSS-a

Točnu cijenu uvođenja nismo bili u mogućnosti pronaći. Da bismo dobili certifikat, provjeru ispunjenosti zahtjeva mora izdati ovlaštena QSA (Qualified Security Assesor) organizacija, koju je Payment Card Industry Standards Security Council ovlastio za to. Bitno pitanje je omjer cijene i prednosti koju donosi uvođenje navedenog certifikata. Na primjer, posjedujemo malu trgovinu koja godnišnje izvrši 100 plaćanja karticama i za to vrijeme nisu praćeni sigurnosni koraci koje propisuje PCI DSS. Napadač locira jednu od sigurnosnih ranjivosti i ukrade podatke plaćanja od tih navedenih 100. U tom slučaju dolazi do velikih troškova. Banka čija je kartica ukradena mora vratiti korisnicima novac, a iznosi se obično kreću oko više stotina tisuća dolara. Naša trgovina mora platiti forenzičku istragu kako bi se utvrdila šteta i koliko je njihovih klijenata oštećeno. Visa kažnjava našu banku kaznom koja se mjeri u tisućama dolara, a banka tu kaznu prenosi na nas. Tada još počinjemo ulagati novac u novi sustav. Također, gubimo povjerenje korisnika, koji odlaze našoj konkurenciji. Ako uzemo sve to u obzir, tada vidimo da je puno bolje odmah investirati u siguran sustav. Cijena uvođenja ne ovisi o broju kartica koje procesuiramo, već o načinu na koji procesuiramo kartice koje prihvaćamo. I zaista nije bitno koliko kartica neka tvrtka obrađuje, već na koji način to čini, jer je napadačima bitno samo da što lakše dođu do svog cilja. Izvor:[12]

--Karlo.duganic 20:49, 17. siječnja 2016. (CET)