Краткое содержание

  • Подтвержденное событие:Ascension зафиксировала необычную активность 8 мая 2024 года, позднее описала событие как атаку программы-вымогателя и сообщила, что клинические операции были нарушены, при этом больницы и отделения оставались открытыми в рамках аварийных процедур. На ее публичной странице об инциденте позднее говорилось, что все затронутые системы, клинические функции и доступ к EHR были восстановлены. (Страница Ascension об инциденте в сфере кибербезопасности)
  • Влияние на непрерывность помощи:В собственном обновлении Ascension от 9 мая говорилось, что электронные медицинские карты, MyChart, часть телефонных систем и системы, используемые для заказа анализов, процедур и лекарств, были недоступны. Часть неэкстренных плановых процедур, анализов и приемов была временно приостановлена, а несколько больниц перенаправляли машины скорой помощи. (Обновление Ascension о сбое в работе сети)
  • Запись о данных:19 декабря 2024 года Ascension сообщила, что завершенный анализ данных показал, что инцидент затронул персональную информацию части нынешних и бывших пациентов, жителей пансионатов для пожилых и сотрудников. Типы данных различались и могли включать медицинскую, платежную, страховую, государственную идентификационную и иную персональную информацию; при этом признаков того, что данные были вынесены из EHR или других клинических систем, нет. Публичный портал утечек HHS OCR — федеральный реестр крупных сообщений об утечках по HIPAA. (Портал утечек HHS OCR)
  • Карта ответственности:Атаку совершили киберпреступники. Ascension контролировала доступ к сети, изоляцию клинических систем, обучение аварийным процедурам, порядок восстановления, повторное подключение партнеров, информирование пациентов, анализ данных и поддержку. Государственные органы контролировали правоохранительную деятельность, киберразведку, надзор за утечками по HIPAA и отраслевые рекомендации. Пациенты и врачи контролировали лишь узкие, стрессовые запасные шаги после того, как сбой добрался до койки пациента.

Программа-вымогатель добралась до койки пациента через рабочие процессы

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

В первом публичном заявлении Ascension от 9 мая 2024 года говорилось, что в среду 8 мая компания обнаружила необычную активность в отдельных технологических системах и полагает, что она вызвана инцидентом в сфере кибербезопасности. В заявлении говорилось, что доступ к некоторым системам был прерван, клиническая работа нарушена, а медицинские бригады начали использовать отработанные процедуры, чтобы продолжать безопасно оказывать помощь с минимальными последствиями. Ascension также сообщила, что привлекла Mandiant, уведомила соответствующие органы и расследует, какая информация, если такая была, пострадала. (Уведомление Ascension от 9 мая)

Более поздняя страница об инциденте формулирует это прямо: 8 мая Ascension подверглась атаке программы-вымогателя, и с тех пор все затронутые системы, клинические функции и доступ к EHR восстановлены. Эта формулировка важна, потому что переводит событие из разряда предполагаемого инцидента в разряд подтвержденной атаки вымогателей, а также определяет заявленную компанией точку завершения восстановления. (Страница Ascension об инциденте в сфере кибербезопасности)

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

Это не неудобство в коммуникации. Это другой режим работы.

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

Могла ли компания восстанавливать системы, не подключая обратно небезопасную инфраструктуру?

Эти вопросы операционные, а не риторические.

«Открыто» не значило «обычная помощь»

В обновлении от 9 мая, выпущенном в 17:30, Ascension перечислила несколько недоступных систем: электронные медицинские карты, MyChart, часть телефонных систем и различные системы, используемые для назначения анализов, процедур и лекарств. Пациентов просили приносить записи приемов, списки лекарств, номера рецептов или упаковки препаратов, чтобы медицинские бригады могли передавать потребности в лекарствах в аптеки по телефону. В сообщении говорилось, что неэкстренные плановые процедуры, анализы и приемы в ряде случаев временно приостановлены, а несколько больниц перенаправляют машины скорой помощи из-за аварийных процедур. (Страница Ascension об инциденте в сфере кибербезопасности)

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

