Executive Summary
Produced by McAfee (formerly Entercept Security Technologies, and now part of Network Associates Inc.*), Entercept is a Host-based IPS (HIPS) which monitors events at the operating system or application server level.

Since Entercept does not deal with network-based exploits, it is very complementary to existing solutions that deal with attacks on that level, such as firewalls and network-based IDS or IPS products. The latest version adds welcome new features such as a new licensing scheme, key backup capabilities, additional reports, OS lockdown and custom signatures, as well as numerous improvements "under the hood".

The host-based approach ensures that there are no issues with switched networks or encrypted traffic, and the insertion of the Agent software at kernel level means that the system is capable of protecting the host against both known and unknown attacks with a relatively small impact on the host system.

The provision of Web Server and Database Agents also secures application software within an almost impregnable vault where virtually all attacks will be prevented before hitting the server. Should an attack actually get through, it is then prevented from operating outside the scope of the application server itself. The Code Red worm is one example - Entercept users were protected even without the IIS patch in place since the worm was rejected at the HTTP layer before it could deliver its payload.

The Entercept Console is very easy to use, providing excellent Agent update, policy deployment and Agent monitoring capabilities for up to 5000 Agents from a single Management Server.

Architecture
With release 4 of the product, Entercept moved from a simple two-tier architecture to a more robust and scalable three-tier system, based on SQL Server as the underlying database. There are now four main components that make up the Entercept system:

:: Management Server
:: Database
:: Agents
:: Console

Management Server
The Management Server communicates between components of the Entercept system via securely-encrypted SSL sessions. All system activity is logged by the Management Server to the database, and information in the database that is necessary to the administrator is communicated by the Management Server to the Console.

Any system configuration initiated from the Console is communicated by the Management Server to the affected components of the Entercept system.

Communication between components of the Entercept system may be an Agent reporting the trigger of a signature, or the Console reporting a change to a security policy.

Database
The SQL Server database is a repository for all information used by the Entercept system. This information includes a comprehensive list of signatures, security events reported by Agents, system events, user group information, an address book of people who are notified in the event of an attack, and the available versions of Entercept Agent software.

For smaller - or trial - implementations, the cut-down MSDE (Microsoft Database Engine) can be used instead of SQL Server.

Agents
Entercept Agents are installed on every host to be protected in order to provide a layer of protection that identifies and prevents malicious attempts to compromise that host.

The Entercept Agents use a database of security signatures covering a number of different exploit categories, such as buffer overflow, privilege escalations, OS hardening, and so on.

The Agents and the signature database are updated frequently by a "smart update" process that enables automatic update of both Agent code and the signature database.

Entercept Agents also protect specific applications against any operation that is outside the normal behaviour of that application, and protect application resources (such as files and registry keys). Each Entercept Agent protects the Operating System itself and the Entercept Agent and Console applications. In addition, there are Agents that protect specific Web and database servers. The Agent types include:

	Windows Standard Edition - protects the OS and the Entercept applications only.
	Windows Web Edition - as Standard Edition, but adds protection for the IIS Web Server.
	Windows Database Edition - as Standard Edition, but adds protection for the MS SQL Server 2000.
	Windows Web and Database Edition - as Standard Edition, but adds protection for the IIS Web Server and MS SQL Server 2000.
	Solaris Standard Edition - protects the OS and the Entercept applications only.
	Solaris Web Edition - as Standard Edition, but adds protection for the Apache, Netscape Enterprise and iPlanet Web Servers.
	HP Standard Edition - protects the OS and the Entercept applications only (new for this release).

Each Agent has a minimal footprint and communicates with the Management Server via SSL-encrypted sessions. In all cases the Management Server is the slave, and the Agent the master, meaning that it is the Agent that initiates the connection to the Console.

Thus there are no open listening ports on the Agent hosts (other than for the "nudge" feature mentioned below).

The Agent contacts its designated Console at regular intervals controlled by a heartbeat parameter. This is now set automatically depending on the number of Agents reporting to the Management Server, but this can be overridden manually on larger networks with many Agents, where chatter between Agent and Management Server could result in significant network traffic. In the latest release, there is also the ability to "nudge" the Agent from the Management Server in order to enforce a change of configuration immediately, without having to wait for the heartbeat. This still does not initiate a session with the Agent, but merely prompts the Agent to contact the Management Server sooner that it would otherwise.

If communication with the Console is interrupted for any reason, the Agent will show as "not connected" at the Console, but will continue to operate in a stand-alone manner. Security events will be stored locally in an encrypted form until connection is re-established, though if the local storage capacity is exceeded (limited to 10MB by default, but configurable beyond that) events will no longer be recorded. In this case, however, attempted exploits will still be prevented providing the Agent is set to Protection mode.

Each Management Server is able to manage up to 5000 Agents, a significant increase over previous releases (no doubt due to the additional tier in the management architecture). If more Agents are needed, additional Management Servers will be required, though there does not appear to be any way to load balance or consolidate reports across multiple Management Servers.

Console
The Console is a Graphical User Interface (GUI) application that allows an administrator to monitor Agent and System activity, manage security, and manage configuration information.

From the Console, it is possible to monitor security events (triggering of signatures, reactions taken by Agents, etc.), system events (detection of new Agents, update of Agent software, etc.), manage Agents (define Agent groups, set the Agent mode of operation, etc.), define and apply security policies, create exceptions to particular events, view and modified severity levels of specific signatures, create custom signatures, manage the versions of Entercept Agent software on the system, manage users, import and export entities, and create reports.

Besides the four major installed components of the system, the actual program that drives the system to perform the functions and protection for the host is comprised of configurable aspects of the system that determine how effectively Entercept protects that host. In addition, the results of this protection are available to view and interpret, to further enhance host protection. These elements are:

:: Events
:: Exceptions
:: Policies
:: Signatures
:: Notifications
:: Reports

Events
Events are viewed on the Console and are the results of actions occurring on the protected hosts. There are two types of events that the system generates: Security Events and System Events.

A Security Event is generated when an Agent recognises a signature or a behavioural rule violation. The event is sent to the Console via the Management Server and logged in the Security Event Monitor (viewed via the Security Event tab).

A System Event is generated when a defined set of Entercept system activities occur. System Events are logged in the System Event Monitor and view in the System Event tab.

Exceptions
An Exception is a mechanism for overriding a security policy under specific circumstances. In some cases, behaviour that is defined as an attack might in fact be part of a user's work routine or activity that is legal for a protected application.

To allow the user or application to proceed under these circumstances without sending an alert, an Exception can be created. An Exception states, for example, that for a particular Agent, Agent Group, Signature, User, User Group, or Process, the event is ignored.

Policies
Security Policies define the Agent reaction when that particular Agent recognises a signature of a particular severity level. Three possible reactions are taken by an Agent:

	Ignore - the event is ignored
	Log - the event is logged
	Prevent - the event is logged, and the specific operation is prevented from taking place

A Security Policy may state, for example, that when members of a particular Agent group recognise a signature of an Info (white) level, they log the occurrence of that signature and allow the process to be handled by the operating system. However, when they recognise a signature of a High (red) level, they prevent it from taking place. A Security Policy also defines the type of notification that is generated in response to an event.

Signatures
Signatures are descriptions of security threats and attack methodologies. These may range from installation of unauthorised software to blatant attempts to damage a host. Signatures are categorised by severity level and a description of the danger an attack poses to a host, and each signature is allocated a default Severity Level.

Each administrator can, if required, set different Severity Levels for individual signatures via the Console, and it is also possible to disable a signature so that it is ignored by Agents.

There are four Severity Levels:

	Info (white) - Indicates a modification to the system configuration that might create a benign security hole, or an attempt to access sensitive system information. Events at this level occur during normal system activity and generally are not evidence of an attack.
	Low (yellow) - Indicates a modification to the system configuration that might create a more severe security hole than an event of an Info (white) level, or is an attempt to access sensitive system information. Events at this level are not identified as known attacks, but indicate suspicious behaviour on the part of a user or application.
	Medium (orange) - Events at this level are either known attacks with low to medium risk or an indication of highly suspicious behaviour on the part of a user or application.
	High (red) - Events at this level are known attacks that pose a serious threat to a system.

Signatures can be designed for specific applications - for example, Web Servers such as Apache, IIS, and NES/iPlanet - or for the Entercept Agent or Console. The majority of signatures protect the whole operating system, while some protect specific named applications.

Notifications
The Entercept system allows the administrator to define four types of Notifications as part of a Security Policy:

	E-mail - E-mails are sent to alert individuals about the event
	Pager - Individuals are paged when an event occurs
	SNMP trap - Traps are sent to a third-part management console when an event is triggered
	Spawned process - A separate process is generated when an event is triggered

The Address Book is used to create a list of personnel who are to be notified in an event of an attack. Notifications are sent according to specific Severity Levels, Agent groups, or signatures (in previous releases, it was by Severity Level only).

For example, a High level notification may be sent to the Security Administrator via e-mail and pager, whilst High and Medium notifications are sent to other personnel via e-mail only. All SQL Server-related security events can also be e-mailed to the Database Administrator.

Reports
Reports enable the administrator to specify and extract information from the Entercept database.

Reports can provide all the data available for a particular subject (for example, security events) or they can be filtered to deliver specific subsets of that data (High level events reported by X Agent Groups for a specified time period, for instance).

How Does It Work?
Entercept is a kernel-level security technology, although it does not actually modify the OS kernel in any way. Instead, the Agent installs itself just above the kernel, where it can intercept System and API calls, understand their parameters and context, evaluate them in real-time against malicious behaviour, and then allow them to be processed by the OS, or reject them.

As with normal applications, all exploits need to use OS resources in order to achieve anything. Therefore, the System Call/API Call interface is the logical place to reside in order to have a complete view and understanding of a machine's processing environment. In order to be proactive, a protection system needs to reside at this level if it is to have the capability to prevent hacks in real-time.

