Архив рубрики: Регуляторика

Начнем про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК

4 комментария

Начнем про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК. Часть 1. Признаки добавления НДВ.

В методике есть перечень признаков того, что вендор принес зловредную функциональность вместе с обновлениями. 6 пунктов, в целом весьма неплохие.

"2.3. Для целей настоящей Методики к признакам недекларированных ​возможностей обновлений безопасности относятся:
​а) попытки обращений к файловой системе, базам данных, электронной ​почте и другой информации, не имеющие отношения к функционалу обновляемых ​программных, программно-аппаратных средств;
​б) недокументированные обращения к сторонним (неизвестным оператору) сетевым адресам и доменным именам, не относящимся к оператору ​информационной системы;
​в) системные вызовы, характерные для вредоносного программного обеспечения (например, попытки загрузки из сети «Интернет» библиотек и программных пакетов, не имеющих отношения к функционалу программного ​обеспечения, попытки перехвата сетевого трафика другого программного ​обеспечения, попытки мониторинга действий пользователей с другим ​программным обеспечением);
​г) потенциально опасные изменения в файловой системе в результате ​установки обновления, в том числе загрузка и установка недокументированных ​программного обеспечения, драйверов и библиотек, не имеющих отношения к ​функционалу обновляемого программного, программно-аппаратного средства;
​д) изменения конфигурации среды функционирования, не имеющие ​отношения к обновляемому программному, программно-аппаратному средству ​(например, появление новых автоматически загружаемых программ);
​е) отключение средств защиты информации и функций безопасности ​информации."

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

Про 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, что мне не особо нравится… Но опять же, см. второй абзац этого поста. 🙂

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

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

7 комментариев

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

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

Кто-то может подумать из названия, что это наверное про 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. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐

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

4 комментария

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

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

И снова про нестабильных зарубежных IT/ИБ вендоров и обновления, которые могут содержать закладки

4 комментария

И снова про нестабильных зарубежных IT/ИБ вендоров и обновления, которые могут содержать закладки.

Очень интересный конкурс на госзакупках от ФСТЭК. "Информационная инфраструктура, обеспечивающая проведение тестирования обновлений безопасности программного обеспечения, страной происхождения которого являются недружественные государства, и программного обеспечения с открытым кодом (далее — зарубежные разработчики), а также предоставление доступа государственным органам (организациям) и субъектам критической информационной инфраструктуры (далее — органы (организации)) к результатам тестирования."

Полистал ТЗ. Вроде круто и как раз в том направлении, как и хотелось. Тесты патчей от регулятора. 👍

1. Если все будет удачно, то к концу года у ФСТЭК будут первые результаты тестирования обновлений для наиболее популярных софтов, который в гос-ах используются (перечень тоже в рамках задачи нужно будет определить). А процесс будет постепенно совершенствоваться ещё 3 года.
2. Интересно, что будет разработана не только "методика проведения работ по тестированию обновлений программного обеспечения" (что логично), а также будет "разработана методология определения критичности уязвимостей программного обеспечения, для устранения которых требуется установка обновлений безопасности и проведения работ по их тестированию". 🧐Насколько я понял это затем нужно, что тестировать будут не все патчи, а только для критичных уязвимостей и только их будут рекомендовать к установке. Возможно будет что-то напоминающее рекомендательный алгоритм НКЦКИ, но это не точно.
3. Прикольно, что ещё сделают руководство по Patch Management-у для организаций. Требуют "разработку руководства по управлению обновлениями программного обеспечения в органе (организациями), в том числе включающего дифференциацию обновлений, описание процессов получения обновлений, тестирования обновлений, установку обновлений, оценку и совершенствование процесса управления обновлениями." Давно топлю за то, чтобы было больше детальных руководств по Patch & Vulnerability Management, а тут ещё и от регулятора. 🔥

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

Второй скриптик это реализация рекомендательного алгоритма НКЦКИ

5 комментариев

Второй скриптик это реализация рекомендательного алгоритма НКЦКИВторой скриптик это реализация рекомендательного алгоритма НКЦКИВторой скриптик это реализация рекомендательного алгоритма НКЦКИ

Второй скриптик это реализация рекомендательного алгоритма НКЦКИ. Сразу наглядно видно какие параметры нужны для принятия решение. Подаешь заполненный дикт на вход, получаешь вердикт стоит обновлять или не стоит, нужно ли повторять проверку через какое-то время или нет, а также шаг алгоритма на котором было принято итоговое решение (для отладки). Можно менять параметры и смотреть как результат меняется. На слайдах я меняю CVSS Base Score c 9 на 6, патчить все ещё надо, т.к. отказ сервиса влияет на бизнес, а СЗИ-шек для митигации не внедрено. Меняю параметр, что у нас есть СЗИ блокирующие эксплуатацию уязвимости и получаю ответ, что патчить не требуется.

Это в первую очередь мне нужно для демонстрации того какие теперь требуются дополнительные входные данные для VM процесса. Но в принципе можно и в реальных системах использовать.