Инциденты и уязвимости
Утечка данных Benesse (2014) — почему инсайдера не остановили, и защита через наименьшие привилегии
В 2014 году до ~35 млн записей клиентов похищены из Benesse инженером-подрядчиком дочерней компании и проданы брокерам. Инсайдер с законным доступом к базе использовал пробел в мониторинге: запись на USB блокировалась, а передача на смартфон — нет. Защита: минимизация привилегий, DLP и надзор за подрядчиками.
Мы читаем реальные, публичные утечки не как повтор новостей, а как «как от этого защититься?» Эта статья основана на публичном материале (заявления компании, регуляторы, авторитетные СМИ). Источники приведены в конце; нет ни инструкций по атаке, ни идентифицирующих деталей о каком-либо человеке.
- Цель
- Данные клиентов образовательного сервиса (имена, адреса, даты рождения, номера телефонов и т.д.)
- Обнаружено
- Июнь–июль 2014 (всплыло из-за рекламной почты других фирм, доходившей до клиентов; раскрыто 9 июля)
- Схема
- Злоупотребление инсайдера командированным инженером в дочерней компании-подрядчике: законный доступ к БД → массовое извлечение → передача на личный смартфон → продажа брокерам данных
- Масштаб
- До ~35 млн записей (одна из крупнейших утечек персональных данных в Японии на тот момент)
- Первопричина
- Избыточные привилегии у инсайдера + пробел в каналах утечки (USB заблокирован, но смартфон/MTP нет) + слабое обнаружение массового доступа + слабый надзор за подрядчиком / субподрядчиком
- Основные меры
- Наименьшие привилегии / need-to-know; DLP, закрывающий каждый канал утечки; обнаружение + аудит-логи массового доступа; управление и надзор за подрядчиками и субподрядчиками
Что произошло (простыми словами)
Большинство мер безопасности исходят из атаки извне. Но человек, который забрал данные здесь, был инсайдером с законно выданным доступом. Benesse передала эксплуатацию и обслуживание своей базы клиентов на аутсорсинг дочерней компании (подрядчику), и работавший там командированный системный инженер использовал выданный для работы доступ, чтобы массово извлечь данные клиентов.
Решающим пробелом стал канал утечки. Корпоративные меры против кражи данных нередко доходят до «блокировать запись на USB-накопители», но передачу на смартфон (метод под названием MTP) легко упустить. И здесь запись на USB блокировалась, однако передача на личный смартфон заблокирована не была. Извлечённые данные были проданы брокерам данных и разошлись дальше. Снаружи никто не взламывал. Законный доступ инсайдера совпал с каналом утечки, который никто не закрыл.
Защита от внешних атак не останавливает инсайдера
Межсетевые экраны и обнаружение вторжений нацелены на атаки извне. Инсайдер с законными привилегиями уже находится внутри, поэтому эти меры к нему не применяются. Злоупотребление инсайдера требует других мер: минимизировать привилегии, закрыть утечку на каждом канале, обнаруживать массовый доступ и распространить надзор на подрядчиков. «Мы доверяем этому человеку» — не повод не урезать привилегии.
Этапы атаки и как остановить каждый из них
Это была цепочка, где на каждом шаге было место, чтобы её остановить. Читайте её как где её можно было разорвать, а не как инструкцию.
1. Избыточные привилегии у инсайдера
Законный доступ доставал до гораздо большего объёма данных клиентов, чем требовалось.
Стоп: наименьшие привилегии / need-to-know; разделение обязанностей; периодический пересмотр доступа
2. Массовые данные вынесены на личное устройство
USB был заблокирован, но передача на смартфон (MTP) — нет.
Стоп: DLP, закрывающий каждый канал (USB / смартфон-MTP / облако / печать); обнаружение массовой выгрузки
3. Слабый надзор у подрядчика / субподрядчика
Эксплуатация была на аутсорсинге, поэтому надзор за реальной работой был тонким.
Стоп: видимость подрядчиков/субподрядчиков; договор + технические меры вместе; аудиты
4. Продано брокерам данных, разошлось дальше
Извлечённые данные были проданы и разошлись способами, которые трудно отследить.
Стоп: мониторинг логов и раннее обнаружение; сделать массовую утечку невозможной по замыслу
Опубликованная хронология
2014-06
Клиенты начинают получать прямую почтовую рекламу от других фирм; резко растёт число запросов с подозрением на утечку.2014-07-09
Benesse раскрывает утечку (первоначально описана как затронувшая, возможно, до ~20,7 млн записей).2014-07-17
Полиция Токио арестовывает командированного системного инженера в дочерней компании-подрядчике; по сообщениям, он признался в извлечении и продаже данных брокерам.2014-09-10
Утечка оценивается до ~35 млн записей. Benesse объявляет подарочные сертификаты (¥500) для пострадавших клиентов и план компенсации/профилактики порядка ~¥20 млрд.2014–2015
Руководство берёт на себя ответственность; METI выдаёт рекомендацию (kankoku) об улучшении. Дело становится одним из драйверов поправки к японскому закону о защите персональных данных (ужесточение правил для брокеров данных).2016
Бывший командированный работник осуждён (срок заключения и штраф).
Первопричина: не только один инсайдер, но и несколько отсутствующих защит
Списать это на «был плохой человек» — значит напроситься на повтор. На деле сразу несколько слоёв, призванных остановить злоупотребление инсайдера, были тонкими одновременно.
Конфигурация, которая не выдержала
- У сотрудника подрядчика был доступ, достающий до гораздо большего объёма данных, чем нужно
- Пробел в мерах против утечки (USB заблокирован, смартфон/MTP открыт)
- Слабое обнаружение/оповещение о массовом просмотре и выгрузке
- Надзор едва дотягивался до реальности подрядчика / субподрядчика
Конфигурация, которая держится
- Наименьшие привилегии / need-to-know ограничивают достижимые данные тем, что требуется
- DLP, закрывающий каждый канал (USB / смартфон / облако / печать)
- Обнаружение и оповещения о массовом доступе/выгрузке плюс аудит-логи
- Видимость и аудиты подрядчиков и субподрядчиков (договор + техника)
Затраты после инцидента намного превышают вложения в проектирование заранее
Benesse компенсировала пострадавшим клиентам (сертификаты; резерв порядка ~¥20 млрд), руководство взяло на себя ответственность, а регуляторы выдали предписания. Дело также помогло продвинуть поправку к японскому закону о защите данных. Стоимость утраченного доверия, компенсаций и реакции регуляторов намного превышает вложения на входе в урезание привилегий и закрытие каналов. Проектируйте внутренний контроль под объём персональных данных, которым вы владеете, — до инцидента, а не после.
Как вы от этого защищаетесь
Как бы хорошо вы ни укрепились против внешних атак, эти меры не остановят законного инсайдера. В порядке приоритета и в любом масштабе:
Минимизируйте привилегии (наименьшие привилегии / need-to-know)
Включая операторов и подрядчиков, ограничьте доступ к продакшен-данным минимумом, который требует работа. Спроектируйте авторизацию (кто к чему может обращаться) и применяйте принцип наименьших привилегий к ключам и учётным записям в целом. Пересматривайте привилегии периодически.
Закройте каждый канал утечки (DLP)
Не только USB-накопители — проведите инвентаризацию и закройте также передачу на смартфон (MTP), загрузку в облако, вложения в письма и печать. Не довольствуйтесь «мы заблокировали USB». Оставьте открытым хоть один канал — и данные уйдут через него.
Обнаруживайте массовый доступ и массовую утечку
Отмечайте «один человек за короткое время просмотрел/выгрузил большой объём данных клиентов» и умейте оповещать, требовать одобрения или приостанавливать. Ведите аудит-логи того, кто, сколько и когда получал доступ. Даже если вы не можете это предотвратить, сокращение времени до обнаружения уменьшает потери.
Распространите надзор на подрядчиков и субподрядчиков
Аутсорсинг — не передача ответственности. Понимайте объём и реальность субподряда и управляйте им и договором (конфиденциальность, право на аудит), и технологиями (привилегии, DLP, логи). Применяйте свою базовую безопасность для организаций и к подрядчикам.
Где это пересекается с тем, как построен этот сайт
По сути этот инцидент позволил законному инсайдеру дотянуться до большего объёма данных, чем нужно, через забытый канал утечки. Это противоположность собственным принципам этого сайта: наименьшие привилегии, ограничение того, насколько далеко распространится ущерб при взломе одной части, и защита из предположения, что каждый канал существует. Защищайтесь только от внешних атак, пренебрегая контролем доступа и внутренней утечкой, — и появится тот же пробел. «Урезать привилегии, закрыть каждый канал, обнаруживать массовый доступ и дотягиваться до подрядчиков» — это защита, которую любой может реализовать в любом масштабе.
Источники (публичный материал)
Факты здесь основаны на следующей публичной информации. Нет ни инструкций по атаке, ни идентифицирующих деталей о каком-либо человеке — только уроки для защиты.
- Официальные заявления Benesse Holdings / Benesse Corporation (уведомления об утечке персональных данных / центр поддержки клиентов, 2014–) — benesse.co.jp
- Японское METI, раскрытия о реагировании на защиту персональных данных (2014) — meti.go.jp
- Комиссия по защите персональной информации (и предшествующие органы), материалы и дискуссия о поправке к закону о защите (2014–2015) — ppc.go.jp
Читать дальше
- Практика: Базовая безопасность для средних и крупных организаций (базовые меры для команды; применяйте их и к подрядчикам)
- Практика: Наименьшие привилегии SSH-ключа (принцип наименьших привилегий на практике) · Аутентификация и авторизация
- Глоссарий: Что такое IDOR (нарушение контроля доступа — чтение данных сверх ваших привилегий)
FAQ
QКакова была первопричина инцидента Benesse?
Не внешняя атака, а инсайдер. Командированный системный инженер в дочерней компании-подрядчике использовал законно выданный доступ к базе, чтобы массово скопировать данные клиентов. Программа мониторинга блокировала запись на USB-накопители, но не блокировала передачу на личный смартфон (MTP). Сошлись вместе избыточные привилегии, пробел в каналах утечки и слабый надзор за подрядчиком / субподрядчиком.
QЕсли я защищаюсь от внешних атак, я в безопасности?
Нет. Это был инсайдер с законным доступом. Межсетевые экраны и обнаружение вторжений нацелены на атаки извне; злоупотребление инсайдера требует других мер: (1) минимизировать привилегии (наименьшие привилегии / need-to-know); (2) обнаруживать массовый просмотр/выгрузку; (3) закрыть каждый канал утечки; (4) распространить надзор на подрядчиков и субподрядчиков. Эти четыре пункта — основа защиты.
QМожет ли небольшая организация или соло-проект извлечь из этого урок?
Да: (1) не давайте операторам или подрядчикам чрезмерно широкий доступ к продакшен-данным; (2) проведите инвентаризацию и закройте каждый канал, по которому данные можно скопировать наружу (USB, смартфон, облако, печать); (3) ведите логи того, кто и сколько данных смотрел, и оповещайте о массовом доступе; (4) понимайте объём и реальность аутсорсинга и субподряда. Чем меньше команда, тем легче сказать «мы им доверяем» и так и не урезать привилегии.