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

Управление рисками при проверке безопасности транспортного слоя (TLSI)

Большая мощь связана с риском

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

Проверка безопасности транспортного слоя (Transport Layer Security Inspection, TLSI), также известная как «прерывание и проверка безопасности транспортного слоя» (TLS break and inspect) – это механизм безопасности, позволяющий корпорациям дешифровать трафик, проверить расшифрованный трафик на угрозы, а затем снова зашифровать его, прежде чем он войдет в сеть или выйдет из нее. Введение такой функциональности в корпоративную безопасность повышает уровень сканирования продуктов безопасносности, охраняющих границы сети, но привносит и новые риски. Хотя эти риски и не являются несущественными, их можно уменьшить.

Рис. 1а. Зашифрованный трафик

Рис. 2а. Проверка безопасности TLS. Слева: канал TLS установлен между клиентом и сервером. Все данные, проходящие по этому каналу, зашифрованы, и поэтому не проверяются. Справа: устройство, заменяющее канал TLS цепочкой TLS, дешифруя данные, проверяя их и блокируя, если они злонамеренные

Что такое TLSI – в деталях

TLSI обычно производится устройством прокси, которое открывает чистый текст, лежащий в основе сессии TLS. Это позволяет устройствам проверки трафика вроде фаерволлов, систем обнаружения и предотвращения вторжения (Intrusion Detection/Prevention Systems, IDS/IPS) обнаружить индикаторы угрозы или компрометирования. При этом TLSI также включает проверку старого трафика Secure Sockets Layer (SSL). Ниже в деталях разбираются три основные функции TLSI в прямой прокси (forward proxy): управление потоком трафика прямой прокси, установление сессий TLS и выдача сертификатов доверия. Риски станут очевидными по мере понимания деталей механизма, используемого TLSI.

Поток трафика прямой прокси

Прямая прокси – это сетевое устройство, перехватывающее запросы от внутрисетевых клиентов и направляющее эти запросы на серверы или во внешние сети. Когда внешние серверы отвечают, эти ответы передаются прямой прокси, и потом прямая прокси посылает эти ответы внутрисетевым клиентам. Функционал TLSI, встроенный в прямую прокси, между границей корпоративной сети и внешней сетью, такой, как Интернет, защищает корпоративных клиентов от среды с высокими рисками за пределами прямой прокси.

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

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

Сессии TLS

TLSI происходит в реальном времени, поскольку клиенты TLS устанавливают зашифрованные соединения с внешними серверами. Она дешифрует трафик, заменяя сквозную сессию TLS «цепочкой TLS», состоящей из двух независимо работающих соединений TLS: одно устанавливается между внешним сервером и «прямой прокси», а второе – между прямой прокси и клиентом TLS, который попытался инициировать сессию TLS на внешний сервер. Эти два соединения TLS позволяют принимать решения о том, как обрабатывать (например, блокировать, пропустить, проверить или переслать) трафик одного соединения, прежде чем передать этот трафик другому соединению. Несмотря на то, что у нас два отдельных соединения, данные проходят так, как если бы оно было одно. Такая цепочка TLS рискует потенциальным ухудшением защиты TLS от того, что было принято клиентом. Версия TLS или методы шифрования, используемая одним независимо работающим соединением, могут быть слабее тех, которые используются другим. Это может привести к пассивному злоупотреблению сессией, или злоупотреблению уязвимостями, связанными с более слабыми версиями TLS или методами шифрования.

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

Доверяйте только сертификатам от надежных центров сертификации (CA) для установления сессий TLS со внешними серверами. Убедитесь, что прямая прокси проверяет имя и срок окончания действия сертификата, его использование, и попытки проверить его статус аннулирования. Неожиданные изменения в сертификатах TLS, полученных от внешних серверов, могут означать атаки злоумышленников на прокси. Отслеживайте серверные сертификаты с течением времени, чтобы обнаружить неавторизованные изменения и сообщить о них администратору безопасности. Примените прозрачность сертификатов, чтобы сообщать владельцам внешних серверов о неавторизованных сертификатах.

