Реферат: Стандартизация в области информационной безопасности в сетях передачи данных - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Стандартизация в области информационной безопасности в сетях передачи данных

Банк рефератов / Компьютерные сети

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 88 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

ТЕМА _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-сообщество уделяет должное внимание административному и проц едурному уровням безопасности ("Руководство по информационной безопасности предприятия ", "Как выбирать поставщика Интернет-услуг ", "Как ре агировать на нарушения информационной безопа с ности "). В вопросах сетевой безопасности невозм ожно разобраться без освоения спецификаций X.800 "Архитектура безопасности для взаимодействия открытых систем ", 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/I EC 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-ECIT S 3], в русскоязы чной литературе обычно (но не совсем ве рно ) именуемого "Общими критериями " (ОК ). На сегодняшний день "Общие критерии " - сам ый полный и современный оценочный стандарт . На самом деле , это метастандарт , опред еляющий инструменты оценки безопасн ости ИС и порядок их использования ; он не содержат предопределенных классов безопасност и . Такие классы можно строить , опираясь на заданные требования . ОК содержат два основных вида требований без опасности : 1 функциональные , соответствующие активному аспе кту защиты , предъявляемые к функциям (сервисам ) безопасности и реализующим их механизмам ; 2 требования дов ерия , соответствующие пассивному аспекту ; они предъявляются к технологии и процессу разработки и эксплуатации . Требования бе зопасности формулируются , и их выполнение проверяется для определенного объекта оце нки - аппаратно-программного продукта или информа ционной системы . Подчеркнем , что безопасность в ОК р ассматривается не статично , а в соответстви и с жизненным циклом объекта оценки . Кр оме того , пос ледний предстает в кон тексте среды безопасности , характеризующейся оп ределенными условиями и угрозами . "Общие критерии " способствуют формировани ю двух базовых видов используемых на п рактике нормативных документов - это профиль защиты и задание по безопасн ости . Профиль защиты представляет собой типо вой набор требований , которым должны удовле творять продукты и /или системы определенно го класса . Задание по безопасности содержит совок упность требований к конкретной разработке , их выполнение позволит решить по ста вленные задачи по обеспечению безопасности . В последующей части курса будут де тально рассмотрены как сами "Общие критерии ", так и разработанные на их основе профили защиты и проекты профилей . Криптография - область специфическая , но общее представлени е о ее месте в архитектуре безопасности и о требованиях к криптографическим компонентам иметь нео бходимо . Для этого целесообразно ознакомиться с Федеральным стандартом США FIPS 140-2 "Требования безопасности для криптогра фических модулей " (Security Require ments 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 wit h guidance for use) [BS7799-2]. В нем разъясняются такие понятия и процедуры , как политика безопасности , общие принципы организации з ащиты , классификация ресурсов и управление ими , безопасность персонала , физическая безопасность , принципы администрирования систем и сетей , у правление доступом , разработка и сопровождение ИС , планирование бесперебойн ой работы организации . Можно видеть , что отобранные для курса стандарты и специф икации затрагивают все уровни информационной безопасности , кроме законодательного . Далее мы приступим к их детальному рассмотр ению. 2. «Общие критерии» , часть 1. Основные идеи Рассматривается история соз дания "Общих критериев ", описывается их теку щий статус , анализируются основные идеи История созд ания и текущий статус "Общих критер иев " В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета (JTC1/SC27/WG3) Международной организации по ст андартизации (ISO) приступила к разработке "Критерие в оценки безопасности информационных технологи й " (Evaluation Crite ria 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 не предоставляет свободный доступ к своим стандартам , они относительно статичн ы , поскольку их обновляют или подтверждают один раз в пять лет (какие-либо из менения в ст андарте 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 0 < суток 2 3 < месяца 3 5 > месяца 5 8 Табл . 2.2. Условные баллы , присваиваемые уязвимости в зависимо сти от уровня квалификации , необходимого дл я ее идентифика ции и использования. Уровень Идентификация уязвимости Использование уязвимости Любитель 0 0 Специалист 2 2 Эксперт 5 4 Табл . 2.3. Условные баллы , присваиваемые уязвимости в зависимо сти от уровня знаний об объекте оценки , необходимого для ее идентифик ации и использования. Уровень Идентификация уязвимости Использование уязвимости Отсутствие знаний 0 0 Общедоступные знания 2 2 Конфиденциальные сведения 5 4 Табл . 2.4. Условные баллы , присваиваемые уязвимости в зависимо сти от времени доступа к объект у оценки , требуемого для ее идентификации и использования. Диапазон Идентификация уязвимости Использование уязвимости < 0.5 часа или доступ незаме тен 0 0 < суток 2 4 < месяца 3 6 > месяца 4 9 Табл . 2.5. Условные баллы , присваиваемые уязвимости в зав исимости от аппаратно-программных и ины х ресурсов (оборудования ), необходимых для е е идентификации и использования. Уровень Идентификация уязвимости Использование уязвимости Отсутствие оборудования 0 0 Стандартное оборудование 1 2 Специальное оборудова ние 3 4 Заказное оборудование 5 6 Если уязвимос ть можно идентифицировать и /или использова ть несколькими способами , для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное , то есть уязвимость характеризуется самым простым ме тодом успешного нападения . В табл . 2.6 приведены диапазоны рейтинга , которые характеризуют стойкость функции б езопасности . Табл . 2.6. Диапазон ы рейтинга , характеризующие стойкость функции безопасности. Диапазон Стойкость функции безопасност и 10 - 17 Ба зовая 18 - 24 Средняя > 24 Высокая Согласно "Обще й методологии ", потенциал нападения оценивается в общем и целом по той же сх еме , что и степень риска от наличия уязвимостей , с некоторыми очевидными отличия ми (например , из нескольких сценариев нападе ния выбирается худший , с наибольшим п отенциалом ). Считается , что он является функ цией уровня мотивации злоумышленника , его к валификации и имеющихся ресурсов . Мотивация влияет на выделяемое на атаки время и , возможно , на привлекаемые ресурсы и подбор нападающи х . В табл . 2.7 приведены диапазоны рейтинга , иллюстрирующие определенный потенциал нападен ия . Табл . 2.7. Диапазон ы рейтинга , характеризующие потенциал нападения. Диапазон Потенциал нападения < 10 Низкий 10 - 17 Умеренный 18 - 24 Высокий > 24 Нереальн о высокий Нападение мож ет быть успешным , только если его потен циал не меньше рейтинга уязвимости . Отсюда следует , в частности , что уязвимости с рейтингом выше 24 устойчивы к нападению с высоким потенциалом , поэтому их практическое испол ьзование злоумышлен никами представляется н ереальным . Отметим , что потенциал предполагаемых н ападений на ОО выявляется дважды : при а нализе задания по безопасности для выбора надлежащих мер противодействия и при анализе уязвимостей для определения достаточно сти выбранных мер и качества их реализации . Рассмотрим пример анализа стойкости фу нкции безопасности . Пусть доступ к информац ионной системе осуществляется посредством терр иториально разнесенных терминалов , работа за которыми не контролируется . Авторизованные п ользователи п роходят аутентификацию путем введения паролей , состоящих из четырех различных цифр . Если пароль введен невер но , терминал блокируется на одну минуту . Требуется оценить стойкость такой парольной защиты для заданного пользователя с и звестным нападающему вход н ым имене м . Для нападения выбран один терминал , временем ввода можно пренебречь . Очевидно , число возможных парольных пос ледовательностей составляет 10*9*8*7 = 5040 Для успешного подбора пароля методом полного перебора требуется примерно 2520 попыток , кот орые можно произвести за 42 часа , что больше суток , но меньше месяца . Никакой квалифик ации , знаний и /или оборудования для это го не нужно . Следовательно , чтобы определить стойкость функции , достаточно сложить два числа : 5 из табл . 2.1 и 6 из табл . 2.4. Сум м а 11 позволяет сделать вывод , чт о данная функция безопасности обладает баз овой стойкостью и является устойчивой к нападению с низким потенциалом . Возвращаясь к трем основным задачам процесса оценки , рассмотрим последнюю , выходн ую задачу . Ее цель - сформул ировать замечания и получить технич еский отчет оценки . Текст с замечаниями не является об язательным . Он нужен , если в процессе о ценки выявились какие-либо неясности или пр облемы . Технический отчет оценки - это главный выходной документ , от качества котор ого во многом зависит повторяемость и воспроизводимость результатов оценки , т . е . возможность их многократного использовани я . "Общая методология " предписывает следующую структуру подобных отчетов : ·1 введение ; ·2 архитектурн ое (высокоуровневое ) описание объекта оцен ки с рассмотрением основных компонентов ; ·3 описание процесса оценки , примененных методов , методол огий , инструментальных средств и стандартов ; ·4 представлен ие результатов оценки ; ·5 выводы и рекомендации ; ·6 список представленных свидетель ств ; ·7 список сокращений , словарь терминов ; ·8 список замечаний . Изучение "Обще й методологии " полезно не только оценщикам , но и разработчикам , так как дает представление о вопросах , которые могут воз никать в процессе оценки . К сожалению , более детально е рассмотрение этого док умента выходит за рамки настоящего курса . 3. «Общие критерии» , часть 2. Функциональные требования безопасности Детально рассматриваются семейства функциональных требований безопасности , представленные в " Общих критериях ". А нализируются достоинства и недостатки принятого в них подхода. Классификация ф ункциональных требований безопасности Часть 2 "Общих критериев ", пр едставляющая собой весьма обширную библиотеку функциональных требований безопасности , описывает 11 классов , 66 семейств , 135 компонентов и содержит сведения о том , какие цели безопасности могут быть достигнуты при современном уровне информационных технологий и каким образом . Аналогия между библиоте кой функциональных требований безопасности и библиотекой программн ых модулей является в данном случае дово льно полной . Функциональные компоненты могут быть не до конца конкретизированы , поэто му фактические параметры подставляются не в самих "Общих критериях ", а в определен ных профилях защиты , заданиях по безопаснос ти и ф ункциональных пакетах . (Прав да , в ГОСТ Р ИСО /МЭК 15408-2002 параметризация не очень удачно названа " назначением " .) В качестве па раметров могут выступать весьма сложные су щности , такие , например , как политика безопа сности (ПБ ). Некоторые функциональные ком поненты "Общих критериев " задаются "с запасом ", в них включается список возможностей , из к оторых затем с помощью соответствующей опе рации выбирается только то , что нужно в конкретно й ситуации . Пример - обнаружение и /или п редотвращение определенных нарушени й полит ики безопасности . На программистском языке подобный отбор называется частичным применение м . Разумеется , любой функциональный компонент допускает многократное использование (например , чтобы охватить разные аспекты объекта оценки ), называемое в ОК ит ерацией , а такж е уточнение и добавление дополнительных деталей (последнее можно считать еще одной формой частичного применения ). Между компонентами функциональных требован ий , как и между привычными библиотечными функциями , могут существовать зависимости . Они возникают , когда компонент не я вляется самодостаточным и для своей реализ ации нуждается в привлечении других компон ентов . Очевидно , размещая в ПЗ , ЗБ или ФП подобный компонент , нужно включить ту да и всю гроздь зависимостей (это похож е на разрешение вн е шних ссылок при формировании выполняемого модуля ). Классы функциональных требований "Общих критериев " можно разделить в зависимости от того , описывают ли они элементарные сервисы безопасности или производные , реализ уемые на основе элементарных , направлены ли они на достижение высокоуровневы х целей безопасности или играют инфраструк турную роль . К первой группе относятся следующие классы : 1 FAU - аудит безоп асности (описывает требования к сервису про токолирования /аудита ); 2 FIA - идентификация /аутентифика ция ; 3 FRU - использование ресурсов (прежде всего - обеспечение отказоуст ойчивости ). Классы второй группы : 1 FCO - связь (обслу живает неотказуемость отправителя /получателя ); 2 FPR - приватность ; Достичь высок оуровневых целей безопасности помогают два класса : 1 FDP - защита данн ых пользователя ; 2 FPT - защита функ ций безопасности объекта оценки . Наиболее мног очисленны классы , играющие инфраструктурную рол ь : 1 FCS - криптографическ ая поддержка (обслуживает управление криптограф ическими ключами и крип тографические о перации ); 2 FMT - управление безопасностью ; 3 FTA - доступ к объекту оценки (управление сеансами работы пользователей ); 4 FTP - доверенный маршрут /канал . Приведенная к лассификация содержит несколько примечательных моментов . Во-первых , фу нкциональные требован ия ОК довольно разнородны . Трудно объяснить , например , почему протоколированию /аудиту с оответствует собственный класс , а такой важ нейший , без преувеличения , классический сервис безопасности , как управление доступом , "спр ятан " среди др у гих требований з ащиты данных пользователя . Во-вторых , в ОК не выделены архитек турные требования . Правда , некоторые весьма важные архитектурные компоненты , в числе ко торых - посредничество при обращениях (частный случай невозможности обхода защитных средст в ) и разделение доменов , вошли в класс FPT (защита функций безопасности ). В-третьих , требования для защиты данных пользователя и функций безопасности объек та оценки разделены , хотя , очевидно , в о боих случаях необходимо применять сходные механизмы . Возможн о , такой подход объясн яется желанием выделить ядро безопасности и сохранить его компактность . Далее мы кратко рассмотрим все 11 кл ассов функциональных требований безопасности "О бщих критериев ". Классы функциональных требова ний , описывающие элементарные с ервисы б езопасности В этом разделе рассматрива ются три класса функциональных требований безопасности : 1 FAU - аудит безопасности ; 2 FIA - идентификация /аутентификация ; 3 FRU - использование ресурсов . Класс FAU состои т из шести семейств , содержащих треб ования к отбору , протоколированию (регис трации ), хранению и анализу данных о де йствиях и событиях , затрагивающих безопасность объекта оценки . Семейство FAU_GEN ( генерация данных аудита безо пасности ) включает два компон ента . Первый , FAU_GEN.1 (генерация да нных аудита ), специфицирует потенциально подвергаемые прото колированию и аудиту события , вводит поняти е уровня протоколирования (минимальный , базовый , детализированный , неопределенный ), определяет м инимум регистрационных данных о событии (да та , время , тип, результат события , а также идентификатор субъекта ). Второй , FAU_GEN.2 (ассо циация идентификатора пользователя ), предписывает ассоциировать каждое потенциально регистрируемое событие с идентификатором пользователя , ег о инициирующего . Семейство FAU_SEL ( вы бор событий аудита безопасности ) определяет требо вания к средствам отбора (включения или исключения ) событий из числа потенциально регистрируемых , которые будут реально проток олироваться и подвергаться аудиту в процес се функционирования объекта оценки . Отб ор может производиться на основе таких атрибутов , как идентификаторы объекта , пользо вателя , субъекта , узла сети ил тип собы тия . Предусматривается задание дополнительных а трибутов . Семейство FAU_STG ( хранение со бытий аудита безопасности ) со держит две пары компонентов . Первая , FAU_STG.1 (защищенное хранение журнала аудита ) и FAU_STG.2 (гарантии доступности данных аудита ), специфиц ирует защиту регистрационного журнала от н есанкционированного удаления , модификации , а так же от повреждения регистрационных данны х при его переполнении , сбое или атаке . Вторая пара , FAU_STG.3 (действия в сл учае возможной потери данных аудита ) и FAU_STG.4 (предотвращение потери данных аудита ), определ яет последовательность действий , если объем информации в регистрационном журнале пре в ышает заранее заданный порог . В их число входят игнорирование и свое временное запрещение протоколируемых событий , з апись поверх самых старых регистрационных данных и т.д . Семейство FAU_SAR ( просмотр ау дита безопасности ) предоставляет право на чтение (полн ое или в ыборочное , на основе критериев с логическим и отношениями ) регистрационного журнала уполном оченным пользователям и запрет на доступ к журналу для прочих пользователей . Семейство FAU_SAA ( анализ ауди та безопасности ) устанавливает требования к средст вам автоматического анализа функционирования объекта оценки , п озволяющим выявлять возможные нарушения безопа сности . Базовым компонентом семейства является FAU_SAA.1 (анализ потенциального нарушения ), регламенти рующий применение набора правил , основанных н а накоплении или объединении событий , сигнализирующих о вероятном нарушении безопасности . В рамках семейства этот компонент усилен по двум направлениям . В FAU_SAA.2 (выявление аномалий , опирающееся на профиль ) вводится понятия профиля поведения , рейтин га п о дозрительной активности для каждого пользователя , чьи действия отражены в профиле , а также порога , превышение которого указывает на ожидаемое нарушение политики безопасности . FAU_SAA.3 (простая эвристика атаки ) и FAU_SAA.4 (сложная эвристика атаки ) соде рж и т понятие сигнатуры атаки (р азной степени сложности ) и специфические фу нкции выявления сигнатур в реальном масшта бе времени . Шестое семейство класса FAU - FAU_ARP ( автоматическая реакция аудита безоп асности ) - определяет действия , которые необходимо предп ринять при выя влении возможных нарушений безопасности . Действ ия эти характеризуются как "наименее разруш ительные ". Можно сделать вывод , что в "Общих критериях " нашли отражение такие важные достижения относительно недавнего прошлого , как разработка и приме нение методов а ктивного аудита . Шесть семейств класса FIA (идентификация /а утентификация ) содержат требования к функциям установления и проверки подлинности заявленн ого идентификатора пользователя , а также св язывания атрибутов безопасности с уполномоченн ым пользователем . Семейство FIA_UID (идентификация пользователя ) вкл ючает два компонента и определяет набор действий (например , получение справочной инфо рмации ), которые разрешается выполнять до ид ентификации . Обычно применяют более сильный компонент FIA_UI D.2 - идентификация до любых действий , выполняемых пользователем при посредн ичестве функций безопасности . Семейство FIA_UAU (аутентификация пользователя ) ус троено сложнее . Оно специфицирует типы меха низмов аутентификации и используемые при э том атрибуты . Два первых компонента , FIA_UAU.1 (выбор момента аутентификации ) и FIA_UAU.2 (аутентифи кация до любых действий пользователя ), играю т (применительно к аутентификации ) ту же роль , что и компоненты семейства FIA_UID. На реализацию надежной аутентификации , уст о йчивой к сетевым угрозам , направлены компоненты FIA_UAU.3 ( аутентификация , защищенная от подделок ), FIA_UAU.4 ( механизмы одноразовой аутентифик ации ) и FIA_UAU.5 ( сочетание механизмов аутентификации ). После периода неактивности польз ователя и в ряде других ситуаций уместно применение компонента FIA_UAU.6 (повторная а утентификация ). Наконец , FIA_UAU.7 (аутентификация с защи щенной обратной связью ) указывает , как отобр ажать пароль при вводе . Семейство FIA_ATD ( определение атрибутов пользователя ) предус матривае т наличие у пользователей не только идентификаторов , но и других атри бутов безопасности , предписываемых политикой бе зопасности . Обычно после успешной идентификации и аутентификации от имени пользователя начи нает действовать некий процесс (субъект ). Се мейс тво FIA_USB ( связывание по льзователь-субъект ) содержит требо вания по ассоциированию атрибутов безопасности пользователя с этим субъектом . Выявлением и реагированием на неудачи аутентификации ведает семейство FIA_AFL ( отказы аутентификации ). Разумеется , и число допустимых неудачных попыток , и действия , выполняемые при превышении порога неудач , - все это параметры единственного компонента семейства . Обычно пользователь доказывает свою по длинность , сообщая нечто , что знает только он ( "секрет " в терминологии ОК ). Семейств о FIA_SOS (спецификация секретов ) вводит понятие м етрики качества секретов и содержит требов ания к средствам проверки качества и г енерации секретов заданного качества . Примеры подобных средств - проверка выполнения технич еских ограничений на п ользовательские пароли в ОС Unix и программные генераторы паролей . В целом класс FIA, по сравнению с FAU, менее конкретен , его компоненты слишком п араметризованы . Вероятно , это связано с тем , что криптография , без которой надежная и удобная для пользовате ля аутентиф икация невозможна , находится вне рамок "Общи х критериев ". Класс FRU (использование ресурсов ) включает три семейства , призванные разными способами поддерживать высокую доступность . Выполнение требований семейства FRU_FLT ( отказоустойчивость ) д о лжно обеспечить корректную работу все х или хотя бы некоторых функций объект а оценки даже в случае сбоев . FRU_PRS ( приоритет обслуживания ) регламентирует действия по защите высокоприоритетных операций от пре пятствий или задержек со стороны операций с более низким приоритетом . Семейство FRU_RSA ( распределение ресурсов ) для достижения высокой доступности ресурсов привлекает меха низм квот . Обращение к вопросу высокой доступност и - несомненное достоинство "Общих критериев ", которое , к сожалению , несколько про игры вает из-за отсутствия системного подхода . По неясным причинам в качестве сущностей одного уровня выделен один из трех высокоуровневых аспектов доступности и два механизма , способствующих ее поддержанию . За пределами рассмотрения остались над ежность и обслуживаемость , да и отказ оустойчивость может достигаться очень разными способами - от использования многопроцессорных конфигураций до организации резервных выч ислительных центров . Помимо двух рассмотренных механизмов п оддержания доступности существуют и други е , не менее важные , например , балансировка загрузки , проактивное управление и т.п . На наш взгляд , было бы целесообразным обо бщить требования к доступности регистрационног о журнала (см . выше семейство FAU_STG) на случ ай произвольных ресурсов . Отметим также , что включение в класс FRU конкретных механизмов еще резче обозначает излишнюю обобщенность требований кл асса FIA. Классы функциональных требова ний , описывающие производные сервисы безопаснос ти Мы приступаем к рассмотрен ию двух следующих классов фу нкциональн ых требований безопасности : 1 FCO - связь ; 2 FPR - приватность . Класс FCO состои т из двух семейств , FCO_NRO и FCO_NRR, ведающих неотказуемостью (невозможностью отказаться от факта отправки или получения данных ), которая достигается путем избир ательной или принудительно й генерации допускающих вер ификацию свидетельств , позволяющи х ассоциировать атрибуты отправителя (получател я ) с элементами передаваемых данных . Класс FPR ( приватность ) содержит четыре семейства фун кциональных требований , обеспечи вающих защи ту пользователя от раскрытия и несанкциони рованного использования его идентификационных данных . Семейство FPR_ANO ( анонимность ) дает возможность выполнения действий без идентификатора пользователя . Ан онимность может быть полной или выборочной . В первом случае функции безопасност и обязаны предоставить заданный набор услу г без запроса идентификатора пользователя . Во втором предусмотрено более слабое требо вание , в соответствии с которым идентификат ор может запрашиваться , но должен скрыватьс я от за р анее указанных пользов ателей и /или субъектов . Семейство FPR_PSE ( псевдонимность ) обеспечивает условия , когда пользователь может использовать ресурс ил и услугу без раскрытия своего идентификато ра , оставаясь в то же время подотчетным за свои действия . Базов ый компонен т семейства , FPR_PSE.1, предписывает выборочную анонимн ость , а также наличие средств генерации заданного числа псевдонимов и определения или приня тия псевдонима от пользователя с верификац ией соответствия некоторой метрике псевдонимов . Эти требо вания дополняются в комп оненте FPR_PSE.2 (обратимая псевдонимность ) возможностью определения доверенными субъектами идентификатор а пользователя по представленному псевдониму , а в компоненте FPR_PSE.3 (альтернативная псевдонимно сть ) - возможностью оператив н ого пер ехода на новый псевдоним , связь которого со старым проявляется лишь в заранее оговоренных ситуациях . Семейство FPR_UNL ( невозможность ассоциации ) содержит единств енный компонент , предусматривающий неоднократное применение пользователем информационн ых сервисов , не позволяя заданным субъектам ас социировать их между собой и приписывать одному лицу . Невозможность ассоциации защища ет от построения профилей поведения пользо вателей (см . выше компонент FAU_SAA.2). Самым сложным в классе FPR является с емейс тво FPR_UNO ( скрытность ). Его требования направлены на то , чтобы пользователь мог незаметно для кого бы то ни было работать с определенными информационными сервисами . Н аиболее интересны два из четырех имеющихся компонентов семейства . FPR_UNO.2 ( р аспределен ие информации , влияющее на скрытность ) предписывает рассредото чить соответствующие данные по различным ч астям объекта оценки . Это одно из немно гих архитектурных требований "Общих критериев " (правда , выраженное в очень общей форме ). В некотором смысле проти воположную роль играет компонент FPR_UNO.4 (открытость для уполномоченного пользователя ), согласно которому уполномоченные пользователи должны иметь воз можность наблюдать за тем , как употребляютс я заданные ресурсы и /или услуги . (Как сказал один пессимист : "Я так и знал , что этим все кончится !") Требования приватности ставят очень се рьезную проблему многоаспектнос ти информационной безопасности , заставляют искать баланс конфликтующих инте ресов субъектов информационных отношений . Разра ботчики заданий по безоп асности должны учесть и конкретизировать эти требования с учетом действующего законодательства и специфики систем ИТ . Защита данных пользователя Мы переходим к рассмотрени ю классов функциональных требований , направленн ых на достижение высокоуровневых целе й безопасности . К высокоуровневым целям безопасности о тносятся защита данных пользователя и защи та функций безопасности объекта оценки . Соо тветствующие классы функциональных требований характеризуются большим числом входящих в них семейств и разнородность ю компонен тов . Класс FDP (защита данных пользователя ) вклю чает тринадцать семейств , которые можно раз бить на четыре группы : 1 политики защиты данных пользователя ; 2 виды защиты данных пользователя ; 3 импорт и э кспорт данных пользователя ; 4 защита данн ых пользователя при передаче между доверенными изделиями ИТ . В первую группу входят два семейства - FDP_ACC (политика управления доступом ) и FDP_IFC (политика управле ния информационными потоками ), - играющие , по сути , формальную роль имено вания политик , р аспространяющихся на оп ределенные множества субъектов , объектов (потоко в ) и операций . Управление может быть ог раниченным и полным . В последнем случае требуется , чтобы все операции всех субъе ктов на любом объекте (потоке ) из облас ти действия функций безопа с ности были охвачены некоторой политикой . Вторая группа объединяет семь семейств . Содержательные аспекты управления доступом (информационными потоками ) регламентируются семей ствами FDP_ACF (функции управления доступом ) и FDP_IFF ( функции управления информа ционными потокам и ). Первое устроено очень просто , состоит из одного компонента и требует наличия политик , основанных на атрибутах безопасно сти , а также дополнительных правил , явно разрешающих или запрещающих доступ . Требования к функциям управления инфор м ационными потоками , представленные шестью компонентами , существенно сложнее и многоо бразнее . Компонент FDP_IFF.1 аналогичен FDP_ACF.1. Усиливающий его компонент FDP_IFF.2 требует поддержки многоуровнев ых политик , основанных на иерархических атрибутах (метк ах ) без опасности . FDP_IFF.3, FDP_IFF.4 и FDP_IFF.5 направлены , соответственно , на ограничение пропускной сп особности , частичное или полное устранение скрытых каналов . Наконец , FDP_IFF.6 требует осуществления монитор инга скрытых каналов , пропускная способно сть которых превышает заданный порог . Семейство FDP_DAU ( аутентификация данных ) обслуживает один из видов статической цел остности данных . В соответств ии с его требованиями функции безопасности должны предоставить возможность генерировать и верифицировать свидетельства правильно сти определенных объектов или типов информ ации (компонент FDP_DAU.1), а также (усиливающий комп онент FDP_DAU.2) идентификатора пользователя , создавшего свидетельство . Отметим , что компонент FDP_DAU.2 ведает неотказуемостью ав торства , а рассмотренный выше класс FCO - неотказуемостью отправки и получения данных , что можно считать разновидностью динамическ ой целостности . Семейство FDP_ITT (передача в пределах ОО ) содержит требования , связанные с защитой данных пользователя при их перед аче по внутренним каналам объекта оценки . Предусматривает ся базовая защита внутренней передачи (FDP_ITT.1), н аправленная на предотвращение раскрытия , модифи кация ситуаций недоступности , а также монит оринг целостности данных (FDP_ITT.3). При обнаружении оши бок целостности должны выполняться заданные действия . Эти требования усиливаютс я , соответственно , компонентами FDP_ITT.2 и FDP_ITT.4 за сч ет раздельной передачи данных , обладающих р азными атрибутам безопасности . Согласно требованиям семейства FDP_RIP ( защ ита остаточной информации ), унаследованным от "Оранжевой книги ", функции безопасности должны обеспеч ить уничтожение любого предыдущего содержания ресурсов при их выдаче и /или осво бождении . Семейство FDP_ROL ( откат ) предусма тривает возможность отмены после дней о перации и возврат к предшествующему состоя нию с сохранением целостности данных польз ователя . Последнее сем ейство второй группы , FDP_SDI (целостность хранимых данных ), содержит требования мониторинга цело стности всех контролируемых объектов и вып олне ния заданных действий при обнаруже нии ошибок целостности хранимых данных . В третью группу семейств класса FDP, о бслуживающую импорт и экспорт данных польз ователя в /за пределы области действия функций безопасности объекта оценки , мы вкл ючили , как и следова ло ожидать , два сходных по структуре двухкомпонентных сем ейства : FDP_ETC (экспорт ) и FDP_ITC (импорт ). Они различают ся по наличию или отсутствию (использованию или игнорированию ) ассоциированных с данны ми атрибутов безопасности . Согласованная интерп ретаци я атрибутов оговорена экспортер ом и импортером . В последнюю , четвертую группу (защита данных пользователя при передаче между доверенными изделиями ИТ ) входят два семейс тва , ведающих обеспечением конфиденциальности (FDP_UCT) и целостности (FDP_UIT). Имеется в виду , чт о одним из доверенных изделий является объект оценки , а для передачи используют ся внешние (по отношению к ОО ) к аналы . FDP_UCT состоит из одного компонента , треб ующего защиты от несанкционированного раскрыти я . В семейство FDP_UIT включены более сод ержательные требования . Во-первых , предусматривается всеобъемлющая защита от модификации , удале ния , вставки и повторения данных . Во-вторых , обнаруженная ошибка целостности может быт ь восстановлена как с помощью отправителя , доверенного изделия ИТ , так и силами самого объекта оценки . Обратим внимание на различие требовани й к защите данных пользователя при пер едаче по внутреннему (семейство FDP_ITT) и внешнем у (семейства FDP_UCT и FDP_UIT) каналам , что можно с читать проявлением гибкости "Общих критериев " . Для внешних каналов требования зада ны более детально (особенно это касается целостности ), однако не предусматривается обе спечение высокой доступности данных . Отметим также , что за различные асп екты целостности данных пользователя отвечают пять семейств : FDP_DAU, FDP_ITT (точнее , компонент FDP_ITT.3), FDP_ROL, FDP_SDI и FDP_UIT. Первое контролирует аутентичность избранных наборов данных , компонент FDP_ITT.3 и семейство FDP_UIT отвечают за (динамическую ) целостнос ть передаваемых данных , FDP_ROL - за восст а новление целостности после сбоев или ошибок , а FDP_SDI предусматривает тотальный монито ринг статической целостности . На практике эти варианты целостности контролируются и восстанавливаются разными м етодами (например , для выполнения требований FDP_DAU есте ственно воспользоваться криптографичес кими хэш-функциями или цифровой подписью , дл я FDP_SDI - обычными контрольными суммами ), поэтому разнесение требований , относящихся к одному аспекту ИБ , представляется в данном сл учае оправданным , хотя , на наш взгляд , п редпочтительнее было бы ограничит ься уровнем компонентов , а не семейств . Примером могут служить рассмотренные выше компоненты FAU_SAA.2 и FAU_SAA.4, обслуживающие различные мето ды выявления подозрительной активности . Защита функций безопасности объекта оц енки Мы продолжаем рассмотрение классов функциональных требований , направленных на достижение высокоуровневых целей безоп асности . Класс FPT (защита функций безопасности объ екта оценки ) включает шестнадцать семейств ( больше , чем какой-либо другой класс фун кциональных требований ), которые можно р азбить на четыре группы : 1 архитектурная безопасность ; 2 защита реализац ии функций безопасности ; 3 защита данных функций безопасности ; 4 инфраструктурные требования . Важнейший при нцип архитектурной безопасности - невозможность обхода защитных средс тв . Семейство FPT_RVM ( посредничество при обращениях ) предназначено для достижения этой ц ели . Входящий в него единственный компонент FPT_RVM.1 (невозможность обхода политики безопасности ОО ) предписывает , чтобы функции , прово дящие в жизнь политику безопасности , вызыва лись и успешно выполнялись прежде любого другого действия , предусмотренного ПБ . Еще один фундаментальный принцип архит ектурной безопасности поддерживается семейством FPT_SEP ( разделение доменов ). Минимальн о необходимо отделе ние домена функций безопасности (компонент FPT_SEP.1), то есть функции безопасности должны под держивать домен безопасности , который защищает их от вмешательства не облеченных дов ерием субъектов и искажений с их сторо ны (кроме того , долж н о быть реализовано разделение доменов безопасности субъектов ). Максимальный уровень потребует реали зации полного монитора обращений (компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности , которая проводит в жизнь по л итики у правления доступом и /или информационными п отоками . Защитой реализации функций безопасности занимаются четыре семейства . Самое простое из них (по формулировке , но не по воплощению и /или проверке ), FPT_FLS ( безопасность при сбое ), содержит требование , чтобы политик а безопасности не нарушалась при сбоях заданных типов . Обеспечения высокой доступности и корр ектной работы функций безопасности вопреки возможным сбоям добивается и более слож ное семейство FPT_RCV ( надежное во сстановление ). FPT_RCV.4 (восст ановлен ие функции ) предписывает , что функция безопа сности либо нормально завершается , либо , для предусмотренных сценариев сбоев , восстанавлива ется ее устойчивое и безопасное состояние . Первые три его компонента отвечают за восстановление - ручное , автомат и че ское и автоматическое без недопустимой пот ери . Для ручного восстановления требуется , ч тобы после сбоя функции безопасности переш ли в режим аварийной поддержки , оставляющег о возможность возврата ОО к безопасному состоянию . Автоматическое восстановление б е з недопустимой потери означает следующее : 1 при сбоях з аданных типов возврат к безопасному состоя нию обеспечивается автоматическими процедурами ; 2 безопасное сост ояние восстанавливается без превышения заранее определенной меры потери данных ; 3 функции б езопасности помогают выяснить , какие об ъекты могут быть восстановлены , а какие нет . Семейств o FPT_PHP ( физическая защита ) требует наличия средств выявления и реагирования на несанкционированный физически й доступ к частям ОО , участвующим в реализации функц ий безопасности . Компоне нт FPT_PHP.1 (пассивное обнаружение физического нападен ия ) можно отнести к средствам контроля целостности , так как он требует однозначног о обнаружения физического воздействия , которое может угрожать выполнению функций безопас ности ; информация о наличии или отсутствии подобного воздействия предоставляется по запросу . Усиливающий компонент FPT_PHP.2 (опове щение о физическом нападении ) предусматривает постоянный контроль за определенными элемент ами и оповещение назначенного пользовател я о подобных происшествиях . Након ец , компонент FPT_PHP.3 (противодействие физическому на падению ) требует автоматической реакции , предотв ращающей нарушение политики безопасности . Семейство FPT_TST ( самотестировани е функций безопасности ) состо ит из одного ко мпонента , но служит сразу двум целям : выполняет собственно самотестирование (при запуске , периодически , п о запросу уполномоченного пользователя и т. п .), а также осуществляет контроль целостнос ти данных и выполняемого кода функций . Объединение в одном комп оненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и , тем более , изменяемых данных ), но п озволяет плавно перейти к третьей группе семейств класса FPT (защита данных функций б езопасности ). В эту группу вхо дят шесть семейств , три из которых , FPT_ITA, FPT_ITC и FPT_ITI, отвечают , соответственно , за доступност ь , конфиденциальность и целостность экспортируе мых данных функций безопасности . Отметим , чт о доступность должна быть обесп е чена с заданной вероятностью , а кон троль целостности в общем случае предусмат ривает возможность восстановления поврежденных данных удаленным доверенным изделием ИТ . Семейство FPT_TDC содержит требование согласован ной интерпретации данных , совместно исполь зуемых функциями безопасности ОО и другим доверенным изделием ИТ . Явных тре бований к контролю импортируемых данных в классе FPT (в отличие от FDP) нет , хотя и з соображений симметрии они , безусловно , дол жны присутствовать (см . выше семейства FDP_ETC и FDP_ I TC). Пятое семейство группы , FPT_ITT (передача данн ых функций безопасности в пределах объекта оценки ), аналогично рассмотренному ранее се мейству из класса защиты данных пользовате ля FDP_ITT (передача в пределах ОО ), но не предусматривает обеспечения досту пности и разделения по атрибутам при контроле целостности . Справедливости ради укажем , одна ко , что в компоненте FPT_ITT.3 более детально специфицированы обнаруживаемые виды нарушений целостности : модификация , подмена , перестановка , удаление данных . Семейс тво FPT_TRC отвечает за согласованность данных функций безо пасности при дублировании в пределах ОО . Здесь следует обратить вн имание на требования элемента FPT_TRC.1.2: если част и ОО , содержащие дублируемые данные , были разъединены , необходимо обеспечить со гла сованность таких данных после восстановления соединения перед обработкой запросов к заданным функциям безопасности . Отметим , что к взаимодействию с удаленным доверенным изделием ИТ требование согласованности данных не предъявляется . В целом же остается неясным смысл разнесения по ра зным классам требований защиты данных поль зователя и функций безопасности . Последние , кроме того , трактуются как одноуровневые , дл я них не предусмотрено разделение по а трибутам , что для сложных систем может оказаться неприемл е мым . Требования , которые мы назвали инфрастр уктурными , вошли в состав четырех семейств . Семейство FPT_AMT (тестирование базовой абстрактной машины ) о пределяет требования к тестированию , демонстрир ующему правильность предположений , обеспечиваемых абстрактн ой машиной (аппаратно-программной платформой ), лежащей в основе функций без опасности . Семейство FPT_RPL ( обнаружение повторного использования ) наце лено на выявление повторного использования сущностей различных типов (например , сообщени й , запросов на обслу живание и ответ ов на запросы ) и выполнение заданных от ветных действий . Семейство FPT_SSP (протокол си нхронизации состояний ) на сам ом деле содержит требования одностороннего или взаимного надежного подтверждения при обмене данными между функциями безопасно сти в распределенной среде . Наконец , семейство FPT_STM (метки времени ) тре бует предоставления надежных меток времени в пределах объекта оценки . Подобные метки необходимы , например , функциям протоколирования и упра вления . Классы функциональных требова ний, играющие инфраструктурную роль Криптографические механизмы - о бязательный элемент защищенных систем . Класс FCS ( криптографическая поддержка ) состоит из 2 семейств , где в самом общем виде (точнее , в виде параметризованных шаблонов ) рассматриваются генераци я , распределение , доступ и уничтожение ключей , а также крипт ографические операции . Смысл требований состоит в том , что необходимо действовать в соответствии с некими алг оритмами , длинами ключей и стандартами ; каки е-либо содержательные спецификации отсутств уют . Класс FMT ( управление безоп асностью ), включающий шесть се мейств , регламентирует управление функциями без опасности и их данными , атрибутами и ро лями безопасности . Семейство FMT_MOF (управление отдельными функциям и ) содержит единственное требование : т ол ько уполномоченные пользователи (точнее , уполном оченные идентифицированные роли ) могут управлят ь режимами выполнения , подключением и отклю чением функций безопасности . К управлению атрибутами безопасности (с емейство FMT_MSA) предъявляется больше требован ий . Во-первых , оно должно быть доступно то лько определенным ролям . Во-вторых , необходимо контролировать безопасность присваиваемых значен ий . В-третьих , при создании объектов должна существовать возможность задания значений , отличных от подразумеваемых . Ан алогичным образом устроено семей ство FMT_MTD (управление данными функций безопасности ), только вместо переопределения подразумеваемых значений в компоненте FMT_MTD.2 специфицируются г раничные значения и действия , предпринимаемые в случае выхода за допусти м ые границы . FMT_REV (отмена ) предусматривает возможность от мены (отзыва ) атрибутов безопасности пользовател ей , субъектов и объектов . FMT_SAE позволяет устанавливать сроки действия атрибутов безопасности . Для каждого атрибута могут задаваться действия , вы полняемые по истечении срока . Наконец , семейство FMT_SMR ( ро ли управления безопасностью ) предназначено для управления назначением разли чных ролей пользователям . Предусмотрено наличие правил , управляющих отношениями между роля ми . Шесть семейств простой ст руктуры содержит и класс FTA (доступ к объекту оценки ), куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации ). Семейство FTA_LSA определяет требования по о граничению атрибутов безопасности сеанса , котор ые м ожет выбирать пользователь . Семейство FTA_MCS ограничивает количество параллельных сеансов , предоставляемых пользователю . Оно может быть как общим , так и индивидуальным (с учетом атрибутов безопасности ). Семейство FTA_SSL ( блокирование сеанса ) определяет возмож ность блокирования или завершения интерактивно го сеанса как по инициативе пользователя , так и по инициативе функций безопасност и (если пользователь неактивен заданное вре мя ). Действия , осуществляемые при блокировании , описаны весьма детально : 1 очи стка или перезапись устройств отображения , придан ие их текущему содержанию нечитаемого вида ; 2 блокирование лю бых действий по доступу к данным польз ователя и устройствам отображения , кроме не обходимых для разблокирования сеанса . Еще три о днокомпонентных семейства содержат некоторые подробности открытия сеанса . Семейство FTA_TAB (предупреждения перед предостав лением доступа к ОО ) предписывает , чтобы перед открытием сеанса отображалось предупре ждающее сообщение относительно несанкционированного использован ия объекта оценки . Это одно из весьма немногих функциональных тре бований без управляющих конструкций назначения или выбора . Семейство FTA_TAH ( история дос тупа к ОО ) при успешном открытии сеанса определяет требования к отображению истории попыток получить д оступ от имени пользователя , выполняющего в ход в систему . Здесь проявлена просто-таки трогательная забота о пользователе : оговар ивается , что справочная информация не должн а исчезать с экрана до того , как п ользователь успеет ее просмотреть . Кроме того , фу нкции безопасности могут отказать пользователю в открытии сеанса , основываясь на атрибутах безопасности , такая возможность с обманчивым названием "Открытие сеанса с ОО " предусмотрена семе йством FTA_TSE. Если сопоставить степень детализации т ребований к кр иптографической поддержке и к управлению сеансами , то различие представляется слишком большим . Впрочем , выде ржать единый уровень в столь большом и сложном документе , как "Общие критерии ", едва ли возможно . Привычные , традиционные т ребования предъявляет кл а сс FTP ( доверенный маршрут /канал ), состоящий из двух семейств , содержащих по одному компоненту в каждом . Доверенный маршрут (семейство FTP_TRP) позволяет вы полнять определенные действия в режиме пря мого взаимодействия с функциями безопасности (например , пр и начальной аутентификации ). Доверенные каналы (семейство FTP_ITC) предназначены для передачи критичных по безопасности данных между функциями безопасности с друг ими доверенными изделиями ИТ . Доверенный ма ршрут /канал должен быть логически отличим от други х маршрутов (каналов ), обеспечивать уверенную идентификацию взаимодейс твующих сторон , а также конфиденциальность и целостность передаваемых данных . На этом мы завершаем рассмотрение функциональных требо ваний безопасности. 4. «Общие критерии» , часть 3. Тр ебования доверия безопасности Детально рассматриваются семейства требова ний и оценочные уровни доверия безопасност и , представленные в "Общих критериях ". Анализ ируются достоинства и недостатки принятого в них подхода Основные понятия и классификация тре бований доверия безопасности Требования доверия безопаснос ти составляют содержание тре тьей части "Общих критериев ". Доверие в трактовке "Общих критериев " - это основа для уверенности в том , что изделие И Т отвечает целям безопасности . Доверие обес печиваетс я через активное исследование (оценку ) изделия ИТ . Требования доверия безопасности охватывают весь жизненный цикл изделий ИТ и предполагают выполнение следующих действий : 1 оцениваются зад ания по безопасности (ЗБ ) и профили защ иты (ПЗ ), ставшие источника ми требований безопасности ; 2 анализируются р азличные представления проекта объекта оценки и соответствие между ними , а также соответствие каждого из них требованиям безопасности ; 3 проверяются про цессы и процедуры безопасности , их применен ие ; 4 анализи рует ся документация ; 5 верифицируются представленные доказательства ; 6 анализируются т есты и их результаты ; 7 анализируются у язвимости объекта оценки ; 8 проводится неза висимое тестирование , в том числе тестовые "взломы " (называемые далее тестированием проникновения ). Каждое требов ание (элемент ) доверия принадлежит одному из трех типов : 1 элементы действ ий разработчика (помечаются буквой "D" после номера эле мента ); эти действия должны подтверждаться д оказательным материалом ( свидете льствами ); 2 элемен ты представления и содержания свидетельств (пом ечаются буквой "C"); 3 элементы действ ий оценщика (помечаются буквой "E"); оценщики обязаны проверить представленные разработчиками свидетел ьства , а также выполнить необходимые дополн ительные действия (наприм ер , провести не зависимое тестирование ). Требования до верия разделены на 10 классов , 44 семейств и 93 компонента . Классы можно сгруппировать в зависимости от охватываемых этапов жизненног о цикла изделий ИТ . К первой группе , логически предшествующ ей разраб отке и оценке ОО , принадле жат классы APE (оценка профиля защиты ) и ASE ( оценка задания по безопасности ). Во вторую группу входят классы ADV (ра зработка ), ALC (поддержка жизненного цикла ) и ACM (у правление конфигурацией ). К этапу получения , представления и анализа результатов разработки можно отн ести классы AGD (руководства ), ATE (тестирование ) и AVA (оценка уязвимостей ). Требования к поставке и эксплуатации составляют содержание класса ADO. Наконец , класс AMA (поддержка доверия ) вклю чает требования , при меняемые после серт ификации объекта оценки на соответствие "Об щим критериям ". По сравнению с функциональными , требова ния доверия устроены несколько проще . Во-пер вых , к их элементам не применяются опер ации назначения и выбора . Во-вторых , компоне нты в преде лах семейства линейно у порядочены , то есть компонент с большим номером всегда усиливает предыдущий . Одна из целей "Общих критериев " сос тоит в минимизации усилий разработчиков и оценщиков , направленных на обеспечение зад анного уровня доверия . Этому способс тву ет введение семи оценочных уровней доверия (ОУД ), со держащих полезные для практического применения комбинации компонентов , упорядоченные по с тепени усиления . Повысить уровень доверия п омогут дополнительные действия : 1 расширение гран иц объекта оценки ; 2 увеличение уров ня детализации рассматриваемых аспектов ОО ; 3 повышение строг ости рассмотрения , применение более формальных методов верификации . Далее мы кратко рассмотрим семейства требований и о ценочные уровни доверия безопасности . Оценка профилей з ащи ты и заданий по безопасности Цель требований , вошедших в классы APE (оценка профиля защиты ) и ASE (оценка задания по безопасности ), - проверить полноту , непротиворечивост ь и реализуемость ПЗ или ЗБ . Класс APE состоит из шести однокомпонентн ых семейств, соответствующих предписанной структуре профилей защиты . Семейство APE_INT (введение ПЗ ) требует от разработчика представить введение как часть ПЗ , содержащую данные идентификации и аннотацию ПЗ . Оценщик должен подтвердить , чт о имеющаяся информация удовле творяет в сем требованиям к содержанию и представлен ию свидетельств , что введение является логи чески последовательным и внутренне непротиворе чивым и согласуется с другими частями ПЗ . Перечисленные требования к действиям оц енщика носят стандартный характер и далее упоминаться не будут . Семейство APE_DES (описание ОО ) специфицирует , что описание объекта оценки должно включат ь в себя , как минимум , тип продукта и его общую характеристику . Требования семейства APE_ENV ( среда безопасности ) более сод ержательны . Н еобходимо идентифицировать и объяснить все допущения о предполагаемом применении ОО и среде использования , все угрозы , от которых нужна защита , и все политики безопасности , обязательные для исполнения . Еще содержательнее требования семейства APE_OBJ ( цели безопасности ). Разработчик должен не только сформулировать цели безопасности для объе кта оценки и его среды , но и предс тавить их логическое обоснование , продемонстрир овав противостояние всем идентифицированным уг розам , охват всех установленных положений п олитик безопасности и предположений бе зопасности . Основное содержание профиля защиты сос тавляют требования безопасности . К этой час ти применимы семейства APE_REQ ( тр ебования безопасности ИТ ) и APE_SRE (требования безопасности ИТ , сформулированные в явном виде ). Первое относится к стандартным требованиям "Общих критериев ", второе - к расширениям ОК , введенным разрабо тчиком ПЗ . Логическое обоснование требований безопасности должно демонстрировать их решаю щую роль в достижении целей безопасности . Класс ASE у строен аналогично классу APE, некоторые отличия вызваны большей конкретн остью задания по безопасности в сравнении с профилем защиты и наличием дополнит ельных разделов . Модифицированы требования шест и рассмотренных выше семейств и добавлены два новых . Семе йство ASE_TSS ( краткая спецификация ОО ) определяет в самом общем виде функции безопасности и меры доверия , предназначенные , соответственно , для выпо лнения функциональных требований и требований доверия . Функции безопасности и функциональные требования соп оставляют таким образом , чтобы можно было понять , какие из них обслуживают отдельно взятое требование и , наоборот , для выполнения каких требований предназначена каждая из функций . Логическо е обоснование краткой спецификации ОО долж но демонстрировать , что с пецифицирова нные функции пригодны для удовлетворения ф ункциональных требований . Функции , реализованные вероятностными или перестановочными механизмами , нуждаютс я в определении требований к стойкости . Если задание по безопасности является конкретизацией не которых ПЗ , к нем у применяются требования семейства ASE_PPC (утвержден ия о соответствии профилям защиты ). Подчеркнем важность тщательной разработки и оценки профилей защиты и заданий по безопасности . Просчеты на стадиях выр аботки требований и спецификаций изделий ИТ чреваты особо тяжелыми последствиями , исправлять которые сложно и дорого . Требования доверия к эта пу разработки Функциональные требования , поли тика безопасности и краткая спецификация о бъекта оценки служат отправным пунктом про цесса разработки функций безопасности ОО . Класс ADV (разработка ) состоит из семи мн огокомпонентных семейств и содержит требования для постепенного повышения уровня детализ ации проекта вплоть до представления реали зации с демонстрацией соотв етствия между уровнями . В этом классе предусмотрены три стиля изложения спецификаций : неформальный , полуформальный и формальный - и три спосо ба демонстрации соответствия .] Неформальная спецификация пишется как обычный текст с определением необходимых терминов . Неформа льная демонстрация соответствия требует у становления "соответствия по сути ". Полуформальная спецификация создается при помощи языка с ограниченным синтаксисом и , как прав ило , сопровождается пояснительным текстом . Полуф ормальная демонстрация соответствия невозможна без стру ктурированного подхода . В формальной спецификац ии используется математическая нотация , а методом демонстрации соответствия служит формальное доказательство . Ранжирование компонентов в семействах класса ADV в основном соответствует стилю изл ожения специфи каций , ужесточаясь от неф ормального к формальному . В классе ADV выделены четыре уровня д етализации проекта : функциональн ая спецификация , проект верхнего уровня , проект нижнего уровня , представление реализации . Поскольку в конкр етной разработке некоторые и з них могут отсутствовать , предусмотрена независимая демонстрация соответствия каждого функциональным требованиям . Требования к функциональной спецификации , сосредоточенные в семействе ADV_FSP, указывают на обязательность включения в функциональную специф икацию описания назначения и методов использования всех внешних интерфейсов функций безопасности объекта оценки с добавлением , где это необходимо , детализации результатов , нештатных ситуаций и сообщени й об ошибках . Из описания должно быть понятно , как учт е ны функционал ьные требования и каким образом строить тесты соответствия . Требования семейства ADV_SPM (моделирование полит ики безопасности ) охватывают еще один аспек т функциональной спецификации - соответствие пол итике безопасности объекта оценки , возможн ости ее осуществления . Средством демонс трации соответствия служит модель политики безопасности : необходимо показать , что все функции безопасности в функциональной специф икации непротиворечивы и их полнота адеква тна модели . Семейство ADV_HLD содержит треб ования к проекту верхнего уровня , описывающего стру ктуру функций безопасности ОО в терминах подсистем . Проект должен идентифицировать все необходимые базовые аппаратные , программно-аппаратные и /или программные средства с представлением функций , обеспечивае мых поддержкой реали зуемых этими средствами механизмов защиты , а также все интерфейсы подсистем , выделяя те из них , которые предполагаются види мыми извне . Каждый интерфейс необходимо сна бдить описанием назначения и методов испол ьзования (то же касается и ф у нкциональных спецификаций - это означает демонст рацию соответствия функциональным требованиям и позволяет организовать тестирование .) Следует выделить подсистемы , осуществляющие политику безопасности . Наконец , проект верхнего уровня должен содержать обос н ование того , что выбранные механизмы достаточны дл я реализации функций безопасности . Требования к проекту нижнего уровня образуют семейство ADV_LLD, в котором детализация доходит до уровня моду ля . Специфицируются все интер фейсы модулей (с выделением видим ых извне ), реализующих функции безопасности . Обяз ательное условие - описание разделения на мо дули , выполняющие политику безопасности , и п рочие , а также предоставление осуществляющих эту политику функций . Взаимосвязи между модулями следует определять в тер м инах имеющихся функциональных возможностей безопасности и зависимостей от других модулей . Проект нижнего уровня должен со держать описание назначения и методов испо льзования всех интерфейсов модулей , а при необходимости - возможность создания детального от ч ета о результатах , нештатны х ситуациях и отправки уведомлений об ошибках . Очень важно , чтобы представление реализ ации (семейство ADV_IMP) однозначно определяло функции безопасности объекта оценки на высоком уровне детализации , тогда впоследствии их возмож но создать без дальнейших про ектных решений . Представление реализации должно быть структурировано в малые и понятн ые разделы , включать в себя описание св язей между всеми частями реализации . Семейство ADV_RCR ведает соответствием всех имеющихся смежных уро вней представления функций безопасности . Надо доказать , что все функциональные возможности более абстрактн ого представления , относящиеся к безопасности , правильно и полностью уточнены на менее абстрактном уровне . Требования семейства ADV_INT (внутренняя с труктура функций безопасности ОО ) носят технологический характер и сходны по смыслу с требованиями структурированного прогр аммирования . Основная идея состоит в миними зации сложности процесса и результата разр аботки путем разбиения на модули и исп ользовани я нескольких уровней абстракции . Здесь придется впервые сформулировать требования к действиям разработчика (до этого мы ограничивались требованиями к представлению и содержанию свидетельств ). Разработчик должен проектировать и стр уктурировать функции безоп асности объекта оценки в модульном , многоуровневом виде , облегчая связи между модулями , а также между уровнями проекта , уменьшая общую сложность , в особенности тех частей , кото рые отвечают за политику безопасности , чтоб ы они были простыми для анализа . Раз работчик обязан представить опи сание архитектуры с изложением назначения , интерфейсов , параметров и результатов применени я каждого модуля и выделением частей , о существляющих политику безопасности , с разбиени ем на уровни и демонстрацией того , что сложность минимизирована . На наш взгляд , подобные архитектурные требования крайне важны , они заслуживают развития и вынесения в отдельный клас с . Есть еще целый ряд других архитектур ных принципов , специфичных для информационной безопасности (например , эшелонированно сть обороны , разнообразие защитных средств ), котор ые , к сожалению , остались за рамками "Об щих критериев ". Технологические требования процедурного ха рактера составляют содержание класса ALC (поддержк а жизненного цикла ), состоящего из четырех семейств . Пре жде всего определяется модель жизненного цикла (семейство ALC_LCD), описывающая процессы разработки и сопровождения ОО , включая д етализацию количественных параметров и /или метрик , используемых для оценки соответствия процесса разработки и принятой модели . Затем следует обосновать выбор инструм ентальных средств и методов (семейство ALC_TAT). Э то относится , в частности , к используемым языкам программирования , средствам подготовки документации , стандартам реализации и т.п . Безопасность разработки организуетс я в соответствии с требованиями семейства ALC_DVS. Разработчик до лжен не только иметь описание и обосно вание всех физических , относящихся к персон алу и иных мер безопасности , которые не обходимы для обеспечения конфиденциальности и целостности проекта ОО и его реализации , но и соблюдать эти меры во время создания и сопровождения ОО , что проверяется оценщиками . Важным элементом этапа сопровождения я вляется устранение недостатков (семейство ALC_FLR). Процедуры отсле живания и устранения недостатков фиксируются разработчиком . Они должны содержать требование представления описания природы и проявлений каждого недостатка безопасности , а также статуса завершения исправления это го недостатка . Разработчик устанавливает процед уру приема и отработки сообщений о нед ост а тках , запросов на их исправ ление с указанием контактных адресов и автоматическим распространением сообщений о недостатках и их исправлении зарегистрированны м пользователям . Все ставшие известными нед остатки безопасности должны быть исправлены (без создани я новых ), а исправле ния изданы . Управление конфигурацией (УК , класс ACM) - необходимый инстру мент коллектива разработчиков . В этот класс входят три семейства , самое содержательное из которых - ACM_CAP, специфицирующее возможности УК . Кроме выполнения очеви дных требован ий уникальной идентификации (маркировки ) объекта оценки , его версий и элементов (с выделением частей , относящихся к функциям б езопасности ), необходимо предусмотреть меры защи ты от несанкционированных изменений и меры поддержки генерации ОО . Л юбопытно применение принципа разделения обязанностей : требуется , чтобы лицо , ответственн ое за включение элемента в УК , не являлось его разработчиком . Семейство ACM_SCP специфицирует область действия управления конфигурацией . Она включает пре дставление реа лизации объекта оценки , п роектную и тестовую документацию , документацию пользователя и администратора , документацию УК , информацию о недостатках безопасности и инструментальные средства разработки . Для уменьшения числа возможных ошибок управление конфигур ацией следует макс имально автоматизировать - в этом смысл треб ований семейства ACM_AUT. Автоматизация должна распро страняться на защиту от несанкционированных изменений , генерацию объекта оценки , выявлени е различий между версиями и на нахожде ние элементов, подвергающихся воздействию определенной модификации . В целом требования доверия к этапу разработки сформулированы на высоком уров не , в соответствии с современной технологие й создания и сопровождения сложных систем . Требования к этапу получ ения , представ ления и анализа результат ов разработки Мы переходим к рассмотрени ю трех следующих классов требований довери я безопасности : AGD ( руководства ), ATE ( тестирование ) и AVA ( оценк а уязвимостей ). Класс AGD состоит из двух однокомпонентны х семейств , где сформулир ованы требован ия к руководствам администратора (AGD_ADM) и польз ователя (AGD_USR). Руководство администратора должно содержат ь : 1 описание особен ностей управления ОО безопасным способом ; 2 описание функци й и интерфейсов администрирования ; 3 предупрежде ния относительно функций и привилегий , подл ежащие контролю ; 4 описание всех предположений о поведении пользователя , кото рые связаны с безопасной эксплуатацией ОО ; 5 описание всех параметров безопасности , контролируемых администр атором , с указанием безопа сных значений ; 6 описание событи й , относящихся к безопасности ; 7 описание всех требований безопасности к среде ИТ , имею щих отношение к администратору . В руководство пользователя необходимо включить : 1 описание функци й и интерфейсов объекта оценки , дост упных пользователям ; 2 описание примен ения доступных пользователям функций безопасно сти ; 3 предупреждения относительно доступных пользователям функций и привилегий , которые следует контролировать ; 4 изложение всех обязанностей пользователя по безопасной эксплуатации ОО . Класс ATE (тестир ование ) состоит из четырех семейств , содержа щих требования к полноте , глубине , способам и результатам тестирования функций безопа сности на предмет их соответствия специфик ациям . Разработчик выполняет ф ункциональное тест ирование (семейство ATE_FUN), обосновывает достаточность глубины (семейство ATE_DPT) и покрытия (ATE_COV) тестов . При функциональном тестировании необходимо проверить все функции безопасности , не ограничиваясь подтверждением наличия требуемых функций безо пасности , но проверяя также , отсутствуют ли нежелательные режимы функционирования . Анализ глубины должен показать достаточность тестов для демонстрации того , что функции безоп асности выполняются в соответствии с проек тами верхнего и нижнего уровней и пред ставлением реализации . Важно , чтобы анализ покрытия демонстрировал полное соответствие между представленными тестами и описанием функций безопасности в функцион альной спецификации . Требуется полностью провер ить все внешние интерфейсы функций безопас ности. Семейство ATE_IND ( независимое тестирование ) регламентирует д ействия оценщиков . Оценщику следует протестиров ать необходимое подмножество функций безопасно сти и подтвердить , что объект оценки фу нкционирует в соответствии со спецификациями , а также выполни ть некоторые или все тесты из тестовой документации , чтоб ы верифицировать результаты , полученные разрабо тчиком . Один из ключевых моментов оценки б езопасности изделия ИТ - оце нка уязвимостей (класс AVA), отпр авным пунктом которой является анализ уязвимосте й (семейство AVA_VLA), выполняемый разработчиком и оце нщиком . Четыре компонента этого семейства р анжированы по уровню строгости анализа и потенциалу предполагаемого нарушителя . Анализ , проводимый разработчиком , направлен на поиск и идентификацию уязвимост ей , обоснование невозможности их исполь зования в предполагаемой среде и стойкости объекта оценки к явным нападениям . Прежде всего оценщик обязан проверить , что ОО противостоит нападениям нарушителя , соответственно , с низким (AVA_VLA.2), умеренным (AVA_VLA .3) или высоким (AVA_VLA.4) потенциалом . Для дос тижения этой цели в общем случае прово дится независимый анализ уязвимостей , а зат ем оцениваются возможности использования идент ифицированных разработчиком и дополнительно вы явленных уязвимостей , посредством п ро ведения тестовых атак . Анализ стойкости функций безопасности объекта оценки ( семейство AVA_SOF) проводится на уровне реализующих механизмов . По своей направленности он а налогичен анализу уязвимостей . Выше , в разде ле "Основные понятия и идеи "Общей мето д ологии оценки безопасности информационных технологий ", мы подробно рассматривали эту тему . Здесь же отметим , что требования единственного компонента семейства AVA_SOF носят формальный характер : для каждого механизма , имеющего утверждение относительно стой к ости функции безопасности , анализ долже н показать , что стойкость достигает или превышает уровень , определенный в профиле защиты или задании по безопасности . Требования семейства AVA_MSU ( неправильное применение ) направле ны на то , чтобы исключить возможнос ть такого конфигурирования и /или применени я объекта оценки , которое администратор или пользователь считают безопасным , в то время как оно таковым не является . Необ ходимо обеспечить отсутствие в руководствах вводящих в заблуждение , необоснованных и противо р ечивых указаний и налич ие безопасных процедур для всех режимов функционирования . Опасные состояния должны л егко выявляться . Задача решается следующим образом : в представленных разработчиком руководствах иденти фицируются все возможные режимы эксплуатации о бъекта оценки , включая действия пос ле сбоя или ошибки в работе , их по следствия и значение для безопасности эксп луатации . Прилагается список всех предположений относительно среды эксплуатации и требова ний к внешним мерам безопасности . Оценщик должен повтор ить все п роцедуры конфигурирования и установки , а та кже выборочно другие процедуры для подтвер ждения того факта , что объект оценки мо жно безопасно конфигурировать и использовать , применяя только представленные руководства . Кроме того , он обязан выполнить н езависимое тестирование и проверить , см огут ли администратор или пользователь выя снить , руководствуясь документацией , что ОО сконфигурирован или используется опасным образ ом . Анализ скрытых каналов , регламентируемый семейством AVA_CCA, кра йне сложен и кон цептуально , и техни чески (см ., например , статью [JI200211]). Здесь легко требовать , но трудно выполнять . Согласно "Общим критериям ", разработчик проводит исчерп ывающий поиск скрытых каналов для каждой политики управления информационными потоками и предост а вляет документацию ан ализа , в которой идентифицированы скрытые к аналы и оценена их пропускная способность , описаны наиболее опасные сценарии использ ования каждого идентифицированного скрытого ка нала . Оценщик должен выборочно подтвердить п равильность анали за скрытых каналов по средством тестирования . Требования к поставке и эксплуатации , поддержка доверия Класс ADO ( пос тавка и э ксплуатация ) содержит требования к процедурам поставки , установки , генерации и запуска объекта оценки . Требования к поставке сосре доточен ы в трехкомпонентном семействе ADO_DEL. Разработчик должен документировать и использовать процед уры поставки объекта оценки или его ча стей . Необходимо описать , каким образом разл ичные процедуры и технические меры обеспеч ивают обнаружение (ADO_DEL.2 ) или предотвра щение (ADO_DEL.3) модификаций либо иного расхождения между оригиналом разработчика и версией , полученной в месте применения , а также обнаружение попыток подмены от имени ра зработчика в тех случаях , когда последний ничего не поставлял . Семейс тво ADO_IGS (установка , генерация и запуск ) предназначено для безопасного пере хода к этапу эксплуатации . Процедуры безопа сной установки , генерации и запуска объекта оценки документируются разработчиком . Документ ация должна содержать описание процедур , об е с печивающих протоколирование применяв шихся опций генерации , для точного ответа на вопрос , как и когда был сгенер ирован ОО . Класс AMA ( поддержка довери я ) включает четыре семейства и содержит требования , к которым обращ аются после сертификации объекта оценки . Они помогают (по возможности экономн о , без полной повторной оценки ) сохранить уверенность в том , что ОО продолжает отвечать своему заданию по безопасности после изменений в нем или в его с реде . Речь идет о выявлении новых угроз или уязвимостей , изменени и в требованиях пользователя , а также об исп равлении ошибок . Действия по поддержке доверия носят циклический характер . Каждая итерация цикла состоит из двух фаз : 1 приемка объекта оценки для поддержки ; 2 мониторинг ОО . Фаза приемки включает разработку п лана поддержки доверия и категорирование компонентов объекта оценки по их влиянию на безопасность . Элементы фаз ы мониторинга - представление описания текущей версии ОО и выполнение анализа влияния изменени й на безопасность . Возможно , в конце итерации вы ясн ится , что план или категорирование нуждаются в уточнении или изменении ; т огда новая итерация начнется с повторной приемки ОО . Цикл поддержки доверия не может вы полняться бесконечно . В конце концов , либо накопится много мелких изменений , либо потребуются к рупные , и тогда переоце нка станет неизбежной . Семейство AMA_AMP (план поддержки доверия ) рег ламентирует вход в цикл поддержки доверия . Оно идентифицирует процедуры , которые выпо лняет разработчик при изменении объекта оц енки или его среды . План поддержки д оверия должен содержать краткое описан ие ОО , включающее предоставляемые им функци ональные возможности безопасности , идентифицировать сертифицированную версию ОО и ссылаться на результаты оценки , определять предусматри ваемые пределы изменения ОО , содержать описание жизненного цикла ОО , текущие планы новых выпусков ОО , аудита и следующей переоценки , а также включать в себя краткое описание любых запланированных изменений , которые , как ожидается , будут иметь заметное влияние на безопасность . План необходимо д о полнить описание м процедур , которые предполагается применять для поддержки доверия и куда , как ми нимум , следует включить процедуры управления конфигурацией , поддержки свидетельства доверия , выполнения анализа влияния произведенных из менений на безопасност ь , устранения недостатков . План поддержки доверия опирается на отчет о категорировании компонентов ОО для сертифицированной версии ОО , специфицируемы й семейством AMA_CAT. Категорирование критически важн о для анализа влияния на безопасность и переоценки ОО. Отчет должен распред елить по категориям каждый компонент , котор ый может быть идентифицирован в каждом представлении функций безопасности от наибол ее до наименее абстрактного , согласно его отношению к безопасности . Как минимум , необходимо разделить компон е нты ОО на осуществляющие и не осуществляющие политику безопасности . Следует описать приме ненную схему категорирования , чтобы сделать возможным распределение по категориям новых компонентов , а также перераспределение сущ ествующих вследствие изменений в ОО и ли в его задании по безопасности . Наконец , отчет должен идентифицировать сре дства разработки , модификация которых влияет на доверие . Назначение семейства AMA_EVD (свидетельство подде ржки доверия ) состоит в том , чтобы в рамках фазы мониторинга убедиться в поддержке разработчиком доверия безопаснос ти объекта оценки в соответствии с пре дставленным планом . Семейство содержит требован ия к документации поддержки доверия для текущей версии ОО . Документация должна в ключать список текущей конфигурации ОО и список и дентифицированных уязвимостей , подтверждать следование процедурам , описанным в плане поддержки доверия . Для каждой уязвимости в текущей версии требуется показать , что она не может быть испо льзована в предполагаемой среде ОО . Оценщик должен подтвердить , чт о все изменения , документированные при анализе влияния на безопасность для текущей в ерсии ОО , находятся в пределах , установленны х планом поддержки доверия , и что функц иональное тестирование выполнялось на текущей версии ОО соразмерно поддерживаемому уров н ю доверия . Анализ влияния на безопасность (семейст во AMA_SIA), проведенный разработчиком , позволит оценит ь последствия изменений , воздействующих на сертифицированный объект оценки . По его рез ультатам готовится документ , идентифицирующий с ертифицированный О О , откуда была получе на текущая версия , а также все новые и модифицированные компоненты . Для каждого изменения , воздействующего на задание по безопасности или на представления функций безопасности , следует описать все последстви я , к которым оно приводит н а более низких уровнях представления , идентифицировать все функции безопасности и компоненты , категорированные как осуществляющие политику безопасности и подверженные влия нию со стороны данного изменения . Если изменение приводит к модификации представления реализации , следует иденти фицировать тесты , подтверждающие правильность ф ункционирования новой версии . Наконец , необходимо проанализировать влияни е изменений на оценку уязвимости , управлени е конфигурацией , руководства , поставку и экс плуатацию , поддержку жизненного цикла объ екта оценки . Оценщик должен удостовериться , что при анализе влияния на безопасность все и зменения документированы на приемлемом уровне детализации вместе с соответствующим стро гим обоснованием поддержки доверия в текущ ей версии ОО . На этом мы завершаем рассмотрени е семейств требований доверия безопасности . Оценочные уровни доверия безопасности В "Общих критериях " определ ено семь упорядоченных по возрастанию оценочных уровней доверия (ОУ Д ) безопасности , содержащих рассчитанные на много кратное применение комбинации требований доверия (не более одного компонента из каждого семейства ). Наличие такой шкалы дает возможность сбала нсировать получаемый уровень доверия со сл ожностью , сроками , стоимостью и самой возмож ностью его достижения . Пред полагается , что в профилях защиты и заданиях по безопасности будут фигурировать или сами оценочные уровни , или их усиления , полученные путем расширения треб ований (за счет добавления к ОУД новых компонентов ) либо увеличения строгости и /или глубины оценки ( посредством заме ны компонентов более сильным вариантом из того же семейства ). Таким образом , ОУД играют роль опорных точек в многомерн ом пространстве требований доверия . Отметим , что в ОУД не включены требования классов APE (оценка профиля защиты ), ASE (о ценка задания по безопасности ) и AMA (поддержка доверия ), поскольку они находятся вне пределов основного цикла разработки изделий ИТ . Оценочный уровень доверия 1 (ОУД 1), предусм атривающий функциональное тестирование , применим , когда требуется некоторая ув еренность , что объект оценки работает безукоризненно , а угрозы безопасности не считаются серь езными . Его можно достичь без помощи ра зработчика и с минимальными затратами поср едством анализа функциональной спецификации , сп ецификации интерфейсов , эксплуатац и онно й документации в сочетании с независимым тестированием . Оценочный уровень доверия 2 (ОУД 2) предусм атривает структурное тестирование и доступ к части проектной документации и резуль татам тестирования разработчиком . ОУД 2 применим , когда разработчикам ил и пользователям требуется независимо получаемый умеренный уровень доверия при отсутствии доступа к полной документации по разработке . В дополнение к ОУД 1 предписывается анализ проекта верхнего уровня . Анализ долж ен быть поддержан независимым тестированием функций безопасности , актом разработчика об испытаниях , основанных на функционально й спецификации , выборочным независимым подтверж дением результатов тестирования разработчиком , анализом стойкости функций и свидетельством поиска явных уязвимостей . Требует с я наличие списка конфигурации ОО с уникальной идентификацией элементов конфигура ции и свидетельства безопасных процедур по ставки . Оценочный уровень доверия 3 (ОУД 3), предусм атривающий систематическое тестирование и пров ерку , позволяет достичь максимально возмо жного доверия при использовании обычных ме тодов разработки . Он применим в тех слу чаях , когда разработчикам или пользователям требуется умеренный уровень доверия на основе всестороннего исследования объекта оцен ки и процесса его разработки . По сравнен ию с ОУД 2 сюда д обавлено требование , которое предписывает разра ботчику создавать акт об испытаниях с учетом особенностей не только функциональной спецификации , но и проекта верхнего уров ня . Кроме того , требуется контроль среды разработки и управление конф и гу рацией объекта оценки . Оценочный уровень доверия 4 (ОУД 4) предусм атривает систематическое проектирование , тестирован ие и просмотр . Он позволяет достичь дов ерия , максимально возможного при следовании общепринятой практике коммерческой разработки . Это сам ый высокий уровень , на ко торый , вероятно , экономически целесообразно орие нтироваться для существующих типов продуктов . ОУД 4 характеризуется анализом функционально й спецификации , полной спецификации интерфейсов , эксплуатационной документации , проектов верх него и нижнего уровней , а также подмножества реализации , применением неформальной модели политики безопасности ОО . Среди других дополнительных требований - независимый анализ уязвимостей , демонстрирующий устойчивость к попыткам проникновения нарушителей с низким потенциалом нападения , и автоматизация управления конфигурацией . Отличительные особенности оценочного уровн я доверия 5 (ОУД 5) - полуформальное проектирование и тестирование . С его помощью достигае тся доверие , максимально возможное при след овании ст рогой практике коммерческой р азработки , поддержанной умеренным применением с пециализированных методов обеспечения безопасности . ОУД 5 востребован , когда нужен высокий уровень доверия и строгий подход к раз работке , не влекущий излишних затрат . Для достижени я ОУД 5 требуется ф ормальная модель политики безопасности ОО и полуформальное представление функциональной спецификации и проекта верхнего уровня , пол уформальная демонстрация соответствия между ни ми , а также модульная структура проекта ОО . Акт об испытания х должен быть основан еще и на проекте нижне го уровня . Необходима устойчивость к попытк ам проникновения нарушителей с умеренным п отенциалом нападения . Предусматривается проверка правильности анализа разработчиком скрытых к аналов и всестороннее управление к о нфигурацией . Оценочный уровень доверия 6 (ОУД 6) характе ризуется полуформальной верификацией проекта . О н позволяет получить высокое доверие путем применения специальных методов проектирования в строго контролируемой среде разработки при производстве высоко качественных и зделий ИТ и при защите ценных активов от значительных рисков . Особенности ОУД 6: 1 структурированное представление реализации ; 2 полуформальное представление проекта нижнего уровня ; 3 иерархическая с труктура проекта ОО ; 4 устойчивость к п опыткам проникновения нарушителей с высоким потенциалом нападения ; 5 проверка правил ьности систематического анализа разработчиком скрытых каналов ; 6 использование с труктурированного процесса разработки ; 7 полная автомати зация управления конфигурацией ОО . Оценочный уро вень доверия 7 (ОУД 7), предусматривающий формальную верификацию проекта , применим к разработке изделий ИТ для использования в ситуац иях чрезвычайно высокого риска или там , где высокая ценность активов оправдывает повышенные затраты . На сед ьмом уровне дополнительно требуются : 1 формальное пред ставление функциональной спецификации и проект а верхнего уровня и формальная демонстраци я соответствия между ними ; 2 модульная , иерар хическая и простая структура проекта ОО ; 3 добавление пред ставлени я реализации как основы акта об испытаниях ; 4 полное независи мое подтверждение результатов тестирования раз работчиком . На наш вз гляд , оценочные уровни доверия выбраны очен ь удачно ; их усиление в профилях защиты и заданиях по безопасности в подавляю щем бо льшинстве случаев носит непринци пиальный характер . Дополнительную информацию по "Общим критериям " можно най ти в книге [OBIT].
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Не спрашивайте меня, видел ли я новый фильм. У меня четыре маленькие дочери. Если там нет поющих принцесс, ответ — нет.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru