Спустя два-три месяца после успешного прохождения аудитов по безопасности финансовых операций PCI DSS и ГОСТ 57580 мне пришло письмо… В нем был список из 195 плановых задач. Мы в процессе прохождения оценок соответствия уже собирали документы, отвечали на вопросы аудиторов и получили необходимые подтверждения соответствия. Казалось бы, можно выдохнуть и вернуться к обычной работе. Но список из 195 мероприятий напомнил о простой вещи: аудит заканчивается, а требования остаются.

Доступы нужно пересматривать, документы — обновлять, сотрудников — обучать, изменения — контролировать, уязвимости — проверять. У каждого мероприятия есть срок, ответственный и набор подтверждений. Если вспоминать обо всем этом только перед следующей проверкой, подготовка снова превращается в аврал.

Для небольшой информационной системы такой процесс еще можно вести в таблицах и календарях. Но когда речь идет об облачной платформе с десятками продуктов и команд, ручное управление быстро перестает работать.

Масштаб оценки Cloud.ru Evolution: более 40 продуктов, 60 продуктовых команд, около 600 мер защиты и 195 плановых задач по итогам успешного аудита.

Почему требования клиентов становятся задачей облачного провайдера

Cloud.ru не является финансовой организацией и не находится под надзором Банка России в том же качестве, что и банки. Но многие наши клиенты работают в регулируемых отраслях и должны подтверждать защищенность своей инфраструктуры.

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

Поэтому соответствие требованиям информационной безопасности для облачного провайдера перестало быть формальностью. Это условие работы с крупными клиентами и выхода в регулируемые сегменты.

Облачная платформа Cloud.ru Evolution при этом представляет собой не коробочное решение, развернутое на собственных мощностях, а платформу собственной разработки. Она включает в себя более 60 IaaS- и PaaS-сервисов. Как следствие в область оценок Cloud.ru Evolution Public по PCI DSS и ГОСТ 57580 (усиленный уровень) вошли около 40 продуктов, более 60 команд и три зоны доступности.

Готового комплекта документов для такой платформы не существует. Нужно предоставить для органа по аттестации / для аудитора архитектуру собственного решения, определить границы систем, распределить ответственность и доказать, что меры защиты работают не только на бумаге.

Чем больше документов компания создает самостоятельно, тем меньше у нее готовых ответов для аудитора.

600 мер защиты идва разных языка

Только в рамках оценки ГОСТ 57580 (усиленный уровень) и PCI DSS мы получили от аттестаторов перечень примерно из 600 мер защиты.

Одно требование стандарта может превратиться в несколько внутренних задач: от технической настройки до сбора подтверждающих свидетельств

Для аудитора это привычный документ: есть формулировка требования, область его применения и ожидаемые свидетельства. Для разработчика, который отвечает за архитектуру, релизы и доступность сервиса, такой запрос может выглядеть как текст на другом языке.

Фраза «предоставить свидетельство выполнения меры» сама по себе почти ничего не объясняет. Ее нужно превратить в конкретную техническую задачу: показать настройку, выгрузку, журнал событий, тикет, регламент, результат сканирования или подтверждение пересмотра прав доступа.

Затем приходится делать обратный перевод и объяснять аудитору, какое требование закрывает полученный материал, к какому продукту он относится и почему может считаться достаточным подтверждением. В этот момент руководитель проекта становится связующим звеном между аудиторами, информационной безопасностью и разработкой.

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

Например, механизмы защиты от несанкционированного доступа на портальной части платформы декомпозируются на задачи для нескольких команд, отвечающих за портал, IAM, систему логирования и т.д.

При 40 продуктах и более чем 60 командах значительная часть времени начинает уходить не на устранение проблем безопасности, а на поиск ответственных, документов и уже существующих ответов.

Почему еще одна таблица не решает проблему

Сначала кажется, что достаточно создать большую таблицу: перечислить требования, ответственных, сроки и ссылки на документы. Затем появляются новые продукты, зоны доступности, стандарты и периодические мероприятия. Информация постепенно расходится по почте, файловым хранилищам, таск-трекерам и локальным документам.

Перед следующей проверкой повторяются одни и те же вопросы:

• Кто сейчас отвечает за эту меру?
• Где находится актуальная версия документа?
• Подходит ли уже собранное свидетельство для другого стандарта?
• Когда нужно повторить мероприятие?

Можно создать отдельное подразделение, которое будет вручную сопровождать оценки, отслеживать сроки и собирать материалы. Но для облачного провайдера постоянное расширение штата под каждую новую проверку не всегда рационально. Особенно если значительная часть работы заключается в переносе информации между системами и повторной постановке одинаковых задач.

Нам нужно было не больше людей, нужен был другой способ управления процессом.

Аттестат получен, работа продолжается

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

После аудита остаются периодические мероприятия: пересмотр прав доступа, обучение сотрудников, контроль изменений, актуализация документов, анализ уязвимостей и тестирование процедур.

Дополнительную сложность создает пересечение стандартов. Одно свидетельство может подтверждать выполнение нескольких требований, но только если компания видит эту связь и может ее обосновать.

При ручном подходе технические команды получают похожие запросы несколько раз. Сначала данные нужны для PCI DSS, затем сопоставимую информацию запрашивают для ГОСТ 57580, а через несколько месяцев к ней возвращаются в рамках планового мероприятия либо внутреннего аудита.

Для разработчиков это выглядит как повторение уже выполненной работы. Для руководителя проекта — как постоянное восстановление информации, которую компания когда-то уже собирала.

Как Compliance App связала требования с реальной работой

Для управления процессом соответствия требованиям мы начали использовать Compliance App, SGRC-платформу компании Compliance Control.

Сначала решение установили в тестовом режиме. Мы выбрали применимые стандарты, но не успели сразу полноценно наполнить систему: основные ресурсы были направлены на завершение текущих проверок.

Аудиты прошли успешно. Спустя несколько месяцев система сформировала те самые 195 плановых задач по PCI DSS и ГОСТ 57580. Тогда стало понятно, для чего нужна SGRC-платформа.

После успешного аудита Compliance App сформировала 195 плановых задач по PCI DSS и ГОСТ 57580: периодические мероприятия появляются в работе заранее и могут быть включены в планы команд

Не для того чтобы создать еще одно хранилище документов и не для того чтобы заменить экспертов, разработчиков или аудиторов. Ее задача — связать в одной системе то, что при ручном подходе находится в разных местах:

требование → мероприятие → ответственный → срок → задача → свидетельство.

Если мероприятие необходимо проводить раз в квартал или раз в год, система напоминает о нем заранее. Если требуется участие конкретного подразделения, задача передается в используемый таск-трекер. Если свидетельство уже собрано и подходит для нескольких требований, его можно не запрашивать у команды повторно.

Руководитель проекта видит не просто список документов, а состояние процесса: какие требования применимы, что уже выполнено, где приближается срок, кто отвечает за задачу и какие подтверждения собраны.

В одной карточке Compliance App связаны требование стандарта, конкретная задача, срок выполнения и ответственный. Команде и аудитору доступен единый контекст выполнения требования

Что изменилось в работе команды

Первое изменение коснулось периодических мероприятий. Они перестали возникать внезапно перед следующей проверкой. Система показывает будущие задачи заранее, поэтому их можно включать в рабочие планы команд.

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

Третье — появились единая точка хранения материалов и истории выполнения требований. Процесс меньше зависит от переписок, локальных таблиц и знаний отдельных сотрудников.

Четвертое — автоматизировалась постановка задач внутренним командам. Руководителю проекта не нужно вручную создавать каждое напоминание и отдельно контролировать все сроки.

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

Переход к управлению через Compliance App сократил количество повторных коммуникаций, централизовал свидетельства и позволил планировать работу между проверками без расширения штата

Не аудита ради, а работающий процесс

В корпоративной практике аудит часто воспринимается как неприятная проверка, к которой нужно подготовиться и которую хочется быстрее закончить. Отсюда — привычный сценарий: собрать документы, получить аттестат и вернуться к обычной работе.

Но аттестат показывает состояние компании только в конкретный момент. Реальная зрелость определяется тем, что происходит между проверками.

Пересматриваются ли доступы вовремя? Выполняются ли плановые мероприятия? Можно ли быстро найти актуальное свидетельство? Понимают ли команды, за какую часть процесса они отвечают?

Compliance App не выполняет требования вместо людей. Платформа помогает встроить их выполнение в обычную работу компании и не терять связь между стандартом, конкретной задачей и ее результатом.

Поэтому письмо со 195 задачами после успешного аудита оказалось неплохой новостью. Система заранее показала объем работы, который иначе пришлось бы восстанавливать вручную перед следующей проверкой.

Как не переложить стоимость соответствия на клиента

Для облачного провайдера управление соответствием связано не только с безопасностью, но и с экономикой продукта. Расширение штата, ручной сбор документов и постоянное отвлечение технических специалистов увеличивают себестоимость облачных сервисов. В конечном счете эти расходы могут отразиться на клиентах.

Использование Compliance App позволило Cloud.ru централизовать работу со свидетельствами, автоматизировать постановку задач и обойтись без расширения штата под отдельные комплаенс-процессы. При этом выполнение требований по подтверждению безопасности не повлияло на стоимость сервисов для клиентов.

Один аудит можно пройти как отдельный проект, но если у компании десятки продуктов, несколько зон доступности и более 60 команд, соответствием необходимо управлять постоянно.

В таком случае ценность SGRC-платформы определяется не количеством загруженных документов. Она проявляется в том, сколько повторной работы удается убрать, насколько реже приходится отвлекать технические команды и может ли компания поддерживать соответствие без нового аврала перед каждой проверкой.