Tivoli Security Compliance Manager

Transcription

1 Tioli Security Compliance Manager Version 5.1 Collector Deelopment Guide SC

2

3 Tioli Security Compliance Manager Version 5.1 Collector Deelopment Guide SC

4 Note Before using this information and the product it supports, read the information in Appendix E, Notices, on page 69. First Edition (May 2004) This edition applies to ersion 5, release 1, modification 0 of IBM Tioli Security Compliance Manager (product number 5724-F82) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation All rights resered. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Preface Who should read this book What this book contains Publications i IBM Tioli Security Compliance Manager library i Related publications i Accessing publications online ii Accessibility ii Tioli technical training ii Contacting software support ii Conentions used in this book ii Typeface conentions iii Operating system differences iii Chapter 1. Data collection oeriew Collectors Life cycle of a collector Collector installation Indiidual collector installation Collector installation from a policy Collector authorization Collector registration Collector deployment Collector execution Collector instance remoal Collector unregistration Collector deletion Chapter 2. Writing collectors Collector execution enironment Collector design guidelines Collector naming conention Collector release number Collector table naming conention Collector table column naming conentions Column data types Classes Required methods Optional methods Utility methods Operating systems Sample collectors Collector testing considerations Chapter 3. Building collectors Compiling a collector Packaging a collector as a JAR file Packaging other files with a collector Updating a collector Chapter 4. Securing collectors Permitting unsigned collectors to be installed Creating a proider signature Signing a collector JAR file Copyright IBM Corp iii

6 Permitting signed collectors to be installed Appendix A. Method reference com.ibm.jac.collectorv2 constructor executev gettables errormessage getcompatibleos getdescription getparameters getparametervalues getreleasenumber start stop com.ibm.jac.collectorv2.collectortable constructor addcolumn getcolumns com.ibm.jac.collectorv2.collectortable.column constructor getconstraints getname getsize gettype com.ibm.jac.message constructor Appendix B. UserJreInfo.jaa Appendix C. UserGroups.jaa Appendix D. UserNdd.jaa Appendix E. Notices Trademarks Index i IBM Tioli Security Compliance Manager: Collector Deelopment Guide

7 Preface Who should read this book The IBM Tioli Security Compliance Manager Collector Deelopment Guide describes how to write a collector for IBM Tioli Security Compliance Manager. Tioli Security Compliance Manager is a data collection serice that gathers and stores a wide ariety of information from multiple participating systems. Information types can include any data stored on a system, such as operating system ersions, software patch leels, and security-related data. System and security administrators can use Tioli Security Compliance Manager to monitor specific data checkpoints on any gien machine (or group of machines). The target audience for this guide includes: System administrators Application specialists Security analysts IT planners Auditors What this book contains This document contains the following chapters and appendices: Chapter 1, Data collection oeriew, on page 1 This chapter proides an oeriew of Tioli Security Compliance Manager and describes how data is collected. Chapter 2, Writing collectors, on page 9 This chapter describes the classes and methods used in writing a collector. Chapter 3, Building collectors, on page 19 This chapter describes how to compile a collector and package the collector in a Jaa Archie (JAR) file. Chapter 4, Securing collectors, on page 21 This chapter describes the use of proider signatures to add a leel of security to the installation and use of collectors. Appendix A, Method reference, on page 23 This appendix describes the methods aailable to Tioli Security Compliance Manager collectors. Appendix B, UserJreInfo.jaa, on page 45 This appendix contains the Jaa source for the any.any.userjreinfo sample collector. Appendix C, UserGroups.jaa, on page 51 This appendix contains the Jaa source for the unix.any.usergroups sample collector, which illustrates storing compliance data in two collector tables by reading the contents of a configuration file on the client system. Appendix D, UserNdd.jaa, on page 59 Copyright IBM Corp. 2004

