Policy Central Enterprise

Introduction

|

How we tested

|

PCE

|

Verdict

Most companies have an AUP (Acceptable Use Policy), which prohibits using company resources for unacceptable purposes. Yet enforcing the acceptable use of business computers is quite often a tricky business.

Depending on the business and its user base, the AUP can be quite relaxed, only forbidding more extreme behaviour like accessing pornographic Web sites or disseminating threatening e-mails (essentially, any behaviour which could lead to legal action). At the other end of the scale are businesses which forbid their users to indulge in using computers for any personal, non-work-related activities.

There are various methods of policy enforcement, some more effective than others. Very common methods are user/workstation group policies applied on login and Web content filtering at the firewall/proxy level. These approaches are generally easy to implement as the infrastructure supporting them is generally already in place, so it's just a natural extension of pre-existing services. They are a bit reactionary however, placing the onus of enforcement on the IT services department. This means thinking ahead of their user base, attempting to -head them off at the pass", so to speak.

A better approach is to place the onus back onto individual users, and have them police themselves. Rather than having the AUP Police stand over everyone's shoulder while they work, to make such an approach effective means you need a physical presence at each workstation with centralised data collection. This is where applications like Policy Central Enterprise come into their own.

Technical Overview
PCE is a client/server-based application, developed by Security Software Systems and distributed locally by Perth-based Eye4you.

The main server application is installed on a machine running Windows 2000/XP Professional or Windows 2000/2003 Server. Data is stored on either a local MDSE/SQL 2005 Express database, or a local or remote SQL 2000/2005 database. The PCE application can only install to a database server which does NOT use a named database instance. While many SQL-based applications can install to a named instance if specified in full, PCE won't recognise the database. The front end is accessed via a virtual Web site served by IIS 5.0 or 6.0. .NET Framework 1.1 or 2.0 is also a requirement on the server machine.

The operating system requirements are dependent on the size of the client base that PCE will be supporting. For a small network of up to 35 clients, Windows XP Professional with an MSDE/SQL 2005 Express database is fine. Bear in mind that Windows XP Professional only supports a maximum of 10 concurrent connections, so for more than 10 clients Windows 2000/2003 Server is required. Subsequently, anything more than 500 clients requires a local or remote SQL 2000/2005 database.

PCE can communicate with Active Directory (AD) to import users, groups and machine information into its own database. The machine which PCE is installed on does not have to be a member of the AD domain but it helps with the speed of communication (especially if AD is heavily populated).

The client component of PCE is installed on every machine in the organisation -- which is what enables system administrators to maintain a physical presence at each workstation. The client software has a very small footprint -- around 200KB -- and is completely undetectable. It communicates back to the PCE server on non-standard TCP/IP ports to avoid conflict with other networked applications.

The PCE server maintains a list of attached clients, and distributes the centrally-maintained policies to each. The client software monitors local activity and when it detects an action which violates the policy, or is in some other way actionable, an event is created and logged with the PCE server. The server documents the event for that particular user, and can automatically inform the system administrator via SMTP.

Introduction

|

How we tested

|

PCE

|

Verdict

Eye4you provided ZDNet Australia with a trial version of the software for testing purposes. Any business interested in trialling PCE can download it from Eye4you's Web site.

The test environment was a VMWare Windows 2003 SP1 Server with Active Directory, IIS and SQL 2005 Express, with a VMWare XP Professional SP2 workstation as the client. The client machine was a member of the AD domain and the user account was also a domain user.

[Click to enlarge] PCE sets itself up as a virtual web server in IIS

Installation is very straightforward -- most of the effort in installing PCE lies in preparing the server. .NET Framework should be installed before IIS (it just makes life easier), and the database engine needs to be fully operational. You will be prompted for the sa username and password during the installation when the PCE database is created. Browse for the database server to ensure you access the correct one.

PCE is very much dependent on standard networking rules and protocols to function. The server and client need to be able to communicate normally via TCP/IP, and should be able to resolve each others' host/domain names. It's also easier if the clients are members of Active Directory.

[Click to enlarge] The Remote Deployment Tool makes installing client software a breeze

Installing the client software can be done in a couple of ways. The simplest way is to open a share to the client install package stored within the application directory on the PCE server and have the clients connect remotely to it and perform the installation. Another option is to have the server perform a remote deployment to all known workstations. PCE comes with a remote deployment tool which can leverage off Active Directory (if installed). Computers known to AD can be imported into a list of machines which need the PCE client installed or updated. You can also add machines which are already known to PCE, or add them individually by hostname. The server must obviously be able to resolve each hostname to its IP address. Point the deployment tool at the share which contains the client software and away it goes.

