Administrator s Guide

Transcription

1 IBM Tioli Risk Manager Administrator s Guide Version 4.2 GC

2

3 IBM Tioli Risk Manager Administrator s Guide Version 4.2 GC

4 Note: Before using this information and the product it supports, read the information in Appendix D, Notices, on page 233. First Edition (October 2003) This edition applies to ersion 4, release 2, of Tioli Risk Manager 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 ii Who Should Read This Book ii What This Book Contains ii Publications iii IBM Tioli Risk Manager Library iii Prerequisite Publications iii Related Publications ix Accessing Publications Online ix IBM Tioli Risk Manager Product Information..x Accessibility x Contacting Software Support x Conentions Used in This Book xi Typeface Conentions xi Naming Conentions xi Operating System Differences xii Chapter 1. Introduction Tioli Risk Manager Topology and Architecture..2 Eent Sources Eent Adapters Tioli Risk Manager Clients Tioli Risk Manager Eent Serer Tioli Risk Manager Console Tioli Risk Manager Historical Reporting...12 Oeriew of Tioli Risk Manager Security Eent Processing Detect Filter and Summarize First-Leel Correlation Second-Leel Correlation Information Displayed at the Tioli Enterprise Console Console Usage Scenario Incident Eent Types Unique Combinations of Source, Destination, and Category (SrcDstCat) Unique Combinations of Source and Category (SrcCat) Unique Combinations of Destination and Category (DstCat) Unique Combinations of Source and Destination (SrcDst) Unique Value for Category (Cat) Unique Value for Source (Src) Unique Value for Destination (Dst) Chapter 2. Eent Serer Configuring Correlation Incidents and Incident Groups Tioli Risk Manager Correlation Components...40 Configuring the Eent Serer Adanced Configuration Performance Considerations Customize the BAROC List Set Eent Cache Size Filtering Attributes Set Instance Count on Agent Senders Tioli Risk Manager BAROC Files Chapter 3. Database Database Structure Tioli Enterprise Console Databases Tioli Enterprise Console Tables and Views...51 Tioli Risk Manager Tables and Views Eent Archie Table Creation Database Maintenance and Support Tioli Risk Manager Database Utilities Tioli Enterprise Console Data Management Utilities RIM Support Utilities Chapter 4. Agent Oeriew Agent Configuration Top-Leel Configuration File (rmagent.xml)..63 Queues and Eent Persistence Second-Leel Configuration Files Relationship of the Configuration Files Client System Configuration Eent Serer System Configuration Distributed Correlation Serer System Configuration Gateway System Configuration Administering the Tioli Risk Manager Agent...76 Starting and Stopping the Agent Managing the Agent Queues Managing Agent DNS Processing Creating and Managing Secure Sockets Layer Keystores Stashing Passwords Secure Sockets Layer Usage Information Setting Up JDBC Driers Chapter 5. Engine Configuration Eent Pre-Normalization Attribute Mapping DNS Look-up Eent Normalization Identifying Eent Classes Assigning Class Category Identifying Known Systems Identifying Trusted Systems Identifying Known Sensors Linking Eents Setting Timestamp Variability Allowance...86 Additional Attributes Adjustments Heartbeat Monitoring Adanced Configuration Chapter 6. Eent Summarization Copyright IBM Corp iii

6 Oeriew Identifying a Summarized Eent Out-of-the-Box Client Configuration Understanding Summarization Rules Configuring Summary Rules Updating An Existing Summary Rule Creating New Summary Rules Actiating Your Changes Sample Eent Summarization Processing Chapter 7. Incident-Based Correlation 95 Oeriew What is an incident? What is the rm_leel attribute? What is a sliding-window? What is a class category? What types of incidents are there? What eents contribute to an incident? Can an eent contribute to more than one incident? How is the seerity of an incident set? How Do I Stop a Specific Eent Class From Contributing to Incident-Based Correlation?..98 Incident-Based Correlation Processing Incident-Based Correlation XML Syntax Incident-Based Correlation Action Functions Customizing Incident-Based Correlation Rules Configuring Incident-Based Correlation Rules Updating an Existing Incident-Based Correlation Rules File Creating a New Incident-Based Correlation Rules File Actiating Changes to the Incident-Based Correlation Rules File Extending Incident-Based Correlation with Customer ID Attribute Enablement Chapter 8. Web Application Functional Oeriew Global Security and UTF Accessing the Web Application from the Tioli Enterprise Console Introduction to the Web Application Graphical User Interface Eent Details System Information Adisor Adisor Rules File Static Text Web Page URL Web Page Run Program Web Page Web Page Chapter 9. Reports What Are Tioli Risk Manager Crystal Reports? 139 Firewall Management Reports Intrusion Detection Reports Risk Assessment Reports Eent Management Reports Virus Management Reports Setting Up an ODBC Data Source Connection DB Oracle Sybase Microsoft SQL Serer Updating Crystal Reports to Use Your ODBC Connection How Do Tioli Risk Manager Crystal Reports Work? Create the Tioli Risk Manager Archie Table 147 Running Tioli Risk Manager Crystal Reports 147 Crystal Reports Runtime Engine Chapter 10. Tasks Tioli Tasks How to Create and Customize Tasks Tasks for Linux and UNIX-Based Systems Tasks for Windows Systems Tasks for the Eent Serer Tasks for the Agent Tasks for Eent Management Tasks for Check Point FireWall Tasks for Cisco Secure PIX Firewall Tasks for Cisco Secure IDS Tasks for Network IDS Chapter 11. Web Intrusion Detection 157 Supported Web Serers Perl Support Starting Web IDS Running Web IDS as a Serice on a Windows System Access Log Rolloer Support The sig.nefarious Signatures File Parser Engine Pattern Engine Suspicion Engine Trust Engine Skip Engine The Web IDS Configuration File Editing the Web IDS Configuration File Configuring Web IDS Log File Access for Rolloer Support Web Serer Specific Configuration Configuring Web Serers That Use the Common Log Format Configuring the Apache Web Serer Configuring IBM Tioli Access Manager WebSEAL Serer Configuring the Sun ONE Web Serer Configuring the Microsoft Internet Information Serer Specifying Log File Format and Values Editing Signatures Configuring Web IDS for Use with the Tioli Risk Manager EIF Configuring Web IDS for Use with the Eent Monitor Configuring the Eent Monitor to Capture Web IDS Eents i IBM Tioli Risk Manager: Administrator s Guide

7 Managing Web IDS Analyzing Web Attack Eents Adding or Remoing Signature Classes Adding or Remoing Web Attack Signatures 178 Combining and Refining Pattern Tests Adding or Remoing Suspicious Hosts Specifying the Type of Suspicious Actiity Adding or Remoing Trusted Signatures Tuning the Threshold and Decay Values Chapter 12. Network Intrusion Detection Supported Adapters Network IDS Eent Correlation Network IDS Alerts Configuring Network IDS Network IDS Tioli Risk Manager Tasks Starting the Network IDS Adapter Stopping the Network IDS Adapter Managing Network IDS Starting Network IDS Automatically with the startnids Command Updating the Signatures File Testing for Promiscuous Operation Omitting IP Addresses Obtaining the Host Name Logging Network IDS Alerts and Information Configuring Network IDS for Use with the Tioli Risk Manager EIF Configuring Network IDS for Use with the Eent Monitor Configuring the Eent Monitor to Capture Network IDS Eents The nids Command Appendix A. Eent Integration Facility Sender and Receier Keywords Keywords Appendix B. Database Archie Configuration Database Archier Keywords JDBC Classpath Settings Appendix C. Secure Socket Layer Introduction and ikeyman Secure Sockets Layer Oeriew Digital Certificates How SSL Works Tioli Risk Manager and SSL Default Keystore Files Storing SSL Passwords Planning Considerations SSL Configuration Files TrustStores Managing Digital Certificates with Keytool Managing Digital Certificates with ikeyman Starting ikeyman Creating a Key Database Creating a Self-Signed Digital Certificate for Testing Adding a CA Root Digital Certificate Deleting a CA Root Digital Certificate Copying Certificates from One Key Database to Another Requesting a Digital Certificate Receiing a Digital Certificate Deleting a Digital Certificate Changing a Key Database Password Appendix D. Notices Trademarks Glossary Index Contents

8 i IBM Tioli Risk Manager: Administrator s Guide

9 Preface Who Should Read This Book What This Book Contains This book describes how to install, configure, and manage IBM Tioli Risk Manager. This guide also proides an oeriew for each IBM Tioli Risk Manager component. You should hae prior knowledge of the Tioli Management Framework and the Tioli Enterprise Console, and of installing and using third-party intrusion-detection applications. IBM Tioli Risk Manager is an implementer of network security policies, specifically intrusion-detection systems (IDS). You need a working knowledge of network security and a solid grasp of Transmission Control Protocol/Internet Protocol (TCP/IP), fundamental networking concepts, and routed networks. See the IBM Tioli Risk Manager Release Notes for changes to the product and this guide. Chapter 1, Introduction, on page 1 proides an oeriew of the Tioli Risk Manager product and components. Chapter 2, Eent Serer, on page 39 describes Tioli Enterprise Console correlation, including correlation terms, processes, and management tasks. Chapter 3, Database, on page 51 describes how to use the Tioli Risk Manager database. Chapter 4, Agent, on page 61 describes the Tioli Risk Manager Agent. Chapter 5, Engine Configuration, on page 81 describes the arious options that can be configured in the agent s engine component. Chapter 6, Eent Summarization, on page 89 describes the purpose of eent summarization. It is used to reduce the network traffic while minimizing the loss of information. Chapter 7, Incident-Based Correlation, on page 95 describes how to configure incident-based correlation. Chapter 8, Web Application, on page 107 describes how to use the Tioli Enterprise Console to iew Tioli Risk Manager information. Chapter 9, Reports, on page 139 summarizes IBM Tioli Data Warehouse and Crystal Reports for enterprise risk management. Chapter 10, Tasks, on page 151 introduces the Tioli Risk Manager-proided Tioli Risk Manager tasks. Chapter 11, Web Intrusion Detection, on page 157 describes Web Intrusion Detection System (Web IDS), a Tioli Risk Manager-proided sensor. Chapter 12, Network Intrusion Detection, on page 183 describes the Network Intrusion Detection (Network IDS) option. Appendix A, Eent Integration Facility Sender and Receier Keywords, on page 195 proides information about keywords used to configure Agent configuration files to send and receie eents. Copyright IBM Corp ii

10 Appendix B, Database Archie Configuration, on page 205 proides reference information about keywords for database archie configuration files Appendix C, Secure Socket Layer Introduction and ikeyman, on page 209 proides SSL information and how SSL interacts with Tioli Risk Manager. This guide also contains a glossary of intrusion-detection and security-related terminology and an index. Publications This section includes the following Publication information: Tioli Risk Manager Library Prerequisite Publications Related Publications Accessing Publications Online Tioli Risk Manager Online Information Read the descriptions of the Tioli Risk 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 Risk Manager Library The publications in the Tioli Risk Manager library are: The IBM Tioli Risk Manager Administrator s Guide Version 4.2, describes how to configure, and manage Tioli Risk Manager. This guide also proides an oeriew for each Tioli Risk Manager component. The IBM Tioli Risk Manager Adapters Guide Version 4.2 proides detailed descriptions for the currently aailable IBM Tioli Risk Manager adapters. The IBM Tioli Risk Manager Command Reference Version 4.2 describes commands used to administer Tioli Risk Manager. The IBM Tioli Risk Manager Installation Guide Version 4.2 contains information on planning your product deployment, including topics such as network topology and installing prerequisite software and describes how to install and configure the Tioli Risk Manager product and components. The IBM Tioli Risk Manager Problem Determination Guide Version 4.2 contains consistent, complete, and clear problem determination processes and examples to assist in determining why Tioli Risk Manager is malfunctioning. The IBM Tioli Risk Manager Read Me First Card Version 4.2 directs you on how to access, and the intended purpose and audience of the Tioli Risk Manager documentation. The IBM Tioli Risk Manager Release Notes Version 4.2 contains last minute information on the installation and administration of the Tioli Risk Manager product. Prerequisite Publications To use the information in this book effectiely, you must hae some prerequisite knowledge, which you can obtain from the following publications: Tioli Management Framework Planning for Deployment Guide, Tioli Management Framework Enterprise Installation Guide, Tioli Management Framework User s Guide, and Tioli Management Framework Reference Manual iii IBM Tioli Risk Manager: Administrator s Guide

11 These books proide detailed information about the desktop, managed nodes, administrators, policy regions, profiles, notices, tasks, scheduling, and command-line interface (CLI) commands. IBM Tioli Enterprise Console User s Guide This guide proides detailed information about using the Tioli Enterprise Console. Related Publications Information related to Tioli Risk Manager is aailable in the following publications: IBM Tioli Enterprise Console Rule Builder s Guide This guide proides detailed information about how to write and integrate new rules. Tioli Eent Integration Facility User s Guide This guide discusses how to deelop your own eent adapters using the Eent Integration Facility (EIF). These eent adapters are tailored to your network enironment and your specific needs. IBM Tioli Enterprise Console Reference Manual This book proides details on the command-line commands. IBM Tioli Enterprise Console Adapters Guide This guide proides detailed descriptions for the currently aailable Tioli Enterprise Console adapters. Tioli Management Framework 4.1 Task Library Language Deeloper s Guide This guide proides detailed information on how to create and customize tasks. 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 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: 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). Preface ix

12 Accessibility IBM Tioli Risk Manager Product Information IBM Tioli customers can find online information for Tioli security products and for Tioli Risk Manager. Contacting Software Support Tioli Risk Manager Adapters are now aailable to customers through the Tioli Risk Manager Support Web site and are no longer included on the product CD. This allows new and improed adapters to be distributed independently from new releases of Tioli Risk Manager and allows customers to download only the adapters they require. For Tioli Risk Manager Adapters, up-to-date product updates including sensor signatures, and serice information about Tioli Risk Manager, go to: support/ibmtioliriskmanager.html For information about the Tioli Risk Manager product, go to: For information about other Tioli security management products, go to: Accessibility features help a user who has a physical disability, such as restricted mobility or limited ision, to use software products successfully. The major accessibility features in this product enable users to do the following: Use assistie technologies, such as screen-reader software and a digital speech synthesizer, to hear what is displayed on the screen. Consult the product documentation of the assistie technology for details on using those technologies with this product. Magnify what is displayed on the screen. In addition, the product documentation has been modified to include features to aid accessibility: All documentation is aailable in both HTML and conertible PDF formats to gie the maximum opportunity for users to apply screen-reader software. All images in the documentation are proided with alternatie text so that users with ision impairments can understand the contents of the images. Before contacting IBM Tioli Software support with a problem, refer to the IBM Tioli Software support Web site at: 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: 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 x IBM Tioli Risk Manager: Administrator s Guide

13 Conentions Used in This Book In this book, a Windows system is a computer system that uses the Windows NT, Windows 2000, or the Windows XP operating systems. A UNIX system is a computer system that uses a UNIX operating system such as the AIX, Linux, HP-UX, or the Solaris Operating Enironment (hereinafter referred to as Solaris) operating systems. Typeface Conentions The following typeface conentions are used in this reference: Bold Italics Lowercase commands or mixed case commands that are difficult to distinguish from surrounding text, keywords, parameters, options, and objects are in bold. Variables, titles of publications, and special words or phrases that are emphasized are in italic. Monospace 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. Naming Conentions The following naming conentions are used in this book: Linux for PowerPC Term used when you are running Linux on iseries and pseries hardware systems. RMINSTDIR The Tioli Risk Manager installation location that includes the RISKMGR subdirectory on your system. For example, on a Solaris system, the default installation directory would be /opt/riskmgr Solaris Operating Enironment Referred to as Solaris. UNIX-based Term used when referring to AIX, HP-UX, and Solaris systems. Tioli Risk Manager Agent Referred to as the agent. Tioli Risk Manager Client Referred to as the client. Tioli Risk Manager Distributed Correlation Serer Referred to as the distributed correlation serer. Tioli Risk Manager Gateway Referred to as the gateway. Tioli Risk Manager Eent Serer Referred to as the eent serer. Tioli Risk Manager Eent Monitor Referred to as the eent monitor. Tioli Enterprise Console user interface Referred to as the eent console. Preface xi

14 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. xii IBM Tioli Risk Manager: Administrator s Guide

15 Chapter 1. Introduction Today, corporations are deploying a ariety of security solutions, such as firewalls, intrusion detection systems, anti-irus software, and access control mechanisms. They use these security solutions as part of their oerall security strategy to achiee the simple objectie of letting the good guys in and keeping the bad guys out. Security policies implemented at the network leel, host leel, and application leel allow access to only authorized users, applications, and systems. Yet, businesses still face eer increasing risks from irus threats, unauthorized access, and denial of serice attacks that target the enterprise. Threats can originate internally from within the enterprise or externally from the Internet. Informal sureys suggest that almost half of the internal threats are malicious and the other half are accidental and arise from improperly configured systems or weak security policies. To effectiely guard against these different threats requires an enterprise iew of security. This coordinated approach can harness the intelligence across the different security checkpoints within the enterprise. Enterprise risk management seeks to accomplish the following broad objecties: Proide a simple, easy-to-use enterprise security console to monitor, iew, and manage security alerts across the enterprise. This approach enables companies to identify and manage threats and ulnerabilities throughout the enterprise. This ensures that access to networks, systems, applications, and desktops is consistent with enterprise security policies. Enable system administrators to precisely identify different types of threats and attacks using adanced correlation techniques, so corporations can identify patterns of intrusions, eliminate clutter, reduce false-positie alerts, and quickly identify real security threats to speed response time. Centralized correlation and management of attacks, threats, and suspicious actiity will proide a broader iew of actiity in the enterprise. This is essential because intrusion detection systems often create large numbers of alerts, and alerts produced by different intrusion detection systems (or applications) are often related to the same root cause. Patterns identified by centralized correlation often proide information that is needed to track down the actual root cause. Proide a ariety of predefined reaction tasks to quickly resole urgent security issues, such as denial of serice attacks, iruses, or unauthorized accesses. Predefined tasks include reoking user accounts on serers, reconfiguring a firewall, disabling compromised serices and managing information that is captured in the Tioli Risk Manager archie database. Integrate with multi-endor security products to proide a comprehensie security management enironment. Leerage integration with the full range of the Tioli network, system, and security management products to take long-term correctie actions and constantly improe enterprise security policies. Proide reporting of information for analysis of intrusion eents that might occur on a customer s system. Tioli Risk Manager is an open, cross-platform, standards-based enterprise management platform that enables customers to manage security intrusions and ulnerabilities across networks, hosts, operating systems, applications, serers, and desktops. Increasingly, attacks and intrusions target the enterprise as a whole, not just as a subsystem. Copyright IBM Corp

16 Customers can leerage their existing inestments in the Tioli Enterprise Console and Tioli Management Framework to seamlessly implement enterprise risk management as a subset of traditional enterprise management. Tioli Risk Manager can manage a broad range of security technologies and products that are widely deployed within the enterprise: Eents and alerts from firewalls, routers, network, and host-based intrusion detection systems, host system security, antiirus systems, and desktop security systems. Using adanced correlation techniques, Tioli Risk Manager significantly reduces clutter and repetition by aggregating and summarizing thousands of alerts, reducing false posities, and enabling system administrators to identify threats through correlation, alert aggregation, and summarization. Seere alerts (attacks, unauthorized access, suspicious actiities, and policy iolations) can be responded to with automatic tasks, such as updating firewall policies, disabling a user account or resetting hostile Transmission Control Protocol (TCP) connections. In order to position Tioli Risk Manager within a typical e-business enironment and understand the necessary infrastructure, see the IBM Tioli Risk Manager Installation Guide for planning information. Tioli Risk Manager Topology and Architecture A high-leel iew of the logical components of a Tioli Risk Manager deployment is shown in Figure 1 on page 3: 2 IBM Tioli Risk Manager: Administrator s Guide

17 Alert/Msg Sources IDS Applications OS WEB IDS NIDS SNMP Trap File Syslog FIFO Win Eent Log Database Custom Browser Eent Details Adisor System Information Logging Mechanisms Launch Tioli Enterprise Console Adapter Tioli Enterprise Console Adapter Custom Adapter Console Tioli Risk Manager Agent as Client Eent Receier Port Eent Monitor Tioli Risk Manager EIF API Summarize Transport Tioli Enterprise Console Serer Tioli Risk Manager Agent as a Correlation Serer Tioli Inentory DB WebSphere Tioli Risk Manager Serlet Eent Details System Information Adisor ETL1 TEDW Eent Repository ETL2 Tioli Risk Manager Crystal Reports Data Mart Figure 1. Logical Components of a Tioli Risk Manager Deployment The primary logical components will typically include the following: Eent Sources Eent Adapters Tioli Risk Manager Clients Tioli Risk Manager Eent Serer (Tioli Enterprise Console Eent Serer) Tioli Risk Manager Consoles Tioli Risk Manager Historical Reporting Eent Sources Tioli Risk Manager gathers possible intrusion-attempt information and other security-related alerts from a ariety of eent sources. Eent sources include intrusion detection sensors (IDS), firewalls, applications, and operating systems. These eent sources are referred to as sensors. Tioli Risk Manager proides a ariety of techniques for capturing this information, and then forwarded to a Tioli Risk Manager serer for correlation, display on a real-time console, and storage in a relational database for recording purposes. In addition to supporting a wide ariety of third-party sensors, applications, and operating systems, Tioli Risk Manager includes a set of intrusion detection sensors: Chapter 1. Introduction 3

18 Web-based Intrusion-detection Sensor Tioli Risk Manager includes the Web Intrusion Detection System (Web IDS) sensor that detects Web serer attacks and other suspicious actiity. Network-based Intrusion-detection Sensor Tioli Risk Manager includes the Network Intrusion Detection System (Network IDS) sensor that detects network-based attacks and suspicious actiity. See Chapter 11, Web Intrusion Detection, on page 157 and Chapter 12, Network Intrusion Detection, on page 183 for more information about Tioli Risk Manager sensors. Eent Adapters An eent adapter is the software component responsible for capturing releant information from an eent source, mapping it into a Tioli Risk Manager eent, and then forwarding the eent. Tioli Risk Manager supports seeral different forms of eent adapters. Custom adapters Tioli Enterprise Console adapters Tioli Risk Manager eent monitor 4 IBM Tioli Risk Manager: Administrator s Guide Custom Adapters A custom eent adapter is required when the eent source or sensor uses a non-standard mechanism for logging alerts such as a programming API specific to that sensor. A custom eent adapter is designed to interact directly with a sensor to acquire eents. Typically, custom adapters utilize a simple eent submission API proided by Tioli Risk Manager to pass sensor eents directly to the agent for formatting, summarization and transport to an eent serer. This eent submission API is the Tioli Risk Manager Eent Integration Facility and is incorporated as part of the client. Most Tioli Risk Manager custom eent adapters, such as the Tioli Risk Manager adapter for Cisco Secure IDS, proide XML files that contain the formatting information used by the eent adapter to extract information from the eent source. Custom eent adapters are installed on the same host system as the client. Tioli Enterprise Console Adapters General-purpose Tioli Enterprise Console adapters are designed to extract information from system logs (or Simple Network Management Protocol (SNMP) traps), format the information into Tioli Risk Manager eents, and then forward the eents to a local agent for summarization and transport to an eent serer. Tioli Risk Manager proides format (.fmt) or class definition statement (.cds) files that contain the formatting information used by the Tioli Enterprise Console adapter to extract information from the eent source. The.fmt or.cds files are proided for a ariety of eent sources including intrusion detection sensors, firewalls, applications, and operating systems. Tioli Enterprise Console adapters are typically installed on the same host system as the client. Tioli Management Framework (TME) Tioli Enterprise Console adapters can be used to capture information from eents sources but must forward information directly to the Tioli Enterprise Console eent serer and bypass the summarization capability within the client. Tioli Risk Manager recommends the use of non-tme Tioli Enterprise Console adapters to capture information from eent sources and forward this information to the local client for summarization and transport. For more information about specific Tioli Enterprise Console adapters, see the IBM Tioli Risk Manager Adapters Guide.

19 Tioli Risk Manager Eent Monitor The Tioli Risk Manager Eent Monitor (eent monitor) is designed to extract information from a ariety of eent sources. Then formats the information into Tioli Risk Manager eents, and forwards the eents to a local agent for summarization and transport to an eent serer. Supported eent sources include: Files Windows Eent Logs Relational database tables Named pipe queues The eent monitor utilizes XML files that contain the formatting information to extract information from the eent source. XML files are proided for a ariety of eent sources including intrusion detection sensors (IDS), firewalls, applications, and operating systems. The eent monitor is installed as an integral part of the client. Using the eent monitor for capturing and creating eents has seeral adantages as an eent adapter oer the Tioli Enterprise Console adapter including: The eent monitor is integrated with the client (and other Tioli Risk Manager roles, such as the distributed correlation serer, eent serer, and gateway) and is installed with the client. A Tioli Enterprise Console adapter is configured, managed and installed separately. The eent monitor configuration wizard will automatically configure an instance of the eent monitor to gather information from an eent source. The Tioli Enterprise Console adapter configuration requires a series of manual steps. The eent monitor configuration wizard will automatically configure the eent monitor to perform multithreaded monitoring of multiple eent sources on the same system. To set up multiple instances of a Tioli Enterprise Console adapter on Linux and UNIX-based systems requires complex installation and setup. Multiple instances of Tioli Enterprise Console adapters are not supported on Windows systems. The eent monitor using XML files used for formatting is more efficient than a Tioli Enterprise Console adapter using.fmt files when dealing with hundreds or thousands of format patterns. The eent monitor can select information from a table in a relational database. Tioli Enterprise Console adapters do not hae this capability. Seeral Tioli Risk Manager adapters use this feature. Tioli Risk Manager includes the wrmfmt2xml command to conert a pre-existing.fmt file into the XML representation used by the eent monitor. The eent monitor does not proide support for SNMP-based eent sources. The Tioli Enterprise Console adapter must be used when monitoring eent sources generating SNMP traps. Tioli Risk Manager adapters that monitor SNMP eent sources include the Tioli Risk Manager adapter for ISS RealSecure and adapter for Cisco Routers. For more information about specific Tioli Risk Manager adapters, see the IBM Tioli Risk Manager Adapters Guide. For more information on the wrmfmt2xml command, see the IBM Tioli Risk Manager Command Reference. Chapter 1. Introduction 5

20 Tioli Risk Manager Clients The client proides key capabilities and is typically deployed in conjunction with an adapter or a sensor. The features proided by the client include: The client includes the eent monitor as an integral component. The eent monitor is installed as an integral part of the client. The eent monitor is designed to extract information from a ariety of eent sources. Then formats the information into Tioli Risk Manager Tioli Enterprise Console eents, and forwards the eents to a local agent for summarization and transport to an eent serer. The client proides a ariety of transport choices for sending the eents to a Tioli Risk Manager serer. These include simple socket-based communications as well as secure communications as proided by Tioli Management Framework and Secure Socket Layer (SSL) communications. The client proides a summarization feature that aggregates duplicate or similar eents. Instead of sending potentially large floods of duplicate eents to the serer, the summarization feature forwards a relatiely small number of summarized eents. This reduces network traffic, the load on the serer, and the olume of information that is stored in the relational eent repository. The client proides message formatting facilities (using XML-based formatting files). The formatting facilities are exploited by many custom adapters and sensors (including the Cisco Secure IDS adapter, and Check Point FireWall-1 adapter). Tioli Risk Manager sensors (including Web IDS and Network IDS), and by the eent monitor. The client proides flexibility in terms of eent filtering and routing eents to multiple serers or eent destinations, including relational databases. The client proides a ery simple eent submission API for use by custom eent adapters. You can use this API to deelop your own Tioli Risk Manager-compatible adapter. See Chapter 4, Agent, on page 61 for more client information. Agent-less Mode The agent supports what is often called agent-less mode. For example, if one or more serers are reporting their security alerts to a syslog serer on a centralized system, the client can be deployed on the syslog serer to capture the security alerts. The eent monitor component imbedded in the client can be used to intercept and forward alerts from the syslog serer to the eent serer. In addition, if non-tme Tioli Risk Manager adapters are deployed on a ariety of systems, these non-tme Tioli Risk Manager adapters can be configured to route their eents to a single client. The client can be used to summarize these eents prior to forwarding them to a serer. Tioli Risk Manager Eent Serer In the most straightforward deployment, a single Tioli Enterprise Console serer hosts the Tioli Risk Manager correlation serer functions. This means that the Tioli Enterprise Console functions and one Tioli Risk Manager correlation engine are on one machine, that is known as the eent serer. The eent serer participates in a Tioli Management Region (TMR). It also uses the serices proided by the Tioli Management Framework as well as a relational database interface. The Tioli Enterprise Console proides the following components: The Tioli Enterprise Console serer, that applies prolog-based rules to receied eents 6 IBM Tioli Risk Manager: Administrator s Guide

21 The Tioli Enterprise Console eent console serer, that manages the distributed consoles The Tioli Enterprise Console eent console The Adapter Configuration Facility (ACF), used to deploy and administer Tioli Enterprise Console adapters through the TMR. Tioli Enterprise Console adapters By installing the eent serer component on a Tioli Enterprise Console serer, the Tioli Enterprise Console serer is instrumental in performing the Tioli Risk Manager correlation functions. Tioli Risk Manager adapters and clients forward Tioli Risk Manager Tioli Enterprise Console eents to the eent serer for real-time correlation as well as for capture in the relational database. The eents receied by the Tioli Enterprise Console serer will be displayed on the eent console. In addition, the Tioli Risk Manager correlation technology implements a two-leel correlation process, that produces two types of alarms. These alarms are created in the form of Tioli Enterprise Console eents and are displayed on the eent console: Incidents Incident Groups Incidents are created by the Tioli Risk Manager state-based correlation engine. Incidents are created by using a patented time-based sliding-window algorithm for detecting suspicious patterns of actiity. Each time a particular pattern of suspicious actiity exceeds a configured threshold within a configured time period, an incident is created and forwarded to the Tioli Enterprise Console prolog correlation engine, where Tioli Risk Manager rules perform additional aggregation. This second leel of aggregation creates Incident Group eents, that represent aggregations of Incidents that are shown in Figure 2 on page 8. Chapter 1. Introduction 7

22 Tioli Risk Manager Eent Serer Real-Time Monitoring Tioli Enterprise Console Serer Prolog Correlation Engine Tioli Risk Manager Prolog Correlation Rules Incident Group Incidents Sensor Eents Console Console Incidents and Sensor eents Tioli Risk Manager State-based Correlation Engine Sensor Eents Eent Repository Archie Table Sensor Eents Client or Adapter Client or Adapter Client or Adapter Tioli Risk Manager Crystal Reports Tioli Data Warehouse Figure 2. Aggregations of Incidents Incidents and incident group eents are displayed on the eent console. The Tioli Enterprise Console captures and stores them in the relational eent repository. The Tioli Risk Manager correlation engine routes sensor eents to the archie table. The archie table is a flat table that is efficiently populated and accessed by the arious reporting facilities. Tioli Risk Manager posts other types of information to the console as well: Eents that indicate suspicious actiity from trusted hosts. Eents that document the presence of a Tioli Risk Manager sensor, based on the receipt of sensor traffic from a sensor. Heartbeat eents that are receied from Tioli Risk Manager components. Other exceptions. The eent console presents a composite iew of the eents receied from sensors in the network. The console can be configured to proide multiple iews of eent actiity, based upon filters that are created by the administrator. Tioli Risk Manager proides an import file to create default eent groups and eent filters. They can also be used when creating console instances for administrators. 8 IBM Tioli Risk Manager: Administrator s Guide

23 Distributed Correlation The eent serer is an essential component of a Tioli Risk Manager deployment. The eent serer proides both the console and the aggregation rules that generate the incident groups. The first-leel correlation process that creates incidents can be deployed in a distributed fashion, as shown in Figure 3, by installing one or more Tioli Risk Manager distributed correlation serers in your network. Each distributed correlation serer is responsible for a portion of the network s eent traffic. The serer performs the incident-based correlation on its portion of the eent traffic, forwards incident alerts and sensor eents to the eent serer for second-leel correlation, and is displayed on the console. Consider the following when deciding whether or not to deploy distributed correlation serers in your enironment: It proides a load-balancing mechanism for correlation, when dealing with extremely high olumes of eents. It can be used to dedicate correlation serers to logically grouped sensors and adapters, based on things such as network topology and location. The grouping might also be done based on organizational boundaries. It can also be used to proide redundancy in your correlation infrastructure. Tioli Risk Manager Eent Serer Prolog Correlation Engine Real-Time Monitoring Tioli Risk Manager Prolog Correlation Rules Tioli Risk Manager State-based Correlation Engine Console Incident Group Incidents Sensor Eents Sensor Eents Console Incident and Sensor Eents Eent Repository Archie Table Distributed Correlation Serer Distributed Correlation Serer Distributed Correlation Serer State-based Correlation Engine State-based Correlation Engine State-based Correlation Engine Sensor Eents Sensor Eents Tioli Risk Manager Crystal Reports Tioli Data Warehouse Client or Adapter Client or Adapter Client or Adapter Client or Adapter Client or Adapter Figure 3. Incident-Based Correlation that is Deployed in a Distributed Fashion A ariety of configuration options are aailable when distributing the Tioli Risk Manager correlation engines in this way. For example, instead of forwarding all Chapter 1. Introduction 9

24 sensor eents to the top-leel eent serer, only incident eents are forwarded. Using this approach, only incidents and incident groups will appear on the eent console, significantly reducing the eent processing load on the eent serer. Distributed correlation serers can also be configured to route sensor eents directly into the Tioli Risk Manager archie table, where they can be accessed using the Web access feature supported by Tioli Enterprise Console and Tioli Risk Manager. See Chapter 8, Web Application, on page 107 for more Web Application information. Tioli Risk Manager Console A Tioli Risk Manager administrator monitors the Tioli Enterprise Console for incidents, incident groups, and indiidual sensor eents (in particular, high-seerity sensor eents). Incident eents and incident group eents represent the results of correlation, and aggregation of correlation results, respectiely. The Tioli Enterprise Console is highly configurable, and can be customized to proide multiple iews of the information collected by Tioli Risk Manager, as well as the eents generated by Tioli Risk Manager s correlation process. Standalone Jaa and Web-based ersions of the Tioli Enterprise Console are also supported. Tioli Risk Manager Web Application Tioli Risk Manager proides a Web application that extends the capability of the Tioli Enterprise Console. The Tioli Risk Manager Web Application consists of three functions, that proide three different sources of information: Eent Details The Eent Details function displays detailed information about incident eents, incident group eents, and indiidual sensor eents. An incident eent is generated by Tioli Risk Manager correlation rules, as the result of processing what may be large numbers of eents receied from sensors and applications (known as sensor eents). Incident eents are further aggregated at the eent serer into incident group eents. By selecting an incident eent on the Tioli Enterprise Console and clicking the Information button, Eent Details proides access to the set of sensor eents that contributed to the creation of the selected incident eent. Similarly, Eent Details proides access to the set of incident eents that contributed to a selected incident group eent (as well as the sensor eents that contributed to the selected incident group eent). Adisor Tioli Risk Manager collects and correlates alerts from a dierse set of sensors, firewalls, applications, and operating systems. It is often essential that an organization s administrators, with arying expertise leels, ealuate and respond to security breaches in a consistent, policy-drien fashion. The Adisor proides a mechanism for security administrators to access pre-defined and accumulated knowledge that has been deeloped by experienced and say members of the organization. The information and suggested actions proided by the Adisor function are based on a set of rules, that proide a programmatic way to ensure consistent access to information and consistent responses to perceied threats. To access the information and suggested actions associated with an eent (per the Adisor rule set), select the eent on the een console and click the Information button. For example, an Adisor rule can proide direct access to the Common Vulnerabilities and Exposures (CVE) Web page, that proides salient details about the exposure. In addition, for a particular exposure or signature, an Adisor rule may recommend that be sent to a specific superisor. For additional information about building a library of Adisor rules, see Adisor on page IBM Tioli Risk Manager: Administrator s Guide

25 System Information Proper analysis of a security threat may depend on access to in-depth information about the target or source of the suspicious actiity. System Information proides direct access to software information and hardware information that is collected by the Tioli Inentory application. Tioli Inentory is a component of the Tioli Configuration Manager suite of applications. For example, Tioli Risk Manager can detect a Code Red attack being directed at a Web serer in your enterprise and may represent it as a single incident eent on the Tioli Enterprise Console. By selecting the incident eent on the console and clicking the Information button, you gain access to the System Information function and can mine the Tioli Inentory database for hardware and software information about the target of the Code Red attack. Continuing the example, if the target system is running an Apache web serer on a Linux operating system, the administrator can determine that the attack is suspicious, but will not cause harm to the target system. The following figure proides a high-leel iew of the placement of the Tioli Risk Manager Web Application function within a Tioli Risk Manager deployment. See Chapter 8, Web Application, on page 107 for more Web Application information. Browser Eent Details Adisor System Information Launch Console Tioli Enterprise Console Serer Tioli Risk Manager Agent as a Correlation Serer WebSphere Tioli Inentory DB Tioli Risk Manager Serlet Eent Details System Information Adisor Custom Adisor Rules Eent Repository Sensor Eents Incident Eents Incident Group Eents Figure 4. Web Application within a Tioli Risk Manager Deployment Chapter 1. Introduction 11

26 Tioli Risk Manager Historical Reporting The Crystal Reports component of Tioli Risk Manager proides twenty-two compiled reports that proide information for analysis of the kinds of intrusion eents that might occur on a customer s system. The compiled Crystal Reports proided with Tioli Risk Manager include Firewall Management Reports, Intrusion Detection Reports, Risk Assessment Reports, Eent Management Reports, and Virus Management Reports. The Compiled Reports format allows you to run reports without haing the Crystal Reports Designer installed on the system. Note: You must purchase and install the Crystal Reports Designer if you want to create or edit Crystal Reports. See Chapter 9, Reports, on page 139 for more information on historical reporting. Oeriew of Tioli Risk Manager Security Eent Processing The following sections proide a logical oeriew of the processing that occurs in a Tioli Risk Manager enironment when an attack (or other suspicious behaior) is detected. In this logical iew, there are four stages in the processing: 1. Detect An intrusion-detection sensor or application detects suspicious actiity or an otherwise interesting security-related action. Based on the configuration or policy of the sensor (or application), an alert is logged. 2. Filter and Summarize A Tioli Risk Manager adapter intercepts the sensor s alert, maps it into a Tioli Risk Manager eent and routes it to the client, that might aggregate duplicate eents and proide additional filtering. After filtering and aggregation, resulting eents are forwarded to a Tioli Risk Manager correlation serer. 3. First-leel correlation The Tioli Risk Manager correlation serer uses a state-based correlation engine to search for patterns of actiity. As particular leels of suspicious actiity are detected, the Tioli Risk Manager correlation engine produces Incident eents. An Incident represents a snapshot of a suspicious actiity pattern that occurred within a specified time period. Incident eents are forwarded to the top-leel Tioli Risk Manager correlation engine for further processing. This top-leel correlation engine is located on a Tioli Enterprise Console serer. 4. Second-leel correlation The top-leel correlation process runs in the Tioli Enterprise Console prolog-based correlation engine, and performs further aggregation on Incidents, as receied from one or more state-based Tioli Risk Manager correlation engines. The results of this aggregation take the form of incident group eents, that represent aggregations of Incidents. The Figure 5 on page 13 depicts a typical attack scenario, using the Web IDS sensor for illustration purposes. 12 IBM Tioli Risk Manager: Administrator s Guide

27 Figure 5. Tioli Risk Manager When an Attack is Detected In this example, the Web IDS sensor and the client (with summarization) are deployed on the same system. Similarly, the state-based correlation and prolog correlation rules are deployed together on the eent serer. The first-leel correlation performed by the state-based correlation engine can also be deployed on one or more Tioli Risk Manager correlation engines, that feed Incidents to the eent serer. Each of the four logical stages of processing are explained in more detail below. Detect The sensor or application performs detection of suspicious actiity and threats. In many cases, a sensor proides its own leel of intelligence in terms of determining when to produce an alert. It might use signatures, a knowledge-base, or built-in rules and policies to perform its own thresholding, aggregation, and so on. For example, a Network IDS tool can be configured to report a port scan when a host attempts to touch 10 or more ports on a serer in a short time period. Filter and Summarize The clients are used to summarize numerous duplicate or similar eents. This is an essential element of eent processing in many enironments. Certain types of Chapter 1. Introduction 13

28 sensors produce an extensie amount of eent traffic, much of it redundant. The ability to summarize eent floods without loss of important information is critical, for arious reasons: Network traffic can be reduced significantly Load on the correlation serers is reduced significantly Load on the database serer is reduced significantly Database footprint is reduced significantly A set of summarization rule files controls the summarization process. New summarization rules are deployed at the client to proide summarization for new applications and sensors. The client also can be tuned to filter out low-seerity or other less interesting alerts. First-Leel Correlation The state-based Tioli Risk Manager correlation engine supports two correlation techniques: Linked eents Pattern matching that is based on source, destination, attack classification, and optionally, a customer ID. Linked Eents A sequence of eents that are produced by a sensor might be linked together. When the second linked eent is receied, the correlation engine might raise the seerity of the second linked eent. An example of the utility is the ability to link eents in Web IDS. When Web IDS reports, for example, a suspicious Common Gateway Interface (CGI) request, the eent is associated with an appropriate seerity leel. Howeer, if the suspicious CGI request is actually successful, then it is appropriate to significantly raise the seerity of the second eent. Pattern Matching The Tioli Risk Manager correlation process analyzes all incoming Tioli Risk Manager sensor eents and searches for patterns. When suspicious actiity is detected as a result of the search for patterns, the Tioli Risk Manager correlation engine produces an alert, referred to as an incident. Incidents, along with sensor eents, will be displayed on the Tioli Enterprise Console as Tioli Enterprise Console eents. Incident creation is based on the following keys (obtained or deried from information in each sensor eent): Classification, or category, of the receied eents Source host of the suspicious actiity Destination host of the suspicious actiity (the resource being accessed), as reported in the receied eents Customer Identification (An optional element for correlation purposes) Various types of incidents might be produced, depending on the type of patterns that are detected. Table 1 describes the type of incidents that might be produced using the default correlation rules: Table 1. Types of Incidents Produced Type Key1 Key2 Key3 Description Category, Source, Destination Category Source Destination Represents specific actiity that is targeted from a single source host, to a single destination host, in a gien category. 14 IBM Tioli Risk Manager: Administrator s Guide

29 Table 1. Types of Incidents Produced (continued) Type Key1 Key2 Key3 Description Source, Destination Category, Destination Category, Source Source Destination List of Categories Category Source Destination Represents a broad range of suspicious actiity that is targeted from one host to another. List of Sources Destination Category Source List of Destinations List of Categories List of Categories Source List of Sources Category Category List of Sources List of Destinations Destination List of Destinations Represents a pattern of suspicious actiity that is directed against a single host from multiple source hosts in a gien category of suspicious actiity. Represents a pattern of suspicious actiity that originates from a single source host and is directed against multiple destinations in a gien category of suspicious actiity. Represents a widespread actiity that originates from a single source. Represents a pattern of widespread actiity from multiple sources that is directed against a single destination host. This scenario is most likely for an externally isible, high-profile serer, such as a Web serer. Represents a pattern of suspicious actiity of a certain type (within a single category) with multiple sources and destinations. This scenario is not common but might occur when a new ulnerability becomes widely known. Seerity, Thresholds, and Sliding Time Windows: Tioli Risk Manager uses three elements to determine when to create incidents: The seerity alues associated with indiidual sensor eents (represented as a numeric alue in the rm_leel attribute in the sensor eents). The adapter or sensor assigns the seerity leel for a specific sensor eent typically. The threshold alues associated with the correlation rules, used to determine when a stream of sensor eents that match a particular pattern type hae an aggregated seerity that warrants the creation of an incident. Correlation rules are located on the correlation serer. A sliding-window is a time-period during that actiity is monitored by the agent. The start time of the actiity is automatically adjusted so that only eents receied within the configured time period are actiely being monitored. Second-Leel Correlation Incident eents created by the state-based correlation engine are forwarded to the eent serer to be displayed on the console and stored in the Tioli Enterprise Console database. In addition, correlation rules running on the Tioli Enterprise Console serer perform an additional leel of aggregation on incident eents. This leel of aggregation is implemented as a set of prolog-based rules that run inside Chapter 1. Introduction 15

30 the Tioli Enterprise Console correlation engine. Aggregation of incident eents results in the creation of Incident Group eents. Information Displayed at the Tioli Enterprise Console This section describes how Tioli Risk Manager sensor eents and alarms are displayed on the eent console. Sensor eents represent the raw eents, generated by sensors and forwarded to the eent serer. Alarms are known as: Incidents Incident groups Incidents are eents that are produced by the Tioli Risk Manager correlation process. Incidents represent bursts of suspicious actiity, as detected oer a relatiely short period of time (for example, 5 or 10 minutes), where the suspicious actiity matches patterns defined in the correlation rules, and exceeds thresholds (also defined in the rules). The Tioli Risk Manager correlation process runs on the eent serer. In addition, the Tioli Risk Manager correlation process can be distributed to one or more distributed correlation serers, then forward incidents to the eent serer. Incident group eents are produced by special Tioli Risk Manager rules that are loaded in the eent serer prolog correlation engine. Incident groups represent aggregations of incident eents, and thus are representatie of sustained suspicious actiity. Console Usage Scenario To help you isualize the information aailable on the eent console, this section will lead you through a scenario based on the use of the following eent sources: Tioli Risk Manager Web Intrusion Detection System (Web IDS) Tioli Risk Manager Adapter for Check Point FireWall-1 Tioli Risk Manager Adapter for Windows Host Intrusion Detection For more information on the Adapter for Windows Host Intrusion Detection and the Adapter for Check Point FireWall-1, see the IBM Tioli Risk Manager Adapters Guide. In this scenario, two Web serers are actiely monitored using Web IDS. A brief description of what happens when a Web-based attack occurs is proided. The scenario also proides details on using the eent console to iew the intrusion-detection eents produced by Web IDS, and the incidents and incident group eents produced by the Tioli Risk Manager correlation process. The scenario is extended to include suspicious information detected by a firewall and Host IDS adapters. What happens when Web IDS detects an attack (or otherwise suspicious actiity) against a Web serer? The Tioli Risk Manager Web IDS sensor analyzes the access log files generated by a Web serer in order to detect suspicious actiity that is directed at the Web serer. The Web IDS sensor uses a knowledge-based approach to detect suspicious behaior, utilizing a set of signatures that when detected, might represent suspicious actiity. The set of signatures is extensie and is used to detect a wide range of possible attacks. The signature file can be customized, so it can be tuned to meet the needs of a particular enironment. When Web IDS detects suspicious actiity, a Tioli Risk Manager Tioli Enterprise Console eent is 16 IBM Tioli Risk Manager: Administrator s Guide

31 produced, and is routed to the eent serer (or a distributed correlation serer, then forwards correlation results to an eent serer). In the scenario described here, Web IDS has detected attacks that are directed at an Apache Web serer (named Apache1) and has posted multiple IDS eents to the eent serer. When the correlation engine running on the eent serer receies these Web IDS eents, they are analyzed. The goal is to detect patterns of suspicious actiity aboe and beyond the information contained in each indiidual eent (as produced by the arious Web IDS sensors). The alue of this correlation process only increases as information is receied from other types of sensors and adapters, that are being used to monitor other resources in the enterprise. The Tioli Risk Manager correlation engine uses the following: The seerity of the actiity, as reported in the eent (a numeric alue, reported in the rm_leel attribute). The olume of the actiity. The timing of the actiity. A larger olume of actiity in a shorter time-period may be more significant than lower rates of actiity spread oer a greater time period. But obiously this is not always the case. In addition, the following keys are used by the correlation engine to detect patterns of suspicious actiity: A categorization of the suspicious actiity (for example, Web attack, Trojan Horse, Denial of Serice, Virus found, and so on) Source of the attack, typically expressed as a host name or Internet Protocol (IP) address Destination of the attack, typically expressed as a host name or IP address Customer ID (optional, not engaged by default) The Tioli Risk Manager correlation engine aggregates eents based on the first three data keys and combinations of these keys and then generates incident eents, that represent alarms raised by the correlation engine. The Tioli Risk Manager correlation engine routes these incident eents to the Tioli Enterprise Console serer, and the eents are displayed on the administrator s console. As noted before, the Tioli Risk Manager correlation engine is always located on the eent serer, and optionally on one or more additional systems as distributed correlation serers. Tioli Enterprise Console Eent Groups Eent groups are used to proide different filtered iews of the eents that hae been collected by the eent serer. Tioli Risk Manager proides a default set of pre-defined eent group definitions that proide different iews of the eents collected by Tioli Risk Manager from sensors and adapters, and the eents generated by Tioli Risk Manager itself. Figure 6 on page 18 proides a iew of the eent console Summary Chart View, that displays a graphical representation of the arious Tioli Risk Manager eents. Chapter 1. Introduction 17

32 Figure 6. Tioli Enterprise Console Summary Chart View The RM_TrustedHost group is populated using a filter that includes eents that are produced when a correlation serer detects a new instance of a trusted host. Suspicious actiity originating from a host designated as trusted will not be correlated and will not contribute to the production of incidents and incident group eents. For example, if a network administrator runs network ulnerability scans on a regular basis, and you do not want this actiity interpreted as suspicious actiity by the correlation engine, you can designate the administrator s host as trusted. The RM_SensorEent group is populated using a filter that includes sensor eents collected from Tioli Risk Manager sensors and adapters. The filter excludes eents that are generated by Tioli Risk Manager, such as incidents, trusted host eents, and error eents. The RM_Sensor group is populated using a filter that includes eents produced when a Tioli Risk Manager correlation serer detects for the first time the presence of an instance of a specific sensor on a specific host. In other words, each time a Tioli Risk Manager correlation serer discoers a new sensor instance, an eent is generated (of class name RM_Sensor). The RM_IncidentGroup group is populated using a filter that includes all Tioli Risk Manager incident group eents. The RM_Incident group is populated using a filter that includes all Tioli Risk Manager incident eents. 18 IBM Tioli Risk Manager: Administrator s Guide

33 The RM_Eent group is populated using a filter that includes all Tioli Risk Manager eents of all types (sensor eents, incident eents, incident group eents, errors and so on). The RM_Error group is populated using a filter that includes error eents that are produced by Tioli Risk Manager. The Eent Viewer Click the RM_SensorEent bar to launch the eent iewer for the sensor eents receied from arious Tioli Risk Manager sensors and adapters. Figure 7. Tioli Enterprise Console Eent Viewer (Sensor Eents) In this example scenario, multiple suspicious requests were detected by Web IDS, deployed on a Web serer called Apache1, and reported to the eent serer. The Hostname attribute, displayed on the eent console, contains useful information: A short-form description of the attack category. In this example, the category is WEB. The host name (or IP address) of the sensor that generated the eent. In this example, Apache1 is the host name of the Web serer where the Web IDS sensor is located. The host name (or IP address) of the source of the suspicious actiity. In this scenario, the host name is Source1. The host name (or IP address) of the target of the suspicious actiity. In this scenario, the host name is also Apache1, because Web IDS typically is located on the serer it is monitoring. The console iew proided here also contains the following information: Time Receied Specifies the time when the eent was receied by the eent serer. Class Specifies the class name of the eent. Hostname As used by Tioli Risk Manager, includes the compact representation of attack category, sensor host name, source host name, and destination host name. Seerity Specifies the Tioli Enterprise Console eent seerity. Chapter 1. Introduction 19

34 Message A brief description of the eent. Typically includes the signature associated with the eent. Repeat Count Set to a non-zero alue if the eent is a summarized eent as generated by the client summarization facility. A non-zero alue (+1) represents the number of indiidual sensor eents that are represented by the summary eent. A alue of zero indicates that the eent is not a summarized eent. Each summarized eent also has an rm_leel alue, that is computed by multiplying the repeat_count +1 by the rm_leel alue associated with the first eent in the summarized sequence. For example, a summary eent with a repeat_count alue of 299 and a default rm_leel of 0.5 has its rm_leel attribute set to Sub-origin The name of the sensor or adapter. In this example, Sub-origin is set to webids. Status Specifies the Tioli Enterprise Console eent status. By default, Tioli Risk Manager leaes the eents in open status. See Closing Sensor Eents on page 43 for details about configuring the eent serer to automatically close sensor eents as they are receied. See Tioli Risk Manager Database Utilities on page 56 for information about using the wrmdbclose utility to schedule the closing of sensor eents. Note: The specific attributes can be customized, as can their position on the iewer. You can customize your eent iewer to include other Tioli Enterprise Console attributes, such as the following: Origin The IP address of the adapter that produced the sensor eent. Adapter Host The host name of the adapter that produced the sensor eent. Incident Eents (Phase 1) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_Incident eent group it would display the eent iewer showing all Tioli Risk Manager Incidents. Figure 8. Tioli Enterprise Console Eent Viewer (Incident Eents) 20 IBM Tioli Risk Manager: Administrator s Guide

35 Continuing with the scenario, Figure 8 on page 20 shows that a SrcDstCat Incident (class=rm_src_dstcat_incident) has been generated by the correlation engine in response to receipt of the set of sensor eents, as was shown in the preious RM_SensorEent eent group iew. Again, the Hostname attribute, as displayed on the eent console, contains useful information in a ery compact form: A short-form description of the attack category. In this example, the category is WEB. The host name (or IP address) of the source of the suspicious actiity. In this scenario, the host name is Source1. The host name (or IP address) of the target of the suspicious actiity. In this scenario, the host name is Apache1. The console iew proided here also contains the following information: Time Receied Specifies the time when the incident eent was receied by the eent serer. Class Specifies the class name of the eent. Hostname As used by Tioli Risk Manager, includes the compact representation of attack category, destination host name, and source host name. Seerity Specifies the Tioli Enterprise Console eent seerity. Message A brief message that indicated the attack falls within the WEB category. It also describes it as suspicious actiity from a host called Source1 targeted at a host called Apache1. Repeat Count The repeat count alue of 5 indicates that fie sensor eents actually contributed to this particular incident eent. Because eight eents were actually receied in a short time period, with the same source, destination and attack category, this implies that receipt of fie of the eents was sufficient to exceed the configured threshold and trigger the creation of an incident eent. The additional three sensor eents may contribute to an additional incident eent later, if Web IDS produces additional eents for this particular source and destination within the configured time window. This incident eent proides essential information about the set of eents that are produced by the Web IDS sensor. This incident eent indicates: A number of sensor eents were receied and correlated that indicate a single source host (Source1) was the origin of Web-related actiity, directed against a single destination Web serer (Apache1). The sensor eents that contributed to this incident were receied within the designated time window and exceeded the thresholds. The size of the time window and the threshold are both defined in the correlation rules. The correlation rules also specified that this leel of actiity should produce an incident with a seerity of Critical. Chapter 1. Introduction 21

36 Additional details about the incident eent can be obtained by selecting the desired incident and double-clicking on the selected eent. This action will bring up a details iew of the selected eent, as shown in the following figure: Figure 9. Incident Details View This details iew proides other information that might be of interest, including: rm_categorydisplaynames A more descriptie form of the attack category, in this case Web Attack. The short form is in rm_categorytokens. rm_customerid If correlation is being performed on a customer (or organization) basis, the 22 IBM Tioli Risk Manager: Administrator s Guide

37 rm_customerid attribute would reflect the specific customer ID associated with the sensor eents that contributed to the incident. In this example, the default alue of NA is set. rm_leel The aggregated seerity leel of the set of sensor eents that contributed to the incident. In this example, the alue is rm_signatures List of unique signatures obtained from the set of contributing sensor eents. rm_sensors A list of unique sensor or host name pairs from contributing eents were receied. Each element in this is actually the sensor type concatenated with the sensor s host name (in this case webids and Apache1). rm_windowsize The size of the sliding window used to control the creation of this incident. In this example, milliseconds (100 minutes) is being used. In addition to this details iew, you can directly access the sensor eents that contributed to an indiidual incident eent by selecting an incident eent and pressing the Information button. A Web browser opens with a iew of the contributing sensor eents. See the IBM Tioli Risk Manager Installation Guide for information about setting up and using this application. Incident Group Eents (Phase 1) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_IncidentGroup eent group it would display the eent iewer showing all Tioli Risk Manager Incident Group eents. Figure 10. Tioli Enterprise Console Eent Viewer (Incident Group Eents) Continuing with the scenario, Figure 10 shows that a SrcDstCat Incident Group (class=rm_srcdstcat_incidentgroup) has been generated by the second-leel correlation process that occurs at the Tioli Enterprise Console eent serer in response to receipt of one or more incident eents. In this case, this incident group eent was generated because the single incident eent triggered the incident group thresholds configured at the eent serer. Chapter 1. Introduction 23

38 As for sensor and incident eents, the Hostname attribute for incident group eents contains useful information in a compact form: A short-form description of the attack category. In this example, the category is WEB. The host name (or IP address) of the source of the suspicious actiity. In this scenario, the host name is Source1. The host name (or IP address) of the target of the suspicious actiity. In this scenario, the host name is Apache1. The console iew proided here also contains the following information: Time Receied Specifies the time when the incident group eent was receied by the eent serer. Class Specifies the class name of the eent. Hostname As used by Tioli Risk Manager, includes the compact representation of attack category, source host name, and destination host name. Seerity Specifies the Tioli Enterprise Console eent seerity. Message A brief message that indicated the attack falls within the WEB category. It also describes it as suspicious actiity from a host called Source1 targeted at a host called Apache1. Repeat Count The repeat count alue of 1 indicates that a single incident eent has contributed to this particular incident group eent. Note that the repeat count will increase if the suspicious actiity continues, and additional incident eents are produced and contribute to this incident group eent. Additional details about the incident group eent can be iewed by selecting the desired incident group and double-clicking on the selected eent. A details iew of the selected eent opens, as shown in the following figure: 24 IBM Tioli Risk Manager: Administrator s Guide

39 Figure 11. Incident Group Details View This details iew proides other information that might be of interest, including: rm_categorydisplaynames A more descriptie form of the attack category, in this case Web Attack. The short form is in rm_categorytokens. rm_customerid If correlation is being performed on a customer (or organization) basis, the rm_customerid attribute would reflect the specific customer ID associated with the incident eents that contributed to the Group. In this example, the default alue of N/A is set. If there is more than one rm_customerid attribute from the contributing incidents, it will be represented with an *. Chapter 1. Introduction 25

40 rm_combinedleel The aggregated seerity leel of the set of incident eents that contributed to the incident. In this example, the alue is e+01. rm_highestleel The highest rm_leel of contributing incidents. In this example, the alue is e+01. rm_lastleel The rm_leel of the most recently receied incident contributing to the Group. In this example, the alue is e+01. rm_metric Specifies whether the metric for creating and maintaining this incident group eent is based on the aggregated seerity leel (rm_leel) or the count of incidents. rm_sensors A list of unique sensor or host name pairs from contributing eents were receied. Each element in this is actually the sensor type concatenated with the sensor s host name (in this case webids and Apache1). rm_signatures List of unique signatures obtained from the set of contributing incident eents. In addition to this details iew, you can directly access the incident and sensor eents that contributed to an indiidual incident group eent by selecting an incident group eent and clicking the Information button. A Web browser opens with a iew of the contributing incident and sensor eents. See the IBM Tioli Risk Manager Installation Guide for information about setting up and using this application. Adding More Web IDS Eents to the Scenario: Figure 12 on page 27 proides a iew of the eent console s Summary Chart View after additional Web IDS eents are receied at the eent serer. The sample scenario now depicts a broadening of the attack, where the Web IDS sensor is located on a second Web serer, IBMHTTP1, and detects suspicious actiity from the same source host, Source1. 26 IBM Tioli Risk Manager: Administrator s Guide

41 Figure 12. Tioli Enterprise Console Summary Chart View As you can see, additional sensor eents hae arried, and additional incident and incident group eents hae been created. Click on the RM_SensorEent bar would launch the eent iewer for sensor eents that are receied from arious Tioli Risk Manager sensors and adapters. Chapter 1. Introduction 27

42 Figure 13. Tioli Enterprise Console Eent Viewer (Sensor Eents) In this example, multiple suspicious requests were detected by two instances of Web IDS and reported to the eent serer. The suspicious actiity from Source1 is now directed against two different Web serers, Apache1, and IBMHTTP1. Incident Eents (Phase 2) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_Incident eent group it would display the eent iewer showing all Tioli Risk Manager Incidents. Figure 14. Tioli Enterprise Console Eent Viewer (Incident Eents) 28 IBM Tioli Risk Manager: Administrator s Guide

43 Continuing with the scenario, Figure 14 on page 28 shows that fie incident eents now appear on the console: Two additional SrcDstCat incidents that reflect snapshots of sustained actiity directed from Source1 against Apache1. A new SrcDstCat incident that reflects a flurry of new actiity directed from Source1 against IBMHTTP1. A single SrcCat incident, reflecting the fact that Source1 is using a single category of attack against multiple Web serers. This particular incident represents the broadening scope of the attack against multiple systems in the enterprise. At this point, the SrcCat incident (class = RM_SrcCat_Incident) becomes the focus of attention. Additional details about the SrcCat incident group eent can be obtained by selecting the desired incident group and double-clicking on the selected eent. This will bring up a details iew of the selected eent. For an example of the incident details iew, see Figure 9 on page 22. Information that might be of interest in the details iew: rm_destinationtokens A list of host names (or IP addresses) that represent the targets of the attack. rm_signatures List of unique signatures obtained from the set of contributing sensor eents. In addition to this details iew, you can directly access the sensor eents that contributed to an indiidual incident eent by selecting an incident eent and clicking the Information button. This will load a Web browser with a iew of the contributing sensor eents. See the IBM Tioli Risk Manager Installation Guide for information about setting up and using this application. Incident Group Eents (Phase 2) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_IncidentGroup eent group it would display the eent iewer showing all Tioli Risk Manager Incident Group eents. Figure 15. Tioli Enterprise Console Eent Viewer (Incident Group Eents) Chapter 1. Introduction 29

44 Continuing with the scenario, Figure 15 on page 29 shows that three incident group eents now appear on the console: Two SrcDstCat incident group eents reflect the two separate flurry of attacks: Source1 attacking Apache1 Source1 attacking IBMHTTP1 Note that the additional incident eents seen on the Incident Eent iewer are also reflected here. Instead of creating additional incident group eents, the incidents continue to be aggregated into the existing incident group eent. There are a couple of clues that this is happening: The repeat_count associated with the incident group eent has been incremented to 3 (since three separate Incident eents are represented by this single incident group eent. The seerity of the incident group has been escalated to Minor. A single SrcCat incident group eent, reflecting the fact that the source is using a single category of attack against a range of Web serers. This incident flags the broadening scope of the attack against multiple systems in the enterprise. Focusing on the SrcCat incident group (class = RM_SrcCat_IncidentGroup) might become more productie than tracking additional incidents related to this attack. Additional incidents related to this attack will be created in the incident iew. Howeer, these new incidents, as they occur, will be folded into existing incident group eents, possibly increasing seerity, adding knowledge in terms of signatures, and targeted hosts. To iew additional details about the SrcCat incident group eent, double-click on the desired eent. This will bring up the details iew. For an example of the incident group details iew, see Figure 11 on page 25. Information that might be of interest in the details iew: rm_destinationtokens A list of host names (or IP addresses) that represent the targets of the attack. rm_signatures A list of unique signatures obtained from the set of contributing incident eents. In addition to this details iew, you can directly access the incident eents and sensor eents that contributed to an indiidual incident group eent by selecting a specific incident group eent and clicking the Information button. This will load a Web browser with a iew of the contributing sensor eents. See the IBM Tioli Risk Manager Installation Guide for information about setting up and using this application. Adding Firewall and Host IDS Eents to the Scenario: Figure 16 on page 31 proides a iew of the eent console s Summary Chart View after additional eents are receied at the eent serer. The example scenario now includes eents collected from an adapter monitoring a firewall, and an adapter monitoring actiity on a host system. 30 IBM Tioli Risk Manager: Administrator s Guide

45 Figure 16. Tioli Enterprise Console Summary Chart View In this scenario, additional sensor eents hae arried, and additional incident and incident group eents hae been created. Clicking on the RM_SensorEent bar would launch the eent iewer for sensor eents receied from arious Tioli Risk Manager sensors and adapters. Chapter 1. Introduction 31

46 Figure 17. Tioli Enterprise Console Eent Viewer (Sensor Eents) In this example, a ariety of alerts are being receied from multiple sensors, from multiple sources, against multiple targets, using a ariety of attack categories, including: Failed attempts to authenticate (SECAUTH.DENY) Access to serices blocked by firewall policy (SERV) Access to network serices blocked by firewall policy (NETLVL) Eent traffic is arriing from the following types of sensors: OS (Host IDS) fw_cpfw (Adapter for Check Point FireWall-1) webids (Web IDS sensor) The olume of indiidual sensor eents can quickly become large enough to be difficult to track on an indiidual basis. The detailed information proided by the indiidual sensor eents can be quite aluable, but it becomes essential that a broader iew of the actiity is proided in such a way to allow you to see the bigger picture. The incident eent iew can help proide this bigger picture. Incident Eents (Phase 3) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_Incident eent group it would display the eent iewer showing all Tioli Risk Manager Incidents. 32 IBM Tioli Risk Manager: Administrator s Guide

47 Figure 18. Tioli Enterprise Console Eent Viewer (Incident Eents) Continuing with the scenario, Figure 18 shows a growing list of eleen Incident eents on the console. A ariety of SrcDstCat incidents are shown, each indicating correlated actiity between specific pairs of sources and destinations, using a single category of suspicious actiity. The SrcCat Incidents reflecting Source1 s attack against multiple web serers remains on the console as well. We also see a series of SrcDstCat Incidents that reflect multiple unsuccessful attempts by a system with IP address to authenticate on two hosts, unixhost4 and unixhost5. The fact that is attempting to logon to multiple systems is reflected by the SrcCat Incidents, that are useful to see the broadening scope of the authentication actiity. In addition, a Cat Incident has been created, reflecting the Serice Attack actiity (short name of SERV) between a ariety of sources and destinations. This particular Cat incident was created before more specific Incidents since the threshold for the broader Incident triggered before the more specific Incidents. Incidents for the NETLVL eents (seen on the SensorEent console iew) hae not been created yet, because thresholds hae not been triggered. To see more details about the information represented by the most recently generated Cat incident eent, select this eent and click the Details button (or double-click on the eent). This will bring up a details iew of the selected eent. For an example of the incident details iew, see Figure 9 on page 22. Information that might be of interest in the details iew: rm_destinationtokens A list of host names (or IP addresses) that represent the targets of the attack. rm_sensors A list of host names (or IP addresses) that represent the sensors reporting the actiity. Chapter 1. Introduction 33

48 rm_signatures A list of unique signatures obtained from the set of contributing sensor eents. rm_sourcetokens A list of host names (or IP addresses) that represent the sources of the attack. In addition to this details iew, you can directly access the sensor eents that contributed to an indiidual incident eent by selecting an incident eent and clicking the Information button. This will load a Web browser with a iew of the contributing sensor eents. See the IBM Tioli Risk Manager Installation Guide for information about setting up and using this application. Incident Group Eents (Phase 3) Return to the Tioli Enterprise Console Summary Chart View, Figure 6 on page 18, and by clicking on the RM_IncidentGroup eent group it would display the eent iewer showing all Tioli Risk Manager Incident Group eents. Figure 19. Tioli Enterprise Console Eent Viewer (Incident Group Eents) Continuing with the scenario, Figure 19 shows that seen incident group eents now appear on the console. Since there has been no additional Web-related actiity, the WEB incident groups are unchanged. Note that the eents in the incident group iew proide similar information to what is seen on the Incident iew, but in a more compact, focused form. Specifically, the following entries in the incident group iew are aggregations of the indiidual Incidents: WEB:Source1=>Apache1 (aggregates 3 incidents) SECAUTH.DENY: =>* (aggregates 2 incidents) SECAUTH.DENY: =>unixhost5 (aggregates 2 incidents) As a result of the continued incident actiity that is contributing to these incident groups, both the associated seerity and repeat_count hae escalated. Any additional incidents related to these incident groups will be created in the incident iew. These new incidents, as they occur, will be folded into existing 34 IBM Tioli Risk Manager: Administrator s Guide

49 Incident Eent Types incident group eents, possibly increasing seerity, adding knowledge in terms of signatures, and targeted hosts. To see additional details about any incident group, double-click on the desired incident group eent. For example, selecting the SECAUTH.DENY: =>* incident group eent will bring up the details iew. For an example of the incident group details iew, see Figure 11 on page 25. There are seen types of incident eents that are created by the Tioli Risk Manager correlation engine when suspicious actiity is detected. The seen default types are described below. Note that each type of incident is controlled by a separate rule, and is produced independently of other types of incidents. Unique Combinations of Source, Destination, and Category (SrcDstCat) As the correlation engine receies input from a ariety of sources (in the form of sensor eents), it tracks all unique combinations of Source, Destination and Category attributes. Wheneer the eent actiity for a specific combination of Source, Destination and Category exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the unique combination of Source, Destination and Category, tracking continues for that combination. An incident of this type represents ery focused actiity. Unique Combinations of Source and Category (SrcCat) The correlation engine tracks all unique combinations of Source attributes and Category attributes, while simply aggregating associated alues for Destination. Wheneer the eent actiity for a specific combination of Source and Category exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the unique combination of Source and Category, tracking continues for that combination. Incidents of this type represent ery focused actiity from a single source, directed against multiple targets. In our example here, an incident of this type might be indicatie of a single hacker launching Web-based attacks against seeral enterprise Web serers. Unique Combinations of Destination and Category (DstCat) The correlation engine tracks all unique combinations of Destination attributes and Category attributes, while simply aggregating associated alues for Source. Wheneer the eent actiity for a specific combination of Destination and Category exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the unique combination of Destination and Category, tracking continues for that combination. Incidents of this type represent ery focused actiity against a single destination host, launched from multiple sources. They might be indicatie of a hacker staging an attack from multiple hosts against a single Web serer in an enterprise. Unique Combinations of Source and Destination (SrcDst) The correlation engine tracks all unique combinations of Source attributes and Destination attributes, while simply aggregating associated alues for Category. Chapter 1. Introduction 35

50 Wheneer the eent actiity for a specific combination of Source and Destination exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the unique combination of Source and Destination, tracking continues for that combination. These types of incidents represent a broader range of actiity between a specific pair of source hosts and destination hosts. A single particular incident might be indicatie of a hacker staging an array of attacks from a single source against a single destination. If the same source launches the broad attack against two different destinations, two or more different incidents of this type might be produced. Unique Value for Category (Cat) The correlation engine tracks all unique categorizations of suspicious actiity, while simply aggregating associated alues for Source and Destination. Wheneer the eent actiity for a specific alue for Category exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the particular alue of Category, tracking continues for that Category. Incidents of this type represent a specific type of suspicious actiity, launched between a ariety of Sources and a ariety of Destinations. These types of incidents represent a broader range of actiity of a specific type, launched between multiple Sources and Destinations. An incident of this type might indicate a situation where a new type of attack is published, and multiple members of the hacker community are exercising the new attack. If two different types of attacks are being exercised in the same way, two or more different incidents of this type may be produced. Unique Value for Source (Src) The correlation engine tracks all unique alues for Source, while simply aggregating associated alues for Category and Destination. Wheneer the eent actiity for a specific alue for Source exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the particular alue of Source, tracking continues for that Source. These types of incidents represent a broader range of actiity, launched from a single Source against multiple Destinations. An incident of this type might indicate a situation where single hacker is launching a range of attacks against many serers in an enterprise. If two different hackers are launching broad-based attacks against a range of serers, two or more different incidents of this type may be produced. Unique Value for Destination (Dst) The correlation engine tracks all unique alues for Destination, while simply aggregating associated alues for Category and Source. Wheneer the eent actiity for a specific alue for Destination exceeds the threshold within the configured time window, an incident eent is produced. If and when additional eents are receied for the particular alue of Destination, tracking continues for that Destination. These types of incidents represent a broader range of actiity, launched from multiple Sources against a single Destination. An incident of this type might 36 IBM Tioli Risk Manager: Administrator s Guide

51 indicate a situation where a broad, concerted attack has been launched against one of your web serers. If two broad-based attacks are being launched against two of your Web serers, two or more different incidents of this type may be produced. Chapter 1. Introduction 37

52 38 IBM Tioli Risk Manager: Administrator s Guide

53 Chapter 2. Eent Serer Configuring Correlation Each sensor that you hae installed in your network monitors a single resource, such as a host or a router, or a network of resources. When actiity is detected, each sensor generates information in the form of eents (also called alerts) that are routed to an eent serer. Each of these eents represents an indiidual occurrence of a suspicious actiity or security-related problem that the sensor has detected. Tioli Risk Manager analyzes the incoming Tioli Risk Manager eents and searches for patterns of actiity. Suspicious actiity or problems, that are detected as a result of the search for patterns, are referred to as incidents. Incidents are displayed on the Tioli Enterprise Console as eents. The incidents are routed to the Tioli Risk Manager eent serer where they are analyzed and displayed on the Tioli Enterprise Console as eents. The analysis at the eent serer creates incident group eents that are displayed on the Tioli Enterprise Console. The process of identifying incidents and incident groups is referred to as correlation. The correlation process reduces redundancy and operator oerload by sifting through intrusion-detection information from multiple sensors and presenting the releant information in a concise format. The configuration of the correlation processing that identifies incidents is described in Chapter 7, Incident-Based Correlation, on page 95. The configuration of the correlation process that identifies incident groups is described later in this chapter. See the IBM Tioli Risk Manager Problem Determination Guide for errors that might occur during correlation or as the result of errors in configuration files. Incidents and Incident Groups The eent serer monitors incident (RM_Incident) eents at the Tioli Enterprise Console serer with Tioli Risk Manager eent classes and prolog rules. The eent serer can be configured to generate incident group (RM_IncidentGroup) eents when RM_Incident eents are receied from a distributed correlation serer or the incident-based correlation engine that is running on the eent serer. RM_IncidentGroup classes are as follows: RM_SrcDstCat_IncidentGroup Generated when RM_SrcDstCat_Incident eents reach the specified threshold. RM_SrcDst_IncidentGroup Generated when RM_SrcDst_Incident eents reach the specified threshold. RM_SrcCat_IncidentGroup Generated when RM_SrcCat_Incident eents reach the specified threshold. RM_DstCat_IncidentGroup Generated when RM_DsCat_Incident eents reach the specified threshold. Copyright IBM Corp

54 RM_Src_IncidentGroup Generated when RM_Src_Incident eents reach the specified threshold. RM_Cat_IncidentGroup Generated when RM_Cat_Incident eents reach the specified threshold. Tioli Risk Manager Correlation Components Tioli Risk Manager serers include the following components: Agent.baroc files List (.lst) configuration files.xml and.conf configuration files The Eent Serer also includes: Prolog (.pro) configuration files Rules (.rls) files Configuring the Eent Serer The configuration settings for the Tioli Risk Manager eent serer are included in the prolog configuration file, RMINSTDIR/etc/tec/rules/riskmg_config.pro. To actiate changes you make in this file, use the rmcorr_cfg command. See the IBM Tioli Risk Manager Command Reference for details on using this command. See the IBM Tioli Risk Manager Installation Guide for basic eent serer configuration information. Adanced Configuration After installing and performing the required configuration on the eent serer, you can change your prolog configuration settings and configure the list (.lst) files. Changing Prolog Configuration Settings You can change the prolog configuration settings by editing the prolog configuration file, riskmgr_config.pro. The riskmgr_config.pro configuration file, is located in the RMINSTDIR/etc/tec/rules directory. Note: This file is a prolog source file. Statements in the prolog are referred to as predicates. You must be careful to ensure that you use correct prolog syntax. This means: Each entry must be terminated with a period (. ). Strings should be enclosed with single quotation marks ( ). Real numbers must not end with a period (. ), but should be followed by.0. For example, 25 must be written as 25.0 The underscore character ( _ ) acts as a wildcard. The order of the predicates is important especially for threshold settings. Be sure to specify the more specific definitions first, followed by the more generic definitions. To actiate the changes you make to the prolog configuration file, use the rmcorr_cfg -reconfig command. See the IBM Tioli Risk Manager Command Reference for details on using this command. 40 IBM Tioli Risk Manager: Administrator s Guide

55 See the following sections to set the configuration options: Disabling Incident Group Creation Setting Incident Group Thresholds Setting the Incident Group Seerity Minimum on page 42 Closing Sensor Eents on page 43 Determine Processes for Non-TME Eent Handling on page 43 Disabling Incident Group Creation You can configure the eent serer to not create RM_IncidentGroup eents using the disable_incident_group_creation predicate. Valid parameters are: ALL Cat Dst Incident group creation is completely disabled. Incident group creation is disabled for RM_Cat_Incident eents. Incident group creation is disabled for RM_Dst_Incident eents. DstCat Incident group creation is disabled for RM_DstCat_Incident eents. NONE Src Incident group creation is fully enabled. This is the default alue. Incident group creation is disabled for RM_Src_Incident eents. SrcCat Incident group creation is disabled for RM_SrcCat_Incident eents. SrcDst Incident group creation is disabled for RM_SrcDst_Incident eents. SrcDstCat Incident group creation is disabled for RM_SrcDstCat_Incident eents. Note: By default, incident group creation is enabled. Setting Incident Group Thresholds You can control the creation of, and seerity assigned to the incident group eents using the set_incidentgroup_threshold predicate. set_incidentgroup_threshold(type, metric, harmless, warning, minor, critical, cust). where: type Cat Dst This threshold is for RM_Cat_IncidentGroup eents. This threshold is for RM_Dst_IncidentGroup eents. DstCat This threshold is for RM_DstCat_IncidentGroup eents. Src This threshold is for RM_Src_IncidentGroup eents. SrcCat This threshold is for RM_SrcCat_IncidentGroup eents. SrcDst This threshold is for RM_SrcDst_IncidentGroup eents. SrcDstCat This threshold is for RM_SrcDstCat_IncidentGroup eents. Chapter 2. Eent Serer 41

56 underscore ( _ ) This threshold is for all RM_IncidentGroup eents. metric leel Metric will be the combined rm_leel of the contributing RM_Incident eents. count Metric will be the number of RM_Incident eents contributing to the RM_IncidentGroup. harmless The numeric threshold that the RM_IncidentGroup eent will be created with seerity= HARMLESS. warning The numeric threshold that the RM_IncidentGroup eent will be created with seerity= WARNING. minor critical cust The numeric threshold that the RM_IncidentGroup eent will be created with seerity= MINOR. The numeric threshold that the RM_IncidentGroup eent will be created with seerity= CRITICAL. This is optional and is typically specified when there is a need to create incident groups. If specified, cust is matched with the rm_customerid attribute of the RM_Incident eents receied at the Tioli Enterprise Console serer. Because cust is a string alue, it must be enclosed in single quotation marks in the set_incidentgroup_threshold predicate. To ensure that incident group eents are processed for rm_customerid that do not hae a specific threshold setting, you should be sure to specify at least one set_incident_group_threshold predicate with no cust alue. Example settings with cust specified: set_incidentgroup_threshold(_, leel,5.0,10.0,30.0,50.0, ABC Inc ). set_incidentgroup_threshold(_, leel,1.0,10.0,30.0,50.0, ZYX Corp ). set_incidentgroup_threshold(_, leel,20.0,40.0,60.0,100.0). Note: Incident group eents are generated when the metric reaches the harmless setting. It is recommended that you use the same metric for all incident group processing. Howeer, you are not required to do so. If you hae a mix of metric settings in your thresholds that results in thresholds for both metrics being set, then the leel threshold specified is used for correlation. Setting the Incident Group Seerity Minimum Using the highest_incident_seerity_is_minimum_incidentgroup_seerity predicate, you can direct the Tioli Risk Manager eent serer to set the RM_IncidentGroup seerity to be no lower than the seerity associated with contributing RM_Incident eents. When enabled, your RM_IncidentGroup eents might hae a seerity higher than the threshold setting. Valid parameters are: yes or no. To ensure that the RM_IncidentGroup eent seerity is at least as high as the seerity of the represented incident eents specify: highest_incident_seerity_is_minimum_incidentgroup_seerity( yes ) 42 IBM Tioli Risk Manager: Administrator s Guide

57 To disable this function, specify: highest_incident_seerity_is_minimum_incidentgroup_seerity( no ) Closing Sensor Eents Using the close_sensor_eents predicate, you can direct the Tioli Risk Manager eent serer to close RM_SensorEents that hae been sent to your Tioli Enterprise Console serer. The RM_SensorEents must hae been normalized by a Tioli Risk Manager correlation serer (agent) to be affected by this predicate. Valid parameters are: yes or no. For example, close_sensor_eents( no ) close_sensor_eents( yes ) Determine Processes for Non-TME Eent Handling In a well-configured system, your non-tme adapters and sensors should route their eents to a Tioli Risk Manager correlation agent. Because it is not possible to route eents from your TME adapters to a Tioli Risk Manager correlation agent, eents from TME adapters are automatically routed to the local Tioli Risk Manager correlation agent. You can specify how you want eents routed from a non-tme adapter or sensor directly to the Tioli Risk Manager eent serer using the non_tme_eent_handling predicate. Valid parameters are: correlate, drop, and ignore. where: correlate The non-tme RM_SensorEent eents are routed to the Tioli Risk Manager correlation agent that is specified in the rmlocal.conf file of your Tioli Enterprise Console rule base. Unless you hae changed the rmlocal.conf file, the default settings will cause the eents to be routed to the local Tioli Risk Manager correlation agent. This is the default behaior. drop The non-tme RM_SensorEent eents will not be routed to the Tioli Risk Manager correlation agent, and therefore will not contribute to incident identification. Such eents will not be aailable for iewing on the eent console and will not be entered in the Tioli Enterprise Console database. ignore The non-tme RM_SensorEent eents will not be routed to the Tioli Risk Manager correlation agent, and therefore will not contribute to incident identification. Such eents will be aailable for iewing on the eent console and will be in the Tioli Enterprise Console database. The default behaior is correlate. For example, non_tme_eent_handling( correlate ). non_tme_eent_handling( drop ). non_tme_eent_handling( ignore ). Chapter 2. Eent Serer 43

58 Configuring the List Files The list files are configuration files used by the rmcorr_cfg command. The list files are as follows: RMINSTDIR/etc/riskmgr_baroc.lst - list of actie BAROC files This file is used by the agent. RMINSTDIR/etc/riskmgr_rules.lst - list of actie rules files RMINSTDIR/etc/riskmgr_pro.lst - list of actie prolog files RMINSTDIR/etc/riskmgr_cfg.lst - list of actie prolog configuration files Configuring the riskmgr_baroc.lst File: See Customize the BAROC List on page 46 for information on customizing the riskmgr_baroc.lst file. Configuring the riskmgr_rules.lst File: If you hae custom Tioli Enterprise Console rules that you want actie in your Tioli Risk Manager rule base, add your rules to the riskmgr_rules.lst file. 1. Add the file to the end of riskmgr_rules.lst. 2. Place your rules (.rls) file in the RMINSTDIR/etc/tec/rules directory. Notes: 1. A sample rules file showing how to enable RM_SensorEent eents to be used with Tioli NetView is included with the eent serer. To enable it, add hostname_remap.rls to the riskmgr_rules.lst file. 2. To actiate changes you hae made to the riskmgr_rules.lst file, use the rmcorr_cfg update command. See the IBM Tioli Risk Manager Command Reference for details on using this command. Configuring the riskmgr_pro.lst File: Do NOT change the riskmgr_pro.lst file. It is intended only for use by Customer Support. Configuring the riskmgr_cfg.list File: This file names the prolog configuration files that are used by the rule base. If you hae custom prolog for your custom rules, you can include your prolog file in riskmgr_cfg.lst. 1. Add the file to the end of riskmgr_cfg.lst. 2. Place your prolog (.pro) file in the RMINSTDIR/etc/tec/rules directory. Note: To actiate changes you hae made to the riskmgr_cfg.lst file, use the rmcorr_cfg update command. See the IBM Tioli Risk Manager Command Reference for details on using this command. Configuring the Rules Files The rules (.rls) files contain the Tioli Enterprise Console rules that are included in your rule base. The rule files are as follows RMINSTDIR/etc/tec/rules/riskmanager.rls RMINSTDIR/etc/tec/rules/boot.rls RMINSTDIR/etc/tec/rules/hostname_remap.rls Configuring the riskmanager.rls file: The riskmanager.rls file contains rules to: Route RM_SensorEent eents that hae not been included in correlation to the local agent. Perform Incident Group processing. 44 IBM Tioli Risk Manager: Administrator s Guide

59 Do NOT make changes to the riskmanager.rls file. If you need to hae custom rules for Tioli Risk Manager sensor or incident eents, you can write your own rules file and include it in the Tioli Risk Manager rule base. See Configuring the riskmgr_rules.lst File on page 44 for information relating to adding a rules file to the rule base. Configuring the boot.rls file: The boot.rls file contains rules to: Actiate the configuration options specified in the riskmanager_config.pro file. Ensure the Tioli Risk Manager rules and configuration settings are actie. If not, an RM_InputError eent will be generated at the Tioli Enterprise Console serer. Do NOT make changes to the boot.rls file. If you need to hae custom rules run when the Tioli Enterprise Console serer starts, you can write your own rules file and include it in the Tioli Risk Manager rule base. See Configuring the riskmgr_rules.lst File on page 44 for information on adding a rules file to the rule base. Configuring the hostname_remap.rls file: sample rules file containing rules to: The hostname_remap.rls file is a Set the hostname attribute of fully-processed RM_SensorEent eents to the rm_sensorhostname attribute alue. Set the adapter_host attribute to the composite string that Tioli Risk Manager sets as the hostname attribute. The rules in hostname_remap.rls file are not actie by default. See Configuring the riskmgr_rules.lst File on page 44 for information on enabling the rules contained in hostname_remap.rls. Enable the rules in hostname_remap.rls if you use Tioli NetView to respond to Tioli Risk Manager sensor eents or if you frequently use tasks in response to Tioli Risk Manager sensor eents. Tioli Risk Manager sets a composite string as the hostname attribute to allow the attack information to be iewed on the eent console. This composite string contains: The attack category The source of the attack The destination of the attack Performance Considerations You can modify the hostname_remap.rls file to remap the composite string to attributes other than adapter_host. Use the rmcorr_cfg update command to actie any changes you made to the hostname_remap.rls file. See the IBM Tioli Risk Manager Command Reference for details on using this command. Configuration options of the Tioli Enterprise Console serer and the Tioli Risk Manager eent serer might affect the Tioli Risk Manager eent serer performance. For example, the eent cache size affects the rule processing performance because it limits the number of eents actiely being processed by the rule base. Chapter 2. Eent Serer 45

60 Customize the BAROC List 1. Remoe any unneeded.baroc files that are specified in the RMINSTDIR/etc/riskmgr_baroc.lst file. This file contains a set of.baroc files that are loaded by the eent serer. You can remoe the.baroc files for any adapter or sensor that you will not deploy in your network. For example, if you are not using the old Netranger adapter or the ISS RealSecure adapter, remoe the following from the riskmgr_baroc.lst file: netranger.baroc realsecure.baroc 2. Position the adapters with the highest eent olume ahead of the other adapter.baroc files. 3. Add additional BAROC files for adapters that you will use in your network. Notes: 1. Do not remoe or reposition the first four entries in the riskmgr_baroc.lst file. root.baroc tec.baroc riskmanager.baroc sensor_abstract.baroc 2. You can reposition, but not remoe the rmagent.baroc entry from the riskmgr_baroc.lst file. 3. To actiate changes you hae made to the riskmgr_baroc.lst file, use the rmcorr_cfg update command. See the IBM Tioli Risk Manager Command Reference for details on using this command. Set Eent Cache Size In the Tioli Enterprise Console enironment, rules are applied to eents that are stored in an eent cache. When the cache fills up, eents are purged or they are no longer processed by the rules. A full eent cache affects correlation results so check the size of the eent cache. To check the size of the Tioli Enterprise Console eent cache on your Tioli Enterprise Console or Tioli Risk Manager serer use the wlsesrcfg command that is part of the Tioli Enterprise Console product. See the IBM Tioli Enterprise Console Reference Manual for details on using this command. The recommended alue for the size of the Tioli Enterprise Console eent cache size is 3000 entries. To change the size of the eent cache, type the following: wsetesrcfg -c 3000 Note: If your eent cache size is not configured properly, the Tioli Enterprise Console serer might clean the cache to allow the actie rules to process eents being receied. When the cache is cleaned in this fashion, the Tioli Enterprise Console serer issues a TEC_Notice eent with the message filed set to Rule Cache full: forced cleaning. When a forced cache cleaning occurs: Processing of existing incident group eents might appear to stop. This occurs if an existing RM_IncidentGroup eent does not receie additional eents to contribute to its processing. Duplication of incident group eents might occur in your eent repository. Duplication takes place if additional eents that contribute to the incident group arrie at the serer. The duplication occurs because the original instance of the RM_IncidentGroup eent has been remoed from 46 IBM Tioli Risk Manager: Administrator s Guide

61 the cache and is therefore no longer being processed by the rules. The original RM_IncidentGroup will not be updated (see preious bullet). Filtering Attributes You can filter your attributes so they are not sent to the Tioli Enterprise Console serer. At your agent and distributed correlation serer you can add an attribute to the eif_sender.conf file to configure it not to send some extended slots to the Tioli Enterprise Console serer. See the RMINSTDIR/etc/templates/sensoreent/attributefilter.xml file for an example of this filtering. For example, attributefilter=filename Set Instance Count on Agent Senders If you hae a high-olume of eent data, it is possible that one of your senders might become backlogged. You will notice the queue size growing when you use the wrmqueue l command. See the IBM Tioli Risk Manager Command Reference for details on using this command. You can tune Tioli Risk Manager to use multiple threads to process your eents on such senders. To do this, edit the rmagent.xml file and add instancecount="number" to the sender. For example, <sender name="eif_sender" class="com..." instance Count="8"> Tioli Risk Manager BAROC Files Each adapter and sensor includes a BAROC file that describes the classes of eents that it supports. The adapter or sensor typically does not use the BAROC file, but seres as a mandatory link between the adapter and eent serer. The Tioli Enterprise Console and Tioli Risk Manager correlation serer must load the BAROC file before they can understand eents that are receied from an adapter or sensor. BAROC files usually hae an extension of.baroc. Tioli Risk Manager proides a list of known BAROC files that are loaded by default. This file, RMINSTDIR/etc/riskmgr_baroc.lst, is shared between the rmcorr_cfg command, when working with your rule base, and the Tioli Risk Manager correlation agent, that uses it to determine what BAROC files to actiate for correlation. The Tioli Risk Manager BAROC files contain a hierarchy of eent classes. All eent classes inherit from the EVENT class. All Tioli Risk Manager eent classes inherit from RM_Eent. Tioli Risk Manager top-leel, abstract classes, and the component eent classes are defined in the BAROC files located in the RMINSTDIR/etc/baroc subdirectory. Table 2 describes the BAROC files included with Tioli Risk Manager. Table 2. BAROC Files BAROC File Name cpfw.baroc Type of Classes The adapter for Check Point FireWall 1 eent classes. Also, these eent classes define some generic firewall eents. The classes in this file depend on classes in the sensor_abstract.baroc file. Chapter 2. Eent Serer 47

62 Table 2. BAROC Files (continued) BAROC File Name crouter_snmp.baroc csids.baroc generic.baroc nids.baroc os.baroc os_linux.baroc os_unix.baroc os_windows.baroc pix.baroc realsecure.baroc riskmanager.baroc rmagent.baroc rmirus.baroc sensor_abstract.baroc Type of Classes The adapter for Cisco Routers eent classes. Also, these eent classes define the generic router eents. This file contains Cisco router class deriaties. The classes in this file depend on classes in the sensor_abstract.baroc file. The adapter for Cisco Secure IDS eent classes. The classes in this file depend on the classes in the sensor_abstract.baroc file. General purpose classes used to facilitate rapid adapter deelopment. The classes defined in this file depend upon those defined in the sensor_abstract.baroc file. The Tioli Risk Manager Network IDS eent classes. The classes in this file depend on classes in the sensor_abstract.baroc file. The adapter for Host IDS eent classes. The classes in this file depend on classes in the sensor_abstract.baroc file. Note: The BAROC file is deprecated. The Host IDS adapters currently use eent classes defined in generic.baroc The adapter for Host IDS on Linux. The eent classes in this file depend on classes from the os.baroc file. Note: The BAROC file is deprecated. The Host IDS adapters currently use eent classes defined in generic.baroc The adapter for Host IDS eent classes on UNIX (AIX and Solaris) operating systems. The classes in this file depend on the classes in the os.baroc file. Note: The BAROC file is deprecated. The Host IDS adapters currently use eent classes defined in generic.baroc The adapter for Host IDS on a Windows system. The eent classes in this file depend on classes from os.baroc. Note: The BAROC file is deprecated. The Host IDS adapters currently use eent classes defined in generic.baroc The adapter for Cisco Secure PIX Firewall eent classes. Also, these eent classes define some generic firewall eents. The classes in this file depend on classes in the sensor_abstract.baroc file. The adapter for ISS RealSecure host-based and network-based eent classes. The classes in this file depend on the classes in the sensor_abstract.baroc file. The Tioli Risk Manager classes used for correlation. Eents related to the agent actiity and configuration. The classes in this file depend on classes in the sensor_abstract.baroc file. The adapter for Norton AntiVirus eent classes and the adapter for the McAfee Alert Manager. Also, these eent classes define the generic antiirus eents. The eent classes in this file depend on classes in the sensor_abstract.baroc file. The top-leel, sensor-related abstract classes. Do not send instances of these classes to the Tioli Enterprise Console. The classes in this file depend on the classes in the riskmgr.baroc file. 48 IBM Tioli Risk Manager: Administrator s Guide

63 Table 2. BAROC Files (continued) BAROC File Name webids.baroc Type of Classes The Web IDS eent classes. The classes in this file depend on the classes in the sensor_abstract.baroc file. Chapter 2. Eent Serer 49

64 50 IBM Tioli Risk Manager: Administrator s Guide

65 Chapter 3. Database Database Structure The Tioli Risk Manager database is the repository of all eents processed by Tioli Risk Manager. This chapter details the database structure and how to maintain your database. The Tioli Risk Manager database consists of the following: The Tioli Enterprise Console Database The Tioli Enterprise Console tables and iews The Tioli Risk Manager tables and iews Tioli Enterprise Console Databases Tioli Risk Manager uses the same database as Tioli Enterprise Console, named TEC on all the supported databases For Tioli Risk Manager database support information, see IBM Tioli Risk Manager Release Notes. Tioli Enterprise Console Tables and Views The Tioli Enterprise Console database tables and schema are listed in the IBM Tioli Enterprise Console Reference Manual. These can be grouped into: The Reception Log table that is the tec_t_et_rec_log table. The Eent Repository tables that comprises the tec_t_et_rep, tec_t_slots_et, and tec_t_task_et tables Tables and iews for the eent console the objects are the tec console_list iew and the tec_t_consoles, tec_t_operators, tec_t_eent_groups, tec_t_eg_whrclause, tec_t_assign_op, and tec_t_assign_eg tables. Tables for the Tioli Enterprise Console rules processing the objects are the tec_t_isa, tec_t_enumerations, tec_t_status_eent, and tec_t_status_task tables Other tables and iews, that are not used by Tioli Risk Manager. Tioli Risk Manager Tables and Views Tioli Risk Manager adds database objects to the Tioli Enterprise Console database for four purposes: 1. Eent archiing 2. Web Application 3. Online reports (Crystal Reports) 4. Tioli Enterprise Data Warehouse (TEDW) Copyright IBM Corp

66 The objects added by Tioli Risk Manager are shown in Table 3. Table 3. Tioli Risk Manager Tables, Views and Other Database Objects Table or View rm_t_arc41 rm inc rm inc_sub rm inc_grp rm inc_grp_sub Description Tioli Risk Manager eent archie table. Eents are archied here by the Database Archier in the Tioli Risk Manager agent component. The eent archie is used by the Web Application, Online Reports (Crystal Reports), or Tioli Enterprise Data Warehouse (TEDW). View from the Tioli Enterprise Console Eent Repository tables that includes all Tioli Risk Manager Incident eents and their extended slots (defined in class RM_Incident). The incident iew is used by the Web Application to display incident eents that contribute to an incident group. View from the Tioli Enterprise Console Eent Repository tables that includes a subset of slots from all Tioli Risk Manager Incident eents. The subset incident iew selects the primary key (serer handle, eent handle, reception timestamp), eent status and incident group ID. This iew is used by the database utilities to close incident eents that contribute to an incident group. View from the Tioli Enterprise Console Eent Repository tables that includes all Tioli Risk Manager Incident Group eents and their extended slots (defined in class RM_IncidentGroup). View from the Tioli Enterprise Console Eent Repository tables that includes a subset of slots from all Tioli Risk Manager incident group eents. The subset incident group iew selects the primary key (serer handle, eent handle, reception timestamp), eent status, incident group ID and timestamp of the last incident in the group. This iew is used by the database utilities to close incident eents that contribute to an incident group. Eent Archie Table Creation As with the Tioli Enterprise Console, after you install the eent serer, you must create the Tioli Risk Manager database objects. For information on creating the archie table, see the IBM Tioli Risk Manager Installation Guide. Note: If you plan on using the following features of Tioli Risk Manager you are required to create the archie table. Eent archiing Web Application Online reports (Crystal Reports) Tioli Enterprise Data Warehouse (TEDW) Archie Table Definition The archie table (rm_t_arc41) definition is based on a subset of columns from the core Tioli Enterprise Console table (tec_t_et_rep) and selected Tioli Risk Manager-specific slots from the Tioli Enterprise Console slot table (tec_t_slots_et). Table 4 on page 53 describes the columns in the archie table and indicates their origin in the Tioli Enterprise Console Eent Repository database. Columns taken from the eent table (tec_t_et_rep) hae the same column name in the archie table, except where indicated in the origin Table column. Columns taken from the slot table (tec_t_slots_et) gie the slot name in parentheses. 52 IBM Tioli Risk Manager: Administrator s Guide

67 Table 4. Columns in the Archie Table and the Origin in the Tioli Enterprise Console Eent Repository Database Column Name Datatype Origin Table (Slot) Description SERVER_HNDL Integer tec_t_et_rep Unique ID for Tioli Enterprise Console serer (part of eent record key) DATE_RECEPTION Integer tec_t_et_rep Coordinated Uniersal Time (UTC) of eent reception, expressed in seconds since January 1, 1970 (part of eent record key). EVENT_HNDL Integer tec_t_et_rep Unique ID for eents with the same date_reception alue (part of eent record key) TIMESTAMP32 Integer tec_t_slots_et (rm_timestamp32) Coordinated Uniersal Time (UTC) of eent generation, expressed in seconds since January 1, TIME_EVENT Timestamp * tec_t_slots_et (rm_timestamp32) Date and time of eent (UTC) CLASS Varchar(64) tec_t_et_rep Eent class name VERSION Varchar(32) tec_t_slots_et (rm_version) Tioli Risk Manager release + CMVC ersion number for example, 4.1_1.2 EVENT_TYPE Varchar(16) tec_t_et_rep (SUB_SOURCE) Type of Tioli Risk Manager eent (IDS or Miscellaneous) ABSTRACT Varchar(128) tec_t_et_rep (HOSTNAME) Composite field of sensor hostname + destination hostname + source hostname + eent category MSG Varchar(255) tec_t_et_rep Descriptie message displayed on the Tioli Enterprise Console CORRELATED Varchar(5) tec_t_slots_et (rm_correlate) Was an eent used by the correlation engine to determine if an incident exists? Two possible alues: yes or no. CORRELATOR_HOST Varchar(128) tec_t_slots_et (rm_correlatedbyagent) Host that performed correlation, or N/A if no correlation. CORR_LEVEL Real tec_t_slots_et (rm_leel) Numeric specification of eent seerity used for threshold computations during eent correlation SEVERITY Varchar (16) tec_t_et_rep Seerity leel of eent REPEAT_COUNT Integer tec_t_et_rep Number of repeat occurrences of the same eent ADAPTER_HOST Varchar(128) tec_t_et_rep Name of host that the eent adapter that reported the eent is installed. SENSOR_TYPE Varchar(32) tec_t_et_rep (SUB_ORIGIN) Sensor type (netranger, webids, and so on) of reporting host Chapter 3. Database 53

68 Table 4. Columns in the Archie Table and the Origin in the Tioli Enterprise Console Eent Repository Database (continued) Column Name Datatype Origin Table (Slot) Description SENSOR_HOSTNAME Varchar(128) tec_t_slots_et (rm_sensorhostname) Name of host reporting eent SENSOR_IPADDR Varchar(32) tec_t_et_rep (ORIGIN) IP address of host reporting Eent SENSOR_OS Varchar(32) tec_t_slots_et (rm_sensoros) Type of operating system on host where sensor is installed SENSOR_TOKEN Varchar(128) rm_sensortoken Value assigned during eent normalization to a string that identifies the sensor (or adapter) type and the host name that the sensor (or adapter) is running. The rm_sensortoken uniquely identifies the sensor that identified the eent. SRC_TOKEN Varchar(128) tec_t_slots_et (rm_sourcehostname or rm_sourceipaddr) Normalized name of host identified as source of intrusion eent. Usually host name, if it is defined, or IP address. SRC_HOSTNAME Varchar(128) tec_t_slots_et (rm_sourcehostname) Name of host identified as source of intrusion eent SRC_IPADDR Varchar(32) tec_t_slots_et (rm_sourceipaddr) IP address of host identified as source of intrusion eent SRC_PORT Varchar(16) tec_t_slots_et (rm_srcport) Host port number (or name) identified as source of intrusion eent DST_TOKEN Varchar(128) tec_t_slots_et (rm_destinationhostname or rm_destinationipaddr) Normalized name of host identified as target of intrusion eent. Usually host name, if it is defined, or IP address. DST_HOSTNAME Varchar(128) tec_t_slots_et (rm_destinationhostname) Name of host identified as target of intrusion eent DST_IPADDR Varchar(32) tec_t_slots_et (rm_destinationipaddr) IP address of host identified as target of intrusion eent DST_PORT Varchar(16) tec_t_slots_et (rm_dstport) Host port number (or name) identified as target intrusion eent SIGNATURE Varchar(255) tec_t_slots_et (rm_signature) Descriptie string identifying intrusion eent CLASS_CAT_DESC Varchar(64) tec_t_slots_et (rm_classcategorydescription) Description of category used for eent correlation CLASS_CAT Varchar(16) tec_t_slots_et (rm_classcategory) Short name of category used for eent correlation PROTOCOL Varchar(32) tec_t_slots_et (rm_protocol) Communications protocol in use SERVICE Varchar(32) tec_t_slots_et (rm_sericename) Name of serice (Telnet, FTP, and so on) associated with the intrusion eent 54 IBM Tioli Risk Manager: Administrator s Guide

69 Table 4. Columns in the Archie Table and the Origin in the Tioli Enterprise Console Eent Repository Database (continued) Column Name Datatype Origin Table (Slot) Description CUSTOMER_ID Varchar(64) tec_t_slots_et (rm_customerid) Identifier for customer (indiidual or company) that is the target of the intrusion eent CATEGORY Varchar(32) tec_t_slots_et (rm_category) Miscellaneous eent category (access, configuration, policy, state, and so on) PRINCIPAL Varchar(64) tec_t_slots_et (rm_principal) User or group ID that initiated the miscellaneous eent OBJECT_TYPE Varchar(32) tec_t_slots_et (rm_objecttype) Miscellaneous eent object type (file, system, user, group, and so forth) OBJECT Varchar(128) tec_t_slots_et (rm_object) Miscellaneous eent object name (file name, host name, user name, user group, application name, and so on) SEC_OBJECT_TYPE Varchar(32) tec_t_slots_et (rm_secondaryobjecttype) Miscellaneous eent object type (file, system, user, group, and so forth). Second-leel object (for example, modify user ID within a group) SEC_OBJECT Varchar(128) tec_t_slots_et (rm_secondaryobject) Miscellaneous eent object name (file name, host name, user name, user group, application name, and so forth). Second-leel object. (for example, modify user ID within a group) ACTION Varchar(32) tec_t_slots_et (rm_action) Miscellaneous eent actions (create, modify, delete, start, stop, and so on) RESULT Varchar(32) tec_t_slots_et (rm_result) Miscellaneous eent result (success, complete, failure, denied and so on) VULN_ID_TYPE Varchar(32) tec_t_slots_et (rm_nametype) Type of Vulnerability Identifier (for example, CVE, BugTraq, endor-defined) VULN_ID Varchar(64) tec_t_slots_et (rm_nameid) ID of ulnerability (for example, from CVE) VULN_DATA Varchar(255) tec_t_slots_et (rm_namedata) Additional data about the ulnerability LOG_DATA Varchar(255) tec_t_slots_et (rm_logdata) Additional eent data FALSE_POS Varchar(16) tec_t_slots_et (rm_falsepositie) NO if not a false positie; else, the means that false positie was determined: OPERATOR, PROGRAM, other. FALSE_POS_ID Varchar(128) tec_t_slots_et (rm_falsepositieid) <NULL> if not a false positie; else, identifier of mechanism that determined the false positie, for example, name of operator, name of correlation host, and so on. Chapter 3. Database 55

70 Note: For DB2, type TIMESTAMP represents both the date and time. For Oracle and Microsoft SQL databases, TIME_EVENT is represented by types DATE and DATETIME, respectiely. Database Maintenance and Support Maintenance and support tools for the Tioli Risk Manager database are: Tioli Risk Manager Database Utilities Tioli Enterprise Console Data Management Utilities RDBMS Interface Module (RIM) Support Utilities Tioli Risk Manager Database Utilities Tioli Risk Manager proides command line utilities for maintaining the eent database. These are listed in Table 5. Table 5. Command Line Utilities for Maintaining the Eent Database. Command wrmdbclear (UNIX) wrmdbclear.cmd (Windows) wrmdbclose (UNIX) wrmdbclose.cmd (Windows) Purpose Remoes closed Tioli Risk Manager eents from the eent repository table and from the eent archie table. Remoes closed Tioli Risk Manager eents from the eent repository table and from the eent archie table. Closes Tioli Risk Manager eents in the eent repository table. Closes Tioli Risk Manager eents in the eent repository table. These utilities are described in detail below. Remoe Eents Program (wrmdbclear) The Remoe Eents program is used to remoe Tioli Risk Manager eents older than a user-specified time threshold, specified in hours. You are prompted for confirmation before the delete operation is carried out. The program can be used to remoe eents from both the Tioli Enterprise Console eent repository as well as the Tioli Risk Manager archie table, but not at the same time. It is necessary for the program to be inoked separately to remoe eents from the Tioli Enterprise Console eent repository and from the Tioli Risk Manager archie table. SYNTAX wrmdbclear -t hours [-D] [ -a -e ] [-b records] [-f] [-c configfile] [RIM_object] INPUT PARAMETERS t hours Age threshold; eents must be older than the number of hours specified. No default. Minimum alue is 0 (hours). For eents in the archie table or the eent repository, the time comparison is made against the reception time of the eent. If 0 (zero) is specified, all eents older than the current time when you run the command are remoed. D Debug; outputs debug and trace information to STDOUT. The default alue is no debugging. 56 IBM Tioli Risk Manager: Administrator s Guide

71 a Only eents in the Tioli Risk Manager archie table are remoed. The default alue is off. e Only Tioli Risk Manager eents in the Tioli Enterprise Console eent repository are remoed. The default alue is on. b records Deprecated: A database commit is performed after eery n number of records are deleted. The default alue is 100 records. Specifying this option has no effect on the operation of the command. f Forces remoal; does not display, Are you sure? prompt. The default alue is off. c configfile Allows you to optionally specify a configuration file that contains database configuration data for a database that is different from the one installed and configured with Tioli Risk Manager. The data in the file must be in the same format as the db_sender.conf file. The fully specified filename must be entered as a parameter. If this parameter is not specified, the ersion of the db_sender.conf file in the RMADHOME/etc directory is used to acquire the database configuration information. RIM_object Deprecated: RIM database where eents are stored. The default alue is tec. Specifying this option has no effect on the operation of the command. For more information about this command, see the IBM Tioli Risk Manager Command Reference. Close Eents Program (wrmdbclose) The Close Eents program can be used to close all Tioli Risk Manager eents older than a user-specified threshold. When used to close incident group eents, the program also closes all contributing incident eents. In addition, it sends a special eent, RM_CloseIncidentGroups, to the eent serer so that any existing correlation facts pertaining to the incident groups are purged from the Tioli Enterprise Console cache. One of the attributes included in this special eent is a shared secret key that is obtained from the RMINSTDIR/etc/tec/rules/riskmgr_flush.dat file. Run this command only from the Tioli Enterprise Console serer because it must hae access to the file containing a shared secret. SYNTAX wrmdbclose -t hours [-D] [-e -g -h -i -r -s] [-c configfile] [RIM_object] INPUT PARAMETERS t hours Age threshold; incidents and eents must be older than the number of hours specified. No default. Minimum alue is 0 (hours), that means close all eents. For incidents and incident groups, the time comparison is made against the time of the last contributing eent or incident, respectiely. For sensor eents, the time comparison is made against the reception time of the eent. D Debug; outputs debug and trace information to STDOUT. The default alue is no debugging. Chapter 3. Database 57

72 e Only internal error eents (class RM_Error) are closed. g Only incident group eents (class RM_IncidentGroup) and their contributing incidents (class RM_Incident) are closed. h Only trusted host eents (class RM_TrustedHost) are closed. i Only incident eents (class RM_Incident) are closed. r Only detected sensor host eents (class RM_Sensor) are closed. s Only sensor eents (class RM_SensorEent) are closed. c configfile Allows you to optionally specify a configuration file that contains database configuration data for a different database than the one installed and configured with Tioli Risk Manager. The data in the file must be in the same format as the db_sender.conf file. The fully specified filename must be entered as a parameter. If this parameter is not specified, the ersion of the db_sender.conf file in the RMADHOME/etc directory is used to acquire the database configuration information. RIM_object Deprecated: RIM database where eents are stored. The default alue is tec. Specifying this option has no effect on the operation of the command. For more information about this command, see the IBM Tioli Risk Manager Command Reference. Tioli Enterprise Console Data Management Utilities The Tioli Enterprise Console proides a number of utilities for accessing the Tioli Enterprise Console database data directly. These are listed in Table 6. Table 6. Tioli Enterprise Console Database Utilities Command wtdbclear wtdbclear.pl wtdbspace wtdbstat wtdumper wtdumprl wtdumptr Purpose Clears eents from the eent database Perl script that clears the database Proides statistics for the database Displays the status of the database Generates an eent report (dump the eent repository tables) Generates a report of receied eents (dumps the reception log) Generates a report of completed tasks (dumps the task table) These utilities are described in detail in the IBM Tioli Enterprise Console Reference Manual. All utilities listed in the table aboe access the database through the tec RIM object RIM Support Utilities Database access by the Tioli Enterprise Console is through the RIM. Some RIM utilities are useful for diagnosing problems with the Tioli Enterprise Console database. The RIM utilities are listed in Table 7. Table 7. RIM Utilities Command wcrtrim Purpose Creates a RIM object 58 IBM Tioli Risk Manager: Administrator s Guide

73 Table 7. RIM Utilities (continued) Command Purpose wgetrim Lists information about a RIM object wrimtest Verifies a RIM object s connectiity and functionality wrimtrace Enables or disables tracing for RIM objects. wsetrim Changes the database information for a RIM object wsetrimpw Sets the RIM password for a RIM object database wrimsql Runs SQL through the RIM object These utilities are described in the Tioli Management Framework Reference Manuals. Chapter 3. Database 59

74 60 IBM Tioli Risk Manager: Administrator s Guide

75 Chapter 4. Agent Oeriew The agent is a component of Tioli Risk Manager eent serer, client, distributed correlation serer, and gateway. The agent is a Jaa application that runs as a Linux daemon and UNIX-based system daemon or as a Windows serice. The agent is configured differently depending on the system configuration you chose during installation. By default, the Tioli Risk Manager installation program will create the appropriate agent configuration to support the system selections made during the installation process. This chapter proides information that will help you: Understand the agent Configuration elements of the agent Administer the agent after it is installed and automatically configured Deelop customized configurations of the agent. The agent proides flexibility in terms of the routing and filtering eents both within the agent and between the agent and remote eent destinations. Create a customized configuration to take adantage of this flexibility. The agent is an eent router that includes a correlation engine. The agent can modify eents it receies as well as create new eents based upon receied eent information or monitored system resources. The agent's configuration determines the processing that the agent does with eents it receies or generates. Each agent is configured with a set of sources, destinations, and connectors. Additionally, filters and an engine can be configured for the agent. Except for connectors, each of the settings is identified by a unique name. Sources Each source definition defines a subcomponent of the agent that receies eents from an eent source or generates eents as part of the subcomponent processing. Eents can be receied using a ariety of eent protocols, including unauthenticated sockets, and SSL. The Tioli Risk Manager eent monitor is an example of a subcomponent that identifies and generates eents. An agent can hae multiple sources configured. Destinations Each destination definition defines a subcomponent of the agent that sends eents to one or more receiing application. The receiing application can be another Tioli Risk Manager system, a Tioli Enterprise Console serer, or a relational database. An agent can hae multiple destinations configured. Engine An engine definition defines the subcomponent of the agent that performs eent analysis and correlation. The engine can be configured to perform simple eent summarization (the default configuration at the client) or to perform Tioli Risk Manager correlation (the default configuration at the serer). The agent can hae at most one engine defined. Connections Each connector defines an eent path between two subcomponents of the Copyright IBM Corp

76 agent. Each connector definition must include a from setting and a to setting. A connector can optionally include a filter to apply to the route between the two subcomponents. The from setting of a connector can be either a source or an engine. The to setting of a connector can be either an engine or a destination. Each engine and destination has an associated queue that allows the indiidual agent subcomponents to process eents at different rates. Filters Each filter defines a logical comparison that can be applied to eents. If the eent matches the filter, then it is routed to the destination specified in the connector that uses the filter. Eents that do not match the filter are not passed to the target (to) specified in the connector. The Figure 20 proides a iew of agent subcomponents. The bold, dotted arrows between the sources, engine, and destinations represent connections. A connection can be configured between any source and the engine, between any source and destination as well as between the engine and a destination. Each connection might also hae associated with it an optional filter. A filter is used to control the specific types of eents that flow oer a connection. Eent Sources: Tioli Enterprise Console Adapter (local or remote) Remote Agent Local Applications: C, Jaa and Perl Applications Sensors Examples: Tioli Risk Manager Web IDS Tioli Risk Manager Network IDS Check Point FireWall Adapter Cisco Secure IDS Adapter Tioli Risk Manager Agent Formatted Eents Unformatted Eents Tioli Risk Manager EIF Shared Library Unformatted Eents Files DBTables Windows Eent Log Syslog (FIFO) Heartbeat Eents XML Rules Receier (SSL) Receier (Sockets) Formatted Eents XML Formatting Rules Eent Monitor Formatted Eents XML Formatting Rules Correlation Summary Heartbeat Queue Summarization or Correlation Engine Queue Queue Queue Queue Sender (TME) Sender (Sockets) Sender (SSL) Sender (JDBC) Remote Eent Destinations: Eent Serer (TME, SSL and Sockets) Distributed Correlation Serer or Gateway (SSL and Sockets) Database Serer (JDBC) Figure 20. Agent Elements 62 IBM Tioli Risk Manager: Administrator s Guide

77 Agent Configuration The agent configuration information is located in the RMINSTDIR/etc directory. The top-leel configuration file for the agent is the rmagent.xml file. This file references other configuration files that are actiely used by the agent subcomponents. The second-leel configuration files are also located in the RMINSTDIR/etc directory. Top-Leel Configuration File (rmagent.xml) The top-leel configuration file, rmagent.xml, contains the definitions for the actie subcomponents (source, engine, or destination) of the agent and specifies the eent paths between the subcomponents. The subcomponent definitions typically include a reference to a separate configuration file. These second-leel configuration files define the behaior associated with the subcomponent. Subcomponent Definitions (Sources, Destinations, and Engines) Each subcomponent definition must contain the following elements: A unique name A alid class Zero or more configuration settings specifying a key with an associated alue The class specified for each subcomponent is the actual Jaa class name of the component that performs the required eent processing. For example, the following can be defined in the rmagent.xml file as a source. This source receies eents into the agent. The configuration file for this source is /IBM/RISKMGR/etc/eif_receier.conf. <source name="eif_receier" class="com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier"> <set key="rma_conf" alue="/ibm/riskmgr/etc/eif_receier.conf"/> </source> Continuing the example, the following can be defined in the rmagent.xml file as a destination. This destination forwards eents to another system. The configuration file for this destination is /IBM/RISKMGR/etc/eif_sender.conf. <destination name="eif_sender" class="com.tioli.riskmanager.agent.transports.senders.rmaeifsender"> <set key="rma_conf" alue="/ibm/riskmgr/etc/eif_sender.conf"/> </destination> Additionally, destinations can be configured to hae an instancecount setting. Using an instancecount greater than one causes multiple instances of the destination class to be created. Each instance runs in its own thread, that allows for oerlapping of eent processing. Your agent might experience improed through put if you specify an instancecount for the normal eent destination classes: com.tioli.riskmanager.agent.transports.senders.rmaeifsender com.tioli.riskmanager.agent.transports.senders.rmaarchiedbsender For example, to hae four threads processing eents on the eif_sender: <destination name="eif_sender" class="com.tioli.riskmanager.agent.transports.senders.rmaeifsender" instancecount="4"> <set key="rma_conf" alue="/ibm/riskmgr/etc/eif_sender.conf"/> </destination> Chapter 4. Agent 63

78 Aailable Classes The following alues are alid to use as the class setting for source components: com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat The following alues are alid to use as the class setting for the engine component: com.tioli.riskmanager.agent.engine.engine The following alues are alid to use as the class setting for destination components: com.tioli.riskmanager.agent.transports.senders.rmaeifsender com.tioli.riskmanager.agent.transports.senders.rmaarchiedbsender com.tioli.riskmanager.agent.transports.senders.rmasendtofile com.tioli.riskmanager.agent.transports.senders.rmasendtostdout com.tioli.riskmanager.agent.transports.senders.rmasendtostderr Notes: 1. Typically the rmasendtofile, rmasendtostdout, and rmasendtostderr destination classes are used only to assist in diagnosing problems that are encountered by the agent. 2. Do not specify instancecount greater than one for the diagnostic destination classes. This will cause unpredictable behaior. 3. The classes listed aboe are included in the default installation of the agent. You can hae additional classes aailable at your installation. For example, there are adapters that include classes that are configured as agent source components. The documentation that is proided with your adapters should describe the adapter configuration. Linking the Agent Subcomponents (Connectors) Connectors define an eent paths between two subcomponents of the agent. Each connector definition must contain the following elements: from to A connector might also include the following elements: withfilter priority The from setting of a connector can be either a source or an engine. The unique name of the source or engine is specified as the from name=alue. The to setting of a connector can be either an engine or a destination. The unique name of the engine or destination is specified as the to name=alue. The withfilter setting of a connector specifies the unique name of a filter. The priority setting of a connector specifies the priority of eents passing through the connector. Valid priority settings are normal and high. You can specify multiple filtered connectors between the same two subcomponents, and you can set the priority to high for eents matching a specific filter. This would cause eents matching the specific filter to be processed at the destination at a higher priority than eents processed at normal priority. If you do create multiple connectors 64 IBM Tioli Risk Manager: Administrator s Guide

79 between the same two subcomponents, you must erify that your filters are defined properly or your eents could be routed to the same subcomponent more than once. For example, the following connector specifies an eent path between a source named eif_receier and an engine named summary_engine. <connector> <from name="eif_receier"/> <to name="summary_engine"/> </connector> Similarly, the following connector conditionally routes eents that are produced by the engine named correlation to the destination named db_sender. In this case, a filter named DB_Sender is applied to the eent path. If eents processed by the engine do not match this filter, they are not routed to the destination. <connector> <from name="correlation"/> <to name="db_sender"/> <withfilter name="db_sender"/> </connector> The following example demonstrates using the connector priority specification to send both incidents and non-incident eents to the same sender named eif_sender from an engine named correlation with incident eents being processed at high priority. <connector priority="high"> <from name="correlation"/> <to name="eif_sender"/> <withfilter name="incidents"/> </connector> <connector> <from name="correlation"/> <to name="eif_sender"/> <withfilter name="nonincidents"/> </connector> Filters Filters are uniquely named components that are associated with connectors. The filtering process can be based on combinations of eent class name, attribute alues, and eent class inheritance. Please note that filtering based upon class inheritance requires knowledge of the class hierarchy as defined in the Tioli Risk Manager BAROC files. Typically, only the Tioli Risk Manager eent serer (installed on the Tioli Enterprise Console serer) and the distributed correlation serer include these BAROC files. Filters support the basic logic structures using <AND>, <OR> and <NOT> tags, that can be nested. Nested within the basic logic structure tags, you can specify that eents must match: eent class names attribute alues eent class inheritance Specifying a class name filter component To specify that an eent must match a classname, use the <classname> tag. The <classname> tag is specified as follows: Chapter 4. Agent 65

80 <classname matchtype=[contains equals startswith] alue="class name" /> For example, to specify that you want only eents whose classname starts with "WW_" to pass this filter, specify the following: <classname matchtype="startswith" alue="ww_" /> Specifying an attribute alue filter component To specify that an eent must hae a specific attribute setting, use the <field> tag. The <field> tag is specified as follows: <field name="attribute name" matchtype=[contains equals startswith] alue="class name" /> For example, to specify that you want only eents whose seerity is CRITICAL to pass this filter, specify the following: <field name="seerity" matchtype="equals" alue="critical" /> Specifying a class inheritance filter component To specify that an eent must inherit from a specific eent class, use the <isa> tag. The <isa> tag is specified as follows: <isa alue="parent class name" /> For example, if you want only eents that inherit from RM_Incident to pass this filter, specify the following: <isa alue="rm_incident" /> If you use an <isa> tag at an agent that does not hae class hierarchy information, only eents whose classname exactly matches the alue setting will pass the filter. What do the classes do (Source, Destination, Engine)? com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier This class receies eents oer a socket. The socket can be either unsecure or secured with SSL. com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier This class extracts information from a ariety of sources and formats the information into Tioli Risk Manager eents. See the IBM Tioli Risk Manager Adapters Guide for information on using the Tioli Risk Manager eent monitor. com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat This class generates a heartbeat eent, RM_HeartBeat, at the specified frequency. com.tioli.riskmanager.agent.engine.engine This class summarizes, normalizes, and correlates eents. com.tioli.riskmanager.agent.transports.senders.rmaeifsender This class sends eents to a remote application using arious protocols. Aailable protocols include, socket, SSL socket, and TME. com.tioli.riskmanager.agent.transports.senders.rmaarchiedbsender This class routes eents to the Tioli Risk Manager archie table. This class uses JDBC to insert information into the archie table. com.tioli.riskmanager.agent.transports.senders.rmasendtofile 66 IBM Tioli Risk Manager: Administrator s Guide

81 This class routes eents to an ASCII file. This class is typically used for diagnosing problems that are encountered by the agent. com.tioli.riskmanager.agent.transports.senders.rmasendtostdout This class routes eents to the system standard output. This class is typically used for diagnosing problems that are encountered by the agent. com.tioli.riskmanager.agent.transports.senders.rmasendtostderr This class routes eents to the system-standard error output. This class is typically used for diagnosing problems encountered by the agent. Note: The rmasendtostdout and rmasendtostderr diagnostic classes display their output to the console. See Starting and Stopping the Agent on page 76 for information on starting the agent from the command line. Queues and Eent Persistence Each subcomponent of the agent that is referenced in the rmagent.xml file as a to setting in a connector has a queue associated with its processing. Eents that the subcomponent needs to process are put on the associated queue by the subcomponent specified as the from setting in the connector. The processing subcomponent remoes the eents from the queue when it is ready to process eents. By default, the eents are persisted to disk when they are placed on a queue. When the processing subcomponent completes its task, the eent is remoed from disk. You can configure both engine and destination component queues to not persist eents to a disk. To turn off persistence, edit the rmagent.xml file and add persist="no" to the subcomponent definition. For example, <destination name="eif_sender" class="com.tioli.riskmanager.agent.transports.senders.rmaeifsender" persist="no" > </destination> Why would you turn off persistence? The processing might be faster since you bypass writing eent data to disk and remoing it later. Why would you NOT turn off persistence? Your system does not hae unlimited memory aailable to the agent. If the eents are not persisted to disk, they must be maintained in memory. You do not want to lose eents if an unexpected error condition causes the agent to terminate. With persistence off, you might lose eent data. Should you turn off persistence? The option to turn off persistence is deprecated. You are strongly encouraged to use the default, persist="yes"for all of your agent s queues. Second-Leel Configuration Files The rmagent.xml file is a file that brings together the arious elements of the agent. As shown in the preious section, the rmagent.xml file contains the source, destination, engine, connector, and filtered destinations needed for the agent to perform it s configured role. Each source, destination, and engine typically includes Chapter 4. Agent 67

82 its own configuration file. By conention, these second-leel configuration files hae a suffix of.conf and referenced in the rmagent.xml file as the RMA_conf parameter setting. sending and receiing eents eent analysis and correlation archiing eents to a database table producing heartbeat eents capturing information from eent sources Second-Leel Configuration Files for Sending and Receiing Eents Classes using this type of configuration file include: com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier com.tioli.riskmanager.agent.transports.senders.rmaeifsender These configuration files contain the definitions needed to send or receie eents oer Tioli Enterprise Console protocols, that include SOCKET, SSL, and TME. The configuration parameters that are contained in this type of second-leel configuration file are defined in Appendix A, Eent Integration Facility Sender and Receier Keywords, on page 195. You can also specify an attributefilter=<filename> setting for the rmaeifsender component to minimize the number of extended attributes that are included with the eent being sent to your Tioli Enterprise Console serer. You would selectiely filter attributes if you hae configured your Tioli Risk Manager to send eents to the Tioli Risk Manager archie table and do not need the specific attributes to be included at your eent console. You can also use filter attributes if your Tioli Enterprise Console database grows too quickly or your Tioli Enterprise Console serer experiences performance degradation when the extended attributes are included with the eents. To specify that an attribute is not to be included with the eent data sent to the Tioli Enterprise Console, specify forward="no" in the attributefilter file. The processing of the settings in the attributefilter XML file is from the top down. The following is an example of an XML file that contains the definition of attributes to filtered, forward="no". <filterattributes> <filter name="all_rm_sensoreents"> <AND> <isa alue="rm_sensoreent" /> </AND> </filter> <foreents matchingfilter="all_rm_sensoreents"> <attribute name="seerity" forward="yes" /> <attribute name="source" forward="yes" /> <attribute name="sub_source" forward="yes" /> <attribute name="sub_origin" forward="yes" /> <attribute name="origin" forward="yes" /> <attribute name="hostname" forward="yes" /> <attribute name="msg" forward="yes" /> <attribute name="status" forward="no" /> <attribute name="adapter_host" forward="yes" /> <attribute name="repeat_count" forward="yes" /> <attribute name="rm_timestamp" forward="yes" /> <attribute name="rm_timestamp32" forward="no" /> <attribute name="rm_timestampfmt" forward="no" /> <attribute name="rm_version" forward="no" /> 68 IBM Tioli Risk Manager: Administrator s Guide

83 <attribute name="rm_correlate" forward="yes" /> <attribute name="rm_correlatedbyagent" forward="no" /> <attribute name="rm_leel" forward="yes" /> <attribute name="rm_sensortype" forward="no" /> <attribute name="rm_sensorhostname" forward="no" /> <attribute name="rm_sensortoken" forward="yes" /> <attribute name="rm_sensoripaddr" forward="no" /> <attribute name="rm_sensorpid" forward="yes" /> <attribute name="rm_sensoros" forward="no" /> <attribute name="rm_sourcetoken" forward="yes" /> <attribute name="rm_sourcehostname" forward="no" /> <attribute name="rm_sourceipaddr" forward="no" /> <attribute name="rm_srcport" forward="no" /> <attribute name="rm_spoofedsourceknown" forward="no" /> <attribute name="rm_destinationtoken" forward="yes" /> <attribute name="rm_destinationhostname" forward="no" /> <attribute name="rm_destinationipaddr" forward="no" /> <attribute name="rm_dstport" forward="no" /> <attribute name="rm_signature" forward="yes" /> <attribute name="rm_description" forward="no" /> <attribute name="rm_priority" forward="no" /> <attribute name="rm_classcategory" forward="no" /> <attribute name="rm_classcategorydescription" forward="no" /> <attribute name="rm_protocol" forward="no" /> <attribute name="rm_sericename" forward="no" /> <attribute name="rm_customerid" forward="no" /> <attribute name="rm_category" forward="no" /> <attribute name="rm_principal" forward="no" /> <attribute name="rm_objecttype" forward="no" /> <attribute name="rm_object" forward="no" /> <attribute name="rm_secondaryobjecttype" forward="no" /> <attribute name="rm_secondaryobject" forward="no" /> <attribute name="rm_action" forward="no" /> <attribute name="rm_result" forward="no" /> <attribute name="rm_nametype" forward="no" /> <attribute name="rm_nameid" forward="no" /> <attribute name="rm_namedata" forward="no" /> <attribute name="rm_logdata" forward="no" /> <attribute name="rm_falsepositie" forward="no" /> <attribute name="rm_falsepositieid" forward="no" /> <attribute name="rm_comment" forward="no" /> <attribute name="rm_portcount" forward="no" /> <attribute name="rm_icmpcode" forward="no" /> <attribute name="rm_icmptype" forward="no" /> <attribute name="rm_reason" forward="no" /> <attribute name="rm_toolname" forward="no" /> <attribute name="rm_content" forward="no" /> <attribute name="rm_file" forward="no" /> <attribute name="rm_thirdhost" forward="no" /> <attribute name="rm_thirdport" forward="no" /> <attribute name="rm_user" forward="no" /> <attribute name="rm_password" forward="no" /> <attribute name="rm_domain" forward="no" /> <attribute name="rm_community" forward="no" /> <attribute name="rm_trojan" forward="no" /> <attribute name="rm_oid" forward="no" /> <attribute name="rm_command" forward="no" /> <attribute name="rm_args" forward="no" /> <attribute name="rm_localuser" forward="no" /> <attribute name="rm_remoteuser" forward="no" /> <attribute name="rm_address" forward="no" /> <attribute name="rm_url" forward="no" /> <attribute name="rm_cgi" forward="no" /> <attribute name="rm_ptyinfo" forward="no" /> <attribute name="rm_pid" forward="no" /> <attribute name="rm_name" forward="no" /> <attribute name="rm_state" forward="no" /> Chapter 4. Agent 69

84 <attribute name="rm_husername" forward="no" /> <attribute name="rm_huserid" forward="no" /> <attribute name="rm_huserdomain" forward="no" /> <attribute name="rm_hupurpose" forward="no" /> <attribute name="rm_huadditional" forward="no" /> <attribute name="rm_hutuaccountname" forward="no" /> <attribute name="rm_hutuaccountid" forward="no" /> <attribute name="rm_hutuaccountdomain" forward="no" /> <attribute name="rm_hutupurpose" forward="no" /> <attribute name="rm_hutuadditional" forward="no" /> <attribute name="rm_hutprocessid" forward="no" /> <attribute name="rm_hutprocessname" forward="no" /> <attribute name="rm_hutfilename" forward="no" /> <attribute name="rm_hutaccessflags" forward="no" /> <attribute name="rm_systemsuccess" forward="no" /> <attribute name="rm_systemfailure" forward="no" /> <attribute name="rm_logonsuccess" forward="no" /> <attribute name="rm_logonfailure" forward="no" /> <attribute name="rm_objectaccesss" forward="no" /> <attribute name="rm_objectaccessf" forward="no" /> <attribute name="rm_priilegeuses" forward="no" /> <attribute name="rm_priilegeusef" forward="no" /> <attribute name="rm_detailedtrackings" forward="no" /> <attribute name="rm_detailedtrackingf" forward="no" /> <attribute name="rm_policychanges" forward="no" /> <attribute name="rm_policychangef" forward="no" /> <attribute name="rm_accountmgmts" forward="no" /> <attribute name="rm_accountmgmtf" forward="no" /> </foreents> </filterattributes> Second-Leel Configuration Files for Eent Analysis and Correlation: using this type of configuration file include: com.tioli.riskmanager.agent.engine.engine Classes These configuration files contain the definitions used by the Tioli Risk Manager state-based correlation engine to analyze and correlate eents. The default configuration file associated with the engine depends upon the system configuration of the agent. A client s engine definition will refer to a summary engine configuration file, summary_engine.conf, that includes a set of parameters identifying indiidual summary rule files. See Chapter 6, Eent Summarization, on page 89 for more information about using and deeloping summarization rules. An eent serer s engine definition will reference an incident engine configuration file, incident_engine.conf, that includes a set of parameters that are additional configuration files. For example, the following can be included in the incident_engine.conf file. rules=/ibm/riskmgr/etc/incident_rules.xml rules=/ibm/riskmgr/etc/monitor_heartbeat_rules.xml barocfiles=/ibm/riskmgr/etc/riskmgr_baroc.lst categoryfile=/ibm/riskmgr/etc/categories.xml attributemap=/ibm/riskmgr/etc/attributemap.xml hostsfile=/ibm/riskmgr/etc/hosts.xml sensorsfile=/ibm/riskmgr/etc/sensors.xml linkedeentsfile=/ibm/riskmgr/etc/linkedeents.xml jittertime= IBM Tioli Risk Manager: Administrator s Guide

85 See Chapter 2, Eent Serer, on page 39 for more information about configuring the incident-based correlation engine and the use of BAROC files. See Heartbeat Monitoring on page 87 for more information about heartbeat monitoring and the action to take when heartbeat eents are not receied in a timely fashion. Second-Leel Configuration Files for Archiing Eents to a Database Table: Classes using this type of configuration file include: com.tioli.riskmanager.agent.transports.senders.rmaarchiedbsender The configuration file associated with the database sender is db_sender.conf. See Appendix B, Database Archie Configuration, on page 205 for more information on configuring the database sender component. Second-Leel Configuration Files for Producing Heart Beat Eents: using this type of configuration file include: com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat Classes The configuration file associated with a heartbeat is the heartbeat.conf file. See Heartbeat Monitoring on page 87 for more information about heartbeat monitoring and the action to take when heartbeat eents are not receied in a timely fashion. Second-Leel Configuration Files for Capturing Information From Eent Sources: Classes using this type of configuration file include: com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier This configuration file is associated with capturing information from eent sources using the eent monitor is defined as adaptername.conf where adaptername represents a name associated with an indiidual eent source or adapter. See the IBM Tioli Risk Manager Adapters Guide for more information about configuring an instance of the eent monitor. Other Configuration Files In addition to the configuration files referenced in the rmagent.xml file, there are two ancillary configuration files used by the agent. These files are located in the RMINSTDIR/etc directory. rmad.conf This file contains two types of configuration information: The agent s administratie port, RmagentPort. The default RmagentPort is This port is used by local administratie utilities, such as wrmqueue and wrmadmin, to communicate with the agent. See the IBM Tioli Risk Manager Command Reference for details on using these commands. The Tioli Risk Manager EIF API uses information in this file to control its connections to the agent s eent reception port. Applications using the Tioli Risk Manager EIF API are essentially adapters that submit eents from the local application to the agent for processing. The Tioli Risk Manager EIF API obtains the agent s eent reception port (type=socket) alue by scanning eif_receier.conf and local_only_receier.conf for the port used by the agent to receie eents oer the SOCKET protocol. Default parameters alues in the rmad.conf file include: ConnectionMode=connection_oriented BufEtPath=c:\IBM\RISKMGR\persistence\rmeif.cache (for example) Chapter 4. Agent 71

86 See Appendix A, Eent Integration Facility Sender and Receier Keywords, on page 195 for more information on these parameters and others that might be set in the rmad.conf file. rmclasspath.conf This file defines the set of Jaa jar files that need to be included in the agent s class path. Typically, there is no need to customize this file. Howeer, certain additional adapters might require that you add their jar file to this file. Also, you might need to modify the zip or jar file used for JDBC if you upgrade your database. On the Tioli Enterprise Console serer, there is an additional configuration file, rmlocal.conf. The Tioli Risk Manager prolog rules use the alues in this file to route unprocessed Tioli Risk Manager sensor eents to the local agent. The port specified in rmlocal.conf must match a alid port on the agent. That is, the same port specified in either in local_only_receier.conf or eif_receier.conf must be set in the rmlocal.conf file. Relationship of the Configuration Files The following diagrams show the relationship of the configuration files for the arious default system configurations. Client Eent Serer Distributed Correlation Serer Gateway Client System Configuration Figure 21 on page 73 depicts a typical configuration for a client. 72 IBM Tioli Risk Manager: Administrator s Guide

87 Agent as Client rmagent.xml local_only_receier.conf linuxhids.conf Eent Monitor Receier o o o aixhids.conf Eent Monitor Receier webids.xml (formatting) nids.xml (formatting) linuxhids.xml (formatting) o o o aixhids.xml (formatting) eif_sender.conf CPFW_summary_rules.xml rmad.conf summary_engine.conf CSIDS_summary_rules.xml NIDS_summary_rules.xml rmclasspath.conf heartbeat.conf PIX_summary_rules.xml RS_summary_rules.xml Figure 21. Client Configuration Eent Serer System Configuration Figure 22 on page 74 depicts a typical configuration for Tioli Risk Manager deployed on a Tioli Enterprise Console serer. Chapter 4. Agent 73

88 Agent as Eent Serer Deployed on a Tioli Enterprise Console Serer rmagent.xml rmad.conf local_only_receier.conf eif_receier.conf incident_sender.conf nonincident_sender.conf incident_engine.conf webids.xml (formatting) nids.xml (formatting) incident_rules.xml monitor_heartbeat.xml riskmgr_baroc.lst attributemap.xml rmclasspath.conf rmlocal.conf db_sender.conf heartbeat.conf hosts.xml sensors.xml linkedeents.xml Figure 22. Eent Serer Configuration Distributed Correlation Serer System Configuration Figure 23 on page 75 depicts a typical configuration for a distributed correlation serer. 74 IBM Tioli Risk Manager: Administrator s Guide

89 Agent as Distributed Correlation Serer rmagent.xml eif_receier.conf heartbeat.conf incident_sender.conf nonincident_sender.conf webids.xml (formatting) nids.xml (formatting) incident_rules.xml monitor_heartbeat.xml riskmgr_baroc.lst rmad.conf rmclasspath.conf db_sender.conf incident_engine.conf attributemap.xml hosts.xml sensors.xml linkedeents.xml Figure 23. Distributed Correlation Serer Configuration Gateway System Configuration Figure 24 on page 76 depicts a typical configuration for a gateway. Chapter 4. Agent 75

90 Agent as Gateway eif_receier.conf webids.xml (formatting) nids.xml (formatting) heartbeat.conf rmagent.xml eif_sender.conf rmad.conf rmclasspath.conf Figure 24. Gateway Configuration Administering the Tioli Risk Manager Agent The agent includes a set of commands to do the following: Starting and Stopping the Agent Managing the Agent Queues on page 78 Managing Agent DNS Processing on page 79 Creating and Managing Secure Sockets Layer Keystores on page 79 Stashing Passwords on page 80 Starting and Stopping the Agent Use the wrmadmin command to manage the agent. This command is aailable on all operating systems supported by the agent, and proides the capability of obtaining status, starting and stopping indiidual components, and terminating and restarting the agent. See the rmagent.xml file for specific component names. For more information on this file, see Top-Leel Configuration File (rmagent.xml) on page IBM Tioli Risk Manager: Administrator s Guide

91 On Linux and UNIX-based systems, you must set up the Tioli Risk Manager enironment by running:. /etc/tioli/rma_eif_en.sh SYNTAX wrmadmin [-i ] [-r component name... ] [-s component name... [ -k] INPUT PARAMETERS i or info Displays ersion information and status of indiidual agent components (actie or inactie). For example, when using the i option you might see the following status information displayed for a running agent: Tioli Risk Manager Component Status ========================================== Receiers eif_receier: Running heartbeat: Stopped Engines correlation: Unknown Destinations db_sender: Failed Retrying eif_sender: Instance 1 of 3: Running Instance 2 of 3: Failed Retrying Instance 3 of 3: Running where: Running The specified Tioli Risk Manager component is running. Stopped The specified Tioli Risk Manager component has stopped. Failed Retrying The specified Tioli Risk Manager component has encountered an error in processing and is retrying. Unknown The status of the specified Tioli Risk Manager component is unknown. r component name or restart component name Stops and then restarts one or more of the agent components. If there is no component name specified, the agent will be stopped and restarted. This option is used to actiate agent configuration changes. The i option will automatically run when using the r option. s component name or stop component name Stops one or more of the agent components. The i option will automatically run when using the s option. k or kill Terminates the agent daemon. Use this option for a shutdown. Notes: 1. See the rmagent.xml file for specific component names. For more information on this file, see Top-Leel Configuration File (rmagent.xml) on page 63. Chapter 4. Agent 77

92 2. Component name refers to the sources, destination, or engine name defined in the rmagent.xml configuration file. 3. When the rmcorr_cfg command is used to update the Tioli Risk Manager eent serer on the Tioli Enterprise Console serer, the agent will automatically restart. Both the Tioli Enterprise Console serer and the agent are stopped and restarted when the install, update and reconfig options are used with the rmcorr_cfg command. See IBM Tioli Risk Manager Command Reference for details on using this command. On Windows systems, you can also stop and start the agent using the following commands: net stop rmagent net start rmagent For more information on this command, see the IBM Tioli Risk Manager Command Reference. Managing the Agent Queues Use the wrmqueue command to monitor and manage the agent queues. Each subcomponent of the agent that is referenced in the rmagent.xml file as a to setting in a connector has an a queue associated with its processing. Eents that the subcomponent needs to process are put on the associated queue by the subcomponent specified as the from setting in the connector. The processing subcomponent remoes the eents from the queue when it is ready to process eents. If the processing subcomponent is not able to keep up with the eent flow, the number of eents in the queue will grow. Queue information is maintained in the following directories: RMINSTDIR/persistence/engines (queues for any engines) RMINSTDIR/persistence/senders (queues for any sender destinations) SYNTAX wrmqueue [-h -l -p -x] queue_name INPUT PARAMETERS h or help Displays a help message. l or list Lists the name, number of eents, and types of all queues. p or purge Clears one specific queue (specified on the command-line). x or purgeall Clears the queue. OUTPUT Returns a simple text-based table detailing the results of the request. If listing queues, the table consists of queue names, the number of eents in each queue, and the type of each queue. If purging queues, the table consists of queue names, the number of eents purged, and the amount of time it took to purge each queue. USAGE 78 IBM Tioli Risk Manager: Administrator s Guide

93 At least one option must be specified. If the p option is specified, it must be accompanied by a queue name. When using the p and x options please note that eents in the purged queues will be lost. When purging a queue it will remoe all unprocessed eents from the queue. Purged eents will no longer be processed. For more information on this command, see the IBM Tioli Risk Manager Command Reference. Managing Agent DNS Processing Use the wrmdns command to display and control the Tioli Risk Manager DNS. This is configured in the agent s engine component configuration file with the RMA_conf parameter. Tioli Risk Manager eent correlation matches the source and target of attacks using a tokenized identifier of the machines inoled. The tokenized identifier is either the host name, preferably fully-qualified, or the IP address of the machine. Since dynamically assigned IP addresses are becoming increasingly prealent, consistently identifying a single machine is an increasingly difficult task. To assist in properly identifying a machine (creating the correct tokenized identifier), Tioli Risk Manager proides an optional interface to your local DNS to map selected IP addresses to fully-qualified host names. By default, the agent does not map IP addresses to host names. SYNTAX wrmdns [-listcache -clearcache -statistics -resole ipaddr -on -off] INPUT PARAMETERS -listcache Lists the contents of the DNS cache. -statistics Displays performance statistics from the DNS cache -clearcache Clears the DNS cache. -resole ipaddr Proides DNS resolution on a single IP address -on -off Turns on DNS resolution. The default alue is off. Turns off DNS resolution. For more information on this command, see the IBM Tioli Risk Manager Command Reference. Creating and Managing Secure Sockets Layer Keystores See, Appendix C, Secure Socket Layer Introduction and ikeyman, on page 209 for information on SSL, ikeyman, and Keytool. Chapter 4. Agent 79

94 Stashing Passwords Use the wrmstashpw command to conert a clear-text password into an obfuscated form and store it in a file. It is also used to stash passwords for SSL, JDBC, Web Application, and the Tioli Risk Manager eent serer. SYNTAX wrmstashpw filename [password] INPUT PARAMETERS filename password Filename where obfuscated password is stored. A clear text password. If not supplied, enter a new password at prompt. For more information on this command, see the IBM Tioli Risk Manager Command Reference. Secure Sockets Layer Usage Information Setting Up JDBC Driers See Appendix C, Secure Socket Layer Introduction and ikeyman, on page 209 for Secure Sockets Layer (SSL) oeriew information. In order for an eent serer or distributed correlation serer to archie Tioli Risk Manager eents to the Tioli Risk Manager archie table, the agent must be configured properly to use a JDBC drier. The JDBC drier is used to communicate with the RDBMS. The installation program will prompt for the proper parameters for setting up the JDBC drier connection. For information on setting up JDBC driers, see Appendix B, Database Archie Configuration, on page 205. For more information on JDBC drier paths, see the IBM Tioli Risk Manager Installation Guide. 80 IBM Tioli Risk Manager: Administrator s Guide

95 Chapter 5. Engine Configuration Eent Pre-Normalization This chapter will help you understand the arious options that can be configured in the agent s engine component. The engine component definition specified in RMINSTDIR/etc/rmagent.xml uses Jaa class, com.tioli.riskmanager.agent.engine.engine. It requires a RMA_conf parameter, that includes the file name of the engine s component configuration file. If the RMA_conf parameter is not specified, the engine does not perform any eent analysis, but instead passes eents it receies on to any destinations connected to the engine. The engine s component configuration file that contains the RMA_conf parameter will contain zero or more rules=<filename> lines. The rules filename specifies the XML file that defines the type of processing the engine will perform on the eents it receies. There are three types of processing that the engine can perform: Heartbeat Monitoring on page 87 Chapter 6, Eent Summarization, on page 89 Chapter 7, Incident-Based Correlation, on page 95 Additionally, the engine can be configured to perform eent pre-normalization and eent normalization of Tioli Risk Manager eents. Tioli Risk Manager eents that the engine processes inherit from the RM_SensorEent class defined in the sensor_abstract.baroc file. Since the full eent normalization process requires knowledge of the eent class hierarchy, its processing is restricted to agents installed as a Tioli Enterprise Console serer and as Tioli Risk Manager distributed correlation serers. Errors that are identified during Tioli Risk Manager eent normalization typically result in the generation of an RM_Error or RM_InputError eent that is routed to the Tioli Enterprise Console serer. The attributes of each such eent contain the details of the problem encountered. Most errors identified during eent normalization indicate a configuration problem with an adapter or sensor. These error eents will be aailable for reiew on the Tioli Enterprise Console. If specified in the engine s component configuration file that contains the RMA_conf parameter, the engine will adjust eent attributes based upon the settings. The options aailable to all agent engines are: attributemap=<filename> dnsresoler=[on off] dnsnameserers=[ipaddr,,,] dnsrequesttimeout=[milliseconds] dnssourcehostfilter=[ipaddr/mask,,,] dnsdestinationhostfilter=[ipaddr/mask,,,] dnssensorhostfilter=[ipaddr/mask,,,] dnsttl=[milliseconds] Copyright IBM Corp

96 dnscachesize=[# of entries] DNS Look-up Attribute Mapping The filename specified as the attribute map contains one or more definitions of changes to be made to the eent based upon the eent s content. You can specify setting an attribute to a specific alue when zero or more attributes contain specific alues. You can use the keyword, $CLASSNAME$, as the field alue to specify using the eent class name. All comparisons for attribute mapping treat the alues as strings. This means that there are no numeric comparisons, so 10.0 is not equal to 10. For example, if you want to set the seerity attribute to CRITICAL for all eents whose sensor type is csids and whose rm_leel is 5.0, specify the following in the attributemap file: <attributemap> <setattr field="seerity" alue="critical" /> <whenattr field="rm_sensortype" alue="csids" /> <whenattr field="rm_leel" alue="5.0" /> </attributemap> Notes: 1. The attribute names must exactly match the name in the BAROC file. 2. You must ensure that the alues specified are appropriate for the attribute specified. For example, use a real alue for the rm_leel attribute. 3. You must ensure that your mappings pertain only to eents you intended, by using a alid combination of whenattr settings. Mapping whenattr conditions must all be true (logical AND) in order for the mapping to occur. If only one whenattr condition needs to be true (logical OR), then create a separate attributemap entry for each of the whenattr conditions. 4. It is possible to change the classname using the $CLASSNAME$ keyword. When configured and enabled, DNS will be used to map IP addresses to fully-qualified host names for selected attributes in eents processed by the agent. The DNS configuration alues are set in the engine s component configuration file that contains the RMA_conf parameter. If DNS mapping is enabled and successful for a gien IP address, Tioli Risk Manager eents can hae their rm_sensorhostname, rm_sourcehostname, and rm_destinationhostname set to the fully-qualified alues associated with the corresponding IP addresses contained within the eent. If the agent is running on a Tioli Enterprise Console serer or on a Tioli Risk Manager distributed correlation serer, DNS lookup is performed if the IP address is not listed as a known host in either hostfile or sensorsfile. You can use the wrmdns command to make temporary changes to an agent s use of DNS. To make persistent changes to the agent s use of DNS, set the following configuration options in the engine s component configuration file specified by the RMA_conf parameter: dnsresoler=[on off] The default alue is off. Set this to on to enable the DNS look-up described aboe. dnsnameserers=[ipaddr,,,] 82 IBM Tioli Risk Manager: Administrator s Guide

97 Specify the DNS name serers. If no serers are specified, the DNS resoler attempts to discoer any DNS serers configured on the local system. Note: It is recommended that you set this parameter because there is no guarantee that the DNS serer self discoery will be successful and the DNS resolution will not be aailable without it. dnsrequesttimeout=[milliseconds] DNS request timeout. The default alue is one second (1000 milliseconds). dnssourcehostfilter=[ipaddr/mask,,,] This parameter is used to further filter DNS resolution on IP addresses and subnet masks. If set, the application will perform DNS resolution for only those source host addresses that fall within the ipaddr/mask specification. Each ipaddr/mask specified can define a range of IP addresses. For example, / specifies a range of hosts from through If set to zero (0) then no filters are applied, that is, all requests for DNS resolution are honored for this data element. You might also use the exclamation point (!) to indicate negatie notation. For example,!0 would imply that no DNS resolution for this data element will occur. Likewise, for ipaddr/mask combinations, the exclamation point (!) can be used to indicate that DNS resolution would not occur to source host addresses that fall within the specification. Testing ipaddr/mask combinations are performed sequentially. That is, there is no ability to build complex filter combinations by ANDing filters together. Filter analysis stops as soon as a true condition is met. The dnssourcehostfilter setting relates to setting the rm_sourcehostname attribute of Tioli Risk Manager eents to a fully-qualified host name. dnsdestinationhostfilter=[ipaddr/mask,,,] See dnssourcehostfilter aboe. This setting relates to setting the rm_destinationhostname attribute of Tioli Risk Manager eents to a fully-qualified host name. dnssensorhostfilter=[ipaddr/mask,,,] See dnssourcehostfilter aboe. This setting relates to setting the rm_sensorhostname attribute of Tioli Risk Manager eents to a fully-qualified host name. dnsttl=[milliseconds] The time-to-lie (TTL) is needed to control the accumulation of stale data in the DNS cache. With the widespread use of DHCP, it might be desirable to refresh cached entries on a frequent basis. dnscachesize=[# of entries] Set the maximum cache size. Eent Normalization In addition to the configurations aailable to all engines in the preious sections, engines at the Tioli Enterprise Console serer and the Tioli Risk Manager distributed correlation serers hae the following normalization configuration options: barocfiles=<filename> categoryfile=<filename> hostfile=<filename> sensorsfile=<filename> linkedeentsfile=<filename> Chapter 5. Engine Configuration 83

98 jittertime=[milliseconds] Eent normalization is performed prior to correlation. Inserting eents into the Tioli Risk Manager archie table requires that the eents be successfully normalized before they are written to the archie table. Identifying Eent Classes The filename specified by barocfiles=<filename> contains a list of BAROC files that are aailable for the Tioli Risk Manager engine to use to normalize the eents it receies. The BAROC files define the eent class hierarchy and define the attributes of each eent class. See Chapter 2, Eent Serer, on page 39 for more information about configuring the incident-based correlation engine and the use of BAROC files. In the list file, DO NOT change the following entries because they define the top-leel eent classes that are required by the agent to properly identify Tioli Risk Manager eents: root.baroc tec.baroc riskmanager.baroc sensor_abstract.baroc Assigning Class Category Class category is assigned to each Tioli Risk Manager sensor eent. The filename specified as categoryfile=<filename> contains the class category definitions used to make this assignment. You can edit the categoryfile to add or change any entries that are appropriate for your network. Because the category assignment is used as one of the primary attributes for incident-based correlation, it is important that you use the same cateforyfile at all Tioli Risk Manager serer-role agents in your network. Each category definition must contain a token, description, and topclass alue. If there are specific eents that belong to the category, but whose class hierarchy would result in it being assigned to a different category, the class should be specified in the members list. Sample category assignment: <category token="dos" description="denial of Serice" topclass= "RM_TDoS" members="rs_imap_oerflow "CSIDS_NetBios_OOB_Data" /> Identifying Known Systems You can define the known systems in your network to ensure that the agent is able to correctly match sensor, source, and destination attributes within your system whether the RM_SensorEent eents contain the host name or IP address. Some adapters and sensors set only the host name, others set only the IP address, and some set both alues in the eent. If you know that you are using adapters or sensors that set only host name or IP address, you might consider predefining your systems. If you know that you use aliases or hae multihomed systems, you should identify these to the agent. 84 IBM Tioli Risk Manager: Administrator s Guide

99 Regardless of whether or not you predefine your system hosts, eery effort is made to correctly match the source, sensor, and destination alues as part of eent normalization. Examples: To define a host with an IP address of and hostname of tioli.domain.com, specify the following in the hostsfile: <host ipaddr=" " hostname="tioli.domain.com" /> To define a host with hostname my.machine1.com and IP addresses of and , specify the following in the hostsfile: <host ipaddr=" " <host ipaddr=" " hostname="my.machine1.com"/> hostname="my.machine1.com"/> To define alias names of my.machine2.com and othermachine2.com for IP address , specify the following in the hostsfile: <host ipaddr=" " <host ipaddr=" " hostname="my.machine2.com"/> hostname="othermachine2.com"/> Identifying Trusted Systems In addition to identifying systems that are known in your enironment, you can also identify systems that you trust in the hostfile. Identifying a system as a trusted host means that you do not want actiity originating from the system to contribute to incident-based correlation. For example, if your trust host named my.machine2.com with an IP address of , specify the following in hostfile: <trusted_host ipaddr=" " hostname="my.machine2.com" /> The trusted host mapping uses the host name mapping to ensure all possible naming conentions are included. For example, if the hostsfile contains:... <host ipaddr = " " hostname = "my.machine2.com" /> <host ipaddr = " " hostname = "othermachine2com" /> <trusted_host ipaddr = " " hostname = "my.machine2.com" />... Eents with source of either of the aliases, my.machine2.com or othermachine2.com, would not contribute to incident-based correlation because the source is trusted. Identifying Known Sensors As part of eent processing, the agent identifies any new sensors sending eents to the agent. By default, when an eent is receied from a preiously unknown adapter or sensor, the engine will generate an RM_Sensor eent that will be iewable on your console. You can predefine your known adapters and sensors in the sensorsfile. In this file, you can specify: Known sensors and adapters Adapter types that the RM_Sensor eents should hae a seerity of HARMLESS instead of the default alue, WARNING Adapter types that the RM_Sensor eents should not be generated Chapter 5. Engine Configuration 85

100 Examples: If you hae a Network IDS adapter on host name, my.machine2.com, with IP address , you can add the following sensors file: <sensor sensortype="nids" ipaddr=" " hostname="my.machine2.com" /> To specify that RM_Sensor eents for your Web IDS adapters hae a HARMLESS seerity, specify the following in the sensorsfile: <downgrade_sensor_creation sensortype="webids" /> To disable the generation of RM_Sensor eents for your Web IDS adapters, specify the following in the sensorsfile: <ignore_sensor_creation sensortype="webids" /> Linking Eents As part of the eent processing, the agent can identify eents that are related to preiously receied eents and adjust the rm_leel attribute before including the second eent in incident-based correlation. For example, when a WW_SuspiciousCgi eent is followed by a WW_Success eent matching the WW_SuspiciousCgi attempt, the WW_Success should be considered more serious than usual. Linking eents depends upon the order the eents are receied, and specific attributes matching within the eents. The definitions for linking eents are in a file specified with the RMA_conf parameter of the agent s engine component. linkedeentsfile=<fully-qualified file name of a file containing information about related eents> You specify; the sensortype, discardtime, firsteent, secondeent, increment, and matchingattributes for each pair of linked eents. DiscardTime is the maximum time in seconds that can pass between receiing the firsteent and the secondeent. For example, to define a link between WW_SuspiciousCgi and WW_Success eents receied within two minutes from Web IDS adapters when the rm_sensortoken and webids_requid attributes of the two eents match, specify the following in the linkedeents file: <sensortype name ="webids" discardtime = "120"> <linkedeents firsteent = "WW_SuspiciousCgi" secondeent = "WW_Success" increment = "25.0" matchingattributes = "rm_sensortoken webids_requid" /> </sensortype> Setting Timestamp Variability Allowance As part of eent monitoring, the agent monitors the flow of eents. Each eent has a timestamp associated with it. In a well-functioning enironment, there will usually not be a large gap between the eents that are processed by the agent. If the time period between eents is larger than the configured timestamp ariability allowance, an eent will be generated to warn you of the ariation. The error eent will be iewable on your console. The error eent could indicate that the clocks within your network are not synchronized. It could also indicate that eent flow has encountered a problem from one or more of the deployed adapters or sensors. 86 IBM Tioli Risk Manager: Administrator s Guide

101 You specify the allowable timestamp ariance with the RMA_conf parameter of the agent s engine component when the agent is installed as a serer. For example, you specify the allowable timestamp ariance with the RMA_conf parameter of the agent s engine component as follows. jittertime=86400 where is the number of seconds ariance. One day is seconds. Additional Attributes Adjustments In addition to the modifications described preiously, Tioli Risk Manager assigns default alues that are specified in the BAROC files and makes the following adjustments to each RM_SensorEent: Sensor Eent rm_timestamp32 rm_timestamp rm_sensortoken rm_sourcetoken rm_destinationtoken origin suborigin hostname msg rm_leel rm_agentnormalized Descriptions Adjusted to GMT Assigned from rm_timestamp32 Assigned Assigned Assigned If not set by adapter, set to rm_sensoripaddr Set to rm_sensortype Assigned alue in the following format: "category: sensor_token( source_token => destination_token)" If not set by adapter, set to rm_signature alue Adjusted for summarized eents Set to true if normalization is successful Heartbeat Monitoring Tioli Risk Manager self-monitors the agents deployed in your network and warns you when an agent becomes inactie. The warning is an RMAgent_Inactie eent generated at one of your correlation serers. RMAgent_Inactie eents are included in the Tioli Enterprise Console database and iewed on the console. By default, each agent is configured to generate RMAgent_HeartBeat eents. Each correlation serer is configured to monitor the RMAgent_HeartBeat eents and generate RMAgent_Inactie eents when an agent stops sending regular RMAgent_HeartBeat eents. By default, there will be an RM_Sensor eent created to represent each agent that generates RMAgent_HeartBeat eents. The RMAgent_HeartBeat eents are not typically forwarded to your Tioli Enterprise Console serer or database. Adanced Configuration This section describes configuration steps that are optional, if you want to customize heartbeat monitoring beyond the default configuration. Adanced configuration steps for heartbeat monitoring are: Configuring the Correlation Serer to Monitor Heartbeat Eents on page 88 Configuring the Agent to Generate Heartbeat Eents on page 88 Chapter 5. Engine Configuration 87

102 Disabling Generation of Heartbeat Eents Disabling Monitoring of Heartbeat Eents Configuring the Correlation Serer to Monitor Heartbeat Eents Your correlation serers will monitor RMAgent_HeartBeat eents that are receied from agents that forward their eents to the correlation serer. To enable the correlation serer agent to monitor the heartbeat, ensure that there is a rule similar to the following enabled in the file specified by the RMA_conf parameter of the actie engine: Configuring the Agent to Generate Heartbeat Eents The RMAgent_HeartBeat eents are generated on each agent whose primary configuration file defines a receier with class, com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat. The time interal (in milliseconds) for the heartbeat eents is specified in the file specified by the RMA_conf parameter of the sender. For example: RMINSTDIR/etc/rmagent.xml:... <receier name="heartbeat" class="com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat"> <set key="rma_conf" alue="rminstdir/etc/heartbeat.conf" /> </receier>... RMINSTDIR/etc/heartbeat.conf:... time= Disabling Generation of Heartbeat Eents To disable the generation of the heartbeat eents, remoe the receier with class, com.tioli.riskmanager.agent.transports.receiers.rmaheartbeat, from the agent configuration file, RMINSTDIR/etc/rmagent.xml. Remoe all connectors referencing the heartbeat. Disabling Monitoring of Heartbeat Eents To disable the monitoring of heartbeat eents at a correlation serer, remoe the reference to the rules file that contains the rule to monitor heartbeat eents. If your RMAgent_HeartBeat eents are not processed by a correlation serer that monitors heartbeats, the RMAgent_HeartBeat eents might appear on your eent console and database. 88 IBM Tioli Risk Manager: Administrator s Guide

103 Chapter 6. Eent Summarization Oeriew Some of the deices that are monitored by Tioli Risk Manager adapters generate a large number of eents that represent a set of ery similar actiity. For example, some sensors present a single port scan as one eent per port scanned. To minimize eent traffic, with minimal loss of information, the agent can summarize similar eents. This chapter proides information that will help you: Identify a summarized eent Understand the eent summarization rules Configure eent summarization rules As described in Chapter 5, Engine Configuration, on page 81, one of the functions proided by the Tioli Risk Manager agent s engine component is eent summarization. Eent summarization is the process used by the agent s engine to identify ery similar eents that occur within a short time period and map the set of eents into a single eent. This minimizes network eent traffic and space in the Tioli Enterprise Console database tables and the Tioli Risk Manager archie table. Identifying a Summarized Eent A summary eent is a RM_SensorEent whose repeat_count attribute is set to a alue greater than zero. The repeat_count attribute alue is one less than the number of original eents that are represented by the summary eent. For example, a summary eent whose repeat_count attribute is nine represents ten ery similar indiidual eents. By conention, Tioli Risk Manager sets the msg attribute of summary eents to a alue starting with the word, SUMMARY, to assist in identifying a summary eent. Out-of-the-Box Client Configuration When the agent is deployed in the client role, the engine is automatically configured to perform eent summarization for the following Tioli Risk Manager adapters: Check Point FireWall-1 (CPFW_summary_rules.xml) Cisco-Secure IDS (CSIDS_summary_rules.xml) NIDS (NIDS_summary_rules.xml) PIX (PIX_summary_rules.xml) Real Secure (RS_summary_rules.xml) By default, the client engine s secondary configuration file is RMINSTDIR/etc/summary_engine.conf. The summary_engine.conf file contains a rules= line enabled for each of the aboe mentioned adapters. The default summary rules definition files are also in the RMINSTDIR/etc directory. If you do not hae one or more of the adapters where default summary rules are proided, you can comment out with the pound sign (#) or remoe unneeded rules=<filename> lines from RMINSTDIR/etc/summary_engine.conf file. Copyright IBM Corp

104 A copy of each of the default summary rules files is proided in the RMINSTDIR/etc/templates directory. Actie summary rules XML files must be in the RMINSTDIR/etc directory. Understanding Summarization Rules Each of the summary rules XML files contains more than one rule definition. Each summary rule contains the following information: A unique rule ID The Tioli Risk Manager eent class to be summarized The time frame, in milliseconds, to monitor for similar eents A list of attributes that must match in the eents for them to be included in a summary eent. Additionally, each summary rule can define one or more alues to assign to specific eent attributes. The following is a sample summary rule: <rule id="pix_portscan_in"> <eenttype>pix_tcp_in_conn_denied</eenttype> <collector timeinteral="30000"> <cloneable attributeset="pix_se pix_code pix_ifname rm_sourceipaddr rm_destinationipaddr rm_sensoripaddr" ignoremissingattributes="true" /> <predicate>true</predicate> </collector> <action function="rmsummary"> <parameters> <![CDATA[ SET:rm_SrcPort=* SET:rm_DstPort=* SET:msg=SUMMARY_Multiple_TCPIP_Inbound_connections_denied_by_PIX ]]> </parameters> </action> </rule> This particular example depicts a rule designed to summarize floods of eents whose eent class is PIX_TCP_in_conn_denied, as specified by <eenttype>pix_tcp_in_conn_denied</eenttype> in the rule. The unique rule ID for this eent is PIX_PortScan_in as specified by <rule id="pix_portscan_in"> in the rule. The Cisco PIX firewall produces one of these eents wheneer it blocks a connection to a specific port. A single port scan triggers a large number of these eents, each with the same eent class name, pix_se, pix_code, pix_ifname, source IP address, destination IP address, and sensor IP address. The destination port might ary, of course, but the essential information is the source and destination addresses associated with the port scan. This rule will monitor the PIX_TCP_in_conn_denied eents for a time period of 30 seconds as specified by timeinteral="30000" in the rule. The time interal is specified in milliseconds. If the incoming PIX_TCP_in_conn_denied eents contain the same alue for the 90 IBM Tioli Risk Manager: Administrator s Guide

105 attributes specified in the attributeset of the rule as the original eent, then they are aggregated into a single summary eent. This sample rule also specifies that the resulting summary eent will hae the following attributes set as follows: rm_srcport will contain the wildcard character (*) to signify that more than one alue can be associated with the attribute. rm_dstport will also contain the wildcard character (*) msg will contain: SUMMARY:Multiple TCPIP Inbound connections denied by PIX The resulting summary eent will hae the same eent class name, PIX_TCP_in_conn_denied, as the indiidual eents. If the agent does not receie any eents matching the first eent, then it forwards the original eent after the time period has expired. Things to note about the syntax of the summary eent rules: When setting the msg attribute of the summary eent, use underscore characters instead of spaces in the rule. The resulting summary eent will hae the first underscore character that is replaced with a colon (:) and subsequent underscore characters that are replaced with a space. Follow the Tioli Risk Manager conention of setting your message to start with SUMMARY to further assist you in identifying a summary eent. The ignoremissingattributes="true" specification after the attributeset tells the engine to aggregate eents that do not contain one or more of the attributeset attributes. In the preious sample, if an eent was receied without the pix_ifname attribute specified, it would be matched to similar eents that are also missing that specific attribute. If you do not specify ignoremissingattributes="true", then eents missing one or more of the attributes would not be summarized. The <predicate>true</predicate> specification is required and typically should not be changed for summary rules. The rules file is an XML file. You can use standard XML comments within the rules file. The eent attributes specified in the attributeset as well as in the SET: parameters must be attributes that are defined for the eent class. During the summarization process, the attribute names are not erified against the BAROC file definitions because the BAROC files are not typically aailable to the client. In particular, if you SET: an attribute that is not defined, then the Tioli Enterprise Console serer will reject the summary eent. The attribute names and the eent class names are case sensitie. The eent class name must match identically with a alid eent class as defined in the adapters BAROC file. If you specify the eent class incorrectly, the agent will not be able to summarize the eents. The alues set for any SET:attribute must be alid for the specific attribute. If the alue set is not alid, the Tioli Enterprise Console serer will reject the eent. The client holds the first eent whose class matches an enabled summary rule for the timeinteral period. If you specify a large time interal, you might notice a delay between when the eent is generated by the adapter and when it is receied at your Tioli Enterprise Console serer or written to your Tioli Risk Manager archie table. Chapter 6. Eent Summarization 91

106 Configuring Summary Rules You can do the following to your summary rule file: Updating An Existing Summary Rule Creating New Summary Rules on page 93 Actiating Your Changes on page 93 Updating An Existing Summary Rule You can change an existing summary rule or add a rule to an existing rules file for an additional eent class. For example, you might notice that you are receiing seeral summary eents for a port scan and want to further reduce your eent flow for that specific attack type. To reduce the number of summary eents for the specific attack: Make note of the time period the attack typically spans Make note of the eent class At your client, edit the appropriate summary rules XML file Modify the rule associated with the specific eent class to change the timeinteral setting to be more appropriate for your enironment. For example, if you notice that you are receiing ten summary eents for one port scan using the default time interal of 30 seconds. Change the time interal to 300 seconds ( milliseconds) to potentially reduce the scan to one summary eent. Or you might only need to reduce the number of summary eents by half, in that case you would probably specify a time interal of 60 seconds (60000 milliseconds). If you notice that an adapter with a summary rules XML file already defined is generating a flood of eents of a type that has no rule defined, add a rule for that specific eent type. Edit the summary rules XML file associated with your adapter, and add a new rule specification. Reiew the sample summary rule on page 90 and refer to existing rules in the XML file for the syntax of a summary rule. Before creating a new summary rule, examine the eent attributes of an eent that might be a good candidate for a new summary rule. If the eent has one or more attributes whose indiidual alues are required to diagnose attack particulars, you should reconsider implementing a summary rule for the eent class because the resulting summary eent will contain exactly one of the alues. Remember, the goal of the summarization process is to reduce eent traffic without loss of releant information. You must ensure that any rule you define does not cause the loss of important information. Prior to adding a new rule, make note of the following: The eent class name Attributes names that you require to match as part of a summary eent Attribute names that you want to set in the summary eent The type of each attribute you want to set in the summary eent. Attribute types are defined in the BAROC files. The expected time period of the eent flood Add the new rule definition in the summary rules XML file, being careful to include the rule within the rules tags in the XML file. Before actiating your changes, be sure to check the following: 92 IBM Tioli Risk Manager: Administrator s Guide

107 You hae specified a unique rule ID You hae correctly specified the eent class name You hae correctly specified the eent attribute names Any SET:attribute specifications use alues that are alid for the attribute. For example, you must not set an INTEGER or REAL type attribute to the wildcard character (*) since it is not numeric. If you do, your Tioli Enterprise Console serer will reject the eent with a PARSING_ERROR. See Actiating Your Changes for information on erifying and actiating your summary rules changes. Creating New Summary Rules You can create your own summary rules XML files to contain summary rules for eents in your enironment. It is strongly recommended that you use an existing summary rules XML file as a template for any new summary rules XML files that you create. See Updating An Existing Summary Rule on page 92 for a sample summary rule and refer to the rule definitions in an existing summary rules XML file for the syntax of a summary rule. Follow the process of creating a new summary rule as defined in Updating An Existing Summary Rule on page 92. See Actiating Your Changes for information on erifying and actiating your rules. Actiating Your Changes Before actiating any changes made to the summary rules XML files, erify that you hae not introduced any syntax errors in the file. Use the checkrules command to alidate the syntax of your changes. If there is a syntax error in your summary rules XML file, the agent will ignore the rules in the file and continue processing. This means that a syntax error in your summary rules XML file does not cause the agent to stop processing. Instead the agent will process the eents as if there was no summarization rule defined for them. Once you hae erified the syntax of your new or updated summary rules XML file, erify that the engine s component configuration file with the RMA_conf parameter contains a rules= line specifying your summary rules XML file. See the IBM Tioli Risk Manager Command Reference for details on using the checkrules command. Use the wrmadmin command to actiate your changes. You can stop and restart the agent using the wrmadmin restart command, or you can stop and restart the agent s engine component as follows: 1. Stop the engine using the wrmadmin s summary_engine command. 2. Restart the engine using the wrmadmin r summary_engine command. See the IBM Tioli Risk Manager Command Reference for more details on using the wrmadmin command. Chapter 6. Eent Summarization 93

108 Sample Eent Summarization Processing The following sample shows the results of eent summarization for a single eent class with a summary rule defined to match eents with the same source IP address and destination IP address. For this example, assume that the source port and destination port as set to the wildcard character by the rule. The following table shows the alues of the attributes for all eents of this class type receied within the summary time interal. Table 8. The original eents receied by the sensors Eent Number Source IPAddress Destination IPAddress Source Port Destination Port For this set of eents, the output from the summarization process will be: A summary eent representing eent numbers 1,3,6, and 8 from the aboe table. This summary eent will hae: repeat_count attribute of 3 source IP address of destination IP address of source port of * destination port of * A summary eent representing eent numbers 2,4,5,9, and 10 from the aboe table. This summary eent will hae: repeat_count attribute of 4 source IP address of destination IP address of source port of * destination port of * An unsummarized eent, eent number 7 from the aboe table. This eent will be unchanged: repeat_count attribute of 0 source IP address of destination IP address of source port of destination port of IBM Tioli Risk Manager: Administrator s Guide

109 Chapter 7. Incident-Based Correlation Oeriew When Tioli Risk Manager is installed on an eent serer and a distributed correlation serer, the agent performs incident-based correlation. Incident-based correlation is the process of identifying and creating RM_Incident eents using the information from the RM_SensorEent eents receied by the agent. In this context, an RM_SensorEent is any eent produced by a Tioli Risk Manager adapter or sensor. The agent monitors the eents receied to determine if the actiity within your network has reached a leel that your network administrator should be alerted. This chapter proides information that will help you understand: Incident-based correlation processing Incident-based correlation XML syntax Incident-based correlation action functions Customizing incident-based correlation rules Configuring incident-based correlation rules Extending incident-based correlation with customer ID attribute enablement This section describes common questions about incidents. What is an incident? An incident is an eent representing a set of RM_SensorEents with combined rm_leel attributes that hae reached the configured threshold within the configured sliding-window time frame. As part of incident identification, the agent also monitors the following: The source of the actiity The destination (or target) of the actiity The class category of the actiity What is the rm_leel attribute? The rm_leel attribute is a alue assigned to each RM_SensorEent by the adapter or sensor that generated the eent. What is a sliding-window? In this context, a sliding-window is a time-period during actiity that is monitored by the agent. The start time of the actiity is automatically adjusted so that only eents receied within the configured time period are actiely being monitored. What is a class category? A class category is an association of RM_SensorEent eents with a known type of intrusion actiity. A class category is assigned to each RM_SensorEent based upon the type of actiity represented by the eent. The assignment of class category is typically based upon the inheritance hierarchy of the eent. Specific eent classes can be assigned to a category separate from its inheritance hierarchy. Table 9 on page 96 shows the default class categories: Copyright IBM Corp

110 Table 9. Default Class Categories Category Name CMD CONFIG DOS HOSTLVL IDSLVL INSTALL MISCLVL NETLVL NETMAN NOMAPPING RESOURCE SECADMIN SECACCESS.ALLOW SECACCESS.DENY SECAUTH.ALLOW SECAUTH.DENY SERV SERVCMP STATECHG SYSERROR TDOS TOPLVL TROJ USER VIRUS WEB Description Command-Leel Actiity Configuration Change Actiity Denial of Serice Actiity Host-Leel Actiity IDS Leel Actiity Installation Actiity Miscellaneous Leel Actiity Network-Leel Attack Network Management Actiity Catchall Eent, Uncategorized Note: Eents assigned to this category indicate that an adapter or sensor does not contain a specific signature for the eent. The adapter or sensor eent formatting file may be updated to categorize the eent more specifically. Resource Alert Security Administration Actiity Access Allowed Actiity Access Denied Actiity Authentication Allowed Actiity Authentication Denied Actiity Serice Attack Serice Compromise State Change Actiity System Error Targeted Denial-of-Serice Category Top Leel. Note: Eents assigned to this category indicate that an adapter or sensor does not contain a specific signature for the eent. The adapter or sensor eent formatting file may be updated to categorize the eent more specifically. Trojan Horse Actiity User-Leel Actiity Virus Actiity Web Attack See Assigning Class Category on page 84 for more information on configuring class category assignments. What types of incidents are there? Table 10 on page 97 describes the RM_Incident eents that represent suspicious actiity within the network. 96 IBM Tioli Risk Manager: Administrator s Guide

111 Table 10. RM_Incidents Eent That Represent Suspicious Actiity RM_Incident Eent Type RM_Cat_Incident RM_Dst_Incident RM_DstCat_Incident RM_Src_Incident RM_SrcCat_Incident RM_SrcDst_Incident RM_SrcDstCat_Incident What is represented by this incident type? Varied actiity within a specific class category. This actiity originates from more than one source host and targets more than one destination host. Varied actiity targeting one destination host. This actiity originates from more than one source host and represents more than one class category. Varied actiity targeting one destination host within a specific class category. This actiity originates from more than one source host. Varied actiity from one source host. The actiity targets more than one destination host and represents more than one class category. Varied actiity from one source host within one class category. The actiity targets more than one destination host. Varied actiity from one source host targeted at one destination host. The actiity is within more than one class category. Very specific actiity from one source host, targeted at one destination host, within a specific class category. What eents contribute to an incident? All well-formed eents inheriting from RM_SensorEent with rm_correlate=yes attribute might contribute to an incident. Well-formed eents hae the following attributes set. rm_sensortype rm_sensorhostname rm_sensoripaddr rm_sourcehostname or rm_sourceipaddr or both rm_destinationhostname or rm_destinationipaddr or both rm_leel These attributes can be set by the sensor or adapter or hae a alid default alue assigned from the BAROC file. Additionally, the rm_leel attribute must be greater than 0.0 for an eent to contribute to an incident. Eents from trusted hosts do not contribute to incidents. Can an eent contribute to more than one incident? Yes, a single RM_SensorEent eent can contribute up to seen incident eents. How is the seerity of an incident set? The seerity of an RM_Incident eent is set based upon the rate the contributing eents reached the threshold setting. The seerity will be WARNING if the elapsed time is more than one half the sliding window time. The seerity will be MINOR if the elapsed time is more than one quarter the sliding window time. The seerity will be CRITICAL if the elapsed time is one quarter or less of the sliding window time. Chapter 7. Incident-Based Correlation 97

112 How Do I Stop a Specific Eent Class From Contributing to Incident-Based Correlation? Any class that inherits from RM_SensorEent can contribute to incident-based correlation. You can disable an eent s contribution to incident processing by setting its rm_correlate attribute to no. To change the default rm_correlate alue for a specific eent: 1. Edit the BAROC file that contains the class that you want to modify. 2. Specify the alue you want to use for the eent s rm_correlate. a. To disable correlation: rm_correlate: default= no ; b. To enable correlation: rm_correlate: default= yes ; 3. Update the Tioli Enterprise Console and serer agent using the rmcorr_cfg update command. See the IBM Tioli Risk Manager Command Reference for details on using this command. 4. Verify that your Tioli Risk Manager BAROC files are at the same leel throughout the network. Some adapters might allow you to set the rm_correlate alue for a specific instance of the adapter. For example, if the adapter uses an the XML file used for formatting, you could change the mappings in the XML file to assign the alue you want. See the documentation proided with the adapter that you want to reconfigure. Incident-Based Correlation Processing As described in Chapter 5, Engine Configuration, on page 81, one of the functions proided by the Tioli Risk Manager agent s engine component is incident-based correlation. Incident-based correlation is the process used by the agent s engine to identify related security actiity and generate an RM_Incident eent when significant actiity is detected. By default, the agent on the Tioli Enterprise Console serer and distributed correlator the engine s secondary configuration file is RMINSTDIR/etc/incident_engine.conf. The incident_engine.conf file contains rules=rminstdir/etc/incident_rules.xml. The rules defined in RMINSTDIR/etc/incident_rules.xml contain the default incident-based correlation rules. The engine identifies that it is to perform incident-based correlation when there is an XML rule using the keyword CorrelationEent as the type of eent used by the rule. When a Tioli Risk Manager sensor eent (RM_SensorEent) is processed by an engine configured to perform incident-based correlation, the engine: Normalizes the eent (if it has not already been normalized) Creates a temporary eent with the attributes used by incident-based correlation from the eent Routes the normalized eent to the connectors defined for the engine Uses the temporary eent for incident-based correlation processing When an incident eent is generated, the engine routes it to the connectors defined for the engine 98 IBM Tioli Risk Manager: Administrator s Guide

113 Incident-Based Correlation XML Syntax The default incident_rules.xml file contains seen rules for producing RM_Incident eents. Each incident rule contains: A unique rule ID The CorrelationEent keyword is specified as the eenttype A threshold indicating the aggregated rm_leel attributes of the original RM_SensorEents A time interal specifying in milliseconds the sliding-time window to monitor the eents An attributeset indicating the original eent attributes are to be used by the rule to identify that the original RM_SensorEents will contribute to the aggregation An action function specifying the type of RM_Incident the rule will generate when the threshold is crossed The alid action functions are described in Table 11. Table 11. Valid Actions Action Function CatIncident DstCatIncident DstIncident SrcCatIncident SrcDstCatIncident SrcDstIncident SrcIncident Action Performed Generates an RM_Cat_Incident eent. If there is no ariance in the source or destination of the contributing eents, no incident eent is generated. Generates an RM_DstCat_Incident eent. If there is no ariance in the source of the contributing eents, no incident is generated. Generates an RM_Dst_Incident eent. If there is no ariance in the source or category of the contributing eents, no incident eent is generated. Generates an RM_SrcCat_Incident eent. If there is no ariance in the destination of the contributing eents, no incident is generated. Generates RM_SrcDstCat_Incident eent. Generates an RM_SrcDst_Incident. If there is no ariance in the category attribute of the eents being processed, no incident eent is generated. Generates an RM_Src_Incident eent. If there is no ariance in the destination or category of the contributing eents, no incident is generated. The following is a sample incident-based correlation rule: <rule id="rm.incident.dstcat"> <!-- Each rule must hae a unique id --> <eenttype>correlationeent</eenttype> <threshold thresholdcount="10" <!-- threshold of rm_leel attribute aggregation that will cause the creation of the RM_Incident eent --> timeinteral="600000" <!-- Sliding time window size in milliseconds --> timeinteralmode="slidewindow" <!-- Use the sliding window method. Do NOT change this --> triggermode="alleents" <!-- Do NOT change this alue --> > <cloneable attributeset="rm_destinationtoken rm_categorytoken" <!-- The attributeset lists the attributes of the eents that must match for Chapter 7. Incident-Based Correlation 99

114 /> <aggregate> incident identification. must match --> In this sample, the destination and category <!-- This section tells the rule engine to aggregate on the rm_leel attribute as the thresholdcount alue --> <![CDATA[ &rm_leel ]]> </aggregate> <predicate>true</predicate> </threshold> <action function="dstcatincident"/> <!-- The action function that is inoked when the threshold is reached within the timeinteral --> </rule> Incident-Based Correlation Action Functions Incident eents are generated for the series of eents with attributes that match the attributeset defined in the rule. The action function determines the type of incident is generated. By default, the action function checks the contributing eents to ensure that more than one unique alue is represented in the eents for the correlation attributes that are not expected in the attributeset for the rule. The correlation attributes are rm_sourcetoken, rm_destinationtoken, and rm_categorytoken. If the contributing eent attributes do not include more than one alue for the checked correlation attributes, then no incident eent is generated. The default Tioli Risk Manager incident rules behae this way to ensure that the incident eents generated represent your network actiity as concisely as possible. The following table describes the default action function behaior: Table 12. Default Action Function Behaior Action Function Expected Correlation Attributes in the attributeset No incident generated if these Correlation Attributes are all the same from the contributing eents CatIncident rm_categorytoken rm_sourcetoken rm_destinationtoken DstCatIncident rm_destinationtoken rm_categorytoken rm_sourcetoken DstIncident rm_destinationtoken rm_sourcetoken rm_categorytoken SrcCatIncident SrcDstCatIncident SrcDstIncident rm_sourcetoken rm_categorytoken rm_sourcetoken rm_destinationtoken rm_categorytoken rm_sourcetoken rm_destinationtoken rm_destinationtoken N/A There can not be any ariation because all the correlation attributes are in the attributeset rm_categorytoken SrcIncident rm_sourcetoken rm_destinationtoken rm_categorytoken You can configure the action function to generate an incident eent when the expected ariation is not found in the contributing eents correlation attributes using the RequireAttributeVariation:false parameter in the rule. 100 IBM Tioli Risk Manager: Administrator s Guide

115 For example:... <action function="srcincident" > <parameters> <![CDATA[ RequireAttributeVariation:false ]]> </parameters> </action> For example, you might want to configure the action this way if you want an incident generated wheneer a specific host is the source of an attack and you do not want to write seen rules (one rule for each action function) for the specific host. Customizing Incident-Based Correlation Rules The predicate portion of the rule determines the eents that will be used by the rule to trigger the action function. The default is <predicate>true</predicate> that means that all eents with matching alues for the attributes specified in the attributeset will be used by the rule. If you change the predicate to be more selectie, then only eents with attributes matching the specified predicate criteria will be used by the rule. The following table shows predicate alues that are alid for attributes defined as STRING to the correlation engine. For the correlation engine only, Tioli Risk Manager defines all attributes except rm_leel as STRING. Tioli Risk Manager defines the rm_leel attribute as a floating point number. The predicate settings can include the following logical operators for STRING attributes: Specification Meaning Description == Equals The specified attributes contains the string alue specified!= Not equal The specified attribute contains a alue that is not identical to the alue specified startswith(&attributename, startvalue ) Starts with The specified attribute is set to alue that starts with the startvalue specified endswith(&attributename, endvalue ) Ends with The specified attribute is set to a alue that ends with the endvalue specified iceq(&attributename, alue ) icne(&attributename, alue ) Ignore case equality Ignore case not equal The specified attribute is set to a alue that matches alue regardless of case. The specified attribute is set to a alue that does not match alue regardless of case. && Logical AND Logically ANDs the two expressions around it Logical OR Logically ORs the two expressions around it Chapter 7. Incident-Based Correlation 101

116 The following comparison functions can be used within the predicate setting for float alues for the rm_leel attribute: Specification Meaning Description == Numeric Equals For example to specify that rm_leel must equal 3.0: &rm_leel== 3.0!= Numeric not equal For example to specify that rm_leel must not be 3.0: &rm_leel!=3.0 < Numeric less than For example to specify that rm_leel be less than 4.0: &rm_leel < 4.0 <= Numeric less than or equal For example, to specify that rm_leel be less than or equal to 4.0: &rm_leel <= 4.0 > Numeric greater than For example, to specify that rm_leel be greater than 4.0: &rm_leel > 4.0 >= Numeric greater than or equal For example, to specify that rm_leel be greater than or equal to 4.5: &rm_leel >= 4.5 For example, if you want only eents that are in a category starting with SERV. And whose rm_leel attribute is between 1.0 and to contribute to your rule, you could specify the following predicate: <predicate> <![CDATA[ startswith(&rm_categorytoken,"serv.") && (&rm_leel>=1.0 && &rm_leel <=100.0) ]]> </predicate> Configuring Incident-Based Correlation Rules You can do the following to your incident-based correlation rules files: Updating an Existing Incident-Based Correlation Rules File Creating a New Incident-Based Correlation Rules File on page 103 Actiating Changes to the Incident-Based Correlation Rules File on page 105 Updating an Existing Incident-Based Correlation Rules File You can make simple updates to your incident-based correlation rules to change: Threshold leel an incident eent is created The time interal for monitoring the actiity To include a specific alue for an attribute in the resulting incident eent To change the threshold leel, edit the specified rule file and change the thresholdcount setting in the rule. To change the time interal for monitoring the actiity, edit the specified rule file and change the timeinteral setting to the appropriate alue. To include a specific alue for an attribute in the resulting incident eent, you can add parameters to the action section of the rule. 102 IBM Tioli Risk Manager: Administrator s Guide

117 Setting an Attribute to a Specific Value If you want an attribute of your RM_Incident eent to be set to a specific alue, specify parameters to the action function. For example, if you want the seerity set to CRITICAL for your RM_SrcDst_Incident eents, set the parameters as follows:... <action function="srcdstincident"> <parameters> <![CDATA[ SET:seerity=CRITICAL ]]> </parameters> </action>... Specify only alid eent attribute names and alues. If you want to set the msg attribute with a alue containing spaces, use underscore ( _ ) characters where you want the spaces. For example:... <action function="srcdstincident"> <parameters> <![CDATA[ SET:msg=Your_customized_message_goes_here ]]> </parameters> </action>... See Actiating Changes to the Incident-Based Correlation Rules File on page 105 for information on erifying and actiating your XML rules changes. Creating a New Incident-Based Correlation Rules File You might want to create new incident-based correlation rules to: Hae different threshold settings for a particular category Monitor actiity from a specific host A copy of incident_rules.xml is proided in the RMINSTDIR/etc/templates directory. Specifying Different Thresholds For Unique Eent Categories After analyzing your typical system eent flow, you might discoer that there are specific eent classes that you want to monitor more closely. While it seems reasonable to simply change the eenttype to a specific eent class name in the rule, doing so will cause your specific eent class eents to be discarded at the correlation serer. Instead, you can create rules for specific categories. This might inole creating your own class category and assigning specific eent classes to the new class category. See Assigning Class Category on page 84 for details on creating a new class category. Also, consider changing the default rm_leel attribute of the specific eents. For example, you can identify that eents that are in category SERV.ALLOW are of interest to you, you could add rules similar to the following to your rules file: <rule id="rm.incident.srcdstcat.serv.allow" > <eenttype>correlationeent</eenttype> <threshold thresholdcount="100" timeinteral="600000" timeinteralmode="slidewindow" triggermode="alleents" > <cloneable attributeset="rm_sourcetoken rm_destinationtoken Chapter 7. Incident-Based Correlation 103

118 rm_categorytoken" /> <aggregate><!cdata[ &rm_leel]]> <predicate> <![CDATA[ &rm_categorytoken=="serv.allow" ]]> </predicate> </threshold> <action funtion="srcdstcatincident"> <parameter> <![CDATA[SET:seerity="CRITICAL" ]]> </parameter> </action> </rule> <rule id="rm.incident.cat.serv.allow"> <eenttype>correlationeent</eenttype> <threshold thresholdcount="100" timeinteral="600000" timeinteralmode="slidewindow" triggermode="alleents"> <cloneable attributeset="rm_categorytoken" /> <aggregate><![cdata[ &rm_leel ]]> <predicate> <![CDATA[&rm_CategoryToken=="SERV.ALLOW" ]]> </predicate> </threshold> <action function="catincident"> <parameter> <![CDATA[SET:seerity="CRITICAL" ]]> </parameter> </action> </rule> Presuming that you did not remoe the original incident rules, the eents in the SERV.ALLOW category will still contribute to incidents created by the original rules. If you do not want eents in the SERV.ALLOW category to contribute to the original incident rules, you can specify this by changing <predicate>true</predicate> in the original rule to: <predicate> <![CDATA[&rm_CategoryToken!="SERV.ALLOW" ]]> </predicate> Monitoring Actiity Targeting A Specific Host As part of monitoring your system security eents, you might notice that a particular machine is frequently the target of suspicious actiity. You can create a rule to generate an incident eent rather quickly when this machine is targeted again. For example, the following rule will generate an RM_Dst_Incident eent when host "abc.our.domain" is the target from any source with a combined rm_leel of 5.0 or more within a one minute time period: <rule id="abc.hit_again"> <eenttype>correlationeent</eenttype> <threshold thresholdcount="5" timeinteral="6000" timeinteralmode="slidewindow" triggermode="alleents"> <cloneable attributeset="rm_destinationtoken" /> <aggregate><![cdata[ &rm_leel ]]></aggregate> <predicate>&rm_destinationtoken=="abc.our.domain"</predicate> </threshold> <action function="dstincident"> <parameters><![cdata[ SET:msg=Actiity_targeted_at_ABC SET:seerity=CRITICAL 104 IBM Tioli Risk Manager: Administrator s Guide

119 ]]> </parameters> </action> </rule> See Actiating Changes to the Incident-Based Correlation Rules File for information on erifying and actiating your XML rules changes. Actiating Changes to the Incident-Based Correlation Rules File Before actiating any changes you hae made to the incident rules XML files, you should erify that you hae not introduced any syntax errors in the file. Use the checkrules command to alidate the syntax of your changes. If there is a syntax error in your summary rules XML file, the agent will ignore the rules in the file and continue processing. This means that a syntax error in your rules XML file does not cause the agent to stop processing. Instead the agent will process the eents as if there was no rule defined for them. See the IBM Tioli Risk Manager Command Reference for more details on using the checkrules command. Once you hae erified the syntax of your new or updated rules XML file, erify that the engine s component configuration file with the RMA_conf parameter contains a rules= line specifying your rules XML file. Use the wrmadmin command to actiate your changes. You can stop and restart the agent using the wrmadmin restart command or you can stop and restart the agent s engine component as follows: 1. Stop the engine using the wrmadmin s summary_engine command. 2. Restart the engine using the wrmadmin r summary_engine command. See the IBM Tioli Risk Manager Command Reference for more details on using the wrmadmin command. Extending Incident-Based Correlation with Customer ID Attribute Enablement The following procedures document how to enable the customer ID attribute, and use it to correlate IBM Tioli Risk Manager eents. To enable the eent serer to aggregate eents using the customer ID attribute, rm_customerid, perform the following steps on each serer: 1. Copy the following file to the RMINSTDIR/etc directory, where RMINSTDIR is the IBM Tioli Risk Manager installation directory: RMINSTDIR/etc/templates/proider_incident_rules.xml 2. Reiew the file to ensure that the threshold settings, and all other settings, are correct for your enironment. 3. Edit the correlation engine s configuration file with the RMA_conf parameter to actiate the rules in the RMINSTDIR/etc/proider_incident_rules.xml file. To do this, add (or change) the file to include the following line: rules=rminstdir/etc/proider_incident_rules.xml Chapter 7. Incident-Based Correlation 105

120 4. See Actiating Changes to the Incident-Based Correlation Rules File on page 105 for information on how to erify your changes to the rules file and restart the agent. After the proide_incident_rules.xml file has been updated and actiated, the customer ID attribute must be set in the RM_SensorEent eents to fully enable incident creation on a per customer basis. Depending on the type of adapters deployed, there are seeral options for setting the customer ID attribute: For logfile type adapters, the XML file used for formatting can be edited to include setting the attribute to the correct alue - usually at the base leel eent class. For any adapter, an attribute map definition can be added to the correlation engine s configuration file with the RMA_conf parameter. This is accomplished by adding an entry to set the rm_customerid attribute. The agent must be restarted to actiate this change. For any adapter, edit the BAROC file and add a default setting for the rm_customerid attribute. At the Tioli Enterprise Console serer, this type of change should be actiated by entering the following command: rmcorr_cfg update For other eent serers, restart the agent using the following command: wrmadmin r See the IBM Tioli Risk Manager Command Reference for details on using the rmcorr_cfg and wrmadmin commands. 106 IBM Tioli Risk Manager: Administrator s Guide

121 Chapter 8. Web Application Functional Oeriew Tioli Risk Manager 4.2 includes a Web Application for Tioli Risk Manager incident and incident group eents. These applications allow you to do the following: Create policies and recommendations for incidents and incident groups View additional information about the indiidual Tioli Risk Manager incident eents View a list of sensor eents that hae contributed to a Tioli Risk Manager incident View a list of contributing incidents for incident groups View information stored in the Tioli Inentory database about the systems associated with the incidents and incident groups The Web Application contains three applications, Eent Details, System Information, and Adisor. These applications allow you to perform the preiously listed functions. The Web applications are Web-browser based applications built using Tioli Presentation Serices Toolkit (PS), Jaa Serer Pages (JSP) and Jaa Serlet technologies. These technologies are used to present a common console to the user. The console uses the following roles: rmeentdetails, rmadisor and rmsysteminfo. The rmeentdetails role allows the user to access the Eent Details application. The rmadisor role allows the user to access the Adisor application. The rmsysteminfo role allows the user to access the System Information application. The Tioli Risk Manager Web Application install will assign all these roles to the WebSphere administrator. The administrator can modify these roles using the WebSphere administration console to grant Tioli Risk Manager Web Application access to other users and groups. To change role to user(s) or group(s) mappings for the Tioli Risk Manager Web applications, use the following steps: 1. On the WebSphere administratie console, select Application Enterprise Application IBMTioliRiskManager4.2 Map security roles to users/groups. 2. Select the roles that you want to modify the membership and click Lookup Users/Lookup groups: Perform a search to get the list of users Aailable. This will perform a search to get the list of users. 3. The list of aailable users is displayed. Select the users you want to modify from the Aailable list, and moe them to the Selected list. After making all modifications, click OK. 4. Click the Sae link at the top of the screen. 5. Click the Sae button. The application serer needs to be restarted. The RmWeb.properties file contains the Web-application specific information, such as database connection information for Eent Details and System information, and SMTP mail serer information for the Adisor. The install will update this file with the database connection information and SMTP mail serer information during configuration of the Web Application. If the database connection information, such as user ID and or password, need to be updated after the Tioli Risk Manager Web application installation run the wrmstashpw command to obfuscate the password Copyright IBM Corp

122 and enter the file name in the RmWeb.properties file, you can edit the file and update the corresponding entries. See the IBM Tioli Risk Manager Command Reference for details using this command. This file gets installed under the WEB-INF directory. For example: $WAS_HOME/installedApps/$NODE/ IBMTioliRiskManagerWebApp42.ear/ rmwebapp42.war/web-inf Where $WAS_HOME is the WebSphere installation directory, and $NODE refers to the name of the managed serer. The application serer will need to be restarted for the changes to take effect. The contents of this file are: // Indicates if the Eent Details is configured. EentDetailsConfig = true // The JDBC URL for the Eent Details TEC database. // Syntax: protocol:drier:subname: Example: jdbc:db2://foo.ibm.com:6789/tec EentDetailsTecDbUrl = jdbc:db2://foo.ibm.com:6789/tec // The class name of the drier for the Eent Details TEC Database EentDetailsTecDbDrier = COM.ibm.db2.jdbc.net.DB2Drier // Eent Details TEC Database user ID Example: db2 EentDetailsTecDbUser = db2 // Eent Details TEC Database password file EentDetailsTecDbPasswordFile = c:/ibm/riskmgr/etc/stashdbed.pwd // Max number of connections that need to established for the pool for Eent // Details TEC Database EentDetailsTecDbMaxConnections = 10 // The JDBC URL for the Eent Details Risk Manager Archie database. // Syntax: protocol:drier:subname: // Example: jdbc:db2://foo.ibm.com:6789/tec EentDetailsRmArchieDbUrl = // The class name of the drier for the Eent Details Risk Manager Archie // Database. Example: COM.ibm.db2.jdbc.net.DB2Drier EentDetailsRmArchieDbDrier = // Eent Details Risk Manager Archie Database user ID Example: db2 EentDetailsRmArchieDbUser = // Eent Details Risk Manager Archie Database password file EentDetailsRmArchieDbPasswordFile = // Max number of connections that need to established for the pool for Eent // Details Risk Manager Archie Database EentDetailsRmArchieDbMaxConnections = // Indicates if the adisor is configured. AdisorConfig = true // Name of the Rules file for Adisor AdisorRuleFile = AdisorRules.xml // The priorities AdisorHighestTitlePriority = 1 AdisorLowestTitlePriority = 100 AdisorDefaultTitlePriority = 50 // Name of the serer AdisorSMTPSerer = us.ibm.com // Indicates if the System Information is configured. SystemInfoConfig = true 108 IBM Tioli Risk Manager: Administrator s Guide

123 Global Security and UTF-8 // The JDBC URL for the System Information database. // Syntax: protocol:drier:subname // Example: jdbc:db2://foo.ibm.com:6789/in_db SystemInfoDbUrl = jdbc:db2://foo.ibm.com:6789/in_db // The class name of the drier for System Information Database // Example: COM.ibm.db2.jdbc.net.DB2Drier SystemInfoDbDrier = COM.ibm.db2.jdbc.net.DB2Drier // System Information Database user ID Example: inti SystemInfoDbUser = inti // System Information Database password SystemInfoDbPasswordFile = c:/ibm/riskmgr/etc/stashdbsi.pwd // Max number of connections that need to established for the pool for System // Information Database SystemInfoDbMaxConnections = 10 The Tioli Risk Manager Web Application requires that global security is enabled in the WebSphere Application Serer. The UTF-8 encoding needs to be enabled for multi-language support. Global security and UTF-8 encoding must be done by the user manually. The global security needs to be enabled before installing the Web application, and UTF-8 must be enabled for multi-language support to work. WebSphere global security needs to be enabled to allow only authorized users to administer WebSphere using the administratie console During Tioli Risk Manager Web Application installation, you will be prompted for the WebSphere administrator user ID and password. This user will be gien access to all the roles. Use the following steps to enable global security: Note: The following example uses the Local OS as the user registry. To use other user registries, refer to WebSphere Application Serer documentation. 1. Global security needs to be enabled on WebSphere Application Serer with the local operating system as the user registry, using the following steps: a. After the WebSphere Application Serer has been started, start the administratie console using a browser with the following URL: Where yourhost.domain is the host and domain name for the machine running WebSphere Application Serer. If you are using a non-default port for the WebSphere Application Serer console, then substitute that number for 9090 aboe. If security is currently disabled, log in with any user ID. b. Next, configure the user registry by selecting Security User Registries Local OS in the left-hand pane. Enter a Serer User ID and Serer User Password on the Local OS User Registry window. Enter a alid user ID in the LocalOS registry that is part of the Administrators group on the WebSphere Application Serer. This user ID must hae the Act as part of operating system priilege on Windows systems, or be root or hae root authority on Linux and UNIX-based systems. Click Apply. To sae the configuration, click Sae in the menu bar at the top. When the Sae panel appears, click Sae again. c. Click Security Global Security in the left-hand pane. The Global Security window is displayed. Select the Enabled check box, and deselect the Enforce Jaa 2 Security check boxes; these two items are the first two items. Chapter 8. Web Application 109

124 d. Click Apply or OK to sae your changes. To sae the configuration, click Sae in the menu bar at the top. When the Sae panel appears, click Sae again. 2. Before restarting the WebSphere Application Serer, log off of the administratie console. You can log off by selecting Logout in the top menu bar. 3. Stop the serer by using a command prompt in the WebSphere Application Serer/bin directory and entering the following command: stopserer serer_name 4. Restart the serer in a secure mode by entering the following command: startserer serer_name username <Serer User ID> -password <Serer User Password> 5. Once the WebSphere Application Serer has security enabled, you will not be able to stop the serer again without specifying an administratie user ID and password. To stop the serer once security is enabled, enter the following command: stopserer serer_name -username <Serer User ID> -password <Serer User Password> To use multiple language encoding support, you must configure an application serer with UTF-8 encoding enabled. Use the following steps to configure the application serer with UTF-8 encoding enabled: 1. Log in to the WebSphere Application Serer administratie console. Click Serers Application Serers. 2. On the Application Serer window, click on the name of the serer you want enabled for UTF On the settings page for the selected application serer, click Process Definition. 4. On the Process Definition window, click Jaa Virtual Machine. 5. On the Jaa Virtual Machine window, enter -Dclient.encoding.oerride=UTF-8 for Generic JVM Arguments and click OK. 6. Click Sae on the console task bar. 7. Restart the application serer. Accessing the Web Application from the Tioli Enterprise Console In order for the Web Application to work properly, the following requirements must be satisfied: You must configure the eent console, as described in the Web Applications chapter in the IBM Tioli Risk Manager Installation Guide. You must define an incident iew in the database used by Tioli Enterprise Console, as described in the Web Applications chapter in the IBM Tioli Risk ManagerInstallation Guide. Use the Tioli Enterprise Console to access the Tioli Risk Manager Web Application. The Tioli Enterprise Console needs to be configured to access the Web Application. Use the following steps to configure the Tioli Enterprise Console so that you can use the Tioli Risk Manager Web Application: 1. On the Tioli Enterprise Console, select Windows Configuration. 2. Click on Consoles, and select Console Preferences. 3. Click on Web Serer and then select the Use Other Web Serer radio button. 110 IBM Tioli Risk Manager: Administrator s Guide

125 4. Enter the Serer URL. The serer URL is the host name where the IBM HTTP Serer and WebSphere are installed. 5. Enter the Serer Port. The serer port is the port where the IBM HTTP serer is listening; the default is On Console Preferences, expand Web Serer and click on Eent Information. Select the Enable radio button. 7. Enter the Program Path. The program path is the path to the cgi-bin PERL script: /riskmgr/cgi-bin/rmweb.pl Click OK. The Tioli Enterprise Console serer is now configured. View the Tioli Risk Manager Web Application from the Tioli Enterprise Console. From the Summary Chart View, you select the Eent Viewer for either RM_Incident or RM_IncidentGroup. Use the following steps to iew the Tioli Risk Manager Web Application: 1. From the Tioli Risk Manager RM_Incident Eent Viewer, select the incident to be displayed. 2. Click the Information button. Alternatiely, you can right-click to display a pop-up menu shown in Figure 25, and then select the Information option. Figure 25. The Tioli Enterprise Console Eent Viewer Shows Information about the Attack Introduction to the Web Application Graphical User Interface The screens shown here are intended to coney a general iew of the Tioli Risk Manager Web Application graphical user interface. The Web Application graphical user interface is made up of three main areas, the Portfolio, the Banner, and the Workspace. An example of the Tioli Risk Manager Web Application graphical user interface follows. Chapter 8. Web Application 111

126 Figure 26. Tioli Risk Manager Web Application Graphical User Interface The Portfolio is the area of the screen where you can find the actions that you hae the proper authority to access; these actions are Eent Details, System Information, and Adisor. The Banner area is in the upper part of the screen where a product or company logo can appear that is specific to the logged on user. The Workspace area is in the middle of the screen, and is where the user s work will appear for a gien action. The Workspace will also display the Welcome page by default when a user logs in. Note: You will not see the Welcome page or the Portfolio area if you only hae access to System Information. The Tioli Risk Manager Web Application contains a robust, and dynamic online help system. You access this system by clicking on the question mark icon,?, in the upper, right-hand corner of the Workspace. After clicking the icon, the system will automatically display the online help topic associated with the window you are currently displaying. These topics will explain the oerall purpose of the window, and of any entry fields or buttons the window contains. The topic will also hae links to additional topics that contain information about tasks that can be accomplished in your current window, and reference topics that help explain any adanced concepts. The help system also contains a search feature, and a topic index, that may be used to search for specific topics. The search window can accept partial entries and wild cards. The first screen you will see when you start the Tioli Risk Manager Web Application is the Sign On window. This screen is used to ensure security, and to determine what Web application you will hae access to. This screen has two entry fields: User Name and Password. These fields are both required fields. Throughout the entire Tioli Risk Manager Web Application, all required fields will 112 IBM Tioli Risk Manager: Administrator s Guide

127 hae an asterisk next to the title, and the entry field will hae a yellow background. An example of the Sign On window follows. Figure 27. Sign On Window Once the Sign On window is displayed, you must enter a alid user ID and password in the User Name and Password fields and click OK. If the Sign On process can not be completed, you will see an error message of Incorrect user ID or Password. Please see error message appendix of the IBM Tioli Risk Manager Problem Determination Guide for more information on how to correct this error. Eent Details The Eent Details application allows you to iew additional information about the indiidual Tioli Risk Manager incident eents, iew a list of sensor eents that hae contributed to a Tioli Risk Manager incident, and iew a list of contributing incidents for incident groups. There are currently seen types of incidents, and seen types of incident groups. You select the incident or incident group that you want more information on in the Tioli Enterprise Console, and then click the Information button. In order to understand that information displayed by the Eent Details application, you must understand the differences and relationships between sensor eents, incidents, and incident groups. A sensor eent is a single eent reported by a Tioli Risk Manager sensor/adapter to a Tioli Risk Manager serer. It contains many attributes including: date/time, eent class, originating host, seerity, descriptie message, and others. An incident is an accumulation of sensor eents occurring within a limited time window, on the order of 5 to 20 minutes. In order for an incident to be created, a seerity leel threshold must be exceeded within the time window. The seerity leel is the accumulation of the seerity leels in all the contributing sensor eents. For a sensor eent to contribute to an incident, the eent must match preious eents on one or more of three attributes: eent Chapter 8. Web Application 113

128 category (or family), source host, destination host. An incident has fewer attributes than a sensor eent. These attributes include: begin window timestamp, end window timestamp, aggregated seerity leel, threshold seerity leel, list of sensors, list of signatures, list of source hosts, list of destination hosts, list of categories. Each new incident also contributes to an incident group. Incidents that share the same matching attributes with preious incidents are added to the preiously created incident group. A new incident group is created from incidents that hae no matching attributes in common with preious incidents. There are fie windows in the Eent Details application. The Eent Details Eents window is used to create customized queries that return specific sensor eent information on the sensor eent that make up an incident or incident group. An example of the Eent Details Eents window follows. Figure 28. Eent Details Eents Window The Eent Details Eents Results window displays the sensor eent information that matches the query created using the Eent Details - Eents window in a table. An example of the Eent Details Eents Results window follows. 114 IBM Tioli Risk Manager: Administrator s Guide

129 Figure 29. Eent Details Eents Results Window The Eent Details Incidents window is used to create customized queries that return specific incident information on the incidents that make up an incident group. An example of the Eent Details Incidents window follows. Chapter 8. Web Application 115

130 Figure 30. Eent Details Incidents Window The Eent Details Incidents Results window displays the incident information that matches the query created using the Eent Details - Incidents window in a table. An example of the Eent Details Incidents Results window follows. Figure 31. Eent Details Incidents Results Window The Eent Details - Details window displays detailed sensor eent, incident, or incident group information in a table. The information displayed comes from the Tioli Enterprise Console product. An example of the Eent Details Details window follows. 116 IBM Tioli Risk Manager: Administrator s Guide

131 Figure 32. Eent Details Details Window The alues for one of the attributes displayed on the Eent Details Details window, the Sensor Category, is detailed below. Table 13. Eent Details Details Window Sensor Type Sensor Category Sensor Name Sensor Abbreiation Web IDS Web IDS sensor webids Host IDS HostIDS for AIX sensor OS_AIX HostIDS for Solaris sensor HostIDS for Linux sensor HostIDS for Windows sensor HostIDS for HP-UX sensor Symantec Intruder Alert ISS RealSecure System Agent OS_Solaris OS_Linux OS_Win OS_HPUX ITA Network IDS NetworkIDS sensor NIDS Cisco Secure IDS (formerly NetRanger) NetRanger ISS RealSecure IDS Snort IDS realsecuresa csids netranger realsecure Snort Chapter 8. Web Application 117

132 Table 13. Eent Details Details Window Sensor Type (continued) Sensor Category Sensor Name Sensor Abbreiation Firewall CheckPoint Firewall-1 fw_cpfw Cisco Secure PIX FW IBM SecureWay Firewall CyberGuard Firewall NetScreen Firewall Zone Alarm Personal Firewall Microsoft Windows XP Firewall Tiny Personal Firewall fw_pix fw_ibm fw_cyberguard fw_netscreen fw_zafw fw_xpfw fw_tpfw Router Cisco Routers CiscoRouter AntiVirus Symantec AntiVirus AV_Symantec McAfee Alert Manager Trend Micro Control Manager Wireless Wireless Security Auditor WSA AV_McAfee Access Control IBM Tioli Access Manager AM4.1 Priacy Management IBM Tioli Priacy Manager PM1.1 Database Oracle Enterprise Serer DB_Oracle Management Points/Other IBM DB2 Uniersal Database ISS RealSecure SiteProtector (Management Point for ISS RealSecure Sensors) Enterasys Dragon Serer (Management Point for Enterasys Dragon Sensors) OpenSSH Secure Shell AV_TrendMicroControlManager DB_MSSQL ISS SiteProtector or ariable based on SENSORNAME field Dragon openshh System Information An incident is generated by Tioli Risk Manager correlation rules that are applied against a stream of incoming sensor eents. If a set of sensor eents arriing within a certain time window hae characteristics that match the correlation rules, an incident is created. If the incident relates to a preiously created incident group, the incident group is augmented with the new information from the new incident. Stored within the incident, or incident group, data from the host name or IP address of the source system, the destination system, and the systems where the sensor is located. Some of these host names and IP addresses may actually be the same system, or they could also be four different systems. System Information allows an administrator to iew specific information pertaining to these systems. It uses the Tioli Inentory database from IBM Tioli Configuration Manager. System Information will only work if the Inentory database and Tioli Configuration Manager are present. A predefined subset of Tioli Inentory database name attributes from within these iews has been selected to be displayed by System Information: computer, operating system, IP address, computer memory, system partitions, installed software, natie software, and network card. For more information on these iews see the IBM Tioli Configuration Manager product documentation. 118 IBM Tioli Risk Manager: Administrator s Guide

133 The System Information application has two windows, the System Information window and the System Information Results window. The System Information window allows you to select a system address category, and then an IP address or host name to display Tioli Inentory database information about that system. Figure 33. System Information Window The System Information - Results window displays the results of your search for system information. The results will contain information found in the Tioli Inentory database; if a line is blank there was no data for that particular field. Chapter 8. Web Application 119

134 Figure 34. System Information Results Window For more information on how to use System Information, and the information that it displays, please see the online help. Adisor The Adisor application displays a series of Web pages that proide information and additional Web sites to an administrator in response to a sensor eent, incident, or incident group. For more information on how to use the Adisor GUI, see the online help. The Adisor toolkit is used to define security rules and response actions using XML in a file called AdisorRules.xml. The Web application uses the rules file to apply the defined security rules to eents selected from the Tioli Enterprise Console. It then performs the response actions defined in the rules file. The response action is a Web page that proides instructions or recommendations on how to best handle the eent. The Adisor Toolkit proides sample security rules and associated actions in a sample rules file. This file is meant to demonstrate how to use this tool effectiely. The security rules and response actions can be modified or expanded to suit indiidual needs. The instructions or recommendations can displayed on one of four possible Adisor Web-page types: Static Text page, URL page, page or Run Program page. Adisor Rules File The Adisor toolkit sample rules file, along with a DTD file, is installed when the Adisor is installed. The DTD file details the possible alues, and uses of, the 120 IBM Tioli Risk Manager: Administrator s Guide

135 entries in the rules file. The sample rules file is enabled by default in the Web application RmWeb.properties configuration file in the AdisorRulesFile section; AdisorRuleFile=AdisorRules.xml To use a different rules file, or more than one rules file, update the AdisorRulesFile section of the RmWeb.properties configuration file. For example, AdisorRuleFile = rule.xml, rule2.xml, rulen.xml Both of these files are located in the same directory: <WebSphereinstdir>/IBMTioliRiskManagerWebApp42.ear/rmwebapp42.war/WEB-INF where <WebSphereinstdir> is the WebSphere Application Serer installation location. There are three main components of the Adisor rules file: list of filters, list of rules, and list of actions (Web pages to display). Each of these three components use unique IDs to differentiate their entries from other entries within the same component, as well as from different components. List of Filters The filters use logical operators in conjunction with a a user defined set of known eent attribute alues. It is these attribute names and their expected alues that are then compared to the actual eent attribute alues. If an eent meets the criteria set forth by the filter, then it will be acted upon by the Adisor using the other entries in the rules file. The filters support the use of AND, OR, XOR and NOT logical operators. The eent attributes used for comparison hae the following key names: classname attribute login eenttime The classname key name is used to define the type of eent, for example, CSIDS_Route_Down. The alue used for comparison may be an exact match, or may describe the beginning text, end text, or een a subset. The alid comparisons for classname are: startswith endswith equals contains For example, the classname alue to search for may be startswith CSIDS or contains Route. The attribute key name can be any eent attribute name, and may use one of the following possible comparisons: notnull null contains equals equalsignorecase startswith endswith numeric_equal Chapter 8. Web Application 121

136 numeric_greater numeric_less numeric_greater_equal numeric_less_equal The login alue is the operating system log in ID, and only an exact match is permitted. Theeenttime is specified as follows: hours:min:seconds. The eenttime can occur before a particular time, after a particular time, or between the hours of the start and end time. These filter key names can be used for sensor eents, incidents, or incident groups. Attributes specified during agent correlation attribute mapping are alid filter attributes, for example a comparison of the rm_customerid. An example of a filter with a unique ID of route_down that looks for an exact match between an eent type called CSIDS_Route_Down and the filter s classname of CSIDS_Route_Down follows. <filter id="route_down"> <AND> <classname matchtype="equals" alue="csids_route_down"/> </AND> </filter> The next example contains a filter with an ID of ce_link that uses the OR and AND logical operators and the classname and attribute filter key names. The ce_link filter specifies that only eents originating from either NIDS or Web IDS are alid eents. Any definitions residing between the OR tags indicate that only one of those filter definitions must be satisfied in order for the OR to resole to true. The filter proides further comparisons between the AND tags. These comparisons are for specific eent attributes keys, rm_nametype and rm_nameid. These keys must exist and the text string stored for rm_nametype must exactly match CVE and the alue stored for rm_nameid may be anything alue but null. <filter id="ce_link"> <AND> <OR> <classname matchtype="startswith" alue="ww_"/> <classname matchtype="startswith" alue="nids_"/> </OR> <attribute id="rm_nametype" matchtype="equals" alue="cve"/> <attribute id="rm_nameid" matchtype="notnull"/> </AND> </filter> To demonstrate the filtering feature for time and for numeric comparisons, the example below defines the filter s criteria as any critical eent arriing between 5 PM and 9 AM the next morning with a rm_leel alue greater than 5. <filter id="after_hours> <AND> 122 IBM Tioli Risk Manager: Administrator s Guide

137 <attribute id="seerity" matchtype="equals" alue="critical"/> <eenttime matchtype="between" start="17:00:00" end="09:00:00"/> <attribute id="rm_leel" matchtype="numeric_greater" alue="5.0"/> </AND> </filter> To illustrate the use of the NOT operator, the filter definition below specifies that an authorized user modifying the firewall policy would be ignored, but any other user modifying the firewall policy would meet this filter s criteria. <filter id="cpfw_change_policy"> <AND> <classname matchtype="equals" alue="cpfw_control"/> <NOT> <attribute id="rm_sourcehostname" matchtype="contains" alue="<sysadmininfo>"/> </AND> </filter> Where <SysAdminInfo> is the system administrator information. Since different members of a team can hae different leels of responsibilities or authority, filtering on a log in ID can be beneficial. The example below demonstrates how to selectiely proide information to a particular user. Specifically, the filter is triggered if the user is logged in as Admin5 and if the alert indicates that someone is attempting to FTP repeatedly into a system with the incorrect user ID. <filter id="cpfw_ftp_deny"> <AND> <classname matchtype="equals" alue="cpfw_ftp_deny"/> <attribute id="cpfw_additional_info" matchtype="notnull"/> <login id="admin5"/> </AND> </filter> List of Rules A rule defines one or more filters whose criteria must be met in order to perform an action. As with filters, each rule has a unique ID. The components of a rule are matchfilter and withaction. The matchfilter component proides either a single filter ID or a list of filter IDs. When a list of filter IDs is proided, then each filter specified must meet all criteria in order for the associated action to be performed. The withaction component defines the action to be performed, that is to display a single Web page or a list of Web pages. Below is an example of a rule called ce_recommendations, that defines a single filter ID called ce_link. When the ce_link filter criteria is met, the action ID of goto_ce_site causes a single Web page to be displayed. Chapter 8. Web Application 123

138 <rule id="ce_recommendations"> <matchfilter id="ce_link"/> <withaction id="goto_ce_site"/> </rule> The next example rule demonstrates the use of multiple filters and multiple actions. Note that multiple filters, or multiple actions, are separated from each other by a comma. <rule id="crit_after_hours"> <matchfilter id="after_house, cpfw_change_policy"/> <withaction id="notify_after_hours, restore_firewall_policy"/> </rule> List of Actions An action is the display of a Web page. There are four predefined templates: the Static Text page, the URL page, the page, or the Run Program page. While the same Web page can be specified for multiple rules, only one copy of a specific Web page will be displayed in the Web application task list een if there are multiple rules specifying that same Web page. In other words, if two rules specify the Web page to contact XYZ, and both of those rules are triggered at the same time, only one Web page to contact XYZ will be listed in the Web application task list. Howeer, it is possible to hae more than one Web page listed in the Web application task list if the action IDs for those Web pages are different. For example, one Web page may be to contact XYZ, and another Web page would be to open a trouble ticket. The definition of these two Web pages would require two different action IDs, and would therefore be considered unique; both Web pages could be simultaneously listed in the Web application task list. The actions specify how to display the information proided in the predefined template Web pages. Each action has a unique ID. Each of the four predefined template Web pages can display a title, titlelayout and content region of the Web page. The title is the text displayed on both the title bar and the portfolio region. See Figure 26 on page 112 for an example of the portfolio region. The titlelayout is the text on the page that seres as the title for the content region. The content area proides a detailed message of what a user should do. For example in the image below, the title is View CVE Recommendations, the titlelayout is set to Click on the link below to iew more details about the alert, and the content region is set to a hyperlink with the corresponding text of CVE Link 124 IBM Tioli Risk Manager: Administrator s Guide

139 Figure 35. Sample IBM Tioli Risk Manager Web Application Adisor Web Page Layout Resource IDs and Dynamic Data: The text displayed in these regions is either specified by a resource ID or hard coded text. The resource ID corresponds to an entry in the CustomAdisorResource_msg.properties file, and it is that data that is displayed on the Web page. A resource ID can include static or dynamic data. Static data is a text string. You only need to specify a resource ID in the rules file when using static data. For example, in the rule files you would hae an entry such as: title="cetitle" Where cetitle is a resource ID. In the CustomAdisorResource_msg.properties file, you would hae an entry that defines the cetitle resource ID, such as: cetitle=view CVE Recommendations When the Web page is displayed, the text View CVE Recommendations will be displayed in the title area. Dynamic data uses a resource ID and an input parameter to determine what to display on the Web page; for example, resource_id:inputparameter. A ariable, that contains data from an eent attribute, can also be used as an input parameter or as part of an input parameter. You define a ariable by using a percent (%) sign at the beginning an end of the ariable. Here is an example of a resource ID with dynamic data: content="cecontent: Where cecontent is the resource ID, and http// is the input parameter, and %rm_nameid% is a ariable that will contain data from the rm_name eent attribute. In the CustomAdisorResource_msg.properties file, you would hae the following entry: cecontent=<li><a href = {0}>CVE Link</a> Resource IDs using dynamic data will replace the number in the brackets, such as {0} in our preious example, with the input parameter information specified in the action in the rules file. In our preious example, the content region uses a resource ID and dynamic data information. When the Adisor application is creating the URL Web page, the content region will be transformed from: <li><a href={0}>cve Link</a> to <li><a href= Chapter 8. Web Application 125

140 The HTML tag of <li> is a bulleted list character, and the HTML anchor tag <a href={0}>cve Link</a> represents hyperlink information. The {0} is a placeholder for dynamic data, and is usually replaced with a URL address. The action in our example specifies that the{0} should be replaced with The eent attribute key name of %rm_nameid% is replaced with that eent attribute s alue. For example, if the rm_nameid eent attribute contains the alue CAN , then the hyperlink proided on the URL Web page would be displayed as When a user clicks on the this hyperlink, they would be redirected to the CVE Web page that describes the CAN ulnerability. While the preious example of dynamic data only lists one input parameter, multiple input parameters can be used and they are separated from each other by a colon. For example, a resource ID that uses multiple dynamically obtained input alues would be expressed as ResourceID:inputParm1:inputParm2:inputParmN. The corresponding CustomAdisorResource_msg.properties file would hae an entry of ResourceID=Message text containing three input parameters of {0}, {1} and {2}. The first input parameter would be used in place of {0}, the second in place of {1}, and the third in place of {2} The following is an example of an action that one could define in the rules file. The example defines an URL Web page, and uses resource IDs defined in the CustomAdisorResource_msg.properties file to specify the text to display. The UrlPage action uniquely identified as goto_ce_site below uses resource IDs with no dynamic data for the title and titlelayout, and uses a resource ID to display dynamic data for the content region. <urlpage id="goto_ce_site" title="cetitle" titlelayout="cetitlelayout" content="cecontent:http// Prioritizing Web Pages in the Task List: Since more than one type of Web page can exist in the task list, a means to prioritize the Web page order is needed. The Adisor toolkit proides the capability to prioritize multiple Web pages in the Web application task list. In order for the Adisor application to accurately prioritize the Web pages, the Adisor application must know the lowest and highest alues in order to determine if the Web pages should be ordered in ascending or descending order. The definitions for highest and lowest priority default alues are specified in the Web application configuration file, RmWeb.properties. For example: AdisorHighestTitlePriority = 1 AdisorLowestTitlePriority = 100 AdisorDefaultTitlePriority = 50 The actions proide a key name called titlepriority that accepts a numeric alue that is used to define the priority alue. Once the list of Web pages to display in the task list has been identified, the titlepriority settings will determine the listing order for those Web pages in the task list. If the titlepriority information is missing from an action definition, then the default priority alue is used. If the Web application configuration file does not set a default alue but instead sets the highest and lowest priority alue, then the default alue will be the mean of the highest and lowest alues. If either the highest priority or lowest priority alue is missing then the titlepriority feature is disabled, and then any alue specified for an action s titlepriority is ignored. 126 IBM Tioli Risk Manager: Administrator s Guide

141 The following is an example of the user specifying the priority ranges in the configuration file and then implementing those priority leels in the rules file. You would make the following entries in the RmWeb.properties file: AdisorHighestTitlePriority = 1 AdisorLowestTitlePriority = 100 AdisorDefaultTitlePriority = 50.0 You would make the following entries in the AdisorRules.xml in the action definition: <statictextpage id="1" title="mytitle" titlelayout="mydescription" content="mydetails" titlepriority="25" /> <statictextpage id="2" title="mytitle2" titlelayout="mydescription2" content="mydetails2" titlepriority="100" /> <statictextpage id="3" title="mytitle3" titlelayout="mydescription3" content="mydetails3" /> <statictextpage id="4" title="mytitle4" titlelayout="mydescription4" content="mydetails4" titlepriority="75" /> If the four Web pages defined aboe were to be listed in the task list, the order would be 1, 3, 4 and 2. Since the highest priority leel was specified in the RmWeb.properties file as the alue 1, and the lowest priority leel was specified as 100, the Adisor application organizes the order of the Web pages in ascending order. Since ID 3 did not specify a titlepriority, then the default priority alue of 50 specified in the RmWeb.properties file was used as the titlepriority alue for that particular Web page. Note: This function is only aailable in the Adisor application. Customizing Web Pages: The Run Program and pages hae entry fields that can be customized using the action definition. The Run Program Web page has a Command entry field used to enter the program to be run. It also has an Enironment settings entry field for any required program enironment alues. Use the program alue of the action definition to customize the Command entry field. Use the programen alue to customize the Enironment settings entry field of the action definition. The Web page has entry fields for a list of recipients, (To, CC, and BCC), an subject line, and a text area for the body of the . These entry fields are can be customized to proide the user with default alues. Use the sendto alue of the action definition to customize the To entry field. Use the sendcc alue of the action definition to customize the CC entry field. Use the sendbcc alue of the action definition to customize the BCC entry field. Use the sendsubject alue of the action definition to customize the Subject entry field. Use the sendbody alue of the action definition to customize the Body Chapter 8. Web Application 127

142 text area. The one entry field that can not be customized is the From entry field. The alue of this field must be entered manually by the user in the From entry field when sending an . If default alues for these entry fields are not defined in the action, then when the Web page is created those entry fields will be blank. If a user changes the alue for an entry field, the default entry field alue specified in the rules file can be restored by pressing the Reset button. See the Run Program Web Page on page 133 and Web Page on page 136 sections of this chapter for further information on how to customize these Web pages. Special Characters: If a text string displayed on the Web page requires a special character like double quotes, then the single quote XML tag (") must be used at the beginning and end of the hard coded string. The double quoted string displayed on the Web page is now embedded in hard coded string. For example, if the Web page needs to display the text: My "friend" Bob will be joining us. This text would be represented in the action definition as the following: content="&apos;my "friend" Bob will be joining us.&apos;" Some characters hae specific meaning in an XML file, and therefore they must be replaced with the XML tag equialent in order to aoid XML parsing errors. Below is a list of XML tags that required an XML tag equialent: XML Tag Equialent & < < > > &apos: " Character & Using Non-English Text in Web Pages: To proide Web pages in arious languages, you are required to use resource IDs and corresponding text strings in the CustomAdisorResource_msg.properties file. Text that has been created locally for display on the Web pages will be stored in a default resource file called CustomAdisorResource_msg.properties. To use translated ersions of this file, the translated text will reside in resource files with the naming conention of CustomAdisorResource_msg_xx.properties where xx is the language and/or in resource files with the naming conention of CustomerAdisorResource_msg_xx_yy.properties where xx is the language and yy is the country. The following is a list language alues: de es fr it ja ko zh_cn zh_tw pt_br 128 IBM Tioli Risk Manager: Administrator s Guide

143 These files are located in the IBMTioliRiskManagerWebApp42.ear\rmwebapp42.war directory. A sample CustomAdisorResource_msg.properties file is shipped with the product, and is placed in this directory. The resource IDs in the sample properties file will correspond to resource IDs specified in the sample AdisorRules.xml file, thus proiding a way to keep the rules logic separate from the translatable text and proiding a concrete example. When multiple message properties files exist, the country and language of the client browser will be used to determine what file should be used for translated text. First, a search attempting to match the client browser s country and language setting occurs and if a matching CustomAdisorResource_msg_xx_yy.properties file is found, then the resource IDs specified for the action will be extracted from this file. If the client browser s country language specification does not match the list of properties files, then a search for a less stringent match will occur. This next search attempts to match the client browser s language setting, and if the matching CustomAdisorResource_msg_xx.properties file is found, then the resource IDs specified in this file will be extracted. Howeer, if client browser s language does not match any of the properties file, then the default message file will be used. Static Text Web Page The Static Text Web page is one of the four predefined Web page templates. The static text information will either be hard coded text that is specified in an action definition in the Adisor rules file, or it will be obtained from a resource file called CustomAdisorResource_msg.properties. One or more resource IDs can be listed for the static text Web page. A resource ID may contain a single sentence or a complete paragraph. You can also insert information from an eent into the text; for example; shutdownport=shut down the port for {0}. Note that if the text associated with the resource ID expands more than one line, add a forward slash ( \ ) to indicate that the text continues to another line. The {0} will be replaced by the alue stored in the attribute, such as rm_destinationtoken. It is also possible to use HTML tags and Jaa script to customize the content region of the Static Text Web page. Here is an example of using an eent type attribute for filter criteria, and then using an action to generate a Static Text Web page that contains procedures to perform in response to the alert information. The Adisor rules file has a filter definition called route_down that looks for an eent type of CSIDS_Route_Down. The filter entry in the rules file is: <filter id"route_down"> <AND> <classname matchtype="equals" alue="csids_route_down"/> </AND> </filter> The rule entry csids_route_down_recommendationsspecifies a single filter ID of route_down, and that when that filter definition is satisfied then the two Web pages specified under withaction will be generated and displayed on the browser. <rule id="csids_route_down_recommendations"> <matchfilter id="route_down"/> <withaction id="iew_route_down_rec,notify_route_down_rec"/> </rule> Chapter 8. Web Application 129

144 The action definitions listed aboe, iew_route_down_rec and notify_route_down_rec, indicate that two Web pages will be displayed. The iew_route_down_recaction is an example of a Static Text Web page. The notify_route_down_rec is an example of an Web page. Since this section is focusing on Static Text Web pages, only the first action will be explained in this section. This example also demonstrates the use of hard coded text instead of resource IDs for the title, titlelayout, and content regions of the Web page. <statictextpage id"iew_route_down_rec" title=""csids Route Down Alert Recommendations"" titlelayout="%rm_description%" content=""the alert was triggered at %rm_timestampt% from sensor id %rm_sensorpid% perform procedures A, B, and C"" /> The Web page would look like the following: Figure 36. Static Text Web Page Example No Formatting If you want to format the data using HTML tags below is an example of the text definitions. While it is possible to hard code this information into the rules file, the use of the XML tags instead of the quotation mark ( ), <and > symbols can make the example hard to understand. The action definition for content would be: content="htmltable:%rm_timestamp%:%rm_sensorpid%" The CustomAdisorResource_msg_.properties file would define HtmlTable as: HtmlTable=<table BORDER="1" CELLPADDING="3" CELLSPACING="0">\ <tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">\ <td COLSPAN=2><b>Alert Information</b></td>\ <tr><td><b>time</b></td><td> {0} </td></tr>\ <tr><td><b>sensor ID</b><td></td> {1} </td></tr>\ <tr><td><b>procedures to perform</b></td><td>a, B, C</td></tr></table>\ The \ at the end of the line indicates that the definition continues to the next line. The Web page would look like the following: 130 IBM Tioli Risk Manager: Administrator s Guide

145 Figure 37. Static Web Page Example Formatted You can also use Jaa script to customize the content region. For example, to display a pop-up window and print a message on the Web page, set the resource alue to: JSexample=<SCRIPT LANGUAGE="jaascript">\ alert ("Hi this is an example of using Jaa script");\ document.write("use Jaa script to write this");</script> URL Web Page The Adisor toolkit proides a way for you to display a Web page from another Web site in the Web application window, or use the Web browser s option to open it in a separate window. Here is an example of using the eent attribute alues rm_nameid and rm_nametype to generate the URL that will direct the user to the Common Vulnerabilities and Exposures (CVE) Web page. The Web page will display a description and recommendations for the suspicious eent related to the eent attribute alues. Let s assume that rm_nameid=can and rm_nametype=cve. The URL to direct the user would then be The filter for this URL page definition will be satisfied if an eent originated from either Web IDS or NIDs, and the eent information contains a CVE ID, for example: <filter id="ce_link"> <AND> <OR> <classname matchtype="startswith" alue="ww_"/> <classname matchtype="startswith" alue="nids_"/> </OR> <attribute id="rm_nametype" matchtype="equals" alue="cve"/> <attribute id="rm_nameid" matchtype="notnull"/> </AND> </filter> Chapter 8. Web Application 131

146 The rule for this URL page definition states that when the criteria for the filter ce_link is met then the Web page defined for ce_recommendations is displayed. <rule id="ce_recommendations"> <matchfilter id="ce_link"/> <withaction id="goto_ce_site"/> </rule> The action for this URL page definition states that a URL Web page template should be loaded with the following information: <urlpage id="goto_ce_site" title="cetitle" titlelayout="cetitlelayout" content="cecontent: /> The resource IDs cetitle, cetitlelayout, and cecontent are defined in the CustomAdisorResource_msg.properties file as: cetitle=view CVE Recommendations cetitlelayout=click on the link below to iew more details about the alert cecontent=<li><a href={0}>cve Link</a> The Web page would look like the following: Figure 38. URL Web Page Example Link After selecting the CVE Link, the Web page would look like the following: 132 IBM Tioli Risk Manager: Administrator s Guide

147 Figure 39. URL Web Page Example Additional Web Site Run Program Web Page The Run Program Web page is used to run programs that are local to the Web serer. You can specify a rule to run the program and to specify any required input parameters and/or any enironment ariables. Once the program is running, the data normally sent to the standard out log file, STDOUT, and standard error log file, STDERR, is redirected to be displayed on the Web page. You can not use the Run Program page to run a script, due to limitations with using the Jaa API s for inoking a process and not being able to obtain access to children processes. The Run Program Web page proides two entry fields. The first entry field is labeled Command. The Command entry field label contains an asterisk, and the entry field itself is yellow by default. The asterisk and the yellow color for the entry field indicate that this entry field is a required field. The second entry field is labeled Enironment settings. This field is not required and the label does not contain an asterisk, and the entry field is white. The Enironment settings entry field proides a way to set enironment ariables that may be required by the program in order to run properly. The Run Program Web page also has three buttons: Start, Abort, and Reset. When the Start button is selected, the Jaa API RunTime.exec() is inoked to launch the program specified in the Command entry field. It will set the program s enironment information to the data specified in the Enironment settings entry field. When the Abort button is selected, if the program has been started but it is not finished executing, the process started from RunTime.exec() will be terminated. When the Reset button is selected, the default alues for the entry field data are displayed. The default alues are obtained from the action definition for the Command and Enironment settings entry fields. You can also use eent data as an input parameter to a program; for example, "jaa d somepath companyprogram alert %rm_sensortoken%" Chapter 8. Web Application 133

148 The %rm_sensortoken% ariable will be replaced by the actual alue stored in the attribute prior to inoking RunTime.exec(). Here is an example of a Run Program Web page that specifies that a Jaa program located on the Web Serer is to run in response to the alert information obtained from the eent. The Command entry field will be preset to a Jaa program called ourprogramonwebsphereserer and the program s classpath is preset to -cp c:\ourcompany.jar. The Run Program action definition also proides two enironment ariables, login ID and a text string, that are required by the Jaa program to run properly. The filter used to display the Run Program page will hae an ID of cpfw_change_policy. This filter determines whether a person without the proper authority has modified the firewall policy. For example: <filter id="cpfw_change_policy"> <AND> <classname matchtype="equals" alue="cpfw_control"/> <NOT> <attribute id="rm_sourcehostname" matchtype="contains" alue=".sys3admin.ourcompany.com"/> </NOT> </AND> </filter> The rule for the Run Program page will hae an ID of restore_policy. This rule specifies that an action definition for the action ID of restore_firewall_policy should be displayed when the filter ID of cpfw_change_policy is met. For example: <rule id="restore_policy"> <matchfilter id="cpfw_change_policy"/> <withaction id="restore_firewall_policy"/> </rule> The action for the Run Program page will hae an ID of restore_firewall_policy. This action customizes the title, titlelayout and content regions of the Run Program Web page. In addition, the two entry fields displayed on the Web page are also customized. The Command entry field displays the data specified for the action definition s program alue. The Enironment settings entry field displays to the data specified for the action definition s programen alue. For example: <runprogrampage id="restore_firewall_policy" title="restorefirewallpolicy" titlelayout="changedetected" content="inokeprogram" program=""jaa -cp c:\ourcompany.jar ourprogramonwebsphereserer"" programen="&aps;userid=%login% preference="fast cars"&apos;" /> The corresponding resource IDs for restorefirewallpolicy, changedetected, and inokeprogram are defined in the CustomAdisorResource_msg.properties as: 134 IBM Tioli Risk Manager: Administrator s Guide

149 restorefirewallpolicy=restore Fire Wall Policy changedetected=checkpoint Firewall Detected Change in Policy inokeprogram=inoke the following program to restore the firewall. Look at the logs to erify change. The Web page would look like the following: Figure 40. Run Program Web Page Example When the user selects the Start, the RunTime.exec() will be inoked. Any data normally sent to the standard out log (STDOUT) will be displayed at the bottom of the page under the Command response area. And any data normally sent to standard error (STDERR) will be displayed as an error message. For example, if the program ourprogramonwebsphereserer sends an error message to the error log and also sends a message to System.out, the following could be displayed: Figure 41. Run Program Web Page Error Chapter 8. Web Application 135

150 For further information on troubleshooting errors on the Run Program page, see the IBM Tioli Risk Manager Problem Determination Guide. Web Page The Web page is used to send an in response to an eent. The Web page has fie entry fields: To, CC, BCC, From, and Subject. It also has one text area, Body, that contains the text of the message. Both the To and From entry fields are required fields denoted by the asterisk and a yellow color of the entry field. The data in the To, CC, BCC, and From fields must adhere to a proper address format of name@mailserername. The Web page also has two buttons, Send and Reset. When the Send button is selected, the is sent to the list of recipients. If an error occurs while contacting the mail serer, or if an address is not considered to be a alid format, then an error message describing the problem is displayed. When the Reset button is selected, the default alues for all fields are restored. The mail serer responsible for forwarding the s is specified in the Web application s configuration file, RmWeb.properties. For example: // Name of the serer AdisorSMTPSerer = us.mycompany.com During the installation process, you will be prompted for a alid mail serer name. This alue will be stored in the RmWeb.properties file for the AdisorSMTPSerer alue. For more information on the Web application installation process, see the IBM Tioli Risk Manager Installation Guide. Here is an example of an Web page that is customized so that it will display only for certain users, will only be generated for certain eents, and will hae the To, CC, BCC, Subject, and Body fields customized. Two filters are specified for this Web page example to demonstrate how filters can be specialized, and a collection of specialized filters can be used to define a specific rule. The rule below will require that all of the criteria specified for filter ID cpfw_ftp_deny and filter ID after_hours must be satisfied in order to trigger the rule s actions. The cpfw_ftp_deny filter definition specifies that any eent of type CPFW_FTP_Deny, with pertinent information stored in the eent attribute of cpfw_additional_info will be displayed to a user when the user s ID is Admin5. In this scenario, Web pages will be customized so that they will only display for specific users. For example: <filter id="cpfw_ftp_deny"> <AND> <classname matchtype="equals" alue="cpfw_ftp_deny"/> <attribute id="cpfw_additional_info" matchtype="notnull"/> <login id="admin5"/> The second filter definition specifies that any critical eent arriing between 5 PM and 9 AM and with an rm_leel exceeding a numeric alue of 5 will meet the filter s criteria. For example: <filter id="after_hours"> <AND> <attribute id="seerity matchtype="equals" alue="critical"/> <eenttime matchtype="between" start="17:00:00" end="09:00:00"/> <attribute id="rm_leel" matchtype="numeric_greater" alue="5.0"/> 136 IBM Tioli Risk Manager: Administrator s Guide

151 </AND> </filter> The rule for the page will hae an ID of crit_after_hours. It specifies that if the criteria for filter ID after_hours and the criteria for filter ID cpfw_ftp_deny are met, then a single Web page, as defined by the action notify_after_hours, is displayed. For example: <rule id="crit_after_hours"> <matchfilter id="after_hours, cpfw_ftp_deny"/> <withaction id="notify_after_hours"/> </rule> The action for the page will hae an ID of notify_after_hours. This action proides an example of customizing the title, titlelayout, content, sendto, sendcc, sendsubject, and sendbody. For example: <send page id="notify_after_hours" title="notify" titlelayout="afterhoursalert" content="opentroubleticket" sendto="opentroubleticket" sendcc="opentroubleticket@my.company.com" sendsubject="%msg%" sendbody="afterhours %cpfw_additional_info%:%rm_sourcetoken%" titlepriority="1" /> The text to display on the Web page is contained in the resource ID definitions of notify, afterhoursalert, opentroubleticket, and afterhours . These definitions are extracted from the CustomAdisorResource_msg.properties file and are defined as: notify=notify Appropriate Personnel opentroubleticket=open Se 1 trouble ticket afterhoursalert=critical Alert Receied After Hours afterhours ={0} orginating from {1} The action has a titlepriority of 1 indicates that this Web Page should be listed at the beginning of the task list, since the RmWeb.properties file set AdisorHighestTitlePriority=1. More information on how to set Web page priorities can be found in Prioritizing Web Pages in the Task List on page 126. The Web page would look like the following: Chapter 8. Web Application 137

152 Figure 42. Web Page Example After selecting the Send button, and if no errors were encountered, then the following message would be displayed: Figure 43. Web Page Example Success Message Once the Close Message link is clicked, the preious page is displayed again with the information stored in the entry fields when the Send button was selected. In order to iew the default alues, the Reset button must be clicked. 138 IBM Tioli Risk Manager: Administrator s Guide

153 Chapter 9. Reports The Crystal Reports component of Tioli Risk Manager proides twenty-two compiled reports that proide information for analysis of intrusion eents that might occur on a customer s system. Before you run the reports, you must hae a supported RDBMS client installed and configured on the system that the reports will run on. You must also hae a working Open Database Connectiity (ODBC) connection set up to the database that the archie table was created in. See Setting Up an ODBC Data Source Connection on page 142. What Are Tioli Risk Manager Crystal Reports? Tioli Risk Manager contains compiled reports created using the Compiled Reports feature of the Crystal Reports Designer program. The Compiled Reports format allows you to run reports without haing the Crystal Reports Designer installed on the system. Note: You must purchase and install the Crystal Reports Designer if you want to create or edit Crystal Reports. The compiled Crystal Reports proided with Tioli Risk Manager include Firewall Management Reports, Intrusion Detection Reports, Risk Assessment Reports, Eent Management Reports, and Virus Management Reports. Firewall Management Reports The following reports are for firewall management: Denied Connections by Network Address (rm_fw_02.exe) This report summarizes the number of denied connections within the customer s network categorized by the type of connection denied. Top Firewall Eents (rm_fw_07.exe) This report lists all classes of firewall-detected eents, ranked by the number of eents in each class and seerity grouping. Intrusion Detection Reports The following reports are for intrusion detection: Intrusion Eents by Network Address (rm_ids_05.exe) This report displays the number of IDS eents categorized by eent class for each host address. When the report is displayed, you can iew details about each eent. Top Attacked Hosts (rm_ids_04.exe) This report displays a bar chart showing the top 10 target hosts for intrusion eents. You can expand the data to display a pie chart showing the distribution of eents by class. Copyright IBM Corp

154 Top Intruders (rm_ids_12.exe) This report displays a bar chart showing the top 10 source hosts for intrusion eents. You can expand the data to display a pie chart showing the distribution of eents by class. Top Intrusion Eents by Category (rm_ids_13.exe) This report displays a bar chart showing the top 10 intrusion eent categories. Examples of eent categories are: Web Attack, Serice Attack, IDS Leel and so on. You can expand the data to display a pie chart showing the distribution of eents by class. Top Web Intrusion Eents (rm_ids_14.exe) This report displays a bar chart showing all classes of Web intrusion eents (where sensor type is webids ), ranked by the number of eents in each class. Risk Assessment Reports The following reports are for risk assessment: Access Violations by Network Address (rm_ra_01.exe) This report summarizes denied access attempts within the subnetwork categorized by the class of denied access. Authentication Eents by Network Address (rm_ra_02.exe) This report displays the number of authentication eents for each host address. A summary chart at the beginning of the report shows the hosts with the most number of authentication eents. Authentication eents are broken down into two broad categories: Allowed and Denied. You can double-click on an authentication category to iew a list of indiidual eents for the selected host and category. Failed Login Attempts by Host and User (rm_ra_03.exe) This report displays failed login attempts by host. You can use the Group By parameter to iew the data from the point of iew of destination hosts (what machine are you logging on to?) or source hosts (what machine are logging in from?). A summary chart at the beginning of the report displays the top 10 hosts, ranked by number of failed login attempts. The report text lists all hosts, ranked by number of failed login attempts. If you double-click on a host in the text section, you can see a pie chart showing the breakdown by user ID. If you double-click on a slice of the pie chart, you can see details about each indiidual eent. Eent Management Reports The following reports are for eent management: Eents by Category (rm_et_08.exe) This report summarizes all eents by category. Examples of category names include Denial of Serice, Network Leel Attack, and Trojan Horse. Eents by Customer (rm_et_04.exe) This report displays a pie chart showing the distribution of eents by customer name. Customer name may be a company name, line of business, geography, department number or any customer-specific ID. You can double-click on a customer name to see a bar chart showing the distribution of eents by host and class category. Finally, double-click on the desired segment of the bar chart to see a listing of indiidual eents within each host and class category. 140 IBM Tioli Risk Manager: Administrator s Guide

155 Eents by Month (rm_et_02.exe) This report displays a summary chart showing the number of eents receied each month, starting with the beginning of the current year. You can also select last year or the year before, using the Year parameter. You can iew weekly eent summaries, by double-clicking on any month in the chart. From the weekly summary chart, double-click on any week to see eent summaries by day. To iew a chronological listing of all the eents receied for a particular day, double-click on the bar for that day. Eents by Seerity (rm_et_03.exe) This report displays a pie chart showing the distribution of eents by seerity. You can double-click on a seerity leel to see another pie chart showing the distribution of eents by class. Finally, to see a listing of indiidual eents within each class, double-click on the desired class. Eents for the Last 7 Days (rm_et_07.exe) This report displays a bar chart showing the number of eents for each day in the last 7 days. Each colored segment on a bar represents the number of eents for a particular sensor type group (see Eents per Day by Address and Sensor Types below for a description of sensor type groups). You can double-click on a colored segment to display an eent list for a single day and sensor type group. Eents for the Last 24 Hours (rm_et_24.exe) This report displays a chart showing the total eents by hour oer the last 24 hours, broken down by sensor type groups. Each colored segment on a bar represents a sensor type group (see Eents per Day by Address and Sensor Types below for a description of sensor type groups). You can double-click on a segment to display an eent list for a single hour and sensor type group. Eents per day by Address and Sensor Type (rm_et_05.exe) This report displays the distribution of eents by sensor type across a network. A summary 3D chart shows the top seen IP addresses with the most number of eents, categorized by sensor type groups. The text section shows the number of eents receied per day at each host in the network, categorized by sensor type groups. All eents originate from one of the following sensor type groups: Antiirus Antiirus sensors such as Norton and McAfee. Database Sensors that report on security-related access attempts and configuration changes to database management systems (DBMS) such as Oracle and DB2. Firewall Firewall sensors such as Check Point FireWall-1, Cisco Secure PIX, IBM Firewall, ZoneAlarm. Host IDS Host-based sensors such as AIX, Solaris, Linux, Windows, RealSecure System Agent. Network IDS Network-based sensors such as NIDS, Cisco Router, Cisco Secure IDS, RealSecure IDS, SNORT. Web IDS Web-based sensors such as Web Intrusion Detection System (Web IDS). Wireless Wireless-based sensors such as Wireless Security Auditor. Eent Query (rm_et_10.exe) This report displays the distribution of eents by user selectable groups. You must select a Primary and Secondary group parameter from the following list: Chapter 9. Reports 141

156 Destination Host Source Host Customers Sensor Type Sensor Host Eent Category Eent Class Seerity Date Day of Week Hour of Day The default for Primary group is Customer; the default for Secondary group is Destination Host. The report displays a summary bar chart showing the top 10 eent counts within the Primary group. You can double-click on a bar and see a pie chart showing the top 15 eent counts within the Secondary group. Finally, you can double-click on a slice in the pie chart to see a listing of all eents in selected group. Top Eents (rm_et_09.exe) This report lists all classes of eents by the number of eents in each class and seerity grouping. Virus Management Reports The following reports are for irus management: Antiirus Scans and Updates (rm_a_10.exe) This report displays all hosts that hae had irus scans and signature updates, ranked by number of days since the last irus scan. The maximum number of days counted is 30. If a host has not been scanned for iruses in the last 30 days, then it will be assigned a alue of 30 days since the last scan. A summary bar chart shows the top 10 hosts that hae not been recently scanned. For each host, one bar shows the number of days since the last scan and another bar shows the number of days since the last update. In the text section of the report, you can double-click on a host to see a chronological list of irus scans and signature updates for that host. Top Infected Hosts (rm_a_06.exe) This report displays a bar chart showing the top 10 hosts infected with iruses. You can double-click on a host to see a list of iruses with date, time, antiirus endor name and irus description. Top Viruses (rm_a_02.exe) This report displays a pie chart showing the top 15 irus signatures. You can double-click on a signature group to iew irus eent detail, including time of eent, host affected, antiirus endor name and a descriptie message. Setting Up an ODBC Data Source Connection Before you create an ODBC connection, install and configure your database client. Consult your database administrator for the appropriate client configuration. 142 IBM Tioli Risk Manager: Administrator s Guide

157 After you install and configure your database client, set up an ODBC Data Source Connection to access the Tioli Risk Manager database from the systems running Tioli Risk Manager Crystal Reports. Refer to the following sections to set up an ODBC data source connection for your database. DB2 Register the DB2 database with the ODBC drier manager as a data source. On a Windows systems, you can make the data source aailable to all users of the system (a system data source) or only the current user (a user data source). You can use any of the following three methods to add the data source; howeer, if you installed the Client Configuration Assistant (CCA) when you installed DB2, it is recommended that you use the first method. Using the CCA to register the DB2 database as a data source To use the CCA to register the DB2 database as a data source: 1. Start the DB2 Client Configuration Assistant program. A list of aailable DB2 databases is displayed. 2. If your database is in the list, select the database and complete the following steps: a. Click Properties. The Database Properties window opens. b. If it is not already selected, select the Register this database for ODBC check box. On Windows systems, you can use the radio buttons to add the data source as either a user or system data source. c. Click OK. If your database is not in the list, complete the following steps: a. Click Add. The Add Database SmartGuide dialog box opens. b. Select Manually configure a connection to a DB2 database. Click Next. c. Enter the host name and port number of the DB2 serer. The default port number for DB2 serers is Check with your database administrator for the proper port number. Do not enter a serice name. d. Click Next. e. Enter the name of the database as it is defined on the serer. The default name is TEC for all Tioli Risk Manager installations. Check with your database administrator for the proper database name. f. Enter an alias and description. The alias can be any name not already used in the CCA database list. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. g. Click Next. h. Verify that the Register this database for ODBC check box is selected. i. Click Done. j. Click Close to finish. Note: If you want to erify connectiity, click Test Connection before you click Close to finish. Chapter 9. Reports 143

158 Using the Microsoft 32-bit ODBC Administration tool to register the DB2 database as a data source To use the Microsoft 32-bit ODBC Administration tool to register the DB2 database as a data source: 1. From the Windows Control Panel for Windows NT, click ODBC Data Sources to run the ODBC Administrator program. From the Windows Control Panel for Windows 2000, click Administratie Tools Data Sources (ODBC) to run the ODBC Administrator program. 2. On Windows systems, the list of user data sources appears by default. If you want to add a system data source, click System DSN or select the System DSN tab (depending on the platform). 3. Click Add. 4. Double-click the IBM DB2 ODBC Drier in the list. If the DB2 database is in the Database alias drop-down list, then select it. Change the Data source name if desired. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. Click OK to finish. If the database is not in the drop-down list, use the following instructions to add the database. a. Click Add or Add Database. The Add Database SmartGuide dialog box opens. b. Select Manually configure a connection to a DB2 database. Click Next. c. Enter the host name and port number of the DB2 serer. The default port number for DB2 serers is Check with your database administrator for the proper port number. Do not enter a serice name. d. Click Next. e. Enter the name of the database as it is defined on the serer. The default name is TEC for all Tioli Risk Manager installations. Check with your database administrator for the proper database name. f. Enter an alias and description. The alias can be any name not already used in the CCA database list. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. g. Click Next. h. Verify that the Register this database for ODBC check box is selected. i. Click Done. j. Click Close to finish. Note: If you want to erify connectiity, click Test Connection before you click Close to finish. Using the CATALOG ODBC DATA SOURCE command to register the DB2 database as a data source To use the CATALOG ODBC DATA SOURCE command to register the DB2 database as a data source: You can issue the CATALOG ODBC DATA SOURCE command at the command-line processor on Windows systems to register the DB2 database with the ODBC drier manager as a data source. For example, to use this command you can create a command-line processor script to register the required databases. Then 144 IBM Tioli Risk Manager: Administrator s Guide

159 run this script on all of the machines that require access to the DB2 databases through ODBC. See the CATALOG [ user system ] ODBC DATA SOURCE command in the IBM DB2 UDB Command Reference for more information. Oracle This section describes how to set up an ODBC connection to an Oracle database. During the database client configuration, you need to create a database alias (Net Serice Name) for the Tioli Risk Manager database. Use this alias as the data source serer name in step 7 of the following procedure. Note: Contact your system administrator for specific information to set up your database client. Use the Net8 Easy Configuration program to create a database alias. After you create an Oracle database alias, use the following procedure to create an ODBC data source for the Tioli Risk Manager database. 1. From the Windows Control Panel for Windows NT, click ODBC Data Sources to run the ODBC Administrator program. From the Windows Control Panel for Windows 2000, click Administratie Tools Data Sources (ODBC) to run the ODBC Administrator program. 2. Select the System DSN tab. 3. Click Add. 4. Select Oracle ODBC Drier, and click Finish. 5. Enter a name for this ODBC data source in the Data Source Name text box. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. 6. Enter a description for the data source in the Description text box. 7. Enter the database Net Serice Name in the Serice Name text box. Note: The database Net Serice Name must be the alias that you gae to the database when you configured the database client. 8. Enter the Tioli Risk Manager database user name (the default is tec) in the Userid text box. 9. Click OK twice to sae Data Source Name and exit the ODBC Administrator. Sybase This section describes how to set up an ODBC connection to a Sybase database. During the database client configuration, you need to create a database alias for the Tioli Risk Manager database. Use this alias as the data source serer name in step 7 on page 146 of the following procedure. Note: Contact your system administrator for specific information to set up your database client. Use the Sybase DSEdit program to create a database alias. After you create a Sybase database alias, use the following procedure to create an ODBC data source for the Tioli Risk Manager database. 1. From the Windows Control Panel for Windows NT, click ODBC Data Sources to run the ODBC Administrator program. From the Windows Control Panel for Windows 2000, click Administratie Tools Data Sources (ODBC) to run the ODBC Administrator program. Chapter 9. Reports 145

160 2. Select the System DSN tab. 3. Click Add. 4. Select Sybase ASE ODBC Drier, and click Finish. The ODBC Sybase ASE Setup dialog box opens. 5. Enter a name for this ODBC data source in the Data Source Name text box. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. 6. Enter a description for the data source in the Description text box. 7. Enter the database serer name in the Serer Name text box. Note: The database serer name must be the alias that you gae to the database when you configured the database client. 8. Enter the Tioli Risk Manager database name (the default is tec) in the Database Name text box. 9. Click Test Connect to erify the data source connection. Enter the appropriate database user ID and password. 10. Click OK twice to sae Data Source Name and exit the ODBC Administrator. Microsoft SQL Serer This section describes how to set up an ODBC connection to a Microsoft SQL Serer database. It is not necessary to create a database alias for the Tioli Risk Manager database before you create an ODBC connection. Use the following procedure to create an ODBC data source for the Tioli Risk Manager database: 1. From the Windows Control Panel for Windows NT, click ODBC Data Sources to run the ODBC Administrator program. From the Windows Control Panel for Windows 2000, click Administratie Tools Data Sources (ODBC) to run the ODBC Administrator program. 2. Select the System DSN tab. 3. Click Add. 4. Select SQL Serer, and click Finish. 5. Enter a name for this ODBC data source in the Name text box. The recommended name is RMDB, that is the default data source name used by the Tioli Risk Manager Crystal Reports. 6. Enter a description for the data source in the Description text box. 7. Enter the SQL serer name in the Serer text box. The serer name is the host name of the machine on what SQL Serer is installed. If the desired serer is in the drop-down list, you can select it from that list. 8. Click Next. 9. Select With SQL Serer authentication, and check the box labeled Connect to SQL Serer. Type in the Login ID and password, and click Next. 10. Make sure the default database is the database that created the Tioli Risk Manager archie table. Accept the default alues for the remaining fields, and click Next. 11. Accept the default alues for this panel, and click Finish. 12. Click OK twice to finish. Updating Crystal Reports to Use Your ODBC Connection The Tioli Risk Manager Crystal Reports are, by default, designed to access a data source named RMDB, database named tec, and user ID tec. If your archie 146 IBM Tioli Risk Manager: Administrator s Guide

161 database uses different data source name (DSN), database or user ID, when a report is run you will need to enter your DSN, database, and user ID each time. Because it can be tedious to enter the same information (DSN, database, user ID) each time a report is run, a utility is aailable from Crystal Decisions to permanently customize your reports to use your DSN, database and user ID. Search the Crystal Decisions support Web site ( for the Update8x.exe utility program. Download the program and follow the instructions included in the readme file and the program online help. How Do Tioli Risk Manager Crystal Reports Work? The Crystal Reports component for Tioli Risk Manager runs against a table of archied eents. Sensors send the eents to the agent to be processed. As part of agent processing, the sensor eents are forwarded to the eent archie table. This table supplies the Crystal Reports with the data needed for the reports to run. Create the Tioli Risk Manager Archie Table You must create the archie table before using Crystal Reports. See the Configuration chapter of the IBM Tioli Risk Manager Installation Guide for information on creating the Tioli Risk Manager archie table. Running Tioli Risk Manager Crystal Reports Use the following steps to access Tioli Risk Manager Crystal Reports: 1. From the Start menu, select Programs IBM Tioli Risk Manager Reports. 2. From the IBM Tioli Risk Manager Reports folder select one of the following sub-folders for report types: Eent Management Firewall Management Intrusion Detection Risk Assessment Virus Management 3. From the sub-folder, select the desired report title. An initial report window is displayed. The name of the report will appear at the top of the window. 4. Customize the report printing, iewing, and exporting options using the following steps: a. Select one of the following in the first window: Print the report to a window Export the report Print the report to a printer b. If you choose to export the report, select the file format and destination for the export by selecting Export Options. Export file formats include comma-separated text, Excel, HTML and others. c. If you choose to print the report to a printer, select the printer and set other printer options by pressing Printer Options. d. For all of the report outputs listed aboe, any options changed are permanently stored and do not need to be re-entered the next time you run the report. 5. After all alues are entered, select Print to print, iew, or export the report. A database logon window is displayed. Enter the ODBC Data source name that was configured using the steps in Setting Up an ODBC Data Source Chapter 9. Reports 147

162 Connection on page 142. Enter the name of the database on the serer in the Database field. Enter the database administrator user ID and password in the User Name and Password fields and click OK. If you follow the steps presented in the Updating Crystal Reports to Use Your ODBC Connection on page 146, then only the password will need to be entered. 6. The Enter Parameter Values window is displayed. From the Parameter Fields section of the window choose one of the following parameters. Reporting Period Date Range optional Customer Host If you do not want to select any parameters you can click OK to not filter any eent attributes. If you choose Reporting Period, select a report range from a drop down list and click OK. If you choose Date Range, enter the desired dates in the start of range and end of range fields and click OK. You can also select from a calendar by clicking on the arrow next to each date field. If you choose Customer, enter the customer name that will be used to create the specified report and click OK. Customer name can be a company name, line of business, geography, department number or any customer-specific ID. Wild card characters, for example *,?, can be used to match multiple names. If you choose Host, enter the host name or IP address that will be used to create the specified report and click OK. Wild card characters, for example *,?, can be used to match multiple names. If you want to change the default alue of any parameter, you must select the parameter field in the dialog window and enter the desired alue. After you hae changed all of the parameters alues, then click OK. Do not click OK after changing each indiidual parameter. If you change the default alues for Reporting Period and Date Range, then the Reporting Period change is ignored and the Date Range change is used. 7. Your selected report will be displayed in a new window, be printed to the selected printer, or be exported to your selected location. If you are iewing the report in a new window, you can naigate through it using the page forward and back icons in the toolbar at the top of the window. To iew details about a particular eent or report item, hold your cursor oer the data you want further details about and when the cursor displays a magnifying glass, double-click to display more detailed data. 8. When you are finished reiewing the report, close the window. This action will return you to the initial report window. 9. Select Done to exit Crystal Reports completely. 148 IBM Tioli Risk Manager: Administrator s Guide

163 Crystal Reports Runtime Engine Tioli Risk Manager proides the Crystal Reports Runtime Engine, that allows users to preiew and print compiled Crystal Reports. Tioli Risk Manager does not proide the Crystal Reports Designer program that is used to create or edit Crystal Reports. Chapter 9. Reports 149

164 150 IBM Tioli Risk Manager: Administrator s Guide

165 Chapter 10. Tasks Tioli Tasks Tioli Risk Manager proides a set of predefined Tioli tasks in the Risk Manager Task Library. This chapter is a quick reference for these tasks. More information about tasks that are specific to Tioli Risk Manager adapters can be found in the IBM Tioli Risk Manager Adapters Guide. A task is an action that is routinely performed on managed nodes and end points throughout the network. Each task references a script, command, or other executable file that performs the work. A task also defines the authorization role required to run the script, and the user or group ID that the task will run as. Example tasks include those that clear printer queues, start system backups, or perform Tioli-supported operations, such as forwarding an eent to an Tioli Enterprise Console eent serer. Variable alues are passed to a task at execution time. The ariable alues can come from input parameters and execution options you specify, or from eent attributes aailable to the task. Tasks are stored in a task library. A task library usually contains tasks that are closely related, such as those that require the same authorization role, or those that help manage a single product or resource. Tioli Risk Manager proides a set of predefined tasks in the Tioli Risk Manager Task Library. The name of this task library, Risk Manager Task Library, appears in task dialogs and is used when specifying the task library from a command line. Tioli Risk Manager tasks let you react to identified risks or manage system components. Tioli Risk Manager installs the task library in the default Tioli Enterprise Console policy region, TEC Region. Tioli Risk Manager tasks are supported only on Tioli end points. See Tioli Framework documentation for more information on installing and configuring a Tioli end point. How to Create and Customize Tasks The Risk Manager Task Library is defined as a task language library file (tll file), rmt_tasks.tll and is built during Tioli Risk Manager installation by running the eent serer configuration script, rmcorr_cfg. If changes are made to this task library file, the task library can be rebuilt using the following command: rmcorr_cfg tasklib Details of scripts, commands, or other executables called by each task can be found by iewing this file. For information on tll files and creating and customizing tasks, see the Tioli Management Framework publication Task Library Language Deeloper s Guide. Copyright IBM Corp

166 Tasks for Linux and UNIX-Based Systems Tasks for Windows Systems To use a Tioli Risk Manager task to perform standard Linux and UNIX-based system tasks: 1. On the Tioli desktop, click TEC Region and then click Risk Manager Task Library. 2. Click the Tioli Risk Manager task that you want to perform from the following list: Unix_Deactiate_User_Account Use this Tioli Risk Manager task to specify a user ID to deactiate the user s account. Unix_Kill_Process Use this Tioli Risk Manager task to specify the process ID (PID) for the process that you want to stop. Unix_List_Actie_Processes Use this Tioli Risk Manager task to list an actie process specified by the name of the application process ID (PID). If no process ID is specified as an input filter, all actie processes are listed. Unix_Run_Command Use this Tioli Risk Manager task to enter the Linux or UNIX based system command that you want to run. To use a Tioli Risk Manager task to perform a standard Windows system task: 1. On the Tioli desktop, click TEC Region and then click Risk Manager Task Library. 2. Click the Tioli Risk Manager task that you want to perform from the following list: Windows_Deactiate_User_Account Use this Tioli Risk Manager task to specify a Windows system user ID in order to deactiate the user s account. For Windows systems, you can control whether or not security eents are captured by the system. The following two tasks let you enable or disable the auditing of security eents on Windows system end points. The rmt_ntaudit.exe program must be installed on the system to be audited in the RMINSTDIR\bin directory to support these tasks. This program is proided on the Tioli Risk Manager eent serer in the RMINSTDIR\etc\tec\tasks directory. This program is distributed to the systems to be audited using the Tioli Enterprise Console Adapter Configuration Facility (ACF). Installing the program with ACF is described in the IBM Tioli Enterprise Console User s Guide. Windows_Disable_Eent_Auditing Use this Tioli Risk Manager task to disable eent auditing on a Windows system. This Tioli Risk Manager task requires the rmt_ntaudit.exe executable to be installed on the Windows system where this task will be run. Windows_Enable_Eent_Auditing Use this Tioli Risk Manager task to enable eent auditing on a 152 IBM Tioli Risk Manager: Administrator s Guide

167 Tasks for the Eent Serer Windows system. This Tioli Risk Manager task requires the rmt_ntaudit.exe executable to be installed on the Windows system where this task will be run. Task Arguments include: Select a success or failure alue: Success and Failure Success Failure Neither Success nor Failure Select an eent type: Logon and Logoff File and Object Access Use of User Rights User and Group Management Security Policy Changes Restart, Shutdown, and System Process Tracking Windows_List_Actie_Serices Use this Tioli Risk Manager task to list the Windows system serices that are actie on a Windows system. Windows_Run_Command Use this Tioli Risk Manager task to run a Windows system command using cmd.exe. Windows_Start_Serice Use this Tioli Risk Manager task to specify the name of a Windows system serice that you want to start using NET START. For example, if you want to start the Apache Web serer, specify apache as the serice name. Or, if you want to start the adapter for Check Point FireWall-1, specify rma_cpfw as the serice name. Windows_Stop_Serice Use this Tioli Risk Manager task to specify the name of a Windows system serice that you want to stop using NET STOP. Tioli Risk Manager proides the following Tioli Risk Manager tasks for iewing the status of the Tioli Risk Manager eent serer. RM_Component_View_Status_for_Unix Use this Tioli Risk Manager task to display the current status of the Tioli Risk Manager components actie on the Tioli Enterprise Console serer. This task must run on the Tioli Risk Manager serer. RM_Component_View_Status_for_Windows Use this Tioli Risk Manager task to display the current status of the Tioli Risk Manager components actie on the Tioli Enterprise Console serer. This task must run on the Tioli Risk Manager serer. Output will be similar to the following example: Chapter 10. Tasks 153

168 Tasks for the Agent Tasks for Eent Management C:\Tioli\db\excalibur-win.db>rmt_corrstatus.cmd C:\WINNT\SYSTEM32\DRIVERS\ETC\Tioli\tmrset.txt C:\Tioli\db\excalibur-win.db\region.out 1 file(s) copied. Tioli enironment ariables configured. C:\Tioli\db\excalibur-win.db>cd C:\RM42\RISKMGR\bin C:\IBM\RISKMGR\bin>bash rmcorr_cfg -status rmcorr_cfg: rmcorr_cfg: Checking Status of Tioli Risk Manager Components... rmcorr_cfg: rmcorr_cfg: The Tioli Enterprise Console Serer is running. rmcorr_cfg: TMR Host: excalibur-win rmcorr_cfg: TMR install dir: C:/Tioli/bin/w32-ix86 rmcorr_cfg: Region name: excalibur-win-region rmcorr_cfg: Risk Mgr install dir: C:/IBM/RISKMGR rmcorr_cfg: Current rulebase: RM42RB rmcorr_cfg: Current rulebase path: c:/ibm/rulebase rmcorr_cfg: Eent cache size: 1000 rmcorr_cfg: Class RM_SensorEent is defined rmcorr_cfg: Eent source RISKMGR is defined rmcorr_cfg: Rules files in rulebase: Rule Set files riskmanager.rls boot.rls Tioli Risk Manager proides the following Tioli Risk Manager tasks for the agent. RM_Agent_Restart_on_Unix Use this Tioli Risk Manager task to stop and restart the agent on Linux and UNIX based systems. RM_Agent_Restart_on_Windows Use this Tioli Risk Manager task to stop and restart the agent on a Windows system. RM_Agent_View_Status_on_Unix Use this Tioli Risk Manager task to report agent status on Linux and UNIX based systems. RM_Agent_View_Status_on_Windows Use this Tioli Risk Manager task to report agent status on a Windows system. Tioli Risk Manager tasks for eent management are used to assist with eent database management. These tasks run the wrmdbclear and wrmdbclose database utilities. For more information on these utilities, see Tioli Risk Manager Database Utilities on page 56. Tioli Risk Manager proides the following Tioli Risk Manager tasks for eent management. Eent_Management_Close_Eents Use this Tioli Risk Manager task to close incident groups, associated incidents, and eents. 154 IBM Tioli Risk Manager: Administrator s Guide

169 Eent_Management_Remoe_Eents Use this Tioli Risk Manager task to remoe closed eents in the Tioli Enterprise Console eent repository and Tioli Risk Manager archie table. Note: The Eent Management tasks are also defined as jobs, configured to run on the Tioli Enterprise Console serer. Tasks for Check Point FireWall-1 Tioli Risk Manager proides the following Tioli Risk Manager tasks for this adapter: CheckPoint_FW-1_Manage_by_IP_Address Use this Tioli Risk Manager task to send Suspicious Actiity Monitor (SAM) requests to the SAM Serer in a Check Point FireWall-1 system. CheckPoint_FW-1_Manage_by_Source_and_Destination Use this Tioli Risk Manager task to send SAM requests to the SAM Serer in a Check Point FireWall-1 system. CheckPoint_Start_Firewall_Adapter_on_Linux Use this Tioli Risk Manager task to start the Check Point FireWall-1 adapter on your selected target hosts. CheckPoint_Start_Firewall_Adapter_on_Solaris Use this Tioli Risk Manager task to start the Check Point FireWall-1 adapter on your selected target hosts. CheckPoint_Start_Firewall_Adapter_on_Windows Use this Tioli Risk Manager task to start the Check Point FireWall-1 adapter on your selected target hosts. CheckPoint_Stop_Firewall_Adapter_on_Linux Use this Tioli Risk Manager task to stop the Check Point FireWall-1 adapter on your selected target hosts. CheckPoint_Stop_Firewall_Adapter_on_Solaris Use this Tioli Risk Manager task to stop the Check Point FireWall-1 adapter on your selected target hosts. CheckPoint_Stop_Firewall_Adapter_on_Windows Use this Tioli Risk Manager task to stop the Check Point FireWall-1 adapter on your selected target hosts. See the IBM Tioli Risk Manager Adapters Guide for more information. Tasks for Cisco Secure PIX Firewall Tioli Risk Manager proides the following Tioli Risk Manager tasks for this adapter: PIX_Configure_Firewall_Access Use this Tioli Risk Manager task to modify the configuration of the PIX Firewall so that connections can be blocked (both existing and new) or unblocked (allowed to be established again). PIX_Show_Firewall_Configuration Use this Tioli Risk Manager task to display the current configuration of the PIX Firewall. You can use it to erify the implementation of your site s security policy. Chapter 10. Tasks 155

170 Tasks for Cisco Secure IDS Tasks for Network IDS PIX_Configure_Firewall_Logging Use this Tioli Risk Manager task to modify the configuration of the PIX Firewall for logging. See the IBM Tioli Risk Manager Adapters Guide for more information. Tioli Risk Manager proides the following Tioli Risk Manager tasks for this adapter: Cisco_Configure_DataFeed_Component Use this Tioli Risk Manager task to configure the Cisco Secure IDS DataFeed adapter client. Cisco_Start_Secure_IDS_Adapter_on_Linux Use this Tioli Risk Manager task to start the Cisco Secure IDS adapter on your selected target hosts. Cisco_Start_Secure_IDS_Adapter_on_Solaris Use this Tioli Risk Manager task to start the Cisco Secure IDS adapter on your selected target hosts. Cisco_Start_Secure_IDS_Adapter_on_Windows Use this Tioli Risk Manager task to start the Cisco Secure IDS adapter on your selected target hosts. Cisco_Stop_Secure_IDS_Adapter_on_Linux Use this Tioli Risk Manager task to stop the Cisco Secure IDS adapter on your selected target hosts. Cisco_Stop_Secure_IDS_Adapter_on_Solaris Use this Tioli Risk Manager task to stop the Cisco Secure IDS Adapter on your selected target hosts. Cisco_Stop_Secure_IDS_Adapter_on_Windows Use this Tioli Risk Manager task to stop the Cisco Secure IDS Adapter on your selected target hosts. See the IBM Tioli Risk Manager Adapters Guide for more information. Tioli Risk Manager proides the following Tioli Risk Manager tasks for this adapter: NIDS_Start_Adapter Use this Tioli Risk Manager task to start the Network IDS adapter on your selected target hosts. NIDS_Stop_Adapter Use this Tioli Risk Manager task to stop the Network IDS adapter on your selected target hosts. 156 IBM Tioli Risk Manager: Administrator s Guide

171 Chapter 11. Web Intrusion Detection The Web Intrusion Detection System (Web IDS) analyzes the access log files generated by a Web serer. It analyzes these files to detect Web serer attacks. A Web serer keeps track of requests in an access log file. The access log files produced by Web serers contain the requests that are posted to the Web serer as well as status information that is generated by the Web serer. Web IDS reads the Web serer s access log file. Depending on the Web serer, the access log entries are formatted using a specific format. One of the most common formats is the common log format (CLF) used by the Apache Serers and the Sun ONE Web Serers. Extended common log format (ECLF) is also supported because the first part of the log entry conforms to CLF, and Web IDS ignores additional fields at the end. For a complete list of supported log formats, see Table 14 on page 158. If your Web serer is not listed in Supported Web Serers on page 158 and the access log file deiates from CLF, but is written in ASCII and contains the required data needed for proper signature matching, the Web IDS configuration file can be modified to add a description of this new format to ensure Web IDS can accurately read and process the Web serer requests. To specify the access log file format, you must configure your Web serer for the correct format. Web IDS uses a knowledge-based approach to detect malicious behaior. By defining general signatures of Web serer attacks, Web IDS can detect a wide range of attacks. Attack signatures can be simple text strings (such as phf), or they can be Perl regular expressions, for example: (?i)count\.cgi Tioli Risk Manager includes a sig.nefarious file that contains signatures for Web serer attacks. Use Web IDS if you hae a Web serer to do the following: Analyze in either real-time mode or in batch mode: real-time mode All new log entries in the access log files are read. Analysis is performed as the new log entries are added into the log file. For real-time mode, you must deploy Web IDS at each monitored Web serer. Web IDS supports rolloer log support. Configuring Web IDS Log File Access for Rolloer Support on page 166 explains how to configure Web IDS to handle multiple log files. batch mode Web IDS does not need to run at the Web serer. Web IDS is run explicitly and reads the log file once. You can tune Web IDS to take adantage of knowledge that is gathered oer time. See Tuning the Threshold and Decay Values on page 181 for information. When attacks are discoered, Web IDS generates eents and routes them to the Tioli Risk Manager for correlation. Copyright IBM Corp

172 Tioli Risk Manager correlates the eents to group them and present a more simple picture of the security status of the network. The correlation process ensures that eents that are critical for the security of the system appear with a high seerity leel and contain releant information in a concise format. Correlation also helps reduce the false alarm rate by making sure that there is enough significant information from different sources to certify the conclusion. See Chapter 2, Eent Serer, on page 39 for more information about Tioli Risk Manager eent correlation. See the IBM Tioli Risk Manager Problem Determination Guide for Web IDS messages. Figure 44 shows the flow of data between a Web serer, Web IDS, and the Tioli Enterprise Console serer. Web IDS Information Flow Web Serer Access Log Web IDS sig.nefarious log file alternate path default path Tioli Risk Manager Agent with summarization -using Eent Monitor webids.xml Tioli Risk Manager Agent with summarization -using Tioli Risk Manager EIF shared library Tioli Enterprise Console or Correlation Serer Figure 44. The Flow of Data from a Web Serer Through Web IDS to the Tioli Enterprise Console Serer Supported Web Serers Web IDS can monitor intrusion-detection eents on the following Web serers: Table 14. Web Serers Supported by Web IDS Web Serers Supported by Web IDS Log File Format Apache Web Serer CLF access log file format 158 IBM Tioli Risk Manager: Administrator s Guide

173 Table 14. Web Serers Supported by Web IDS (continued) Web Serers Supported by Web IDS BEA WebLogic Serer IBM HTTP Serer IBM Tioli Access Manager WebSEAL Serer Microsoft Internet Information Serer (IIS) Sun ONE Web Serer Log File Format CLF access log file format CLF access log file format CLF access log file format The following formats: W3C Extended Format (W3C) Internet Information Serer (IIS) Open Database Connectiity (ODBC) National Center for Supercomputing Applications (NCSA) Either the CLF access log file format or the customized access log file format For a more detailed Web serer support list, see the IBM Tioli Risk Manager Release Notes. You must configure your Web serers as needed. See Web Serer Specific Configuration on page 167). For example, before you can use the W3C Extended Format with Web IDS, you must select specific options from the Extended Property window (see Configuring the Microsoft Internet Information Serer on page 168 for instructions). Perl Support Starting Web IDS To use Web IDS, you must use the Perl that is proided with Tioli Risk Manager. See the IBM Tioli Risk Manager Installation Guide for Perl support installation information. As shown here, Web IDS can be started by running a Perl script file. You can also run Web IDS as a serice on a Windows system, see Running Web IDS as a Serice on a Windows System on page 160 for more information. SYNTAX webids [-d -e -h -t - -i input_file -c configuration_file] INPUT PARAMETERS d Prints debug information. The program writes to standard output (STDOUT), and then you can then redirect to a file. e Prints information to syslog or Tioli Risk Manager EIF depending on the alue of librmad_alue in the configuration file. If this option is not used, Web IDS parsing results and alerts are printed to STDOUT. h Displays help information about Web IDS. t Used to continuously monitor the Web serer log. Prints ersion information. i input_file Specifies the fully qualified path and name of the access log file. Chapter 11. Web Intrusion Detection 159

174 c configuration_file Specifies the fully qualified path and name of the configuration file. The default is: $RMADHOME/etc/webids.cfg For example, to start Web IDS, hae it read from the Web serer s access log (webserer.accesslog), and then send the output to the Tioli Enterprise Console eent log adapter: webids -e -i webserer.accesslog Note: On Linux and UNIX-based systems, you must set up the Tioli Risk Manager enironment by running:. /etc/tioli/rma_eif_en.sh For more information on using this command, see the IBM Tioli Risk Manager Command Reference. Running Web IDS as a Serice on a Windows System The Web IDS serice (rma_webids) is an additional program that facilitates the start of Web IDS as a Windows Serice. The Web IDS serice uses the Eent Integration Facility (EIF) as an eent send mechanism. Configuring Web IDS as a Serice on a Windows System After installing Tioli Risk Manager, the Web IDS Serice must be installed as a Windows Serice and configured to use the Web IDS configuration file. The rma_webids i webids command will install the Web IDS as a serice on a Windows system. f:\>rma_webids -i webids HRMWS0007I: Attempting to install serice: webids HRMWS0008I: Serice installed: webids HRMWS0030I: WebIDS serice commands: "e:\ibm\riskmgr\perl\bin\perl.exe" "e:\ibm\riskmgr\bin\webids.bat" -c "e:\ibm\riskmgr\etc\webids.cfg" -t -e syslog HRMWS0002I: Exiting... If you hae changed the serice name or created more than one serice entry, be sure to remoe the correct entry using the names originally specified. Note: The Web IDS serice uses the following command to run Web IDS as a serice. "e:\ibm\riskmgr\perl\bin\perl.exe" "e:\ibm\riskmgr\bin\webids.bat" -c "e:\ibm\riskmgr\etc\webids.cfg" -t -e syslog The Rolloer logfile mechanism must be used to specify the location of the Web Serers HTTP access logs. Also, it must be configured to use the Tioli Risk Manager EIF to send eents. In order to remoe the Web IDS serice, the serice name used to install the Web IDS serice must be used to uninstall the serice (webids is the name assigned to the serice and will be listed it the Windows Serice Control Panel). rma_webids r webids f:\>rma_webids -r webids HRMWS0008I: Attempting to remoe serice: webids HRMWS0011I: Serice remoed: webids HRMWS0002I: Exiting IBM Tioli Risk Manager: Administrator s Guide

175 Access Log Rolloer Support For more information on this command, see the IBM Tioli Risk Manager Command Reference. Web serers can generate large amounts of access logs in a relatiely short amount of time. For this reason, many Web serers can be configured to rolloer their logs. After a predefined file limit has been reached, or a certain amount of time has passed, the access log will be copied to an archie and new log will be started. Web IDS has the capability to keep track of this actiity and continuously monitor the actie log file. The sig.nefarious Signatures File The Tioli Risk Manager sig.nefarious file stores the signatures for Web attacks. Web IDS uses this file to monitor Web serers for attacks. After installation, the default sig.nefarious file is in the RMINSTDIR/etc directory on all supported operating systems. To create your own signatures file, copy the default signatures file proided when you installed Tioli Risk Manager or download the most recent ersion of the signatures file from the Support Web site at: support/ibmtioliriskmanager.html Parser Engine The parser engine proides instructions on how to read the log files, and it determines what type of analysis to conduct. An example of suspicious actiity might be the hexadecimal encoding of certain characters. The parser engine runs tests that ealuate methods, strings, and protocols to find suspicious uniform resource locator (URL) actiities, such as: Wrong format for the log entry, for example, a missing field in the log record Unable to understand or interpret the date and time information Empty URL request Bad URL format Inalid hexadecimal encoding that is used in the URL request Inalid hexadecimal encoding that is used in the query request Suspicious hexadecimal code that is used in the URL request Suspicious hexadecimal code that is used in the query request The classes are predefined. You cannot add or remoe classes. The class header follows this format: [class=classname; leel1=count1; leel2=count2; k=decay_param] You can only change these class parameters. leel1=count1; leel2=count2; k=decay_param Chapter 11. Web Intrusion Detection 161

176 See Tuning the Threshold and Decay Values on page 181 for instructions on how to tune the parser engine s class parameters. Pattern Engine The pattern engine looks for attack signatures in specified fields of the log file entry. Examples of the types of fields that the pattern engine searches are: URL status query method The classes, unlike in the parser engine, are not predefined and can be added or remoed. The class header follows this format: [class=classname; field=fieldname; leel1=count1; leel2=count2; k=decay_param] This engine, like the parser engine, runs tests against the log entry. If a test raises a warning, additional tests can be performed to determine whether: A suspicious request also contains suspicious entries in the query field A suspicious request succeeded A suspicious request contains any hexadecimal encoding (hex codes) For combined testing, the class header follows this format: [class=classname; field=field; requires=class; leel1=count1; leel2=count2; k=decay_param] For the most up-to-date intrusion detection, add newly discoered attacks and ulnerabilities to the list of signatures in this file. Regularly reiew and track new attacks using some of the security community databases. To configure the Web IDS pattern engine, edit the sig.nefarious file s pattern engine section. Configuration tasks include: Adding or Remoing Web Attack Signatures on page 178 Adding or Remoing Signature Classes on page 178 Tuning the Threshold and Decay Values on page 181 Combining and Refining Pattern Tests on page 179 Suspicion Engine The suspicion engine tracks hosts that you identify as being suspicious. If a host sent a request that caused Web IDS to raise a warning or an alert, you can add that host s name to the sig.nefarious file to continue to track this particular host. The class header follows this format: [class=suspicioushosts; printll=leel] To configure Web IDS, edit the sig.nefarious file s suspicion engine section. Configuration tasks include: Adding or Remoing Suspicious Hosts on page 180 Specifying the Type of Suspicious Actiity on page IBM Tioli Risk Manager: Administrator s Guide

177 Trust Engine You can define a specific set of hosts as trusted. When requests are receied from a trusted host, any alarms generated are suppressed. This suppression is useful when the scanning software is used within an enterprise by trusted network administrators. Many false alarms are eliminated. You can define a specific set of signatures as trusted. To detect ariations of an attack, make the attack signatures as generic as possible. Howeer, when you make the attack signatures too generic, false alarms can be triggered. The trust engine allows you to reduce the number of false alarms. First, determine that a signature can be trusted. Then, add this signature to reduce the number of false alarms. The class header follows this format: [class=classname; field=fieldname; cancels=class] For example: [class=trustedsig; field=url; cancels=all] /cgi-bin/fortune /cgi-bin/here To configure Web IDS, edit the sig.nefarious file s trust engine section. See Adding or Remoing Trusted Signatures on page 180 for more information. Skip Engine The Skip Engine is similar to the Trust Engine. You define a specific set of signatures (as regular expressions) to skip. Web IDS does not process any request that matches this pattern. The difference between the Skip Engine and the Trust Engine is subtle, but important. With the Trust Engine, you define signatures that, when matched, cancel out specific classes of alerts. With the Skip Engine, if the signatures match, then nothing is done with the request. By default, Web IDS does not process requests for GIF or JPEG images as suspicious, because these files will not be the source of attacks. For example: [class=pictures; field=url] \.gif$ \.jpg$ The Web IDS Configuration File gif jpg Web IDS proides a configuration file, webids.cfg, for setting and configuring its options. This configuration file contains a section for each Web serer that Tioli Risk Manager Web IDS supports. Note: Make sure that you are editing the correct section of the configuration file for the type of Web serer that you want to configure. The default configuration is for a Web serer that uses the Common Log Format. To change from the default format of CLF to another logfile format, comment out the CLF entries and find the correct section of the configuration file for the type of Web serer that you want to configure. Also, remoe the pound sign (#) to uncomment lines in that section. You can edit the Web IDS configuration file to: Specify forwarding eents to the system log (Linux and UNIX-based systems syslog or the Windows Eent Log adapter) or the Tioli Risk Manager EIF. Chapter 11. Web Intrusion Detection 163

178 Specify fully qualified path information for arious components of Web IDS, for example, the signature file or the Tioli Risk Manager EIF library file. Proide an error-exit statement. Specify the Web serer s log file syntax. Specify the format of the access log file that it will be reading; either deiate from or adhere to the CLF. Specify acceptable date formats. Define the dictionary configuration. Define the text character used to separate the key ariables and the Web serer s descriptie terms. Define the extraneous text to be remoed. Specify log file access for rolloer support. For complete information about how to change the configuration file, see Editing the Web IDS Configuration File. Editing the Web IDS Configuration File Before you begin editing the configuration file, see the introductory information in The Web IDS Configuration File on page 163. The webids.cfg configuration file is an editable text file that allows you to customize the enironment that Web IDS is running in. This configuration file contains sections for the Web serers that Tioli Risk Manager Web IDS supports. Usually you do not hae to change the ariables in the file because they are set during installation. The sections below list the ariables in the file. Note: Make sure that you are editing the correct section for the type of Web serer that you want to configure. Changing the Locale Information When using language files other than U.S. English, the National Language Serice (NLS) path must be set to establish the locale. The default NLS path is set automatically by the Web IDS installation and setup procedure. The nlspath_alue parameter is automatically set as follows: nls_path_alue = nlspath where nlspath is the fully qualified path location to the Web IDS message catalog file, webids.cat. For example, if nlspath_alue is set to: nlspath_alue = x:\webids\%l\%n.cat where x: is the drie letter, both the language ariable (%L) and the message catalog file name ariable (%N.cat) are resoled at runtime. Note: The %L and %N must be uppercase. Changing the Library Information When Web IDS is using the Tioli Risk Manager EIF Perl interface to send eents to the Tioli Risk Manager serer, it uses the alue associated with the librmadpath_alue parameter in the webids.cfg file to locate the library. This 164 IBM Tioli Risk Manager: Administrator s Guide

179 parameter is set automatically by the Web IDS installation and setup procedure. For example, if Web IDS is installed on a Windows system, the following parameters are set: librmad_alue=1 librmadpath_alue=x:\ibm\riskmgr\bin where librmad_alue=1 indicates that Web IDS is to route its eents to Tioli Risk Manager EIF, and librmadpath_alue specifies the path to the required library, as installed with Tioli Risk Manager EIF. Specifying the Location of the sig.nefarious Signatures File The Tioli Risk Manager sig.nefarious file stores the signatures for Web attacks. Web IDS uses this file to monitor Web serers for attacks. For complete information about the sig.nefarious file, see The sig.nefarious Signatures File on page 161. Note: Do not edit the original sig.nefarious file that is proided with Tioli Risk Manager. Make a copy of this file, rename it, and edit the copy. Edit the webids.cfg configuration file to specify the path and name of the signatures file that you want to load. For example: signaturefilepath_alue = Path\SignaturesFileName where Path\SignaturesFileName is one of the following: The fully qualified path and file name of the default sig.nefarious file. The fully qualified path to your own signatures file that you created by copying, renaming, and changing the sig.nefarious file proided with Tioli Risk Manager. For example: signaturefilepath_alue = g:\webids\sig.mysignatures To download the most current ersion of sig.nefarious signatures file, see the Support Web site at: support/ibmtioliriskmanager.html Specifying the Exit Information Specifies the number of errors, that is, the access log file entries that do not match the format expected, before exiting occurs: exit_alue = n Select from the following alues to specify when to exit on error conditions: 0 Neer exit. 1 Exit after the first error. n Exit after a specified number of errors (access log file entries that do not match the format expected). The number of access log file errors cannot exceed (2**53)-1. Specifying the Refresh Information Specifies the number of alters to gather before discarding all preiously stored alter information. It is recommended that the refresh alue is not less than the largest Chapter 11. Web Intrusion Detection 165

180 leel2 alue specified in the signature file. Web IDS will calculate a refresh alue of 1.5 times the largest leel2 alue if the refresh_alue is set to 1. refresh_alue=0 Refresh occurs when: Web IDS does not discard stale alert info=0 Web IDS calculates appropriate refresh rate=1 Web IDS sets the refresh rate to number specified=n To configure Web IDS to clean up the stale suspicious request information, set the refresh_alue attribute in the webids.cfg file to the proper setting. You can disable this refresh feature by setting the refresh_alue to 0. A refresh_alue set to 1 means that Web IDS will calculate the optimal refresh alue and a refresh_alue set to n is the minimum number of suspicious requests receied by Web IDS to trigger the clean up of the stale requests. The n number of suspicious requests should not be smaller than the largest leel2 alue. Specifying File Pattern Information File pattern Specifies a regular expression, not a wildcard, to match against files. Therefore, Web IDS can switch more up-to-date logfiles as they become aailable, without haing to restart. File path specifies the path where Web IDS should look for the logfile. File match specifies the whether this is disabled or enabled. this feature is disabled=0 this feature is enabled=1 The following is an example of common alues to support Apache on a Linux system: filepattern_alue=^access_log.* filepath_alue=/usr/local/apache/logs filematch_alue=1 Specifying the Resume Function Information Web IDS has the ability to resume analysis of a file from where it ended the last time it was running. This preents duplicating alerts each time you run Web IDS. Resume position specifies the whether this is disabled or enabled. Resuming is disabled=0 Resuming is enabled=1 The following is an example of the resume function: resumeposition_alue=1 On a Windows system, Web IDS must write out the resume information at certain interals. This alue specifies how many alerts must be generated before this information is saed. If this option is missing, Web IDS will default to 20. resumewindowsinteral_alue=20 Configuring Web IDS Log File Access for Rolloer Support You can schedule most Web serers to switch to a different log file after an amount of time you specify, for example, a day. Web IDS can also switch to new log files without exiting. Edit the ariables in the webids.cfg file that let you specify log files. 166 IBM Tioli Risk Manager: Administrator s Guide

181 filepattern_alue Specifies a regular expression for Web IDS to use to find alid log files. Web IDS uses the most recently modified file that matches this pattern. filepath_alue Specifies the directory where the logfiles are located. filematch_alue 1 Enables rolloer log support 0 Disables rolloer log support. Web IDS ignores the filepattern_alue and filepath_alue and specifications. For example, for an Apache Web serer on Linux and UNIX-based systems: filepattern_alue = access_log.* filepath_alue = /usr/local/apache/logs filematch_alue = 1 A file specified on the command line with the i option oerrides the alues specified in the webids.cfg file. Howeer, if this information is specified in the configuration file, you do not hae to specify the file name explicitly on the command line. Web Serer Specific Configuration You must configure the Web serer access log files before using Web IDS. Depending on the Web serer, the configuration tasks include: Configuring the following Web serers in the CLF: Configuring the Apache Web Serer Configuring the IBM HTTP Serer Configuring the IBM Tioli Access Manager WebSEAL Configuring the Sun ONE Web Serer Configuring the Microsoft Internet Information Serer in the following log file formats: W3C IIS NCSA ODBC For Web serer support information, see the IBM Tioli Risk Manager Release Notes. Configuring Web Serers That Use the Common Log Format Web serers that create the access log file by using the CLF include: Apache Web Serer IBM Tioli Access Manager WebSEAL IBM HTTP Serer The Sun ONE Web Serer allows you select CLF to generate Common Log Format output. For additional configuration instructions, see Configuring the Sun ONE Web Serer on page 168. Chapter 11. Web Intrusion Detection 167

182 Configuring the Apache Web Serer On the Apache Web Serer, the access log file is installed in the /logs directory during Apache installation. On Linux and UNIX-based systems, information is written to the access_log file. On a Windows system, information is written to the access.log file. Configuring IBM Tioli Access Manager WebSEAL Serer The Tioli Access Manager WebSEAL lets you store requests, referer, and agent log records in the same file. Howeer, Web IDS understands only the request log records. When you configure WebSEAL, store the request log records in a file separate from the referer and agent information. You can specify the file path and names of the location for the three types of log information in the wand section of the WebSEAL configuration file. Configuring the Sun ONE Web Serer To configure your Sun ONE Web Serer: 1. Run the startconsole.sh script file located in the /*/netscape/serer4 directory. This script file starts the Administrator s tool in the Netscape Web browser. 2. Select the Web serer you want to configure from the Select a Serer menu from the Serers tab at the top of the page. 3. Click Manage to load the new Web page. 4. Click Status. 5. Click Logging Preferences to display the access log configuration page. 6. Select Domain Names to set the type of record. 7. Select Use Common Logfile Format to set the type of format. The default access log file name and location are: /*/netscape/serer4/https-hostname.domain.com/logs/access Configuring the Microsoft Internet Information Serer Roll oer support is by default disabled in Web IDS. To ensure that the Microsoft Internet Information Serer (IIS) stores all Web serer requests in one file, follow the instructions below: 1. From the IIS Microsoft Management Console, right click the name of the Web serer. 2. Choose Properties and select the WebSite tab. 3. Click Properties in the logging section. 4. Change the log period to unlimited file size. After following these instructions, IIS will not swap out logs but will instead write to the same file infinite times. To enable roll oer support requires updating the Web IDS configuration file, see Configuring Web IDS Log File Access for Rolloer Support on page 166 for information and configuring IIS to set a log period alue. For the IIS W3C Extended Format, you must select a minimum set of Extended Property options for Windows. You do not need to proide Extended Property options for the other formats that IIS proides, such as National Center for Supercomputing Applications (NCSA). 168 IBM Tioli Risk Manager: Administrator s Guide

183 You must select the following set of options from the Extended Property window for the W3C format: Date Time Client IP address Method URI stem URI query Bytes sent HTTP status Protocol ersion If you select any additional options, such as Cookie or Serer Port, Web IDS remoes information about these options prior to sending the information to the Tioli Risk Manager EIF or the Windows Eent Log adapter. These options are set to ignore in the dictionary definitions supplied in the W3C section of the webids.cfg file. To see the complete list of Extended Properties: 1. Click Microsoft Personal WebSerer Internet Serice Manager. 2. From the console, select Default Web Site. 3. Expand the icon for the computer host, if necessary. 4. Click Properties Actie Log Format. 5. From Actie Log Format, click W3C Extended Logfile Format. 6. Click Properties Extended Properties tab. The options that you select appear as a comment line in the log file. For example, you might see: #Fields: date time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-bytes cs-ersion If you do not select the minimum list of properties, Web IDS flags the error. Then, Web IDS records the missing options and the line number in the log file, and generates this eent: ALERT :parser(readaccesslog)==>nnnn:malformed line in the log file. the other tests skipped. The log file that the IIS serer creates is saed using the YYMMDD format (for example ex log) in directory: c:\winnt\system\logfiles\w3sc1\exyymmdd.log If the National Computer Security Association (NCSA) format is used, the log file s name is ncyymmdd.log. Specifying Log File Format and Values Web serers that Web IDS supports can use different log formats. For each log format, different parameters alues, as appropriate for the Web serer you want to use, are defined in the webids.cfg configuration file. Not eery parameter listed applies to each serer. The configuration file is diided into different sections-each section applies to a different type of Web serer log format. Chapter 11. Web Intrusion Detection 169

184 To use the default Common Log Format (CLF), no action is needed because the CLF default parameters are not commented out. To use a different Web serer format other than CLF: Locate the Common Log Format section and comment out the lines that apply to the CLF by adding a pound sign (#) to the beginning of each parameter alue line. Locate the section that applies to the log format you want to use, and remoe the pound sign (#) that is at the beginning of each parameter alue line. The following alues, as appropriate for the Web serer you want to use, are defined in the webids.cfg configuration file: clf_alue Select whether the logfile format should adhere or deiate from CLF standards: Deiates from Common Log Format = 0 Adheres to Common Log Format = 1 dictionary_alue Some Web serers proide a description of the content and the order of the information logged in the Web serer s log file. The dictionary_alue proides a way for Web IDS to interpret the Web serer s naming conention. The Web serer proides a comment line that lists the log entry fields. In order for Web IDS to understand that comment line, Web IDS must be able to equate the Web IDS key ariables used (for example, host, method, and so forth) with the naming conention that is used by the Web serer. Web IDS key ariables include: bytes day host hour method min month protocol query rfc sec status timezone user url year If the Web serer proides additional information, that does not equate to a Web IDS key ariable, then map the Web serer key ariable to the Web IDS term ignore. For example, the Microsoft Internet Information Serer W3C log file might list the key ariable s-sitename that does not map to any of the Web IDS key ariables and, therefore, is set to ignore. See the W3C dictionary_alue for an example of using ignore. 170 IBM Tioli Risk Manager: Administrator s Guide

185 Note: If you include a log format in the logfile and specify a dictionary alue key in the configuration key, Web IDS uses that information to figure out the new logfile format. If you do not specify a dictionary alue or a comment alue, each request, that does not conform to the regular expression that Web IDS uses to break apart the log entry, causes a warning eent. For example, some Web serers write the log format as the first line of their log file when running in batch mode. Wheneer this occurs, Web IDS generates the following eent because the log entry does not conform to the CLF: ALERT :parser(readaccesslog)==><line1>:malformed line in the log file. the other tests skipped. dictionary_delim Lists the text characters used to delimit Web IDS key ariables and the Web serer s descriptie terms. date_alue Web serers use different methods of specifying the date format. The date_alue flag enables you to specify the typical date style for the Web serer s log file format. You can use the logpattern_alue to create an intermediate definition. The intermediate definitions must eentually resole to a Web IDS key ariable or ariables. For an example, see the intermediate definition clfdate_alue for the Sun ONE Web serer dictionary_alue statement. that uses day, month, and year. The intermediate definition uses that uses day, month, and year to create a new clfdate_alue with its own delimiter list, clfdate_delim. eofpadded_alue Most Web serers append the new log entry to the end of the file. Howeer, some Web serers create a large static-sized file and insert the log entries within the file rather than append the log entry to the end of the file. For example, the Microsoft Internet Information Serer creates the log file with a starting size of 65,627 bytes and each log entry is inserted into the file after the last written line rather than appended to the end of the file. When you inoke the webids program with the tail function (webids -t) the eofpadded_alue flag indicates where real-time updates to the log file should be read. Select where you want the log file entries written: Appended to the end of file = 0 Inserted after last written line = 1 extraneous_alue Contains any text that is consistently appended to the Web serer s description of the log pattern content and order. The extraneous text must be remoed by Web IDS prior to calculating the log pattern order to ensure that a proper correlation between the log pattern elements and the log pattern definition. logpattern_delim Lists the text characters used to parse the Web serer s log file entries into its subelements of host, URL, bytes, and so forth. Make sure that the delimiters specified are not likely to be characters used within the URL string. Chapter 11. Web Intrusion Detection 171

186 Editing Signatures In some instances, a delimiter used to parse the string can cause unwanted results if that delimiter appears in the other part of the log entry. For instance, if the date contains a slash symbol (/), the logpattern_alue would be incorrectly parsed if the logpattern_delim included a slash symbol because the character / is also prealent in URLs. To aoid parsing too much, create an intermediate definition with its own delimiter list. Note, that intermediate definitions must eentually resole to a Web IDS key ariable. For example, if the logpattern_alue contains clfdate, then clfdate_alue will resole to the Web IDS key ariables, day, month, and year, and the clfdate_delim that equals / will only parse the substring equated with clfdate and not parse the entire log entry. logpattern_alue Ensures that Web IDS can dynamically interpret the Web serer s log file format any time the Web serer adds the logging information comment. Set this alue to: logpattern_alue = dictionary To create your own signatures file, copy the default signatures file proided when you installed Tioli Risk Manager or download the most recent ersion of the signatures file from the Support Web site at: support/ibmtioliriskmanager.html You must edit the webids.cfg configuration file to specify the new path and name of the signatures file that you want to load. The signaturefilepath_alue= alue must be set. Creation of signatures requires a knowledge of Perl regular expressions. Follow these basic rules when creating or changing the signatures file: Copy and rename the original default sig.nefarious file for backup. Edit the webids.cfg configuration file to point to the fully qualified path of your new signatures file. For example: signaturefilepath_alue = \Fully_Qualified_Path\new_filename A class must consist of a class header and a list of signatures. Put each signature on a separate line. A signature line contains four entries: 1. The signature, expressed in Perl regular expression syntax 2. A text string that represents the name of the attack 3. The ulnerability ID if it is known 4. The information source of the ulnerability, such as CVE or Bugtraq The four entries are located in four columns. For example: (?i)showcode\.asp showcode.asp [CAN ] [CVE] Do not use a pound sign (#) as part of your signature name when defining new signatures. Text after the pound sign is ignored. Web IDS ignores empty lines. You can use the same class name only when the classes are in different engines. Class names must be unique within each engine section. 172 IBM Tioli Risk Manager: Administrator s Guide

187 Put similar attack signatures in the same class because Web IDS reports only one class (for example, put ulnerable CGI programs in the same class). The [class= directie is read downward in the file until the next [engine= or [class= directie is found. Semicolons (;) separate parameters. The sig.nefarious file has main sections; each section contains signatures (defined as classes). The sections used in this file correspond to the main engines. Configuring Web IDS for Use with the Tioli Risk Manager EIF Web IDS is configured by default to utilize a simple eent submission API proided by Tioli Risk Manager to pass sensor eents directly to the agent for formatting, summarization and transport to an eent serer. This eent submission API is the Tioli Risk Manager EIF and is incorporated as part of the agent. Web IDS proides XML files used for formatting that contain the formatting information used by the agent to extract information from Web IDS generated eents and create Tioli Risk Manager eents. During installation, the agent is configured to enable formatting of Web IDS eents by specifying the Web IDS XML file used for formatting in the receier configuration file on the host where Web IDS is installed. On a client, this configuration file is RMINSTDIR/etc/local_only_receier.conf. On an eent serer or distributed correlation serer, this configuration file is RMINSTDIR/etc/eif_receier.conf. The following is an example of local_only_receier.conf configuration for a client running Web IDS on a Windows system: TransportList=t1 t1type=localonlysocket t1channels=c1 c1sererlocation=yourserer.com c1port=5529 BufferEents=NO EentDefinitions=C:\IBM\RISKMGR\etc\webids.xml # UnmatchedLog=C:\temp\local_only_receier_webids_unmatch.log #TraceLeel=ALL #TraceFileName=C:\temp\local_only_receier_trace.log #LogLeel=ALL #LogFileName=C:\temp\local_only_receier_msg.log The following is an example of eif_receier.conf configured for a distributed correlation serer running Web IDS on Linux and UNIX-based systems: TransportList=t1 t1type=socket t1channels=c1 c1sererlocation=yourserer.com c1port=5539 ConnectionMode=connection_oriented BufferEents=NO EentDefinitions=/opt/RISKMGR/etc/webids.xml # UnmatchedLog=/opt/RISKMGR/persistence/eif_receier_webids_unmatch.log #TraceLeel=ALL #TraceFileName=/opt/RISKMGR/persistence/eif_receier_trace.log Chapter 11. Web Intrusion Detection 173

188 #LogLeel=ALL #LogFileName=/opt/RISKMGR/persistence/eif_receier_msg.log Note: The UnmatchedLog parameter specifies where to log eents that do not match any of the format specifications in the XML file. This should only be defined and used for deelopment and debug purposes. Configuring Web IDS for Use with the Eent Monitor Web IDS can be configured to send its eents to the operating system log (syslog on Linux and UNIX-based systems, the Eent Log on a Windows system). The eent monitor can be used to capture these eents from these system logs. The eent monitor is designed to extract information from a ariety of eent sources, format the information into Tioli Risk Manager eents, and then forward the eents to a local agent for summarization and transport to an eent serer. The eent monitor is installed as an integral part of the agent and utilizes the same formatting libraries as the eent submission API, Tioli Risk Manager EIF. Therefore it uses the same Web IDS XML files used for formatting. To configure Web IDS to log eents to the operating system log file, do the following: 1. Set librmad_alue=0 in the webids.cfg file. Configuring the Eent Monitor to Capture Web IDS Eents To configure the eent monitor to capture Web IDS eents from the system logs, refer to the IBM Tioli Risk Manager Adapters Guide. It contains information on how to use the Tioli Risk Manager Eent Monitor Configuration Wizard to define an instance of the eent monitor and for information on eent monitor configuration parameters. Configuring the Eent Monitor Using the Wizard When installing the eent monitor you should hae the following information before performing the installation on a Linux or UNIX-based system. Table 15. Information Needed - Web Intrusion Detection System - Logging to file through Linux and UNIX-based syslog Eent Monitor Parameter Description Suggested Value ID A user defined ID for an eent monitor. tioliwebids Eent source type The type of eent monitor. Logfile Eent source Eent source definition file Eent monitor configuration file Polling interal The input eent source for an eent monitor. The XML file used for eent formatting. the configuration file used by the agent for the eent monitor. An interal, in seconds, that an eent source has examined for new data. /ar/adm/messages $RMADHOME/etc/webids.xml $RMADHOME/etc/tioliWebIDS.conf IBM Tioli Risk Manager: Administrator s Guide

189 Table 15. Information Needed - Web Intrusion Detection System - Logging to file through Linux and UNIX-based syslog (continued) Eent Monitor Parameter Unmatched eent log file Description Specifies a log file that includes eent data that can not be formatted by the eent definitions file by the eent monitor. Suggested Value Value should only be specified for debug purposes When installing the eent monitor you should hae the following information before performing the installation on a Windows system. Table 16. Information Needed - Web Intrusion Detection System - Logging to Windows Eent Log Eent Monitor Parameter Description Suggested Value ID Eent source type Eent source Eent source definition file Eent monitor configuration file Polling interal Unmatched eent log file A user defined ID for an eent monitor. tioliwebids The type of eent monitor. Logfile The input eent source for an eent monitor. The XML file used for eent formatting. the configuration file used by the agent for the eent monitor. An interal, in seconds, that an eent source has examined for new data. Specifies a log file that includes eent data that can not be formatted by the eent definitions file by the eent monitor. /ar/adm/messages %RMADHOME%\etc\webids.nt.xml %RMADHOME%\etc\tioliWebIDS.conf 10 Value should only be specified for debug purposes Manually Configuring the Eent Monitor To manually configure the Eent Monitor to capture Web IDS eents, do the following: 1. Verify that the Web IDS XML file used for formatting has been installed in the RMINSTDIR/etc directory. webids.xml for Linux and UNIX-based systems webids.nt.xml for Windows systems 2. Create an eent monitor configuration file, monitor_receier_webids.conf, in the RMINSTDIR/etc directory and add the following: Linux and UNIX-based systems: RMMonitorList=A1 A1Type=LogFile A1PollingInteral=10 A1Source=/ar/log/messages A1EentDefinitions=/opt/RISKMGR/etc/webids.xml #A1UnmatchedEentLog=/opt/RISKMGR/persistence/ Chapter 11. Web Intrusion Detection 175

190 monitor_receier_webids_unmatch.log A1ID=webids A1CrcByteCount=50 where Source identifies the log file for syslogd. Windows system: RMMonitorList=A1 A1Type=Windows A1PollingInteral=10 A1Source=application A1EentDefinitions=C:\IBM\RISKMGR\etc\webids.nt.xml #A1UnmatchedEentLog=C:\temp\monitor_receier_webids_unmatch.log A1ID=webids A1CrcByteCount=50 where Source identifies the Windows application eent log. Note: The UnmatchedLog parameter specifies where to log eents that do not match any of the format specifications in the XML file. This should only be defined and used for deelopment and debug purposes. 3. Add the following eent monitor receier source definition to the RMINSTDIR/etc/rmagent.xml file. Linux and UNIX-based systems: <!-- Eent Monitor for WebIDS --> <source name="monitor_receier_webids" class="com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier"> <set key="rma_conf" alue="/opt/riskmgr/etc/monitor_receier_webids.conf"/> </source> Windows system: <!-- Eent Monitor for WebIDS --> <source name="monitor_receier_webids" class="com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier"> <set key="rma_conf" alue="c:\ibm\riskmgr\etc\monitor_receier_webids.conf"/> </source> 4. Add the following eent monitor connector definition to the RMINSTDIR/etc/rmagent.xml file. For a client: <connector> <from name="monitor_receier_webids"/> <to name="summarization"/> </connector> For a distributed correlation serer and eent serer: <connector> <from name="monitor_receier_webids"/> <to name="correlation"/> </connector> 5. Restart the agent, or start the added eent monitor using the wrmadmin command. wrmadmin -r monitor_receier_webids Note: When using the eent monitor on a Solaris system with Web IDS, the Solaris syslog message ID option must be disabled. Ensure that msgid=0 is set in the /kernel/dr/log.conf file. If Web IDS is configured to route eents to the 176 IBM Tioli Risk Manager: Administrator s Guide

191 Managing Web IDS Tioli Risk Manager EIF API, then the msgid setting in the /kernel/dr/log.conf file is not releant. The following tasks can be performed by an administrator to manage Web IDS: Analyzing Web Attack Eents Adding or Remoing Signature Classes Adding or Remoing Web Attack Signatures Combining and Refining Pattern Tests Adding or Remoing Suspicious Hosts Specifying the Type of Suspicious Actiity Adding or Remoing Trusted Signatures Tuning the Threshold and Decay Values Analyzing Web Attack Eents Web IDS proides information if the attacks it checks for are well known. The following is an example of captured information: _1 some.host.org - - [03/May/2001:03:42: ] "GET /cgi-bin/test-cgi HTTP/1.1" WARNING : pattern(serererror) ==> 5xx WARNING : pattern(cgi) ==> test-cgi ALERT : pattern(cgi) ==> class cgi : ll=1.00 >= 1! DECODED : REQUEST : GET /cgi-bin/test-cgi HTTP/1.1 HOST/USR: some.host.org - - STATUS : 500 BYTES : 345 METHOD : GET URL : /cgi-bin/test-cgi QUERY : VERSION : 1.1 DATE : 03/May/2001:03:42: Web IDS captures requests from a host when an alarm is raised because of a request from that host. You can then analyze this captured information and decide whether or not to define any new signatures or classes of signatures in the signature database (sig.nefarious file). Attacks not found in the database can go completely unnoticed. Knowledge-based systems need regular updates to the database. For the most up-to-date intrusion detection, add newly discoered attacks and ulnerabilities to the list of signatures in the sig.nefarious file. Reiew and track new attacks regularly by using some of the security community databases maintained just for this purpose. Two examples of such databases are: The Bugtraq Web site: The Common Vulnerabilities Enumeration (CVE) Web site: Chapter 11. Web Intrusion Detection 177

192 You must analyze this captured information manually and determine what actions you must take to correct the problem. Adding or Remoing Signature Classes The engine pattern section of the sig.nefarious file contains groups of signatures (classes) that look for patterns of attack signatures in the fields of the log entry. A single access is reported as a warning. You must specify the field name as part of the class definition when creating a new class. To add or remoe a class of Web attack signatures: 1. Go to the ENGINE PATTERN section of sig.nefarious. 2. To add a class, add the following to the file: a. [class=classname; field=fieldname; leel1=count1; leel2=count2; k=decay_param] where: class=classname field=fieldname leel1=count1 leel2=count2 A unique name for a signature specified in the pattern engine. The fields against the signatures hae to match. Valid fields for the pattern engine are: host, method, url, status, or query. See Adjusting the Leel Counters on page 182 for information. See Adjusting the Leel Counters on page 182 for information. Be sure to add comment lines that explain the new class of signatures. Each comment line must begin with a pound sign (#). 3. To remoe an existing class of signatures, delete the lines that define the class of signatures that you want to remoe. 4. Sae and close this file. For example: [class=directory; field=url; leel1=2; leel2=1; k=1000] # Some serers are sensitie to directory tricks like specifying /./ # in the path name. /\.\./ /\.\ Adding or Remoing Web Attack Signatures To add or remoe a Web attack signature: 1. Edit the sig.nefarious file. 2. Go to the ENGINE PATTERN section of this file. 3. Find the appropriate class section, such as [class=cgi; field=url; 4. Do one of the following: a. Create a new signature by adding a four-column signature line similar to: 178 IBM Tioli Risk Manager: Administrator s Guide

193 # CVE , Bugtraq ID 629, input alidation error phf phf [CVE ] CVE Add a comment line, beginning with a pound sign (#) to explain the new signature. Proide the Bugtraq ID number (if known), the CVE ID number (if known), and a short description of the signature. b. Remoe an existing Web attack signature by deleting the lines that define the signature that you want to remoe. 5. Sae and close this file. Combining and Refining Pattern Tests The pattern engine section of the sig.nefarious file contains groups of signatures (classes) that look for attack signatures in fields of the log entry. This engine also runs additional combined tests when a warning or alert is raised for any of the log file s entry fields. For example, after a warning or an alert is raised, you might want to run some additional tests to see if a request for a ulnerable CGI program succeeded. To do this, you can combine and refine the tests by using the requires=class attribute. This attribute specifies the classes that must hae raised the alarm before Web IDS performs these tests. Valid classes are classes from the parser engine and pattern engine sections of the sig.nefarious file. Some examples are: requires=pattern(cgi) requires=parser(suspicioushexcodesurl) requires=parser(suspicioushexcodesquery) requires=pattern(cgi) pattern(directory) requires=(pattern(cgi) pattern(directory))&(parser (suspicioushexcodesurl) parser(suspicioushexcodesquery)) classname represents a boolean expression of the class name. Use parentheses to group boolean expressions. The following boolean operators are alid when typing the requires=class attribute: := OR & := AND! := NOT To define or refine combination testing: 1. Edit the sig.nefarious file. 2. Go to the ENGINE PATTERN section of this file. 3. Do one of the following: a. Add a new combination of tests by following this format on one line: [class=classname; field=fieldname; requires=class; leel1=count1; leel2=count2; k=decay_param] Be sure to add comment lines to describe the new class. Each comment line must begin with a pound sign (#). b. Add or change leel1=, leel2=, or k= alues. See Tuning the Threshold and Decay Values on page 181 for more information. c. Remoe an existing class of signatures by deleting the lines that relate to the class that you want to remoe. 4. Sae and close this file. Chapter 11. Web Intrusion Detection 179

194 Adding or Remoing Suspicious Hosts You can identify suspicious hosts that you do not trust. Add the host name or the IP address of a Web serer to the sig.nefarious file after you determine that a host is sending suspicious requests. Web IDS compares host names in lowercase letters. It translates the host name in the requests and in the class name in the suspicious engine to lowercase before the comparison is performed. Use only the letters A through Z, numbers 0 through 9, and the period (.) and dash (-) characters. To add an IP address to the list of suspicious hosts, add a line similar to: # suspicious host Or, add a line for the host name in lowercase letters similar to: possible.attack.org # suspicious host This line is added under the class header, that follows this format: [class=suspicioushosts; printll=leel] where: class= printll= A unique name for a suspicious host specified in the suspicion engine. The type of requests that you want to receie. Valid types of requests include: all, alerts, or warnings. See Specifying the Type of Suspicious Actiity for more information. To remoe a suspicious host, edit the sig.nefarious file and remoe the line containing the host name or the IP address for that host. Specifying the Type of Suspicious Actiity You can specify the type of suspicious actiity (alerts, warnings, or both) that you want to record and analyze. The class header follows this format: [class=suspicioushosts; printll=leel] To change the type of requests that you receie, specify a different printll= reporting leel. The alid reporting leels are: all All the requests after the first warning are reported. warnings Warnings and alerts are reported. alerts Only the alerts are reported. Adding or Remoing Trusted Signatures The first time that you start Web IDS after its initial installation, you might see a large number of eents forwarded to the eent console. Some of these intrusion-detection eents might be false alarms. After you determined that a signature can be trusted, you can add this signature to the trust engine to reduce the number of false alarms. 180 IBM Tioli Risk Manager: Administrator s Guide

195 The class header follows this format: [class=classname; field=fieldname; cancels=class] where: class=classname A unique name for a signature class specified in the trust engine. field=fieldname The fields against the signatures hae to match. Valid fields for the trust engine are: host, method, url, or query. cancels=class The warnings or alerts are not reported (cancelled) if a matching signature is found for the class specified. Valid keywords for classes to cancel include: all Cancels all matching alerts and warnings. engine_name(class_name) Cancels matching alerts and warnings for the engine name and class name specified. engine_name(class_name),engine_name(class_name) Cancels matching alerts and warnings for a list of engine names and class names, each one separated by a comma (,). Some examples include: [class=trustedhosts; field=host; cancels=all] friendly\.computer\.org [class=linuxdistr; field=url; cancels=pattern(cgi),pattern(file)] ^\~linus/mirror/linux Tuning the Threshold and Decay Values Tioli Risk Manager Web IDS differentiates between two types of alarms: warnings and alerts. A warning is considered less seere than an alert and is usually not reported to the Tioli Enterprise Console eent console. After a certain number of the same type of warnings, the warning turns into an alert. For example, certain types of Web serer attacks become alerts only after a certain number of the same suspicious request is obsered, such as repeated unsuccessful authentication requests that are submitted from the same host. You can configure Web IDS to specify how fast a warning becomes an alert by adjusting the following class parameters: leel1 leel2 k If you are receiing too many alerts or too few alerts, then consider adjusting the class parameters. Edit the Web IDS parser and pattern engine sections in the sig.nefarious file to adjust the class parameters. To tune information for Web attack signatures: 1. Back up the sig.nefarious file. 2. Edit the sig.nefarious file. Chapter 11. Web Intrusion Detection 181

196 3. Go to the ENGINE PATTERN or ENGINE PARSER section of the file. 4. Tune the leel and decay information by adjusting the leel1=, leel2=, or k= alues. See Adjusting the Leel Counters for more information. 5. Add comment lines if you want to explain the new alues. Each comment line must begin with a pound sign (#). 6. Sae and close this file. Adjusting the Leel Counters Tioli Risk Manager Web IDS counts the number of suspicious requests of the same type until the threshold leel that you specify is exceeded. After a threshold is exceeded, Web IDS issues an alert. The threshold leels that you can specify and adjust include: leel1=count1 The number of suspicious requests of the same eent class type for the same domain. The leel1 alue must be equal to or higher than the alue for leel2. leel2=count2 The number of suspicious requests of the same eent class type for the same host. The threshold used is based on whether it is the same domain or the same host. Using this example host name: The domain uses the leel1 threshold: tioli.com All other parts of the host name would use leel2 thresholds: www and austin To adjust the leel1 or leel2 parameter alues, edit the Web IDS ASCII text file sig.nefarious file to define the threshold. Use any text editor to change the file. If this is the first time that you are editing this file, make a backup copy of the original file before you begin. 182 IBM Tioli Risk Manager: Administrator s Guide

197 Chapter 12. Network Intrusion Detection The Network Intrusion Detection System (Network IDS) is a network-based intrusion-detection sensor. See the IBM Tioli Risk Manager Problem Determination Guide for Network IDS messages. Network IDS listens to network traffic, waiting for signs of malicious actiity, such as scans or actual intrusion attacks. You typically run Network IDS on a single dedicated machine just inside or outside a firewall to watch for intrusion attempts that are coming in from the Internet. Network IDS runs on Linux and UNIX-based systems. You can run Network IDS in promiscuous mode to watch traffic to or from any node on the network. Network IDS can also run in a nonpromiscuous mode by running on a serer where it watches only the traffic that is destined for that serer. Using the nonpromiscuous mode is useful in switched or ery fast networks where it is not possible or practical to try to watch the traffic from a single node. The Network IDS sensor supports two options for sending alerts to an eent serer: Send alerts directly by utilizing the Tioli Risk Manager eent submission API incorporated as part of the agent. Log alerts to syslog and utilize the eent monitor to capture and forward eents. See Logging Network IDS Alerts and Information on page 189 for more information on options for logging Network IDS alerts. Figure 45 on page 184 depicts the two routing options for sending Network IDS alerts to a serer: Copyright IBM Corp

198 Network IDS Information Flow Network Packets Network IDS ids.rules alternate path default path log file Tioli Risk Manager Agent with Summarization - using Eent Monitor nids.xml format file Tioli Risk Manager Agent with Summarization - using RMEIF shared library Tioli Enterprise Console or Correlation Serer Figure 45. Sending Network IDS Alerts to a Serer Supported Adapters The following table lists supported network interfaces or deices. Table 17. Supported Deices Supported Network Interfaces or Deice Ethernet Fiber Distributed Data Interface (FDDI) Description Ethernet is a network standard IEEE It is the most widely used for of local area network (LAN) communication and typically runs at 10 megabytes per second, though newer systems use 100 Mbps, or een gigabit of transfer. FDDI is a set of American National Standards Institute (ANSI) and Open Systems Interconnection (ISO) standards for data transmission on fiber optic lines in a local area network that can extend in range up to 200 km (124 miles). 184 IBM Tioli Risk Manager: Administrator s Guide

199 Table 17. Supported Deices (continued) Supported Network Interfaces or Deice Point-to-Point Protocol (PPP) SLIP Token Ring Description PPP is a protocol for communication between two computers using a serial interface, typically a personal computer connected by phone line to a serer. SLIP is a TCP/IP protocol used for communication between two machines that are preiously configured for communication with each other. A token ring network is a LAN where all computers are connected in a ring or star topology and a binary digitor token-passing scheme is used in order to preent the collision of data between two computers that want to send messages at the same time. Note: For Network IDS some limitations apply on Linux for zseries concerning the OSA adapter configuration. For example, promiscuous mode is not supported on Linux for zseries. The following table lists the supported network interfaces or deices in nonpromiscuous mode only on Linux for zseries. Table 18. Support Network Interfaces or Deices in Nonpromiscuous Mode for Linux for zseries Supported Network Interfaces or Deice OSA2 ENTR OSA2 Fast Ethernet OSA EXPRESS Fast Ethernet Description Ethernet -Token Ring Fast Ethernet 100 bits per second Configured in non-qdio mode. CHPID TYPE - OSE - OSA Express Channel The following table lists non-supported network interfaces or deices for Network IDS on Linux for zseries. Table 19. Non-Supported Network Interfaces or Deices for NIDS on Linux for zseries Network Interfaces or Deice Description OSA EXPRESS Fast Ethernet Configured in QDIO mode. CHPID TYPE - OSD - OSA Direct Express Channel OSA EXPRESS Gigabit Ethernet OSA ATM Channel to Channel (CTC) Hiper Socket IUCV VLAN Gigabit Ethernet 1000 bits per second Any type of ATM. ESCON fiber running between 2 Linux images. A memory to memory connection between two or more images on the same hardware. A connection between two images on the same irtual machine image. A connection between many images on the same irtual machine image. Chapter 12. Network Intrusion Detection 185

200 Network IDS Eent Correlation Network IDS Alerts Network IDS monitors the network for actiity and matches that actiity to known patterns of possible intrusion (signatures). When Network IDS finds a match, it writes a message to the system log. The Tioli Logfile adapter sends the eents to the eent serer. Tioli Risk Manager correlates Network IDS eents with other eents that are coming from other types of sensors to proide the Tioli Risk Manager administrator with a total iew of intrusion-detection eents. In Network IDS, reportable alerts hae the following information: A unique identifying number A seerity leel A text description Network IDS uses identification (ID) numbers to identify and distinguish alerts. The ID numbers do not correspond to the Common Vulnerability Entry (CVE) numbers because Network IDS tests for security problems that are more than ulnerabilities (such as, configuration errors, backdoors, scanning, and so forth) and because Network IDS tries to recognize attacks generically. For example, Network IDS has three signatures that look for typical buffer oerflow data. These oerflow signatures catch hundreds of CVE specific buffer oerflow attacks. Network IDS keeps the signatures generic, een ones that hae not been seen before and are not registered in CVE, so that they can catch any buffer oerflow. Because the signatures are so general, Network IDS cannot distinguish exactly what buffer oerflow ulnerability is being attacked. In most cases, it is more important to know reliably that an attack is taking place rather than to know exactly what ulnerability is inoled. For those Network IDS signatures that correspond exactly to CVE entries, Network IDS proides the CVE reference ID at the beginning of the reporting string. You can obtain more information for each specific CVE ID at: Network IDS specifies the seerity leels as an integer number. Zero (0) represents the less seere risks and the higher numbers represent the more seere situations. Each text description for an alert begins with a keyword that categorizes the alert. The categories of alerts are: Keyword CVE ALERT DOS SCAN CONFIG AUTH Description A specific ulnerability listed in the CVE database. A generic attack not listed in CVE. A known denial of serice attack. A traffic pattern that indicates pre-attack reconnaissance. An attempt to exploit security-related configuration errors. An authentication failure that might indicate an attack. 186 IBM Tioli Risk Manager: Administrator s Guide

201 Keyword BACKDOOR STEALTH Description Traffic to or from a back-door program. Traffic typical of known stealth attacks. Configuring Network IDS Network IDS has two categories of detections: Built-in alerts The built-in alerts coer situations that Network IDS cannot detect by looking for a simple pattern in the session or packet data. These alerts require either looking at stateful interaction within a protocol or analysis across multiple sessions. Network IDS hardcodes these tests. You cannot modify them. Network IDS specifies the output strings and seerity leel for these built-in alerts in the ids.msg file. Signature-based alerts In signature-based alerts, Network IDS looks for specified patterns in the packet or session data stream in a gien protocol leel. Network IDS specifies the patterns, the alert priority, and the output message for these signatures in the ids.rules file. For more information on creating signatures for the Network IDS, see the Network Intrusion Detection System Language Reference Guide aailable from the Tioli Risk Manager Support Files and Adapters Web site at: support/ibmtioliriskmanager.html Tioli Risk Manager proides periodic updates of the ids.rules file on the Support Web site so you can replace this file with the latest updated signature file. See Updating the Signatures File on page 188 for instructions. You can configure Network IDS locally or with Access Control Facility (ACF). 1. Edit the ids.cfg configuration file, if necessary. Use the ACF to redistribute it if you configure at a central location. 2. Replace and update the signatures file (ids.rules), if necessary, if an updated signatures file is aailable. Refer to Updating the Signatures File on page 188 for instructions. 3. After completing the configuration, start Network IDS by using the Tioli Risk Manager-proided Tioli Enterprise Console task. See Starting the Network IDS Adapter. Network IDS Tioli Risk Manager Tasks Tioli Risk Manager proides its own task library, Tioli Risk Manager Task Library. Tioli Risk Manager installs the task library in the default Tioli Enterprise Console policy region. Tioli Risk Manager includes tasks to start and stop Network IDS. Starting the Network IDS Adapter To start Network IDS: Chapter 12. Network Intrusion Detection 187

202 1. You must run Network IDS as root if you want to read packets from a network interface. If you read from a dump file, you do not need root priilege. 2. On the Tioli desktop, click TEC-Region and then click Risk Manager Task Library. 3. Click the NIDS_Start_Adapter Tioli Risk Manager task. Stopping the Network IDS Adapter To stop Network IDS: Managing Network IDS 1. On the Tioli desktop, click TEC-Region and then click Risk Manager Task Library. 2. Click the NIDS_Stop_Adapter Tioli Risk Manager task. The following tasks can be performed by an administrator to manage the Network IDS: Starting Network IDS Automatically with the startnids Command Updating the Signatures File Testing for Promiscuous Operation Omitting IP Addresses Obtaining the Host Name Starting Network IDS Automatically with the startnids Command Network IDS proides the startnids startup script that writes a line to the Inittab file so that Network IDS will start automatically een if it stops before the system is rebooted. This automatic startup capability proides some leel of security to the user in knowing that Network IDS is always running een after a reboot. See the IBM Tioli Risk Manager Command Reference for details using the startnids command. Updating the Signatures File Tioli Risk Manager proides periodic updates to the Network IDS signatures file at the Support Web site. To replace your signatures file in a Tioli enironment: 1. Download the ids.rules and other required files from the Support Web site: support/ibmtioliriskmanager.html 2. Use the ACF to distribute and replace the old ersion of the signatures file with the new one. To manually replace your signatures file: 1. Stop the Network IDS daemon by running the following script file: stopnids 2. Download the ids.rules and other required files from the Support Web site: 188 IBM Tioli Risk Manager: Administrator s Guide support/ibmtioliriskmanager.html

203 3. Restart the Network IDS daemon by running the following script file: startnids Testing for Promiscuous Operation Not all network interfaces support promiscuous mode operation. In particular, some ISA and some older PCMCIA Token Ring cards do not support promiscuous sniffing. You can test your hardware for promiscuous operation by running the tcpdump command and looking for packets that are not to or from the local host, and are not multicast or broadcast. Note: The open system adapter does not support promiscuous operation on Linux for zseries. Omitting IP Addresses In some cases, it can be helpful for Network IDS to listen on a passie-only interface, meaning an interface that is not isible on its segment and that does not transmit any packets. One example of a passie-only interface is one that interface is connected passiely to an external (outside the firewall) segment, and a second interface is actie on an internal segment to report Network IDS alerts to Tioli Risk Manager inside the firewall. For Network IDS to run on a passie interface, you must configure the interface for up mode but with no assigned Internet Protocol (IP) address. Use the ifconfig up command to omit any IP address specification. While the interface is in up mode, it does not transmit any packets because it has no IP address information for the network. Network IDS does not listen on a down interface. Obtaining the Host Name Network IDS tries to include the sensor host s IP address and fully qualified host name, for example, host.company.com, in its alerts that are sent to Tioli Risk Manager. The fully qualified host name is important to Tioli Risk Manager to ensure uniqueness of the alert source name. For Network IDS to obtain the fully qualified host name, the local resoler must be configured to return the fully qualified name to a gethostbyaddr( ) query. Normally you configure for the local host in the /etc/hosts file, although it might alternately come from Domain Name System (DNS) or Network Information Serices (NIS) queries. See the resoler man pages for details. Alternately, this function can be left to the agent that is also capable of reerse DNS resolution for the purposes of resoling IP addresses to fully qualified host names. Logging Network IDS Alerts and Information Network IDS can send alert and logging information to seeral different locations: Syslog A local file The console (using standard out for the process) Tioli Risk Manager EIF You can specify your choice of these destinations on the command line, or in the ids.cfg configuration file. The ids.cfg file sets the default logging location or locations. You can oerride the defaults in the ids.cfg file by using the nids Chapter 12. Network Intrusion Detection 189

204 command with the -y or -e option to force output to syslog or EIF and the -q option to turn off the console output. When used with Tioli Risk Manager, you normally specify these switches so that the output goes to syslog or EIF to preent Network IDS from creating any growing files in the /usr directory. The default configuration in ids.cfg file will log information to the Tioli Risk Manager EIF. See the IBM Tioli Risk Manager Command Reference for details using the nids command. Configuring Network IDS for Use with the Tioli Risk Manager EIF Network IDS is configured by default to utilize a simple eent submission API proided by Tioli Risk Manager to pass sensor eents directly to the agent for formatting, summarization and transport to an eent serer. This eent submission API is the Tioli Risk Manager EIF and is incorporated as part of the agent. Network IDS proides an XML file used for formatting that contains the formatting information used by the agent to extract information from Network IDS generated eents and create Tioli Risk Manager eents. During installation, the agent is configured to enable formatting of Network IDS eents by specifying the Network IDS XML file used for formatting in the receier configuration file on the host where Network IDS is installed. On a client, this configuration file is RMINSTDIR/etc/local_only_receier.conf. On an eent serer or distributed correlation serer, this configuration file is RMINSTDIR/etc/eif_receier.conf. The following is an example of local_only_receier.conf configured for a client running Network IDS on Linux and UNIX-based systems: TransportList=t1 t1type=localonlysocket t1channels=c1 c1sererlocation=yourserer.com c1port=5529 BufferEents=NO EentDefinitions=/opt/RISKMGR/etc/nids.xml # UnmatchedLog=/opt/RISKMGR/persistence/eif_receier_nids_unmatch.log #TraceLeel=ALL #TraceFileName=/opt/RISKMGR/persistence/eif_receier_trace.log #LogLeel=ALL #LogFileName=/opt/RISKMGR/persistence/eif_receier_msg.log The following is an example of eif_receier.conf configured as a Linux or UNIX-based distributed correlation serer running Network IDS: TransportList=t1 t1type=socket t1channels=c1 c1sererlocation=yourserer.com c1port=5539 ConnectionMode=connection_oriented BufferEents=NO EentDefinitions=/opt/RISKMGR/etc/nids.xml # UnmatchedLog=/opt/RISKMGR/persistence/eif_receier_nids_unmatch.log #TraceLeel=ALL #TraceFileName=/opt/RISKMGR/persistence/eif_receier_trace.log 190 IBM Tioli Risk Manager: Administrator s Guide

205 #LogLeel=ALL #LogFileName=/opt/RISKMGR/persistence/eif_receier_msg.log Note: The UnmatchedLog parameter specifies where to log eents that do not match any of the format specifications in the XML file. This should only be defined and used for deelopment and debug purposes. Configuring Network IDS for Use with the Eent Monitor Network IDS can be configured to send its eents to the operating system log (syslog on Linux and UNIX-based systems). The eent monitor can be used to capture these eents from these system logs. The eent monitor is designed to extract information from a ariety of eent sources, format the information into Tioli Risk Manager eents, and then forward the eents to a local for summarization and transport to an eent serer. The eent monitor is installed as an integral part of the agent and utilizes the same formatting libraries as the eent submission API, Tioli Risk Manager EIF. Therefore it uses the same Network IDS XML file used for formatting. To configure Network IDS to log eents to the operating system log file, do the following: 1. Use the nids command with the -y option or edit the ids.cfg file and make appropriate modifications. Configuring the Eent Monitor to Capture Network IDS Eents To configure the eent monitor to capture Network IDS eents from the system logs, refer to the IBM Tioli Risk Manager Adapters Guide for information on how to use the Tioli Risk Manager Eent Monitor Configuration Wizard to define an instance of the eent monitor and for information on eent monitor configuration parameters. Configuring the Eent Monitor Using the Wizard When installing the eent monitor you should hae the following information before performing the installation on a Linux or UNIX-based system. Table 20. Information Needed - Network Intrusion Detection System - Logging to file through Linux and UNIX-based syslog Eent Monitor Parameter Description Suggested Value ID A user defined ID for an eent monitor. tiolinids Eent source type The type of eent monitor. Logfile Eent source Eent source definition file Eent monitor configuration file Polling interal The input eent source for an eent monitor. The XML file used for eent formatting. the configuration file used by the agent for the eent monitor. An interal, in seconds, that an eent source has examined for new data. /ar/adm/messages $RMADHOME/etc/nids.xml $RMADHOME/etc/tioliNIDS.conf 10 Chapter 12. Network Intrusion Detection 191

206 Table 20. Information Needed - Network Intrusion Detection System - Logging to file through Linux and UNIX-based syslog (continued) Eent Monitor Parameter Description Suggested Value Unmatched eent log file Specifies a log file that includes eent data that can not be formatted by the eent definitions file by the eent monitor. Value should only be specified for debug purposes Manually Configuring the Eent Monitor To manually configure the eent monitor to capture Network IDS eents, do the following: 1. Verify that the Network IDS XML file used for formatting has been installed in the RMINSTDIR/etc directory. nids.xml for Linux and UNIX-based systems 2. Create an eent monitor configuration file, monitor_receier_nids.conf, in the RMINSTDIR/etc directory and add the following: Linux and UNIX-based systems: RMMonitorList=A1 A1Type=LOGFILE A1PollingInteral=10 A1Source=/ar/log/messages A1EentDefinitions=/opt/RISKMGR/etc/nids.xml #A1UnmatchedEentLog=/opt/RISKMGR/persistence/monitor_receier_nids_unmatch.log A1ID=nids A1CrcByteCount=50 where Source identifies the log file for syslogd. Note: The UnmatchedLog parameter specifies where to log eents that do not match any of the format specifications in the XML file. This should only be defined and used for deelopment and debug purposes. 3. Add the following eent monitor receier source definition to the RMINSTDIR/etc/rmagent.xml file. Linux and UNIX-based systems: <!-- Eent Monitor for NIDS --> <source name="monitor_receier_webids" class="com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier"> <set key="rma_conf" alue="/opt/riskmgr/etc/monitor_receier_nids.conf"/> </source> Windows system: <!-- Eent Monitor for NIDS --> <source name="monitor_receier_webids" class="com.tioli.riskmanager.agent.transports.receiers.rmamonitorreceier"> <set key="rma_conf" alue="c:\ibm\riskmgr\etc\monitor_receier_nids.conf"/> </source> 4. Add the following eent monitor receier source definition to the RMINSTDIR/etc/rmagent.xml file. For a client: <connector> <from name="monitor_receier_nids"/> <to name="summarization"/> </connector> 192 IBM Tioli Risk Manager: Administrator s Guide

207 The nids Command For a distributed correlation serer or eent serer: <connector> <from name="monitor_receier_nids"/> <to name="correlation"/> </connector> 5. Restart the agent, or start the added eent monitor using the wrmadmin command. wrmadmin -r monitor_receier_nids Note: When using the eent monitor on a Solaris system with Network IDS, the Solaris syslog message ID option must be disabled. Ensure that msgid=0 is set in the /kernel/dr/log.conf file. If Network IDS is configured to route eents to the Tioli Risk Manager EIF API, then the msgid setting in the /kernel/dr/log.conf file is not releant. To manually start Network IDS or to use other options, use the nids command. See the IBM Tioli Risk Manager Command Reference for details on using this command. Chapter 12. Network Intrusion Detection 193

208 194 IBM Tioli Risk Manager: Administrator s Guide

209 Appendix A. Eent Integration Facility Sender and Receier Keywords Keywords This section proides reference information about keywords used to configure agent configuration files to send and receie eents. These configuration files are referenced in the rmagent.xml file, the master agent configuration file. The configuration files specified as the RMA_conf parameter alue for the Eent Integration Facility (EIF) senders and receiers can use the keywords described below. Specifically, they apply to sections in rmagent.xml that are associated with the following: source with class name com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier destination with class name com.tioli.riskmanager.agent.transports.senders.rmaeifsender Tioli Risk Manager uses the Tioli Enterprise Console serer s EIF to send and receie eents. The information in this section is a reflection of the eent serer s EIF facility, tailored for use in the Tioli Risk Manager enironment. For example, when the documentation refers to the adapter, the agent is the adapter, because it is the application sending and receiing eents using the eent serer s Eent Integration Facility. For information about other EIF configuration parameters that are not described here, see the IBM Tioli Eent Integration Facility User s Guide. Keywords use the following format: keyword=alue. Do not use blank spaces in keyword statements unless enclosed in single quotation marks. Do not use class names that are not defined in a BAROC file with configuration options. Note: Tioli Risk Manager does not issue error messages for misspelled keywords or keywords set to a alue that is not alid. A configuration file can contain the following keywords: BatchCount=number Specifies the number of eents to send in one batch to a destination. BufEtMaxSize=kilobytes Specifies the maximum size, in kilobytes, of the cache file for the eent sender or receier. The default alue is 64. The cache file stores eents on disk when the BufferEents keyword is set to YES. The minimum size for the file is 8 KB. File sizes specified below this leel are ignored, and 8 KB is used. There is no upper limit for the file size. Note: If the cache file already exists, you must delete the existing cache file for any change to the BufEtMaxSize maximum size for keyword changes to take effect. The BufEtMaxSize keyword is optional. Copyright IBM Corp

210 BufEtPath=pathname Specifies the full path name of the cache file for the eent sender or receier. Tioli Risk Manager will automatically create an eent cache file for each eent sender and receier in the Tioli Risk Manager RMINSTDIR\persistence directory if BufferEents=YES. By default, BufferEents=NO. Unless you want to change the location of an eent cache file (and BufferEents=YES), there is no need to specify the BufEtPath parameter. Note: If BufEtPath is used to oerride the default location for an eent sender or receier s cache, it is essential that each eent sender and receier hae a different cache file. Results are unpredictable if a cache file is shared between multiple eent handlers (senders and receiers). BufferEents=YES MEMORY_ONLY NO Specifies how eent buffering is enabled. If BufferEents is set to YES, eents are stored in the file specified by the BufEtPath keyword. If BufEtPath is not specified, Tioli Risk Manager will create the appropriate cache file in the Tioli Risk Manager RMINSTDIR/persistence directory. If BufferEents is set to MEMORY_ONLY, eents are buffered in memory. If the keyword is set to NO, eents are not stored or buffered. The alue is not case-sensitie. The default alue is NO. This keyword is optional. BufferFlushRate=eents_per_minute Specifies the number of eents that are sent per minute. After the lost connection is recoered, and there are eents in the buffer, the eents are sent at this rate per minute. The default alue is zero (0); all eents are sent in one burst. The BufferFlushRate keyword is optional. ConnectionMode=connection_oriented connection_less Specifies the connection mode to use to connect to an eent serer or the IBM Tioli Enterprise Console gateway. Valid alues are connection_oriented (or its abbreiations CO and co) and connection_less. The default alue for Tioli Risk Manager is connection_oriented or CO. When connection_less is specified, a new connection is established (and discarded) for each eent or group of eents that is sent. When connection_oriented or one of its abbreiations is specified, a connection is established at initialization and is maintained for all eents sent. A new connection is established only if the initial connection is lost. The connection is discarded when the Tioli Risk Manager agent is stopped. The ConnectionMode keyword is optional. Filter Works with the FilterMode keyword to determine how eents are filtered. An eent matches a Filter statement when each attribute=alue pair in the Filter statement is identical to the corresponding attribute=alue pair in the eent. A Filter statement must contain the eent class, and optionally can include any other attribute=alue pair that is defined for the eent class. The format of a filtering statement is the following: Filter:Class=class_name;[attribute=alue;...;attribute=alue] 196 IBM Tioli Risk Manager: Administrator s Guide

211 Each statement must be on a single line. The attributre=alue pair is case sensitie. This keyword is optional. LogFileName=pathname LogLeel=leel Specifies the full path name of the log file for the Jaa API. The default location for the file is $TIVOLIHOME/tec/eif.log. If UseStateCorrelation=YES, the LogFileName keyword also defines the path to store the log file for state correlation. Tioli Eent Integration Facility adds the prefix _sc to the specified file name. The prefix differentiates the log file for the Jaa API from the log file for state correlation. The default alue for the path is $TIVOLIHOME/tec/eif_sc.log. If you specify a non-alid path name, the API returns the following error: LOG0014E Unable to open the handler output file <filename>. jaa.io.filenotfoundexception:<filename> (The system cannot find the path specified) This keyword is optional. Specifies whether the Jaa API generates log messages or not. By default, no messages are generated. Specify ALL to generate messages. If you specify any other alue or no alue, the API does not generate messages. This keyword is optional. MaxPacketSize=bytes Specifies the number of bytes to be sent at the rate specified by BufferFlushRate. The default alue is zero (0), where one eent is sent at a time. RmadLogging=YES NO Specify RmadLogging=YES in thermad.conf file to enable tracing for the Tioli Risk Manager EIF API. Default is set to NO. RMAgentSenderRetryInteral=seconds Specifies the number of seconds between retries when the destination serer is unaailable. This is used to control the retry rate for Tioli Risk Manager agent sender components that send eents to an eent serer using the Eent Integration Facility, as well as senders that insert eents into the Tioli Risk Manager archie table (in a relational database). For an EIF sender, the default alue is 30 seconds. For a database sender, the default alue is 120 seconds. This is useful when BufferEents=no, ConnectionMode=co, and EIF is not caching eents when the serer is unaailable. Note: By default, the agent sets RetryInteral to the same alue as RMAgentSenderRetryInteral. RMAgentSenderRetryAttempts=integer Specifies the number of retries for sending an eent when the destination serer is unaailable. The number of seconds between retries is specified by the RMAgentSenderRetryInteral parameter. If the Tioli Risk Manager agent cannot successfully forward the eent after the specified number of attempts, the eent is left on the agent queue and the agent processes the next eent on the queue. The default alue is zero (or 0), which specifies to retry indefinitely. Appendix A. Eent Integration Facility Sender and Receier Keywords 197

212 SererLocation=host Specifies the name of the host on which the eent serer is installed. The alue of this field must be one of the formats shown in Table 21, depending on the eent protocol, and whether the eent serer is part of an interconnected Tioli management region. Table 21. Formats for SererLocation keyword Protocol TME TME in an interconnected Tioli management region non-tme (SOCKET or host_name or IP_address. Use the dotted format for IP_address. For TME adapters on managed nodes and adapters, SererLocation can contain up to eight alues, separated by commas. The first location is the primary eent serer, while others are secondary serers to be used in the order specified when the primary serer is down. For end point adapters, secondary eent serers, if any, are defined in the IBM Tioli Enterprise Console gateway configuration file. Only specify a primary eent serer in the configuration file for an end point adapter. The SererLocation keyword is optional and not used when the TransportList keyword is specified. Note: SererLocation defines the path and name of the file for logging eents, instead of the eent serer, when used with TestMode=YES. SererPort=number Specifies the port number on which the eent serer or gateway listens for eents. If the eent serer is a Tioli Enterprise Console serer running on a UNIX system with an actie portmapper serice, then this keyword alue can be set to zero (0). Howeer, if the Tioli Risk Manager 4.1 serer is running on the Tioli Enterprise Console serer and the connection is non-tme socket-based then it is recommended that you specify the default Tioli Risk Manager Agent port alue of 5539, which is more efficient than routing the eents through the eent serer and then to the Agent. If the eent serer is a Tioli Enterprise Console serer running on a Windows system, there is no portmapper serice that allows the adapter to query the reception port at runtime. The Tioli Enterprise Console serer listens on a fixed port (tec_rec_agent_port in.tec_conf file), which defaults to 5529 for non-tme connections. Howeer, if the Tioli Risk Manager 4.1 serer is running on the Tioli Enterprise Console serer and the connection is non-tme (socket-based) then it is recommended that you specify the default Agent port alue of 5539, which is more efficient than routing the eents through the eent serer and then to the Agent. If a non-tme connection is being used, and the remote eent serer is any of the following, it is recommended that default port 5529 be used (unless a non-default port is being used by the eent serer): Tioli Risk Manager Distributed Correlation Engine Tioli Risk Manager Gateway Tioli Aailability Intermediate Manager 198 IBM Tioli Risk Manager: Administrator s Guide

213 If an SSL-based connection is being used, and the remote eent serer is any of the following, it is recommended that default port 5549 be used (unless a non-default port is being used by the eent serer): Tioli Risk Manager Tioli Enterprise Console Serer Tioli Risk Manager Distributed Correlation Engine Tioli Risk Manager Gateway The SererPort keyword is not used when the TransportList keyword is specified. TestMode=YES NO Specifies whether test mode is turned on or off. When TestMode=YES, the SererLocation keyword specifies the file to which eents are logged, instead of being sent to the eent serer. Valid alues are YES and NO, without regard to case. The default is NO. The TestMode keyword is optional. TraceFileName=pathname Specifies the full path name of the trace file for the Jaa API. The default location of the file is $TIVOLIHOME/tec/eif.trc. If the UseStateCorrelation keyword is set to YES, the TraceFileName keyword also defines the path to store tracing for state correlation. Tioli Eent Integration Facility adds the prefix to the specified file name. The prefix differentiates the trace file for the Jaa API from the trace file for state correlation. The default alue for the path is $TIVOLIHOME/tec/eif_sc.trc. If you specify a non-alid path name, the API returns the following error: LOG0014E Unable to open the handler output file <filename>. jaa.io.filenotfoundexception: <filename> (The system cannot find the path specified) This keyword is optional. TraceLeel=leel Specifies whether the Jaa API generates trace messages or not. By default, no messages are generated. Specify ALL to generate messages. If you specify any other alue or no alue, the API does not generate messages. This keyword is optional. TransportList=type_name... Specifies the user-supplied name of transport mechanisms to be used. When sending eents, the transport mechanisms are used in the order they are specified in when a failure occurs with the preious transport mechanism. When receiing eents, all the transport mechanisms are created and used. This keyword is optional. The transport type and channel for each type_name are specified by the Channels and Type keywords: type_namechannels=channel_name... Specifies the user-supplied names of channels that are used by the transport mechanism, which is specified by the TransportList keyword. This keyword is required. Appendix A. Eent Integration Facility Sender and Receier Keywords 199

214 type_nametype=lcf SOCKET TME SSL LOCALONLYSOCKET Specifies the transport type for the transport mechanism specified by the TransportList keyword. Types SOCKET and SSL can be used on any system. A Type alue of LCF is used when using the TME send eent protocol on an Endpoint. A Type alue of TME is only used by Tioli Risk Manager when it is installed on the Tioli Enterprise Console serer to send eents. When TME is used, TMEHost, TMEPassword and TMEUserID must also be specified. This keyword is required when TransportList is used. The serer and port for each channel_name are specified by the SererLocation and Port keywords. Depending on the Type specified, you also use one or more of the following keywords: channel_nameport=number Specifies the port number on which the transport mechanisms serer listens for the specified channel (set by the Channel keyword). See the usage information for the Port parameters on using the channel_name Port parameter. channel_namesererlocation=serer[region] Specifies the eent serer name and region on which the transport mechanisms serer is located for the specified channel (set by the Channel keyword). This keyword is required when the Type keyword is set to TME, LCF, SOCKET, LOCALONLYSOCKET, or SSL. See Table 21 on page 198 for alid formats of the serer and region fields. channel_namesslcipherlist=cipherlist Specifies an explicit list of cipher suites, oerriding the settings associated with SSLSecurityLeel. Instances of SSLCipher associated with the SSLCipherList are used to explicitly specify the list of enabled cipher suites. See SSLCipher on page 203 for the list of aailable ciphers. channel_namesslkeystore The path of the SSL keystore file. This file is typically used to store personal certificates, including priate keys. channel_namesslkeystorepw Specifies the password for the SSL keystore file. The password as specified here is clear-text. Tioli Risk Manager also proides the ability to store and retriee the password in an obfuscated representation. A Tioli Risk Manager utility is proided to take a clear-text password, obfuscate it, and store it in a stash file. channel_namesslkeystorepwfile Specifies the path to a stash file that contains an obfuscated representation of the password used to access the SSL keystore file, as specified with the SSLKeystore parameter. If you change the password in your keystore file, or use a different keystore file, it is necessary to reset the obfuscated password in the keystore password file. To store the obfuscated form of a new password in the file, use the wrmstashpw command. See the IBM Tioli Risk Manager Command Reference for details on using this command. 200 IBM Tioli Risk Manager: Administrator s Guide

215 channel_namesslrequireclientauthentication For serer-side support, specifies whether the connections must include client authentication: NO Clients do not need to proide authentication information (default). YES Clients must proide authentication information. channel_namesslsecurityleel Specifies the leel of cryptographic protection to be used by the EIF SSL client or serer, in conjunction with the IBM JSSE proider. For conenience, leels of protection are grouped into three classifications, using the following alues: high medium low If SSLSecurityLeel is not specified (and SSLCipherList is not specified), the leel of cryptographic protection defaults to high. When set to high and the configuration for EIF SSL is either a client or serer, the following cipher suites are enabled: SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_ RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA When set to medium and the configuration for EIF SSL is either a client or serer, the following cipher suites are enabled: SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA When set to low and the configuration for EIF SSL is serer, the following cipher suites are enabled. These suites do not encrypt the payload, but do perform integrity checks to ensure that the payload has not been modified during transit: SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA When set to low and the configuration for EIF SSL is client, the following cipher suites are enabled. These suites do not encrypt the payload, but do perform integrity checks to ensure that the payload has not been modified during transit: SSL_RSA_WITH_NULL_MD5 Appendix A. Eent Integration Facility Sender and Receier Keywords 201

216 SSL_RSA_WITH_NULL_SHA channel_namessltruststore The path of the SSL trust store file. This file is typically used to store signer certificates, which specify whether the signer of the serer s certificate is to be trusted. The trust file helps you manage which signers an organization allows connections to. This enables clients and serers to store their personal certificates (including priate keys) in the key store file and all of their signers in the trust store file. If not specified, SSLTruststore is set to the alue associated with SSLKeystore. channel_namessltruststorepw=password Specifies the password for the SSL trust store file. The password as specified here is clear-text. Tioli Risk Manager proides the ability to store and retriee the password in an obfuscated representation. A Tioli Risk Manager utility is proided to take a clear-text password, obfuscate it, and store it in a stash file. channel_nametmehost=hostname For the Jaa API only, specifies the host name of the managed node where the eent serer is located. This is a required keyword when the Type keyword is set to TME. channel_nametmepassword=password Specifies the cleartext password used for sending eents from the agent to the Tioli Enterprise Console serer, using the TME protocol. By default, Tioli Risk Manager does not use this keyword. The password is stored in an obfuscated fashion, in a stash file. See TMEPasswordFile for more information. This keyword, or the alternatie TMEPasswordFile, is required when the Type keyword is set to TME. channel_nametmepasswordfile=pathname Specifies the path to a stash file that contains an obfuscated representation of the password used for sending eents from the agent into the Tioli Enterprise Console serer, using the TME protocol. If you change the password used to make this connection, it is necessary to reset the obfuscated password in the TME password stash file. To store the obfuscated form of a new password in the file, use the wrmstashpw command. See the IBM Tioli Risk Manager Command Reference for details on using this command. channel_nametmeport=number Specifies the port number used for sending eents from the agent to the Tioli Enterprise Console serer, using the TME protocol. The default alue for this optional keyword is 94. This keyword can be used to oerride the default when the Type keyword is set to TME. channel_nametmeuserid=name Specifies the TME administrator ID used for sending eents from the agent to the Tioli Enterprise Console serer, using the TME protocol. Any TME administrator with the user role will suffice. In Tioli Risk Manager enironments, this parameter is automatically setup during installation to reference the supplied userid. This is a required keyword when the Type keyword is set to TME. 202 IBM Tioli Risk Manager: Administrator s Guide

217 cipher_listsslcipher=cipher Specifies a particular cipher suite within a list associated with an SSLCipherList. In addition to all of the cipher suites referenced in the documentation for SSLSecurityLeel, the following cipher suites are also aailable when using the IBM JSSE proider: SSL_IBM_DH_EKE_EXPORT_WITH_RC4_40_MD5 SSL_IBM_DH_EKE_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_WITH_IDEA_CBC_SHA SSL_IBM_DH_EKE_WITH_RC4_128_MD5 SSL_IBM_DH_EKE_WITH_DES_CBC_SHA SSL_IBM_DH_EKE_WITH_3DES_EDE_CBC_SHA Appendix A. Eent Integration Facility Sender and Receier Keywords 203

218 204 IBM Tioli Risk Manager: Administrator s Guide

219 Appendix B. Database Archie Configuration This section proides reference information about keywords for database archie configuration files. The two configuration files necessary for database archiing are: db_sender.conf rmclasspath.conf Database Archier Keywords The database archier is defined in rmagent.xml as a destination with classname= "com.tioli.riskmanager.agent.transports.senders.rmaarchiedbsender" and a configuration file defined by the RMA_conf parameter. The default database archie configuration file is RMINSTDIR/etc/db_sender.conf. This file must be configured with the parameters necessary for the agent to connect to the database containing the Tioli Risk Manager archie table. The parameters are described in the following section. The database archie configuration file might contain the following keywords: ArchieDBUserid=userid The archie database userid. ArchieDBPasswordFile=passwordfilename The stashed password of the database user. ArchieDBType= DB2 ORACLE MSSQL SYBASE Specifies the database type. ArchieDBPort=databaseportnumber Port used by the JDBC to communicate with the database. Common defaults are proided for each database. ArchieDBName=databasename The name of the database you will use to store Tioli Risk Manager eents in. In most instances, you can use the Tioli Enterprise Console database unless you want to create a separate database for archiing eents. The database should hae be created prior to running the Tioli Risk Manager installation. ArchieDBDescriptionXML=XMLfilename XML file that describes the archie database entries. The default alue is RMINSTDIR/etc/archie_db.xml. ArchieDBDrier=JDBCdriername JDBC drier to be used. DB2: COM.ibm.db2.jdbc.net.DB2Drier Oracle: oracle.jdbc.drier.oracledrier Microsoft SQL: Copyright IBM Corp

220 The following is an example for the Microsoft drier. com.microsoft.jdbc.sqlserer.sqlsererdrier The following is an example for the DataDirect drier. com.ddtek.jdbc.sqlserer.sqlsererdrier The following is an example for the Aenir drier. net.aenir.jdbc2.drier Sybase: The following is an example for the default Sybase drier. com.sybase.jdbc2.jdbc.sybdrier The following is an example for the DataDirect drier. com.ddtek.jdbc.sqlserer.sybasedrier ArchieDBHostName=hostname Host name where the database resides. ArchieJDBCUrl=Urlstring JDBC connection URL. This is used for MSSQL and Sybase. Microsoft SQL: The following is an example for the Microsoft drier. jdbc:microsoft:sqlserer://acme.com:1433 The following is an example for the DataDirect drier. jdbc:datadirect:sqlserer://acme.com:1433 The following is an example for the Aenir drier. jdbc:aenirdrier://acme.com:1433 Sybase: JDBC Classpath Settings The following is an example for the default Sybase drier. jdbc:sybase:tds:acme.com:4100 The following is an example for the DataDirect drier. jdbc:datadirect:sybase://acme.com:5000 In order for the JDBC driers to function, the location of the drier class files must be known to the agent. The information is located in the rmclasspath.conf file, and points to the JAR or ZIP files that contain the database drier. DB2: $DB2PATH/jaa12/db2jaa.zip Oracle: $ORACLE_HOME/jdbc/lib/classes111.zip Microsoft SQL: 206 IBM Tioli Risk Manager: Administrator s Guide

221 The following is an example for the Microsoft drier. C:\temp\mssqlserer.jar;C:\temp\msutil.jar;C:\temp\msbase.jar The following is an example for the DataDirect drier. C:\temp\sqlserer.jar;C:\temp\base.jar;C:\temp\util.jar Sybase: C:\sybase\jConnect-5_2\classes\jconn2.jar Appendix B. Database Archie Configuration 207

222 208 IBM Tioli Risk Manager: Administrator s Guide

223 Appendix C. Secure Socket Layer Introduction and ikeyman Priacy and security are concepts that are more critical than eer in today s electronic business enironment. Eery business professional needs to be concerned about security oer open communication networks, such as the Internet. It is not enough to hae a secure Web site; you also need to hae secure communication between Web sites, communication that cannot be monitored by outside parties. Both you and your users need to be confident that you hae a secure enironment in which to conduct your business. This appendix proides an introduction to the concept of a Secure Sockets Layer (SSL), which proides communication security for Tioli Risk Manager by using digital certificates. Digital certificates are explained in greater detail in Digital Certificates. Secure Sockets Layer Oeriew Secure communication requires encryption, and encryption is what the SSL, proides: security for the connection oer which you can communicate. SSL was deeloped jointly by Netscape Communications and RSA Data Security. Many companies worldwide hae adopted SSL as their communication protocol of choice. In fact, many financial transactions on the Internet, including online banking, are now conducted using SSL. Because digital certificates are an important component of SSL, this appendix consists of the following sections: Digital Certificates How SSL Works on page 214 Tioli Risk Manager and SSL on page 217 Managing Digital Certificates with Keytool on page 220 Managing Digital Certificates with ikeyman on page 222 Digital Certificates Digital certificates allow unique identification of an entity; they are, in essence, electronic ID cards issued by trusted parties. Digital certificates allow a user to erify to whom a certificate is issued as well as the issuer of the certificate. Digital certificates are the ehicle that SSL uses for public-key cryptography. Public-key cryptography uses two different cryptographic keys: a priate key and a public key. Public-key cryptography is also known as asymmetric cryptography, because you can encrypt information with one key and decrypt it with the complement key from a gien public-priate key pair. Public-priate key pairs are simply long strings of data that act as keys to a user s encryption scheme. The user keeps the priate key in a secure place (for example, encrypted on a computer s hard drie) and proides the public key to anyone with whom the user wants to communicate. The priate key is used to digitally sign all secure communications sent from the user; the public key is used by the recipient to erify the sender s signature. Copyright IBM Corp

224 Public-key cryptography is built on trust; the recipient of a public key needs to hae confidence that the key really belongs to the sender and not to an impostor. Digital certificates proide that confidence. A digital certificate seres two purposes: it establishes the owner s identity, and it makes the owner s public key aailable. A digital certificate is issued by a trusted authority a certificate authority (CA) and it is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced. Format of Digital Certificates The digital certificate contains specific pieces of information about the identity of the certificate owner and about the certificate authority: Owner s distinguished name. A distinguished name is the combination of the owner s common name and its context (position) in the directory tree. In the simple directory tree shown in Figure 46, for example, LaurenA is the owner s common name, and the context is OU=Engnring.O=XYZCorp; therefore, the distinguished name is:.cn=laurena.ou=engnring.o=xyzcorp Owner s public key. Date the digital certificate was issued. Date the digital certificate expires. Issuer s distinguished name. This is the distinguished name of the CA. Issuer s digital signature. O=XYZ Corp OU=Engnring OU=Accting CN=LaurenA CN=ChrisR Figure 46. A Simple Directory Tree 210 IBM Tioli Risk Manager: Administrator s Guide

225 Figure 47 shows the layout of a typical digital certificate. Owner s Distinguished Name Owner s Public Key Issuer s (CA) Distinguished Name Issuer s Signature Figure 47. Simplified Layout of a Digital Certificate Security Considerations for Digital Certificates If you send your digital certificate containing your public key to someone else, what keeps that person from misusing your digital certificate and posing as you? The answer is your priate key. A digital certificate alone can neer be proof of anyone s identity. The digital certificate just allows you to erify the identity of the digital certificate owner by proiding the public key that is needed to check the digital certificate owner s digital signature. Therefore, the digital certificate owner must protect the priate key that belongs to the public key in the digital certificate. If the priate key is stolen, the thief can pose as the legitimate owner of the digital certificate. Without the priate key, a digital certificate cannot be misused. Certificate Authorities and Trust Hierarchies Trust is a ery important concept in digital certificates. Each organization or user must determine which CAs can be accepted as trustworthy. A user of a security serice requiring knowledge of a public key generally needs to obtain and alidate a digital certificate containing the required public key. Receiing a digital certificate from a remote party does not gie the receier any assurance about the authenticity of the digital certificate. To erify that the digital certificate is authentic, the receier needs the public key of the certificate authority that issued the digital certificate. Appendix C. Secure Socket Layer Introduction and ikeyman 211

226 If the public key user does not already hold an assured copy of the public key of the certificate authority that signed the digital certificate, then the user might need an additional digital certificate to obtain that public key. In general, a chain of multiple digital certificates might be needed, comprising a digital certificate of the public key owner (the end entity) signed by one CA, and optionally one or more additional digital certificates of CAs signed by other CAs. Figure 48 shows a chain of trust. Owner s Distinguished Name Owner s Public Key Issuer s (CA) Distinguished Name Issuer s Signature Verify Signature Owner s (CA s) Distinguished Name Owner s Public Key Issuer s (Root CA s) Distinguished Name Issuer s Signature Verify Signature Root CA s Distinguished Name Root CA s Public Key Root CA s Signature Figure 48. Chain of Trust CAs Signing CA Digital Certificates Up to the Root CA Note that many applications that send a subject s digital certificate to a receier send not only that digital certificate, but also send all the CA digital certificates necessary to erify the initial digital certificate up to the root CA. The chain of trust begins at the root CA. The root CA s digital certificate is self-signed; that is, the certificate authority uses its own priate key to sign the digital certificate. The public key used to erify the signature is the public key in the digital certificate itself (see Figure 49 on page 214). To establish a chain of trust, the public-key user must hae receied the digital certificate of the root CA in one of the following ways: On a diskette receied by registered mail or picked up in person Pre-loaded with software receied from a reliable source or downloaded from an authenticated serer Uses for Digital Certificates in Internet Applications Applications using public-key cryptography systems for key exchange or digital signatures need to use digital certificates to obtain the needed public keys. Internet 212 IBM Tioli Risk Manager: Administrator s Guide

227 applications of this kind are numerous. Following are brief descriptions of a few of the commonly used Internet applications that use public-key cryptography: SSL A protocol that proides priacy and integrity for communications. This protocol is used by Web serers to proide security for connections between Web serers and Web browsers, by the LDAP to proide security for connections between LDAP clients and LDAP serers, and by Tioli Risk Manager to proide security for connections between the client and a serer. SSL uses digital certificates for key exchange, serer authentication, and optionally, client authentication. Client Authentication Client authentication is an option in SSL that requires a serer to authenticate a client s digital certificate before allowing the client to log on or access certain resources. The serer requests and authenticates the client s digital certificate during the SSL handshake. At that time the serer can also determine whether it trusts the CA that issued the digital certificate to the client. Secure Electronic Mail Many electronic mail systems, using standards such as Priacy Enhanced Mail (PEM) or Secure/Multipurpose Internet Mail Extensions (S/MIME) for secure electronic mail, use digital certificates for digital signatures and for the exchange of keys to encrypt and decrypt messages. Virtual Priate Networks (VPNs) Virtual priate networks, also called secure tunnels, can be set up between firewalls to enable protected connections between secure networks oer insecure communication links. All traffic destined to these networks is encrypted between the firewalls. The protocols used in tunneling follow the IP Security (IPsec) standard. For the key exchange between partner firewalls, the Internet key exchange (IKE) standard, preiously known as ISAKMP/Oakley, has been defined. The standards also allow for a secure, encrypted connection between a remote client (for example, an employee working from home) and a secure host or network. Secure Electronic Transaction ( SET ) SET is a standard designed for secure credit card payments in insecure networks (the Internet). Digital certificates are used for card holders (electronic credit cards) and merchants. The use of digital certificates in SET allows for secure, priate connections between card holders, merchants, and banks. The transactions created are secure and indisputable, and they cannot be forged. The merchants receie no credit card information that can be misused or stolen. Digital Certificates and Certificate Requests Simplified, a signed digital certificate contains the owner s distinguished name, the owner s public key, the certificate authority s (issuer s) distinguished name, and the signature of the certificate authority oer these fields. A self-signed digital certificate contains the owner s distinguished name, the owner s public key, and the owner s own signature oer these fields, as shown in Figure 49 on page 214. Appendix C. Secure Socket Layer Introduction and ikeyman 213

228 Owner s Distinguished Name Owner s Public Key Owner s Signature Figure 49. Self-Signed Digital Certificate A root CA s digital certificate is an example of a self-signed digital certificate. You can also create your own self-signed digital certificates to use when deeloping and testing a serer product. You can create a self-signed digital certificate with the keytool utility, proided with the Jaa irtual machine (JVM). Or you can use the ikeyman utility. See Creating a Self-Signed Digital Certificate for Testing on page 224 for information on using ikeyman to create self-signed certificates. A certificate request that is sent to a certificate authority to be signed contains the owner s (requester s) distinguished name, the owner s public key, and the owner s own signature oer these fields. The certificate authority erifies this signature with the public key in the digital certificate to ensure that: The certificate request was not modified in transit between the requester and the CA. The requester is in possession of the priate key that belongs to the public key in the certificate request. The CA is also responsible for some leel of identification erification. This can range from ery little proof to absolute assurance of the owner s identity. How SSL Works SSL is a protocol that proides priacy and integrity between two communicating applications using TCP/IP. The Hypertext Transfer Protocol (HTTP) for the World Wide Web uses SSL for secure communications. The data going back and forth between client and serer is encrypted using a symmetric algorithm such as DES or RC4. A public-key algorithm usually RSA is used for the exchange of the encryption keys and for digital signatures. The algorithm uses the public key in the serer s digital certificate. With the serer s digital certificate, the client can also erify the serer s identity. Versions 1 and 2 of the SSL protocol proide only serer authentication. Version 3 adds client authentication, using both client and serer digital certificates. 214 IBM Tioli Risk Manager: Administrator s Guide

229 The SSL Handshake An SSL connection is always initiated by the client. At the beginning of an SSL session, an SSL handshake is performed. This handshake produces the cryptographic parameters of the session. A simplified oeriew of how the SSL handshake is processed is shown in Figure 50. This example assumes the SSL connection is being established between a Web browser and a Web serer. Client issues secure session request ( Serer send X.509 certificate containing serer s public key. Client authenticates certificate against list of known CAs. (If CA is unknown, browser can gie user option to accept certificate at user s risk.) Client generates random symmetric key and encrypts it using serer s public key. Client and Serer now both know the symmetric key and encrypt end-user data using symmetric key for duration of session. Figure 50. SSL Handshake with Serer Authentication 1. The client sends a client hello message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the ersion of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number. 2. The serer responds with a serer hello message that contains the cryptographic method (cipher suite) and the data compression method selected by the serer, the session ID, and another random number. Note: The client and the serer must support at least one common cipher suite, or else the handshake fails. The serer generally chooses the strongest common cipher suite. 3. The serer sends its digital certificate. (The serer uses X.509 V3 digital certificates with SSL.) If the serer uses SSL V3, and if the serer application (for example, the Web serer) requires a digital certificate for client authentication, the serer sends a Appendix C. Secure Socket Layer Introduction and ikeyman 215

230 digital certificate request message. In the digital certificate request message, the serer sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities. 4. The serer sends a serer hello done message and waits for a client response. 5. Upon receipt of the serer hello done message, the client (the Web browser) erifies the alidity of the serer s digital certificate and checks that the serer s hello parameters are acceptable. If the serer requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is aailable, the client sends a no digital certificate alert. This alert is only a warning, but the serer application can fail the session if client authentication is mandatory. 6. The client sends a client key exchange message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the serer. If the client sent a digital certificate to the serer, the client sends a digital certificate erify message signed with the client s priate key. By erifying the signature of this message, the serer can explicitly erify the ownership of the client digital certificate. Note: An additional process to erify the serer digital certificate is not necessary. If the serer does not hae the priate key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails. 7. The client uses a series of cryptographic operations to conert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is deried. Then the client sends a change cipher spec message to make the serer switch to the newly negotiated cipher suite. The next message sent by the client (the finished message) is the first message encrypted with this cipher method and keys. 8. The serer responds with a change cipher spec and a finished message of its own. 9. The SSL handshake ends, and encrypted application data can be sent. Digital Certificates and Trust Chains with SSL Secure Sockets Layer V3 can use serer digital certificates as well as client digital certificates. As preiously explained, serer digital certificates are mandatory for an SSL session, while client digital certificates are optional, depending on client authentication requirements. The public key infrastructure (PKI) used by SSL allows for any number of root certificate authorities. An organization or end user must decide which CAs it will accept as being trusted. To be able to erify the serer digital certificates, the client must hae possession of the root CA digital certificates used by serers. If an SSL session is about to be established with a serer that sends a digital certificate with root CA digital certificate that is not defined in the client s truststore file, the SSL session is not established. To aoid this situation, import the root CA digital certificate into your client keystore or truststore. If client authentication is used, the serer requires possession of the root CA digital certificates used by clients. All root CA digital certificates that are not part of the default serer keystore must be installed using the ikeyman utility before any 216 IBM Tioli Risk Manager: Administrator s Guide

231 Tioli Risk Manager and SSL client digital certificates are issued by these CAs. For more information on ikeyman, see Managing Digital Certificates with ikeyman on page 222. Tioli Risk Manager uses SSL in both the client and serer capacities. When a Tioli Risk Manager system is the recipient of eent traffic oer SSL connections, it is running as an SSL serer. When a Tioli Risk Manager system is sending eent traffic oer SSL connections, it is running as an SSL client. Configurations that are receiing eents oer SSL connections, and forwarding eents oer SSL are sering in both roles. The SSL roles played by arious Tioli Risk Manager configurations are listed here: Client Participates as an SSL client Distributed Correlation Serer Participates as both an SSL client and an SSL serer, because it is receiing eent information from the client, and forwarding eent information to an upstream serer. Eent Serer Participates as an SSL Serer Gateway Participates as both an SSL client and an SSL serer, because it receies and forwards eent information. A particular Tioli Risk Manager system typically has a keystore for each SSL role. For example, a client would use a client keystore. A gateway or distributed correlation serer would hae both a client keystore and a serer keystore. An eent serer would hae a serer keystore only. Default Keystore Files When installing Tioli Risk Manager, you can use the default client and serer keystore files that come with Tioli Risk Manager. By using these files, you can use SSL and establish secure connections between the arious Tioli Risk Manager systems (including client and serer authentication). While this might be conenient for getting Tioli Risk Manager up and running quickly and proides encrypted connections, using these files does not establish a truly secure enironment because the priate keys are not truly priate. The following default keystore files are installed with Tioli Risk Manager: RMINSTDIR/etc/SSLclient.jks RMINSTDIR/etc/SSLsr.jks The password associated with these default keystore files is riskmgr. Do not use the default keystores in production enironments. Priate keys and signed certificates should be generated and used to create the necessary keystore files for your enironment. See Planning Considerations on page 218 for more information on the planning considerations for creating keystores for your enironment. Storing SSL Passwords When creating a secure SSL connection, Tioli Risk Manager must hae access to the password needed to access the keystore file. Instead of storing the password in the clear in a configuration file, the password is stored in an obfuscated fashion in a stash file. Appendix C. Secure Socket Layer Introduction and ikeyman 217

232 It is essential that keystores and associated stash files be protected, including the use of appropriate local file system security. These files should not be shared with anyone you do not trust. By conention, the name of the stash file is deried from the name of the associated keystore file. For example, the stash files associated with the default keystore files are: stashsslclient.pwd (associated with SSLclient.jks) stashsslsr.pwd (associated with SSLsr.jks) To continue the example, if you name a custom keyfile as foo.jks, the associated stash file would be called stashfoo.pwd. The associated stash file must be located in the same directory as the associated keystore file. The wrmstashpw command is proided to create a stash file with an obfuscated password. When creating new keystores, or changing the password of an existing keystore, use wrmstashpw to build a stash file with the matching password. See the IBM Tioli Risk Manager Command Reference for details on using this utility. Planning Considerations When planning your SSL configuration, consider the following: Each serer requires a serer keystore with a priate key and an associated signed certificate. The certificate may be self-signed or signed by a Certification Authority (CA). Each serer should hae its own keystore with a different priate key and associated signed certificate. Each client requires a client keystore with a CA certificate signed by the same signer as the signed certificate in the serers keystore. If you plan on using client authentication, each client keystore must contain a priate key and an associated signed certificate. The serer s keystore must include a CA certificate signed by the same signer as the signed certificate in the client keystore. When using client authentication, each client should hae its own keystore with a different priate key and associated signed certificate. Decide whether a Certification Authority (CA) will be used to sign your certificates, or self-signed certificates will be used. Some characteristics associated with each choice include: Self-signed certificates: - Adantages No cost No outside dependencies Quick start May be appropriate for small, intranet enironments - Disadantages More complex client configuration, because each client must hae a keystore that contains a certificate for each serer with which it communicates. If self-signed certificates are used for the clients, then the serer for a set of clients must hae a keystore that contains a signed certificate for each and eery client. CA-signed certificates: 218 IBM Tioli Risk Manager: Administrator s Guide

233 - Adantages Simpler client configuration, often works by default (if the default client keystore contains the appropriate signer certificate). Each client can use the same keystore een when multiple serers are in use. May be appropriate for internet ecommerce enironments and large intranet enironments. - Disadantages Higher cost (might need to purchase certificates) Certificates must be requested (there may be a delay in obtaining the signed certificates) SSL Configuration Files When a Tioli Risk Manager system is configured to accept SSL connections, a source definition is needed in the primary Tioli Risk Manager configuration file (rmagent.xml). Similarly, when a Tioli Risk Manager system is configured to create outbound SSL connections (to forward eent information), a destination definition is needed in rmagent.xml as well. The following example depicts the source and destination definitions for an SSL receier and SSL sender, respectiely. <source name = "eif_receier" class = "com.tioli.riskmanager.agent.transports.receiers.rmaeifreceier"> <set key="rma_conf" alue="f:\program Files\RISKMGR\etc\eif_receier.conf"/> </source> <destination name = "incident_sender" class = "com.tioli.riskmanager.agent.transports.senders.rmaeifsender"> <set key="rma_conf" alue="f:\program Files\RISKMGR\etc\incident_sender.conf"/> </destination> The source and destination definitions reference configuration files that contain the specific EIF configuration parameters necessary to control the EIF SSL connections. In this example, the eif_receier.conf file typically contains the following type of information. In this example, gateway1.de.tioli.com is the local host name and client authentication is required (each client must proide a certificate). This configuration file defines the SSL serer role. TransportationList=t1 t1type=ssl t1channels=c1 c1sererlocation=gateway1.tioli.com c1port=5549 c1sslrequireclientauthentication=yes c1sslkeystore=f:\program Files\RISKMGR\etc\SSLsr.jks c1sslkeystorepwfile=f:\program Files\RISKMGR\etc\stashSSLsr.pwd c1sslsecurityleel=high Similarly, the incident_sender.conf file might look like this, where serer1.tioli.com is the remote serer to which information will be forwarded. This configuration file defines the SSL client role. TransportList=t1 t1type=ssl t1channels=c1 c1sererlocation=serer1.tioli.com c1port=5549 c1sslkeystore=f:\program Files\RISKMGR\etc\SSLclient.jks c1sslkeystorepwfile=f:\program Files\RISKMGR\etc\stashSSLclient.pwd c1sslsecurityleel=high Appendix C. Secure Socket Layer Introduction and ikeyman 219

234 See Chapter 4, Agent, on page 61 for more information on configuring the agent and its rmagent.xml file. See Appendix A, Eent Integration Facility Sender and Receier Keywords, on page 195 for more information on configuring SSL in the indiidual EIF configuration files. TrustStores By default, Tioli Risk Manager stores the following information in a keystore: Key pairs and certificates, used for SSL authentication Trusted CA certificates (also known as signer certificates), used to erify the identifies of other clients and serers As an administrator of the SSL enironment, you may prefer to maintain the key pairs and certificates in keystores and maintain the CA certificates (also known as signer certificates) in a separate truststore. The trustfile helps you manage which signers an organization allows connections to. This enables clients and serers to store their personal certificates (including priate keys) in the keystore file and all of the signers in the truststore file. If a truststore is not specified, it is assumed that CA certificates are located in the keystore file. In this example, the serer-side configuration file defines separate keystore and truststore files. TransportationList=t1 t1type=ssl t1channels=c1 c1sererlocation=gateway1.tioli.com c1port=5549 c1sslrequireclientauthentication=yes c1sslkeystore=f:\ibm\riskmgr\etc\sslsr.jks c1sslkeystorepwfile=f:\ibm\riskmgr\etc\stashsslsr.pwd c1ssltruststore=f:\ibm\riskmgr\etc\sslsrtrust.jks c1ssltruststorepwfile=f:\ibm\riskmgr\etc\stashsslsrtrust.pwd c1sslsecurityleel=high Managing Digital Certificates with Keytool The Jaa Runtime Enironment (JRE) used by Tioli Risk Manager proides keytool, a key and certificate management utility. Keytool can be used to administer public and priate key pairs and associated certificates. Keytool can also be used to generate certificate requests, so commercial certification authorities can be used to sign your certificates. Tioli Risk Manager proides an alternatie tool, called ikeyman. It proides a graphical interface for managing certificates and keystores. See Managing Digital Certificates with ikeyman on page 222 for information about using ikeyman. The keytool utility is intended to be run from the command line, by typing the following: keytool On UNIX systems, keytool is typically located at: $JAVA_HOME/bin/keytool On Windows systems, keytool is included with the JRE installed with Tioli Risk Manager, and is located at: RMINSTDIR\jre\jre\bin\keytool.exe 220 IBM Tioli Risk Manager: Administrator s Guide

235 The command line options can be proided in any order. Type keytool help to see a summarized ersion of keytool s usage information. On UNIX systems, use man keytool for detailed usage information. For more detailed keytool information see the following Web resources: (UNIX) (Windows) Shown here is a sample script for running keytool. A script of this nature can be useful when generating a large number of certificates and keystores in a production enironment. This sample script is proided to illustrate typical usage. With appropriate customizing it might proide a model suitable for your enironment. #!/bin/sh # This sample script depicts the sequence of steps for using keytool # to create self-signed client and serer certificates for use with # Risk Manager s SSL support. # # Note that this script assumes that priate keys and public certificates # are stored in the same keystore file (client and serer). Public # certificates can be stored in separate, password-protected truststores. # Setup common enironment ariables CLIENT_DNAME="cn=Risk Manager Agent SSL Sender,ou=Tioli,o=IBM,c=US" CLIENT_ALIAS="rma_ssl_sender" CLIENT_PW="rma_sender_pw" CLIENT_KEYSTORE="$CLIENT_ALIAS".jks CLIENT_CERTFILE="$CLIENT_ALIAS".cert SERVER_DNAME="cn=Risk Manager Agent SSL Receier,ou=Tioli,o=IBM,c=US" SERVER_ALIAS="rma_ssl_receier" SERVER_PW="rma_receier_pw" SERVER_KEYSTORE="$SERVER_ALIAS".jks SERVER_CERTFILE="$SERVER_ALIAS".cert SERVER_NCAUTH_KEYSTORE="$SERVER_ALIAS"_ncauth.jks DAYS_VALID=365 set -x # Generate client s keypair and keystore # Also creates a self-signed public key certificate for the client # By creating a keypair, the client can support client authentication # when connecting to the Tioli Risk Manager serer. If not using client # authentication, it is sufficient to import the serer s public # key certificate into the client s keystore. keytool -genkey -alidity "$DAYS_VALID" -keypass "$CLIENT_PW" \ -dname "$CLIENT_DNAME" -alias "$CLIENT_ALIAS" \ -keystore "$CLIENT_KEYSTORE" -storepass "$CLIENT_PW" # Export client s public key certificate to a file keytool -export -keystore "$CLIENT_KEYSTORE" -storepass "$CLIENT_PW" \ -alias "$CLIENT_ALIAS" -rfc -file "$CLIENT_CERTFILE" # Generate serer s keypair and keystore # Also creates a self-signed public key certificate for the serer # A serer always requires a keypair, unlike the client keytool -genkey -alidity "$DAYS_VALID" -keypass "$SERVER_PW" \ -dname "$SERVER_DNAME" -alias "$SERVER_ALIAS" \ -keystore "$SERVER_KEYSTORE" -storepass "$SERVER_PW" Appendix C. Secure Socket Layer Introduction and ikeyman 221

236 # Export serer s public key certificate to a file keytool -export -keystore "$SERVER_KEYSTORE" -storepass "$SERVER_PW" \ -alias "$SERVER_ALIAS" -rfc -file "$SERVER_CERTFILE" # Import serer s public key certificate into client s keystore as a # new trusted certificate. keytool -import -keystore "$CLIENT_KEYSTORE" -storepass "$CLIENT_PW" \ -alias "$SERVER_ALIAS" -file "$SERVER_CERTFILE" -noprompt # Make a copy of the serer keystore before adding the client s certificate # This can be used to test the case where no client authentication is required cp "$SERVER_KEYSTORE" "$SERVER_NCAUTH_KEYSTORE" # Import client s public key certificate into the serer s keystore as a # new trusted certificate. This is required only when client authentication # is required by the serer. keytool -import -keystore "$SERVER_KEYSTORE" -storepass "$SERVER_PW" \ -alias "$CLIENT_ALIAS" -file "$CLIENT_CERTFILE" -noprompt Managing Digital Certificates with ikeyman The ikeyman utility is a tool you can use to manage your digital certificates. With ikeyman, you can create a new key database or a test digital certificate, add CA roots to your database, copy certificates from one database to another, request and receie a digital certificate from a CA, set default keys, and change passwords. The ikeyman utility is a part of the IBM Jaa Secure Socket Extension package. Starting ikeyman The ikeyman utility is installed with Tioli Risk Manager. To load ikeyman, run the wrmikeyman shell script, located in RMINSTDIR/etc/bin. UNIX system: wrmikeyman Windows system: wrmikeyman.cmd For more information about using this command, see the IBM Tioli Risk Manager Command Reference. Creating a Key Database A key database enables a client application to connect to those serers that hae digital certificates signed by those CAs for which you hae signed digital certificates. To create a key file, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File New. The New window is displayed, which will look similar to the one shown in Figure 51 on page IBM Tioli Risk Manager: Administrator s Guide

237 Figure 51. New Key Database File Window 3. Select JKS for the Key database type field. 4. Change the alues for the File Name and Location, if desired. 5. Click OK. The Password Prompt window is displayed, as shown in Figure 52. Figure 52. Password Prompt Window 6. Type a password in the Password field, and type it again in the Confirm Password field. 7. Click OK. A confirmation window is displayed, erifying that you hae created a key database. 8. Click OK. You hae successfully created a key database, and the IBM Key Management window is displayed. The IBM Key Management, an example of which is shown in Figure 53 on page 224, will reflect your new key file name and your signer digital certificates. Appendix C. Secure Socket Layer Introduction and ikeyman 223

238 Figure 53. IBM Key Management Window The following signer digital certificates are proided with ikeyman: RSA Secure Serer CA Thawte Personal Premium CA Thawte Personal Fre CA Thawte Personal Basic CA Thawte Premium Serer CA Thawte Serer CA VeriSign Class 1 Public Primary CA VeriSign Class 2 Public Primary CA VeriSign Class 3 Public Primary CA VeriSign Test CA Root Certificate These signer digital certificates enable your clients to connect to serers that hae alid digital certificates from these signers. Now that you hae created a key database, you can use it on your client and connect to a serer that has a alid digital certificate from one of the signers. If you need to use a signer digital certificate that is not on this list, you need to request it from the CA and add it to your key database (see Adding a CA Root Digital Certificate on page 225). Note: The VeriSign Test CA Root Certificate is a low-assurance CA that is included for testing purposes. You should remoe this root before placing a key database class into a production application. Creating a Self-Signed Digital Certificate for Testing When you are testing a production application, you might not want to purchase a true digital certificate until after you are done testing the product. With ikeyman, 224 IBM Tioli Risk Manager: Administrator s Guide

239 you can create a self-signed digital certificate to use until testing is complete. A self-signed digital certificate is a temporary digital certificate you issue to yourself, with yourself as the CA. To create a self-signed digital certificate, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open to display the Open window. 3. Select the key database file to which you want to add a self-signed digital certificate and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the file is open and ready. 5. Select Personal Certificates from the list. 6. Click New Self-Signed. The Create New Self-Signed Certificate window is displayed, as shown in Figure 54. Figure 54. Create New Self-Signed Certificate Window 7. Type a Key Label, such as keytest, for the self-signed digital certificate. 8. Type a Common Name and Organization, and select a Country. For the remaining fields, either accept the default alues, or type or select new alues. 9. Click OK. The IBM Key Management window is displayed. The Personal Certificates field shows the name of the self-signed digital certificate you created. Adding a CA Root Digital Certificate After you hae requested and receied a CA root digital certificate from a CA, you can add it to your database. Most root digital certificates hae the form *.arm (for example, cert.arm). To add a CA root digital certificate to a database, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open to display the Open window. Appendix C. Secure Socket Layer Introduction and ikeyman 225

240 3. Select the key database file to which you want to add a CA root digital certificate and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the file is open and ready. 5. Select Signer Certificates from the list. 6. Click Add. The Add CA s Certificate from a File window is displayed. 7. Click Data type and select a data type, such as Base64-encoded ASCII data. 8. Type a Certificate file name and Location for the CA root digital certificate, or click Browse to select the name and location. 9. Click OK. The Enter a Label window is displayed. 10. Type a label for the CA root digital certificate, such as VeriSign Test CA Root Certificate, and click OK. The IBM Key Management window is displayed. The Signer Certificates field now shows the label of the CA root digital certificate you just added. Deleting a CA Root Digital Certificate If you no longer want to support one of the signers in your signer digital certificate list, you need to delete the CA root digital certificate. Note: Before deleting a CA root digital certificate, create a backup copy in case you later want to re-create the CA root. To delete a CA root digital certificate from a database, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open to display the Open window. 3. Select the key database file from which you want to delete a CA root digital certificate and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the file is open and ready. 5. Select Signer Certificates from the pulldown list. 6. Select the CA root digital certificate you want to delete and click Delete. The Confirm window is displayed. 7. Click Yes. The IBM Key Management window is displayed. The label of the CA root digital certificate you just deleted no longer appears in the Signer Certificates field. Copying Certificates from One Key Database to Another When setting up a priate trust network or using self-signed certificates for testing purposes, you might find it necessary to extract a certificate from a database to be added to another database as a signer or site certificate. Other times, you might want to export a personal certificate and import it as a personal certificate. First scenario: To extract a certificate from the (source) key database to be added as a signer or site certificate in the (target) key database, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open. The Open window is displayed. 226 IBM Tioli Risk Manager: Administrator s Guide

241 3. Select the (source) key database containing the certificate that you would like to add to another (target) database as a signer or site certificate and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the class is open and ready. 5. Select the type of certificate you want to export: Personal, Signer, or Site. 6. Select the certificate that you want to add to another database. 7. If you select Personal, click the Extract Certificate button. If you select Signer or Site, click the Extract button. The Extract a Certificate to a File window is displayed. Proceed with the remaining steps. 8. Click Data type and select a data type, such as Base64-encoded ASCII data. The data type needs to match the data type of the certificate stored in the certificate file. The ikeyman tool supports Base64-encoded ASCII files and binary DER-encoded certificates. 9. Type the certificate file name and location where you want to store the certificate, or click Browse to select the name and location. 10. Click OK. The certificate is written to the specified file, and the IBM Key Management window is displayed. To add a certificate as a signer or site certificate to the database (target), follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open to display the Open window. 3. Select the key database to which you would like to add the certificate that has been extracted from aboe and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the class is open and ready. 5. Select the type of certificate you would like to add: Signer or Site. 6. Click Add. If you had selected Signer Certificates from the list the Add CA s Certificate from a File window is displayed. If you had selected Site Certificates from the list the Add Site Certificate window displays. For more information concerning these two windows see step 8 in the first scenario aboe. 7. Type the certificate file name that you used when you extracted a certificate. For more information, see step 9 in the first scenario aboe. 8. The Enter a Label window is displayed. 9. Specify the name of the certificate, and click OK. The certificate is now added to the (target) database. Second scenario: In the preious scenario, you extracted a personal, signer, or site certificate from a source database and added it to the target database as a signer or site certificate. This scenario exports a personal certificate from a source database and imports it to a target database as a personal certificate. To export a personal certificate from the (source) key database to be imported as a personal certificate in the (target) key database follow these steps: 1. Start ikeyman, if it is not already running. Appendix C. Secure Socket Layer Introduction and ikeyman 227

242 2. Click Key Database File Open. The Open window is displayed. 3. Select the (source) key database containing the certificate that you would like to add to another (target) key database as a personal certificate and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the class is open and ready. 5. Select Personal Certificates from the list. 6. Select the personal certificate you want to export. 7. Select the Export/Import button to transfer keys between the current database and a PKCS12 file or another database. The Export/Import Key window is displayed. 8. Select Export from the Choose Action Type. 9. Select Key File Type (for example, PKCS12 file) from the list to be exported. 10. Type the certificate file name (for example, copy.p12) that you would like to export and the location where you want to store the certificate, or click Browse to select the name and location and click OK. The Password Prompt window is displayed. 11. Enter a password for the password file, confirm the password, and click OK. The certificate is now extracted from the (source) database. To import a personal certificate to the (target) key database, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open. The Open window is displayed. 3. Select the (target) key database to which you would like to import the certificate that has been exported aboe and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the class is open and ready. 5. Select the Personal Certificates from the list. 6. If the target key database has no personal certificate, click the Import button to import keys from a PKCS12 file or another database. The Import Key window is displayed. If the target key database has one or more personal certificates: Click the Export/Import key button and the Export/Import key window is displayed. Select Import from the Choose Action Type. 7. Select the same key file type that you specified from the export. For more information, see step 10 on page 227, and click OK. The Password Prompt window is displayed. 8. Specify the password used when you exported. For more information, see step 11 on page 228 from the second scenario and click OK. The certificate is now imported to the (target) database. Requesting a Digital Certificate A digital certificate is required to run the SSL-enabled serer code and might be required for client applications. To acquire a digital certificate, generate a request using ikeyman and submit the request to a CA. The CA will erify your identity and send you a digital certificate. 228 IBM Tioli Risk Manager: Administrator s Guide

243 To request a digital certificate, follow these steps: 1. Start ikeyman, if it is not already running. 2. Click Key Database File Open. The Open window is displayed. 3. Select the key database file from which you want to generate the request and click Open. The Password Prompt window is displayed. 4. Type the password and click OK. The IBM Key Management window is displayed. The title bar shows the name of the key database file you selected, indicating that the file is open and ready. 5. Select Personal Certificate Requests from the list. 6. Click New. The Create New Key and Certificate Request window is displayed, as shown in Figure 55. Figure 55. Create New Key and Certificate Request Window 7. Type a Key Label, such as Production Certificate for MyWeb at My Company, for the self-signed digital certificate. 8. Type a Common Name and Organization, and select a Country. For the remaining fields, either accept the default alues, or type or select new alues. 9. At the bottom of the window, type a name for the file, such as certreq.arm. 10. Click OK. A confirmation window is displayed, erifying that you hae created a request for a new digital certificate. 11. Click OK. The IBM Key Management window is displayed. The Personal Certificate Requests field shows the key label of the new digital certificate request you created. 12. Send the file to a CA to request a new digital certificate, or cut and paste the request into the request forms of the CA s Web site. Receiing a Digital Certificate After the CA sends you a new digital certificate, you need to add it to the key database from which you generated the request. To receie a digital certificate, follow these steps: Appendix C. Secure Socket Layer Introduction and ikeyman 229