В этой статье мы рассмотрим основные понятия и терминологию, связанную с недопустимыми событиями в информационной безопасности, а также различные типы, методы идентификации, процедуры реагирования, превентивные меры и стратегии минимизации рисков, а также тенденции и будущее в области определения недопустимых событий в информационной безопасности.
Любая современная организация полагается на информационные системы почти так же, как организм на кровеносную систему. Перебои мгновенно отражаются на репутации и кошельке, а иногда и на жизнях людей. Поэтому события, которые способны парализовать процессы, уничтожить данные или обрушить доверие клиентов, относят к категории недопустимых. Ниже разберёмся, о чём именно идёт речь, научимся вовремя замечать первые звоночки и поймём, какие меры помогут «погасить пожар», пока он не перешёл в степень стихийного бедствия.
Термин пришёл из риск-менеджмента. Недопустимое событие — это эпизод или цепочка действий, последствия которых выводят риски за границу «приемлемо»: нарушается конфиденциальность, целостность или доступность ключевой информации. Достаточно вспомнить простой пример: база клиентов с паспортами и телефонами «утекла» в открытый доступ — «красный» уровень угрозы без скидок.
С точки зрения стандартов, определение встречается в ISO/IEC 27005 и в российских методических документах ФСТЭК. Везде упор делается на два критерия: масштаб ущерба и вероятность наступления. Как только комбинация «часто + дорого» превышает установленный порог терпимости, событие признаётся недопустимым.
На практике порог закрепляется в политике безопасности: «потеря доступа к CRM на более чем 30 минут» или «утечка персональных данных более 1000 клиентов». Такая «красная линия» избавляет от бесконечных споров и помогает реагировать без лишней бюрократии.
Чтобы не путаться, удобно раскладывать угрозы по нескольким плоскостям.
Чёткая классификация помогает строить «карты угроз» и разрабатывать адресные контрмеры. «Поймать всё сразу» нереально, а вот последовательно закрывать красные зоны — вполне.
И последнее: не забывайте, что рейтинги угроз живые. Вчера DDoS стоил вам часа простоя и потерянных заказов, а сегодня та же атака бьёт по системе анализа биржевых сделок и несёт миллионы убытков. Пересматривайте приоритеты хотя бы раз в год или после крупных изменений архитектуры.
Рыбак рыбака видит издалека, а специалист по безопасности — недопустимое событие. Только глядеть приходится не на реку, а на потоки логов и телеметрии.
Параллельно фиксируются метрики: SLE (единичный потенциальный убыток), ALE (годовой ожидаемый убыток), MTTR (время на восстановление). Они показывают, насколько опасность перешагнула «допустимый» порог.
Для мелких компаний совет один: начинайте хотя бы с централизации логов и четких процедур эскалации. Сложные пилоты UEBA можно подключить позже, когда потоки данных станут плотнее.
Инструментов так много, что глаза разбегаются. Однако «соберите всё и сразу» редко работает — бюджет не резиновый, а людей, умеющих крутить каждую консоль, ещё меньше.
Для оценки зрелости инфраструктуры полезно заглянуть в открытый список CIS Controls — лаконично и по делу. Проверили пункт, внедрили, закрыли — и двигаемся дальше по списку.
Важный совет: чем больше автоматизации, тем строже нужны процессы. Иначе на входе получаем гору «красных» тревог, а на выходе — уставших аналитиков, которые перестают верить в сигналы системы.
Техника без людей бессильна: никто не нажмёт красную кнопку отключения сервера, если не понимает, когда и зачем это делать. Поэтому хорошая политика безопасности включает инструкции понятные, а не «копипасту из договоров времён ASCII-терминалов».
Главные блоки процесса:
План реагирования должен быть живым документом. После каждой отработанной ситуации делайте пост-мортем: что сработало, где тормозили, какие данные потеряли. Ошибки — лучший бесплатный преподаватель, если на них не заканчивать обучение.
Вопрос «нужна ли нам безопасность?» отпадает, когда в дверь стучится проверка. В России действуют 152-ФЗ «О персональных данных», 187-ФЗ «О безопасности критической информационной инфраструктуры», приказы ФСТЭК, Банка России, Роскомнадзора. Для международного бизнеса добавьте GDPR. Штрафы растут — а с ими интерес начальства к темам «конфид-лайн» и «расследование утечек».
Совет простой: выстроить систему так, чтобы она «по умолчанию» выполняла регуляторные требования. Тогда аудит превращается из кошмара в рутинную проверку чек-листов.
Полезны и отраслевые стандарты. Банкам, например, не обойтись без ГОСТ Р 57580, энерго-компаниям — без методик ФСТЭК по АСУ ТП. Универсальным «зонтиком» остаётся линейка ISO 27000.
Классический цикл выглядит так:
Хорошая практика — заранее иметь шаблоны «playbook». Например, если «звонит» антивирус, а в журнале Process Creation мелькает vssadmin delete shadows
, скрипт автоматически запрашивает у EDR опорожнить сеть от соответствующего хэша файла — и только потом зовёт аналитика.
И да: проверяйте резервные копии. Печально слышать от потерпевших: «Всё было на NAS, но никто не заметил, что полгода не прогонялся test-restore». Лучше «лениво» тестировать каждый месяц, чем один раз в кризис понять, что ленту нечем прочитать.
Профилактика всегда дешевле лечения, даже если кажется дорогой в моменте.
Не забывайте о человеческом факторе: одна непроверенная флешка способна обрушить годовой труд инженеров. Поэтому «холодный» контроль периметра сочетается с «тёплой» корпоративной культурой: сотрудники знают, что безопасность — не пугало, а повседневный инструмент.
Недопустимые события — это не метафора страховых актов, а реальный список сценариев, каждый из которых может «выстрелить» в самый неподходящий момент. К счастью, внимание к риск-менеджменту, практика непрерывного мониторинга и грамотные процессы реагирования превращают хаос в управляемую погоду.
Установите понятные пороги допустимости, обновляйте карту угроз, автоматизируйте рутинные задачи и, главное, не бойтесь признавать ошибки — они подсказывают, где броня тоньше, чем казалось. Тогда даже самое громкое «тревога!» будет означать не конец света, а чёткий сигнал к действию.