MorePC - Главная страница


О сайте

Регистрация

Обратная связь

Реклама на сайте

Публикации на сайте

Карикатуры

  Категории СВТ     Тесты и методики испытаний     Новости СВТ     Проблемы информатизации     Форум     Опросы     Словарь     Поиск  

     Средства защиты информации : Теория  

Предлагаем Вашему вниманию статьи по информационной безопасности.
 

13.04.2007 Компьютерная безопасность в корпоративных приложениях. Начнем с самого начала.

версия для печати

Компьютерная безопасность в корпоративных приложениях. Начнем с самого начала.

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

(ЗАО “НПП “Информационные технологии в бизнесе”)

www.npp-itb.spb.ru

Наконец-таки, мы начинаем приходить к пониманию того, что решение задач ИТ-безопасности в корпоративных приложениях не только целесообразно, но и жизненно необходимо. Осознание же того, что современные универсальные ОС даже гипотетически не могут обеспечить высокого уровня компьютерной безопасности, приводит к повышению спроса на всевозможные средства защиты информации. Рынок же формируют потребители, и он всегда немедленно реагирует на появление спроса. Естественно, что при бурном развитии какого-либо сегмента рынка, на нем появляются как профессиональные решения, так и явные “поделки” (каждый производитель “хочет отхватить свой кусок пирога” даже в том случае, когда не может создать чего-либо стоящего). Бурное развитие рынка характеризуется тем, что и потребитель не всегда достаточно хорошо понимает, а что же ему нужно, и как это должно быть сделано. Это очень наглядно иллюстрируют всевозможные форумы по компьютерной безопасности. Но компьютерная безопасность – это очень своеобразная область знаний, средство защиты не может быть хорошим, либо плохим – оно либо защищает, либо нет. Но как во всем этом разобраться, как за собственные деньги не получить лишь иллюзию защиты? Ведь, рано или поздно, но подобная иллюзия даст о себе знать, и будем “кусать локти”. Наверное, учитывая, что компьютерная безопасность сегодня уже по праву может рассматриваться, как один из элементов национальной безопасности, все эти вопросы должны быть урегулированы на государственном уровне – должны быть соответствующие требования, которые позволят нам выбрать профессиональное средство защиты. Отдадим должное, такие документы существуют. Но вот в чем противоречие: основополагающие нормативные документы, содержащие требования к механизмам защиты системных средств, призванным обеспечивать компьютерную безопасность, практически в неизменном виде действуют в нашей стране уже более десяти лет (созданы еще в прошлом веке). Можно предположить, что при столь бурном развитии ИТ-технологий, которое имеет место в последнее десятилетие, не могли не измениться и требования к механизмам защиты, не могли не потерять своей актуальности и некоторые из существующих требований. Тогда вопрос, а как получить сколько-нибудь актуальную оценку их эффективности, если требования “морально” устарели? Не следует ли сначала определиться с тем, как должны быть построены средства защиты, а уж потом пытаться их сравнивать? При этом отметим, на взгляд автора, недопустимо в принципе вести разговор о решении каких-либо отдельных задач защиты информации, например, противодействие только внутренним, либо только внешним ИТ-угрозам, антивирусное противодействие и т.д. Средство защиты должно решать все эти задачи в комплексе, в противном случае, в нем мало толку – необходимо перекрывать все возможные каналы несанкционированного доступа к информации. Итак, начнем с самого начала и попытаемся в данной работе сформулировать ключевые требования к средствам защиты информации в современных условиях, призванных решать задачи защиты информации в комплексе. Использование данных требований, надеемся, поможет читателю получить более или менее объективную оценку средств защиты информации, представленных сегодня на рынке а, как следствие, и оценку их потребительской стоимости (или целесообразности практического использования).

Состав и назначение требований к механизмам защиты. Общий подход к оцениванию компьютерной безопасности.

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

Эксплуатационная безопасность можно определить только в процессе эксплуатации системного средства. Она определяется статистикой за исследуемый период обнаруженных уязвимостей и исправлений. Именно интенсивность обнаруживаемых уязвимостей характеризует качество разработки, а продолжительность их устранения – качество технической поддержки компании-производителя.

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

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

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

Требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства, сформулированы в действующем сегодня нормативном документе “Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации”, используемом при аттестации объекта информатизации.

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

Естественно, что при подобном подходе к защите АС необходимо наличие сертифицированных средств защиты, т.к. сертификация – это и есть проверка корректности реализации механизмов защиты в системном средстве.

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

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

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

    • Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.

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

На наш взгляд (с позиций требований в достаточности), однозначная трактовка данного требования появляется при следующей его формулировке:

    • “Есть ресурс – к нему должен контролироваться доступ субъектов, не контролируется доступ – не должно быть ресурса”.

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

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

