More SIEM Vendor Leap Frog

Network World's recent article provides additional evidence that Log Management and SIEM Vendors are still trying to evolve.

Dominique Levin (EVP of Strategy/Marketing at Log Logic writes in this Network World article posted last night (03/19/2009) about the development and convergence of SIEM and Log Management. I'm glad that Log Logic finally understands the model and is trying to address a broader market opportunity by incorporating SIEM into their offering. If you didn't already know, last month Log Logic partnered with ExaProtect to be able to provide a more native (to Log Logic) SIEM solution. As a side note, it has been my experience that you can make other SIEM's work in conjunction with Log Logic (at least in an unidirectional manner) by forwarding events to a SIEM from the Log Management platform. I hope that Log Logic (and other vendors) continue to read my SIEM Vendor Leap Frog post and take some of the challenges in current technologies to heart. Bi-directional search between Log Management and SIEM, shared user authorization and authentication techniques, more robust shared management options - all of which really need to evolve from these types of offerings. I hope they and the other vendors look at this as an opportunity to truly merge the products into a solution versus the current "bolt-on" approach some in the market have taken. It is not enough to just have the technology available, the vendors must understand how the customers will use this in the field and make it more simple to deploy, manage and ultimately actually use these products. ArcSight, RSA and other key players are working on this very diligently and have made great strides to making this vision a reality. It's still nowhere near perfect but I think it will get much more emphasis over the next 12-18 months or so as more people demand better integrated solutions during their acquisition or renewal cycles.

Another side note: At the recent IANS DC forum and again at SOURCE Boston Peter Kuper noted that security vendors are going to have to make more of an effort to partner with their customers to really thrive in this market. Peter also made the point that customers have to demand more value from their vendors in order to show value to their own management. I think everyone should take that message to heart!

The information presented in the Network World article further validates some of the positions I presented in my SIEM Vendor Leap Frog post earlier this week. For that matter so does a recent "tweet" from NitroSecurity (Twitter: @nitrosecurity) as well as, a "tweet" from RSA's SIEM Solutions Evangelist Paul Stamp (Twitter: @tknsecurityguy) and a recent post Paul Stamp in his personal blog.

The idea of combining Log Management and SIEM isn't novel (in fact it is several years old) but only recently has it become the "standard" for gaining "Enterprise Visibility" and then moving towards making security operations work more fluidly through the use of a SIEM. The combining of Log Management and SIEM is not trivial to accomplish but can be done quite well and adds huge value, if architected correctly.

The article explains the evolution of SIEM through the years, beginning with Perimeter Security "Use-Cases", moving through certain "Internal Monitoring" Use-cases and then describes how SIEM gained critical mass through "Compliance" Use-Cases. I will not debate the relevance of SIEM in each of these situations other than to say - Both the Log Management and SIEM's product sets are nothing more than tools. They can be a powerful resource in the right hands and have a great many potential applications, but the team wielding that power has to know how to apply it and when (and when not to). While it is true that some SIEM platforms are flexible enough to move beyond simple network security based use-cases, the complexity involved in making those transitions requires expert touch. Let's get these systems working correctly in security first then we can think about expansion into other areas (business intelligence, etc). There is no magic fairy dust here. It is hard work at each and every step, but there is a payoff. You can automate many labor intensive tasks including identification and escalation of alerts, which should free up some analytical cycles to find new and more complex activities that they can turn into "events of interest" for future correlation. BTW I didn't mean to dismiss the value of Log Management and SIEM outside the context of Security - it is possible (it requires great flexibility in the vendor solution but I know many organizations that have made interesting solutions work in very unique ways) I'm simply saying there is a lot more work we can do to get the actual security focused portion of these solutions to work better before we try and show value (and over exert our reach/resources) in other areas.

Let's keep working together to encourage the right partnership and evolution from our vendors! They are doing the best they can, but it is up to the community at large to focus them in the right direction.

Combined Log Management and SIEM Architecture Benefits

The following notional diagram provides some basic recommendations to consider when deploying and managing Log Management and SIEM systems together.

A well-maintained Log Management and SIEM deployment can significantly reduce the time to Incident Identification and really enhance your overall information security capability. The diagram attempts to illustrate that all information from the Event Sources are processed through the appropriate Log Collection Mechanism and then forwarded to the Log Management System.

The Log Management system eats, stores and can regurgitate everything put into it. The Log Management Solution also can further refine the data set and forward only applicable events for analysis to the correlation engine (SIEM) through the use of intelligent “tagging” of events.

Overall data reduction is only part of the end goal, more importantly we want to ensure the right data is forwarded and evaluated so that we can gain from the overall efficiencies offered by the SIEM. In short we’re ensuring the system has the correct information available to it so that it can respond to the questions you want to ask of it and reduce the garbage as much as possible.



This post is a mirror of my post at http://blog.decurity.com
SIEM Best Practices: Combined Log Management and SIEM Architecture Benefits

SIEM Best Practices: Evaluation Criteria

SIEM Best Practices: Evaluation Criteria


Decurity often has the opportunity to our customers find the right Log Management and/or SIEM solution. We are honored that our customers trust us with that very important question so we wanted to take a moment and explain our requirements gathering/documentation process for vendor selection and hope that our explanation helps a few of more folks out there! We also get asked by Vendors on how they can improve their products, but that’s a entirely different blog post.

In March of 2008 I authored a couple of posts related to SIEM pre-requisites:

SIEM Best Practices: Very Basic SIEM Implementation Success Criteria and
SIEM Best Practices: Before you buy.

In those posts I tried to create a baseline of information customers looking to purchase and implement a SIEM solution should have before engaging the vendors. The point of those posts really boiled down to this idea: You must have a strong set requirements defined up front for the vendors to indicate how they meet that requirement. Allowing the vendors to "work their magic" and define your problems is roughly equivalent to handing them a blank check. Along those lines I wanted to highlight a strategy we employ when helping company’s to define their SIEM requirements by presenting a sample of the categories of questions we ask of the customer and the vendors during evaluation process.



A couple of quick notes before we begin with the listings:
1.) All of this assumes you’ve answered the initial “Key Problems we are trying to solve” question and the answer is something more tangible than to meet PCI,SOX, Audit requirements.
1a.) If events per second (EPS) is your key measurement you are looking at the wrong product set - seek out Log Management Tools first.
2.) It is also important to note that when we perform the evaluation each of these stated technical requirement categories breaks down into a dozen or more actual testing criteria that is prioritized according to your requirements The "Sample Questions" presented are only a very quick overview of the types of questions that fall into that category.
3.) This post is simply highlighting the fact that significant thought should be given to this decision. Don’t worry if you need help – we’re here.


