SOC 2 сертифікація: як впоратися та досягти успіху?

Кожен SaaS-провайдер, перш ніж інтегруватися у великий або середній бізнес, проходить процес перевірки.

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

Weblab Technology отримав власний досвід роботи із сертифікацією SOC 2 під час співпраці з Shaman BV.

Чому не ISO 27001?

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

Ще один важливий момент: SOC розділено на SOC 1, SOC 2 та SOC 3. Перший стосується винятково контролю фінансів, а третій використовують переважно для маркетингових цілей, тож SaaS-провайдери можуть сфокусуватися лише на SOC 2.

Критерії довіри

Під час сертифікації SOC 2 компанію оцінюють за категоріями довіри. Отже, які критерії формують фінальний висновок?

  • Безпека (security). Системи та інформація, що зберігаються, повинні бути захищеними від неавторизованого доступу та оприлюднення.
  • Доступність (availability). Інформація та продукт мають бути готовими до використання і виконати своє призначення тоді, коли це потрібно клієнту.
  • Конфіденційність (confidentiality). Непублічна інформація повинна бути надійно захищена.
  • Цілісність обробки (processing integrity). Система оброблення інформації має бути повною, дійсною, точною, своєчасною та авторизованою, а дані клієнта — залишатися коректними протягом усього періоду роботи. Іншими словами, система повинна чітко виконувати своє завдання.
  • Приватність (privacy). Збирання, використання, збереження, розкриття та видалення особистої інформації слід здійснювати відповідно до заздалегідь установлених правил.

SOC 2 Технічні характеристики

Важливо розуміти, що SOC 2 — це не тільки про безпеку. Дані, якими керують SaaS-провайдери, можуть бути критичними для бізнесу загалом, адже навіть короткочасний збій у роботі може призвести до значних фінансових чи репутаційних втрат — серйозність проблеми залежить від специфіки конкретного випадку. Ось чому необхідно переконатися, що SaaS-провайдер використовує найкращі методи роботи.

Процес SOC 2 містить такі ключові пункти.

  • Щоквартальне сканування вразливостей всіх внутрішніх систем. SOC 2 відстежує всі вразливості критичного та високого рівня до моменту, коли вони будуть виправлені.
  • Використання інструментів управління журналами подій (log management) для виявлення випадків, які потенційно можуть вплинути на безпеку.
  • Тестування компанії на зовнішні втручання (penetration testing) виконується принаймні щороку. Розробляється план із відновлення, а зміни для усунення вразливостей впроваджуються відповідно до SLA.

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

SOC 2 Тип 1 & 2

SOC 2 представлений у Типах 1 та 2.

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

Тип 2 показує, як системи контролю працюють протягом певного часу: зазвичай від 6 до 12 місяців після Типу 1. Протягом цього періоду аудитор перевіряє контрольні пункти та вразливості й проблеми моніторингу, що виникають, а також відтворює їхню хронологію.

Системи моніторингу можуть сигналізувати про проблеми та вразливості. Це нормально, але якщо вони існували протягом значного часу, то аудитор може запропонувати розширити період аналізу на додаткові 6–12 місяців. Отже, у процесі сертифікації важливі послідовність та відповідальність.

SOC 2 — це не тільки технічні моменти

Менеджмент:

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

Рада директорів:

  • демонструє незалежність від менеджменту;
  • разом із менеджментом встановлює структури та порядок підпорядкування.

HR:

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

Список принципів неповний, проте ці пункти зводяться до більш численних та конкретних ключових точок.

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

Ви повинні переконатися, що зміни та контроль — це не просто пусті балачки.

Ми мали впровадити десятки політик, покращили архітектуру і представили численні моніторингові рішення, такі як Trendmicro Conformity, Wazuh, Sentry і DataDog.

Продукт побудований переважно на AWS, тому ми використовували ще й досить багато їхніх інструментів для покращення систем логування, моніторингу, доступності тощо. Наприклад, AWS Inspector, AWS WAF, AWS KMS, AWS Secrets Manager, AWS CloudTrail. До речі, ми вважаємо, що хороший початок — це AWS Well-Architected Framework, навіть якщо ви ще не потребуєте SOC 2. Операційна досконалість, безпека, надійність і стійкість цього рішення значною мірою збігаються з тим, що очікують від SOC 2.

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

І все ж таки яким має бути план дій?

Як і в багатьох інших сферах, вам потрібні команда, підхід і процес.

  1. Найміть кваліфіковану команду R&D з DevOps та SysOps. Необхідно виділити підгрупу з чітким лідерством, яка відповідатиме за підготовку до SOC 2.
  2. Знайдіть консультанта з безпеки. Найкраще вибирати зовнішнього консультанта або компанію, адже SaaS-компанії рідко потребують штатного спеціаліста з безпеки.
  3. Чітко окресліть терміни. Виділіть 6–12 місяців для сертифікації Типу 1 та стільки ж часу для Типу 2.
  4. Починайте роботу заздалегідь, особливо з документацією, політиками та архітектурними змінами.
  5. Завчасно замовте Penetration Testing.
  6. Інтегруйте фреймворки та інструменти моніторингу.

Як вибрати аудитора?

SOC-аудитори — це незалежні сертифіковані консультанти (CPA). Вони оцінюють та складають звіт про засоби контролю в організації, що обслуговується. Варто поглянути на Sensiba San Filippo (саме з ними співпрацювали ми), Seiler, Hood & Strong.

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

  1. Комунікація. Під час вибору аудитора варто провести особисту зустріч. Навіть якщо кандидати є професіоналами, комунікація з деякими може бути комфортнішою.
  2. Терміни. Деякі аудитори можуть бути недоступними у потрібний вам період часу.
  3. Вподобання клієнта. Якщо інтеграція базується на запиті, отриманому від замовника, він може мати власні очікування — переконайтеся, що здатні виконати їх.

Щасти!

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Альтернатива не сертифікованого продукту ну така собі. У нас це був В2В та щi максимально серйозні

Datadog шикарно зайшов після New Relic, особливо з огляду на скільки той став коштувати (а юзати потрібно вже не часто)

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

Плани планами, але скільки реально було витрачено часу в цьому випадку? Адже ми ж розуміємо як це буває) Як зрозумів, тут був задіяний Тип 2

Десь 10 місяців на тип 1, та 8 на тип 2

цікаво було б почитати також про досвід з ISO 27001 якщо був такий

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

Ми теж досить повільно йшли поки не додали Vanta та не додали ще одного DevOps в команду.
Часу цей процес забирає досить багато. Навіть після самої сертифікації щось постійно треба :)

Для клієнта це було питання довготермінового контракту, який дозволив подвоїти бізнес. Тому в R&D була мотивація і ресурсі. А якщо це не дуже треба, то навіщо і робити

Як щодо Apache Metron для комплексного моніторингу?

Ініціатива вибору Wazuh як основного SIEM йшла від консультанта з безбеки.
Не маю компетенції порівняти Wazuh та Apache Matron.
Але Wazuh досить добре свою задачу виконує. Досить проста установка агентів, зрозуміле налаштування імпорту з AWS. Логічний інтерфейс.

Зрозумів, справа була у вимогах з боку аудиторів — їхні стандарти, дякую!

Підписатись на коментарі