Уровни доверия

На смену классификации по уровню контроля отсутствия недекларированных возможностей пришли уровни доверия. В чем различие между ними? Что такое классы безопасности и уровни доверия, откуда они взялись, в чем их особенности? Кто кому доверяет и почему не всё можно проверить? Этим вопросам посвящена наша статья.

Чтобы одобрить выдачу сертификата, недостаточно просто проверить выполнение функций безопасности в ПО. Нужно понять, насколько надежно эти функции выполняются, какова вероятность того, что эти функции будут выполняться всегда, в любом окружении, при любых событиях. Что эти функции нельзя отключить, обойти – случайно или намеренно. И тут мы сталкивается с тем, что одними испытаниями на соответствие профилю защиты или технических условий не обойтись. При этом строгая, исключающая несоответствие требованиям безопасности в любых ситуациях проверка для современного ПО просто невозможна: слишком оно сложное, а способы такой строгой проверки часто слишком теоретические, и их нельзя применить на практике. Ситуация усугубляется тем, что для ПО часто недоступны ни структура (блоки и связи между ними), ни исходный код. То есть такое ПО представляется для нас «черным ящиком»: мы может судить о нем только по его реакции на внешние воздействия: вводу данных, изменению конфигурации или программного окружения. В таких условиях надежно подтвердить работу функций безопасности в программных продуктах очень сложно. Ведь для полной надежности нужно, чтобы ПО правильно работало во всех возможных ситуациях, в то время как достаточно одного-единственного воспроизводимого сочетания параметров, в котором работа функций защиты нарушается, и всё: продукт уже уязвим.

И тут на помощь приходит идея доверия и процесс безопасной разработки ПО. Эти вещи впервые появились в тех же «Общих критериях». На их основании были приняты национальные стандарты ГОСТ, в том числе ГОСТ Р ИСО/МЭК 15408-3-2013. В нем используется понятие оценочного уровня доверия. Если коротко, то доверие устанавливает причинно-следственную связь между процессами безопасной разработки ПО и характеристиками его безопасности. В этом случае вместо самого ПО как конечного продукта проверяются среда и процессы. Чем строже требования к этим процессам, тем выше вероятность, что функции безопасности будут выполняться как надо. Подход с оценочным уровнем доверия из ГОСТ первым начал широко применять (и применяет до сих пор) Банк России. Именно он ввел обязательную проверку прикладного программного обеспечения по оценочным уровням доверия в информационной безопасности.

Раньше Гостехкомиссия (а потом и ФСТЭК) использовала принципы уровней доверия в своих требованиях по отсутствию недекларированных возможностей. И такая проверка стала частью сертификационных испытаний. Но за почти 20 лет подход ФСТЭК и методические документы на его основе уже устарели, принципы безопасной разработки эволюционировали, и нужно было опять синхронизировать их, привести в соответствие.

И в 2018 году появились требования доверия ФСТЭК, которые как раз и решили эту проблему. Они гораздо полнее соответствуют современным принципам безопасной разработки. И отдельную проверку на недекларированные возможности больше не делают: ее включили в подтверждение требований к уровням доверия как часть этих требований. Поэтому говорить о том, что проверку на недекларированные возможности «отправили на пенсию», нельзя. Правда, первый блин оказался комом: требования 131-го приказа на практике оказались трудновыполнимыми, и были оперативно приняты новые требования, зафиксированные в 76-м приказе. Именно он сейчас является главным документом, и именно на соответствие требованиям этого приказа сейчас сертифицируется любое ПО. Сейчас уровни доверия в информационной безопасности стали обязательной частью процесса сертификации, без них обойтись нельзя, а если продукт не был сертифицирован по уровням доверия, то его сертификат может прекратить действие в любой момент по решению ФСТЭК.

Посмотрим повнимательнее на 76-й приказ. Сам документ носит пометку «для служебного пользования», но выдержки из него опубликованы, и их достаточно, чтобы разобраться с составляющими доверия.

Всего уровней 6, но для информации ограниченного распространения используются три нижних уровня — 4, 5 и 6. В приказе перечислено соответствие уровней доверия классам/уровням/категориям для нескольких сценариев – государственных информационных систем, информационных систем персональных данных, значимых объектов критической информационной инфраструктуры, автоматизированных система управления производственными и технологическими процессами. Что же касается других сценариев, то уровни доверия задаются документами, которые содержат требования по защите данных к этим сценариям. Например, так задаются требования в финансовой сфере.

Похожим образом уровни доверия привязываются к классам средств защиты информации. То есть получается, что к уровням доверия для сертифицированного ПО мы приходим двумя путями: напрямую через 76-й приказ, и опосредованно через приказы с мерами защиты. Понятно, что тут возможны противоречия, разночтения, но пока их нет, и будем надеяться, что регуляторы их не допустят.

