зашедший

Допустим ОС заменят на линукс например, хотя может действительно решат с нуля сделать, а что будут делать с аппаратурой ? Оставить вражескую - проблема остается не решенной, создать свою - малореально. Можно конечно просто обеспечить недоступность критичной техники для внешнего воздействия, но такой проект дает возможность распила гораздо меньшей суммы денег, да и звучит это не очень круто, пиару не спосбствует...

У меня есть модели нарушителей, есть соответствующие списки угроз. Я сопоставляю эти угрозы с алгоритмами работы СЗИ. Политика безопасности, с моей точки зрения, описывает общие концепции. А я привел частный случай обработать который и должна конкретная подсистема системы безопасности. С теоритической точки зрения - может быть. А на практике сотрудник осознает, что его действия есть кража информации, то что он списывает данные на бумагу обязательно увидят коллеги - все это заставляет нервничать. Кроме того, у нас например, для черновиков используется прошитые блокноты, так что на бумаге вынести не получится. Вернее можно, но очень рисковано. Вы имеете в виду, что для назначения грифа вновь созданного вручную документа пользователь должен создавать его в определенной сессии ?

2 MOS сравните какие установлены сервис-паки, хотфиксы и версию джава-машин

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

2 Andrew Рекомендую начать с организации мониторинга офисных телефонов и интернет. Писать и если нет возможности постоянно анализировать, то хранить до момента когда появится необходимость. В интернет логах смотреть в первую очередь кому шлют мыло и кто ищет новую работу. Если не можете запретить, то хотя бы выявите людей использующих на рабочих местах внешние почтовые сервисы (типа mail.ru). Программные и некоторые административные способы защиты от слива информации обсуждаются тут http://it2b-forum.ru/index.php?showtopic=769. После этого уже можно думать о самой провокации. Кроме этого рекомендую обратить внимание на те советы которые дал MOS (сообщении от Mar 16 2006, 18:41). Единственное что бы добавил, разговор с конкурентом проводить в последнюю очередь, если провокация результатов не даст. И естественно о ваших действиях должно знать минимальное кол-во сотрудников.

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

Еще один момент забыл. Понижать гриф документа в SecretsSaver Corporate может только офицер безопасности. Сотрудник может только повышать.

2 ИТБ Так как я наиболее подробно познакомился с СЗИ SecretsSaver Corporate, то скажу как это реализовано в ней. Понятия текущий уровень пользователя в вашем контексте там нет. Есть текущий уровень сессии. Равен максимальному грифу открытого документа. Как ограничивается доступ к ресурсам не знаю, но возможность распространять информацию блокируется в зависимости от уровня доступа пользователя к сети и сменным носителям и от текущего уровня сессии. Т.е. если сотрудник имеет уровень доступа к сети равный "секретно", а уровень доступа к сменным носителям равный "общедоступно", то после открытия документа с грифом "секретно" будет заблокирован доступ к сменным носителям, а после открытия документа с грифом "сов.секретно" будет заблокирован и доступ к сети. Вновь созданный документ будет иметь гриф равный уровню сессии. Поэтому проблемы с буфером обмена нет. Корзина должна быть отключена, но в нашем случае это абсолютно не критично. Кстати в письме я Вас спрашивал, ответа не получил к сожалению. Продублирую. Каким образом можно посмотреть Ваш продукт в действии ? То что Вы рассказываете очень интересно, но хотелось бы составить собственное впечатление.

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

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

Я имел в виду что секретный файл лежит в общедоступной папке. Как может быть понижен уровень секретности информации в файле ?

А если оставить папку общедоступной, где канал утечки ? Какие от этого проблемы ?

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

Процесс именно изъятия винчестера известен как маски-шоу. Личности исполнителей разглашению не подлежат, хотя вроде вышло какое-то постановление чтобы в дальнейшем шоу проводилось без масок. Если разговор именно об изъятии то пусть их там хоть сотня, изымут вместе с сервером. И криптоанализировать не надо просто спросят пароль и админ его сразу скажет. Это без вариантов. Я думаю, что имелась в виду кража информации с винчестера. Что хоть и не так громко, но не менее не приятно, так как может быть проведено не заметно.

Уважаемый ИТБ Во-первых спасибо за ответ-пример, это именно то что я хотел от вас получить. Тут я должен согласиться с уважаемым motov'ым, что с точки зрения пользователя вариант не слишком удобный, хотя возможно задачу он решает. Во-вторых предлагаю учесть, что технический уровень присутствующих на форуме специалистов, в большинстве своем не позволяет им обсуждать архитектуру системы защиты на равне с вами, так как опыта разработки подобных систем у присутствующих скорее всего нет. Поэтому, я предлагаю вместо (или как минимум кроме) теоритических обоснований приводить практические их реализации. Например, вы говорите об грифе на секретный диск. Практический пример иллюстрирующий ваши доводы - использование низкоуровневого дискового редактора для доступа к секретной информации. Я правильно понял ? Хотелось бы чтобы вы приводили подобные примеры для остальной своей аргументации. Примите во внимание, что руководство, которое часто принимает окончательное решение, скорее всего не дочитает до конца доклад написанный профессиональным языком. И вопрос по "Панцирю". В нем реализован механизм создания замкнутой программной среды. Поясните пожалуйста, необходимость включения в продукт данного механизма - это исключительно требования РД или аналогичный механизм (Software Ristriction Policy) реализованный в Windows имеет какието недостатки ? И если имеет, то опять попрошу прокоментировать примером.