Як підготуватись до проходження PCI DSS, SOC 2 та ISO: реальний досвід фінтех-компанії

Привіт! Мене звуть Дмитро Бєляєв, я — CTO Spendbase. Разом із колегою Терентієм Стребковим, CISO компанії, ми вирішили поділитися досвідом проходження аудитів за стандартами PCI DSS, SOC 2 та ISO 27001.

Spendbase — це FinTech-платформа, яка допомагає бізнесам оптимізувати витрати на софт і хмарні сервіси. У процесі розвитку продукту ми неодноразово стикалися з вимогами до інформаційної безпеки та необхідністю підтвердити відповідність міжнародним стандартам.

У цій статті ми розказуємо, як організувати проходження аудитів так, щоб розбити цей процес на конкретні задачі та вписатися в адекватні часові рамки.

Матеріал буде корисний командам, які проходять аудит вперше. Якщо у вас вже є такий досвід, скоріше за все тут не буде для вас нової інформації.

Зайдіть на сайт будь-якого вендора послуг, прокрутіть вниз сторінки й майже напевно побачите посилання на Trust Center або Whitepaper про безпеку. Клієнтів завжди цікавить, наскільки безпечно користуватися сервісом. Щоб в тисячний раз не розповідати одне й те саме, компанії публікують свої сертифікати відповідності міжнародним стандартам безпеки прямо на сайті. Але щоб отримати такий сертифікат, потрібно спершу пройти аудит.

Типовий приклад секції безпеки на сайті вендора

Коротко про стандарти

Почнемо з короткого опису стандартів і пояснення, чому вони можуть знадобитися.

PCI DSS. Потрібен, якщо ви обробляєте фінансові дані або зберігаєте дані платіжних карток. Наприклад, випускаєте ці картки, тобто маєте власну карткову програму або еквайрінг. Цей стандарт регламентує багато різних аспектів: від кольору бейджа відвідувача в офісі до того, що саме пишеться в лог, як воно деплоїться і запускається. PCI DSS дуже стандартизований: як скажуть робити, так вам і доведеться підлаштувати процеси.

SOC 2. Якщо ви збираєтесь працювати з американськими компаніями, можуть вимагати його для співпраці. SOC 2 регламентує теж багато чого: від процедур найму (як саме відбувається скрінінг, evidence) до деплою коду. Основна ідея тут в захисті даних вашого користувача та загальній безпеці в організації.

SOC хоч і більш гнучка система, яка вказує лише критерії, під які вам треба підходити, щоб успішно пройти аудит (контролі ви вже можете обрати самі), водночас вона і найзаплутаніша, бо має 3 види: SOC 1, SOC 2 і SOC 3. Проте насправді, коли розібратися, як вона влаштована, то складність зникає.

SOC 1 стосується фінансових репортів ваших клієнтів і того, як ваша організація з ними поводиться. А от SOC 2 вже стосується організації повістю та складається з п’яти TSC (Trust Service Criteria): перший і обов’язковий Security, далі Availability ваших сервісів, Confidentuality в вашій компанії, Privacy даних користувачів i Processing Integrity.

SOC 3 — це той самий SOC 2, тільки репорт більш розрахований на загального читача, без конфіденційної інформації по внутрішнім процесам та контролям.

Тип 1 відрізняється від типу 2 тим, що є оцінкою точки проведення аудиту у часі, а тип 2 оцінює відрізок.

ISO 27001. Фреймворк безпеки захисту даних користувача, безпеки організації. Має багато спільного з SOC 2 і є одним із найпоширеніших у світі. Деякі клієнти навіть не будуть вас розглядати, якщо у вас не буде цього сертифікату.

Коли потрібен аудит

Для білого бізнесу, який хоче бути вендором для великих компаній, запит на аудити формується десь так: ви — B2B SaaS, ваш сейлз знаходить ліда на вашу унікальну пропозицію з Fortune 500, але лід каже, що ви повинні бути сертифікованим вендором.

ISO 27001 міжнародно визнаний. Тут те ж саме, що і для SOC 2: якщо хочете продавати свої рішення, наприклад, міжнародній фармкомпанії, відсутність сертифікації стане блокером. Бо компанія-клієнт чи партнер зобов’язані за цими ж фреймворками вести справи тільки з такими ж сертифікованими компаніями, щоб прибрати supply chain небезпеку, яку несуть компанії з невідомим статусом безпеки. Тож якщо у вас немає сертифікації, готуйтеся постійно проходити опитувальники безпеки.

