Kaseya VSA: задержка обнаружения и ответственность в цепочке

Резюме

Инцидент с Kaseya VSA в июле 2021 года превратил проблему поставщика ПО и управляемых услуг в проблему ответственности на нижних уровнях цепочки: многие пострадавшие компании зависели от уведомлений и восстановления со стороны поставщиков управляемых услуг (MSP), хотя напрямую VSA не эксплуатировали.
Открытые данные показывают, что Kaseya уже работала с DIVD в рамках скоординированного раскрытия до атаки, что часть уязвимостей была устранена, а уязвимые локальные системы всё ещё существовали, когда группировка REvil использовала VSA 2 июля 2021 года.
Действия Kaseya после сигнала — остановка облачной среды VSA, рекомендация локальным клиентам отключить серверы, привлечение специалистов по реагированию, контакты с государственными партнёрами и выпуск инструмента обнаружения — были важны. Но они не отвечают на все вопросы о том, насколько снижалась подверженность риску до эксплуатации и как быстро нижние звенья цепочки получили пригодные для использования инструкции.
Пострадавшие считаются по уровням. Kaseya позднее называла менее 60 напрямую пострадавших клиентов, многие из которых — MSP, и менее 1500 компаний на нижних уровнях. Эти цифры описывают разные позиции в дереве зависимостей, и их нельзя сводить к одному числу.
Стандарт исправления ситуации — наблюдаемость: экосистема управляемых услуг должна уметь показать, кто был подвержен риску, кто был предупреждён, кто отключился, у кого были зашифрованы системы, кто получил инструкции по восстановлению и могли ли клиенты, не имеющие прямого контроля над VSA, увидеть риск вовремя, чтобы защитить непрерывность бизнеса.

Задержка обнаружения прошла через всю цепочку услуг

Инцидент Kaseya часто называют атакой программы-вымогателя через цепочку поставок. В целом это верно, но такая формулировка может скрывать конкретный путь ответственности. Открытые материалы не показывают, что злоумышленники изменили сборку ПО Kaseya или распространяли вредоносное обновление вендора. Вобзоре инцидента и технических деталяхKaseya говорится, что злоумышленники использовали уязвимости нулевого дня в локальной версии VSA, обошли аутентификацию, получили возможность выполнять команды и с помощью штатных функций VSA развернули программу-вымогатель на управляемых конечных точках. Доверие было нарушено через административные полномочия, а не через отравленный пакет вендора.

Это различие важно для обнаружения и раскрытия. VSA — это программное обеспечение для удалённого мониторинга и управления. Поставщики управляемых услуг используют такие инструменты, чтобы вести учёт устройств, проводить обслуживание, разворачивать ПО и поддерживать клиентов, у которых часто нет собственного штатного технического персонала. Когда злоумышленник получает контроль над сервером VSA, вредоносное действие может выглядеть как административное действие, пока поведение, время, полезные нагрузки или сообщения клиентов не покажут обратное.

Первое явное предупреждение может появиться у MSP, у нижнего клиента, у вендора средств безопасности, у производителя ПО или у государственного партнёра. Ни одна из этих позиций не видит всю цепочку.

Впресс-релизе от 5 июля 2021 годаKaseya сообщила, что внутренние и внешние источники предупредили компанию о возможной атаке примерно в 14:00 по восточному времени 2 июля и что компания в течение часа остановила свою облачную среду VSA и рекомендовала локальным клиентам отключить серверы. Это действие после сигнала имело значение. Оно, вероятно, ограничило дальнейшее распространение. Но анализ ответственности на нижних уровнях задаёт более длинный вопрос: когда риск стал известен на каждом уровне и как быстро предупреждение дошло от первого уровня, который узнал об угрозе, до компаний, которым предстояло потерять системы?

Компания Huntress, получившая ранние сообщения от пострадавших партнёров, опубликовалакраткий обзор событий и извлечённых уроков. В нём описано, как сообщения от MSP поступали почти одновременно, как выявилась общая связь через VSA, как размещались полезные нагрузки, проводились работы по очистке и доставка шла через функции управления. Sophos опубликовалатехнический разбортого периода с точки зрения конечных точек и реагирования. Эти описания реагирования — не глобальная статистика жертв, но они показывают, почему задержка обнаружения в этом случае была распределённой. Первая компания, заметившая шифрование, не обязательно была той стороной, у которой есть полномочия исправить VSA.

Впубличном заявлении FBI об атаке на Kaseyaбыло повторено требование отключить серверы и настоятельная рекомендация сообщать об инцидентах. Позже CISA и FBI выпустили совместные рекомендации вэтом информационном бюллетене (PDF), где рекомендовали инструмент обнаружения, многофакторную аутентификацию, ограничение каналов удалённого управления, защиту административных интерфейсов через VPN или межсетевой экран, защищённые резервные копии и минимально необходимые привилегии. Это сильные меры, принятые после обнаружения. Открытым остаётся вопрос, насколько можно было снизить подверженность риску до того, как истекло отпущенное преступникам время.

Поэтому задержку обнаружения нельзя измерять только внутри Kaseya. Её нужно измерять в точках, где MSP могли заметить аномальное поведение VSA, где нижние компании могли понять, что инструмент их провайдера и есть путь атаки, и где государственные ведомства могли превратить сообщения об инцидентах в более широкое предупреждение. Инцидент превратил концентрированную платформу управления в проблему ретрансляции.

Скоординированное раскрытие столкнулось со сроками злоумышленников

История до эксплуатации необычайно важна, потому что она сопротивляется и простому осуждению, и простому оправданию. Взаписке об ограниченном раскрытииDIVD сообщила, что некоммерческая исследовательская группа начала изучать VSA в апреле 2021 года и уведомила Kaseya 6 апреля. DIVD заявила, что реакция Kaseya была своевременной и конструктивной и что компания работала с исследователями над исправлениями. Это важно. Открытые данные не подтверждают простой тезис о том, что вендор проигнорировал ответственные сообщения об уязвимостях.

Вкарточке дела, которую ведёт DIVD, видна другая сторона хронологии. В деле было несколько уязвимостей. Некоторые были исправлены до июля. Облачная среда Kaseya получила соответствующие исправления до атаки. Локальным серверам VSA ещё требовались действия, когда начался инцидент с программой-вымогателем. Позже DIVD опубликовалаполные детали уязвимостей, включая CVE-2021-30116, а взаписи о CVE-2021-30116 в NVDтеперь указано, что эта проблема эксплуатировалась в реальных атаках.

Эта последовательность задаёт жёсткий стандарт ответственности. Вендор, который добросовестно работает с исследователями, всё равно может столкнуться со сбоем на нижних уровнях, если устранение уязвимостей, снижение подверженности риску и предупреждение клиентов не опередят повторное обнаружение уязвимости злоумышленниками. Скоординированное раскрытие задумано для снижения вреда: исправления появляются раньше, чем публикуются детали. Но оно также создаёт период, когда небольшое число людей знает, что продукт с высокими последствиями уязвим, а многие операторы не знают достаточно, чтобы изменить своё поведение.

Чем более привилегирован продукт, тем короче должен быть этот период.

Роль VSA усиливала срочность. Продукт удалённого администрирования — не обычный контентный сайт. Это плоскость управления для клиентских машин. Если в доступном из интернета сервере VSA есть критическая уязвимость аутентификации или авторизации, вероятное последствие — не только компрометация одного сервера. Это вредоносные действия на всех конечных точках, доверяющих этому серверу. А значит, промежуточные меры защиты должны рассматриваться как часть процесса раскрытия, а не как необязательное усиление после выхода патча.

В открытых материалах остаётся несколько нерешённых вопросов о периоде до атаки. С какими операторами открытых систем Kaseya связывалась напрямую до 2 июля? Какие промежуточные ограничения требовались или рекомендовались? Были ли административные интерфейсы переведены за VPN или отдельные правила межсетевого экрана? Просили ли клиентов с высокорисковыми локальными развёртываниями отключаться до выхода патча? Как Kaseya проверяла, что известные открытые системы изменили своё состояние? Существовала ли телеметрия, позволявшая отличить подозрительное создание процедур от обычной работы по удалённому управлению?

Эти вопросы не подразумевают халатности.

Они определяют, какие доказательства нужны, чтобы оценить, соответствовали ли предэксплойтные предупреждения радиусу поражения VSA.

