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

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

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

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

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

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

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

Выводы.

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

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

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

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

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

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

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

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

·          Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

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

·          Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

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

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

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

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

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

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

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

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

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

В общем случае файловый объект может быть идентифицирован различными способами. Рассмотрим эти способы, на примере 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 и 3) в современных условиях теряют свою актуальность. Это обусловлено тем, что в современных системах (например, ОС Windows и Unix) всегда должны быть заведены, по крайней мере, две учетные записи – администратора и пользователя, права доступа к ресурсам для которых принципиально различаются (работа пользователя под учетной записью администратора принципиально недопустима, если мы говорим о защите информации).

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

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

Выводы.

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

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

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

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

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

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

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

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

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

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

·          Контроль доступа к файловым объектам на жестком диске;

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

·          Контроль доступа к объектам реестра ОС;

·          Контроль доступа к устройствам (включая их иерархию – порты, подключаемые к портам устройства, носители), т.е. ко всем объектам, интерпретируемые ОС, как устройства.

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

Вывод.

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

Замечание.

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

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

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

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

·          Контроль доступа к удаленным хостам и сетевым устройствам (имеющим свой IP адрес, например, к сетевым принтерам), соответственно, с удаленных хостов и сетевых устройств.

Вывод.

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

 

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

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

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

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

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

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

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

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

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

Обозначения, использованные в Табл.1.

“ -  “ - нет требований к данному классу;

“ + “ - есть требования к данному классу.

Таблица 1

Формализованные требования к АС первой группы

 

Подсистемы и требования	Классы
	1Д	1Г	1В	1Б	1А
1. Подсистема управления доступом 1.1. Идентификация, проверка подлинности и контроль доступа субъектов: ·       в систему ·       к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ ·       к программам ·       к томам, каталогам, файлам, записям, полям записей 1.2. Управление потоками информации	+   - - - -	+   + + + -	+   + + + +	+   + + + +	+   + + + +
2. Подсистема регистрации и учета 2.1. Регистрация и учет: ·       входа (выхода) субъектов доступа в (из) систему (узел сети) ·       выдачи печатных (графических) выходных документов ·        запуска (завершения) программ и процессов (заданий, задач) ·       доступа программ субъектов доступа к защищаемым файлам, включая их создание и удаление, передачу по линиям и каналам связи ·       доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, программам, томам, каталогам, файлам, записям, полям записей ·       изменения полномочий субъектов доступа ·       создаваемых защищаемых объектов доступа 2.2. Учет носителей информации 2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей 2.4. Сигнализация попыток нарушения защиты	+   -   -     -     -   - - + -   -	+   +   +     +     +   - - + +   -	+   +   +     +     +   + + + +   +	+   +   +     +     +   + + + +   +	+   +   +     +     +   + + + +   +
3. Криптографическая подсистема 3.1. Шифрование конфиденциальной информации 3.2. Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах 3.3. Использование аттестованных (сертифицированных) криптографических средств	-   -     -	-   -     -	-   -     -	+   -     +	+   +     +
4. Подсистема обеспечения целостности 4.1. Обеспечение целостности программных средств и обрабатываемой информации 4.2. Физическая охрана средств вычислительной техники и носителей информации 4.3. Наличие администратора (службы) защиты информации в АС 4.4. Периодическое тестирование СЗИ НСД 4.5. Наличие средств восстановления СЗИ НСД 4.6. Исп-ние сертифицированных средств защиты	+     +   - + + -	+     +   - + + -	+     +   + + + +	+     +   + + + +	+     +   + + + +

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

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

Таблица 2

Подсистемы и требования к защите информации

в автоматизированной системе

 