Что очень важно. Если средство защиты не обеспечивает контроль доступа к какому-либо ресурсу – это уязвимость данного средства, т.к. появляется угроза того, что к ресурсу может быть реализован несанкционированный доступ.

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

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

Уточним следующий тезис: “гарантированно исключить его техническими средствами из состава защищаемого объекта” - это очень важно. Речь идет о таком способе исключения ресурса (о каких-либо организационных мерах речь здесь идти просто не может), при котором, он не может быть использован в принципе. Например, если средство защиты не имеет в своем составе механизма контроля доступа к сетевым ресурсам, естественно, что оно не обладает достаточностью для защиты компьютеров в составе сети, однако это отнюдь не означает, что это средство достаточно, применительно к защите автономного компьютера. Это обусловливается тем, что собственно ресурс доступа в сеть в компьютере присутствует – вот и уязвимость! Условием достаточности здесь будет наличие механизма контроля монтирования (подключения) устройств. Этим механизмом от системы должны быть отключены устройства доступа в сеть – не будет ресурса, не будет и уязвимости.

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

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

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

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

Средством защиты должен контролироваться доступ ко всем объектам (ресурсам) в системе, при этом должно выполняться следующее основополагающее правило защиты: “Есть ресурс – к нему должен контролироваться доступ субъектов, не контролируется доступ – не должно быть ресурса”.

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

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

Требованием к набору субъектов доступа является следующее:

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

Видим, что в качестве субъекта доступа в нормативных документах регламентируется рассматривать только сущность “Пользователь” (или, соответственно, “Учетная запись”). А вот здесь настало время начать говорить о современных условиях использования системных средств. Достаточно обратиться к существующей статистике успешных атак на системные средства (например, опубликованной на сайте www.itsec.ru), чтобы сделать вывод о том, что основные уязвимости, позволяющие осуществлять успешные атаки на системные средства, несут в себе процессы (приложения).

Приведем классификацию процессов, в основу которой положим группирование свойств процессов, порождающих угрозу:

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

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

Обратимся к проблеме защиты от вирусных атак. Для этого приведем классификацию угроз вирусных атак:

1. "Вредоносные программы" (трояны и т.п.). Отдельные программы, которые выполняют те или иные деструктивные/несанкционированные действия.

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

3. “Черви”. Разновидность 1,2,4, использующая сетевые возможности для заражения.

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

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

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

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

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

Единые разграничения (заметим, достаточно грубые) к системным ресурсам для приложений Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003, обеспечивающие их корректное функционирование и минимизирующие последствия атаки на системные ресурсы, с использованием уязвимости этих приложений, вне зависимости от типа угрозы (вирусная атака, ошибка программирования и т.д.), представлены в Табл.1.

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

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

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

Таблица 1

Файловые ресурсы

Разрешенные для чтения

Разрешенные для записи и чтения

Разрешенные для выполнения

D:\DOCUMENTS AND SETTINGS\

ALL USERS\

APPLICATION DATA\

MICROSOFT\

OFFICE\

DATA\

OPA11.BAK

 

 

D:\DOCUMENTS AND SETTINGS\ “Имя пользователя”

D:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\MICROSOFT\OFFICE\

DATA\OPA11.DAT

 

D:\WINDOWS

D:\PROGRAM FILES

Ресурсы реестра

Запрещенные для чтения

Разрешенные для записи и чтения

-

HKCU\*

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

Подытожив все сказанное, сформулируем требование к достаточности набора субъектов доступа к объектам (ресурсам).

Субъект доступа к объектам (ресурсам) должен определяться двумя сущностями - “Пользователь” и “Процесс”, а реализация разграничительной политики доступа к ресурсам должна позволять задавать:

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

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

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

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

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


Рис.1

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

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

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

Основу полномочного контроля доступа составляет способ формализации понятий “группа” пользователей и “группа” объектов, на основании вводимой шкалы полномочий. Иерархическая шкала полномочий вводится на основе категорирования данных (открытые, конфиденциальные, строго конфиденциальные и т.д.) и прав допуска к данным пользователей (по аналогии с понятием “формы допуска”).

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

Если принять, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), то матрица доступа D, описывающая полномочную модель контроля доступа, примет следующий вид:

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

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

Если считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), а Pi – это вероятность того, что документ i-й категории “заражен” макро-вирусом, причем: P1 < P2 <…<< Pk = 1, то матрица доступа F, описывающая вероятностную модель контроля доступа (контроль доступа на основе вероятности “заражения” документов различных категорий конфиденциальности), примет следующий вид:

Вот и противоречие! Напомним, что защита информации от НСД – это совокупность мер, направленных на предотвращение хищения и несанкционированной модификации информации. Это задачи, которые в совокупности должны решаться механизмами контроля доступа к ресурсам.

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

Что мы видим - матрицы доступа D и F полностью исключают друг друга.

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

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

Подытожив все сказанное, сформулируем требование к достаточности набора режимов обработки категорированных данных.

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

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

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

