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.
Figure 17 - Centrax: Configuring network detection policies
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.