Задачи противодействия внешним ИТ-угрозам. Способы решения

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

ЗАДАЧИ ПРОТИВОДЕЙСТВИЯ ВНЕШНИМ ИТ-УГРОЗАМ.
СПОСОБЫ РЕШЕНИЯ

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

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

ВВЕДЕНИЕ

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

С учетом сказанного можем сделать вывод, что именно процесс несет в себе уязвимость, когда речь заходит о внешних ИТ-угрозах, как следствие, задача обеспечения компьютерной безопасности в рассматриваемых приложениях в основе своей сводится к задаче контроля запуска и локализации действий процессов на защищаемом компьютере. В основе локализации действий процессов лежит реализация контроля доступа (разграничения прав доступа) к защищаемым ресурсам (естественно, что как к информационным, так и к системным ресурсам) для субъекта доступа ПРОЦЕСС. Как следствие, реализация данной технологии защиты предполагает принципиальное изменение самой схемы назначения и реализации разграничительной политики доступа к ресурсам, по сравнению со схемой, реализуемой в современных универсальных ОС, где в качестве субъекта доступа к ресурсам выступает ПОЛЬЗОВАТЕЛЬ (контроль доступа к ресурсам реализован для учетных записей пользователей).

Теперь замечание. Акцентируем внимание читателя на известной укрупненной классификации известных типов вирусов:

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

"Грэхем Ингрэм, главный управляющий австралийского подразделения Группы оперативного реагирования на чрезвычайные ситуации в компьютерной области (AusCERT) утверждает, что распространенные антивирусные приложения блокируют лишь около 20 процентов недавно появившихся вредоносных программ. При этом популярные антивирусы пропускают до 80 % новых троянов, шпионов и других вредоносных программ. Это означает, что в восьми из десяти случаев недавно появившийся вирус может проникнуть на компьютер пользователя" (www.itsec.ru, 24.07.2006 г.).

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

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

ЧАСТЬ 1. ПРОТИВОДЕЙСТВИЕ УГРОЗАМ СО СТОРОНЫ ПРОЦЕССОВ (ПРОГРАММ), АПРИОРИ ОБЛАДАЮЩИХ НЕДЕКЛАРИРУЕМЫМИ ВОЗМОЖНОСТЯМИ

1.1. ПРИНЦИП ДОВЕРИТЕЛЬНОГО КОНТРОЛЯ ДОСТУПА

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

Рисунок. Обработка данных критичным процессом

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

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

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

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

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

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

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

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

1.2. ПРИНЦИП ВЕРОЯТНОСТНОГО КОНТРОЛЯ ДОСТУПА

Второй случай характеризуется тем, что меру недоверия к процессу можно каким-либо образом категорировать, в этом случае можно говорить о какой-либо вероятности того, что после чтения документа процесс несет в себе угрозу НСД.

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

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

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

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

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

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

Будем считать, что чем выше полномочия субъекта и категория объекта, тем, соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов доступа - С = {С1,…, Ск} и О = {О1,…, Оk}). Пусть S = {0,Чт,Зп} – множество прав доступа, где "0" обозначает отсутствие доступа субъекта к объекту, "Чт" – разрешение доступа для чтения из объекта, "Зп" – разрешение доступа для записи в объект. Обозначим же через Pi вероятность того, что документ i-й категории "заражен" вирусом, при этом (как было сказано выше) априори имеем: P1 < P2 <…< Pk. Беря во внимание тот факт, что вирус начинает действовать (что может нести в себе угрозу "заражения") лишь после прочтения его соответствующим приложением, и что предотвращать следует возможность "заражения" документа более высокой категории вирусом из документа более низкой категории (после его прочтения приложением), получаем следующую матрицу доступа F, описывающую вероятностную модель контроля доступа, которая может быть использована для антивирусного противодействия:

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

