допустимость стороннего ПО

MVV

New member
Сообщения
5
#1
Кто может дать авторитетную оценку выполнения требований условий применения изделия для стороннего ПО?
Под сторонним ПО я понимаю ПО, не входящее в установочный диск и обновления. Например, Р7-Офис.
Если конкретизировать вопрос - не нарушит ли сертификат Астры Линукс 1.6 установка Р7-Офис?
 

MVV

New member
Сообщения
5
#3
Я специально сформулировал вопрос таким образом, что в нём идёт речь не об аттестации, а о нарушении требований сертифицированного продукта. Безусловно, конечная цель - аттестация ИС. Однако, с моей точки зрения, в данном вопросе наиболее авторитетно мнение разработчика. Орган по сертификации с разработчиком определили требования к сертифицированному продукту. Далее, в вопросе эксплуатации только разработчик отслеживает использование продукта. Орган по аттестации контролирует соответствие более широкому кругу требований и менее компетентен.
 

oko

New member
Сообщения
1 257
#4
to MVV
Требования какого регулятора? И в каких АС/ИС предполагается использование? От этого зависит очень многое...
Приведенная вами ссылка относится к ограничениям, изложенным в формуляре Astra Linux, сертифицированной по линии ФСБ России. При использовании Astra Linux с сертификатом ФСТЭК России или МО России ограничения и формулировки будут иными. Как минимум понятие "тематические исследования" в контексте приведенного документа имеется только у ФСБ России...
Орган по аттестации (лицензиат, если объект КОНФИ) выносит итоговое решение относительно допустимости того или иного изменения. Так что я бы не стал принижать его компетенцию (безотносительно конкретных лицензиатов, ага)...
В случае Р7-Офис проще всего действовать по следующему принципу:
  • нарушает ли установка Р7-Офис контрольные суммы дистрибутива Astra Linux (ядро, модули ядра, основные исполняемые файлы и библиотеки, файлы КСЗ), приведенные в формуляре?
  • использует ли Р7-Офис макросы и интерпретаторы, способные влиять на защищенность ОС в целом, и не перекрытые используемой КСЗ?
  • противоречат ли механизмы Р7-Офис и их эксплуатация базовым правилам Astra Linux Red Book?
Сертификация как СЗИ - это подтверждение того, что конкретный продукт позволяет реализовать требуемые меры защиты информации + если идет речь об НДВ (ОУД), не содержит в себе недекларированного функционала и ошибок, влияющих на качественные характеристики механизмов защиты информации...
А вообще, наиболее полную оценку может дать только отдел РусБИТех, разрабатывавший Задание по безопасности, и сертификационная лаборатория...

ЗЫ Так-то, если смотреть на приведенный документ "в лоб", то для эксплуатации Р7-Офис под Astra Linux SE 1.6 ему необходимо провести тематику (оценку влияния). Что очень похоже на сертификацию, но несколько проще, быстрее и дешевле, ага...
 

MVV

New member
Сообщения
5
#5
to OKO
Действительно, с регулятором я промахнулся. На странице
Использование стороннего программного обеспечения в аттестованных информационных системах, функционирующих под управлением ОС Astra Linux размещены условия использования стороннего ПО. Я посчитал, что приведённая внизу ссылка более полно описывает условия использования стороннего ПО. Сейчас вижу, что ошибся и условий применения изделия относится с сертификатам ФСБ.
Меня интересует возможность применения стороннего ПО без нарушения сертификата ФСТЭК.
На сайте Astra Linux https://astralinux.ru/ready-for-astra/ready-for-astra-products/ready-for-astra-software/ публикуется совместимое с операционной системой ПО. Публикация списка стороннего ПО, допустимого к установке в Astra Linux Special Edition, вместе с рекомендуемыми настройками сняла бы все вопросы.
 

oko

New member
Сообщения
1 257
#6
to MVV
Так ведь в "Руководство по КСЗ. Часть 1" РУСБ.10015-01 97 01-1 (п. 17.2 и п. 17.3) по линии ФСТЭК России расписаны условия. В общем случае нужно оценить влияние устаналиваемого ПО на перечисленные требования (в целом, в прошлом сообщении вам общую методику расписал). Вопрос возникает только в части механизма ЗПС, потому что стороннее ПО обычно не подписано ключом РусБИТех...
В части публикации совместимого ПО согласен. Но, сдается мне, что подобная публикация очень скоро превратилась бы в "Реестр отечественного ПО" в части творящегося там балагана, ага...
Как говорится, будем посмотреть. Авось коллектив РусБИТех совместно со ФСТЭК России со временем наведут порядок (читай, приведут явную методику) в этом вопросе...
 

MVV

New member
Сообщения
5
#7
to OKO
Оценка выполнения требований пп. 17.2 и 17.3 "Руководство по КСЗ. Часть 1" РУСБ.10015-01 97 01-1" мне не кажется тривиальной. Поэтому вопрос и возник. Если для Вас не составляет труда выполнить такую оценку, предлагаю это сделать на примере какого-либо ПО и выложить результаты на форум.
 

