Эффективная антивирусная защита.

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

Так что же такое "вирус" в общем случае, что же несет в себе угрозу вирусной атаки?

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

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

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

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

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

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

А теперь введем классификацию процессов, или причин, обусловливающих наше недоверие к определенным группам процессов:

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

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

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

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

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

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

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

Макросы, как правило, используются для решения следующих задач:

- Для ускорения часто выполняемых операций редактирования или форматирования;

- Для объединения нескольких команд, например, для вставки таблицы с указанными размерами и границами и определенным числом строк и столбцов;

- Для упрощения доступа к параметрам в диалоговых окнах;

- Для автоматизации обработки сложных последовательных действий в задачах.

Другими словами, пользователь может произвольно расширить возможности используемого программного обеспечения. Проблема же состоит в том, что на возможности расширения функций офисных приложений практически нет никаких ограничений. Ядро автоматизации составляет Visual Basic for Application (VAP). Он включает в себя функции работы с реестром и файловой системой, что позволяет осуществлять деструктивные действия не только по отношению к обрабатываемым данным, но и в отношении системных ресурсов.

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

Защита от сторонних процессов

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

• Вот, что думали об этом год назад: "Современные антивирусные средства неэффективны для противодействия новым троянам, шпионам и другим вредоносным программам (Новость с сайта www.itsec.ru от 24.07.2006). Грэхем Ингрэм, главный управляющий австралийского подразделения Группы оперативного реагирования на чрезвычайные ситуации в компьютерной области (AusCERT) утверждает, что распространённые антивирусные приложения блокируют лишь около 20 процентов недавно появившихся вредоносных программ. При этом популярные антивирусы пропускают до 80 процентов новых троянов, шпионов и других вредоносных программ. Это означает, что в восьми из десяти случаев недавно появившийся вирус может проникнуть на компьютер пользователя".

• А вот, что об этом думают сегодня: "На 12% компьютеров с установленными антивирусами действует вредоносное ПО, а на 35% находится скрытое вредоносное ПО, т.е. оно не активно, когда работает сканер, но может в любой момент активироваться и начать действовать, сообщает Panda Security по итогам сканирования компьютеров с помощью программ NanoScan и TotalScan на сайте Infectedornot.com (Новость с сайта www.securitylab.ru от 29.08.2007)".

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

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

Под полнотой реализации разграничительной политики доступа в данном случае понимается возможность разграничить доступ “на выполнение” для всех компьютерных ресурсов, с которых возможен запуск программы.

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

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

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

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

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

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

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

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

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

Таким образом, в качестве субъекта доступа может рассматриваться либо только пользователь, либо только процесс, либо "пара" – процесс и пользователь.

Нас далее в работе будет интересовать реализация разграничительной политики доступа к ресурсам для субъекта процесс.

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

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

Рис.1. Пример настройки механизма защиты

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

Аналогично может быть задана разграничительная политика доступа к объектам реестра ОС.

В порядке замечания отметим, что упоминание о КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003 в статье приводится отнюдь не для рекламы данного продукта. Важным является то, что в КСЗИ кардинально изменен подход к реализации интерфейса механизма защиты – права доступа назначаются не присвоением атрибутов объектам, а присвоением прав доступа субъектам. Основной же разграничительной политикой доступа к ресурсам является разрешительная политика, задаваемая правами доступа "Ресурсы, разрешенные для…". Проиллюстрируем сказанное. В интерфейсе на рис.1 задано, что субъект (в данном случае, любой – маска "*") может запустить процесс только из двух соответствующих папок на диске F:). Это кардинально упрощает задачу администрирования (если вообще не является единственно приемлемым для практического использования решением), когда речь заходит о реализации разграничительной политики доступа к ресурсам для субъекта "процесс".