Видим, что при реализации данной схемы вероятность "заражения" документа более высокой категории, например O1 (P1), не изменяется в связи с тем, что на том же компьютере обрабатывается информация более низкой категории, например, Ok (Pk). При этом, понимая, что режимы обработки информации различных категорий кардинально различаются получаем, что при обработке на одном компьютере открытой Оk и конфиденциальной информации О1, имеем: Pk >> P1, причем в зависимости от реализованных правил и организационных мер по обработке конфиденциальных данных это отношение может составлять сотни, тысячи и более раз, т.е. именно во столько раз можно снизить вероятность "заражения" конфиденциальных данных вирусами, хранящимися в открытых данных, для которых, можем принять Pk = 1.

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

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

- субъект имеет право доступа "Зп/Чт" к объекту в том случае, если полномочия субъекта и категория объекта совпадают;

- субъект имеет право доступа "Чт" к объекту в том случае, если полномочия субъекта выше, чем категория объекта;

- субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.

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

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

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

ЧАСТЬ 2. ПРОТИВОДЕЙСТВИЕ УГРОЗАМ СО СТОРОНЫ ВРЕДОНОСНЫХ ПРОГРАММ

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

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

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

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

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

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

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

Эффективный подход к реализации механизма обеспечения замкнутости программной среды состоит в задании разрешенных к запуску процессов (приложений) заданием перечня папок (каталогов, подкаталогов) на жестком диске, из которых пользователям разрешено запускать процессы. С учетом того, что должен контролироваться и запуск системных процессов, в качестве подобных папок целесообразно задавать каталоги C:\Program Files и C:\Winnt (WINDOWS). Данные каталоги должны запрещаться (не разрешаться) пользователям на запись, что предотвращает возможность модификации разрешенных на выполнение исполняемых файлов.

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

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

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

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

ЧАСТЬ 3. ПРОТИВОДЕЙСТВИЕ СЕТЕВЫМ АТАКАМ

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

3.1. ПРОТИВОДЕЙСТВИЕ УГРОЗАМ СО СТОРОНЫ КРИТИЧНЫХ (СЕТЕВЫХ) ПРИЛОЖЕНИЙ

3.1.1. ЛОКАЛИЗАЦИЯ ПРОГРАММНОЙ СРЕДЫ ДОСТУПА ВО ВНЕШНЮЮ СЕТЬ

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

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

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

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

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

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

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

3.1.2. ЛОКАЛИЗАЦИЯ ПРАВ ДОСТУПА КРИТИЧНЫХ (СЕТЕВЫХ) ПРИЛОЖЕНИЙ К КОМПЬЮТЕРНЫМ РЕСУРСАМ

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

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

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

3.2. ПРОТИВОДЕЙСТВИЕ УГРОЗАМ СО СТОРОНЫ КРИТИЧНЫХ (СЕТЕВЫХ) ПРИЛОЖЕНИЙ, ЗАПУСКАЕМЫХ С СИСТЕМНЫМИ ПРАВАМИ

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

3.2.1. РЕШЕНИЕ ЗАДАЧИ ЗАЩИТЫ В ОБЩЕМ ВИДЕ

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

Решение задачи защиты в данном случае основывается на том, что при управлении доступом к ресурсам (здесь нас интересуют файловые объекты и объекты реестра ОС) должны различаться два самостоятельных субъекта доступа – "пользователь" и "процесс", причем права доступа субъекта "процесс" должны устанавливаться и анализироваться эксклюзивно – вне прав пользователя (возможные режимы контроля доступа к ресурсам рассмотрены ранее). Рассмотрим, как использовать в рассматриваемом случае данный механизм защиты. Системному пользователю (рассмотрим на примере System) запретим доступ на запись к системному диску и к системным областям реестра ОС. При этом любое сетевое приложение, запущенное с правами системного пользователя доступ к этим объектам получить не сможет. Выделим системные процессы, которым подобное право доступа следует разрешить (в противном случае ОС не будет функционировать) – для этих процессов зададим эксклюзивный режим обработки запросов - доступ к объекту разрешается, если он разрешен процессу (права доступа пользователя не анализируются). К таким процессам относятся: winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe.

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

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

3.2.2. ЧАСТНОЕ РЕШЕНИЕ ЗАДАЧИ ЗАЩИТЫ

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

Частное решение состоит в разграничении прав доступа к системным ресурсам не для системного пользователя, а для конкретного приложения, запускаемого с системными правами. Данное решение также возможно лишь в случае, если в разграничительную политику доступа к ресурсам включен субъект "процесс".

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

