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

Разобрал заметки про эфир AM Live по Vulnerability Management‑у

Разобрал заметки про эфир AM Live по Vulnerability Management-у

Разобрал заметки про эфир AM Live по Vul­ner­a­bil­i­ty Management‑у. Эфир шел чуть меньше 3 часов. Ух! Всё ещё самое концентрированное мероприятие по VM‑у в России. 🔥

Каких-то явных клинчей VM-вендоров практически не было. А ведь это самое интересненькое. 😈 Отметил:

🔻 От Александра Дорофеева по поводу стоимости решения. Эшелон активно конкурирует по цене. Павел Попов хорошо это парировал обращением к клиентам: "смотрите сами, что вам нравится и подходит по бюджетам".
🔻 Тоже от Александра Дорофеева, что детект поиском по базе лучше, чем детект скриптами или OVAL-контентом. Имхо, разницы какой-то нет, зависит от реализации и когда решение "ищет по базе" сложно понять какие уязвимости оно в принципе может детектировать 🤷‍♂️.
🔻Небольшие пикировки по поводу использования нескольких сканеров в решении: те, кто умеют такое, говорили, что это must have, а те, кто не умеют, либо молчали, либо переводили в русло "а кто будет отвечать за качество детектирования в сторонних (в том числе бесплатных) сканерах".

В остальном было всё тихо-мирно и в одном ключе. Основные тезисы:

🔹 VM про совместную работу в компании. Важность VM должен осознавать IT, ИБ, Бизнес.
🔹 VM-щик в одиночку может реализовывать только функции контроля.
🔹 Цель VM‑а в том, чтобы сделать взлом компании через известные уязвимости невозможным (имхо, правильнее говорить про увеличение стоимости атаки)
🔹 Внедрение компенсирующих мер это лучше, чем ничего, но это неполное исправление. "А если WAF упадёт, что тогда?"
🔹 Не нужно исправлять все уязвимости, нужно определять критичные и исправлять их. Тут меня резко резануло, т.к. я‑то как раз за то, что нужно стремиться к детектированию и исправлению всех уязвимостей. 🙄
🔹 Нулевой этап Vul­ner­a­bil­i­ty Management‑а это Asset Man­age­ment. Желательно, чтобы была интерактивная визуализация с подсветкой Kill Chain-ов и т.п.
🔹 Базы детектов должны обновляться очень быстро, чтобы можно было исправлять критичные уязвимости за 24 часа.
🔹 Обосновывать необходимость VM‑а за последние 2 года стало проще из-за публичных инцидентов.

Про то, что нужно договариваться о безусловных регулярных обновлениях с IT в этот раз не говорили — жаль. 😔

Ответы вендоров про отличия от конкурентов:

🔸 ГК «Солар». Вообще не VM-вендор, а сервис, который может использовать решения разных вендоров. Можно добавлять свои сканеры и детекты.
🔸 Solid­Lab VMS. Не просто вендор, а решение предоставляющее отвалидированные уязвимости с reme­di­a­tion-ами, настроенными под заказчиков. Вдохновлялись Qualys-ами.
🔸 «АЛТЭКС-СОФТ». Используют открытый стандарт SCAP/OVAL, можно импортить свой OVAL. Пока не VM-решение, а сканер, но активно работают над VM-ом (пока в аналитике). OVALdb идёт как отдельный продукт.
🔸 «Эшелон Технологии»/Сканер ВС. Цена низкая, детект быстрым поиском по базе (+ перерасчет уязвимостей без пересканирования), работает на Astra Lin­ux.
🔸 Secu­ri­ty Vision. "Настроенный SOAR в виде VM".
🔸 R‑Vision. Полноценное решение от управления активами до детекта и исправления уязвимостей. Быстрые детекты 5–20 секунд на хост. Своя тикетница.
🔸 Spacebit/X‑Config. Com­pli­ance Man­age­ment. Хорошая производительность, гибкие политики, поддержка российского ПО.
🔸 Pos­i­tive Technologies/MaxPatrol VM. Asset Man­age­ment, перерасчет уязвимостей без пересканирования, Com­pli­ance Man­age­ment. Подробности о новых фичах будут на PHDays. 😉

Направление развития у всех более-менее схожи и укладываются в общемировые тренды: автоматизация исправления уязвимостей (VMDR. autopatch­ing), использование AI для приоритизации уязвимостей и упрощения работы. Ну и общее подтягивание до уровня ТОП3 западных решений.

Понравилось, что в одном из голосований по поводу проблем VM-решений большая часть опрошенных (32%) высказалась по поводу полноты базы детектов и качества детектирования. Т.е. за хардкорную базовую функциональность. 👍 Хочется надеяться, что это будут учитывать и VM-вендоры выставляя приоритеты своей разработки. 🙂

