Успеть за 12 часов: как найти и устранить трендовые уязвимости в софте
Каждый год в программном обеспечении выявляется множество уязвимостей. Их важно своевременно обнаруживать. Уязвимости, которые хакеры уже используют в своих атаках или могут это сделать в ближайшем будущем, принято называть «трендовыми». Исследования показывают, что злоумышленники начинают их использовать уже в первые 24 часа с момента обнаружения. Чтобы опередить их и иметь время на устранение бреши, информацию об уязвимостях ИБ-специалисты должны получить в течение первых 12 часов. Как организовать их быстрое выявление, обеспечить приоритизацию и контроль над трендовыми уязвимостями?
Ежегодно десятки тысяч уязвимостей обнаруживаются в программном обеспечении по всему миру. Чтобы не погрязнуть в таких объемах информации, важно приоритизировать наиболее опасные — трендовые уязвимости. В 2023 году мы отнесли к ним более 110 уязвимостей. В их числе отечественное ПО, софт с открытым кодом, а также зарубежное коммерческое ПО. Такие уязвимости важно не только определить как можно быстрее, но и в течение первых 24 часов устранить их — ровно поэтому мы организовали сверхбыструю 12-часовую доставку информации о них в MaxPatrol VM. Как это работает? Расскажем подробнее.
Популярный стандарт оценки опасности уязвимостей — CVSS (Common Vulnerability Scoring System — система оценки уязвимостей по общим критериям) — учитывает множество параметров, но не включает в расчет популярность уязвимости среди злоумышленников. Поэтому мы самостоятельно анализируем множество ресурсов, отслеживаем появление эксплойтов, наблюдаем за поведением злоумышленников и отслеживаем особо опасные уязвимости. Трендовые уязвимости отличаются тем, что они эксплуатируются атакующими в настоящий момент или будут эксплуатироваться в ближайшее время. Подобные бреши необходимо устранять в первую очередь.
Как понять, что уязвимость трендовая?
Чтобы выявить одну трендовую уязвимость, эксперты анализируют сотни недостатков безопасности. Учитывается медийный резонанс, общедоступная информация об уязвимости, наличие особого кода, который использует уязвимости в ПО, — эксплойта, его сложность и другое.
Какие источники используются для определения трендовых уязвимостей?
Мы изучаем информацию о новых уязвимостях и об уже известных в Exploit Database (значимом агрегаторе данных о выходе эксплойтов — вредоносных программ), GitHub, различных сообществах, а также используем другие источники, список которых регулярно актуализируется. Также мы следим за бюллетенями ключевых вендоров, в которых содержится информация об угрозах и рекомендации по реагированию на них. Мы фильтруем уязвимости по различным параметрам, и при соответствии информация о трендовых уязвимостях в системе заполняется автоматически.
Какие сложности встречаются при детектировании уязвимостей?
Иногда происходит так: клиент получил информацию об уязвимости, скачал обновление, установил его, а сканер не видит, что уязвимость закрыта. Это может быть по разным причинам. К примеру, систему забыли перезагрузить и установленное обновление еще не начало функционировать. Бывает также, что вендор закрыл уязвимость, сообщил ее ID на своей странице, но не отправил информацию о ней в базы уязвимостей, например, MITRE ATT&CK или БДУ ФСТЭК.
Отдельно хочется сказать про проекты с открытым исходным кодом. Нередко возникают проблемы обнаружения уязвимостей в таком ПО: уязвимостей в копии исходного хранилища нет, но на самом деле они есть, просто вендор их не признает, а соответственно, сканер их не видит. Хочется, чтобы вендоры стремились контролировать процесс устранения уязвимостей и публиковали об этом информацию в отечественной базе уязвимостей — БДУ ФСТЭК. Это позволит специалистам ИБ оптимизировать время и не собирать информацию об уязвимостях из различных источников.
Как выявлять трендовые уязвимости внутри инфраструктуры?
Самый простой метод касается версионных уязвимостей, существование которых выясняется по версии программного обеспечения. Исследователи проверяют заголовки уязвимости, выясняют версию ПО, в котором она обнаружена, и ищут ее в международных или национальных базах данных уязвимостей.
Существует также активное сканирование версионных уязвимостей, при котором сопоставляется часть кода в программе с цифровым слепком уязвимости. Однако наличие уязвимости часто зависит от конфигурации софта. Сегодня функция, влияющая на работоспособность уязвимости, выключена, но завтра эта функциональность может быть активирована, и уязвимость станет эксплуатируемой. Для более полной проверки можно применять локальные сканеры уязвимостей, которые учитывают конфигурацию и версию ПО.
Третий подход, возможно, самый эффективный, — применение безопасных фрагментов кода, которые позволяют эксплуатировать уязвимости. Если он сработает, то уязвимость может считаться существующей, и мы сможем обогатить карточку о ней дополнительной информацией. Но если проверка не показала наличие уязвимости, необходимо анализировать причины: действительно ли уязвимости нет или использованию мешает одна из конфигураций ПО?
У нас есть наработки по тому, как сделать механизм, позволяющий любой компании, например интегратору, писать собственные описания уязвимостей — и самостоятельно подтверждать наличие или отсутствие недостатков безопасности. Это цель, к которой мы идем. Со временем такой механизм будет реализован, и он позволит серьезно расширить базу уязвимостей.
Зачем нужна сверхбыстрая доставка информации о трендовых уязвимостях?
Если наши эксперты определили, что опасная уязвимость вошла в тренд и, возможно, в этот момент ее используют злоумышленники, система MaxPatrol VM мгновенно повышает приоритет устранения уязвимости и подсвечивает ее в активах компании.
Сегодня пользователи MaxPatrol VM могут выявить трендовую уязвимость в своей инфраструктуре в течение первых 12 часов после обнаружения.
Мы шли к этому около года, разрабатывая механизмы, которые позволяют нашим специалистам наблюдать, как эти данные проходят по пайплайну (процессу сборки продукта, которым является в данном случае вся информация об уязвимости и ее обнаружению) и сколько времени это занимает.
Почему именно 12 часов? Согласно нашей внутренней статистике, от момента обнародования эксплойта до его реальной эксплуатации проходит в среднем 24 часа. Мы оценили время, необходимое нам для доставки информации об уязвимости и ее устранения, — до 12 часов. Соответственно, у клиентов остается 12 часов или больше, чтобы эту уязвимость закрыть. Для этого и нужна наша система. При этом необязательно быть целью сложной целенаправленной APT-атаки, чтобы быть взломанным. Злоумышленники, получив эксплойт (вредоносную программу) для трендовой уязвимости, часто сканируют множество различных компаний с помощью ботов, получая доступы, что называется, на всякий случай. Потом такой доступ может быть продан заинтересованным людям.
Как объединить все базы уязвимостей и зачем это нужно?
Все большей популярностью пользуются базы уязвимостей OVAL (Open Vulnerability and Assessment Language) и NVD (National Vulnerability Database). Можем ли мы совместить информацию из этих баз и обогатить их данными друг друга? Это действительно интересная задача, но не такая простая, учитывая их собственную структуру и форматы. Иногда форматы описания уязвимостей не учитывают некоторые условия, например, конфигурационные.
Но даже если «подружить» все базы в одном продукте по выявлению уязвимостей, необходимо научиться анализировать различный софт с помощью этих уязвимостей. Чтобы поддержать весь популярный китайский софт, надо иметь образцы этого ПО на своем тестовом стенде. Это масштабная задача, которая требует развернутой инфраструктуры со всеми распространенными китайскими системами, «железом», ОС.
Если вернуться к российскому ПО, то в любом случае необходима приоритизация по популярности ПО (поддерживать все невозможно), а также система уведомления пользователей о выходе новых версий софта. Это два направления, над которыми мы сейчас и работаем.
Этот материал опубликован на платформе бизнес-сообщества Forbes Экспертиза
Ежегодно десятки тысяч уязвимостей обнаруживаются в программном обеспечении по всему миру. Чтобы не погрязнуть в таких объемах информации, важно приоритизировать наиболее опасные — трендовые уязвимости. В 2023 году мы отнесли к ним более 110 уязвимостей. В их числе отечественное ПО, софт с открытым кодом, а также зарубежное коммерческое ПО. Такие уязвимости важно не только определить как можно быстрее, но и в течение первых 24 часов устранить их — ровно поэтому мы организовали сверхбыструю 12-часовую доставку информации о них в MaxPatrol VM. Как это работает? Расскажем подробнее.
Популярный стандарт оценки опасности уязвимостей — CVSS (Common Vulnerability Scoring System — система оценки уязвимостей по общим критериям) — учитывает множество параметров, но не включает в расчет популярность уязвимости среди злоумышленников. Поэтому мы самостоятельно анализируем множество ресурсов, отслеживаем появление эксплойтов, наблюдаем за поведением злоумышленников и отслеживаем особо опасные уязвимости. Трендовые уязвимости отличаются тем, что они эксплуатируются атакующими в настоящий момент или будут эксплуатироваться в ближайшее время. Подобные бреши необходимо устранять в первую очередь.
Как понять, что уязвимость трендовая?
Чтобы выявить одну трендовую уязвимость, эксперты анализируют сотни недостатков безопасности. Учитывается медийный резонанс, общедоступная информация об уязвимости, наличие особого кода, который использует уязвимости в ПО, — эксплойта, его сложность и другое.
Какие источники используются для определения трендовых уязвимостей?
Мы изучаем информацию о новых уязвимостях и об уже известных в Exploit Database (значимом агрегаторе данных о выходе эксплойтов — вредоносных программ), GitHub, различных сообществах, а также используем другие источники, список которых регулярно актуализируется. Также мы следим за бюллетенями ключевых вендоров, в которых содержится информация об угрозах и рекомендации по реагированию на них. Мы фильтруем уязвимости по различным параметрам, и при соответствии информация о трендовых уязвимостях в системе заполняется автоматически.
Какие сложности встречаются при детектировании уязвимостей?
Иногда происходит так: клиент получил информацию об уязвимости, скачал обновление, установил его, а сканер не видит, что уязвимость закрыта. Это может быть по разным причинам. К примеру, систему забыли перезагрузить и установленное обновление еще не начало функционировать. Бывает также, что вендор закрыл уязвимость, сообщил ее ID на своей странице, но не отправил информацию о ней в базы уязвимостей, например, MITRE ATT&CK или БДУ ФСТЭК.
Отдельно хочется сказать про проекты с открытым исходным кодом. Нередко возникают проблемы обнаружения уязвимостей в таком ПО: уязвимостей в копии исходного хранилища нет, но на самом деле они есть, просто вендор их не признает, а соответственно, сканер их не видит. Хочется, чтобы вендоры стремились контролировать процесс устранения уязвимостей и публиковали об этом информацию в отечественной базе уязвимостей — БДУ ФСТЭК. Это позволит специалистам ИБ оптимизировать время и не собирать информацию об уязвимостях из различных источников.
Как выявлять трендовые уязвимости внутри инфраструктуры?
Самый простой метод касается версионных уязвимостей, существование которых выясняется по версии программного обеспечения. Исследователи проверяют заголовки уязвимости, выясняют версию ПО, в котором она обнаружена, и ищут ее в международных или национальных базах данных уязвимостей.
Существует также активное сканирование версионных уязвимостей, при котором сопоставляется часть кода в программе с цифровым слепком уязвимости. Однако наличие уязвимости часто зависит от конфигурации софта. Сегодня функция, влияющая на работоспособность уязвимости, выключена, но завтра эта функциональность может быть активирована, и уязвимость станет эксплуатируемой. Для более полной проверки можно применять локальные сканеры уязвимостей, которые учитывают конфигурацию и версию ПО.
Третий подход, возможно, самый эффективный, — применение безопасных фрагментов кода, которые позволяют эксплуатировать уязвимости. Если он сработает, то уязвимость может считаться существующей, и мы сможем обогатить карточку о ней дополнительной информацией. Но если проверка не показала наличие уязвимости, необходимо анализировать причины: действительно ли уязвимости нет или использованию мешает одна из конфигураций ПО?
У нас есть наработки по тому, как сделать механизм, позволяющий любой компании, например интегратору, писать собственные описания уязвимостей — и самостоятельно подтверждать наличие или отсутствие недостатков безопасности. Это цель, к которой мы идем. Со временем такой механизм будет реализован, и он позволит серьезно расширить базу уязвимостей.
Зачем нужна сверхбыстрая доставка информации о трендовых уязвимостях?
Если наши эксперты определили, что опасная уязвимость вошла в тренд и, возможно, в этот момент ее используют злоумышленники, система MaxPatrol VM мгновенно повышает приоритет устранения уязвимости и подсвечивает ее в активах компании.
Сегодня пользователи MaxPatrol VM могут выявить трендовую уязвимость в своей инфраструктуре в течение первых 12 часов после обнаружения.
Мы шли к этому около года, разрабатывая механизмы, которые позволяют нашим специалистам наблюдать, как эти данные проходят по пайплайну (процессу сборки продукта, которым является в данном случае вся информация об уязвимости и ее обнаружению) и сколько времени это занимает.
Почему именно 12 часов? Согласно нашей внутренней статистике, от момента обнародования эксплойта до его реальной эксплуатации проходит в среднем 24 часа. Мы оценили время, необходимое нам для доставки информации об уязвимости и ее устранения, — до 12 часов. Соответственно, у клиентов остается 12 часов или больше, чтобы эту уязвимость закрыть. Для этого и нужна наша система. При этом необязательно быть целью сложной целенаправленной APT-атаки, чтобы быть взломанным. Злоумышленники, получив эксплойт (вредоносную программу) для трендовой уязвимости, часто сканируют множество различных компаний с помощью ботов, получая доступы, что называется, на всякий случай. Потом такой доступ может быть продан заинтересованным людям.
Как объединить все базы уязвимостей и зачем это нужно?
Все большей популярностью пользуются базы уязвимостей OVAL (Open Vulnerability and Assessment Language) и NVD (National Vulnerability Database). Можем ли мы совместить информацию из этих баз и обогатить их данными друг друга? Это действительно интересная задача, но не такая простая, учитывая их собственную структуру и форматы. Иногда форматы описания уязвимостей не учитывают некоторые условия, например, конфигурационные.
Но даже если «подружить» все базы в одном продукте по выявлению уязвимостей, необходимо научиться анализировать различный софт с помощью этих уязвимостей. Чтобы поддержать весь популярный китайский софт, надо иметь образцы этого ПО на своем тестовом стенде. Это масштабная задача, которая требует развернутой инфраструктуры со всеми распространенными китайскими системами, «железом», ОС.
Если вернуться к российскому ПО, то в любом случае необходима приоритизация по популярности ПО (поддерживать все невозможно), а также система уведомления пользователей о выходе новых версий софта. Это два направления, над которыми мы сейчас и работаем.
