Архив метки: Remediation

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса

Добавить комментарий

Попался на глаза мем объясните Управление Уязвимостями своими словами - перевёл его в виде комикса

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса. В целом, типичный процесс Управления Уязвимостями в организации (с точки зрения VM-щика, естественно 🙂) - это разгребание постоянных косяков:

🔻 в работе инструментов детектирования уязвимостей (в принципе неподдерживаемое ПО и типы активов, фолсы, баги);

🔻 в качестве информации об уязвимостях (вроде эксплуатируется - но фиг знает как, где и кем; вроде эксплойт есть, но фиг знает, что конкретно он делает и при каких условиях работает);

🔻 в состоянии проверяемой инфраструктуры и понимании того, из чего она состоит, как НА САМОМ ДЕЛЕ функционирует и что в ней критично;

🔻 в безответственности формально ответственных за состояние инфраструктуры людей;

🔻 в отсутствии интереса со стороны руководства (пока не настанет полнейший карачун).

Это утомительное бесконечное бодание с аргументацией вроде "мы не будем ничего обновлять, это может нам что-то сломать" - при полном отсутствии плана тестирования, оценки рисков или конкретных шагов по устранению проблемы. 😖

И руководству следовало бы, конечно, задаваться не вопросом "Насколько мы защищены?" (здесь и сейчас), а гораздо более важным: "Понимаем ли мы, какими активами располагаем, какие риски с ними связаны, знаем ли, кто несёт за них ответственность и насколько эффективно ими управляют?" Так, чтобы Управление Уязвимостями перестало быть задачей одного несчастного технаря, практически не имеющего рычагов воздействия на решения, принимаемые в организации, и стало частью корпоративного управления…

Но это, конечно, уже что-то из области фантастики. 😅👽

В начале октября с коллегами из Бастиона записали подкаст "ВСЕ ПО ИБ | Про эксплуатацию уязвимостей, приоритизацию рисков и защиту инфраструктуры"

Добавить комментарий

В начале октября с коллегами из Бастиона записали подкаст "ВСЕ ПО ИБ | Про эксплуатацию уязвимостей, приоритизацию рисков и защиту инфраструктуры". Бастион - российская компания в сфере информационной безопасности, предоставляющая широкий спектр услуг: от тестирования на проникновение и аудита защищённости до мониторинга безопасности и реагирования на киберинциденты. Компания входит в ИКС Безопасность.

Мои собеседники:

🔹 Дмитрий Калинин, руководитель департамента пентеста, Бастион
🔹 Семён Рогачёв, руководитель отдела реагирования на инциденты, Бастион

Мне очень понравилось! 😇 Разговор получился содержательным и интересным. Обсудили практику Vulnerability Management-а: приоритизацию уязвимостей, их реальную эксплуатацию в атаках, проверку эксплоитов, выявление цепочек атак, харденинг инфраструктуры, особенности работы сканеров уязвимостей, организационные и документальные аспекты. Разобрали эффективность компенсирующих мер, применение AI, роль антивирусов и мониторинга, подходы к принятию рисков, различия и взаимодействие между VM, CTEM, пентестом и автопентестом.

С пентестерами и специалистами по Incident Response всегда интересно пообщаться, потому что это даёт практический взгляд на уязвимости и позволяет лучше понять, что реально эксплуатируется в атаках. 😉

Таймстемпы:

00:00 В этом выпуске
01:28 Почему компании откладывают устранение уязвимостей
10:30 Что чаще приводит к атакам: старые уязвимости или новые
12:31 Какие уязвимости реально эксплуатируются в инцидентах
18:59 Количество обнаруживаемых уязвимостей и эксплуатируемых уязвимостей - две большие разницы
22:43 Как проверить работоспособность эксплоитов
24:15 Могут ли уязвимости исключаться из KEV или из Трендовых Уязвимостей
27:29 Как определить, какие уязвимости нужно устранять в первую очередь: CVSS, KEV, VMDR, CTEM
30:48 VM/CTEM, пентест, автопентест, Red Team, Purple Team: в чём разница
35:11 Vulnerability Management процесс всегда внедряется сверху
38:08 Как определить, что несколько безобидных проблем могут сложиться в цепочку атаки, приводящую к недопустимому последствию, и можно ли это делать без CTEM-решения
41:31 Примеры использования старых уязвимостей и мисконфигураций в атаках
45:18 Рекомендации ФСТЭК по харденингу и как правильно харденить инфраструктуру
48:45 Грандиозная проблема в том, что люди не только не патчат, но и не мониторят
52:27 Про антивирусы
56:09 Когда компенсирующие меры эффективны, а когда создают иллюзию безопасности
01:00:05 Что делать в ситуации, когда патч установлен, а уязвимость не устранена
01:07:05 Как отличать осознанно принятый риск от забытой уязвимости
01:12:13 Нужно ли стремиться к нулевому количеству уязвимостей в инфраструктуре
01:23:49 Как работает детектирование уязвимостей в сканерах и почему качество детектирования различается
01:29:05 Роль AI в ресёрче уязвимостей, автоматической эксплуатации и Vulnerability Management-е
01:41:04 Взаимодействие пентеста и Vulnerability Management-а

Подкаст также доступен в аудио, на RuTube и на YouTube.

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

Добавить комментарий

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

В опроснике: 50. Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

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

💿 Базовые образы

4.4-6 Процесс управления уязвимостями включает процедуры проверки и устранения уязвимостей в базовых образах инфраструктуры, используемых для развертывания корпоративных информационных систем.

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

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

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

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

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

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

2 комментария

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять. Сейчас на Западе очень популярна тема Вульнпокалипсиса (Vulnpocalypse). Этот термин обозначает ситуацию, когда скорость обнаружения уязвимостей и появления эксплойтов для них начинает значительно превосходить скорость выпуска обновлений безопасности вендорами ПО и скорость установки этих обновлений их клиентами. В принципе, это уже сейчас похоже на правду: количество CVE растёт настолько быстро, что NVD отказались от анализа всех CVE. Microsoft Patch Tuesday вырос примерно со 100 исправляемых уязвимостей в месяц до 500+. Аналогично, каждый месяц обновляются рекорды по числу уязвимостей в отчётах Linux Patch Wednesday.

Причиной этого обычно называют развитие технологий искусственного интеллекта. И с этим можно отчасти согласиться: ИИ действительно значительно упростил поиск уязвимостей и разработку инструментов для их эксплуатации. Но, на мой взгляд, настоящая причина такого количества уязвимостей - не в ИИ, а в качестве ПО. Десятилетиями вендоры ПО писали ОЧЕНЬ плохой код. Их цель была одна - реализовать как можно больше фич за наименьшее время и наименьшие деньги. Если разработку можно было отдать на аутсорс в страны с максимально дешёвой рабочей силой и низкой культурой разработки - её отдавали. Если можно было взять бесплатный код, непонятно кем написанный и выложенный в открытый доступ (я про open source) - его использовали. В результате мы имеем то, что имеем: огромное количество уязвимостей в этом коде.

Раньше это было не так заметно, т.к. скорость прироста выявленных уязвимостей ограничивалась возможностями специалистов-ресёрчеров. А они в первую очередь искали уязвимости там, где за это платили. Как только это ограничение начало сниматься благодаря ИИ-сервисам, уязвимости начали массово проявляться. 😏 Есть основания полагать, что с развитием ИИ-инструментов темпы роста обнаруживаемых уязвимостей будут только расти.

С ростом количества уязвимостей растёт и количество обновлений, которые необходимо тестировать и устанавливать в инфраструктурах. Обновлений будет МНОГО, гораздо больше, чем было раньше. И выходить они будут ещё чаще. Сложившаяся ситуация - это плата за то, что вендоры софта могут писать плохой код, лепить из него продукты, а затем годами выпускать бесконечные заплатки для этих продуктов. А компании-клиенты готовы такие продукты покупать и использовать. 🤷‍♂️

При этом имеет место довольно занимательная ситуация. Покупать продукты клиенты готовы, а выполнять рекомендации вендоров ПО по устранению уязвимостей в купленных продуктах (устанавливать обновления, менять конфигурацию и применять другие меры защиты) они НЕ ГОТОВЫ. И ищут "индульгенции", чтобы этого не делать.

И находят! 🙂 Есть Vulnerability Management (Exposure Management)-вендоры, которые в своём маркетинге транслируют, что "нужно устранять только 1-3% уязвимостей". Только купите их решение, и они вам этот минимальный список уязвимостей покажут. 🔮 Это, конечно, безответственное шарлатанство, потому что супер-критичные уязвимости появляются из общего пула всех неустранённых уязвимостей. И появляются ВНЕЗАПНО! Сегодня уязвимость может не представлять особого интереса, а завтра стать супер-критичной из-за появления публичного эксплоита или обнаружения признаков эксплуатации уязвимости в реальных атаках. Если бы в компании своевременно устранили эту уязвимость по рекомендации вендора ПО, эта супер-критичная уязвимость им бы не была страшна, но, доверившись недобросовестному VM/EM-вендору, вместо планового устранения они получают ещё один "пожар", который может привести к серьёзному инциденту. Таким образом, вместо экономии ресурсов получается бесконечный забег по граблям.

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

