Инциденты и уязвимости
Утечка данных 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 выдаёт предписание об улучшении. Дело становится одним из драйверов поправки к японскому закону о защите персональных данных (ужесточение правил для брокеров данных).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) понимайте объём и реальность аутсорсинга и субподряда. Чем меньше команда, тем легче попасть в ловушку «мы им доверяли» и так и не урезать привилегии.