СТАНДАРТИЗАЦИЯ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ В СЕТЯХ ПЕРЕДАЧИ ДАННЫХ

ТЕМА 2 CиСРиСИЗ 1,2,3,4 СТАНДАРТИЗАЦИЯ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ В СЕТЯХ ПЕРЕДАЧИ ДАННЫХ 1. Роль стандартов и спецификаций. Наиболее важные стандарты и спецификации в области информационной безопасности Специалистам в области информационной безопасности ИБ сегодня почти невозможно обойтись без знаний соответствующих стандартов и спецификаций. На то имеется несколько причин.Формальная состоит в том, что необходимость следования некоторым стандартам например, криптографическим и или Руководящим документам Гостехкомиссии России закреплена законодательно.

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

Отмеченная роль стандартов зафиксирована в основных понятиях закона РФ О техническом регулировании от 27 декабря 2002 года под номером 184-ФЗ принят Государственной Думой 15 декабря 2002 года 1 стандарт - документ, в котором в целях добровольного многократного использования устанавливаются характеристики продукции, правила осуществления и характеристики процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения работ или оказания услуг.

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

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

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

Эти группы, разумеется, не конфликтуют, а дополняют друг друга.

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

Из числа оценочных необходимо выделить стандарт Министерства обороны США Критерии оценки доверенных компьютерных систем и его интерпретацию для сетевых конфигураций, Гармонизированные критерии Европейских стран , международный стандарт Критерии оценки безопасности информационных технологий и, конечно, Руководящие документы Гостехкомиссии России.К этой же группе относится и Федеральный стандарт США Требования безопасности для криптографических модулей , регламентирующий конкретный, но очень важный и сложный аспект информационной безопасности. Технические спецификации, применимые к современным распределенным ИС, создаются, главным образом, Тематической группой по технологии Internet Internet Engineering Task Force, IETF и ее подразделением - рабочей группой по безопасности.

Ядром рассматриваемых технических спецификаций служат документы по безопасности на IP-уровне IPsec . Кроме этого, анализируется защита на транспортном уровне Transport Layer Security, TLS , а также на уровне приложений спецификации GSS-API, Kerberos . Необходимо отметить, что Internet-сообщество уделяет должное внимание административному и процедурному уровням безопасности Руководство по информационной безопасности предприятия , Как выбирать поставщика Интернет-услуг , Как реагировать на нарушения информационной безопасности . В вопросах сетевой безопасности невозможно разобраться без освоения спецификаций 0 Архитектура безопасности для взаимодействия открытых систем , X.500 Служба директорий обзор концепций, моделей и сервисов и X.509 Служба директорий каркасы сертификатов открытых ключей и атрибутов . Британский стандарт BS 7799 Управление информационной безопасностью. Практические правила , полезный для руководителей организаций и лиц, отвечающих за информационную безопасность, без сколько-нибудь существенных изменений воспроизведен в международном стандарте ISO IEC 17799. Таков, на наш взгляд, стандартный минимум , которым должны активно владеть все действующие специалисты в области информационной безопасности.

Краткие сведения о стандартах и спецификациях, не являющихся предметом данного курса.

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

Первым оценочным стандартом, получившим международное признание и оказавшим исключительно сильное влияние на последующие разработки в области информационной безопасности, стал стандарт Министерства обороны США Критерии оценки доверенных компьютерных систем Department of Defense Trusted Computer System Evaliation Criteria, TCSEC, TCSEC , более известный по цвету обложки под названием Оранжевая книга . Без преувеличения можно утверждать, что в Оранжевой книге заложен понятийный базис ИБ. Достаточно лишь перечислить содержащиеся в нем понятия безопасная и доверенная системы, политика безопасности, уровень гарантированности, подотчетность, доверенная вычислительная база, монитор обращений, ядро и периметр безопасности.

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

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

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

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

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

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

Важно указание и на различие между функциями сервисами безопасности и реализующими их механизмами, а также выделение двух аспектов гарантированности - эффективности и корректности средств безопасности.Руководящие документы РД Гостехкомиссии России GTKRD1-GTKRDn начали появляться несколько позже, уже после опубликования Гармонизированных критериев , и, по аналогии с последними, подтверждают разницу между автоматизированными системами АС и продуктами средствами вычислительной техники, СВТ , но в общем и целом они долгое время следовали в фарватере Оранжевой книги . Первое примечательное отклонение от этого курса произошло в 1997 году, когда был принят РД по отдельному сервису безопасности - межсетевым экранам МЭ GTKRDFW . Его основная идея - классифицировать МЭ на основании осуществляющих фильтрацию потоков данных уровней эталонной семиуровневой модели - получила международное признание и продолжает оставаться актуальной.

