Recently I stumbled across an interesting article talking about Microsoft, Opensource and ITIL where ossim was being mentioned. (the article can also be found googling for "ossim itil microsoft" in case the link breaks).

I've never been very keen about learning ITIL either (although I've heard about it everywhere during the last year) but this really caught my attention. In that paper ossim gets referenced only on the "security management" section, but I think that's mainly caused by ossim being hard to install, setup and understand when that article was written, so I thought I give it another try from my point of view, taking the included tools into account for the different ITIL sections.

So, the goal of this article would be to extend and improve that other article, giving a thought about how I'd approach all those ITIL recommendations from an OSSIM point of view.

The Information Technology Infrastructure Library is comprised by two main sets and a series of subsets (from what I've read on that article and the wikipedia):

• Service Support
• Service Delivery

Note: The definitions after each topic have been quoted from the MS article since they're small and concise.

Service Support

Incident Management

The incident manager is the obvious choice for this activity from an OSSIM point of view, with a couple of details and exceptions mentioned below.

Five points are mentioned as important for incident management:

• Detect and Record an incident (the main incident manager)
• Classify (Incident types)
• Initial Support (This requires more manual intervention, although automated urls with information could be sent to the users involved in the incident)
• Investigate and Resolve (With forensics, realtime viewers, vulnerability databases and everything logged on a central location there are plenty of tools for doing this)
• Track, Monitor and Communicate (Specific metrics / dashboards could be designed for htis, also check the "Report" section at ossim.com.

Problem Management

• Problem and Error Control (Well, this is what a SIEM is used for 90% of the time, isn't it ? Linking to the root description for overview.)
• Proactive Management (Identifying problems and errors before they occur. Anomalies can be a very valuable tool for this)
• Report (Also check the "Report" section under ossim.com

Configuration Management

At first I was confused and didn't see how ossim could fit into this. The following tasks are mentioned as being important for this part. As I don't see how this fits I don't link them to any specific sites.

• Planning
• Identification
• Configuration Control
• Status Accounting
• Verification and Audit

Discover devices on a network

Determine the host OS

Determine OS version and patch levels

Determine which applications are installed

Detect any changes to the configuration

Change Management

This is an area where ossim can be greatly improved. OCS already includes some "Install software updates and configuration changes" functionality but it's not fully integrated.
The article suggests Bcfg2, cfgengine or Webmin for this. We already considered using webmin for the installer CD configuration so this would be an obvious addition.

The rest of it is covered by the Incident manager, reports, executive panels and OCS.

• Filtering Changes
• Implementing Changes
• Review and Close
• Report

Release Management

Again there are things missing for this to be fully covered by ossim. Integrating Zenoss would be an option although with tight ocs integration and some additional development this should be easily accomplished without additional dependencies. Maybe webmin too.

• Build and Configure
• Test and accept
• Schedule and Plan (The incident manager would be suitable although not perfect for this)
• Communicate and Prepare (Again we'd use the subscription feature for this)
• Distribute and Install (As mentioned earlier ocs can be used for remote software installation)

Service Delivery

Service Level Management

This on the other hand is something which is fully covered by ossim. Having implemented lots of metrics and measurements it is very easy to:

• Define SLAs, OLAs and UCs (Also executive panel metrics, service level, vulnmeter can be used for this)
• Define a service catalog (Typifying and tagging incidents)
• Status accounting (Also check the ossim.com report section for metrics)

Financial Management for IT Services

This is more of a human task than an ossim one. I guess metrics could be enforced if the data related to all of this is stored somewhere but I'd need to investigate it some more.

Capacity Management

This is a very interesting expertise area, where some parts are covered by ossim and others not so much. The article mentions Zenoss and Hyperic HQ as tools that meet the needs for this, and I guess ossim as is also meets many of the needs:

• Monitoring (Including trends and forecasting due to heavy RRD usage: Nagios, Ntop, ocs, etc...)
• Analysis (Most of ossim can be used for this)
• Demand Management (Most of ossim can be used for this)
• Modeling (Policy establishes a baseline and anomalies provide information on how this has changed over time)
• Planning (Most of ossim can be used for this)

Availability Management

This obviously is fully covered by monitors and executive panels with metrics:

• Define requiremens (This involves policy, executive panel metrics, business processes, check the main descriptions)
• Availability Planning (Nagios, Ntop, OCS, etc...)
• Monitor Availability (Nagios, Ntop, OCS, etc...)
• Monitor obligations (This involves policy, executive panel metrics, business processes, check the main descriptions)

IT Service Continuity Management

This is also a very manual and off-ossim task, some parts could help for this (monitoring, sla's, etc...)

Security Management

This is were the article mentions ossim, although not fully extending on what can be covered using ossim. Four main tasks are required for this:

• Coordinate Security Management (Using the incident manager)
• Implement Controls (This is covered by most of ossim)
• Evaluate and Audit Controls (Also this)
• Maintain and Monitor (Using the incident manager, executive panels, reports)

Conclusion

This article is more of an exercise of what could be done rather than a step by step guide on how to implement it. Obviously that step-by-step guide is now on my todo list but that requires much more than the couple of hours I've spent writing this up.

Anyway, I hope this article gave a quick overview of how ossim can be applied to ITIL.

Remember the graph at the top and the numbers ? Let's resume where each task would fit in ossim.

1. The new incident creates a log read by the agent, a response is issued by policy and a new incident inserted.
2. Using the incident manager we tag and typify the incident.
3. Next we analyze events, alarms, monitors and reports checking what could be wrong. We notice the service level and metrics at executive panel decreasing.
4. Through the incident manager we subscribe the people who can fix the issue to the incident, and describe needed actions in order to fix them.
5. Another executive panel reflects to the customer what the current issue means to their business in terms of money.
6. Again we track everything using the incident manager and issue a patch rollout using OCS's automatic soft installation feature.
7. We change our inventory information based on the new automatic changes and keep track of them using the incident manager. The anomalies panel gets automatically updated once the new versions get detected.
8. Nagios will reflect the downtime and affect the overall service level due to this issue.
9. Policy, executive panels and directives get updated if needed after this new situation.
10. The closed incident gets reported to the customer and will show up on incident reports.