Архив метки: ФСТЭК

Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной

Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной.

00:00 Паша торжественно бьёт в дуршлаг, здороваемся, я рассказываю чем занимаюсь и пиарю свои телеграмм-канальчики. 🙂
01:32 Как я начал заниматься безопасностью и VM-ом. Рассказываю как я довольно случайно прошёл на ИУ8 МГТУ Баумана по собеседованию для медалистов. VM-ом начал заниматься из-за первой работы в Позитиве и вот так дальше пошло-поехало.
04:06 Пригодился ли мне универ? Рассказываю, что, как и многие, не понял прикол с дикими объемами дискретки. Но безусловно базу дало. Не устаю пиарить курс Валентина Цирлова по ТОИБАС.
06:00 Начинаем с определения уязвимости. Определяю как багу, которую может использовать злоумышленник. Миша накидывает про мисконфигурации. Я вспоминаю про CCE и CCSS.
08:23 Классическая тема: сканеры уязвимостей, Vulnerability Management решения, Vulnerability Management процесс. Выражаю скепсис по поводу принципиальной разницы между сканером уязвимостей и VM-решением. Вспоминаю про шведов с Антифишингом в VM-ме. Паша накидывает: а нужен ли в VM-е контроль целостности? VM-процесс он про исправление уязвимостей, причём силами IT.
13:36 Миша спрашивает: "Что входит в процесс управления уязвимостями"? По факту на вопрос не отвечаю, а рассказываю почему основа VM-а это управление активами. 😏
18:59 Обсуждаем CVSS и методику оценки критичности уязвимостей ФСТЭК. Вспоминаю ОСОКу. Трендовых уязвимостей тоже касаемся. Агитирую за безусловный патчинг, указывая на куцые описания уязвимостей из MS Patch Tuesday. Вспоминаю про Linux Patch Wednesday.
30:38 Безусловные обновления плохо сочетаются с требованиями по проверке патчей западного ПО, включая open source. Выход? Импортозамещение! Рекомендательный алгоритм НКЦКИ и методика оценки обновлений ФСТЭК, что из этого более приоритетно? Вопрос к методологам.
34:40 Призываем отечественных вендоров публиковать уязвимости.
37:38 Vulnerability Management процесс в организации сложно построить? Какие люди нужны? Организации разные. Начинать нужно с руководства. Рассказываю про докажи-покажи.
43:21 Можно ли построить VM-процесс на open source решениях? Вполне реально сканить порты, детектить линуксовые уязвимости по пакетам. Но есть ограничения детектирования и спросить вам будет не с кого. С Windows всё плохо.
48:16 Обсуждаем уход западных VM-решений с российского рынка. Как это было?
50:17 Обсуждаем должен ли Compliance Management входить в VM и в чём проблема текущей реализацией CM в VM решениях и текущих стандартов конфигурирования.
56:52 Какая функциональность должна быть реализована в VM решении это вопрос регуляторный. Может нужна сертификация? 🤔
58:24 Крутое VM-решение для каждого клиента своё. Кому-то нужна "коробка", кому-то только детекты.
01:02:11 Вопрос VM-вендорам: почему такая разница в результатах детектирования между решениями от двух вендоров? Может сертификация нужна? 🤔 Паша и Миша накидывают кейсы по MS, которые могут давать расхождения. Хорошо, когда логика детектирования прозрачна и доступна для изучения.
01:07:00 Как я вижу развитие VM решений. Хотелось бы хорошего качества детектирования с фокусом в сторону импортозамещающей инфры. Также хотелось бы возможностей по добавлению уязвимостей со стороны и собственных детектов.
01:11:09 Торжественное вручение мне ведра с подарками. 😁

Подписывайтесь на КиберДуршлаг на удобных вам платформах по ссылкам в официальном посте!

Прожектор по ИБ, выпуск №4 (24.09.2023)

Прожектор по ИБ, выпуск №4 (24.09.2023). Записали вчера очередной эпизод, состав тот же:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Digital Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enterprise Security Suite
19:04 Cisco покупает Splunk
25:59 Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Linux уязвимостей на примере CVE-2022-1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова. На сайте реестра российского ПО Минцифры у каждого ПО есть своя страничка. И в этой страничке отмечаются уязвимости из БДУ для этого ПО, устранённые и неустранённые. На страничке Dr.Web Enterprise Security Suite значилась неустранённой древняя уязвимость BDU:2014-00226. Там суть в том, что обновления качаются по HTTP без шифрования. Непорядок. Но вроде как это уже и пофиксили давно. Но когда приостановили действие сертификата, уязвимость на странице софта значилась неустранённой, а когда восстановили действие, то уязвимость на странице стала показываться как устранённая. Т.е. кипеш был из-за странной уязвимости 2014 года? 🧐 Похоже на то.