Подсистемы и требования	Класс 1Г
Контроль доступа
1. Подсистема контроля доступа в систему: Ø       Загрузка в штатном режиме Ø       Загрузка в безопасном режиме (размешена только администратору) Ø       Доступ при выходе из хранителя  экрана Ø       Доступ при смене пользователя	+ +   + +
2. Подсистемы контроля доступа субъектов к объектам Примечания: 1.       Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа. 2.       Должна быть реализована разрешительная политика доступа к ресурсам: «Все что не разрешено – явно не указано, то запрещено».
2.1. Подсистема контроля доступа к  объектам файловой системы (дискам, папкам, файлам) на жестком диске и на любом внешнем носителе: Ø       К локальным объектам Ø       К разделенным в сети объектам: Ø       К удаленному объекту Ø       От удаленного пользователя	+ + + +
2.2. Подсистема контроля доступа к системным объектам (в частности, запрет модификации системного диска) Ø       Для прикладных пользователей Ø       Для системных пользователей	+ +
2.3. Подсистема контроля идентификации объекта файловой системы Ø       По длинному имени Ø       По короткому имени Ø       По ID	+ + +
2.4. Подсистема контроля идентификации субъекта доступа - контроль заимствования прав пользователями (контроль сервиса олицетворения)	+
2.5. Подсистема обеспечения замкнутости программной среды (контроль доступа к исполнению файлов) Ø       Списком разрешенных к запуску процессов Ø       Списком папок, из которых разрешен запуск процессов	+ +
2.6. Подсистема контроля доступа к объектам реестра ОС (ветви, ключи реестра ОС) Ø       Для прикладных пользователей Ø       Для системных пользователей	+ +
2.7. Подсистема контроля доступа к  устройствам (к любой сущности, принимающей запрос на обслуживание: порты, внешние накопители, принтеры, контроллеры и т.д.): Ø       К локальным устройствам Ø       К разделенным в сети устройствам	+ +
2.8. Подсистема контроля доступа к виртуальным каналам связи сети (к объектам,  имеющим свой адрес в сети): Ø       К удаленным объектам Ø       От удаленных объектов	+ +
2.9. Подсистема контроля доступа к настройкам механизмов защиты (доступ разрешен только администратору, сущность «Владелец» информации должна быть исключена из схемы администрирования как таковая)	+
Регистрация и учет Примечание. Регистрация и учет должны  осуществляться подсистемами контроля доступа:
1. Подсистемой контроля доступа в систему (1) В параметрах регистрации указываются: Ø       дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы; Ø       результат попытки входа: успешная или неуспешная; Ø       идентификатор субъекта, предъявленный при попытке доступа; Ø       пароль, предъявленный субъектом при неуспешной попытке.	+
2. Подсистемами контроля доступа субъектов к  объектам  (2.1 – 2.8) В параметрах регистрации указываются: Ø       дата и время зарегистрированного события – доступ субъекта к объекту; Ø       имя (идентификатор) пользователя, инициировавшего доступ к объекту  (имя и эффективное имя пользователя); Ø       имя (идентификатор) программы (процесса), инициировавшего доступ к объекту; Ø       тип и идентификатор объекта, к которому инициирован доступ субъектом; Ø       тип запрошенного субъектом доступа к объекту (чтение, запись, исполнение и т.д.); Ø       - результат доступа (успешный, неуспешный – несанкционированный).	+
Обеспечение целостности
1. Подсистема обеспечения целостности СЗИ НСД при загрузке системы	+
2. Подсистема периодического контроля целостности программных и информационных компонент СЗИ НСД	+
3. Подсистема периодического контроля работоспособности и восстановления СЗИ НСД	+

 

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

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

            Замечание. Используя требования, представленные в табл.1 (расставив знаки «+», либо «-» в каждой строке таблице), уже можно провести корректное сравнение представленных на рынке альтернативных вариантов СЗИ НСД для защиты конфиденциальной информации, оценить достаточность их применения в АС, в части выполнения формализованных требований к защите конфиденциальной информации. Корректное, а не полное потому, что в Табл.2 сведены лишь формализованные требования (с их уточнениями), в то время, как СЗИ НСД могут обладать и принципиально иными возможностями (расширенными свойствами защиты).

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

Подсистемы и требования к защите информации в АС, реализуемые КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003 приведены в Табл.3.

Обозначения, использованные в Табл.3.

Ø       черный цвет – формализованные требования к АС;

Ø       красный цвет – дополнительные возможности КСЗИ.

  

Таблица 3

Подсистемы и требования к защите информации

в АС, реализуемые КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003

 