8 This appendix contains the Jaa source for the unix.multi.userndd sample collector, which illustrates using parameters and reading output from a command. Appendix E, Notices, on page 69 This appendix contains the legal notices and copyright information. Publications Read the descriptions of the IBM Tioli Security Compliance Manager library, the prerequisite publications, and the related publications to determine which publications you might find helpful. After you determine the publications you need, refer to the instructions for accessing publications online. IBM Tioli Security Compliance Manager library The publications in the IBM Tioli Security Compliance Manager library are: IBM Tioli Security Compliance Manager Installation Guide: All Components (GC ) Explains how to install and configure Tioli Security Compliance Manager software. IBM Tioli Security Compliance Manager Installation Guide: Client Component (GC ) Explains how to install and configure the Tioli Security Compliance Manager client component software. IBM Tioli Security Compliance Manager Administration Guide (SC ) Explains how to manage and configure Tioli Security Compliance Manager serices using the administration console. IBM Tioli Security Compliance Manager Collector Deelopment Guide (SC ) Explains how to design and implement custom Tioli Security Compliance Manager collectors. IBM Tioli Security Compliance Manager Warehouse Enablement Pack, Version 1.1 Implementation Guide for Tioli Data Warehouse, Version 1.2 (SC ) Explains how to integrate Tioli Security Compliance Manager with Tioli Data Warehouse. IBM Tioli Security Compliance Manager Release Notes (GI ) Proides late-breaking information, such as software limitations, workarounds, and documentation updates. Related publications This section lists publications related to the Tioli Security Compliance Manager library. The Tioli Software Library proides a ariety of Tioli publications such as white papers, datasheets, demonstrations, redbooks, and announcement letters. The Tioli Software Library is aailable on the Web at: The Tioli Software Glossary includes definitions for many of the technical terms related to Tioli software. The Tioli Software Glossary is aailable, in English only, from the Glossary link on the left side of the Tioli Software Library Web page i IBM Tioli Security Compliance Manager: Collector Deelopment Guide

9 Accessibility IBM DB2 Uniersal Database IBM DB2 Uniersal Database is required when using Tioli Security Compliance Manager. Additional information about DB2 can be found at: Accessing publications online The publications for this product are aailable online in Portable Document Format (PDF) or Hypertext Markup Language (HTML) format, or both in the Tioli software library: Tioli technical training Contacting software support To locate product publications in the library, click the Product manuals link on the left side of the library page. Then, locate and click the name of the product on the Tioli software information center page. Product publications include release notes, installation guides, user s guides, administrator s guides, and deeloper s references. Note: To ensure proper printing of PDF publications, select the Fit to page check box in the Adobe Acrobat Print window (which is aailable when you click File Print). Accessibility features help a user who has a physical disability, such as restricted mobility or limited ision, to use software products successfully. You can use assistie technologies to hear and naigate the product documentation. You also can use the keyboard instead of the mouse to operate some features of the graphical user interface. For Tioli technical training information, refer to the IBM Tioli Education Web site: Before contacting IBM Tioli Software Support with a problem, refer to the IBM Tioli Software Support site by clicking the Tioli support link at the following Web site: If you need additional help, contact software support by using the methods described in the IBM Software Support Guide at the following Web site: The guide proides the following information: Conentions used in this book Registration and eligibility requirements for receiing support Telephone numbers, depending on the country in which you are located A list of information you should gather before contacting customer support This reference uses seeral conentions for special terms and actions and for operating system-dependent commands and paths. Preface ii

10 Typeface conentions The following typeface conentions are used in this reference: Bold Italic Monospace Lowercase commands or mixed case commands that are difficult to distinguish from surrounding text, keywords, parameters, options, names of Jaa classes, and objects are in bold. Variables, titles of publications, and special words or phrases that are emphasized are in italic. Code examples, command lines, screen output, file and directory names that are difficult to distinguish from surrounding text, system messages, text that the user must type, and alues for arguments or command options are in monospace. Operating system differences This book uses the UNIX conention for specifying enironment ariables and for directory notation. When using the Windows command line, replace $ariable with %ariable% for enironment ariables and replace each forward slash (/) with a backslash (\) in directory paths. If you are using the bash shell on a Windows system, you can use the UNIX conentions. iii IBM Tioli Security Compliance Manager: Collector Deelopment Guide

11 Chapter 1. Data collection oeriew IBM Tioli Security Compliance Manager is a policy-drien data collection and security compliance product. Tioli Security Compliance Manager is used in two stages: Run collector software to gather specific information from the managed systems and store this information in a database. Write Structured Query Language (SQL) queries to extract the data and produce reports that reeal system ulnerabilities and iolations of defined security policies. In the first stage, as a data collection serice, Tioli Security Compliance Manager gathers information from multiple computer systems using collectors. A collector is a software module that runs on a client system and collects specific data, usually on an assigned schedule. This information can include any data located on the system, such as operating system ersion information, file and directory information, application information, and other security-related data. After the data has been collected, the client sends the data to the serer. The serer stores the data in one or more database tables. In the second stage, as a monitoring and reporting serice, Tioli Security Compliance Manager can extract the data collected, analyze the data for ulnerabilities, and produce reports that can reeal adherence to internal and industry-standard security policies. A graphical representation of the relationship between the serer, the clients, the collectors, and the database is shown in Figure 1 on page 2. Copyright IBM Corp

