Sara Peters at Information Week recently posted an article titled “SIEM Case Study: Israeli e-government ISP” In this article, Assaf Keren, information security manager at the Israeli e-government ISP Project (called “Tehila”) calls our attention to some very important details to consider when Implementing a SIEM. Keren’s advice is that a successful SIEM implementation requires:

1. Detailed planning,
2. Fastidious attention to detail,
3. Superb communication between concerned parties
4. Attentive oversight of vendor activity.
Another Key Point from Mr. Keren - don’t outsource this “theory phase.”

Note: I agree with Mr. Keren that the SIEM requirements have to be driven from within your organization. However, I believe that expert external entities can and should help drive discussions and help extract and refine requirements from your team. Obviously, the expert external entity MUST NOT be from a Vendor or reseller of any SIEM Products.

Looking back over hundreds of SIEM deployments and seeing so many consistent decisions (or indecisions) that adversely affected the success of the SIEM I felt compelled to add a bit more context to augment the lessons Mr. Keren shared.

Overview:
1. It takes a village, building planners, city inspectors, etc: Probably, the most important takeaway from this post is that you should take the necessary time to fully comprehend and vet your requirements, as well as decide on your service delivery model, gain consensus on that approach and have realistic expectations along the way. SIEM failures are more often the fault of poor planning, moving tactically while ignoring the strategic nature of the project, or simply misaligned expectations rather than a pure technology failure.

2. Know what you are going to do with the Output before you make it Input: It is tough to make sense (and therefore derive any value) out of billons of events by adding even more events to be evaluated into the mix. Intelligent Collection, Analysis, Escalation and Remediation and workflow efforts defined before you start (and refined along the way) means that you’ll have a better idea what to do with the information your presented and a much higher chance for success in both end-user usage of the system and aligning that usage of the SIEM with the needs of your organization’s security or compliance program.

3. Purchase the “right” technology, but do it incrementally: Quite candidly some SIEM products should be avoided at all costs, however it should be noted that most of them can at least be used to help you meet some very basic requirements. Consider your business and technical requirements over a 24-month period, but only purchase what is necessary to deliver based on the next 6 months of work you expect to get accomplished. The system needs to be flexible to support all of those upcoming needs, but there is no need to spend money today to support tasks you won’t even consider touching for over 12 months.

A successful SIEM tool supporting your organization’s Security and/or Compliance needs really boils down to some very simple concepts:

Define Success
Have a strategic vision about how you want your Security Operation and/or Compliance Program to run and use that to help define requirements for how the SIEM (and Log Management) tools will provide input or drive workflow related to that Program. Involve all the stakeholders early and keep them engaged along the way!

• If your rationale for buying a SIEM is PCI Compliance, STOP.

• If your rationale for investing in SIEM is to provide “x”,”y” and “z” data sets to business unit “a” and “b” and initiating workflow for your SOC; and you understand the event sources necessary/business logic to compile the data sets for each customer; and you fully understand how they intend to use that information the you are much closer to being ready to work with a SIEM.

Related Resources:
• SIEM: Basic Implementation Success Criteria
• SIEM: Before you Buy

Plan Accordingly
SIEM is not an overnight project, and yes even an Appliance-based SIEM’s require significant attention to work to their maximum potential for your organization.

• Gather requirements from all “stakeholders” Compliance, Legal, IT, Business Units, Security, Executive, everyone that will help you get information into the SIEM or receive information from the SIEM (or your service offering that leverages SIEM).

• Define Event Sources based on end-user needs: Security, IT Operations and Compliance teams all have distinct needs and therefore may require different event source information. At a minimum they may require different “views” of similar information set available in the SIEM or Log Management Tool. Ensure you have the proper information sets, logging at the right levels and the information is available in a logical and meaningful manner.

• End-User Requirements are the most valuable. The more your team understands how your “customers” value the data and service offering the more you can benefit from the functionality of the SIEM.