В 2002 году Гостехкомиссия России приняла в качестве РД русский перевод GTKRDCC международного стандарта ISO IEC 15408 1999 Критерии оценки безопасности информационных технологий ECITS1-ECITS3 , что послужило толчком для кардинальной и весьма своевременной со всех точек зрения переориентации вспомним приведенный выше принцип стандартизации из закона О техническом регулировании . Конечно, переход на рельсы Общих критериев будет непростым, но главное, что он начался.

Среди технических спецификаций на первое место, безусловно, следует поставить документ X.800 Архитектура безопасности для взаимодействия открытых систем X800 . Здесь выделены важнейшие сетевые сервисы безопасности аутентификация, управление доступом, обеспечение конфиденциальности и или целостности данных, а также невозможность отказаться от совершенных действий.

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

Наконец, детально рассмотрены вопросы администрирования средств безопасности для распределенных конфигураций.Спецификация Internet-сообщества RFC 1510 Сетевой сервис аутентификации Kerberos V5 Kerb относится к более частной, но весьма важной и актуальной проблеме - аутентификации в разнородной распределенной среде с поддержкой концепции единого входа в сеть. Сервер аутентификации Kerberos представляет собой доверенную третью сторону, владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.

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

Краткие аннотации подробно рассматриваемых в курсе стандартов и спецификаций Гармонизированные критерии Европейских стран стали весьма передовым документом для своего времени, они подготовили появление международного стандарта ISO IEC 15408 1999 Критерии оценки безопасности информационных технологий Evaluation criteria for IT security ECITS1-ECITS3 , в русскоязычной литературе обычно но не совсем верно именуемого Общими критериями ОК . На сегодняшний день Общие критерии - самый полный и современный оценочный стандарт.

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

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

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

Криптография - область специфическая, но общее представление о ее месте в архитектуре безопасности и о требованиях к криптографическим компонентам иметь необходимо.Для этого целесообразно ознакомиться с Федеральным стандартом США FIPS 140-2 Требования безопасности для криптографических модулей Security Requirements for Cryptographic Modules FIPS140 . Он выполняет организующую функцию, описывая внешний интерфейс криптографического модуля, общие требования к подобным модулям и их окружению.

Наличие такого стандарта упрощает разработку сервисов безопасности и профилей защиты для них. Криптография как средство реализации сервисов безопасности имеет две стороны алгоритмическую и интерфейсную.Нас будет интересовать исключительно интерфейсный аспект, поэтому, наряду со стандартом FIPS 140-2, мы рассмотрим предложенную в рамках Internet-сообщества техническую спецификацию Обобщенный прикладной программный интерфейс службы безопасности Generic Security Service Application Program Interface, GSS-API GSS-API . Интерфейс безопасности GSS-API предназначен для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент сервер.

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

Технические спецификации IPsec IPsec имеют, без преувеличения, фундаментальное значение, описывая полный набор средств обеспечения конфиденциальности и целостности на сетевом уровне. Для доминирующего в настоящее время протокола IP версии 4 они носят факультативный характер в перспективной версии IPv6 их реализация обязательна.На основе IPsec строятся защитные механизмы протоколов более высокого уровня, вплоть до прикладного, а также законченные средства безопасности, в том числе виртуальные частные сети. Разумеется, IPsec существенным образом опирается на криптографические механизмы и ключевую инфраструктуру.

Точно так же характеризуются и средства безопасности транспортного уровня Transport Layer Security, TLS TLS . Спецификация TLS развивает и уточняет популярный протокол Secure Socket Layer SSL , используемый в большом числе программных продуктов самого разного назначения.

В упомянутом выше инфраструктурном плане очень важны рекомендации X.500 Служба директорий обзор концепций, моделей и сервисов The Directory Overview of concepts, models and services X500 и X.509 Служба директорий каркасы сертификатов открытых ключей и атрибутов The Directory Public-key and attribute certificate frameworks X509 . В рекомендациях X.509 описан формат сертификатов открытых ключей и атрибутов - базовых элементов инфраструктур открытых ключей и управления привилегиями.

Как известно, обеспечение информационной безопасности - проблема комплексная, требующая согласованного принятия мер на законодательном, административном, процедурном и программно-техническом уровнях. При разработке и реализации базового документа административного уровня - политики безопасности организации - отличным подспорьем может стать рекомендация Internet-сообщества Руководство по информационной безопасности предприятия Site Security Handbook, см. SSH1 , SSH2 . В нем освещаются практические аспекты формирования политики и процедур безопасности, поясняются основные понятия административного и процедурного уровней, содержится мотивировка рекомендуемых действий, затрагиваются темы анализа рисков, реакции на нарушения ИБ и действий после ликвидации нарушения.