Sample Categories of Requirements to consider:
Common Requirement Categories
Category (Sample Questions)
Access Control (Application, User, flexibility, inherited controls, etc)
Authentication (LDAP, SSO, AD, Internal, other)
Architecture (Reliable and Scalable)
Event Sources (Supported Technologies and versions, Connection Methods for each, Data Parsing Errors, Normalization Data Loss, Categorization Correctness, Structured/Unstructured Data Handling)
Log Management (Is the Integration Bi-Directional, easy to implement, etc)
Event Forwarding (Security, Methods, Low-Bandwidth options, etc)
Overall Security (System and the data)
External Integrations: (Tool Integration, Ticketing System Integrations, etc)
Storage Requirements (Compression, Costs, Management)
Storage Flexibility (NAS, SAN, Internal, Offline/Online, Tiered Storage)
Data Processing (Internally how does the system handle new event sources with uncommon field requirements "unstructured data")
Installation (Does the solution match our standards?)
Patching and Upgrade (Level of effort required for Minor and Major Versions)
Overall User Experience (Can I see what is important quickly and easily? Can I drill down quickly and intuitively?)
Standard Reporting (Easy, Flexible, Exportable)


Advanced Usage Requirement Categories
Category (Sample Questions)
Basic Alerting Criteria (Pattern Matching or Aggregation/Counting)
Basic Correlation (IF ,THEN, ELSE, AND, NOT, OR type Statements)
Advanced Correlation (Meta Analysis of enriched and/or raw data across technologies, time and result sets in real time.)
Statistical Analysis (Flexible event statistics that can be used in alerting or to enrich data sets for correlation)
Custom Reporting (Can I create my favorite report or extend it)
Data Mining (Can I easily look for patterns across the entire DB?)
Data Visualization (Can data viz be integrated and does it matter for me?)
Vulnerability Integration (Is the correlation useful for our environment and is the reporting useful?)
Network Modeling (How hard is to model our environment and what value is lost/gained?)
Asset Modeling (Can I easily assign systems to relevant categories and assign priorities, can I update them easily, etc)
User/Activity Modeling (Can we realistically “profile” users or activities and alert on deviations?)
External Threat Feeds (Does the vendor or a partner provide daily updates for Hotlists?)
Built in Mgmt Tools (Does the vendor provide a way of measuring the health of the system?)


