ИТБ

"Игрушки" хороши для Бонда. При защите же конфиденциальных данных, хищение которых может нанести большой вред, надо формулировать и решать задачи профессионально. Если мы говорим о шифровании на флеш, то не так важно, программно, аппаратно, важно, чтобы пользователь, имея эту флэш, украв компьютер со свеми установленными драйверами защиты, не смог дома все это расшифровать. А это уже вопросы реализации ключевой политики - несколько ключей, только один из которых доступен пользователю. Здесь шла речь о троянах, нет ничего проще предотвратить возможность запуска на компьютере любого деструктивного кода, необходимо защищать системный диск от модификации даже с правами System - не сложная задача. Можно разграничивать права доступа к ресурсам для процессов, например, для winword.exe (сохраните и системный диск и реестр). Нужно просто использовать комплексные эффективные средства защиты, обладающие соответствующим набором механизмов защиты, которых нет в ОС. Кстати, цена подобной системы, сопоставима с ценой одной "флешки для Бонда". Просто, если хотим защитить, надо начинать с азов, а не "вырывать" из множества отдельную, замечу, одну из простейших в части практического решения, задачку защиты и долго обсуждать, как ее решить.

Познакомьтесь с КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003 (разработка ЗАО "Нпп "Информационные технологии в бизнесе") www.npp-itb.spb.ru. Данная система позволяет защитить системный диск от модификации даже для пользователя System. Возможности применения описаны в разделе "Публикации"

Коллеги, если с flash-устройствами требуется работать (нельзя отключить), то никакие орг.меры не помогут. Есть одно средство - шифрование, причем ключ шифрования должен быть недоступен пользователю. Тогда хищение данных не приведет к раскрытию их конфиденциальности. В качестве примера такого решения предлагаю познакомиться с СЗД "Панцирь" для ОС Windows 2000/XP/2003 (на сайте www.npp-itb.spb.ru). И обратите внимание на реализацию ключевых политик, это очень важно для противодействия раскрытию информации (при хищении) санкционированным пользователем.

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

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

Зашедшему. Подготовил статью по поводу полномочного контроля доступа. Если интересует, могу сбросить, сообщите куда (мой info@npp-itb.spb.ru)

По поводу ноутбуков. Это серьезный вопрос и (не в порядке рекламы, а то меня все время в этом обвиняют) мы предлагаем в нашем средстве СЗД для ОС Windows 2000/XP/2003 реализацию такой ключевой политики (при шифровании), которая обеспечивает невозможность расшифрования данных пользователем при наличии данных, установленной СЗД (т.е. полностью компьютера) и ключа шифрования (можете познакомиться с решением на нашем сайте www.npp-itb.spb.ru). Относительно формализации все правильно, вопрос в том, кто это осуществляет и какой результат получает потребитель (это же основа для построения системы защиты), вот в чем вопрос.

Уважаемые коллеги, вопросы от разработчика средств защиты. Два вопроса. 1. Сейчас мы пытаемся усилить свои средства защиты механизмами контроля действий пользователей на защищаемых компьютерах. Один из подобных механизмов состоит в оперативном визуальном контроле действий пользователей. Краткое описание ниже. Вопрос. Насколько по вашему мнению данная функция полезна и будет востребована? 2. Поделись своим опытом (как разработчикам, нам это важно). Какие функции контроля вам бы пригодились и были бы полезными? Краткое описание подсистемы. Для обработки информации на защищаемом объекте пользователю необходимо средство отображения – монитор. Экранная копия представляет собой моментальное отображение (снимок) действий пользователя на компьютере. Следовательно, контроль действий пользователей на защищаемых объектах корпоративной сети предприятия, как правило, возлагаемый на администратора безопасности, может осуществляться визуально, по средством сбора и обработки экранных копий (снимков). Таким образом, основной задачей визуального оперативного контроля действий пользователей можно считать оперативный сбор (в реальном времени) на сервер безопасности (АРМ администратора безопасности) экранных копий (снимков) с защищаемых компьютеров в сети. Если говорить о подходах к решению, то, в первую очередь, следует понимать, что основной проблемой реализации подобного контроля становится существенное возрастание загрузки связного ресурса, что в значительной мере может снизить пропускную способность канала связи корпоративной сети. С учетом требований к минимизации нагрузки на сеть, раелизована следующая совокупность решений задачи: 1. Периодический (синхронный) визуальный контроль. Данный контроль состоит в том, что для контролируемых рабочих станций устанавливается расписание получения экранных копий на сервер (например, 1 раз в минуту, в такие-то дни, в такое-то время). Экранные копии поступают на сервер безопасности в реальном времени. Данный способ может использоваться для общего контроля действий пользователей на защищаемых компьютерах. Недостатком этого способа является то, что не может устанавливаться малый интервал контроля одновременно для многих компьютеров в сети. 2. Асинхронно-синхронный визуальный контроль. Данный подход предполагает реализацию причинного запуска механизма контроля. В качестве причины предлагается рассматривать два события (их совокупность) – запущенный процесс (приложение) и активность окна соответствующего приложения на мониторе. В этих условиях механизм контроля запускается. Для запущенного же при заданных условиях контроля устанавливается расписание получения экранных копий на сервер (например, 1 раз в 10 секунд). Экранные копии поступают на сервер безопасности в реальном времени. Данный способ может использоваться уже для контроля действий пользователей с конкретными приложениями (например, с электронной почтой и др., причем, как с одним, так и с несколькими). В отличие от предыдущего подхода, здесь без существенного увеличения загрузки сети можно установить более детальный контроль (можно установить небольшой интервал времени выдачи экранных копий (снимков) на сервер безопасности) действий пользователей для критичных приложений. 3. Асинхронный (разовый по запросу администратора) визуальный контроль. Данный подход реализует возможность получения экранной копии с контролируемых компьютеров в реальном времени по запросу администратора (на запрос администратора выдается один текущий снимок экрана). 4. Асинхронный (непрерывный) визуальный контроль. Данный подход реализует возможность отображения на сервере безопасности в реальном времени экрана контролируемого компьютера. Запускается контроль администратором и непрерывное в реальном времени отображение экрана на мониторе сервера безопасности осуществляется до момента отключения контроля администратором. Предлагаемые альтернативные способы запуска контроля функционально независимы, поэтому могут осуществляться одновременно (параллельно). С учетом того, что, с одной стороны, может возникнуть возможность просмотра экранных копий (снимков) повторно (по запросу администратора), с другой стороны, данные снимки могут послужить доказательной базой несанкционированных действий пользователя, снимки не только отображаются на мониторе сервера безопасности, но и сохраняются (кроме способа непрерывного визуального контроля) в базе сервера безопасности. Эта база формируется следующим образом. Для каждого контролируемого объекта создается свой каталог для хранения снимков, снимок представляет собою файл, имя которого содержит дату и время его формирования). Таким образом, администратор имеет возможность просмотра сохраненных снимков по дате и по времени (соответственно, просмотра сохраненных снимков за интересующий его период времени).

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

Зашедшему. Вопрос. Вы действительно серьезно относитесь к таким формализациям, как модели нарушителей и угроз? Если эта информация не конфиденциальная, хотелось бы взглянуть, если возможно, перешлите на мой адрес info@npp-itb.spb.ru. Меня всегда интересовали такие вещи, как можно прописать в списке угроз, например, ошибку в приложении и т.д. На Ваш вопрос. Мы уже обсуждаем его несколько раз и что-то не понимаем друг друга. Суть в следующем. Если полльзователь размечен как конфиденциальный и имеет право на запись только в конфиденциальный каталог (нет понятия сессии), то любой вновь создаваемый им документ может быть сохранен только в конфиденциальном каталоге (этот как работа с документами в первом отделе). Речь идет не о том, что он какой-то документ прочтет, модифицирует и сохранит, а введет текст заново - создаст новый документ. При различных сессиях, он сможет сохранить вновь созданный документ, как в конфиденциальном, так и в открытом каталоге.

1, При нашем способе нет необходимости входить под разными пользователями. Вы можете разрешить вход только под одним (у нас же свой механизм авторизации ользователя при входе в систему), можете под разными, причем с одним паролем. Уже когда вошли, Вы можете в проводнике выбрать необходимый исполняемый файл и по правой кнопке его запустить с правами другого пользователя. При этом Вам выпадет диалог выбрать пользователя, с правами которого запустить приложение и ввод пароля ОС (пароль можно оставить пустым - у нас своя авторизация, с правами какого можно или нельзя запустить также можно контрролировать нашим механизмом контроля олицетворения и заимствования прав). У нас ничего перезагружать не нужно. Если же необходимо, отключите эту возможность и реализуйте вход пользователя под своей учетной записью (с тем же паролем) под другую сессию (учетная запись - это сессия), получите решение, аналогичное рассматриваемому Вами. 2. Контрпример. Вы опять берете некий отдельный пример не в общем контексте решения задачи. Здесь опять же есть различные решения (разработка этих решений есть разработка политики безопасности). То что Вы описали проше сделать с использованием ручки и листа бумаги, для этого незачем открывать два окна (на бумаге получится быстрее и вынести проще). 3. По моему примеру. Речь о том, что пользователь вводит новый документ в компьютер, пусть с листа бумаги (а не модифицирует существующий). Если он может выбирать сесиию, то он введет этот документ туда, куда захочет, вне зависимости от гифа документа. 4. Естественно, что я это и предполагаю, иначе бы мы не вели столь интерессную и, наверное, полезную (причем обеим сторонам, мне ведь тоже интересно мнение специалиста, использующего средство защиты - подобные мнения во многом формируют направление развития наших продуктов. Сделать подобное решение, как Вы описываете, для нас (на основе существующих) несколько недель, вопрос - стоит ли - я также постоянно апробирую правильность своей позиции). Речь велась о том, что не следует упрощать средства защиты, да еще позиционировать это как потребительское свойство СЗИ, в угоду возможной низкой квалификации потребителя. Моя позиция, следует упрощать администрирование, но не возможности СЗИ.

