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

Проведенный анализ источников угроз атак.

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

В данном разделе рассматриваем защиту от внедрения и запуска вредоносного или командного файла.

Поскольку данная задача защиты крайне важна, КСЗИ «Панцирь+» решает ее комплексно, реализуя различные методики защиты, которые могут использоваться одновременно, в комплексе. Это обусловливается тем, что каждый из данных подходов нацелен на решение определенного круга задач защиты.

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

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

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

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

Проведенный анализ способов защиты КСЗИ «Панцирь+» и их применения.

Три различные способа решения данной задачи защиты, реализуемые КСЗИ «Панцирь+», состоят в следующем.

1. Обеспечение замкнутости программной среды. Данное решение обеспечивает возможность исполнения файлов с учетом их расположения в системе, с предотвращением возможности их модификации. Пусть на защищаемом компьютере разрешено исполнение файлов только из двух папок – Windows и Program Files, с запретом возможности для них записи в эти папки и модификации их содержимого. Естественно, что это предполагает необходимость инсталляции администратором приложений только в папку Program Files (в противном случае потребуется задать иные права доступа). Разграничительная политика доступа, реализующая это решение, представлена на рис.9.

Рис.9. Разграничения доступа по запуску процессов

На рис.9 приведены разрешающие правила. Так же должно быть создано общее (для этой задачи) запрещающее правило – для субъекта доступа (пользователь и процесс «Любой», см. рис.5, - при создании субъектов доступа используется маска «*») к любому файловому объекту, используется маска «*», должен быть задан режим доступа: +Ч, +З, -И, +П.

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

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

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

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

Проведенная проверка, подтверждающая ограничение данного способа защиты.

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

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

Заданными правилами разрешается запись системе в соответствующие папки, при этом все подобные действия поставлены на контроль.

По результатам работы системы с подобными правилами получены записи в журнале аудита, проиллюстрированные на рис.11.

Рис.11. Результаты испытаний

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

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

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

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

Вывод. Применение механизма обеспечения замкнутости программной среды ограничено его использованием только в отношении не привилегированных учетных записей.

Для преодоления данного ограничения решение этой задачи защиты продублировано на прикладном уровне, что реализуется механизмом «Разрешенные процессы» из состава КСЗИ «Панцирь+», см. рис.12. Здесь запуск процессов контролируется и разграничивается не для отдельных субъектов, а для компьютера в целом.

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

Рис.12. Правила контроля разрешенных процессов

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

Вывод. Замкнутость программной среды должна обеспечиваться одновременно обоими рассмотренными механизмами защиты из состава КСЗИ «Панцирь+» - системного и прикладного уровня.

Отметим, что в составе КСЗИ «Панцирь+», есть еще один механизм контроля процессов, который может использоваться при реализации защиты от целевых атак «Обязательные процессы», интерфейс которого приведен на рис.13.

Рис.13. Интерфейс механизма контроля обязательных процессов

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

С учетом целесообразности совместного использования КСЗИ «Панцирь+» и антивирусного средства защиты, о чем говорили ранее, данная возможность КСЗИ «Панцирь+» может применяться для контроля активности антивируса, с возможностью его автоматического перезапуска с системными правами.

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

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

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

Рис.14. Разграничения доступа по созданию файлов

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

Данный механизм защиты может использоваться и для обеспечения замкнутости программной среды. В этом случае исполнимые файлы должны задаваться следующим образом: %SystemRoot%\*.exe. Так же должно быть создано и общее запрещающее правило – для любого субъекта к любому файловому объекту должен быть задан режим доступа: +Ч, +З, -И, +П.

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

Этот способ защиты уже может использоваться для запрета создания исполнимых и командных файлов системными пользователями.

Проведенная проверка, подтверждающая возможность данного способа защиты.

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

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

В результате работы системы с подобными правилами, в журнале аудита записей не отложилось.

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

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

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

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

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

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

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

