V súlade so štandardom pci. Príprava na certifikáciu PCI DSS

Mobilné platobné riešenia zatiaľ nie sú na svetovom trhu a u nás zvlášť zastúpené. Záujem o takéto riešenia zo strany fintech vývojárov, podnikov a podnikov obchodu a služieb však každým rokom rastie.

Andrej Gaiko
Certifikovaný audítor digitálnej bezpečnosti QSA

Čo je mPOS

Mobilné platobné riešenie (mPOS) pozostáva z nasledujúcich hlavných komponentov:

• mobilné zariadenie – smartfón alebo tablet, ku ktorému je čítačka pripojená;
• platobná aplikácia pre mobilné zariadenie - softvér, cez ktorého rozhranie predávajúci zadáva údaje pre platbu a vymieňa si údaje so spracovaním. Prostredníctvom tohto softvéru je tiež možné overiť držiteľa karty pomocou podpisu;
• čítačka - rozlišujú sa dva typy čítačiek: Pin Entry Device (PED), čítačka kariet a zariadenie na zadávanie PIN kódu. Pripája sa k mobilnému zariadeniu cez Bluetooth, audio konektor alebo mini-USB; Secure Card Reader (SCR), čítačka kariet. Zvyčajne sa pripája k mobilnému zariadeniu cez audio konektor.

Mobilným platobným riešením rozumieme softvérovú a hardvérovú platformu pre obchodníkov (ďalej len obchodníci), ktorá umožňuje prijímať platby od fyzických osôb pomocou smartfónu/tabletu a k nemu pripojenej čítačky. Prostredníctvom mPOS je možné prijímať platby ako bezkontaktným spôsobom (bankovou kartou nahratou v mobilnom telefóne klienta s podporou NFC (ďalej len NFC karta), alebo bezkontaktnou bankovou kartou), tak klasickou plastovou kartou. karty (s magnetickým prúžkom a/alebo EMV čipom).

Okrem funkcií bezpečného čítania kariet a zadávania PIN kódu by mPOS mal podporovať všetky hlavné metódy overovania držiteľa karty, šifrovanie dát pri prenose medzi komponentmi a spracovateľskou časťou systému, ako aj možnosť tlače šekov alebo ich odosielania. prostredníctvom SMS a e-mailu.

Na strane poskytovateľa služieb alebo akvizičnej banky, ktoré sa zaoberajú prijímaním a ďalším spracovaním údajov pre mPOS platby, je využívaný back-end systém (platobná brána), podobný tým, ktoré sa používajú pri internetovom alebo bežnom POS akvizícii.

Aby sme pochopili, aké bezpečnostné požiadavky by mali byť na technickej úrovni, je potrebné určiť hlavné zložky ekosystému mPOS a existujúce informačné toky. Pre pochopenie zodpovednosti subjektov ekosystému mPOS za bezpečnosť platieb na obchodnej úrovni je potrebné určiť existujúce obchodné modely účastníkov platobného procesu.

Schéma informačných tokov obsahuje 8 hlavných etáp (pozri obr. 1):

• etapa 1. Pracovník obchodníka prepojí čítačku s mobilným zariadením (smartfón alebo tablet) s pripojením na internet. Spustí špeciálnu mobilnú aplikáciu a zadá do nej informácie o nákupe a výške platby;
• etapa 2. Klient vloží, zroluje alebo prinesie bankovú kartu do čítačky. V prípade NFC karty si klient na svojom smartfóne otvorí aplikáciu Peňaženka, vyberie si platnú bankovú kartu a priblíži smartfón k čítačke. V závislosti od nastavení na karte budete vyzvaní na zadanie PIN kódu. V tomto prípade zákazník zadá PIN pomocou PIN-padu, ktorý môže byť zabudovaný v čítačke;
• etapa 3. Čítačka načíta údaje o karte, zašifruje ich a prenesie do mobilného zariadenia pracovníka obchodníka;
• etapa 4. Mobilné zariadenie zamestnanca odosiela zašifrované údaje na platobnú bránu a údaje sa z platobnej brány prenášajú do akvizičného systému. Okrem údajov o karte je možné v závislosti od nastavení dodatočne prenášať informácie o mPOS, transakcii, zakúpenom produkte alebo službe;
• etapa 5. Požiadavka na autorizáciu z akvizičného systému sa odošle do MPS. Po spracovaní požiadavky sa výsledok (prijatý alebo zamietnutý) vráti do akvizičného systému. Ak je karta, na ktorej sa uskutočňuje platba, vydaná tou istou bankou, prostredníctvom ktorej sa uskutočňuje akvizícia, žiadosť sa neodošle do IPS;
• krok 6. Výsledok autorizačnej požiadavky sa prenesie do mobilného zariadenia;
• krok 7. Ak karta vyžaduje podpis majiteľa, potom sa v mobilnej aplikácii zobrazí príslušný formulár a klient sa podpíše (stylusom alebo prstom);
• krok 8. Pracovník obchodníka v mobilnej platobnej aplikácii zvolí spôsob odoslania šeku klientovi. Je možné poslať SMS, e-mail alebo vytlačiť na miestnu pokladňu.

Nasledujúce spoločnosti môžu byť zapojené do implementácie procesu opísaného vyššie:

• Vývojári zariadení mPOS – vyvíjajú a vyrábajú hardvér, ktorý bezpečne číta údaje z karty a PIN kód;
• vývojári platobného softvéru pre mobilné zariadenie a/alebo platobnú bránu - vyvíjajú klientsky softvér pre obchodníka a prípadne softvér pre platobnú bránu;
• vývojári platforiem - vývojárske spoločnosti, ktoré vytvárajú jednu hardvérovú a softvérovú časť riešenia mPOS na jeho ďalší predaj poskytovateľom služieb alebo nadobúdateľom riešení mPOS;
• Poskytovatelia služieb riešení mPOS – spoločnosti, ktoré vyrábajú finálny produkt pre obchodníkov. Spoločnosti tohto typu sú akvizičné banky alebo takzvaní sprostredkovatelia platieb (sprostredkovatelia platieb). Tieto spoločnosti môžu buď samostatne vyvíjať všetky komponenty mobilného platobného riešenia, alebo licencovať jednotlivé komponenty od rôznych výrobcov a vzájomne ich integrovať. Sprostredkovatelia platieb, s výnimkou akvizičných bánk, sú krížencom medzi poskytovateľom služieb a obchodníkom. Ich klientmi sú obchodníci, pre ktorých sa interakcia s prijímajúcou bankou stáva transparentným procesom, keďže za zúčtovanie s obchodníkom je zodpovedný sprostredkovateľ platby;
• distribútori - spoločnosti, ktoré na trhu propagujú určité mPOS riešenia od rôznych výrobcov a vykonávajú funkciu ďalšieho predaja mPOS riešenia obchodníka;
• poskytovateľ platobných služieb (spracovateľská spoločnosť, platobná brána) - spoločnosť, ktorá je sprostredkovateľom medzi poskytovateľom služieb riešení mPOS a nadobúdajúcou bankou. Poskytuje informačnú interakciu medzi mobilným zariadením obchodníka a nadobúdateľom;
• nadobúdateľ – prijímajúca banka alebo spracovateľské centrum napojené na IPS, ktoré poskytuje autorizáciu platby. Na zúčtovanie s obchodníkmi je možné využiť akvizičné banky, s ktorými poskytovatelia služieb riešení mPOS spolupracujú.

Je potrebné poznamenať, že spoločnosť môže vykonávať nielen jednu zo špecifikovaných úloh. Je možné, že spoločnosť dokáže plne vyvinúť všetky softvérové ​​a hardvérové ​​komponenty riešenia mPOS. Podľa toho, aké funkcie bude podnik vykonávať, závisí od toho, aké bezpečnostné požiadavky musí spĺňať.