Требования к корректности реализации механизмов защиты.

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

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

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

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

Первое базовое требование – реализация индуктивности модели безопасности.

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

    • КСЗ (комплекс средств защиты) должен контролировать доступ наименованных субъектов (пользователей и процессов) к наименованным объектам (ресурсам).

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

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

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

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

но и требованием:

      • Из схемы контроля доступа к ресурсам должна быть исключена сущность “Владение” объектом как таковая.

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

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

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

      • Должна быть реализована разрешительная разграничительная политика доступа к ресурсам, состоящая в том, что право доступа устанавливать субъектам, а не присваивается в качестве атрибутов объектам (данное решение на практике используется для включения в схему контроля доступа сущности “Владения”), с указанием соответствующих объектов и типов доступа, которые разрешаются субъекту.

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

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

      • Контроль доступа должен быть применим к каждому объекту (ресурсу) и каждому субъекту (пользователю и процессу), включая системные субъекты и объекты.

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

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

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

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

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

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

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

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

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

Однако если реализуется контроль доступа к сервисам олицетворения, то зачем сформулирована вторая часть требования “…КСЗ должен препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась”. Да дело в том, что на практике далеко не всегда возможно корректно определить субъект доступа. Это ярко иллюстрируется примером реализации контроля доступа к некоторым устройствам, обращение к которым осуществляется драйвером, поэтому средством защиты невозможно корректно идентифицировать субъект доступа (в запросе доступа будет фигурировать имя пользователя “System” и имя процесса “System”). Проведите собственный эксперимент. Возьмите какое-либо средство контроля доступа пользователей к устройствам. Задайте разграничительную политику доступа к устройству, взаимодействие с которым осуществляется через драйвер. Одной учетной записи разрешите доступ к этому устройству, другой нет. Затем зайдите в систему под одной учетной записью, после чего запустите приложение с правами другого пользователя (по правой кнопки мыши). И обратитесь этим приложением к данному устройству. Заметим, имя пользователя средством защиты при обращении к устройству в этом случае корректно не определить. Как отработает заданная вами разграничительная политика доступа к ресурсам? Проверьте.

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

С учетом всего сказанного уточним рассматриваемое очень важное требование к корректности реализации разграничительной политики доступа к ресурсам:

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

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

С учетом сказанного можем сформулировать дополнительное требование к корректности реализации разграничительной политики доступа к ресурсам:

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

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

Третье базовое требование – корректность идентификации объекта доступа. При всей своей очевидности и необходимости выполнения данного требования при реализации разграничительной политики доступа к ресурсам, здесь также имеются свои “подводные камни”. Очевидно, что в общем случае требование к корректности идентификации объекта доступа может быть соответствующим образом сформулировано по аналогии с соответствующим требованием, к корректности идентификации субъекта доступа, рассмотренным выше:

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

Здесь также можно констатировать две причины возможной некорректности идентификации, но уже объекта доступа. Первая причина состоит в существовании различных способов идентификации некоторых объектов (ресурсов). Например, в NTFS к файловым объектам, задаваемым длинными именами, можно обращаться по короткому имени (например, к каталогу “\Program files\” можно обратиться по короткому имени “\Progra~1\”), файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode, файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

С учетом сказанного можем сформулировать дополнительное требование к корректности реализации разграничительной политики доступа к ресурсам:

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

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

Здесь также, по аналогии с требованиями, сформулированными ранее, можем сформулировать дополнительное требование к корректности реализации разграничительной политики доступа к ресурсам:

      • КСЗ должен предотвращать появление в системе объектов, которые не могут быть корректно идентифицированы при запросе к ним доступа.

Итак, в заключение подытожим все сказанное в работе.

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

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

Заключение.

Как видим, сформулированных нами базовых требований к средству защиты конфиденциальной информации в современных условиях не так уж и много, но ответьте на вопрос, каким из известных вам системным средством, либо средством добавочной защиты (СЗИ от НСД), эти требования реализуются в полном объеме? А ведь мы говорим об уязвимости системных средств и средств защиты информации! Каков же уровень их функциональной безопасности, а, как следствие, какова их потребительская стоимость, которая для средства защиты определяется тем, насколько эффективно оно реализует защиту информации, или насколько оно неуязвимо! Какие реальные задачи защиты информации могут решаться подобными средствами, каков обеспечиваемый мим уровень функциональной безопасности?! А ведь на практике необходимы комплексные средства защиты информации, а их-то где взять?

Статью "13.04.2007 Компьютерная безопасность в корпоративных приложениях. Начнем с самого начала." Вы можете обсудить на форуме.




вверх
  Copyright by MorePC - обзоры, характеристики, рейтинги мониторов, принтеров, ноутбуков, сканеров и др. info@morepc.ru  
разработка, поддержка сайта -Global Arts