Illustration

PCI DSS v4.0 

13.02.2023
PCI DSS (Payment Card Industry Data Security Standard, у перекладі з англ. «стандарт безпеки індустрії платіжних карток») — стандарт зі сфери кібербезпеки, спрямований на максимальний захист карткових даних при їх зберіганні, обробці або передачі. Був розроблений у грудні 2004 року при загальній участі п’яти транснаціональних корпорацій у сфері платіжних карт: Visa, MasterCard, American Express, Discover Financial Services, JCB International. 
Якраз нещодавно була випущена 4.0 версія стандарту PCI DSS, яка, у загальному, покращує вже дещо застарілі вимоги версії 3.2.1 (розробленої у 2018 році, а формально - ще у 2016), але має і зовсім нові вимоги — відповідні до сучасних реалій кіберзагроз. Проте структура залишилася незмінною: 12 розділів, що містять у собі конкретизовані вимоги (259 вимог, якщо бути точними).
Але почати краще з іншого. А саме з термінів, коли ж саме 4.0 версія стане обов’язковою. Уже з другого кварталу (1 квітня) 2024 року версія 3.2.1 втрачає свою чинність. Відповідно, якщо організація проходить планову ресертифікацію до кінця першого кварталу 2024 року, то вона ще може пройти її за вимогами версії 3.2.1 стандарту.
Крім того, як колись і з версією 3.2, версія 4.0 має «best practice» - вимоги, які стають обов’язковими лише після 31.03.2025 року, а до того є лише рекомендацією. Майже всі нові вимоги є саме рекомендованими.

Illustration

Отже, а що саме нове є в тому PCI DSS 4.0?
Для початку, до кожного з розділів додали по вимозі, що всі ролі, які беруть участь у забезпечені її (вимоги) підтримки в організації повинні бути задокументованими та описаними.
Перший та другий розділи особливих змін не зазнали.
До третього розділу додали сім нових вимог (вимога щодо ролей та обов’язків не враховується). Загалом: • були окремо описані вимоги щодо використовуваних хешів (такі самі, що були до шифрування), • документувати архітектуру шифрування необхідно тепер не тільки сервіс-провайдерам, • замість маскування у форматі 6*4 відтепер дозволено маскування у форматі BIN*4.
Четвертий розділ отримав лише дві нові вимоги. Необхідно впровадити інвентаризацію усіх довірених ключів та сертифікатів, які використовуються для захисту повного номеру картки при його передачі. А також додали вимоги до сертифікатів, що використовуються для захисту повного номеру картки при його передачі через публічні мережі.
П’ятий розділ має п’ять нових вимог — майже символічно. Саме в п’ятому розділі вперше з’являється нове для стандарту PCI DSS поняття «targeted risk analysis» — цільовий аналіз ризику. 
Версія 4.0 пропонує організаціям самостійно заповнювати таблицю, шаблон якої наведено у новій версії стандарту, де аналізується той чи інший ризик та робляться висновки щодо його (ризику) прийняття чи компенсації, чи уникнення тощо. І саме заповненням даної таблиці вимагається визначати періодичність та частоту сканування систем антивірусними засобами, а також періодичність перевірок систем, що вважаються непідданими вірусним загрозам. Також п’ятий розділ визначає, що антивірус відтепер повинен сканувати і всі знімні носії, а також повинен бути організований захист організації від фішингу.
Шостий розділ отримав три нові вимоги. Необхідно створити та підтримувати реєстр всього користувальницького ПЗ, а також всього ПЗ від третіх сторін. Також для власників веб-сторінок платіжних систем необхідно вести список всіх скрипт-сценаріїв на даній сторінці з обґрунтуванням необхідності кожного з них. Та відтепер WAF є обов’язковим для використання.
Сьомий розділ — знову три нові вимоги. Впровадили перевірку всіх облікових записів на легітимність їх існування та прав щонайменше раз на шість місяців, а також окремо виділили вимоги до технічних та сервісних облікових записів.
Восьмий розділ містить п’ять нових вимог. Вони стосуються, у більшій мірі, саме мультифакторної автентифікації. А також тут були сформульовані вимоги щодо облікових записів, які можуть бути використані для інтерактивного входу.
Дев’ятий розділ отримав лише одну нову вимогу. Необхідно тепер із періодичністю, визначеною тим самим «targeted risk analysis», перевіряти пристрої POI на відсутність підробки.
Десятий розділ може похизуватися трьома новими вимогами. Вони вимагають обов’язково використовувати з 2025 року автоматизовані механізми перевірки логів.
Одинадцятий розділ має п’ять нових вимог. Вони дещо конкретизують особливості та порядок дій при внутрішньому скануванні на вразливості (проводити яке мають лише авторизовані користувачі), а також додають, що системи IDS/IPS повинні виявляти та усувати зокрема приховані канали передачі шкідливих програм. А також з’явилося поняття «multi-tenant service providers» — будь-які дата-центри та хмарні провайдери підпадають під дане визначення. І всі вони повинні будуть проходити додаткову перевірку за додатком A1.
Дванадцятий розділ - останній та абсолютний чемпіон за кількістю нових вимог (їх аж тринадцять). І аж дві вимоги з них є обов’язковими для виконання ще з 2024 року. Це необхідність проводити вже декілька разів згаданий «targeted risk analysis» щонайменше раз на рік, а також необхідність підтримувати документований опис зони відповідності стандарту в актуальності та проводити перевірку щонайменше раз на рік або при суттєвих змінах даного середовища. Усі інші нові вимоги також зосереджені в основному на документуванні того чи іншого аспекту підтримання організацією відповідності вимогам стандарту PCI DSS.
Підводячи підсумки, версія 4.0 стандарту PCI DSS зосереджена на сучасних проблемах та методах, вона ширша у формулюваннях за своїх попередників але й більш вимоглива. Але рік перехідного періоду, коли версія 4.0 вже є обов’язковою, але майже всі нові вимоги є рекомендованими, дозволить організаціям підготуватися до них та провести впровадження їх виконання у спокійному режимі.
Посилання на текст стандарту PCI DSS v4.0: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf 
Посилання на опис змін у стандарті PCI DSS v4.0 у порівнянні з v3.2.1:https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r2.pdf

Залишилися питання?

Заповни форму зворотного зв'язку, і наші фахівці нададуть консультацію найближчим часом.

Дякуємо!

Ми зв'яжемося з вами найближчим часом

Can't send form.

Please try again later.

Made with