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

Денег на безопасность выделяли немало. По данным расследования, в 2024 году расходы на ИБ составляли сотни миллионов рублей. Подрядчиков было несколько, самой безопасностью занимались две структуры: департамент ИБ и аппарат заместителя гендиректора по ИТ и ИБ. Структур две, бюджетов два. Результатом, судя по всему, не владел никто.

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

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

Поэтому январь интересует меня больше июля.

Что считалось результатом реагирования: злоумышленников вытеснили или периметр действительно обезопасили? Кто проверил, что точка входа закрыта? Кто оценил риск для заказчика? И кто должен был сказать бизнесу: мы пока не уверены, что всё закончилось?

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

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

Можно провести аудит, получить отчёт, отработать инцидент, принять работы подрядчика. На каждом этапе будут документы, ответственные и положительные статусы. А потом выяснится, что бизнес всё это время оставался под угрозой.

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

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