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

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

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

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

Требование к корректности реализации – СЗИ от НСД должна разделять буфер обмена (между пользователями, процессами, категориями (в зависимости от разграничений).

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

В NTFS все данные, хранящиеся на томе, содержатся в файлах. Главная таблица файлов (MFT) занимает центральное место в структуре NTFS-тома. MFT реализована, как массив записей о файлах, где каждая запись представляет собой совокупность пар атрибутов и их значений. Размер каждой записи фиксирован и равен 1 Кб. Если размер файла достаточно мал, чтобы поместиться в теле записи, то данные такого файла хранятся непосредственно в MFT.

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

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

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

Возникает вопрос, отражены ли данные требования в нормативных документах и в каком виде? Достаточно ли их для оценки корректности реализации механизмов защиты в СЗИ от НСД?

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

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

2.2. Оценка достаточности (полноты) набора механизмов защиты в составе СЗИ от НСД.

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

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

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

· Разграничение по учетным записям (обработка данных каждой категории под собственной учетной записью). Достоинства: обработка данных различных категорий с различными привилегиями пользователей, возможность задания разграничений ко всем ресурсам, возможность одновременной работы с данными различных категорий (без перезагрузки – запуск приложения «с правами другого пользователя».

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

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

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

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

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

Поэтому и в данном случае – для анализа достаточности набора механизмов в СЗИ от НСД для решения конкретных задач защиты информации, нам остается только рекомендовать потребителю привлекать специалистов (естественно, из числа разработчиков) на стадии выбора СЗИ от НСД.

3. Рекомендации по выбору эффективного решения.

Подытоживая все сказанное ранее, определимся с исходными для выбора эффективного решения посылами: