Подготовили гид по безопасной работе с персональными данными. Эксперты из Mindbox, «Яндекса», «Додо Пиццы», «Здравсити» и банка «Точка». Полезно, если руководите маркетингом, продажами или просто хотите разобраться в теме.
12 июля 2024
Утечки персональных данных. Почему они происходят и как обезопасить компанию
В 2023 году в интернет попало 1,12 млрд персональных данных, что почти на 60% больше, чем в 2022 году. Такие цифры приводятся в исследовании InfoWatch. Волнений бизнесу добавляет и подготовка законопроекта с оборотными штрафами за утечки персональных данных клиентов.
Вместе с head of legal и менеджером по информационной безопасности Mindbox подготовили подробный гид по информационной безопасности. Он будет полезен, если вы руководите маркетингом, продажами или просто соприкасаетесь с персональными данными и хотите разобраться, как работать с ними безопасно.
Своим опытом поделились эксперты по информационной безопасности и сотрудники «Яндекса», «Додо Пиццы», «Здравсити» и банка «Точка».
Содержание:
Кратко: как обезопасить клиентские данные — опыт Mindbox
Собрали ключевые мысли из материала, чтобы вы могли понять, релевантен ли вам опыт Mindbox и стоит ли прочитать статью целиком. Итак, для безопасности клиентских данных полезно:
- Разработать собственные требования к безопасности. За основу можно взять, например, международный стандарт по информационной безопасности ISO/IEC 27001.
- Внедрить модель угроз, чтобы иметь общее представление о потенциальных рисках. Модель угроз может выглядеть как список всех используемых сервисов с перечислением потенциальных сценариев атак.
- Провести внешний или внутренний аудит процессов, то есть проверить, что вы все учли: точно ли есть инструкция на экстренные случаи, ежеквартальные ревизии доступов, проверка поставщиков. При необходимости аудит можно дополнить сертификацией.
- Если утечка уже произошла, понять источник и «закрыть» его, провести расследование, оповестить Роскомнадзор и заинтересованных лиц, а также продумать дальнейшие действия, которые предотвратят повтор ситуации.
Персональные данные: что это такое с точки зрения закона
Понятие. Согласно федеральному закону № 152 «О персональных данных» персональные данные — это «любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных)». Операторами персональных данных являются все компании, хотя бы потому, что они нанимают сотрудников.
Закон трактуют по-разному. Например, некоторые компании не считают email-адреса персональными данными, потому что они могут быть неидентифицируемыми, например kokot@gmail.com. Мое мнение таково: если есть хоть какие-то сомнения, то лучше относить данные к персональным.
В Mindbox мы понимаем под персональными данными пользователей сайта фамилию, имя, отчество, email, телефон, должность, компанию, а также данные cookies, включая IP-адрес и местоположение.
Штрафы. Сейчас активно обсуждается законопроект, вводящий оборотные штрафы за утечки персональных данных. Штрафы уже повысили с 23 декабря 2023 года. Например, за обработку персональных данных без согласия клиента компанию оштрафуют на сумму от 300 до 700 тысяч рублей, при повторном нарушении — от миллиона до полутора.
Особые случаи. В законе выделены особые категории персональных данных, которые могут храниться только на серверах компании и требуют особой сертификации. К ним относится, в частности, банковская тайна.
Это не значит, что банки не могут использовать сторонние сервисы: ограничения распространяются только на конкретные данные. То есть отправлять массовые рассылки без персонализации через сторонний сервис можно, даже если это рассылки банка. А вот выделять сегмент на основании банковской тайны разрешено только на своей стороне — сторонний сервис допустимо использовать просто как шлюз для отправки.
Данные, составляющие банковскую тайну, по закону можно хранить только в собственном периметре. Теоретически часть клиентских данных банк может передать в облачный сервис. Но для этого нужно получить согласие клиентов, обезличить данные и исключить чувствительную информацию, в том числе номера счетов, карты и остатки на счетах.
В «Точке» мы отдаем предпочтение сервисам, которые можно развернуть внутри контура. Исключение — сервисы, которые сложно разработать самостоятельно и которые не требуют передачи клиентских данных. Например, сервисы для отправки коммуникаций. Транзакционные рассылки мы осуществляем самостоятельно, а для маркетинговых целей используем сторонний рассыльщик с интеграцией через API. Преимущество таких решений не только в том, что можно быстро сделать рассылку и собрать статистику, но и в удобной верстке. Благодаря этому не нужно нанимать специалиста по верстке, который собирает письма и проверяет их отображение на различных устройствах.
Почему происходят утечки данных: хакеры и инсайдеры
Глобально у утечек всего две причины: взлом и действия сотрудников. Основатель сервиса разведки утечек данных и мониторинга даркнета DLBI Ашот Оганесян утверждает, что до февраля 2022 года по вине сотрудников происходило 60% утечек, а после — только 30%. Причина такого резкого падения — в активизации хакеров.
Интересно, что в большинстве случаев хакеры не используют сложные схемы, а просто сканируют инфраструктуру компании на предмет общеизвестных, но не устраненных уязвимостей. Такие уязвимости могут возникнуть, если компания использует сервис, который перестал обновляться, в том числе из-за санкций, или в компании нет политики регулярного обновления ПО.
Российский разработчик средств безопасности «СёрчИнформ» приводит похожие данные о распределении причин утечек. Компания опросила 1124 эксперта и выяснила, что доля инцидентов с сотрудниками снижается.
Доля экспертов, которые сталкивались с утечками информации по вине сотрудников
По данным «СёрчИнформ»
Главная проблема с инсайдерами в том, что традиционно в России строят защиту от внешнего атакующего, а утечки происходят и по вине сотрудников. Бывает и комбинация факторов. Например, бывший сотрудник, у которого забыли отобрать права: он атакует снаружи, но по факту действует как инсайдер.
Интересно распределение виновных сотрудников.
Портрет нарушителя
По данным «СёрчИнформ». Опрашиваемые могли выбрать несколько вариантов ответов
Как понять, что данные клиентов в безопасности
На каком уровне безопасности находится компания
Когда мы в Mindbox разрабатывали требования к безопасности, то отталкивались от пожеланий наших клиентов. В результате наш фреймворк получился максимально похожим на международный стандарт по информационной безопасности ISO/IEC 27001, по которому мы в итоге успешно сертифицировались.
Ниже я выделил основные технические пункты, которые, по нашему мнению, характеризуют уровень информационной безопасности в компании. Каждый следующий уровень не исключает, а дополняет предыдущий. Список пунктов и способов защиты не конечный и зависит от внутренних процессов, инфраструктуры, бизнес-модели и защищаемой информации:
Базовый уровень
Средний уровень
Продвинутый уровень
Управление идентификацией и доступом
Есть многофакторная аутентификация
Запрещены простые пароли и общие учетные записи
Регулярно проводится аудит прав доступа
Доступы распределяются на основе ролей
Инфраструктура недоступна извне без авторизации
Запрещены простые пароли и общие учетные записи
Регулярно проводится аудит прав доступа
Доступы распределяются на основе ролей
Инфраструктура недоступна извне без авторизации
Доступы выдаются по принципу минимальных привилегий
Используется единая учетная запись для входа во все сервисы через single-sign-on
Используется единая учетная запись для входа во все сервисы через single-sign-on
Есть процесс управления привилегированными учетными записями: повышенные права выдаются временно и по согласованию с ИБ, действия с таких учетных записей логируются
Защита данных
Настроены резервное копирование критичных данных, мониторинг инфраструктуры на наличие лишних открытых портов
Развернут межсетевой экран (firewall)
Обеспечено шифрование данных, передаваемых по открытым сетям
Развернут межсетевой экран (firewall)
Обеспечено шифрование данных, передаваемых по открытым сетям
Обеспечено шифрование данных на всех этапах: во время передачи, в том числе по внутренним сетям, в состоянии покоя (хранении) и в резервных копиях
Используются механизмы WAF и (или) reverse-proxy, отбрасывающие потенциально опасные запросы извне
Настроена защита от DDoS-атак
Используются механизмы WAF и (или) reverse-proxy, отбрасывающие потенциально опасные запросы извне
Настроена защита от DDoS-атак
Настроены системы обнаружения и предотвращения вторжений (IDS/IPS)
Есть система предотвращения утечек (DLP)
Сотрудники не имеют доступа к данным — они замаскированы
Есть система предотвращения утечек (DLP)
Сотрудники не имеют доступа к данным — они замаскированы
Физическая и сетевая безопасность в офисе
Доступ в офис и серверные ограничен
Гостевой вайфай не дает доступа к инфраструктуре, вайфай запаролен
Гостевой вайфай не дает доступа к инфраструктуре, вайфай запаролен
Установлено видеонаблюдение
Подключение неавторизованных устройств к вайфаю или сетевым розеткам в офисе не дает доступа к инфраструктуре
Подключение неавторизованных устройств к вайфаю или сетевым розеткам в офисе не дает доступа к инфраструктуре
Подключение к сети офиса предоставляет только выход в интернет
Доступ к отдельным частям инфраструктуры настроен по принципам zero trust: запрашивается точечно и временно, логируется
Доступ к отдельным частям инфраструктуры настроен по принципам zero trust: запрашивается точечно и временно, логируется
Обучение сотрудников
Проводится ежегодное обучение и тестирование по безопасности
Обучение проводится на основе ролей
Проводятся учебные фишинговые атаки
Проводятся учебные фишинговые атаки
Предусмотрены персонализированные программы обучения
Внешние специалисты ИБ проводят контролируемые атаки на сотрудников и офисные помещения с применением социальной инженерии
Внешние специалисты ИБ проводят контролируемые атаки на сотрудников и офисные помещения с применением социальной инженерии
Аудит и мониторинг
Логи систем, в которых находятся критичные данные, хранятся централизованно
Время во всех системах синхронизировано
Время во всех системах синхронизировано
Для хранения и анализа логов используется продукт класса SIEM, настроены нотификации при возникновении нежелательных событий
Внедрен SOC: выделенные сотрудники ИБ или подрядчик круглосуточно в режиме реального времени анализируют проблемы, подсвеченные SIЕМ
Сотрудники также реагируют на аномалии, например в графиках сетевой активности
Сотрудники также реагируют на аномалии, например в графиках сетевой активности
Рабочие устройства
Вручную настраиваются базовые требования к устройствам, например политика блокировки экрана, установка антивируса или шифрование жесткого диска
Используется автоматизированное централизованное управление политиками безопасности на устройствах, например с помощью mobile device management
На устройствах используется средство класса endpoint protection platform: обнаруживает и предотвращает вторжения (HIDS или HIPS), отправляет логи с устройств в централизованное хранилище, анализирует угрозы и защищает от них
Контроль поставщиков
Поставщиков проверяют на соответствие требованиям безопасности: важно наличие сертификатов безопасности, репутация, открытость
Передаются логи с сервиса поставщика
Есть прямой контакт со службой ИБ поставщика
Внешняя инфраструктура поставщика включена в область сканирования на уязвимости
Есть прямой контакт со службой ИБ поставщика
Внешняя инфраструктура поставщика включена в область сканирования на уязвимости
ИБ управляется совместно: с поставщиком обмениваются экспертным опытом, вместе дорабатывают процессы и системы безопасности, моделируют угрозы, проводят тесты на проникновение в инфраструктуру поставщика
Управление конфигурациями серверного оборудования
Есть чек-листы для базовой настройки оборудования для инженеров, включая шифрование, блокировку неиспользуемых портов, включение логирования, смену паролей по умолчанию
Оборудование автоматически развертывается через скрипты
Проводится регулярный аудит конфигураций
Проводится регулярный аудит конфигураций
Оборудование управляется по принципу infrastructure-as-a-code: в коде прописываются конфигурации оборудования — система не позволяет изменить их вручную
Управление уязвимостями
Внешний периметр инфраструктуры сканируется на уязвимости
Внутренний периметр инфраструктуры сканируется на уязвимости
Внешние специалисты проводят ручные тесты на проникновение в инфраструктуру
Внешние специалисты проводят ручные тесты на проникновение в инфраструктуру
Проводится автоматический анализ кода на уязвимости
Выкладка нового кода или микросервисов блокируется, если обнаружены уязвимые компоненты
В компании работают специалисты по кибербезопасности, которые находят и устраняют уязвимости
Выкладка нового кода или микросервисов блокируется, если обнаружены уязвимые компоненты
В компании работают специалисты по кибербезопасности, которые находят и устраняют уязвимости
Управление инцидентами
Инциденты регистрируются и обрабатываются — предусмотрены в том числе разработка следующих шагов по предотвращению и уведомление клиентов, госорганов
Назначены ответственные, есть планы действий при типовых инцидентах, которые регулярно тестируются
Заранее выбран подрядчик для помощи с расследованием сложных инцидентов
Заранее выбран подрядчик для помощи с расследованием сложных инцидентов
Используются автоматизированные системы обнаружения и реагирования на инциденты (SOAR)
Непрерывность бизнеса и восстановление после сбоев
Разработаны и тестируются планы восстановления после сбоев (DRP) для критически важных систем
Настроен мониторинг доступности критических компонентов системы
Проводится резервное копирование критически важных компонентов системы
Настроен мониторинг доступности критических компонентов системы
Проводится резервное копирование критически важных компонентов системы
Есть планы по восстановлению или замене всех компонентов, в том числе вспомогательных, например мессенджеров, почты
Настроен мониторинг на наличие и целостность резервных копий
Есть внутренний и внешний SLA, покрытый мониторингом
Критичные компоненты системы, например базы данных, дублируются
Настроен мониторинг на наличие и целостность резервных копий
Есть внутренний и внешний SLA, покрытый мониторингом
Критичные компоненты системы, например базы данных, дублируются
Настроено автоматическое непрерывное резервное копирование и восстановление инфраструктуры и данных
Проводятся нагрузочные и хаос-тесты
Есть второй ЦОД, дублирующий основной
Проводятся нагрузочные и хаос-тесты
Есть второй ЦОД, дублирующий основной
Практики, которые легко отследить, приносят максимум пользы. Ниже приведу несколько примеров из опыта «Здравсити».
Политика в отношении пользователей. В ней привилегии и уровень доступа сотрудника определяются его ролью. Все прописывается в так называемых картах доступа — благодаря им техподдержка видит, у кого какие права в какой системе. С одной стороны, у сотрудников нет доступа к лишней информации, с другой — техподдержке легко управлять такими группами. Конкретные правила выдачи и удаления доступов указаны во внутренних регламентах.
Инфраструктура. На уровне доменов разделяем клиентские сервисы, например сайт, и внутренние — для разработки и маркетинга.
Во многих компаниях разделения нет просто потому, что нужно покупать дополнительный домен. В этом случае риск утечки очень высок: злоумышленники регулярно сканируют сервисы на предмет уязвимостей. Если они взломают сайт с публичными данными, ничего критичного не произойдет, но если на том же домене хранится еще и база клиентских данных, риски резко возрастают.
Культура информационной безопасности. Помимо регламентов и аудитов, крайне важна ответственность сотрудников. Информационная безопасность начинается с найма: вопросы на проверку софт-скилов помогут определить, насколько человек склонен к ответственному поведению или, наоборот, перекладыванию ответственности. Следите за мотивацией своих сотрудников: если человек прохладно относится к своим должностным обязанностям, то это неизбежно сказывается и на информационной безопасности.
Как проверить, что ощущение безопасности — не ложное
Даже полное соблюдение стандартов и требований федерального закона «О персональных данных» не гарантирует, что данные компании надежно защищены. Для дополнительной уверенности в их безопасности имеет смысл делать больше, чем требует закон.
Модель угроз
Позволяет оценить риски и их предполагаемые последствия. Федеральный закон требует разработать модель угроз по методологии ФСТЭК. Это верхнеуровневый подход — в дополнение к нему мы в Mindbox внедрили собственную методологию моделирования рисков. Она полезна для операционных целей: позволяет работать со сценариями атак как с задачами.
Наша операционная модель угроз выглядит как список всех сервисов, которыми мы пользуемся. Во-первых, это офисные программы, поддерживающие работу сотрудников: корпоративные мессенджеры, почта и так далее. Во-вторых, наш продукт — базы данных и вся инфраструктура в облаке и ЦОДе. По каждому сервису у нас есть отдельная вкладка, где перечислены все возможные сценарии атаки с детализацией — вплоть до того, какую кнопку может нажать нарушитель для реализации сценария атаки.
Для каждого риска учитываем четыре параметра:
- Урон.
- Влияние на конфиденциальность, то есть чувствительность информации, к которой может получить доступ злоумышленник.
- Влияние на целостность, то есть возможность изменения информации злоумышленником.
- Влияние на доступность, то есть возможность потери доступа к информации.
- Потенциал угрозы.
- Для внутренних нарушителей — количество и экспертиза сотрудников, которые могут реализовать сценарий.
- Для внешних нарушителей — предполагаемый уровень специальных знаний и навыков в области ИТ и (или) ИБ, необходимый для реализации сценария.
- Возможность применения навыков социальной инженерии.
- Возможность проведения продолжительной и ресурсоемкой атаки.
- Вероятность действия.
- Статистика инцидентов.
- Привлекательность цели.
- Сила текущих мер — то, что компания уже делает для снижения риска.
Для приоритизации защитных мер используем формулу:
Когда узнаем о новых сценариях в уже существующей инфраструктуре, сразу вносим их в модель угроз и пересматриваем ее раз в год или при появлении нового сервиса.
Модель нужно улучшать — это постоянный процесс. Чтобы быть в курсе новых рисков, сотруднику, контролирующему безопасность, критически важно общаться с коллегами, отвечающими за разные домены. Имеет смысл также время от времени нанимать внешних консультантов для проведения аудитов, в том числе технических.
Изначально «Додо Пицца» стала строить систему информационной безопасности, фокусируясь на возможных атаках на критические системы. Эта система выглядела как дерево, где мы описывали сценарии развития рисков и меры по их предотвращению или уменьшению последствий.
Постепенно доросли до того уровня, когда можем работать с угрозами и для остальных систем, а не только наиболее критичных. Сейчас ведем подробный перечень всех информационных активов компании. В нем описываем, насколько чувствительная информация есть в том или ином сервисе.
Важно понимать степень угрозы и то, как цена защиты соотносится с потерями, которые компания может понести. Если потенциальные потери близки к нулю, смысла сильно вкладываться в защиту системы нет, если риски высокие — такой сервис стоит изучить под микроскопом.
Аудит процессов и сертификация
Различают внутренний, внешний и сертификационный аудит. Внутренний и внешний аудит — это формальная проверка, все ли вы учли: точно ли есть инструкция на экстренные случаи, ежеквартальные ревизии доступов, проверка поставщиков.
Четких критериев для прохождения внутреннего и внешнего аудита нет, все зависит от бизнес-потребностей. Внутренний и внешний аудит отличаются только тем, кто проверяет компанию и дает рекомендации: внутренний сотрудник или внешний консультант. Консалтинговых компаний в России довольно много, и хорошая идея — каждый год приглашать новую. Преимущество внешнего аудита — непредвзятость проверяющего.
В «Яндексе», помимо внешних аудитов, мы проводим и внутренние, на соответствие требованиям законодательства и нашим регламентам. Конечно, у нас настроены автоматические алерты, например при увольнении сотрудника приходят события и об увольнении, и о блокировке учетной записи. Поставка логов — это тоже сервис, и его доступность надо мониторить.
Замечу также, что контроль увольнения нельзя настраивать внутри самой кадровой системы. Это ненадежно, должен быть независимый внешний сервис. Если поставка логов кадровой системы сломается, то контроль, построенный внутри кадровой системы, может не заметить пропущенное увольнение. То же относится к сотрудникам: действие и контроль действия должны быть разделены. Сотрудник, ответственный за контроль блокировки учетных записей при увольнении, не может сам заниматься плановой блокировкой уволенных. Иначе возникнет конфликт интересов.
Сертификационный аудит — это проверка на соответствие какому-либо из фреймворков. Проверка проводится сертификационной компанией — при его выборе важно учитывать репутацию на рынке. Мы в качестве фреймворка выбрали ISO 27001, поэтому ниже будем рассказывать на его примере.
Аудиты по стандарту ISO 27001 обычно проводятся раз в год либо при существенных изменениях в инфраструктуре или процессах. При этом важна возможность выделить специалиста по информационной безопасности, который возьмет на себя подготовку к сертификации: приведет в порядок документацию и процессы, выступит заказчиком для внедрения недостающих технических мер.
Мы успешно прошли аудит и получили сертификат соответствия стандарту ISO 27001:2013 в 2022 году. Нарушений не нашли, но порекомендовали так называемые ВДУ — возможности для улучшения. Аудитор необязательно ориентируется на стандарты — может предложить что-то сверх них. Например, по ISO сотрудники должны раз в год проходить тест по безопасности. У нас он был единым для всех, как и требует стандарт. Аудитор предложил разделить его по ролям — отдельно для разработчиков, отдельно для менеджеров клиентского сервиса и так далее. Такие рекомендации повышают уровень информационной безопасности в компании, потому что учитывают особенности конкретного бизнеса.
В среднем подготовка к сертификации занимает год-полтора и требует ресурсов не только безопасника, но и почти всей компании — юристов, бухгалтерии, администрации, разработчиков. В нашем случае в подготовке к сертификации участвовала даже редакция: коллеги вычитывали правила безопасности и прочую документацию.
Главная проблема сертификации — невозможно оценить, помогла ли она защититься от утечек. Возможно, утечек не было бы и без нее. Нужно также иметь в виду, что получение сертификатов замедляет развитие бизнеса: больше процедур, больше согласований.
При этом подготовка к сертификации и аудиты очень полезны. Они помогают посмотреть на всю ИТ-систему и структурировать информацию о ней: кто с какими сервисами и данными работает, какие риски есть. За время подготовки у компании появляется сильная экспертиза в информационной безопасности. А внешний аудитор помогает еще раз взглянуть на процессы и перепроверить, все ли учтено.
Некоторые компании проходят весь путь подготовки к сертификации ISO 27001, но не идут на сам сертификационный аудит, потому что у них нет потребности в получении сертификата. Так тоже можно: бизнес получает все преимущества от сертификации, но не тратит лишние деньги.
Как действовать в случае утечки
Многие компании не осознают, что после драки кулаками не машут. Если не включено логирование, то успешность расследования будет стремиться к нулю: у вас просто не будет фактуры.
Важно также не затоптать следы: сразу отключить компьютер, через который произошла атака, чтобы сохранить артефакты для расследования. В противном случае злоумышленник успеет их удалить. Расследовать нужно по горячим следам: если логи хранятся три дня, то призывать даже самого крутого специалиста через неделю бессмысленно.
Наконец, должен быть план реагирования, причем с учетом затрат. Условно: если утечет некритичная информация, стоит ли тратить деньги на расследование или достаточно восстановить бэкап. Нужен ли вообще бэкап и резервная инфраструктура или бизнесу дешевле оплатить простой.
Другое дело, что часто к плану реагирования подходят формально. Например, бэкапы есть, но хранятся в том же сегменте сети, что и основная база. Тогда в случае атаки злоумышленник находит потенциально интересные документы и одновременно уничтожает бэкапы. Поэтому нужно досконально понимать, что произойдет в случае утечки, — подготовка плана сама по себе помогает оценить риски.
Алгоритм действий непосредственно в момент утечки можно свести к четырем основным пунктам:
- Понять источник утечки и «закрыть» его.
- В течение 24 часов после обнаружения утечки оповестить Роскомнадзор и заинтересованных лиц, в том числе клиентов.
- Провести расследование, возможно, с участием внешних консультантов.
- Продумать дальнейшие действия, которые предотвратят повтор ситуации.
Мы прописываем в клиентском договоре ответственность за утечки из сервиса Mindbox по нашей вине. К счастью, они ни разу не происходили, но теоретически мы готовы компенсировать реальный ущерб, например оплатить штраф Роскомнадзора или расходы клиента на внешних специалистов по информационной безопасности, которые минимизируют ущерб от утечки.
Открытость очень важна: совершенно нормально сказать, что вы выясняете причину утечки и дадите статус в течение нескольких часов. Главное — действительно дать его. Другое дело, что заявления должны быть последовательны и для этого лучше привлечь пиар. Нужно заранее определить, кто из сотрудников или топ-менеджмента может комментировать инцидент.
Хороший пример реакции на атаку показала логистическая компания Maersk. В 2017 году она была атакована шифровальщиком, и сотрудники компании в режиме реального времени рассказывали, что они выяснили и что предпринимают в этой связи. Такая реакция помогла другим компаниям минимизировать ущерб от эпидемии шифровальщика.
Нельзя забывать про требования регуляторов, в частности про необходимость уведомить об утечке персональных данных Роскомнадзор в течение 24 часов (в разных сферах, например банковской, могут быть дополнительные требования).