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