The context of System and API calls is well-defined - they are used in a well-documented way, with well-defined parameters, in order to achieve specific and identifiable results. Because of this, there is little ambiguity in determining whether a request for system resources can be termed "good behaviour", or whether somebody is trying to exploit a known vulnerability. In addition, nothing is encrypted at this level, meaning that all parameters are passed in clear-text, making it easier to identify malicious intent and keeping false positives to a minimum.

Click for larger view

Figure 1 - Entercept: Architecture

Entercept is available in three versions: the Standard Edition, the Web Server Edition, and the Database Edition. The Web Server Edition includes all the functionality of the Standard Edition as well as additional features specific to preventing attacks against Web Servers.

Entercept Standard Edition
The Entercept Standard Edition protects the most important part of any server: the operating system.

All users and programs access the server through the operating system. Entercept Standard Edition runs on Solaris, HP-UX, and Windows, and offers the following capabilities:

Resource Protection - The Standard Edition protects system resources (libraries, files, directories, user accounts) and prevents them from being amended in any way, thus preventing Trojan horses, rootkits, and backdoors from altering the system resources in order to install themselves.

Prevention Of Privilege Escalation Exploits - Privilege escalation attacks are designed to give ordinary users super user-level (root or administrator) access to the server. The Entercept Standard Edition prevents these attacks from succeeding by preventing access to the files and resources necessary to alter privilege levels. Even new, previously unpublished privilege escalations can be stopped without knowledge of the specific exploit. This is possible since all privilege escalation exploits alter user privileges, and Entercept prevents such alterations.

Buffer Overflow Exploit Prevention - The Entercept Standard Edition is able to determine if code that is about to be executed by the OS came from a normal application or from an overflowed buffer. If the code came from a normal application, Entercept allows it to be executed. If it came from an overflowed buffer, it is blocked, and the buffer overflow exploit is thwarted.

Unknown Attacks - Entercept can prevent the aforementioned attacks using behavioural rules technology, rather than relying solely on individual signatures. This technology allows Entercept to stop new and previously unknown attacks without requiring signature updates to the product. For example, Entercept's rules to stop buffer overflow exploits from succeeding are not tied to a specific application or signature. Instead, Entercept can prevent buffer overflow exploits from succeeding, regardless of the application or buffer involved.

SecureSelect - Entercept provides three security modes: SecureSelect-Warning Mode, SecureSelect-Protect Mode, and SecureSelect-Vault Mode. Each mode provides more security than the previous one. Customers begin Entercept deployments in Warning Mode, then progress to Protection Mode, and Vault Mode as they tune and tighten their Entercept installation.

Entercept Web Server Edition
The Entercept Web Server Edition (WSE) runs on Solaris and Windows. It supports Netscape Enterprise Server, iPlanet Web Server, Apache Web Server, and Microsoft IIS Web Server. The Web Server Edition includes all the functionality of the Standard Edition as well as additional levels of protection specifically tailored for Web servers, including HTTP Filtering and Web Server Shielding:

HTTP Filtering - Entercept Web Server Edition includes an HTTP filtering layer that intercepts HTTP requests after they are decrypted and decoded (from any SSL encryption, Unicode encoding, or hex encoding) before the Web server executes them. Entercept uses signatures at this layer to detect attacks against the Web server and other vulnerabilities.

This layer is the preferred place to stop attacks, since they are blocked long before the server can actually execute them.

Web Server Shielding - Entercept also employs Web Server Shielding to stop both known and unknown attacks from altering Web content or using the Web server as an attack tool.

Entercept places the Web server application, its files, and its resources inside a virtual "steel vault". If the Web server attempts to access any resources outside that vault, Entercept blocks the attempt. Conversely, if any other user or process tries to access or alter the files or resources contained within the vault, Entercept blocks that access as well.

Entercept accomplishes this protection by defining a set of behavioural rules for the Web server. If the Web server attempts to do things that are not within its defined behaviour, the attempt is blocked. This ensures the integrity of the Web server, its applications and files (including customer data), and enables Entercept to protect Web servers from both known and unknown attacks.

Click for larger view

Figure 2 - Entercept: Web Shielding

The shielding concept is based on a simple yet powerful assumption that the Web server and Web application execution pattern is very specific and repeats itself. Thus, it is possible to accurately characterise the "normal" behaviour and the typical access patterns to resources of the Web server.

The "normal behaviour" of the Web server is encoded as rule templates rather than fixed rules, allowing the Web server to be installed and configured in different ways for different installations. As the Agent starts up, the shielding mechanism initiates a scanning process that gathers a set of attributes reflecting the details of the installation and configuration of the Web server, including services, program files, data files, Web pages and Registry settings.

Next, an instantiation program is executed that derives the appropriate rules from the given rule template. The instantiation program uses the information gathered during the scanning phase to fill the missing information within the rule template and to generate the specific optimised rules.

Once the set of rules is ready, they are loaded into the Agent. This procedure is executed whenever the Web server configuration is modified. Entercept's protection tightens the security of the Web server resources to the extent that even if an intruder gains administrative privileges, he still cannot access those resources.

It accomplishes this in a number of ways:

Program File Shielding: The shielding protects the Web server executables and configuration files from being modified or deleted. As an example, the "inetinfo.exe" file, which is the main IIS executable, will be located and an appropriate rule including its current directory will be generated. This rule will not allow any program other than the Windows Installer to modify this executable.

Data File Shielding: Access to the Web server data files is restricted to the process running the "inetinfo.exe" executable. Since the executable is shielded, it is guaranteed that no other process will access the data files. In addition, the static Web pages are also shielded, and any attempt to either modify or delete these pages is prohibited. The only program that can modify these files is the predefined Web-authoring tool run only by the predetermined Web master.

Registry Shielding: To function properly, the Web server relies on settings stored in the system Registry. If the intruder modifies the appropriate Registry entries, he can affect the operation of the Web server. The Registry shielding makes sure that the correct level of read/write access is granted only to the appropriate processes.

Service Shielding: To prevent denial-of-service attacks, the Web server shield includes rules that prevent any attempt to stop the Web server service or change its start-up mode.

User Shielding: The shield makes sure that the privileges of the users under which the Web server runs cannot be modified. This eliminates the possibility of escalating the privileges of the Web server user, a common goal of intruders. The shield also prevents changing the user under which the Web server is running. If, for example, the user was changed to Administrator, ensuing attacks could be harmful since the attacker could execute code with Administrator rights.

Hackers often exploit Web server and application vulnerabilities in order to escalate privilege, execute malicious commands or access data. Since the normal behaviour of the Web server is well defined, most of these deviations can be identified and prevented.

Web shielding ensures that nobody (process or person) can alter the configuration, layout, and operation of the Web site.

Even if intruders gained administrative privileges on the server box, they still would be unable to deface or otherwise modify the content files (such as the corporate Home page).

Entercept Database Edition
Entercept Database Edition provides a means to protect assets and ensure database server integrity by protecting against both unknown and known attacks, including popular SQL Injection attacks. Entercept Database Edition locks down the database to both enforce correct behaviour and block abnormal behaviour.

Entercept uses a technique called SQL Interception to intercept all incoming database queries and block any that would result in malicious activity. Entercept's SQL Interception Engine analyses the query for buffer overflow conditions, SQL injection attempts, and abnormal manipulation of the database. Using this information, calls are matched against the appropriate behavioural rules and known attack signatures. Entercept then blocks queries that attempt malicious behaviour or match any specific attack signature. All preventive activity is logged to the Entercept Management System for review and reporting.

The Database Edition performs the following operations:

SQL Injection Protection - protects against a common threat to database security: SQL injection techniques. By entering cleverly-crafted SQL statements into a vulnerable application's data fields, attackers can access restricted data such as credit card numbers, delete private data, alter data, and even attack the other computers on the database server's network. The Entercept Database Edition prevents SQL injection attacks by validating SQL queries before they are processed by the database engine. Malicious SQL injection attempts are rejected and the database's integrity is preserved.

Specific Attack Prevention - prevents attackers from disrupting the database. Dozens of known attacks exist that are designed to crash and/or compromise database servers. Using SQL Interception technology, Entercept blocks these attacks before they can cause any harm to the database.

Database Shielding - protects databases and data from unauthorised access. Database shielding ensures that no process, other than the database itself, will be able to access the database's execution environment, data, or settings. In addition, the database is prevented from accessing non-database resources. This prevents attackers from using the database to launch attacks against other targets.

All Features of Entercept Standard Edition - The Entercept Database Server Edition includes the features described above, as well as all the features present in the Entercept Standard Edition: known and unknown attack prevention, buffer overflow exploit prevention, resource protection and prevention of privilege escalation.

One of the key advantages of Entercept is the fact that all activity on the host is seen, and is not impaired by encryption, switched data or reliance on system log information. Entercept functionality can be used to protect specific resources of the OS or applications (registry keys, accounts, files, processes, and so on), and from that point of view, it can be viewed as a means to harden both the OS and applications on a server.

In fact, this "OS hardening" capability has been extended and automated in recent releases of the software through the introduction of the SecureSelect Vault Mode. This mode of operation provides users the capability to lock down their operating system based on Vault Signature rules, which are designed to monitor for critical activities that would normally be signs of OS update or patching activity.

Performance
The aim of this section is to determine the impact the Host IPS agent has on the host on which it is installed.

Entercept stopped all of the attempted unauthorised access to critical files, directories, registry keys and applications, and it was very straightforward to create exceptions to allow legitimate operations to proceed where they have been prevented in error.

As you would expect from an agent incorporating an ISAPI filter, there is some impact on the overall performance of the host Web server once the Agent software has been installed.

The most obvious impact of the Entercept Agent is to reduce the maximum capacity of the server when under extreme loads, as well as to increase the average page and URL response times. However, when the server with and without Agent is compared under the real-world load levels of our tests, the differences - although numerically significant in that the average response time is approximately four times greater with the Agent installed than without - are still only in the order of microseconds.

Given that all response times, with or without the Agent installed, remain less than one millisecond throughout our tests, it is extremely unlikely that the Agent will make a noticeable difference to the user experience.

Finally, the FTP tests show almost no performance degradation between the two tests. This indicates that the actual impact of the Agent alone is indeed as low as that claimed by Entercept, and that the most significant impact (numerically, rather than real-world) is imposed by the use of the ISAPI filter in Web traffic.

