Архив рубрики: Темы

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 2. Что определяет руководство?

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

"Руководство определяет состав и содержание работ по анализу и устранению уязвимостей (далее – управление уязвимостями),"

Отмечаем: "управление уязвимостями" = "анализ и устранение уязвимостей" ❗️

"выявленных в

программных,
программно-аппаратных средствах"

Ага, вот куда ПО и ПАС из названия документа переехали. ПО и ПАС относящихся к чему?

"информационных систем,
информационно-телекоммуникационных сетей,
автоматизированных систем управления,
информационно-телекоммуникационных инфраструктурах [м.б. инфраструктур?] центров обработки данных, на базе которых функционируют эти системы и сети (далее – информационные системы)."

Т.е., если у вас есть ИС, ИТС, АСУ, центр обработки данных - будьте любезны внедрить VM для ПО и ПАС. 😉👍

Часть 1

Евгений Касперский аргументирует почему Apple iPhone зло в русскоязычном посте про Triangulation

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

Евгений Касперский аргументирует почему Apple iPhone зло в русскоязычном посте про Triangulation.

"Мы считаем, что главной причиной этого инцидента является закрытость iOS. Данная операционная система является «черным ящиком», в котором годами могут скрываться шпионские программы подобные Triangulation. Обнаружение и анализ таких угроз осложняется монополизацией Apple исследовательских инструментов, что создает для шпионских программ идеальное убежище. Иными словами, как я уже не раз говорил, у пользователей создаётся иллюзия безопасности, связанная с полной непрозрачностью системы. Что на самом деле происходит в iOS, специалистам по IT-безопасности неизвестно. Отсутствие новостей об атаках отнюдь не свидетельствует о невозможности самих атак — в чем мы только что убедились."

И как бы это всё правильно. И здорово, что KUMA зараженные устройства продетектила. Но вопрос в том, а как так получилось, что сотрудники Kaspersky, в значительной части специалисты по ИБ, пользуются на работе iOS устройствами? Теми самыми, которые представляют "идеальное убежище для шпионских программ". Может вводить требования, чтобы устройства Apple не тащили в корпоративный wifi, не использовали их для работы, а ТОПы возможно не использовали их вовсе?

PS: Это, конечно очень чувствительная и непопулярная тема, понимаю. Даже в этом канале, на который далеко не случайные люди подписаны, где-то больше трети с айфонами. 🙂
PPS: НКЦКИ в своём бюллетене связали утренний пресс-релиз и "операцию триангуляцию", так что можно считать это одним кейсом.

И вот сегодня же Kaspersky выпускают пост "Операция «Триангуляция»: iOS-устройства атакованы ранее неизвестным вредоносным ПО"

1 комментарий

И вот сегодня же Kaspersky выпускают пост Операция «Триангуляция»: iOS-устройства атакованы ранее неизвестным вредоносным ПО

И вот сегодня же Kaspersky выпускают пост "Операция «Триангуляция»: iOS-устройства атакованы ранее неизвестным вредоносным ПО".

Компрометацию тоже по трафику нашли:

"При мониторинге сетевого трафика собственной корпоративной сети Wi-Fi, выделенной для мобильных устройств, с помощью Kaspersky Unified Monitoring and Analysis Platform (KUMA) мы заметили подозрительную активность, исходившую от нескольких телефонов на базе iOS."

Раскопали это:

"…мы смогли определить конкретные артефакты, указывающие на компрометацию. Это позволило продвинуть исследование вперед и реконструировать общую последовательность заражения:

- Целевое устройство iOS получает сообщение через службу iMessage с вложением, содержащим эксплойт.
- Без какого-либо взаимодействия с пользователем сообщение триггерит уязвимость, которая приводит к выполнению кода.
…"

В статье есть список C&C доменов для мониторинга.

Случайное совпадение с тем, что было в пресс-релизе? Не думаю. 🙂

По поводу новости про малварь на Apple iPhone устройствах в России

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

