|
|
To print: Select File and then Print from your browser's menu
-------------------------------------------------------------- This story was printed from ZDNet Australia. --------------------------------------------------------------
|
Policy Central Enterprise By James Bannan, ZDNet Australia September 22, 2006 URL: http://www.zdnet.com.au/reviews/software/productivity/soa/Policy-Central-Enterprise/0,139023447,339271126,00.htm
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 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.
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.
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.
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.
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.
Summary Desktop 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.
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
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 e-mail Group Settings General 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
Logs Reports
Verdict Policy Central Enterprise offers a wide variety of options to control and monitor your users' activities. Most businesses these days run some sort of management software on each system, such as Microsoft SMS or Novell ZENWorks, but PCE fills a real gap in a niche market. Management systems tend to focus on the system rather than the user and depending on your business and what sort of controls you wish to achieve, it's becoming increasingly necessary to be able to maintain an administrative presence at such a basic level.The application is simple and robust yet rich and flexible. Definitely a product of interest to any IT department.
Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved. |
|
