8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Вы находитесь в разделе Типовых решений систем безопасности

Современные условия использования вычислительных средств диктуют необходимость новых требований к их защите



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

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

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

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

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

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

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

Однако в данной работе мы будем говорить о функциональной безопасности системных средств.

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

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

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

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

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

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

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

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

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

На Рис.1 представлен интерфейс, реализованного в КСЗИ Панцирь-К для ОС Windows 2000/XP/2003, механизма Проверка олицетворения субъектов доступа.

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



Рис.1

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

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



Рис.2

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

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

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

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

Данный нормативный документ используется при аттестации объектов информатизации.

Например, в части защиты конфиденциальной информации это требования к классу АС 1Г. Применительно к рассматриваемым нами вопросам реализации разграничительной политики доступа к ресурсам, остановимся на следующем всеобъемлющем требовании:
  • Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.


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

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

Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе (Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации). Например, в части реализации разграничительной политики доступа к ресурсам для средств, предназначенных для защиты конфиденциальной информации (5 класс СВТ), данные требования формулируются следующим образом:
  • КСЗ (комплекс средств защиты) должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).
  • Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту).
  • КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа.
  • Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).
  • Механизм, реализующий дискреционный принцип контроля доступа, должен предусматривать возможности санкционированного изменения правил разграничения доступа (ПРД), в том числе возможность санкционированного изменения списка пользователей СВТ и списка защищаемых объектов.
  • Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).


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

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


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

В порядке иллюстрации реализации данного основополагающего механизма защиты персонального компьютера, на Рис.3 – Рис.6 проиллюстрированы интерфейсы его настройки в КСЗИ Панцирь-К.

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



Рис.3



Рис.4



Рис.5



Рис.6

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

Задачи контроля доступа к ресурсам для персонального компьютера

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

Достаточно обратиться к анализу существующей статистики уязвимостей современных системных средств (например, на сайте www.itsec.ru, систематически публикуемой в разделе Новости), чтобы показать, что в общем случае именно процесс следует рассматривать в качестве источника возникновения внешней ИТ-угрозы. Может быть предложена следующая классификация процессов, в основу которой положено группирование свойств процессов, порождающих внешние ИТ-угрозы:
  • Несанкционированные (сторонние) процессы. Это процессы, которые не требуются пользователю для выполнения своих служебных обязанностей и могут несанкционированно устанавливаться на компьютер (локально, либо удаленно) с различными целями, в том числе, с целью осуществления несанкционированного доступа (НСД) к информации, разрушающих воздействий на защищаемые ресурсы, осуществления шпионских функций и т.д.;
  • Критичные процессы. К ним мы отнесем две группы процессов: к процессам первой группы отнесем те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, это сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой, атаки на процессы второй группы наиболее вероятны;
  • Скомпрометированные процессы – процессы, содержащие ошибки программирования (уязвимости), ставшие известными, использование которых позволяет осуществить атаку на компьютерные ресурсы. Отнесение данных процессов в отдельную группу обусловлено тем, что с момента обнаружения уязвимости злоумышленником и до момента устранения ее разработчиком системы или приложения (выхода в свет соответствующего path-а), может пройти несколько месяцев. В течение всего этого времени в системе находится известная уязвимость, поэтому система не защищена (и хорошо, если известная уязвимость будет устранена еще до появления новой, в противном случае, получаем непрерывное состояние уязвимости системы). Чтобы понять, насколько данная проблема сегодня критична, достаточно познакомиться со статистикой обнаружения и исправления ошибок в офисных приложениях;
  • Процессы, априори обладающие недекларируемыми разработчиком (документально не описанными) возможностями. К этой группе мы отнесем процессы, являющиеся средой исполнения (прежде всего, это виртуальные машины, являющиеся средой исполнения для скриптов и апплетов, и офисные приложения, являющиеся средой исполнения для макросов).


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

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

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

Теперь рассмотрим примеры механизмов защиты, реализованных в КСЗИ Панцирь-К в части реализации предложенной концепции защиты информации для персональных компьютеров.

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



Рис.7

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

