--PAGE_BREAK--Программно-аппаратные комплексы «Secret Net» версии 4.0. предназначены для защиты информации, хранимой и обрабатываемой на автономных персональных компьютерах и рабочих станциях и серверах ЛВС, работающих под управлением операционных систем (ОС) Windows 95/98 и Windows NT/ 2000.
Основные возможности:
идентификация пользователей при помощи специальных аппаратных средств (Touch Memory, Smart Card, Smarty, Proximity и т.п.);
аутентификация по паролю длиной до 16 символов;
поддержка автоматической смены пароля пользователя по истечении заданного интервала времени;
аппаратная поддержка защиты от несанкционированной загрузки ОС с гибкого диска и CD-ROM диска;
разграничение доступа пользователей к ресурсам компьютера с помощью механизмов дискреционного и мандатного управления доступом;
создание для любого пользователя ограниченной замкнутой среды программного обеспечения (списка разрешенных для запуска программ);
управление временем работы всех пользователей;
возможность объединения пользователей в группы для упрощения управления их доступом к совместно используемым ресурсам;
регистрация действий пользователя в системном журнале;
поддержка для каждого пользователя индивидуальных файлов Config.sys и Autoexec.bat;
защита компьютера от проникновения и размножения вредоносных программ;
контроль целостности средств защиты, среды выполнения программ и самих прикладных программ;
гибкие средства администрирования системы защиты с использованием механизма привилегий, позволяющего распределить административные функции между различными пользователями компьютера.
Особенности сетевого варианта:
усиленная идентификация и аутентификация;
криптографическая защита данных;
централизованный мониторинг состояния безопасности информационной системы и управление защитными механизмами.
Сетевой вариант «Secret Net» предоставляет администратору безопасности возможность централизованного управления защитными механизмами клиентов «Secret Net», мониторинга состояния безопасности информационной системы, оперативного управления рабочими станциями в случае попыток НСД, централизованной обработки журналов регистрации и генерации отчетов.
КОМПЬЮТЕРНАЯ БЕЗОПАСНОСТЬ
ЧАСТЬ 1. ФУНКЦИОНАЛЬНОЕ НАЗНАЧЕНИЕ ДОБАВОЧНЫХ СРЕДСТВ ЗАЩИТЫ ИНФОРМАЦИИ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА
А. Щеглов, К.Щеглов
Вниманию читателя предлагается цикл статей под общим названием “Компьтерная безопасность”. В данных работах авторы попытаются изложить свою точку зрения, основанную на собственном опыте разработки добавочных средств защиты информации от несанкционированного доступа (СЗИ НСД) для ОС семейств Windows и Unix, по вопросам актуальности, функционального назначения и корректности реализации СЗИ НСД. Авторы нисколько не претендуют на роль экспертов в этих вопросах, а излагаемые материалы, которые в чем-то могут показаться читателю спорными, приводятся в порядке обсуждения. Поэтому авторы будут благодарны за отзывы и комментарии к данному материалу, готовы поддержать дискуссию на рассматриваемую тему и, по возможности, дать ответы на вопросы читателя, которые следует направлять по адресу: info@npp-itb.spb.ru.
Функциональное назначение добавочных средств защиты информации от несанкционированного доступа (СЗИ НСД) следует из самого понятия «добавочные» — они вносятся на защищаемый объект с целью добавления к встроенным (как правило, в ОС) механизмам защиты. Однако возникает вопрос – с какой целью вносятся добавочные механизмы защиты, как следствие, каково их функциональное назначение? Дав ответ на эти вопросы, можно судить и об актуальности практического использования СЗИ НСД.
Большинство разработчиков СЗИ НСД имеет мнение (такой вывод можно сделать на основании рассмотрения свойств большинства известных нам СЗИ НСД, и того, как позиционируют свойства СЗИ НСД разработчики этих средств), что добавление новых механизмов защиты реализуется, с целью добавления новых функциональных возможностей в систему защиты, т.е. функциональных свойств, не реализуемых встроенными механизмами.
Набор функциональных свойств защиты, с учетом уровня конфиденциальности защищаемой информации, формализован и прописан в соответствующих нормативных документах в области защиты информации [1]. В соответствии с данными документами и с учетом того, что защищаемый объект должен обладать заданным набором свойств защиты, естественно, что первоочередной задачей разработчиков СЗИ НСД является добавление свойств (соответственно механизмов, их реализующих), не реализуемых встроенными в ОС механизмами. В зависимости от класса защищенности, к таким свойствам можно отнести гарантированное удаление остаточной информации, полномочный (или мандатный) принцип контроля доступа к ресурсам и др. При определенных условиях (в частности, если не проведены соответствующие уровню конфиденциальности обрабатываемой информации сертификационные испытания встроенных в ОС механизмов защиты), к добавочным СЗИ НСД выдвигается требование по реализации своими собственными средствами всех механизмов защиты, регламентируемых нормативными документами (о встроенных в ОС механизмах защиты в этом случае можно забыть).
Кроме того, как правило, добавочные СЗИ НСД привносят и некоторые дополнительные возможности, не регламентируемые нормативными документами в области защиты информации, в большинстве случаев, это относится к подключению дополнительных устройств аутентификации пользователя – электронные ключи, Flash-устройства и др., а также контроля действий пользователя на защищаемых объектах (в дополнение к решению задач аудита).
Заметим, что сама по себе задача добавления новых свойств защиты весьма не тривиальна (отнюдь не только в части реализации механизма защиты) и требует серьезных исследований, в первую очередь, принципов построения самой ОС. В качестве примеров возникающих проблем, например, для упоминавшихся выше механизмов защиты, можем отметить следующее. Если речь идет о мандатном управлении доступом к ресурсам, можно говорить о проблемах назначения меток безопасности иерархическим объектам, о включении в иерархические уровни – уровня «система» (как субъекта, так и объекта доступа), о необходимости разделения средствами СЗИ НСД файловых объектов, не разделяемых системой и приложениями [2], без чего, на наш взгляд, вообще нельзя говорить о корректности реализации полномочного принципа контроля доступа, и т.д. Если, например, рассматриваем вопросы гарантированного удаления остаточной информации, то должны учитывать, что при сохранении информации небольшого объема (где-то менее 1Кб), она располагается ОС не только в соответствующем файле, но и в таблице MFT (NTFS), и в журналах изменений.
Заметим, что вопросы корректности реализации СЗИ НСД (корректности, в смысле, не внесения дополнительных уязвимостей в систему) требуют самостоятельного исследования, поэтому их рассмотрению мы посвятим отдельную часть нашей работы (естественно, ни в коей мере, не предполагается рассмотрение уязвимостей современных СЗИ НСД, речь идет лишь о требованиях к корректности их реализации, вытекающих из широко известных и опубликованных архитектурных особенностей ОС).
Обобщая сказанное выше, можем определить следующее функциональное назначение добавочных СЗИ НСД:
Дополнение встроенной защиты новыми механизмами, с целью выполнения требований к защите информации соответствующего уровня конфиденциальности, заданных в нормативных документах в области защиты информации.
Дополнение встроенной защиты новыми возможностями, не регламентируемыми нормативными документами в области защиты информации, в большинстве случаев, это относится к подключению дополнительных устройств аутентификации пользователя – электронные ключи, Flash-устройства и др., а также контроля действий пользователя на защищаемых объектах (в дополнение к решению задач аудита).
Для ряда приложений, к добавочным СЗИ НСД выдвигается требование по реализации своими собственными средствами всех механизмов защиты, регламентируемых нормативными документами (без учета встроенных в ОС механизмов).
Таким образом, видим, что выше речь шла о внесении добавочными средствами СЗИ НСД некоторых новых дополнительных механизмов защиты, в некоторых же приложениях – дополнительно требуется повторить (этот вопрос требует некоторых уточнений и мы вернемся к нему в одной из следующих частей работы, вместе с рассмотрением вопросов корректности реализации СЗИ НСД) функции встроенных механизмов защиты, присутствующих в ОС, добавочными средствами. Но попробуем ответить на вопрос – а сами то встроенные в ОС механизмы защиты хороши, их функционала достаточно для обеспечения надежной защиты информации от НСД.
Для ответа на эти вопросы можем, обратиться, например, к работе [3], где приведена (получена из открытых источников) и классифицирована современная статистика найденных уязвимостей в ОС и приложениях, соответственно, к работе [4], где проведен краткий анализ причин возникновения основных уязвимостей, во многом, на наш взгляд, возникновение которых связано именно с архитектурными недостатками и принципами построения встроенных в ОС средств защиты. Анализируя же известную статистику уязвимостей ОС и приложений, и, наверное, это ни для кого сегодня не секрет, можем сделать вывод о том, что свойства встроенных во многие ОС механизмов защиты не столь хороши, как хотелось бы.
Следуя сказанному, можем определить следующую важную (а, на наш взгляд, так важнейшую) функциональную задачу добавочных СЗИ НСД:
Устранение архитектурных недостатков встроенных в ОС механизмов защиты, с целью противодействия, атакам, использующим как известные, так и потенциально возможные уязвимости ОС и приложений.
В качестве замечания отметим, что, во-первых, здесь речь идет не о решении новых задач защиты, в дополнение к задачам, решаемым встроенными механизмами, а о добавлении новых свойств защиты для повышения эффективности решения тех задач, для которых предназначены встроенные механизмы защиты, во-вторых, важнейшим условием эффективной защиты является противодействие именно «потенциально возможным уязвимостям». Наличие потенциальной возможности уязвимости обнаруживается в результате анализа собственно архитектуры построения ОС, при этом известная уязвимость может натолкнуть исследователя на выявление причины. Средствами же СЗИ НСД нужно противодействовать самой причине (устранять причину) возникновения уязвимости – только в этом случае задача защиты может быть решена в общем виде. В противном случае – если будем противодействовать конкретным уязвимостям, получим решение задачи, очень близкое по своей сути к существующим подходам – устранение уязвимостей, за счет внесения обновлений ОС и приложений (о том, к чему это приводит, поговорим в следующей части нашей работы, которую посвятим вопросам исследования надежности защиты информации).
Теперь, чтобы нас не обвинили в голословности, рассмотрим всего лишь одно запатентованное нами решение (сегодня по реализации механизмов защиты нами подано 17 заявок на изобретение, уже получено 11 патентов), и посмотрим, какие новые свойства защиты информации оно в себе несет. Заметим, что данное решение нами практически реализовано и апробировано.
Основу принципов контроля доступа к ресурсам составляет задание прав и разграничение на основании определенных правил доступа субъектов (пользователей) к объектам, в частности, к файловым объектам. Данный способ контроля доступа реализуется современными средствами защиты информации от НСД, в частности ОС, и формализован в соответствующих нормативных документах.
При этом любой процесс, запускаемый пользователем (в том числе, и пользователем System), наследует права доступа пользователя, его запустившего. Другими словами, поток, порождаемый процессом, обращается к ресурсу с правами пользователя (если, естественно, не произведено олицетворения с маркером безопасности другого пользователя, но это отдельный вопрос).
Однако, именно процесс, может нести в себе уязвимость несанкционированного доступа к информации. Тому может быть несколько причин, во-первых, процесс априори может обладать недекларированными (документально не описанными) свойствами, в частности, это процессы, являющиеся средой исполнения (прежде всего, это виртуальные машины, являющиеся средой исполнения для скриптов и апплетов, и офисные приложения, являющиеся средой исполнения для макросов), во-вторых, процесс может быть скомпрометирован – содержать ошибки, использование которых позволяет осуществить несанкционированный доступ к информации (наиболее критичными сегодня являются ошибки переполнения буфера приложений и некорректность использования приложениями сервисов олицетворения, приводящие к расширению привилегий пользователей, как правило, получение привилегий пользователя System, с правами которого запускаются данные приложения).
Таким образом, может быть обозначена проблема осуществления контроля доступа к ресурсам с учетом доверия к процессам, а также с учетом решаемых задач и особенностей функционирования процесса. Естественно, что это возможно только в том случае, если процесс можно рассматривать, как самостоятельный субъект доступа, а не субъект, наследующий права доступа пользователя (в противном случае, следует говорить о доверии к пользователю, а не к процессу).
Основу предлагаемого нами механизма контроля доступа процессов к ресурсам, составляет включение в схему разграничения прав доступа к ресурсам, наряду с субъектом доступа «пользователь», субъекта доступа «процесс», в предположении, что права доступа этих субъектов могут не совпадать (еще раз напомним, что в системе процесс запускается с правами пользователя, его запустившего).
Предлагаемое нами запатентованное решение (Патент № 2207619) состоит в следующем. В общем случае при управлении доступом к ресурсам следует различать два самостоятельных субъекта доступа – «пользователь» и «процесс». При этом предлагается управлять доступом (разграничивать права доступа) не только для субъекта пользователь, но и для субъекта процесс, причем могут быть выделены следующие схемы задания разграничительной политики доступа к ресурсам:
Разграничение прав доступа к объектам процессов вне разграничений пользователей (эксклюзивный режим обработки запросов процессов — доступ к объекту разрешается, если он разрешен процессу – права доступа пользователя, запустившего процесс не учитываются. Данная схема разграничений может использоваться в том случае, когда процессу следует расширить права доступа к ресурсам, по сравнению с пользователем, запустившим процесс);
Разграничение прав доступа к объектам пользователей, вне разграничений процессов (эксклюзивный режим обработки запросов пользователей — доступ к объекту разрешается, если он разрешен пользователю – права доступа процесса не учитываются. Это обычная схема разграничений прав доступа, используемая современными ОС, не позволяющая учитывать свойства отдельных процессов, в частности, уровень доверия к ним);
Комбинированное разграничение прав доступа — разграничение прав доступа к объектам процессов в рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей — доступ к объекту разрешается, если он разрешен и пользователю, и процессу. Данная схема разграничений может использоваться в том случае, когда процессу следует сузить права доступа к ресурсам, по сравнению с пользователем, запустившим процесс).
Укрупненный алгоритм анализа прав доступа к ресурсу при реализации данной технологии, приведен на рис. 1.
Рисунок 1 — Укрупненный алгоритм анализа прав доступа к ресурсам
Кликните по схеме для увеличения масштаба
Таким образом, применение данного подхода позволяет устанавливать и анализировать для субъекта «процесс» права доступа к ресурсам, как для самостоятельного субъекта доступа.
Заметим, что в соответствии с описанием запатентованного решения, могут использоваться различные механизмы управления доступом к ресурсам процессов (как избирательный, так и полномочный) – суть запатентованного решения состоит в том, что права доступа процесса к ресурсу могут отличаться от прав доступа пользователя (назначаются для процесса, как для самостоятельного субъекта доступа), запустившего данный процесс, к этому ресурсу.
Применение данной технологии позволяет получить множество принципиально новых свойств защиты.
В качестве примера возможностей предлагаемого подхода, проиллюстрируем появляющуюся возможность противодействия атакам на расширение привилегий. В общем виде (не применительно к конкретной уязвимости скомпрометированного процесса) противодействовать данным атакам возможно лишь в том случае, если устранить привилегии пользователя, от которого запускается скомпрометированный процесс – в данном случае пользователя System – при это теряется сам смысл атаки на получение прав пользователя System.
Применительно к данной задаче, речь пойдет о назначении эксклюзивных прав доступа так называемым привилегированным процессам (процессам, доступ которых к ресурсам должен разграничиваться вне прав доступа, устанавливаемых для пользователей).
Теперь определимся с тем, как необходимо разграничить права доступа для пользователя System, чтобы противодействовать в общем виде атакам на повышение привилегий. Естественно, что, прежде всего, необходимо запретить ему право на «запись» (модификацию) системного диска, право на модификацию каталогов, где расположены исполняемые файлы разрешенных к запуску процессов, а также запретить право на запись (модификацию) значимых ветвей и ключей реестра ОС, в частности, отвечающих за политику безопасности системы.
Установка запрета доступа «на запись» к системному диску и к значимым ветвям и ключам реестра ОС для пользователя System связано с включением в схему разграничения прав доступа привилегированных процессов – здесь системных процессов и процессов СЗИ НСД, для которых устанавливаются права доступа вне прав пользователя, в частности, этим системным процессам и процессам СЗИ НСД для корректного функционирования системы и СЗИ НСД вне прав пользователя «System» разрешается запись на системный диск.
Пример настройки механизма управления доступом к файловым объектам для виртуального пользователя «System» для ОС Windows технологии NT представлен в Табл. 1.
Таблица 1
Кликните по таблице для увеличения масштаба
Замечание. Данные настройки обеспечивают корректное функционирование системы и офисных приложений. При использовании иных приложений на компьютере (прежде всего, запускаемых с системными правами), может потребоваться модификация данных настроек.
Настройки выполнены в следующих предположениях: системным является диск C:\, исполняемые файлы программ, разрешенных для выполнения, располагаются в каталогах: C:\Winnt (WINDOWS) – системные процессы, C:\Program Files – каталог, в который администратором инсталлируются разрешенные пользователям для выполнения программы. СЗИ НСД установлена на системный диск в каталог: C:\СЗИ НСД.
Заметим, что выделенным привилегированным процессам (системным процессам и процессам СЗИ НСД) в наших настройках (см. Табл. 1) права доступа к файловым объектам не ограничены. При необходимости, можно проанализировать (это можно осуществить с использованием средств аудита СЗИ НСД), к каким конкретно файловым объектам необходимо разрешить обращаться привилегированным процессам и разрешить им доступ (вне прав пользователей) только к этим объектам.
Аналогично могут быть сформированы и права доступа к объектам реестра ОС. Пример настройки механизма управления доступом к объектам реестра ОС для виртуального пользователя «System» (где также необходимо вводить привилегированные процессы) для ОС Windows технологии NT представлен в Табл. 2.
Таблица 2
Кликните по таблице для увеличения масштаба
Замечание. Заметим, что выделенным привилегированным процессам (системным процессам и процессам СЗИ НСД) в наших настройках (см. Табл. 2) права доступа к объектам реестра ОС не ограничены. При необходимости, можно проанализировать (это можно осуществить с использованием средств аудита СЗИ НСД), к каким конкретно объектам реестра ОС необходимо разрешить обращаться привилегированным процессам и разрешить им доступ (вне прав пользователей) только к этим объектам. Проиллюстрируем сказанное примером. Представленные разграничения для процесса Lsass.exe обеспечивают запрет работы с учётными записями пользователей. Наиболее распространенные действия злоумышленника при получении системных прав сводятся к заведению новой учетной записи в системе в группе администраторов, с последующим доступом в систему под этой учетной записью. При данных разграничениях завести нового пользователя в системе, имея права System, становится невозможным.
Из Табл.1 и Табл.2 видим, что при данных настройках системы защиты теряется какой-либо смысл атак на расширение привилегий, т.к. у пользователя System становится прав на доступ к ресурсам меньше, чем у любого другого пользователя, зарегистрированного в системе.
В качестве замечания отметим, что, во-первых, рассмотренные в статье решения (в частности, приведенные настройки механизма защиты) апробированы при создании семейства СЗИ НСД – КСЗИ «Панцирь» (для ОС семейств Windows и Unix) — разработка НПП «Информационные технологии в бизнесе», во-вторых, они либо уже запатентованы, либо находятся в стадии патентования, поэтому без нарушения авторских прав, рассмотренные в работе технологии не могут быть реализованы в разработках иных производителей.
В порядке иллюстрации, покажем, как выглядит интерфейс настройки механизма контроля доступа к файловым объектам для субъекта процесс в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, см. рис.2 (настройками, представленными на рис.2, выделяются привилегированный процессы – процессы могут быть заданы полнопутевым именем хранения их исполняемых файлов, полнопутевым именем папки (тогда для всех процессов, исполоняемые файлы которых хранятся в этой папке, будут действовать установленные разграничения), маской, которым разрешен полный доступ (ничего не запрещено) ко всем ресурсам.
В качестве замечания отметим, что в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003 процесс, как самостоятельный субъект доступа, включен во все механизмы управления доступом к ресурсам: к локальным и разделенным в сети (по входу и выходу) файловым объектам – на жестком диске и устройствах ввода, включая Flash-устройства, к объектам реестра ОС, к портам, к сетевым ресурсам (задача межсетевого экранирования). Подобный же подход реализован и в наших СЗИ НСД для ОС семейства Unix (HP-UX, Linux, Free BSD).
Рисунок 2 — Интерфейс настройки механизма контроля доступа к файловым объектам для субъекта процесс, реализованный в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003
Кликните по рисунку для увеличения масштаба
С защитой системного диска связаны и вопросы корректности реализации механизма обеспечения замкнутости программной среды, т.к. на системном диске находятся исполняемые файлы системных процессов, возможность модификации которых необходимо предотвратить. продолжение
--PAGE_BREAK--