Однако вернемся к разграничениям, приведенным на рис.1. Специалист, представляющий себе архитектуру современных ОС семейства Windows, нам возразит – при подобных настройках система работать не будет, мы увидим "синий экран", и он окажется прав. При подобных настройках система работать не сможет, требуются уточняющие настройки. Дело в том, что некоторые системные процессы должны иметь право записи в соответствующие файловые объекты на системном диске. Их не так много (не более десятка). К таким процессам, например, могут быть отнесены: winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe и некоторые другие.

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

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

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

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

Защита от атак со стороны санкционированных процессов

В данном случае раздельно рассмотрим две задачи – защиту системных и информационных ресурсов.

1. Защита системных ресурсов

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

• Модификации критичным приложением системного диска и папок, в которых хранятся исполняемые файлы приложений;
• Запуска критичным приложением несанкционированной программы;
• Модификации критичных объектов реестра ОС, к которым, в первую очередь, следует отнести ветвь: HKEY_LOCAL_MACHINE.

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

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

Проведем исследование возможности и сложности решения данной задачи на примере наиболее часто используемых офисных приложений. Исследования будем проводить в следующих предположениях:

1. Операционная система - Microsoft Windows XP;

2. Рассматриваемые офисные приложения – Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003;

3. Операционная система установлена на диске F;

4. Все приложения инсталлированы в каталог F:\Program files;

5. Обработка информации осуществляется под учетной записью User 1;

6. Для хранения обрабатываемых данных пользователем используется каталог F:\OOD1.

К защищаемым системным ресурсам в данных предположениях, в первую очередь, следует отнести каталоги F:\Windows и F:\Program files и объект реестра HKEY_LOCAL_MACHINE.

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

Таблица 1Единые разграничения к системным ресурсам для процессов офисных приложений

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

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

Итак, антивирусную защиту системных ресурсов со стороны критичных процессов, запуск которых должен разрешаться на защищаемом компьютере, мы решили. Заметим, что задача защиты системных ресурсов при этом решается в общем виде, т.к. становится неважным, известным ли, либо каким-либо новым макро-вирусом осуществляется атака.

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

1. Доверительный контроль доступа к ресурсам.

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

Принципиальным отличием постановки задачи доверительного контроля доступа является то, что мера доверия к процессу определяется доверием к читаемому им объекту (например, к документу, который может исполняться после его прочтения процессом). Можно выделить два случая. Первый (рассматриваемый в данном разделе) случай характеризуется тем, что меру доверия к документу невозможно как-то категорировать. Например, это использование Java-машины при работе с ресурсами сети Интернет – какое здесь может быть доверие к документам, расположенным на сайтах общего доступа? Это получение почтовых сообщений из открытой сети и т.д. Невозможность категорировать документы по степени доверия к ним, требует рассматривать задачу защиты в предположении полного недоверия к документам, как следствие, полного недоверия к процессу, призванному обрабатывать эти документы, т.е. в предположении, что процесс после чтения документа содержит исполняемый объект, который выполняется под именем этого процесса, и в общем случае "от лица процесса" может осуществить любое несанкционированное действие.

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

Рис.2. Схемы доступа к информационным ресурсам критичными процессами

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

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

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

2. Вероятностный контроль доступа к ресурсам (общий случай)

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

Чтобы начать исследование данного вопроса, прежде всего, рассмотрим, в чем состоит особенность обработки категорированной информации.

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

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

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

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

Рассмотрим суть вероятностного контроля доступа к ресурсам.

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

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

При реализации данной схемы вероятность вирусных атак на документы более высокой категории, например, O1 (P1) из-за того, что на том же компьютере обрабатывается информация более низкой категории, имеющие большую вероятность заражения вирусом, например, Ok (Pk). При этом, понимая, что режимы обработки информации различных категорий кардинально различаются, получаем, что при обработке на одном компьютере открытой Оk и конфиденциальной О1 информации, имеем: Pk >> P1, причем в зависимости от реализованных правил и организационных мер по обработке конфиденциальных данных это отношение может составлять сотни, тысячи и более раз, т.е. именно во столько раз можно снизить вероятность вирусной атаки на конфиденциальные данные вирусами, хранящимися в открытых данных, для которых, можем принять Pk = 1.

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

3. Важное замечание

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