Самостійне оцінювання кіберризиків: 6 прогалин, які фінтех помічає останніми

Самостійне оцінювання ризиків кібербезпеки (cybersecurity risk self-assessment) - це швидка внутрішня перевірка захищеності компанії за структурованим переліком запитань. Для фінтеху воно показує, які напрями захисту тримаються на припущеннях, а не на перевірених фактах, і з чого варто починати детальнішу перевірку. Це не аудит і не заміна пентесту.

За дев'ять років тестувань на проникнення для фінтех-компаній і банків ми бачимо, що прогалини повторюються від проєкту до проєкту. Ось як вони виглядають найчастіше:

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

Навіщо фінтех-компаніям проводити самостійне оцінювання кіберризиків?

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

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

Паралельно змінюються вимоги. DORA, NIS2, PSD2, PCI DSS і GDPR оновлюються в різному темпі, і навіть досвідчена команда не завжди встигає перевірити, що саме змінилося конкретно для неї.

Найнебезпечніший стан - не «ми знаємо про свої проблеми», а «у нас начебто все спокійно». У проєкті з впровадження SIEM для фінансової компанії, що обслуговує понад 200 000 клієнтів, уже на етапі пілотного запуску виявилося 12 інцидентів, які до того залишалися непоміченими. Тобто відсутність зафіксованих інцидентів означала лише те, що їх не було кому фіксувати.

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

• конкретні прогалини: пентест не проводили більше року, API не тестували окремо, хмарну інфраструктуру ніхто не перевіряв, план реагування написаний, але жодного разу не відпрацьований;
• напрями, де захист тримається на припущенні, а не на перевіреному факті;
• теми для першої ж розмови з фахівцями з кібербезпеки - уже у формі конкретних запитань, а не загального «перевірте нас».

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

Які напрями кібербезпеки охоплює тест?

Опитувальник побудовано на дев'ятирічному досвіді Datami у проведенні тестувань на проникнення для фінтех-компаній і банків у країнах ЄС, Балтії, Великій Британії, регіоні DACH та Північній Європі. Під час розробки враховано вимоги NIS2 (EU 2022/2555), GDPR (EU 2016/679), PCI DSS v4.0.1, PSD2 (EU 2015/2366) і DORA (EU 2022/2554), а також специфіку платіжних процесів, бізнес-логіки транзакцій, KYC-процедур і роботи з підрядниками.

1. Відповідність вимогам та регуляторна готовність. Регуляторні прогалини зазвичай спливають у найгірший момент - під час due diligence перед підключенням нового партнера. Причина рідко в тому, що документів немає: під час аудиту політик безпеки для міжнародної BaaS-компанії сім ключових політик існували, але більшість процесів були на рівні зрілості Defined / Repeatable - описані, проте некеровані. Тому перший блок питань стосується не наявності документів, а того, чи живуть вони в щоденних процесах.
2. Тестування на проникнення та оцінка безпеки. Пентест, проведений півтора року тому, описує систему, якої вже не існує: змінилися релізи, з'явилися нові ендпоінти й інтеграції. Ще частіше платіжна логіка взагалі не входила у скоуп, а після виправлень ніхто не проводив ретест. Питання цього напряму - про давність перевірки, її охоплення й підтвердження виправлень.
3. Безпека API та транзакцій. Більшість дорогих інцидентів у фінтеху відбуваються не через «злам сервера», а через логіку: недостатню перевірку прав на конкретний об'єкт, можливість повторно надіслати підтвердження транзакції або пройти сценарій в обхід бізнес-правил. Показово, що в аудиті P2P-платформи з десяти знайдених вразливостей усі три критичні були саме в механізмах обробки транзакцій і смартконтрактах - потенційні збитки оцінювалися приблизно у $300 000. Саме тому в опитувальнику є окремі питання про контроль доступу до ендпоінтів, обмеження кількості запитів і узгодженість транзакцій між собою.
4. Моніторинг та реагування на інциденти. DORA і GDPR встановлюють жорсткі строки повідомлення про інцидент, але план реагування, який жодного разу не програвали на навчаннях, у момент атаки зазвичай не працює. Різниця вимірюється в цифрах: у згаданому SIEM-проєкті час виявлення інциденту скоротився з кількох днів до 1–2 годин, а час реагування - з 2–3 днів до 6–8 годин. Питання перевіряють, чи є задокументований план, хто ухвалює рішення поза робочим часом і чи справді хтось дивиться на події безпеки цілодобово.
5. Ризики третіх сторін та ланцюга постачання. Інцидент у платіжного провайдера або KYC-сервісу зупиняє ваші операції незалежно від того, наскільки добре захищена власна інфраструктура. При цьому договір із постачальником рідко відповідає на просте запитання: за скільки годин він зобов'язаний повідомити вас про компрометацію. У проєкті для BaaS-компанії окремим результатом стало саме посилення вимог до вендорів у договорах і запровадження регулярних перевірок третіх сторін.
6. Люди, процеси та архітектура. Права доступу накопичуються самі собою: співробітник змінює роль, а старі доступи залишаються. Без сегментації один скомпрометований компонент відкриває шлях до платіжного контуру. Питання цього напряму - про регулярний перегляд прав, навчання команди та ізоляцію критичних систем.

