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.

SIEM Vendor Leapfrog

Recently, Log Management and SIEM vendors have spent a lot of time updating/fixing their products. Over the past few months some vendors have quietly passed over other solutions in terms of market relevance and certainly the door has been opened to a whole bunch of upstarts trying to make a name for themselves. While the majority of Log Management and SIEM business (and therefore product direction) is driven by compliance activities, I appreciate the forward movement towards enterprise security that many in the field are trying to make. The initial execution on that product vision I'm seeing from many of the vendors this year is very welcome. IMHO the entire space had gotten very stale with the big guys mainly focusing on compliance appliances or playing feature catch-up with one another. Here's my summary of what's going on in SIEM and Log Management so far in 2009.


My observations about recent SIEM and Log Management Vendor announcements and my thoughts about what is still needed to make it more effective for most customers.

1. Log Management appliance based solutions continue to rule the land. See ArcSight's last quarterly results announcement and extract from that the fact that something like 46% of product revenue was based on their appliances or talk with Intellitactics about their recent growth in SAFE Logging Appliance sales if you don't believe me. Splunk may be exception to that appliance rule as they continue to gain ground on everyone but the fact remains if you don't have a solid Log Management offering you're toast in 2009. Conversely, pure Log Management solutions have seen the importance of having a SIEM offering available to be able to effectively compete on larger accounts (see the link below about Log Logic partnership with ExaProtect as one example).

2. Some vendors are still playing feature catch-up adding things like Trouble Ticket Integration of Vulnerability Assessment Tool Integration. It is amazing to me that these are "new feature sets" in several products, but progress is progress and I'll take it. I'm still not thrilled with most vendors idea of integration being unidirectional SMTP based updates but it's a start. The idea of Vulnerability Management and then furthering that by full CMDB integration is awesome in theory but in many cases it is very hard to scale. This has made significant stride forward but in my mind much more is left to be accomplished.

3. Database Activity Monitoring seems to be catching on. Interesting given how difficult this really is to accomplish in an enterprise - Admin level monitoring is easy enough but field level and/or transaction level auditing like Oracle FGA is a non-trivial task to accomplish. Most vendors have approached this solution set through 3rd party product support (Imperva, Guardium, etc) but at least a couple have tackled this directly through development or acquisition.

4. Enterprise Visibility is a growing trend. I've previously stated my appreciation for having proper visibility across the enterprise. When NetWitness announced their free version of Investigator I posted my comments and review of the technology. Last year in my "Best Practices in Security Operations: Collection" post I expressed my thoughts on what it takes to really do Enterprise Security Operations correctly and that the foundation of the entire process is Collection. Part of that collection is filling in the gaps missed by other products and Full Packet Capture is an awfully powerful tool to have in your arsenal. Several vendors have announces partnerships with 3rd party providers and/or announced network capture/replay as an internal capability through development or acquisition (see NitroSecurity).

5. Hard stuff is still hard - Windows Event Logs, Custom Applications, CMDB Integration, Database Monitoring are all hard problems to tackle. No vendor has this perfect (how could we expect them to) but several have started to think about ways to make this easier, rather than just saying "start with critical systems" they are developing more reliable/scalable/flexible solutions. I'm interested to see how far the vendors get with the more complex logs and more meaningful IT operations integrations in 2009.

6. Relevant content is king. The default content (Correlation, Reports, etc) from most of the vendors is not going to work in your enterprise. Sure some of it works at least some of the time but seriously on average how could 1500+ reports ever apply to your environment. Content Tuning is the #1 area vendors can make these solutions more relevant and easier for customers. I believe this so much that Decurity has re-focused much of its energy to address this issue head on hey, it's my blog and I'll pimp if I want to.

7. Consolidation/Contraction. I do expect to see more industry consolidation. High Tower won't be the last failure and some of the big boys need to revamp their overall integrated solutions. The Log Management side may be commodity ready but SIEM is not (yet). I expect at least 2 more acquisitions/failures to occur in the space in the coming months and not necessarily because of bad technology. A great technology in the wrong hands or begin put against the wrong goals is no better than a crappy technology.

Additional Thoughts:
SIEM: The Fortune 100 seems to be saturated with products/solutions (a lot have failed and some are actually working) and they have plenty of war stories that hey are more than willing to share. The overall take-away is simple - you need to be ready to invest in success if you jump into SIEM, product flexibility, product expertise, documented internal requirements and perhaps most importantly internal processes/procedures for making it work.
Fortune 200-2000: I'm happy to see that many organizations are now starting to push-back on vendors (and their own management) after learning from the mistakes of others. I think they will take a more reasonable approach of making Log Management work first before moving to SIEM and when they get to SIEM I'm encouraged by the increasing trend of documenting actual use-cases and requirements.
Channel: Nearly all the of vendors are trying enabling better global channel programs and at least in Log Management these are very successful programs helping them gain foreign market share and SMB market in the US.

