Один из самых неудобных вопросов в кибербезопасности звучит просто: что делать, если злоумышленник пользуется системой именно так, как она задумана? Он входит под действующей учетной записью, открывает документы, выгружает данные, подключает внешнее приложение. Технически все разрешено. Только интересы компании в этом процессе никто не представляет.
Сам по себе это не новый подход. Но облачные сервисы, удаленная работа и большое количество связей между системами сделали его гораздо удобнее для атакующего. Для того, чтобы получить доступ, не обязательно устанавливать вредоносную программу на компьютер жертвы. Можно похитить сессию авторизации, убедить службу поддержки изменить настройки доступа, либо воспользоваться учетной записью подрядчика. Успешный вход говорит о том, что система приняла предъявленные ей данные. Но вот кто именно ими воспользовался и зачем – это уже вопрос к безопасности.
Старые атаки тоже никуда не делись
На фоне новых сценариев легко забыть о старых. Уязвимый VPN-шлюз по-прежнему может стать входом в корпоративную сеть. Сетевое оборудование зачастую контролируется хуже, чем рабочие компьютеры. А значит, отсутствие тревоги со стороны антивируса еще ничего не говорит о состоянии всей инфраструктуры.
Для SOC (Security Operations Center, центр мониторинга и реагирования на киберугрозы) это означает изменение самого предмета наблюдения. Недостаточно смотреть на отдельные события. Нужно видеть цепочку.
Например, сотрудник обращается в поддержку. После этого меняется способ подтверждения его входа. Затем появляется новое приложение с доступом к корпоративным данным. Каждый шаг по отдельности может иметь вполне нормальное объяснение. Но вместе они уже требуют внимания. Кто инициировал изменения? Зачем? Кто их подтвердил? Что произошло после этого? Разделение ответственности между IT, безопасностью, поддержкой и бизнесом не должно разделять само расследование.
На расследование остается все меньше времени
Скорость здесь становится отдельной проблемой. По данным CrowdStrike, в криминальных атаках за 2025 год среднее время от первоначального доступа до перехода атакующего на другую систему составило 29 минут. Это не означает, что любая атака развивается по такому сценарию. Но цифра хорошо показывает масштаб проблемы: у защитника может быть очень мало времени между первым скомпрометированным доступом и дальнейшим развитием атаки.
Поэтому при пересмотре защиты я бы начинал не с выбора очередного инструмента, а с простого упражнения. Что сможет сделать посторонний, если прямо сейчас получит доступ к учетной записи нашего сотрудника? До каких данных он доберется? Где сможет повысить свои права? Какие действия ему доступны? На каком этапе мы его заметим? Ответы на эти вопросы гораздо полезнее абстрактного разговора о «повышении уровня защищенности».
Из этого уже следуют конкретные решения: где ограничить доступ, какие обновления поставить в приоритет, какие события обязательно мониторить. Отдельно стоит посмотреть на сервисные учетные записи и доступы подрядчиков. Доверие, выданное когда-то для конкретной задачи, имеет неприятное свойство оставаться гораздо дольше самой задачи.
Что делать, когда атака уже началась
Есть еще один вопрос, который лучше не оставлять на момент инцидента: кто и при каких условиях имеет право остановить атаку? Если компрометация подтверждена, может потребоваться завершить активные сессии, заблокировать учетную запись, отозвать доступ приложения к данным или изолировать устройство.
При этом простая смена пароля не всегда решает проблему. Если злоумышленник уже получил другие способы доступа, они могут продолжить работать независимо от нового пароля.
Часть технических действий вполне можно автоматизировать. Но автоматическая блокировка должна учитывать качество сигнала и цену ошибки. Заблокировать скомпрометированную учетную запись администратора – это одно. Но автоматически остановить критический производственный процесс из-за недостаточно проверенного сигнала – совсем другое. Границы здесь лучше определить заранее. Во время инцидента времени на разработку таких правил уже не будет.
ИИ ускоряет и атаку, и защиту
Искусственный интеллект постепенно становится инструментом обеих сторон. Атакующий может использовать его для подготовки убедительных писем, сообщений в поддержку или других элементов социальной инженерии. Защитнику ИИ необходим для анализа большого количества событий, поиска связей и ускорения расследования.
Но есть важное ограничение. Убедительный ответ модели еще не является доказательством. В SOC любую гипотезу, предложенную ИИ, нужно проверять по исходным данным. Модель может подсказать, куда посмотреть, помочь связать события или сократить время анализа. Но решение о вмешательстве в работу компании должно опираться на проверенные факты. ИИ может ускорить путь к решению. Он не снимает с человека ответственность за это решение.
Защитить систему недостаточно. Нужно уметь ее восстановить
Есть еще одна часть киберустойчивости, о которой вспоминают обычно уже после атаки. Речь идет о восстановлении. Злоумышленники давно научились атаковать не только рабочие системы, но и резервные копии. А если данные были похищены, восстановление инфраструктуры само по себе не обязательно решает проблему. Украденную информацию можно использовать для шантажа. Поэтому резервная копия должна быть не просто записью в расписании. Нужно понимать, где она хранится, насколько она защищена от изменения и удаления, можно ли восстановить из нее критические системы и сколько времени это реально займет. И лучший способ проверить это – попробовать восстановление до того, как оно действительно понадобится.
Киберустойчивость проверяется не презентацией
О киберустойчивости сегодня говорят все чаще, в том числе на уровне государственного регулирования и цифровой политики. Но сама по себе концепция мало что меняет.В конечном счете все проверяется довольно простыми вопросами. Удалось ли заметить опасное действие? Удалось ли понять, что происходит? Удалось ли вовремя ограничить доступ? И, если атака все-таки привела к остановке системы, удалось ли восстановить критический процесс?
Для меня именно здесь проходит граница между формальной защищенностью и реальной киберустойчивостью. Каждый серьезный инцидент должен оставлять после себя не только отчет о произошедшем, но и конкретные изменения. В настройках, правилах доступа, мониторинге, полномочиях или резервном копировании. Иначе компания будет каждый раз все лучше описывать, как именно ее атаковали, и при этом сохранять условия для следующей атаки.
Источник: Курсив · Клим Гольцман