Other Important Criterion
Category (Sample Questions)
Company Performance (This is becoming more and more a key decision factor.)
Support (What can I escalate, response times, expertise, RMA)
Thought Leadership (What is the vision for the technology?)
Training (Do I need 4 weeks of training to use the product? If so how many types of training opportunities are available?)
Services Support (Do I need 12 weeks of Services? How can I guarantee I don’t get the new guy? Is the team compensated on billability or Customer Success?)
Content Updates (How often can I receive content updates? Do I need constant "workshops" to move forward, Are there external providers that can help?)
Licensing Model (Price can be greatly affected by various pricing models, make sure you understand the total cost of all phases of your deployment before you begin).

This post is a mirror of my personal post on http://blog.decurity.com
http://blog.decurity.com/index.php/dec_template/more/siem_best_practices_evaluation_criteria/

SIEM Best Practices: Are you ready for correlation?

SIEM Best Practices: Are you ready for Correlation?

This post is a follow up to my previous posts related to SIEM Best Practices: “SIEM: Before you buy” , “SIEM: basic correlation and default content” and ”SIEM: Basic Success Criteria”. It is my hope that this information provides you with valuable insight into the best possible approaches for Log Management, Security Information, and Event Management and Security Operations for your organization.

Many organizations try their best to leverage Security Information and Event Management (SIEM or SIM) solutions in an attempt to drive a more proactive stance in monitoring their networks and/or systems for malicious traffic and alerting on intrusions. Unfortunately, there are many examples in which a company's expectations of what these solutions provide did not necessarily deliver the results as originally expected. Here are some reasons for this mismatch in expectations. Many other reasons exist; these are just two easy examples:

1) For various reasons, it seems that Event Correlation Projects begin with a focus on the SIEM technology, as opposed to starting with the actual business needs. The SIEM vendors understand the general problem sets and their technology attempts to solve that problem much more efficiently than most customers who do not understand their own requirements. This creates an unbalanced environment before you even enter negotiations. During the sales cycle, there may be a "bake-off" or other vendor selection criteria that the customer goes through, but the actual requirements are not all that well understood. They may be too far in the future to add value or perhaps the vendor is too skilled at answering the question with flash and dazzle that the customer overlooks the real work that may be required in order to get to the solution in their production environment. The SIEM is one of many tools that can enhance your information security capabilities, but it is not the "silver bullet," nor is it simple and easy. The implications of a SIEM deployment need to be fully vetted well before you consider a purchase of one of these products. The clearer you are on your use of the system, the clearer the vendor capabilities become, and the easier it is to pick the right vendor(s) for your environment.
2) In other cases, the SIEM and/or Log Management purchase is driven by a compliance or governance activity versus being aligned with an overall enterprise approach to information security. This focus creates an environment where the customer fails to fully consider the end use of the data and therefore is not able to realize the most cost effective solution to meeting their requirements.