Zoznamy hlavných komponentov a typov obchodných modelov sú poskytnuté s cieľom pochopiť, ako by mala byť zodpovednosť za splnenie bezpečnostných požiadaviek rozdelená medzi všetkých účastníkov v ekosystéme mPOS.

Druhy certifikácie

Prvé bezpečnostné pokyny pre riešenia mobilných platieb vydala spoločnosť Visa v roku 2011. Poskytli všeobecné usmernenia pre vývojárov a obchodníkov týkajúce sa bezpečnosti používania riešení pre mobilné platby. V roku 2012 vydala PCI SSC podrobnejšie pokyny pre vývojárov. Vydanie IPU a PCI SSC dnes takmer každý rok aktualizovalo bezpečnostné rady mPOS.

Okrem odporúčaní vyvinuli spoločnosti Visa a MasterCard certifikačné programy pre poskytovateľov mobilných platobných riešení. V skutočnosti sú si oba programy dosť podobné a s vysokou pravdepodobnosťou možno tvrdiť, že vývoj riešenia podľa požiadaviek jedného z MEA môže certifikovať druhý. Obe MPS vedú registre certifikovaných spoločností a mPOS riešení.

štandardy PCI SSC

PCI DSS
V novej verzii štandardu sa objavili nové požiadavky, ktoré sú pri zabezpečení mPOS najviac vítané. Do oddielu 9 bol doplnený najmä odsek 9.9, podľa ktorého je potrebné viesť evidenciu čítačiek kariet, ako aj vykonávať pravidelné školenia zamestnancov/používateľov obsluhujúcich zariadenia, aby bolo možné odhaliť spoofing mPOS alebo iné znaky. skimmingu. V prípade poskytovateľov služieb riešení mPOS alebo akvizičných spoločností budú musieť pri poskytovaní čítačiek čitateľom vypracovať odporúčania a návody na ochranu pred skimmingom a upozorniť na ne zamestnancov obchodníkov. V rámci požiadavky 12.8 môžu poskytovatelia služieb a nadobúdatelia na zmluvnej úrovni od obchodníkov vyžadovať, aby dodržiavali príslušné bezpečnostné požiadavky mPOS.

Napriek tomu, že plnenie väčšiny bezpečnostných požiadaviek pripadá na rôznych poskytovateľov služieb a banky, nadobúdajúce banky majú právo požadovať od Obchodníka vyplnenie samohodnotiacich hárkov (SAQ) príslušného typu (SAQ P2PE-HW v prípade obchodník používajúci riešenie P2PE, SAQ B-IP pri používaní mPOS s certifikovanou čítačkou PCI PTS). V tabuľke sú uvedené komponenty riešení mPOS, príslušný štandard, ktorý musí komponent spĺňať a spoločnosť zodpovedná za implementáciu požiadaviek.

Požiadavka 12.8 je relevantná aj vtedy, keď softvér riešenia mPOS pre poskytovateľa služieb vyvíja tretia strana. Splnenie požiadavky 6.5 v tomto prípade leží výlučne na pleciach developerskej spoločnosti. Zároveň, ak developerská spoločnosť nesplní požiadavky, poskytovateľ služby nebude môcť prejsť auditom zhody PCI DSS. Zmluvy medzi poskytovateľmi služieb (nadobúdateľmi) a vývojármi by mali počítať s otázkou auditu určitých obchodných procesov developerskej spoločnosti v prípade, že poskytovateľ služieb prejde každoročnou certifikáciou PCI DSS. proces vývoja bude zahrnutý do rozsahu auditu poskytovateľa služieb. To isté platí aj v prípade outsourcingu iných služieb. Vo všeobecnosti platí, že potvrdenie o zhode s požiadavkami PCI DSS treťou stranou v časti s tým súvisiacej môže byť poskytnuté samocertifikáciou potrebných obchodných procesov podľa PCI DSS s následným poskytnutím certifikátov o úspešne vykonanom overení, alebo poskytnutím možnosť auditu podnikového procesu v rámci auditu služby.poskytovateľ (nadobúdateľ).

Treba si uvedomiť, že u nás je audit developerov v rámci auditu zákazníckej firmy dosť ojedinelý. Vývojári môžu verbálne garantovať znalosť a aplikáciu bezpečných metód vývoja, no v skutočnosti nemajú potrebné znalosti a nedodržiavajú príslušné postupy. S vydaním novej verzie PCI DSS by sa veci mali zmeniť, pretože požiadavky sa spresnili a overovacie postupy špecifikované v texte normy zaväzujú audítora QSA vykonávať hlbšie kontroly.

PCI PTS
Štandard PCI PTS upravuje bezpečnostné požiadavky pre zariadenia Point of Interaction Devices (POI) a hardvérové ​​bezpečnostné moduly (HSM). Bod záujmu je čítačka pripojená k mobilnému zariadeniu. Ako už bolo spomenuté vyššie, riešenia mPOS používajú dve triedy bodov záujmu: zariadenie na zadávanie PIN kódu (PED) a čítačku bezpečných kariet (SCR). V závislosti od typu POI, do ktorého čítačka patrí, sa určujú skupiny požiadaviek PCI PTS, ktoré musí zariadenie spĺňať.

V súčasnosti niektoré mPOS riešenia ponúkané na domácom trhu využívajú čítačky no-name výrobcov. Použitie takýchto čítačiek nezaručuje bezpečný prenos dát medzi zariadeniami a umožňuje preniesť číslo karty do mobilného zariadenia ako čistý text. Preto sa pri výbere riešenia mPOS musíte uistiť, že poskytovateľ služby ponúka čítačku s certifikáciou PCI PTS.

Existujú dva obchodné modely vývoja klientskeho softvéru: vývoj pre vlastný projekt, keď vývojár vytvorí riešenie mPOS a uvedie ho na trh pod vlastnou značkou: v tomto prípade bude vývojár poskytovateľom služby riešenia mPOS; - a vývoj finálneho riešenia pre ďalšie licencovanie spoločnosťami, ktoré navzájom integrujú komponenty od rôznych výrobcov a na ich základe vytvárajú vlastné mPOS riešenia.

PA-DSS
Pre riešenia mPOS je PA-DSS povinný aplikovať na firmvér zariadení, ktoré čítajú údaje z karty. Pre softvér nainštalovaný na mobilnom zariadení zamestnanca obchodníka je tento štandard odporúčaním. Je to preto, že mobilné zariadenie je nedôveryhodné a zle kontrolované prostredie. Zariadenie môže byť napríklad jailbreaknuté, čo rádovo znižuje bezpečnosť zariadenia a nezaručuje bezpečnosť nainštalovanej platobnej aplikácie. Ministerstvo železníc preto zakazuje používanie mobilných zariadení na zadávanie PIN kódu a vyžaduje, aby údaje z čítačky prichádzali do mobilného softvéru v zašifrovanej podobe a následne sa v rovnakej forme prenášali k nadobúdateľovi. V tomto prípade nebudú údaje o platobnej karte spracované a uložené v otvorenej forme v mobilnom zariadení, čo znamená, že sa nevzťahujú požiadavky PA-DSS.

Verzia 3.0 štandardu zaviedla nové požiadavky, ktorým by mali venovať pozornosť predovšetkým vývojári firmvéru pre čítačky a krabicové platobné aplikácie. Po prvé, každá vydaná aktualizácia musí prejsť samostatnou certifikáciou. Po druhé, teraz musia zákazníci používať iba tie verzie (aktualizácie) softvéru, ktoré sú certifikované a uvedené na webovej stránke rady PCI.

