Croc

8 шагов для успешного восстановления после атаки вымогателей

8 шагов для успешного восстановления после атаки вымогателей 8 шагов для успешного восстановления после атаки вымогателей 8 шагов для успешного восстановления после атаки вымогателей
01.12.2021

Согласно отчету об обзоре программ-вымогателей, опубликованному в июне компанией Keeper Security, 49% компаний, пострадавших от подобного ПО, заплатили за данные, а еще 22% отказались сообщить, заплатили они или нет. В какой-то степени причина заключается в отсутствии резервных копий, в частности, в отсутствии пригодных для использования резервных копий.

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

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

1. Держите резервные копии изолированными

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

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

Некоторые облачные платформы включают управление версиями как часть продукта без дополнительных затрат. Например, Office 365, Google Docs и онлайн-системы резервного копирования, такие как iDrive, хранят все предыдущие версии файлов, не перезаписывая их. Даже если вымогатель атакует, а зашифрованные файлы копируются, процесс резервного копирования просто добавляет новую, поврежденную версию файла - он не перезаписывает старые резервные копии, которые уже есть.

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

2. Используйте методы хранения с однократной записью

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

3. Храните несколько типов резервных копий

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

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

4. Защитите резервный каталог

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

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

5. Создайте резервную копию всего, что нужно создать

Когда в 2016 году район острова Кадьяк на Аляске был поражен программой-вымогателем, у муниципалитета было около трех десятков серверов и 45 компьютеров сотрудников. Все данные были зарезервированы, говорит ИТ-супервайзер Пол Ван Дайк, который руководил восстановлением. Были зарезервированы все серверы, кроме одного. «Я пропустил один сервер, который оценивал стоимость недвижимости», - говорит он.

Требование выкупа было небольшим по сегодняшним меркам, всего половина биткойна, который тогда стоил 259 долларов США. Специалист заплатил выкуп, но использовал ключ дешифрования только на этом сервере, так как не доверял целостности систем, восстановленных с помощью злоумышленников. «Я предположил, что все данные были грязными», - говорит он. Сегодня все покрыто технологией резервного копирования.

Более крупные организации также сталкиваются с проблемой обеспечения того, чтобы все, что нужно резервировать, было действительно зарезервировано. Согласно опросу Veritas, ИТ-специалисты считают, что в среднем они не смогут восстановить 20% своих данных в случае полной их потери. Не помогает то, что у многих, если не у всех компаний, есть проблемы с теневым ИТ.

«Люди стараются выполнять свою работу наиболее удобным и эффективным способом, - говорит Рэнди Уоткинс, технический директор Critical Start. - Часто это означает, что нужно находиться вне поля зрения и делать что-то самостоятельно».

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

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

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

6. Резервное копирование всех бизнес-процессов

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

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

«Бизнес-процесс работает как оркестр, - говорит Дэйв Бург, руководитель отдела кибербезопасности в EY Americas. - У вас есть разные части оркестра, издающие разные звуки, и если они не работают последовательно друг с другом, то вы слышите шум».

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

«Отсутствует понимание технологической инфраструктуры и взаимосвязей, - говорит Бург. - Недостаточное понимание того, как технология действительно работает, чтобы сделать бизнес».

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

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

7. Используйте узлы аварийного восстановления и автоматизацию для ускорения восстановления

По данным Veritas, только 33% ИТ-директоров считают, что они могут оправиться от атаки вымогателя в течение пяти дней. «Я знаю компании, которые тратят много денег на кассеты и отправляют их в Iron Mountain», - говорит Уоткинс. «У них нет времени ждать час, чтобы вернуть кассеты, и 17 дней, чтобы восстановить их».

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

«Это несложно, - говорит Уоткинс. - У вас может быть скрипт, который копирует вашу инфраструктуру и поддерживает ее в другой зоне доступности или у другого провайдера в целом. Затем подготовьте автоматизацию, чтобы вы могли начать воспроизведение. Нет времени на восстановление, всего 10 или 15 минут, чтобы включить ее. Может быть, целый день, если вы прошли тестирование ".

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

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

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

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

Джонсон признает, что существует культурный барьер для активного инвестирования в кибербезопасность. «Мы - реакционное общество, но кибербезопасность, наконец, стала очевидной: инвестиции. Унция предотвращения стоит фунта лечения».

8. Тестируйте, тестируйте и снова тестируйте

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

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

Проверять нужно не только технологии, но и человеческий фактор. «Люди не знают того, чего не знают, - говорит Голден. - Или нет регулярного аудита их процессов, чтобы убедиться, что люди придерживаются политики».

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

Автор: Maria Korolov

Warning: array_rand(): Second argument has to be between 1 and the number of elements in the array in /home/sec1297941/securitymedia.org/docs/bitrix/templates/mediapro_main/components/bitrix/catalog.element/info/template.php on line 319

Warning: in_array() expects parameter 2 to be array, null given in /home/sec1297941/securitymedia.org/docs/bitrix/templates/mediapro_main/components/bitrix/catalog.element/info/template.php on line 324

Warning: in_array() expects parameter 2 to be array, null given in /home/sec1297941/securitymedia.org/docs/bitrix/templates/mediapro_main/components/bitrix/catalog.element/info/template.php on line 324

Комментарии 0