Я, конечно, не говорю, что приоритизировать уязвимости - это плохо. Вполне полезно показывать клиентам уязвимости, которые требуют немедленного внимания, в том числе через моделирование путей атаки. Но как только VM-вендор меняет риторику с "эти уязвимости нужно устранить в первую очередь" на "остальные уязвимости можно игнорировать" - это переход на тёмную сторону. 😈

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

У Антона Чувакина, в прошлом главного идеолога Gartner по Vulnerability Management, недавно вышел блогпост, в котором он предлагает провести мысленный эксперимент:

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

Теперь самое интересное - попробуйте разобраться, как это стало возможным.

Какие фундаментальные изменения должны были произойти в вашей инфраструктуре, чтобы такое 15-минутное окно стало реальностью?

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

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

Ну а стратегически хотелось бы, чтобы безнаказанный выпуск дырявого ПО, предполагающий постоянный патчинг, когда-нибудь прекратился. И чтобы компании-клиенты стали использовать продукты от вендоров, которые инвестируют не только в поиск уязвимостей, но и в безопасную разработку кода по принципу secure by design. Да, такие решения стоили бы гораздо дороже. Но если продукт по факту имеет меньше уязвимостей и реже требует экстренных обновлений, его эксплуатация становится значительно проще и безопаснее. "Жаль только - жить в эту пору прекрасную. Уж не придется - ни мне, ни тебе." © 😉

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

2 комментария

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так:

Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM?

🔹 Предложить внедрить компенсирующие меры в компромиссный срок.
🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству.
🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации.
🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису.

Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет.

Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️

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

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

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

Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?"

🔻 Если ваши коллеги из IT и/или бизнеса должны были устранять такого рода уязвимости, значит, должен быть документ, в котором прописано, какие типы уязвимостей они устраняют и в какие сроки. Эти сроки должны быть заранее согласованы и зафиксированы. Этой бумажной частью работы кто-то должен методично заниматься.

🔻 Если вы раньше знали об этой уязвимости (детектировали её в рамках сканов), значит, нужно было донести эту информацию до ответственного за устранение так, чтобы это было неотказуемо. Что значит неотказуемо? Не устно, не через мессенджеры и даже не через почту. По этой уязвимости должна существовать задача на устранение, назначенная на конкретного исполнителя, с указанием крайнего срока. Да, этот срок может быть сложно выдержать в реальных условиях, но формально и по руководящим документам он должен быть установлен. С вашей стороны всё, что нужно, должно было вылететь. Если срок устранения не был выдержан, нужно было показать свое деятельное участие: что вы пытались эскалировать проблему. Возможно, попытки эскалации все равно были бы безуспешными, но эти попытки необходимо фиксировать.

🔻 Если вы раньше не знали об этой уязвимости (НЕ детектировали её в рамках сканов), возникает вопрос: почему? Не занимались планомерным покрытием инфраструктуры регулярными сканами? Вместо качественных средств детектирования использовали быстрые? 😉 Аргумент "мы сканировали, но сканер нам ничего не показал" будет выглядеть в рамках разбирательства весьма слабо. Оценка качества детектирования - ваша задача.

И так далее. Эти формальные меры могут повысить шансы, что в случае неприятного инцидента простого VM-щика не сделают крайним: не посадят и не уволят с волчьим билетом.

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

Возвращаясь к описанной в вопросе ситуации, я плясал бы от оценки критичности уязвимости по методике ФСТЭК и формально требовал устранить уязвимость (обновлением или воркараундом) в установленный регулятором срок. А при отказе постарался бы это как можно лучше задокументировать на случай инцидента и теребил бы ответственных за устранение, пока работы не будут полностью выполнены, документируя все свои обращения и их ответы, желательно на бумаге и под роспись.

Так что склоняюсь скорее ко второму варианту. И там уж как пойдет. Получится пропушить устранение в нормативное время, отлично. 👍 Не получится пропушить, но инцидента в растянутый срок устранения не произойдет, тоже норм. 👌 Если злодеи все-таки успеют пробить периметр организации в растянутый срок устранения и это приведет к критичному инциденту - плохо. 😔 Но в этой ситуации будет что показать приехавшим разбираться людям в погонах и будет чем аргументировать, что VM-щик сделал все, что мог.

