SIEM Best Practices:  Before you buy.

Knowledge of your Enterprise:  This is the single most important factor to a successful SIEM deployment.  IMHO, you simply cannot have a successfully deployed SIEM product without significant knowledge of your environment.  Here is some of my rationale on this subject.  As awesome as correlation can be (and it can be phenomenal) correlation can’t overcome lack of context.  Correlation Rules work best and more efficiently if you can provide them with boundary conditions.  The more focus and context you provide the more specific the results will be and the more automated your responses can be (in a word – efficiency). 

Most anyone who has spent the time to hunt down this humble little blog post knows of Richard Bejtlich.  In my mind, Richard is one of the most amazing minds in information security.  If you haven’t read his books/blog please take the time and do so!  Anyway… back to the topic….  In a recent blog post based on some recent conferences he attended, Richard boils down a few SIEM best practices into a few simple statements.
1. “Deploying a SIM requires understanding your network to begin with. You can’t deploy a SIM and expect to use it to learn how your network works.”
2. “You can’t use a SIM to reduce security staffing. Your staffing requirements will definitely increase once you begin to discover suspicious and malicious activity.”
3. “You can’t expect tier one analysts to be sufficient once a SIM is deployed. They still need to escalate to tier two and three analysts.”

As I also attended/facilitated this discussion with the Institute of Applied Network Security Forum in Feb I wanted to take this opportunity to provide some context to these statements from my personal perspective.

Knowledge of your Enterprise:  This is the single most important factor to a successful SIEM deployment.  IMHO, you simply cannot have a successfully deployed SIEM product without significant knowledge of your environment.  Here is some of my rationale on this subject.  As awesome as correlation can be (and it can be phenomenal) correlation can’t overcome lack of context.  Correlation Rules work best and more efficiently if you can provide them with boundary conditions.  The more focus and context you provide the more specific the results will be and the more automated your responses can be (in a word – efficiency). 

In the real world what you get is the best effort of the security and/or project teams (not necessarily in coordination with one another) to lump in data to the SIEM.  – Sometimes a “casserole surprise” works – and other times, well… there’s always Pizza.

Some Additional Best Practice Recommendations with regards to SIEM:

1. Understand what your requirements are for a SIEM product before you purchase and/or begin your implementation project.  Log Management/Log Search and SIEM are certainly close relatives in certain aspects of their functionality but you must understand your needs before jumping into this water. A multi-million dollar mistake (Product, Hardware, Software, Consultants, Internal Team, etc for a large global enterprise deployment) can be slightly career limiting.

Note:  If you are a Fortune 500 Organization – Consider what it would take to align your IT Security vision to across business units to leverage resources and funding to make this investment work for everyone.  Many organizations I’ve seen over the past year are considering a similar model where one business unit acts as the Enterprise-wide Security Operations Center. 

2. The Vendor does not know your business, how could they possibly know your business – wouldn’t they then be your partner or a competitor????  The vendor knows their product and they know some of the issues you face with regards to Compliance, Regulatory concerns and general Information Security.  Your team needs to be the driving force for requirements of the SIEM and then eventual implementation of the SIEM product.  The SIEM product should be well constructed and intuitive to the point where you should be able to mold it around your business requirements and not the other way around.  If you find yourself asking the vendor for suggestions – refer to suggestion #4 below.

3. Focus Internal Resources in the right areas:  I see organizations spending months of effort on designing architecture documentation on how the SIEM will talk to Source Devices, attempting to measuring assumed network bandwidth, projecting storage requirements and obtaining hardware – all before they decide what data is valuable to them.  Rather than taking traditional sources (IDS/FW/VPN/OS/etc) as the “Gospel” look at your IT environment, your business’s use of IT and the direction of your organization and decide what event sources might offer more value.  For example:  Web Proxy may offer more context and value than Firewall in certain organizations.  If storage costs are a limiting factor – spend the time to figure out what information is going to suit the needs of your information security program better.  I’d rather you spend your time aligning asset management, data classification and prioritizing event sources and correlation scenarios than buying hardware/storage and planning against imaginary data sets.

4. Hire Experts:  The vendors have great resources and you should considering using their services, but there are alternatives available that might be able to help you on a larger scale than just the best possible solution around their product(s).  You have different needs of the products based on your intended usage of the SIEM and your overall environment.  One-size may fit all but the extra cloth may become cumbersome…

Stay tuned there is a lot more to come on SIEM and Log Management!