PCI P2PE
Relatívne nedávno bol vydaný nový bezpečnostný štandard PCI P2PE. Štandard je určený pre riešenia, ktoré poskytujú kryptografickú ochranu dát pri ich prenose medzi všetkými komponentmi platobného riešenia. V prípade šifrovania je rozsah štandardu u obchodníka redukovaný na minimálnu úroveň, nakoľko obchodník nemá možnosť získať údaje o držiteľoch kariet vo forme čistého textu.

Zoznam všetkých hlavných komponentov ekosystému mPOS zahŕňa:

• čítacie zariadenie;
• platobná aplikácia pre mobilné zariadenie;
• platobná brána;
• akvizičný systém pripojený k MPS.

Na rozdiel od PCI DSS, ktoré sa týka len informačnej infraštruktúry, je PCI P2PE komplexnejšie a týka sa nielen infraštruktúry, ale aj čítačiek a softvéru POI terminálov (v prílohe mPOS ide o čítačky). Štandard pozostáva zo 6 domén, ktorých požiadavky vychádzajú zo súčasných štandardov PCI: čítačky musia spĺňať požiadavky PCI PTS SRED; čítací softvér - PA-DSS; správa šifrovacích kľúčov – bezpečnostné požiadavky PCI PIN; infraštruktúra platobných informácií obchodníka - PCI DSS. Ak je riešenie certifikované PCI P2PE, znamená to, že dáta medzi všetkými podsystémami (od čítačky po mobilné zariadenie v softvéri, od softvéru po spracovanie a ďalej) sa prenášajú v šifrovanej podobe a všetky podsystémy spĺňajú požiadavky príslušné normy PCI.

Podľa požiadaviek P2PE je možné certifikovať jednotlivé komponenty aj hotové riešenia.

MPS odporúča používať riešenia P2PE na prijímanie platieb mPOS. Problém však spočíva v tom, že v súčasnosti je na trhu málo riešení tohto typu, preto MPS nevyžadujú, ale odporúčajú používať PCI P2PE riešenia a pri vývoji sa nimi riadiť. Poskytovatelia platobných riešení mPOS sa však musia pripraviť na to, že MPS budú čoskoro vyžadovať povinnú PCI P2PE certifikáciu svojich riešení mPOS.

O štandarde

PCI DSS (Payment Card Industry Data Security Standard) je štandard zabezpečenia údajov v odvetví platobných kariet vyvinutý Radou pre bezpečnostné štandardy odvetvia platobných kariet (PCI SSC), ktorá bola založená spoločnosťami Visa, MasterCard, American Express, JCB a Discover.

Požiadavky normy sa vzťahujú na všetky spoločnosti pracujúce s medzinárodnými platobnými systémami: banky, obchodné spoločnosti a spoločnosti poskytujúce služby, poskytovateľov technologických služieb a ďalšie organizácie, ktorých činnosť súvisí so spracovaním, prenosom a uchovávaním údajov o držiteľoch platobných kariet.

PCI DSS - Komplexná bezpečnostná príručka

Štandard PCI DSS kladie požiadavky na bezpečnosť komponentov infraštruktúry, v ktorých sa prenášajú, spracúvajú alebo uchovávajú informácie o platobných kartách. Kontrola súladu platobnej infraštruktúry s týmito požiadavkami odhaľuje dôvody, ktoré výrazne znižujú úroveň jej bezpečnosti. Penetračné testy, ktoré sú zaradené do zoznamu povinných opatrení regulovaných štandardom PCI DSS, ukazujú skutočnú úroveň bezpečnosti informačných zdrojov spoločnosti ako z pozície útočníka, ktorý sa nachádza mimo skúmaného perimetra, tak aj z pozície tzv. zamestnanec firmy, ktorý má prístup „zvnútra“.

Rada PCI DSS sformulovala kľúčové požiadavky na ochranu údajov v štandarde zabezpečenia údajov v odvetví platobných kariet (PCI DSS). Požiadavky a postupy na hodnotenie bezpečnosti. Verzia 3.0". Tieto požiadavky sú zoskupené takým spôsobom, aby sa zjednodušil postup bezpečnostného auditu.

Stiahnite si PCI DSS v ruštine.

Požiadavky a postupy hodnotenia bezpečnosti PCI DSS

Budujte a udržiavajte bezpečné siete a systémy

• Požiadavka 1: "Nainštalujte a udržiavajte konfiguráciu brány firewall na ochranu údajov držiteľa karty."
• Požiadavka 2. "Nepoužívajte heslá pre systémy a iné bezpečnostné nastavenia nastavené výrobcom."

Chráňte údaje držiteľa karty

• Požiadavka 3: „Chráňte uložené údaje držiteľa karty.“
• Požiadavka 4: Zašifrujte údaje držiteľa karty pri prenose cez verejné siete.

Udržujte program riadenia zraniteľnosti

• Požiadavka 5: „Chráňte všetky systémy pred škodlivým softvérom a pravidelne aktualizujte antivírusový softvér.“
• Požiadavka 6: „Vyvíjajte a udržiavajte bezpečné systémy a aplikácie.“

Implementujte prísne opatrenia na kontrolu prístupu

• Požiadavka 7: „Obmedzte prístup k údajom držiteľa karty na základe potreby poznať.“
• Požiadavka 8: „Identifikujte a overte prístup k systémovým komponentom“.
• Požiadavka 9: Obmedzte fyzický prístup k údajom držiteľa karty.

Vykonávať pravidelné monitorovanie a testovanie sietí

• Požiadavka 10: „Sledovať a monitorovať všetky prístupy k sieťovým zdrojom a dátam držiteľov kariet.“
• Požiadavka 11: „Pravidelne testujte bezpečnostné systémy a procesy“

Dodržiavajte politiku informačnej bezpečnosti

• Požiadavka 12: „Udržiavať politiku informačnej bezpečnosti pre všetkých zamestnancov.“

Prospective Monitoring pomáha bankám, obchodníkom a vývojárom finančných služieb pripraviť sa na audit súladu PCI DSS a poskytuje odbornú podporu pri plnení požiadaviek normy.

Vo viacerých skorých publikáciách sme už uvažovali o niektorých medzinárodných štandardoch v oblasti informačnej bezpečnosti. Boli však prevažne v dome , t.j. vnútornej infraštruktúry spoločnosti. Najjasnejšie pochopenie informačnej bezpečnosti prichádza vtedy, keď bezpečnosť priamo súvisí s financiami, keď ukazuje svoj významný vplyv na podnikanie v číslach. Preto si dnes povieme niečo o bezpečnosti vo finančných inštitúciách ako sú banky, úverové inštitúcie, platobné agentúry atď. Všetky sa podieľajú na prevodoch peňazí, čo znamená, že spadajú pod priemyselný štandard.PCI DSS(Štandard zabezpečenia údajov v odvetví platobných kariet)

Štandardné PCI DSS je určený na zaistenie bezpečnosti spracovania, uchovávania a prenosu údajov o držiteľoch platobných kariet v informačných systémoch spoločností pracujúcich s medzinárodnými platobnými systémami víza , hlavná karta a ďalšie. Normu vytvára komunita Rada pre bezpečnostné štandardy PCI, do ktorej patria svetoví lídri na trhu platobných kariet, ako napr americký Expres, Objavte finančné služby, JCB, MasterCard Worldwide A Visa International. Štandardné požiadavky PCI DSS šírenie pre všetky spoločnosti ktoré spracúvajú, uchovávajú alebo prenášajú údaje o držiteľoch platobných kariet (banky, spracovateľské centrá, poskytovatelia služieb, systémy elektronického obchodu atď.). V Rusku súlad s normou PCI DSS sa stal povinné pre používanie v príslušných organizáciách od roku 2007.

Podľa výsledkov štúdie Analysys Mason, približne 42 % poskytovateľov cloudových služieb dodržiava štandardy zabezpečenia údajov v odvetví platobných kariet (PCI DSS, štandard zabezpečenia údajov v odvetví platobných kariet). Pôsobia na celom svete a vzťahujú sa na všetky organizácie, ktoré spracúvajú kreditné karty a tiež uchovávajú alebo prenášajú informácie o ich držiteľoch. Tento štandard bol zavedený s cieľom poskytnúť odvetviu platobných kariet väčšiu kontrolu nad citlivými údajmi a zabrániť ich úniku. Jeho cieľom je tiež zabezpečiť, aby boli spotrebitelia pri používaní kreditných kariet chránení pred podvodmi alebo krádežou identity.

Podľa klasifikácií Visa aj MasterCard sú systémy, ktoré spracúvajú, uchovávajú alebo prenášajú viac ako 6 miliónov transakcií ročne, klasifikované ako prvá úroveň (úroveň 1) a sú povinné každoročne byť auditovaný .

HISTÓRIA VÝVOJA ŠTANDARDU

1.0 je pôvodná verzia štandardu.

1.1 – prijaté v septembri 2006.

1.2 – prijaté v októbri 2008.

2.0 – prijaté v októbri 2010.

3.0 – prijaté v novembri 2013.

3.1 – prijaté v apríli 2015.

PCI DSS verzia 3.0

„Nová verzia PCI-DSS 3.0 urobí zo štandardu neoddeliteľnú súčasť bežných obchodných operácií,“ povedal pre eWeek Bob Russo, generálny riaditeľ Rady pre bezpečnostné štandardy odvetvia platobných kariet (PCI SSC). — Chceme sa pokúsiť odnaučiť ľudí, aby verili, že PCI-DSS sa dá riešiť raz za rok, a potom na to nemyslieť. V reálnej situácii sa často vyskytujú medzery.

PCI-DSS bol často vnímaný len ako základ pre kontrolu dodržiavania predpisov firmy, kedy si môžete odškrtnúť, že momentálne je všetko v poriadku a pokojne prejsť k iným veciam. Bob Russo zdôraznil, že v novom štandarde PCI-DSS 3.0 kladie sa dôraz na vzdelávanie a politiku, čím sa bezpečnosť platieb stáva každodennou úlohou a prvkom neustále udržiavaného poriadku. Pointa je, že štandard pomôže viesť k dôslednejšiemu procesne orientovanému riadeniu, čo je dôležité najmä pre veľké organizácie. A tiež posilňuje zameranie na priebežnú zodpovednosť, nielen na občasné audity PCI-DSS.

Jednou z výčitiek štandardu PCI-DSS je nedostatočná jasnosť jeho ustanovení. Norma môže napríklad vyžadovať, aby organizácia nasadila bránu firewall webovej aplikácie (WAF) bez toho, aby podrobne uviedla požadovanú konfiguráciu brány firewall alebo dokonca vysvetlila, prečo je to potrebné. Táto kritika bola vyjadrená v jasnej a ostrej forme členmi PCI SCC, čo si vyžiadalo vývoj nového a vylepšeného štandardu.

V predchádzajúcich verziách štandardu boli vždy dva stĺpce vysvetľujúce konkrétnu požiadavku na kontrolu bezpečnosti. V prvom stĺpci bola uvedená požiadavka a v druhom boli uvedené podrobnosti o postupe testovania. PCI-DSS 3.0 by mal mať tretí stĺpec, ktorý podľa Leacha bude obsahovať reálne príklady rizík, ktoré má táto bezpečnostná kontrola zmierniť.

Takže v prípade WAF nový štandard vysvetlí, čo táto technológia dokáže a aké typy rizík môže pomôcť zmierniť.

Jedna z dôležitých zmien v štandarde PCI-DSS 3.0 súvisí s používaním hesiel. Za posledné tri roky PCI SCC vykonalo sériu štúdií sily hesiel, ktoré pomohli sformulovať nové požiadavky.

Jednou z požiadaviek PCI-DSS 3.0, ktoré budú musieť predajcovia splniť, je včasná detekcia škodlivého kódu. Nariadenie 5.1.2 bolo pridané, aby sa zabezpečilo, že každá osoba spracúvajúca údaje o platobných kartách má v tejto oblasti riadny proces riadenia rizík.

PCI-DSS 3.0 neustále zdôrazňuje potrebu flexibility v správe bezpečnosti, ktorú je potrebné dosiahnuť rôznymi spôsobmi, ktoré sa neustále zlepšujú.

PCI DSS verzia 2.0

28. októbra 2010 bola vydaná nová verzia štandardu PCI DSS , konkrétne verzia 2.0. Zmeny zavedené do dokumentu upravujúceho odvetvie je ťažké nazvať radikálnymi, majú najmä charakter spresnenia a upresnenia. Okrem toho boli niektoré overovacie postupy zoskupené novým spôsobom, aby sa zjednodušilo ich vnímanie a implementácia počas auditu.

Hoci štandard verzia 2.0 nadobudol účinnosť 1. januára 2011, účastníci odvetvia platobných kariet môžu predchádzajúcu verziu používať do konca roka 2011. Táto iniciatíva Rady PCI SSC umožňuje postupný prechod na novú verziu. Ďalšiu verziu pripraví PCI SSC počas trojročného životného cyklu.

Požiadavky PCI DSS

PCI DSS definuje nasledujúcich šesť oblastí kontroly a 12 základných bezpečnostných požiadaviek.

Budovanie a udržiavanie bezpečnej siete

Napriek otvorenosti noriem sa hromadí veľa otázok. Na niektoré z nich sa pokúsime odpovedať nižšie.

1. Na koho sa vzťahuje PCI DSS?

V prvom rade norma definuje požiadavky na organizácie, ktorých informačná infraštruktúra uchováva, spracúva alebo prenáša údaje o platobných kartách, ako aj na organizácie, ktoré môžu ovplyvniť bezpečnosť týchto údajov. Účel normy je celkom zrejmý – zabezpečiť bezpečnosť obehu platobných kariet. Od polovice roku 2012 musia všetky organizácie zapojené do procesu skladovania, spracovania a prenosu WPC spĺňať požiadavky PCI DSS a spoločnosti v Ruskej federácii nie sú výnimkou. Aby ste pochopili, či vaša organizácia podlieha povinnému súladu s požiadavkami normy PCI DSS , odporúčame použiť jednoduchú blokovú schému.

Prvým krokom je zodpovedať dve otázky:

• Sú údaje o platobných kartách uložené, spracovávané alebo prenášané vo vašej organizácii?
• Môžu obchodné procesy vašej organizácie priamo ovplyvniť bezpečnosť údajov o platobných kartách?

Ak sú odpovede na obe tieto otázky negatívne, certifikujte sa podľa PCI DSS netreba. V prípade aspoň jednej kladnej odpovede, ako je vidieť na obrázku 1, je súlad s normou nevyhnutný.

2. Aké sú požiadavky PCI DSS?

Súlad s normou si vyžaduje splnenie požiadaviek, ktoré sú zhrnuté v dvanástich častiach uvedených v tabuľke nižšie:

Ak pôjdete trochu hlbšie, norma vyžaduje absolvovanie približne 440 overovacích postupov, ktoré by mali poskytnúť pozitívny výsledok pri kontrole súladu s požiadavkami.

3. Ako môžem overiť súlad s PCI DSS?

Existujú rôzne spôsoby, ako potvrdiť súlad s požiadavkami normy PCI DSS ktorá spočíva vo vykonávaní externý audit (QSA) , interný audit (ISA) alebo sebahodnotenie (SAQ) organizácií.

Vlastnosti každého z nich sú znázornené v tabuľke.