NOTE: If your first set of questions to the SIEM vendor is related to "Speeds and Feeds," you are having the wrong conversation. Stop now. Read carefully – if what I am describing still doesn't make sense call us now before buying your SIEM, and we'll explain it further.

The recommended approach: Identify Critical systems, Users, Customers and Event Sources
1) Identify the key sources of information, the key regulatory requirements, and the associated business-risk driven priorities. Classify the applications and map the associated business requirements/criticality.
2) Understand who is consuming the information being generated by the SIEM. Know how they will use this information and what problem it solves. (What is the value?)
3) Understand your SIEM users, the Incident Response, IT Infrastructure, Management, and Security Operations Teams. They may all have different, but critical, use-cases for the SIEM.

Log Management:
Develop and execute on a log consolidation and management program. Consider the following when planning an implementation of a Log Management solution.

Key Log Management Questions:
• What are the key event sources you can start with in phase one? What solutions can you deliver with this information based on your consumers needs?
• What information can you obtain (and deal with in a reasonable fashion) in phases two, three, and four?
The Benefits:
• You are in a better position to realize your organization's overall requirements
• Improve the processes for log review/analysis
• Increase your Incident Response effectiveness
• Immediately add value to audit and regulatory compliance efforts.

Identify and Consoidate Event Sources
The identification and consolidation of event sources (Log Management) will add significant value to the implementation of an event log correlation project.
The Benefits:
• The tools do what they are best at and you receive as much value as possible. The SIEM can focus on correlation and workflow, while the log management tool can focus on eating as much data as you can throw at it.
• Much of the hard work of obtaining the data is already accomplished by the log management tool.
• Storage costs are greatly reduced (bandwidth and hardware requirements are also highly likely to be significantly reduced)
• Technical architecture is more easily defined based on log management. The event sources are known as the events rates and the "value" of data being processed.
• You save time, energy, and money. Things get done right the first time, in the most efficient manner possible, without wasting time/resources/licensing.

Define use-cases for the information.
In order to deliver a solution based on the “use-case” you need to know as much as possible, including but not limited to:
• What event sources are required to provide context to the analyst and/or end-user?
• What log level is required for each event source?
• What asset information is required?
• What business context is required?
• You will need to understand standard traffic patterns to reduce false positives. This means you will need to understand the network/system/application/user and not just IDS events.
• You will know what you want to do with the output of the correlated scenario (is it informational only, reporting, alerting, etc?).
• What is the workflow from cradle to grave for the information being generated?
• How do I (and when do I) present information to the consumer, management, auditor, etc.?
The Benefits:
• You are now ready to start considering a SIEM. You will begin to show the real value of correlation for your environment for each defined use-case.
• You will save time and money on hardware, storage, processing, licensing, etc versus just buying the SIEM and figuring it out later.

Comments on the Technologies:
Log Management: In most cases, this technology should probably be considered a commodity: they collect logs, store them, and provide some sort of reporting functionality. Some do it better and faster and play well with others. While looking for differentiators in log management solutions, consider the event sources that go beyond the norm. What you incorporate into log management system in phase one may be simple, but phase four may reach way beyond the product's ability to provide value (ie: data may not be accessible in a meaningful manner). Look towards tools that can deal with new data with a minimum of parsing/coding/mapping and that can deal with both structured and unstructured data sets. Look for tools that can forward events to SIEM (if your requirements dictate the need for SIEM) in an efficient manner. This means they should be able to forward any subset of events that your requirements dictate in a flexible manner (not solely based on syslog priority or vendor defined category).
Here are some basic requirements the Log Management tools must be able to support:
• Handle current event sources, (the identified phase one event sources), in your environment.
• Handle any event source using common reporting methods (SNMP, SYSLOG, FILE READER, ODBC/JDBC, WMI, API/SDK)
• Parse data or display data in a meaningful way to the user/tools – not lumped into a blob. The data should be searchable by any field in the data.
• The system should provide meaningful reports on the data in the system
• You should be able to search across all, some, or one of the log management devices in your environment based on the use-case.
• Advanced User ACL's (you should be able to restrict functionality of the system and access to data by user/groups)
• You should be able to define a complex set of criteria and forward that information to the SIEM.