Overall, the Entercept software is unlikely to impact negatively on the average user experience, especially when weighed against the benefits of having the Agent installed.

Security Effectiveness
Entercept did well in all our tests, providing the ability to detect most of our activities via the default policies and signatures.

Where our requirements fell outside the scope of the built-in rules, the custom signature capability - which is much more flexible in the current release than in previous versions of the software - allowed us to cover most activities (the only exceptions being custom signature creation for FTP exploits and user-specified network services/ports).

None of our evasion techniques had any effect on the detection or prevention capabilities of the Entercept Agent.

Usability
This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis.

Installation
Although this is a slightly more complicated than previous releases due to the addition of the Management Server, installation is still very straightforward. All that is required is to run the Installer from the CD supplied and select the appropriate menu options.

The first job is to install the Management Server and its underlying database - this can be SQL Server, which is recommended for all live deployments, or MSDE, which is suitable for trial (or very small) implementations. During installation a public/private key pair and accompanying digital certificate is generated to enable authentication and encryption between Agents and the Management Server.

The Management Server also includes the Tomcat Web server in order to provide secure Web-based access to the Entercept Console. It is recommended that a Web and Database Agent be installed on the Management Server to provide complete protection, and one is included in the package at zero cost.

The Java-based Entercept Console can be installed on any host on the network with access to the Management Server. Once Management Server and console have been installed, it is time to deploy the Agents. The Agent can be installed from the CD or from a network share, and the Management Server's public key must be provided to the Agent during installation. This can also be acquired from the Management Server (in unencrypted form), though the most secure means of distributing this vital component would be via an out of band method such as floppy disk.

Although the initial installation is performed manually, subsequent upgrades to the Agent are carried out from the Console. Organisations with large numbers of Agents to roll out may want to consider the use of third party software distribution tools for the initial installation.

Despite the low-level operation of the Agent software, no reboot is necessary after installation (or uninstallation), and the Agent immediately contacts the Console to determine its initial mode of operation. Parameters in the Console specify whether the Agent should be active by default following installation, and whether it should start up in "Warning" or "Protection" mode.

All new Agents have the default policy applied automatically, and each Agent is brought up in "Warning" mode to ensure that alerts are raised immediately, though no suspicious operations are blocked.

Configuration
The Console is protected by a user name and password combination, and any number of users can be created. The options and views available to a user when using Entercept are based on the role they are assigned by the system administrator. Each role (except for the Global Administrator) only allows certain actions to be performed, eliminating Console menu tabs and restricting the scope of alerts that can be viewed where necessary.

Click for larger view

Figure 3: SEQ Figure \* ARABIC 3 - Entercept: Java-based GUI Console

In addition, each user can be restricted to working on one or more Agent groups if required. For example, a user with a Viewer role can create a report for the Agent group they are associated with, or can view security events, but they can not create Exceptions or Policies. This prevents unauthorised users from editing entities that can adversely affect the way the system operates. Roles allow the system administrator to enable only certain qualified users to manage sensitive Entercept features.

All critical configuration files and databases are protected by the Entercept Agent itself, a copy of which can be installed on the host machine following installation of the Console software (a free license is provided for this Agent).

The Console has changed somewhat in appearance - though not much in the way it operates - since the last time we looked at this product in our labs. This is because the GUI has been completely redeveloped as a Java application. The main Console screen is clear and easy to read, with a toolbar down the left hand side consisting of three icons: Event Monitor, Configuration and Tools. On selecting one of these options, a tabbed window appears in the right hand pane, once tab for each of the options in that menu.

One nice ease-of-use feature is that the right hand pane is itself divided into two sections.

The main operations always occur in the right-hand section, whilst the left-hand section always contains a hierarchical tree view of the elements which are being operated upon. So, for example, if the administrator is working on Signatures, the tree will present a top-level view pertaining to "All Signatures", and lower-level branches which correspond to Agent Groups, thus allowing the administrator to quickly select Signatures applied to an individual group only. The Address Book tab has a top level of "All Contacts", and lower-level branches for each type of contact, such as e-mail, pager, SNMP trap, and so on.

Every window in the system which displays data allows that data to be sorted by any column, and columns can be moved around (though not deleted) to format the screen layout as required. An excellent new feature is the provision of a filter icon on every column of data in the system. By clicking on this icon in a particular column, the administrator is presented with a drop-down menu of selections (if the column contains a range of fixed values, such as Severity Level), or a free-format text search box.

By entering values within these search boxes, the data is filtered and the only records displayed are those which match that particular criterion. The icon changes colour to indicate that a filter is active on that column, and multiple filters can be active on multiple columns.

Alternatively, selecting any row of data and then clicking on the filter icon will set the filter immediately to the appropriate value in the row selected. A separate filter dialogue window is also available to allow multiple filters to be set in a single place if required.

This feature is extremely easy to use, and yet extremely powerful in operation, enabling the administrator to quickly and easily isolate small subsets from large volumes of data, whether it be configuration data such as signature definitions, or alert details.

