Мобільні платіжні технології та вимоги з безпеки pci ssc - інформаційна безпека
Мобільні платіжні рішення ще недостатньо широко представлені на світовому ринку і в нашій країні зокрема. Проте, інтерес до подібних рішень з боку fintech-розробників, бізнесу та торгово-сервісних підприємств з кожним роком зростає.
Андрій Гайко
Сертифікований QSA-аудитор Digital Security
Що таке mPOS
Мобільний платіжний рішення (mPOS) складається з наступних основних компонентів:
Крім функцій захищеного читання карти та введення PIN-коду у mPOS повинна бути підтримка всіх основних способів верифікації власника карти, шифрування даних при передачі між компонентами і процессинговой частиною системи, а також можливість друку чеків або їх відправки по SMS і електронній пошті.
На стороні сервіс-провайдера або банку-еквайра, які займаються прийомом і подальшою обробкою даних при mPOS-платежах, використовується back-end система (платіжний шлюз), схожа з тими, що використовуються при інтернет-або звичайному POS-еквайринг.
Для того, щоб зрозуміти, які вимоги з безпеки повинні пред'являтися, на технічному рівні необхідно визначити основні компоненти екосистеми mPOS і існуючі інформаційні потоки. Для розуміння відповідальності суб'єктів екосистеми mPOS за безпеку платежів на бізнес-рівні необхідно визначити існуючі бізнес-моделі учасників платіжного процесу.
Схема інформаційних потоків містить 8 основних етапів (див. Рис. 1):
У реалізації описаного вище процесу можуть брати участь наступні компанії:
Слід зазначити, що компанія може виконувати не тільки одну із зазначених ролей. Можлива ситуація, коли компанія може повністю розробити всі програмні і апаратні компоненти mPOS-рішення. Залежно від того, які функції будуть виконуватися компанією, залежить, які вимоги з безпеки нею повинні дотримуватися.
Переліки основних компонентів і типів бізнес-моделей наведені для того, щоб зрозуміти, як повинна розмежовуватись відповідальність за виконання вимог безпеки між усіма учасниками екосистеми mPOS.
види сертифікації
Крім рекомендацій Visa і MasterCard розробили програми сертифікації постачальників мобільних платіжних рішень. По суті, обидві програми досить схожі, і з великою ймовірністю можна стверджувати, що розробка рішення відповідно до вимог однієї з МПС може бути сертифікована в іншої. Обидві МПС ведуть реєстри сертифікованих компаній і mPOS-рішень.
Далі будуть описані особливості застосування кожного зі стандартів PCI SSC до mPOS-рішень.
Стандарти PCI SSC
PCI DSS
У новій версії стандарту з'явилися нові вимоги, які як не можна до речі відносяться до безпеки mPOS. Зокрема, в розділі 9 додався пункт 9.9, згідно з яким необхідно вести облік пристроїв зчитування карт, а також проводити періодичне навчання співробітників / користувачів, які обслуговують пристрої, для того щоб вони вміли визначати підміну mPOS чи інші ознаки скіммінгу. У випадку з сервіс-провайдерами mPOS-рішень або еквайрингу при наданні клієнтам зчитувальних пристроїв вони повинні будуть розробити рекомендації та інструкції щодо захисту від скіммінгу і довести їх до відома співробітників ТСП. В рамках виконання вимоги 12.8 сервіс-провайдери і еквайєри на рівні договірних відносин можуть зобов'язати ТСП виконувати відповідні вимоги з безпеки mPOS.
Незважаючи на те, що виконання більшості вимог безпеки лягає на різних сервіс-провайдерів і банки, банки-еквайєри має право вимагати від ТСП заповнення листів самооцінки (SAQ) відповідного типу (SAQ P2PE-HW в разі використання ТСП P2PE-рішення, SAQ B-IP в разі використання mPOS зі зчитувачем, сертифікованим по PCI PTS). У таблиці вказані компоненти mPOS-рішень, відповідний стандарт, з яким компонент повинен відповідати, і компанія, відповідальна за реалізацію вимог.
Вимога 12.8 також актуально для тих випадків, коли ПО mPOS-рішень для сервіс-провайдера розробляється сторонньою організацією. У цьому випадку виконання вимоги 6.5 повністю лягає на плечі компанії-розробника. При цьому якщо компанія-розробник не буде виконувати вимоги, сервіс-провайдер не зможе пройти аудит на відповідність PCI DSS. У договорах між сервіс-провайдерами (еквайєрами) і розробниками слід передбачити питання проведення аудиту певних бізнес-процесів компанії-розробника в разі проходження сервіс-провайдером щорічної сертифікації по PCI DSS, тому що процес розробки буде включений в область аудиту сервіс-провайдера. Те ж актуально і в разі аутсорсингу інших послуг. У загальному випадку підтвердження третьою стороною відповідності вимогам PCI DSS в частині, що її стосується, може бути забезпечено шляхом самостійної сертифікації по PCI DSS необхідних бізнес-процесів з подальшим наданням свідчень про успішно пройдений перевірці або шляхом надання можливості аудиту бізнес-процесу в рамках аудиту сервіс провайдера (еквайра).
Відзначимо, що в нашій країні аудит розробників в рамках аудиту компанії-замовника відбувається досить рідко. Розробники на словах можуть гарантувати знання і застосування методів безпечної розробки, але по факту не володіти потрібними знаннями і не виконувати відповідних процедур. З виходом нової версії PCI DSS стан речей має змінитися, так як вимоги стали детальними, і зазначені в тексті стандарту перевірочні процедури зобов'язують QSA-аудитора проводити більш глибокі перевірки.
PCI PTS
Стандарт PCI PTS регламентує вимоги до безпеки для Point of interaction devices (POI) і Hardware Security Modules (HSM). Пристрій, що зчитує, що підключається до мобільного пристрою, є POI. Як згадувалося вище, в mPOS-рішеннях використовується два класи POI: PIN Entry Device (PED) і Secure Card Reader (SCR). Залежно від того, до POI якого типу відноситься пристрій, що зчитує, визначаються групи вимог PCI PTS, яким пристрій повинен відповідати.
На даний момент в деяких пропонованих на вітчизняному ринку mPOS-рішеннях використовуються зчитувачі no-name-виробників. Використання таких зчитувачів не гарантує безпечної передачі даних між пристроями та робить можливим передачу в мобільний пристрій номера карти у відкритому вигляді. Тому, вибираючи mPOS-рішення, необхідно переконатися, що сервіс-провайдер пропонує сертифіковане по PCI PTS пристрій, що зчитує.
Існують дві бізнес-моделі розробки клієнтського ПЗ: розробка для власного проекту, коли розробник створює mPOS-рішення і виводить його на ринок під власним брендом: в цьому випадку розробник буде сервіс-провайдером mPOS-рішення; - і розробка кінцевого рішення для подальшого ліцензування компаніями, які інтегрують компоненти різних виробників між собою і на їх основі створюють свої mPOS-рішення.
PA-DSS
Для mPOS-рішень PA-DSS в обов'язковому порядку вживають щодо прошивка пристроїв, що зчитує карткові дані. Для програмного забезпечення, що встановлюється на мобільний пристрій співробітника ТСП, даний стандарт є рекомендаційним. Це пов'язано з тим, що мобільний пристрій є недовірених і слабоконтроліруемой середовищем. Наприклад, на пристрої може бути виконаний jailbreak, який на порядок знижує його безпеку, не гарантує безпеки встановленого платіжного додатка. Саме тому МПС забороняють використовувати мобільні пристрої для введення PIN-коду і вимагають, щоб дані від пристрою, що зчитує приходили в мобільне ПЗ в зашифрованому вигляді і далі в тому ж вигляді передавалися в еквайринг. У цьому випадку дані платіжних карт не будуть у відкритому вигляді оброблятися і зберігатися в мобільному пристрої, а значить, і вимоги PA-DSS неспроможні.
У версії 3.0 стандарту з'явилися нові вимоги, на які розробникам прошивок для зчитувальних пристроїв і коробкових платіжних додатків слід звернути увагу в першу чергу. По-перше, кожне випускається оновлення має відбуватися окрему сертифікацію. По-друге, тепер клієнти повинні використовувати тільки ті версії (поновлення) ПО, які є сертифікованими і наведені на сайті Ради PCI.
PCI P2PE
Порівняно недавно вийшов у світ новий стандарт безпеки PCI P2PE. Стандарт призначений для рішень, що забезпечують криптографічний захист даних при їх передачі між усіма компонентами платіжного рішення. У разі застосування шифрування досягається звуження області дії стандарту в ТСП до мінімального рівня, так як у ТСП немає можливості отримання даних про власників карток у відкритому вигляді.
У перелік всіх основних компонентів екосистеми mPOS входить:
- пристрій, що зчитує;
- платіжний додаток для мобільного пристрою;
- платіжний шлюз;
- еквайрингова система, підключена до МПС.
На відміну від PCI DSS, який поширюється тільки на інформаційну інфраструктуру, PCI P2PE є більш комплексним і поширюється не тільки на інфраструктуру, а й на зчитувальні пристрої і програмне забезпечення POI-терміналів (в додатку до mPOS - це зчитувальні пристрої). Стандарт складається з 6 доменів, вимоги яких засновані на діючих стандартах PCI: зчитувальні пристрої повинні задовольняти вимогам PCI PTS SRED; програмне забезпечення зчитувальних пристроїв - PA-DSS; управління ключами шифрування - PCI PIN Security Requirements; платіжна інформаційна інфраструктура ТСП - PCI DSS. Якщо рішення сертифіковане по PCI P2PE, це означає, що дані між усіма підсистемами (від зчитувача до мобільного пристрою в ПО, від ПО в процесинг і далі) передаються в зашифрованому вигляді, і всі підсистеми виконують вимоги відповідних стандартів PCI.
За вимогами P2PE можуть бути сертифіковані як окремі компоненти, так і готові рішення.
МПС рекомендують використовувати P2PE-рішення для прийому mPOS-платежів. Однак складність полягає в тому, що на поточний момент на ринку існує трохи рішень подібного типу, тому МПС не вимагають, а рекомендують використовувати PCI P2PE-рішення і при розробці керуватися ними. Проте, сервіс-провайдерам платіжного mPOS-рішення потрібно бути готовими до того, що МПС незабаром будуть вимагати обов'язкової сертифікації їх mPOS-рішень за вимогами PCI P2PE.