Napriek zjavnej jednoduchosti prezentovaných metód sa zákazníci často stretávajú s nedorozumeniami a ťažkosťami pri výbere vhodnej metódy. Príkladom sú nižšie uvedené otázky.

4. V akej situácii je potrebné vykonať externý audit av akej - internej? Alebo sa stačí obmedziť na sebahodnotenie organizácie?

Odpovede na tieto otázky závisia od typu organizácie a počtu transakcií spracovaných za rok. Nemalo by ísť o náhodný výber, pretože existujú zdokumentované pravidlá, ktoré určujú, akým spôsobom bude organizácia overovať súlad s normou. Všetky tieto požiadavky stanovujú medzinárodné platobné systémy, z ktorých najpopulárnejšie sú v Rusku víza A hlavná karta. Existuje dokonca klasifikácia, podľa ktorej sa rozlišujú dva typy organizácií: obchod servisné spoločnosti (obchodníci) a poskytovateľov služieb.

Podnik obchodu a služieb je organizácia, ktorá prijíma platobné karty na platbu za tovar a služby (obchody, reštaurácie, internetové obchody, čerpacie stanice a pod.). Podnik obchodu a služieb je organizácia, ktorá prijíma platobné karty na platbu za tovary a služby (obchody, reštaurácie, internetové obchody, čerpacie stanice a pod.).

V závislosti od počtu transakcií spracovaných za rok možno obchodníkov a poskytovateľov služieb klasifikovať do rôznych úrovní.

Povedzme, že podnik v oblasti obchodu a služieb spracuje až 1 milión transakcií ročne pomocou elektronického obchodu. Podľa klasifikácie víza A hlavná karta(Obr. 2) bude organizácia klasifikovaná na úrovni 3. Preto na potvrdenie súladu PCI DSS je potrebné vykonávať štvrťročné externé skenovanie zraniteľnosti komponentov informačnej infraštruktúry ASV (Approved Scanning Vendor) a každoročné sebahodnotenie SAQ. V tomto prípade organizácia nemusí zbierať dôkazy o súlade, pretože to nie je potrebné pre súčasnú úroveň. Vyplnený hárok sebahodnotenia SAQ bude dokumentom správy.

Skenovanie ASV (schválený dodávateľ skenovania)— automatizovaná kontrola všetkých bodov pripojenia informačnej infraštruktúry k internetu s cieľom identifikovať slabé miesta. PCI DSS vyžaduje, aby sa tento postup vykonával štvrťročne.

Alebo si vezmite príklad poskytovateľa cloudových služieb, ktorý spracuje viac ako 300 000 transakcií ročne. Podľa zavedenej klasifikácie víza alebo hlavná karta, poskytovateľ služieb bude klasifikovaný ako úroveň 1. To znamená, že ako je uvedené na obrázku 2, je potrebné vykonať štvrťročné externé skenovanie zraniteľnosti komponentov informačnej infraštruktúry ASV, ako aj externý ročný audit QSA.

Treba si uvedomiť, že banka zúčastňujúca sa na procese akceptovania platobných kariet na platbu za tovar alebo služby, tzv. akvizičná banka, ako aj tzv. medzinárodné platobné systémy (IPS ) môžu podľa vlastného posúdenia rizika prepísať úroveň obchodníka, ktorý je k nim pripojený, alebo poskytovateľa služieb. Priradená úroveň bude mať prednosť pred klasifikáciou medzinárodného platobného styku uvedenou na obrázku 2.

Organizácie, ktoré uchovávajú, spracúvajú a prenášajú údaje o platobných kartách medzinárodných platobných systémov (Visa, MasterCard, American Express, Discover, JCB), sú povinné dodržiavať požiadavky štandardu PCI DSS. Platobné systémy určili frekvenciu a formu potvrdenia splnenia požiadaviek normy, ako aj sankcie za ich nedodržanie a kompromitovanie údajov o platobnej karte.

S cieľom pomôcť organizáciám splniť požiadavky normy Informzashchita ponúka rôzne možnosti služieb zhody PCI DSS, ktoré zohľadňujú úlohy a špecifiká klienta. Medzi nimi:

• Súlad s PCI DSS. Služba spočíva v zosúladení úrovne informačnej bezpečnosti spoločnosti s požiadavkami štandardu PCI DSS od základu. Zahŕňa:
• Predbežný audit s vypracovaním plánu súladu;
• Priamo štádium odlievania;
• Záverečný certifikačný audit.
• Udržujte súlad s PCI DSS. Služba zahŕňa pomoc organizáciám, ktoré už majú certifikát zhody PCI DSS a majú záujem o jeho ďalšie potvrdenie.
• Certifikačný audit PCI DSS. Služba je určená organizáciám, ktoré nezávisle implementovali požadované bezpečnostné opatrenia PCI DSS a zaujíma ich len konečné posúdenie zhody.
• Certifikácia softvéru podľa požiadaviek štandardu PA-DSS. V roku 2008 Bezpečnostná rada odvetvia platobných kariet (PCI SSC) prijala štandard zabezpečenia údajov platobných aplikácií (PA-DSS) na podporu súladu s požiadavkami PCI DSS. Podľa požiadaviek platobných systémov VISA a MasterCard musia byť všetky „krabicové“ aplikácie zapojené do spracovania autorizačných transakcií alebo zúčtovania platobnými kartami certifikované podľa štandardu PA-DSS.
  Platobné systémy VISA a MasterCard stanovili termín ukončenia prechodu agentov a podnikov obchodnej a servisnej siete na používanie certifikovaných aplikácií - 1. júla 2012.
  Iba audítor so statusom PA-QSA môže certifikovať žiadosti o zhodu s PA-DSS. Informzashchita je prvou spoločnosťou v Rusku, ktorá má tento štatút.
  Od roku 2009 špecialisti Informzaschita vykonávajú audity na dodržiavanie štandardu PA-DSS. Počas prác sme certifikovali viac ako 10 aplikácií: spracovateľský softvér, platobné terminály a aplikácie elektronického obchodu. Nahromadené skúsenosti nám umožňujú určiť optimálnu schému pre vývojára na vykonanie prípravných prác a certifikácie. Implementácia požiadaviek na zabezpečenie bezpečného vývoja a údržby softvéru sa vykonáva s prihliadnutím na existujúce procesy. Úroveň finálnych dokumentov a osvedčených postupov zabezpečuje minimálny čas na absolvovanie povinného postupu kontroly kvality zo strany PCI SSC.
• Udržiavajte softvér v súlade s požiadavkami PA-DSS. Zmeny platobných aplikácií s certifikáciou PA-DSS podliehajú kontrole a v niektorých prípadoch si vyžadujú proces povinného opätovného overenia. Rozsah a reportovacie dokumenty prebiehajúcej certifikácie závisia od typu zmien.
  Certifikovaní audítori spoločnosti Informzaschita majú skúsenosti s vývojom stratégií vydávania s prihliadnutím na požiadavky normy a realitu predajcu, s realizáciou recertifikácie pre všetky typy zmien definovaných normou a s koordináciou finálnych dokumentov s PCI SSC.
  Prístup k poskytovaniu recertifikácií je vytvorený na základe želaní vývojára a zameriava sa na existujúcu prax vydávania aktualizácií od vývojára aplikácie.