Для фінтех-компаній сертифікації — це джентльменський мінімум. Без них буде важко стати вендором або клієнтом. Тут все залежить від ризиків, які ви вносите своєю діяльність для інших у бізнес-ланцюжках та процесах. Є можливість створити, наприклад, необанк і не випускати картки самому, а делегувати їх випуск партнеру. В такому випадку сертифікація PCI DSS може бути необов’язкова, і деякі контролі чи критерії будуть не обов’язкові в інших фреймворках.

Але загалом, як ми вже зазначили, у певний момент до вас, як до CEO, CTO або ліда, приходить сейлз-менеджер і каже: «Це блокер». От тоді й починається етап планування.

Як організувати проходження сертифікації

Для цього процесу потрібно:

1. Визначити, які сертифікації потрібні з огляду на стратегію компанії. Якщо вам зараз потрібен ISO 27001, але ви плануєте вихід на ринок США, то знадобиться і SOC 2 у майбутньому. З цим питанням також може допомогти legal-команда, адже крім безпекових сертифікацій, є ще питання комплаєнсу: GDPR, DORA, CCPA, HIPAA тощо.

2. Призначити відповідальну особу, яка буде імплементувати аудит в компанії. Морально приготуватись, що ця особа буде турбувати хедів та лідів, і ставитиме таски на впровадження. Тобто повноцінний PM, який буде об’єднувати та комунікувати з усіма залученими командами, як зовнішніми, так і внутрішніми.

3. Почати пошук аудитора. Як правило, вони самі спамлять на пошту постійно. Таких вендорів багато, вони надсилають пропозиції, але ціна може відрізнятись в 10 разів залежно від обсягу послуг:

• Найдорожчий варіант all inclusive — комплаєнс-платформа, допомога в імплементації, внутрішній аудит, зовнішній аудит. Це як сходити в дорогий ресторан, де в тебе приймуть замовлення і принесуть все на блюді.
• Середній варіант — допомога в імплементації, внутрішній аудит, зовнішній аудит. Це як фудкорт: треба самому донести свою їжу та прибрати за собою.
• Мінімум — внутрішній аудит, зовнішній аудит. Це як приготувати їжу вдома самому: перед цим треба не забути купити всі продукти.
• Лише зовнішній аудит. Це як приготувати їжу у XV столітті: треба нарубати дров для печі, виростити томати та курей, заготовити картоплю, а вже потім готувати та їсти.

За співвідношенням ціна/якість рекомендуємо другий або третій варіант, залежно від того, що буде простіше: платити людині всередині компанії за імплементацію чи покластись на аудиторську компанію.

До речі, нам було важливо, щоб аудитор був сам сертифікований і акредитований надавати такі послуги. Також варто проговорити, що вам важливо, щоб зовнішній аудит і фінальний сертифікат були також від акредитованої компанії.

Коли ви обрали компанію-аудитора, перевірили її у реєстрі сертифікованих аудиторів і готові перейти до самого процесу, виникає цікава виделка:

• у вашій команді є людина з досвідом, яка це робила;
• у вас немає такої людини в команді.

Розглянемо другий варіант, коли все робиться з нуля і перший раз.

Розділимо процес на такі кроки:

1. Планування.
2. Підготовка.
3. Імплементація.
4. Валідація.

1. Планування

На етапі планування відповідальна особа повинна повністю ознайомитися зі стандартом.

Організація вивчає стандарт → Формує для себе план впровадження → Живе за цим планом → Робить докази для аудитора

По кожній з цих сертифікацій є документація. Наприклад, можна скачати PDF по актуальному PCI DSS тут www.pcisecuritystandards.org. Те саме справедливо для SOC 2, ISO 27001.

Але будемо чесними: прочитати PDF на 500 сторінок, законспектувати його і створити план — доволі складна задача. Та й загалом там немає рекомендацій, як саме і що робити, а просто прописані формальні вимоги.

Далі нам потрібно зібрати команду. Спланувати цей процес — задача не для однієї людини, адже будуть задіяні різні компетенції:

