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

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК. Что? 😳 ДА! 🎉Теперь можно ссылаться не на CIS, не на DISA STIGs, не на BSI IT-Grundschutz, а на технические требования нашего отечественного регулятора. Ну круть же! Скачать можно на сайте ФСТЭК.

1. Документ очень компактный, всего 7 страниц. CIS Benchmark для Ubuntu Linux 20.04 LTS, для сравнения, занимает 531 страницу.
2. Рекомендации подлежат реализации в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ).
3. Рекомендации распространяются на настройку НЕсертифицированных ОС (как раз Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Т.е. мейнстримные Linux дистрибутивы из КИИ и ГИС придется выносить, если они есть. Сертифицированные же Linux-ы должны настраиваться "в соответствии с эксплуатационной документацией разработчиков".
4. Рекомендации касаются именно настройки. Пример: "2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путём установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config." Как проверять не расписывается.
5. Сложность реализации настроек и проверок соответствия по пунктам из этих рекомендаций зависит от конкретности рекомендаций. Часть рекомендаций выглядят достаточно конкретными, часть нет, например "2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (, /usr/bin, , и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра)". Понятно, что конкретные настройки могут зависеть от конкретного дистрибутива, но все же хотелось бы большей однозначности, что нужно делать.
6. В некоторых пунктах приводится обоснование зачем это настройка нужна, например "в противном случае это может привести к выполнению произвольного кода от имени владельца задания cron". Но для большей части рекомендаций этого нет. А тоже хотелось бы.

Блоки рекомендаций:
1. Настройка авторизации в операционной системе.
2. Ограничение механизмов получения привилегий.
3. Настройка прав доступа к объектам файловой системы.
4. Настройка механизмов защиты ядра Linux.
5. Уменьшение периметра атаки ядра Linux.
6. Настройка средств защиты пользовательского пространства со стороны ядра Linux.

В целом, инициатива очень крутая, но к такому документу нужны ещё дополнительные конкретизирующие документы с настройками/проверками для конкретных ОС и обоснованиями почему каждая настройка важна и что может сделать злоумышленник в случае, если рекомендации по настройке не будут применены.

Результаты тестирования обновлений безопасности

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

Результаты тестирования обновлений безопасности уже доступны на сайте БДУ ФСТЭК. Вкладка Уязвимости -> Тестирование обновлений. Пишут, что "в настоящее время проводится опытная эксплуатация раздела". Это результаты работ по той самой госзакупке? Не знаю, но судя по таймингу тестирований вполне возможно.

1. Всего 112 обновлений протестировано.
2. Скачать весь фид целиком похоже пока нельзя. По кнопке "скачать" скачивается только текущая страница.
3. Первое тестирование от 28.08.2022, последнее тестирование от 24.12.2022.
4. Похоже, что обновления пока только Microsoft-овские.
5. Для обновления доступно его наименование, ссылка на описание, ссылка на файл-обновления, хеши, дата выпуска обновления, вендор, ПО, версии уязвимого ПО, версии тестируемого ПО, идентификаторы БДУ, идентификаторы CVE, вердикт.
6. Возможные значения для вердикта: "Влияние на инфраструктуру отсутствует", "Может оказать некритичное влияние на инфраструктуру", "Выявлено деструктивное воздействие на инфраструктуру".
7. Пока для всех тестов вердикт "Влияние на инфраструктуру отсутствует".

Теперь перед раскаткой обновления можно/нужно поглядывать на его вердикт в БДУ. Как это делать удобно и автоматизированно пока не особо понятно, но какой-то ручной процесс уже можно выстраивать. И это несоизмеримо проще, чем делать полноценное тестирование обновлений своими силами по методике. Ура!

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

Добавить комментарий

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Добавить комментарий

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍

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

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 под видом телеметрии и определить, что это активность зловредная надо будет постараться.

Александр В. Леонов

Управление Уязвимостями и прочее