Технология виртуального патчинга (Virtual Patching) — одна из самых популярных в области защиты приложений. Виртуальное закрытие уязвимостей ограничивает доступ к ним до их ликвидации разработчиком. В результате компании получают возможность спокойно дожидаться, пока поставщик того или иного программного обеспечения опубликует официальные «заплатки».
- Введение
- Что такое виртуальный патчинг?
- Достоинства и недостатки виртуального патчинга
- Продукты с функциями виртуального патчинга
- Методология виртуального патчинга
- Выводы
Введение
Одной из основных причин успешных атак на ИТ-инфраструктуру компаний является наличие в ней уязвимостей. Эксплуатация брешей злоумышленниками позволяет нарушить работу бизнес-систем, запустить вредоносную программу на атакуемом хосте, скачать конфиденциальные данные или даже получить полный контроль над сервером. Согласно исследованиям, около 60 % утечек данных произошли из-за эксплуатации известных уязвимостей, для которых не успели установить обновления.
Для исправления программных изъянов необходимо устанавливать обновления сразу же после их выхода, т. к. это сокращает временной интервал, в котором компания подвержена атакам через эксплуатацию «незакрытых» уязвимостей. При применении «классических патчей» возникает ряд трудностей. Многие организации не так уж строго следуют расписанию обновлений. Кроме того, зачастую внесение изменений в работающую систему требует простоя бизнес-процессов, а некоторые компоненты информационных систем бывает сложно или невозможно обновить.
Кроме того, если уязвимость будет выявлена в коммерческом приложении, клиент, скорее всего, не сможет самостоятельно изменить исходный код. В этой ситуации он попадает в зависимость от вендора, так как ему приходится ждать официального выпуска патча. Поставщики обычно имеют чрезвычайно жёсткие даты выпуска обновлений, а следовательно, официально поддерживаемый патч может быть недоступен в течение длительного периода.
Кроме того, организация может использовать коммерческое приложение, поставщик которого вышел из бизнеса, или версию программы, которая больше не поддерживается разработчиком. В этих ситуациях устаревший код приложения не может быть исправлен. Дополнительная сложность возникает в тех случаях, когда организация вынуждена использовать устаревший код из-за добавления собственных пользовательских функций поверх исходного кода от поставщика. Эта функциональность привязана ко критически важному бизнес-приложению, и попытки обновления могут нарушить её.
Что такое виртуальный патчинг?
Виртуальный патчинг — это быстрая разработка и оперативное внедрение политики безопасности, предназначенной для предотвращения эксплуатации уязвимости. Это процесс, при котором посредством разных технологий блокируются векторы атаки, через которые может быть проэксплуатирована уязвимость. Таким образом организацию можно защитить без затрат и операционных простоев на аварийное обновление либо циклы обновления и, конечно, без дополнительных расходов из-за взломов системы, которая не была вовремя обновлена.
Виртуальный патчинг может применяться на внешнем или внутреннем периметре сети, на межсетевых экранах уровня приложений (WAF) и т. д. Он осуществляется несколькими способами, каждый из которых имеет свои преимущества.
Первый тип основан исключительно на анализе сетевого трафика. Продукты, предлагающие этот тип виртуального исправления, используют сигнатуры, регулярные выражения и сопоставление шаблонов для выявления вредоносной активности и блокирования соответствующих запросов.
Второй тип основан на тех же принципах, однако он предлагает более надёжный способ — определение критериев блокировки запросов при помощи языка правил и управления состоянием. ModSecurity является примером такого виртуального патчинга.
Виртуальный патчинг первых двух типов имеет ряд недостатков. Из-за отсутствия понимания контекста эти методы известны тем, что генерируют ложные срабатывания. Сигнатуры и сопоставление шаблонов — это эвристические подходы, которые не могут обеспечить необходимую для высокой эффективности точность. Плохо написанный виртуальный патч такого типа может заблокировать легитимный трафик, нарушить нормальное выполнение приложения и добавить дополнительную нагрузку на механизмы защиты. Кроме того, виртуальные патчи такого типа очень «хрупки» в случае изменения параметров приложения. Например, когда в веб-приложении происходит изменение уязвимого URL-адреса или параметров HTTP, виртуальный патч нуждается в повторной настройке.
Эти подходы защищают конкретные исходные данные, но оставляют уязвимые компоненты незащищёнными. Если существует несколько точек входа, ведущих к одному и тому же уязвимому компоненту, то виртуальный патч не сможет защитить его. Поскольку код остаётся уязвимым даже после применения виртуального патчинга, некоторые называют эти подходы «защитой уязвимостей», а не исправлением.
Третий тип — это естественная эволюция виртуального патчинга при использовании компиляторов Just-in-Time современных платформ (таких как Java и Common Language). Находясь внутри приложения и имея возможность контролировать каждую инструкцию до её выполнения, можно достичь «истинного» виртуального патчинга. Теперь можно поставить виртуальный патч, функционально эквивалентный реальному патчу поставщика, без изменения исходного кода приложения или его двоичных файлов, гарантируя при этом, что компонент исправлен должным образом и больше не уязвим.
На сегодняшний день технологии виртуального патчинга продвинулись до такой степени, что он может стать автоматизированным процессом, который не требует ручного вмешательства и будет эффективен и, возможно, более надёжен, чем ручное исправление.
Достоинства и недостатки виртуального патчинга
Преимущества виртуального патчинга:
- Виртуальный патчинг оперативно снижает риск использования эксплойта до тех пор, пока не будет протестирован и внедрён полноценный и постоянный патч.
- Виртуальный патчинг позволяет компаниям поддерживать нормальный цикл применения патчей без прерывания бизнес-процессов, если уязвимость обнаруживается между выпусками полноценных патчей.
Недостатки виртуального патчинга:
- Виртуальный патчинг может не покрывать все возможные пути и локации, посредством которых работает эксплойт.
- Есть вероятность, что после применения виртуального патча, который сразу продемонстрирует свою эффективность, компания посчитает вопрос решённым и забудет об установке постоянного патча.
- В то время как виртуальный патч может оперативно устранить основные риски от появления новой уязвимости, он не может принести столько же пользы в долгосрочной перспективе, как постоянный патч, потому что виртуальное исправление не может устранить «врождённые» дефекты в уязвимом приложении.
Продукты с функциями виртуального патчинга
Изначально виртуальный патчинг был придуман вендорами IPS / IDS много лет назад. Позже его перенесли в WAF, а совсем недавно эту функциональность начали предлагать продукты класса RASP.
На сегодняшний день функциональные возможности виртуального патчинга имеет подавляющее большинство WAF, например:
- Positive Technologies Application Firewall;
- Wallarm;
- ModSecurity;
- Nemesida WAF.
Реализация функциональности виртуального патчинга в WAF позволяет блокировать попытки эксплуатации уязвимостей в веб-приложениях безо внесения изменений в исходный код, то есть не дожидаясь выпуска официального патча от разработчиков.
Методология виртуального патчинга
Виртуальный патчинг, как и большинство других процессов информационной безопасности, — это не то, к чему следует подходить бессистемно. OWASP в рекомендациях OWASP Virtual Patching Best Practices выделяет следующие этапы:
- Подготовка.
- Идентификация.
- Анализ.
- Создание виртуального исправления.
- Внедрение / тестирование.
- Восстановление / последующее выполнение.
Этап подготовки
Идея состоит в том, что нужно настроить процессы виртуального патчинга и фреймворк, прежде чем фактически работать с выявленной уязвимостью или, что ещё хуже, реагировать на атаку на веб-приложение в реальном времени. Момент атаки — не самое подходящее время предлагать установку брандмауэра для веб-приложений и концепцию виртуального патча. Напряженность и так высока во время реальных инцидентов, потому необходимо быть готовым к работе, когда произойдёт инцидент.
Вот несколько важных шагов, которые следует сделать на этапе подготовки:
- Убедитесь, что вы подписаны на рассылки от вендоров программного обеспечения, которое используется в компании. Это гарантирует, что вы получите уведомление, если вендор опубликует информацию об уязвимостях и данные об исправлениях.
- Виртуальные патчи должны быть реализованы быстро, чтобы ускорить обычные процессы управления и авторизации стандартных обновлений программного обеспечения. Поскольку виртуальные патчи не изменяют исходный код, они не требуют такого же объёма тестирования, как обычные.
- Заранее установите продукты реализующие виртуальный патчинг. Не дожидайтесь реальных инцидентов.
- Стандартный общий формат журнала (CLF), используемый большинством веб-серверов, не предоставляет достаточных данных для проведения надлежащего реагирования на инциденты. Поэтому требуется увеличить объём логирования и собирать следующие данные:
- Request URL (включая QUERY_STRING).
- Request Headers.
- Request Body (включая нагрузку POST).
- Response Headers.
- Response Body.
Этап идентификации
Этап идентификации наступает тогда, когда компания узнаёт об уязвимости в своём веб-приложении. Как правило, используются два различных метода выявления уязвимостей: проактивный и реактивный.
Проактивный метод подразумевает тестирование на проникновение и анализ исходного кода. Реактивный включает в себя поиск информации об уязвимостях в рассылках от вендора или публичных источниках, а также признание факта наличия уязвимости в тот момент, когда уже произошёл инцидент и атака идёт в активной фазе.
Этап анализа
На этапе анализа OWASP рекомендует выполнить следующие шаги:
- Определить применимость виртуального патча, учитывая то, что он подходит для изъянов инъекционного типа, но может не обеспечить адекватного уровня уменьшения площади атаки для других типов или категорий киберугроз. Следует провести тщательный анализ основной бреши, чтобы определить, обладает ли инструмент виртуального патчинга адекватными логическими возможностями обнаружения.
- Введите информацию об уязвимости в систему отслеживания ошибок (bug tracking / ticketing system) для отслеживания статуса.
- Проверьте идентификатор уязвимости, например имя или номер CVE. Если уязвимость выявляется «проактивно», а не с помощью анализа публичных сведений, то каждой уязвимости следует присвоить свой уникальный идентификатор.
- Определите уровень критической опасности уязвимости.
- Необходимо определить, какие версии программного обеспечения затронуты брешью и используются ли они у вас.
- Определите, какая конфигурация требуется для эксплуатации уязвимости, учитывая, что некоторые уязвимости могут проявляться только при определённых параметрах конфигурации.
- Проанализируйте код эксплойта, демонстрации (proof-of-concept) или вредоносных нагрузок, используемых во время атак либо тестирования. Во многих базах уязвимости сопровождаются подобными данными. Если они доступны, обязательно загрузите их для анализа. Это будет полезно позже как при разработке виртуального патча, так и при его тестировании.
Этап создания виртуального патча
Процесс создания виртуального патча связан с двумя основными правилами:
- Никаких ложных срабатываний — никогда и ни при каких обстоятельствах не блокируйте легитимный трафик.
- Никаких ложноотрицательных срабатываний — никогда не пропускайте атаки, даже когда злоумышленник намеренно пытается уклониться от обнаружения.
Следует позаботиться о том, чтобы попытаться свести к минимуму нарушения этих правил. Возможно, вам не удастся на 100 % придерживаться обоих, но помните, что виртуальное исправление — это в первую очередь снижение риска.
Существует два метода создания виртуальных патчей: ручной и автоматизированный.
Ручное создание виртуального патча подразумевает формирование белого списка («позитивный подход») или чёрного списка («негативный подход»).
Позитивный подход основывается на определении характеристик допустимых входных данных (набор символов, длина и т. д.) и отрицает всё то, что не соответствует этим критериям. Такие правила обеспечивают лучшую защиту, однако это — кропотливый ручной процесс, который не масштабируется. К тому же список правил трудно поддерживать для больших или динамических сайтов.
Негативный подход основан на наборе правил, которые обнаруживают конкретные известные атаки вместо разрешения только легитимного трафика.
Если же уязвимости были выявлены с помощью автоматизированных средств и доступен XML-отчёт, можно автоматически преобразовать эти данные об уязвимостях в виртуальные патчи для систем защиты. Самыми популярными средствами автоматизации являются OWASP ModSecurity Core Rule Set (CRS) Scripts, ThreadFix Virtual Patching и прямое импортирование в WAF.
Этап внедрения и тестирования
Для тестирования виртуальных патчей могут быть задействованы:
- веб-браузер,
- веб-утилиты для терминалов (например, curl и wget),
- локальный прокси-сервер,
- ModSecurity AuditViewer.
При этом изначально реализуйте виртуальные патчи в конфигурации «только журналирование», чтобы точно не заблокировать легитимный пользовательский трафик из-за ложных срабатываний.
Можно также выполнить повторное тестирование, если уязвимость была выявлена конкретным инструментом.
Если повторное тестирование показывает, что виртуальный патч можно обойти, необходимо вернуться к фазе анализа, чтобы определить, как лучше устранить уязвимость.
Этап восстановления и последующего наблюдения
На данном этапе рекомендуется:
- обновление данных о виртуальном патчинге в тикет-системе,
- периодическое повторное оценивание, чтобы проверить, можно ли удалить предыдущие виртуальные патчи, если веб-приложение было обновлено с помощью реального исправления исходного кода,
- просмотр логов системы с целью определить, сработал ли какой-либо из ваших виртуальных патчей.
Выводы
Виртуальный патчинг меняет парадигму кибербезопасности, обеспечивая проактивную нейтрализацию эксплойтов. Виртуальные патчи ограничивают доступ ко скомпрометированным частям приложения до закрытия уязвимости разработчиком, тем самым «разрушая» вектор атаки, поэтому злоумышленникам не удаётся проэксплуатировать неисправленные изъяны. Компании могут минимизировать риски, при этом растягивая циклы обновления, позволяя ИТ-специалистам спокойно дождаться того момента, когда поставщик программного обеспечения опубликует официальные «заплатки».
Преимущества «виртуального патчинга» очевидны: можно снизить риск доступа к информационной системе, в которой обнаружена уязвимость, а реальный патч установить по мере выпуска обновления вендором, причём выбрав для этого удобное время, когда доступность приложения не столь значима для бизнес-процессов.