Мораль: если ваше ПО есть в реестре Минцифры и у вас есть сертификат ФСТЭК, мониторьте раздел "неустранённые уязвимости" и активно исправляйте или доказывайте, что уже исправили. А то могут быть проблемки.

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?"

Алексей Лукацкий вкинул сегодня вопрос: Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?" Он проиллюстрировал это тем, как Microsoft проставляет свой уровень критичности для уязвимости без привязки к CVSS, учитывая, среди прочего, вероятность реализации успешной брутфорс-атаки.

Имхо, ответ на поверхности:

1. CVSS это не священная корова. CVSS это просто опросник. С довольно произвольными полями. С довольно произвольной формулой расчёта скоринга. И сами авторы из First регулярно шатают CVSS только в путь.

2. Сделать свою систему приоритизации уязвимостей не rocket science, а свой пиар-эффект среди ширнармасс оно даёт. Особенно если написать про "внутри у ней нейронка" и про миллион анализируемых параметров.

То, что "систем приоритизации уязвимостей сегодня уже под десяток от разных компаний, организаций и регуляторов" и это "мешает установлению некоего единого языка общения между специалистами" действительно так, не поспоришь. Но это объективная реальность. От призывов, допустим, сплотиться вокруг наступающего CVSS 4.0 она не изменится.

Как мне кажется, нам в России тоже следовало бы отойти от прямого использования CVSS as is в сторону чего-то более практичного и опирающегося на отечественные методические рекомендации, но с возможностью использовать CVSS-векторы в качестве источника данных.

Моя ОСОКА здесь как пример. 😉 Про неё не забываю. После адаптации инфраструктурных метрик понимание как должен выглядеть полный вектор уже есть. Следующей этап - накодить калькулятор.

Как обучать Vulnerability Management-у?

Как обучать Vulnerability Management-у?

Как обучать Vulnerability Management-у? Мне предложили поучаствовать в записи онлайн-курса переподготовки по ИБ для МГТУ им. Н.Э. Баумана в части VM-а. 🎓

Аудитория: слушатели курсов по профессиональной переподготовке и студенты ИБ-шники
Дедлайн: конец августа
Фронт работ: 3 ролика по 20-25 минут

Темы:
🔹 Анализ защищённости
🔹 Управление уязвимостями
🔹 Управление обновлениями

Объем небольшой, но можно сделать первый подход к полноценному семестровому курсу.

Пока у меня задумка такая:

1. Видео по анализу защищённости хочу посвятить тому, что такое уязвимости и техническим способам детектирования уязвимостей. Простые виды веб-уязвимостей продемонстрирую на своём старом проекте уязвимого приложения. Сканирование в режиме "чёрного ящика" рассмотрим на примере cpe-детектов в nmap с Vulners плагином. Для Linux уязвимостей (включая Docker-образы) рассмотрим бюллетени безопасности и SCAP-контент. Для Windows уязвимостей рассмотрим Patch Tuesday и поговорим о KB-шках. Цель - показать как работают сканеры уязвимостей, подсвятить какие там есть проблемы и сложности.

2. Видео по управлению уязвимостями планирую построить на той идее, что управление уязвимостями это не только их детектирование, а комплексный процесс, который должен быть выстроен в организации. Оттолкнемся от руководства ФСТЭК по организации VM-процесса. Разберем способы приоритизации уязвимостей (также на примере методики ФСТЭК). Коснёмся основных метрик, за которыми следует следить: покрытие хостов в инфраструктуре VM-процессом, выполнение SLA по исправлению уязвимостей. Поговорим о Vulnerability Intelligence и о том, что делать, когда для уязвимости нет автоматизированных детектов.

3. Видео по управлению обновлениями хочу построить вокруг идеи, что уязвимостей очень много, разбираться с каждой по отдельности накладно, а выход в том, чтобы договариваться с IT-шниками о процессе регулярного безусловного обновления систем. Это позволит VM-щикам избавиться от рутины и уделять больше времени наиболее критичным трендовым уязвимостям и уязвимостям, которые простым обновлением не фиксятся. Здесь хотелось сформулировать лучшие практики по общению с IT: распространенные уловки и способы их обойти, методы эскалации, идеи по метрикам/презентациям для руководства и т.п. Здесь же коснемся требований ФСТЭК по контролю безопасности обновлений и, как следствие, необходимости скорейшего импортозамещения IT-систем.

Собираю комментарии и пожелания в посте в ВК. 😉

Инфраструктурные метрики ОСОКА

Инфраструктурные метрики ОСОКА