Пусть, например, создатеся исполнимый файл под именем stream.exe в альтернативном потоке файла test.txt, расположенном на системном диске C:\. Созданный альтернативный поток будет идентифицироваться в NTFS следующим образом: C:\test.txt:stream.exe. Именно так он будет идентифицироваться и в запросе доступа, который должен анализироваться соответствующим механизмом защиты, решающим задачу обеспечения замкнутости программной среды.

КСЗИ «Панцирь+» анализирует все конструкции запроса, в том числе и при создании нового файла - перехватывает и анализирует все символы, идентифицирующие объект доступа в запросе.

Рассмотрим, как идентифицируются объекты доступа в правилах, реализующих представленные выше разграничительные политики доступа. Для обеспечения замкнутости программной среды объект доступа системный диск запущенной ОС в правилах идентифицируется маской %SystemRoot%\*, где символ «*» означает любые символы, любое их количество, либо отсутствие символов.

Как видим, при запрете доступа к объекту %SystemRoot%\*, объект C:\test.txt:stream.exe не cможет быть создан.

В случае же задание объекта расширением исполнимого файла, например, маской *.exe, рассматриваемый объект C:\test.txt:stream.exe опять же не сможет быть создан, так как он подпадает и под эту маску.

Вывод. КСЗИ «Панцирь+» контролирует создание и разграничивает прав доступа по созданию альтернативных потоков, в которые могут помещаться исполнимые файлы вредоносных программ.

Однако сделанный вывод требует подтверждения. Кроме того, требуется проверить, может ли КСЗИ «Панцирь+» разграничивать права доступа на исполнение программы в альтернативном потоке неисполняемого файла, при условии того, что такой поток был создан.

Проведенная проверка, подтверждающая возможность КСЗИ «Панцирь+» контролировать создание и разграничивать права доступа по созданию альтернативных потоков.

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

Рис.16. Тестовое правило доступа

Альтернативный поток создавался реализацией последовательности команд, представленной на рис.17.

Замечание. Для записи исполнимого файла в альтернативный поток, был использован редактор notepad, т.к. он изначально присутствует в системе, т.е. данный исполнимый файл не требуется создавать, чтобы предотвратило правило запрета соответствующих исполнимых файлов, представленное на рис.16. Обратим внимание на то, что исполнимый файл с именем stream.exe помещен в альтернативный поток текстового файла с расширением txt. Т.е. при обзоре файловой системы мы будем видеть текстовый файл, не подозревая о том, что в его альтернативном потоке расположен исполнимый файл.

Рис.17. Реализованная последовательность команд

В результате видим, см. рис.17, отказ в доступе, который в соответствующем журнале аудита зафиксирован записью, приведенной на рис.18.

Рис.18. Регистрация отказа в доступе

Аналогично была проверена невозможность создания альтернативного потока и при запрете на запись в объект %SystemRoot%\* при реализации замкнутости программной среды.

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

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

Проведенная проверка того, могут ли исполняться альтернативные потоки в файлах, имеющих расширения не исполнимых файлов, в том числе, и при запрете КСЗИ «Панцирь+» доступа к этим неисполнимым файлам на исполнение.

В рамках проведения соответствующей проверки был создан на диске E:\ файл с именем test.txt, в альтернативный поток которого была помещена утилита Debug View. Отметим, что некоторые архиваторы, например, WinRar, позволяют сохранять в архиве файла альтернативные потоки этого файла. При этом при передаче заархивированного таким средством файла на другой компьютер, в архиве будет передаваться и созданный для него альтернативный поток, т.е. при этом будет передаваться зараженный файл.

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

Рис.19. Запуск программы из альтернативного потока

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

Затем было создано правило, запрещающее исполнение программ на диске E:\, где записан файл с соответствующим альтернативным потоком и создана соответствующая ссылка, и повторно проведено испытание. В результате видим, см. рис.20, отказ в доступе, который в соответствующем журнале аудита зафиксирован соответствующими записями, см. рис.21.

Рис.20. Повторное испытание

Рис.21. Регистрация отказов в доступе

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

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

Проведенная проверка того, что КСЗИ «Панцирь+» реализует полноценный контроль и разграничение прав доступа к альтернативным потокам, с возможностью использования масок при задании альтернативных потоков в разграничительной политике доступа.

