Миллионы людей ежедневно пользуются сервисами Яндекса и доверяют нам свои данные. Для нас это большая ответственность, поэтому мы делаем всё, чтобы обеспечить защиту и конфиденциальность информации. Чтобы эти слова не оставались просто обещаниями, мы регулярно проходим независимые аудиты систем информационной безопасности.
В апреле 2024 года на конференции Data Fusion мы подписали Отраслевой стандарт защиты данных вместе с другими ИТ‑компаниями. В течение года мы хотели пройти по нему аудит и подтвердить, что мы надёжно защищаем данные. И у нас всё получилось: ниже расскажу о том, как мы проходили проверку и какие результаты получили в итоге.
Статья будет особенно полезна специалистам в области информационной безопасности, которые занимаются или интересуются прохождением аудитов и тестирований.
Что такое Отраслевой стандарт
Наша и другие компании регулярно проходят сертификацию по международным системам ISO, AICPA, ISF и ежегодно получают разные сертификаты безопасности. За год мы проходим около 40 подобных независимых проверок. При этом у нас, как и у других российских ИТ‑компаний, есть много накопленного опыта и экспертизы в области стандартов безопасности, которыми мы хотели поделиться с индустрией. Так возникла идея зафиксировать эти знания на уровне отрасли — чтобы в России появился единый стандарт защиты данных. Это важно для развития отрасли и повышения общей защищённости.
В ноябре 2023 года компании, входящие в Ассоциацию больших данных, разработали концепцию единого отраслевого стандарта информационной безопасности, а в апреле 2024-го подписали документ. Стандарт не противоречит законодательным требованиям, а его соблюдение является добровольным. Итоговый текст Отраслевого стандарта размещён на сайте АБД.
Стандарт определяет критерии зрелости процессов информационной безопасности как для компании в целом, так и для отдельных её систем. Процессный подход позволяет не только зафиксировать текущее состояние ИБ, но и показать, что компания системно работает над защитой данных в долгосрочной перспективе. Это не разовая проверка на соответствие требованиям, а учёт всего жизненного цикла информационной безопасности.
Кроме того, стандарт адаптирован к разным методологиям управления, органично сочетаясь не только с классическим Waterfall, но и с гибкими подходами вроде Agile.
Зачем нам нужны проверки
Мы уверены: за добровольной сертификацией будущее. Особенно если компания стремится создавать что‑то масштабное, технологичное и хочет укрепить доверие к защищённости её сервисов.
А ещё мы немного идеалисты: верим, что своим примером можем поднять общий уровень информационной безопасности в стране, — это наша важная миссия. Поэтому вместе с коллегами из других ИТ‑компаний на площадке АБД разработали стандарт, который позволяет не только оценить процессы ИБ, но и понять, куда двигаться дальше для их развития.
Как мы проходили аудит по отраслевому стандарту
Мы определились с тем, на соответствие каким стандартам хотим проверить наши процессы. Но Яндекс — это большая экосистема с более чем 90 сервисами, и сразу охватить всё просто невозможно. Мы решили запустить пилотный проект с одним из наших сервисов.
С одной стороны, пилот — это быстрый способ проверки. Но с другой — важно, чтобы он был действительно полезным. Поэтому мы выбрали в качестве объекта оценки Яндекс ID. Этот сервис играет ключевую роль: он объединяет все наши сервисы, а также хранит пользовательские данные и управляет ими. Проверив его, мы сможем оценить, насколько зрелы наши процессы информационной безопасности в целом.
Этапы подготовки
Первым шагом стал GAP‑анализ. Раньше для него мы привлекали консалтинговые компании, но сейчас накопили достаточно экспертизы, чтобы проводить такие проверки самостоятельно, даже для новых стандартов. Это позволяет нам не только быстрее выявлять пробелы, но и гибко адаптироваться к новым требованиям, улучшая процессы информационной безопасности.
В результате мы получили:
матрицу критериев стандарта;
описание процесса, как реализуется этот критерий у нас внутри;
документ, в котором закреплён процесс;
свидетельства стабильной работы процесса.
Пример того, что мы описываем в матрице:
Что мы получили по итогам GAP‑анализа:
В Яндексе есть чётко прописанная политика управления уязвимостями. Она актуальна на дату аудита, регулярно пересматривается и определяет ответственных за выявление, оценку и устранение уязвимостей. У нас даже есть отдельное подразделение, которое этим занимается.
Мы используем сканеры уязвимостей — они работают, настроены корректно, а их документация хранится в базе знаний. У каждого сканера есть владелец, и они еженедельно сканируют инфраструктуру в соответствии с политикой. За их работой следят мониторинги, а результаты сканирований автоматически превращаются в тикеты для ответственных сотрудников.
Дальше вступает в силу чёткий процесс: приоритизация, оценка рисков, устранение уязвимостей. Причём этот процесс связан с управлением обновлениями и программой Bug Bounty.
Для каждого из этих действий у нас есть подтверждения: политика, тикеты, роли управления сканерами в IDM, отчёты, мониторинги, дашборды и, конечно, логи.
Всё это мы собираем в матрицу и показываем аудитору.
Методика прохождения проверки
Чтобы оценить соответствие стандарту, сначала нужно понять, как именно проводить по нему проверку. Это стало одной из наших ключевых задач. Мы задумались о методике оценки ещё на этапе подготовки к аудиту.
Наша цель была в том, чтобы создать понятный инструмент, который не только объяснит, что именно нужно проверять, но и поможет провести аудит максимально объективно. Поскольку раньше мы не проводили аудит самостоятельно, то обратились за помощью к экспертам из компании с большим опытом в проверке соответствия различным стандартам. Мы попросили их разработать первый драфт методики оценки.
В итоге получилась методика, которая подробно описывает весь процесс оценки: этапы, категории компаний, возможные свидетельства, критерии и метрики. Методика универсальна и подходит как крупным, так и небольшим компаниям, у которых есть функция информационной безопасности.
Сейчас методика доступна на сайте АБД. В ней детально прописаны все этапы и роли участников оценки. Для каждого критерия есть разъяснения, примеры реализации в разных компаниях и варианты подтверждения выполнения. Это помогает исключить разночтения и сделать процесс проверки прозрачным и понятным.
Пример, как оценить компанию по одному из критериев:
1.6. Моделирование угроз безопасности информации
Недопустимый частный показатель для категорий 1, 2, 3, 4.
Целевое значение — уточнение процесса моделирования угроз ИБ для ИСПДн и поддержания актуальности такой модели.
Исходными данными могут быть:
организационные и распорядительные документы, регламентирующие моделирование угроз ИБ для ИСПДн;
совокупность отлаженных процессов и инструментов регламентации в данной области (рекомендации руководства, маршрутные карты процессов).
Примеры ожидаемых свидетельств внедрения:
модель угроз ИБ для ИСПДн;
техническое задание на анализ защищённости ИСПДн;
тикет или постановка задачи в почте на анализ защищённости (должно быть подтверждено, что анализ базируется на модели угроз ИБ для ИСПДн);
свидетельства, подтверждающие доведение информации об угрозах ИБ до заинтересованных лиц;
свидетельства, подтверждающие регулярный пересмотр модели угроз для ИСПДн.
Про баллы
Стандарт основан на балльной системе. Количество набранных по каждому критерию баллов зависит от уровня зрелости процесса или значения метрики.
Всего в стандарте описаны семь критериев по организации управления защитой информации, 12 критериев по реализации процессов защиты информации и 10 метрик. Максимальный балл, который можно набрать, — 29.
Проходной балл зависит от объёма данных, обрабатываемых в информационной системе персональных данных.
4-й уровень защищённости и < 100 000 записей — 6 баллов;
3-й уровень защищённости и > 100 000 записей — 10 баллов;
2-й уровень защищённости и спецкатегории — 14 баллов;
> 500 000 записей — 18 баллов.
Посмотрим на нашем примере. Яндекс ID попадает в самую высокую категорию — 4-ю, потому что обрабатывает более 500 000 записей пользователей. То есть нам надо было набрать 18 баллов из 29.
Оцениваем, как у нас выполняется критерий по управлению обновлениями безопасности. У него такая разбивка по баллам:
0 — управление обновлениями безопасности не осуществляется.
0,3 — правила установки обновлений регламентированы (в руководстве, политике, инструкции и др.).
0,5 — правила установки обновлений регламентированы (в руководстве, политике, инструкции и др.). Определены лица, ответственные за установку обновлений.
1 — правила установки обновлений регламентированы (в руководстве, политике, инструкции и др.). Определены лица, ответственные за установку обновлений. Реализовано тестирование обновлений.
В Яндекс ID действует чёткий регламент обновления безопасности: уязвимости оперативно обрабатываются выделенной командой, а все новые функции проходят тщательное тестирование перед выпуском в прод. Благодаря этому по данному критерию мы получили максимальную оценку — 1 балл.
Недопустимый частный показатель
Без локомотива состав не поедет — так и в информационной безопасности: без базовых процессов система не будет работать эффективно. Именно поэтому в стандарте существует понятие «недопустимый частный показатель». Это те критерии, которые должны выполняться без исключений, — их значение всегда должно быть больше нуля.
Например, компаниям с объёмом записей менее 100 000 отчёт не выдаётся, если:
функция по организации защиты не возложена на руководителя организации или одного из его заместителей;
не разработано положение об организации защиты информации;
нет планирования мероприятий по защите информации;
не проводится моделирование угроз безопасности информации;
не реализовано управление обновлениями безопасности;
не регламентировано управление учётными данными;
не определены негативные последствия;
не реализовано управление учётными записями;
не проводится работа по выявлению и оценке уязвимостей.
Если по какому‑то из критериев компания набирает 0 баллов, проверка не пройдена.
Соответственно, чем больше данных обрабатывает компания, тем больше базовых критериев она должна выполнять. Для компании 1-го уровня это девять критериев, для 2-го — одиннадцать, для 3-го — пятнадцать, для 4-го — восемнадцать.
Внутренняя и внешняя оценка
Как уже упоминалось выше, в среднем за год мы проходим около 40 комплексных аудитов, и понимаем, насколько это ресурсоёмкий процесс. Чтобы сократить время и оптимизировать наши ресурсы, мы концептуально делим процесс оценки на два этапа: внутренний и внешний. На первом этапе независимое подразделение, например внутренний аудит, проводит тщательную проверку реализации каждого критерия. На втором этапе внешняя аудиторская компания валидирует результаты внутренней проверки, чтобы убедиться, что всё было выполнено с должным качеством.
Скажем честно: для первого раза мы наняли внешних аудиторов для проведения внешней и внутренней оценки. Причина проста: это было быстрее согласовать, и не нужно было вставать в очередь за ресурсами команды аудита. Проверок в параллели проходит много, поэтому ожидание могло растянуться на пару месяцев — мы хотели применить Отраслевой стандарт как можно раньше. Но теперь мы планируем проводить оценку своими силами.
Подготовка и GAP‑анализ заняли у нас месяц. Внутренняя и внешняя оценка тоже заняла месяц. Всё происходило по такому графику:
Два дня на интервью по восемь часов. Мы приходили к ключевым сотрудникам, которые отвечают за организацию хранения и защиты данных, — задавали им важные вопросы и фиксировали ответы.
Две недели на сбор свидетельств. Те, кто проходит аудиты, понимают, что это не просто один документ. Тут нужно пройти несколько итераций и отправить не один дополнительный запрос, чтобы аудитор точно понял, как устроен процесс и какие есть свидетельства.
Две недели на подготовку отчёта. Здесь весь процесс был на стороне аудитора.
В итоге мы получили два отчёта. Подробный внутренний — что проверялось, какие документы были представлены, какие свидетельства подтверждают выполнение критерия и набранный балл. И короткий внешний отчёт — две страницы с описанием, кто и что проверял и к каким выводам пришли. По пилотному аудиту мы набрали 27,5 балла.
Итоговые впечатления и польза
Говоря о стандарте в целом, мы видим реальную пользу в добровольной сертификации. Она позволяет любой компании значительно повысить доверие как со стороны рынка, так и со стороны клиентов. И чтобы не быть голословными, мы готовы продемонстрировать наш отчёт об оценке как альтернативу отчёту о выполнении требований ПП № 1119.
По итогам хочется отметить ключевые моменты, которые помогут компаниям и сотрудникам ИБ в процедуре оценки:
Выбирайте скоуп оценки с точки зрения пользы для ваших клиентов. Стандарт нацелен на защиту данных, и в первую очередь — персональных. Если сложно провести оценку по всем системам сразу, выберите в первую очередь системы обработки персональных данных.
Хорошая подготовка — залог простого и быстрого аудита, а значит, и уменьшения стоимости затраченных ресурсов.
Выбирайте опытных аудиторов, которые понимают принципы построения вашей инфраструктуры, — это значительно упростит вам процесс оценки.
