А. Созданные субъекты доступа

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

Рис.60. Созданная разграничительная политика доступа

Таким образом, при реализации данной разграничительной политики доступа, возможность создания/модификации системных объектов и приложений предоставляется только системному администратору и только средствами администрирования, входящими в состав ОС, причем собственно содержимое папки %SystemRoot%\system32 также может модифицироваться только хранящимися в этой папке исполнимыми объектами.

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

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

В рамках проведения соответствующей проверки проведено испытание, для чего, с использованием при заданных правилах доступа, см. рис.60, программы, для этого была создана программа с именем Procmon64.exe, расположенной не в папке %SystemRoot%\System32, запускаемой под учетной запись администратора - с правами привилегированного пользователя, был запрошен доступ к объекту, располагаемому в папке %SystemRoot%\System32 – была сделана попытка модифицировать системный объект. Запрос доступа был отклонен, что было зарегистрировано в соответствующем журнале аудита, см. рис.61.

 

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

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

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

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

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

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

 

 

Рис.62. Меню создания файлового объекта

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

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

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

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

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

Замечание. Возможность усечения прав системного администратора в части отдельных задач администрирования проанализирована на примере создания задачи в ОС.

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

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

При этом рис.63 иллюстрирует создание задачи "calc" из оснастки, рис.64 - из командного интерпретатора cmd. Отметим, что в обоих случаях задача создается для запуска процесса калькулятора с системными правами.

Оснастка «Планировщик заданий» запускается при запуске динамической библиотеки %SystemRoot%\System32\taskschd.dll.

Из командной строки задача создается утилитой %SystemRoot%\System32\schtasks.exe. Для запуска данной утилиты используем командный интерпретатор cmd: %SystemRoot%\System32\cmd.exe.

Как видим, используемые средства администрирования располагаются в папке %SystemRoot%\System32.

Файл созданной задачи хранится в папке %SystemRoot%\System32\Tasks (файл – это "имя задачи"); в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree для этой задачи создается свой раздел ("имя задачи") с ID задачи, см. рис.65; в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks для этой задачи создается свой ("ID задачи") с параметрами задачи, см. рис.66.

 

 

Рис.63. Создание задачи из оснастки

 

 

Рис.64. Создание задачи из командной строки

 

Рис.65. Созданный для задачи calk раздел реестра

 

 

Рис.66. Созданный в реестре для задачи calk раздел "ID задачи"

 

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

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

 

 

 

Рис.67. Создание задачи с использованием оснастки

 

 

Рис.68. Создание задачи из командной строки

 

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

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

Теперь рассмотрим рис.68 (аудит включается уже после запуска командного интерпретатора). Видим, что командным интерпретатором запускается утилита schtasks, которая уже исполняет библиотеку taskschd.dll, после чего работа системы полностью совпадает с первым случаем. Полностью при рассматриваемых вариантах создания задачи совпадают и обращения к разделам реестра.

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

1. В папку %SystemRoot%\System32\Tasks\* должна быть разрешена запись только процессу %SystemRoot%\System32\svchost.exe под учетной записью системного администратора, при этом в правиле для усиления защиты может быть задано соответствующее олицетворение, см. рис.67, рис.68 (такое право доступ процессу svchost может разрешаться только при условии, что он олицетворил себя с правами системного администратора). Для всех иных субъектов доступа (используем маски «*» при создании субъекта) запись в эту папку должна запрещаться

2. В соответствующие разделы реестра Tree и Tasks, см. рис.67, должна быть разрешена запись только процессу %SystemRoot%\System32\svchost.exe под учетной записью системы, всем остальным субъектам - запрещена.

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

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

 

Рис.69.Интерфейс механизма управления доступом к объектам реестра