• Skenovanie PCI ASV, skenovanie WEB aplikácií. Informzashchita je certifikovaný (certifikát č. 4159-01-08) poskytovateľ PCI ASV skenov. Skenovanie PCI ASV zabezpečuje súlad s článkom 11.2.2 štandardu PCI DSS. Okrem formálneho súladu so štandardom vám skenovanie PCI ASV umožňuje posúdiť bezpečnosť vášho externého sieťového perimetra, identifikovať slabé miesta a nesprávne konfigurácie.
• Komplexný penetračný test podľa požiadaviek PCI DSS. Súčasťou služby je praktické posúdenie možnosti neoprávneného prístupu k údajom o platobných kartách alebo sieťovým zdrojom, ktoré spracúvajú údaje o platobných kartách (požadované v bode 11.3 PCI DSS).
• Vývoj programu na dodržiavanie požiadaviek PCI DSS zo strany obchodníkov pre akvizičné banky. Podľa požiadaviek medzinárodných platobných systémov sú prijímajúce banky zodpovedné za súlad svojich obchodníkov s požiadavkami štandardu PCI DSS. V rámci služby je vyvinutý program na kontrolu súladu obchodníkov s požiadavkami štandardu PCI DSS na základe bezpečnostných programov medzinárodných platobných systémov Bezpečnosť informácií o účte a Ochrana údajov na stránkach.
• Pomoc pri vypĺňaní hárku sebahodnotenia PCI DSS. Služba je určená pre obchodníkov a poskytovateľov služieb s malým objemom transakcií. V rámci služby Informzashchita poskytuje pomoc pri posudzovaní súladu s vyplnením samohodnotiaceho hárku PCI DSS.

Realizáciou prác bude možné splniť požiadavky stanovené normou, znížiť riziká ohrozenia údajov o platobných kartách a vyhnúť sa sankciám zo strany medzinárodných platobných systémov.

Informzashchita bola prvou spoločnosťou v Ruskej federácii, ktorá získala štatút QSA a ASV, čo jej dáva právo vykonávať certifikačné audity PCI DSS a externé skenovanie ASV. V počte certifikovaných audítorov QSA Informzashchita prevyšuje ostatné ruské spoločnosti. S každým klientom tak pracuje osobný špecialista. Spoločnosť úspešne prešla kontrolou kvality správ PCI SSC, ktorá potvrdila vysokú kvalitu služieb poskytovaných zákazníkom. Od roku 2006 spoločnosť dokončila viac ako 90 projektov zhody a certifikácie PCI DSS pre banky, nezávislé spracovateľské centrá, poskytovateľov služieb, dátové centrá a obchodníkov.

Akékoľvek objektívne a zmysluplné penetračné testovanie musí
vykonávať v súlade s odporúčaniami a pravidlami. Aspoň byť
kompetentného odborníka a nič vám neunikne. Takže ak chcete zviazať svoje
profesionálna činnosť s pentestom - určite sa oboznámte s
štandardy. A v prvom rade - s mojím článkom.

Pravidlá a rámec penetračného testovania informácií sú uvedené v metodikách
OSSTMM A OWASP. Následne sa dajú získané dáta jednoducho
prispôsobené na posudzovanie zhody s akýmkoľvek priemyslom
štandardy a „najlepšie svetové postupy“, ako napr. Cobit,
sériové štandardy ISO/IEC 2700x, odporúčania CIS/BEZ/NIST/atď
a - v našom prípade - štandard PCI DSS.

Samozrejmosťou sú nahromadené údaje získané počas testovania na
penetráciu, vykonať úplné posúdenie podľa priemyselných noriem
nebude stačiť. Ale preto je to pentest, nie audit. Okrem toho pre
realizácia takéhoto hodnotenia v plnom rozsahu, len technologické údaje o
nikomu nebude stačiť. Na úplné posúdenie sú potrebné rozhovory so zamestnancami.
rôzne divízie oceňovanej spoločnosti, analýza administratívnych
dokumentácia, rôzne IT/IS procesy a mnoho iného.

Pokiaľ ide o penetračné testovanie podľa potreby
štandard pre informačnú bezpečnosť v odvetví platobných kariet - to nie je veľa
sa líši od konvenčného testovania vykonávaného pomocou metód
OSSTMM A OWASP. Navyše štandard PCI DSS odporúčané
Aby ste dodržiavali pravidlá OWASP pri vykonávaní oboch pentestov (AsV) a
audit (QSA).

Hlavné rozdiely medzi testovaním PCI DSS od testovania do
prienik v širšom zmysle slova sú nasledovné:

1. Norma neupravuje (a preto sa nevyžaduje) vykonávať útoky s
   pomocou sociálneho inžinierstva.
2. Všetky vykonané kontroly by mali minimalizovať hrozbu „odmietnutia
   Služba (DoS). Preto by testovanie malo byť
   vykonávané metódou „šedej skrinky“ s povinným upozornením
   príslušných správcov systému.
3. Hlavným účelom takéhoto testovania je pokus o implementáciu
   neoprávnený prístup k údajom platobnej karty (PAN, Meno držiteľa karty a
   atď.).

Metóda "šedej škatule" sa týka implementácie rôznych
druh kontrol s predbežným prijatím dodatočných informácií o
systém v rôznych fázach testovania. Tým sa znižuje riziko
odmietnutie služby pri vykonávaní takejto práce v súvislosti s informáciami
zdroje fungujúce 24/7.

Vo všeobecnosti by PCI penetračné testovanie malo
spĺňať nasledujúce kritériá:

• Článok 11.1(b) – Analýza bezpečnosti bezdrôtovej siete
• Odsek 11.2 – Skenovanie informačnej siete z hľadiska zraniteľností (AsV)
• 11.3.1 - Vykonávanie kontrol na sieťovej vrstve (sieťová vrstva
  penetračné testy)
• Článok 11.3.2 – Vykonávanie kontrol na aplikačnej úrovni (Aplikačná vrstva
  penetračné testy)

Týmto končíme teóriu a prejdeme k praxi.

Stanovenie hraníc prebiehajúceho výskumu

Najprv musíte pochopiť hranice penetračného testovania,
určiť a dohodnúť postupnosť úkonov, ktoré sa majú vykonať. V tom najlepšom
V tomto prípade môže oddelenie IS získať mapu siete, na ktorej
schematicky ukazuje, ako centrum spracovania interaguje s generálom
infraštruktúry. V najhoršom prípade budete musieť komunikovať so správcom systému,
ktorý si je vedomý vlastných zárubní a získava komplexné údaje o
informačného systému bude brzdiť jeho neochota podeliť sa o svoje
jedinečné (alebo nie - cca. Forb) vedomosti. Tak či onak, aby
PCI DSS Pentest vyžaduje aspoň tieto informácie:

• segmentácia siete (používateľská, technologická, DMZ, spracovanie a
  atď.);
• firewall na hraniciach podsiete (ACL/ITU);
• použité webové aplikácie a DBMS (testovacie aj produktívne);
• používané bezdrôtové siete;
• akékoľvek bezpečnostné detaily, ktoré je potrebné vziať do úvahy
  v priebehu prieskumu (napríklad zablokovanie účtov v N
  nesprávne pokusy o overenie), špecifiká infraštruktúry a všeobecné
  priania na testovanie.

So všetkými potrebnými informáciami uvedenými vyššie môžete
organizujte svoje dočasné útočisko v najoptimálnejšom segmente siete a
začať skúmať informačný systém.

Penetračné testy na sieťovej vrstve

Na začiatok stojí za to analyzovať sieťový prenos prechádzajúci pomocou
akýkoľvek sieťový analyzátor v "promiskuitnom" režime sieťovej karty
(promiskuitný režim). Ako sieťový analyzátor na podobné účely
skvele padne alebo CommView. Tento krok bude trvať 1-2 hodiny.
ňufák. Po tomto čase sa nazhromaždí dostatok údajov na vykonanie
analýza zachytenej premávky. A v prvom rade, pri jej analýze by sa malo
venujte pozornosť nasledujúcim protokolom:

• prepínacie protokoly (STP, DTP atď.);
• smerovacie protokoly (RIP, EIGRP atď.);
• dynamické protokoly konfigurácie hostiteľa (DHCP, BOOTP);
• otvorené protokoly (telnet, rlogin atď.).

