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

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

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

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

Какие вводятся проверки:

1. Сверка идентичности обновлений безопасности (Т001). Пользователям с русскими IP могут прилетать зловредные обновления, а другим пользователям нет. Поэтому качаем разными способами, сверяем контрольные суммы.

2. Проверка подлинности обновлений безопасности (T002). Контрольные суммы того, что скачали должны быть равны контрольным суммам, которые сообщает вендор (если он их сообщает).

3. Антивирусный контроль обновлений безопасности (Т003). Скормили двум и более антивирусам (от разных антивирусных вендоров) файлы с обновлением и натравили на сам хост после обновления, смотрим что продетектится.

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

5. Мониторинг активности обновлений безопасности в среде тестирования (Т005). Ставим обновления и ищем НДВ, о которых первой части было. Интересно, что добавили необходимость проведения "г) сигнатурного поиска известных уязвимостей." Похоже про то, что вендор-злодей может добавить известную уязвимость в продукт, чтобы это меньше было похоже на бекдор.

6. Ручной анализ обновлений безопасности (Т006). Это самое хардкорное. Выполняется, когда предыдущие проверки выявили что-то подзрительное. Если НЕ можем такой анализ провести, то просто говорим, что есть НДВ. Если можем, то проводим… Ох, дам цитатой 😱:
"а) анализ логики работы (в том числе дизассемблирование или декомпиляция бинарного кода при наличии соответствующих возможностей);
б) исследование компонентов обновления безопасности с помощью отладчиков и трассировщиков;
в) проверки наличия в обновлении безопасности ключевой информации (паролей, секретных ключей и другой чувствительной информации);
г) статического и динамического анализа (при наличии исходных кодов обновлений безопасности)."

Если в ходе ручного анализа (Т006) что-то нашлось, нужно написать во ФСТЭК и НКЦКИ. И всеми результатами тестирования рекомендуется делиться со ФСТЭК, а ФСТЭК их будет выкладывать в БДУ.

Набор проверок для проприетарного и опенсурсного софта отличается. Для проприетарного в целом логичный набор: Т001 и/или Т002; Т003 и/или Т004; Т005. Для опенсурсного почему-то вообще не требуется проводить сверку идентичности обновлений безопасности (Т001) и поиск опасных конструкций безопасности (Т004), зато видимо обязательно проводить ручной анализ обновлений безопасности (Т006). Логика за этим кроется какая-то хитрая, я её не понял. Как это сочетается с тем, что в описании Т006 пишут, что его проводим только если предыдущие что-то продетектили, тоже не понял.

Если попробовать резюмировать впечатления от документа, то всё это выглядит страшновато (особенно Т005 и Т006). Особенно с учетом громадных объемов обновлений Microsoft и ещё больших объемов для мейнстримных Linux дистрибутивов. А ведь там ещё тучи third-party софта. 🤯 На текущий момент сложно представить, что все эти работы будут скрупулезно проводиться внутри организаций так как это описано. Трудоемкость чудовищна. Будем посмотреть во что это реально выльется. Хочется надеяться, что все же в готовые фиды.

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

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

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