Более подробно последние вопросы рассмотрены в рекомендации Как реагировать на нарушения информационной безопасности Expectations for Computer Security Incident Response KRN . В этом документе можно найти и ссылки на полезные информационные ресурсы, и практические советы процедурного уровня.

При развитии и реорганизации корпоративных информационных систем, несомненно, окажется полезной рекомендация Как выбирать поставщика Internet-услуг Site Security Handbook Addendum for ISPs SSHA . В первую очередь ее положений необходимо придерживаться в ходе формирования организационной и архитектурной безопасности, на которой базируются прочие меры процедурного и программно-технического уровней.

Для практического создания и поддержания режима информационной безопасности с помощью регуляторов административного и процедурного уровней пригодится знакомство с британским стандартом BS 7799 Управление информационной безопасностью.Практические правила Code of practice for information security management BS7799 и его второй частью BS 7799-2 2002 Системы управления информационной безопасностью - спецификация с руководством по использованию Information security management systems - Specification with guidance for use BS7799-2 . В нем разъясняются такие понятия и процедуры, как политика безопасности, общие принципы организации защиты, классификация ресурсов и управление ими, безопасность персонала, физическая безопасность, принципы администрирования систем и сетей, управление доступом, разработка и сопровождение ИС, планирование бесперебойной работы организации.

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

Далее мы приступим к их детальному рассмотрению. 2. Общие критерии , часть 1. Основные идеи Рассматривается история создания Общих критериев , описывается их текущий статус, анализируются основные идеи История создания и текущий статус Общих критериев В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета JTC1 SC27 WG3 Международной организации по стандартизации ISO приступила к разработке Критериев оценки безопасности информационных технологий Evaluation Criteria for IT Security, ECITS . Несколько позже, в 1993 году, правительственные организации шести североамериканских и европейских стран - Канады, США, Великобритании, Германии, Нидерландов и Франции - занялись составлением так называемых Общих критериев оценки безопасности информационных технологий Common Criteria for IT Security Evaluation . За этим документом исторически закрепилось более короткое название - Общие критерии , или ОК Common Criteria, CC . Рабочая группа ISO, возглавляемая представителем Швеции, функционировала на общественных началах и действовала весьма неторопливо, пытаясь собрать и увязать между собой мнения экспертов примерно из двух десятков стран, в то время как коллектив Проекта ОК , финансируемый своими правительствами, несмотря на первоначальное трехлетнее отставание, весьма быстро начал выдавать реальные результаты.

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

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

Практически это означало, что группа WG3 стала бесплатным приложением к Проекту ОК , а сами Общие критерии автоматически должны были получить статус не межгосударственного, а международного стандарта.

В ОС Unix есть утилита tee, создающая ответвления каналов путем копирования стандартного вывода в файлы и довольно точно моделирующая взаимоотношения между коллективом Проекта ОК и группой WG3. С 1994 года ранние версии ОК становятся рабочими проектами WG3. В 1996 году появилась версия 1.0 Общих критериев , которая, помимо публикации в Internet для всеобщего свободного доступа, была одобрена ISO и обнародована в качестве Проекта Комитета.

Широкое открытое обсуждение документа и опытная эксплуатация привели к его существенной переработке и выходу версии 2.0 ОК в мае 1998 года. Разумеется, эксперты WG3 не могли ее не отредактировать.

Их замечания были учтены в версии 2.1 ОК CC211-CC213 , принятой в августе 1999 года. Соответствующий международный стандарт ISO IEC 15408-1999 ECITS1-ECITS3 введен в действие с 1 декабря 1999 года. Таким образом, фактически стандарт ISO IEC 15408-1999 и версия 2.1 ОК совпадают, а если пренебречь описываемыми ниже нюансами, их названия могут считаться взаимозаменяемыми.Однако, строго говоря, Критерии оценки безопасности информационных технологий и Общие критерии оценки безопасности информационных технологий - разные документы, поскольку выпущены под эгидой разных организаций, руководствующихся разными правилами распространения и обновления. не предоставляет свободный доступ к своим стандартам, они относительно статичны, поскольку их обновляют или подтверждают один раз в пять лет какие-либо изменения в стандарте ISO IEC 15408 можно ожидать в 2004 году . Напротив, портал Проекта ОК http www.commoncriteria.org открыт для всех желающих, а разработчики Общих критериев постоянно предлагают и принимают изменения, уточнения, интерпретации отдельных положений и готовят третью версию своего документа.