Позже Kaseya публиковала уведомления, напримерважное уведомление от 4 августа 2021 года, и дополнительные материалы по восстановлению, а также предоставиластраницу инструмента обнаружения компрометации. Эти документы — часть записей о мерах после инцидента. Сами по себе они не восстанавливают картину того, что было возможно в июне 2021 года. Устойчивый урок: скоординированное раскрытие для привилегированного ПО управления должно включать наблюдаемое снижение подверженности риску задолго до публичного заголовка в новостях.

Масштаб пострадавших на нижних уровнях изменил картину ущерба

Число прямых жертв Kaseya было небольшим относительно всей клиентской базы, и Kaseya справедливо подчёркивала, что пострадали не все клиенты. Этот факт нужно сохранить. Но им нельзя приуменьшать операционную форму инцидента. Инцидент имел значение потому, что часть пострадавших прямых клиентов были поставщиками управляемых услуг. Один MSP может соединить одну скомпрометированную плоскость управления с десятками или сотнями компаний.

Шведская розничная сеть Coop стала публичным символом потери непрерывности на нижнем уровне. Investing.com перепечатала материал Reuters о том, чтокибератака на американского ИТ-провайдера вынудила шведскую сеть закрыть 800 магазинов. В более поздних материалах говорилось, что пострадавшим компаниям может потребоватьсянесколько недельна восстановление. Эти сообщения не следует считать полным списком жертв. Они показывают, как компрометация инструмента удалённого управления может дойти до публичных сервисов, которые потребители воспринимают как закрытые двери, недоступные платежи или сбои в работе на местах.

Для малых и средних предприятий управляемый сервис — рациональный выбор. Он даёт доступ к профильным специалистам, мониторингу, управлению резервными копиями, установке обновлений и поддержке, которые многие небольшие организации не смогли бы выстроить сами. Но та же концентрация создаёт коррелированные сбои. Набор компаний, которые выглядят независимыми по географии и отрасли, может пользоваться услугами одного MSP, одного инструмента удалённого управления, одной схемы резервного копирования и одних сотрудников по восстановлению.

Атака программы-вымогателя на этом уровне способна одновременно обрушить множество формально независимых планов непрерывности.

Так же может быть затронута непрерывность государственного сектора. Местные администрации, школы, коммунальные предприятия и ведомства, работающие с населением, часто зависят от MSP или аналогичного внешнего сопровождения. Граждане, пострадавшие от простоя, не различают, управлялся ли инструмент сотрудником ведомства, подрядчиком, реселлером или производителем ПО. Им нужно восстановление услуг. Однако путь ответственности проходит через эти технические отношения, и на каждой передаче может возникать задержка.

Здесь обнаружение и раскрытие становятся экономическим фактором. Малая компания, которая быстро узнаёт об угрозе, может отключить системы, сохранить резервные копии, предупредить сотрудников, перевести приём платежей на другой канал, перенести работы или позвонить клиентам. Компания, которая узнаёт только после шифрования, имеет меньше вариантов. Ей могут грозить потерянные продажи, сбой выплат зарплаты, недовольство клиентов, неопределённость с регуляторной отчётностью и бумажная волокита со страховой.

Одна и та же техническая эксплуатация приносит разный ущерб в зависимости от того, когда нижняя сторона получила пригодную для использования информацию.

Позже CISA, NSA, FBI и международные партнёры выпустили более широкие рекомендации по защите отношений между поставщиками управляемых услуг и их клиентами — о них объявила CISA вэтом уведомлении. Эти рекомендации отражают системный момент: безопасность MSP — не только их частная проблема. Это общая проблема непрерывности для клиентов, которые наследуют доверие к ним.

Действия правоохранителей не заменили доказательств восстановления

Инцидент Kaseya породил и материалы правоохранительных органов. Министерство юстиции США объявило в 2021 году, что гражданин Украины быларестован и обвинёнв связи с атакой программы-вымогателя. Europol объявила, чтопять аффилированных лиц, связанных с Sodinokibi/REvil, были нейтрализованы. Позже Министерство юстиции США объявило, что аффилированное лицо Sodinokibi/REvil былоприговоренок наказанию за более широкую роль в схеме вымогательства. Эти материалы важны для ответственности злоумышленников.