Сами требования доверия подразделяются на три группы, каждая из которых подразделяется на несколько подгрупп. Таким образом, у нас есть 16 отдельных требований.

Требования к разработке и производству средства заключаются в том, что для каждой области (уровня детализации) разработки должны быть предусмотрены определенные меры по безопасности. Именно этих вещей не хватало в старых требованиях по контролю отсутствия недекларированных возможностей. Например, должна быть разработана модель безопасности средства, и в этой модели должны быть политики управления доступом и фильтрации информационных потоков (если они требуются исходя из функционального назначения средства). Архитектура безопасности, помимо того, что она должна быть, должна быть такой, чтобы функции безопасности невозможно было обойти или получить к ним несанкционированный доступ. Функциональная спецификация – должна присутствовать и, помимо этого, должна включать в себя описания интерфейсов (как функций безопасности, так и других функций). На уровне проектирования появляются подсистемы. Вот тут интересно: они делятся на те, что влияют на функции безопасности, и те, что не влияют. На этом уровне можно изолировать подсистему безопасности от остальных подсистем средства, и таким образом раздельно обновлять их модули. Это влияет на удобство и оперативность обновления ПО.

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

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

Имеются в виду не сертификационные, а внутренние испытания. Помимо доказательств того, что такие испытания вообще проводились, положение предъявляет требования к этим тестам.

Во-первых, это тестирование, проверка результатов работы программы заранее известным, заданным значениям. Сравниваем то, что ожидали получить, с тем, что получили. У нас должен быть план тестирования (набор тестов с порядком их выполнения). Все функции безопасности должны быть покрыты тестами – как минимум на уровне интерфейсов, а начиная от 5-го уровня доверия — еще и на уровне подсистем (с оценкой влияния на них подсистем без функций безопасности), а с 4-го – с модулями программы.

Отдельная подгруппа требований – контроль уязвимостей и недекларированных возможностей. Именно эта группа требований посвящена анализу кода и поведения программных средств. Для этого в 76-м приказе вводятся новые уровни контроля, с 1-го по 6-й. Уровень контроля должен соответствовать уровню доверия, то есть для 6-го уровня доверия нужно проводить испытания по 6-му уровню контроля, и так далее. Напоминаем, что сам 76-й приказ, а также недавно принятая методика для контроля уязвимостей и недекларированных возможностей – она действует с 1 апреля 2021 года – документы для служебного пользования, доступны лицензиатам ФСТЭК. Это еще одна причина, почему у заявителя должна быть лицензия ФСТЭК – без нее просто не провести этот шаг испытаний. «Старые» уровни контроля недекларированных возможностей, введенные в действие приказом Гостехкомиссии России от 4 июня 1999 г. N 114, при сертификации больше не применяются.

Кроме тестирования и испытаний на уязвимости и недекларированные возможности, программное средства 4-го уровня доверия нужно проанализировать на отсутствие скрытых каналов через память системы.

Чтобы ПО оставалось безопасным не только в момент его изготовления, но и на всем протяжении его жизненного цикла, к нему предъявляется еще одна группа требований. Самое главное — поддержка должна быть. Если нет поддержки, то доверие к такому ПО автоматически прекращается, даже если к текущему моменту нет неустраненных уязвимостей.

Сама такая поддержка должна быть направлена как на сам продукт, его код, так и на пользователей. То есть пользователей нужно информировать о событиях, инструктировать о процедурах. Наконец, обеспечить доставку обновлений. За эту поддержку отвечает заявитель, который должен привлекать разработчика (если заявитель — не разработчик) и изготовителя (если заявитель сам не производит ПО).

Чтобы обеспечить эти требования, заявитель должен развернуть информационные каналы, собирать информацию о выявленных недостатках, собирать обратную связь от пользователей, тестировать средство на недостатки. Если эти недостатки выявлены и подтверждены, то разрабатывать компенсирующие меры, которые бы не позволили использовать (как говорят, эксплуатировать) эти недостатки. И, наконец, заявитель должен донести всю полученную и выработанную информацию до ФСТЭК и пользователей продукта. Кроме того, заявитель должен доработать средство, протестировать его и передать доработанное средство пользователям. Для 5-го и 4-го уровней доверия еще и заданы максимальные сроки реагирования (выработки и доведения компенсирующих мер и ограниченный до пользователей) и доработки.

Процедуры устранения недостатков заявителем должны быть документированы, а пользователи должны быть оповещены о снятии продукта с производства или поддержи не менее чем за год.

Разбираемся в сертификации ПО
Сертификационные испытания ПО
Требования по безопасности информации