SIEM: The solution being both intuitive and flexible is the key. Look for event correlation tools that can grow with you in terms of correlative scenarios. Start with your exact correlative scenarios. Look for correlation tools that work with your anticipated workflow. IT Support, Security Operations, and Incident Response teams have different uses for these systems. You need to understand how each of them derives requirements. Purchasing based on price alone will leave you with a tool that, in reality, is no better than a good log management solution and some Perl scripts. Purchasing based on fancy features means you will overpay for something you'll never accomplish. Drive the vendors to illustrate how they meet your needs. If you can't articulate your requirements in a way that separates the lines between vendors, either hire a consultant to help you understand it better or wait to purchase the SIEM, it may save you hundreds of thousands of dollars in the end.
Here are some basic requirements SIEM tool must be able to support:
• Vulnerability Scanning Tools (Assets should be created and correlated against vulnerable/non-vulnerable systems)
• Advanced ACL's
• Analyst Workflow: External tool integration, Event "Marking" or notes for escalation, Case Management, and Integration with ticketing systems
• Reporting and Dashboarding
• Integration with Log Management devices (bi-directionally receive events and search events). Most accomplish this natively via SSL data transfer with their own solutions, via syslog, API/SDK, or other OS tools (FIFO, Log File) for other solutions.
• KEY: Flexible correlation – not just a pre-defined set of values; you should be able to correlate on any value maintained within the system. Correlation amongst standard and custom fields is the key to future expandability beyond the most basic use-cases.
• KEY: If you have already justified the need for a security analysis program, the use of the tool for these users is critical. Many have similar functionality that is only appreciated by the advanced user base. Make sure these users get hands-on and understand those subtle but time-saving/consuming differences. Most investigatory actions should be right-click driven or otherwise very intuitive in nature for the analyst.
• Analytical tools: statistical analysis, data mining, visualization tools can add significant value. Make sure you understand how you will use them in your operations before purchasing – there may be better alternatives out there.

Other relevant thoughts:
Event Sources (today and tomorrow): In our experience, we have seen many situations where the only event sources considered default to a standard set of network security monitoring devices. Though important, these devices are not always focused and prioritized according to business risks and business criticalities, nor do they always add the most correlative value. For example, firewalls are a useful data set, but depending on the configuration, location, and log levels, these devices may only provide a very limited value in terms of correlation of malicious traffic. The costs for transporting, processing, and storing these logs may or may not make sense in a SIEM product. Capturing the data and forwarding a subset of the data based on a specified use-case is be a better idea in most cases. This is where other technologies, like a Log Management Device in conjunction with a SIEM product, can add significant value if designed properly.

SIEM Staffing Requirements: Many organizations have the expectation that the SIEM will provide all necessary services related to information security and that their overall staffing requirements will be reduced. The truth is, if the SIEM is properly utilized, your staff will be extraordinarily busy in responding to newly identified security incidents that it did not previously have visibility into. A properly configured, tuned, and maintained SIEM will make your team more efficient, but will also increase the workload. A less than ideally maintained SIEM will increase your staffing requirements and workload and reduce the overall efficiency dramatically by forcing the team to respond to a multitude of activities that may or may not have a security impact. Consolidating log information provides a lot of raw resources that, traditionally, analysts become mired in for hours/days/weeks before they can find any single thing of value. Many network security analysts have not had the experience of looking at Oracle logs or other application data, and when presented with this data without context, it creates a very complex work environment. Having knowledgeable base information, defined workflows, escalation paths, and an understanding of maintaining the system reduces this complexity and allows the security team to focus on incidents.
Depending on the networks and systems you are protecting, there may be more useful sources of information, such as intrusion detection, web proxy logs, DNS and Email logs, VPN logs, operating system logs, application logs, database logs, directory services, and many other types of information sets that can add significant context and value into both a Log Management and SIEM solution. Failing to take into account these valuable sources of information can result in missed security incidents and will significantly reduce the ability of the security team to filter out false positives. The SIEM will require resources to maintain the content (Correlation Rules, Reports, etc), the system (patches, SP, Versions), and in certain circumstances the database (updates, tuning, etc). The latter, system/database, are not full-time resources, but should be accounted for in your planning. The content is constantly evolving and requires daily, if not hourly interaction – one or more resources should be considered to handle the load as one of their primary duties.