oko

New member
Сообщения
1 257
#8
to MVV
Primo, не утверждал, что подобная оценка является тривиальной задачей. Скорее радовался, что в Руководстве КСЗ вообще сказано хоть что-то, позволяющее провести оценку "своими силами" без обязательства тематических исследований или сертификационных испытаний...
Secundo, замечу, что ваш первичный вопрос не касался Руководства КСЗ - мы с вами на него в процессе обсуждения вышли...
Tertio, вы не привели конкретные характеристики обрабатываемой информации ограниченного доступа (ИОД). Замечу, что Руководство КСЗ рассматривает вопросы "доверенной среды" в контексте автоматизированных систем, предназначенных для обработки ИОД, содержащей сведения, составляющие государственную тайну. Для КОНФИ-систем, imho, большая часть положений Руководства КСЗ может не выполняться посредством соответствующего обоснования (на основании той же Модели угроз и нарушителей). И это ни коим образом не будет нарушать параметров сертификации Astra Linux. Кроме, пожалуй, случая упертого представителя регулятора, но об этом, по понятным причинам, не будем...
Last, могу привести условный пример оценки "в лоб" согласно Руководству КСЗ. Исключительно на правах imho и исключительно для простейшего варианта (см. исходные данные в спойлере). Потому что для разбора иных вариантов нужны официальный запрос к лицензиату и оплата работы экспертов требуется куда больше времени, чем есть у уставшего безопасника, периодически сидящего на этом форуме, ага...

Исходные данные
  1. ПО XXX распространяется по лицензии GNU/GPL. Его применение в организации YYY и автоматизированной системе ZZZ не противоречит приведенной лицензии.
  2. ПО XXX входит в список программного обеспечения, официально поддерживаемого ОС Astra Linux Special Edition 1.6. Исполняемые файлы и библиотеки ПО XXX подписаны ключом ЭЦП, выданным АО "НПО РусБИТех".
  3. Программное обеспечение ХХХ предназначено для выполнения следующих задач: перечень задач
  4. Средствами ПО XXX не предусмотрена обработка ИОД. Основное назначение ПО XXX - выполнение утилитарных и технологических операций для повышения удобства эксплуатации АС ZZZ.
  5. ПО XXX поставляется в виде DEB-пакета(ов), не требует компилляции из исходных текстов и, соответственно, не требует инсталляции и запуска средств компилляции и сборки программного обеспечения в АС ZZZ.
  6. Инсталляция ПО XXX в среде ОС ALSE 1.6 не требует подключения сторонних репозиториев (за исключением репозиториев ALSE 1.6, размещенных на DVD-дисках комплекта поставки ОС) и не требует замены или обновления существующих исполняемых файлов и библиотек в составе ОС ALSE 1.6 из сторонних репозиториев или источников.
  7. Источником получения установочных пакетов ПО XXX является web-ресурс организации-производителя (разработчика) ПО XXX в сети "Интернет" - адрес ресурса, с учетом исполняемых файлов, подписанных ключом ЭЦП АО "НПО РусБИТех".

Оценка согласно РУСБ.10015-01 97 01-1, п. 17.3 "Условия применения ПО"
  1. ПО XXX не предназначено для эксплуатации с правами суперпользователя root или в режиме кратковременного повышения привилегий пользователя-эксплуатанта ПО XXX средствами sudo.
  2. ПО XXX не использует в своем коде или в процессе своей эксплуатации вызовы к сторонним интерпретаторам и трансляторам за исключением интерпретатора BASH (SH).
  3. ПО XXX не предназначено и не использует ресурсы защищенной СУБД PostgreSQL, установленной в среде ОС ALSE 1.6 в составе АС ZZZ.
  4. ПО XXX использует сетевую подсистему установленной в АС ZZZ копии ОС ALSE 1.6. При этом ПО XXX не предназначено для запуска и эксплуатации на мандатных уровнях выше "0" (минимальный мандатный уровень) и использования привилегированных операций со стеком протоколов TCP/IP в составе ОС ALSE 1.6.
  5. В составе ПО XXX отсутствуют и ПО XXX не использует в своей работе программные компоненты брокера сообщений RabbitMQ.
  6. ПО XXX не используется в своей работе программные компоненты или интерфейсы связи (передачи данных) с защищенным web-сервером Apache2, установленным в среде ОС ALSE 1.6 в составе АС ZZZ.
  7. ПО XXX не используется в своей работе программные компоненты, разработанные на языке функционального программирования Erlang.
  8. При эксплуатации ПО XXX в ОС ALSE 1.6 в составе АС ZZZ следующий функционал не может быть реализован средствами ПО XXX по причине отсутствия у ПО XXX необходимых функциональных методов и общесистемных привилегий:

  • отсутствует функционал и привилегии для подмены ядра ОС ALSE 1.6, размещенного в каталоге /boot или иных каталогах размещения;
  • отсутствует функционал и привилегии для изменения таблицы системных вызовов или полей структур типа *securiry* подсистемы безопасности PARSEC в составе ОС ALSE 1.6;
  • отсутствует функционал и привилегии для внесения изменений в конфигурации загрузчика GRUB в составе ОС ALSE 1.6;
  • отсутствует функционал и привилегии для подмены (не переопределения) корневого системного процесса Init;
  • отсутствует функционал и привилегии для изменения параметров PAM-сценариев, конфигурационные файлы которых размещены в /etc/pam.d;
  • отсутствует функционал и привилегии для установки (изменения) PAM-модулей, позволяющих взаимодействовать с API библиотеки libparsec-mac подсистемы безопасности PARSEC в составе ОС ALSE 1.6;
  • отсутствует функционал и привилегии для установки (изменения) PAM-модулей, позволяющих взаимодействовать с API библиотеки libparsec-cap подсистемы безопасности PARSEC в составе ОС ALSE 1.6;
  • отсутствует функционал и привилегии для вывода информации в "твердую копию" (печать) в обход защищенного сервиса печати CUPS в составе ОС ALSE 1.6;
  • отсутствует функционал и привилегии для замены интерпретаторов bash, dash, PHP, Perl, Python и TCL, а также установки иных командных интерпретаторов в ОС ALSE 1.6;
  • отсутствует функционал и привилегии для получения доступа к памяти других процессов иного используемого ПО с использованием вызовов CAP_SYS_PTRACE и системного вызова ptrace;
  • отсутствует функционал и привилегии для изменения системного времени и даты;
  • отсутствуют привилегии для динамического изменения кода ядра или неэкспортируемых символов ядра ОС ALSE 1.6;
  • отсутствуют привилегии для доступа к файлу ctl файловой системы parsecfs в обход системных функций библиотек libparsec-*.
9. Механизмы подсистемы защиты информации в ОС ALSE 1.6 в составе АС ZZZ настроены в соответствии с правилами РУСБ.10015-01 97 01-1, п. 17.2 и Astra Linux Red Book, включая механизм замкнутой программной среды.

Выводы
Согласно представленным исходным данным и анализу проведенной оценки влияния ПО XXX на ОС ALSE 1.6 в составе АС ZZZ организации YYY допустимо утверждать, что при установке ПО XXX:
  • защищенность ОС ALSE 1.6, применяемой в АС ZZZ, и АС ZZZ в целом не снижается;
  • положения применения ОС ALSE 1.6 в АС, предназначенных для обработки ИОД, в целом выполняются.

ЗЫ Убедительная просьба ко всем, кто будет читать приведенный в спойлере текст:
  1. Не говорить, что это все лирика, а интересовал детальный анализ каждого пункта (например, как оценить, что в ПО XXX отсутствует тот или иной функционал или привилегии). Как уже сказал выше, детальный анализ явно выходит за границы общения на форуме...
  2. Не говорить, что такая оценка влияния - это ближе к аттестации, а не сертификации. Потому что суть в обеспечении защищенности оконечной среды эксплуатации, а не подтверждении выполнения каких-то бумаг, которых кроме разработчика и сертификационной лаборатории никто не видел и, вероятно, не увидят...
  3. Не принимать приведенный "Условный акт" в качестве modus operandi и уж тем более не копировать его безотносительно переложения на реалии собственных АС. Повторюсь, все здесь сказанное приведено больше для примера подхода и на правах imho...
 

MVV

New member
Сообщения
5
#9
to OKO
Благодарю за аргументированные ответы.
Предлагаю ограничиться рассмотрением обработки конфиденциальной информации. Ваше мнение о избыточности требований КСЗ для конфи-систем можете шире раскрыть?
 

oko

New member
Сообщения
1 257
#10
to MVV
Комплексный ответ будет долгим, а мне, честно признаться, вломм (по приведенной ранее причине)...
Но если коротко, то в КОНФИ все решает Модель угроз и нарушителей и специфика выбора мер защиты относительно функциональности и экономичности оконечной защищаемой системы...
Можно защищаться периметрально, не рассматривая влияние нарушителя на процессы, исполняемые на уровне ОС. Особенно, если это не сервер в ДМЗ. Тогда снимаются вопросы наличия/доступности интерпретаторов, Erlang и ptrace автоматически снимаются...
Можно защищаться точечно, прикрутив поверх систему протоколирования действий пользователей и процессов на уровне ОС или иные меры. Тогда вопросы PAM, root-права и проч. тоже можно нивелировать...
Можно (зачастую так и делается) вообще отказаться от МКЦ, что сразу снимает вопросы привилегий parsec, управление libparsec и mac/pdp/cap...
В ГТ же напротив, нарушитель = космическому уроду, на пару поколений превосходящему возможности эксплуатанта. Поэтому существуют жесткие и безкомпромиссные регламенты и правила. И только замкнутый техпроцесс с учетом всего и вся спасет отца русской безопасности, ага...