3.3. КОНТРОЛЬ ИСПОЛЬЗОВАНИЯ КРИТИЧНЫМИ ПРИЛОЖЕНИЯМИ СЕРВИСОВ ОЛИЦЕТВОРЕНИЯ

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

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

Обозначим: Ixy — олицетворение потока с исходным идентификатором доступа x и олицетворяющим идентификатором доступа y. Представим Ixy в виде матрицы олицетворения I, отображающей варианты заимствования прав. Введем следующие обозначения. Пусть множество C = {C1…Cn} — линейно упорядоченное множество субъектов доступа. В качестве субъекта доступа Сk, k = 1…n рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа. Введем следующую иерархию субъектов доступа: чем меньше порядковый номер (идентификатор) k субъекта, тем большими полномочиями он обладает. Обозначим Xk — исходный идентификатор субъекта доступа Ck, Yk — олицетворяющий идентификатор субъекта доступа Ck.

Модель управления олицетворением контекстов защиты формально может быть описана следующим образом: элемент (Iij) матрицы олицетворения I назначается следующим образом: Iij = 1, если ; Iij = 0, если ; где i – порядковый номер исходного идентификатора субъекта доступа (номер строки в матрице олицетворения), j – порядковый номер олицетворяющего идентификатора субъекта доступа (номер столбца в матрице олицетворения). Т.е. разрешенными считаются олицетворения, не приводящие к повышению полномочий субъекта доступа.

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

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

а) позволяет запретить все некорректные олицетворения;

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

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

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

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

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

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

ЧАСТЬ 4. ПРОТИВОДЕЙСТВИЕ ШПИОНСКИМ ПРОГРАММАМ И ШПИОНСКИМ ФУНКЦИЯМ ПРИЛОЖЕНИЙ

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

4.1. ПРОТИВОДЕЙСТВИЕ ШПИОНСКИМ ПРОГРАММАМ

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

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

4.2. ПРОТИВОДЕЙСТВИЕ УГРОЗАМ СО СТОРОНЫ САНКЦИОНИРОВАННЫХ ПРОГРАММ, ОБЛАДАЮЩИХ ШПИОНСКИМИ ФУНКЦИЯМИ

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

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

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

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

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

ЧАСТЬ 5. АНАЛИЗ ПРИЛОЖЕНИЙ НА НАЛИЧИЕ НЕДЕКЛАРИРУЕМЫХ РАЗРАБОТЧИКОМ ФУНКЦИЙ. ЛОКАЛИЗАЦИЯ ФУНКЦИЙ ПРИЛОЖЕНИЙ

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

В заключение хочется обратить внимание читателя на два момента. Во-первых, автор надеется на то, что данный материал убедит читателя в том, что, если не все, то, по крайней мере, очень многие насущные задачи защиты информации могут быть эффективно решены СЗИ от НСД, если, конечно, это действительно продуманные комплексные средства защиты информации. Во-вторых, что современные универсальные ОС в большой мере уязвимы не только потому, что в них систематически обнаруживаются ошибки, а и по тому, что ими не реализуются механизмы защиты, которые могут эффективно использоваться в корпоративных приложениях (универсальное средство, есть универсальное средство). И, наконец, в-третьих, что изложенные в работе технологии защиты не являются некими гипотетическими решениями, которые потенциальны применимы в СЗИ от НСД. Все эти решения (на которые, к слову, получено 11 патентов на изобретения) практически реализованы и апробированы в Комплексной системе защиты информации (КСЗИ) "Панцирь-К" для ОС Windows 2000/XP/2003 (сертификат ФСТЭК №1144 от 17.01.2006). Заметим, что их реализация повлекла за собою и кардинальное изменение подходов к реализации интерфейсов механизмов защиты, однако рассмотрение этого самостоятельного вопроса построения СЗИ от НСД выходит за рамки настоящей работы.

Ваше мнение и вопросы присылайте по адресу infosec@groteck.ru

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

Задачи противодействия внешним ИТ-угрозам. Способы решения