Главная страница - Законодательство в области безопасности

ТРЕБОВАНИЯ К СИСТЕМЕ ЗАЩИТЫ КОНФИДЕНЦИАЛЬНОЙ ИНФОРМАЦИИ



Методологическая основа формализации требований к средствам защиты информацииПрежде, чем приступить к нашему исследованию, определимся с тем, что же является признаком защищенности вычислительной системы, как следствие, что должно быть положено в основу формализации требований к средствам защиты. Для этого определим основные термины, которые часто используются на практике, и будут использованы нами далее в материале: “уязвимость”, “угроза” и “атака”. Под уязвимостью системы защиты нами понимается такое ее свойство (архитектурный, либо иной недостаток), которое может быть использовано злоумышленником для осуществления несанкционированного доступа (НСД) к информации. Другими словами, уязвимость – это «канал» НСД к защищаемой информации. При этом любая уязвимость системы защиты несет в себе угрозу осуществления злоумышленником НСД к информации, посредством реализации атаки (либо атак, которые в общем случае могут принципиально различаться) на уязвимость в системе защиты. Таким образом, именно уязвимость системы защиты – это признак системы, а наличие (отсутствие) уязвимостей является характеристикой защищенности системы. Проиллюстрируем сказанное примером. В ОС 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.

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

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


Итак, в Табл.2 представлен набор требований, включающих, как требования к корректности реализации механизмов защиты, так и требования к их достаточности (полноте), применительно к условиям использования в составе сети (в частности, в ЛВС). Отметим, что в Табл.2 не включено ни одного требования, являющегося дополнительным к формализованным требованиям, изложенным в соответствующих нормативных документах, либо противоречащего им – внесены лишь уточняющие требования, с учетом рассматриваемой области приложений средства защиты (сетевая АС, реализованная на платформе ОС Windows), которые напрямую следуют из требований соответствующих нормативных документов. Внимание. Используя требования, представленные в табл.1 (расставив знаки «+», либо «-» в каждой строке таблице), уже можно провести корректное сравнение представленных на рынке альтернативных вариантов СЗИ НСД для защиты конфиденциальной информации, оценить достаточность их применения в АС, в части выполнения формализованных требований к защите конфиденциальной информации. Корректное, а не полное потому, что в Табл.2 сведены лишь формализованные требования (с их уточнениями), в то время, как СЗИ НСД могут обладать и принципиально иными возможностями (расширенными свойствами защиты). Замечание. Сегодня разработчики средств защиты информации не стремятся по ряду причин предоставить заказчику аналитического материала, иллюстрирующего потенциальные возможности поставляемых ими систем. Большинство известных нам сравнительных оценок ограничивается рассмотрением требований, сформулированных в Табл.1, что, как мы стремились показать в этой работе, без дополнительных исследований и уточнений может существенно искажать объективную оценку эффективности средства защиты. Поэтому данный материал (в частности, требования, сформулированные нами в Табл.2), мы предлагаем рассматривать в качестве методологической основы оценки эффективности средства защиты конфиденциальной информации.В качестве примера оценим эффективность КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003 (разработчик ЗАО «НПП «Информационные технологии в бизнесе»). Данная система защиты не только реализует все требования, сведенные в Табл.2 (в каждой строке Табл.2 можем поставить знак «+», т.е. в полном объеме реализует собственными средствами все требования к защите конфиденциальной информации в автоматизированной системе – требования к АС класса защищенности 1Г), но и характеризуется рядом ключевых дополнительных возможностей.Подсистемы и требования к защите информации в АС, реализуемые КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003 приведены в Табл.3.Обозначения, использованные в Табл.3. черный цвет – формализованные требования к АС; красный цвет – дополнительные возможности КСЗИ.

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


