Уровень 2. Система для обработки информации с грифом не выше „секретно", и т. д.

Соответственно и требования потребители хотели бы формулировать примерно в такой форме: «Мы хо­тим, чтобы у нас все было защищено для обработки со­вершенно секретной информации». Этот неконструктив­ный подход сам по себе не так страшен, гораздо хуже другое — многие потребители не понимают, что за все надо платить (и не только деньгами) и что требования безопасности обязательно противоречат функциональ­ным требованиям (удобству работы, быстродействию и т. п.), накладывают ограничения на совместимость и, как правило, вынуждают отказаться от очень широко рас­пространенных незащищенных прикладных программ­ных средств.

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

Эксперты по квалификации и специалисты по серти­фикации рассматривают стандарты как инструмент, по­зволяющий им оценить уровень безопасности, обеспечи­ваемый продуктами информационных технологий, и предоставить потребителям возможность сделать обос­нованный выбор. Производители в результате квалифи­кации уровня безопасности получают объективную оценку возможностей своего продукта. Эксперты по квалификации находятся в двойственном положении. С одной стороны они, как и производители, заинтересова­ны в четких и простых критериях, над применением ко­торых к конкретному продукту не надо ломать голову (например, в виде анкеты с ответами типа «ДА/НЕТ»). С другой стороны, они должны дать обоснованный ответ пользователям — удовлетворяет продукт их нуждам или нет. Именно эксперты принимают на себя ответствен­ность за безопасность продукта, получившего квалифи­кацию уровня безопасности и прошедшего сертифика­цию.

Таким образом, перед стандартами информационной безопасности стоит непростая задача — примирить эти три точки зрения и создать эффективный механизм взаимодействия всех сторон. Причем «ущемление» по­требностей хотя бы одной из них приведет к невозмож­ности взаимопонимания и взаимодействия и, следова­тельно, не позволит решить общую задачу — создание защищенной системы обработки информации. Необхо­димость в подобных стандартах была осознана уже дос­таточно давно (по меркам развития информационных технологий ) и в этом направлении достигнут существенный прогресс закрепленный в новом поколении документов разработки 90-годов. Наиболее значимыми стандартами информационной безопасности являются (в хронологическом порядке): «Критерии безопасности компьютерных систем министерства обороны США» [7], Руководящие документы Гостехкомиссии России [1,2,3,4,5] (только для нашей страны), «Европейские критерии безопасности информационных технологий» [16] «Федеральные критерии безопасности информационных технологий США»[17], «Канадские критерии безопасно­сти компьютерных систем» [18] и «Единые критерии безопасности информационных технологий» [19].

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

2.5 Критерии безопасности компьютерных систем министерства обороны США («Оранжевая книга»)

2.5.1. Цель разработки

«Критерии безопасности компьютерных систем» (Trusted Computer System Evaluation Criteria») [7], полу­чившее неформальное, но прочно закрепившееся название «Оранжевая книга», были разработаны Министерством обороны США в 1983 году с целью опреде­ления требований безопасности, предъявляемых к аппаратному, программному и специальному обеспече­ние компьютерных систем и выработки соответствующей методологии анализа политики безопасности, реализуемой в компьютерных системах военного на­значения.

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

2.5.2. Таксономия требовании и критериев «Оранжевой книги»

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

2.5.2.1. Политика безопасности

Требование 1. Политика безопасности.

Система должна поддерживать точно определенную политику безопасности. Возможность осуществления субъектами доступа к объектам должна определяться на основании их идентификации и набора правил управ­ления доступом. 'Гам. где необходимо, должна использоваться политика нормативного упрощения доступом. позволяющая эффективно реализовать разграничение доступа к категорированной информации (информации, отмеченной грифом секретности, типа «секретно», «сов. секретно» и т.д. ).

Требование 2. Метки

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

2.5.2.2. Аудит

Требование 3. Идентификации и аутентификация

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