Из-за атаки вымогателя медучреждение не могло принять пациентов

Из-за атаки вымогателя медучреждение не могло принять пациентов

Из-за атаки вымогателя медучреждение не могло принять пациентов

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

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

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

«Мы реорганизовали наши системы, в том числе используем бумажные документы. Система электронных медкарт находится в автономном режиме на время исследования и проведения следственных мероприятий», — говорит пресс-секретарь.

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

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

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

«Это очень яркий пример того, насколько серьезное влияние на здоровье и жизнь пациентов могут оказать различные киберинциденты», — отметила Ребекка Герольд, глава ИБ-компании Simbus. — «Отрадно наблюдать, что некоторые врачи и медсестры, которые столкнулись с этим, теперь гораздо активнее поддерживают внедрение систем для киберзащиты сетей медицинских учерждений».

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

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

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

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

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

RSS: Новости на портале Anti-Malware.ru