Отметим, что данное техническое решение подпадает под действие патентов [Щеглов А.Ю., Щеглов К.А. Система контроля доступа к ресурсам компьютерной системы с субъектом доступа "пользователь, процесс" // Патент на изобретение №2534599, правообладатель ООО «НПП «ИТБ», Щеглов А.Ю., Щеглов К.А. Система контроля доступа к ресурсам компьютерной системы с субъектом "исходный пользователь, эффективный пользователь, процесс" // Патент на изобретение №2534488, правообладатель ООО «НПП «ИТБ»].

Проведенная проверка.

В рамках проведения соответствующей проверки проведено испытание, для чего был запрошен доступ к папке %SystemRoot%\System32\Tasks\* проводником. Соответствующий запрос доступа был отклонен, в соответствующем журнале аудита появились записи, проиллюстрированные на рис.70.

 

 

Рис.70. Зарегистрированный отказ в доступе

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

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

Для контроля же администратором безопасности событий создания задач, в реальном времени достаточно поставить на аудит события записи в папку %SystemRoot%\System32\Tasks\*. Заданием соответствующих исключающих правил можно задать условие контроля только в отношении вновь создаваемых задач. При этом администратор безопасности может воспользоваться средствами удаленного управления для оперативного реагирования на зарегистрированное в системе событие.

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

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

 

 

Рис.71. Средства удаленного реагирования в сервере аудита

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

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

 

Рис.72. Интерфейс запуска\завершения процессов

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

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

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

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

Усечение прав системного администратора средствами КСЗИ «Панцирь+» может осуществляться в части:

- запрет решения задачи администрирования;

- ограничение средств администрирования для решения задачи;

- ограничение функций администрирования при решении задачи.

Анализ был проведендля рассматриваемого примера – создание задачи в ОС.

Для запрета системному администратору вообще возможности создания задач в системе, достаточно запретить ему право записи в папку %SystemRoot%\System32\Tasks\*. С точки зрения ограничения средств администрирования, можно запретить ему для решения этой задачи использование командного интерпретатора, запретив процессу %SystemRoot%\System32\cmd.exe исполнение утилиты %SystemRoot%\System32\schtasks.exe.

Отметим, что в общем случае вообще можно запретить администратору использование командного интерпретатора, запретив ему исполнение файла %SystemRoot%\System32\cmd.exe, при этом доступными для него средствами системного администрирования будут только соответствующие оснастки.

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

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

Проведенная проверка запуска процесса созданной задачи.

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

Результаты аудита запуска процесса созданной задачи с правами пользователя приведен на рис.73, с правами системы, на рис.74.

 

 

Рис.73. Аудит запуска процесса задачи с правами пользователя

Рис.74. Аудит запуска процесса задачи с правами системы

Видим, что в обоих случаях процесс созданной задачи запускается одной и той же утилитой %SystemRoot%\System32\taskeng.exe, но в одной случае это осуществляется из под учетной записи пользователя, в другом – системы.

Таким образом, если говорить об ограничении функций системного администратора по созданию задач, то запретом чтения утилитой %SystemRoot%\System32\taskeng.exe папки %SystemRoot%\System32\Tasks\* с системными правами будет вообще запрещаться запуск процессов задач с системными правами, каким бы образом не создавал их системный администратор. Если же при этом требуется разрешить запуск с системными правами уже созданных задач, то в разграничительную политику доступа необходимо ввести соответствующие правила исключений. Например, если требуется разрешить запуск с системными правами процесса существующей задачи с именем «1», таким исключающим правилом будет разрешение исполнения утилитой %SystemRoot%\System32\taskeng.exe с системными правами только файла %SystemRoot%\System32\Tasks\1.

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

 

Для контроля же действий системного администратора по созданию задач следует контролировать то, с какими правами утилита %SystemRoot%\System32\taskeng.exe читает соответствующие задачи из папки %SystemRoot%\System32\Tasks\* и запускает исполнимые файлы. Это позволит, при условии разрешения системному администратору создания задач, получать (при необходимости, в реальном времени) администратору безопасности всю необходимую информацию о том, какая задача была создана для автоматического запуска какой программы и при каких условиях, а так же с какими правами запускается процесс созданной задачи. Заданием соответствующих исключающих правил можно задать условие контроля только в отношении вновь создаваемых задач.

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

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

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

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

HKLM\SOFTWARE\Policies\Microsoft\Windows \Installer\AlwaysInstallElevated

HKCU\SOFTWARE\Policies\Microsoft\Window s\Installer\AlwaysInstallElevated

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

Указание на расположение системной службы и способ ее запуска находятся в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Каждой службе соответствует свой раздел.

Ключ «Start» управляет загрузкой и инициализацией.

Значения Star для системных служб:

2 – AUTO – служба запускается автоматически при загрузке системы.

3 – MANUAL – служба запускается вручную.

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

Аналогичным образом, с использованием того же раздела реестра, осуществляется управление запуском системных драйверов, также располагаемых в папке \WINDOWS\System32.

Значения Star для драйверов:

0 – BOOT – драйвер загружается загрузчиком системы.

1 – SYSTEM – драйвер загружается в процессе инициализации ядра.

4 – DISABLE – драйвер отключен.

3.Внедрение и запуск функции (DLL).

В порядке замечания отметим, что такого понятия как “запуск DLL” нет, поскольку это не исполнимый файл в чистом виде (вроде EXE). В библиотеках DLL содержатся только функции (процедуры), поэтому и вызываться могут только функции. Таким образом, с позиций безопасности здесь уместно говорить о внедрении в процесс вредоносных функций.

При загрузке любого приложения, использующего user32.dll, а таких абсолютное большинство, все DLL, перечисленные в разделе реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, загружаются в адресное пространство этого приложения. В том числе это относится и к системным процессам.

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

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

 

Рис.75. Запрет доступа системному администратору к календарю и к системному времени

С этой целью ему достаточно запретить доступ на исполнение к соответствующей оснастки – динамической библиотеки, располагаемой в папке %SystemRoot%\system32, см. рис.75, при этом оснастка настройки часов и системного времени не откроется. Для запрета же изменения соответствующих важных параметров любым способом, системному администратору требуется запретить доступ к соответствующим разделам реестра, см. рис.75 (отметим, что доступ к разделу реестра HKLM\* непривилегированному пользователю запрещен системой по умолчанию).