По поводу новости про малварь на Apple iPhone устройствах в России

По поводу новости про малварь на Apple iPhone устройствах в России. Почитал исходный пресс-релиз.

1. Речь о заражениях ранее неизвестной малварью, использующей уязвимости iPhone. Т.е. видимо это не NSO Group Pegasus, которая обычно в подобных новостях светится.
2. Утверждается, что уязвимости были намеренно "предусмотрены производителем", т.е. Apple.
3. Утверждается, что заражено несколько тысяч устройств.
3. Утверждается, что это операция АНБ.

Охотно верю, что так и было. Имхо, Apple это зло и их устройствами пользоваться нельзя. Тем более, что в этих устройствах нет никакой особой необходимости, чего, например, не скажешь о продуктах Microsoft или Google. Одна мнимая статусность и глупые привычки, сформированные маркетинговой истерией. Надеюсь, что одним пресс-релизом не ограничится и последуют конкретные запретительные меры. Как по мне, то у госслужащих и у работников связанных с КИИ никаких продуктов Apple быть в принципе не должно.

Руководство ФСТЭК по Управлению Уязвимостями

1 комментарий

Руководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 1. Общая структура.

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

1. Скорректировали название. Было "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)", стало "Руководство по организации процесса управления уязвимостями в органе (организации)". Новое название кажется более удачным. Тут и акцент именно на процесс, и вроде указывать уязвимости чего тоже смысла нет.
2. Общая структура документа не изменилась. Но добавили приложение с описанием BPMN элементов на схемах - полезная вещь.
3. Текстовая часть расширилась. Проект был на 29 страниц, релиз на 33 (включая одну страницу-приложение).

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

1 комментарий

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 3/3. Поддержка методик ФСТЭК.

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

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

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

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

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Positive Technologies MaxPatrol VM я смотрел текущую реализацию, для R-Vision VM, АЛТЭКС-СОФТ RedCheck и Фродекс VulnsIO пока нет.

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

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

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

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

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

Часть 2

Про CVE_Prioritizer и Vulristics

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

Про CVE_Prioritizer и Vulristics

Про CVE_Prioritizer и Vulristics. Несколько раз за последние месяцы натыкался на посты про CVE_Prioritizer. Но сегодня появился повод прокомментировать.

"CVE_Prioritizer is a powerful tool that helps you prioritize vulnerability patching by combining CVSS, EPSS, and CISA's Known Exploited Vulnerabilities. It provides valuable insights into the likelihood of exploitation and the potential impact of vulnerabilities on your information system."

Прикольная утилита, но, имхо, мой Vulristics приоритизирует покруче. 🙂 Он учитывает не только CVSS, EPSS и CISA KEV, но и тип уязвимости, распространенность софта, информацию об эксплоитах (из многих паков на Vulners) и атаках из AttackersKB.

И CVE_Prioritizer, и Vulristics для каждой уязвимости в динамике выполняют запросы к внешним источникам. Только у CVE_Prioritizer таких источников только 2 и поэтому он отрабатывает быстрее. Кроме того, Vulristics каждый раз в динамике определяет наименование софта и тип уязвимости по описанию. Это медленная операция. А в случае использования Vulners в качестве источника, всё это ещё и стоит денег 💸 (хотя лично мне не стоит, т.к. у меня ресерчерская лицензия - спасибо ребятам из Vulners!❤️). Так что с помощью Vulristics достаточно удобно оценивать 100-200 уязвимостей за раз (как в MS Patch Tuesday), а оценивать больше не особо рационально. 🙁

Что с этим можно сделать? Если заранее формировать полный (и желательно бесплатный/общедоступный 😉) фид по всем уязвимостям, чтобы Vulristics строил отчёт по готовым данным, это было бы гораздо быстрее и эффективнее. В этом случае можно было бы приоритизировать уязвимости хоть для всей инфраструктуры разом. У меня есть в некоторых долгосрочных планах этим заняться. Кто хочет поучаствовать - всегда welcome! 🙂