Центр сертификации

Устройства прямой прокси TLSI содержат функцию центра сертификации (CA), которая создает и подписывает новые сертификаты, представляющие внешние серверы клиенту: CA, встроенный в прямую прокси, выдает сертификат, отражающий параметры сертификата запрошенного внешнего сервера. Система TLSI использует этот сертификат во время обработки трафика TLS в соединении между клиентами TLS и прямой прокси. Клиенты TLS сконфигурированы доверять этому CA.

Основной риск, связанный с CA, встроенным в TLSI – потенциальное злонамеренное использование этого CA для выдачи неавторизованных сертификатов, которым будут доверять TLS-клиенты. Злоупотребление доверенным CA может позволить преступнику подписывать злонамеренный код, чтобы обойти IDS/IPS хоста или для внедрения злонамеренных сервисов, притворяющихся перед клиентами законными корпоративными сервисами или внешними серверами.

Рис. 2. Взломанный центр сертификации. 1 – взломав CA, встроенный в устройство, атакующий может подделывать сертификаты или подтверждать сертификаты. 2 – если CA взломан, нельзя проверить, откуда клиенты получают данные. 3 – это позволяет атакующим как видеть, так и считывать данные, а также внедрять вредоносные данные. Это относится и к внутреннему (не проверяемому) трафику.

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

Управляйте доступом и применяйте минимальные привилегии

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

Хотя TLSI обеспечивает инструментам предотвращения потери данных доступ к чистому тексту, полученному из зашифрованного трафика, дополнительный риск инсайдерской угрозы связан с авторизованными администраторами безопасности, ответственными за управление реализацией TLSI. Эти авторизованные индивидуумы могут злоупотребить своими правами доступа для захвата паролей и других конфиденциальных данных, видимых в дешифрованном трафике. Применяйте принципы минимально необходимых привилегий и разделения обязанностей, чтобы гарантировать, что только авторизованные администраторы TLSI имеют доступ к данным, а другие администраторы (например, те, которые отвечают за конфигурацию устройства), такого доступа не имеют. Используйте отдельную роль аудитора для определения изменений политики TLSI и других потенциальных злоупотреблений привилегиями администратора.

В США корпорации, использующие функционал TLSI, подчиняются законам и правилам, относящимся к конфиденциальности. Корпорации должны знать о соответствующих требованиях (например, для данных о финансах, здоровье и скрытой информации, которой обмениваются адвокаты со своими клиентами), и сконфигурировать TLSI так, чтобы предотвратить неавторизованное обнародование данных.

Делайте хорошо и один раз

Чтобы минимизировать описанные выше риски, разрыв и проверка трафика TLS должны выполняться в корпоративной сети только один раз. Избыточные TLSI, в которых трафик между клиентом и сервером дешифруется, проверяется и снова шифруется одной прямой прокси, а потом перенаправляется другой, делающей то же самое, не должны применяться. Множественные проверки могут сильно усложнить диагностику сетевых проблем с трафиком TLS. Кроме того, множественные проверки еще более скрывают сертификаты при попытке определить, можно ли доверять какому-либо серверу. В этом случае «самая внешняя» прокси принимает решения о том, каким серверным сертификатам и CA можно доверять, и является единственной локацией, где производятся проверки внешних сертификатов. Встраивайте любые необходимые дополнительные проверки в единственную изолированную зону проверки, вместо того, чтобы добавлять множество зон проверки, каждую из которых придется изолировать, обезопасить и отслеживать. Наконец, одной реализации TLSI достаточно для обнаружения угроз трафика: дополнительные TLSI будут работать с одним и тем же трафиком. Если первая реализованная TLSI обнаружит угрозу, уничтожит сессию и сбросит трафик, дополнительные реализации TLSI будут бесполезными, поскольку они даже не получат трафик для дальнейших проверок. Избыточные TLSI повышают риск, предоставляют преступникам дополнительные возможности получения неавторизованного доступа к дешифрованному трафику, и не дают никаких дополнительных преимуществ.