Associated Press сообщило, что из-за атаки машины скорой помощи перенаправляли, анализы откладывали, а записи о пациентах были недоступны на всей территории системы, которая работает примерно в 140 больницах в 19 штатах. AP также сообщило, что пострадали и электронные записи, и MyChart, а персонал вернулся к бумажным записям. (Материал AP о сбоях в оказании помощи в Ascension) Эти сообщения согласуются с собственными заявлениями Ascension, но официальным источником по тому, что подтвердила сама Ascension, остается страница компании.

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

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

Аварийные процедуры были скрытым механизмом безопасности

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

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

Обновления Ascension от 7 и 11 июня показывают, почему сверка имела значение. По мере того как доступ к EHR восстанавливался волнами, Ascension предупреждала, что медицинские записи и другая информация за период с 8 мая по дату местного восстановления EHR могут быть недоступны, пока загружаются данные, собранные во время простоя. Пациентов просили в этот период обращаться в офис своего врача по поводу доступности записей и предупреждали, что сообщения на портале могут задерживаться. (Страница Ascension об инциденте в сфере кибербезопасности)

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

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

Восстановление EHR было клиническим приоритетом, а не просто IT-задачей

Ascension неоднократно называла восстановление EHR главным приоритетом. 29 мая компания сообщила, что доступ к EHR восстановлен на первом рынке и действует поэтапный план. 4 июня — что доступ восстановлен на рынках Флориды, Алабамы и Остина. 5 июня добавила Теннесси, Мэриленд и Центральный Техас. 7 июня — Оклахому и назвала целью восстановление EHR по всей системе к 14 июня. 11 июня перечислила Флориду, Алабаму, Теннесси, Мэриленд, Центральный Техас, Оклахому, Висконсин, Иллинойс, Канзас, часть Мичигана и часть Индианы, продолжая работу к сроку 14 июня. (Страница Ascension об инциденте в сфере кибербезопасности)

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

Как пациентов и службы скорой помощи информировали о том, в каком состоянии находится каждая местная площадка?

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

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

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

Непрерывность работы аптек стала практической проверкой помощи

Доступ к лекарствам был одним из самых наглядных примеров того, как программа-вымогатель покидает дата-центр и входит в повседневную жизнь. Ascension просила пациентов приносить упаковки препаратов, номера рецептов и списки лекарств, чтобы медицинские бригады могли передавать потребности в лекарствах в аптеки по телефону. Позже Ascension сообщила, что розничные аптеки Ascension Rx, службы доставки на дом и специализированные аптеки открыты и могут обеспечить потребности в рецептах, а врачи могут передавать рецепты в аптеки Ascension Rx в электронном виде. (Страница Ascension об инциденте в сфере кибербезопасности)

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

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

Spectrum News из Висконсина рассказал о местных аптеках, столкнувшихся с кибератакой на Ascension и необходимостью обеспечивать пациентов хроническими препаратами. (Материал Spectrum News об аптеках) Этот локальный взгляд полезен, потому что сбой в аптеках часто рассредоточен. Он не всегда выглядит как драматичный отказ больницы. Он выглядит как пациент, фармацевт и врач, пытающиеся восстановить достаточно информации, чтобы продолжить терапию.

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

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

Публичная картина показывает, что Ascension признала проблему аптек. Оставшийся вопрос ответственности — насколько единообразно эти обходные пути работали в разных штатах и на разных площадках.

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

В обновлениях от 21 и 24 мая Ascension обозначила еще одну недооцененную проблему восстановления: партнерам и вендорам нужно было заново подключаться к сети. Ascension сообщила, что начала регулярные контакты с ключевыми партнерами и вендорами, чтобы предоставить информацию для восстановления их подключения к сети Ascension. 24 мая компания сообщила, что многие вендоры и партнеры начали подключаться заново и возобновлять услуги, что должно ускорить восстановление. (Страница Ascension об инциденте в сфере кибербезопасности)

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

