Шифровальщик ударил, бэкап не спас. За 48 часов вернулись в строй только 4 компании из 800+

Fenix24 проверила больше 800 организаций, переживших атаки шифровальщиков, и обнаружила среди них всего 4 компании, которые подошли близко к собственным срокам восстановления в 24-48 часов. Даже у этой четвёрки речь шла лишь о части рабочих процессов, а вернуть инфраструктуру в рабочий режим полностью быстрее чем за несколько недель не получилось ни у кого. Цифры компания собрала в первом отчёте State of Recoverability, который вышел 15 сентября и опирается на 500+ реальных кейсов восстановления после атак вымогателей.

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

У 99,2% проверенных организаций отдельного плана восстановления систем идентификации не нашлось вообще, от слова совсем. Там, где такой документ всё же существовал, он трещал по швам при первом реальном контакте с атакой:

• Active Directory обычно оказывался среди первых компонентов инфраструктуры, терявших работоспособность в ходе атаки;
• 94% компаний завязали резервные механизмы на тот же каталог пользователей, который позже попадал под контроль преступников;
• почти пятая часть первых двух суток восстановления уходила только на работу с идентификацией;
• на возврат минимально нужной инфраструктуры после появления хотя бы одного доверенного источника аутентификации уходило ещё от 72 часов.

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

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

С многофакторной аутентификацией ситуация не лучше, а местами даже смешнее, если бы не было так грустно:

• только 15% организаций использовали полноценный MFA на входе в сеть;
• для критических административных консолей показатель падал до 5%.

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

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

Целые резервные копии тоже спасают далеко не всегда, и это отдельный привет всем, кто хранит бэкапы для галочки. В 38% случаев с формально уцелевшими бэкапами Fenix24 всё равно фиксировала, что вернуть бизнес к работе через них не получается:

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

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

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

У проблемы восстановления есть и вполне физическая сторона, банальное место на дисках и пропускная способность сети:

• в 82% случаев организациям не хватало места для хранения восстановленных данных;
• в 38% случаев сеть не могла передать нужный объём информации с достаточной скоростью;
• Fenix24 советует начинать не с полного списка систем, а с одного сервиса, от которого напрямую зависит выручка;
• для этого сервиса стоит заранее прописать карту зависимостей вместе с внешними поставщиками и сторонними сервисами.

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

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

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

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

Ранее сообщалось, что переговоры с хакерами-вымогателями превратились в самостоятельное направление внутри атак с использованием ransomware. По словам старшего директора Intelligence Fusion Team компании Intel 471 Дэйва Росса, группировки теперь представляют собой не разрозненные команды с одним ноутбуком, а организованные структуры с аналитиками, переговорщиками и даже сторонними колл-центрами, а сами атаки строятся как конвейер с чётким распределением обязанностей.