Сложности разработки

Многие продукты TLSI «срезают углы», чтобы удовлетворить требованиям к производительности. Выбирайте те продукты, которые протестированы независимыми организациями на правильную реализацию потока данных, функций TLS и CA. АНБ рекомендует продукты, протестированные Национальным Товариществом Информационной Надежности (National Information Assurance Partnership, NIAP), и сконфигурированные в соответствии с рекомендациями производителя во время тестирования.

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

• TLS 1.3 реализует ограничения, не допускающие некоторые сокращения, широко используемые в продуктах TLSI. TLSI может привести к ошибкам сессий для приложений, использующих исключительно TLS 1.3.
• Внешние серверы, требующие клиентской аутентификации TLS, не будут доверять подписанному сертификату TLSI, и будут отклонять сессии, использующие клиентские сертификаты, выданные встроенным CA.
• Привязка токенов TLS привязывает токены безопасности к определенным используемым сессиям TLS. Системы TLSI могут привести к тому, что сессии или токены будут отвергнуты клиентским приложением, или сервером, или обоими.
• Hypertext Transfer Protocol Strict Transport Security (HSTS) требует, чтобы Hypertext Transfer Protocol над TLS (HTTPS) в будущем использовался с доверенными сертификатами, и чтобы весь контент также принимался через HTTPS. Если приложение-клиент TLS пытается следовать требованиям HSTS, но не доверяет отдельному центру сертификации TLSI, клиент будет отвергать сессии TLSI и не даст пользователям просмотреть предупреждения браузера.
• TLSI также может вызывать неожиданное падение сессий, если они используют привязку сертификатов (certificate pinning) на клиентском уровне. Привязка сертификатов часто используется для автоматических обновлений програмного обеспечения.
• Domain Name System-Based Authentication of Named Entities (DANE), еще один метод, при котором приложение требует особого сертификата в сессии TLS, также может вызвать сбой сессии TLSI. DANE обычно используется для обеспечения безопасности почтовых соединений от сервера к серверу.

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

Владельцы сетей должны понимать, что TLSI – не панацея. Она может только проверять трафик SSL и TLS, если клиенты (и серверы для взаимной аутентификации) доверяют сертификату прокси. Поскольку некоторые устройства прерывания и проверки безопасности могут блокировать сессии TLS, которые не допускают проверки, это также может прервать правомерную активность.

Минимизация риска

Администраторы безопасности не могут защитить от того, что они не видят. Современные тактики, техники и процедуры (TTP) позволили атакующим задействовать зашифрованный трафик, чтобы проскользнуть мимо инструментов отслеживания трафика. Профессионалы в области безопасности сражались с этими TTP, используя TLSI. Возможности TLSI, реализованные в корпоративных прямых прокси, могут обеспечить видимость зашифрованного сетевого трафика, чтобы обнаружить злонамеренное использование шифрования, но устройства, прерывающие трафик TLS и проверяющие его, могут стать первоочередными целями для злоупотребления и внести дополнительные риски в корпоративную сеть. Корпорации должны тщательно взвесить эти риски против преимуществ TLSI и ее альтернатив, и если TLSI будет реализована, устранять эти риски. Более того, поскольку приложения, несовместимые с TLSI, могут привести к появлению задержек и ошибок у пользователей, постоянное управление и поддержка помогают администраторам балансировать между безопасностью и поддержкой пользователей. Рассмотренные меры могут сократить риски, связанные с введением TLSI, обеспечить индикаторы, предупреждающие администраторов о возможном взломе систем TLSI, и минимизировать ненамеренное блокирование правомерной сетевой активности. Таким путем администраторы безопасности могут успешно добавить TLSI в свой арсенал и продолжать усовершенствовать методы противодействия современным преступникам и TTP.