Они не отвечают на операционные вопросы. Уголовные обвинения и приговоры могут назвать подозреваемых или осуждённых, нарушить работу инфраструктуры, собрать улики и сдержать будущие кампании. Они не доказывают, у каких именно клиентов MSP были надлежащие резервные копии, кому из клиентов сообщили вовремя, какие серверы VSA были открыты до 2 июля и безопасно ли каждая организация на нижнем уровне провела восстановление. Ответственность злоумышленников и ответственность за оказание услуг сосуществуют, поскольку касаются разных мер контроля.

То же различие применимо к вниманию конгресса. Запись слушаний в Палате представителей, доступная черезGovInfo, зафиксировала общественное беспокойство по поводу программ-вымогателей, критически важных сервисов и готовности частного сектора. Надзор может выявить закономерности и показать потребности в политике. Но он всё равно не заменяет доказательства на уровне конкретного субъекта: хронологию обнаружения, содержание уведомлений, исполнение отключения и качество восстановления.

ВSP 800-161 Rev. 1 (NIST)даётся более широкий словарь для оценки рисков цепочки поставок. В нём поставщики, продукты, услуги и контроль жизненного цикла рассматриваются как часть управления кибербезопасностью. Инцидент Kaseya показывает, почему в этот словарь нужно включать операционные доказательства по управляемым услугам. Закупочная команда не может просто спросить, использует ли MSP платформу удалённого управления. Нужно спросить, как эта платформа доступна из интернета, как она мониторится, кто может её отключить, как устроена сегментация клиентов, как изолированы резервные копии, как сообщается об инцидентах и как будут передаваться доказательства.

Поэтому доказательства восстановления после Kaseya должны быть многослойными. Kaseya должна показать устранение уязвимостей продукта, зрелость процесса приёма сообщений об уязвимостях, каналы предупреждения клиентов и ожидания безопасности по умолчанию для высокорискованных развёртываний. MSP должны показать ограничение административного доступа, многофакторную аутентификацию, сегментацию, минимальные привилегии, защищённые резервные копии, сценарии уведомления клиентов и учения, включающие компрометацию инструмента.

Нижние клиенты должны показать, что они знают, какие инструменты провайдера могут администрировать их системы, и какие есть альтернативы для непрерывности, если эти инструменты придётся отключить.

Никакой успех правоохранителей не отменяет необходимости таких записей. Аффилированное лицо программы-вымогателя может быть арестовано, а у компании по-прежнему не будет восстанавливаемой резервной копии. Вендор может выпустить патч, а MSP не успеет связаться со всеми клиентами. Государственная рекомендация может быть правильной, а самая маленькая пострадавшая компания всё равно не поймёт, что произошло. Ответственность должна достигать того уровня, где ложится ущерб.

Наблюдаемость — стандарт устранения последствий

Вопрос второго ракурса по Kaseya не в том, плох ли управляемый сервис. Управляемый сервис может повысить безопасность организаций, у которых иначе было бы мало поддержки. Вопрос в том, виден ли риск, создаваемый концентрацией администрирования, тем сторонам, которые от него зависят. Скрытая плоскость управления создаёт скрытую ответственность.

Наблюдаемость начинается со знания активов. Каждый клиент должен знать, какие удалённые инструменты могут выполнять команды, разворачивать ПО, сбрасывать учётные данные или получать доступ к чувствительным системам. MSP должен знать, какие серверы и арендаторы обладают такими полномочиями. Вендор должен знать, какие клиенты эксплуатируют открытые высокорисковые версии — там, где это возможно на основе лицензий и телеметрии. Государственные ведомства должны знать, как связаться с поставщиками критически важных услуг, когда инцидент у MSP угрожает коммунальным сервисам.

Наблюдаемость продолжается хронометражем событий. Полезная запись об инциденте должна фиксировать первое известное применение эксплойта, первое внутреннее оповещение, первое сообщение клиента, первую инструкцию вендора об отключении, первое уведомление от MSP клиенту, первое шифрование на нижнем уровне, первый результат работы инструмента обнаружения и время, когда каждая пострадавшая сторона достигла устойчивого восстановления. Без этих меток времени руководители могут хвалить быстрые действия в одной точке, не заметив задержку в другой.

Наблюдаемость также требует дисциплины в исчислении пострадавших. Менее 60 прямых клиентов, 57 локальных клиентов, до 1500 компаний на нижнем уровне и бесчисленное множество управляемых конечных точек — разные счётчики. Они описывают разные единицы ответственности. Счёт прямых клиентов говорит о подверженности вендора. Счёт компаний на нижнем уровне говорит об ущербе непрерывности. Счёт конечных точек говорит о технической нагрузке. Если их смешивать, невозможно увидеть, где устранение последствий удалось, а где нет.

Наконец, наблюдаемости нужен язык, понятный клиенту. Малой компании не нужны все детали эксплойта в первый час. Ей нужно знать, был ли затронут инструмент удалённого управления её провайдера, нужно ли отключать системы, безопасны ли резервные копии, зашифрованы ли файлы, можно ли продолжать приём платежей, стоит ли сотрудникам перестать пользоваться определёнными устройствами и когда придёт следующее обновление. Качество уведомлений MSP — часть профиля ущерба от инцидента вендора, потому что продукт вендора дал MSP возможность доставать до клиентов.

Инцидент Kaseya показал, что платформа удалённого управления может концентрировать и эффективность, и хрупкость. Задача ответственности после 2021 года — сохранить эффективность, сделав хрупкость видимой. Это значит: более быстрые частные предупреждения там, где публичное раскрытие повысило бы риск, более строгие ограничения доступа по умолчанию, клиентские контракты, называющие зависимости от удалённого управления, и планы восстановления, которые допускают, что любимый инструмент MSP сам может стать недоступным или враждебным.

У цепочки уведомлений должен быть свой целевой уровень обслуживания

Инцидент показывает, почему безопасности управляемых услуг нужен целевой уровень обслуживания для уведомлений, а не только цель по устранению уязвимости. При обычной уязвимости ПО оператор, получающий рекомендацию вендора, часто является той же организацией, которая пострадает, если система останется открытой. В управляемом сервисе оператор и клиент, несущий риск, могут быть разными. MSP может получить предупреждение вендора; малая компания может получить только последствие. Этот разрыв требует измеримого стандарта.

Цель уведомлений должна начинаться с классификации. Если инструмент удалённого управления может выполнять команды, разворачивать ПО, менять настройки безопасности или касаться резервных копий в средах клиентов, то серьёзная уязвимость в таком инструменте — не рядовая заявка в службу поддержки. Это событие риска для клиентов. У MSP должна быть заранее написанная категория «инцидент плоскости управления провайдера», которая запускает коммуникацию с клиентами ещё до того, как будут известны все технические детали. Сообщение может быть ограниченным и осторожным, но оно не должно ждать, пока шифрование станет видимым у клиента.

Первое уведомление не обязано раскрывать детали эксплойта, которые помогли бы злоумышленникам. Оно должно сказать клиенту, что важно операционно: привилегированная платформа управления находится на экстренной проверке; доступ провайдера может быть ограничен; часть работ по обслуживанию может быть приостановлена; клиентам стоит сохранить резервные копии и не перезапускать затронутые машины без инструкций; доступны контакты для срочных вопросов и сроки следующего обновления. Если компрометация подтверждена, уведомление должно сказать, какие системы затронуты, что делает провайдер, что делать клиенту и какие доказательства нужно сохранить.

Второе уведомление должно показать карту зависимости. Многие клиенты не знают названий продуктов, стоящих за управляемым сервисом. Компания может понимать фразу «наш ИТ-провайдер занимается обновлениями», но не понимать, что «VSA может выполнять команды на каждом рабочем месте». Во время инцидента это незнание становится проблемой непрерывности. Клиент не сможет объяснить событие своим сотрудникам, страховой, своим клиентам, регулятору или совету директоров, если MSP не назовёт затронутую плоскость управления.

В контрактах должно быть указано, когда название продукта может раскрываться клиентам в экстренной ситуации и сколько деталей нужно сообщать.

Третье уведомление должно касаться операционной деятельности. Если MSP отключает VSA, могут быть нарушены регулярный мониторинг, развёртывание ПО, удалённая поддержка и часть функций реагирования на инциденты. Клиентам нужно знать, какая поддержка остаётся доступной. Им нужны альтернативные телефоны, каналы заявок, правила экстренного доступа и ожидаемые задержки. Инструкция об отключении, защищающая безопасность, может всё же навредить непрерывности, если никто не объяснит последствия для сервиса.

Четвёртое уведомление должно фиксировать доказательства и восстановление. Клиент должен знать, были ли зашифрованы его устройства, выполнялись ли подозрительные процедуры, затронуты ли резервные копии, были ли сменены учётные данные, относятся ли к ситуации рекомендации правоохранителей или CISA и использовал ли провайдер инструмент обнаружения Kaseya или другие свидетельства реагирования. Клиент, получивший только фразу «мы работаем над этим», не может принимать собственные юридические, страховые и клиентские решения.

Эта цепочка уведомлений должна быть ограничена по времени. MSP может пообещать первоначальное уведомление клиентов в течение установленного числа минут после подтверждённого инцидента плоскости управления провайдера, затем — обновления через заданные интервалы и письменный итоговый документ после восстановления. Хронология будет различаться в зависимости от клиента и тяжести инцидента, но принцип — нет. Риск управляемых услуг делегирован; ответственность — нет.

Предварительно санкционированное отключение — управленческий контроль

Инструкция Kaseya отключить локальные серверы VSA вскрыла неудобную правду: действие, безопасное с точки зрения защиты, может быть разрушительным для бизнеса. Отключение платформы удалённого управления может сократить радиус действий злоумышленника, но также может лишить MSP основного способа поддержки клиентов. Если MSP заранее не определил, кто имеет право принимать такое решение, реагирование может застопориться в самый худший момент.

Предварительная авторизация должна определить, кто может отключить инструмент, при каком пороге доказательств и как об этом сообщается клиентам. Она также должна определить, какие функции остаются доступны после отключения. Могут ли специалисты поддерживать клиентов по телефону? Есть ли альтернативный удалённый доступ? Является ли альтернативный доступ более или менее безопасным? Какие клиентские среды слишком чувствительны для экстренных удалённых инструментов? Каким клиентам требуется письменное одобрение, прежде чем агенты провайдера снова подключатся? Эти детали кажутся утомительными, пока атака в пятницу днём не сделает их срочными.

Та же логика применима к вендору. Для такого продукта, как VSA, отключение облачной среды находится под прямым контролем компании, но локальным операторам нужны чёткие пороги. Вендор может рекомендовать или требовать отключение в условиях поддержки, но исполнение принадлежит клиентам. Если вендор знает, что некоторые доступные из интернета локальные развёртывания находятся в высоком риске до готовности патча, ему нужна модель частной эскалации: прямой контакт, уведомления высшего приоритета, отслеживание обращений в поддержку и проверка там, где это возможно. Цель — не пристыдить клиентов.

Цель — сократить число открытых плоскостей управления до действий преступников.

Полномочия на отключение также связаны с резервными копиями. Реагирование на программу-вымогателя зависит от восстанавливаемых и защищённых резервных копий, но многие MSP управляют резервными копиями через ту же экосистему администрирования, что и регулярное обслуживание. Если плоскость управления вызывает подозрение, реагирующим нужно знать, независимы ли консоли резервного копирования, учётные данные, хранилища и процедуры восстановления. Рекомендации CISA и FBI подчёркивали резервные копии, изолированные от сети или защищённые иным образом, потому что компрометация управления может угрожать не только производству, но и восстановлению.

Клиенты не должны во время инцидента обнаруживать, что план резервного копирования MSP зависит от скомпрометированного инструмента. Контракт на управляемые услуги должен описывать, разделены ли резервные копии логически и административно, как часто тестируется восстановление, кто может санкционировать восстановление и что происходит, если среда управления MSP недоступна. Для малых компаний такая контрактная формулировка может быть единственной практической возможностью увидеть свою устойчивость.

Предварительно санкционированное отключение помогает и страховщикам, и регуляторам. Клиент, который может показать, что провайдер следовал документированному сценарию отключения и уведомлений, находится в ином положении, чем клиент, реконструирующий решения из разрозненных писем. Доказательства предварительно авторизованных действий не устраняют ущерб, но показывают управляемость. Они также могут уменьшить споры между вендором, MSP, клиентом, страховщиком и правоохранителями после события.

