Контроль недекларированных возможностей

Максим Репин
Специалист ОАО "Концерн "БЕГА"

Анастасия Сакулина
Специалист ОАО "Концерн "БЕГА"

В наше время в связи с увеличением случаев утечек конфиденциальной информации (КИ) основным становится вопрос о ее надежной защите.

В отличие от государственной тайны и персональных данных, документы регуляторов в области защиты КИ носят рекомендательный характер, поэтому возникает естественный вопрос: следовать им или нет?

Рассмотрим необходимость и целесообразность сертификации средств защиты КИ по уровням контроля отсутствия недекларированных возможностей (НДВ).

Уровни контроля отсутствия НДВ

Существуют четыре уровня контроля отсутствия НДВ. Для защиты КИ обычно используют 4-й уровень, но также можно использовать и 3-й уровень, включающий более тщательный анализ отсутствия НДВ.

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

Мы часто слышим следующие аргументы в пользу сертификации:

• сертифицированное ПО корректно выполняет свои функции защиты информации;
• сертифицированное ПО гарантирует отсутствие встроенных механизмов, которые могут нанести вред информации заказчика.

На практике наличие сертификата у ПО не всегда обеспечивает выполнение этих утверждений.

Если взять те продукты, предлагаемые на отечественном рынке, которые имеют сертификат, то и они нередко представляют собой довольно плачевное зрелище, так как обычно обладают полным набором программных ошибок и не обеспечивают ни удобства в эксплуатации, ни гибкости настроек.

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

На рынке свободного ПО эти функции выполняют энтузиасты. Они часто имеют очень глубокие знания в этой области, и их численность много больше, чем сотрудников любой лаборатории. Это позволяет досконально перебрать весь код и исправить все тонкие места.

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

Еще одной проблемой является то, что обновление ПО и установка исправлений являются нарушениями условий действия выданного сертификата и требуют повторной процедуры проверки. Похожая ситуация возникает, если срок действия сертификата истек. При наличии нового руководящего документа по контролю отсутствия НДВ установленная процедура подтверждения и продления действия сертификата, которая основана на анализе соответствия сертифицированных свойств вновь предоставляемого продукта со свойствами старой сертифицированной версии, уже не работает.

Парадокс проблемы наличия в продукте программных закладок (ПЗ)

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

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

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

На данный момент для построения действительно надежной системы защиты лучше вложить деньги в грамотных и проверенных системных администраторов и консультантов. Их знания и опыт помогут выбрать наиболее надежные и подходящие именно для конкретной фирмы решения.

Статьи по теме

В требованиях по безопасности информации при проектировании информационных систем указываются признаки, характеризующие применяемые средства защиты информации. Они определены различными актами регуляторов в области обеспечения информационной безопасности, в частности - ФСТЭК и ФСБ России. Какие классы защищенности бывают, типы и виды средств защиты, а также где об этом узнать подробнее, отражено в статье.

Введение

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

О серьезности ситуации сообщает ФСБ России: сумма ущерба, нанесенная злоумышленниками за несколько лет по всему миру составила от $300 млрд до $1 трлн. По сведениям, представленным Генеральным прокурором РФ, только за первое полугодие 2017 г. в России количество преступлений в сфере высоких технологий увеличилось в шесть раз, общая сумма ущерба превысила $ 18 млн. Рост целевых атак в промышленном секторе в 2017 г. отмечен по всему миру. В частности, в России прирост числа атак по отношению к 2016 г. составил 22 %.

Информационные технологии стали применяться в качестве оружия в военно-политических, террористических целях, для вмешательства во внутренние дела суверенных государств, а также для совершения иных преступлений. Российская Федерация выступает за создание системы международной информационной безопасности.

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

Средства защиты информации, или СЗИ обеспечивают защиту информации в информационных системах, по сути представляющих собой совокупность хранимой в базах данных информации, информационных технологий, обеспечивающих ее обработку, и технических средств.

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

