Архив за месяц: Июнь 2023

Посмотрел запись онлайн-запуска 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-ных каналов, тем лучше. 😉

Послушал эфир Сергея Вильянова с бывшим гендиром российского филиала Acer

Послушал эфир Сергея Вильянова с бывшим гендиром российского филиала Acer. Среди прочего, они обсуждали куда с российского рынка делись российские ноутбуки (iRU, Rover и прочее). Ничего сложного. Через жёсткий демпинг их за несколько лет убрали Acer и прочие зарубежные вендоры. А сейчас, абсолютно не стесняясь, об этом подробно рассказывают.

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

Ещё раз подивился тому как сильно по-разному воспринимают реальность обычные люди и гики (особенно гики-безопасники). В мире обычных людей, даже у тех кто вплотную с вычислительной техникой связан, вообще другие характеристики ноутбуков ценятся: красивый дизайн, чтобы работало быстро, было удобненько, экран четенький, чехольчик (!!), а стоило недорого. Какая там импортонезависимость, какая безопасность, НДВ и прочее. Это в лучшем случае есть в нашем мире, деформированных профессионально, и то не у всех, а другие люди в принципе никогда об этом не задумываются.

Поэтому к вопросу "а будут ли в России честные российские ноутбуки с высокой степенью локализации производства"? Вот прям до процессора. В условиях абсолютно свободной конкуренции точно нет. В условиях гарантированного спроса вызванного жёсткими регуляторными требованиями - возможно где-то и будут. Смотря как будут контролировать исполнение этих требований и карать за их обход. Но явно эти устройства будут не у физиков. Цена-качество у таких ноутбуков будет такое, что физики такие устройства будут покупать только если они абсолютные фанатики.

Это как с Ричардом Столлманом, который продолжительное время работал исключительно на дохленьком нетбуке Lemote Yeeloong с опенсурсным BIOS. Вот для него это было важно, а остальное не столь важно. Много ли среди нас Столлманов?

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

Первоначальные намётки по ОСОКА

Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:

▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные

1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

2. Эксплуатационные предлагаю сделать такие:

Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept ℗, Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).

Exploitation Activities: Not Defined (X), Reported ®, Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉

Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

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

3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.

Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты

Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%

Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»

Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.

Как вам?

Проекты, над которыми я сейчас размышляю

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

1. CVE Mentions. Переводить аналитические отчёты с упоминанием CVE-идентификаторов в формализованный вид, использовать их для приоритизации уязвимостей в Vulristics.

2. Свой Vulnerability Feed. Анализировать все CVE/БДУ, детектировать тип уязвимости и уязвимый продукт, наличие эксплоита и факта эксплуатации вживую. Использовать фид в Vulristics.

3. Linux Patch Wednesday. Формировать ежемесячные обзоры по Linux-овым уязвимостям. Написать скрипт для формирования скоупов CVE с разбивкой по месяцам.

4. ОСОКА. Система оценки критичности уязвимости на основе CVSS v3 и методики оценки критичности ФСТЭК. Расписать метрики, формулу расчета, автоматическую генерацию базовых метрик из CVSS Base v2, v3, v4.

5. Scanvus OVAL. Добавить в Scanvus возможность детектирования уязвимостей с использованием OVAL-контента без доступа к внешним платным API.

6. Scanvus Docker. Добавить возможность детектировать уязвимости Docker images без запуска контейнера, только через анализ SBOM.

7. Telegram2WordPress. Написать обвязку, которая будет раскидывать посты из телеграмма в блог на WordPress. Для упрощения навигации, улучшения индексации и на случай если Телеграмм снова начнут блокировать.

Mаппинг сегментов рынка по анализу защищённости от Gartner на мои группы VM-продуктов (2/2)

Mаппинг сегментов рынка по анализу защищённости от Gartner на мои группы VM-продуктов (2/2)

📌 Digital risk protection service (DRPS).

"Gartner defines DRPS as “a combination of technology and services in order to protect critical digital assets and data from external threats. These solutions provide visibility into the open (surface) web, social media, dark web, and deep web sources to identify potential threats to critical assets and provide contextual information on threat actors, their tools, tactics, and processes for conducting malicious activity.”

Сейчас фактически это дополнительная функциональность Средств Детектирования Уязвимостей Сетевого Периметра (СДУСП).

📌 Continuous Threat Exposure Management (CTEM)

"Gartner defines CTEM as a set of processes and capabilities that enable enterprises to continually evaluate the accessibility, exposure and exploitability of their digital and physical assets.

In short, CTEM is the center that informs governance, risk and compliance (GRC) mandates. Using CTEM, you can build mature, strategic security controls with detection and response capabilities that are always aligned with the business’s risk appetite."

Честно говоря, это "exposure" меня люто бесит. Более размытого и бессмысленного термина в мире ИБ найти сложно. Когда начинают затирать про "cyber exposure" или "threat exposure", я расцениваю это как 100% признак, что вендору нечего показать и остаётся только прятаться под завесой неконкретных слов и концепций. К "Tenable - The Exposure Management Company" это также относится. Но это тема для отдельного поста. Здесь же можно сказать, что любой способ анализа уязвимостей и инфраструктуры, который они смогут придумать, вполне ляжет в Средства Анализа Уязвимостей (САУ).

