Управление уязвимостями

Выявление уязвимостей

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

Основным источником данных об уязвимостях вашего ПО являются рассмотренные ранее инструменты статического и динамического анализа, которые интегрированны в процессы непрерывной интеграции (CI) и непрерывной доставки (CD). Формируемые ими отчеты рекомендуем собирать и анализировать в централизованном трекере уязвимостей (DefectDojo) или на отдельной панели системы управления версиями, посвященной безопасности ПО (GitLab Security Dashboards). Такие инструменты позволяют не только отображать найденные уязвимости с гибкими настройками фильтрации, но и координировать работу по устранению этих уязвимостей. 

Также стоит использовать инструменты анализа состава ПО (SCA) или анализа происхождения компонентов. Эти инструменты могут автоматически предупреждать, когда в ваших зависимостях обнаруживаются публично известные уязвимости.

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

• Software Package Data Exchange (SPDX)
• Software Identification (SWID)
• CycloneDX

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

• www.cve.org
• ubuntu.com/security/notices
• security.openstack.org/ossalist.html
• kubernetes.io/docs/reference/issues-security/official-cve-feed/

Распространенный метод поощрения сообщений об уязвимостях — программа Bug Bounty, в рамках которой вы платите исследователям за сообщения об особенно важных уязвимостях. При грамотном использовании такие программы могут быть экономически эффективными, особенно после устранения всех относительно простых для обнаружения уязвимостей.

Раскрытие информации об уязвимостях

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

Требование простое: определите порядок приема сведений об уязвимостях и сделайте эту информацию легко доступной. Ниже собрали распространенные способы.

• Многие компании и проекты указывают email-адрес, например security@example.com или abuse@example.com.
• В открытых проектах часто используется файл SECURITY.md в корне репозитория или в папке docs/. GitHub и подобные платформы рекомендуют создавать этот файл. Добавьте ссылку на SECURITY.md в ваш README.md.
• Если у проекта есть веб-сайт, рекомендуем разместить файл security.txt по адресу /security.txt или /.well-known/security.txt. Подробности — в стандарте securitytxt.org.
• GitHub предоставляет специальный тип задачи (issue) для приватного сообщения об уязвимости. Другие системы управления кодом имеют похожие возможности. Обычно файл SECURITY.md предлагает авторам отчетов использовать именно этот способ.

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

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

Другие полезные документы по теме раскрытия уязвимостей

• The CERT Guide to Coordinated Vulnerability Disclosure. В руководстве термин «поставщик» относится к организации, выпускающей ПО и которой необходимо узнать об уязвимости.
• FIRST’s Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure.

Рабочая группа по раскрытию уязвимостей OpenSSF разработала Guide to coordinated vulnerability disclosure for open source software projects. Если вы поддерживаете проект с открытым исходным кодом, используйте это руководство, чтобы быть готовыми к получению сообщений об уязвимостях заранее. 

Что стоит помнить при раскрытии обнаруженных уязвимостей другим сторонам, например, если вы нашли их в стороннем компоненте? Памятка по раскрытию уязвимостей OWASP® рекомендует специалистам, обнаружившим уязвимости:

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

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

Существует несколько моделей, определяющих когда и как информация об уязвимости становится публичной (OWASP® Vulnerability Disclosure). У каждой есть свои плюсы и минусы. Понимание этих моделей помогает увидеть, почему сегодня общепринятым стал скоординированный подход.

Приватное (закрытое) сообщение

В этой модели человек, обнаруживший уязвимость, сообщает о ней напрямую и конфиденциально организации-разработчику. Решение о том, публиковать ли детали, остается за организацией. Из-за этого многие уязвимости так и не становятся достоянием общественности. Большинство программ Bug Bounty работают по этой модели. Ее главный недостаток — если разработчик проигнорирует сообщение или откажется исправлять проблему, информация может навсегда остаться скрытой. Именно такое поведение компаний в прошлом заставляло тех, кто находит уязвимости, разочаровываться и переходить к модели полного раскрытия.

Полное раскрытие

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

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

Скоординированное раскрытие

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

Исторически такой подход называли «ответственным раскрытием», однако этот термин считается предвзятым. Даже его автор теперь рекомендует использовать название «скоординированное раскрытие». Крайне важно, чтобы был установлен жесткий срок, по истечении которого уязвимость будет раскрыта в одностороннем порядке. Без такого временного лимита эта модель практически не отличается от приватного раскрытия, поскольку у поставщика нет стимулов для быстрого устранения проблемы.

Сроки скоординированного раскрытия или период эмбарго — это время, которое дается поставщику на исправление уязвимости до ее публикации тем, кто ее обнаружил.

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

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

• linux-distros: желательно менее 7 дней, допускается до 14 дней, до 19 дней — если отчет поступил в четверг/пятницу, а публикация назначена на понедельник/вторник.
• oCERT: стандартный срок — 14 дней; 7 дней для простых проблем, 30 дней для критических или сложных, до двух месяцев в исключительных обстоятельствах.
• CERT/CC: 45 дней «вне зависимости от наличия патчей или временных решений… Особые обстоятельства… могут изменить этот срок… Мы не распространяем эксплойты».
• Google Project Zero: 90 дней.

Реагирование на сообщения об уязвимостях

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

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

Рекомендуем создать группу для работы с инцидентами безопасности, которые связаны с разрабатываемым вами ПО. Такие группы называют Product Security Incident Response Teams (PSIRT).

FIRST рекомендует создавать PSIRT на этапе формирования требований и не позднее первого релиза ПО. Правильно работающая PSIRT позволяет быстро выявлять и реагировать на самые серьезные сообщения об уязвимостях.

Группы PSIRT часто работают вместе с командами реагирования на инциденты компьютерной безопасности (Computer Security Incident Response Team, CSIRT).

• CSIRT занимаются безопасностью компьютерных систем и (или) сетей, составляющих инфраструктуру всей организации;
• PSIRT сосредоточены на уязвимостях в конкретных продуктах или услугах.

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

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

• качественной (экспертной) оценки возможностей эксплуатации уязвимости — для новых уязвимостей без присвоенного номера CVE, включая недостатки в конфигурациях программных компонентов; 
• количественной оценки в соответствии со стандартом CVSS (CVSS Score) — для известных уязвимостей с присвоенным номером CVE.

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

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

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

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

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

Выбор метода устранения уязвимости зависит от типа уязвимости и условий ее проявления и может выполняться путем:

• обновления/изменения программных компонентов и (или) их конфигураций;
• применения компенсирующих организационных и технических мер.

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

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

Устранение уязвимостей в коде или в зависимостях ПО собственной разработки выполняется путем их непосредственного изменения. 

Устранение уязвимостей внешних компонентов — например, операционных систем, пакетов, образов контейнеров — выполняется через установку официальных обновлений (патчей), направленных на устранение уязвимостей, и через изменения конфигураций этих компонентов. 

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

Тестирование изменений проводится в выделенной тестовой среде. 

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

Важно оповестить пользователей о выходе обновленной версии и способствовать ее скорейшему распространению.

OWASP® рекомендует разработчикам своевременно публиковать информацию об уязвимостях и списки изменений, а также указывать человека, который сообщил об уязвимости (OWASP® Vulnerability Disclosure).

Если существуют временные решения (workarounds), которые могут снизить риск без немедленного обновления, их также стоит подробно описать. Это особенно важно в случаях, когда:

• многие пользователи не могут быстро обновить свое ПО, которое зависит от вашего ПО;
• уязвимость уже стала публично известна, но исправления еще нет.