Cognizant превратила восстановление после шифровальщика Maze в тест на подотчётность в ИТ-услугах

Резюме

• Cognizant в апреле 2020 года подтвердила, что инцидент безопасности, затронувший её системы и вызвавший сбои в обслуживании части клиентов, стал результатом атаки шифровальщика Maze. Компания сообщила, что поддерживает связь с клиентами и передала им индикаторы компрометации и технические меры защиты.
• Вопрос подотчётности состоит в том, у кого находился практический контроль над сегментацией управляемых услуг, изоляцией конечных точек, коммуникацией с клиентами, приоритетами восстановления, раскрытием затрат, доказательствами для заказчиков и границей между системами Cognizant и средами клиентов.
• В более поздних публичных отчётах событие описывалось как сбой бизнеса, который привёл к несанкционированному доступу к определённым данным, затронул часть клиентских сервисов, повлёк расходы на локализацию и восстановление, а также совпал по времени с давлением удалённой работы в период пандемии.
• Имеющиеся данные не позволяют утверждать, что все случаи воздействия на клиентов, действия злоумышленника или детали криминалистического анализа публично известны. При этом они позволяют рассматривать событие как случай нарушения непрерывности ИТ-услуг, поскольку сбой поставщика может превратиться в событие риска для клиента.
• Клиентам, командам, эксплуатирующим переданные на аутсорсинг процессы, сотрудникам, инвесторам, страховщикам и командам безопасности клиентов пришлось оценивать, изменил ли инцидент с шифровальщиком у поставщика их собственные допущения о непрерывности, доступе и доказательствах.

Доказательная база и как она используется

Эта статья рассматривает открытые данные как многослойное свидетельство. Заявления Cognizant, материалы для инвесторов и документы SEC используются для отражения того, что компания публично сообщала об атаке шифровальщика Maze, сбоях в обслуживании, локализации, восстановлении, финансовых последствиях и коммуникации с клиентами. Материалы по безопасности и технологиям используются для публичной хронологии, отражения озабоченности заказчиков и современной интерпретации событий с сохранением неопределённости.

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

Почему инцидент с шифровальщиком у поставщика стал событием риска для клиентов

Инцидент с шифровальщиком Maze в Cognizant в 2020 году важен, потому что Cognizant была не просто очередным предприятием, пытавшимся восстановить свои файлы. Она была поставщиком ИТ-услуг и профессиональных услуг для других организаций. Эта роль меняет практическую значимость. Поставщик может обладать операционными знаниями, доступом для поддержки, рабочими процессами сервис-деска, проектными записями, учётными данными для управляемой инфраструктуры, подключением к сетям клиентов и доверием, необходимым клиентам для продолжения переданных на аутсорсинг процессов.

Когда поставщик подвергается атаке шифровальщика, клиенты спрашивают не только о том, сможет ли поставщик восстановить себя.

Они спрашивают, изменили ли доступ поставщика, его инструменты и доказательства их собственный уровень риска.

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

Таким образом, инцидент на стороне поставщика немедленно пересёкся с работой на стороне клиента.

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

Именно поэтому инцидент — это тест на подотчётность, а не просто ярлык «утечка». События с шифровальщиками часто сводятся к одному заголовку: системы зашифрованы. Инциденты у поставщиков требуют более широкой карты. Какие услуги были нарушены? Какие клиенты потеряли сервис? Какие клиенты в порядке предосторожности приостановили доступ поставщика? В каких системах поставщика хранились данные клиентов? Какие среды клиентов оставались подключёнными? Какие системы поддерживали удалённую работу во время пандемии? Какие решения о восстановлении защитили наибольшее число клиентов, не увеличив риск ни для одного из них?

Открытые данные отвечают на часть этих вопросов, а остальное оставляют закрытым.

Что устанавливают открытые данные

Открытые данные с высокой степенью уверенности устанавливают несколько фактов. Cognizant публично подтвердила атаку шифровальщика Maze в апреле 2020 года. Компания сообщила, что часть клиентов столкнулась со сбоями в обслуживании. Она заявила, что поддерживает связь с клиентами и передаёт индикаторы и защитную информацию. В отчётности за первый квартал позднее сообщалось, что атака привела к несанкционированному доступу к определённым данным и вызвала значительные сбои в бизнесе.

