- Методы оценки систем
- Зачем проводить оценку продукта?
- Оранжевая книга
- Оранжевая книга и Радужная серия
- Красная книга
- ITSEC
- Общие критерии
Обновлено: 03.05.2010
При оценке безопасности системы проверяются части системы, имеющие отношение к ее безопасности: ТСВ, механизмы управления доступом, монитор обращений, ядро и механизмы защиты. Взаимоотношения и взаимодействие между этими компонентами также подлежит оценке. Существуют различные методы оценки и присвоения уровней гарантии системам. Но почему недостаточно только одного метода? Это связано с тем, что методы и идеология со временем развиваются, а различные страны смотрят на компьютерную безопасность по-разному и по-разному оценивают некоторые аспекты безопасности. Далее будет описан каждый из методов, и все методы будут сравнены между собой.
Оценка продукта на соответствие Оранжевой книге, ITSEC или Общим критериям – это далеко не прогулка в парке для производителя. В действительности, это длительный и сложный процесс. Прежде чем перейти к этим критериям, давайте посмотрим, зачем вообще нужно проходить через этот процесс.
Если вы идете в магазин, чтобы купить межсетевой экран, как вы узнаете уровень защиты, который предоставляет каждый из имеющихся в магазине межсетевых экранов? Какой из них лучше всего подходит для вашей среды? Вы можете послушать речи маркетологов производителя или поверить менеджеру магазина, который расскажет вам, что все ваши проблемы будут решены определенным продуктом всего за неделю. Либо вы можете послушать совет независимой третьей стороны, которая всесторонне проверила продукт и не имеет к нему никаких замечаний. Если вы выбираете последний вариант, вам нужно присоединиться к миру людей, которые используют рейтинги гарантий.
В США Национальный центр компьютерной безопасности (NCSC – National Computer Security Center), входящий в Агентства национальной безопасности (NSA – National Security Agency), является организацией, которая отвечает за оценку компьютерных систем и продуктов. NCSC использует Программу оценки доверия к продукту (TPEP – Trusted Product Evaluation Program) при проведении тестирования коммерческих продуктов на соответствие определенному набору критериев для присвоения им рейтинга.
Таким образом, производители создают продукт и передают его на оценку, которая является проверкой соответствия требованиям TPEP. Оценивающая организация имеет группу тестировщиков, которые следуют набору критериев (многие годы этими критериями была Оранжевая книга, но сейчас для этих целей используются Общие критерии) для тестирования продукта, предоставленного производителем на оценку. После прохождения оценки, продукту присваивается рейтинг уровня гарантий. Успешно оцененные продукты размещаются в Списке оцененных продуктов (EPL – Evaluated Products List) с указанием присвоенного им рейтинга. Поэтому, вместо того, чтобы просто доверять маркетологам производителя, вы, как покупатель, можете поверить словам независимой третьей стороны, полностью протестировавшей продукт. Для этого вы можете воспользоваться EPL.
Процесс оценки является очень трудоемким и дорогостоящим для производителя. Не каждый производитель проводит свои продукты через это, поскольку это дорого и, к тому же, отодвигает дату выпуска продукта на рынок. Обычно, производитель проводит свои продукты через этот процесс, только если основная часть его потенциальных покупателей ориентируется на рейтинг гарантий при выборе продукта. В США Министерство обороны является самым крупным покупателем, поэтому многие производители проводят свои основные продукты через процесс оценки, в надежде, что их купит Министерство обороны (или кто-то другой).
Министерством обороны США был разработан стандарт TCSEC (Trusted Computer System Evaluation Criteria), называемый «Оранжевой книгой», который используется для оценки операционных систем, приложений и других продуктов. Покупатели используют рейтинг гарантий в качестве критерия, являющегося метрикой при сравнении различных продуктов. Он также предоставляет конкретные требования для разработчиков, чтобы они могли учесть их при разработке своих продуктов.
Оранжевая книга используется для оценки продукта – действительно ли он имеет заявленные производителем свойства безопасности, и подходит ли продукт для выполнения определенных функций и определенных вариантов применения. Оранжевая книга используется для анализа функциональности, эффективности и гарантий продукта в процессе оценки. Она использует классы, содержащие типовые шаблоны требований безопасности.
TCSEC предоставляет систему классификации, иерархически разделенную на следующие уровни гарантий:
- А – Проверенная защита (verified protection)
- B – Мандатная защита (mandatory protection)
- C – Дискреционная защита (discretionary protection)
- D – Минимальная безопасность (minimal security)
Каждый уровень может иметь один или несколько пронумерованных классов с соответствующими наборами требований, которые должны выполняться системой для достижения этого конкретного рейтинга. Классы с более высокими номерами предоставляют более высокую степень доверия и гарантий. Так, например, класс «B2» более доверенный, чем класс «B1».
Критерии включают в себя 4 основных раздела: политика безопасности, подотчетность, гарантии и документация. Но в действительности они делятся на 7 различных областей:
- Политика безопасности. Политика должна быть ясной, однозначной и реализованной механизмами системы.
- Идентификация. Отдельные субъекты должны быть уникально идентифицированы.
- Метки. Метки управления доступом должны быть надлежащим образом связаны с объектами.
- Документация. Должна быть предоставлена документация по тестированию, конструкторская документация, технические требования, руководства для пользователя, учебная документация.
- Подотчетность. Данные аудита должны сохраняться и защищаться для обеспечения подотчетности.
- Гарантии жизненного цикла. Должна существовать возможность протестировать по отдельности программное обеспечение, аппаратное обеспечение и прошивки, чтобы убедиться, что каждый из этих компонентов эффективно реализует политику безопасности в течение своего жизненного цикла.
- Непрерывная защита. Механизмы безопасности и система в целом должны всегда работать предсказуемо и приемлемо в различных ситуациях.
Каждый уровень и класс включает в себя требования предыдущего уровня или класса. Это означает, что «C2» должен соответствовать требованиям своих критериев, а также всем требованиям критериев «C1», а «B3» помимо своих требований должен удовлетворять требованиям «C1», «C2», «B1» и «B2». Каждый уровень или класс вносит свой вклад в требования безопасности и ожидает выполнения всех требований всех предыдущих классов и разделов.
Разве Оранжевая книга еще актуальна? Мы перешли от Оранжевой книги к Общим критериям, поэтому возникает резонный вопрос – зачем изучать Оранжевую книгу? Сам по себе факт перехода не сделал Оранжевую книгу неважной. Это была первая эволюция критериев, и она использовалась 20 лет. Многие основные термины и концепции произошли из Оранжевой книги. И у нас все еще есть много продуктов с рейтингами Оранжевой книги, которые, в конечном счете, пройдут оценку по Общим критериям.
Экзамен CISSP неуклонно переходит от Оранжевой книги к Общим критериям, но этот переход еще не завершен.
Уровень D: Минимальная защита
На уровне «D» есть только один класс. Он зарезервирован для систем, которые проходили процесс оценки, но не смогли удовлетворить критериям и требованиям более высоких уровней.
Уровень С: Дискреционная защита
Уровень «C» содержит два отдельных класса рейтинга гарантий, которые описаны далее. Более высокий номер рейтинга гарантий означает более высокий уровень защиты.
C1: Дискреционное обеспечение безопасности (Discretionary Security Protection). Дискреционное управление доступом основано на отдельных людях и/или группах. Оно требует разделения пользователей и информации, проведения идентификации и аутентификации отдельных сущностей. Управление доступом необходимо, чтобы пользователи могли быть уверены, что их данные не могут быть получены или повреждены неуполномоченными лицами. Архитектура системы должна обеспечивать защищенный домен выполнения, обеспечивающий невозможность негативного воздействия на привилегированные системные процессы со стороны менее привилегированных процессов. Должны существовать определенные способы проверки функциональной целостности системы. Требования к документации включают обязательное наличие конструкторской документации, показывающей, как защитные механизмы встроены в систему, документации по тестированию (планы и результаты тестирования), описания возможностей системы, позволяющие покупателю понять, как правильно установить и настроить систему, а также учебную документацию для пользователей.
Этот рейтинг требуется для среды, в которой пользователи обрабатывают информацию одного уровня критичности, поэтому строгое управление доступом и средства аудита в ней не требуются. Это доверенная среда с низким уровнем безопасности.
C2: Управляемая защита доступа (Controlled Access Protection). Пользователи должны быть индивидуально идентифицированы для обеспечения более точного управления доступом и функций аудита. Механизмы логического управления доступом используются для выполнения аутентификации и однозначной идентификации каждого пользователя. Существенные с точки зрения безопасности события журналируются, записи о них защищены от несанкционированной модификации. Архитектура должна обеспечивать изоляцию ресурсов (или объектов), предоставляя надежную защиту, а также надлежащим образом журналировать любые производимые с ними действия. Должна применяться концепция обеспечения безопасности при повторном использовании объектов, предусматривающая, что в любом хранилище данных не должно оставаться остаточной информации после его освобождения для возможности использования другим субъектом. Например, если субъект использует сегмент памяти, то после окончания его использования, этот сегмент не должен содержать никакой информации. Это справедливо для носителей информации, используемых объектов, создаваемых временных файлов – все данные должны эффективно затираться, когда субъект перестает использовать это хранилище.
Этот класс требует применения более детализированных методов, обеспечивающих управление доступом. Система должна реализовывать строгие процедуры входа в систему и предоставлять возможности принятия решений по запросам субъектов на доступ к объектам. Система «C2» не может гарантировать невозможность своей компрометации, но она предоставляет уровень защиты, который существенно усложняет попытки взлома.
Системы с рейтингом «С2» требуются для среды, в которой пользователи являются доверенными, но требуется определенный уровень подотчетности. «С2», в целом, выглядит наиболее разумно для коммерческих приложений, однако уровень его защиты сравнительно невелик.
Уровень B: Мандатная защита
Мандатное управление доступом реализуется посредством использования меток безопасности. Архитектура основана на модели безопасности Bell-LaPadula, должны быть доступны доказательства реализации монитора обращений.
B1: Маркированная безопасность (Labeled Security). Каждый объект данных должен содержать метку классификации, а каждый субъект должен иметь метку допуска. Когда субъект пытается получить доступ к объекту, система должна сравнить метки безопасности субъекта и объекта, чтобы убедиться, что запрошенные действия допустимы. Выходящие из системы данные также должны содержать правильную метку безопасности. Политика безопасности основана на неформальных утверждениях, а технические условия и конструкторская документация проанализированы и проверены.
Этот рейтинг безопасности предназначен для сред, в которых обрабатываются классифицированные данные.
ПРИМЕЧАНИЕ. Метки безопасности не требуются при рейтинге безопасности ниже «В». Поэтому например, «С2» не требует меток безопасности, а «В1» – требует.B2: Структурированная защита (Structured Protection). Политика безопасности явно определена и документирована, структура системы и ее реализация подвергнуты исчерпывающему анализу и детальным тестовым процедурам. Этот класс требует наличия более строгих механизмов аутентификации и строго определенных интерфейсов между уровнями. Субъекты и устройства требуют наличия меток, а система не должна допускать наличия скрытых каналов. Должен существовать доверенный способ (trusted path) входа в систему и прохождения аутентификации, который обеспечивает прямое взаимодействие субъектов с приложениями или операционной системой, а также отсутствием недокументированных способов доступа (backdoor, trapdoor). Отсутствуют способы обхода или компрометации этого доверенного коммуникационного канала. Существует разделение функций администратора и оператора в рамках системы для обеспечения более доверенного и защищенного функционирования. Должно быть обеспечено отдельное адресное пространство для изоляции процессов и проведен анализ скрытых каналов. Этот класс увеличивает гарантии, расширяя требования к структуре системы.
Системы «В2» требуются для среды, в которой обрабатываются критичные данные, требующие высокого уровня безопасности. Такая среда требует использования систем, относительно стойких к попыткам проникновения и компрометации.
B3: Домены безопасности (Security Domains). В этом классе обеспечена еще большая детализация для каждого защитного механизма, а программный код, не требующийся для поддержки политики безопасности, исключен. Структура и реализация системы не должны быть очень сложными, поскольку сложность системы увеличивает требования к уровню подготовки людей, которые должны будут ее тестировать, поддерживать и настраивать, в связи с чем безопасность системы в целом может быть подвержена дополнительным угрозам. Компоненты монитора обращений должны быть достаточно небольшими, чтобы они могли быть надлежащим образом протестированы, также они должны быть устойчивы к внешним воздействиям. Роль администратора безопасности должна быть явно определена, система должна быть способна восстанавливаться после сбоев без снижения уровня безопасности. Процесс запуска системы и загрузки ее операционной системы и компонентов должен выполняться в изначально безопасном состоянии, чтобы обеспечить невозможность использования слабостей системы на этом этапе.
Системы «В3» требуются для высоко защищенной среды, которая обрабатывает очень критичную информацию. Системы должны быть высоко устойчивы к попыткам проникновения.
Уровень A: Проверенная защита
Формальные методы используются для обеспечения того, что все субъекты и объекты управляются средствами дискреционного и мандатного управления доступом. Проектирование, разработка, внедрение и документация рассматриваются формально и детально. Механизмы безопасности систем «В3» и «А1» отличаются несильно, но в «А1» применяются гораздо более структурированные и строгие процедуры оценки способов проектирования и разработки системы.
A1: Проверенная структура (Verified Design). Архитектура и возможности защиты не сильно отличаются от систем с рейтингом «В3», но гарантии систем «А1» выше, чем систем «В3», из-за более формального подхода к проектированию системы «А1», разработки ее технических требований и более детальной техники проведения проверки. Для проверки эквивалентности между техническими требованиями ТСВ и моделью политики безопасности используются формальные техники. При разработке систем «А1» реализуется более строгое изменение конфигурации, может быть проверена структура в целом. Часто даже способ доставки системы заказчику внимательно исследуется, чтобы убедиться в отсутствии компрометации системы до ее внедрения в работу.
Тип среды, который требует систем «А1», является самым безопасным среди безопасных сред. Этот тип среды пригоден для совершенно секретной информации и гарантирует невозможность использования системы, минуя строгую аутентификацию, ограничения и аудит.
ПРИМЕЧАНИЕ. TCSEC учитывает конфиденциальность, но не целостность. Функциональность механизмов безопасности и гарантии этих механизмов не оцениваются раздельно, они комбинируются и оцениваются как одно целое.Ссылки по теме:
- Trusted Computer System Evaluation Criteria (Orange Book), U.S. Department of Defense (Dec. 26, 1985)
- Lecture notes for Cryptography and Network Security, Part 7, “Trusted Computer Systems,” William Stallings, lecturer, Dr. Lawrie Brown, author
Оранжевая книга в основном учитывает правительственные и военные требования и ожидания для их компьютерных систем. Многие люди видят определенные недостатки в Оранжевой книге в части безопасности, особенно когда применяют эти требования в коммерческой области, а не военной организации. Ниже перечислены основные проблемы, возникающие у практиков при использовании Оранжевой книги:
- Она применима к операционным системам, но не другим системам, таким как сети, базы данных и т.д.
- Она фокусируется в основном на одном атрибуте безопасности – конфиденциальности, но не учитывает целостность и доступность.
- Она работает с правительственной классификацией, а не с классификацией, применяемой в коммерческих компаниях.
- Она имеет относительно небольшое количество рейтингов, в связи с чем множество различных аспектов безопасности не оцениваются независимо.
Поскольку Оранжевая книга фокусируется на операционных системах, множество других областей безопасности она не учитывает. Оранжевая книга предоставляет широкую платформу для построения и оценки доверенных систем, но оставляет без ответа множество вопросов, не касающихся операционных систем. Много книг было написано для расширения границ Оранжевой книги в другие области безопасности. Эти книги предоставляют детальную информацию и интерпретацию определенных требований Оранжевой книги и описывают процесс оценки. Все эти книги вместе называются Радужной серией (т.к. их обложки имеют различные цвета).
Для пояснения каждой книги и ее использования, пожалуйста, ознакомьтесь со следующими ссылками.
Ссылки по теме:
Оранжевая книга учитывает односистемную безопасность, но сети являются комбинацией систем, и каждая сеть нуждается в обеспечении безопасности, не требуя при этом полного доверия от всех и каждой подключенных к ней систем. Трактовка доверенных сетей (TNI – Trusted Network Interpretation), также называемая Красной книгой, учитывает аспекты оценки безопасности для сети и сетевых компонентов. Она учитывает изолированные локальные (LAN) сети и глобальные сети (WAN).
Как и Оранжевая книга, Красная книга не содержит конкретных деталей по вопросам реализации механизмов безопасности, вместо этого она предоставляет основу для обеспечения безопасности различных типов сетей. Сеть имеет политику безопасности, архитектуру и дизайн – как и операционная система. Субъекты, использующие доступ к объектам в сети, должны управляться, отслеживаться и проверяться. В сети субъектами могут быть рабочие станции, а объектами могут быть сетевые сервисы на сервере.
Красная книга оценивает степень конфиденциальности данных и операций, происходящих в сети и сетевых системах. Данные и метки должны быть защищены от несанкционированного изменения, должна обеспечиваться целостность передаваемой информации. Исходные и целевые механизмы, используемые для обмена сообщениями, должны быть оценены и протестированы, чтобы обеспечить невозможность модификации.
Безопасность сети обеспечивается такими средствами, как шифрование и протоколы, и Красная книга измеряет их функциональность, стойкость и гарантии.
Ниже приведен перечень вопросов безопасности, учтенных в Красной книге:
• Целостность коммуникаций
- Аутентификация. Защищает от атак маскарадинга и повторного воспроизведения (playback attack). Механизмы включают цифровую подпись, шифрование, штампы времени и пароли.
- Целостность сообщений. Защищает заголовок протокола, информацию маршрутизации и содержимое пакета от модификации. Механизмы включают аутентификацию и шифрование сообщений.
- Невозможность отказа от авторства. Гарантирует, что отправитель не может отказаться от факта отправки сообщения. Механизмы включают шифрование, цифровую подпись и подтверждение подлинности (notarization).
- Непрерывность деятельности. Обеспечивает доступность сети даже в случае атаки. Механизмы включают применение отказоустойчивых и избыточных систем, а также средства перенастройки сетевых параметров в случае аварийной ситуации.
- Управление сетью. Мониторинг производительности сети, выявление атак и сбоев. Механизмы включают компоненты, позволяющие сетевому администратору отслеживать и ограничивать доступ к ресурсам.
- Конфиденциальность данных. Защищает данные от неавторизованного доступа в процессе передачи. Механизмы включают управление доступом, шифрование и физическую защиту кабелей.
- Конфиденциальность потока трафика. Предотвращает неавторизованный доступ к информации о маршрутизации или частоте выполнения коммуникаций посредством анализа трафика. Механизмы включают «разбавление» (padding) сообщений, отправку «шума» и «ложных» сообщений.
- Избирательная маршрутизация. Маршрутизирует сообщения способом, исключающим некоторые специфические угрозы. Механизмы включают конфигурацию сети и таблицы маршрутизации.
TCSEC введен в 1985 году и отменен в декабре 2000 года. Это был первый методический и логичный набор стандартов разработки безопасных компьютерных систем. Он оказал большое влияние на многие страны, которые разработали свои стандарты оценки на основе рекомендаций TCSEC. В конечном итоге TCSEC был заменен Общими критериями.
ITSEC (Information Technology Security Evaluation Criteria) – это первая попытка создания единого стандарта для оценки атрибутов безопасности компьютерных систем и продуктов рядом европейских стран. США использовали Оранжевую книгу и Радужную серию, а Европа применяла ITSEC для оценки и установки рейтингов компьютерных систем. (Сегодня все мигрировали на Общие критерии, описанные в следующем разделе).
ITSEC оценивает два основных атрибута защитных механизмов систем: функциональность и гарантии. При оценке функциональности защитных механизмов системы, проводится проверка и оценка предоставляемых субъектам сервисов (механизмов управления доступом, средств аудита, аутентификации и т.д.). Функциональность защитных механизмов может сильно различаться, так как системы разрабатываются по-разному, чтобы предоставить различную функциональность пользователям. После оценки функциональности она тестируется, чтобы понять, обеспечивают ли эти функции защиту системы в той мере, в которой утверждает производитель. Гарантии, с другой стороны, это степень доверия защитным механизмам, их эффективность и возможность работы согласованным образом. Гарантии в основном проверяются путем анализа практик разработки, документации, управления настройками, тестирования механизмов.
Возможно существование двух защитных механизмов систем, предоставляющих одинаковый тип функциональности, но имеющих существенно различающийся уровень гарантий. Это связано с тем, что предоставляющие функциональность механизмы были разработаны, спроектированы и внедрены по-разному. Например, системы А и В могут иметь защитные механизмы, предоставляющие одинаковую функциональность аутентификации, и в этих условиях оба продукта имеют одинаковый рейтинг по функциональности. Но разработчики системы А были неряшливы и беззаботны при разработке механизма аутентификации и поэтому их продукт получил меньший рейтинг по уровню гарантий. ITSEC разделяет эти два атрибута (функциональность и гарантии) и присваивает им рейтинг по-отдельности, тогда как TCSEC рассматривает их совместно и присваивает им один рейтинг (от «D» до «A1»).
Следующий список показывает различные аспекты функциональности и гарантий, которые тестируются в процессе оценки.
- Требования к функционалу безопасности
- Идентификация и аутентификация
- Аудит
- Использование ресурсов
- Доверенные пути/каналы
- Защита пользовательских данных
- Управление безопасностью
- Доступ к продукту
- Коммуникации
- Защита персональных данных
- Защита функций безопасности продукта
- Поддержка криптографии
- Требования к гарантиям безопасности
- Инструкции и руководства
- Управление конфигурациями
- Оценка уязвимостей
- Доставка и функционирование
- Поддержка жизненного цикла
- Обеспечение гарантий
- Разработка
- Тестирование
Таким образом, отличие между ITSEC и TCSEC заключается в том, что TCSEC оценивает функциональность и гарантии совместно, а ITSEC рассматривает два этих атрибута раздельно. Другим отличием является тот факт, что ITSEC разработан для предоставления большей гибкости, чем TCSEC, а также то, что ITSEC учитывает целостность, доступность и конфиденциальность, в то время как TCSEC – только конфиденциальность. ITSEC также учитывает сетевые системы, а TCSEC – только автономные системы.
Таблица 3-2 показывает взаимосвязь между двумя схемами оценки.
Таблица 3-2. Связь между ITSEC и TCSEC
Как вы могли заметить, большинство рейтингов ITSEC связаны с рейтингами TCSEC, но в ITSEC добавлены рейтинги «F6» – «F10» для специфических нужд потребителей, которые TCSEC не учитывает.
ITSEC – это критерии для операционных систем и других продуктов, которые рассматриваются как отдельные объекты оценки (TOE – Target of Evaluation). Поэтому, если вы читаете литературу, обсуждающую ITSEC-рейтинги продуктов, и в ней заявлено, что ТОЕ имеет рейтинг «F1» и «Е5», вы знаете, что ТОЕ – это продукт, который был оценен и что он указывает на низкий рейтинг функциональности и высокий рейтинг гарантий.
Рейтинги относятся к гарантиям, которые являются корректностью и эффективностью механизмов безопасности, а также к функциональности. Анализ корректности рассматривает, как ТОЕ был построен и внедрен, при этом анализируется архитектура, реализация политики безопасности механизмами безопасности, документация по эксплуатации, среда. Анализ эффективности рассматривает недостатки процесса разработки и эксплуатации, простоту их использования, чтобы корректные настройки безопасности не мешали производительности. Функциональность рассматривается в терминах целей безопасности системы, функций и механизмов безопасности. Функциональностью может быть, например, идентификация и аутентификация, управление доступом, подотчетность, журналирование, повторное использование объектов, точность, надежность сервисов и обмен данными.
Ссылки по теме:
Оранжевая книга и Радужная серия предоставляют схемы оценки, крайне негибкие для бизнеса. ITSEC пытается предоставить более гибкий подход, разделяя атрибуты функциональности и гарантий и учитывая оценку всей системы в целом. Однако эта гибкость добавляет сложности, так как оценщики могут смешивать и сочетать рейтинги функциональности и гарантий, что приведет к слишком большому количеству классификаций и их ненадежности. Следующей попыткой сделать все правильно стало создание более эффективных и приемлемых критериев оценки – Общих критериев (Common Criteria).
В 1990 году Международная организация по стандартизации (ISO – International Organization for Standardization) выявила наличие потребности в международном стандарте критериев оценки, который мог бы использоваться в глобальных масштабах. Проект по созданию Общих критериев стартовал в 1993 году, когда несколько организаций собрались для объединения и согласования существующих и разрабатываемых критериев оценки (TCSEC, ITSEC, CTCPEC и Федеральных критериев). В результате сотрудничества между национальными организациями по стандартизации США, Канады, Франции, Германии, Великобритании и Нидерландов были разработаны Общие критерии.
Выгода от получения глобального, принятого на мировом уровне набора критериев заключается в уменьшении сложности рейтингов для покупателей, исключении необходимости понимания определения и смысла различных рейтингов в рамках различных схем оценки. Это также помогает производителям, т.к. теперь они могут обеспечивать соответствие одному конкретному набору требований, даже если они хотят продавать свой продукт на международном рынке, а не пытаться обеспечить соответствие нескольким различным рейтингам с различными требованиями и правилами.
Оранжевая книга оценивает все системы на соответствие модели Bell-LaPadula. Общие критерии предоставляют значительно большую гибкость, оценивая продукты на соответствие профилям защиты, которые структурированы для учета потребностей безопасности в реальном мире. Так, если Оранжевая книга говорит: "Все марш в этом направлении, в этой форме и по этому пути!", Общие критерии спрашивают: "Так, какие угрозы сегодня стоят перед нами и каков лучший вариант борьбы с ними?".
В модели Общих критериев выполняется оценка продукта, после чего ему присваивается Оценочный уровень гарантий (EAL – Evaluation Assurance Level). Исчерпывающее и строгое тестирование, основанное на ориентированных на детали задачах, повышает уровень гарантий. Общие критерии имеют семь уровней гарантий в диапазоне от «EAL1», где проводится тестирование функциональности, до «EAL7», где выполняется исчерпывающее тестирование и проверяется структура системы. Различные пакеты EAL приведены в списке:
- EAL 1. Функционально протестировано
- EAL 2. Структурно протестировано
- EAL 3. Методически протестировано и сверено
- EAL 4. Методически проработано, протестировано и проанализировано
- EAL 5. Полуформально проработано и протестировано
- EAL 6. Полуформально проработано и протестировано с подтверждением
- EAL 7. Формально проработано и протестировано с подтверждением
ПРИМЕЧАНИЕ. Если система является «формально проработанной», это означает, что она основана на модели, которая может быть математически доказана.Общие критерии используют профили защиты в процессе оценки. Это механизм, который используется для описания потребностей реального мира в отношении продуктов, которые сейчас отсутствуют на рынке. Профиль защиты содержит набор требований по безопасности, их смысл и обоснования, а также соответствующий рейтинг EAL, который требуется для продукта. Профиль защиты описывает предположения о среде, цели, ожидаемый уровень функциональности и гарантий. Каждая существенная угроза указывается с пояснениями, как она должна контролироваться посредством конкретных задач. Профиль защиты также обосновывает уровень гарантий и требования к стойкости каждого защитного механизма.
Профиль защиты дает покупателю (или другим) возможность указать специфические потребности в безопасности для решения определенной проблемы безопасности. Если кто-то определил потребности в безопасности, но они не реализованы в имеющихся на рынке продуктах, этот человек может написать профиль защиты, описывающий продукт, решающий эту реальную проблему. Профиль защиты нужен для указания необходимых целей и защитных механизмов для достижения необходимого уровня безопасности, а также списка вещей, которые могут «пойти не так» в процессе разработки системы такого типа. Этот список используется инженерами, разрабатывающими систему, и затем оценщиками, чтобы убедиться, что инженеры выполнили свою работу в полном объеме.
Общие критерии были разработаны, чтобы придерживаться классов оценки, сохраняя при этом некоторую степень гибкости. Профили защиты были разработаны для описания функциональности, гарантий, описаний и рациональных требований к продукту.
Как и другие оценочные критерии до них, Общие критерии работают, чтобы ответить на два основных вопроса об оцениваемом продукте: что делают его механизмы безопасности (функциональность) и насколько в них можно быть уверенным (гарантии)? Эта система создает основу, позволяющую покупателям ясно описывать свои проблемы безопасности, разработчикам – описывать свои решения по безопасности для решения этих проблем, а оценщикам – для недвусмысленного определения того, что продукт в действительности выполняет.
Профиль защиты содержит следующие пять разделов:
- Описательные элементы. Указывает название профиля и описание проблемы безопасности, которая должна быть решена.
- Логическое обоснование. Обосновывает профиль и дает более детальное описание реальной проблемы, которая должна быть решена. Предполагаемые среда и порядок использования, а также угрозы, показываются вместе с описанием политик безопасности, которые должен поддерживать продукт или система, чтобы соответствовать данному профилю.
- Функциональные требования. Устанавливают границы защиты, означающие, что угрозы или компрометации в рамках этих границ должны быть предотвращены. Продукт или система должны реализовать границы, установленные в этом разделе.
- Требования к гарантиям разработки. Идентифицирует конкретные требования, которым продукт или система должны удовлетворять на этапе разработки – от момента начала проектирования до момента внедрения.
- Требования к оценке гарантий. Устанавливают тип и интенсивность оценки.
ПРИМЕЧАНИЕ. Когда продукту присвоен рейтинг гарантий, это означает, что потенциально он может обеспечить этот уровень защиты. Покупатель должен правильно настроить продукт, чтобы реально получить этот уровень защиты. Производитель должен предоставить необходимую документацию по настройке и объяснить покупателю, как правильно настроить продукт и сохранить правильную настройку в течение всего времени его эксплуатации.
Различные компоненты Общих критериев перечислены и описаны ниже:
Ссылки по теме:
- Профиль защиты. Описание необходимого решения безопасности.
- Объект оценки. Продукт, который предлагается в качестве необходимого решения безопасности.
- Цель безопасности. Написанное разработчиком пояснение функциональности и гарантий безопасности, реализованных необходимым решением безопасности; другими словами: «это то, что наш продукт делает и как он это делает».
- Пакеты EAL. Требования в отношении гарантий и функциональности, объединенные в пакет для повторного использования. Этот компонент описывает, что должно быть учтено для достижения продуктом определенного рейтинга EAL.
Комментариев нет:
Отправить комментарий