Как защитить информацию в таких условиях? Соответствующие требования предъявляют уполномоченные органы, в частности, ФСТЭК и ФСБ России. В рамках статьи постараемся отразить основные подходы к классификации СЗИ с учетом требований указанных регуляторов. Иные способы описания классификации СЗИ, отраженные в нормативных документах российских ведомств, а также зарубежных организаций и агентств, выходят за рамки настоящей статьи и далее не рассматриваются.

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

Структурой, определяющей порядок и координирующей действия обеспечения некриптографическими методами ИБ, является ФСТЭК России (ранее - Государственная техническая комиссия при Президенте Российской Федерации, Гостехкомиссия).

Если читателю приходилось видеть Государственный реестр сертифицированных средств защиты информации , который формирует ФСТЭК России, то он безусловно обращал внимание на наличие в описательной части предназначения СЗИ таких фраз, как «класс РД СВТ», «уровень отсутствия НДВ» и пр. (рисунок 1).

Рисунок 1. Фрагмент реестра сертифицированных СЗИ

Классификация криптографических средств защиты информации

ФСБ России определены классы криптографических СЗИ: КС1, КС2, КС3, КВ и КА.

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

Если криптографическое СЗИ может противостоять атакам, блокируемым средствами класса КС1, а также проводимым в пределах контролируемой зоны, то такое СЗИ соответствует классу КС2. При этом допускается, например, что при подготовке атаки могла стать доступной информация о физических мерах защиты информационных систем, обеспечении контролируемой зоны и пр.

В случае возможности противостоять атакам при наличии физического доступа к средствам вычислительной техники с установленными криптографическими СЗИ говорят о соответствии таких средств классу КС3.

Если криптографическое СЗИ противостоит атакам, при создании которых участвовали специалисты в области разработки и анализа указанных средств, в том числе научно-исследовательские центры, была возможность проведения лабораторных исследований средств защиты, то речь идет о соответствии классу КВ.

Если к разработке способов атак привлекались специалисты в области использования НДВ системного программного обеспечения, была доступна соответствующая конструкторская документация и был доступ к любым аппаратным компонентам криптографических СЗИ, то защиту от таких атак могут обеспечивать средства класса КА.

Классификация средств защиты электронной подписи

Средства электронной подписи в зависимости от способностей противостоять атакам принято сопоставлять со следующими классами: КС1, КС2, КС3, КВ1, КВ2 и КА1. Эта классификация аналогична рассмотренной выше в отношении криптографических СЗИ.

Выводы

В статье были рассмотрены некоторые способы классификации СЗИ в России, основу которых составляет нормативная база регуляторов в области защиты информации. Рассмотренные варианты классификации не являются исчерпывающими. Тем не менее надеемся, что представленная сводная информация позволит быстрее ориентироваться начинающему специалисту в области обеспечения ИБ.

И,кстати, "лицензии на НДВ" не существует.

Я не докапываюсь, просто хочу разобраться.

Заявитель может быть одним из разработчиков, если разработка совместна.

Заявитель просто — тогда зачем ему это делать

Если для дальнейшего производства — то лицензия нужна.

Если нет — то необходим комплект документов для сертификации, договор с разработчиком об использовании разработки ил иное основание. В данном случае зачем ему сертификат если невозможно производить с последующей продажей.

> разработчиком об использовании разработки ил иное основание. В данном случае

> зачем ему сертификат если невозможно производить с последующей продажей.

Как пройти сертификацию фстэк

Получение заветного сертификата

О сертификации некриптографических информационно-телекоммуникационных систем по требованиям ФСБ

И.Г. Шапошников, директор ООО «Центр сертификационных исследований», к.ф.-м.н.

В.А. Мыльцев, заместитель директора по лицензированию и сертификации ООО «Центр сертификационных исследований»

