Негосударственное образовательное учреждение повышения квалификации «НАУЧНО-ИНФОРМАЦИОННЫЙ ЦЕНТР ПРОБЛЕМ БЕЗОПАСНОСТИ»

Комплексное обеспечение безопасности объектов связи

Часть 3

192148, Санкт-Петербург, Большой Смоленский, 36 тел.: (812) 325-1037, факс:(812) 568-1035

e-mail: nic@confident.spb.ru

Основные критерии защищенности автоматизированных систем

43.1

Методы и средства защиты информационных объектов от вредоносных программ

Содержание

3.Критерии оценки безопасности компьютерных систем министерства обороны

6.РУКОВОДЯЩИЙ ДОКУМЕНТ Защита от НСД к информации (Часть 1. Программное обеспечение средств защиты информации.

43.2

Основные критерии защищенности автоматизированных систем

1. Архитектура безопасности (стандарт ISO)

Для обеспечения безопасности распределенных систем Международная организация стандартов ISO (International Standart Organization) разработала дополнение к базовой эталонной модели взаимодействия от крытых систем и выпустила в 1988 году стандарт ISO 7498 2 Security Architecture (Архитектура безопасности). Этот стандарт определяет угрозы безопасности и устанавливает требования к безопасности в среде взаимо действия открытых систем.

Архитектура безопасности охватывает общее описание средств защиты данных и методов, связанных с их работой. Защита предусматривает:

•идентификацию абонентов;

•предотвращение чтения сообщений любыми лицами;

•защиту трафика от его анализа посторонними;

•обнаружение искажений блоков данных;

•обнаружение изменений потоков сообщений;

•управление методами кодирования информации (криптографии);

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

Реализация формальной модели политики безопасности строится с использованием, так называемой, Дове рительной Вычислительной Базы (ДВБ,Trusted Computing Base TCB), включающей общие механизмы внутрен ней защиты системы (аппаратные, микропрограммные и программные), комбинация которых обеспечивает реализацию требований политики безопасности, образует базовое окружение защиты и поддерживает пользо вательские службы, необходимые в защищенных компьютерных системах.

Требования стандарта ISO по номенклатуре услуг, предоставляемых системой безопасности

Система безопасности в соответствии со стандартом ISO должна обеспечивать следующие услуги бе зопасности:

1. Аутентификация однорангового объекта.

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

2. Аутентификация источника данных.

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

3.Контроль доступа, который предотвращает несанкционированное использование ресурсов, доступных через среду OSI. Не все ресурсы должны быть ресурсами OSI. Контроль доступа может применяться к некоторым ви дам доступа (чтение/запись данных, активизация информационных ресурсов, исполнение операций над ресур сами), либо ко всем видам доступа к ресурсу.

4.Конфиденциальность соединения, обеспечивающая конфиденциальность всех данных пользователя этого соединения.

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

6.Конфиденциальность выделенного поля обеспечивает конфиденциальность определенного поля в блоке данных соединения или сервисном блоке данных в случае режима без установления соединения.

7.Конфиденциальность трафика предотвращает получение информации путем наблюдения трафика.

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

9.Целостность соединения без восстановления обеспечивает те же возможности, что и предыдущая услуга, но без попытки восстановления.

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

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

12.Целостность выделенного поля в режиме без установления соединения позволяет обнаружить модифи кацию выделенного поля в отдельном сервисном блоке данных.

13.Доказательство источника заключается в предоставлении получателю данных доказательства (в виде данных) с предотвращением любой попытки отправителя отрицать впоследствии факт передачи.

43.3

Методы и средства защиты информационных объектов от вредоносных программ

14. Доказательство доставки заключается в предоставлении отправителю данных доказательства (в виде дан ных) с предотвращением любой попытки получателя отрицать впоследствии факт получения данных. Распределение услуг безопасности по уровням эталонной модели ISO приведено в таблице 1.

Таблица 1

Механизмы безопасности

Механизмы безопасности предназначены для реализации услуг безопасности. Выделяют следующие механиз мы безопасности:

•механизмы шифрования (обеспечивают услуги конфиденциальности, а также являются элементами ряда других механизмов);

•механизмы цифровой подписи (обеспечивают услуги опознавания и доказательства);

•механизмы контроля доступа (реализуют услугу контроля доступа, обеспечивают предоставление объектам соответствующих прав доступа к ресурсам);

•механизмы целостности данных (поддерживают услуги целостности и частично услуги доказательства);

•механизмы обменной аутентификации (услуга аутентификации однорангового объекта);

•механизмы подстановки трафика (поддерживают услуги конфиденциальности трафика и предотвраща ют анализ трафика);

•механизмы управления маршрутизацией (используются услугами конфиденциальности);

•механизмы арбитража (для подтверждения некоторых характеристик данных, передаваемых между объек тами).

Управление безопасностью

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

Функции управления безопасностью могут быть разделены на три большие группы:

•управление безопасностью системы;

•управление услугами безопасности;

•управление механизмами безопасности.

Управление безопасностью системы рассматривает вопросы управления безопасностью всей среды OSI и включает функции:

•поддержки целостности методики безопасности;

•взаимосвязи с остальными функциями управления OSI и управления услугами и механизмами безо пасности;

•управления механизмом событий безопасности, механизмом контроля безопасности и механизмом вос становления безопасности.

43.4

Основные критерии защищенности автоматизированных систем

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

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

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

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

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

Управление шифрованием может включать взаимодействие с управлением ключами, определение криптог рафических параметров и криптографическую синхронизацию.

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

Управление контролем доступа может включать распространение атрибутов безопасности (включая паро ли) и поддержание списков контроля доступа или мандатов.

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

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

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

Управление арбитражем может включать распространение информации об арбитрах и использование про токола между арбитром и взаимодействующими объектами.

При создании архитектуры безопасности необходимо учитывать различные факторы:

•минимизация количества объектов защиты повышает надежность ее работы;

•размещение средств защиты на канальном уровне не обеспечивает безопасности при наличии в сети хотя бы одного узла коммутации;

•размещение защиты только на прикладном уровне не позволяет защитить заголовки и концевики бло ков данных.

Архитектура безопасности включает необходимые технические и программные средства, анализ характери стик их работы.

Как и все эталонные системы, архитектура безопасности ISO обладает избыточностью.

Конечно, реализация всех требований, определенных стандартом ISO, очень трудна и дорогостояща. На се годняшний день систем безопасности, полностью соответствующих ISO, нет. Данный стандарт фактически является мерой соответствия национальных (промышленных) стандартов эталону. Далее рассмотрим неко торые “реальные” стандарты.

2. Руководящие документы Государственной Технической Комиссии России

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

43.5

Методы и средства защиты информационных объектов от вредоносных программ

Структура требований безопасности

Руководящие документы ГТК состоят из пяти частей.

1.Защита от несанкционированного доступа к информации. Термины и определения.

2.Концепция защиты СВТ и АС от НСД к информации.

3.Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.

4.Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации.

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

Основные положения концепции защиты СВТ и АС от НСД к информации

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

•выработка требований по защите СВТ и АС от НСД к информации;

•создание защищенных СВТ и АС, т.е. защищенных от НСД к информации;

•сертификация защищенных СВТ и АС.

Как уже было сказано выше, концепция предусматривает существование двух относительно самостоятель ных направлений в проблеме защиты информации от НСД: направления, связанного с СВТ, и направления, связанного с АС. Различие двух направлений порождено тем, что СВТ разрабатываются и поставляются на рынок лишь как элементы, из которых в дальнейшем строятся функционально ориентированные АС, и по этому, не решая прикладных задач, СВТ не содержат пользовательской информации. В случае СВТ можно говорить лишь о защищенности (защите) СВТ от НСД к информации, для обработки, хранения и передачи которой СВТ предназначено. Примером СВТ можно считать специализированную плату расширения с соот ветствующим аппаратным и программным интерфейсом, реализующую функции аутентификации пользо вателя по его биометрическим характеристикам. Или к СВТ можно отнести программу прозрачного шифро вания данных, сохраняемых на жестком диске.

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

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

•непосредственное обращение к объектам доступа (например, через получение программой, управляе мой пользователем, доступа на чтение или запись в файл);

•создание программных и технических средств, выполняющих обращение к объектам доступа в обход средств защиты (например, используя люки, оставленные разработчиками системы защиты);

•модификация средств защиты, позволяющая осуществить НСД (например, путем внедрения в систему защиты программных закладок или модулей, выполняющих функции “троянского коня”);

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

Далее в руководящих документах ГТК представлены семь принципов защиты информации:

•защита СВТ и АС основывается на положениях и требованиях существующих законов, стандартов и нор мативно методических документов по защите от НСД к информации;

•защита СВТ обеспечивается комплексом программно технических средств;

•защита АС обеспечивается комплексом программно технических средств и поддерживающих их органи зационных мер;

•защита АС должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ;

•программно технические средства защиты не должны существенно ухудшать основные функциональные характеристики АС (надежность, быстродействие, возможность изменения конфигурации АС);

43.6

Основные критерии защищенности автоматизированных систем

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

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

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

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

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

•Третий уровень определяется возможностью управления функционированием АС, т.е. воздействием на ба зовое программное обеспечение системы и на состав и конфигурацию ее оборудования (например, к дан ному классу относится нарушитель, внедривший в систему безопасности АС программную закладку).

•Четвертый уровень определяется всем объемом возможностей лиц, осуществляющих проектирование, ре

ализацию и ремонт технических средств АС, вплоть до включения в состав СВТ собственных технических средств с новыми функциями по обработке информации (например, известны случаи, когда в АС внедря лись “временные бомбы”, выводящие систему из строя по истечении срока гарантийного ремонта).

Кроме перечисленных выше понятий, во второй части руководящих документов ГТК рассматриваются:

•основные направления обеспечения защиты от НСД, в частности, основные функции средств разграни чения доступа (СРД) и обеспечивающих СРД средств;

•основные характеристики технических средств защиты от НСД;

•порядок организации работ по защите.

Показатели защищенности средств вычислительной техники от НСД

В ч.2 руководящих документов ГТК устанавливается классификация СВТ по уровню защищенности от НСД к информации на базе перечня показателей защищенности и совокупности описывающих их требований. Под СВТ понимается совокупность программных и технических элементов систем обработки данных, способных функционировать самостоятельно или в составе других систем.

Показатели защищенности содержат требования защищенности СВТ от НСД к информации и применяются к об щесистемным программным средствам и операционным системам (с учетом архитектуры компьютера). Конк ретные перечни показателей определяют классы защищенности СВТ и описываются совокупностью требований. Совокупность всех средств защиты составляет комплекс средств защиты (КСЗ).

По аналогии с критерием TCSEC, который будет рассмотрен далее, установлено семь классов защищенности СВТ от НСД к информации. Самый низкий класс седьмой, самый высокий первый. Показатели защищеннос ти и требования к классам приведены в табл. 2.

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

Интересно, что защищенные СВТ содержат разделение только по двум классам политик безопасности: диск реционной и мандатной.

Невлияние субъектов друг на друга описывается требованием “изоляция модулей” (требуется с 4 го класса). Гарантии выполнения политики безопасности коррелированы с требованием “целостность КСЗ” (требуется с 5 го класса) и “гарантии проектирования” (требуется также с 5 го класса).

Классы защищенности АС

В ч. 3 руководящих документов ГТК дается классификация АС и требований по защите информации в АС раз личных классов. При этом определяются:

1. Основные этапы классификации АС:

•разработка и анализ исходных данных;

•выявление основных признаков АС, необходимых для классификации;

•сравнение выявленных признаков АС с классифицируемыми;

•присвоение АС соответствующего класса защиты информации от НСД.

43.7

Методы и средства защиты информационных объектов от вредоносных программ

2. Необходимые исходные данные для классификации конкретной АС:

• перечень защищаемых информационных ресурсов АС и их уровень конфиденциальности;

• перечень лиц, имеющих доступ к штатным средствам АС с указанием их уровня полномочий;

• матрица доступа или полномочий субъектов доступа по отношению к защищаемым информационным ресурсам АС;

• режим обработки данных в АС.

3. Признаки, по которым производится группировка АС в различные классы:

•наличие в АС информации различного уровня конфиденциальности;

•уровень полномочий субъектов доступа АС на доступ к конфиденциальной информации;

•режим обработки данных в АС: коллективный или индивидуальный.

Таблица 2.

Показатели по классам защищенности СВТ Гостехкомиссии РФ

Обозначения:

“ ” нет требований к данному классу; “+” новые или дополнительные требования,

“=” требования совпадают с требованиями к СВТ предыдущего класса.

Документы ГТК устанавливают девять классов защищенности АС от НСД, распределенных по трем группам. Каждый класс характеризуется определенной совокупностью требований к средствам защиты. В пределах каждой группы соблюдается иерархия классов защищенности АС. Класс, соответствующий высшей степени защищенности для данной группы, обозначается индексом NА, где N номер группы (от 1 до 3). Следующий класс обозначается N/Б и т.д.

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

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

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

Втабл. 3 приведены требования к подсистемам защиты для каждого класса защищенности.

Вприложении приведен РУКОВОДЯЩИЙ ДОКУМЕНТ Защита от НСД к информации (Часть 1. Программное

обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недеклари рованных возможностей)

43.8

Основные критерии защищенности автоматизированных систем

Таблица 3.

Требования к защищенности автоматизированных систем.

Обозначения:

“ “ нет требований к данному классу; “+” есть требования к данному классу; “СЗИ НСД” система защиты информации от несанкционированного доступа.

Рассмотренные выше документы ГТК необходимо воспринимать как первую стадию формирования отечествен ных стандартов в области информационной безопасности. На разработку этих документов наибольшее вли яние оказал критерий TCSEC (“Оранжевая книга”), который будет рассмотрен ниже, однако это влияние в

43.9

Методы и средства защиты информационных объектов от вредоносных программ

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

К недостаткам руководящих документов ГТК относятся: ориентация на противодействие НСД и отсутствие тре бований к адекватности реализации политики безопасности. Понятие “политика безопасности” трактуется ис ключительно как поддержание режима секретности и отсутствие НСД [б]. Из за этого средства защиты ориен тируются только на противодействие внешним угрозам, а к структуре самой системы и ее функционированию не предъявляется четких требований. Ранжирование требований по классам защищенности по сравнению с остальными стандартами информационной безопасности максимально упрощено и сведено до определения на личия или отсутствия заданного набора механизмов защиты, что существенно снижает гибкость требований и возможность их практического применения. Несмотря на указанные недостатки, документы ГТК заполнили “пра вовой вакуум” в области стандартов информационной безопасности в России и оперативно решили проблему проектирования и оценки качества защищенных АС.

3. Критерии оценки безопасности компьютерных систем министерства обороны США (“Оранжевая книга”)

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

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

Общая структура требований TCSEC

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

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

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

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

Подотчетность

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

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

Гарантии (корректность)

43.10

Основные критерии защищенности автоматизированных систем

Требование 5. Контроль корректности функционирования средств защиты. Средства защиты должны со держать независимые аппаратные и/или программные компоненты, обеспечивающие работоспособность фун кций защиты. Это означает, что все средства защиты, обеспечивающие политику безопасности, управление атрибутами и метками безопасности, идентификацию и аутентификацию, регистрацию и учет, должны нахо диться под контролем средств, проверяющих корректность их функционирования. Основной принцип контро ля корректности состоит в том, что средства контроля должны быть полностью независимы от средств защиты. Требование 6. Непрерывность защиты. Все средства защиты (в том числе и реализующие данное требова ние) должны быть защищены от несанкционированного вмешательства и/или отключения, причем эта защи та должна быть постоянной и непрерывной в любом режиме функционирования системы защиты и компью терной системы в целом. Данное требование распространяется на весь жизненный цикл компьютерной сис темы. Кроме того, его выполнение является одной из ключевых аксиом, используемых для формального до казательства безопасности системы.

Классы защищенности компьютерных систем по TCSEC

“Оранжевая книга” предусматривает четыре группы критериев, которые соответствуют различной степени за щищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов. Группы D и А содержат по одному классу (классы D и А соответственно), группа С классы С1, С2, а группа В три класса В1, В2, ВЗ, характеризующиеся различными наборами требований защи щенности. Уровень защищенности возрастает от группы D к группе А, а внутри группы с увеличением номе ра класса. Усиление требований осуществляется с постепенным смещением акцентов от положений, опреде ляющих наличие в системе каких то определенных механизмов защиты, к положениям, обеспечивающим высокий уровень гарантий того, что система функционирует в соответствии с требованиями политики безо пасности (табл. 4). Например, по реализованным механизмам защиты классы ВЗ и А1 идентичны.

Таблица 4.

Показатели защищенности “Оранжевой книги”

Обозначения:

“ ” нет требований к данному классу; “+” новые или дополнительные требования; “=” требования совпадают с требованиями к предыдущему классу.

43.11

Методы и средства защиты информационных объектов от вредоносных программ

Рассмотрим основные требования классов защищенности по указанным выше четырем категориям:

•политика безопасности;

•подотчетность;

•гарантии;

•документация.

Центральным объектом исследования и оценки по TCSEC является доверительная база вычислений (ТСВ).

Группа D. Минимальная защита

Класс D. Минимальная защита. Класс D зарезервирован для тех систем, которые были представлены на сер тификацию (оценку), но по какой либо причине ее не прошли.

Группа С. Дискреционная защита

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

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

Документация должна включать:

•описание реализованных в ТСВ механизмов защиты, их взаимодействия, и руководство пользователя по их использованию;

•руководство для администратора системы на гарантирование системы защиты;

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

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

Класс С1 рассчитан на многопользовательские системы, в которых осуществляется совместная обработка дан ных одного уровня конфиденциальности.

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

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

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

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

•идентификация и аутентификация пользователя;

•размещение объектов в адресном пространстве процессов пользователей (например, чтение информа ции из файлов);

•уничтожение объектов;

•действия, осуществляемые администраторами системы.

При этом запись журнала аудита должна снабжаться необходимым набором атрибутов:

•дата и время события;

•идентификатор пользователя, инициировавшего событие;

•тип события (например, вход в систему, получение доступа к файлу на чтение и т.д.);

•результат: успех или неуспех выполнения события.

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

43.12

Основные критерии защищенности автоматизированных систем

Гарантии. ТСВ должна изолировать подлежащие защите ресурсы так, чтобы выполнялись требования конт роля доступа и аудита.

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

Документация должна дополнительно (по сравнению с классом С1) включать описание событий, заносимых в журнал аудита.

Группа В. Мандатное управление доступом

Основные требования этой группы мандатное (полномочное) управление доступом с использованием меток бе зопасности, реализация некоторой формальной модели политики безопасности, а также наличие спецификаций на функции ТСВ. В системах этой группы постепенно к классу ВЗ должен быть реализован монитор ссылок (или МБО в терминологии гл. 4), который должен контролировать все доступы субъектов к объектам системы.

Класс В1. Системы класса В1 должны удовлетворять требованиям класса С2. Кроме того, должны быть вы полнены следующие дополнительные требования.

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

Подотчетность. Аудиту подлежат любые изменения меток секретности читаемого вывода.

Гарантии. ТСВ должна обеспечивать изоляцию процессов системы, через выделение им соответствующего ад ресного пространства. Целью тестирования является:

•Поиск всех каналов проникновения внешних субъектов с целью получения несанкционированного дос тупа к информации.

•Получение гарантии того, что никакой неавторизованный для этого специально пользователь не может ввести ТСВ в состояние, в котором она не способна отвечать на запросы других субъектов.

ТСВ должна быть построена на основе неформальной или формальной политики безопасности, которая дол жна поддерживаться на протяжении всего жизненного цикла системы.

Документация должна дополнительно включать:

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

•Описание формальной или неформальной политики безопасности, а также то, как она реализована в

системе.

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

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

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

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

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

43.13

Методы и средства защиты информационных объектов от вредоносных программ

Документация должна дополнительно включать:

•для системного администратора описание того, как безопасно создать новую ТСВ;

•результаты проверки эффективности использованных методов по сокращению мощности скрытых кана лов утечки информации.

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

Класс ВЗ. Домены безопасности. В системах класса ВЗ ТСВ должна удовлетворять всем требованиям предыдущего класса и дополнительно требованиям монитора ссылок, который должен быть:

•защищен от несанкционированного изменения или порчи;

•обрабатывать все обращения;

•прост для анализа и тестирования.

ТСВ должна быть структурирована таким образом, чтобы исключить код, не имеющий отношения к безопас ности системы.

Дополнительно должно быть обеспечено;

•поддержка администратора безопасности;

•расширение механизма аудита с целью сигнализации о любых событиях, связанных с безопасностью;

•поддержка процедуры восстановления системы.

Политика безопасности. Не включает существенных дополнительных требований по сравнению с предыду щим классом защиты.

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

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

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

Должен быть обеспечен механизм восстановления при сбоях компьютерной системы без нарушения ее безопас ности.

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

Должно быть четко показано, что высокоуровневая спецификация ТСВ соответствует модели политики безо пасности.

Документация дополнительно должна включать:

•для системного администратора описание процедур, которые могут дать гарантию, что система начала свою работу безопасно;

•неформальное доказательство того, что все элементы ТСВ соответствуют высокоуровневой специфика

ции.

Группа А. Верифицированная защита

Данная группа характеризуется применением формальных методов верификации корректности работы ме ханизмов управления доступом (дискреционного и мандатного). Требуется, чтобы было формально показано соответствие архитектуры и реализации ТСВ требованиям безопасности.

Класс А1. Формальная верификация. Критерий защиты класса А1 не определяет дополнительные по сравне нию с классом ВЗ требования к архитектуре или политике безопасности компьютерной системы. Дополни тельным свойством систем, отнесенных к классу А1, является проведенный анализ ТСВ на соответствие фор мальным высокоуровневым спецификациям и использование технологий проверки с целью получения высо ких гарантий того, что ТСВ функционирует корректно.

Наиболее важные требования к классу А1 можно объединить в пять групп.

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

•Формальная высокоуровневая спецификация должна включать абстрактное определение выполняемых ТСВ функций и аппаратный и (или) встроенный программный механизм для обеспечения разделения доменов.

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

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

43.14

Основные критерии защищенности автоматизированных систем

•Должны быть использованы формальные технологии для выявления и анализа скрытых каналов. Не формальная технология может быть использована для анализа скрытых временных каналов. Существо

вание оставшихся в системе скрытых каналов должно быть оправдано.

Более строгие требования предъявляются к управлению конфигурацией системы и конкретному месту дис локации (развертывания) системы.

Перечисленные требования не затрагивают группы Политика безопасности и Подотчетность и сконцентриро ваны в группе Гарантии с соответствующим описанием в группе Документация.

Интерпретация и развитие TCSEC

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

Круг специфических вопросов по обеспечению безопасности компьютерных сетей и систем управления ба зами данных нашел отражение в отдельных документах, изданных Национальным центром компьютерной бе зопасности США в виде дополнений к “Оранжевой книге”:

•“Интерпретация TCSEC для компьютерных сетей” (Trusted Network Interpretation).

•“Интерпретация TCSEC для систем управления базами данных” (Trusted Database Management System

Interpretation).

Эти документы содержат трактовку основных положений “Оранжевой книги” применительно к соответствую щим классам систем обработки информации.

Устаревание ряда положений TCSEC обусловлено, прежде всего, интенсивным развитием компьютерных тех нологий и переходом с вычислительных комплексов типа IBM 360/370 (советский аналог машины серии ЕС) к рабочим станциям, высокопроизводительным персональным компьютерам и сетевой модели вычислений. Именно для того, чтобы исключить возникшую в связи с изменением аппаратной платформы некорректность некоторых положений “Оранжевой книги”, адаптировать их к современным условиям и сделать адекватными нуждам разработчиков и пользователей программного обеспечения, и была проделана значительная работа по интерпретации и развитию положений этого стандарта. В результате возник целый ряд сопутствующих “Оранжевой книге” документов, многие из которых стали ее неотъемлемой частью. К наиболее часто упоми наемым относятся:

•“Руководство по произвольному управлению доступом в безопасных системах” (A guide to understanding discretionary access control in trusted systems),

•“Руководство по управлению паролями” (Password management guideline).

•“Руководство по применению “Критериев безопасности компьютерных систем” в специфических сре дах” (Guidance for applying the Department Of Defence Trusted Computer System Evaluation Criteria in specific environment).

•“Руководство по аудиту в безопасных системах” (A Guide to Understanding Audit in Trusted Systems).

•“Руководство по управлению конфигурацией в безопасных системах” (Guide to understanding configuration management in trusted systems).

Количество подобных вспомогательных документов, комментариев и интерпретаций значительно превыси ло объем первоначального документа, и в 1995 г. Национальным центром компьютерной безопасности США был опубликован документ под названием “Интерпретация критериев безопасности компьютерных систем”, объединяющий все дополнения и разъяснения. При его подготовке состав подлежащих рассмотрению и тол кованию вопросов обсуждался на специальных конференциях разработчиков и пользователей защищенных систем обработки информации. В результате открытого обсуждения была создана база данных, включающая все спорные вопросы, которые затем в полном объеме были проработаны специально созданной рабочей группой. В итоге появился документ, проинтегрировавший все изменения и дополнения к TCSEC, сделанные с момента ее опубликования, что привело к обновлению стандарта и позволило применять его в современных условиях.

В заключение отметим, что критерии TCSEC Министерства обороны США представляют собой первую попытку создать единый стандарт безопасности, рассчитанный на проектировщиков, разработчиков, потребителей и специалистов по сертификации систем безопасности компьютерных систем. В свое время этот документ явился значительным шагом в области безопасности информационных технологий и послужил отправной точкой для многочисленных исследований и разработок. Основной отличительной чертой этого документа, как уже от мечалось, является его ориентация на системы военного применения, причем в основном на операционные системы. Это предопределило доминирование требований, направленных на обеспечение конфиденциаль ности обрабатываемой информации и исключение возможностей ее разглашения. Большое внимание уделе но меткам конфиденциальности (грифам секретности) и правилам экспорта секретной информации.

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

Тем не менее “Оранжевая книга” послужила основой для разработчиков всех остальных стандартов инфор мационной безопасности и до сих пор используется в США в качестве руководящего документа при сертифи кации компьютерных систем обработки информации.

43.15

Методы и средства защиты информационных объектов от вредоносных программ

4. Европейские критерии безопасности информационных технологий

Вслед за выходом критерия TCSEC страны Европы разработали согласованные “Критерии безопасности инфор мационных технологий” (Information Technology Security Evaluation Criteria (ITSEC), далее “Европейские крите рии”). Рассмотрим версию 1.2 данного документа, опубликованную в июне 1991 г. от имени соответствующих органов четырех стран: Франции, Германии, Нидерландов и Великобритании.

Основные понятия

“Европейские Критерии” рассматривают следующие задачи средств информационной безопасности:

•защита информации от несанкционированного доступа с целью обеспечения конфиденциальности (под держание конфиденциальности);

•обеспечение целостности информации посредством защиты от ее несанкционированной модификации или уничтожения (поддержание целостности);

•обеспечение работоспособности систем с помощью противодействия угрозам отказа в обслуживании (поддержание доступности).

Для того, чтобы удовлетворить требованиям конфиденциальности, целостности и доступности, необходимо реализовать соответствующий набор функций безопасности, таких, как идентификация и аутентификация, управление доступом, восстановление после сбоев и т.д. Чтобы средства защиты можно было признать эф фективными, требуется высокая степень уверенности в правильности их выбора и надежности функциони рования. Для решения этой проблемы в “Европейских критериях” впервые вводится понятие адекватности (assurance) средств защиты.

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

Общая оценка уровня безопасности системы складывается из функциональной мощности средств защиты и уровня адекватности их реализации.

Основным объектом проверки и оценки, аналогом ТСВ в “Оранжевой книге”, в “Европейских Критериях” яв ляется цель оценки (Target of Evaluation TOE).

Пути реализации политики безопасности, предъявляемые требования к защитным механизмам зависят от того, является ли TOE в терминологии “Европейских Критериев” системой или продуктом. Это разделение систем ана логично используемому в Руководящих документах Гостехкомиссии делению компьютерных систем на АС и СВТ (см. выше).

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

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

Функциональные критерии

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

•идентификации и аутентификации;

•управления доступом;

•подотчетности;

•аудита;

•повторного использования объектов;

•целостности информации;

•надежности обслуживания;

•безопасности обмена данными.

Большинство из перечисленных требований совпадает с аналогичными требованиями “Оранжевой книги”. Остановимся лишь на специфичных для “Европейских критериев”.

Требования безопасности обмена данными регламентируют работу средств, обеспечивающих безопасность данных, передаваемых по каналам связи, и включают следующие разделы:

•аутентификация;

•управление доступом;

43.16

Основные критерии защищенности автоматизированных систем

•конфиденциальность данных;

•целостность данных;

•невозможность отказаться от совершенных действий.

Набор функций безопасности может специфицироваться с использованием ссылок на заранее определен ные классы шаблоны: В “Европейских критериях” таких классов десять. Пять из них (F C1, F C2, F B1. F B2,F B3) соответствуют классам безопасности “Оранжевой книги” с аналогичными обозначениями. Рассмотрим подробнее другие пять классов, так как их требования отражают точку зрения разработчиков стандарта на проблему безопасности.

Класс F IN предназначен для систем с высокими потребностями в обеспечении целостности, что типич но для систем управления базами данных. Его описание основано на концепции “ролей”, соответствую щих видам деятельности пользователей, и предоставлении доступа к определенным объектам только по средством доверенных процессов. Должны различаться следующие виды доступа: чтение, запись, добав ление, удаление, создание, переименование и выполнение объектов (имеется в виду порождение субъекта из соответствующего объекта источника).

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

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

Класс F DC уделяет особое внимание требованиям к конфиденциальности передаваемой информации. Информа ция по каналам связи должна передаваться только в зашифрованном виде. Ключи шифрования должны быть за щищены от несанкционированного доступа.

Класс F DX предъявляет повышенные требования и к целостности, и к конфиденциальности информации. Его можно рассматривать как функциональное объединение классов F DI и F DC с дополнительными возможнос тями шифрования и защиты от анализа трафика. Должен быть ограничен доступ к ранее переданной инфор мации.

Критерии адекватности

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

“Европейские критерии” определяют семь уровней адекватности от ЕО до Е6 (в порядке возрастания). Уровень ЕО обозначает минимальную адекватность. При проверке адекватности анализируется весь жизненный цикл си стемы от начальной фазы проектирования до эксплуатации и управления. Уровни адекватности от Е1 до Е6 вы строены по нарастанию требований тщательности контроля. Так, на уровне Е1 анализируется лишь общая архи тектура системы, а адекватность средств защиты подтверждается функциональным тестированием. На уровне ЕЗ к анализу привлекаются исходные тексты программ и схемы аппаратного обеспечения. На уровне Е6 требу ется формальное описание функций безопасности, общей архитектуры, а также политики безопасности.

Степень безопасности системы определяется самым слабым из критически важных механизмов защиты. В “Ев ропейских критериях” определены три уровня безопасности: базовый, средний, высокий. Безопасность счи тается базовой, если средства защиты способны противостоять отдельным случайным атакам (злоумышлен ник физическое лицо). Безопасность считается средней, если средства защиты способны противостоять злоумышленникам, обладающим ограниченными ресурсами и возможностями (корпоративный злоумышлен ник). Наконец, безопасность можно считать высокой, если есть уверенность, что средства защиты могут быть преодолены только злоумышленником с высокой квалификацией, набор возможностей и ресурсов которого выходит за рамки возможного (злоумышленник государственная спецслужба).

‘Таким образом, “Европейские критерии безопасности информационных технологий” появившиеся, вслед за “Оранжевой книгой” оказали существенное влияние на стандарты безопасности и методику сертификации. Главное достижение этого документа введение понятия адекватности средств защиты и определение отдель ной шкалы для критериев адекватности. Необходимо отметить, что “Европейские критерии” тесно связаны с “Оранжевой книгой”, что делает их не вполне самостоятельным документом.

На первый взгляд, довольно странным представляется факт, что “Европейские критерии” признают возможность наличия недостатков в сертифицированных по некоторому классу защищенных системах (критерий возможно сти использования недостатков защиты), однако на самом деле данный подход свидетельствует о реалистич ном взгляде на существующее положение дел.

43.17

Методы и средства защиты информационных объектов от вредоносных программ

5. Федеральные критерии безопасности информационных технологий

“Федеральные критерии безопасности информационных технологий” (Federal Criteria for Information Technology Security) разрабатывались как одна из составляющих “Американского федерального стандарта по обработке ин формации” (Federal Information Processing Standard), призванного заменить критерий TCSEC ”Оранжевую книгу”. Разработчиками стандарта выступили Национальный институт стандартов и технологий США (National Institute Of Standards and Technology) и Агентство национальной безопасности США (National Security Agency). Данный об зор основан на версии 1.0 этого документа, опубликованной в декабре 1992 г.

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

Основные положения

“Федеральные критерии безопасности информационных технологий” (далее “Федеральные критерии”) охва тывают практически полный спектр проблем, связанных с защитой и обеспечением безопасности, так как вклю чают все аспекты обеспечения конфиденциальности, целостности и доступности.

Основными объектами применения требований безопасности “Федеральных критериев” являются продукты информационных технологий (Information Technology Products) и системы обработки информации (Informa tion Technology Systems). Под продуктом информационных технологий (ПИТ) понимается совокупность ап паратных и программных средств, которая представляет собой поставляемое конечному потребителю гото вое к использованию средство обработки информации. Как правило, ПИТ эксплуатируется не автономно, а интегрируется в систему обработки информации, представляющую собой совокупность ПИТ, объединенных в функционально полный комплекс, предназначенный для решения прикладных задач (т.е. для реализации некоторой целевой функции компьютерной системы). В ряде случаев система обработки информации может состоять только из одного ПИТ, обеспечивающего решение всех стоящих перед системой задач и удовлетво ряющего требованиям безопасности.

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

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

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

“Федеральные критерии” представляют процесс разработки систем обработки информации, начинающийся с формулирования требований потребителями и заканчивающийся введением в эксплуатацию, в виде следу ющих основных этапов:

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

2.Разработка и сертификация ПИТ. Разработанные ПИТ подвергаются независимому анализу, целью которо го является определение степени соответствия характеристик продукта сформулированным в профиле за щиты требованиям и спецификациям.

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

43.18

Основные критерии защищенности автоматизированных систем

“Федеральные критерии” регламентируют только первый этап этой схемы разработку и анализ профиля защиты, процесс создания ПИТ и компоновка систем обработки информации остаются вне рамок этого стандарта.

Профиль защиты

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

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

•описание;

•обоснование;

•функциональные требования к ПИТ;

•требования к технологии разработки ПИТ;

•требования к процессу сертификации ПИТ.

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

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

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

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

Раздел требований к процессу сертификации ПИТ регламентирует порядок сертификации в виде типовой ме тодики тестирования и анализа. Объем и глубина требуемых исследований зависят от наиболее вероятных типов угроз, среды применения и планируемой технологии эксплуатации.

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

Разработка профиля защиты осуществляется в три этапа: анализ среды применения ПИТ с точки зрения бе зопасности, выбор профиля прототипа и синтез требований.

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

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

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

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

43.19

Методы и средства защиты информационных объектов от вредоносных программ

Функциональные требования к продукту информационных технологий

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

Функциональные требования, приведенные в “Федеральных критериях”, определяют состав и функциональ ные возможности ТСВ. Она объединяет все компоненты ПИТ (аппаратные, программные и специальные сред ства), реализующие функции защиты. Таким образом, функциональные требования, направленные на обес печение безопасности, относятся либо к внутренним элементам ТСВ, либо к ее внешним функциям, доступ ным через специальные интерфейсы. Для того чтобы расширить спектр потенциального применения профи ля защиты в “Федеральных критериях”, при описании функциональных требований предполагается, что ТСВ является единственной частью ПИТ, которая нуждается в защите и обладает такой характеристикой, как уро вень защищенности. По этой причине предполагается достаточным установить множество требований, ка сающихся только безопасности ТСВ. Функциональные требования профиля защиты задаются в виде общих положений и косвенным образом определяют множество угроз, которым может успешно противостоять удов летворяющий этим положениям ПИТ.

Структура функциональных требований

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

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

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

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

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

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

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

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

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

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

•Контроль скрытых каналов утечки информации включает технические и административные меры, на правленные на ликвидацию таких каналов посредством минимизации объема совместно используемых ресурсов и введения активных “шумовых помех”.

43.20

Основные критерии защищенности автоматизированных систем

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

•Контроль над распределением ресурсов осуществляется посредством введения ограничений (квот) на их потребление или приоритетной системы распределения ресурсов.

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

•компоновка, установка, конфигурация и поддержка компьютерной системы;

•администрирование атрибутов безопасности пользователей (идентификаторов, полномочий, доступных ресурсов и т.д.);

•администрирование политики управления доступом;

•управление потреблением ресурсов системы;

•аудит действий пользователей.

2.Мониторинг взаимодействий. Требования этого раздела регламентируют порядок взаимодействия между ком понентами системы и прохождения информационных потоков через компьютерную систему. Реализация полити ки безопасности будет эффективна только в том случае, если все без исключения взаимодействия в системе, т.е. доступ к объектам, ресурсам и сервису, осуществляются при обязательном посредничестве ТСВ (следовательно, требуется, чтобы ядро защиты представляло собой МБО см. гл. З).

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

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

4.Физическая защита ТСВ. Требования этой группы задают ограничения на физический доступ к компонен там ТСВ, а также допустимые физические параметры среды функционирования компьютерной системы.

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

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

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

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

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

Ранжирование функциональных требований

Состав и содержание включенных в профиль защиты функциональных требований определяются средой эксп луатации ПИТ. Чтобы обосновать выбор тех или иных требований и не вступать в противоречие с существующи ми стандартами в области безопасности ПИТ, функциональные требования, приведенные в “Федеральных кри териях”, ранжируются по уровням с помощью следующих четырех критериев: широта сферы применения, сте пень детализации, функциональный состав средств защиты, обеспечиваемый уровень безопасности.

Широта сферы применения определяется множеством сущностей, к которому могут быть применены данные требования, а именно:

• пользователи системы, субъекты и объекты доступа;

• функции ТСВ и интерфейс взаимодействия с компьютерной системой;

43.21

Методы и средства защиты информационных объектов от вредоносных программ

•аппаратные, программные и специальные компоненты ТСВ;

•множество параметров конфигурации ТСВ.

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

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

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

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

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

В связи с этим в “Федеральных критериях” отсутствуют рекомендации как по выбору и применению тех или иных функциональных требований, так и по определению их роли в системе обеспечения безопасности. Вместо жестких указаний этот документ содержит согласованный с предшествующими ему стандартами (“Оранже вая книга”, “Европейские критерии”) ранжированный перечень функциональных требований и предостав ляет разработчикам профиля защиты возможность самостоятельно сделать выбор необходимых методов и средств обеспечения безопасности, основанный на назначении и специфике среды эксплуатации ПИТ.

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

Применение критериев ранжирования к различным группам функциональных требований представлено в табл. 5 Знак “*” указывает, на какие значимые свойства компьютерной системы (широта сферы применения, сте пень детализации и т.д.) влияет реализация того или иного защитного механизма.

Требования к процессу разработки продукта информационных технологий

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

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

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

ляющей производителю ПИТ доказать соответствие самого продукта и технологии его изготовления выдви нутым требованиям.

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

“Федеральные критерии” содержат ранжированный перечень типовых требований к технологии разработки ПИТ [17]. Выполнение требований к технологии разработки является необходимым условием для проведе ния процедуры сертификации.

43.22

Основные критерии защищенности автоматизированных систем

Требования к процессу сертификации продукта информационных технологий

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

Требования к тестированию описывают процедуру тестирования функций компьютерной системы как самим разработчиком ПИТ, так и независимыми экспертами. Рассмотренные требования регламентируют процесс сертификации только в общих чертах и, по замыслу разработчиков стандарта, должны послужить основой для разработки специализированных методик сертификации, ориентированных на различные области при менения и классы ПИТ. В заключение отметим, что “Федеральные критерии безопасности информационных технологий” являются первым стандартом в области безопасности систем обработки информации, в кото ром определены и рассмотрены три независимые группы требований: функциональные требования к сред ствам защиты, требования к технологии разработки и требования к процессу сертификации. Авторами этого документа предложена концепция профиля защиты документа, содержащего полное описание всех требо ваний безопасности к процессу разработки, сертификации и эксплуатации ПИТ.

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

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

“Федеральные критерии безопасности информационных технологий” вместе с “Европейскими критериями безо пасности информационных технологий” и “Канадскими критериями безопасности компьютерных систем” послу жили основой при создании “Единых критериев безопасности информационных технологий”. Целью “Единых критериев” стала разработка на основе накопленного в разных странах опыта имеющихся стандартов, разроз ненных документов и подходов единого согласованного стандарта, лишенного концептуальных и технических раз личий, имевшихся у его предшественников. Работа над проектом началась в 1993 г., в конце 1996г. была опубли кована первая версия документа, а в марте 1998 г. вторая, доработанная и исправленная. “Единые критерии” адресованы трем группам специалистов: потребителям, производителям и экспертам по классификации. Они представляют новый, межгосударственный уровень в стандартизации информационных технологий.

43.23

Методы и средства защиты информационных объектов от вредоносных программ

6. РУКОВОДЯЩИЙ ДОКУМЕНТ Защита от НСД к информации (Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей)

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

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:

•к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;

•к содержанию испытаний.

Руководящий документ разработан в дополнение РД “Средства вычислительной техники. Защита от несанк ционированного доступа к информации. Показатели защищенности от несанкционированного доступа к ин формации”, М., Военное издательство, 1992 г., РД “Автоматизированные системы. Защита от несанкциониро ванного доступа к информации. Классификация автоматизированных систем и требования по защите инфор мации”, М., Военное издательство, 1992 г. и РД “Средства вычислительной техники. Межсетевые экраны. За щита от несанкционированного доступа к информации. Показатели защищенности от несанкционированно го доступа к информации”, М., 1997 г.

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

Общие положения

1.1.Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2.Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уро вень характеризуется определенной минимальной совокупностью требований.

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

1.4.Самый высокий уровень контроля — первый, достаточен для ПО, используемого при защите информа ции с грифом “ОВ”.

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом “CC”. Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом “C”.

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

Термины и определения

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

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

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

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

В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.

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

2.5.Маршрут выполнения функциональных объектов — определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6.Фактический маршрут выполнения функциональных объектов — последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

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

43.24

Основные критерии защищенности автоматизированных систем

2.8.Статический анализ исходных текстов программ — совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на струк турном анализе и декомпозиции исходных текстов программ.

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

Требования к уровню контроля

Требования к четвертому уровню контроля

Контроль состава и содержания документации

В состав документации, представляемой заявителем, должны входить:

•спецификация (ГОСТ 19.202 78), содержащая сведения о составе ПО и документации на него;

•описание программы (ГОСТ 19.402 78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описа ние методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;

•описание применения (ГОСТ 19.502 78), содержащее сведения о назначении ПО, области применения, при меняемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы;

•исходные тексты программ (ГОСТ 19.401 78), входящих в состав ПО.

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

Контроль исходного состояния ПО

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

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

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

Статический анализ исходных текстов программ

Статический анализ исходных текстов программ должен включать следующие технологические операции:

•контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;

•контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

Отчетность

По окончании испытаний оформляется отчет (протокол), содержащий результаты:

•контроля исходного состояния ПО;

•контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне фай лов;

•контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.

Требования к третьему уровню контроля

Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена “Пояснительная записка” (ГОСТ 19.404 79), содержащая основные све дения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (под схемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функци онирования и т.п.

Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявля ются следующие требования:

•контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объек тов (процедур);

•контроль связей функциональных объектов (модулей, процедур, функций) по управлению;

•контроль связей функциональных объектов (модулей, процедур, функций) по информации;

•контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

•формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

43.25

Методы и средства защиты информационных объектов от вредоносных программ

Динамический анализ исходных текстов программ

Динамический анализ исходных текстов программ должен включать следующие технологические операции:

•контроль выполнения функциональных объектов (процедур, функций);

•сопоставление фактических маршрутов выполнения функциональных объектов (процедур, функций) и мар шрутов, построенных в процессе проведения статического анализа.

Отчетность

Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (про токол) должен содержать результаты:

•контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функци ональных объектов (процедур);

•контроля связей функциональных объектов (модулей, процедур, функций) по управлению;

•контроля связей функциональных объектов (модулей, процедур, функций) по информации;

•контроля информационных объектов различных типов (например, локальных переменных, глобальных пере менных, внешних переменных и т.п.);

•формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);

•контроля выполнения функциональных объектов (процедур, функций);

•сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и мар шрутов, построенных в процессе проведения статического анализа.

Таблица 1.

Перечень требований

Обозначения:

“—” нет требований к данному уровню; “+” новые или дополнительные требования;

“=” требования совпадают с требованиями предыдущего уровня.

43.26

Основные критерии защищенности автоматизированных систем

Требования ко второму уровню контроля

Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:

•контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспе чения на уровне функциональных объектов (функций);

•синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) по тенциально опасных программных конструкций;

•формирование перечня маршрутов выполнения функциональных объектов (ветвей);

•анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для задан ных экспертом списков информационных объектов;

•построение по исходным текстам контролируемого ПО блок схем, диаграмм и т.п., и последующий срав нительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма рабо ты, приведенного в “Пояснительной записке”.

Динамический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:

•контроль выполнения функциональных объектов (ветвей);

•сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.

Отчетность

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (прото кол) должен содержать результаты:

•контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспе чения на уровне функциональных объектов (функций);

•синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) по тенциально опасных конструкций;

•формирования перечня маршрутов выполнения функциональных объектов (ветвей);

•анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для за данных экспертом списков информационных объектов;

•построения по исходным текстам контролируемого ПО блок схем, диаграмм и т.п., и последующего срав нительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма ра боты, приведённого в “Пояснительной записке”;

•контроля выполнения функциональных объектов (ветвей);

•сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.

Требования к первому уровню контроля

Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно предъявляют ся следующие требования:

•контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием серти фицированных компиляторов;

•семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потен циально опасных конструкций.

Динамический анализ исходных текстов программ

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

43.27

Методы и средства защиты информационных объектов от вредоносных программ

Отчетность

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно отчет (прото кол) должен содержать результаты:

•контроля соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием серти фицированных компиляторов;

•семантического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потен циально опасных конструкций.

43.28