12 Figure 1. Tioli Security Compliance Manager architecture Collectors A collector is a Jaa language-based software module, packaged as a Jaa Archie (JAR) file, that collects specific information from a client system. A collector is designed to be short-lied and non-inasie. The collector might collect data by: reading the content of one or more files on the client system running an operating system command or utility and examining the output running an executable program packaged as part of the collector JAR file and examining the output Aailable collectors are displayed on the Collectors page of the administration console. Different icons preceding the collector name indicate the state of the collector. 2 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

13 Icon State Life cycle of a collector Installed collector. Must be authorized and registered before being deployed to clients. Authorized collector. Must be registered before being deployed to clients. If collectors do not need to be explicitly authorized, the collector is immediately shown as authorized after being installed. Registered collector. The collector can be deployed to clients and client groups. A number of collectors are proided as part of Tioli Security Compliance Manager, either indiidually or included with the predefined policies. Updated and additional collectors and policies might be aailable on the Web. For more information, see: You can write your own collectors by using the information in this publication. A collector has the following life cycle: Installed Authorized Registered Deployed (added to one or more clients) The administration console and the administration utilities are used to change the state of a collector. The life cycle is illustrated in Figure 2 on page 4. Chapter 1. Data collection oeriew 3

14 Collector JAR file Install Collector scminstallcollector Policy bundle Import Policy scmimportpolicy Installed Uninstalled Authorize collector scmsigncollector scmsignpolicycollectors scmremoepolicy Delete collector Authorized Unauthorized Register collector scmregisterpolicycollectors Registered Deploy Collector Uninstall Collector Remoe signature Unregistered Add collector to client Add collector to client group Add policy to client group scmaddgrouppolicy Unregister collector Deployed Undeployed scmremoegrouppolicy Remoe collector Remoe policy Figure 2. Life cycle of a collector Collector installation Installing a collector results in the collector being copied to the serer, alidated, and then stored in the database. Collectors can be packaged as indiidual JAR files or as part of a policy bundle file. When packaged as indiidual JAR files, collectors are installed using: The Collectors page of the administration console The scminstallcollector command 4 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

15 When packaged as part of a policy bundle file, collectors are installed by importing the policy, using: The Policies page of the administration console The scmimportpolicy command Indiidual collector installation Indiidual collectors are installed using either the Collectors page of the administration console or the scminstallcollector command. During the installation process, the JAR file containing the collector is checked to ensure that the file contains exactly one collector. The signatures on the JAR file are compared with the proider signatures on the serer to ensure that the proper number of signatures, from the proper signers, are present in the file. If these alidation checks are successful, the contents of the JAR file are copied to an internal database table and the collector is displayed on the Collector page of the administration console. By default, the serer requires that all collectors be signed by IBM before they can be installed. You can modify this behaior to permit the installation of your own collectors, as described in Chapter 4, Securing collectors, on page 21. The collector is marked as authorized if the serer does not require any authorization signatures. Otherwise, the collector is simply marked as installed. Collector installation from a policy When a policy is imported, the signatures on the collectors in the policy are compared with the proider signatures on the serer to ensure that the proper number of signatures, from the proper signers, are present in the file. If the alidation is successful, the collector is stored to an internal database table and displayed on the Collectors page of the administration console. Collector authorization By default, the serer requires that all collectors be signed by IBM before they can be installed. You can modify this behaior to permit the installation of your own collectors, as described in Chapter 4, Securing collectors, on page 21. The collector is marked as authorized if the serer does not require any additional authorization signatures. Otherwise, the collector is simply marked as installed. Collectors are authorized, or signed, using: The Security page of the administration console The scmsigncollector command The scmsignpolicycollectors command Collectors must be signed with the proper number of authorizer signatures, from the proper signers, before the collector is marked as authorized. If no authorizer signatures are required by the serer, the collector is marked authorized immediately after the collector is installed. By default, no authorizer signatures are required, but you can modify this behaior to add an additional leel of security as described in Chapter 4, Securing collectors, on page 21. Chapter 1. Data collection oeriew 5

16 Collector registration Collector deployment Collector execution Collectors are registered using: The Collectors page of the administration console The scmregisterpolicycollectors command The scminstallcollector command with the register option. Registering a collector results in the collector tables associated with the collector being created in the database. A default schedule for the collector can be set at this time also. After a collector is registered, the collector can be added to clients and client groups directly, or by using a policy. A collector is deployed when it is added to a client. A collector can be deployed by: Adding a collector to a client Adding a collector to a client group containing one or more clients Adding a policy containing the collector to a client group containing one or more clients using either the administration console or the scmaddgrouppolicy command Deploying a collector to a client in any of these ways results in a copy of the JAR file that contains the collector to be sent to the client system. The schedule and any parameters associated with the collector instance are sent to the client as well. Multiple instances of a collector can be deployed to a client. Each subsequent time the same collector is deployed to the client, a new collector instance is created with its own schedule and parameters. The collector JAR file, howeer, is not sent again because the collector is already aailable on the client system. Each collector instance runs in its own thread under the Jaa Virtual Machine (JVM) of the client component. A collector instance runs on its defined schedule, or when a Run Collector or Test Collector request is sent from the administration console. When the collector instance runs, the collector collects the requested data and queues a message to the client component. The client then returns the collected data. When the collector instance runs on its defined schedule or as a result of a Run Collector request, the data is returned to the serer and stored in one or more collector tables associated with the collector. The data in the collector tables is identified by the unique client identifier, CLI_ID, and the collector instance identifier, INSTANCE_ID. Only the most recent data from a specific collector instance is kept in the collector tables. When the collector instance runs as a result of a Test Collector request, the data is not stored in the collector tables; the data is displayed only in the administration console. 6 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

17 Collector instance remoal Collector unregistration Collector deletion Remoing a collector from a client or a client group, or remoing a policy containing the collector from a client group, results in the collector instance being remoed. Howeer, the collector JAR file remains on the client system. Future deployments of the same collector reuse the collector JAR file. Any data collected by the collector instance is remoed from the collector tables in the database and is no longer aailable for iewing or report generation. Unregistering a collector remoes the collector tables associated with the collector from the database. All data collected by all collector instances is deleted and is no longer aailable for iewing. Deleting a collector remoes the collector JAR file from the database. To make a collector aailable again, either the indiidual collector must be installed or a policy containing the collector must be imported. Chapter 1. Data collection oeriew 7

18 8 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

19 Chapter 2. Writing collectors A collector is a Jaa language-based software module, packaged as a Jaa Archie (JAR) file, that collects specific information from a client system. A collector extends the com.ibm.jac.collectorv2 class and implements the set of required methods listed in Required methods on page 14. The classes and methods specific to Tioli Security Compliance Manager collectors are proided in the client.jar file. The client.jar file is installed with the client component of Tioli Security Compliance Manager and is located in the following default locations: UNIX Windows $SCM_HOME/jars/client.jar %SCM_HOME%\jars\client.jar Attention: Only use the Tioli Security Compliance Manager classes and methods described in this publication. The use of undocumented classes and methods is not supported and might cause unexpected results, including the loss of data. Collector execution enironment Collectors run in the Jaa Virtual Machine (JVM) of the Tioli Security Compliance Manager client, which uses Jaa ersion 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. After a collector is deployed to a client, the following actions are performed by the client during the next client/serer 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. The default directory locations are: UNIX $SCM_HOME/client/collectors/collector_name.jar Windows %SCM_HOME%\client\collectors\collector_name.jar 2. Any additional files packaged with the collector are stored in the scripts subdirectory in a directory with the same name as the collector. The default locations are: UNIX $SCM_HOME/client/scripts/collector_name/file_name Windows %SCM_HOME%\client\scrupts\collector_name\file_name 3. A new thread is created in the JVM of the client and the constructor for the collector is called. 4. The client calls the setparameters method to proide the collector instance with its parameters. 5. The client calls the start method. This method 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 Copyright IBM Corp

20 the administration console. The collector then gathers its data and queues it for transmission to the serer. 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 to permit the collector to perform any necessary cleanup. Figure 3 illustrates the method calls made to the collector instance from the client component. Collector instance Client component constructor setparameters(...) start( ) executev2( ) stop( ) Collector design guidelines Figure 3. Method calls on a collector instance from the client component A Soft Reset Request sent from the administration console causes the client to resynchronize with the serer and results in the same processing as when a collector is deployed to a client. A Hard Reset Request sent from the administration console causes the client component itself to stop and then restart. This action results in the stop method of all the collector instances to be called and the collector instances are unloaded. During the restart of the client component, the collector instances are instantiated and processing is as described preiously. Collectors should adhere to the following design principles: Collectors should be named as described in Collector naming conention on page 11. Collectors should hae a release number that increases each time that the collector is changed, as described in Collector release number on page 12. Collector tables should be named as described in Collector table naming conention on page IBM Tioli Security Compliance Manager: Collector Deelopment Guide