• IT — відповідають за всі внутрішні процеси компанії, від доступів до роботи з вендорами.
• Legal — перевіряють документи на відповідність вимог policy, редагують тексти.
• HR — збирають докази скринінгу кандидатів, evidence при onboarding/offboarding.
• DevOps — відповідають за бекапи, системи SIEM/IAM, централізацію логування.
• Development — реалізують шифрування даних і визначають, що пишеться у логи.
• C-Level — контролюють впровадження на рівні компанії.

Одна людина може закривати декілька компетенцій, але якщо є можливість розподілити ці ролі, це суттєво прискорить процес.

Деякі речі, наприклад, шаблони політик, може надати аудитор. Зазвичай у нього є готові приклади, які, на його думку, підходять компанії. Головне запам’ятати: policy — це не просто документ, а буквально інструкція для всіх по тому, як щось робиться у вашій компанії.

Перед початком, в ідеалі, кожен із перелічених спеціалістів має пройти хоча б короткий онлайн-курс на Udemy на тему сертифікаціі. Не всі прочитають і запам’ятають повний документ, але всі мають бути в курсі задач та цілей компанії.

Що саме ми плануємо?

Ми плануємо зміни у коді, логіці продукту та процесах компанії. Розглянемо це на прикладі логування. Припустимо, ми маємо пункт N, який вимагає участі Legal, DevOps та Development. Ці фахівці збирають і аналізують вимоги та планують їх реалізацію.

Беремо PCI DSS 4.0 і дивимось вимоги для логування:

• Логи зберігаються не менше 1 року.
• У швидкому доступі мають бути логи за 3 місяці.
• Логи мають бути захищені від втручання.
• Повинен існувати механізм експорту, пошуку та аналізу логів.
• Логи повинні покривати всі компоненти cardholder data.

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

• Legal перевіряє, як вимоги відображені в policy.
• Development дивиться, чи всі компоненти генерують потрібні логи; якщо ні, то створює задачі для доопрацювання (SDLC).
• DevOps налаштовує retention policy та access policy на рівні IAM.

Таким чином, по кожному пункту вимог сертифікації можна спланувати обсяг робіт.

2. Підготовка

Коли план складено й зрозуміло, де знаходиться старт вашої подорожі, можна починати роботу.

Якщо ви обрали допомогу аудитора в імплементації, то перед нею він попроcить вас максимально повно описати, що, як і для чого ви робите. Щоб зрозуміти, де у вас прогалини в процесах і що саме треба підняти в першу чергу, щоб запрацювало все інше.

Будьте готові розповісти все як є та попутно згадати всі архітектурні рішення й технології, якими користуєтесь. Наприклад, що звільнених співробітників ви ніколи й не офбордили, і не видаляли їхні доступи.

Після підготовки у вас має бути чекліст, який показує:

• що вже готово;
• що треба покращити;
• що треба створити з нуля.

332 пункти контролів, які необхідні для PCI DSS 4.0 lvl1

3. Імплементація

Основні складові імплементації:

• Документаційна. Вся можлива документація по процесах і правилах у компанії. Її потрібно надати на ознайомлення і аудиторам, і співробітникам, які мають знати, наприклад, як користуватися корпоративним лептопом та де брати доступи.
• Продуктова / Development. Зміни до продукту, що забезпечують відповідність вимогам. Наприклад, правила аутентифікації користувачів, SDLC.
• Інфраструктурна / DevOps, IT. Все, що стосується вашої інфраструктури. Як продукту, так і внутрішньої.
• Безпекова / HR, IT. Процеси та відповідальність за безпеку.

Загальні поради щодо побудови процесів:

• Масштабованість. Це окей — щось робити руками, поки ви мала компанія. Але враховуйте, що в майбутні роки ви маєте покращити цей процес і зробити його таким, щоб не треба було наймати 20 співробітників, які б зранку до вечора крутили одну гайку.
• Доказовість. Ви, звісно, можете сказати, що робите Vendor due diligence перед онбордингом нового вендора, і навіть прописати це у вендор-полісі. Але як довести це аудитору? Будуйте процеси так, щоб можна було переглянути таски, логи, дзвінки, імейли та скріншоти, які б слугували доказом проведення тих чи інших дій.
• Швидкість. Ніхто не хоче сповільнювати команди додатковим контролем та бюрократією, але повністю відмовитися від процедур теж не вийде. Обирайте варіанти, які поєднують дві попередні характеристики й при цьому не дуже блокують роботу команд. Наприклад, замість того, щоб кожен співробітник приходив до IT-адміна і просив доступ до якоїсь тули, а потім отримував дозвіл від керівника та логував це в системі, автоматизуйте цей процес.