Также сообщалось, что часть клиентов столкнулась со сбоями в обслуживании, поскольку Cognizant полагалась на затронутые системы и сети для выполнения работы для клиентов, а также были затронуты системы, поддерживавшие удалённую работу.

В отчётности также сообщалось, что часть клиентов в порядке меры предосторожности приостановила доступ Cognizant к своим сетям.

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

Открытые данные также устанавливают финансовую значимость. Материалы для инвесторов и публичные результаты Cognizant обсуждали ожидаемое и понесённое финансовое влияние инцидента с шифровальщиком. Отраслевые материалы отразили публичное обсуждение влияния на второй квартал в размере от $50 до $70 млн на основе комментариев руководства. В более поздних материалах отчётности упоминались расходы на расследование, локализацию, восстановление, юридические и профессиональные услуги, улучшение безопасности и возможные лимиты страхования. Смысл не в том, чтобы свести инцидент к строке расходов.

Смысл в том, что реагирование потребовало внимания руководства, доверия клиентов и денежных средств.

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

Поэтому самый сильный публичный вывод точен. Инцидент с Maze в Cognizant стал тестом на подотчётность в области непрерывности ИТ-услуг, потому что системы поставщика, предоставление услуг клиентам, решения клиентов о доступе, криминалистические доказательства и финансовые раскрытия оказались связаны в открытых данных.

Граница обслуживания была центральным объектом доверия

Центральным объектом доверия был не только сервер или база данных. Это была граница обслуживания между Cognizant и её клиентами. Эта граница включала учётные записи, удалённый доступ, проектные системы, инструменты предоставления услуг, связь с клиентами, документацию, коммуникации и человеческие отношения, через которые выполняется переданная на аутсорсинг работа. Когда собственная среда Cognizant была поражена, границу нужно было подтверждать заново.

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

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

У границы обслуживания две стороны. Cognizant должна была локализовать и восстановить свои системы. Клиенты должны были решить, поддерживать ли доступ, ограничивать его, мониторить или приостанавливать. Решение клиента приостановить доступ может быть разумным, но затратным. Поставщик не может выполнять некоторые услуги без этого доступа. Формулировки отчётности делают этот компромисс видимым: когда клиенты приостанавливали доступ, Cognizant не могла продолжать предоставлять услуги через эти сети клиентов до восстановления доступа.

Это означает, что кибербезопасная локализация и непрерывность обслуживания не были отдельными направлениями работы. Это была одна и та же бизнес-задача.

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

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

Локализация под давлением шифровальщика

Локализация последствий шифровальщика отличается от обычной очистки, потому что злоумышленник может оставаться активным, системы могут быть зашифрованы или изолированы, а системы восстановления могут быть целью. Техники MITRE «данные зашифрованы для воздействия» и «подавление восстановления системы» описывают общие цели злоумышленников: сделать данные или системы недоступными и затруднить восстановление. Рекомендации CISA по шифровальщикам также подчёркивают подготовку, локализацию, резервное копирование, коммуникацию и восстановление.

В случае поставщика эти задачи выполняются, пока клиенты спрашивают, могут ли они продолжать полагаться на поставщика.

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

Более поздняя формулировка об устранении последствий, подкреплённая дополнительным мониторингом, — более сильное утверждение.

Для клиентов заявления о локализации должны превращаться в решения. Если Cognizant говорит, что злоумышленник больше не действует в среде, какие доказательства поддерживают восстановление доступа поставщика? Были ли отключены затронутые учётные записи? Были ли проверены пути удалённого доступа? Были ли пересобраны конечные точки? Были ли ротированы привилегированные учётные данные? Были ли проверены системы, поддерживающие предоставление услуг клиентам, перед повторным подключением? Были ли отделены клиентские инструменты от затронутых систем?

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

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

Какие клиенты приняли остаточный риск?

Какие клиенты приостановили доступ до получения дополнительных доказательств?

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

Коммуникация с клиентами была частью системы контроля

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

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

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

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

Альтернативные списки контактов клиентов, проверенные внешние каналы, исполнительные мосты и заранее согласованные контакты службы безопасности могут снизить путаницу.

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

