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

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (1/3)

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

Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (1/3). 😉

Часть 1. РЫНОК СИСТЕМ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ В РОССИИ

1. Что входит в современное понимание процесса управления уязвимостями (Vulnerability Management)?

Управление уязвимостями это их детектирование и исправление. Остальное всё опционально. Вон Holm Security считают, что в современном Vulnerability Management решении обязательно должен быть Антифишинг встроенный. И чего теперь, не будем VM-решения без встроенного Aнтифишинга за современный VM считать? 🙂 Не ведитесь на маркетинг, обращайте внимание на главное - качество детектирование. А на исправление влияет в первую очередь то, как вы договоритесь со своими админами/девопсами. Коробочное решение за вас это не сделает.

2. Каковы основные драйверы рынка управления уязвимостями?

a. Западные VM-решения отвалились, все кинулись активно импортозамещаться.
b. IT-инфраструктура также импортозамещается. VM-вендоры должны за этим поспевать, поддерживать все эти континенты, 1С-ы, отечественные Linux-ы и прочее. База знаний отечественного VM решения станет сильно отличаться от западного.
c. Регуляторы стали уделять процессу управления уязвимостями гораздо больше внимания.

3. Усложнился ли процесс управления уязвимостями с уходом из России зарубежных вендоров?

Безусловно. Уход VM-вендоров = отвалившиеся VM-процессы. Уход IT-вендоров = поиски решений, которые могут детектировать уязвимости в импортозамещенных продуктах.

4. Обнаруживать уязвимости можно обычным сканером. Что понимается под непосредственно “управлением”?

См. вопрос 1. Управление активами, оценка и приоритизация уязвимостей это всё доп. функциональность. "Если вы надетектили уязвимости как-то и приняли решение, что с ними дальше делать (устранять, смягчать, оставить как есть) и сделали отчет для начальства, то поздравляю, это уже Vulnerability Management."

5. Vulnerability Management — это непрерывный процесс или набор разовых лимитированных активностей?

Это набор нескольких непрерывных процессов. "Все, что в "лепестках" должно идти одновременно, параллельно, автоматически. Нет "сканов-ресканов", есть процесс поддержания инвентори/детектов и его улучшения. Разбор и переоценка уязвимостей отдельный процесс. Пушинг их исправления тоже."

6. Как Vulnerability Management связан с Continuous Penetration Testing?

Continuous Penetration Testing это считай сервис сканирования периметра + обработка результатов аналитиками вендора. VM-решение это продукт, а CPT это, по сути, услуга. Также можно спросить: как связан Vulnerability Management и Bug Bounty. Как-то связан: и там уязвимости, и там. Нужно сливать воедино? Если VM-решение позволяет заносить уязвимости из сторонних источников - почему бы и нет.

7. Какими функциями обладают системы (платформы) управления уязвимостями?

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

8. Можно ли управлять уязвимостями без специальных систем?

Без качественных средств детектирования уязвимостей очень тяжко. Если есть продетектированные уязвимости, остальное можно накодить самим или взять open source решение.

9. Какие сотрудники компании должны быть вовлечены в процесс управления уязвимостями?

ТОП-ы, ИБ-подразделение, ИТ-подразделение. У PT про это хорошо расписано.

10. Как выглядит процесс управления уязвимостями в специализированной системе?

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

11. Как обосновать покупку системы управления уязвимостями?

Совсем без средств детектирования уязвимостей не узнаешь состояние инфраструктуры и она будет деградировать в полнейшее решето. Другое дело какое именно решение брать - тут могут быть варианты. Сочетание "грамм-градус-копейка" для всех будет разным.

Алексей Лукацкий выложил слайды своей презентации по VM-у от 2008 года

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

Алексей Лукацкий выложил слайды своей презентации по VM-у от 2008 года. Я тогда ещё в универе учился и ни о каких сканерах уязвимостей не задумывался. "Будь я нескромен, сказал бы, что я - пророк 😊". В целом да, справедливо, всё в примерно эту сторону и развивается. Пару слайдов я даже не удержусь, стащу для своей презы. 😉

Хочется, правда, обратить внимание, что все слайды (кроме одного - "рост сканирующих возможностей") про то, что нам делать с имеющейся информацией об уязвимостях инфраструктуры. С чем нам ещё интегрироваться, какие ещё управляющие воздействия на основе факта наличия уязвимостей сделать. Как будто бы информация об уязвимостях для всех активов организации уже есть или может быть тривиальна получена. И эта информация достоверна, полна и достаточна. Это, разумеется, не так. Это никогда не было так и долго ещё не будет. Просто редко кто-то смотрит под капот, как на самом деле работают детекты и какие ограничения у них есть. А запроса на открытые базы детектов уязвимостей, которые позволяли бы хотя бы приблизительно оценивать "слепые пятна" у средств Управления Уязвимостями (Сканеров Уязвимостей, СДУИ - как угодно) как не было, так и нет. И со стороны VM-вендоров он не появится, им туда лезть невыгодно. Он должен подниматься снизу, формулируйте и задавайте им неудобные вопросы, товарищи!

Первые впечатления от майского Microsoft Patch Tuesday

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

Первые впечатления от майского Microsoft Patch Tuesday

