Критическая уязвимость обнаружена, способ устранения известен, но заявка днями ждёт исполнения. Причина часто не в бездействии: эксплуатационные команды опасаются, что изменение заблокирует легитимный трафик, нарушит работу сервиса или затронет приложение, от которого зависит бизнес. Пока последствия неясны, даже обоснованная рекомендация может остаться на бумаге.
Эта осторожность имеет цену. Организации нередко уже располагают средствами защиты, но не включают их полностью. Сигнатуры IPS могут быть выключены или оставлены в режиме Detect, пока команды оценивают риск ложных срабатываний, нагрузку на инспекцию и возможный ущерб непрерывности бизнеса. Между тем приложения и характер трафика меняются, исключения накапливаются, а настройки постепенно расходятся с реальными условиями эксплуатации.
В документе Safe Remediation: Confident Remediation in Production указано: среди измеренных организаций у 47% было активировано менее половины доступных средств защиты. Но включить всё разом — плохой план: каждое изменение способно повлиять на работу систем. Нужно понять, какая мера нужна для конкретной угрозы и как она поведёт себя в рабочей среде. Именно поэтому, как гласит подпись к рисунку 1, «операционная нагрузка и дрейф конфигураций могут задерживать применение защиты».
Практический подход строится вокруг четырёх действий: наблюдать, проверять, выполнять и подтверждать. На этапе наблюдения собирают уже имеющиеся данные систем безопасности и ИТ: результаты поиска уязвимостей, трафик IPS, загрузку устройств, политики конечных точек и текущие конфигурации. Они дают контекст для предполагаемого изменения: что именно оно затронет и в каких условиях будет работать.
Затем выбранную меру проверяют подходящим для технологии способом. Для IPS трафик можно сначала анализировать в режиме Detect, чтобы оценить ложные срабатывания и производительность, и лишь затем переходить к Prevent. При усилении защиты операционной системы изменения проверяют на выбранной тестовой группе, а после выполнения повторно проверяют каждый узел. Настройки конечных устройств сопоставляют с базовой линией усиления защиты, рекомендованной производителем.
Такая проверка переводит спор о риске в предметный разговор. Команда безопасности объясняет, какую защиту ожидает получить; владельцы инфраструктуры и приложений оценивают последствия для систем, за которые отвечают. После оценки действие проходит предусмотренные согласования. Организация может требовать утверждения объёма изменений или разрешить автоматическое выполнение через настроенные рабочие процессы.
Исполнение при этом остаётся в системах, которые уже управляют соответствующими средствами защиты: изменения IPS передаются через сервер управления безопасностью, усиление операционных систем выполняется имеющейся инфраструктурой управления исправлениями, а поддерживаемые настройки конечных устройств меняются через API производителя. Так не приходится создавать отдельный канал исполнения для каждой меры. Подпись к рисунку 2 описывает эту связь: «Проверка соединяет данные о среде с согласованием, выполнением и подтверждением».
После выполнения проверяют результат, а не ограничиваются отметкой в заявке. Установка политики подтверждает, что защита IPS дошла до режима блокирования; проверки узлов показывают, применилось ли усиление системы. Записи выполнения фиксируют неудачные или ожидающие действия, имя пользователя, время и связанную уязвимость. Последующие события безопасности могут показать, остановил ли включённый контроль активность, связанную с этой угрозой.
Пока готовится постоянное исправление, дополнительную защиту может дать уже имеющаяся сигнатура IPS или виртуальный патч, блокирующий путь эксплуатации. Установка обновления остаётся необходимой для устранения самой уязвимости, но тестирование, согласования и графики развёртывания способны задержать его выход в рабочую среду. Сопоставление данных об уязвимостях с покрытием средствами защиты помогает выбрать действие: проверить и включить подходящую защиту либо срочно установить патч или применить другую меру, если компенсирующего контроля нет. В записи следует отдельно обозначать временную защиту и постоянное исправление.
В измеренных средах успешными оказались 99,5% действий по устранению проблем. За один месяц средства защиты, включённые в ходе таких действий, впоследствии заблокировали 703,56 млн атак; 21 млн из них были остановлены в течение 24 часов после устранения проблемы. Эти данные приведены на рисунке 3 и относятся к средам, измеренным для документа, а не автоматически ко всем организациям.
Check Point Exposure Management связывает приоритизацию уязвимостей с проверкой условий в конкретной среде, контролируемым выполнением и подтверждением результата через существующие технологии безопасности. Смысл подхода — снижать уязвимость к атакам, одновременно оценивая операционные последствия каждого шага. Описание методики, способов проверки и измеренных результатов приведено в документе Safe Remediation: Confident Remediation in Production.
Изображение носит иллюстративный характер
Эта осторожность имеет цену. Организации нередко уже располагают средствами защиты, но не включают их полностью. Сигнатуры IPS могут быть выключены или оставлены в режиме Detect, пока команды оценивают риск ложных срабатываний, нагрузку на инспекцию и возможный ущерб непрерывности бизнеса. Между тем приложения и характер трафика меняются, исключения накапливаются, а настройки постепенно расходятся с реальными условиями эксплуатации.
В документе Safe Remediation: Confident Remediation in Production указано: среди измеренных организаций у 47% было активировано менее половины доступных средств защиты. Но включить всё разом — плохой план: каждое изменение способно повлиять на работу систем. Нужно понять, какая мера нужна для конкретной угрозы и как она поведёт себя в рабочей среде. Именно поэтому, как гласит подпись к рисунку 1, «операционная нагрузка и дрейф конфигураций могут задерживать применение защиты».
Практический подход строится вокруг четырёх действий: наблюдать, проверять, выполнять и подтверждать. На этапе наблюдения собирают уже имеющиеся данные систем безопасности и ИТ: результаты поиска уязвимостей, трафик IPS, загрузку устройств, политики конечных точек и текущие конфигурации. Они дают контекст для предполагаемого изменения: что именно оно затронет и в каких условиях будет работать.
Затем выбранную меру проверяют подходящим для технологии способом. Для IPS трафик можно сначала анализировать в режиме Detect, чтобы оценить ложные срабатывания и производительность, и лишь затем переходить к Prevent. При усилении защиты операционной системы изменения проверяют на выбранной тестовой группе, а после выполнения повторно проверяют каждый узел. Настройки конечных устройств сопоставляют с базовой линией усиления защиты, рекомендованной производителем.
Такая проверка переводит спор о риске в предметный разговор. Команда безопасности объясняет, какую защиту ожидает получить; владельцы инфраструктуры и приложений оценивают последствия для систем, за которые отвечают. После оценки действие проходит предусмотренные согласования. Организация может требовать утверждения объёма изменений или разрешить автоматическое выполнение через настроенные рабочие процессы.
Исполнение при этом остаётся в системах, которые уже управляют соответствующими средствами защиты: изменения IPS передаются через сервер управления безопасностью, усиление операционных систем выполняется имеющейся инфраструктурой управления исправлениями, а поддерживаемые настройки конечных устройств меняются через API производителя. Так не приходится создавать отдельный канал исполнения для каждой меры. Подпись к рисунку 2 описывает эту связь: «Проверка соединяет данные о среде с согласованием, выполнением и подтверждением».
После выполнения проверяют результат, а не ограничиваются отметкой в заявке. Установка политики подтверждает, что защита IPS дошла до режима блокирования; проверки узлов показывают, применилось ли усиление системы. Записи выполнения фиксируют неудачные или ожидающие действия, имя пользователя, время и связанную уязвимость. Последующие события безопасности могут показать, остановил ли включённый контроль активность, связанную с этой угрозой.
Пока готовится постоянное исправление, дополнительную защиту может дать уже имеющаяся сигнатура IPS или виртуальный патч, блокирующий путь эксплуатации. Установка обновления остаётся необходимой для устранения самой уязвимости, но тестирование, согласования и графики развёртывания способны задержать его выход в рабочую среду. Сопоставление данных об уязвимостях с покрытием средствами защиты помогает выбрать действие: проверить и включить подходящую защиту либо срочно установить патч или применить другую меру, если компенсирующего контроля нет. В записи следует отдельно обозначать временную защиту и постоянное исправление.
В измеренных средах успешными оказались 99,5% действий по устранению проблем. За один месяц средства защиты, включённые в ходе таких действий, впоследствии заблокировали 703,56 млн атак; 21 млн из них были остановлены в течение 24 часов после устранения проблемы. Эти данные приведены на рисунке 3 и относятся к средам, измеренным для документа, а не автоматически ко всем организациям.
Check Point Exposure Management связывает приоритизацию уязвимостей с проверкой условий в конкретной среде, контролируемым выполнением и подтверждением результата через существующие технологии безопасности. Смысл подхода — снижать уязвимость к атакам, одновременно оценивая операционные последствия каждого шага. Описание методики, способов проверки и измеренных результатов приведено в документе Safe Remediation: Confident Remediation in Production.
