Реагирование на инциденты безопасности: кто принимает решения
В момент инцидента нет времени выстраивать цепочку управления. Разбираю, что нужно определить заранее и почему это управленческий, а не технический вопрос.
Когда инцидент безопасности происходит - а рано или поздно он происходит - первые тридцать минут определяют, насколько хорошо или плохо всё пройдёт. В эти тридцать минут нужно понять масштаб, принять первые решения, начать координацию. Делать это без подготовки - значит терять время на организационные вопросы вместо того, чтобы заниматься самим инцидентом.
Большинство организаций думают о реагировании на инциденты как о технической задаче: есть ИТ-команда, есть антивирус, есть файрвол. Это не так. Реагирование на серьёзный инцидент - это управленческая задача с техническим исполнением.
Что нужно решить до инцидента
Первое - кто объявляет инцидент инцидентом. Это не очевидный вопрос. Аналитик по безопасности видит аномалию - это инцидент или подозрение? Кто принимает решение эскалировать, а не "подождать и посмотреть"? Без явного ответа на этот вопрос организации склонны занижать серьёзность ситуации и реагировать с запозданием.
Второе - кто принимает решения при инциденте. Технический руководитель отвечает за изоляцию и восстановление. Но решение об отключении критичных систем, о том, уведомлять ли клиентов, о взаимодействии с регуляторами - это уровень топ-менеджмента. Важно, чтобы этот человек был идентифицирован, доступен и знал о своей роли.
Третье - кто и когда уведомляет внешние стороны. Клиентов, партнёров, регуляторов. Слишком раннее уведомление при нечёткой картине создаёт панику. Слишком позднее - создаёт правовые и репутационные риски. Это решение требует участия юридической службы и PR, не только ИТ.
Ошибки, которые я вижу чаще всего
Первая - план реагирования существует только на бумаге. Написали документ, положили в папку, никто не читал, не тренировался, не проверял. В момент реального инцидента этот документ бесполезен.
Вторая - технические специалисты принимают решения, которые должны приниматься на управленческом уровне. Это происходит не из желания превысить полномочия, а потому что менеджмент недоступен или не знает, что его нужно привлечь.
Третья - коммуникация внутри компании не выстроена. Кто что знает и когда - разные подразделения получают информацию в разное время, через разные каналы, противоречивую. Это добавляет хаоса поверх технической проблемы.
Минимальная готовность
Несколько конкретных вещей, которые должны существовать до инцидента:
Список контактов для разных сценариев - кто кому звонит при компрометации данных, при недоступности систем, при подозрении на утечку. Список должен быть актуальным и доступным не только в корпоративных системах.
Ролевая матрица: кто принимает технические решения, кто принимает бизнес-решения, кто коммуницирует с внешними сторонами.
Хотя бы одна учебная тревога в год - разбор гипотетического сценария с теми людьми, которые будут реально реагировать. Не как формальность, а как возможность найти пробелы в процессе до того, как они проявятся в реальности.
Один вопрос для проверки
Задайте своей команде прямо сейчас: "Если сегодня в 22:00 мы обнаружим, что кто-то получил несанкционированный доступ к нашим клиентским данным - кто принимает решение и что происходит в первый час?"
Если ответ уверенный и конкретный - у вас есть основа. Если нет - это разговор, который стоит провести до того, как он понадобится.