The only drawback is that if Windows Firewall is active on the client then the push with fail. If this is the case the client will either have to be modified to allow traffic through from the PCE server (which is the better idea), or connect to the share and perform a pull installation.

Introduction

|

How we tested

|

PCE

|

Verdict

The main features of PCE are controlled on the PCE server via a Web console interface. This is served via IIS and is accessible locally or from a remote workstation. The console view is split up into different tabs which control all the various features of the app.

[Click to enlarge] Summary page: what's happening within PCE

Summary
Displays a summary of captured information: the most recent captures, users with the most captures against them, database statistics, top five Web sites and top five Web site users.

Desktop
Allows you to administer desktop filtering -- which is essentially what happens on the client computer -- and how PCE responds. The client software can be set to run in active or stealth mode -- active mode places a -PC" logo in the system tray, but users can't interact with it. The policy statement can be made to show every time a workstation is turned on, or every time a user logs on (useful for public access machines).

When the client detects a violation, the default action is to take a screenshot and log the incident, but it can also display a violation warning screen or close the application window.

[Click to enlarge] Configure what happens on each client, and what words to look out for

The desktop library has a number of pre-defined words in various categories. You can increase or decrease each filter or turn it off completely, depending on the level of restriction you wish to apply.

The Disabled Word Library lets you put in specific words which are exempt from the desktop library. Even if it's a word which would otherwise have flagged a violation, once it's disabled it won't cause any action to be taken. Similarly, the Blocked Word Library lets you specify words which will flag a violation.

The last entry on this screen lets you set the policy for offline clients. Clients which can't communicate to the PCE server will either have the client disabled until they re-establish communication, or the client can continue to monitor violations, store them locally and then forward all the stored incidents to the server on re-connection.

Internet
This screen is similar to desktop filtering, but is specific to Internet activity. By default, PCE will log all Web sites visited as well as chat sessions within MSN Messenger 7.5, Yahoo Messenger 7.5, AOL Messenger 5.9 and AOL Triton 1.0. It also allows you to scan Internet activity and block URLs which fall into particular pre-defined categories, like pornography, gambling or Web mail.

[Click to enlarge] Lock down your Internet access!

You can also maintain a list of allowed and blocked sites (domain names) and apply those rules to either the currently selected group or globally across all groups. To be really restrictive, PCE has the ability to only allow access to a manually-defined list of sites, with all other sites blocked.

Finally, you can prevent the selected group from accessing the Internet during particular times. This is convenient if you have rigid work hours and wish to prevent employees accessing the Internet outside of this time, or if the users are school students.

Application
Application management lets you add applications to a list. Each entry is subject to a policy acceptance requirement and/or time restrictions and can be applied to a single group or globally. You can also modify the text of the policy statement.

e-mail
Allows you to be notified by e-mail when a violation takes place. You can specify how many captures are contained in each e-mail, and which addresses they are to be sent to.

Group Settings
Shows you the users contained in each user group, or each workstation contained in the workstation groups (viewed on the left-hand side of the screen). You can move users and workstations between groups, or add new users. Any user can have their rights revoked for a specified time, and you can browse their activity to date.

General
Lets you define various settings for the PCE application. You can set a maximum number of captures per user and whether the capture is done in black & white (faster) or colour (slower but more detail).

Active Directory synchronisation is set-up through this page -- enter in the domain/administrator details, and then you can pull AD groups or users into the PCE database. Existing computers or users won't be overwritten.

This is also the area to define the proxy server, SMTP server, cache server and time synchronisation. Additionally you can specify a redirection URL when a blocked URL is accessed. By default it's the Security Software Web site, but you can make it a descriptive internal page.

Console Users
By default there is one admin account for accessing the PCE console. Here you can change the default admin password and add more console users.

[Click to enlarge] Create rich activity reports

Logs
The log screen allows you to view logs from any and all events. The search criteria are quite flexible -- you can search on users, groups, machines, event types and time ranges.

Reports
The reporting feature gives you a rundown, based on the report criteria. You can generate Web, chat or capture reports, which can then be exported to Excel, Word, PDF, RTF or HTML.

Introduction

|

How we tested

|

PCE

|

Verdict

Verdict

The application is simple and robust yet rich and flexible. Definitely a product of interest to any IT department.

Interoperability
	Easy to use, leverages off popular Microsoft standards. No option for opensource based implementation
Futureproofing
	Libraries will need constant updating to remain relevant.
ROI
	High cost per client, subscription is better, more flexible and more popular.
Service
	E-mail, phone, knowledgebase and forums.
Rating

(Back to top)