21 Collector naming conention Columns in a collector table should be named as described in Collector table column naming conentions on page 12. Collectors must implement the required methods listed in Required methods on page 14. Collectors should hae short execution times and be non-inasie. In general, collectors should run fie seconds or less. Data collected by a collector should be returned as a single row of data for each item and not as a comma separated list of items. Use multiple collector tables if a list of data items is required. Collectors should use system enironment ariables, such as %SYSTEMROOT% or $SCM_HOME instead of specific drie letters or partition names. If a collector needs to run in a Jaa enironment that is different from the one proided by the client component, the collector must spawn a separate thread and instantiate its own Jaa Virtual Machine (JVM). Collectors are named using the following conention: operating_system.os_ersion.collector_nameversion_number Operating system designations include: aix any hpux linux solaris unix win IBM AIX systems Any supported operating system HP-UX systems Red Hat Linux and SUSE LINUX systems Sun Solaris Operating Enironment systems UNIX systems (AIX, HP-UX, Linux, and Solaris) Microsoft Windows systems The operating system ersion designations include: any multi nt Any supported ersion of the operating system. Multiple ersions of the operating system. Microsoft Windows NT systems only. Additional operating system ersion designations could include specific ersion numbers, for example: aix51 solaris8 win2k The ersion number for the collector is indicated by the letter V followed by a number. The first ersion of a collector is usually indicated by V1. The ersion number is increased each time the collector is changed in an incompatible way, such as when the collector tables change. Some examples of collector names are: aix.any.bshqueuev1 any.any.jreinfov1 hpux.any.umaskv1 linux.any.logindefsv1 Chapter 2. Writing collectors 11

22 solaris.any.etcdefaultv1 unix.any.crontabv1 unix.multi.securettyv1 win.any.nav1 win.nt.auditpolicyv1 win.multi.auditpolicyv1 Collector release number Eery collector has a release number associated with it. The release number is proided in addition to the collector ersion number that is used in the name of the collector and the names of any collector tables associated with the collector. 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. The Tioli Security Compliance Manager serer treats a collector with a larger release number as an updated, or more recent, collector and permits the collector to be deployed. If a collector has a smaller release number than the collector currently in use, the collector cannot be deployed until the current collector is unregistered and uninstalled. If an incompatible change is made to a collector, such as changing the structure of the collector tables or changing the behaior of a collector significantly, either the collector and its tables should be renamed with a later ersion number, or the current collector needs to be unregistered and uninstalled before the newer ersion is deployed. See Updating a collector on page 20 for information on updating collectors. Collector table naming conention Each collector defines one or more collector tables. These collector tables are used to store the compliance data collected by the collector. The names of the collector tables should be related to the collector name to proide an easy means of identification. The collector table name should reflect the type of data that the table contains. Collector table names can be up to 30 characters in length, must start with a capital alphabetic character, and consist only of capital letters, numbers, and underscore characters (_). The name of the collector table should end with the ersion number of the collector. For example, a collector called win.any.browsersv3 might hae a collector table called WIN_BROWSERS_V3 associated with it. The name of the collector and the names of the associated collector tables, must be changed when the structure of the collector tables is changed. Each new ersion of a collector should use a different set of collector tables. This ensures that each ersion of the collector uses the correct collector tables and permits different ersions of a collector to be deployed and coexist with each other when running. Collector table column naming conentions A collector table consists of one or more columns of compliance data. Column names can be up to 30 characters in length, must start with a capital alphabetic character, and consist of only capital letters, numbers, and underscore characters (_). 12 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

23 Column data types The following column names are resered and cannot be used: CLI_ID INSTANCE_ID LOGDATE HOSTNAME Each column in a collector table contains data that can be mapped from a Jaa data type to a DB2 data type. The length of a column must be sufficient to store the largest data item that could be collected. Otherwise, the collected data might be truncated. The total length of all the columns cannot exceed 3975 bytes. Table 1 summarizes the mappings of Jaa data types to DB2 data types in DB2 Uniersal Database for Linux, UNIX, and Windows systems. When more than one Jaa data type is listed, the first data type is the recommended data type. Table 1. Mappings of Jaa data types to DB2 data types for updating DB2 tables short, boolean 1, byte 1 int, jaa.lang.integer long, jaa.lang.long float, jaa.lang.float Jaa data type double, jaa.lang.double SMALLINT INTEGER BIGINT REAL DOUBLE jaa.math.bigdecimal DECIMAL(p,s) 2 jaa.lang.string CHAR(n) where n <= 254 SQL data type jaa.lang.string GRAPHIC(m) where m <= 127 jaa.lang.string VARCHAR(n) where n <= jaa.lang.string VARGRAPHIC(m) where m <= jaa.lang.string CLOB(n) 3 where n <= byte[] CHAR(n) FOR BIT DATA where n <= 254 byte[] VARCHAR(n) FOR BIT DATA where n <= byte[] BLOB(n) 3 where n <= jaa.sql.blob BLOB(n) where n <= Chapter 2. Writing collectors 13

