7.2.2. "Методический документ. Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций" (утв. Банком России 10.07.2020)

ADV_ARC.1 Описание архитектуры безопасности

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

Зависимости:

ADV_FSP.1 Базовая функциональная спецификация;

ADV_TDS.1 Базовый проект.

Элементы действий разработчика

ADV_ARC.1.1D

Разработчик должен спроектировать ОО и обеспечить реализацию проекта таким образом, чтобы свойства безопасности ФБО невозможно было обойти.

ADV_ARC.1.2D

Разработчик должен спроектировать ФБО и обеспечить их реализацию таким образом, чтобы ФБО обеспечивали собственную защиту от вмешательства недоверенных сущностей.

ADV_ARC.1.3D

Разработчик должен предоставить "Описание архитектуры безопасности" ФБО.

Элементы содержания и представления документированных материалов

ADV_ARC.1.1C

Уровень детализации "Описания архитектуры безопасности" должен соответствовать представленному в проектной документации по ОО описанию абстракций (элементов представления ОО), осуществляющих выполнение ФТБ.

ADV_ARC.1.2C

В "Описание архитектуры безопасности" должно быть включено описание доменов безопасности, обеспеченных согласованностью ФБО с ФТБ.

ADV_ARC.1.3C

"Описание архитектуры безопасности" должно предоставлять информацию о том, насколько процесс инициализации ФБО является защищенным.

ADV_ARC.1.4C

В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО обеспечивают собственную защиту от вмешательства.

ADV_ARC.1.5C

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

Элементы действий оценщика

ADV_ARC.1.1E

Оценщик должен подтвердить, что информация, представленная разработчиком в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в ADV_ARC.1.1C - ADV_ARC.1.5C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 10.3.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

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

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

ADV_FSP.4 Полная функциональная спецификация

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

если сервис, доступ к которому предоставляется интерфейсом, может быть сопоставлен с одним из ФТБ, предъявляемых к ФБО, тогда данный интерфейс относится к категории осуществляющих выполнение ФТБ;

интерфейсы сервисов, от которых зависят функциональные возможности, осуществляющие выполнение ФТБ, но при этом от них для осуществления политик безопасности ОО требуется только правильное функционирование, относятся к категории поддерживающих выполнение ФТБ;

интерфейсы сервисов, от которых никак не зависят функциональные возможности, осуществляющие выполнение ФТБ, относятся к не влияющим на выполнение ФТБ.

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

Зависимости: ADV_TDS.1 Базовый проект.

Элементы действий разработчика

ADV_FSP.4.1D

Разработчик должен представить функциональную спецификацию.

ADV_FSP.4.2D

Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.

Элементы содержания и представления документированных материалов

ADV_FSP.4.1C

В функциональной спецификации должны быть полностью представлены ФБО.

ADV_FSP.4.2C

В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.

Замечания по применению:

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

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

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

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

ADV_FSP.4.3C

В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.

ADV_FSP.4.4C

В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.

ADV_FSP.4.5C

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

ADV_FSP.4.6C

В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

Элементы действий оценщика

ADV_FSP.4.1E

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

ADV_FSP.4.2E

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

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 10.4.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ADV_IMP.2 Полное отображение представления реализации ФБО

Зависимости:

ADV_TDS.3 Базовый модульный проект;

ALC_TAT.1 Полностью определенные инструментальные средства разработки;

ALC_CMC.4 Поддержка генерации, процедуры приемки и автоматизация.

Элементы действий разработчика

ADV_IMP.2.1D

Разработчик должен обеспечить доступ к представлению реализации для всех ФБО.

Замечания по применению:

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

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

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

ADV_IMP.2.2D

Разработчик должен обеспечить прослеживание всего представления реализации к описанию проекта ОО.

ADV_IMP.2.3D

Разработчик должен провести контроль представления реализации ОО.

Замечания по применению:

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

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

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

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

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

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

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

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

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

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

б) текстов функциональных объектов преобразования форматов данных;

в) вызовов системных функциональных объектов и функциональных объектов обеспечения ИБ разделяемых обеспечивающих компонентов ППО, в том числе функциональных объектов обеспечения ИБ операционной системы, функциональных объектов ввода/вывода, управления памятью и системными ресурсами;

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

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

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

ж) текстов функциональных объектов обработчиков ошибок и исключений.

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

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

Элементы содержания и представления документированных материалов

ADV_IMP.2.1C

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

ADV_IMP.2.2C

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

Замечания по применению:

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

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

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

ADV_IMP.2.3C

В прослеживании между всем представлением реализации и описанием проекта ОО должно быть продемонстрировано их соответствие.

Замечания по применению:

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

Для модулей ОО, определенных как "не влияющие на выполнение ФТБ", должно быть предоставлено соответствующее обоснование.

ADV_IMP.2.4C

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

Замечания по применению:

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

Элементы действий оценщика

ADV_IMP.2.1E

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

ADV_IMP.2.2E

Оценщик должен провести контроль соответствия всего представления реализации описанию проекта ОО, включая:

а) контроль исходного состояния ОО;

б) контроль полноты представления реализации на уровне исходных модулей программ;

в) контроль отсутствия избыточности представления реализации на уровне исходных модулей программ;

г) контроль полноты представления реализации на уровне функциональных объектов;

д) контроль отсутствия избыточности представления реализации на уровне функциональных объектов;

е) контроль связей функциональных объектов представления реализации по управлению;

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

Работы оценки:

1. Оценщик должен выполнить действия в соответствии с пунктом 10.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" для всего представления реализации.

2. Исследование представления реализации должно выполняться с использованием методов статического и динамического анализа исходных модулей программ.

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

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

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

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

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

4. Оценщик должен выполнить контроль полноты представления реализации на уровне исходных модулей.

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

Оценщик должен исследовать исходные модули, входящие в представление реализации, для того чтобы сделать заключение о соответствии их назначения описанию назначения, представленному в проекте ОО, и о достаточности представления реализации для выполнения ФТБ.

Если в результате исследования установлено, что для ФТБ отсутствует представление реализации или оно представлено только частично, то такому этапу исследования не может быть дана положительная оценка.

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

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

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

Оценщик при контроле отсутствия избыточности исходных модулей должен:

- в части исходных модулей, осуществляющих и поддерживающих выполнение ФТБ, - исследовать (основываясь на структурном анализе и декомпозиции) эти модули, чтобы сделать заключение об отсутствии в исходных модулях функциональных возможностей безопасности, не предусмотренных проектом и ФТБ;

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

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

6. Оценщик должен выполнить контроль полноты представления реализации на уровне функциональных объектов.

Оценщик должен исследовать документированные материалы разработчика ОО, чтобы сделать вывод о том, что все аспекты ФТБ реализованы на уровне интерфейсов исходных модулей и связанных с ними определений функциональных объектов.

Оценщик должен исследовать функциональные объекты, входящие в представление реализации, с тем чтобы сделать заключение о соответствии их назначения описанию назначения, представленному в проекте ОО, и о достаточности содержащихся в представлении реализации функциональных объектов для выполнения ФТБ.

7. Оценщик должен выполнить контроль отсутствия избыточности представления реализации на уровне функциональных объектов.

Оценщик должен исследовать представление реализации, чтобы сделать заключение в отношении каждого функционального объекта как обеспечивающего выполнение ФТБ, поддерживающего выполнение ФТБ или не влияющего на выполнение ФТБ.

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

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

8. Оценщик должен выполнить контроль связей функциональных объектов представления реализации по управлению.

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

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

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

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

9. Оценщик должен выполнить контроль связей функциональных объектов (модулей, процедур, функций) по информации.

Связи функциональных объектов по информации осуществляются путем использования функциональными объектами общих информационных объектов.

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

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

При проведении исследования должны быть четко определены защищаемые ФБО информационные объекты и проанализированы все возможные обращения к ним из функциональных объектов, как непосредственные, так и через последовательность вызовов функциональных объектов.

Оценщик должен исследовать связи функциональных объектов по информации, с тем чтобы сделать заключение о том, что они не допускают возможности обхода механизмов, осуществляющих выполнение ФТБ.

ADV_IMP_EXT.3

Реализация ОО

Зависимости:

ADV_IMP.2 Полное отображение представления реализации ФБО.

Элементы действий разработчика

ADV_IMP_EXT.3.1D

Разработчик должен предоставить реализацию ОО.

ADV_IMP_EXT.3.2D

Разработчик должен обеспечить прослеживание реализации ОО к представлению реализации ФБО.

Элементы содержания и представления документированных материалов

ADV_IMP_EXT.3.1C

В документации должны быть указаны состав и значения контрольных сумм элементов реализации ПО [выбор:

загрузочные модули ПО;

[назначение: иные типы элементов реализации ПО]

].

ADV_IMP_EXT.3.2C

В прослеживании между реализацией ОО и представлением реализации должно быть продемонстрировано соответствие между реализацией ПО [выбор:

загрузочные модули ПО,

[назначение: иные типы элементов реализации ПО]

] и их представлением реализации [выбор:

исходные тексты ПО,

[назначение: иные формы представления реализации]

].

Элементы действий оценщика

ADV_IMP_EXT.3.1E

Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_IMP_EXT.3.1C и ADV_IMP_EXT.3.2C.

Работы оценки

1. Оценщик должен верифицировать представленное разработчиком прослеживание между элементами представления реализации и элементами фактической реализации ОО.

2. Оценщик должен выполнить контроль соответствия представления реализации ОО фактической реализации ОО.

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

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

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

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

ADV_TDS.3

Базовый модульный проект

Зависимости: ADV_FSP.4

Полная полуформальная функциональная спецификация.

Элементы действий разработчика

ADV_TDS.3.1D

Разработчик должен представить проект ОО.

Замечания по применению:

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

При разработке проекта ОО должны учитываться положения руководящего документа РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов", а также ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем".

ADV_TDS.3.2D

Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.

Элементы содержания и представления документированных материалов

ADV_TDS.3.1C

В проекте должно приводиться описание структуры ОО на уровне подсистем.

ADV_TDS.3.2C

В проекте должно приводиться описание структуры ОО на уровне модулей.

ADV_TDS.3.3C

В проекте должны быть идентифицированы все подсистемы ФБО.

ADV_TDS.3.4C

В проекте должно приводиться описание каждой из подсистем ФБО.

ADV_TDS.3.5C

В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.

ADV_TDS.3.6C

В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.

ADV_TDS.3.7C

В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

ADV_TDS.3.8C

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

ADV_TDS.3.9C

В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

ADV_TDS.3.10C

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

Элементы действий оценщика

ADV_TDS.3.1E

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

ADV_TDS.3.2E

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

Работы оценки

Оценщик должен выполнить действия по оценке в соответствии с пунктом 10.8.3 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".