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

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

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

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

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

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

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

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

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

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

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

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

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

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

Win­dows Desk­top
Win­dows Serv­er
Microsoft SQL Serv­er
Gener­ic Lin­ux
Ora­cle Data­base
VMware ESXi
VMware vCen­ter
Microsoft Exchange
RHEL-based Lin­ux
HP UX
IBM AIX
Lin­ux Ker­nel
Dock­er
Cis­co IOS
Cis­co IOS XE
Cis­co ASA года
Cis­co Nexus

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

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

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

Подробнее про PT Essen­tial — Lin­ux Ker­nel

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

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

Теперь официально поддерживается в Max­Pa­trol VM. Про вопросы к реализации я уже раньше писал, это не sil­ver bul­let пока. Но и в таком виде работать в Max­Pa­trol VM проще, чем считать руками или скриптовать своё. Эта функциональность реализована в виде PDQL фильтра, такие фильтры будут доступны в общей библиотеке.

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

Крутой запуск! Многая лета новому поколению Com­pli­ance Management‑а в Max­Pa­trol 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 Met­rics для Sub­se­quent Sys­tems (но это неточно). Также для User Inter­ac­tion будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

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

Exploit Matu­ri­ty: Not Defined (X), High (H), Func­tion­al (F), Proof-of-Con­cept ℗, Unre­port­ed (U) — эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Tem­po­ral вектора некоторых вендоров (например Microsoft).

Exploita­tion Activ­i­ties: Not Defined (X), Report­ed ®, Unre­port­ed (U) — это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или Attack­erKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 — преимущество ОСОКи. 😉

Exploita­tion Prob­a­bil­i­ty: Not Defined (X), High (H), Medi­um (M), Low (L) — это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

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

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

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

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

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

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

Как вам?

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

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

1. CVE Men­tions. Переводить аналитические отчёты с упоминанием CVE-идентификаторов в формализованный вид, использовать их для приоритизации уязвимостей в Vul­ris­tics.

2. Свой Vul­ner­a­bil­i­ty Feed. Анализировать все CVE/БДУ, детектировать тип уязвимости и уязвимый продукт, наличие эксплоита и факта эксплуатации вживую. Использовать фид в Vul­ris­tics.

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

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

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

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

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

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

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

📌 Dig­i­tal risk pro­tec­tion ser­vice (DRPS).

"Gart­ner defines DRPS as “a com­bi­na­tion of tech­nol­o­gy and ser­vices in order to pro­tect crit­i­cal dig­i­tal assets and data from exter­nal threats. These solu­tions pro­vide vis­i­bil­i­ty into the open (sur­face) web, social media, dark web, and deep web sources to iden­ti­fy poten­tial threats to crit­i­cal assets and pro­vide con­tex­tu­al infor­ma­tion on threat actors, their tools, tac­tics, and process­es for con­duct­ing mali­cious activ­i­ty.”

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

📌 Con­tin­u­ous Threat Expo­sure Man­age­ment (CTEM)

"Gart­ner defines CTEM as a set of process­es and capa­bil­i­ties that enable enter­pris­es to con­tin­u­al­ly eval­u­ate the acces­si­bil­i­ty, expo­sure and exploitabil­i­ty of their dig­i­tal and phys­i­cal assets.

In short, CTEM is the cen­ter that informs gov­er­nance, risk and com­pli­ance (GRC) man­dates. Using CTEM, you can build mature, strate­gic secu­ri­ty con­trols with detec­tion and response capa­bil­i­ties that are always aligned with the business’s risk appetite."

Честно говоря, это "expo­sure" меня люто бесит. Более размытого и бессмысленного термина в мире ИБ найти сложно. Когда начинают затирать про "cyber expo­sure" или "threat expo­sure", я расцениваю это как 100% признак, что вендору нечего показать и остаётся только прятаться под завесой неконкретных слов и концепций. К "Ten­able — The Expo­sure Man­age­ment Com­pa­ny" это также относится. Но это тема для отдельного поста. Здесь же можно сказать, что любой способ анализа уязвимостей и инфраструктуры, который они смогут придумать, вполне ляжет в Средства Анализа Уязвимостей (САУ).

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

Часть 1

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

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

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

📌 Vul­ner­a­bil­i­ty Assess­ment (VA)

"The vul­ner­a­bil­i­ty assess­ment (VA) mar­ket is made up of ven­dors that pro­vide capa­bil­i­ties to iden­ti­fy, cat­e­go­rize and man­age vul­ner­a­bil­i­ties. These include unse­cure sys­tem con­fig­u­ra­tions or miss­ing patch­es, as well as oth­er secu­ri­ty-relat­ed updates in the sys­tems con­nect­ed to the enter­prise net­work direct­ly, remote­ly or in the cloud."

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

📌 Exter­nal attack sur­face man­age­ment (EASM)

"Exter­nal attack sur­face man­age­ment (EASM) refers to the process­es, tech­nol­o­gy and man­aged ser­vices deployed to dis­cov­er inter­net-fac­ing enter­prise assets and sys­tems and asso­ci­at­ed vul­ner­a­bil­i­ties which include exposed servers, cre­den­tials, pub­lic cloud ser­vice mis­con­fig­u­ra­tions, deep dark web dis­clo­sures and third-par­ty part­ner soft­ware code vul­ner­a­bil­i­ties that could be exploit­ed by adver­saries."

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

📌 Cyber asset attack sur­face man­age­ment (CAASM)

"Cyber Asset Attack Sur­face Man­age­ment (CAASM) is an emerg­ing tech­nol­o­gy that focused on pre­sent­ing a uni­fied view of cyber assets to an IT and secu­ri­ty team. […] In order to detect assets con­tain­ing out­dat­ed soft­ware, mis­con­fig­u­ra­tions, and oth­er vul­ner­a­bil­i­ties CAASM tools use API inte­gra­tions to con­nect with exist­ing data sources of the orga­ni­za­tion."

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

📌 Breach and attack sim­u­la­tion (BAS)

"Breach and Attack Sim­u­la­tion (BAS) Tools enable orga­ni­za­tions to gain a deep­er under­stand­ing of secu­ri­ty pos­ture vul­ner­a­bil­i­ties by automat­ing test­ing of threat vec­tors such as exter­nal and insid­er, lat­er­al move­ment, and data exfil­tra­tion."

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

📌 Vul­ner­a­bil­i­ty pri­or­i­ti­za­tion tech­nol­o­gy (VPT)

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

📌 Pen­e­tra­tion and test­ing as a ser­vice (PTaaS)

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

📌 Auto­mat­ed pen­test­ing and red team­ing (а тут аббревиатуру пока не придумали)

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

Часть 2

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

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

Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL. Они прекратили публиковать srpm-пакеты RHEL в репозитории git.centos.org. Теперь можно будет забирать только исходники пакетов нестабильного дистриба Cen­tOS Stream. 😏 Естественно, Alma и Rocky оказались в щекотливом положении. Вендоров отечественных RPM-based дистрибутивов новость тоже, наверняка, не порадовала. Самый смачный пост был у Mike McGrath, "Vice Pres­i­dent of Core Plat­forms Engi­neer­ing at Red Hat". Вообще в выражениях не стесняется:

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

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

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

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

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