• Analytical and Workflow Requirements. Security Analysts need to be able to quickly identify, analyze, prioritize and escalate the data with context in order for the SIEM to meet its most basic functions. This functionality is not as common as you would think across different SIEM’s. Be sure that the SIEM integrates with your workflow systems in an acceptable fashion.

Related Resources:
• SIEM: Best Practices in Collection

Vendor Selection
Now that you have your requirements documented and prioritized compare them against SIEM: Evaluation Criteria and refine them even further…

• Either partner with an expert that can tell you exactly why certain Vendors can not meet your needs (today/tomorrow) and compare those answers a n honest discussion with the vendor or invest in a Pilot in an effort to prove out ALL of your requirements (not just the top three.)

• Make sure you have data either directly from production event sources or a reasonably similar source. If you use combined Log Management and SIEM architecture, make sure you can configure outbound events in a format the SIEM can comprehend for more than just Syslog events. If the SIEM can natively handle ODBC but your architecture requires Log Management to be the Collection Tier and forward events to the SIEM – How does the LM reformat those events and how does the SIEM handle that data?

• Customer Referrals are nice, but be careful. I’ve seen this scenario too many times. Victim asks a SIEM Reference Client about a key area of concern, say scalability and the reference client dutifully answers the questions with a resounding “Yes, the $VENDOR scales to meet my global organization’s amazing needs” in all the excitement it was overlooked that it takes 100+ systems to get there and oh yeah, by the way none of these SIEM systems can cross correlate information. As your requirements are defined, build out testing plans if the requirement is that critical and test it prior to purchasing.

• Maximize your dollar. Ensure the vendor is prepared to partner with you for the long haul, you both have a vested interest in the success of the program – make sure they are going to be there for you
• Find out the vendor’s fiscal period and plan your purchase accordingly. Fiscal Quarter end and Fiscal Year end are great times to make deals (especially enterprise deals) with vendors.
• Purchase what you need not what you want. If you don’t have a documented requirement that you can reasonably achieve in the next 6 months don’t buy it yet. Conversely, don’t skimp on things you absolutely do need. If you have a requirement to store 8 Billon events a day over a 10-year period and you expect to do that with local storage or even DAS, NAS. Stop and rethink things a bit.


Focused Effort:
Ensure that you have dedicated enough time and energy to the success of your SIEM Effort. If you are a large enterprise this is at least 2 FTE’s or an Expert Partner

Seriously, Requirements Gathering, Vendor Selection, Pilot, Implementation, Initial Operating Capability, Operational Refinements, Final Operating Capability (Formal Service Delivery), On-going Enhancements, Patches, Upgrades, Lab Testing, Additional Content Tuning, Expansion and the related Coordination, Planning, Execution, Oversight and Measurements is enough to keep an entire team busy. Doing all of that within the framework of your overall Strategic Security Program and not just tactically solving issues as the “pop-up” on a daily basis is the key to success with SIEM and ultimately your entire security and/or compliance program.

Having the wrong team or not listening to the right team is about the same as not having resources at all. Spend the time to ensure your SIEM team is baked into your Security/Compliance Program(s) so they can help you plan for today and tomorrow and save a lot of headaches in new hardware, storage or even total SIEM replacement. If your not ready to dedicate the right Resources/Partner’s then you may be better off waiting and then introducing SIEM into your organization when the requirements, proposed solution and funding are more in line.

Lifecycle Planning
This goes way beyond simple O&M tasks. SIEM is part of your overall Security Program and as such need to stay in step with that Program. Your SIEM Team (Partner) needs to be involved along the way to help ensure compatibility and/or flexibility as you evolve. Service Delivery, Technology, Business and Compliance requirement changes and/or reprioritizations can all have a significant impact on the success or failure of the overall program. The tighter the team is with the thought process around those upcoming changes the more likely your SIEM Program will meet your needs.