Архив метки: ФСТЭК

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

1 комментарий

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

Похоже исследователь может выбирать на чём тестировать обновления. Хоть на проде! 🙂

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

Требования к инструментами для тестирования есть, но довольно общие и странновато сформулированные:

"При проведении тестирования обновлений безопасности в соответствии с настоящей Методикой должны применяться инструментальные средства анализа и контроля, функциональные возможности которых обеспечивают реализацию положений настоящей Методики,

имеющие техническую поддержку и возможность адаптации (доработки) под особенности проводимых тестирований,

свободно распространяемые в исходных кодах

или

средства тестирования собственной разработки."

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

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

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, а тут ещё и от регулятора. 🔥

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