Контакты
Подписка
МЕНЮ
Контакты
Подписка

Выбор СЗИ от НСД

Выбор СЗИ от НСД

В рубрику "Защита информации" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Читайте полный текст статьи "Выбор СЗИ от НСД", опубликованной в № 3-4 журнала "Information Security/Информационная безопасность"

ВЫБОР СЗИ ОТ НСД

Д.т.н., проф. А.Ю.Щеглов
ЗАО "НПП "Информационные технологии в бизнесе"
www.npp-itb.spb.ru

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

1. Назначение и общая классификация СЗИ от НСД.

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

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

Противодействие внутренним ИТ-угрозам.

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

Некоторые (далеко не полный список) недостатки механизмов защиты ОС Windows:


    1. Реализован дискреционный принцип контроля доступа к файловым объектам, предполагающий, что пользователь, создавший файловый объект (и ставший его "владельцем") может предоставить доступ к этому объекту другим пользователям.
    2. Ряд файловых объектов не разделяется ОС (например, папка All Users) и приложениями между пользователями.
    3. Буфер обмена не разделяется ОС между пользователями в случае запуска программы с правами другого пользователя (после его аутентификации) из проводника (утилита runas.exe).
    4. Не реализована разрешительная политика подключения устройств (ОС позволяет лишь запрещать подключение ранее подключенных к ней устройств). Разрешительная политика – это не запрет подключения конкретных устройств, а разрешение подключения только санкционированных устройств (желательно с анализом серийных номеров изготовителя), при этом по умолчанию запрещается подключать любое иное устройство.
    5. Отсутствие разграничений прав доступа для субъекта "процесс" (доступ разграничивается только для пользователей), что не позволяет локализовать среду исполнения для отдельных приложений.
    6. И т.д.

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

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

Противодействия внешним ИТ-угрозам.

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

Некоторые (далеко не полный список) недостатки механизмов защиты ОС Windows:


    1. Невозможность разграничить в полном объеме права доступа для пользователя System. При этом ОС предоставляет сервис запуска приложений (как правило, клиент-серверных) с системными правами. Ошибка в подобном приложении приводит к получению злоумышленником прав System, т.е. возможности полного управления защищаемым компьютером.
    2. Невозможность разграничивать права доступа для процессов и приложений, как следствие, любое приложение, в том числе, критичное, скомпрометированное и т.д. имеет те же права доступа, что и пользователь. Если это вирус, шпионская программа (либо приложение со шпионскими функциями) и т.д., они имеют доступ к данным пользователя, в том числе к конфиденциальной информации, что позволяет ее уничтожить или похитить.
    3. Неэффективный (частичный) контроль сервисов олицетворения (ОС Windows предоставляет возможность (предоставляет сервис разработчикам приложений) процессам (точнее, потокам, порождаемым этими процессами) при запросе доступа к ресурсам запросить у системы права другого пользователя – и обратиться к ресурсу с этими правами, т.е. в обход разграничительной политики доступа к ресурсам). С данным недостатком связаны, например, атаки на расширение привилегий.
    4. И т.д.

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

Проведенный анализ позволяет сделать следующий вывод.

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

2. Вопросы оценки эффективности СЗИ от НСД.

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

2.1. Оценка корректности реализации механизмов защиты СЗИ от НСД.

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

В NTFS файловый объект может быть идентифицирован различными способами:


    • Файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться как по длинному, так и по короткому имени, например к каталогу “\Program files\” можно обратиться по короткому имени “\Progra~1\”;
    • Файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например, короткое имя для каталога “C:\Documents and Settings\USER1\Главное меню” выглядит как “C:\Docume~1\USER1\5D29~1\”. К этим объектам также можно обратиться, как по длинному, так и по короткому имени;
    • Файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

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

Несколько других примеров.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

Исходя из вышесказанного, рекомендации автора по выбору эффективного решения сводятся к следующему:


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

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

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

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

Опубликовано: Сайт ITSec.Ru-2007

Приобрести этот номер или подписаться

Статьи про теме