История Kaseya показывает, что быстрые действия после сигнала ценны. Следующий стандарт должен сдвинуть решение раньше и сделать его более автоматическим там, где радиус поражения очевиден. Плоскость управления удалённым администрированием должна быть спроектирована так, чтобы при сбое переходить в закрытое состояние (fail closed), с известным путём работы в ограниченном режиме. Если для отключения каждый раз требуется отдельное обсуждение, значит, бизнес-модель не до конца учла роль безопасности, которую играет такой инструмент.

Доказательства с нижних уровней — часть истории продукта

Вендоры ПО естественным образом сосредоточены на прямых клиентах, но последствия продукта управляемых услуг распространяются на клиентскую базу этих клиентов. Это значит, что доказательства с нижних уровней принадлежат истории продукта. Вендор может не знать каждую конечную точку или каждую компанию, которую обслуживает MSP, но он должен проектировать отчётность об инцидентах так, чтобы по возможности сохранять цепочку зависимостей.

Первая проблема доказательств — идентификация затронутой цепочки. Какой клиент Kaseya эксплуатировал затронутый экземпляр VSA? Был ли этот клиент MSP? Какие клиентские среды обслуживал этот экземпляр VSA? Какие агенты подключались в окне подверженности риску? Какие процедуры выполнялись? Какие конечные точки получили полезные нагрузки? Какие конечные точки были офлайн и позже оказались под риском при переподключении? Без этой цепочки цифры становятся неоднозначными, а восстановление — неравномерным.

Вторая проблема — время. Компания на нижнем уровне должна знать, когда были затронуты её системы, а не только когда вендор обнаружил инцидент. Если вредоносная процедура выполнялась в конкретное время, эта метка становится якорем для расследования конечных точек, выбора резервных копий, решений по зарплате и уведомления клиентов. Если MSP не может предоставить хронологию, клиенту, возможно, придётся считать подозрительным более широкий период, что увеличивает издержки.

Третья проблема — сохранность доказательств. Журналы могут находиться на сервере VSA, у MSP, на конечных точках, в средствах безопасности и у вендора. Во время атаки программы-вымогателя часть доказательств может быть удалена, зашифрована, перезаписана или отключена. Зрелый продукт должен делать действия с высокими последствиями достаточно устойчивыми, чтобы реагирующие могли реконструировать произошедшее, даже если сервер управления скомпрометирован. Это не требует публикации чувствительной телеметрии на весь мир. Это требует проектирования под реконструкцию инцидента.

Четвёртая проблема — язык, понятный клиенту. Компании на нижнем уровне может понадобиться отчитаться перед регулятором, школьным советом, мэром, владельцем, страховщиком или своими клиентами. Она не может просто переслать технический бюллетень вендора, если в нём не сказано, была ли затронута её собственная среда. MSP должны превращать доказательства вендора в индивидуальные заявления для клиента: в зоне поражения, вне зоны поражения, зашифровано, не зашифровано, неизвестно из-за отсутствия доказательств, восстановлено из резервной копии, учётные данные сменены или всё ещё расследуется.

«Неизвестно» приемлемо, если это правда; притворяться знающим нельзя.

Пятая проблема — справедливое распределение ответственности. Если вендор, MSP и клиент вносят вклад в итоговый риск, запись доказательств должна позволять такое распределение. Уязвимость вендора может создать точку входа. Открытость MSP в интернете или слабая сегментация могут увеличить ущерб. Слабые резервные копии клиента могут удлинить восстановление. И наоборот, предупреждение вендора, отключение MSP и план непрерывности клиента могут уменьшить ущерб. Ответственность должна быть достаточно детальной, чтобы признавать и заслуги, и вину соответствующих мер контроля.

Вот почему доказательства с нижних уровней — часть истории продукта. Недостаточно, чтобы вендор знал, сколько прямых клиентов пострадало, если экономическая роль продукта в том, чтобы администрировать гораздо больше организаций. Управление продуктом должно учитывать дерево зависимостей заранее. Шаблоны инцидентов, телеметрия, эскалация поддержки и публичные заявления должны сохранять знаменатели по уровням: прямые клиенты, MSP, организации на нижнем уровне, конечные точки и услуги. Инцидент Kaseya стал знаковым именно потому, что все эти уровни сработали одновременно.

Контракты должны раскрывать скрытую плоскость управления