В общем, при желании все эти Gartner-овские придумки можно вполне успешно по моим группам VM-продуктов разложить. Не понимаю зачем Gartner заводит по аббревиатуре чуть ли не на каждую высокоуровневую фичу. Ну если не брать вариант, что они так каждому более-менее крупному вендору-спонсору могут выдать по отдельному сегменту и нарисовать его там стопроцентным уникальным лидером. 🙂

Часть 1

Mаппинг сегментов рынка по анализу защищённости от Gartner на мои группы VM-продуктов (1/2)

Mаппинг сегментов рынка по анализу защищённости от Gartner на мои группы VM-продуктов (1/2)

Алексей Лукацкий снова поднял тему моих аббревиатур для групп VM-продуктов и привёл перечень сегментов рынка по анализу защищённости от Gartner. Задачи полностью импортозаместить гартнеровские термины у меня никогда не было и я к этому не призывал. Я хотел только карту отечественных VM-вендоров более-менее адекватную нарисовать. Но за любое упоминание и буст канала всегда спасибо! 😊 Раз на то пошло, попробовал сделать маппинг этих Gartner-овских сегментов рынка на мои группы VM-продуктов.

📌 Vulnerability Assessment (VA)

"The vulnerability assessment (VA) market is made up of vendors that provide capabilities to identify, categorize and manage vulnerabilities. These include unsecure system configurations or missing patches, as well as other security-related updates in the systems connected to the enterprise network directly, remotely or in the cloud."

Довольно "резиновый" сегмент, т.к. не определяются методы детекта, виды активов, функциональность по анализу. В моих терминах решения из этого сегмента попадут в Средства Детектирования Уязвимостей Инфраструктуры (СДУИ), если они сами детекты уязвимостей делают, или Средства Анализа Уязвимостей (САУ), если позволяют анализировать уязвимости из сторонних источников.

📌 External attack surface management (EASM)

"External attack surface management (EASM) refers to the processes, technology and managed services deployed to discover internet-facing enterprise assets and systems and associated vulnerabilities which include exposed servers, credentials, public cloud service misconfigurations, deep dark web disclosures and third-party partner software code vulnerabilities that could be exploited by adversaries."

Здесь полное соответствие Средствам Детектирования Уязвимостей Сетевого Периметра (СДУСП).

📌 Cyber asset attack surface management (CAASM)

"Cyber Asset Attack Surface Management (CAASM) is an emerging technology that focused on presenting a unified view of cyber assets to an IT and security team. […] In order to detect assets containing outdated software, misconfigurations, and other vulnerabilities CAASM tools use API integrations to connect with existing data sources of the organization."

Это дополнительная функциональность по учету информации об активах в Средствах Анализа Уязвимостей (САУ). Т.к. подчеркивается, что интеграция с другими системами через API, проблем с добавлением сторонних уязвимостей быть не должно.

📌 Breach and attack simulation (BAS)

"Breach and Attack Simulation (BAS) Tools enable organizations to gain a deeper understanding of security posture vulnerabilities by automating testing of threat vectors such as external and insider, lateral movement, and data exfiltration."

Если есть возможность добавлять сторонние уязвимости, то это дополнительная функциональность по построению цепочек атак в Средствах Анализа Уязвимостей (САУ), если нет, то дополнительная функциональность в Средствах Детектирования Уязвимостей Инфраструктуры (СДУИ).

📌 Vulnerability prioritization technology (VPT)

Упоминается только в одном документе как обозначение для решений, которые сами уязвимости не детектируют, но занимаются только приоритизацией. В таком описании соответствуют Средствам Анализа Уязвимостей (САУ).

📌 Penetration and testing as a service (PTaaS)

Описания на сайте Gartner-а не нашел. Всё, что я видел, сводилось к периметровым сервисам с ручной валидацией. Поэтому пока выглядит как дополнительная функциональность Средств Детектирования Уязвимостей Сетевого Периметра (СДУСП).

📌 Automated pentesting and red teaming (а тут аббревиатуру пока не придумали)

Описания у Gartner в свободном доступе не нашел. Если эта штука будет касаться не только периметра, но и внутренней инфраструктуры, то будет похоже на продвинутый BAS и также можно будет уложить в Средства Анализа Уязвимостей (САУ) или Средства Детектирования Уязвимостей Инфраструктуры (СДУИ) в зависимости от возможности добавлять сторонние уязвимости.

Часть 2

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL. Они прекратили публиковать srpm-пакеты RHEL в репозитории git.centos.org. Теперь можно будет забирать только исходники пакетов нестабильного дистриба CentOS Stream. 😏 Естественно, Alma и Rocky оказались в щекотливом положении. Вендоров отечественных RPM-based дистрибутивов новость тоже, наверняка, не порадовала. Самый смачный пост был у Mike McGrath, "Vice President of Core Platforms Engineering at Red Hat". Вообще в выражениях не стесняется:

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

"В конечном счете, мы не находим ценности в ребилдерах RHEL-а и не обязаны облегчать жизнь ребилдерам"

"Простой ребилд кода без добавления ценности или какого-либо изменения представляет собой реальную угрозу для компаний с открытым исходным кодом во всем мире. Это реальная угроза открытому исходному коду, и она потенциально может вернуть опенсурс обратно в деятельность только для любителей […]".

Вот тебе и опенсурс. Как в КВНе было: "- Дайте полотенце - Вон там, на швабре возьмите". А кто-то ещё критикует МЦСТ за нарушение GPL. 😏

Так-то ещё с закапывания CentOS было понятно, что дело пахнет керосином и бежать нужно не на RHEL-клоны, а куда подальше.