CORE FORCE Architecture

This article surveys the architecture of the CORE FORCE client sofware, describing how it implements a comprehensive endpoint security solution for Windows 2000 and Windows XP systems.

Introduction

CORE FORCE implements a security framework that enable users to define security profiles for programs that run in the computer independently. Each application can be given access to specific parts of the file system and registry, so that it can only read or modify those objects needed for the application to work correctly. Inbound and outbound network traffic can also be restricted for every program.

CORE FORCE is built on a modular architecture, with individual components that enforce permissions on a computer's resources (see Figure 1). These components intercept requests by programs running in the computer and apply the permissions configured by the user. There are currently three modules that implement the security protection framework of CORE FORCE, and they are used to restrict network connections, and protect the file system and the registry. These modules are kernel-mode drivers to prevent the security framework from being bypassed and to minimize the performance footprint of the enhanced security.

Figure 1. Diagram of CORE FORCE client modules.

The modules that do security enforcement check permissions against an in-memory database of permissions known as Dispatcher. The Dispatcher stores all network, file system and registry permissions for the programs configured in CORE FORCE, and provides an API for the other modules to query its database.

There are two additional modules that run in user-mode and complement the functionality provided by the kernel-mode drivers in CORE FORCE, known as Policy Developer and Force Repository. The Policy Developer provides the user interface for the user to configure security profiles for the programs that run in the computer, and it also handles user authorization requests from the security enforcement modules. Force Repository is the module that handles the persistence of the security database, and performs validation on the database whenever it's loaded.

Firewall

The Firewall module of CORE FORCE is responsible of filtering inbound and outbound network traffic based on a set of rules on a per application basis, so the module associates a program's process with an independent set of firewall rules, which are loaded when the program is launched using the security profile configured for the program.

The firewall is a Windows port of OpenBSD’s Packet Filter (PF), which has been trimmed and tailored to make it suitable for desktop systems and to minimize complexity. There are two kernel-mode drivers that implement CORE FORCE's firewall, the core functionality of the firewall is performed by a miniport driver (croxy.sys) that uses the standard NDIS (Network Driver Interface Specification) API to wrap all communications between the network card drivers and the Operating System application layer. This driver intercepts all outgoing and incoming network packets, and because it's placed at the bottom of the networking stack, it additionally protects attacks to the Operating System's stack itself.

The other driver (tdifilter.sys) is a TDI (Transport Dispatch Interface) filter driver which works at a higher level, on the transport layer Windows provides to implement networking protocols. This driver complements the functionality of the NDIS driver by keeping track of a map network connections for each process, and it also allows CORE FORCE to perform synchronous queries for user authoriation of network connections.

File System and Registry Protection

These two modules provide similar functionality to each kind of objects (file system objects and registry objects), allowing CORE FORCE to enforce permissions when access is required to list, read, write, delete or execute one of these objects. The security modules are implemented in two kernel-mode drivers (alpha2.sys and alpha2r.sys for file system and registry protection, respectively), which mediate the communication between the operating system and file system drivers. Due to their location inside the operating system, they can trap calls that access any file system or registry object, and even calls made by other kernel components.

Dispatcher

The Dispatcher is the module that keeps track of all permissions required by programs running in the computer, and it answers queries from security enforcement modules to allow or deny actions intercepted by these modules. The Dispatcher acts as a broker for the security enforcement modules, as they don't interact with user-mode modules directly. For example, if the File System Protection module finds that user authorization is required to execute a program, it sends the request to the Dispatcher, which will communicate with the user interface, and wait for an answer from the user.

The Dispatcher minimizes memory footprint by mantaining a list of only those permissions to be applied at any given moment (this means that, for example, only permissions for a program's current security level are stored in the Dispatcher's database). Permissions in the Dispatcher are also translated before they are stored in the database to map predefined folders or aliases referenced in the permissions to their actual values, which improves the performance when evaluating queries from the security enforcement modules (for example, permissions based on the User's Profile predefined folder are expanded to refer to, usually, C:\Documents and Settings\<username>).

This module works in kernel-mode (the driver is dispant.sys) to prevent the permissions from being tampered by other programs and for performance reasons. Because the Dispatcher is being queried all the time by security enforcement modules that also run in kernel-mode, storing the permissions in a module at the same level minimizes the cost of switching between user and kernel mode.

Force Repository

The Force Repository module is responsible for persisting CORE FORCE's configuration which includes firewall rules, file system and registry permissions for all of the security profiles that have been configured, and default system permissions and shared policies as well. Force Repository loads the security database when the computer is started, uploading the permissions to the Dispatcher so that it can evaluate queries from security enforcement modules. Changes to the configuration made by the user in the configuration interface (Policy Developer) are received by Force Repository, which keeps both the database and the Dispatcher up to date. The import and export of security profiles (CFX files), required to interact with the Community web site, is also handled by this module.

The Force Repository is a system service (LocalCPA.exe) that starts at boot time, and it provides a COM interface for the Policy Developer to load and update the security configuration. The database and the security profiles exported by the module are XML documents, which are structured so that they map the configuration interface of CORE FORCE to enable human inspection of these files. Additionally, these documents are validated with a robust hybrid method that combines both XML-Schema and Schematron, to prevent malformed or corrupted data on the main repository file or any security profile to be imported to the database.

Modules interaction - Request for user authorization to perform a network connection

We will finish this description of the architecture of CORE FORCE by illustrating the interaction of the different modules in a typicl scenario, where the user is required to authorize a program's attempt to make a network connection intercepted by the firewall. In this example, a program that has Internet functionality (to download news or check for updates) attempts to make a network connection to a remote computer, and the user is asked to allow or deny the action because there is a firewall rule that applies to the program which has been configured to request user authorization for this connection.

The program has been identified by CORE FORCE when it was launched, and permissions configured for the program are being applied by all security enforcement modules. Figure 2 shows the sequence of steps that happen under the hood from the moment when the program attempts to start the network connection until CORE FORCE shows a window asking the user for authorization. When the program tries to initiate the connection (step 1), Firewall/TDI intercepts this attempt (step 2) and sends a message to Dispatcher requesting the firewall rules to be applied (step 3).

Figure 2. Request for user authorization to connect to a remote computer.

The firewall then finds a rule that matches the connection being attempted (step 4) and because this rule is configured to require user authorization before the action is allowed or denied, it sends a request for user intervention to the Dispatcher specifying all information about the connection (step 5). Dispatcher then forwards the request to Policy Developer (step 6), which is running in user mode, which in turn display a window that displays all information sent by the firewall and asking the user for authorization (step 7).

Figure 3 shows the steps performed after the user answers the question shown by Policy Developer, we'll assume that the user has denied permission to connect to the remote computer (step 1). Policy Developer then communicates with Dispatcher providing this response from the user (step 2), and Dispatcher forwards the information to the firewall (step 3). The firewall then rejects the connection attempt by the program (step 4), as instructed by the user. Finally, the program receives a notification by the operating system that the network connection could not be performed (step 5).

Figure 3. User denies the connection attempt.

A similar interaction is performed by the File System and Registry modules when user intervention needs to be requested. We have shown briefly how the modules in CORE FORCE interact to enforce security permissions and how the Dispatcher is involved as a broker when accessing a protected resource.