На днях вышла openKylin v.1.0. По описанию существенных отличий от 0.7 не видно, но нужно тестить. 🙂 Также непонятно, как обстоят дела с бюллетенями безопасности. Для коммерческой Kylin OS они есть, а для openKylin я пока не нашел.
Посмотрел запись онлайн-запуска 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-ных каналов, тем лучше. 😉
Наблюдаю за попыткой 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-клоны, а куда подальше.
Linux Patch Wednesday? Раз уж значение Linux-а у нас стремительно растёт, выглядит правильным смещать фокус внимания с уязвимостей продуктов Microsoft на уязвимости Linux. При этом для продуктов Microsoft у нас есть единый день повышенного внимания - Microsoft Patch Tuesday, а для Linux такого нет. Слишком там всё фрагментировано и патчи выпускаются буквально ежедневно. Но что нам мешает самостоятельно раз в месяц формировать список исправленных за месяц CVE-шек и подсвечивать критичное? Кажется ничего. Список CVE можно получать, например, через парсинг OVAL-контента дистрибутивов (а кто такое не публикует - позор им 🙂).
Выпускать подобное предлагаю в каждую третью среду месяца и называть Linux Patch Wednesday. Как вам идейка?
CNews удивительные. 🤡 У них не только карты ИБ-вендоров смешные. Выпустили ТОП вендоров отечественных ОС. В одном топе у них вендоры российских десктопных/серверных Linux-ов и вендор мобильной ОС. И рисуют ОМП Авроре 0.9 % "рынка продаж", типа аутсайдеры. А сколько, извините, остальные вендоры заработали на мобильных ОС за год? И есть ли они у них вообще? Ну, кроме гипотетической РОСА Мобайл. 🙂
Про SberLinux. С одной стороны круто, что появился "дистриб от крупной российской окологосударственной IT компании", как раз о чем я писал в прошлом году. 🙂 С другой стороны, это, конечно, совсем не "бесплатный базовый Linux дистрибутив", который бы хотелось видеть. Видимо такое выпускать мало кому интересно. 🙂 Platform V SberLinux OS Server это прежде всего операционная система для облачной платформы "ГосТех". И декларируемое описание этого дистрибутива заставляет задуматься о том, что же такое "отечественная ОС":
"Дистрибутив ОС GNU/Linux. На 100% бинарно и bug-for-bug совместимый с дистрибутивом ОС RedHat Enterprise Linux версии 8.6 и выше".
Т.е. этот дистрибутив полностью, даже в части нежелательных функций, это такой же RHEL 8. Фактически это аналог AlmaLinux, Rocky Linux, Oracle Linux. Хорошие проекты, но являются ли они российскими ОС? Ну, очевидно нет. Если в американской компании Red Hat вдруг решат добавить бэкдор для систем с российским IP, то bug-for-bug этот бэкдор придет и в SberLinux, и в Гостех.
В описании вакансии QA Engineer (SberLinux) можем прочитать:
"Команда SberLinux OS DevTeam формирует команду создания дистрибутива ОС Linux 100% бинарно-совместимого с Red Hat Enterprise Linux для реализации инициативы технологической независимости от поставок лицензий и предоставления поддержки вендора.
Цель: Обеспечение технологической независимости в части ОС Linux для Группы Сбера."
Но достаточно ли независимости от поставок лицензии и независимой поддержки, для того, чтобы считать ОС российской? Сейчас видимо да.
Можем довести до абсурда. Допустим, в России есть некая ООО "Гигасофт". Эта компания заключает OEM договор с Microsoft на выпуск ОС Gigasoft Doors, которая на 100% бинарно и bug-for-bug совместима с Microsoft Windows. Потому что это Microsoft Windows и будет, только "Windows" везде на "Doors" заменено и логотип изменен. Лицензии можно приобретать у ООО "Гигасофт", за поддержкой тоже к ним. Это что же получается, Gigasoft Doors будет отечественной ОС, обеспечивающей "технологическую независимость"? Ну, странно ведь получается, как думаете?
По поводу предыдущей картинки, вынесу из комментов в ВК.
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.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.