Число атак с использованием программ-шифровальщиков не снижается – риск столкнуться с вымогателями есть у всех компаний независимо от размера и отрасли. Как избежать ошибок при реагировании на такие инциденты, рассказывает Виталий Гололобов, архитектор решений облачного провайдера Linx Cloud.
Программы-шифровальщики – не новый вид вредоносного программного обеспечения (ВПО), но особенно часто их стали использовать в последние несколько лет. Так, в 2024 году число атак шифровальщиков в России выросло на 44%. В 10% случаев целью атаки было не получение выкупа, а нанесение урона жертве.
Значительное увеличение масштаба и сложности атак с помощью программ-вымогателей – один из заметных трендов в сфере информационной безопасности. Поэтому компаниям, которым удалось избежать атак или успешно их отразить, не стоит терять бдительность. В первую очередь им важно опираться на плачевный опыт менее удачливых компаний. Разберем основные ошибки при защите бизнеса от шифровальщиков.
Немного о поведении шифровальщиков
Задача атакующего, который использует программу-вымогатель, заставить жертву заплатить выкуп. Это значит, что ему нужно не просто зашифровать инфраструктуру или ее чувствительные сегменты, но и максимально усложнить компании самостоятельное устранение проблемы. Для этого злоумышленник будет стараться:
Важно помнить, что злоумышленники активно эксплуатируют фактор стрессовой ситуации, чтобы побудить жертву на необдуманные решения. Понимая цели и механику действий хакеров, стоит выстраивать защиту и составлять план действий на случай атаки.
Ошибка №1: недостаточная глубина хранения бэкапов
По нашим оценкам, около половины компаний пренебрегают правилами работы с бэкапами, в том числе золотым правилом бэкапирования «3-2-1», касающимся форматов и площадок хранения бэкапов.
На сегодняшний день бэкап во многих компаниях из-за экономии ресурсов выглядит как ежедневные инкременты и фулл-копии, создаваемые раз в неделю, с глубиной хранения одна-две недели. При такой политике шанс восстановить незараженную инфраструктуру крайне мал – организация буквально пытается восстановиться из уже зашифрованной копии.
По нашему опыту, рекомендуемый срок бэкапа должен составлять не менее 30 дней. Это коррелирует со средним временем, которое атакующие тратят на анализ и закрепление внутри инфраструктуры компании до начала процесса шифрования.
Ошибка №2: упование на disaster recovery
Многие компании используют резервные площадки, которые дублируют их основную ИТ-инфраструктуру или ее наиболее критичные компоненты.
Это помогает в случае инцидента с основным ЦОД, но очень редко работает в случае атаки с применением шифровальщика – компании стремятся минимизировать время выполнения заданий репликации, чтобы снизить RPO при наступлении инцидента.
Существует большой риск, что синхронизация между площадками произойдет, когда основная уже заражена, а присутствие шифровальщика еще не обнаружено. В результате зараженными и зашифрованными окажутся сразу обе площадки. Также вероятна ситуация, когда на резервную площадку в процессе синхронизации попадут уже зашифрованные данные.
Disaster recovery защитит вас от катастрофы (отключение электричества, пожар, наводнение, выход из строя оборудования на одной из площадок), но не от вредоносного воздействия на уровне ПО.
Ошибка №3: поспешное развертывание бэкапов
Кибермошенники часто стараются найти бэкап и удалить либо заразить его. В случае, когда злоумышленники не добрались до данных, которые хранятся у облачного провайдера, компания стремится как можно быстрее вернуть работоспособность сервиса и часто начинает восстанавливаться прежде, чем будут окончательно локализованы момент и путь заражения.
Это может закончиться повторным шифрованием, поскольку последние резервные копии данных уже были заражены или путь хакера в компанию еще не устранен – он по-прежнему имеет доступ к инфраструктуре и может доставить ВПО. Это достаточно очевидный кейс, но в моменте сотрудники компании, находясь в состоянии стресса, забывают о такой вероятности и о необходимости проверить, какие бэкапы можно использовать и ликвидирована ли угроза.
Удостоверьтесь, что вы восстанавливаетесь в нескомпрометированную инфраструктуру.
Ошибка №4: превалирование технических мер над организационными
Многие ошибки имеют в корне одну причину – это спешка и стресс. Чтобы нивелировать эти факторы, важно иметь заранее разработанный сценарий реагирования на инцидент с использованием шифровальщика, в том числе с указанием людей, которые будут принимать конечные решения.
На уровне организационных мер важно выполнить две основные задачи:
Возможна ситуация, когда в критический момент оказывается, что нет ответственного за действия компании во время атаки. Например, назначенный сотрудник недавно уволился, а другого назначить забыли. Поэтому роль ответственного лучше закреплять не за конкретным человеком, а за должностью, не забывая снабжать занимающего ее специалиста подробной инструкцией. В ней (хотя бы на базовом уровне) должны быть прописаны параметры, согласно которым сотрудник принимает те или иные решения.
Так, после восстановления из резервных копий важно создать новые задачи резервного копирования и остановить старые. Иначе может возникнуть ситуация, когда компания восстанавливала систему и работала в ней, пока задачи резервного копирования выполнялись для зашифрованной инфраструктуры.
Пусть лучше сценарий реагирования никогда не пригодится, чем его не окажется в нужный момент, и борьба с последствиями превратится в сумбурные действия, которые принесут больше вреда, чем пользы.
Проверьте, назначен ли у вас ответственный за действия в случае компрометации инфраструктуры и составлен ли план действий.
***
Все вышеперечисленное является не «серебряной пулей», а лишь гигиеническим минимумом, на уровне «мойте руки перед едой». Для обеспечения полноценной безопасности инфраструктуры необходимы специальные средства защиты периметра (от антивируса и песочницы до статического анализа кода, WAF и постоянного обучения персонала), а также квалифицированные ИБ-эксперты.
© 2025 Linx
Закажите консультацию специалиста