Your thoughts/questions/comments are welcome.

-Rocky

SIEM Best Practices: Basic Correlation and Default Content

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 some basic 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).

Typically SIEM Vendor Use Case: Company “X’ wants to correlate on a near real time basis several stimuli and responses, say Network Traffic, IDS Signature(s) and Server/Application Response(s) and have it alert key personnel only when it matters most. With the right event sources, environmental context and log levels you can do that with a good SIEM based on Time, IP’s, Ports, Services, Vulnerabilities and/or other attributes of the related log entries.

What happens in the real world? As many of you know if you leave the default content enabled with your raw data flow - All hell breaks loose. You will see 10’s or 100’s of thousands of correlated activities on a daily basis. This is just a function of lab versus real life.

First, many organizations still don’t have what I would consider a robust IDS signature management program and the alerting from their current systems is ….. um….. well….. interesting. The really good IDS shops have lots of custom signatures that are categorized by the Vendors and won’t necessarily be included in default correlation rules.

Network traffic logging is inconsistent at best and finding out what systems/applications they have (not to mention how and what they log) is neither possible nor realistic without a fundamental change in the organization. Neither of the above is the fault of the SIEM Vendor or Product – it is simply the world we live in.

Yes this is all changing (very slowly) and certain compliance activities (PCI for example) can be used to help us to slowly drive those changes (if we are lucky enough to present a enterprise-wide security enhancement scenario to the exec team before a vendor pitches a product to simply “check the box”).

So then what value does SIEM correlation add? For now, I’ll just say that your mileage may vary, but you can control it! Several factors can add significant value to the data, location information, system information, business use information, vulnerability information, etc… To the Security Analyst the value of the information increases as more about the context of the data set, the targeted system and the overall environment in known. The less context the more work the analyst has to do to understand the alerts that are generated.

You can do the hard work or contextualizing (is that a word???) your environment as best you can for your SIEM ahead of time and say on top of it as the environment changes, or you can do the work with each event you have to analyze. The choice is yours depending on how you configure your SIEM. In the end the team that is prepared with the right ingredients at the beginning will enjoy SIEM life much more.

Other more technical rationale: SIEM Content (Correlation, Statistical Analysis, Reports) are after all memory, processor and/or query operations and consume resources in order to function and provide you with the end result. As minimal as those resources may be for each piece of content – in aggregate or across an enterprise your data will eventually overwhelm those resources if not managed properly. You can hurt yourself with bad content. Yes the good products are scalable, however the complexity with scalability is the topic of a future blog post.

SIEM Configuration Default Content Recommendations:
1. Know your environment. The better you understand your environment the better you can tune the tools you have to help you tame it. I use the concept of system and or network profiles to help capture that data into a knowledge base.

2. Disable default system content: Yes a lot of time and energy went into developing this content and in many cases it is highly useful. My recommendation is to use is as a template and/or a learning tool. Enable the content that you need and understand. If it doesn’t align to a documented workflow or feed a report – what exactly is it doing???

3. Document your known requirements and plan. There is nothing that says you can’t build content to solve tactical and strategic needs of your organization. I suggest a roadmap discussion and plan out your requirements accordingly. Some of these SIEM solutions provide 3 or more ways to accomplish essentially the same thing you can get lost easily.

4. If you don’t know – ask. There is an ever increasing number of SIEM users out there that have similar issues (perhaps with different technologies) but their approaches can be leveraged through Forums/Blogs/Linkedin/etc. Decurity will be providing more help in this area soon. So stay tuned.

SIEM Best Practices: Before you buy

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!