Policy Management
The Policy option is something of a misnomer, since unlike a typical IDS or IPS product, Entercept does not expect the administrator to define which signatures apply to which Agents. Instead, all enabled signatures are applied to all Agents by default (some of the more "noisy" signatures are now disabled by default out of the box), and the Policy simply determines how specific Agents or groups of Agents will react to security events, and which people will be notified of those reactions. The definition of how an Agent will react is based on the Severity Level of each security event.

All that is required is to define the Agents and/or users to which the Policy applies. Policies can be as granular as they need to be - applying to a single host or user if required - since it is possible to apply multiple Policies to individual entities. Where conflicts occur (where a group-based Policy has different settings to an individual one, perhaps) they are resolved automatically by Entercept applying the highest security setting of those that are in conflict.

Each alert generated by an Entercept Agent has a Severity Level associated with it - high, medium, low, info or disabled - and this determines the action that is taken by the Agent when each alert is raised.

Three direct actions are supported:

:: Ignore - the action that caused the alert is allowed to continue and no record is kept

:: Log - the action that caused the alert is allowed to continue, but details of the alert are recorded

:: Prevent - a log entry is made and the action is terminated. A sensible error code is returned to the application that caused the alert so that it is not obvious that it is an IPS that has terminated the action.

In addition to one of the direct actions above, it is also possible to generate alerts via e-mail, pager, spawn process (which could also take additional corrective action via external programs, scripts or batch files), or SNMP trap. Log entries are always recorded to the Entercept database and reported directly to the Console screen.

Click for larger view

Figure 4 - Entercept: Policy management

In the latest release, the product includes a small number of pre-defined Policies which are created during installation. These range from Level 1 - where only High level security events are prevented (this replaces the old "default" Policy in the latest release) - to Level 3 - where all levels except Information are prevented - and are designed to allow administrators to be up and running as quickly as possible. In addition to the noisier signatures being disabled by default, many of the other signatures have also been re-graded for this latest release in an attempt to ensure that High (red) signatures are now only comprised of events with zero chance of raising a false positive. Thus, the Level 1 policy can be selected with confidence from day one.

However, should the administrator wish to "re-grade" a number of signatures himself (perhaps to re-enable all of those which are disabled), there is a problem. It is not possible to make bulk changes to Signatures in this way - each one has to be amended separately. This makes operations such as changing all "Disabled" signatures to "Informational", a long winded affair. In addition, the Signature tab still only shows the default Severity Level, and not the new one.

This is partly necessary because it is possible to apply multiple Severity Levels per signature - one for each Agent group, for example - but it still makes it very difficult to track changes at a glance.

The Agents tab provides a list of Agent groups down the left, and Agent details on the right. It is the Agent Groups that determine the security policy that is applied and, as mentioned previously, it is possible to allocate Agents to more than one group. All new Agents appear in the "All Agents" group by default, from where they can be moved into other groups as required.

Click for larger view

Figure 5 - Entercept: Configuring Agent properties

Selecting any Agent Group brings up a list of Agents within that Group, with details of the Agent type (OS platform, and whether it is a Server or Web Server Agent), version, current state and requested state. The Console can check the Entercept Web site at regular, administrator-defined intervals and automatically download new versions of the Agent software.

With the latest release, it is possible to have multiple versions of an Agent active on the network at the same time (previous releases allowed only two versions to be active - a "live" and a "test" version). This provides the means for the administrator to test new Agent releases on specific test machines before deploying them live across the organisation.

Once correct operation has been verified, the new versions can be rolled out to all the hosts controlled by the Console automatically - no reboot or other intervention is required on any of the Agent hosts. It is also possible to roll-back versions to a previous release at the click of a button on the Console should problems arise.

The "state" of an Agent can be set to one of three values, which are known as SecureSelect levels:

Warning Mode - Entercept logs all perceived malicious activity, but does not block that activity.

This mode is very useful for tuning the Entercept system and assessing Entercept's impact on installed applications. that would otherwise violate the Entercept Security Policy. Note that even in Warning Mode, there are some events - such as trying to delete the Entercept database - which will always be prevented.

Protection Mode - This is the next step in the deployment lifecycle. Once any tuning has been performed in Warning Mode, security administrators can enable Protection Mode. This mode protects against buffer overflow attacks, specific known attacks, and enforces behavioural rules on the system to prevent new, previously unknown attacks.

Those events which are marked as ignore or log are allowed to pass, whereas those marked as prevent will be stopped and logged immediately by the Agent. Protection Mode provides the full protection of Entercept, without the extra OS lock-down features provided by Vault Mode, and thus requires less tuning. Organisations may elect to remain in Protection Mode or continue to improve their security posture by moving to Vault Mode as required.

Vault Mode - This mode is designed to build upon the protection present in Protect Mode and take it one step further. Vault Mode locks access to the key files and settings most critical to the operating system and prevents them from being accessed or changed, even by users with root or administrator privileges. This prevents attackers from compromising the OS, even if they are able to obtain root-level access.