Именно здесь пересекаются непрерывность государственного сектора и локализация данных. Медицинские данные не хранятся в одном аккуратном месте. Они проходят через клинические системы, файловые серверы, порталы пациентов, процессы выставления счетов, лабораторные интерфейсы, аптечные пути, каналы страховщиков и среды вендоров. Ascension позднее сообщила, что злоумышленники вынесли файлы с семи из примерно 25 000 серверов, использовавшихся в основном сотрудниками для повседневных и рутинных задач, и что некоторые файлы могут содержать PHI и PII. Компания также сообщила, что у нее нет доказательств выгрузки данных из EHR и других клинических систем. (Страница Ascension об инциденте в сфере кибербезопасности)

Эти заявления проводят полезную границу, но также подчеркивают, почему доступность важнее физического местоположения. Запись может юридически находиться у некоммерческой системы здравоохранения США и все же оказаться раскрытой, если до нее можно добраться через скомпрометированный рабочий процесс, рутинный файловый сервер или путь партнера. Суверенитет данных в здравоохранении — это не только то, где данные хранятся; это кто может их касаться, копировать, передавать, экспортировать, просматривать или подключаться к ним снова после утечки.

Поэтому важным доказательством после инцидента является не только «системы восстановлены». Это «соединения восстановлены с проверкой». Система здравоохранения должна быть в состоянии показать, что повторное подключение партнеров не вернуло скомпрометированные учетные данные, устаревшие доверительные отношения, непроверенный удаленный доступ или немониторируемые пути данных.

Утечка данных — это не то же самое, что клинический сбой

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

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

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

Граница в заявлении Ascension важна: данные пациентов были затронуты, но, по словам Ascension, по-прежнему нет доказательств, что данные были вынесены из EHR и других клинических систем, где хранятся полные записи пациентов. Это значимая гарантия, а не полное устранение вреда. Дата оказания услуги, тип лабораторного анализа, код процедуры, страховой номер или государственный идентификатор все равно могут быть чувствительными. Тот факт, что полные записи EHR, согласно публичным данным Ascension, не были вынесены, не делает данные с рутинных файловых серверов безвредными.

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

Государственные и отраслевые сообщения показывают, как запись о конфиденциальности превратилась в запись о защите потребителей. Генеральный прокурор Мичигана Дана Нессел призвала пациентов и сотрудников Ascension рассмотреть бесплатный мониторинг кредитной истории после того, как Ascension предупредила, что часть персональной информации могла быть затронута. (Уведомление генерального прокурора Мичигана) Healthcare Dive позднее сообщил о федеральном масштабе утечки в 5,6 млн человек в контексте публичных уведомлений об утечках. (Материал Healthcare Dive об утечке) Эти источники не заменяют уведомление Ascension или портал HHS, но показывают, что последствия для конфиденциальности оставались активными после клинического восстановления.

Объяснение с вредоносным файлом не снимает ответственности

12 июня Ascension сообщила, что установила, как злоумышленник получил доступ: сотрудник одного из ее учреждений случайно скачал вредоносный файл, который он считал легитимным. Ascension заявила, что у нее нет оснований полагать, что это было что-то иное, чем честная ошибка. (Страница Ascension об инциденте в сфере кибербезопасности)

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

Страница HHS о правиле безопасности излагает стандарт правила в общих чертах: требуются административные, физические и технические гарантии для защиты конфиденциальности, целостности и доступности электронной защищенной медицинской информации. (Правило HHS о безопасности) HHS также поддерживает материалы с рекомендациями по кибербезопасности для организаций, подпадающих под HIPAA, и деловых партнеров. (Материалы HHS по кибербезопасности) Руководство CISA StopRansomware также подчеркивает готовность, предотвращение, планирование реагирования, резервное копирование и коммуникации. (Руководство CISA StopRansomware)

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

Формулировка «честная ошибка» гуманна. Она избегает превращения отдельного работника в козла отпущения. Но гуманный язык должен сочетаться с организационным обучением. Обвинять работника — это слабая ответственность. Рассматривать действие работника как один сигнал в более крупной системе контроля — сильнее.