Pokiaľ ide o otvorené protokoly, pravdepodobnosť, že do nich spadnú
doba snímania prechádzajúcej prevádzky v prepínanej sieti je pomerne malá.
Ak je však takáto prevádzka veľká, potom sa v skúmanej sieti jasne pozoruje
problémy v nastaveniach sieťových zariadení.

Vo všetkých ostatných prípadoch existuje možnosť vykonať krásne útoky:

• klasický MITM (Man in the middle) útok v prípade, keď
  DHCP, RIP
• získanie úlohy koreňového uzla STP (Root Bridge), čo umožňuje
  zachytiť premávku susedných segmentov
• prepnutie portu do režimu trunk pomocou DTP (povoliť trunking);
  vám umožňuje zachytiť všetku návštevnosť vášho segmentu
• atď.

Na implementáciu útokov na prepínanie protokolov je k dispozícii úžasný nástroj
Yersinia. Predpokladajme, že v procese dopravnej analýzy lietanie
minulé pakety DTP (pozri snímku obrazovky). Potom odošlete paket DTP ACCESS/DESIRABLE
môže umožniť, aby bol port prepínača nastavený do režimu trunk. Ďalej
vývoj tohto útoku vám umožňuje počúvať váš segment.

Po otestovaní odkazovej vrstvy sa oplatí prepnúť pozornosť na tretiu
OSI vrstva. Na rade je útok otravy ARP. Všetko je tu jednoduché.
Vyberte si nástroj, napr.

a prediskutovať so zamestnancami IS podrobnosti tohto útoku (vrátane
potreba útoku zameraného na zachytenie jednosmerného SSL).
Ide o to, že v prípade úspešnej implementácie ARP-otrava zaútočí proti
celého jeho segmentu môže nastať situácia, keď počítač útočníka nie
vyrovnať sa s tokom prichádzajúcich údajov a v konečnom dôsledku sa to môže stať
spôsobiť odmietnutie služby pre celý segment siete. Preto najsprávnejšie
vyberie jednotlivé ciele, ako sú pracovné stanice správcu a/alebo
vývojári, akékoľvek špecifické servery (prípadne radič domény,
DBMS, terminálový server atď.).

Úspešný útok otravy ARP vám umožní dostať sa do priepasti
heslá k rôznym informačným zdrojom - DBMS, katalóg domén (s
Downgrade overenia NTLM), reťazec komunity SNMP atď. Menej ako
našťastie sa hodnoty hash dajú získať z hesiel do rôznych systémov,
ktoré bude potrebné obnoviť počas letníc do
dúhové tabuľky (dúhové tabuľky), slovníkom alebo útokom „na čelo“. zachytený
heslá sa dajú použiť niekde inde a následne je to aj potrebné
potvrdiť alebo zamietnuť.

Okrem toho sa oplatí analyzovať všetku zachytenú premávku na prítomnosť
CAV2/CVC2/CVV2/CID/PIN prenášané v čistom formáte. Na to môžete preskočiť
uložený súbor cap cez NetResident a/alebo
.
Druhý, mimochodom, je skvelý na analýzu nahromadenej návštevnosti vo všeobecnosti.

Penetračné testy aplikačnej vrstvy

Prejdime k štvrtej vrstve OSI. V prvom rade tu ide o všetko
inštrumentálne skenovanie skúmanej siete. Ako to uskutočniť? Výber je nesprávny
príliš veľký. Počiatočné skenovanie je možné vykonať pomocou Nmap in
Režim "Rýchle skenovanie" (prepínače -F -T Aggressive|Insane) a v nasledujúcich krokoch
testovanie na skenovanie na konkrétnych portoch (prepínač -p), napr.
v prípadoch detekcie najpravdepodobnejších penetračných vektorov spojených s
zraniteľnosti určitých sieťových služieb. Súčasne sa oplatí spustiť skener
bezpečnosť - Nessus alebo XSpider (ten bude mať ošúchané výsledky) v
režim vykonávania iba bezpečných kontrol. Pri skenovaní
zraniteľnosti, je potrebné venovať pozornosť aj prítomnosti zastaraných systémov
(napríklad Windows NT 4.0), pretože štandard PCI ich zakazuje
použitie pri spracovaní údajov držiteľov karty.

Nestojí to za to, keď sa v akejkoľvek službe okamžite nájde kritická zraniteľnosť
ponáhľať sa to využiť. Správny prístup pri testovaní cez PCI -
toto, po prvé, získať úplnejší obraz o stave bezpečnosti subjektu
systém (je táto zraniteľnosť náhodná alebo je všadeprítomná),
a po druhé, koordinovať svoje kroky na využitie zistených zraniteľností v
určité systémy.

Výsledky inštrumentálneho vyšetrenia by mali byť celkovým obrazom
implementované procesy IS a povrchné chápanie stavu bezpečnosti
infraštruktúry. Počas vývoja skenov môžete požiadať, aby ste sa s nimi oboznámili
politiku informačnej bezpečnosti používanú Spoločnosťou. Na všeobecný sebarozvoj :).

Ďalšou fázou je výber cieľov pre prienik. V tejto fáze by ste mali
analyzovať všetky zhromaždené informácie získané počas počúvania
skenovanie návštevnosti a zraniteľnosti. Pravdepodobne do tejto doby bude
sledovať zraniteľné alebo potenciálne zraniteľné systémy. Preto to prišlo
čas využiť tieto nedostatky.

Ako ukazuje prax, práca prebieha v nasledujúcich troch oblastiach.

1. Využitie slabých miest v sieťových službách

V dávnej minulosti je čas, keď vykorisťovanie bolo údelom elity,
schopný aspoň zostaviť kód niekoho iného a (och môj bože!) pripraviť svoj vlastný shell kód.
Teraz využívanie zraniteľností v sieťových službách, ako je pretečenie
nárazníky a im podobné, dostupné pre každého. Okrem toho je proces stále viac podobný
pátracia hra. Vezmite si aspoň Core Impact, v ktorom sa zníži celý pentest
na klikanie na rôzne rozbaľovacie ponuky v peknom obale GUI.
Takáto sada nástrojov šetrí veľa času, ktorý pri internom testovaní
nie veľmi. Pretože vtipy sú vtipy a sada funkcií implementovaná v Core Impact,
umožňuje bez zvláštneho obťažovania dôsledne vykonávať prevádzku, zdvíhanie
privilégiá, zhromažďovanie informácií a odstraňovanie stôp vášho pobytu v systéme. IN
Preto je Core Impact obľúbený najmä u západných audítorov a
pentesterov.

Z verejných nástrojov tohto druhu možno spomenúť nasledovné.
zostavy: Core Impact, CANVAS, SAINTexploit a všetkým obľúbený Metasploit Framework.
Pokiaľ ide o prvé tri, sú to všetko komerčné produkty. Pravda, niektoré
staré verzie komerčných zostáv unikli na internet naraz. Ak je to žiaduce
môžete ich nájsť na globálnej sieti (samozrejme, výhradne za účelom
sebavzdelávanie). No, všetok nový sploit zadarmo je dostupný v Metasploite
rámec. Samozrejme, existujú zero-day buildy, ale to sú úplne iné peniaze.
Okrem toho existuje kontroverzný názor, že pri vykonávaní pentestu je ich použitie
nie je úplne spravodlivé.