SIEM: Some idea's for improvement:
1. Most of the SIEM products require significant expertise to deploy, manage and maintain effectively. There is a good business there for the right partnerships and companies should leverage that expertise. Today the number of VAR's and Consulting organizations that really can be considered "expert" in this area can be counted on one hand. I still think the vendors are going to have to do better to make their SIEM products more user-friendly and that will require a true partnership with their customers.
2. If your SIEM can't correlate events (Raw or Meta events) between engines you should be pushing your Vendor towards making that work in 2009. Linear scalability is irrelevant you are going to need flexibility in the future. Even if your organization is not mature enough to use that functionality today, you will eventually get there, make sure your vendors are partnered with you to help you achieve your long-term goals.

LOG MANAGEMENT: Log Management will continue to grow across all market segments, no question. The overall channel effectiveness seems to be growing as the acceptance of appliance based solutions grows. Compliance is an easy driver for sales in Log MGMT but at some point the big customers will have to step up and require better and more scalable solutions from the vendors.

Log Management: Some idea's for improvement:
1.) Log Management solutions that attach to an in-house SAN is a great idea - but only if the SAN carve out is unlimited or at least sufficient enough that they aren't required to purchase additional appliances to scale to the enterprise.
2.) Better bi-directional support between Log Management and SIEM solutions is absolutely required. You have to be able to search one/both from a single location for these to gain better traction as combined offerings.
3.) Flexibility is going to be key moving forward. Splunk is gaining ground for a reason (and it is more than marketing). Integration of new event sources will continue to be a key issue.
4.) Content is also an issue on the Log Management end. Some vendors do a fantastic job and others need better partnerships or a renewed internal focus on relevant security content.


Recent Log Management and SIEM Product Update News and Links:
March 2009
Nitro Security Acquires Chronicle Solutions .
EMC RSA RSA releases enVision v4.0 And now Paul Stamp is over there helping them move the product further along!
NetForensics NetForensics releases NFX v4.1 .

Feb 2009
TenableTenable releases Database Auditing Capability
Q1Labs QRadar 6.2 was released. .
LogLogic partners with exaprotect
NetForensics HighTower was gobbled up by NetForensics. I'm reserving judgment for now.

Jan 2009
Nitro Security integrates Database Activity Monitoring (DAM) into SIEM.
eIQnetworks announces a new round of funding and management additions A lot of "buzz" around eIQ right now but I have yet to have the opportunity to see them in action in a global enterprise. I hear good things about their approach, but I'm always cautious.

Late 2008 News:
Symantec SIM v4.6 released" .
Trigeo seeks HighTower's customers Trigeo offered a competitive upgrade to former HighTower customers.
LogRhythm Version 4.1 Released
Sensage version 4.0 Released
Splunk v3.4.6 released I hear rumors of Splunk 4.0 coming this summer!
ArcSight Announces ESM 4.0 SP2 and ArcSight Logger 3.0 ArcSight Logger 3.0 was a VAST improvement over previous versions in terms of speed and capability.
Q1 Labs QRadar product was OEM'ed into Juniper STRM Products. An interesting play, very similar to what Protego did a few years ago (now Cisco MARS).

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/

Preview of Decurity’s New Enterprise SIEM Subscription Service

The Decurity team has been incredibly busy over the last few months cooking up new and more cost effective ways to support our mantra of “keeping security simple”. We’re getting ready to introduce a “game changer” for our Log Management and SIEM customers. Our newest offering will be fully described in the coming days but here is a preview of the new subscription services Decurity is offering to our clients.

Simplistic overview of the O&M Problems most SIEM customers face:
1. Today, many SIEM customers have 2 or more Full Time Engineers (FTE’s) supporting, managing or otherwise dedicated to their SIEM and still find themselves using only a small percentage of the SIEM’s real potential.
2. Many customers know that there is more they can “do” with the SIEM but simply can’t get there from where they currently stand. Frustration continually builds up.
3. Most customers simply don’t know where to go next after the initial implementation or consulting engagement.
4. Hiring the best SIEM Experts is really, really expensive especially when you factor in all of the downtime caused by change-control or other mission critical tasks that pop-up and waste valuable time.

