Вы находитесь в разделе Типовых решений систем безопасности
Вопросы комплексирования механизмом защиты конфиденциальной информации в единую техническую системуНа сегодняшний день набор механизмов защиты, который должен быть включен в комплекс средств защиты конфиденциальной информации, и требования к этим механизмам сформулированы в соответствующих нормативных документах. Однако, несмотря на то, что в этих документах речь идет о комплексе средств защиты информации, в них не сформулированы цели комплексирования разнородных механизмов защиты в единую техническую систему, как следствие, ими регламентируется лишь некий набор требований к решению разнородных задач защиты информации. Насколько эффективен такой подход при решении задачи комплексирования механизмов защиты в единую техническую систему, так ли действительно функционально независимы механизмы защиты информации? Если же это не так, то в чем заключается задача комплексирования механизмов защиты в единую систему, и что следует понимать под комплексной системой защиты информации? Попытаемся в данной работе ответить на сформулированные вопросы и дать опредение комплексной системы защиты конфиденциальной информации. На сегодняшний день требования к корректности реализации механизмов системы защиты информации определены нормативным документом: Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации (в части защиты конфиденциальной информации - требованиями к 5 классу СВТ); требования к достаточности (полноте) механизмов в системе защиты определены нормативным документом: Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации (в части защиты конфиденциальной информации - требованиями к классу АС 1Г). Требования к АС первой группы (включающие требования к техническим средствам защиты информации) представлены в Табл.1. Обозначения, использованные в Табл.1. - - нет требований к данному классу; + - есть требования к данному классу. Таблица 1 Формализованные (определенные в нормативных документах) требования к АС первой группы
Таким образом, обращаясь к Табл.1, мы видим требования к набору (не к комплексу) самостоятельных механизмов защиты, каждым из которых должна решаться своя функциональная задача защиты информации. Но так ли это на самом деле, так ли действительно функционально независимы представленные механизмы защиты информации, в чем состоит задача их комплексирования в единую техническую систему? Для ответа на эти вопросы рассмотрим лишь один механизм защиты, по нашему мнению ключевой, который всегда должен присутствовать и быть активен на защищаемом вычислительном средстве – механизм обеспечения замкнутости программной среды. Под обеспечением замкнутости программной среды в общем случае понимается локализация на защищаемом компьютере возможности запуска программ пользователями механизмом управления доступом к ресурсам (контролем доступа на исполнение файлов). При корректной реализации на компьютере данного механизма защиты, принципиально исключается возможность запуска трояна, червя, вируса; кардинально снижается вероятность успешной атаки, направленной на несанкционированный доступ к информационным ресурсам (большинство подобных известных атак требовало запуска злоумышленником собственного программного кода) и т.д. Требованиями к корректности реализации механизма обеспечения замкнутости программной среды является следующее: механизм реализован корректно только при условии, если им выполняются требования к полноте и к корректности разграничений к исполняемыми файлами. С учетом сказанного, делаем вывод, что механизм обеспечения замкнутости программной среды и механизм управления доступом к исполняемому файлу (к запуску программ) в общем случае два различных механизма защиты (причем один реализуется по средством другого). При этом под полнотой разграничений понимаем возможность разграничить доступ “на исполнение” для всех компьютерных ресурсов, с которых возможен запуск программы, а под корректностью разграничений понимаем обеспечение отсутствия какой-либо возможности модифицировать разрешенные к запуску исполняемые файлы, а также возможность запутить под их именем другие (несанкционированные) программы. Замечание. Практическое использование данного механизма защиты связано с определенными трудностями. Так, ряд известных нам добавочных СЗИ НСД решают эту задачу, по средством задания списка разрешенных к запуску исполняемых файлов – процессов (при этом выполняется ряд мероприятий по обеспечению корректности решения задачи – исполняемые файлы в разграничениях задаются их полнопутевыми именами, причем они должны располагаться только на жестком диске, и к разрешенным на запуск исполняемым файлам запрещается доступ на запись), с последующим заданием соответствующих разграничений для исполняемых файлов. Кто хоть раз пробовал настроить подобный механизм, представляет насколько это сложно, причем, как в части создания, так и в части модификации списка (списков, если они различны для различных пользователей) разрешенных к запуску процессов. Во-первых, подобных файлов в системе (а это ведь не только файлы приложений, но и системные исполняемые файлы) может быть достаточно много, во-вторых, один процесс, может запускать другой, и для корректной работы приложения необходимо разрешить на запуск все его процессы, установив соответствующие разграничения на исполняемые файлы. Не случайно разработчики известных нам добавочных средств защиты пытаются, хоть как-то, упростить настройку данного механизма – вводят малую автоматизацию с использованием средств аудита, прилагают отдельные инструкции по настройке данного механизма. Как следствие, велика вероятность ошибок в администрировании механизма, причем критичных ошибок, в том числе, связанных с корректностью функционирования, как приложений, так и собственно системы. Подход же к решению задачи, связанный с заданием контрольных сумм разрешенных к запуску исполняемых файлов, предполагающий осуществление контроля исполняемых файлов перед их запуском, нами не рассматривается (механизм контроля целостности, сильно влияющий на загрузку вычислительного ресурса, принято использовать в случае, когда невозможно корректно решить задачу средствами контроля доступа). Прелагаемый нами подход к реализации механизма обеспечения замкнутости программной среды состоит в следующем. Замкнутость программной среды предлагается определять не списком разрешенных к запуску процессов, а каталогом (каталогами), из которых пользователям разрешается запуск исполняемых файлов. Проиллюстрируем сказанное на примере. Пусть все разрешенные к запуску процессы располагаются (устанавливаются) только в каталогах C:\Program Files и С:\Windows (на системном диске C:\), это целесообразно, так как следует контролировать запуск и системных процессов. Реализуя разрешительную разграничительную политику доступа к ресурсам (Все, что не разрешено (явно не указано), то запрещено) – это основное условие корректности реализации механизма, разрешим пользователям на исполнение только каталоги C:\Program Files и С:\Windows, причем не разрешим пользователям доступ к этим каталогам “на запись” (чем запретим создание и модификацию расположенных в этих каталогах файловых объектов). Рассмотрим, к чему это приведет. Пользователь сможет запустить программу только из заданных каталогов, причем только с жесткого диска, и не сможет модифицировать исполняемые файлы разрешенных к запуску процессов, причем, как прикладных, так и системных. Теперь вернемся к проблеме сложности администрирования. При подобной реализации механизма, в части его администрирования, сохраняются все исходные (выполняемые до установки средства добавочной защиты) действия администратора – он штатными средствами должен инсталлировать программы в заданные каталоги, в частности C:\Program Files и С:\Windows, и штатными же средствами удалять программы. Рассмотренные же выше разграничения задаются лишь несколькими записями при настройке механизма защиты. Теперь вернемся к исследуемому нами вопросу. Важнейшим условием корректности реализации механизма обеспечения замкнутости программной среды является следующее – в системе не должно существовать какой-либо возможности несанкционированной модификации каталогов с разрешенными к запуску исполняемыми файлами. Следовательно, данные каталоги должны быть закрыты “на запись” (должна предотвращаться любая возможность их модификации) любым пользователем, в том числе, и привилегированными пользователями, в частности, пользователем System. Из этого следует, что всем пользователям, включая привилегированных, следует запрещать доступ на запись к системному диску. Невыполнение данного требования делает механизм обеспечения замкнутости программной среды уязвимым – атака на уязвимость приложения, запускаемого с системными правами, направленная на расширение привилегий (например, по средством переполнения буфера приложения), позволяющая получить злоумышленнику привилегии пользователя System, позволит ему бесконтрольно модифицировать системную область диска, в результате чего им может быть внесен туда произвольный программный код и далее запущен в обход механизма обеспечения замкнутости программной среды. Таким образом, в части обеспечения корректности реализации механизма обеспечения замкнутости программной среды, можем сформулировать следующее требование – механизмом контроля доступа к ресурсам должна предотвращаться возможность модификации системного диска всеми пользователями, включая системных, в частности, System. Очевидно, что, если разработчиком в средстве добавочной защиты декларируется реализация механизма обеспечения замкнутости программной среды и при этом не выполняется данное уточняющее требование, можно считать, что механизм реализован некорректно (или, попросту отсутствует в средстве добавочной защиты, т.к. обладает серьезной уязвимостью). Замечание. Вообще говоря, потребитель, заинтересованный в эффективной защите своей информации, должен обладать необходимой квалификацией, чтобы отличить средства защиты от средств, предоставляющих ему иллюзию защиты. В частности, иногда к достоинствам средства защиты разработчики пытаются отнести якобы простоту его администрирования, что уже, наверное, должно насторожить специалиста, представляющего себе проблемы защиты информации. Итак, возвращаясь к нашему исследованию, видим, что два рассматриваемых механизма (контроль доступа к объектам файловой системы и замкнутость программной среды) функционально зависимые механизмы защиты – без корректной реализации одного не может быть обеспечена корректная реализация другого. Продолжим. Теперь рассмотрим случай, когда различным пользователям следует разрешить запуск различных программ, пусть из различных каталогов. Здесь вопрос корректности реализации механизма обеспечения замкнутости программной среды напрямую связан с вопросами корректности идентификации пользователя (т.к. разграничения устанавливаются для пользователей). Казалось бы, что для этого существует механизм идентификации и аутентификации пользователя при входе в систему. Однако, это не совсем так. Система предоставляет разработчикам приложений сервисы олицетворения. Сервис олицетворения (impersonation) предоставляет возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, его запустившего, т.е. действовать от лица другого пользователя. Как следствие, здесь возникают вопросы корректности идентификации пользователя при доступе к ресурсам (не выполнение этого требования позволит злоумышленнику обойти заданные в системе правила резграничений на запуск исполняемых файлов). В данном случае аутентификация пользователя не производится, поэтому средством защиты должен быть реализован контроль (основанный на разграничении прав) корректности олицетворения. Заметим, что атаки на сервисы олицетворения в последнее время занимают весьма заметное место в общей статистике успешных атак на защищаемые ресурсы. Таким образом, в части обеспечения корректности реализации механизма обеспечения замкнутости программной среды, можем сформулировать следующее требование – системой защиты должен осуществляться контроль корректности олицетворения при доступе пользователей к ресурсам, суть которого состоит в разграничении прав и контроле заимствования потоком маркера безопасности другого пользователя. Очевидно, что, если разработчиком в средстве добавочной защиты декларируется реализация механизма обеспечения замкнутости программной среды и при этом не выполняется данное уточняющее требование, можно считать, что для приложений, требующих различных разграничений для пользователей по запуску ими исполняемых файлов, механизм реализован некорректно (или, попросту отсутствует в средстве добавочной защиты, т.к. обладает серьезной уязвимостью). Данное исследование можно было бы продолжить далее, однако, наверное, например, поговорив об активности и корректности функционирования системы защиты в целом, однако, наверное, уже всего сказанного выше вполне достаточно, чтобы сделать следующие важные выводы:
С учетом сказанного дадим определение комплексной системе защиты информации. Под комплексной системой защиты информации следует понимать необходимый и достаточный для решения требуемой совокупности задач защиты набор взаимосвязанных механизмов, каждым из которых реализуются требования к корректности и достаточности, в части решения требуемой совокупности задач защиты информации. В результате исследования вопросов комплексирования механизмов защиты в единую техническую систему, на основании формализованных требований, представленных в Табл.1, нами сформулированы требования к комплексной защите конфиденциальной информации, приведенные в Табл.2 (заметим, что эти требования не противоречать формализованным требованиям, представленным ранее, они их уточняют и дополняют). Особое внимание при разработке данных требований уделено защите компьютерной информации от санкционированного пользователя – пользователя, в задачи которого входит обработка информации на защищаемом вычислительном средстве – данную задачу невозможно решить без использования средств криптографической защиты информации, к которым здесь также формулируются особые требования). Читайте далее:  Rustock.c - не миф, а реальность! Восполнимая потеря.... электронных данных Программно-аппаратный комплекс netswift igate 14 - 20 января 2008 года Анализ российского рынка систем охранного телевидения Анализ рынка безопасности ,июнь 2005 года, 3. самые успешные компании 2007 года ,часть 1, Ах ты, камбала - не вобла... Ежегодный анализ тайваньского рынка безопасности. Комментарий к security 50 04 - 10 февраля 2008 года Созидающая волоконная оптика 08 - 09 марта 2008 года 14 - 20 апреля 2008 года ,рынок it, 28 - 30 апреля 2008 года ,рынок безопасности,
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