Поэтому, с формальной точки зрения, международный стандарт ISO IEC 15408-1999 по-русски правильнее сокращенно именовать КОБИТ, а не ОК. Правда, велика вероятность, что рабочая группа ISO любезно согласится и дальше пользоваться плодами Проекта ОК , естественно, внося в них свои редакторские правки Уточним, что далее, в рамках этой темы, мы будем иметь в виду именно Общие критерии , а не стандарт ISO. С целью унификации процедуры сертификации по Общим критериям в августе 1999 года была опубликована Общая методология оценки безопасности информационных технологий Common Methodology for Information Technology Security Evaluation CEM , описывающая минимальный набор действий при проведении оценки.

Проект ОК с самого начала носил не только технический, но и экономико-политический характер.

Его цель состояла, в частности, в том, чтобы упростить, удешевить и ускорить выход сертифицированных изделий информационных технологий ИТ на мировой рынок. Для этого в мае 2000 года уполномоченные правительственные организации шести стран-основателей Проекта ОК , а также Австралии и Новой Зеландии, Греции, Италии, Испании, Норвегии, Финляндии и Швеции подписали соглашение О признании сертификатов по Общим критериям в области безопасности информационных технологий позднее к нему присоединились Австрия и Израиль . Участие в соглашении предполагает соблюдение двух независимых условий признание сертификатов, выданных соответствующими органами других стран-участниц, а также возможность осуществления подобной сертификации.

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

По данным на конец 2002 года, правом выдачи сертификатов, признаваемых участниками соглашения, обладали Австралия и Новая Зеландия, Великобритания, Германия, Канада, США и Франция. К началу 2003 года сертификаты по Общим критериям получили около семидесяти разнообразных изделий ИТ ведущих производителей операционные системы, системы управления базами данных, межсетевые экраны, коммуникационные средства, интеллектуальные карты и т.п. еще почти сорок находились в процессе сертификации.

Определяя статус Общих критериев в России, следует отметить, что отечественные специалисты с самого начала внимательно следили за этим проектом, публиковали аналитические обзоры и переводы см например, JI981K . В 1999 году была организована работа по подготовке российского стандарта и Руководящего документа РД Гостехкомиссии России на основе аутентичного перевода ОК. Она велась в тесном контакте с зарубежными коллегами и успешно завершена в 2002 году. Именно тогда был официально издан ГОСТ Р ИСО МЭК 15408-2002 Критерии оценки безопасности информационных технологий GOST1-GOST3 с датой введения в действие 1 января 2004 года. А пока положение регулируется РД Гостехкомиссии России GTKRDCC , который, как и Общие критерии , по замыслу разработчиков, должен быть динамичнее стандарта, модифицируясь вместе с ОК. Российские специалисты - активные участники Проекта ОК , они вносят предложения по доработке Общих критериев , выступают с докладами на конференциях, ведут научно-исследовательские работы, внедряют ОК в практику различных организаций.

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

В ОК данное условие выполнено под объектом оценки ОО понимается аппаратно-программный продукт или информационная система с соответствующей документацией.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следуя принципам структурной декомпозиции, разработчики выделили в процессе оценки три задачи этапа 1 входная задача 2 задача оценки 3 выходная задача.Входная задача имеет дело с представленными для оценки свидетельствами далее для краткости мы будем именовать их свидетельствами оценки . Ее назначение - убедиться, что версии свидетельств корректны и должным образом защищены.

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

На всех этапах оценки должна обеспечиваться конфиденциальность.Задача оценки в общем случае разбивается на следующие подзадачи 1 оценка задания по безопасности 2 оценка управления конфигурацией ОО 3 оценка документации по передаче ОО потребителю и эксплуатационной документации 4 оценка документации разработчиков 5 оценка руководств 6 оценка поддержки жизненного цикла ОО 7 оценка тестов 8 тестирование 9 оценка анализа уязвимостей.

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

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

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

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

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

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

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

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

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

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

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

При оценке стойкости функций безопасности фаза идентификации не рассматривается предполагается, что уязвимость известна , поэтому достаточно выбрать и сложить пять чисел из последних столбцов. Табл. 2.1. Условные баллы, присваиваемые уязвимости в зависимости от времени, которое понадобится для ее идентификации и использования.Диапазон Идентификация уязвимости Использование уязвимости 0.5 часа 0 суток 2 месяца 3 месяца 5.