Первые впечатления от майского Microsoft Patch Tuesday. Давненько не было таких малюсеньких Patch Tuesday. 57 CVE с учетом набежавших за месяц. А если смотреть выпущенные только во вторник, то всего 38! 😄

1. Memory Corruption - Microsoft Edge (CVE-2023-2033). Наиболее критичная, но вендоры не подсвечивают. Это уязвимость в Chrome, о которой три недели трубят. Естественно касается и Edge. Есть в CISA KEV.
2. Security Feature Bypass - Secure Boot (CVE-2023-24932). Уязвимость используется в BlackLotus UEFI bootkit.
3. Memory Corruption - Microsoft Edge (CVE-2023-2136). Ещё одна критичная уязвимость в Chrome, есть в CISA KEV.
4. Elevation of Privilege - Windows Win32k (CVE-2023-29336). Пишут, что возможно уязвимость эксплуатируется при открытии зловредного RTF файла. Есть в CISA KEV.
5. Remote Code Execution - Microsoft SharePoint (CVE-2023-24955). Уязвимость продемонстрирована на Pwn2Own Vancouver.

Полный отчет Vulristics

Методические документы регуляторов, связанные с Управлением Уязвимостями

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

Методические документы регуляторов, связанные с Управлением Уязвимостями. В презентации, которую я сейчас готовлю к ISCRA Talks, будет слайд про документы регуляторов связанные с VM-ом, выпущенные за последние 1,5 года. Если я что-то важное пропустил, напишите мне, пожалуйста, в личку или комментом в пост в ВК.

1. НКЦКИ "Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source". Рекомендательный алгоритм, помогающий принять решение: установить обновление с риском привнести НДВ (недекларированные возможности)/блокировку функциональности или не обновлять с риском получить эксплуатацию уязвимости. Этого алгоритма я касался в выступлении на PHDays 11 и писал скрипты автоматизации проверок по нему в рамках опенсурсного проекта Monreal.

2. ФСТЭК "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств". Описывает каким образом можно получить общую оценку критичности уязвимости и выставить требования по оперативности исправления. Я писал комментарии по этой методике.

3. ФСТЭК "Методика тестирования обновлений безопасности программных, программно-аппаратных средств". Описывает какими способами искать НДВ в обновлениях безопасности. Мои комментарии к этой методике: Часть 1, Часть 2, Часть 3.

4. ФСТЭК "Рекомендации по безопасной настройке операционных систем Linux". Рекомендации распространяются на настройку НЕсертифицированных ОС (Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Я разбирал эти рекомендации.

5. ФСТЭК "Руководство по организации процесса управления уязвимостями в органе (организации)". Подробное описание этапов процесса, участников процесса и выполняемых ими операций. Я написал комментарии к проекту руководства "процесс не для человеков" и "место автоматического детектирования уязвимостей".

По поводу предыдущей картинки, вынесу из комментов в ВК

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

По поводу предыдущей картинки, вынесу из комментов в ВК.

1. В другом качестве картинки нет, стащил из аккаунта Nucleus в соцсеточке, на сайте у них не нашел. 🤷‍♂️ Но это просто статистика по второй колонке из CISA KEV.

2. "Возможно большее количество уязвимостей говорит о большей распространенности и большем числе продуктов вендора. А Linux - здесь наверное только linux kernel?" Да, Linux это только Linux Kernel, а Microsoft это все продукты Microsoft, включая Windows Kernel. Но то, что продукты Microsoft наиболее активно атакуются - факт. Отказ от продуктов Microsoft поднимет защищённость хотя бы по логике "если у вас нет собаки, её не отравит сосед". 🙂

3. "Как эппл и адоб умудрились заслужить столько?" У Adobe основной генератор дырок это PDF reader. Apple macOS, к сожалению, достаточно популярная десктопная ОС, для неё регулярно находят критичные RCE уязвимости. В основном в ядре и WebKit. Средств администрирования и защиты информации для macOS меньше и они не так развиты. Поэтому, имхо, устройства Apple в инфраструктуре это даже большая проблема, чем продукты Microsoft.

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

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

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям. Навели статистику по вендорам. К статистике наведенной по всем уязвимостям из NVD я отношусь обычно скептически - непонятно то ли у вендора такие дырявые продукты, то ли вендор наоборот ответственно подходит к уязвимостям в своих продуктах и заводит CVE на каждый чих. Здесь же рассматриваются только уязвимости с признаками эксплуатации в реальных атаках, просто так в CISA KEV не попадают. Поэтому вполне справедливо будет сделать вывод: если у вас инфраструктура на продуктах Microsoft, то уровень риска у вас соответствует этому громадному кружку, а если на Linux, то гораздо меньшему кружку (его так сразу и не заметишь). Выпиливайте у себя Microsoft! Хотя бы стратегически двигайтесь в этом направлении. Тоже касается и других больших кружков: CISCO, Apple, Oracle, Adobe. Google выпилить скорее всего не получится - это вездесущий Chromium. 🙂

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали

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

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали. Видимо теперь уже до доработанного официального релиза. Поэтому ту публичную версию от 31 марта заливаю сюда. Чтобы было понятно к чему относятся мои комментарии про "процесс не для человеков" и "место автоматического детектирования уязвимостей". Кроме того, после официального релиза будет интересно посмотреть, что изменилось по сравнению с проектом.