Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Классы требований уверенности в безопасности при оценке ОО





Управление конфигурацией (ACM)

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

Поставка и эксплуатация (ADO)

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

Разработка (ADV)

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

Руководства (AGD)

Класс «Руководства» связан с безопасной эксплуатацией ОО пользователями и администраторами.

Поддержка жизненного цикла (ALC)

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

Тестирование (ATE)

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

Оценка уязвимостей (AVA)

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

Подход к оценке

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

Оценка

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

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

Оценка ПЗ – выполняемая по критериям оценки для ПЗ (из части 3 ОК)

Оценка ЗБ – выполняемая по критериям оценки для ЗБ (из части 3 ОК)

Оценка ОО – выполняемая по критериям оценки из части 3 ОК с использованием оцененного ЗБ в качестве основы

Поддержание уверенности в безопасности – выполняемое в соответствии со схемой, основанной на требованиях из части 3 ОК.

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

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

Примеры ПЗ

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

· базовый коммерческий профиль защиты;

· профили, отражающие требования классов C2 и B1 «Оранжевой книги»;

· профиль управления доступом, основанного на ролях;

· профили для смарт–карт;

· профиль для реляционных баз данных;

· профили межсетевых экранов для пакетных фильтров и шлюзов приложений.







Date: 2016-08-30; view: 322; Нарушение авторских прав



mydocx.ru - 2015-2024 year. (0.005 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию