Оцінка готовності до SOC 2 SaaS-платформи

Чому SOC 2 став умовою нових контрактів 

Причина була простою: кілька потенційних клієнтів у США готові підписати контракт лише за умови відповідності компанії вимогам SOC 2. Без підготовки до незалежного аудиту компанія ризикувала втратити ці угоди. Показово, що жодного інциденту безпеки до цього моменту в компанії не сталося – це не був антикризовий проєкт.

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

Ці прогалини стосувалися кількох напрямів:

1. Не всі правила задокументовані. Частина практик безпеки вже діяла, однак не була закріплена у формальних політиках і процедурах. Для аудитора SOC 2 усна домовленість не є доказом контролю.

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

3. Журналювання та моніторинг безпекових подій були обмеженими, а формалізованого порядку реагування на інциденти не існувало.

І ширше – управління ризиками інформаційної безпеки не було структурованим: компанія не проводила регулярної оцінки ризиків.

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

Як ми оцінювали готовність до SOC 2

Готовність до SOC 2 – це про те, щоб перевірити контролі, усунути прогалини та підготувати докази їхнього впровадження для майбутнього аудитора.

Оцінка готовності до SOC 2

Основою роботи над проєктом стало оцінювання готовності компанії до SOC 2. У її межах перевірили чотири напрями: 

• управління безпекою;
• політики та процеси безпеки;
• контроль доступів;
• безпеку хмарної інфраструктури.

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

• хмарну інфраструктуру SaaS-платформи;
• систему управління доступами (IAM, ролі, привілейовані облікові записи);
• архітектуру SaaS-платформи та REST API-інтеграції;
• систему логування та моніторингу безпекових подій;
• політики інформаційної безпеки компанії;
• процедури реагування на інциденти;
• процеси управління ризиками;
• процеси управління змінами в ІТ-інфраструктурі.

Як наша команда побудувала роботу:

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

2. Аналіз прогалин відповідно до визначених критеріїв SOC 2. Кожен наявний контроль звірили з критеріями, зафіксували прогалини та класифікували їх за рівнем критичності. 

3. Робочі сесії з командою клієнта. Ми не просто видали список рекомендацій, а працювали разом із технічними та управлінськими командами клієнта – перетворювали розрізнені практики на єдині задокументовані процеси.

4. Формалізація процесів і контролів. Ми регламентували та вдосконалили:

• повний набір політик інформаційної безпеки під визначені для проєкту критерії SOC 2;
• формалізований процес управління доступами, включно з регулярним переглядом прав і контролем привілейованих облікових записів;
• процес управління змінами (Change Management Process) – контрольоване внесення змін в ІТ-інфраструктуру;
• розширену систему логування та моніторингу безпекових подій;
• регулярний цикл оцінки ризиків інформаційної безпеки замість разових перевірок.

Розробка плану реагування на інциденти

Datami розробила для компанії план реагування на інциденти (Incident Response Plan). Цей документ визначає порядок дій у разі інциденту: від його виявлення та оцінки до усунення наслідків і відновлення роботи. Щоб команда могла діяти узгоджено, у плані закріплено ролі відповідальних, порядок ескалації та комунікації.

Результати оцінки готовності до SOC 2

Під час роботи над цим проєктом команда Datami виявила 16 прогалин у контролях безпеки:

• 3 критичні (зокрема управління привілейованими доступами та відсутність формалізованого реагування на інциденти); 
• 6 середніх (логування подій і контроль доступів);
• 7 низьких (документація політик і процесів управління змінами).

Три прогалини були класифіковані як критичні на рівні контролів – вони вимагали пріоритетного усунення до проходження аудиту. Основні прогалини клієнт закрив у межах узгодженого плану підготовки до аудиту.

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

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

Завдяки цьому проєкту SaaS-компанія отримала такі бізнес-результати:

• досягла готовності до аудиту SOC 2 Type I;
• відкрила шлях до отримання контрактів з великими корпоративними клієнтами у США;
• знизила ризик репутаційних і юридичних наслідків через витік корпоративних даних клієнтів.

Що далі: рекомендації після оцінки відповідності SOC 2

За результатами оцінки клієнт отримав рекомендації щодо наступних кроків: 

• регулярні внутрішні аудити контролів SOC 2;
• автоматизація моніторингу подій та управління логами;
• періодичні пентести та оцінки безпеки;
• програма навчання співробітників з кібербезпеки;
• підготовка до проходження аудитів SOC 2 Type I та SOC 2 Type II (Type II вимагає доводити ефективність контролів не в моменті, а протягом часу).

Від оцінки готовності до чіткого плану дій

Для SaaS-компанії вихід на корпоративний ринок США вимагав готовності підтвердити відповідність вимогам SOC 2 за допомогою незалежного аудиту.

За 10 тижнів Datami оцінила наявні контролі. Ми виявили 16 прогалин і розробили документацію з безпеки, зокрема, план реагування на інциденти. SaaS-компанія отримала рекомендації щодо усунення виявлених проблем, а після впровадження клієнтом контролів було підтверджено готовність до аудиту SOC 2 Type I.

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

Готуєтеся до комплаєнс-аудиту і не знаєте, з чого почати? 

Зверніться до Datami – ми проведемо перевірку безпеки ваших цифрових ресурсів і визначимо готовність компанії до аудитів відповідності. Підкажемо, які прогалини потрібно закрити в першу чергу.