Что? Где? Куда?

Что? Где? Куда?

Пока локальная сеть состоит из десятка устройств, ее схему и правила межсетевых экранов (МСЭ) может без усилий запомнить один сетевой администратор. По мере роста сети в нее добавляются новые устройства, зачастую от других производителей, появляются различные серверы управления, системы безопасности и пр. Хороший вариант, если в этом процессе удалось сохранить четкое и задокументированное понимание структуры сети и не потерять ее управляемость. В ином случае администраторы и пользователи начинают сталкиваться с проблемами, связанными со слабой управляемостью и отсутствием понимания структуры сети. Далее будут разобраны три довольно распространенных случая, характеризующих такую проблему.

Случай 1: Заявка на открытие сетевого доступа открывается слишком долго (иногда неделю или больше)

Довольно распространенная проблема: SLA не выполняется, сроки сгорели, бизнес-пользователи не получили вовремя необходимый доступ, а сетевой администратор все ищет тот самый последний МСЭ, который блокирует почти открытый доступ.

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

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

Для решения подобных проблем существуют специальные системы управления доступами МСЭ. Одной из таких систем является Tufin Orchestration Suite. Tufin собирает конфигурации и правила фильтрации с сетевых L3-устройств и МСЭ, анализирует их и строит полные маршруты прохождения трафика.

Функционально Tufin состоит из следующих компонентов:

• SecureTrack, собирающий и анализирующий конфигурации МСЭ;
• SecureChange, управляющий заявками на доступ;
• SecureApp, управляющий приложениями в сети.

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

Рисунок 1. Запрос на карту прохождения трафика

После получения подробной информации о маршруте прохождения трафика администратору сети остается только внести изменения в конфигурацию на соответствующих МСЭ. Это можно сделать самостоятельно или довериться автоматизации. Для этого в Tufin есть компонент SecureChange. Он может выступать как самостоятельной системой управления заявками, так и интегрироваться с существующей Service Desk системой. В любом случае SecureChange позволит определить МСЭ, на которых требуется провести изменения, характер необходимых изменений (в человекочитаемом представлении и в виде готовых команд для ввода в интерфейсе), риски этих изменений, а также может сам провести все необходимые изменения и проверить их корректность.

Таким образом, за счет дополнительной автоматизации ряда задач Tufin может сократить время обработки заявки во много раз (вплоть до нескольких минут).

Кроме того, у системы есть ряд приятных особенностей:

• проверка требуемого заявкой доступа и закрытие заявки, если доступ уже есть;
• возможность делать ревизию правил на предмет их необходимости через определенное время;
• возможность провести полную ревизию правил МСЭ на предмет их актуальности, корректности и рисков;
• механизм добавления своих политик безопасности для предварительной проверки рисков открытия доступов (например, запрет доступа из DMZ_1 в DMZ_2 будет закрывать заявки на открытие такого доступа, как несоответствующие политике ИБ).

Случай 2. Владельцы бизнес-приложений не могут явно управлять необходимыми им сетевыми доступами

Владельцы и администраторы бизнес-приложений (БП) в своей работе обычно не оперируют конкретными требованиями к настройке МСЭ: им важен доступ, например, от этого сервера к этой базе данных, и не важно, как пойдет трафик. Зато важно, чтобы между хостами его БП не пропадала сетевая доступность. Довольно неприятная ситуация, если приложение вдруг перестало работать из-за сетевой недоступности, и владелец БП не видит, между какими хостами блокируется трафик. Для решения проблемы администраторам сети обычно требуется повторно определить требования приложения к сетевым доступам. В таком случае проблема может быть решена в приемлемые сроки, если на ИТ-систему есть паспорт или технические требования к сети. Иначе, если подобных документов нет или они неактуальны (например, один из серверов переехал на другой ip-адрес), то проблема восстановления работы приложения может стать очень трудоемкой или потребовать открытия слишком широких правил на МСЭ.

Решение подобных проблем также относится к задачам систем управления доступами МСЭ.  Рассмотрим решение подобной проблемы на примере другой системы подобного класса, а именно Algosec Security Management Solution.

Algosec, как и Tufin, имеет три функциональных модуля (три с половиной, если считать AutoDiscovery):

Firewall Analizer, содержащий в себе всю логику анализа конфигураций и политик МСЭ;
FireFlow, управляющий заявками на изменение и обеспечивающий автоматическое применение изменений;
BusinessFlow c компонентом AutoDiscovery, обеспечивающий поиск и обнаружение в трафике приложений и управляющий ими.

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

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

Рисунок 2. Приложение BusinessFlow

Среди множества функций BuinessFlow можно выделить наиболее интересные:

• контроль сетевой доступности между хостами приложения с автоматическим созданием заявки, если такого доступа нет;
• возможность миграции хостов на другие ip-адреса с автоматическим созданием и отслеживанием заявки на изменение доступов;
• возможность видеть риски приложений после интеграции со сканерами уязвимостей (например, с MaxPatrol);
• возможность увидеть влияние конкретного МСЭ на затрагиваемые приложения (какие приложения «упадут», если мы перезагрузим данный роутер);
• возможность автоматической трансляции сетевых требований БП в набор правил для всех задействованных МСЭ.

По итогу, владелец приложения получает удобный и понятный интерфейс управления своими приложениями, а сетевой администратор облегчает свою работу, поскольку BusinessFlow автоматически транслируют требования типа «от этого сервера в этой СУБД» с созданием заявки в FireFlow с набором команд для МСЭ.

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

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

На текущий момент Skybox Security Suite – одна из немногих систем, которая может справиться с этой проблемой. Skybox относится к классу систем управления доступами и уязвимостями. Он также, как и Tufin и Algosec получает информацию о конфигурации МСЭ и может ими управлять, но, кроме этого, помогает управлять уязвимостями: он имеет специальный модуль, непредназначенный для отслеживания векторов атак злоумышленников и расстановки приоритетов при закрытии уязвимостей.

В Skybox присутствуют следующие функциональные компоненты:

• Firewall Assurance – получение конфигураций МСЭ и их анализ;
• Network Assurance – анализ сетей и сетевой доступности;
• Change Manager – управление изменениями на МСЭ;
• Vulnerability Control – управление уязвимостями.

Последний компонент Vulnerability Control – это то, что отличает Skybox от других систем подобного класса. Он позволяет осуществлять управление уязвимостями и контроль векторов атак.

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

Рисунок 3. Пример маршрута атаки

Очевидно, что если доступ на МСЭ для реализации какой-либо уязвимости закрыт, то работа с ней становится менее приоритетной. Это главное отличие в подходе к управлению уязвимостями по сравнению с классическими сканерами уязвимостей, которые требуют немедленного закрытия всех обнаруженных уязвимостей. В конечном итоге это серьезно сокращает трудозатраты на управление ИБ при том же уровне защищенности.