а. Тестовое правило запрета чтения

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

Рис.117. Испытание корректности запрета чтения

 

 

Испытание корректности запрета записи. Было создано тестовое правило запрета записи файла, см. рис.118.а. После этого по ссылке link.txt «блокнотом» был прочитан файл E:\test.txt, изменено его содержимое и совершена попытка записи файла по ссылке link.txt, в доступе было отказано, см. рис.118.б, что было зарегистрировано в соответствующем журнале аудита, см. рис.118.в.

 

А. Тестовое правило запрета записи

Б. Сообщение об отказе в доступе

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

Рис.118. Испытание корректности запрета записи

 

Испытание корректности запрета исполнения. Было создано тестовое правило запрета исполнения файла E:\notepad.exe, см. рис.119.а. После этого командой, проиллюстрированной на рис.119.б, была совершена попытка исполнения файла ссылки link.exe, в доступе было отказано, см. рис.119.б, что было зарегистрировано в соответствующем журнале аудита, см. рис.119.в.

 

А. Тестовое правило запрета исполнения

Б. Выполненная команда

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

Рис.119. Испытание корректности запрета записи

 

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

После этого были повторены все приведенные выше испытания при создании символьной ссылки уже на каталог E:\test, в который были помещены файлы test.txt и notepad.exe. Соответствующая символьная ссылка была создана последовательностью команд, проиллюстрированной на рис.120.

 

 

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

Были созданы следующие правила запрета доступа, см. рис.121.

 

 

 

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

 

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

 

 

 

 

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

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

 

 

Рис.123. Зафиксированные отказы в доступе

 

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

 

 

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

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

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

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

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

Проведено следующее испытание. Сначала проводником под учетной записью admin были созданы соответствующие тестовые файлы. Затем под другой учетной записью – Татьяна были созданы ссылки на эти файлы, причем иным процессом – cmd.exe, для чего была выполнена последовательность команд, представленная на рис.125.

 

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

Разметка созданных различными пользователями и различными процессами файлов и ссылок на них приведена на рис.126.

 

Рис.126. Разметка файлов и ссылок на эти файлы

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

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

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

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

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

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

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

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

Сначала в отношении контроля доступа к статичным файловым объектам.

Созданным правилом, приведенным на рис.127, был полностью запрещен доступ к исполнимому файлу с именем E:\Far.exe.

 

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

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

 

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

В соответствующем журнале аудита при этом созданы записи об отказе в доступе, не позволившем создать жесткую ссылку на файл E:\Far.exe, см. рис.129.

 

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

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

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

 

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

Были повторены действия по созданию жесткой ссылки, представленные на рис.128, в доступе было отказано. В соответствующем журнале аудита при этом создалась запись об отказе в доступе, не позволившем создать жесткую ссылку на файл E:\Far.exe, см. рис.131.

 

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

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

Проведено испытание. Созданное для испытания правило доступа представлено на рис.132.

 

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

Были повторены действия по созданию жесткой ссылки, представленные на рис.128, в доступе было отказано. В соответствующем журнале аудита при этом создалась запись об отказе в доступе, не позволившем создать жесткую ссылку на файл E:\Far.exe, см. рис.133.

 

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

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

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

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

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

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

Проведено следующее испытание. Сначала проводником под учетной записью admin были созданы соответствующие тестовые файлы. Затем под другой учетной записью – Татьяна были созданы жесткие ссылки на эти файлы, причем иным процессом – cmd.exe, для чего была выполнена последовательность команд, представленная на рис.134.

 

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

Разметка созданных различными пользователями и различными процессами файлов и ссылок на них приведена на рис.135.

 

Рис.136. Разметка файлов и ссылок на эти файлы

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

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

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

 

Заключительные положения

Проведенное исследование показало следующее:

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

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

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

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

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

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

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

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

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