Simplified solution overview:
1. Decurity will help ensure you purchase the right tool for your needs and ensure the tools are configured optimally for the long-haul.
2. Decurity will provide pre-packaged and custom-built content delivered to you on a recurring basis to help expand your usage of the SIEM and extract the most possible value from the tool.
3. Decurity is there for the long-term, working to understand your changing needs and using our expertise to help guide your efforts accordingly.
4. Decurity leverages the most experienced SIEM team in the industry to deliver these services in a very cost-effective manner.

A little more detail about what is including in our Enterprise SIEM Subscription Service:

Installation/Expansion:
Decurity can help during all phases of your SIEM deployment. Decurity will work with you to help you define the requirements, guide you through vendor selection, architect the solution, implement or expand on your existing infrastructure. We partner with you to ensure you receive the best possible advice through the lifecycle of your SIEM deployment.

Quarterly SIEM Healthchecks:
As part of this service offering on a quarterly basis Decurity will work with your team to ensure your SIEM is performing at it’s most optimal capacity. Typically, much of this work can be accomplished remotely further reducing your team’s time and cost commitments. We’ll quickly identify any issues, offer remediation plans and help you implement any necessary changes.

SIEM Content Updates:
Our experts will develop SIEM Content to help your analysts more accurately focus on the “Events of Interest” for your organization. Our solutions are categorized by Event Source and/or by Problem-Set to help you better understand which content will add value to your environment. Solutions will be updated on a recurring basis (daily, weekly, etc) as new Event Sources, Problem-Sets and Solutions are identified and/or refined.

Here are some examples of SIEM Content we’ll update/refine for you:
• Active Lists: For Example: Hot IP’s, Domains - We maintain a list of Hot IP’s and Domains that is updated Daily (as necessary).
• Active Channels: Events of Interest, Interesting Analytical Views
• Data Monitors / Dashboards: Statistical Analysis, Performance Measurements, Security Status Dashboards
• Filters: (reusable queries)
• Reports/Query/Trends: Reports that focus on measuring success or providing “Actionable Intelligence”
• Correlaton Rules: Basic and Advanced Correlation relevant to the Problem-set and customizable to meet your specific organizations needs.
• Workflow and Notifications
• Tools: Integration of tools/macros/scripts
• Pattern Discovery (Profiles): (ArcSight Only) By providing new and updated profiles based on Event Sources or problem sets we’ll help you gain the most from this powerful tool!

Added Value:
As part of this offering customers also have the opportunity to submit new problem-sets for us to solve - simply work with us through our support system to understand the problems you are trying to solve and we’ll help you develop customized solutions. Instead of investing in costly consulting engagements you can leverage this service to create solutions.

Log Management and SIEM integration Support
We’ll help you most effectively use your Log Management and SIEM tools to complement and enhance the overall value of both solutions!
We’ll ensure from the the data is intelligently processed providing you with the information you need but not killing your SIEM and overwhelming your team. From the Event Source through the “collector” into your Log Management Solution and finally as it reached your SIEM we’ll work with you to ensure the right information is collected, stored, forwarded and analyzed to maximize functionality and overall value by reducing storage/processing costs.

Summary:
No matter where you stand with your SIEM deployment Decurity’s Subscription service will benefit you greatly. If you’re just getting started we’ll save you the 2 years of frustration your peers enjoyed. If you’re more mature in your SIEM efforts we can help ensure you’re really getting all the value you possibly can from your system. Our goal is to make this as simple as possible so that you can work on the output of the SIEM and take action to protect your enterprise. We’ll make the SIEM work FOR you!

Sales Information: We want to work with you to understand your needs and will be more than happy to schedule some time to talk more about how Decurity can help you with your SIEM and Log Management needs. Please send us an email at sales at decurity dot com with any questions you might have and we’ll get back to you (usually the same day).

About Decurity:
Decurity supports the Fortune 500 Globally and many US Government customers on a true enterprise scale. We are focused solely on Security Operation including the usage SIEM and Log Management Solutions to enhance the Incident Response Process. Our experts have been responsible for hundreds of Log Management and SIEM implementations across the world. We will do what it takes to make you successful!

The preceding has been a repost of my blog entry at: http://blog.decurity.com/index.php/dec_template/more/preview_of_decuritys_new_subscription_service/

Update 1 (23 Feb 2009) : Updated http://www.decurity.com reference link: http://www.decurity.com/SIEM_SUBSCRIPTION_OVERVIEW.html
The webpage offers additional explanation about the initial rollout of this service offering which is centered on the Arcsight ESM and ArcSight Logger products. Future releases will offer support for products such as Splunk, Symantec SIM, RSA Envision, etc.

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!