Реализация данных дополнительных возможностей позволяет говорить о реализации комплексной системы защиты информации (КСЗИ): Эффективная защита информации от несанкционированного доступа (эффективная, т.к. возможности СЗИ НСД принципиально расширены), причем в части противодействия, как внешним, так и внутренним IT-угрозам; Криптографическая защита информации - шифрование локальных и разделенных в сети файловых объектов (логических дисков, каталогов, файлов) на жестком диске и внешних носителях, с реализацией ключевой политики (в том числе и сетевой), не позволяющей несанкционированно раскрыть данные даже санкционированному пользователю, при наличии у него ключа шифрования, зашифрованных данных, и средства шифрования; Противодействие ошибкам и закладкам в системном и прикладном ПО (механизм контроля санкционированных событий); Противодействие шпионским программам; Антивирусное противодействие и противодействие шпионским программам, основанные на использовании механизмов контроля доступа к ресурсам (механизма обеспечение замкнутости программной среды и доверительного контроля доступа к ресурсам – контроля доступа процессов к ресурсам).В заключение отметим, что полное сравнение (с учетом дополнительных свойств) возможностей СЗИ НСД целесообразно лишь при условии, что альтернативными средствами в полном объеме выполняются формализованные требования, которые, с учетом соответствующих уточнений, представлены в Табл.2 (дополнительные возможности не должны быть реализованы за счет основных, если они не решают задачи последних) т.к. средство защиты, не выполняющее требования, представленные в Табл.2, на наш взгляд, не является самодостаточным для защиты конфиденциальной информации. В порядке замечания здесь будет уместным остановиться на вопросах разработки политики информационной безопасности и других, сопутствующих при построении системы защиты, документов. Все эти документы в большей, либо в меньшей мере формализуют возможности технических средств защиты информации, которые являются основой реализации системы информационной безопасности. Как следствие, подобные документы могут быть типовыми (совпадать) лишь в части формализации требований к техническим средствам защиты информации, т.е. в общем случае можно говорить лишь о типовой концепции, формирующей общие требования к защите (например, требования к защите вычислительных средств, сведенные в Табл.2). Политика же информационной безопасности объекта информатизации является прямым отражением возможностей конкретного (используемого) технического средства защиты информации, и исследуя ее эффективность, следует переходить к анализу эффективности технического средства защиты информации.Более подробную же информацию о КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003 (разработчик ЗАО «НПП «Информационные технологии в бизнесе») и о других разработках компании можно получить на сайте: www.npp-itb.spb.ru, либо запросить интересующие сведения по системам защиты и условиям их поставки по электронной почте: info@npp-itb.spb.ru.


Д.т.н., проф. А.Ю.Щеглов




Похожие по содержанию материалы раздела: Лесной кодекс двинулся в лес Россиян обязали регистрировать все средства спутниковой связи Российским нефтяным компаниям разрешили приобретать оружие Проект федерального закона «Об участии граждан в обеспечении правопорядка» Календарь отечественных выставок Мелочь, недостойная ГАИ: как водители сами будут оформлять аварии От сторожевой охраны до оператора ПЭВМ - как себя обезопасить Приказ Министерства транспорта Российской Федерации (Минтранс России) от 25 июля 2007 г. N 104 г. Москва "Об утверждении Правил проведения предполетного и послеполетного досмотров" "Перспективы развития частной охранно-детективной деятельности в свете нового законодательного подхода к негосударственной системе безопасности в России" Госдума ратифицировала договор о госгранице с Латвией ОБРАЩЕНИЕ Центрального Комитета Общероссийского профсоюзаработников негосударственных организаций безопасности Негосударственные структуры безопасности: задачи и решения Работа подразделений УВД на Московском метрополитене по предотвращению террактов УЛРР ГУВД г. Москвы: новый документ по ЧОПам и СБ Пожарная безопасность Московской области «Баярд»: программа «женщина-телохранитель» реализована О проекте федерального закона "О внесении изменений в некоторые законодательные акты Российской Федерации в связи с совершенствованием государственного контроля в сфере частной охранной и детективной деятельности" «СПЕЦИАЛЬНЫЕ АНАЛИТИЧЕСКИЕ ТЕХНОЛОГИИ» Указание Заместителя начальника ГУВД г. Москвы генерал-майора милиции В.Ф. Чемисова от 09.07.2001 г. № 92/4-1192 «О порядке организации проведения проверок частных охранно-сыскных структур»

(c) 2008
Видеонаблюдение,
охранная и
пожарная сигнализация