Які проблеми найчастіше залишаються непоміченими?

Кілька хибних уявлень трапляються навіть у зрілих командах - і саме через них прогалини живуть роками.

Сканування сприймають як пентест. Автоматичний сканер знаходить типові технічні проблеми, але не перевіряє бізнес-логіку й не будує ланцюжки з кількох дрібних недоліків. В аудиті P2P-платформи автоматичні інструменти працювали паралельно з ручним тестуванням - і критичні знахідки дала саме ручна перевірка механізмів розрахунків.

Комплаєнс прирівнюють до захищеності. Пройдена перевірка підтверджує наявність процесів. Чи витримають технічні механізми реальну атаку - окреме запитання, і відповідь на нього дає тільки практика. У аудиті хмарної інфраструктури GCP перед сертифікацією PCI DSS знайшли 12 вразливостей, більшість - у базових налаштуваннях доступу, а не в екзотичних сценаріях атак.

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

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

Як працює тест?

Пройти тест нескладно: 20 запитань, відповіді «Так» або «Ні», п'ять хвилин часу. Значно складніше відповідати чесно.

Спокуса відповісти краще, ніж є насправді, виникає майже завжди. «Пентест у нас був» - але два роки тому й без перевірки платіжної логіки. «План реагування на інциденти є» - але його жодного разу не відкривали після написання. Формально в обох випадках відповідь «Так». Насправді захисту немає.

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

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

Результат не є аудитом, сертифікацією або підтвердженням відповідності нормативним вимогам.

Що означає ваш результат?

• 0–3 «Ні» - низький рівень ризику. Базові процеси безпеки сформовані, потрібен регулярний перегляд.
• 4–7 - середній. Є окремі прогалини, здатні вплинути на захищеність або відповідність вимогам.
• 8–12 - високий. Кілька важливих напрямів потребують оцінки та пріоритезації.
• 13–20 - критичний. Потрібна комплексна перевірка й план першочергових заходів.

Ця шкала показує масштаб роботи. Її пріоритет вона не показує.

Що робити після проходження тесту?

Пріоритет визначає не цифра, а розподіл. Три «Ні», розкидані по організаційних питаннях, і три «Ні» поспіль у блоці про платіжну логіку та реагування на інциденти дають однаковий бал і зовсім різний рівень загрози. Другий випадок стосується напряму, де, за нашою практикою, ховаються найдорожчі вразливості, - і реагувати на нього варто швидше, ніж підказує загальний результат.

Далі логіка проста:

• визначити, які активи й дані справді критичні;
• перевірити технічні ризики в напрямах з найбільшою кількістю «Ні»;
• провести пентест або аудит систем і платіжної логіки;
• скласти план усунення вразливостей із чіткими пріоритетами;
• після впровадження змін пройти ретест.

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

Висновок

Найгірше слово у звіті з безпеки - не «критично». Критичну знахідку можна закрити: на P2P-платформі клієнт усунув три такі вразливості за 48 годин. Найгірше слово - «не оцінювалося». Саме так виглядав статус вразливостей у фінтех-компанії перед аудитом GCP, поки перевірка не перетворила порожнечу на дванадцять конкретних пунктів із планом виправлення.

Самостійне оцінювання не робить систему захищенішою - жоден опитувальник цього не вміє. Воно робить іншу річ: переводить частину «ми не знаємо» у «ми знаємо». І компанія, яка бачить десять своїх слабких місць, у значно кращому становищі за ту, яка щиро не бачить жодного.

Повертайтеся до самостійного оцінювання після кожної суттєвої зміни - нової інтеграції, виходу на новий ринок, зміни платіжного провайдера. А якщо тест показав прогалини у критичних напрямах, наступний крок - перевірити їх на практиці. Команда Datami проведе тестування на проникнення з урахуванням специфіки платіжної логіки, API та вимог NIS2, PCI DSS і DORA, а за результатами складе план усунення вразливостей із чіткими пріоритетами.