Vault Mode is most appropriate for servers that do not change frequently, as Entercept will prevent all attempts to change the system's configuration - including applying OS updates and patches. Necessary, authorised configuration changes can be accommodated via Entercept's exception mechanism or by placing an Agent temporarily in Warning Mode.

By locking down the OS critical files, Entercept is attempting to provide some of the advantages of a trusted OS without the management and cost implications associated with replacing existing operating systems. Attackers are unable to install rootkits, Trojaned versions of system files, or viruses on Entercept-protected servers that are Vault-enabled. Additionally, by protecting and locking the critical OS configuration files, Entercept thwarts attempts at server compromise by changing the OS configuration.

Naturally, such a complete lock-down of the OS can also have tremendous negative impact too, so the administrator needs to be sure that Vault-enabled servers are not running - or accessed by - software that may need to access or update critical OS files or settings for any legitimate reason. Vault Mode would be particularly useful for dedicated Web and FTP servers, for example, particularly those installed as public-facing servers in the De-Militarised Zone (DMZ).

The pre-defined policies are always applied automatically from the moment the Agent is activated although, by default, Agents are initially placed into Warning Mode only (this default initial setting is configurable). However, now that High (Red) signatures are considered safe to deploy immediately with zero chance of false positives, the administrator is able to move to a basic Protect Mode level of operation (at least with the default Level 1 Policy) very quickly.

Administrators are advised to run Agents in Warning Mode for a short period of time following installation to provide some idea of what could be considered "normal" behaviour. The information that is gathered while the system is in Warning Mode can then be used to create any Exceptions that may be needed before moving to Protect Mode. Entercept Exceptions enable customisation of the predefined Entercept Security Policy and allow custom applications to perform any necessary functions that would otherwise violate the Policy.

For example, Entercept can log details of any attempt to add, delete or modify files in the protected Web directories. However, these are all normal activities for the Webmaster, and so it would be desirable to define Exceptions to these events. An Exception allows the administrator to specify when a particular security event can be ignored in order to filter out false positives, and it can be applied on an individual Agent, user or process basis if required. This would allow a rule which says that files can be added to the Web root directory only if they are added by user Webmaster, using FrontPage on server WebServer.

Click for larger view

Figure 6 - Entercept: Advanced Exception properties provide increased flexibility

Exceptions can be defined based on a number of parameters, including users and groups, processes (applications), Agents, specific Signatures, and "Advanced Details" (wildcards are acceptable). That last one is extremely powerful, since it allows Exceptions to be based on one or more pieces of "context data" from an event, such as the source or destination IP address, workstation name, URL and so on. It is also possible to combine multiple signatures into a single exception.

Without a doubt, the easiest way to create an Exception is to wait for a security event to be raised, right click on the event and select "Create Exception", and then tune the Exception parameters as required. When reviewing security events raised from an Agent in Warning Mode, this provides a relatively quick and easy means for the administrator to fine tune a Policy before switching the Agent to Protect Mode.

However, it does have the disadvantage of actually requiring a security event to be raised in the first place, and this may not always be desirable (especially when the Agent is already in Protect Mode and the administrator knows an Exception is required to prevent a new application from being blocked). For these cases, it is possible to create Exceptions from scratch in advance, so that where the administrator knows that a Policy rule will cause problems, those problems can be pre-empted and the Policy tuned before it is deployed.

Click for larger view

Figure 7 - Entercept: Signatures

The heart of the Entercept system consists of the Signatures. These are descriptions of security threats and attack methodologies, ranging from installation of unauthorised software, to attempts to damage a computer. Signatures consist of a set of rules, or entities, associated with a Severity Level that defines a set of possible occurrences or incident. Severity Levels are divided into four colour-coded categories (red, orange, yellow or white) indicating the different levels of potential danger to a system (high, medium, low or info), and allowing the administrator to define different reactions to different levels of potential harm. When a Signature is activated, the Policy is checked to determine what action is to be taken, as defined by the Security Level. A Signature can also be disabled, so that it is ignored by Agents. Signatures can also be designed for specific applications, for example: Web Servers such as Apache or IIS; Database Servers such as Microsoft SQL Server 2000; or the Entercept Agent or Console.

Severity Levels can be modified for individual Signatures (there is no means to alter Levels for a group of Signatures) and thus define how Entercept will respond to specific security alerts. For each Signature, it is possible to override the default Security Level on a global basis (i.e. for all Agent groups) or for a specific Agent group.

For example, if an attempted directory traversal is detected on an Internet-facing Web server, it could be designated as "High", whereas on a purely internal server it would be "Medium".

Whereas "Medium" priority would ensure that the event is prevented and logged, "High" priority may also reprogram the firewall (via a spawned process) to prevent further traffic from the attacking host, as well as raising an SNMP trap to escalate the alert to a central network management console.

Click for larger view

Figure 8 - Entercept: Signature Severity Levels

Security Levels provide an enormous amount of flexibility in how attacks are handled within Entercept, but once a large number of them have been customised it can be difficult to determine exactly what constitutes the actual Security Policy applied to any given Agent or Agent group.

