Вы находитесь в разделе Типовых решений систем безопасности

Методологическая основа сравнительного анализа средств защиты конфиденциальной информации ,часть 1,

На сегодняшний день системы защиты информации, представленные на рынке, сильно различаются, как по набору механизмов защиты, так и по подходам к реализации (реализованным возможностям) отдельных механизмов, причем базовых, требования к которым формализованы в нормативных документах (речь не идет о дополнительных возможностях защиты). Это вводит в заблуждение потребителя, не имеющего профессиональной подготовки в данной области знаний, т.к. формально для него подобные системы равноценны – выполняют требования одних и тех же документов. Естественно, что подобное возможно либо при недостаточно жесткой (либо недостаточно корректной) формализации требований, либо при неоднозначном трактовании формализованных требований разработчиками средств защиты информации. В данной работе мы попытаемся разобраться в данном вопросе - выявим причины возможного неоднозначного трактования формализованных требований и соответствующим образом попытаемся их уточнить (не изменить). Результатом проводимых исследований станет разработка МЕТОДОЛОГИЧЕСКОЙ ОСНОВЫ СРАВНИТЕЛЬНОГО АНАЛИЗА СРЕДСТВ ЗАЩИТЫ КОНФИДЕНЦИАЛЬНОЙ ИНФОРМАЦИИ.

Методологическая основа формализации требований к средствам защиты информации

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

Таким образом, именно уязвимость системы защиты – это признак системы, а наличие (отсутствие) уязвимостей является характеристикой защищенности системы.

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

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

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

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

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

Вопросы формализации требований к корректности реализации механизмов защиты информации

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

Формализованные требования к корректности реализации разграничительной политики доступа к ресурсам определены действующим сегодня нормативным документом (Гостехкомиссия России. Руководящий документ. Средства вычислительной техники.

Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации), в части защиты конфиденциальной информации (5 класс СВТ), следующим образом:

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

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

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

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

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

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

Данные требования определяют возможность задать ПРД для любого пользователя (включая пользователей System и root) к любому объекту (включая системный диск, системные объекты реестра ОС и т.д.), причем для любых типов доступа (включая их модификацию). Это следует из требования Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.)….

Данные требования определяют возможность разделить любой объект между всеми пользователями (в системе не должно быть объектов, в частности, файловых, которые невозможно разделить между пользователями средством защиты). Это следует из требования Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов). Заметим, к таким объектам, например, можно отнести папку: “All Users” на системном диске для ОС Windows. Некоторые приложения должны сохранять данные в одной папке, вне зависимости от того, под какой учетной записью они запущены. Невыполнение данного требования делает уязвимой информацию при многопользовательском режиме ее обработки.

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

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

В общем случае файловый объект может быть идентифицирован различными способами.Рассмотрим эти способы, на примере NTFS:

• Файловый объект идентифицируется именем, при этом:
• Файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться, как по длинному, так и по короткому имени, например к каталогу “\Program files\” можно обратиться по короткому имени \Progra~1\;
• Файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например, короткое имя для каталога C:\Documents and Settings\USER1\Главное меню выглядит как C:\Docume~1\USER1\5D29~1\. К этим объектам также можно обратиться, как по длинному, так и по короткому имени;
• Файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.
• Файловый объект может адресоваться не напрямую, а с использованием ссылок (ссылки бывают жесткие и символьные). При этом один файловый объект может содержать в себе ссылку на другой объект, тогда при обращении к первому объекту, осуществляется доступ, в соответствии с находящейся в первом объекте ссылкой, ко второму объекту.

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

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

Выводы.

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

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

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

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

Вопросы формализации требований к полноте (достаточности для условий использования) механизмов защиты информации

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

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

Показатели защищенности от НСД к информации), в части защиты конфиденциальной информации (класс АС 1Г) следующим образом:

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

Сразу, в порядке замечания, отметим, что требования к иным группам АС (2 и в современных условиях теряют свою актуальность. Это обусловлено тем, что в современных системах (например, ОС Windows и Unix) всегда должны быть заведены, по крайней мере, две учетные записи – администратора и пользователя, права доступа к ресурсам для которых принципиально различаются (работа пользователя под учетной записью администратора принципиально недопустима, если мы говорим о защите информации).

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

Частный же случай применения средства защиты определяется условием его использования, что в формализованных требованиях определяется следующим образом Должен осуществляться контроль доступа субъектов к защищаемым ресурсам…

Выводы.

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

В качестве замечания отметим, что организационные меры защиты информации от НСД для АС также формализованы и для класса АС 1Г состоят в следующем:

• должна осуществляться физическая охрана СВТ (устройств и носителей информации), предусматривающая контроль доступа в помещение АС посторонних лиц, наличие надежных препятствий для несанкционированного проникновения в помещение АС и хранилище носителей информации, особенно в нерабочее время;
• должно проводиться периодическое тестирование функций СЗИ НСД при изменении программной среды и персонала АС с помощью тест-программ, имитирующих попытки НСД;

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

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

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

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

• Контроль доступа к файловым объектам на жестком диске;
• Контроль доступа ко всем внешним накопителям и к файловым объектам на отчуждаемых носителях информации (дискета, Flash-устройство, CD-ROM диск и т.д.);
• Контроль доступа к объектам реестра ОС;
• Контроль доступа к устройствам (включая их иерархию – порты, подключаемые к портам устройства, носители), т.е. ко всем объектам, интерпретируемые ОС, как устройства.

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

Вывод.
Средство защиты, не реализующее базовые требования, не является достаточным для защиты конфиденциальной информации, обрабатываемой вычислительным средством.

Замечание.

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

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

• Контроль доступа удаленных пользователей к разделенным на компьютере в сети файловым объектам, накопителям и устройствам;
• Контроль доступа пользователей к удаленным разделенным на компьютерах сети файловым объектам, накопителям и устройствам;
• Контроль доступа к удаленным хостам и сетевым устройствам (имеющим свой IP адрес, например, к сетевым принтерам), соответственно, с удаленных хостов и сетевых устройств.

Вывод.
Средство защиты, не реализующее дополнительные к базовым требования, не является достаточным для защиты конфиденциальной информации, обрабатываемой вычислительным средством в составе сети (в частности, ЛВС).

Общие выводы.

1. Средство защиты информации может быть использовано как самодостаточное средство защиты (без использования, помимо него, дополнительных средств) только при условии выполнения в полном объеме всех требований к корректности реализации и к полноте набора (достаточности для области использования) механизмов защиты.
2. Сформулированные в рассматриваемых нормативных документах требования (в частности, уточняющие требования, сформулированные в работе) позиционируются нами, как обязательные для выполнения разработчиком средств защиты. Данные требования должны учитываться вне зависимости от способа формализации требований к средству защиты (при любом способе формализации требований, эти требования должны присутствовать), т.к. их даже частичное невыполнение несет в себе уязвимость средства защиты информации – формирует канал НСД к информации, как следствие, угрозу преодоления злоумышленником защиты информации.
3. В случае если какой-либо механизм не выполняет требований к корректности реализации, он не должен использоваться и учитываться в составе средства защиты информации, т.к. этот механизм несет в себе уязвимость, как следствие, угрозу быть преодоленным злоумышленником.
4. В случае если набор механизмов средства защиты не выполняет требований к полноте (достаточности для области использования), данное средство защиты не является самодостаточным для заданных условий его использования. При этом возможны два подхода к решению задачи защиты – либо изменять условия использования защищаемого вычислительного средства (если технически это возможно – использование организационных мер для решения этой задачи недопустимо), либо дополнять систему защиты другими средствами, с целью выполнения ими в совокупности формализованных требований к полноте набора механизмов защиты.
5. Базовыми и дополнительными к базовым требованиями к полноте набора механизмов защиты определяется возможность использования средства защиты в возможных альтернативных приложениях защищаемого вычислительного средства (автономный компьютер, компьютер в составе сети). Следовательно, любое из возможных условий использования вычислительного средства подпадает под данную совокупность требований к полноте набора механизмов защиты.

Читайте далее:
Пользователи становятся все более требовательными к вопросам конфиденциальности
Американские учреждения оцениваются уровнем f по безопасности
Ibutton интегрированы в систему защиты информации
Оптимальный вариант транспортной среды
Анализ рынка безопасности ,март 2005 года,
безопасность загородной недвижимости стоит дорого
Защита банка
7. портрет участника рынка безопасности 2007 года
Конкуренция в южнокорейском экспорте
Перспективы азиатского рынка безопасности в 2003 году
11 - 15 февраля 2008 года
18 - 24 февраля 2008 года
17 - 23 марта 2008 года
21 - 27 апреля 2008 года ,рынок безопасности,
28 - 30 апреля 2008 года ,рынок it,