Как ограничить распространение инцидента внутри корпоративной сети

Почему локальный инцидент становится общей проблемой

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

Если между этими ресурсами разрешено слишком много сетевых взаимодействий, скомпрометированный узел может стать отправной точкой для дальнейшего распространения атаки.

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

Как распространяется инцидент внутри сети

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

• Рабочая станция. Компрометация пользовательского компьютера становится первоначальной точкой присутствия.
• Смежные ресурсы. Проверяется доступность файловых ресурсов, серверов и корпоративных приложений.
• Учётные записи. Полученные права могут использоваться для обращения к другим системам.
• Инфраструктурные сервисы. При недостаточных ограничениях атака постепенно затрагивает более важные компоненты.

Какие связи между системами действительно нужны

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

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

Чем точнее определены допустимые направления взаимодействия, тем меньше возможностей для распространения инцидента.

Как ограничить область воздействия

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

Зачем разделять критичные и пользовательские ресурсы

Рабочие станции пользователей и критичные серверы имеют разный уровень риска и выполняют разные функции. Размещать их в среде с практически неограниченным взаимным доступом нежелательно.

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

Чем важнее система, тем строже должны быть правила взаимодействия с ней.

Почему внутреннюю сеть нельзя считать полностью доверенной

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

Поэтому сам факт нахождения внутри сети не должен автоматически давать широкие возможности взаимодействия с другими ресурсами.

Запросы между различными частями инфраструктуры необходимо контролировать в соответствии с назначением систем и установленными правилами безопасности.

Как защитить критичные серверы

Серверы с важными корпоративными данными и инфраструктурными функциями требуют дополнительных ограничений. Доступ к ним должен предоставляться только тем системам и пользователям, которым он необходим.

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

Такой подход сокращает количество возможных путей к критичному ресурсу при развитии инцидента.

Как административный доступ влияет на распространение инцидента

Отдельного внимания требуют административные соединения. Если привилегированная учётная запись используется на скомпрометированном устройстве или доступна из обычного пользовательского сегмента, последствия инцидента могут значительно увеличиться.

Административные подключения следует отделять от повседневной пользовательской работы и разрешать только из предусмотренных точек управления.

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

Почему важно контролировать межсегментный трафик

Само логическое разделение инфраструктуры не решает задачу, если между её частями разрешён практически любой трафик. Необходимо понимать, какие соединения проходят между зонами и зачем они нужны.

Правила взаимодействия следует формировать на основе реальных сервисов и бизнес-процессов. Неиспользуемые и избыточные разрешения увеличивают потенциальную область распространения инцидента.

Как обнаружить попытку распространения

Ограничение связей необходимо дополнять наблюдением за сетевой активностью. Необычные обращения между системами могут указывать на развитие инцидента.

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

Анализ таких событий помогает обнаруживать подозрительную активность до того, как проблема затронет значительную часть инфраструктуры.

Как изолировать проблемный участок

При обнаружении инцидента важно иметь возможность ограничить взаимодействие с затронутой системой или частью сети. Чем быстрее это можно сделать, тем меньше времени остаётся для дальнейшего распространения угрозы.

При этом изоляция должна учитывать работу критичных сервисов. Поэтому способы локализации желательно определить заранее, а не разрабатывать их уже во время инцидента.

Почему правила нужно регулярно пересматривать

Корпоративная инфраструктура постоянно меняется: появляются новые приложения, серверы, филиалы и способы подключения. Вместе с ними возникают новые сетевые взаимодействия.

Временное разрешение, созданное для внедрения системы или проведения работ, может сохраниться после завершения задачи. Со временем такие исключения увеличивают количество возможных путей между различными частями сети.

Поэтому правила доступа и межсистемного взаимодействия необходимо периодически проверять и удалять соединения, которые больше не нужны.

С чего начать локализацию возможных инцидентов

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

Особое внимание следует уделить избыточным связям: доступу, который существует исторически, но больше не требуется для работы приложений или сотрудников.

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