Архив за месяц: Ноябрь 2022

Про Linux-ы хорошо заходит

Про Linux-ы хорошо заходит. 🙂 К предыдущему посту набралось много комментариев в VK. К сожалению, у меня создалось такое впечатление, что со многими комментаторами мы не сошлись во мнении из-за того, что писали о разных вещах. Поэтому ещё раз переформулирую почему я считаю, что свободный бесплатный базовый российский Linux дистрибутив нам нужен и делать его видимо лучше независимо от существующих вендоров коммерческих Linux дистрибутивов.

Я на это дело смотрю несколько со стороны. Я не CTO, не системный архитектор и даже не сисадмин. Я безопасник. Мне так-то все равно на чем строится инфраструктура. Не считаю выбор конкретных решений своей зоной ответственности. Хоть на Windows, хоть на Linux платном или бесплатном, хоть на BSD, хоть на AIX и HPUX, хоть на KasperskyOS. Я могу что-то там высказать со своей колокольни, но бизнесу и IT безусловно виднее. Моё дело разбираться как контролировать уязвимости для всего этого безобразия, как его обновлять и харденить. Есть бюллетени безопасности? Класс. Они ещё и в машиночитаемом виде? Супер! Поддерживается сканером уязвимостей? Совсем здорово!

Вместе с тем сложно не замечать тот факт, что инфраструктура больших российских (и естественно не только российских) компаний в настоящий момент по большей части состоит из Linux серверов как железных, так и виртуальных. И используемые Linux дистрибутивы по большей части бесплатные. То есть это как раз-таки Debian, CentOS (Alma/Rocky), Ubuntu. Вопрос в следующем: а на что будут заменяться конкретно эти сервера к 2025 году? Такой конкретный вопрос, остальное импортозамещение в расчет не берем.

И тут видятся следующие варианты:

1. Они вообще не будут заменяться. И тогда зависимость от, по факту, западных решений останется с понятными рисками. И регулятору в виде ФСТЭК такой вариант видимо не особо нравится, см. предыдущий пост про Методику оценки критичности уязвимостей, а конкретно про тестирование патчей для опенсурса.
2. Они будут заменяться на отечественные коммерческие сертифицированные Linux-ы со $100 за лицензию. Про сто баксов это условно, т.к. там есть конкуренция (пока) и на объемах в тысячи и десятки тысяч хостов стоимость будет пониже. Но в любом случае дополнительные затраты будут ощутимые. И это будет уже не вполне тот Linux, который мы любим, ценим и везде используем, в том числе, и из-за возможности за лицензию не платить и разворачивать столько хостов, сколько потребуется.
3. Они будут заменены бесплатным отечественным базовым Linux дистрибутивом. Как раз-таки аналогом "Debian, CentOS (Alma/Rocky), Ubuntu" в том числе и по свободности и бесплатности, но разрабатываемым в России и контролируемым из России. Могут ли российские вендоры коммерческих Linux-ов сделать и поддерживать такой дистриб, включив его в реестр российского ПО, чтобы у компаний и частных лиц была такая опция для импортозамещения? Да конечно могут. Легко! А делают они это? Нет, потому что зачем вредить своему основному бизнесу на торговле лицензиями. Если я здесь не прав и такой вендор и дистриб есть, то назовите его и "свободный бесплатный базовый российский Linux дистрибутив" это будет вот он, сам же буду за него ратовать.

Но пока выглядит, что у государства один интерес - максимально снизить зависимость в том числе от "Debian, CentOS (Alma/Rocky), Ubuntu". А у существующих вендоров коммерческих Linux-ов другой - заработать и выжить на конкурентном рынке. Интересы и цели разные.

Поэтому и приходят в голову идеи, что заниматься разработкой и поддержкой бесплатного базового Linux дистрибутива должны вообще не они, а крупные российские окологосударственные IT компании в интересах государства. Но что-то каких подвижек в эту сторону не видно и по всей видимости будет реализовываться либо вариант 1, либо вариант 2, что мне не особо нравится… Но опять же, см. второй абзац этого поста. 🙂

На эту тему можно ещё посмотреть в контексте контейнеризации, но об этом как-нибудь в следующий раз.

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Прочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средствПрочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Кто-то может подумать из названия, что это наверное про CVSS. И будет отчасти прав. CVSS v3.0/3.1 это один из компонентов итоговой цифири. Причем не только Base Score. "Итоговый показатель I cvss определяется совокупностью показателей базовых, временных и контекстных метрик применительно к конкретной информационной системе". И все кроме базовых придется накликивать самим. Даже этого было бы достаточно для веселья. Но…

Есть ещё второй компонент "характеризующий влияние уязвимости … на функционирование информационной системы". 🙂 Там про тип уязвимого актива, массовость уязвимости, доступность через Интернет.

В зависимости от итогового значения выдвигаются требования по оперативности исправления. И там есть связь со вторым документом про тестирование обновлений:

"3.4. В случае если уязвимости содержатся в зарубежных программных, программно-аппаратных средствах или программном обеспечении с открытым исходным кодом, решение об установке обновления такого программного обеспечения, программно-аппаратного средства принимается оператором информационной системы с учетом результатов тестирования этого обновления, проведенного в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств, утвержденной ФСТЭК России от 28 октября 2022 г., и оценки ущерба от нарушения функционирования информационной системы по результатам установки обновления."

