5.1.1 Оценивание функциональной пригодности программных средств

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

- описание основных свойств и совокупности сопутствующих понятий субхарактеристики функциональная пригодность при ее выборе подробно изложено в п.5 и проиллюстрировано в Таблица 1;

- метрики качества ПС в использовании представлены в четвертой части ISO 9126 и по существу отражают особенности атрибутов функциональной пригодности, которые следует учитывать в первую очередь с позиции заказчиков и пользователей;

- план и технология выполнения работ по оцениванию характеристик качества ПС для разработчиков, приобретателей и испытателей достаточно подробно изложены в стандарте ISO 14598:3-5;

- организации процессов оценивания основных характеристик качества ПС посвящены четыре раздела стандарта ISO 14598.

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

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

5.1.2 Оценивание корректности программных средств

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

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

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

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

Назначение оценивания корректности ПС состоит в том, чтобы обнаружить, зарегистрировать и устранить дефекты и ошибки, которые могли быть внесены во время разработки или модификации программ, проверить и установить, что (см. Таблица 1):

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

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

- архитектура ПС и требования к компонентам низкого уровня корректно переработаны в удовлетворяющий им исходный текст программ;

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

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

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

- каждое требование высокого уровня является точным, однозначным и достаточно детализированным и эти требования не конфликтуют друг с другом;

- не существует никаких конфликтов между требованиями высокого уровня и возможностями аппаратных и программных средств объектного вычислителя, особенно такими, как время реакции системы и аппаратуры ввода/вывода;

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

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

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

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

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

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

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

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

5.1.3 Оценивание способности к взаимодействию программных средств и их компонентов

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

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

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

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

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

Оценивание субхарактеристики способность к взаимодействию программных средств -- состоит в определении качества:

- унификации совместного функционирования компонентов ПС и БД с другими прикладными системами и компонентами на локальных и удаленных вычислительных платформах;

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

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

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

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

- стандартизированную архитектуру ПС или БД определенного класса, унифицированные правила структурного построения программных компонентов и базы данных, обрабатываемых программами;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.4 Оценивание защищенности программных средств

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

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

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

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

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

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

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

- ресурсы, необходимые и доступные для разработки и размещения программных компонентов системы обеспечения безопасности ИС (финансово экономические, ограниченная квалификация специалистов и вычислительные ресурсы ЭВМ);

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

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 5. Оценивание характеристик качества программных средств

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

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

Качество комплексов защиты зависит от применения конкретных стандартов и нормативных документов и реализации их требований. Наиболее широко и детально методологические и системные задачи проектирования и оценивания комплексной защиты ИС изложены в трех частях стандарта ISO 15408:1999 - 1-З. - Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1 Введение и общая модель. Часты 2. Защита функциональных требований. Часть 3. Защита требований к качеству.

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