Legal — у рамках кожного з аудитів є вимоги на мінімальний набір policy, і це доволі tricky-частина. Наприклад, є полісі по бекапах, а чи видаляєте ви дані клієнтів з бекапаів по запиту? Писати ці штуки із ChatGPT не потрібно. Можна купити готовий пакет як чернетку (ціна $200–500) та відредагувати під задачі вашої організації. Це десь близько 50 документів, частину яких можна перевикористати для наступного аудиту. Аудитор також може надати свої темплейти, які можна адаптувати під ваш кейс.

Development/Product — тут буде найбільше роботи, але потрібно чітко визначити, що саме є об’єктом аудиту: наприклад, для PCI DSS це будуть конкретні сервіси та база. А умовно якась зайва тула в GitHub не буде частиною аудиту.

Для кожної із перелічених сертифікацій є загальні риси.

• Software Development Life Cycle. 3 бранчі, 2 апруви на PR (той, хто створив PR, не може його апрувати), наявність незалежних середовищ (env) із різними рівнями доступу (розробники не мають доступу до продакшену). Це перевірять автоматизованою тулою.
• Безпечний код. Тести, linter, шифрування даних визнаними алгоритмами (NIST). Інтеграція SAST (статичний аналіз безпеки) і DAST (динамічний аналіз безпеки) для всіх репозиторіїв, що входять до аудиту.
• Доступи до бази, AWS, секретів. Згідно з тим, що ви зазначили в policy, але паролі не можуть бути старшими за 90 днів. Згідно policy це перевіряє відповідальна особа. Всі outside collaborators теж повинні бути чітко обліковані: хто у вас працює, з яким доступом і чому.

Якщо на попередньому етапі все було правильно сплановано, імплементація перетворюється на набір задач, де нічого нового винаходити не потрібно.

Після того як ми зробили все, що планували, закодили й перевірили, наступний крок — повідомити аудиторів, що ми готові до перевірки. На цьому етапі починаються дзвінки, де ми показуємо, що і як у нас працює, GitHub з кодом, AWS, Grafana з логами.

Аудитори йдуть по своєму чек-лісту, задають уточнюючі питання. Якщо у них є відкриті питання, вони формують remediation plan. Якщо питань немає, то переходять на наступний етап.

4. Валідація

Тепер ваша система та процеси організації повинні працювати згідно з тим, що написано в policy. Тобто на цьому етапі ви повинні жити цим: наприклад, надсилати листи при великих змінах згідно PCI DSS, мати SIEM систему, повідомляти про інциденти тощо.

Якщо все налаштовано правильно, етап валідації буде дуже простим. Він виглядає наступним чином: вам присилають величезний чекліст, де на кожне питання потрібно зробити evidence. Наприклад, для логування — показати, де стоїть retention (скріншот), як дістати логи у швидкому доступі (відео), що саме ви пишете в код і як, наприклад, хешуєте карткові дані (посилання на код, скріншот логів).

Цей етап найдовший, для кожної сертифікації у нас він зайняв не менше двох місяців.

Також така валідація буде зберігатись щорічно, тож краще завчасно продумати, як збирати потрібні дані та формувати докази, щоб наступного року прийти з усім готовим.

Висновки

Сертифікації — це довго, в кращому випадку пів року+. Це важко не через складність окремих кроків, а через великий обсяг роботи. При чому ця робота не є rocket science і кожен крок можна загуглити.

Головне розуміти основну мету сертифікацій — все це для того, щоб з вашою компанією могли співпрацювати інші. Особливо коли у вашій організації більше ніж 20-50 людей, і вже не можна в ручному режимі за всім слідкувати та оперувати безпечно.

Ми проходили сертифікації вперше. Завдяки тому що наш продукт ще був на стадії розробки (сертифікація PCI DSS йому потрібна була для виходу в продакшн, щоб працювати без card frame), ми могли вносити зміни в код доволі швидко і пройшли PCI DSS за 9 місяців.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.