Столкнулись с вирусом-вымогателем — пишу о том, как всё было и какие выводы сделали

Мы столкнулись с тем же два года назад. Разница только в одном: наши бэкапы были не чистыми.

Производство стояло три дня. Теперь копия бэкапа лежит отдельно и защищена от изменений. Дорогой урок.

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

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

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

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

В-четвертых, отчет после инцидента. Когда горячие дни проходят, все возвращаются к норме, и выводы не пишутся. Если отчет об инциденте не написан в течение недели, он не будет написан никогда.

Хочу зацепиться за один момент: вы говорите, что «уязвимостей не было». Как вы это проверили?

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

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

Вопрос справедливый, отвечу.

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

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

В итоге мы переустановили затронутые машины с нуля. Путь медленнее, но надежнее.

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

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

И замеряйте время восстановления. Фраза «у нас есть бэкап» не так ценна, как «мы поднимемся за восемь часов». Если вы не знаете второе, попробуйте в субботу.

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

Автоматический отчет о сканировании и пентест — это не одно и то же. Проверено опытом.

Спасибо, что написали об этом, это действительно так. Если делаете впервые, начните с малого, масштабирование потом.

Исправьте, если я ошибаюсь.

Вы правы. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Конечно, если ваша ситуация отличается, всё меняется.

А как вы решили этот вопрос? Непроверенная резервная копия — не резервная копия.

Интересно, есть ли те, кто делает иначе.

Эта тема в архиве.

Верно.

Буду рад, если напишете о результате.

После того случая мой взгляд на вещи изменился. Изменение платежных данных никогда не подтверждается через тот же канал.

На этом всё извините если затянул.

Я проходил через это, расскажу. Без измерений мы всегда приходим к одному и тому же.

Пишите, если есть вопросы, отвечу по мере возможности.

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

Исправьте, если я ошибаюсь.

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

ответ сильно звисит от отрасли, универсального правила нет.

Хочу предупредить. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Не полагайтесь на одну меру защиты; действуйте слоями. Пишите, если есть вопросы, отвечу по мере возможности.