Na základe údajov sieťového skenovania sa môžete zahrať na malého hackera :).
Po predchádzajúcej dohode o zozname cieľov vykonajte operáciu zistených
zraniteľnosti a potom vykonať povrchný lokálny audit zachytených systémov.
Informácie zozbierané o zraniteľných systémoch sa môžu zlepšiť
privilégiá na iné sieťové zdroje. Teda ak počas útoku
poškodili ste Windows, potom by nebolo zbytočné odstraňovať z neho databázu SAM (fgdump)
následné obnovenie hesla, ako aj tajomstvá LSA (Cain & Abel), v ktorých
často je možné prehľadne uložiť množstvo užitočných informácií. Mimochodom,
po vykonaní všetkej práce možno zhromaždené informácie o heslách považovať za
kontext súladu alebo nesúladu s požiadavkami normy PCI DSS (odsek 2.1,
2.1.1, 6.3.5, 6.3.6, 8.4, 8.5.x).

2. Analýza kontroly prístupu

Analýza kontroly prístupu sa musí vykonať na všetkých informáciách
zdrojov, na ktorých bolo možné NSD realizovať. A na zdieľanie súborov
Windows (SMB), na ktorých je otvorený anonymný prístup. To často umožňuje
získať ďalšie informácie o zdrojoch, ktoré neboli objavené v
čas skenovania siete, alebo naraziť na iné informácie, rôzne
stupeň dôvernosti uložený v prehľade. Ako som už povedal, o
vykonaním testovania PCI je vyhľadávanie zamerané predovšetkým na zistenie
údaje držiteľa karty. Preto je dôležité pochopiť, ako môžu tieto údaje vyzerať a
hľadajte ich vo všetkých informačných zdrojoch, pre ktoré existuje vhodný
prístup.

3. Útok hrubou silou

Je potrebné minimálne skontrolovať predvolené nastavenia a jednoduché kombinácie prihlasovacieho hesla.
Takéto kontroly je potrebné vykonať predovšetkým vo vzťahu k sieti
zariadení (vrátane SNMP) a rozhraniami vzdialenej správy.
Pri vykonávaní skenovania AsV cez PCI DSS nie je dovolené vykonávať „ťažké“
hrubou silou, čo môže viesť k stavu DoS. Ale v našom prípade je to tak
o internom PCI penteste, a teda v rozumnej forme a bez fanatizmu stojí
vykonať útok na výber jednoduchých kombinácií hesiel k rôznym
informačné zdroje (DBMS, WEB, OS atď.).

Ďalším krokom je analýza bezpečnosti webových aplikácií. Počas PCI pentestu
o hĺbkovej analýze webovej reči nejde. Nechajme to na QSA. Tu
stačí vykonať skenovanie čiernej skrinky so selektívnym overením
zneužiteľné zraniteľnosti servera/klienta. Okrem už spomínaných
bezpečnostné skenery, môžete použiť skenery prispôsobené na analýzu
Web. Ideálnym riešením je určite HP WebInspect resp
(ktorý je mimochodom výborný na odhaľovanie chýb v AJAX). Ale toto všetko je
drahý a cenovo nedostupný luxus a ak áno, tak nám bude vyhovovať w3af, ktorý v
v poslednej dobe naberá na sile, pokiaľ ide o detekciu rôznych druhov
zraniteľnosti webových aplikácií.

Čo sa týka manuálneho overovania zraniteľností na webe! Je to potrebné minimálne
skontrolujte mechanizmy autentifikácie a autorizácie, používanie jednoduchých
kombinácie prihlasovacích hesiel, predvolené hodnoty a obľúbené SQL injekcie,
vrátane súborov a vykonávania príkazov na serveri. Čo sa týka klientskej strany
zraniteľnosti, potom okrem overenia možnosti zneužitia zraniteľnosti tu
nič viac sa nevyžaduje. Ale na strane servera sa musíte trochu pohrať,
lebo je to stale pentest, aj ked podla PCI DSS. Ako som už uviedol, hľadáme PAN,
Meno držiteľa karty a CVC2/CVV2 voliteľné. S najväčšou pravdepodobnosťou takéto údaje
sú obsiahnuté v DBMS, a preto, ak sa nájde SQL injekcia, stojí za to vyhodnotiť názvy
tabuľky, stĺpce; je žiaduce vyrobiť niekoľko skúšobných vzoriek
potvrdiť alebo vyvrátiť prítomnosť takýchto údajov v databáze
v nezašifrovanej podobe. Ak narazíte na Blind SQL injection, je lepšie podnecovať
na webový server (s
--dump-all key), ktorý v súčasnosti funguje s MySQL, Oracle,
PostgreSQL a Microsoft SQL Server. Tieto údaje budú stačiť na preukázanie
zneužívanie zraniteľnosti.

Ďalším krokom je analýza bezpečnosti DBMS. Opäť je tu skvelé
nástroj - AppDetective od "Application Security Inc.", ale je drahý
potešenie. Bohužiaľ, podobný bezpečnostný skener by vydal
toľko informácií, koľko dokáže AppDetective, a podporuje to isté
DBMS momentálne neexistuje. A to je dôvod, prečo musíte vziať na palubu
mnoho samostatných, nesúvisiacich produktov, ktoré sú naostrené pod
spolupracovať s určitými predajcami. Takže pre orákula minimálna množina
pentester bude nasledovný:

• Oracle Database Client – ​​prostredie pre prácu s DBMS
• Ropucha pre Oracle - klient pre prácu s PL/SQL
• Oracle Assessment Kit – používatelia hrubou silou a databázové SID
• rôzne PL/SQL skripty (napríklad konfiguračný audit alebo
  schopnosť ísť až na úroveň vykonávania príkazov OS)

Poslednou fázou penetračného testovania PCI je analýza
bezpečnosť bezdrôtových sietí, alebo skôr ani analýza, ale hľadanie prístupových bodov,
pomocou zraniteľných konfigurácií, ako je Open AP, WEP a WPA/PSK. S inou
Na druhej strane štandard PCI nezakazuje hlbšiu analýzu vrátane
s obnovovacími kľúčmi na pripojenie k bezdrôtovej sieti. Pretože to dáva zmysel
vykonávať tento druh práce. Hlavným nástrojom v tejto fáze je
samozrejme bude aircrack-ng. Okrem toho môžete vykonať útok zameraný na
bezdrôtových klientov, známych ako "Caffe Latte", ktorí používajú to isté
nástroj. Pri vykonávaní prieskumu bezdrôtových sietí môžete bezpečne
riadiť sa údajmi z lokality
wirelessdefence.org.

Namiesto záveru

Na základe výsledkov testu sa vykoná analýza všetkých zozbieraných informácií
v kontexte dodržania technických požiadaviek normy PCI DSS. A ako už aj ja
poznamenané na samom začiatku, rovnakým spôsobom môžu byť údaje získané počas pentestu
interpretované v kontexte akéhokoľvek iného dokumentu na vysokej úrovni,
obsahuje technické kritériá a odporúčania pre systém manažérstva
informačná bezpečnosť. Čo sa týka šablóny používanej na podávanie správ
PCI dokumentov, môžete použiť požiadavky MasterCard na PCI
Skenovanie AsV. Ustanovujú rozdelenie správy na dva dokumenty -
dokument najvyššej úrovne pre manažéra, ktorý obsahuje krásne grafy
a je uvedené percento zhody aktuálneho stavu systému s požiadavkami PCI DSS,
a technický dokument obsahujúci protokol o vykonaných skúškach
penetráciu, identifikované a zneužité zraniteľné miesta, ako aj odporúčania pre
zosúladenie informačného systému s požiadavkami MasterCard.
Môžem sa teda rozlúčiť a popriať vám veľa šťastia vo výskume!

www

pcisecuritystandards.org - Rada pre bezpečnostné štandardy PCI.
pcisecurity.ru - portál,
venovaný PCI DSS od Informzaschita.
pcidss.ru je portál venovaný
PCI DSS od Digital Security.
isecom.org/osstmm - Otvoriť
Metodická príručka testovania bezpečnosti zdroja.
owasp.org - Otvorená webová aplikácia
bezpečnostný projekt.