Ваш SOC 2 — це не ваша безпека

Кожен fintech-засновник зрештою має ту саму розмову зі своїм першим корпоративним клієнтом. Клієнт просить SOC 2. Засновник замовляє його. Шість місяців і сорок тисяч доларів пізніше аудит закривається чисто, і угода закривається разом із ним.

Потім проходить рік, продукт росте, і в один тихий вівторок команда безпеки знаходить те, чого там не повинно бути. Аудит був чистим. Система — ні.

Це не звинувачення SOC 2. Це чесний опис того, чим SOC 2 є і чим не є, та де живе прірва між ними.

Що SOC 2 насправді підтверджує

Аудит SOC 2 Type II підтверджує, що у вас є контролі та що ці контролі функціонували відповідно до задуму протягом певного вікна — зазвичай три, шість або дванадцять місяців. Це аудит процесів. Аудитор перевіряє, що ви робите те, що кажуть ваші політики.

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

Це справді цінно. Це означає, що покупець може запитати "чи логуєте ви доступ?" і довіряти відповіді. Регулятор може бачити, що ви серйозно ставитеся до контролів. Суд, якщо дійде до цього, може бачити, що ви вжили розумних заходів.

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

Проблема двох систем

Fintech-системи зазвичай мають дві паралельні позиції безпеки.

Перша — задекларована позиція: те, що кажуть ваші політики, що описують ваші runbook-и, що бачить аудитор. Саме це підтверджує SOC 2.

Друга — реальна позиція: те, що насправді відбувається у виробництві о третій ночі, коли черговий інженер реагує на інцидент. Як виглядає staging-середовище після шести місяців "прибиремо це пізніше." Що насправді робить сторонній SDK, що обробляє токенізацію вашої картки.

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

Що реально робити

Є три звички, що закривають прірву.

Ставтеся до аудиту як до підлоги, а не стелі. Аудитор перевіряє, що ви логуєте доступ. Добре. Потім запитайте: чи правильні речі ми логуємо? Чи ми переглядаємо логи? Чи будуть дії рішучого інсайдера помітні, чи невидимі в шумі? SOC 2 цього не запитає. Ви повинні.

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

Пильно стежте за нудним дрейфом. Новий SDK додається без security review. Staging-база даних засівається знімком виробничої. Дозволи постачальника розширюються "тимчасово" і ніколи не звужуються. Цей дрейф — те, чого аудити не бачать і що зломи роблять.

Чесна пропозиція

Чистий SOC 2 є необхідним. Але його недостатньо. Агентства та консультанти, що трактують його як фінішну пряму — а їх багато — продають вам аудит, а не безпеку.

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