This blog article is about application allow listing. We show how the required allow lists can be created easily and automatically. For this purpose, we use a new technology that is based on the “Authorized Owner” principle. In addition, we show further possibilities for the automatic detection of applications to be allowed and how the application allow lists can be updated at any time, e.g. via a secure integration interface.
Why application allow listing?
With the ever-increasing amount of malware and malicious software, organizations are forced to deploy application control solutions. The amount of available software and malware is unmanageable, so it is not sufficiently secure to exclude unwanted software (“deny listing”). Allow listing allows only known software that is deemed safe, providing the only secure approach to application control.
What are the challenges in creating the application allow lists?
Microsoft AppLocker allows you to create rules that control the execution of applications. Only explicitly allowed software can be launched on systems configured by AppLocker, unknown software and malware is blocked by the filter driver.
The default configuration of AppLocker assumes that all applications to be allowed, Windows Installer files, scripts and packaged apps are installed or present in the program and system directories. This is very often not the reality. Companies often use their own directory structures for deploying software. This is exactly what makes it very difficult to define and maintain a suitable application allow lists.
Every intentional change to the target system, e.g. by installing new applications and updates, requires an adjustment of the configuration, which leads to high administrative efforts and costs.
How can deviceTRUST help here?
The application allow listing approach of deviceTRUST complements the well-known configuration options in Microsoft AppLocker with the “Authorized Owner” principle. The creation of rules is not explicitly bound to paths, hashes or publishers, but implemented dynamically using the NTFS property “Owner”. In addition – in contrast to the AppLocker standard – all environment variables can be used. This makes the configuration even more flexible.
All Microsoft operating systems today are installed and operated with the Microsoft NTFS file system. For each file and folder in an NTFS file system, the property “Owner” is maintained. The owner of a file or folder is always the account that applied the file to the system.
If you distribute applications, for example, through a software distribution system, any application that is installed, updated, or copied to the target system through an authorized administrative account is automatically assigned a corresponding owner in the NTFS file system.
In the deviceTRUST Console, a list of authorized owners can be defined for the automatic creation of the application allow lists. The basic configuration already contains standard accounts that are normally used in a Windows operating system for installing software. This list can of course be adapted to individual requirements. Also, certain directories can be excluded from the automatic creation of the application allow lists.
This ensures that only applications, Windows Installers, scripts and packaged apps that have been applied to the system by an “Authorized Owner” are taken into account when the application allow lists is automatically created. All unwanted applications are ignored during creation and thus prevented from running.
For each application type (Applications, Windows Installer, Scripts and Packaged App) it is possible to define separately whether files with Authorized Owners are considered or not when creating the application allow lists.
If allow listing is used by means of “Authorized Owner”, the deviceTRUST Agent creates the required AppLocker rules at system start. The file system is analyzed and the corresponding entries are written to AppLocker. These rules are active immediately.
Authorized users can cause the system to process an updated set of rules at runtime. The deviceTRUST Agent analyzes the adjusted configuration and adds or removes rules to AppLocker based on it.
The update interface can be addressed both manually and automatically, e.g. via software distribution. Internal rights management ensures that only authorized users have access.
Extended environment variables
In a traditional Microsoft AppLocker configuration, only special AppLocker variables – e.g. %OSDRIVE% and %WINDIR% – can be used to configure the application allow lists. AppLocker does not recognize standard environment variables. This makes it much more difficult to create a dynamic set of rules.
deviceTRUST extends the functionality to standard environment variables. All variables known to the system can be used for rule creation in the deviceTRUST Console.
With the Authorized Owner feature and the use of standard environment variables, deviceTRUST enables its customers to easily create and maintain the application allow listsing in an automated manner. The maintenance effort for an application allow listing can be reduced significantly. On the one hand this saves costs and on the other hand it is much less error-prone.
In the next blog article, we will show how to control the allowed applications very easily depending on the context of the access, the device and the user. This includes not only the implementation of such defaults when starting the device or connecting to a remote or DaaS environment, but also how to handle them during the session runtime or when unlocking or reconnecting to the digital workspace.
If you want to learn more, make an appointment with our technical experts!