24 Table 1. Mappings of Jaa data types to DB2 data types for updating DB2 tables (continued) jaa.sql.clob Jaa data type CLOB(n) SQL data type where n <= jaa.sql.clob DBCLOB(m) where m <= jaa.sql.date jaa.sql.time jaa.sql.timestamp jaa.io.bytearrayinputstream DATE TIME TIMESTAMP BLOB(n) where n <= jaa.io.stringreader CLOB(n) where n <= jaa.io.bytearrayinputstream CLOB(n) where n <= jaa.net.url DATALINK 4 Notes: 1. DB2 has no exact equialent for the Jaa boolean or byte data types, but the best fit is SMALLINT. For a Boolean data type, use a alue of 1 for true and a alue of 0 for false. 2. p is the decimal precision and s is the scale of the DB2 column. You should design financial applications so that jaa.math.bigdecimal columns map to DECIMAL columns. If you know the precision and scale of a DECIMAL column, updating data in the DECIMAL column with data in a jaa.math.bigdecimal ariable results in better precision and performance than using other combinations of data types. 3. This mapping is alid only if DB2 can determine the data type of the column. 4. The DATALINK data type is supported only by the DB2 JDBC Type 2 Drier for Linux, UNIX, and Windows. Classes Required methods The following classes are proided by Tioli Security Compliance Manager for collector use: com.ibm.jac.collectorv2 com.ibm.jac.collector com.ibm.jac.collectorv2.collectortable com.ibm.jac.collectorv2.collectortable.column com.ibm.jac.message Eery collector must implement the following methods: 14 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

25 Optional methods Utility methods getreleasenumber Returns the release number of the collector. getcompatibleos Returns the list of operating systems supported by the collector. getdescription Returns the text description of the collector. getparameters gettables executev2 Returns the names of the parameters supported by the collector. Returns an empty Vector if no parameters are supported. If parameters are supported, the setparameters method must be implemented also. Returns the names and structures of the database tables that are populated by the data that the collector collects. Runs the collector and returns the compliance data collected. collector_name constructor Default constructor for the collector. Note: The constructor must be an empty method. Use the optional start method to perform any initialization needed by the collector. The following method must be implemented if the collector supports parameters: setparameters Called by the client to proide the collector with the parameter alues specified for the collector instance. See Appendix A, Method reference, on page 23 for a complete description of these methods. The following methods can be implemented by the collector, if desired: start Called by the client when the collector instance is started. Proides an opportunity for the collector to perform any initialization. The client waits for this method to return. stop Called by the client when the collector instance is about to be stopped and unloaded. Proides an opportunity for the collector to perform any cleanup. See Appendix A, Method reference, on page 23 for a complete description of these methods. The following methods are aailable for use by the collector to perform arious functions: errormessage Returns an error message. getparametervalues Returns the alues for the specified parameter. CollectorTable constructor Defines the structure of a collector table. Chapter 2. Writing collectors 15

26 Operating systems CollectorTable.column constructor Defines a column in a collector table. CollectorTable.addcolumn Adds a column to a collector table. CollectorTable.getcolumns Returns all of the columns defined in a collector table. See Appendix A, Method reference, on page 23 for a complete description of these methods. A collector must return a list of operating systems where the collector can run. This list is proided using the getcompatibleos method. The alid alues to return are: AIX IBM AIX systems HP-UX Hewlett-Packard HP-UX systems LINUX Red Hat Linux and SUSE LINUX systems SUNOS Sun Solaris Operating Enironment systems Windows Microsoft Windows systems Table 2 lists the supported client operating systems and the corresponding alue to return using the getcompatibleos method. Table 2. Mapping of client operating system to getcompatibleos method alue Client operating system getcompatibleos() alue HP-UX 11.0 HP-UX HP-UX 11i IBM AIX 5.1 AIX IBM AIX 5.2 Microsoft Windows NT 4.0 Serer Windows Microsoft Windows NT 4.0 Workstation Microsoft Windows 2000 Professional Microsoft Windows 2000 Serer Microsoft Windows 2000 Adanced Serer Microsoft Windows XP Professional Microsoft Windows 2003 Serer Standard Edition Microsoft Windows 2003 Serer Enterprise Edition Red Hat Enterprise Linux 2.1 LINUX Red Hat Enterprise Linux 2.1 Adanced Serer Red Hat Enterprise Linux 3.0 Adanced Serer Red Hat Enterprise Linux 3.0 for iseries Red Hat Enterprise Linux 3.0 for pseries Red Hat Enterprise Linux 3.0 for zseries Red Hat Enterprise Linux 7.2 for zseries Red Hat Linux 6.2 LINUX Red Hat Linux 7.0 Red Hat Linux 7.1 Red Hat Linux 7.2 Red Hat Linux 7.3 Red Hat Linux 8.0 Red Hat Linux IBM Tioli Security Compliance Manager: Collector Deelopment Guide

27 Table 2. Mapping of client operating system to getcompatibleos method alue (continued) Client operating system Sun Solaris Operating Enironment 2.6 Sun Solaris Operating Enironment 2.7 Sun Solaris Operating Enironment 2.8 Sun Solaris Operating Enironment 2.9 SUSE LINUX 7.0 SUSE LINUX Enterprise Serer 8 SUSE LINUX Enterprise Serer 8 for iseries SUSE LINUX Enterprise Serer 8 for pseries SUSE LINUX Enterprise Serer 8 for zseries SUNOS LINUX getcompatibleos() alue Sample collectors The Jaa source for three sample collectors is proided in the Collector SDK. The Collector SDK is packaged as both a TAR file and a ZIP file: collector_sdk.tar collector_sdk.zip These files are aailable on the Tioli Security Compliance Manager Web site: The three sample collectors proided are: any.any.userjreinfo.jaa A sample collector that runs on any supported operating system and gathers the endor and ersion of the Jaa Runtime Enironment (JRE) running on the client system from the system properties. This sample illustrates the basic structure of a collector. See Appendix B, UserJreInfo.jaa, on page 45 for a program listing. unix.any.usergroups.jaa A sample collector that runs on any supported UNIX operating system and illustrates reading the contents of a file on the client system and storing compliance data in two collector tables. See Appendix C, UserGroups.jaa, on page 51 for a program listing. unix.multi.userndd.jaa A sample collector that runs on HP-UX and Sun Solaris Operating Enironment systems and illustrates the use of parameters and the capturing of output from a command utility aailable on the client system. See Appendix D, UserNdd.jaa, on page 59 for a program listing. Collector testing considerations To erify that the collector tables are created correctly, install and register the collector. When a collector is registered, the collector tables associated with the collector are created in the database. You can erify that the tables exist and hae the proper columns using the administration console. To erify that a collector returns the appropriate data: 1. Deploy the collector to a client. 2. Using the administration console, send a Soft Reset Request to the client to cause a client/serer heartbeat to occur. Chapter 2. Writing collectors 17

28 During the client/serer heartbeat, the client synchronizes with the serer and downloads the collector JAR file along with the parameters and schedule associated with the collector instance. 3. Use Test Collector to run the collector and return the results in the administration console. Use the errormessage method to record errors during the execution of your collector. Howeer, messages written using this method are not logged until the executev2 method successfully returns to the client. Because each collector runs in a separate thread under the JVM of the client component, the typical output streams used for debugging messages, such as standard output and standard error, are not aailable. To obtain diagnostic information from your collector while it is running, you can log information to a file. 18 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

29 Chapter 3. Building collectors Compiling a collector Before a collector can be installed on a Tioli Security Compliance Manager serer, the collector must be compiled and then packaged as a Jaa Archie (JAR) file. The JAR file can contain only one collector. The collector runs in the Jaa Virtual Machine (JVM) of the client component on the client system. The JVM proided with Tioli Security Compliance Manager is at Jaa ersion The collector can be compiled using a Jaa Software Deelopment Kit (SDK) ersion or later, but the resulting class file must be compatible with Jaa ersion Note: The examples assume that the Jaa SDK is installed and that the executable files are aailable using the PATH enironment ariable. To compile a collector: 1. Locate the client.jar file. The client.jar file is installed with the client component of Tioli Security Compliance Manager and is located in the following default locations: UNIX $SCM_HOME/jars/client.jar Windows %SCM_HOME%\jars\client.jar 2. Make the client.jar file aailable to your Jaa deelopment enironment. For example, you can copy the JAR file to the directory that contains your Jaa source files. 3. Compile the collector using the Jaa compiler, jaac. For example, to compile the UserJreInfo.jaa sample proided with the Collector SDK and store the resulting class file in the any/any subdirectory: jaac -d. -classpath client.jar Packaging a collector as a JAR file To package a collector into a JAR file: UserJreInfo.jaa 1. Go to the directory containing your Jaa source files. 2. Use the jar command proided with your Jaa deelopment enironment to package the class associated with the collector into a JAR file. For example, to package the any.any.userjreinfo sample collector: jar cf any.any.userjreinfo.jar any/any/userjreinfo.class The resulting any.any.userjreinfo.jar file can be signed, if necessary, and then installed on the Tioli Security Compliance Manager serer. Copyright IBM Corp

