Вы находитесь в разделе Типовых решений систем безопасности
Как противодействовать инсайдерским атакам?На сегодняшний день нормой обработки информации в корпоративных приложениях становится работа пользователя на одном и том же компьютере, как с открытой, так и с конфиденциальной информацией, требующих для обработки различной номенклатуры ресурсов. Это существенно расширяет потенциальную возможность хищения (нарушения конфиденциальности) данных санкционированным пользователем (пользователем, допущенным к работе на вычислительном средстве в рамках выполнения своих служебных обязанностей – инсайдером) и несанкционированной модификации (нарушения доступности и целостности) конфиденциальных данных, в результате обработки на том же компьютере открытой информации. Общий подход к решению задачи защиты Из теории защиты информации известно, что эффективная защита может быть построена только на основе реализации разграничительной политики доступа к ресурсам (механизмы контроля, в частности контентного контроля, по очевидным причинам могут использоваться лишь как вспомогательные). Однако, как в существующих требованиях к средству защиты, так в известных практических реализациях – в ОС и в приложениях, применение разграничительной политики предполагается для разграничения доступа различных пользователей, допущенных к обработке информации на компьютере, к ресурсам. При реализации же защиты информации от инсайдерских атак, задача реализации разграничительной политики доступа к ресурсам уже иная собственно в своей постановке – необходимо разграничивать режимы обработки различных категорий информации на одном компьютере для одного и того же пользователя (а не доступ к ресурсам между различными пользователями). Правильнее здесь уже говорить не о разграничительной, а о разделительной политике доступа к ресурсам. Как следствие, необходимы совершенно иные подходы решению задачи защиты, а механизмами защиты должны выполняться совсем иные требования. Рассмотрим в данной работе возможный апробированный подход к решению задачи защиты и сформулируем требования, реализация которых необходима для эффективного решения задачи защиты от инсайдерских атак. Поскольку на одном компьютере обрабатывается информация различных уровней конфиденциальности, и при этом обработка информации различных уровней конфиденциальности требует различных ресурсов (различные приложения, файловые объекты, устройства, сетевые ресурсы, и т.д., и т.п.), причем, как правило, чем ниже уровень конфиденциальности обрабатываемой информации, тем шире номенклатура ресурсов может использоваться при ее обработке (что и составляет потенциальную угрозу хищения конфиденциальной информации), задача защиты информации состоит в формировании и изолировании режимов обработки информации различных уровней конфиденциальности. Формирование режимов обработки категорированной информации состоит в подключении соответствующего набора ресурсов при обработке информации каждого уровня конфиденциальности. Изолирование режимов обработки категорированной информации состоит в противодействии любой возможности изменения режима обработки (санкционированного набора ресурсов) информации каждого уровня конфиденциальности. При реализации подобного подхода уже нечего контролировать, т.к. предотвращается сама возможность хищения конфиденциальной информации, за счет использования несанкционированных (не используемых для ее обработки) ресурсов. Решая задачу защиты информации, необходимо учитывать, что в общем случае защита состоит, не только в противодействии хищению конфиденциальной информации (нарушению конфиденциальности информации), но и в обеспечении ее доступности и целостности. Рассматриваемый в работе подход к реализации защиты от инсайдерских атак, состоящий в реализации разделительной политики доступа к ресурсам, проиллюстрирован на Рис.1.  Рис. Иллюстрация рассматриваемого подхода к реализации защиты от инсайдерских атак Требования к локализации компьютерных ресурсов (формирование объекта защиты) Нельзя защищать (если же, конечно, говорить об эффективной защите) тот объект, функциональность которого не определена. В частности, рассматриваемый нами подход к защите состоит в формировании режимов обработки категорированной информации - должна быть реализована разделительная политика доступа к ресурсам, состоящем в подключении соответствующего набора ресурсов при обработке информации каждого уровня конфиденциальности. Как следствие, набор ресурсов, подключение которых возможно к системе, должен жестко регламентироваться. К подобным ресурсам, в первую очередь, можно отнести устройства и приложения. Как следствие, основополагающими задачами локализации компьютерных ресурсов (формирование объекта защиты) являются:
Итак, используя механизм управления монтированием устройств, необходимо локализовать на каждом компьютере предприятия работу пользователя с необходимым и достаточным, для выполнения его профессиональных задач, набором устройств, обеспечивающих возможность решения соответствующих функциональных задач, например, доступ в сеть только по локальной сети, причем только по проводным каналам, печать на локальном, либо (и) сетевом принтере, использование накопителей, пусть конкретных (по серийным номерам) Flash-устройств и т.д. Все иные устройства, при всем их разнообразии, подключить к системе становится невозможным, следовательно, доступ к ним разграничивать не потребуется. Все это относится и к серверам, естественно, с соответствующей оговоркой. Все сказанное в полной мере относится и к локализации ПО (системного и прикладного) на защищаемом компьютере, которое также определяет функциональность объекта защиты. На самом деле, решение этой задачи весьма просто в реализации и последующей настройки механизма защиты. Требуется разрешить (опять же разрешительная политика) запуск исполняемых файлов из ограниченного числа объектов (папок) жесткого диска, возможность модификации которых предотвратить для пользователей. Получаем, что пользователь сумеет запускать только те программы (системные и прикладные), которые установлены администратором. Какой бы вредоносный код он не имел для обхода защиты, запустить данное несанкционированное ПО ему не удастся. Решение данной задачи защиты уже позволяет вести речь о достаточности механизмов защиты, в противном случае, номенклатура угроз возрастает катастрофически, а задача защиты становится неразрешимой. Замечание. Реализация замкнутости программной среды является основным шагом при решении практически любой задачи защиты информации. Хотите нормально решить антивирусную задачу защиты, активизируйте подобный механизм защиты, и забудете обо всех троянах, сниферах, шпионских и прочих вредоносных программах, обо всех типах вирусных атак, направленных на модификацию системного и прикладного ПО. Запустить их станет невозможно! В части противодействия ошибкам в ПО, этот механизм защиты не позволит запустить эксплойты и т.д. Когда речь заходит о защите серверов, а не рабочих станций, необходимо уже обеспечивать замкнутость программной среды и применительно к системным пользователям (что, например, не позволяет делать ОС Windows – запретите пользователю System запись на системный диск и увидите синий экран). Правда, это уже задача защиты, скорее, от сетевых атак. Она также может быть успешно решена, но уже при реализации разграничительной политики доступа к ресурсам для субъекта процесс – запрещаете модификацию системного диска пользователю System, а необходимым системным процессам (их не более десятка), которые при реализации замкнутости программной среды не могут быть модифицированы, подобную возможность следует разрешить. При этом даже с системными правами запуск вредоносного ПО становится невозможен. Однако локализация функций защищаемого объекта не ограничивается набором устройств и ПО – это и корректность функционирования системного ПО, т.е. собственно системы. Третий необходимый механизм – это защита системных ресурсов, так же напрямую связан с формированием объекта защиты. К этим объектам можно отнести системный диск, исполняемые файлы и файлы настроек приложений, для ОС Windows, кроме того, системный реестр. Вопросы защиты системных файловых объектов мы рассмотрели выше (без их защиты невозможна корректная реализация замкнутости программной среды). В части защиты реестра ОС достаточно предотвратить возможность несанкционированной модификации пользователями ветви: (для серверов и пользователей с системными правами) HKEY_LOCAL_MACHINE. Для серверов, соответственно, для пользователей с системными правами, здесь опять же потребуется разграничение доступа к объектам реестра ОС для субъекта процесс. Итак, в результате применения трех рассмотренных механизмов защиты будет сформирован объект защиты. Только после этого в принципе становятся уместными какие-либо разговоры о достаточности механизмов защиты, как следствие, вообще о принципиальной возможности защиты информации, обрабатываемой данным объектом. Требование 1. В объекте защите должен быть локализован набор ресурсов, подключение которых возможно к системе, должны защищаться системные ресурсы от несанкционированной модификации. Замечание. Три рассмотренных механизма должны быть реализованы при решении любой функциональной задачи защиты (внешние и внутренние ИТ-угрозы, антивирусная защита и др.). Лишь после их реализации можно начать разговоры о том, какие еще и почему механизмы защиты могут понадобиться. Общие требования к реализации разграничительной политики доступа к ресурсам Итак, как ранее отмечали, защита информации должна реализовываться разграничительной политикой доступа к ресурсам, к тем ресурсам, которые необходимы для выполнения служебной деятельности сотрудником компании, и потому, разрешены для монтирования (подключения) к системе. При этом один и тот же пользователь в рамках выполнения своих служебных обязанностей должен обрабатывать, как открытые, так и конфиденциальные данные. Однако априори эти данные имеют совершенно различную ценность для предприятия, следовательно, режимы их обработки принципиально различаются (например, только открытую информацию можно передавать во внешнюю сеть, сохранять на внешних накопителях, конфиденциальные данные могут обрабатываться только неким корпоративным приложением и т.д., сохраняться на накопителе только в зашифрованном виде, причем наличие ключа шифрования не должно давать пользователю возможность нарушить ее конфиденциальность и т.д.). Введем основополагающее для рассматриваемых приложений защиты информации понятие сессия. Под сессией пользователя будем понимать режим обработки пользователем данных соответствующей категории, реализуемый соответствующей разграничительной политикой доступа к ресурсам. По категории обрабатываемых в сессии данных, будем соответствующим образом подразделять на категории и сессии: открытая, конфиденциальная и т.д. Первый вопрос, возникающий, в части реализации сессионного контроля доступа, состоит в том, а допустим ли обмен информацией между сессиями (если да, то по каким правилам), либо обработка информации в сессии должна быть полностью изолированной (в этом случае пользователь получает возможность доступа к информации иной категории только посредством смены сессии). Требование 2. Обработка информации между сессиями различной категории должна быть полностью изолированной. Данное требование может быть сформулировано, исходя собственно из постановки задачи защиты информации от несанкционированного доступа (НСД), включающей защиту от нарушения конфиденциальности (хищения) данных и обеспечение доступности и целостности (противодействие несанкционированному искажению и удалению) данных. При попытке реализации обмена данными в сессиях различной категории (для одного пользователя), сталкиваемся со следующим противоречием. С одной стороны, можно было бы разрешить чтение (не запись) документов, предназначенных для обработки в менее конфиденциальной сессии, как следствие, информация более низкой категории может обрабатываться в более жестком режиме, что, само по себе, не очень разумно, но осуществляется противодействие понижению категории документа. Подобные правила реализуются, так называемым, принципом мандатного контроля доступа к ресурсам, состоящем в следующем:
Так в чем же состоит противоречие? Дело в том, что нельзя разрешать подобную возможность обмена, совершенно из иных требований к защите информации от НСД, т.к. запись при этом разрешается в объекты категории выше, чем категория прочтенных документов, а чем ниже категория (например, открыто), тем выше вероятность заражения документов вирусами, как следствие, получаем стремительный рост вероятности несанкционированной модификации (нарушения целостности и доступности) данных высокой категории, в результате прочтения данных низкой категории (т.е. именно тех данных, которые, в первую очередь, и должны защищаться от НСД). Вследствие сказанного, получаем требование к единственно возможному корректному решению - обработка информации между сессиями различной категории должна быть полностью изолированной, что и составляет основу разделительной политики доступа к ресурсам. Доступ же к данным иной категории возможен лишь в результате смены сессии. Замечание. Как видим, при реализации подобного подхода оказывается противодействие и вирусным атак, в данном случае атакам со стороны макро-вирусов. Действительно, они не только не имеют доступа к системным ресурсам (об это мы говорили в начале работы), но за счет изолированности сессий исключается возможность атаки на конфиденциальные данные макро-вирусами, содержащимися в открытых документах. Причем для подобной защиты не требуется какого-либо анализа каких-либо сигнатур. С учетом же того, что вероятность заражения макро-вирусами открытых документов на порядки выше, чем конфиденциальных (различные режимы обработки информации различных категорий конфиденциальности), на порядки снижается и вероятность вирусной атаки на конфиденциальные данные, при обработке на одном компьютере, как открытой, так и конфиденциальной информации. Замечание. Вообще говоря, альтернативные задачи защиты, как в своей постановке, так и по способам решения, во многом пересекаются. Как видели, решая задачу защиты от инсайдерских атак, хотим мы того или нет, но попутно мы решаем задачи антивирусные защиты, задачи защиты от внешних угроз и т.д. Поэтому, в общем случае, следует говорить о комплексном подходе к решению задачи защиты, о комплексных средствах защиты информации, но это уже вопрос иного исследования. Продолжим. Следующий вопрос – это как определять сессию, какая сущность должна служить субъектом доступа при реализации разграничительной политики доступа к ресурсам, ведь один и тот же пользователь должен обладать возможностью работы в нескольких сессия (с информацией различных категорий конфиденциальности)? На первый взгляд, казалось бы, логичным определять сессию категорией объекта доступа. Другими словами, к объекту какой категории обратился (например, прочитал файловый объект), та сессия обработки и запускается (заметим, что именно такой подход и реализуется мандатным принципом контроля доступа, о котором мы упоминали ранее). Однако в этом случае сразу же получаем следующее противоречие. Если сессия определяется тем, какие данные считаны (например, если считываются конфиденциальные данные, то вступает в силу конфиденциальная сессия – режим обработки конфиденциальных данных), то необходимо в начальный момент времени (сессия не определена) разрешить пользователю чтение данных всех категорий, к которым он допущен в рамках своей служебной деятельности. Однако при этом в общем случае не могут быть реализованы требования к заданию различных режимов обработки данных различных категорий – не возможно задать для данных различных категорий, каким приложением, с какими привилегиями пользователя, с какого устройства, с какими правами доступа к системным ресурсам и т.д., они могут быть прочитаны. Следовательно, для реализации этого условия, режимы обработки (в частности, по доступу к данным различных категорий конфиденциальности) до выбора сессии должны совпадать, что противоречит собственно идеи рассматриваемого подхода к защите (противоречие сформулированному ранее Требованию . Сказанное проиллюстрировано на рис.2.  Рис. Альтернативные схемы выбора сессии С учетом этого может быть сформулировано следующее требование. Требование 3. Сессия должна быть задана (выбрана) до начала обработки данных (данные должны загружаться – из файлового объекта, из сети и т.д., только после того, как определен режим их обработки, соответственно, способы загрузки и обработки, т.е. сессия). Данное требование не может быть выполнено в случае, если категория сессии определяется объектом доступа. Остается лишь определять сессию субъектом доступа. Альтернативные способы определения сущности сессия субъектом доступа Очевидно, что, так как мы говорим о контроле доступа к ресурсам, то в общем случае без включения каких-либо дополнительных категорий, мы имеем три сущности для определения сессии: учетная запись пользователя, процесс (имя процесса), ресурс (категория объекта). Категорией объекта сущность сессия назначать нельзя (вступаем в противоречие с Требованием , остаются сущности учетная запись пользователя и процесс (имя процесса), либо необходимость включения каким-либо образом дополнительной сущности, определяющей сессию. Включение в схему контроля доступа к ресурсам дополнительных сущностей: субъекта выбор сессии и объекта выбор сессии При реализации данного способа решение может состоять в следующем. Вводится некий дополнительный субъект выбор сессии, пусть это некая программа, управление которой выносится в виде меню на рабочий стол. При входе пользователя в систему (после идентификации и аутентификации) автоматически запускается сессия выбор сессии (соответствующая программа) – пользователю разрешается доступ только к объекту выбора сессии (предлагается выбрать сессию для работы, ко всем иным ресурсам, в том числе и возможность запуска любого иного приложения, доступ пользователя запрещен). Объектом доступа здесь служат настройки механизмов контроля доступа к ресурсам, которые должны быть загружены в результате выбора соответствующей сессии. После выбора сессии вступают в силу разграничения для выбранной пользователем сессии (в общем случае, совокупность разграничений для сущностей пользователь и сессия) – пользователь может работать в данной сессии. Переход от сессии к сессии (изменение сессии) осуществляется аналогично и поддерживается необходимыми для корректной реализации разграничительной политики доступа к ресурсам мерами, в частности, осуществляется очистка буфера обмена, освобождаемой оперативной памяти, принудительно завершаются приложения, запущенные в предыдущей сессии и т.д. Естественно, что в части обеспечения корректности решения рассматриваемой задачи, разграничительная политика доступа должна реализовываться не для учетных записей, а для включенных субъектов сессия. Возможно, что данный подход и имеет право на жизнь, но не при реализации добавочных средств защиты. Он требует радикального изменения всей концепции защиты, реализуемой в современных универсальных ОС и приложениях, где в качестве субъекта доступа рассматривается сущность учетная запись. Другими словами, чтобы его реализовать, необходимо забыть обо всех наработках и реализованных в современных универсальных ОС решениях и создать всю защиту заново, совершенно на иных принципах. По нашему мнению, если подобное, корректно реализованное средство защиты и может быть корректно реализовано, то только разработчиками ОС. Сегодня о подобном решении можно забыть, а решать задачу защиты от инсайдерских атак требуется сегодня (на самом деле, уже вчера)! Использование для задания сессии сущности учетная запись Попытаемся максимально облегчить задачу реализации сессионного контроля доступа к ресурсам (переведем наши теоретические исследования в более практическую плоскость), памятуя о том, что вся разграничительная политика доступа к ресурсам в современных универсальных ОС и приложениях реализуется для субъекта доступа учетная запись, причем, как в части задания правил доступа к ресурсам, так и в части задания привилегий, т.е. попытаемся максимально использовать существующие на сегодняшний день наработки, применительно к решению рассматриваемой задачи защиты информации – противодействие внутренним ИТ-угрозам. При реализации данного способа решение состоит в следующем. Итак, сессия должна определяться учетной записью. Поскольку данные различных категорий должны обрабатываться в различных сессиях, то для каждого пользователя должно быть создано несколько учетных записей – по одной для обработки информации каждой категории конфиденциальности. Пользователь для обработки данных соответствующей категории должен войти в систему под соответствующей учетной записью (при необходимости смены сессии осуществить штатными средствами смену учетной записи, либо запустить процесс под иной учетной записью – утилита runas – по правой кнопки мыши, начиная с Windows XP). Заметим, что гипотетически при этом реализуются все требования, сформулированные выше, в частности, может быть обеспечена изолированная обработка данных различных категорий (посредством реализации изолированной обработки данных для различных учетных записей), а сессия выбирается пользователем до получения доступа к данным (до прохождения процедуры идентификации и аутентификации (при выборе сессии) доступ к какому-либо ресурсу невозможен). Для работы в сессии также могут устанавливаться привилегии, назначаемые при данном решении учетным записям. Возможность решения задачи в общем виде также обусловливается и тем, что разграничения могут быть реализованы для субъекта сессия, пользователь. С этой целью этого для каждого пользователя должны быть созданы соответствующие учетные записи для обработки данных различных категорий. Использование для задания сессии сущности процесс Если выше нами рассматривались альтернативные подходы для решения задачи в общем виде, то очевидно, что данное решение частное. Частность данного решения обусловливается тем, что сессия определяется сущностью процесс или полнопутевым именем процесса. Т.е., другими словами, категорируется некий информационные сервис (например, работа с сетью Интернет разрешается только в открытой сессии). Запуск категорированного процесса означает запуск категорированного информационного сервиса (приложения) с соответствующей ему разграничительной политикой доступа к ресурсам. Ограничение состоит в том, что одно и то же приложение не может использоваться в нескольких сессиях (при обработке информации различных категорий), т.к. именно приложением и определяется сессия. При реализации данного способа решение может состоять в следующем. Разграничение прав доступа устанавливается для процессов (приложений), характеризующих категорируемый информационный сервис, например, для процессов сетевых служб. Т.е. именно процесс выступает в качестве субъекта доступа, следовательно, для всех учетных записей разграничения при работе с этим процессом совпадут. Для получения доступа к категорированному информационному сервису, пользователь должен запустить процесс, для которого заданы соответствующие права доступа к ресурсам (по сути, изменить сессию) – все запросы пользователя к ресурсам, производимые данным процессом (например, к файловым объектам, к объектам реестра ОС, к сетевым ресурсам – хостам, и т.д.), будут осуществляться в рамках прав доступа к ресурсам, заданных для процесса. Не смотря на свою частность (один и тот же информационный сервис – процесс, может использоваться только для обработки данных одной категории), такое решение могло бы быть весьма эффективным в некоторых конкретных приложениях, например, если с компьютера, на котором обрабатывается конфиденциальная информация, пользователям следует разрешить доступ в сеть Интернет, при этом предотвратить возможность передачи конфиденциальных данных пользователями в сеть. Однако, при реализации данного подхода, мы сталкиваемся с теми же недостатками реализации разграничительной политики, о которых говорили ранее, связанных с тем, что доступ к информации различных категорий осуществляется под одной и той же учетной записью, в то время, как вся разграничительная политика в современных ОС и приложениях основана на задании разграничении для учетных записей и на назначении привилегий учетным записям. С учетом всего сказанного, можем сформулировать следующее требование к реализации разделительной политики доступа к ресурсам в современных условиях (речь идет о добавочных средствах защиты информации). Требование 4. В современных условиях разделительная политика доступа к ресурсам (основа основ противодействия инсайдерским атакам) должна реализовываться разграничительной политикой доступа к ресурсам для учетных записей. Требования к корректности реализации разделительной политики доступа к ресурсам Теперь, определившись с тем, какая сущность должна являться субъектом доступа при реализации разграничительной политики доступа к ресурсам, каким образом определяется, создается и изменяется сессия при обработке на компьютере категорированной информации, сформируем требования к реализации разделительной политики доступа к ресурсам, которая, следуя Требованию 4, должна реализовываться разграничительной политикой доступа к ресурсам для учетных записей. Требование 5. Должна предоставляться возможность задания разграничительной политики доступа к ресурсам для учетных записей ко всем ресурсам (файловые объекты, устройства, сетевые ресурсы и т.д.), монтирование (подключение) которых разрешено к системе (к объекту защиты). Следствие. Достаточность набора механизмов защиты, корректно реализующих разделительную политику доступа к ресурсам для учетных записей, определяется выполнением следующего правила: Есть в системе ресурс – к нему должна предоставляться возможность разграничить доступ к ресурсам для учетных записей, если подобная возможность не предоставляется – возможность монтирования (подключения) ресурса к системе должна предотвращаться. Требование 6. Должна предоставляться возможность разграничить права доступа между всеми учетными записями к каждому ресурсу, монтирование (подключение) которых разрешено к системе (к объекту защиты). Вскользь остановимся на данном требовании. Очевидно, что если существует ресурс, доступ к которому невозможно разграничить между всеми учетными записями, то ни о какой разделительной политики доступа к ресурсам говорить не приходится, т.к. данный ресурс становится несанкционированным каналом обмена информации между сессиями, который может послужить каналом хищения конфиденциальных данных. Здесь следует отметить, что современные универсальные ОС и приложения не ориентированы на реализацию разделительной политики доступа к ресурсам, как следствие, не обеспечивают возможность реализации разграничений ко всем ресурсам системы. Как следствие, для реализации рассматриваемого подхода к защите, необходимы дополнительные механизмы защиты. Рассмотрим лишь несколько примеров, применительно к ОС семейства Windows. Наиболее очевидными каналами обмена категорированной информацией в нашем случае являются буфер обмена и файловые объекты. Так вот, буфер обмена в ОС является принадлежностью рабочего стола. При запуске приложения по правой кнопки мыши (утилита runas) под другой учетной записью, буфер обмена между соответствующими двумя учетными записями не разделяется. Данная задача должна быть решена добавочным средством защиты. Другой пример, системой нельзя разделить между учетными записями папку Documents and Settings\All Users. Рассмотрим пример реализации соответствующего механизма защиты, реализующего разделение между учетными записями любого файлового объекта, не разделяемого системой и приложениями, из состава Комплексной системы защиты информации (КСЗИ) Панцирь-К для ОС Windows 2000/XP/200 Интерфейс данного механизма защиты приведен на рис.  Рис. Интерфейс механизма переназначения путей к каталогам Данный механизм защиты позволяет разделить любую папку между учетными записями. При этом для каждой учетной записи создается собственная папка, в которую для нее перенаправляются обращения, осуществляемые под данной учетной записью к исходной неразделяемой системой, либо приложением, папки. Исходная же папка становится виртуальной, к ней невозможно обратиться ни под одной учетной записью. Замечание. Здесь и далее мы иллюстрируем реализацию механизмов защиты на примере КСЗИ Панцирь-К для ОС Windows 2000/XP/2003 по одной простой причине – данным средством защиты в полном объеме (включая криптографическую защиту, о чем речь пойдет далее) реализуется рассматриваемый в работе подход к защите от инсайдерских атак. Требования к корректности реализации разграничительной политики доступа к ресурсам Эти требования диктуются требованием к реализации индуктивности модели безопасности, являющимся основополагающим требованием при построении защиты для корпоративных приложений. Напомним, что индуктивность модели безопасности достигается в том случае, если единожды установленная в безопасное состояние система, находится в таком состоянии в процессе своего функционирования. Индуктивность модели безопасности обеспечивается при реализации следующих требований. Требование 7. Из разграничительной политики доступа к ресурсам должна быть исключена, как таковая, сущность владения объектом (напомним, что под владельцем объекта понимается пользователь, создавший этот объект). Все задачи реализации разграничительной политики доступа (настройки механизмов защиты) должны решаться администратором безопасности – пользователь должен быть исключен из схемы администрирования. Требование 8. Должна быть реализована разрешительная разграничительная политика доступа к ресурсам – все, что явно не разрешено, то запрещено, т.к. только в этом случае становится невозможен доступ пользователей к вновь создаваемым объектам. Замечание. Все сказанное в полной мере относится и механизмам защиты, реализующим локализацию компьютерных ресурсов (формирование объекта защиты). Вопросы построения интерфейсов механизмов защиты Очевидно, что реализация рассматриваемого подхода к защите от инсайдерских атак может привести к существенному усложнению задачи администрирования механизмов защиты. Действительно, предполагается, что на компьютере, где обрабатывается категорированная информация, для каждого пользователя должно быть создано число учетных записей по числу категорий конфиденциальности обрабатываемой информации. Те, кто сталкивался с настройкой механизмов защиты, встроенных в ОС Windows, от этой мысли придет в ужас, и заговорит о безопасности с человеческим лицом. Рассмотрим решение по построению интерфейсов механизмов защиты, на примере, наиболее трудного в настройке механизма разграничения прав доступа к объектам файловой системы, на примере КСЗИ Панцирь-К для ОС Windows 2000/XP/2003, см. рис.  Рис. Интерфейс механизма управления доступом к файловой системе Особенности данного решения состоят в следующем:
Теперь касательно номенклатуры типов задаваемых прав доступа. Некоторые производители средств защиты позиционируют широкую номенклатуру типов задаваемых прав доступа чуть ли не как основное потребительское свойство средства защиты, говоря при этом, о возможности реализации гибких настроек. Мы с этим категорически не согласны по двум причинам. Во-первых, это лишь усложняет итак непростую задачу настройки механизмов защиты, приводя к дополнительному повышению вероятности ошибок администрирования. Во-вторых, для корпоративных приложениях, на наш взгляд, это становится просто излишним. Порассуждаем на эту тему. Во-первых, априори исключим все типы прав доступа, связанные с сущностью владения. Пойдем дальше. Если пользователю разрешено чтение файла, то по умолчанию ему должна быть запрещена его модификация, переименование, удаление, создание нового файла (то же относится и к папке). Если пользователю разрешена запись в файл, то ему должна быть разрешена его модификация, запрещены удаление, переименование, создание новых файлов, если разрешена запись в папку – пользователю разрешаются любые действия внутри папки, запрещается переименование, удаление папки, создание нового файла вне папки и т.д. Видим, что все многообразие настраиваемых типов доступа может быть сведено к трем: чтение, запись, выполнение (остальные типы доступа могут устанавливаться автоматически средством защиты на основании установленного администратором одного из трех настраиваемых типов доступа), при этом реализованное решение никак не сказывается на универсальности механизма защиты, в части реализации разграничительной политики доступа к ресурсам в корпоративных приложениях. Заметим, что типы доступа чтение, запись используются для объектов, хранящих данные, тип доступа выполнение - для объектов, хранящих исполняемые файлы (этот настраиваемый тип доступа необходим для настройки важнейшего (более того, ключевого при решении практически любой задачи защиты информации) механизма защиты – механизма обеспечения замкнутости программной среды, на наш взгляд, без этого механизма вообще нет никакой защиты). Итак, с настраиваемыми типами доступа к объектам разобрались. Но будем помнить, что некоторые объекты, например, файловые, имеют иерархическую структуру (диск, каталог, подкаталог, файл). Если мы говорим о реализации разрешительной разграничительной политики доступа к ресурсам, то здесь возникает вопрос о реализации права доступа обзор. Естественно, что если мы хотим разрешить доступ, например, пользователю к файлу, то необходимо разрешить ему обзор и всех объектов более высокого уровня иерархии, включающих данный файл. Естественно, что данное правило также целесообразно реализовывать средством защиты автоматически. Тогда, например, чтобы разрешить некоему пользователю только определенное право (тип) доступа к какому-либо объекту, например, D:\Doc\1, ему достаточно будет задать разрешенный тип доступа к полнопутевому имени данного объекта. Что получим. Объекты D и D:\Doc (более высоких уровней иерархии) ему автоматически разрешается обозревать (заметим, только в рамках одного уровня иерархии – он не сможет увидеть что расположено в иных каталогах на данном диске – на диске D он увидит все объекты, но сумеет зайти только в объект D:\Doc, и т.д.), при этом ни к какому иному объекту никакого доступа пользователь не получит. Возвращаясь к рис.4, на примере рассмотрим, как легко настраивать сложную разграничительную политику доступа к файловым объектам (локальным и разделенным в сети, на жестком диске и на внешних накопителях) с использованием данного интерфейса. Так на рис.4 лишь несколькими записями в интерфейсе мы разрешили учетной записи User 1 только запись и чтение в каталог D:\Doc (разрешить доступ одной записью можно к файловому объекту любого уровня иерархии – диск, каталог, подкаталог, файл), а выполнение программ только из каталогов C:\Windows и C:\Program Files, одновременно запретив туда запись – реализовали замкнутую программную среду и защитили системные ресурсы от модификации. Заметим, что снижение вероятности ошибок администрирования при реализации данного решения достигается не только простотой настройки прав доступа к ресурсам, но и наглядностью разграничительной политики доступа к ресурсам. Так на рис.4 в одном окне интерфейса отображается вся разграничительная политика доступа ко всем объектам файловой системы (в том числе и к объектам, разделенным в сети, и к объектам на внешних накопителях, включая мобильные), заданная для учетной записи User 1 (иных прав доступа он не имеет, т.к. они не разрешены по умолчанию). Захотите посмотреть разграничительную политику для другого пользователя, выберите его, она также будет отображена в одном окне интерфейса. Не требуется перебирать объекты, смотреть на их атрибуты – все наглядно и информативно! Вопросы применения криптографических механизмов защиты информации Здесь, наверное, применительно к рассматриваемой задаче защиты, мы не скажем ничего особенно нового. Как известно, методы криптографической защиты, в отличие от механизмов защиты от НСД, призванных противодействовать хищению информации, применяются для дополнительной защиты объектов, защита которых в полном объеме невозможна механизмами защиты от НСД. В первую очередь, это внешние накопители, например, Flash-устройства, монтирование которых разрешено, и которые предназначены для хранения конфиденциальной информации, и соответствующие виртуальные каналы связи. Вместе с тем, некоторые дополнительные требования решаемая задача накладывает и на данные методы защиты. К таким требованиям может быть отнесено следующее. Требование 9. Шифрование объектов, назначаемых администратором безопасности, должно осуществляться автоматически, прозрачно для пользователей. Замечание. Поскольку пользователи выступают в качестве потенциальных злоумышленников, применение в данном случае каких-либо прикладных средств шифрования (под управлением пользователя) недопустимо. Требование 10. Ключевая политика (способы хранения и ввода ключевой информации) должна обеспечивать возможность расшифрования информации только тем пользователям и только на тех вычислительных средствах, которые определены администратором безопасности. Замечание. Возможности реализации различных ключевых политик становится для рассматриваемой в работе задачи защиты, одним из важнейших свойств средства криптографической защиты информации. В общем случае, ключ шифрования можно держать в файле, в реестре, на внешнем устройстве, может быть реализован форум ключей (например, для расшифрования понадобится два ключа – один будет храниться на внешнем устройстве у пользователя, другой в реестре определенного компьютера, откуда с пользовательскими правами будет запрещено чтение информации), для хранения ключей может быть организован отдельный ключевой сервер и т.д. и т.п. Альтернативные возможности хранения и ввода ключевой информации крайне важны при определении (разработке) политики информационной безопасности предприятия, т.к. эти возможности напрямую связаны с реализацией дополнительных организационных мер защиты информации. Вопросы резервного копирования категорированной информации Поскольку, как отмечали ранее, защита информации состоит не только в предотвращении ее хищения, но и в обеспечении ее целостности и доступности, а санкционированный пользователь, обладающий полным доступом к конфиденциальной информации, рассматривается в качестве потенциально возможного нарушителя, для защиты информации от санкционированного пользователя должно обеспечиваться ее периодическое копирование. Здесь не лишним будет отметить, что использование таких способов копирования информации, как зеркалирование, в данном случае недопустимо. Другими словами, и к механизмам резервного копирования при решении рассматриваемой задачи выдвигаются некоторые требования, состоящие в следующем. Требование 11. Резервное периодическое копирование информации из объектов, назначаемых администратором безопасности, должно осуществляться автоматически, прозрачно для пользователей. Замечание. Поскольку пользователи выступают в качестве потенциальных злоумышленников, применение в данном случае каких-либо средств копирования под управлением пользователя недопустимо. Требование 12. Реализацией разграничительной политики доступа к ресурсам должна предотвращаться возможность доступа пользователей к объектам, хранящим резервную информацию. Очевидно, что подобная задача защиты очень просто может быть решена средством добавочной защиты, при этом периодическое резервное копирование может осуществляться как в файловый объект на том же компьютере (доступ пользователей к нему должен запрещаться), так и на сервере, например, в общий, разделенный в сети файловый объект. В заключение хотелось бы остановиться на вопросе, почему, на наш взгляд, так актуальна и важна на сегодняшний день задача разработки требований к решению различных задач защиты информации (от внутренних и от внешних ИТ-угроз, антивирусной защиты, защиты от атак на ошибки программирования в системных средствах и в приложениях, и т.п.). Дело в том, что на сегодняшний день мы пользуемся нормативными документами в области защиты информации, опубликованными еще в 1992 году. Разработчики по этим требованиям создают средства защиты, потребители их оценивают. А ведь в этих требованиях ни слова нет о том, какой механизм защиты, применительно к решению какой задачи защиты и каким образом должен использоваться. К чему это приводит? Очень, на наш взгляд, показательны в этом смысле исследования, проведенные в свое время компанией Infowatch (в свое время данные исследования были опубликованы на многих профильных сайтах). На рис. 5 приведен один из результатов данного исследования, который мы обсудим в данной работе.  Рис.5 Обратим внимание на представленную динамику (этим нам и интересно данное исследование). Когда пришло осознание проблемы, разработчиками срочно начали создаваться средства защиты от инсайдерских атак. В течение года подобные средства появились на рынке, и для половины респодентов это не осталось незамеченным. Но практически пропорционально этому выросло и количество респондентов, отмечающих отсутствие стандартов, т.е. каким-либо образом формализованных требований к средству защиты от инсайдерских атак, позволяющих оценить его эффективность. Это говорит о том, что потенциальный потребитель хотел бы разобраться с тем, что же ему предлагается разработчиками. Отрадно, что в 2 раза увеличилось число респондентов, отмечающих нехватку квалифицированного персонала. Это говорит о том, что существует понимание сложности задачи защиты и невозможности ее решения простейшими средствами. К сожалению, на сегодняшний день, мало что изменилось в этом вопросе – требования к решению рассматриваемой задачи защиты, позволившие бы оценить эффективность средств защиты, не сформулированы и не формализованы, обоснования подходов к построению средств защиты автору также не встречалось, что и побудило автора к написанию данной статьи. Читайте далее:  08 - 09 марта 2008 года 14 - 20 апреля 2008 года ,рынок it, 28 - 30 апреля 2008 года ,рынок безопасности, 01. 04. 2008 05 - 11 мая 2008 года ,рынок безопасности, 12 - 18 мая 2008 года ,рынок it, 26 - 31 мая 2008 года ,рынок it, Организация строительно-монтажных, пусконаладочных работ и ввода в эксплуатацию интегрированных сист Наш опыт прокладки кабелей Заземление в системах промышленной автоматизации ,часть 2, Способы устранения искажений видеосигнала в линиях связи Как бороться с периодическим проявлением дефектов в системах безопасности Выставка ifsec 2008 ,11 - 20, О безопасности в великобритании и не только... терпение О безопасности в великобритании и не только... предупрежден – значит, вооружен
|