ОДНИМ из направлений деятельности ФСБ (ранее — ФАПСИ) является сертификация средств криптографической защиты информации. Сами сертификационные исследования проводятся в аккредитованных лабораториях и центрах. При этом подтверждается соответствие продукции требованиям безопасности информации. ООО «Центр сертификационных исследований» (ЦСИ) создавалось как организация, занимающаяся сертификацией шифротехники. Поэтому с первыми полученными лицензиями центр приобрел статус испытательной лаборатории по сертификации шифротехники в соответствии с требованиям безопасности связи, установленными ФАПСИ. Сертификация шифротехники — область деятельности, в которой необходимо наличие у заказчика сертификации четкого понимания порядка ее проведения. Последние, как правило, осведомлены о том, какие действия им необходимо предпринять, чтобы успешно пройти процедуру сертификации, какие материалы представить. Указанный порядок законодательно зафиксирован в ряде нормативных документов (например, ПКЗ-2005).

В соответствии с новыми требованиями

В последнее время область сертифицируемых изделий по требованиям информационной безопасности ФСБ значительно расширилась. Сейчас сертифицируется не только телекоммуникационное оборудование, включающее криптографические средства защиты, но и не имеющее таковых.

В настоящее время кроме шифротехники в ФСБ сертифицируются:

• цифровые АТС;
• межсетевые экраны;
• оборудование плезиохронной цифровой иерархии;
• программное обеспечение, используемое в автоматизированных системах ИТКС специального назначения;
• антивирусные средства.

При осуществлении сертификационных исследований используются нормативные документы (требования, методики) ФСБ. В настоящее время такие документы существуют для всех видов вышеперечисленного телекоммуникационного оборудования, не содержащего средств криптографической защиты информации. ЦСИ стал первопроходцем в проведении сертификационных исследований в соответствии по этим новым требованиям, принимал участие в создании регулирующих методических документов и работает в строгом соответствии с ними.

Цель предлагаемой вашему вниманию статьи — дать некоторое представление о существующих трудностях в проведении сертификации оборудования, не содержащего шифротехники. Необходимо также остановиться на тех требованиях, которые предъявляются к создателям данной техники.

В последние годы появилось много новых негосударственных фирм-разработчиков, как правило, незнакомых с этой процедурой. Играет свою отрицательную роль дефицит широко распространенных (например, как ПКЗ-99 и ПКЗ-2005) государственных документов, регламентирующих разработку и проведение аттестации по требованиям безопасности. В их отсутствие порядок проведения определяется существующей практикой. Ниже мы попытаемся отразить наиболее важные моменты процедуры, исходя из опыта работы ЦСИ.

От заявки — до сертификата

Итак, проведение сертификации включает в себя следующие необходимые этапы:

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

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

Перечень представляемой документации по сертифицируемой аппаратуре

1. Подробная схема архитектуры сертифицируемого объекта, в которой должны быть представлены все функциональные блоки и связи между ними.

2. Описание работы всего изделия.

3. Для каждой платы (субблока) должно быть представлено:

• техническое описание;
• инструкция по настройке;
• инструкция по эксплуатации;
• схема электрическая принципиальная;
• перечень элементов;
• функциональная схема.

4. Подробное описание ПО, которое должно содержать:

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

Эталоны не изменяются

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

Разработчики телекоммуникационной техники регулярно изменяют ПО аппаратуры с целью исправления ошибок, расширения выполняемых функций или для отслеживания трансформирующейся аппаратной части (например, элементной базы), то есть происходит непрерывная модернизация аппаратуры. Однако распространение действия сертификата на оборудование с какими-либо преобразованиями требует дополнительных исследований. Здесь-то, как правило, и возникает непонимание между разработчиком и сертифицирующей организацией. Сначала первый подает документацию, разные части которой относятся к разным этапам «развития» аппаратуры, а после проведения сертификации считает возможным внести незначительные, с его точки зрения, изменения, что не отвечает высоким требованиям, предъявляемым к сертифицированному оборудованию.