Финансовое восстановление не измерило нагрузку на пациентов

Финансовые раскрытия Ascension показывают, что событие имело операционные последствия за пределами страницы об инциденте. В сентябре 2024 года Ascension сообщила, что операции в мае и июне пострадали от инцидента в сфере кибербезопасности, что привело к снижению выручки из-за перерыва в деятельности, расходам на устранение проблем и другим операционным расходам. Компания также сообщила, что баланс и уровень ликвидности остались прочными и ликвидности достаточно, чтобы продолжать оказывать помощь. (Финансовые результаты Ascension за IV квартал 2024 финансового года)

В феврале 2025 года Ascension сообщила, что операции в IV квартале 2024 финансового года пострадали от майской кибератаки, но восстановление объемов в 2025 финансовом году продолжилось, а объем пациентов в тех же учреждениях вырос примерно на 5–6 процентов с момента киберсобытия, при этом ключевые операционные KPI возвращаются к нормальному состоянию. (Финансовые результаты Ascension за II квартал 2025 финансового года)

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

Запись об ответственности была бы сильнее, если бы послеинцидентная отчетность разделяла как минимум четыре показателя восстановления. Первый — техническое восстановление: какие системы были чистыми и доступными. Второй — клиническое восстановление: какие функции помощи вернулись к обычному рабочему процессу. Третий — восстановление записей: как была сверена аварийная документация. Четвертый — поддержка пациентов: какие задержки, перенаправления, переносы и уведомления о данных требовали продолжения.

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

Отрасль восприняла атаку на больницу как вопрос общественной функции

Ascension сообщила, что уведомила правоохранительные органы и правительственных партнеров, включая ФБР, CISA, HHS, и Американскую больничную ассоциацию, и поделилась соответствующими данными об угрозах с H-ISAC, чтобы партнеры и коллеги по отрасли могли защитить себя. (Страница Ascension об инциденте в сфере кибербезопасности) Эта межведомственная рамка важна, потому что атака программы-вымогателя на больницу — это не только частное дело между жертвой и злоумышленником.

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

Американская больничная ассоциация в своей работе по кибербезопасности неоднократно называла атаки программ-вымогателей на больницы вопросом безопасности пациентов. Ее страница по кибербезопасности подчеркивает готовность больниц и систем здравоохранения к киберустойчивости. (Ресурсный центр AHA по кибербезопасности) AHA также подготовила резюме обсуждения в Совете Безопасности ООН, на котором президент Ascension рассказал, что майская атака нарушила операции в больницах Ascension, зашифровала тысячи компьютерных систем и сделала электронные медицинские карты недоступными. (Материал AHA о заседании Совета Безопасности ООН)

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

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

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

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

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

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

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

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

Заявленная тема «Суверенитет и локализация данных» — это не узкий вопрос о том, где физически находились серверы. Дело Ascension показывает более важный вопрос здравоохранения: к каким данным можно было добраться через какие пути доступа в ходе обычной работы?

Ascension сообщила, что злоумышленники вынесли файлы с семи из примерно 25 000 серверов, использовавшихся в основном сотрудниками для повседневных и рутинных задач. Компания также сообщила, что эти файлы могут содержать PHI и PII. Это сочетание показательно. Чувствительные данные могут жить в рутинных рабочих областях, выгрузках, вложениях, общих папках, рабочих очередях, отчетных файлах, отсканированных документах и временных операционных хранилищах. EHR может быть полной записью пациента, но это не единственное место, где появляется информация о пациенте.

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

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

Правильный урок не в том, что EHR никогда не должна подключаться к другим системам. Здравоохранение не может так работать. Урок в том, что каждая вторичная копия данных пациента становится частью клинического и конфиденциального радиуса поражения.

Как выглядела бы более полная доказательная база

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

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

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

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

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

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

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

Урок — устойчивость у койки пациента

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

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

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

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

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