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

Именно это на примере недавних кейсов заказчиков иллюстрирует Александр Герман, руководитель лаборатории расследования и реагирования на инциденты ИБ компании RuSIEM.

10 ошибок реагирования на инциденты. Несогласованность процедур, отсутствие регламентов и немного психологии
© It-world

Первая ошибка — паника. Это самая настоящая проблема, поскольку она усугубляет и без того сложную ситуацию. Что произошло у нашего заказчика: злоумышленники выложили в открытый доступ конфиденциальную информацию. Казалось бы, понятно: выложить файлы — не обязательно единственная цель. Почти всегда задача злоумышленников — посеять панику и подтолкнуть ИТ- и ИБ-службы к импульсивной, а потому с вероятностью практически 100% ошибочной реакции.

В наборе «бей», «замри» или «беги» любая реакция — неправильная, потому что инстинктивная (ошибка № 2). Чтобы в случае инцидента действовать максимально быстро и правильно, нужно заранее смоделировать алгоритм таких действий, зафиксировать его во внутреннем регламенте (не иметь его — ошибка № 3) и протестировать на киберучениях. Это позволит избежать еще одной ошибки (№ 4) — попытки устранить симптомы вместо причин проблемы. В одном из недавних кейсов сотрудники заказчика попытались обойтись поверхностными мерами. В результате исчезла информация о конфигурации и логах нескольких серверов компании.

Ошибка № 5 — не устанавливать обновления. После того как команда RuSIEM провела работы по криминалистическому анализу, открылась до боли знакомая картина: ряд обновлений не был установлен и информация об этом была в открытом доступе. Злоумышленники получили возможность пользоваться этим окном в течение долгого времени, методично проводя свои атаки.

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

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

Возвращаясь к теме регламента и зрелости бизнеса и процессов внутри него: в идеале указанный документ должен содержать также порядок взаимодействия ИТ и ИБ в случае инцидента вне зависимости от того, кто первый о нем узнал. Потому что отвечать за результат придется все-таки безопаснику. И да, когда вы пойдете к руководителю, не спрашивайте, что вам делать. Предлагайте варианты — именно этого, как правило, от вас и ждут. Чтобы говорить с руководителем компании на его языке, следует не брезговать изучением бизнес-процессов своей организации, а также постоянно мониторить изменения в бизнес-инфраструктуре. Не делать этого — ошибка № 7.

Ошибка № 8 — несогласованность действий ИТ- и ИБ-подразделений. Часто для реагирования на инциденты информационной безопасности требуется помощь сотрудников отдела ИТ. Поэтому подразделение не интегрировано в общий для всех процесс отработки инцидента, то время реагирования увеличивается многократно. За этот период вирус на рабочей станции способен перерасти в настоящую эпидемию. Во избежание подобных последствий и требуется наличие плана реагирования на инциденты с распределением обязанностей и регламентом взаимодействия. Следующий уровень — автоматизация реагирования, построенная на шаблонах регистрации инцидента с расстановкой задач и контролем сроков их выполнения.

Не уделить этому нужное внимание или выстроить модель угроз и правила корреляции неправильно — ошибка № 9. Да, сложные средства защиты информации требуют тонкой настройки: развернуть систему, завести в нее источники событий, настроить правила корреляции. Как вариант, чтобы ускорить этот процесс, можно настраивать систему «на кошках», поручив сотруднику симулировать события информационной безопасности, отслеживать и фиксировать реакцию системы на них.

Неправильная настройка СЗИ — ошибка № 10. Как гласит интернет–фольклор, «по возможности старайтесь этого избегать».