Подсистемы и реализуемые требования	«Панцирь-К» для ОС Windows 2000/XP/2003
Контроль доступа
1. Подсистема контроля доступа в систему: Ø       Загрузка в штатном режиме Ø       Загрузка в безопасном режиме (размешена только администратору) Ø       Доступ при выходе из хранителя  экрана Ø       Доступ при смене пользователя Примечание. Реализовано подключение аппаратных средств хранения и ввода пароля: файловых устройств (Flash-устройство, дискета, CD-ROM диск), электронного ключа eToken. Ø       Запрет повторного доступа в систему (сведение задачи к однопользовательской, многозадачной). В общем виде решается задача изоляции программных модулей – в системе всегда может быть зарегистрирован только один пользователь.	+ +   + +           +
2. Подсистемы контроля доступа субъектов к объектам Примечания: 1.       Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа. 2.       Должна быть реализована разрешительная политика доступа к ресурсам: «Все что не разрешено – явно не указано, то запрещено». 3.       Права доступа задаются не для объектов, а назначаются субъектам – ключевое решение в части реализации индуктивной модели безопасности и упрощения администрирования
2. 1. Подсистема контроля доступа к  объектам файловой системы (дискам, папкам, файлам) на жестком диске и на любом внешнем носителе: Ø       К локальным объектам Ø       К разделенным в сети объектам: Ø       К удаленному объекту Ø       От удаленного пользователя	+ + + +
2.2. Подсистема контроля доступа к системным объектам (в частности, запрет модификации системного диска) Ø       Для прикладных пользователей Ø       Для системных пользователей	+ +
2.3. Подсистема контроля идентификации объекта файловой системы Ø       По длинному имени Ø       По короткому имени Ø       По ID	+ + +
2.4. Подсистема контроля идентификации субъекта доступа - контроль заимствования прав пользователями (контроль сервиса олицетворения)	+
2.5. Подсистема обеспечения замкнутости программной среды (контроль доступа к исполнению файлов) Ø       Списком разрешенных к запуску процессов Ø       Списком папок, из которых разрешен запуск процессов	+   +
2.6. Подсистема контроля доступа к объектам реестра ОС (ветви, ключи реестра ОС) Ø       Для прикладных пользователей Ø       Для системных пользователей	+ +
2.7. Подсистема контроля доступа к  устройствам (к любой сущности, принимающей запрос на обслуживание: порты, внешние накопители, принтеры, контроллеры и т.д.): Ø       К локальным устройствам Ø       К разделенным в сети устройствам	+ +
2.8. Подсистема контроля доступа к виртуальным каналам связи сети (к объектам,  имеющим свой адрес в сети): Ø       К удаленным объектам Ø       От удаленных объектов	+ +
2.9. Подсистема контроля доступа к настройкам механизмов защиты (доступ разрешен только администратору, сущность «Владелец» информации должна быть исключена из схемы администрирования как таковая)	+
2.10. Подсистема доверительного контроля доступа к ресурсам. Для подсистем 2.1 – 2.9 права доступа могут назначаться и разграничиваться отдельно для субъекта «пользователь», отдельно для субъекта «процесс»,  комбинированно – «для пользователя, осуществляющего доступ процессом»	+
Регистрация и учет Примечание. Регистрация и учет должны  осуществляться подсистемами контроля доступа:
1. Подсистемой контроля доступа в систему (1) В параметрах регистрации указываются: Ø       дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы; Ø       результат попытки входа: успешная или неуспешная; Ø       идентификатор субъекта, предъявленный при попытке доступа; Ø       пароль, предъявленный субъектом при неуспешной попытке.	+
2. Подсистемами контроля доступа субъектов к  объектам  (2.1 – 2.8) В параметрах регистрации указываются: Ø       дата и время зарегистрированного события – доступ субъекта к объекту; Ø       имя (идентификатор) пользователя, инициировавшего доступ к объекту  (имя и эффективное имя пользователя); Ø       имя (идентификатор) программы (процесса), инициировавшего доступ к объекту; Ø       тип и идентификатор объекта, к которому инициирован доступ субъектом; Ø       тип запрошенного субъектом доступа к объекту (чтение, запись, исполнение и т.д.); Ø       - результат доступа (успешный, неуспешный – несанкционированный).	+
3. Подсистемой контроля доступа к настройкам механизмов защиты (2.9), в части: Ø       изменения полномочий субъектов доступа Ø       создания защищаемых объектов доступа В параметрах регистрации указывается все по п.п.2	+ +
Сигнализация попыток нарушения защиты Ø       Локально Ø       Удаленно (на сервер безопасности)	+ +
Криптографическая защита
1. Подсистема шифрования конфиденциальных данных «на лету»
Ø       Шифрование конфиденциальной информации (объектами могут служить логические диски, папки, файлы) на жестком диске и внешних носителях: ·          Локальные объекты ·          Разделенные в сети (удаленные) объекты (данные по каналу передаются в зашифрованном виде) Ø       Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах (ключевая информация присваивается объекту) Ø       Использование аттестованных (сертифицированных) криптографических средств (подключен криптопровайдер «Signal-COM CSP» Примечание. Реализовано подключение аппаратных средств хранения и ввода ключей шифровани: файловых устройств (Flash-устройство, дискета, CD-ROM диск), электронного ключа eToken.	+ +     +         +
Обеспечение целостности
1. Подсистема обеспечения целостности СЗИ НСД при загрузке системы	+
2. Подсистема периодического контроля целостности программных и информационных компонент СЗИ НСД	+
3. Подсистема контроля целостности  файловых объектов: Ø       Периодический контроль Ø       Асинхронный контроль (по факту выявления несанкционированного события)	+ +
4. Подсистема периодического контроля целостности объектов реестра ОС	+
5. Подсистема контроля целостности программ (исполняемых файлов) перед запуском	+
6. Подсистема контроля санкционированности событий (противодействие ошибкам и закладкам в системном и прикладном ПО)	+
7. Подсистема периодического контроля работоспособности и восстановления СЗИ НСД	+
8. Подсистема контроля активности СЗИ НСД: Ø       Аппаратно (с использованием платы - опционально) Ø       Программно – удаленно с сервера безопасности	+   +
9. Подсистема доверенной загрузки ОС и СЗИ НСД (опционально с использованием платы)	+

 

            Реализация данных дополнительных возможностей позволяет говорить о реализации комплексной системы защиты информации (КСЗИ):

Ø       Эффективная защита информации от несанкционированного доступа (эффективная, т.к. возможности СЗИ НСД принципиально расширены);

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

Ø       Противодействие ошибкам и закладкам в системном и прикладном ПО (механизм контроля санкционированных событий);

Ø       Антивирусное противодействие и противодействие шпионским программам, основанные на использовании механизмов контроля доступа к ресурсам (механизма обеспечение замкнутости программной среды и доверительного контроля доступа к ресурсам – контроля доступа процессов к ресурсам).

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

Более подробную информацию о разработках компании можно получить на сайте: www.npp-itb.spb.ru, либо запросить интересующие сведения по системам защиты и условиям их поставки по электронной почте: info@npp-itb.spb.ru.