Столь жесткие критерии обеспечения информационной защиты в телекоммуникационном оборудовании по требованиям ФСБ обусловлены областью его использования. Сертификат ФСБ предоставляет возможность эксплуатировать оборудование в высших органах власти. Поэтому разработчику аппаратуры, прежде чем начинать сертификацию, следует подумать о ее необходимости. Не исключено, что достаточно будет получить сертификат ФСТЭК, который позволяет использовать аппаратуру в государственных структурах. Если же решение о сертификации по требованиям ФСБ принято, то следует начинать работу со специалистами сертифицирующей лаборатории по составлению ТЗ, определению уровня защиты, составлению перечня документации и оборудования для сертификации. В ЦСИ, например, подобная подготовка проводится еще до заключения договора с организациями.

Важным моментом дальнейшей совместной работы сертифицирующей организации и заказчика является определение объема исследований и соответственно стоимости работ. Из-за сложности исследуемого оборудования порой бывает трудно установить этот объем без проведения предварительных исследований. Тогда вначале заключается договор лишь на первый этап работы, когда проводится предварительный анализ документации, разрабатываются программа и методики испытаний, которые согласуются с соответствующим подразделением ФСБ. Согласованная программа исследований становится тем объективным документом, на основании которого определяется объем предстоящих исследований, сроки их проведений и стоимость работ.

Следует отметить еще один важный момент осуществления сертификационных исследований — экспертизу представленных отчетов в экспертной организации (подразделение 8-го Центра ФСБ). Этот этап не включается в договор на проведение сертификации (так как ФСБ не может быть участником договора), но на его реализацию тратится, как правило, до двух месяцев. Результатом экспертизы считается заключение 8-го Центра ФСБ о выполнении требований по безопасности. Конечно, положительные выводы отчетов сертифицирующей лаборатории не гарантируют таких же положительных оценок заключения. Однако практика работы нашей испытательной лаборатории показывает, что совпадение выводов бывает почти стопроцентным. А положительное заключение дает право на получение сертификата.

Обсуждение

Требуется ли их сертификация? Если требуется, то на основании каких документов?

Не пойму с каких пор профессиональный термин шифртехника стал с буквой "О9 внутри.

Раньше так только "ЛЮБИТЕЛИ9 писали.

Ни тебе цен ни четких требований.

Где же вы были сертифи каторы?

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

Это вообще о чем?

Что в этом направлении делалось?

Только пузыри надували?

Писал стажер (первое нижнее фото) — а оба цензора (на верхних фото) видимо спали.

"ОДНИМ из направлений деятельности ФСБ (ранее - ФАПСИ)"

как будто раньше ФСБ называлось ФАПСИ 🙂

Персонал 8 ГУ КГБ поделили между КГБ и СВР

потом из КГБ их обозвали ФСК и где-то там-же из тех-же было образовано ФАПСИ.

А когда Путин ФАПСИ поделил между ФСО, ФСБ и СВР то запутал уже всех.

Вот они и самоназываются как хотят, предполагая что фамилия начальника отдела (управления) говорит что-то посвященным.

Одним словом не грузитесь — это все одна каша.

Просто ранеее это направление было в ведении ФАПСИ. Когда ФАПСИ разделили — отошло к ФСБ

Вы предмету по энциклопедии учились?

Или это вы туда (в энциклопедию) эту ошибку сами намеренно внесли?

Насколько могу судить в профессиональной (НЕ Любительской) среде термин

ШИФР"о9ТЕХНИКА исстари пишется без связующей "О9 .

О — это для щелкоперов уровня щеголева и прочих "ЖУРНАЛИСТОВ9- "специалистов9.

Настоящий Руководящий документ (РД) устанавливает классификацию программного обеспечения (ПО) (как отечественного, так и импортного производства) средств защиты информации (СЗИ), в том числе и встроенных в общесистемное и прикладное ПО, по уровню контроля отсутствия в нем недекларированных возможностей.

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъ­являемого:

к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ

Руководящий документ разработан в дополнение РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.,

РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство,

1992 г. и РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации»,М., 1997 г.