В рамках проведения соответствующей проверки проведено испытание, для чего создано правило, запрещающее исполнение программы, расположенной в конкретном файле, содержащем ее в качестве альтернативного потока с именем E:\test.txt, в котором объект доступа – альтернативный поток, задан с использованием соответствующей маски, как E:\test.txt:*, см. рис.22.

Рис.22. Созданное тестовое правило доступа

При этих условиях вновь проведено описанное выше испытание. В результате видим, см. рис.23, отказ в доступе, который в соответствующем журнале аудита зафиксирован соответствующими записями, см. рис.24.

Рис.23. Реализованная последовательность команд

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

Проведенное испытание подтверждает, что КСЗИ «Панцирь+» позволяет контролировать и разграничивать права доступа к альтернативным потокам, созданным в отдельных файлах, в том числе и с использованием масок для их задания в разграничительной политике доступа.

Это позволяет реализовывать соответствующие разграничительные политики доступа к альтернативным потокам, как к самостоятельным объектам доступа. В частности, используя маску *:\*:*, можно для соответствующего субъекта доступа вообще запретить созданием альтернативных потоков и/или их исполнение, используя маску %SystemRoot%\*:* запретить создание альтернативных потоков и/или их исполнение для файлов, расположенных на системном диске, можно задать соответствующие разграничения для отдельной папки и т.д.

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

Проведенная проверка возможности запрета всем субъектам доступа создания альтернативного потока9(проверка работы запрещающего правила).

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

Рис.25. Созданное тестовое правило доступа

Вновь было проведено испытание, реализованное соответствующей последовательностью команд, см. рис.17. В результате был отказ в доступе, см. рис.17, который в соответствующем журнале аудита был зафиксирован соответствующей записью, приведенной на рис.18.

Вывод. КСЗИ «Панцирь+» реализует полноценный контроль и разграничение прав доступа к альтернативным потокам, с возможностью использования масок при задании альтернативных потоков в разграничительной политике доступа.

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

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

Важнейшим требованием к СЗИ НСД является возможность регистрации событий отказов в доступе с предоставлением информации о зафиксированных событиях отказов администратору безопасности в реальном времени.

Решение данной важнейшей задачи защиты связано с определенными противоречиями. Для их иллюстрации рассмотрим приложения, написанные с помощью виртуальных машин. Некоторые виртуальные машины предоставляют плагины для браузеров (например, JVM или Adobe Flash Player). Такие плагины делают возможным написание приложений, которые будут исполняться в браузере пользователя. С точки зрения безопасности эти приложения не представлены в системе исполнимыми файлами, но таковыми являются по сути. Они чаще всего представлены обычными файлами, которые читает и запускает виртуальная машина. При этом опять же чаще всего подобные вредоносные сценарии используются в атаках типа drive-by загрузки (загрузки в файловую систему). Данный тип атак позволяет при помощи внедренных вредоносных скриптов загружать без ведома пользователя вредоносные программы.

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

Противоречие состоит в том, что запретив создание подобных файлов, регистрировать соответствующие события отказов в доступе в журнале аудита безопасности не имеет никакого смысла, т.к. он моментально заполнится результатами штатной деятельности браузера. Отличить же вредоносный скрипт средствами КСЗИ «Панцирь+» не представляется возможным, т.к. эта система защиты не анализирует содержимого файлов.

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

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

Проверка возможности КСЗИ «Панцирь+» по избирательной регистрации отказов в доступе субъектов к объектам.

Реализация данной возможности применительно к каждому объекту доступа в КСЗИ «Панцирь+» проиллюстрирована на рис.26.

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

Рис.26. Меню настройки правил регистрации событий безопасности

Вывод. КСЗИ «Панцирь+» обеспечивает избирательную регистрацию отказов в доступе субъектов к объектам, в том числе, для субъектов доступа процесс.

Проверка возможности КСЗИ «Панцирь+» по предоставлению информации о зафиксированных событиях отказов администратору безопасности удаленно в реальном времени.

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

Интерфейс сервера аудита безопасности представлен на рис.27.