В порядке замечания отметим, что под данные разграничения подпадают и все системные процессы (здесь не важно под какой учетной записью запускается процесс). Для обеспечения работоспособности системы при данных настройках некоторым системным процессам, таким, как winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe необходимо разрешить право записи на системный диск. Однако это не приведет к снижению безопасности системы, т.к. данные системные процессы не имеют пользовательского интерфейса.

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

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

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

Таблица 1
Разграничение доступа к файловым объектам
Приложение: The Bat !
Имя процесса : D:\Program Files\The Bat!\thebat.exe
Чтение Запись / Чтение Выполнение
D :\ Documents and Settings \”Имя пользователя”\ Мои документы\ Mail (или другой базовый каталог для почты) D:\Documents and Settings\” Имя пользователя ”\Local Settings\Temp D:\Program Files
  D :\ Documents and Settings \”Имя пользователя”\ Мои документы\ Mail (или другой базовый каталог для почты) D:\WINDOWS
Таблица 2
Разграничение доступа к объектам реестра
Приложение: The Bat !
Имя процесса : D:\Program Files\The Bat!\thebat.exe
Чтение Запись / Чтение
HKCU\SOFTWARE HKCU\SOFTWARE\RIT\THE BAT!
HKLM\SOFTWARE\MICROSOFT  
HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL  
Таблица 3
Разграничение доступа к файловым объектам
Приложение: Outlook Express
Имя процесса : D:\Program Files\Outlook Express\msimn.exe
Чтение Запись / Чтение Выполнение
  D :\ WINDOWS \”Имя пользователя”. WAB D:\Program Files
  D:\Documents and Settings\” Имя пользователя ”\Local Settings\Application Data\Identities\{BCAEFC1C-30B6-4025-8093-90C08423123C}\Microsoft\Outlook Express D:\WINDOWS
  D:\Documents and Settings\” Имя пользователя ”\Local Settings\Temp  
Таблица 4
Разграничение доступа к объектам реестра
Приложение: Outlook Express
Имя процесса : D:\Program Files\Outlook Express\msimn.exe
Чтение Запись / Чтение
HKCR\CLSID HKCU\CLSID
HKCU\APPID\MSIMN.EXE HKCU\IDENTITIES
HKCU\SOFTWARE HKCU\SOFTWARE\MICROSOFT\
HKLM\SOFTWARE  
HKLM\SYSTEM\CURRENTCONTROLSET  
Таблица 5
Разграничение доступа к файловым объектам
Приложение: Internet Explorer
Имя процесса : D:\Program Files\Internet Explorer\IEXPLORE.EXE
Чтение Запись / Чтение Выполнение
D:\Documents and Settings\” Имя пользователя ” D:\Documents and Settings\” Имя пользователя ” D:\Program Files
    D:\WINDOWS
Таблица 6
Разграничение доступа к объектам реестра
Приложение: Internet Explorer
Имя процесса : D:\Program Files\Internet Explorer\IEXPLORE.EXE
Чтение Запись / Чтение
HKCR\  
HKCU\  
HKLM\HARDWARE  
HKLM\SOFTWARE  
HKLM\SYSTEM\CURRENTCONTROLSET  
Когда ставятся задачи защиты от атак на сетевые приложения, защиты от шпионских программ и т.д. естественно в качестве ресурсов рассматривать и объекты сети. Здесь опять же следует разграничивать права доступа к ресурсам для процессов, в частности, разрешать доступ в сеть только тем процессам, которым необходима для обеспечения возможности выполнения сотрудником своих обязанностей, при необходимости, только к тем хостам, к которым требуется. Т.е. задача, аналогичная предыдущей, с поправкой на то, что в качестве ресурсов выступаю объекты сети.

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



Рис.8

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



Рис.9

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

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

На Рис.10 представлен интерфейс (реализованный в КСЗИ Панцирь-К) управления доступом к буферу обмена. Настройками в интерфейсе, приведенном на Рис.10, соответствующему процессу запрещено использование буфера обмена.



Рис.10

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

Как видим, современные условия использования вычислительных средств диктуют необходимость новых требований к их защите!




Читайте далее:
Ах ты, камбала - не вобла...
Ежегодный анализ тайваньского рынка безопасности.
Комментарий к security 50
04 - 10 февраля 2008 года
Созидающая волоконная оптика
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,