Документ предназначен для специалистов испытательных лабораторий, заказчиков, разработчиков ПО СЗИ при его контроле в части отсутствия недекларированных возможностей.

1. Общие положения

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2. Устанавливаетсячетыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.

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

1.4 . Самый высокий уровень контроля –первый , достаточен для ПО, используемого при защите информации с грифом «ОВ».

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».

1.5 Самый низкий уровень контроля -четвертый , достаточен для ПО, используемого при защитеконфиденциальной информации.

2. Термины и определения

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

2.6.Фактический маршрут выполнения функциональных объектов – последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации

Классификация по уровню контроля отсутствия недекларированных возможностей

Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. N 114

Настоящий Руководящий документ (РД) устанавливает классификацию программного обеспечения (ПО) (как отечественного, так и импортного производства) средств защиты информации (СЗИ), в том числе и встроенных в общесистемное и прикладное ПО, по уровню контроля отсутствия в нем недекларированных возможностей.

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:
- к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
- к содержанию испытаний.

Руководящий документ разработан в дополнение:
- РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;
- РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;
- РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.

Документ предназначен для специалистов испытательных лабораторий, заказчиков, разработчиков ПО СЗИ при его контроле в части отсутствия недекларированных возможностей.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.

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

1.4. Самый высокий уровень контроля - первый, достаточен для ПО, используемого при защите информации с грифом «ОВ».

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».

1.5 Самый низкий уровень контроля - четвертый, достаточен для ПО, используемого при защите конфиденциальной информации.

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

2.1. Недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.

Реализацией недекларированных возможностей, в частности, являются программные закладки.

2.2. Программные закладки - преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.

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

В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.

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

2.5. Маршрут выполнения функциональных объектов - определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6. Фактический маршрут выполнения функциональных объектов - последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

2.7. Критический маршрут выполнения функциональных объектов - такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.

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

2.9. Динамический анализ исходных текстов программ - совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа.

3. ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ
3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ

Таблица 1

Обозначения
"-" - нет требований к данному уровню;
"+" - новые или дополнительные требования;
"=" - требования совпадают с требованиями предыдущего уровня.

3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ

3.2.1.Контроль состава и содержания документации

В состав документации, представляемой заявителем, должны входить:

Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;

Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;

Описание применения (ГОСТ 19.502-78), содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы.

Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.

Для ПО импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям указанных ГОСТ.

3.2.2. Контроль исходного состояния ПО

Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.

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

Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.

3.2.3. Статический анализ исходных текстов программ

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

3.2.4. Отчетность

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

3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ

3.3.1.Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

3.3.3.Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:
- контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);
- контроль связей функциональных объектов (модулей, процедур, функций) по управлению;
- контроль связей функциональных объектов (модулей, процедур, функций) по информации;
- контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
- формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

3.3.4. Динамический анализ исходных текстов программ

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

3.3.5. Отчетность

Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
- контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур);
- контроля связей функциональных объектов (модулей, процедур, функций) по управлению;
- контроля связей функциональных объектов (модулей, процедур, функций) по информации;
- контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
- формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);
- контроля выполнения функциональных объектов (процедур, функций);
- сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.

3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ

3.4.1.Контроль состава и содержания документации

3.4.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

3.4.3. Статический анализ исходных текстов программ

- контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
- синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
- формирование перечня маршрутов выполнения функциональных объектов (ветвей);
- анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
- построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.

3.4.4. Динамический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
- контроль выполнения функциональных объектов (ветвей);
- сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа

3.4.5 Отчетность

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
- контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
- синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;
- формирования перечня маршрутов выполнения функциональных объектов (ветвей);
- анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
- построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в “Пояснительной записке”;
- контроля выполнения функциональных объектов (ветвей);
- сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.

3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ

3.5.1. Контроль состава и содержания документации

3.5.2. Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.3. Статический анализ исходных текстов программ

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

3.5.4. Динамический анализ исходных текстов программ

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.5. Отчетность

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