А уж какое там веселье. Ммм… 🙂 Но это как-нибудь в следующий раз.

Какие впечатления:
1. Методика это хорошо. Стандартизация от регулятора должна быть. Описано все просто и понятно.
2. Дополнительные критерии помимо CVSS это хорошо, критерии связанные с инфраструктурой выглядят в целом адекватно.
3. Не увидел учета такого важнейшего фактора как признак Exploitation in the wild. Когда я делаю приоритизацию с помощью своего проекта Vulristics наличие публичного эксплоита и признаков эксплуатации вживую играет наибольшую роль. Если наличие эксплоита ещё как-то учитывается (но кажется недостаточно) в CVSS Temporal Metrics, то эксплуатация вживую не отражена совсем. Кстати, давно уже пора делать наш аналог CISA Known Exploited Vulnerabilities Catalog.
4. Не увидел учет типа уязвимости. Когда я приоритизирую в Vulristics тип уязвимости также играет важную роль. Можно сказать, что тип уязвимости опосредованно учитывается в CVSS, но кажется этого также недостаточно.
5. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐

Благодаря ФСТЭКу будет что почитать в выходные непосредственно по нашей теме

Благодаря ФСТЭКу будет что почитать в выходные непосредственно по нашей теме. 🙂👍

1. Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
2. Методика тестирования обновлений безопасности программных, программно-аппаратных средств

В середине июля я принял участие в записи подкаста ЛК "Смени пароль!"

В середине июля я принял участие в записи подкаста ЛК Смени пароль!

В середине июля я принял участие в записи подкаста ЛК "Смени пароль!".

"Сколько проработает импортное «железо» без обновлений? Как выявлять вредоносные закладки в софте? Что нужней для создания безопасного кода – хакерские конкурсы или научное проектирование? Продолжаем обсуждать главные проблемы года с ИБ-экспертами из разных компаний. В этом выпуске свои истории рассказывают Алексей Лукацкий (Positive Technologies), Александр Леонов («Тинькофф»), Алексей Марков («Эшелон»), Николай Клендар (Home Credit Bank), Александр Бондаренко (R-Vision) и Пётр Девянин («Русбитех-Астра»)."

Я рассказывал про оценку стабильности вендоров, исправление уязвимостей в продуктах нестабильных вендоров и алгоритм НКЦКИ, про зачастую разный mindset у безопасников и админов. С 14:50. За 3 месяца тренд на вынос западных решений только усилился и есть надежда, что возврат к нормальному VM-процессу с доверием используемым вендорам совершится несколько раньше, чем можно было предполагать.

Что касается уязвимостей OpenSSL, которые многие так ждали 1 ноября

Что касается уязвимостей OpenSSL, которые многие так ждали 1 ноября. Обе уязвимости "переполнение буфера" (CVE-2022-3786, CVE-2022-3602).

Лучше всего процитировать блог Rapid7:

"Другими словами, возможности эксплуатации значительно ограничены:

- В случае, когда целью является сервер (веб-сервер, сервер базы данных, почтовый сервер и т.д.): сервер должен сначала запросить аутентификацию клиента как часть взаимной аутентификации. Такую конфигурацию распространенной не назовешь, но в особо критичных системах встречается.
- В случае, когда целью является клиент (веб-браузер, программа для чтения электронной почты, коннектор для базы данных и т.д.): злоумышленнику необходимо сначала заставить уязвимого клиента подключиться к вредоносному серверу. Можно выдать себя за другое лицо (MitM, захват существующего ресурса и т.д.) или убедить человека щелкнуть ссылку (через фишинг, "атаку на водопое" и т.д.).

В обоих сценариях такие атаки вряд ли будут широко использоваться злоумышленниками".

По поводу сегодняшнего инфоповода про Минцифры и три отечественные ОС

По поводу сегодняшнего инфоповода про Минцифры и три отечественные ОС.

Крамольную мысль скажу, но имхо, создание массового независимого российского Linux-дистрибутива вообще не должно быть коммерческой темой. Считаю, что государству нужно сейчас не поддерживать российские аналоги RedHat и Canonical через снижение конкуренции, а формировать российский The Debian Project.

Т.е. собрать группу разработчиков-энтузиастов, дать им денег из специального фонда (опционально замотивировать крупных российских ИТ-игроков туда донатить) и поставить им задачу поддерживать бесплатный базовый Linux дистриб не заботясь о какой-либо монетизации вообще. Пусть просто сидят и пилят на фулл-тайме то, что считают важным с точки зрения базовой функциональности и безопасности. А коммерсы пускай им контрибьютят то, что для них важно и (добровольно-принудительно) используют этот дистриб как апстрим. И вот поддержку такого базового бесплатного и свободного дистриба можно делать обязательной для разрабов прикладного ПО.

Это то, что пробуют сделать сейчас китайцы с openKylin. И такой путь через формирование и поддержку комьюнити мне кажется наиболее устойчивым и правильным.