4. Условия реализации требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Видим, что в качестве субъекта доступа в нормативных документах регламентируется рассматривать только сущность «Пользователь» (или, соответственно, «Учетная запись»). А вот здесь настало время начать говорить о современных условиях использования системных средств.

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

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

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

• Критичные процессы. К ним могут быть отнесены две группы процессов: к процессам первой группы относятся те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, это сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой, атаки на процессы второй группы наиболее вероятны;

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

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

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

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

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

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

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

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

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

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