Многие клиенты управляемых услуг не покупают Kaseya VSA напрямую. Они покупают результат: обновлённые ноутбуки, работающую почту, доступные принтеры, отслеживаемые серверы, поддержку в службе помощи и восстановление после сбоя. Продукт удалённого управления спрятан за обещанием услуги. Эта скрытость может быть эффективной в обычное время, но во время атаки программы-вымогателя она оставляет клиента без карты. Клиент не может оценить риск для непрерывности, если не знает, какие внешние системы могут администрировать его среду.

Поэтому контракты должны называть категории привилегированных инструментов провайдера, даже если не публиковать каждую чувствительную настройку. Клиент должен знать, использует ли MSP программное обеспечение удалённого мониторинга и управления, средства обнаружения и реагирования на конечных точках, консоли резервного копирования, брокеры удалённого рабочего стола, скриптовые движки, администрирование учётных записей или облачные порталы управления. Для каждой категории клиент должен знать, может ли инструмент разворачивать ПО, выполнять команды, сбрасывать учётные записи, получать доступ к резервным копиям или менять меры безопасности.

Это не любопытство. Это реестр зависимостей.

Контракт также должен определять, как будет обрабатываться компрометация инструмента. Уведомит ли MSP клиента, если привилегированный инструмент провайдера активно эксплуатируется? Кто решает отключить агентов провайдера? Получит ли клиент список затронутых конечных точек? Как быстро MSP предоставит письменные факты для страховой и юридической проверки? Какие доказательства будут сохранены? Какая поддержка останется, если инструмент будет отключён? Эти условия превращают размытые доверительные отношения в подотчётную операционную модель.

У малой компании может не быть рычагов, чтобы согласовать каждый пункт. Поэтому важны отраслевые стандарты, публичные рекомендации, страховщики и шаблоны закупок. Если многие клиенты задают одни и те же вопросы, MSP могут выработать повторяемые ответы. Если вопросов никто не задаёт, плоскость управления остаётся невидимой, пока инцидент её не вскроет. Инцидент Kaseya должен сделать невидимое администрирование менее продаваемым.

Это не значит, что каждый MSP обязан раскрывать чувствительные внутренние детали каждому клиенту. Архитектуру безопасности можно описать на нужном уровне: полномочия, зависимости, уведомления, доказательства и восстановление. Клиенту не нужен код эксплойта или административные пароли. Ему нужно знать, что может случиться с его бизнесом, если инструмент провайдера будет скомпрометирован, и что провайдер обязан сделать дальше.

Примечание о типографике

Что осталось неизвестным

Открытые материалы не устанавливают каждый запрос на использование эксплойта, каждого затронутого MSP, каждое последствие для компаний на нижнем уровне и каждую метку времени клиентских уведомлений. Они не доказывают, что злоумышленники узнали об уязвимостях из процесса скоординированного раскрытия. Параллельное обнаружение уязвимости правдоподобно, и его нельзя превращать в необоснованное обвинение. Не раскрыты и все промежуточные меры до атаки, и все операторы, с которыми связались до 2 июля. Не подтверждена независимо и эффективность каждой последующей меры Kaseya или MSP.

Эти ограничения не делают инцидент непознаваемым. Они определяют, каких доказательств всё ещё не хватает для сильной ответственности в управляемых услугах.

Достаточно самых сильных известных фактов: исследователи приватно сообщили о серьёзных слабостях VSA; исправления готовились; облачный сервис получил соответствующие исправления; локальные системы оставались открытыми; злоумышленники использовали полномочия VSA для распространения программы-вымогателя; Kaseya и партнёры выпустили срочные рекомендации по отключению и восстановлению; а компании на нижнем уровне понесли ущерб, который часто брал начало в инструментах, которыми они напрямую не управляли.

Поэтому вопрос ответственности практичен. Когда плоскости управления управляемого сервиса угрожает опасность, может ли каждая сторона, которая понесёт последствия, увидеть достаточно и вовремя, чтобы действовать? В июле 2021 года ответ был неравномерным. Некоторые участники действовали быстро, как только атака стала известна. Многие организации на нижнем уровне всё ещё зависели от чужого обнаружения, чужого решения об отключении и чужого объяснения. Это и есть проблема ответственности на нижних уровнях, которую Kaseya сделала видимой.

Kaseya превратила задержку обнаружения в управляемых сервисах в проблему ответственности на нижних уровнях цепочки