How to Audit Tivoli Identity Manager with Tivoli Compliance Insight Manager
[This article is sponsored by Peningo Systems, Inc., a provider of Tivoli Consulting Services on a nationwide basis. For more information on Peningo Systems, please go to the Peningo Tivoli Consultants page. ]
The IBM DeveloperWorks site is an excellent repository of information and resources regarding various IBM offerings and systems. IBM has IBM recently published an article on the IBM DeveloperWorks site regarding the importance and how to faclitate an Audit of Tivioli Identity Manager with the Tivoli Compliance Insight Manager.
The following is the article from IBM. We recommend this article to any Tivoli Identity Manager Consultant ot IT Security Consultant who is considering perorming an Audit of the provisioning that is done by the IBM Tivioli Identity Manager:
IBM Tivoli Identity Manager (TIM), being a provisioning platform, manages provisioning to various target applications. Hence, it becomes all important to audit the provisioning done from the TIM system. Tivoli Compliance Insight Manager (TCIM) allows us to monitor the usage of administrative rights, which is important to identify any breach in security rights or violations of any security policy in an organization.
The auditing and reporting of the TIM logs is done using the W7 Model from within TCIM.
TCIM applies the policy and attention rules to load the audit data into the GEM database whenever data is processed i.e., loaded into the reporting database.
W7 model
The audit data, from event sources such as TIM, is normalized into the w7 language and stored in the Generic Event Model (GEM) database.
Following are the W7 attributes into which all the data is normalized.
- Who Which user, application, or process initiated the event?
- What What type of action does the event represent?
- When When did the event happen?
- onWhat What object was affected? An object could be any type of file, database, application, permissions, etc., that was manipulated by the event.
- Where On which machine did the event happen?
- WhereFrom Which system is the source of the event?
- WhereTo Which system is the target of the event?
TCIM databases are based on the Generic Event Model(GEM) and is used to store the audit data collected by the actuator.
TCIM loads the audit data that is collected by the Actuator, into these databases.
The audit data is normalized into seven parts representing the W7 audit model and then the normalized data is loaded in to the GEM database.
Tivoli Compliance Insight Manager policy
The primary goal of TCIM is to monitor security compliance. To achieve this, the corporate security policy is translated into rules that form the TCIM Policy. The security policy defines the compliance to the Company's IT security rules and can be based on well known industry standards like ISO27001, Sarbanes-Oxley, PCI, Basel II, HIPAA and GLBA.
The policy consists of:
- W7 groups which are queries used to determine the W7 categorization of an event.
- Policy rules are a combination of W7 elements that describe allowed behavior.
- Attention rules are a combination of W7 elements which identifies events that require special attention.
Figure 1. Architecture
Figure 1 shows the TCIM architecture.
The primary functions of TCIM are the collection of logs, archiving and preparation of data for reporting.
The actuator consists of an agent and numerous actuator scripts.
- The agent is responsible for maintaining a secure link with the agents running on the TCIM server and other audited systems.
- The actuator scripts are invoked by the agent to collect the log for a particular event source.
Point of presence is the server where the actuator is installed.
The collection of logs, also called as audit trials can be done two different ways
1. Local
2. Remote
Local The point of presence that collects the logs resides on the local machine. This could be the target machine or the audited machine.
Target machine: The target machine is not always the audited machine. This could be a machine from where the Tivoli Compliance Manager has access to the audit data.
Audited machine: The audit trails or logs are collected from this machine. It is on this machine where the events occur. Here TIM system is the Audited System.
Remote The purpose of remote event source is to audit a system that does not have a point of presence installed.
The collection of logs can be designed in one of the following configurations
- Configuration 1. TIM on one machine with TCIM server acting as point of presence.
- Configuration 2. TIM system and point of presence on same machine and TCIM server on separate machine.
- Configuration 3. TIM, point of presence and TCIM server on separate machines.
Figure 2 shows the configurations.
Figure 2. Configurations
The event sources support auditing of TIM system running on IBM AIX®, Sun Solaris and Microsoft® Windows®.
The point of presence is always a Windows server in all the configurations and the audited system could be either Unix or Windows based systems.
Enable Tivoli Identity Manager auditing
The first step for auditing a TIM System is to enable auditing on the server. To enable auditing set the "itim.auditing" property to true in the 'enroleAuditing.properties' file. The path to the 'enrole.Auditing.properties' file is <itim_home>\data. For example, in AIX the file is in /opt/IBM/itim/data directory. Apart from enabling auditing the file, it also allows you to set the itim.auditing.retrycount (number of times auditing will be retried in case of failure and itim.auditing.retrydelay(wait time before each retry). Also, it allows setting the auditing property for particular event category like ACIManagement, Authentication, etc., to true in case you want to turn ON the auditing for that category.
The TIM GEM database is used to store the audit data.
To create a GEM database called TIM, that will be used to store the TIM audit data, open the TCIM management console and click on "database-> Add GEM Database".
Figure 3 shows the 'Add GEM Database' window.
Figure 3. Add GEM database
At the next screen, provide the name and size of the database to be created. Here we name it as 'TIM', the name with which it will appear on the management console and size as 10 MB.
The GEM databases can grow as needed and the size of these databases range from 10 MB to 32 GB. The maximum size of a database is 32 GB.
Figure 4 shows the GEM database parameters defined.
Figure 4. GEM database parameters
The 'TIM' GEM database is created on clicking "OK" and is shown in the management console.
Figure 5 shows the newly created GEM database in the management console.
Figure 5. TIM GEM database
The security policy is applied every time an event data is processed i.e., when collected data is loaded into a reporting database.
While creating a security policy you could follow the model given in Figure 6.
Figure 6. Security policy creation model
The first step involved in creating the TCIM Policy is to transform the company's security rule into w7 classifications, identifying all entities of the w7 model.
Once the rule is translated into W7 groups, check the TIM audit trail to match the w7 grouping. Drop the rules that do not match and incorporate all other rules in the security policy. Once all the rules have been processed and added or dropped, the TCIM security policy is ready for use. For example, if the security policy says "All administrators should use their own id to log on to the TIM system and should not use the TIM administrator account." Using this statement we could create security rules.
- Administrators(Privileged Users) should use their own id to log on to TIM System is a requirement and forms the policy rules.
- Any Login with TIM Administrator (TIM Manager) account is a restriction and forms Attention rules.
Before we create policy rule, we will first create groups to categorize all logon events. To create a new group, go to the policy explorer, right click on last committed policy and select duplicate. Name the policy as 'TIMAudit'.
Figure 7 shows the newly created TCIM policy in the policy explorer window.
Figure 7. TIMAudit policy
In the policy panel, expand the itim group and double click the "itim_group" grouping file.
Figure 8 shows the 'itim_group' in the policy explorer window.
Figure 8. itim_group
Right click the 'who' folder, select New Group and enter 'TIM Administrators' for group name with significance 90. Click "OK" to add the group.
Now right click the 'TIM Administrators' group and select New Requirement. Here give "Logon name is TIM MANAGER" . Similarly add TIM Users group with requirement 'not in group TIM Administrators'. The 'TIM Administrators' group is used to categorize logon events of "TIM Manager" account and 'TIM Users' group to categorize logon events of all other account that does not belong to the 'TIM Administrators' group.
Figure 9 shows the 'Group Definition' window.
Figure 9. Group definition window
Once the group definitions are added, we create a policy rule for logon events. All logon events of users in 'TIM Users' group are acceptable events.
To add a policy rule, right click on Policy tab and select New Rule.
Figure 10 shows the 'New Rule' window.
Figure 10. New rule window
On clicking 'New Rule' the 'Edit Rule' window opens. Enter 'TIM Users' in the Who field and 'Logon' in 'what' field to signify that all logon events of TIM Users is acceptable.
Figure 11 shows the parameters for the policy rule defined as per the policy.
Figure 11. Policy rule parameters
To create an Attention rule, click on 'Attention' Tab and right click to select New Rule.
This will open the 'Edit Rule' for Attention rules. Enter 'TIM Administrators' in the 'who' field and 'Logon' in 'what' field to signify that all logon events of accounts belonging to 'TIM Administrators' group requires special attention. Here all logon by the "TIM Manager" account will be treated as special attention events.
Figure 12 shows the parameters for the attention rule defined as per the policy.
Figure 12. Attention rule parameters
Save the rule and exit the policy after saving the group definition set, and saving the changes to the Policy and Attention Rules for TIMAudit Policy.
|
Once auditing is enabled in the TIM System, the next step is to add the target machine to the Tivoli Compliance Manager Server. On the add machine wizard, first select the audited machine type. The audited machine type could be one of the supported operating systems, AIX, Solaris or Windows.
Figure 13 shows the 'Choose Audit Machine Type' window.
Figure 13. Choose audit machine type
In the next screen, select or add the machines on which you want to audit. This is essentially the Hostname or IP address of the audited machine. You can also select the machines through a network browse by clicking on the Network Browse selection box.
Figure 14 shows the 'Choose Audited Machine' window.
Figure 14. Choose audited machine
The next step involves the selection of the point of presence. The point of presence is always a Windows server and could do a remote or local collection of the logs.
The Remote point of presence could be any of the following:
1. The TCIM server
2. Point of presence existing on some other machine
3. We could install a new actuator
The local point of presence is the point of presence that is installed on the audited machine itself.
Figure 15 shows the 'Select Point of Presence' window.
As the TIM audit records are stored in the databases, we require ODBC drivers installed on the Windows server and should also have supported ODBC drivers installed.
Figure 15. Select point of presence
Once the add machine wizard completes, the next step is to choose the event source type. Select TIM event source from the list of available event sources.
Figure 16 shows the 'Choose Event Source Type' window.
Figure 16. Choose event source type
On successful addition of the audited and target machines, we move forward to define the properties of the event source.
For defining the event source properties, the database DSN has to be first defined.
To define the database DSN, go to Windows "Administrative Tools" and click on 'data Sources' to create new data source in SystemDSN.
Figure 17 shows the 'Create New Data Source' window.
Figure 17. Create new data source
Since IBM DB2® is the database used for TIM, we define the IBM DB2 ODBC driver. Configure the data source by setting the data source name, user ID/password as shown in Figure 18.
The audit logs of the TIM server are stored in the database tables namely AUDIT_EVENT, AUDIT_MGMT_TARGET, AUDIT_MGMT_DELEGATE, AUDIT_MGMT_PROVISIONING. The user account must have the create view privilege and read permissions for these tables.
Figure 18. ODBC datasource settings
Once data source is configured, move on to the TCP/IP settings. Define the database name, database alias, hostname/IP address where the database resides, and the port number to connect to the database.
Figure 19 shows the 'TCP/IP settings' defined.
Figure 19. TCP/IP settings
Once the data source name is successfully configured, move ahead to add the event source. We define the properties of the event source using the add event source wizard. Here configure the database DSN (which was defined earlier) and the user name/ password that is used to connect to the database.
Figure 20 shows the 'Event Source Properties' defined for the TIM event source.
Figure 20. Event source properties
Next select the database in which the audit logs will be loaded and the collection schedule for collecting the logs from the Event Source i.e., the TIM.
Figure 21 shows the 'Choose a GEM Database' window.
Figure 21. Choose a GEM database
Once the machine and event source are added to the TCIM server, the TIM server is ready to be audited. The data is collected and loaded to the server as per the schedules. For adhoc collection and loading of data, right click on the database where TIM Server logs are to be loaded and click on Load from the menu.
Choose the period between which the data should be collected and loaded and move on to the next screen where you have to select whether to collect the data before loading or just load the data for analysis from the previous collections.
At this screen select the 'Collect the latest data for the associated event sources before loading data from the requested period into the database'. This ensures that all new data that is not collected already, is first collected and then loaded in to the database.
Figure 22 shows the 'Load Database' window.
Figure 22. Load database
At the 'Choose a Policy' select 'TIMAudit' as the policy to be applied to the data that is to be loaded into the database, and start the collection and loading of the data from the TIM Server. 'TIMAudit' is the policy that we created earlier.
Figure 23 shows the 'Choose a Policy' window.
Figure 23. Choose a policy
Once the collection is completed, the data is loaded into the database according to the policy.
The audited results from the TIM Server can be analyzed and viewed at the iView console. Login to the Web portal and click on iView console. Click on the TIM database icon at the bottom of the iView main screen to open the summary view.
Figure 24 shows the iView console.
Figure 24. iView console
Next, click on the TIM database icon in the iView console. This opens up the summary view of the events. Figure 25 shows the summary view of all the events associated with the TIM database.
Figure 25. Summary view
You can see that the screen shows the two groups we had created earlier, and summarizes all the events from users of both these groups. All other events are classified as Unknown. Also, the event detail shows special attention for events that require attention, which was earlier defined in the security policy.
Figure 26 shows the event detail for a particular event. The event is a special attention event and is an exception to the policy rules set in the TCIM policy.
Figure 26. Event detail
|
The audited results can be used to generate reports that can be used for various purposes. For example, we will create a custom report called 'Logon by TIM Manager'. We will configure this report to shown all Logon events.
To Create reports on the event sources go to the 'Reports' Tab and click on "Add custom report" button as shown in Figure 27.
Figure 27. Add custom report
This will open up the report editor. At the general information section, add title as TIM Manager Logon Events. Choose standard report center for report center and name it as custom report examples as shown in Figure 28.
Figure 28. Report editor general information
At the report layout section, there are four types of reports available.
- Event List- Detailed report showing events in simple list format.
- Summary Report- Summary report showing events, exceptions, attentions and failures per group.
- Top N Report- Summary report showing user defined number of events in a specified time period. It displays top N(number of) rows of the report.
- Threshhold Report- Summary report showing events that happened more than a user-defined number of times.
At this section we select the 'Report Type' as shown in Figure 29.
Figure 29. Report type
After defining the report layout, we specify the criteria that will be searched in the GEM database to generate the report.
The criteria available are events, policy exceptions, special attention events, Failures, and successes. Selecting any of these means selecting events that fulfill these criteria. For example: selecting 'Special Attention Events' means we are selection only GEM events that are labeled 'Special Attention Events' by policy.
At this point, we select events and move on to specify the conditions. The conditions are defined to find events that satisfy the condition set.
For example: To select all events generated by "TIM Manager", we give condition as The value of field Who group is equal to "TIM Administrators".
Figure 30 shows the field values defined for the above condition.
Figure 30. Report conditions
Next, save the report and execute it. On execution, we generate a report of all logon events by TIM Manager.
Figure 31 shows a sample report showing all events by "TIM Manager"
Figure 31. Sample report
Again, we could refine the condition to show all TIM Manager Logon events that were successful. To accomplish this, you could edit the report and add one more condition. The value of field What detail is equal to "Authenticate : Priviligeduser/Success" as shown in Figure 32.
Figure 32. Report conditions
On execution, we generate a report of all successful logon events of "TIM Manager" user as shown in Figure 33.
Figure 33. Sample report
|
TCIM helps to provide comprehensive log management and user access monitoring for enterprises. It helps to monitor, audit and report on the logs that have been collected from different systems. The reports generated from TCIM have the ability to report on the current compliance status of security controls of any installed system. The TCIM reports can help risk officers and auditors to view any anomalies within the IT environment. It helps ensure that security, regulatory, and operational policies of a company are followed. Using TCIM, this article demonstrates the auditing of TIM System.
Should you wish to go to the IBM DeveloperWorks Site to view this article, click here to view the article.
If you are an "End Client" looking for Consulting Service providers to support your WebSphere Applications, Peningo Systems provides Consultants with expertise in many areas including:
- WebSphere Portal
- Tivoli Consultants
- WebSphere Commerce
- WebSphere Eclipse Development
- Websphere MQ
- System Security Architecture
- Tivoli Access Manager
- Tivoli Identity Manager
- DB2 – UDB,
- SAP,
- Remedy
- Peregrine / HP Openview AssetCenter and ServiceCenter
- J2EE based systems architecture and development.
To see Peningo Systems areas of expertise, please go to the Peningo Technical Areas page or go to the Peningo Tivoli Consultants page.