Вы находитесь в разделе Типовых решений систем безопасности
Противодействуем внутренним it-угрозамВ первой части работы было представлено исследование, основанное на опросе представителей 387 государственных и коммерческих организаций Российской Федерации, иллюстрирующее, что сегодня подавляющая часть специалистов (62% из опрошенных) считают, что действия санкционированных пользователей (инсайдеров) являются самой большой угрозой для российских организаций, причем 98% из них относят нарушение конфиденциальности информации к самой большой внутренней ИТ-угрозе. При этом отрадным является тот факт, что 87% опрошенных специалистов считают технические средства эффективным способом защиты, правда следует отметить, что 58% не осведомлены о существующих технологических решениях. Не лишним будет заметить и то, что 5% опрошенных специалистов отметили отсутствие соответствующих стандартов. Это важно тем, что, как было показано нами в первой части работы (на этом вопросе мы остановимся и в данной статье), требования к средствам защиты информации, сформулированные в соответствующих нормативных документах в области защиты информации, в полном объеме и корректно формулируют требования к реализации эффективного противодействия внутренним ИТ-угрозам (ради справедливости отметим, не акцентируя эту задачу защиты информации), другое дело, что данные требования в этой части не выполняются современными ОС и многими средствами добавочной защиты (в этом, на наш взгляд, и состоит причина их уязвимости). В представленном в первой части работы исследовании было показано, что к основным путям утечки данных опрошенные специалисты относят электронную почту, интернет ресурсы и мобильные накопители. В первой части работы нами исследовался вопрос и рассматривались решения по противодействию использованию мобильных накопителей (в общем случае любых внешних устройств) для хищения конфиденциальных данных. В данной же части работы мы рассмотрим задачу (и предлагаемые ее решения) защиты от утечек данных, посредством использования инсайдером электронной почты и интернет ресурсов. Введение Интересующие нас в работе фрагменты исследования Infowatch о внутренних ИТ-угрозах в России, опубликованное на сайте: www.itsec.ru от 22.11.2005 г., проиллюстрированы на рис.1 и рис.2.
В данной работе мы исследуем вопросы обеспечения защиты от утечек данных (в части нарушения конфиденциальности), посредством использования инсайдером электронной почты и интернет ресурсов (как следует из рис.2, это сегодня одна из наиболее вероятных атаках, направленных на нарушение конфиденциальности информации, со стороны санкционированного пользователя). Как и в первой части работы, в качестве возможных вариантов решения соответствующих задач защиты информации, нами буту рассматриваться апробированные механизмы защиты, реализованные в Комплексной системе защиты информации (КСЗИ) «Панцирь-К» для ОС Windows 2000/XP/2003 (разработка ЗАО «НПП «Информационные технологии в бизнесе», сертификат ФСТЭК №1144 от 17.01.200 . Постановка задачи защиты. Общий подход к решению В общем случае следует рассматривать ситуацию, когда на одном вычислительном средстве предполагается вести обработку конфиденциальной информации, являющейся объектом защиты (именно утечка этой информации является критичным событием) и использовать ресурсы внешней сети, причем не защищенной (корпоративной), а открытой сети общего пользования. При этом предполагается, что эти возможности следует предоставить одному и тому же сотруднику предприятия – пользователю вычислительного средства. В предположении же, что данный санкционированный пользователь, в рамках выполнения своих служебных обязанностей допущенный к обработке конфиденциальных данных и к сетевым ресурсам открытой сети, является потенциальным инсайдером, следует предотвратить какую-либо возможность несанкционированной отправки им конфиденциальных данных во внешнюю сеть.Замечание Возможны частные случаи постановки задачи, решение которых не требует дополнительных исследований в рамках рассматриваемой проблемы:
Решение задачи в первом случае состоит в том, чтобы предотвратить любую возможность подключения к системе устройств (в том числе, и внешних), предоставляющих сетевой ресурс для передачи информации. Подход к решению данной задачи и механизм защиты, реализующий данную возможность, были рассмотрены в первой части работы (конечно, ни о каких организационных мероприятиях при решении данной задачи речь идти не может). Решение задачи во втором случае состоит в реализации контроля доступа к сетевым ресурсам. Напомним, что подобная функция средства защиты является обязательной при защите конфиденциальной информации (следовательно, данный механизм защиты обязательно должен присутствовать в средстве защиты конфиденциальной информации). В требованиях к достаточности (полноте, применительно к условиям использования) реализации разграничительной политики доступа к ресурсам, которые определены действующим сегодня нормативным документом (Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации), в части защиты конфиденциальной информации (класс АС 1Г), это формализуется следующим образом:
В порядке иллюстрации приведем интерфейс настройки механизма управления доступом к сетевым ресурсам, реализованный в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003, см. рис.  Отметим, что здесь, как и во всех механизмах контроля доступа к ресурсам, в соответствии с требованиями нормативных документов, должна быть реализована разрешительная разграничительная политика доступа к ресурсам («Все что не разрешено – явно не задано, то запрещено»). В части расширения функциональных возможностей механизма защиты, в схему контроля доступа целесообразно включить процесс, как самостоятельный субъект доступа (при этом разграничения могут задаваться только для пользователя, только для процесса и для субъекта доступа «пользователь и процесс»). Данный механизм защиты позволяет локализовать возможность взаимодействия пользователя только с корпоративными сетевыми ресурсами (хостами), причем, как на уровне ЛВС (включая разделяемые в сети ресурсы), так и на уровне распределенной сети. В порядке замечания отметим следующее. Подчас подобный механизм защиты называют персональным межсетевым экраном (даже пытаются его сертифицировать по требованиям к межсетевым экранам), что, на наш взгляд не корректно – это механизм контроля доступа к сетевым ресурсам. Межсетевой экран же априори не может быть персональным – он должен представлять собой выделенное программно-аппаратное средство, устанавливаемое на «стыке» подсетей с целью их физической изоляции. Контроль доступа к сетевым ресурсам является лишь частной задачей межсетевого экрана. При этом следует говорить о функции контроля доступа межсетевого экрана лишь в части задания разграничений доступа между объектами подсетей (а не внутри одной подсети, например, ЛВС, что с точки зрения надежности функционирования подсети, на наш взгляд, недопустимо). Теперь рассмотрим общий подход к решению задачи, сформулированной в общем случае (защищенная обработка конфиденциальных данных и возможность доступа к открытым сетевым ресурсам с одного вычислительного средства одним и тем же пользователем). В порядке замечания отметим, что подчас решение подобной задачи разработчиками средств защиты возлагается на всевозможные средства мониторинга, однако, на наш взгляд, эффективное решение может состоять лишь в предотвращении самой возможности утечки конфиденциальных данных, что можно обеспечить лишь механизмами контроля доступа к ресурсам. Следует понимать, что существует масса способов сокрытия самого факта передачи конфиденциальных данных (подобным вопросам посвящено отдельное направление – стеганография). Данные не только можно изменить до неузнаваемости, сохранив содержание документа (при этом совсем не обязательно использовать криптографические методы), но и «спрятать» их при передаче, например, поместив в картинку. Любопытно, что даже исполняемый файл содержит около 2% избыточности, куда можно поместить данные, не нарушая его работы (т.е. данные можно передать даже путем отправки программы). Трудно предположить, что средство мониторинга может обеспечить необходимый стеганографический анализ сообщения (вопрос о производительности подобного средства мы даже не ставим). Итак, вернемся к нашему исследованию. Пусть мы имеем два вида информации (конфиденциальная и открытая), обрабатываемой на одном вычислительном средстве, одним пользователем. Способы этой обработки кардинально различаются – конфиденциальная информация может обрабатываться только локально, должна предотвращаться возможность ее выдачи в сеть (с использованием электронной почты и интернет сервисов). В этих условиях, сам собой напрашивается общий подход к решению задачи – пользователь должен обладать различными правами доступа к ресурсам при обработке конфиденциальной и открытой информации, при этом должна предотвращаться любая возможность несанкционированного изменения статуса информации (конфиденциальная информация ни при каких условиях не должна восприниматься средством защиты, как открытая). Теперь рассмотрим возможные способы реализации представленного общего подхода к защите информации, а также выявим причины невозможности корректного решения рассматриваемой задачи защиты информации встроенными в современные ОС механизмами защиты. Решение задачи на основе разграничений для учетных записей пользователя Наиболее очевидным является следующее решение. Пользователю в системе требуется завести две учетные записи (одну для обработки конфиденциальной информации, другую для работы с открытыми данными). Затем реализовать соответствующую разграничительную политику доступа к ресурсам - для каждой учетной записи создать свои файловые объекты (в общем случае не пересекающиеся, либо возможно разрешить пользователю, допущенному к обработке конфиденциальных данных, чтение объектов пользователя, допущенного к обработке открытых данных, чем открывается допустимый канал их взаимодействия через файловую систему) для хранения, соответственно, конфиденциальной и открытой информации; учетной записи, используемой для обработки конфиденциальной информации запретить, а другой разрешить доступ к сетевым ресурсам (если это делать добавочными средствами, они все равно понадобятся, то для этого можно использовать, например, механизм защиты, описанный выше). Итак, доступ к сетевым ресурсам мы разграничили, теперь при входе в систему под одной учетной записью он может быть получен пользователем, под другой – не может. Файловые объекты для хранения информации различного статуса мы также изолировали. На первый взгляд, задача решена. Замечание Здесь и далее мы не будем рассматривать вопросы передачи информации (в нашем случае, с целью понижения ее статуса) с использованием внешних накопителей, т.к. это самостоятельная задача, возможное решение которой рассмотрено нами в первой части работы (если бесконтрольно можно использовать внешние устройства, то вырождается и проблема хищения данных с использованием электронной почты и интернет ресурсов – проще это сделать с использованием мобильных накопителей). Будем считать, что этот возможный канал изменения статуса информации нами закрыт. Чтобы ответить на вопрос, насколько корректно решена задача, следует остановиться на вопросах корректности реализации разграничений доступа к файловым объектам. Введем общий критерий корректности реализации разграничительной политики доступа к ресурсам. Для этого введем следующие обозначения. Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} – соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа Сi, i = 1,…,k рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа, соответственно, в качестве объекта доступа Оi, i = 1,…,k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми к ним правами доступа. Пусть S = {0,1} – множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «1» – разрешение полного доступа. Тогда каноническую модель контроля доступа можно представить матрицей доступа D, имеющей следующий вид:  Определение Под канонической моделью контроля доступа для линейно упорядоченных множеств субъектов (групп субъектов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой «1» – задают полный доступ субъектов к объектам, остальные элементы «0» – задают запрет доступа субъектов к объектам. Модель контроля доступа формально может быть описана следующим образом - элемент (Dij) матрицы Dij = 1, если i = j, иначе Dij = 0. Утверждение Диспетчер доступа реализует механизм управления доступом к ресурсам корректно только в том случае, если его настройками (заданием учетных записей субъектов и объектов доступа и правил разграничения доступа) можно реализовать каноническую модель контроля доступа. Доказательство Доказывается утверждение от обратного. Если каноническую модель контроля доступа реализовать невозможно – присутствуют элементы «1» вне главной диагонали матрицы доступа, то в системе присутствует, по крайней мере, один объект, доступ к которому (либо субъект, доступ которого) невозможно разграничить в полном объеме (объект включается одновременно в несколько групп объектов, априори характеризуемых различными правами доступа к ним). Это означает невыполнимость ключевого требования к механизму защиты, в части возможного его использования для обработки на одном вычислительном средстве информации различных уровней конфиденциальности (в нашем случае открытую и конфиденциальную). Следствие Механизм управления доступом к ресурсам должен позволять настройками диспетчера доступа сводить реализуемую им модель доступа к каноническому виду. Без реализации данного требования в принципе невозможно противодействовать изменению статуса обрабатываемой информации (т.е. корректно решить рассматриваемую задачу). Теперь рассмотрим, что относительно всего этого сказано в нормативных документах, формализующих требования к реализации механизма контроля доступа к ресурсам, и проанализируем эти требования. Формализованные требования к корректности реализации разграничительной политики доступа к ресурсам определены действующим сегодня нормативным документом (Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации), в части защиты конфиденциальной информации (5 класс СВТ), следующим образом:
Проанализируем эти требования. Проблема возможной неоднозначности трактования данных требований состоит в том, что подобные основополагающие требования (выполнение которых является обязательным для разработчика средств защиты) не могут быть в документе сформулированы детально, с учетом архитектурных особенностей различных системных средств - как любые основополагающие требования, они должно носить максимально общий характер, а любое обобщение неминуемо приводит к возможности неоднозначного толкования. Для возможности однозначного трактования данных требований, сформулируем ряд уточняющих требований, напрямую из них следующие. В порядке замечания отметим, что здесь мы формулируем уточняющие требования, применительно к задаче противодействия внутренним ИТ-угрозам (в части противодействия внешним ИТ-угрозам данные требования будут несколько иными, с полной совокупностью подобных требований к защите конфиденциальной информации можно познакомиться на сайте ЗАО «НПП «Информационные технологии в бизнесе»: www.npp-itb.spb.ru). Данные требования предполагают исключение сущности «Владелец объекта» как таковой (под «Владельцем объекта» в современных ОС понимается пользователь, создавший объект, которому предоставляется право устанавливать разграничения прав доступа к этому объекту). Это следует из требования «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)». Невыполнение данного требования в принципе нивелирует роль администратора безопасности (как можно отвечать за хищение информации, если не имеешь возможности однозначно и полностью разграничивать права доступа к объектам). Заметим, что в современных ОС, являющихся универсальными по своей сути – используются и как персональные средства, и для обработки информации на предприятии, сущность «Владелец» в полной мере используется в механизмах, реализующих разграничительную политику доступа к ресурсам. Суть этого состоит в том, что пользователь, создавший файловый объект (являясь его «владельцем») сам решает, кому предоставить доступ к этому объекту (при этом становится невозможна реализация канонической модели контроля доступа). Данные требования определяют реализацию разрешительной разграничительной политики доступа к ресурсам «Все что не разрешено – явно не указано, то запрещено». Это следует из требований: «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта…». Необходимость реализации данного требования обусловливается тем, что только при реализации данной политики доступа к ресурсам контролируется доступ к вновь создаваемым объектам в системе (доступ «по умолчанию» запрещается, если для объекта не заданы ПРД) - при невозможности контролировать доступ к вновь создаваемым объектам, становится невозможна реализация канонической модели контроля доступа. Данные требования определяют возможность разделить любой объект между всеми пользователями (в системе не должно быть объектов, в частности, файловых, которые невозможно разделить между пользователями средством защиты). Это следует из требования «Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов)». Заметим, что в системе к таким объектам можно отнести, как прикладные, так и системные файловые объекты, например, для ОС Windows к прикладным можно отнести папку: “All Users” на системном диске, к системным - главную таблицу файлов (MFT). MFT реализована, как массив записей о файлах, где каждая запись представляет собой совокупность пар атрибутов и их значений. Размер каждой записи фиксирован и равен 1 Кб. Если размер файла достаточно мал, чтобы поместиться в теле записи, то данные такого файла хранятся непосредственно в MFT. В процессе работы системы, NTFS ведет запись в файл метаданных – файл журнала с именем $LogFile. NTFS использует его для регистрации всех операций, влияющих на структуру тома NTFS, как то: создание файла, удаление файла, расширение файла, урезание файла, установка файловой информации, переименование файла и изменение прав доступа к файлу. Информация, описывающая подобные транзакции, включает в себя копии записей из MFT и в дальнейшем используется для повтора или отмены изменений. Соответственно, если данные файла содержатся в записи MFT, то при каждом изменении, данные файла будут (в числе прочего) скопированы в файл журнала. Кроме рассмотренных особенностей системной реализации, существует еще угроза и того, что ряд приложений позволяет сохранять данный только в один объект, вне зависимости от пользователя (все это обусловливает невозможность реализации канонической модели контроля доступа). Данные требования определяют, что корректность реализации механизма может быть обеспечена только при корректной (однозначной) идентификации субъекта и объекта доступа, в противном случае контроль доступа в соответствии с заданными ПРД становится невозможен в принципе. Это очевидное требование формулируется следующим образом “КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)». Казалось бы, на данном требовании не следует и заострять своего внимания, настолько оно очевидно, однако за внешней очевидностью, кроются серьезные архитектурные особенности современных ОС, которые должны быть учтены при создании средств добавочной защиты. Проиллюстрируем сказанное примерами. В общем случае файловый объект может быть идентифицирован различными способами. Рассмотрим эти способы, на примере NTFS:
В результате проведенного исследования можем сделать несколько важных выводов:
В порядке замечания добавим, что на первый взгляд, весьма простая задача, сформулированная в начале работы, после проведенного исследования превратилась в весьма не тривиальную задачу кардинального пересмотра основных принципов реализации разграничительной политики доступа к ресурсам. Отметим, что это характерно для той области знаний, к которой относятся вопросы защиты информации, при этом просто решение (которое может оказаться просто бессмысленным вложением средств) и эффективное решение на практике, как правило, кардинально различаются. Выбор же действительно эффективного решения (как видим, в том числе и из данной работы) требует от потребителя соответствующей квалификации. При этом не будем забывать, что когда информация является товаром, квалификация инсайдера высока (по крайней мере, злоумышленником ему будет предоставлен эффективный инструментарий хищения данных, а «нажать необходимый набор кнопок» можно научить любого пользователя). И очень плохо, если квалификация лица, ответственно за предотвращение хищения данных, окажется не конкурентоспособной. Теперь остановимся на вопросах реализации механизмов контроля доступа в добавочных средствах защиты и предлагаемые нами решения проиллюстрируем интерфейсами настройки механизмов защиты, реализованными в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003. Заметим, что реализованный в средстве защиты подход к построению интерфейсов во многом определяется архитектурной особенностью самого средства защиты (поэтому мы и рассматриваем механизмы с использованием интерфейсов). Так в современных универсальных ОС «Владелец» включен в схему администрирования - может назначать права доступа к созданным им объектам другим пользователям. Рассмотрим, как это сказывается на построении интерфейса механизма защиты. Для этого отметим, что «Владелец» не может изменять права доступа пользователей в общем случае, т.е. не может задавать (изменять) права доступа к любым объектам другим пользователям. Наверное, единственно возможное решение этой задачи и реализуется современными универсальными ОС. Суть реализуемого ими подхода состоит в том, что права доступа к объектам (в частности, к файловым) являются атрибутами объекта, т.е. присваиваются непосредственно объектам. В этом случае можно задавать различные привилегии изменения атрибутов, в частности «Владельцами», которые при этом могут изменять права доступа остальных пользователей не в общем случае, а лишь к отдельным файловым объектам - к созданным ими объектам. Но подобная универсальность является не только излишней, но, как следует из формализованных требований, недопустимой при защите конфиденциальной информации. Здесь, как раз, требование состоит в том, чтобы привилегированный пользователь (например, администратор безопасности) мог назначать (изменять) права доступа пользователей не к отдельным объектам, а в общем случае – ко всем объектам, сущность же «Владелец» должна быть исключена из схемы администрирования. На основании сказанного, можем сделать следующий важный вывод – ключевым элементом назначения разграничительной политики доступа к ресурсам при защите конфиденциальной информации должны являться не объекты, а субъекты доступа (пользователи), как следствие, права доступа должны выступать не в качестве атрибутов доступа, присваиваемых объектам, а должны выступать в качестве прав доступа, назначаемых субъектам, в частном случае, пользователям. Это следует и из того, что разграничительная политика доступа к ресурсам формируется для субъектов (определяет то, что разрешено, либо запрещено пользователям). Кроме того, как сформулировано в нормативных документах, основу должна составлять разрешительная разграничительная политика (запретительная может использоваться лишь опционально). Данный подход в полной мере реализован в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003, что иллюстрирует интерфейс соответствующего механизма защиты, приведенный на рис.4 (данный механизм позволяет настраивать разграничения прав доступа к объектам файловой системы: на жестком диске и на внешних накопителях, локальных и разделенных в сети, для разделенных – по исходящему и входящему запросам доступа).  Механизм защиты анализирует запрос при любой попытке открытия файла и разрешает, либо запрещает запрашиваемый пользователем доступ в соответствии с заданными в интерфейсе настройками. Механизм позволяет по любому из трех типов доступа (чтение, запись, выполнение) установить либо разрешительную, либо запретительную политику (в соответствии с требованиями нормативных документов должна устанавливаться разрешительная политика, запретительная включена опционально). При этом пользователь сможет получить только тот доступ и к тем объектам, которые заданы в интерфейсе, см. рис.4. Из рис.4 и видим, что реализация рассмотренного подхода при построении интерфейса механизма защиты принципиально упрощает настройку механизма, во-первых, делая ее интуитивно понятной (разграничительная политика доступа априори формируется для пользователей), во-вторых, вся настройка механизма сводится лишь к занесению нескольких записей в интерфейсе. Объекты, к которым разрешается (либо запрещается) доступ пользователю, определяются своими полнопутевыми именами (задаются с использованием соответствующей функции обзора), поэтому не требуется осуществлять разграничения ко всем объектам иерархии: диск, каталог, подкаталог, файл - в настройках требуется указать только соответствующий объект иерархии. Для упрощения группирования объектов реализован механизм масок. При реализации подобного подхода обеспечивается высокий уровень информативности интерфейса (надо понимать, что средство защиты настраивается в системе не единожды, в процессе эксплуатации системы требуется изменение настроек механизмов защиты). Для того, чтобы получить информацию о правах доступа пользователя к ресурсу в системе, нет необходимости перебирать все объекты, в частности файловые, с последующим анализом установленных для них атрибутов, достаточно выбрать пользователя, и в окне интерфейса (см. рис. , мы увидим все разрешенные (или запрещенные, в зависимости от выбранной политики) ему права доступа, а также соответствующие политики задания разграничений для пользователя. Следует обратить внимание и на номенклатуру типов контролируемого доступа - в КСЗИ их всего три: запись, чтение, выполнение. Права по остальным типам доступа (переименование, удаление, создание и т.д.) формируются КСЗИ автоматически, на основе назначения трех устанавливаемых типов доступа. Действительно, если пользователю разрешено чтение файла, то по умолчанию ему запрещена его модификация, переименование, удаление, создание нового файла (то же относится и к папке). Если пользователю разрешена запись в файл, ему разрешена его модификация, запрещены удаление, переименование, создание новых файлов, если разрешена запись в папку – пользователю разрешаются любые действия внутри папки, запрещается переименование, удаление папки, создание нового файла вне папки. Априори исключены все типы и права доступа, связанные с “владением”. На наш взгляд, обоснованно минимальный набор прав доступа, выносимый для настройки в интерфейс механизма защиты, является его большим достоинством, в части упрощения задачи администрирования механизмов защиты, следовательно, именно к реализации такого подхода (а не к увеличению числа атрибутов, с целью якобы достижения высокого уровня универсальности настроек), на наш взгляд, следует стремиться разработчикам средств защиты. Теперь, что касается разделения между пользователями файловых объектов, не разделяемых системой и приложениями. Проиллюстрируем данный недостаток системы (недостаток, в части решаемой нами задачи) с использованием матрицы доступа D, где объект, неразделяемый системой или приложениями (пусть это папка: “All Users” на системном диске), обозначим, как Ос. Для рассматриваемого случая модель контроля доступа имеет следующий вид:  Как мы уже отмечали, это приводит к тому, что в данном случае невозможно корректно решить задачу разграничения прав доступа к ресурсам для пользователей (учетных записей), которые обладают различными привилегиями обработки информации и доступа к ресурсам Для решения рассматриваемой задачи предлагается использовать следующий механизм защиты. Для каждого файлового объекта, не разделяемого между пользователями системой и приложениями, создаются собственные объекты для каждого пользователя. Обращение к исходному (указанному в интерфейсе настройки механизма защиты) объекту перехватывается средством защиты, определяется пользователь, инициировавший обращение, после чего запрос перенаправляется к соответствующему объекту, созданному для этого пользователя (исходный неразделяемый системой и приложениями объект становится виртуальным, к нему невозможно обратиться, т.к. все подобные обращения перенаправляются). Важным в реализации данного решения является то, что перенаправление запроса должно осуществляться перед выполнением анализа прав доступа. На соответствующие же объекты пользователей уже могут быть установлены свои разграничения. Таким образом, данный механизм защиты позволяет разделить между пользователями любой неразделяемый ОС или приложениями файловый объект, обеспечивая тем самым корректность реализации контроля доступа к ресурсам при наличии пользователей (учетных записей), которые обладают различными привилегиями обработки информации и доступа к ресурсам Пример интерфейса механизма перенаправления запросов к файловым объектам, реализующего рассмотренное решение в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003, приведен на рис.  Теперь, что касается системных неразделяемых ресурсов (таблица MFT). Здесь нами предлагается (и реализовано в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/200 следующее решение. При сохранении файла КСЗИ анализирует его размер. Если он менее 1 Кб, то КСЗИ принудительно увеличивает размер сохраняемого файла, что в принципе предотвращает возможность записи данных такого файла непосредственно в MFT. В порядке замечания отметим, что решение данной задачи актуально не только в части реализации канонической модели контроля доступа, но и для корректного решения задачи гарантированного удаления остаточной информации (однако в данной работе мы эту функцию, реализуемую КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003, рассматривать не будем). Итак, используя совокупность описанных выше механизмов защиты, нам удалось корректно решить сформулированную задачу противодействия внутренним ИТ-угрозам. В порядке замечания отметим, что возможности разграничительной политики доступа к ресурсам при реализации рассмотренного подхода могут расширяться, путем введения более чем двух учетных записей для работы на вычислительном средстве одного и того же пользователя – это, своего рода, инструментарий, который может быть применен для различных приложений. При всех достоинствах рассмотренного подхода, он обладает и существенным недостатком, связанным с существенным усложнением работы пользователя на вычислительном средстве, состоящим в том, что переход к другому режиму обработки информации (к другой учетной записи) связан с полной перезагрузкой компьютера (не очень упрощает эту ситуацию и то, что для входа в систему под различными учетными записями в данном случае может использоваться один и тот же пароль). Попробуем разрешить эту проблему. С этой целью рассмотрим возможность запуска программы с правами другого пользователя – сервис, предоставляемый ОС. Для того чтобы запустить процесс (программу) с правами другого пользователя, пользователь под своей учетной записью запускает программу-проводник, позволяющую запускать соответствующую утилиту, например, runas. В качестве параметров при запуске этой утилиты задается, какой процесс, с правами какого пользователя должен быть запущен, и пароль этого пользователя. Утилита запускается с правами текущего пользователя и взаимодействует с системной службой svchost, запущенной с правами System, которая, в свою очередь, взаимодействует с процессом winlogon, осуществляющим регистрацию входа нового пользователя в систему. При регистрации нового пользователя, потоки, запускаемые процессом winlogon, олицетворяют себя с правами регистрируемого пользователя (заметим, что если запретить подобное олицетворение, то регистрация нового пользователя в системе будет невозможна). Далее системная служба svchost запускает процесс, запуск которого запросил пользователь, с правами System, после чего, осуществляет смену первичного маркера доступа для запущенного процесса – смену маркера доступа System - на маркер доступа нового пользователя. В результате этого процесс функционирует под учетной записью нового пользователя. Рассмотрим, как можно использовать эту возможность на практике. Создадим ярлык запуска Internet Explorer (либо иного, интересующего нас приложения) с правами другого пользователя (это позволяет сделать ОС) и установим возможность его запуска под другой учетной записью. Будем считать, что приложение Internet Explorer должно использоваться для обработки открытой информации, поэтому запретим для создаваемой дополнительной учетной записи доступ к файловым объектам, хранящим конфиденциальные данные – создадим для нее собственный файловый объект для хранения открытых данных. При этом получаем, что один и тот же пользователь одновременно в одном сеансе (без перезагрузки системы) сможет работать, как с конфиденциальными, так и с открытыми данными под различными учетными записями. С открытыми данными он сможет работать, запустив с «рабочего стола» приложение Internet Explorer под другой учетной записью. Заметим, что в предположении, что используется добавочное средство защиты, которое в соответствии с нормативными требованиями к защите конфиденциальной информации должно собственными средствами обеспечивать авторизацию пользователя при входе в систему (по крайней мере, КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003 подобную возможность реализует в полном объеме), можно установить пустой пароль ОС на запуск приложения под другой учетной записью (тогда для пользователя эта процедура будет вообще полностью «прозрачной» – он просто запустит приложение по ярлыку на рабочем столе, а войти в систему под созданной учетной записью с пустым паролем не сможет). Но здесь вновь «наталкиваемся» на проблему – таким образом (зная имя и пароль пользователя) можно запустить программу под любой учетной записью. Возможны два решения – частное – запретить пользователю (учетной записи), обрабатывающему конфиденциальные данные какой-либо доступ к сетевым ресурсам (например, с помощью механизма, описанного в начале статьи), либо общее – не разрешить этому пользователю запуск данной программы (в данном случае можно полностью локализовать его среду исполнения – разрешать запускать только необходимые ему для работы приложения). Вспомним, что механизм контроля доступа, описанный выше, см. рис.4, позволяет контролировать выполнение программ (тип доступа «Выполнение»), и если задать разрешительную политику по этому типу доступа и не внести в разрешенные для выполнения соответствующий исполняемый файл (который обязательно должен располагаться на жестком диске), пользователь не сможет запустить соответствующую программу. Заметим, что для корректного решения задачи необходимо обеспечить невозможность переименования или модификации данного исполняемого файла (настройками механизма контроля доступа, см. рис.4, к нему должен быть не разрешен тип доступа «Запись»). Возможность же запуска иного файла под именем разрешенного исключается тем, что разрешенные к запуску объекты задаются своими полнопутевыми именами. Заметим, что реализованный нами подход, см. рис.4, позволяет задавать разрешенные к запуску программы не списками соответствующих им исполняемых файлов, а папками (например, каталогами), откуда разрешен запуск программ. Это принципиально упрощает задачу администрирования (в частности, сохраняются все штатные действия по установке и удалению программ, требуется лишь выбирать папку, в которую необходимо инсталлировать программу). Таким образом, нам удалось разрешить сформулированную выше проблему усложнения работы пользователя на вычислительном средстве (теперь он в одном сеансе без перезагрузки компьютера может обрабатывать конфиденциальную и открытую информацию), однако, мы тут же сталкиваемся с новой проблемой, состоящей в следующем. Оказывается, что ОС при подобном способе запуска приложения (под другой учетной записью) не разграничивает между учетными записями буфер обмена, т.е. в этом случае открывается новый канал изменения статуса информации. В части противодействия этому нами предлагается и реализовано (в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/200 следующее решение – реализован отдельный механизм защиты, позволяющий разграничивать между пользователями (между учетными данными) доступ к буферу обмена (при любом способе запуска приложения). Таким образом, объектом доступа здесь является буфер обмена, разграничения состоят в разрешении (основная политика – разрешительная), либо в запрете доступа пользователю (учетной записи) к буферу обмена. В нашем случае следует запретить доступ к буферу обмена учетной записи, используемой для обработки открытых данных. В качестве замечания отметим, что подход, связанный с полным отключением буфера обмена (для всех пользователей) – реализуется в одном известном нам средстве добавочной защиты, не целесообразен, ввиду того, что это сильно сказывается на штатной работе пользователя (на практике подобный механизм все равно будет отключен). Итак, применение рассмотренного подхода позволяет корректно решить сформулированную в работе задачу противодействия внутренним ИТ-угрозам, сохранив все штатные возможности пользователя по обработке информации, причем, практически не значительно осложнив (а с учетом реализованных подходов к построению интерфейсов, возможно, и упростив) задачу администрирования средства защиты информации. Решение задачи на основе разграничений для процессов Очевидно, что при обработке информации, обладающей различным статусом (в рассматриваемом случае конфиденциально и открытой) защита должна базироваться на различии разграничений доступа и режимов обработки этой информации. Выше нами был рассмотрен подход, основанный на введении для обработки информации различных уровней конфиденциальности различных учетных записей, с последующим назначением соответствующих прав доступа к информации и режимов ее обработки, применительно к учетным записям. Однако, как собственно доступ к информации, так и ее обработка в соответствии с тем, либо иным режимами, осуществляются процессами (программами). Следовательно, можем предположить, что рассматриваемую задачу можно решить, посредством задания разграничений для процессов. Предлагаемый нами подход к решению этой задачи состоит в следующем. В общем случае при управлении доступом к ресурсам следует различать два самостоятельных субъекта доступа – «пользователь» и «процесс». При этом предлагается управлять доступом (разграничивать права доступа) не только для субъекта пользователь, но и для субъекта процесс, причем могут быть выделены следующие схемы задания разграничительной политики доступа к ресурсам:
Данный подход позволяет получить принципиально новые свойства защиты (например, корректно запретить возможность модификации системным пользователям, в частности System, системного диска и системных областей реестра ОС, что не обеспечивается встроенными в ОС механизмами защиты, чем в общем виде решить задачу противодействия атакам на расширение привилегий, и т.д., однако все эти возможности механизмов защиты мы не будем рассматривать в данной работе). Рассмотрим возможности данного подхода применительно к решаемой в данной работе задаче. Данный подход в полной мере реализован в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003, что иллюстрирует интерфейс соответствующего механизма защиты, приведенный на рис.6 (данный механизм позволяет настраивать разграничения прав доступа к объектам файловой системы: на жестком диске и на внешних накопителях, локальных и разделенных в сети, для разделенных – по исходящему и входящему запросам доступа). Здесь реализованы все подходы к построению механизма контроля доступа к ресурсам и к построению интерфейса механизма защиты, описанные выше, см. рис.4.  Если же говорить о задании разграничений для субъекта “процесс” (о реализации интерфейса механизма защиты), то здесь также целесообразен подход, предполагающий назначение прав доступа субъектам доступа (в данном случае – процессам), а не установка соответствующих атрибутов для объектов (в противном случае, сложность настройки механизма защиты возрастает геометрически). Рассмотрим, как мы можем использовать данный механизм. Опять же следует выделить различные (в общем случае, непересекающиеся) файловые объекты для хранения конфиденциальной и открытой информации. Далее следует назначить права доступа к этим объектам процессам (приложениям) в соответствии с реализуемыми ими режимами обработки информации, например, процессам, позволяющим осуществить передачу информации во внешнюю сеть, должен быть разрешен доступ только к объектам, предназначенным для хранения открытых данных, соответственно, процессам, используемым для обработки конфиденциальной информации не должен разрешаться (либо может разрешаться только по чтению) доступ к объектам, предназначенным для хранения открытых данных. Таким образом, разграничениями к файловым объектам мы локализовали режимы обработки соответствующей информации. Теперь надо предусмотреть возможность изменения (в нашем случае, понижения) статуса обрабатываемой информации. Как помним, первая проблема состояла в том, что ряд файловых объектов не разделяется между пользователями ОС и приложениями. Особенность рассматриваемого подхода состоит в том, что пользователь работает под одной учетной записью, а соответствующие разграничения вводятся для процессов, как следствие, в данном случае эта проблема теряет свою актуальность. Вторая проблема была связана с возможностью использования буфера обмена для изменения статуса обрабатываемой информации. Вот эта проблема здесь, что называется, «в полный рост» (о каких либо возможностях, предоставляемых встроенными в ОС механизмами, здесь говорить не приходится). В части противодействия этому нами реализовано (в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/200 следующее решение – механизм защиты, позволяющий разграничивать между пользователями (между учетными данными) доступ к буферу обмена, функционально расширен, в части возможности разграничивать права доступа к буферу обмена приложениям. В части задания субъекта доступа реализованы все возможности, описанные ранее - в качестве субъекта доступа может рассматриваться либо только пользователь, либо только процесс, либо «пара» – процесс и пользователь. Таким образом, объектом доступа здесь является буфер обмена, разграничения состоят в разрешении (основная политика – разрешительная), либо в запрете доступа, в данном случае, процессов (все они запускаются под одной учетной записью) к буферу обмена. В нашем случае следует запретить доступ к буферу обмена процессам, используемым для обработки открытых данных. Как и для предыдущего решения в данном случае остается и проблема локализации среды исполнения пользователя (данную проблему и способ ее решения, с использованием механизма защиты, интерфейс настройки которого проиллюстрирован на рис.4, который обязательно должен быть реализован и в рамках рассматриваемого подхода, мы рассмотрели выше). Вообще говоря, задачу локализации среды исполнения мы рассматриваем, как необходимое условие построения эффективной защиты информации. Если пользователю предоставляется возможность запуска лишь ограниченного его служебной деятельностью набора приложений, то исключается сама возможность использования дополнительного инструментария (какой-либо программы) для осуществления атаки на защищаемые ресурсы. Другим важнейшим приложением данного механизма защиты является обеспечение противодействие в общем виде запуску всевозможных вредоносных программ (троянов, червей и т.д.). Пусть у вас весь компьютер заражен подобными программами, полученными через почтовые вложения, через интернет или любым иным способом, запустить их не удастся. Кстати говоря, вновь обратимся к исследованию Infowatch о внутренних ИТ-угрозах в России. Интерессующий нас здесь фрагмент этого исследования приведен на рис.7, из которого видно, вредоносные программы специалисты относят к одной из наиболее опасных ИТ-угроз. Используя же решение, описанное выше, о подобной угрозе вообще можно забыть. На данном примере видим, что задачи противодействия внутренним и внешним ИТ-угрозам во многом пересекаются, как следствие, на наш взгляд, целесообразно вести речь о комплексной системе защиты – о едином средстве, которое в равной мере эффективно противодействует как внутренним, так и внешним ИТ-угрозам.  Итак, применение рассмотренного альтернативного подхода также позволяет корректно решить сформулированную в работе задачу противодействия внутренним ИТ-угрозам, сохранив все штатные возможности пользователя по обработке информации, причем, также практически не осложнив задачу администрирования средства защиты информации. Таким образом, рассмотренные в работе альтернативные подходы, в части обеспечивающей ими эффективности решения сформулированной в работе задачи, эквивалентны. Вместе с тем, подход, основанный на разграничении для процессов, характеризуется упрощением задачи администрирования соответствующих механизмов защиты. Вместе с тем, он менее универсален, в частности, если требуется обеспечить возможность одному пользователю различные режимы работы с сетевыми ресурсами (передача конфиденциальной информации только в рамках корпоративной сети, а открытой – в рамках открытой сети, то при разганичениях на основе учетных записей эта задача легко решается, по средством введения дополнительной учетной записи и задания для нее соответствующих ограничений. При разграничениях же по процессам, потребуется использовать различные приложения для передачи данных в корпоративной и в открытой сети. Однако на практике возможно комбинирование рассмотренных альтернативных подходов. Выбор же подхода в большой мере определяется тем, какая совокупность задач при защите конфиденциальной информации решается в комплексе (не будем забывать о внешних ИТ-угроза, необходимости антивирусного противодействия, противодействия шпионским программам, возможным ошибкам и закладкам в системном и прикладном ПО и т.д., все эти задачи позволяет эффективно решать КСЗИ «Панцирь-К» для ОС Windows 2000/XP/200 . В зависимости от этого в той или иной мере будут задействованы механизмы средства добавочной защиты, с учетом этого уже целесообразно принимать решение о реализуемом подходе для противодействия внутренним ИТ-угрозам. Заметим, что это уже все определяется политикой информационной безопасности, разрабатываемой при внедрении средства защиты, как видим, универсальной, не ориентированной на конкретное техническое средство, политика безопасности быть не может, она эффективна ровно в той мере, в какой мере эффективно используемое средство защиты информации. Тоже, но в меньшей мере, относится и к концепции безопасности, разрабатываемой, как правило, на начальном этапе построения системы защиты. Любая концепция, предполагает возможность ее реализации, поэтому она либо «ни о чем», либо опять же, основывается на возможностях предполагаемых к внедрению технических средств (кстати говоря, концепции, разработанные системным интегратором и разработчиком средства защиты, подчас, существенно различаются). В результате проведенного исследования можем сделать следующие выводы:
Приведенные же в работе (в первой и второй частях) исследования (в частности, сформулированные требования к механизмам защиты) можно рассматривать в качестве методологической основы оценки эффективности решения задачи противодействия внутренним ИТ-угрозам. Еще раз отметим, что далеко не все (мы позволим себе предположение, что лишь малая их часть) представленные сегодня на рынке средства добавочной защиты могут быть применены для противодействия внутренним ИТ-угрозам. Используя же данный материал, выявляющий условия эффективного решения данной задачи, потребитель средства защиты самостоятельно может оценить эффективность предлагаемого ему разработчиком решения. Важным моментом, на который здесь следует обратить внимание читателя, является то, что противодействие хищению данных инсайдером с использованием электронной почты или интернет ресурсов является лишь частным случаем применения рассмотренных технических решений. Использование рассмотренных в работе подходов обеспечивает корректное решение одной из ключевых задач защиты информации – задачу обеспечения обработки на одном вычислительном средстве информации различных уровней конфиденциальности при обеспечении различных режимов ее обработки. В работе предлагаются подходы к решению этой задачи в общем виде, приложения же могут быть различными. Таким образом, если в первой части работы мы рассмотрели в общем случае вопросы достаточности механизмов защиты для условий использования (рассмотрен подход (и его реализация) к решению задачи, состоящий в том, что все устройства, к которым не может быть корректно разграничен доступ, должны быть отключены), то в данной части работы мы рассмотрели вопросы корректности реализации разграничительной политики доступа к устройствам (на примере сетевых ресурсов), которые должны быть подключены для решения штатных задач пользователем. Следовательно, применение совокупности механизмов защиты, рассмотренных в данной работе (в первой и второй ее частях) позволяет выполнить требования к достаточности и к корректности решения задачи, что обусловливает эффективность практического использования рассмотренных подходов при решении задачи противодействия внутренним ИТ-угрозам. В заключение еще раз отметим, что рассмотренные в работе механизмы защиты реализованы и апробированы в составе Комплексной системы защиты информации (КСЗИ) «Панцирь-К» для ОС Windows 2000/XP/2003 (разработка ЗАО «НПП «Информационные технологии в бизнесе», сертификат ФСТЭК №1144 от 17.01.200 . Более подробно с этой и с другими разработками компании читатель может познакомиться на сайте: www.npp-itb.spb.ru, либо может обратиться к разработчикам с интересующим его вопросом по почте, по адресу: info@npp-itb.spb.ru. Читайте далее:  07 - 13 января 2008 года 28 - 31 января 2008 года Анализ рынка безопасности ,май 2005 года, Воровство в супермаркете 6. предпочтения участников рынка безопасности 2007 года Некоторые мысли после выставки mips 2008 Security 50 – лучшие в мире 50 компаний в области безопасности по объему продаж 01 - 03 февраля 2008 года 1.4. действия сил охраны 25 - 29 февраля 2008 года 07 - 13 апреля 2008 года ,рынок it, 21 - 27 апреля 2008 года ,рынок it, Адаптер sb-1 для монтажа видеокамер на столбах 01- 04 мая 2008 года ,рынок it, 12 - 18 мая 2008 года ,рынок безопасности,
|
