Жизненный цикл реагирования на инциденты — как настроить его в небольшой компании?

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

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

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

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

я чёт не понял, а почему выключать-то нельзя? если питание отрубить вирус же переестает работать не логичнее сразу из розетки дернуть?

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

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

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

Две недели ведения заметок дают лучший результат, чем шестимесячные прогнозы. Конечно, если ваша ситуация отличается, всё меняется.

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

Если напишете результат здесь, это поможет и другим.

Я долго занимался этим вопросом. Две недели ведения заметок дают лучший результат чем шестимесячные прогнозы.

Если делаете впервые, начните с малого масштабирование потом. Надеюсь это будет полезно.

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

Это мое мнение, не утверждаю, что оно единственно верное.

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

Если напишете результат здесь, это поможет и другим.

Обсуждение размылось, давайте структурируем. Чем сложнее отменить решение, тем медленнее его принимайте.

Если напишете результат здесь, это поможет и другим.

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

Я бы пошел этим путем.

Сохранил.

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

Я бы пошел этим путем.

Я столкнулся с тем же два года назад. Непроверенная резервная копия — не резервная копия.

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

Расскажу, как это делается на практике. Чем сложнее отменить решение, тем медленнее его принимайте.

Проверено опытом.