30 Packaging other files with a collector Updating a collector To help in gathering compliance data from a client system, a collector might need to use scripts, batch files, utilities, tools, or other executable files that are not aailable on the client. These additional files can be packaged with the collector in the collector JAR file. These files and tools are made aailable after the collector has been deployed to a client. Any additional files packaged with the collector JAR file are extracted and stored in the scripts subdirectory of the client. For example, assume that a collector called win.any.plugins had both a plugin.bat and a scanplug.exe file packaged with it. When the collector is deployed to a client, the following files would be unpacked and stored on the client: %scm_home%\client\scripts\win.any.plugins\plugin.bat %scm_home%\client\scripts\win.any.plugins\scanplug.exe The collector must directly reference the additional files from the appropriate directory when the files are needed. No special classes or methods are proided for this purpose. Updating a collector inoles replacing the stored copy of the collector in the database with a new copy. After the collector has been updated in the database, each client, during the next client/serer heartbeat, detects that a new copy of the collector is aailable and updates its local copy. To update a collector, the scminstallcollector command must be used. The administration console does not support the update of a collector. A collector can be updated proided that all of the following are true: the name of the collector is the same the collector table is the same the release number of the collector is greater than the current release number the new collector has all the same proider and authorizer signatures as the current collector If any of these conditions are not met, the collector must be unregistered and uninstalled before a new copy can be installed and used. 20 IBM Tioli Security Compliance Manager: Collector Deelopment Guide

31 Chapter 4. Securing collectors The collectors proided by IBM are signed with the IBM proider signature. The collectors proided include the collectors packaged with the predefined policies as well as collectors proided as indiidual JAR files. By default, only collectors signed with the IBM proider signature can be installed on a Tioli Security Compliance Manager serer. You cannot sign collectors using the IBM proider signature because the IBM priate key is not proided. To install your own collectors, you must either permit unsigned collectors to be installed on the serer or enable the serer to accept collectors signed with a signature other than the IBM proider signature. Note: The examples assume that the Jaa SDK and JRE are installed and that the executable files are aailable using the PATH enironment ariable. Permitting unsigned collectors to be installed Attention: Only a serer in a test enironment should be changed to permit unsigned collectors to be installed. Permitting unsigned collectors in a production enironment significantly reduces the security of the compliance checking enironment. To permit unsigned collectors to be installed on a serer: 1. Open the Security page in the administration console. 2. Click the Collectors tab. 3. In the Proiders pane, clear the Accept check box for the IBM proider signature. 4. Click Apply. Creating a proider signature To create a keystore and define a proider signature to be used for signing collector JAR files: 1. Open a command session on a system with a Jaa Runtime Enironment (JRE) installed and aailable. 2. Use the keytool command proided as part of the JRE to create a keystore and an authorization key. For example, to create a proider key called CompanyKey with a password of p3ssw0rd in a file called proiderkeys.jks: keytool -genkey -alias CompanyKey -storepass p3ssword -keystore proiderkeys.jks 3. Export the signature in a format that can be used by the Tioli Security Compliance Manager serer. For example, to export the key to a file called proider.der: keytool -export -alias CompanyKey -keystore proiderkeys.jks -file proider.der -storepass p3ssw0rd 4. Copy the file containing the proider signature to a system with the administration console installed. Copyright IBM Corp

32 Signing a collector JAR file To sign a collector JAR file with a proider signature: 1. Open a command session on a system with the Jaa Software Deelopment Kit (SDK) installed and aailable. 2. Use the jarsigner command proided as part of the Jaa SDK to sign a collector JAR file. For example, to sign the unix.any.usergroups.jar file with the proider key called CompanyKey from the keystore proiderkeys.jks with a password of p3ssw0rd: jarsigner -keystore proiderkeys.jks -storepass p3ssw0rd unix.any.usergroups.jar CompanyKey Permitting signed collectors to be installed To add a new certificate to the serer keystore containing the public key of the signer and require that collectors must be signed by either that certificate or the IBM signed certificate: 1. Open the Security page in the administration console. 2. Click the Collectors tab. 3. Right-click in the Proiders pane and click Import. 4. Locate the DER or PEM file containing the certificate to be added. Click Open. 5. Specify an alias name for the certificate and click OK. 6. Mark the Accept check box to indicate that collector JAR files signed with this signature can be installed on the serer. Leae the signatures required field set to 1. This permits collectors to be signed with either the IBM certificate or the certificate that was just imported. 7. Click Apply. 22 IBM Tioli Security Compliance Manager: Collector Deelopment Guide