Традиционный эфир на AM Live по Vulnerability Management‑у в этом году подкрался для меня неожиданно

Традиционный эфир на AM Live по Vulnerability Management-у в этом году подкрался для меня неожиданноТрадиционный эфир на AM Live по Vulnerability Management-у в этом году подкрался для меня неожиданно

Традиционный эфир на AM Live по Vul­ner­a­bil­i­ty Management‑у в этом году подкрался для меня неожиданно. Заметил за несколько минут до начала. 😅

Довольно сильно изменился состав участников.

В этом году НЕ участвуют в дискуссии представители от:
🔹 BIZONE
🔹 «Фродекс»

Появились новые представители от:
🔹 Solid­Lab VMS
🔹 ГК «Солар»
🔹 Secu­ri­ty Vision

И остались представители от:
🔹 Pos­i­tive Tech­nolo­gies
🔹 R‑Vision
🔹 «АЛТЭКС-СОФТ»
🔹 «Эшелон Технологии»
🔹 Spacebit

Блок вопросов "Рынок систем управления уязвимостями в России" превратился в "Процесс управления уязвимостями по-российски", что тоже довольно символично.

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vul­ner­a­bil­i­ty Management‑у. Часть 3/3. Поддержка методик ФСТЭК.

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

> 5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

> 3. Ваше VM-решение позволяет проводить приоритизацию уязвимостей с использованием "Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств" ФСТЭК?

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Pos­i­tive Tech­nolo­gies Max­Pa­trol VM я смотрел текущую реализацию, для R‑Vision VM, АЛТЭКС-СОФТ Red­Check и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Tem­po­ral и Envi­ron­men­tal метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

> 4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

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

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vul­ner­a­bil­i­ty Management‑у. Часть 2/3. Эталонный сканер.

Вопрос был такой:  

> 2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Win­dows и отечественных Lin­ux-ов?

Зачем я задал этот вопрос? Давайте начнем с того, что такое эталонный сканер уязвимостей.

Начнем просто с эталона. Возьмем, для примера, эталон единицы измерения массы. "Международный прототип (эталон) килограмма хранится в Международном бюро мер и весов (расположено в Севре близ Парижа) и представляет собой цилиндр диаметром и высотой 39,17 мм из платино-иридиевого сплава (90 % платины, 10 % иридия)." Вряд ли вы будете использовать этот цилиндр для того, чтобы отвесить себе килограмм помидоров. Скорее всего вы просто положите свои помидоры на электронные весы. А вот для того, чтобы проверить, что эти весы работают корректно, некоторый эталон очень даже пригодится.

Теперь по поводу сканеров уязвимостей. Не секрет, что если вы просканируете один и тот же хост различными сканерами уязвимостей, то вы получите различные же результаты. Иногда практически не пересекающиеся по CVE идентификаторам. Тут дело не в том, что различные VM-вендоры поддерживают различные наборы Third-par­ty софтов, это ещё простительно. Но даже если мы ограничимся только детектированием уязвимостей ОС, по KB-шкам Win­dows или бюллетеням безопасности Lin­ux, всё равно разница будет, потому что каждый VM-вендор реализует свои собственные алгоритмы детектирования. А уязвимость на хосте либо есть, либо нет. Это вещь объективная. И если результаты различаются, значит как минимум одно из средств детектирования работает неправильно.

Есть ли у нас такой сканер уязвимостей, результаты детектирования которого мы могли бы принять за эталон? Есть один претендент — ScanOVAL. Он общедоступный, бесплатный и самое главное выпущен ФСТЭК. С ним вполне удобно сравнивать результаты детектирования уязвимостей для Win­dows и российских Lin­ux-ов.

Так готовы ли VM-вендоры признать ScanOVAL за эталон качества детектирования уязвимостей?

Каверзность вопроса в том, что если ответить "да", то все различия при сравнении со ScanOVAL будут автоматически являться ошибками. А если ответить "нет", то получается сканер уязвимостей регулятора некорректно уязвимости детектирует? Давайте-ка с этого момента поподробнее. 😏

Любой ответ представителя VM-вендора, сулит проблемы для него. А для клиентов наоборот — любой ответ выгоден, т.к. подсвечивает проблемы детектирования уязвимостей и улучшает либо возможности продукта VM-вендора, либо ScanOVAL. Ну или хотя бы дискуссию провоцирует о качестве детектирования, и то неплохо.

В итоге вопрос про ScanOVAL задали в 2:22:01 в таком виде:

"А у нас ещё такой провокационный немного вопрос в сторону присутствующих здесь вендоров. А что если просто взять ScanOVAL и с помощью умелых рук организовать весь процесс, чем это будет слабее Enter­prise решений?" 🤦🏻‍♂️

Как видите, вопрос не про эталон, не про качество сканирования, а из серии можно ли выкопать котлован малой сапёрной лопаткой. Ну и ответы соответствующие. 🤷‍♂️

В общем, жаль, что обсуждение этой темы не получилось, но попробуем пропедалировать её в следующий раз. 😉

Часть 1

Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (RedCheck)

Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (Red­Check)

Компания дает возможность выгрузки ОVAL feed-ов, используемых для детекта уязвимостей в Red­Check, на следующих условиях:

1. Доступ предоставляется крупным заказчикам и частным исследователям, не аффилированным с конкурентами. Быть клиентом необязательно.
2. Доступ предоставляется для запрашиваемых платформ.
3. Доступ предоставляется на некоторый оговоренный промежуток времени.
4. Доступ предоставляется при условии заключения соглашения на запрещение коммерческого использования, что не запрещает публикацию, критику и сравнение с конкурентами в исследовательских целях.

При этом фиды АЛТЭКС-СОФТ, которые поддерживаются в рамках проекта ScanOVAL ФСТЭК полностью открыты и фактически доступны для изучения.

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

Если кто-то ещё из представителей VM-вендоров хочет добавить уточнения по своей позиции — пишите в личку, всегда выкладываю без проблем. 🙂

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у

Разбираю ответы на мои вопросы с эфира AM Live по Vul­ner­a­bil­i­ty Management‑у. Часть 1/3. Доступность баз детектов уязвимостей для анализа.

Вопрос был такой:

> 1. Вы предоставляете информацию об уязвимостях (идентификаторы CVE, БДУ), которые может детектировать ваше VM-решение, чтобы клиенты (текущие и потенциальные) могли оценить полноту базы детектов вашего VM-решения?

Зачем я задавал этот вопрос? Хотелось бы делать сравнения отечественных средств детектирования уязвимостей, также как я делал сравнения для Nes­sus и Open­VAS. Но тут проблема — нет публичных данных, перечней детектируемых CVE-шек для сравнения.

Вопрос задали и на него начали отвечать в 1:00:38:

"Есть у нас вопрос от Александра Леонова, как раз в тему. А насколько вы предоставляете информацию об уязвимостях, которые ваше решение детектирует? Т.е., проще говоря, ваша база данных уязвимостей…"

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

Pos­i­tive Tech­nolo­gies: "В нашем решении в VM‑е можно с помощью фильтра вывести все уязвимости, которые есть. Если не ошибаюсь, их сейчас там около 100.000, близко к этому. И в режиме real time можно посмотреть какие есть, можно точечно уязвимость проверить. Поэтому никаких секретов в этом нет."

Т.е. список уязвимостей получить можно, если у вас есть приобретенное решение Max­Pa­trol VM. Или, возможно, если вы запросили эту информацию в ходе пилотного проекта. Какого-то публично доступного файла с детектируемыми CVE-шками нет.

АЛТЭКС-СОФТ: "У нас собственный репозиторий уязвимостей, который могут смотреть все пользователи мира. Наша база данных сканера доступна не только пользователям продукта, но и любому человеку".

Подчеркивается, что одно дело доступность для клиентов, другое публичная доступность. И для АЛТЭКС-СОФТ это действительно в большей степени справедливо — есть поисковый интерфейс OVAL репозитория. В вебинтерфейсе видны уязвимости и их идентификаторы. Но какой-то возможности выгрузить всё для изучения ведь там тоже нет. Только если сделать робота, который всё это сграбит через веб-интерфейс.

Эшелон: "У нас консолидированная база уязвимостей, можно проверить наличие любой уязвимости, которая только вышла. Обновления ежедневно".

Список уязвимостей Сканер-ВС 6 доступен для клиентов, но не является доступным публично. В случае Эшелона дать список всех детектируемых уязвимостей сложно, т.к. для детекта используется поиск по базе. Допустим VM-вендор взял NVD и ищет в ней по продуктовым cpe-идентификаторам. Спроси его: какие он уязвимости может детектить? Да он сам не знает. В принципе всё, что в NVD есть может в каком-то случае найтись. Правда не любые cpe могут прийти на вход от средства инвентаризации. Но поиск может идти не только по cpe. Поэтому получить перечень потенциально детектируемых уязвимостей затруднительно.

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

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

Пока спасение утопающих — дело рук самих утопающих. Запрашивайте данные и делайте сравнение баз детектируемых уязвимостей непосредственно в ходе пилотных проектов. Обращайтесь или используйте мои наработки в проекте VulnKB­d­iff.