One of the biggest changes in the recent releases has been the ability to define custom Signatures from scratch. This has been further enhanced in the latest release via the addition of GUI tools to define and maintain those custom Signatures (previously handled via a cumbersome method of editing text files). This allows Entercept to compete more readily in the traditional Host IDS market place since it is now possible to monitor and prevent access to any file or registry setting on the protected host.

The rules definition capability is very flexible - each rule can be designated as an include or exclude rule, and wildcards can be used throughout. This makes it possible for Entercept to monitor and/or prevent access to a wide range of files, directories, applications and registry entries. Signatures can be created from scratch for those conversant with the rule definition language, or via a graphical Wizard. The latter is the simplest way to create a basic rule which can then be tweaked and tuned manually as required.

Once custom Signatures have been created, they are treated like normal rules in terms of policy definition and alert generation, although they are displayed with a "Custom" icon that distinguishes them from standard signatures in the GUI. As with normal Signatures, it is possible to define Security Levels and Exceptions for custom Signatures.

When using more than one Console, the Import and Export feature is a new feature that can be used to transfer the following information between them:

:: Agent Groups
:: Policies
:: Address Book
:: Notification
:: Exceptions
:: Signatures

Click for larger view

Figure 9 - Entercept: Creating Custom Signatures

Transferring information is performed through an export basket that contains the objects that are being imported and exported in a configuration file. These objects contain related entities. This feature allows the administrator to export all local configuration (useful for backup and Console duplication), certain information (all exceptions, security policies, and so on), or specific settings.

Alert Handling
The Console provides the Event Monitor window, which contains two real-time monitoring tabs (one for Security Events and one for System Events) to display events as they are transmitted from the Agents.

The Security Event tab lists all Security Events reported by the various agents that report to the Console. It provides a one line description of each event, and - as with other areas of the system - all the events can be filtered or sorted on any of data in any of the columns. There is also a comprehensive search capability allowing subsets of the available data to be displayed based on various criteria such as Severity Level, Signatures, Agents, Processes and Users. The filtering, sorting and searching capabilities - some of which are new for this release - make tracking down similar or related groups of events very straightforward.

By clicking at any point in the hierarchical tree view to the left of the screen it is also possible to view Events from all Agents, or only those Events raised by a specific Agent.

Events can be marked as read or unread, and it is possible to store notes against each event. Events can also be hidden once they have been dealt with in order to reduce on-screen clutter, and unhidden should further investigation be required. One bad point about the interface is that when using the "Select All" option to mark as read or hidden, only the items on the current page are selected, and not the entire set of unread/unhidden alerts. This can make it a long and laborious process to clear a large number of alerts.

Click for larger view

Figure 10 - Entercept: Handling alerts via the Security Event Monitor

Note that when two events are triggered by the same cause, the reaction taken is the highest of the two. For example, assume that Low level events are assigned the reaction Log, and Medium level events are assigned the reaction Prevent. When these events are triggered by the same cause, the reaction is Prevent.

Two small icons at the top right of the screen provide an instant indication of the arrival of new Security or System events. On clicking these icons, the status is cleared and a window popped up to provide a quick count of the total number of events of each Severity Level.

More detailed information can be displayed for each event by viewing its properties, where the event and the actions that triggered it are described fully. If it is decided that a particular event is a false positive, a click of a button is all that is required to create an exception based on that event.

The System Event tab is very similar in appearance and operation to the Security Event tab. It's job, however, is to monitor Entercept's system activity, such as services starting/stopping, console administrators logging on/off, agents starting/stopping, and so on. Events can also be filtered in a similar manner to the Security Event tab.

Reporting and Analysis
Reporting continues to improve with each release of the software, and there are a number of pre-defined text and graphical reports available via the Reports menu.

Click for larger view

Figure 11 - Entercept: Text report

Several of the reports simply document the system configuration, whilst others provide graphical analyses of security events and reactions.

Available reports include:

:: Security/System Events
:: Agents/Agent Groups
:: Exceptions
:: Policies
:: Address Book
:: Notifications
:: Agent Versions
:: Signatures
:: Security Events by Agent/Agent Group
:: Security Events by Date
:: Security Events by Reaction
:: Security Events by User
:: Security Events by Severity Level
:: Reactions by Agent/Agent Group
:: Reactions by Severity Level
:: Policy Reactions by Severity Level
:: Agent Uptime
:: Notification History for Security/System Events
:: Configuration Preferences

Most eventualities are covered, which is just as well since Entercept locks down the database and configuration as a security measure, thus preventing additional user-defined reports from being implemented.

Reports can be filtered on a wide variety of parameters (depending on the report subject), including:

	Security Level - Info, Low, Medium, High (or all)
	User - Operating system user (one only can be selected, or all)
	Reaction Type - Log, Prevent (or all)
	Signature - One only can be selected (or all)
	Agent - One only can be selected (or all)
	Process - One only can be selected (or all)
	Date Range - From and To dates, or Last X Days (or all)
	Acknowledged By - Entercept user (one only can be selected, or all)

Each report can be viewed on-screen in PDF or RTF format, and saved as PDF, RTF or Excel files. The biggest problem with the reporting system at the moment is that data is archived every 24 hours to CSV files, after which it