Относительно по пользователю на каждый гриф. А у Вас так много грифов - открытая и конфиденциальная (2, ну три пользователя, в чем сложность). Относительно сессии. Вы говорите об интервале времени между перезагрузками. Т.е. при переходе от сессии к сессии нужна перезагрузка? Есле запускать ппроцессы с правами различных пользователей, по сути это и есть выбор сессии (Вы завели двух пользователей - открытый и конфиденциальный со своими разграничениями), то перезагрузка не нужна, у Вас одновременно могут быть открыты приложения обоих пользователей (сессиий), в обоих Вы можете работать (буфер обмена между пользователями изолирован нашими средствами (ОС при таком запуске его не изолирует), у каждого пользователя своя корзина, для каждого пользователя свои разграничения - к принтеру, к хостам (по TCP, UDP/IP) и т.д. Так что удобнее (усложнение настройки исчисляется секундами). Кстаити говоря, Вы рассматриваете лишь одну задачу из совокупности. Например, кардинально новые возможности защиты предоставляет разграничения для процессов (приложений) с правами или вне прав пользователей и т.д. Трудно это связать с полномочными разграничениями. Относительно ввода нового документа я говорил о другом. Пользователю требуется создать совершенно новый документ (ввести текст с консоли). Документ конфиденциальный. Он создает сессию открытой обработки и записывает созданные данные в открытый каталог, кто проконтролирует? Относительно сложности - здесь две стороны медали. С одной стороны, СЗИ должна быть простой в эксплуатации (но в моем понимании, разработчик СЗИ не должен ориентироваться на дурака администратора, простой, не значит в ущерб защищенности - реализация одной коасной кнопки "защитить", с другой стороны, должна обладать достаточным набором механизмов защиты (которые могут востребоваться не сразу, а в процессе эксплуатации) для решения задач при различных изменениях ее эксплуатации. Например, в используемом вами приложении обнаружена дыра, которая будет исправлена разработчиком через 5-8 месяцев, что делать, откзататься от использования приложения - в нашей КСЗИ Вы в этом случае сможете воспользоваться механизмом доверительного контроля доступа (разганичить права доступа для скомпрометированного приложения). Относительно того, что смотреть ПО в работе совершенно согласен. Я говорил, что сначала нужно посмотреть по документации потенциальные возможности СЗИ (может быть в результате этого Вам и продукт смотреть не захочется - не подойдет по сфоим функциям). Если фунционал ПО интересен, тогда конечно следует смотеть эксплуатационные свойства.

Зашедшему. Уровень сессии появился еще в СЗИ "Сраж-NT", где процессы можно запускать одним пользователем с разными правами (то о чем я писал, это не та система, которую Вы рассматриваете). Вместе с тем, относительно уровня сесии я и говорил - максимальный уровень из открытых документов. Еще раз отмечу, я категорически против подобной позиции - все права должны определяться правами пользователя (это основа построения системы защиты ОС). По моему мнению, права пользователя не должны изменяться в зависимости от категории обрабатываемой информации, т.е. быть динамическими. Естественно, что при таком подходе внешне решение выглядит "изящно", но, наверное, танк Вы будете выбирать не по наличию в нем кондиционера. Как Вы думаете, сколько существует способов взаимодействия процессов (поименованные каналы и т.д., мне известен десяток, не задумываясь) а, эти СЗИ гарантируют перекрытие всех, а если Вы запустите один и тот же процесс с разными правами (в разных сессиях). Дело в том, что при подобном подходе естественно появляется масса проблем, т.к. это противоречит принципам построения самой ОС, буфер обмена и корзина - это очевидные проблемы. Я не утверждаю что-либо по конкретной системе, я против такого подхода в принципе (однако, это мое личное мнение, возможно я не прав и разработчиком конкретной системы решены все проблемы, тогда хорошо - это пусть решает тот, кто использует средства защиты). С точки зрения нового документа, вопрос как контролировать его уровень, если пользователь может быть в разных сессиях (в какой будет, с тем грифом и будет создан новый документ). По поводу буфера обмена - если Вы откроете два текстовых редактора под одним пользователем (дважды запустите один и тот же процесс) и запустите их в разных сессиях - одним прочитаете документ одного уровня, другим другого, что с буфером обмена (я фантазирую, конкретно с системой, которую Вы смотрите, я не знакомился, т.к. меня интересуют только сертифицированные продукты, да и нет времени смотреть на все). Для получения демоверсии нашей системы Панцирь-К существует определенный порядок, с условиями Вы можете познакомиться на нашем сайте www.npp-itb.spb.ru (в закладке Демоверсия). Также на сайте есть полный комплект документации на систему, его вполне достаточно для ознакомления с основными свойствами.

Забыл ответить на следующий важный вопрос: "В ОС windows nt и выше реализован дескриционный механизм разграничения доступа, причем достаточно мощный и гибкий. Зачем создавать новый ?" Я принципиально не согласен с этой позицией. Не будем забывать, что эта ОС универсальная, а не созданная для защиты конфиденциальной информации в корпоративной сети предприятия. Все ее механизмы защиты могут быть кардинально пересмотрены (что мы и делаем в своих разработках). В рамках форума дать развернутый комментарий на этот вопрос не представляется возможным, однако у меня есть статья (десяток страниц) именно по этому поводу. Если интересует, готов "закинуть" для ознакомления, сообщите куда.

Важно не то, что реализовано, а то, как реализовано. Рассмотрим возможный пример реализации "Полномочки". Пусть "Полномочка" состоит в том, что один и тот же пользователь может обрабатывать как открытую, так и конфиденциальную информацию, причем текущий уровень пользователя определяется максимальным уровнем открытого документа (такой уровень получает процесс, открывший документ). Но беда-то в том, что все остальные разграничения (не к файловым объектам) реализуются под учетную запись. Вот Вам противоречие - под одной учетной записью можно обрабатывать информацию различных грифов, следовательно ко всем внешним ресурсам (не к файловым объектам) необходимо уже разграничивать для разных пользователей - но тогда один пользователь не должен обрабатывать одновременно информацию разных грифов (как с практическим использованием подобной "полномочки"). Я ранее утверждал, что единственно корректный способ разграничений - по пользователям (иначе сразу натолкнемся на проблему буфера обмена и т.д.), сразу будем говорить о необходимости отключения корзины и т.д. и т.п. Другое противоречие. А с каким грифом будет вновь созданный документ, кто это проконтролирует - пользователь одновременно может создать его с различными грифами (кстати такое было бы невозможно, если бы полномочка была бы реализована в соответствии с соответствующими требованиями к данному механизму - уровень пользователя статичен, не изменяется в зависимости от уровня обрабатываемых данных). Этот ряд можно продолжить. style_emoticons/default/smile9.gif