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

Разобрал заметки про эфир 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-вендоров. 😉 Собираюсь отслеживать на что они будут делать акценты.

Подбил итоги сентября для англоязычного канала и блога

Подбил итоги сентября для англоязычного канала и блога. Сентябрь получился отличный! 😊 Много разнообразных активностей удалось реализовать и разрулить. А с учётом непубличного так и вообще удивительно как всё в итоге удачно сложилось. 🙂 По Patch Tues­day: обратите внимание, что lib­webp CVE-2023–4863 теперь идёт с уровнем Urgent, т.к. на гитхабе выложили эксплоит.

Hel­lo every­one! On the last day of Sep­tem­ber, I decid­ed to record anoth­er ret­ro­spec­tive episode on how my Vul­ner­a­bil­i­ty Man­age­ment month went.

Edu­ca­tion
00:09 BMSTU online cyber secu­ri­ty course
00:33 Pos­i­tive Tech­nolo­gies online Vul­ner­a­bil­i­ty Man­age­ment course
00:52 Bahasa Indone­sia

Russ­ian Pod­casts
01:20 Прожектор по ИБ ("Infor­ma­tion Secu­ri­ty Spot­light") pod­cast
01:47 КиберДуршлаг ("Cyber Colan­der") by Pos­i­tive Tech­nolo­gies

Main Job
01:57 Good­bye Tin­koff

Patch Tues­day
02:54 Sep­tem­ber Microsoft Patch Tues­day
03:11 Remote Code Exe­cu­tion – Microsoft Edge/libwebp (CVE-2023–4863), Mem­o­ry Cor­rup­tion – Microsoft Edge (CVE-2023–4352)
04:11 Remote Code Exe­cu­tion – Win­dows Themes (CVE-2023–38146) "The­me­Bleed"
04:48 Infor­ma­tion Dis­clo­sure (NTLM relay attack) – Microsoft Word (CVE-2023–36761)
05:19 Ele­va­tion of Priv­i­lege – Microsoft Stream­ing Ser­vice Proxy (CVE-2023–36802)
05:36 Remote Code Exe­cu­tions — Microsoft Exchange (CVE-2023–36744, CVE-2023–36745, CVE-2023–36756)

Oth­er Vul­ner­a­bil­i­ties
06:54 Bitrix CMS RCE (BDU:2023–05857)
07:32 RHEL/CentOS 7 can’t be detect­ed, can’t be fixed vul­ner­a­bil­i­ty (CVE-2022–1012)
08:09 Qualys TOP 20 vul­ner­a­bil­i­ties

Vul­ner­a­bil­i­ty Man­age­ment Mar­ket
09:06 For­rester and GigaOm VM Mar­ket reports
09:49 R‑Vision VM

🎞 Video
🎞 Video2 (for Rus­sia)
📘 Blog­post

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей

Ещё одно размышление после конференции R-Vision, про таски на исправление уязвимостей

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей. На этой теме был акцент и в основном выступлении про R‑Vision VM, и в кейсе НРД. Несмотря на то, что таски могут быть предметом долгих разбирательств IT и ИБ, имхо, таски должны быть. Почему?

1. Слова (как и дашборды, доступ для IT-шников в VM-систему, нотификации в почте/мессенджерах и прочее) к делу не пришьёшь. А тут формальная задачка. С критичностью, исполнителем и датой заведения. И для аудитов есть, что показать, и в случае инцидента пригодится. 😏
2. Вполне вероятно, что в организации уже внедрены процессы оценки эффективности работы подразделений на основе анализа статусов тасков, можно и исправление уязвимостей оценивать по аналогии.
3. Руководство ФСТЭК требует заводить таски. Можно, конечно, рассуждать об обязательности этого руководства, но если можно соответствовать, то лучше соответствовать. 😉

Какие это должны быть таски?

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

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

Сколько таких тасков будет? Допустим, у нас для одного Lin­ux хоста за месяц выходят 100 новых уязвимостей. Допустим, у нас 10000 Lin­ux хостов в инфраструктуре. Получается миллион тасков за месяц. 12 миллионов в год. И это только Lin­ux!

Отсюда следует:
1. Система для учёта тасков должна быть готова к таким объемам.
2. Вручную работать с такими тасками практически нереально.

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

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

❓А те ITшники, которые считают, что полное регулярное обновление им не подходит, смогут разбираться с каждой уязвимостью отдельно и тем способом, который сочтут нужным. Включая их ручную обработку. 🤷‍♂️ Может в процессе они скорректирую свои взгляды относительно регулярных обновлений. 😏

Что я вынес из доклада про R‑Vision VM

Что я вынес из доклада про R-Vision VM

Что я вынес из доклада про R‑Vision VM. Раньше конкурентным преимуществом R‑Vision было то, что они интегрируются со всеми сторонними решениями для детектирования уязвимостей, существующими на рынке. Но они пришли к тому, что некоторые задачи могут быть решены только на своём стеке, включающих в том числе и свой детект. С другой стороны, закрываться от других продуктов они не собираются, возможности для интеграции останутся.

В части детектов R‑Vision VM это OVAL/SCAP сканер. Пока, в рамках MVP, поддерживаются только Lin­ux дистрибутивы.

Западные:
🔹 Debian v. 7–11
🔹 RHEL v. 6–9
🔹 Ubun­tu v. 14.04–23.04
🔹 Suse SLED/SLES 11, 12, 15

Российские:
🔻 RedOS v. 7.3
🔻 AstraL­in­ux v. 17

Расчёт уязвимостей происходит на сервере.

Поддержку Win­dows собираются добавить в конце года — начале следующего.

Куда идут? "VM третьего поколения":

🔸 Активо-центричный подход
🔸 Автоматические сценарии обработки
🔸 Приоритизация с учётом ценности актива
🔸 Патч менеджмент

Сегодня в оффлайне на конференции R‑Vision

Сегодня в оффлайне на конференции R-Vision

Сегодня в оффлайне на конференции R‑Vision. Планирую поучаствовать в "Интерактивном круглом столе нa тему SIEM/VM". Подключайтесь к трансляции в 16:05. 😉

В продолжение темы с R‑Vision VM

В продолжение темы с R-Vision VM

В продолжение темы с R‑Vision VM. 28 сентября, то есть уже завтра, R‑Vision проводят конфу R‑EVOlution Conf 2023 (игра слов в том, что EVO — это название их экосистемы продуктов), на которой будет как минимум 3 выступления/активности непосредственно связанных с R‑Vision VM:

🔹 11:30–12:30 R‑Vision VM — новый подход к управлению уязвимостями. Название интригующее. 😇
🔹 14:30–15:10 R‑Vision VM — реальный кейс от заказчика. Т.к. докладывается здесь Олег Кусеров, директор по ИБ НРД (Национальный расчетный депозитарий), то можно предположить о каком заказчике пойдет речь.
🔹 16:05–17:05 Интерактивный круглый стол нa тему SIEM/VM.

Я зарегался. Планирую заслушать живую трансляцию или в записи и затем отрефлексировать. 😉