This page refers to an older version of the product.View the current version of the online Help.
Product Architecture
In this section:
Architecture Diagram
Software Agent
Application Control is installed and run on endpoints using a lightweight agent. The agent is installed directly onto the local computer. Both agents and configurations are constructed as Windows Installer (MSI) packages and so can be distributed using any third party deployment system that supports the MSI format. The installers are delivered in separate 32-bit and 64-bit Microsoft Installer packages.
For Application Control to function, the agent must be installed on the client endpoint together with an associated configuration. The installation may be performed manually or by means of a deployment system such as the Management Center. Because agents and configurations are installed and stored locally on the endpoint, they continue to operate when the endpoint is disconnected or offline.
The Application Control agent installs a Windows Service (the Application Control Service), a file system filter driver, a kernel driver, a hook and browser extensions. The hook is injected into all processes by the kernel driver and intercepts create process requests, Winsock calls, as well as certain calls related to privilege management. For further details see the Application Hook section.
The file system filter driver intercepts execute, overwrite, and rename requests from all non-system processes. The driver is started and stopped dynamically when the agent is started\stopped. For further details see the File System Filter Driver section.
If a request is intercepted and successfully handled by the hook, then that same request will be ignored by the driver. If the hook is not present (e.g. due to an exclusion) then the driver will intercept the request and it will pass through the rules engine.
Agent Service
The Application Control Agent Service runs as a SYSTEM service on each computer that is controlled using the Application Control component. The agent provides the intelligence for dealing with the requests passed to it from the file system filter driver, the hook, and the browser extensions. Each request is validated against the configuration settings and sent through the rules engine. Along with the details of the application request, the service checks the username, the hostname, and other metadata in order to process the request and ensure user, group, client, and custom rules function as expected.
The configuration is stored in a local configuration file for performance and control reasons. This means that all requests can be turned around in minimum time and perhaps more importantly, without the need for a network link to a central server, which ensures that unconnected machines, such as laptops, remain secured even when not physically connected to the Local Area Network.
Agent Assist
Agent Assist provides support for the agent. Instances of Agent Assist are started on demand by the agent and run using the SYSTEM account. Each Agent Assist is specific to a user session. If Agent Assist is initiated, no more than one instance runs in a session. Once started, Agent Assist typically remains running until the session logs off or the agent is stopped.
DLL Injection Assist
DLL Injection Assist is a 32-bit component that is only installed on 64-bit systems. It is used solely by Agent Assist to install the 32-bit application hook into 32-bit applications running in the same user session.
File System Filter Driver
The filter driver primarily intercepts file opens with execute rights. Executables and DLLs must be opened with execute rights if they are going to be executed hence the driver is guaranteed to intercept those. Other files can be opened with execute rights too, even those that cannot actually be executed, e.g. log files and ini files - that is why sometimes events for non-executable files being denied can be seen. These intercepted requests are sent up to the agent and passed through the rules engine. The result will either be that the request is allowed or denied. If the result is allow ,there is no change, and the request goes down to the file system as before. If the request is deny, the original request is swapped for AMMesage.exe, this is so the calling application does not report an error and the user will see something on the screen to explain what is going on. If the request was for a DLL, it will be prevented from loading and depending on the type of DLL, either the OS, or the application, will display a message to the user.
The filter driver will also detect requests to overwrite and rename files. These requests are also sent up to the agent for rules processing. The request could either result in nothing happening, or the affected file having its owner changed to that of the user. That means the next time the file is run, it will be denied because the owner will typically not be trusted. Finally, the filter driver is responsible for intercepting and potentially blocking access to UNC paths. That is done as part of the Application Network Access Control feature - specifically Host Name control.
All of the above actions will be audited as per the configuration.
Application Hook
This is a DLL that is injected into every user process by the AsModLdr Kernel driver. The Application Hook sends create process and Winsock network requests to the agent for authorization. In the event of a blocked network request, access to the network resource is denied and a configurable message displayed.
If any privilege management is required the Create Process request is sent over to the agent for rules processing. If privilege management is required, the agent will start the relevant process with elevated rights and reparent the application. Control is then returned to the hook in the calling application.
Where Application Network Access Control (ANAC) is concerned, because requests for network traffic is high, the results provided by the agent are cached in the memory of the application. This is essential to avoid a dramatic performance degradation to network traffic.
Browser Add-on
CascadeBHO.dll is an Application Control Browser Helper Object (BHO) loaded by Internet Explorer that is used as part of the URL Redirection and Elevated Web Sites features. If a configuration contains any of these types of rules, the Cascade BHO is enabled, and therefore loaded, by Internet Explorer. If there are no URL Redirection or Elevated Web Sites rules, the BHO is disabled.
The BHO is loaded by only Internet Explorer. A separate extension that provides the same functionality, Ivanti Cascade, is loaded by Google Chrome and new Microsoft Edge (Chromium) browsers.
Check the CascadeBHO.dll Status
-
In Internet Explorer, select Tools >Manage add-ons.
The Manage Add-ons dialog displays.
-
In the Add-on Types panel, ensure Toolbars and Extensions is selected.
You can view the status of the add-ons in the pane on the right.
Configuration
AppSense Application Control configuration files (AAMP files) contain the rule settings for securing your system. The agent checks the configuration rules to determine the action to take when intercepting file execution requests.
Configurations are stored locally in the All Users profile and are protected by NTFS security. In standalone mode, configuration changes are written directly to the file system from the Application Control console. In Enterprise mode, configurations are stored in the Management Center database, and distributed in MSI format using the Management Center console.
Configurations can also be exported and imported to and from MSI file format using the Application Control console. This is useful for creating templates or distributing configurations using third party deployment systems.
After creating or modifying a configuration you must save the configuration (and deploy if necessary) to ensure that they are actioned.