защита информации от кражи персоналом

[ИТБ]

Относительно замечания:

 

Пользователь систем имеет доступ "общедоступно", т.е. к секретам доступа нет.

Все субъекты по умолчанию - общедоступно. Это я о SecretsSaver и SecretNet.

 

А что делать с ситемным диском, он также должен быть помечен (как по требования РД, так и по соображениям здравого смысла).

 

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

[зашедший]

Уважаемый ИТБ

Во-первых спасибо за ответ-пример, это именно то что я хотел от вас получить. Тут я должен согласиться с уважаемым motov'ым, что с точки зрения пользователя вариант не слишком удобный, хотя возможно задачу он решает.

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

Хотелось бы чтобы вы приводили подобные примеры для остальной своей аргументации. Примите во внимание, что руководство, которое часто принимает окончательное решение, скорее всего не дочитает до конца доклад написанный профессиональным языком.

 

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

[Toparenko]

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

8314[/snapback]

В том-то и задача, что все внешние накопители отключить нельзя. На отчуждаемый носитель должна выводиться только неконфиденциальная информация.

 

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

Если только стоит задача не хранить секреты на пк, но работать с ними только на пк ?

8314[/snapback]

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

 

В любом случае пока я не вижу (кроме оргмер) возможности:

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

- снижения степени конфиденциальности данных без появления отдельного супервизора (встает вопрос контроля за ним и ведения логов изменения степени конфиденциальности данных).

 

Подобные действия (вообще-то) должны производится как минимум двумя лицами (команда одного уполномоченного пользователя с подтверждением другого)...

Т.е. например дома он доступ к этой информации не получит, т.к. там нет одного из ключей. А зачем тогда вообще сменные носители ? Чтобы внутри офиса информацию переносить ?

8297[/snapback]

На счет работы дома - тут стоит ввести категорический запрет или работа в терминале (как минимум через VPN) без подключения ко всей сети/базе (только со специально созданным для данной работы массивом данных).

 

Отчуждаемые носители только для выдачи информации внешним адресатам.

Заводите две учетные записи - одна для работы с секретными данными

лругая - открытыми. Пусть пользователь авторизуется и входит в систему с секретными правами (можно и наоборот). Для каждой - свои разграничения

8313[/snapback]

"А теперь вопрос" (с):

1. Что делать если обе эти учетные записи необходимы системному администратору (не администратору безопасности) - возможности по изменению полномочий, возможность входа от имени системы и т.п.?

2. Что делать если эти две учетные записи принадлежат администратору безопасности (который в единственном числе) - порядок контроля за его действиями, полномочия по изменению/удалению логов, кто контролирует действия/логи?

[ИТБ]

Зашедшему.

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

Второе. Я говорил о грифе не на секретный, а на системный диск.

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

Четвертое. В Windows амкнутость программной среды реализован относительно неплохо. Нехостатки (как я их вижу):

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

2. Замкнутость программной среды определяется не только исполняемыми файлами. Например - это bat файлы (командные интерпретаторы, виртуальные машины). Их запуск происходит по запросу не на выполнение, а на чтение. Механизм не работает.

3. Интерес представляет замкнутость программной среды не только для пользователя, но для процесса - когда процессу можно указать, какие иные процессы он может запускать (субъект доступа процесс и объект доступа процесс). Данная очень полезная на практике опция не реализована.

[ИТБ]

Toparenko

Мы можем усекать возможности администратора (например, админисртратор безопасности определяет, что может системный администратор). Один всегда должен быть главным - а как иначе?

В Unix мы все это делаем программно (можем установить любые права пользователю root, но не администратору безопасности), в Windows для этого программно-аппаратная реализация (плата поставляется к КСЗИ Панцирь-К опционально (здесь разграничить доступ системному администратору мы можем, а вот предотвратить им снятие наших драйверов (контролировать можем - у даленно, с сервера, предотвратить нет) без платы очень сложно (кстати говоря, это аппаратное решение нами запатентовано)