Дефолтный алгоритм такой: представьте, что вы на допросе по инциденту, случившемуся из-за эксплуатации уязвимости. Какие артефакты, по вашему мнению, могут помочь не присесть конкретно вам? 🙂 Обычно такой мысленный эксперимент подсказывает, чего вашему VM-ному процессу на самом деле не хватает. Те же VM-щики, которые всегда готовы на компромисс и не думают о последствиях для себя лично, имхо, рискуют оказаться в неожиданный момент кинутыми буквально всеми и с горячей картошкой в руках.

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

2 комментария

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ. Т.е. использование ИИ для разработки эксплоитов на основе патчей и публичной информации об уязвимостях. Новую неизвестную уязвимость нужно ещё понять, где искать. А найдя, придумать вменяемый сценарий атаки с эксплуатацией этой уязвимости. Это работа на удачу, своего рода золотоискательство или, вспоминая Маяковского: "…та же добыча радия. В грамм добыча, в годы труды. Изводишь единого слова [уязвимости] ради тысячи тонн словесной руды [проверенного кода и неподтвердившихся гипотез эксплуатации]." Конечно, в случае использования ПО с открытым кодом задача анализа упрощается. Но всё равно найти что-то стоящее весьма непросто. Поэтому, кстати, я противник того, чтобы результаты этой добычи бесконтрольно утекали за рубеж.

Другое дело, когда уязвимость уже известная, с присвоенным CVE, вендорским описанием, признанной критичностью и выпущенным патчем. Тут задача серьёзно упрощается.

🔹 Понятно, где искать. Очевидно, там, где вендор исправляет что-то патчем.

🔹 Понятно, что нужно получить в результате. То, о чём вендор сообщил в описании уязвимости.

Задача разобраться, как именно эксплуатировать уязвимость и разработать утилиту для этого тоже непростая, но всё же гораздо проще, чем искать что-то совершенно новое. Этим можно заниматься на потоке. Например, маркетинг компании watchTowr Labs практически полностью построен на том, что они быстро анализируют патчи для устранения уязвимостей сетевых устройств и публикуют по ним публичные исследования и эксплоиты.

Естественно, этим занимаются не только исследователи watchTowr Labs. 😏 Тем более, что ИИ-агенты значительно упрощают процесс вепонизации, а то и полностью его автоматизируют. Как сообщает Денис Макрушин, стоимость автономной разработки эксплоита сейчас может составлять даже меньше 3 долларов. И ведь прогресс в ИИ пока не останавливается! Разработанные эксплойты могут выкладываться исследователями в паблик ради самопиара и общественного блага (ну, как они его себе видят), а могут и не выкладываться, а, например, продаваться на чёрном рынке. 😈 А затем эти эксплоиты будут использоваться в атаках на организации, пока их не спалят и факт эксплуатации уязвимости не станет подтверждённым. И всё это бесконечно повторяется для всё новых и новых уязвимостей. It's the circle of life and it moves us all…

Что вся эта движуха означает для простого VM'щика? Нарратив, который двигали многие VM-вендоры: "Патчьте только 3% уязвимостей, которые мы вам подсветим, а на остальные просто забейте", с самого начала выглядел булшитненько и безответственно, а в условиях ускорения и удешевления вепонизации n-day-уязвимостей и подавно. Аргументов, что любая уязвимость может внезапно выстрелить и привести к инциденту, значительно прибавилось. А значит, нужно стремиться к приоритизированному устранению всех уязвимостей, что создаёт значительную нагрузку на IT, особенно если IT-инфраструктура организации не была изначально рассчитана на непрерывную установку и тестирование обновлений безопасности. 🤷‍♂️ То, что VM-щик сможет запросто влиять на изменение инфраструктуры организации - сценарий более чем оптимистичный, на который не стоит всерьёз рассчитывать. Но агитировать за такие архитектурные изменения и стараться заводить задачи на устранение всех выявленных уязвимостей - святая обязанность VM-щика. Делай, что должен, и будь, что будет.

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Добавить комментарий

Закончу разбирать основной VM-ный пункт 3.3. Управление уязвимостями (КУ) из недавно опубликованного методического документа Мероприятия и меры по защите информации, содержащейся в информационных системах, и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. В прошлый раз я расписал Цели и Требования к реализации, сегодня рассмотрю Требования к документированию и Требования к усилению.

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

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

👥 Подразделения / работники

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

Получается, что подразделения (работники) делятся на:

🔹 ответственных за организацию и контроль управления уязвимостями;
🔹 участвующих в реализации процессов управления уязвимостями.

Для каждого подразделения (работника) необходимо расписать:

🔹 обязанности (функции);
🔹 права (полномочия).

Напрашивается таблица следующей структуры:

Подразделение (работник); За что отвечает; В реализации каких процессов участвует; Обязанности (функции); Права;

