Атака через поставщика ПО: когда ваш периметр начинается не у вас
Почему компрометация стороннего программного обеспечения - это угроза вашей инфраструктуре, и как думать об управлении этим риском.
В марте 2019 года стало известно о масштабной атаке, в ходе которой злоумышленники скомпрометировали механизм автоматического обновления популярного программного обеспечения. В результате вредоносный код был доставлен на машины огромного числа пользователей - через совершенно легитимный канал, которому они доверяли.
Это не новый класс угрозы - атаки на цепочку поставок программного обеспечения известны давно. Но масштаб и механизм этого конкретного случая заставляют по-новому смотреть на вопрос: где на самом деле начинается ваш периметр безопасности?
Почему обновления ПО - это вектор атаки
Большинство корпоративных систем безопасности устроены для защиты от внешних атак: закрыть порты, проверять почту, контролировать доступ. Но обновление программного обеспечения - это легитимный входящий трафик. Оно должно проходить.
Если злоумышленник получает контроль над инфраструктурой поставщика ПО - сервером обновлений, ключами подписи, сборочным конвейером - он может доставить вредоносный код с подписью, которой вы доверяете, через канал, который вы намеренно открыли.
Ваш периметр в этом сценарии начинается не у вашего межсетевого экрана. Он начинается у вашего поставщика.
Как оценить свою зависимость
Большинство компаний не имеют инвентаря стороннего ПО на достаточном уровне детализации. Знать, какой антивирус установлен, - это одно. Знать, какое ПО на всех машинах автоматически получает обновления, с каких серверов, с какой проверкой подписи - это совсем другое.
Первый шаг к управлению этим риском - составить список. Какое стороннее ПО установлено в инфраструктуре? Какое из него имеет автоматическое обновление? Кто его поставляет? Насколько этот поставщик сам обеспечивает безопасность своей цепочки поставок?
Это не параноя. Это инвентаризация зависимостей - то же самое, что вы делаете для финансовых или операционных рисков.
Что можно сделать практически
Полностью устранить этот риск невозможно: без обновлений вы оставляете уязвимости незакрытыми, что ещё хуже. Но управлять им можно.
Сегментация помогает ограничить радиус поражения. Если скомпрометированное ПО попало на рабочую станцию, но у неё нет доступа к производственным системам и чувствительным данным - ущерб значительно меньше.
Мониторинг поведения, а не только трафика. Скомпрометированное ПО с легитимной подписью пройдёт проверку по хэшу и сигнатуре. Но его поведение в системе - сетевые соединения, обращения к файлам, создание процессов - может быть аномальным. Это детектируется.
Управление привилегиями. Стороннее ПО не должно работать с правами администратора там, где это не нужно. Принцип минимальных привилегий снижает то, что атакующий может сделать, получив контроль.
Осознанный выбор поставщиков. При оценке критичного ПО имеет смысл задавать поставщику вопросы о его собственной цепочке разработки и безопасности: есть ли подписание кода, есть ли аудит.
Вопросы для оценки вашего положения
- Есть ли у вас список стороннего ПО в инфраструктуре с отметкой о том, что обновляется автоматически?
- Есть ли у вас понимание, какие системы имеют наибольший радиус поражения в случае компрометации?
- Работает ли критичное ПО с минимально необходимыми привилегиями?
- Есть ли мониторинг аномального поведения на конечных точках?
- Проводите ли вы оценку безопасности ключевых поставщиков ПО - не только их продуктов, но и их процессов?
Атака через цепочку поставок - это не аргумент за паранойю. Это аргумент за инвентаризацию и осознанность в отношении зависимостей, которые большинство компаний принимают как данность.