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
Posts
No comments:
Post a Comment