Инфраструктурные метрики ОСОКА. Предлагаю вот такие метрики с маппингом на показатели/значения из методики оценки уровня критичности уязвимостей ФСТЭК.

Т.е. инфраструктурная часть вектора для "десктопной уязвимости, которой подвержены 20% десктопов, без возможности эксплуатации на периметре" будет выглядеть так:

AT:D/AS:M/PS:N

Посмотрел запись онлайн-запуска MaxPatrol VM 2.0 и MaxPatrol HCC

Посмотрел запись онлайн-запуска MaxPatrol VM 2.0 и MaxPatrol HCC. Выписал некоторые тезисы. 🙂

По уязвимостям

В рамках пилотов MaxPatrol VM в организациях находят в среднем ~30к уязвимостей, из них ~50 особо критичных и легко эксплуатируемых.

Главное согласовать SLA на исправление уязвимостей в организации. Идеально укладываться в 24 часа для особо критичных (что и ФСТЭК рекомендует).

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

От меня: фокус на собственную приоритизацию сейчас у всех топовых VM-вендоров. Например, Tenable VPR и Qualys TruRisk. Дело хорошее 👍

Информация о трендовых уязвимостях попадает в MaxPatrol VM с минимальной задержкой благодаря архитектурным изменениям в базе знаний. Привели пример кейса по добавлению трендовой уязвимости для софта (22:45), который в MaxPatrol VM вообще не поддерживается (VirtualBox). Если вдруг будет трендовая супер-критичная уязвимость, несмотря на отсутствие поддержки, исследователь добавит её с SLA в 12 часов.

По контролю конфигураций

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

Предлагается следующий процесс:

Этап 1.
1. Определение регламента принятых стандартов. Возможно надергать требований из CIS Benchmarks, чтобы составить свой.
2. Определение правил и задач по работе со стандартом, которые направляются IT-специалисту.
3. Проверка соответствия активов.
4. Проводим troubleshooting, возможно с видоизменением стандарта.
5. Принятие и внедрение стандарта на живую информационную систему.
Этап 2.
Работа с отчётами по нарушению требований (исправление или корректировка стандартов), разработка новых стандартов.

Сейчас в HCC доступный 17 стандартов PT Essential (44:13). Они разработаны совместно с пентестерами:

Windows Desktop
Windows Server
Microsoft SQL Server
Generic Linux
Oracle Database
VMware ESXi
VMware vCenter
Microsoft Exchange
RHEL-based Linux
HP UX
IBM AIX
Linux Kernel
Docker
Cisco IOS
Cisco IOS XE
Cisco ASA года
Cisco Nexus

Можно отслеживать коммуникацию с IT и выполнение установленных сроков в рамках политик.

Отдельного комплаенс сканирования нет, используется та же инвентаризация аудита. Проверки реализованы в виде запросов на собственном языке. Функционально можно сравнить с .audit от Tenable. Есть шансы, что в перспективе дадут делать свои проверки на нем. 😉

Из PT Essentials можно надёргать требований и составить из них свой стандарт.

Подробнее про PT Essential - Linux Kernel

В ядре Linux >30 млн. строк кода, 4000 разработчиков в год участвуют, каждый день 8000 строк меняются. Множество уязвимостей, особенно из-за ошибок доступа к памяти. Уязвимости добавляются быстрее, чем исправляются. Среднее время жизни критической уязвимости в ядре 5,5 лет. Проект Kernel Self Protection Project - "подушка безопасности" для устранения некоторых проблем как класса. Есть карта средств защиты ядра. Стандарт для ядра Linux был реализован с использованием этой карты и собственной дефенс экспертизы. Эти же требования были использованы в стандарте по настройке Linux систем от ФСТЭК. 👍

Методика ФСТЭК по оценке критичности уязвимостей

Теперь официально поддерживается в MaxPatrol VM. Про вопросы к реализации я уже раньше писал, это не silver bullet пока. Но и в таком виде работать в MaxPatrol VM проще, чем считать руками или скриптовать своё. Эта функциональность реализована в виде PDQL фильтра, такие фильтры будут доступны в общей библиотеке.

Добавили интеграцию с LAPS, чтобы избегать компрометации учёток с правами админа на многих хостах.

---

Крутой запуск! Многая лета новому поколению Compliance Management-а в MaxPatrol HCC! Буду активно отслеживать эту тему. 🙂 И не только я. Валерий Ледовской из X-cofig запустил канал по CM и тоже поделился впечатлениями от запуска HCC, зацените и подпишитесь! Взгляд со стороны прямых конкурентов это всегда любопытно. И чем больше будет авторских околоVM-ных каналов, тем лучше. 😉