📋 Операции

Требования по документированию операций имеют идентичную структуру:

"описание операций, осуществляемых при {название этапа (подпроцесса)}, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при {название этапа (подпроцесса)}"

Буквально вот так:

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

Напрашивается таблица следующей структуры:

Этап (подпроцесс); Наименование операции; Описание операции; Перечень исполнителей; Продолжительность реализации; Входные данные; Выходные данные;

Типовые операции и их описания можно взять из Таблиц 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2 "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

🗺️ Схемы

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

Интересно, что здесь требуются схемы взаимодействия при реализации операций. А операция, в терминах РУУ23, - это что-то более-менее атомарное, чем занимается один исполнитель. Например, "Анализ информации об уязвимости" или "Корректировка механизмов мониторинга". Это не тот уровень, где подразумевается взаимодействие. Есть подозрение, что авторы здесь имели в виду не конкретные операции, а этапы (подпроцессы). По аналогии с тем, как этапы разрисованы в РУУ23 на Рисунках 2.2, 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2. Здесь требуется разъяснение регулятора, какие именно схемы должны быть приведены в регламенте. Текущая формулировка неоднозначна.

📜 Какие различия с драфтом?

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

Остальные правки касались только орфографии.

К сожалению, требования к документированию не затрагивают, как именно описываются уязвимости и как ставятся задачи для IT на их устранение. 😔 А ведь именно от качества описаний и постановки задач зависит, будут ли уязвимости корректно поняты и устранены в требуемый срок. Без этого процесс управления уязвимостями рискует остаться формальным.

ТРЕБОВАНИЯ К УСИЛЕНИЮ

Насколько вообще обязательны требования из этого раздела? Читаем в сноске в пункте 3.1:

"Усиления мероприятий (процессов) по защите информации, приведенные в подразделах «требования к усилению» раздела 3, применяются по решению оператора (обладателя информации) для повышения эффективности реализации мероприятий по защите информации и повышения уровня защищенности информационных систем и содержащейся в них информации, а также для снижения возможности нарушителей по реализации угроз безопасности информации.

⚙️ Автоматизация

1) для управления уязвимостями используются автоматизированные системы управления уязвимостями;

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

👾 Анализ угроз

2) для мониторинга уязвимостей применяются средства анализа угроз, в том числе TI-платформы;

Фактически это требование означает, что управление уязвимостями должно стать частью CTEM (Continuous Threat Exposure Management) и учитывать данные о реальной эксплуатации уязвимостей: какие из них уже используются атакующими, какие техники применяются и в каких сценариях. В связке с анализом путей атаки это позволяет понимать, как уязвимости используются злоумышленниками для проникновения к целевым активам, и соответственно приоритизировать их устранение.

🗃️ CMDB

3) для оценки применимости уязвимостей используются данные, содержащиеся в автоматизированных системах сбора и хранения данных об объектах инвентаризации и их конфигурациях (СMDB-системы); (в документе в "СMDB" кириллическая С 🤷‍♂️)

Это нужно, чтобы управление уязвимостями опиралось на полный и актуальный контекст инфраструктуры. CMDB задаёт перечень активов, их конфигурации, связи и критичность для бизнеса. Без CMDB информацию об активах приходится получать исключительно методом активного сканирования, у которого могут быть ограничения по полноте и точности.

🤝 Смежные процессы

4) для контроля устранения уязвимостей используются результаты мониторинга информационной безопасности или управления обновлениями, или управления конфигурациями.

Это требование означает, что контроль устранения уязвимостей должен опираться на перекрёстные проверки из уже существующих процессов - мониторинга ИБ, управления обновлениями и управления конфигурациями. Такой подход снижает риск ошибок, когда устранение уязвимости подтверждается только средством анализа защищённости (САЗ), но фактически проблема в системе сохраняется. Использование нескольких независимых источников позволяет подтвердить факт устранения с разных сторон и повысить достоверность контроля.

📜 Какие различия с драфтом?

В релиз не вошло требование "для мониторинга уязвимостей и оценки их применимости используются результаты контроля (оценки) уровня защищенности информации;"

Очень жаль, что убрали этот пункт, потому что результаты пентестов и независимого анализа защищённости часто выявляют уязвимости, которые по каким-то причинам не обнаруживаются штатными САЗ, используемыми в процессе управления уязвимостями. Такие находки являются индикатором проблем в процессе: недостаточного покрытия активов, низкого качества детектирования или несоблюдения сроков устранения. Они позволяют объективно оценить эффективность VM-процесса и улучшить его.

Остальные исправления касаются опечаток и косметических изменений.

---

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