Финансовые раскрытия сделали устойчивость измеримой

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

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

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

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

Публичное обсуждение влияния на второй квартал в размере от $50 до $70 млн следует читать внимательно. В нём описывалось ожидаемое влияние шифровальщика на выручку и соответствующую маржу, а не полная совокупная стоимость всех последствий. В отчётности за второй квартал позднее упоминались понесённые в связи с атакой расходы и продолжающиеся значительные дополнительные затраты на восстановление и усиление безопасности. В годовом отчёте инцидент упоминался среди нескольких факторов, повлиявших на результаты 2020 года, включая пандемию и выход из бизнесов. Внимательный читатель не должен механически объединять эти категории.

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

Финансовые раскрытия не отвечают на вопрос, какие системы клиентов были затронуты. Они показывают, что восстановление поставщика и непрерывность клиентов были экономически связаны.

Утечка данных и границы публичной определённости

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

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

Учётные данные или секреты требуют немедленной ротации. Публичные отчётные документы редко раскрывают всё это.

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

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

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

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

Автоматизация безопасности и приоритеты восстановления

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

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

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

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

Приоритет восстановления — это решение подотчётности, а не только техническая очередь.

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

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

Облачная зависимость без взлома панели управления публичного облака

Инцидент в Cognizant не был сбоем панели управления публичного облака, но облачная зависимость всё равно относится к делу. Поставщики ИТ-услуг работают через размещённую совместную работу, идентификацию, тикеты, удалённый доступ, порталы клиентов, мониторинг безопасности и облачные бизнес-процессы. Клиенты часто потребляют поставщика как услугу, даже если базовая работа охватывает людей, приложения, сети и клиентские операции. Атака шифровальщика на среду поставщика может нарушить облачно-опосредованную работу, даже если ни один публичный облачный провайдер не отказал.

В отчётности Cognizant упоминалась зависимость от затронутых систем и сетей для выполнения работы для клиентов и от систем, поддерживавших удалённую работу. В апреле 2020 года этот контекст удалённой работы не был случайным. Пандемия COVID-19 уже изменила допущения о предоставлении услуг в глобальном масштабе. Восстановление поставщика должно было происходить, пока сотрудники и клиенты приспосабливались к удалённым операциям. Это сделало идентификацию, управление устройствами, совместную работу и удалённую поддержку более центральными.

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

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

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

Решение клиента приостановить доступ

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

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

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

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

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

Непрерывность бизнеса — это не то же самое, что восстановление из резервных копий

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

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

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

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

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

Страхование, судебные разбирательства и издержки доверия

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

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

Судебный риск важен по аналогичным причинам. Клиенты могут задавать вопросы о том, выполнил ли поставщик договорные обязательства, были ли разумными меры безопасности, был ли своевременным уведомление, применимы ли кредиты за нарушение соглашений об уровне услуг или привели ли действия поставщика к убыткам клиента. Отчётность Cognizant не признавала каждую такую претензию; отчётность идентифицирует риски. Смысл подотчётности в том, что доказательства восстановления должны создаваться с расчётом на будущую проверку.

Решения, сроки, уведомления и одобрения восстановления следует документировать, потому что они могут позже определить ответственность и доверие.

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

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

Что показали бы более сильные доказательства для клиентов

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

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

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

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

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

Вопросы управления для клиентов и поставщиков

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

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

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

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

Наконец, управление должно учитывать региональную и трансграничную сложность. Регион обзора в этой статье следует за справочной организацией, но бизнес и клиенты Cognizant были глобальными. Переданные на аутсорсинг ИТ-услуги часто пересекают юрисдикции, режимы защиты данных и клиентские сектора. Это делает чёткие контракты, обязанности по уведомлению и индивидуальные доказательства для клиентов ещё более необходимыми.

Вывод о подотчётности

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

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

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

Публичные материалы Cognizant дают содержательные раскрытия о существовании инцидента, влиянии на услуги, позиции по локализации, затратах и сохраняющемся риске. Репортажи добавляют контекст о коммуникации с клиентами, ожидаемом финансовом влиянии и опасениях по поводу утечки данных. База данных по-прежнему оставляет частные детали частными. Это приемлемо только в том случае, если клиенты получили индивидуальные доказательства там, где они им нужны.

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