Перейти к основному содержимомуПерейти к нижней части страницы

Как приоритизировать уязвимости и назначать меры по их устранению

Связанная услуга: Устранение уязвимостей

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

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

Подготовьте результаты, которым можно доверять

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

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

Запишите, можно ли достичь уязвимого состояния отдельно. Для приложения, определите, выполняется ли затронутый код и с какими данными или разрешениями. Для сервера, определите, кто может подключиться к соответствующему сервису. Доступность кода и интернет-видимость описывают разные условия и не заменяют друг друга. Если сетевое правило блокирует текущий путь, проверьте внутренние пути и возможность изменения этого правила. Утверждение о том, что что-то не используется, требует доказательств и дату проверки.

Разделите серьезность, эксплуатацию и прогноз

Сигнал

Что это показывает

Что это не устанавливает

CVSS

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

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

KEV

Каталог CISA содержит уязвимости, для которых подтверждено использование в реальных атаках.

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

EPSS (Оценка вероятности)

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

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

SSVC (Дерево принятия решений)

Дерево принятия решений связывает факты и контекст выбранной заинтересованной стороны с действием в отношении уязвимости.

Это не еще одна оценка уровня серьезности или универсальный набор сроков для каждой организации.

Вы можете уточнить CVSS (Common Vulnerability Scoring System) с использованием информации об угрозах и окружающей среде в соответствии с правилами выбранной версии. В версии 4.0, дополнительные метрики предоставляют контекст, но не изменяют итоговую оценку. Сравнивайте записи с четким источником оценки и принимайте решения вместе с данными об окружающей среде.

Не умножайте CVSS на EPSS, чтобы создать якобы точное значение риска. Масштабы описывают различные величины. Низкий EPSS не отменяет уже подтвержденную эксплуатацию в CVE. Также различаются публичная демонстрация атаки, подтвержденное использование в реальных атаках и признаки атаки внутри компании. Последний из этих пунктов требует реагирования на инцидент в сочетании с устранением уязвимости.

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

Уточните последствия и фактические пределы защиты.

  • Цель и владелец активов: какие операции и данные зависят от системы, и существует ли альтернативное решение.
  • Доступность: интернет, внутренняя сеть, партнеры, удаленное администрирование и необходимые учетные данные.
  • Возможные последствия атаки: чтение данных, изменение записей, остановка сервиса, расширение прав доступа или доступ к другим системам.
  • Существующие меры защиты: ограничения доступа, отключение функции, изоляция, фильтрация и обнаружение. Оценка охвата записей и доказательства эффективности в отношении конкретного пути.
  • Зависимости при устранении: поставщик, библиотека, базовый образ, совместимость приложений, требования к перезапуску и доступное окно для работы.

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

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

Создайте рабочую матрицу приоритетов

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

Определение условий

Решение и обоснование

Владелец и сроки

Доказательства эксплуатации

В вашей среде обнаружены признаки эксплуатации.

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

Назначен координатор инцидента и владелец системы; согласуйте действия и сроки во время реагирования.

Доказательства собраны, согласованы действия по реагированию, и проверена эффективность решения проблемы.

Эксплуатация подтверждена в KEV, и затронутый сервис доступен извне и важен для работы.

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

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

Проверена установленная версия или конфигурация, предыдущее состояние эксплуатации и работа сервиса.

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

Составьте график устранения неполадок и контролируйте ограничение. Высокий уровень риска сохраняется, но текущие условия влияют на принятие решения.

Владелец активов; дата устранения и отдельная дата для проверки ограничений.

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

Компонент присутствует в общей библиотеке или изображении, используемом многими системами.

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

Владелец библиотеки или изображения; согласованная дата развертывания для зависимых систем.

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

Применимость или доступность неизвестны.

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

Назначенный рецензент; конкретная дата ответа и процесс эскалации при задержках.

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

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

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

Определите безопасное действие, даже если нет доступного патча

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

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

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

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

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

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

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

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

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

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

Источники

Использование материалов сайта

Использование, воспроизведение или распространение материалов, опубликованных на этом сайте, в полном объеме или частично, разрешено только при предварительном письменном согласии от редакционной команды DK’S Enterprises, Ltd.

При цитировании или ссылке на материалы с этого сайта необходимо указать прямую, активную и индексируемую ссылку на исходный источник: https://dkent.net/

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

Оценка уязвимостей и тестирование на проникновение: различия и выбор
Усиление безопасности сервера: практический контрольный список