Collector development

implement an additional Java collector for Security Compliance Manager.

6.2.3 Collector development

A collector is a Java language-based software module, packaged as a Java Archive (JAR) file, that collects specific information from a client system. In this section, we discuss the steps of collector development using the example of the Security Compliance Manager collector for Tivoli Risk Manager. First, we discuss some of the design guidelines given in the IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595. In the next step, we demonstrate the major design tasks of collector development and discuss implementation options. Appendix A, “Developing a custom collector” on page 173 lists the complete source code of the Security Compliance Manager collector for Tivoli Risk Manager.

Collector design guidelines

ABBC’s development team has to decide on a number of design guidelines for their collector development project.

Collector releases (indicating compatible changes)

Every collector has a release number associated with it. The release number is provided in addition to the collector version number. The first release of a collector usually has a release number of 1. The collector release number increases each time the collector is modified or enhanced in a compatible way. Compatibility means that the table structure of the collector does not change. The new version number forces the Security Compliance Manager server to deploy the new collector to the Security Compliance Manager clients.

Collector versions (indicating incompatible changes)

The version number for a collector should be indicated by the name of the collector and has to be changed each time the collector is changed in an incompatible way, such as when the collector tables change. The IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 recommends that the letter V followed by a number should be added to the name of the collector. The first version of a collector is usually indicated by V1.

Collector naming conventions

The IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 recommends the following naming convention for Security Compliance Manager collectors:

operating_system.os_version.collector_nameVversion_number

This naming convention informs you about the platforms the collector is designed for and its version number. For example, the collector name

any.any.JavaVersionV1 would indicate that it is the version 1 of the collector and runs on any operating system platform of any version. The collector

aix.aix51.MyCollectorV2 will signal that it is can be run only on a single platform version. The recommended naming convention simplifies the process of

combining collectors into a policy for a specific platform.

Collector execution time

Collectors should have short execution times and be non-invasive. In general, collectors should run five seconds or less. Security Compliance Manager is designed to keep impacts on the IT systems as low as possible. Instead of performing data collection in one step influencing the IT system’s performance, the collectors can be executed at different times. Therefore, each data collector should perform only a single task within a limited time frame.

Completeness of collected data

The collector has to return data that can be interpreted by the SQL statement of the compliance object without uncertainty. If there are any errors during the data collection phase the returned data has to reflect this situation. If a collector does not return any data, the compliance object assumes that the execution of the collector failed.

Use one collector for all platforms or single platform collectors

Obviously, the answer to this question depends on the diversity of the platforms. In most cases, we recommend implementing single platform collectors if there are changes between the platforms. Implementing cross platform collectors results in:

򐂰 Cross platform collectors will be changed more often if any of the supported platforms will change.

򐂰 Differences in the platforms will result in a lengthy source code and make the collector source code less readable if you have to use multiple if-then-else statements.

򐂰 Developers of cross platform collectors need to have knowledge about all the platforms. Splitting the development among multiple developers is difficult.

򐂰 Changes in a cross platform collector requires modifications in multiple policies bundles.

The same is true for differences between different versions and flavors of a platform, for example, differences between AIX V4.3 and AIX 5L™ V5.1 or between Windows NT and Windows 2000. To cover this design option, IBM provides collector naming conventions in the IBM Tivoli Security Compliance Manager Version 5.1 Collector Development Guide, SC32-1595 that tell you on which platforms the collector is able to run. Additionally, during execution, the collectors return a list of supported operating systems.

Collector design phase

During the collector design phase, the development team has to answer the following questions, which describe the major design options:

򐂰 Which platforms must be supported by the collector?

򐂰 What kind of data has to be gathered by the collector in order to implement the policy?

򐂰 How can a collector access that data on a given platform?

Platform coverage

The development team inspects ABBC’s Risk Manager infrastructure. They discover that the Tivoli Risk Manager Agent is installed on the platforms AIX, Sun Solaris, Linux, Windows NT, Windows 2000, and Windows 2003. The Tivoli Risk Manager collector has to run on all these platforms.

Data collection

In “Tivoli Risk Manager monitoring” on page 151, we define that the Tivoli Risk Manager policy has to verify if Tivoli Risk Manager is installed on a given system, if the Risk Manager Agent is running, and if the correct filterset is in use. In order to fulfill this task, the Risk Manager collector has to collect the following data:

򐂰 Data indicating that the Tivoli Risk Manager agent is installed

The Microsoft Windows platforms have a feature called the

registry

, which contains

registry keys

and their values. The Tivoli Risk Manager program builds registry keys in a specific hierarchy. If, for example, the registry key RMHOME exists in Risk Manager’s registry hierarchy, as depicted in

Figure 6-28, it indicates that the Tivoli Risk Manager agent is installed. If the registry key is not there, the software is definitely not installed.

Figure 6-28 Registry key for Tivoli Risk Manager’s home directory

Alternatively, the collector may verify if the environment variable RMHOME is set on the system. To check if Risk Manager is installed on a UNIX machine, we have to analyze the shell script file rma_eif_env.sh, which can be found at a known and defined path. This script sets variables, for example, the RMHOME value. Therefore, we check if this file exists as an indication that Tivoli Risk Manager is installed.

򐂰 Data indicating that the Tivoli Risk Manager agent is running

Under Windows, Risk Manager is running as a service. The Risk Manager service always has the name "Risk Manager Agent". So you can check through if the service is started or not, as indicated in Figure 6-29 on page 155.

Figure 6-29 Service entry for Tivoli Risk Manager Agent

Alternatively, we can use the command net start, which returns a list of started processes. On UNIX, we have to use the command ps to verify if the Risk Manager Agent’s process rmagent is running.

򐂰 Data indicating that the current Risk Manager policy is in use

It is important for the security of ABBC’s environment that the Tivoli Risk Manager agents react to specific events according to ABBC’s security policy. In ABBC’s Risk Manager infrastructure, this configuration information is stored in the file filterset/ruleset/policy. Unauthorized modifications to this file may cause the Tivoli Risk Manager agents to misinterpret events and overlook attacks, so you must limit the users that can change the filterset. Collecting the complete policy of the Risk Manager Agent and verifying its correctness would be a troublesome task. A better option to implement this task is creating a hash of the filterset. A hash produces a specific number for a given object. The word 'tree', for example, may be mapped to the

hash-value 5, and the sentence "Java is nice" to the hash-value "27". The important characteristic of a hash-value is that it is unique for each object. Even if you change a period into a comma in a large file, the hash-value will change completely. Therefore, the collector can build a hash of the filterset on a system to be monitored and store this value in the Security Compliance Manager database. This value is compared to the hash of the correct policy. If they are identical, everything is okay; if they vary, we can be sure that someone manipulated the filterset.

Design decisions

Based on the alternatives listed in the previous sections, ABBC’s development team makes the following design decisions:

򐂰 The Tivoli Risk Manager policy requires data that can be stored in a single table in the Security Compliance Manager database schema jac_idata. This results in a single collector to be implemented, as each table belongs to a specific collector.

򐂰 The data to be collected is:

– Tivoli Risk Manager is installed.

The team decides to verify if the RMHOME environment variable is set on a Windows system. This option avoids accessing the registry, which

– Risk Manager runtime information.

The collector gathers runtime information using commands on Windows and UNIX systems.

– A hash of the Risk Manager’s ruleset.

򐂰 The collected data is stored in a database table using the following columns:

TYPE The column TYPE defines the type of the returned data.

VERSION If a record contains the entry “TRM” in the column TYPE, then the VERSION entry indicates if the Risk Manager Agent is installed. If a record contains the entry “MD5” in the column TYPE, then the VERSION entry contains the name of the Risk Manager rule set file.

VALUE If a record contains the entry “TRM” in the column TYPE, then the VERSION entry indicates if the Risk Manager Agent is running. If a record contains the entry “MD5” in the column TYPE, then the VERSION entry contains the hash value of the Risk Manager rule set file.

Figure 6-30 shows an example of values returned by the Tivoli Risk Manager collector.

Figure 6-30 Data returned by the Tivoli Risk Manager collector

򐂰 Due to the minimal platform differences between UNIX and Windows, the team decides to implement a single collector that covers all platforms. The advantage is to have a single Risk Manager policy that can be attached to all infrastructure systems that need a Risk Manager Agent. The name of the collector will be any.any.TivoliRiskManagerV1.

Collector implementation phase

A collector is a Java language-based software module, packaged as a Java Archive (JAR) file. The classes and methods specific to Tivoli Security

Compliance Manager collectors are provided in the client.jar file. The client.jar file is installed with the client component of Tivoli Security Compliance Manager. Any additional classes required to implement the collector have to be included in the collector’s JAR file. The collectors library environment is depicted in

Figure 6-31.

Figure 6-31 Security Compliance Manager Java collector JAR file

Collectors run in the Java Virtual Machine (JVM) of the Tivoli Security Compliance Manager client, which uses Java Version 1.3.1. Each collector instance runs in its own thread. On UNIX systems, the collectors run with root authority. On Microsoft Windows systems, the collectors run using the local system account. A collector extends the com.ibm.jac.CollectorV2 class that is implemented in the client.jar file. The collector needs to implement a set of required methods, which are called by the Security Compliance Manager client, the Security Compliance Manager server, or the Security Compliance Manager administration utilities.

During installation and registration of the collector at the Security Compliance Manager server, and for display at the administration console, the following methods are called and need to be implemented by each collector:

getReleaseNumber getReleaseNumber returns the release number of the

collector. It is used to decide if a collector needs to be replaced on a client.

getCompatibleOS getCompatibleOS returns the list of operating systems

Java libraries required by the

collector ITSCM’s client.jar

Java SDK 1.3.1 ITSCM Java collector class ITSCM Java collector (JAR file)

getDescription getDescription returns the text description of the collector. It is used to provide information about the collector in the administration console.

getParameters Returns the names of the parameters supported by the collector. It has to return an empty Vector if no

parameters are supported. If parameters are supported, the setParameters method must be implemented also.

getTables getTables returns the names and structures of the database tables that are populated by the data that the collector collects.

After a collector is deployed to a client, the following actions are performed by the client during the next client/server heartbeat:

1. The collector JAR file is stored in the collectors subdirectory of the client, if the JAR file is not already present or if the release number of the collector has increased.

2. Any additional files packaged with the collector are stored in the scripts subdirectory in a directory with the same name as the collector.

3. A new thread is created in the JVM of the client and the constructor for the collector is called. The constructor should be an empty method. The optional start method must be used to perform any initialization needed by the collector.

4. The client calls the setParameters method to provide the collector instance with its parameters.

5. The client calls the start method. This method is optional and permits the collector to perform any required initialization. The client waits for the start method call to complete.

6. The collector instance then waits until the client calls the executeV2 method. The executeV2 method is called when the collector instance is scheduled to run, and when the Run Collector or Test Collector actions are requested using the administration console. The collector then gathers its data and queues it for transmission to the server. The thread then waits again. 7. If the parameters for a collector instance are set or changed, the client calls

the setParameters method again to notify the collector instance of the change.

8. When the collector instance is being unloaded, the client calls the stop method. The stop method is optional and provides an opportunity for the collector to perform any cleanup.

Figure 6-32 on page 159 illustrates the method calls made to the collector instance from the client component.

Figure 6-32 Functions called by the Security Compliance Manager Client component The TivoliRiskManager collector to be implemented consists of one class, TivoliRiskManagerV1, which extends the class com.ibm.jac.CollectorV2. The complete source code and documentation is listed in Appendix A, “Developing a custom collector” on page 173.

Risk Manager policy

Having implemented and tested the Security Compliance Manager collectors, you can define a new policy for Tivoli Risk Manager. Using the Security

Compliance Manager administration console, go to the Policies tab and create a new policy named ABBC Risk Manager Policy. For each control, you define a Compliance Object, as shown in Figure 6-33.

Collector instance TivoliRiskManagerV1 Client component TivoliRiskManagerV1() setParameters(…) start() executeV2() stop() required methods

The SQL statements for the compliance objects are:

򐂰 ABBC TRM ACTIVE

select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where a.type = 'TRM' and a.value not like 'yes%'

򐂰 ABBC TRM INSTALLED

select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where a.type = 'TRM' and a.version not like 'yes%'

򐂰 ABBC TRM POLICY VERSION

select distinct a.cli_id from jac_data.any_tivoli_riskmgr a where (a.type = 'MD5' and a.version like '%EvMonWin_Win.xml%' and a.value <> 'DKf6/DlYTSGQAn4nMEmsmsP159M=') or

(a.type = 'MD5' and a.version like '%EvMonWin_Unknown.xml%' and a.value <> '0wzxW4dOwAdch17/5HQgYKhTRQQ=')

The hash values used in the SQL compliance objects need to be adjusted each time ABBC modifies the Tivoli Risk Manager’s ruleset.

In document IBM Tivoli Security Compliance Manager (Page 165-174)