 |
|
|
CyberSafe Centrax 2.4 CyberSafe Centrax is probably one of the most complete solutions we have looked at as part of this test, in that it includes audit policy control, Host-based IDS (with both real-time and batch policies), Network-based IDS, Network Node IDS and even basic Vulnerability Assessment. The Command Console runs on Windows NT/2000 and target agents are available for Microsoft Windows NT 3.51 and 4.0, Windows 2000, Sun Solaris 2.5.1, 2.6, 7 and 8, HP-UX 10.2 and 11.0, and IBM AIX 4.2.1 and 4.3.2. Centrax comprises a central Command Console which controls a number of Target Agents. The Command Console is used to define security policy and control the remote Target Agents, as well as to monitor and respond to real-time alerts raised by the Agents. The Console also controls vulnerability assessments of the Targets, how often log files are collected, and how frequently reports are run. The Command Console consists of three parts: the GUI, the collection engine, and the detection engine.� The graphical user interface is used to manage all aspects of the Command Console and to communicate with the clients.� The collection engine receives all files from the target agents and forwards them to the detection engine.� The detection engine analyses the audit data, populates the database and archives off the original audit data Target Agents are the “business-end” of Centrax, the bits that do the actual monitoring and alerting. Where Centrax scores is in its provision of a wide range of Target Agents, including both host-based and network-based, and when Agents are first installed they become immediately active with a default security policy. Audit data is reduced based on pattern matches of detected activity signatures and then stored in a database for later analysis and reporting. There are two types of host-based Agents – Batch-Mode and Real-Time. Batch-Mode Agents collect data and store it at the target host for periodic collection by the Command Console, and parsing of the data is not performed until it is has been collected from the target. Real-Time Agents, on the other hand, perform the same host-based functions but report anomalies and alerts back to the Command Console immediately. This arrangement provides a much more scalable solution than many Host-IDS systems. For instance, many host-based systems are typically reactive, in that they store data to be analysed at a later date, by which time it may be too late to do anything about it. However, if you want to do everything in real time, you run the risk of overloading both the host itself and the subnet on which it resides. Centrax provides the perfect balance. Both Batch-Mode and Real-Time Agents can use identical policies, allowing them to monitor the same events. However, by splitting the functionality, it is possible to have a small, manageable policy for real-time alerting – monitoring only the most critical events – and a much larger Batch-Mode policy that can collect all the data necessary for forensic investigation at a later date. There are also two types of network targets – Network and Network Node which broadly follow the functionality description from the Introduction. Network Agents work in promiscuous mode, monitoring all traffic on a particular network segment (and generally require a dedicated machine on which to run), whilst Network Node Agents monitor traffic specific to a particular server or workstation as it arrives at that host’s network card. Both network Agents send alerts directly back to the Command Console for processing. Centrax uses TCP/IP to communicate between the Command Console and Target Agents. All transmissions of audit policies, collection policies and counter-measure responses between the Console and Agents are encrypted using DES or Triple-DES. Installation of Centrax is remarkably easy. Starting off with the Command Console, it is the usual “put in the CD and go” type of Windows installation. After that it gets quite clever. From the Command Console GUI the administrator can create “Target installations” on the Console machine, which can then be shared via Windows Explorer. All that is then required to install the Target Agents is to access the share from the target host and run the SETUP program. Unix installations are performed in a similar way, usually by copying the install directory created at the console to the target and running setup.sh. Of course, it is also possible to use the installation CD to install remote detectors too, but the share method is a nice idea. It would be even nicer if it was possible to push the Agent installation from the Console to the remote hosts, which would offer a much more scalable approach to deployment in large, distributed networks. Apparently, CyberSafe is working on such an approach for the next release, whilst in the mean time the product is integrated with Microsoft’s SMS to assist in distribution. When running SETUP at the remote host, choices are offered as to which Agent (or Agents) is to be installed – Batch, Real-Time or Network. Installing Real-Time also forces an install of the Batch Agent, since that is used to perform the actual event collection. Installation of the Network Agent forces an install of all three components, since the Real-Time Agent is used by the Network Agent for alerting purposes. The same Network Agent is used for Network and Network Node operation, and the choice of which mode is employed is determined from the Command Console. We installed on a Windows 2000 platform, so didn’t even need to reboot once we had finished – very impressive. The Command Console provides the interface to communicate with the remote target agents, the detection engine and a view into the database.�� The GUI provides editors to define the different policies available to Centrax.� These different policies define the both how host operating system will gather information and how Centrax will migrate and process that information. To the uninitiated, Centrax can appear complicated thanks to the bewildering array of policies that it is possible – and necessary – to define. The Console GUI provides three panes when started. The top window is the Alert Manager, which is used to display all batch, real-time, network and network node alerts. Columns for each alert display the Priority, Alert Type, User or Source IP Address, Activity ID, Date, Description and Details of the alert. Alert filters can be defined in order to reduce the amount of information displayed in this window if required.
Double-clicking an alert message brings up additional information which is limited to a brief description of the problem and three possible solutions, labelled Critical, Concerned and Cautious. These often turn out to offer almost the same advice for each category, and in many cases are not as helpful as they might be. For instance, when bringing up the extra information window for one particular type of DoS attack, all the advice it could offer was “watch out for excessive ACK packets” – no explanation of what they signify or how to avoid them. The bottom window is the Target Manager, split into two panes and showing which machines are being monitored and their current configuration. The left hand pane is a hierarchical tree view of the Target Agents sorted by operating system, domain/workgroup and machine name. Targets can be grouped together logically using this window, and check boxes at each level of the tree allow the administrator to quickly and easily focus on groups of machines or individuals, which are then displayed as a list in the right hand pane. This list shows each target, along with the policies that have been applied, the date and time of the last event processed, and the current assessment status. It is the number of possible policies that can be confusing to the uninitiated. The first, and possibly most important, is the Audit Policy. Audit Policies define which user and system activities are recorded in the security event log. The great thing about Centrax is that it provides the only sensible means for managing audit policies across an enterprise-wide network. In the NT world, for example, you can imagine the amount of work involved in specifying, applying and maintaining audit policies across every machine in the company. NT simply does not provide any centralised means of doing this, and so the administrator is faced with the task of accessing each and every machine individually in order to apply the appropriate audit parameters. The potential for error when trying to apply a single policy across an organisation is very real. Centrax allows one or more audit policies to be defined in the Command Console and then applied in a single stroke across the entire organisation, or across groups of machines as defined in the Target Manager. Audit Policies can be defined for AIX, HP-UX, NT and Solaris, and a number of sample policies are provided covering Administrative Activity, File Browsing, Computer Access, Hacking Attempts, and so on. When creating audit policies, the policy definition screens are identical in look and feel to the native NT audit dialogues – covering auditable events (logon/logoff, file and object access, security policy changes, etc), individual file auditing, and registry key auditing, thus making them easy to get to grips with. Naturally, slightly different settings are available for the Unix environments. In the NT world, the NT security event log is used to store audited events, whereas in the Unix world, the usual insecure syslog mechanism is replaced by a secure binary C2 audit trail. Policies can also be merged, making it easy to group sets of audit requirements together into a single policy.
Closely related to the Audit Policy is the Detection Policy. This policy defines rules by which the Detection Engine will scan the raw audit trails in order to determine what constitutes an alert. It is important to note the distinction between Audit and Detection policies in terms of the information they process. In an extreme case, for instance, an administrator could ask the OS to audit absolutely every event, thus creating a complete (and incredibly cumbersome) audit trail for forensic purposes. The Detection engine then filters and reduces that audit trail to individual attack or misuse alerts as defined in the Detection Policy. The advantage of this approach is that should an alert be raised, it is possible for the administrator to dig deeper into the full audit trail in order to provide more information about the attack. This makes Centrax a good tool for forensic examinations. Once again, a number of sample detection policies are available for each OS platform, and these are split into Batch and Real-Time policies. This is another advantage of Centrax, since although the same options are available for the two types of policy, it is possible to specify a comprehensive detection policy to run in batch mode - thus reducing the load on the target host and on the network - whilst ensuring that a smaller subset of critical events are reported in real time. Note that it is possible for each Target Agent to have either a Batch policy or a Real-Time policy applied to it, or both – or even neither of them, if required. A huge number of pre-defined activities (over 800) are available for each type of detection policy (i.e. to monitor access to individual files, to monitor failed logon attempts, to monitor administrative access, and so on), and it is possible to define your own custom events, though this entails editing of cryptic text files. The procedure is well documented, but it would be nice to see a GUI custom event editor added to the package. Against each event is a set of Activity Signature Properties, classifying the event as High, Medium or Low priority, and determining the system response should that event be detected. Built-in responses are limited to logging off the user, logging off and disabling the account, and running a TripWire scan (if TripWire is installed on the target host) to check that no files have been altered. Custom responses can be created if required – perhaps running a script to trigger a batch run of an anti-virus scanner. It is also possible to specify a notification option, choosing from e-mail, pager or SNMP trap. A group of activity events can be selected and saved as part of a custom-designed detection policy, or one of the pre-defined sample policies can be selected and applied. It is worth noting that in order for the Detection Engine to do its work, it needs the raw security events to be logged initially, and this means the audit policy has to ensure the correct events are logged. Since not all administrators are familiar enough with the auditing process to make sure this happens, the usual approach would be to “audit everything” just to be on the safe side. For this reason, CyberSafe has introduced a special audit policy called AuditPilot. AuditPilot works backwards from the detection policy and automatically creates the correct audit policy to provide all the necessary raw audit events. This completely removes the burden of defining effective audit policies from the shoulders of the administrator. Of course, Centrax is a Network IDS as well as a Host IDS, so there are Network detection policies too, which can be applied to all Target hosts with the Network Agent installed. The events in here cover the more typical NIDS territory such as alerts for certain DoS attacks, FTP password grabbing, Web phf attacks, CGI scans, BackOrifice scans, and so on. Though the common ones are covered, Centrax has a much more limited attack signature database than the more specialised NIDS. New signatures cannot be added by the administrator, the only modification possible to a Network policy being the ability to enable or disable each signature check. Once again, it is possible to select a subset of the available signatures and create new custom policies, and individual or groups of signatures can be restricted to certain address ranges (perhaps you are not interested in checking for CGI scans from your internal network, for example). An additional response has also been added to network policies – the ability to tear down a connection. Target Agents can be designated as Network or Network Node agents. The same Agent is used for each operation, and the distinction is made from the Command Console. It is recommended that promiscuous-mode Network Agents are on a dedicated host, for performance reasons. The final policy is the Collection Policy. As its name implies, the Collection Policy defines how data from the Target Agents is retrieved by the Collection Service. In reality each Target Agent sends its data in a push type manner, which is generated from either a request from the Command Console GUI or from the Collection Policy.� The Target Agent communicates with the Collection Service through a 56 bit DES or 168 bit Triple-DES encrypted channel. The secret key is generated when the Command Console is first installed, and that key is pushed out to the Target Agent when it is installed. The Collection Service receives files from the Target Agent and stores them in the Collection directory, where they are processed by the Detection Engine with respect to the Detection Policy, looking for suspicious activity. As well as the Detection policies, Centrax also includes some basic security assessment capabilities, providing an indication of where your security policies need tightening up.
For instance, you are rated as Poor, Fair or Good in a number of categories (posture, login configuration, drive configuration, passwords, screen savers, accounts and system configuration) depending on such things as how long your default passwords are, whether you have a guest account enabled, whether you have renamed your administrator account, whether you allow all users to access the NT system directory, and so on. Security Assessments can be scheduled for regular runs, allowing administrators to keep on top of new and existing machines and monitor how their security posture changes over time. In addition to a simple on-screen “traffic light” display (red for poor, yellow for fair, and green for good) of security assessments, it is possible to run detailed reports against individual hosts which provide extensive information on the vulnerabilities found and how to fix them. An Enterprise Assessment Report pulls together a summary of all machines that have had assessments run against them. It should be remembered that this is a fairly basic assessment tool, and not in the same league as more specialised offerings from ISS and NAI. It concentrates more on operating system settings relating to security posture rather than the more extensive “hacker in a box” approach. However, the inclusion of such functionality in an intrusion detection package should be seen as a definite bonus, and the simplicity this feature will certainly mean it will be used regularly, helping to enforce security policy across an organisation. Once the Command Console has been started, it will automatically display all host machines that have a Target Agent installed, each of which will have a default detection policy applied and running automatically at install time. By right-clicking individual Targets or groups of Targets it is possible to apply Audit, Detection and Collection policies to each target as required. Policies are selected from a drop-down menu of available policies which have been previously defined, and it is also possible to select no policy if required. Once policies have been applied in this way, real-time alerts will appear in the Alert Manager window as soon as they are detected. Alerts extracted from the Batch detection policies are displayed in the Alert Manager window when they are collected by the Collection Service at intervals defined by the Collection Policy. It is also possible to force an immediate collection from one or more Target Agents, as well as trigger an immediate assessment. One nice feature – of the utmost importance in large-scale enterprise-wide deployments – is that whenever a source policy is amended in the Command Console, Centrax will examine all Target Agents to see which ones have that policy applied. It will then provide the option to have the new policy applied automatically to all the appropriate Targets – if only all IDS worked that way. The Scheduler service provides the means for the administrator to force a number of events to be run at regular intervals:
For each type of event, it is possible to restrict the scheduled operation to a single Target, a group of Targets or apply the event to all Targets. Bearing in mind the volume of information that can be collected by Centrax, it is important to be able to filter and report on this in an intelligent manner. The ubiquitous Crystal Reports provides the reporting engine. A number of predefined reports are available, and these can be filtered by Target Agent or by individual users, and run for a specific data range. An “Advanced” tab provides a list of all available attack signatures and events, allowing the administrator to home in on particular type of suspicious activity. Output can be to the screen, printer or disk file, and disk file output can be in a range of formats, including plain text, Microsoft Word or HTML. The latter option would allow reports scheduled overnight to be published directly to an internal Web site for access by a number of users if required. Once all the report parameters have been selected, they can be saved as a report template, which can then be run from a drop-down menu of available reports in the main Command Consol GUI.
Completed report templates can be run regularly by adding them to the Scheduler service, and a number of data management tools are provided for housekeeping and archiving of data. At first sight, Centrax can appear to be complex product with a less-than-intuitive interface. However, it is worth getting to grips with that complexity for the power it offers the administrator in providing Intrusion Detection cover for the largest organisation. In fact, one of the nicest features is the fact that once the various policies have been defined, the Collection and Scheduler services will automate most of the day to day tasks, providing a system that virtually runs itself – Centrax refers to this as “hands-free IDS”. Its most powerful features are clearly in the areas of Host IDS and audit policy management across an enterprise, and with the latter feature Centrax has a unique and valuable advantage over its competitors. The ability to create and deploy audit, IDS and Vulnerability Assessment policies across a corporate network from a single, central location is incredibly useful. This centralised management, plus a combined real-time and “store and forward” architecture for host-based alerts, also makes it very scalable. It is less strong in the area of Network IDS, where it currently offers a fairly limited range of signatures, and the Vulnerability Assessment capability is best thought of as a “bonus”. In its present incarnation, you would certainly not purchase Centrax solely as a Network IDS product – although this feature is improving quickly with each new release, it still has some way to go. On the other hand, take a look at the top Network IDS products – how many of those include Host IDS and Vulnerability Assessment products out of the box? They are usually provided as completely separate offerings. If your main concern is to protect your network from the infamous “70 per cent of attacks which are internal” that is regularly reported by the FBI, then Centrax is a powerful and flexible product, with advanced Host IDS and Audit Policy management capabilities. Company name:
CyberSafe Corporation Address: European Office: For additional contact details, see the CyberSafe Web site at http://www.cybersafe.com/company/contact.html� Click here
to return to the CyberSafe Centrax Results
|
 |
Send mail to webmaster
with questions or�
|
