Course Prerequisites: A while back I published a diagram and associated text illustrating the benefits of a combined SIEM and Log Management architecture. This diagram/post did a good job of explaining the features and functionality of Log Management and SIEM at a very high level. If you haven't seen that post or if you haven’t read Decurity's SIEM 101 previously I would encourage you to go back and take a look. Basic concepts from those resources will help in understanding of Use-Cases and how they apply to SIEM .
Introduction:
In my experience I’ve noticed that SIEM customers use something like 30% of less of the functionality of the tool they bought. That number is actually probably pretty high when you consider the fact that a very high percentage of customers are only using the default content that came pre-installed or was "customized" during a professional services engagement. There are some very advanced users out there, no doubt and this post will help them as well, but it is really focused on providing a framework to advance the majority of SIEM users so they can gain better appreciation for how to maximize the value of their SIEM investment.
The process (and diagram) that follows, outlines how Decurity looks at use-cases related to SIEM. We are providing this information in the hopes that you'll internalize it as part of your SIEM operations. Decurity will also be announcing in the very near future an online solution using this methodology so that you can track/update/share your use-cases/solutions - contact us if you're interested in learning more about that solution.
Use-Case Requirement:
The most simplistic advice I can give is that you should try to focus on the output first. What is the point of the work effort? What is the problem we are trying to solve? What is the intended action/output? Who benefits from this and more importantly why do they benefit from this solution? Then you can move into questions like - what information is required to solve the problem?
The information provided in this article will help to guide you through the process. Implementing solutions in your SIEM in an ad-hoc manner will result in failure or at best very temporary and minimalistic gains. If you don’t believe me you can ask any of the hundreds of organizations who tried it before you.
Use-Case Illustration:
General:
This is the most basic logistical information related to the use-case and related solution. It provides a documentation framework.
• Author: Who was involved in the creation/authoring of the solution?
• ID, Version and Date: What is the current version and ID and last date of update.
• Objects, Artifacts: Link to objects (externalized or within solution) used within the solution for example, the configuration objects like report, rules, dashboards, etc.
• Solution Description: Quick reference to the solution, using categorization that makes sense for your organization.
• References: Corporate or External documents that act as reference material for your use-case and/or solution.
Business Justification: This is the problem being addressed from a corporate perspective. One or more Business problems may apply, but each should be documented in some fashion.
• Business Problem Description: What are the specific problems that need to be addressed?
• Business Owner(s): Who owns the actions for output of the system? Who owns relevant Systems, Applications and Data? Who is requesting Assistance?
• Business Perspective: Security, Compliance, Risk, Audit, Fraud, Legal, HR, Other?
• Current Solution: Today how is this problem addressed? How can it be improved?
• Expectations: What is it that the business owners expect from the solution?
• Priority: What is the value of solving this issue, or conversely what is the cost of not solving this issue?
Technical Requirements:
• Need: Active Statements – “The system shall”, “We have to” *(DO SOMETHING)* Define that something.
• Action: Action(s) and/or Output(s) required from the system.
• Actor: Relative to a *(PERSON/TEAM)*
• Event: Specific scenario(s) to be evaluated.
• Context: Relevant environmental conditions. How does our knowledge of this environment affect how we can refine the analysis and output? Some examples of context that should be considered are: Organizational Structure, Business Units, Application and/or Data Categorizations, Network Segmentation, System Configurations, Users, “Hot Lists”, Vulnerability Data, Data/System/User Criticality, other environment specific information.
• Timing: Within, before, at, during, after.
• Logic: Boolean Logic Statements (T/F) using AND, OR, IF, THEN, NOT as conditions.
Collection:
• Data Source(s): What data sources would provide the best context? What information do we have already available?
• Data Accessibility: Are there physical, logical, business, technical or political barriers to having the relevant data?
• Data Format: is the data readily comprehended by our solution, is customization of the data necessary or possible? Do we need to update logging standards?
• Data Relevance:
o Content: What elements of the data provide us the necessary context? Which exact fields are relevant?
o Timing: Do we receive it often enough to be relevant to our proposed solution?
• Data Location: Does the data reside in a centralized, easily accessed location? Is it already aggregated, normalized or filtered in a way that would adversely affect our proposed solution?
Note: You can and should use these questions and related answers as justification for your enterprise visibility project. Logging Standards, Data Access and reliable access to the information are very often the proverbial “long pole”.
Proposed Solution:
• Technology/Process: Does SIEM make sense to solve this problem, given the data we have, our environment and the proposed solution? Can we solve this using other technology or processes in a more efficient/effective manner? SIEM is great, but not always the answer.
• Configuration: What SIEM configuration(s) provide us with the most efficient and effective solution. Is it simply a report or do we need to leverage advanced meta-correlation? Does Statistical evaluation help? Describe possibilities and known variables/obstacles. Know the capabilities of your product will help you to understand how to configure it. Advanced Use-Cases, Custom Applications, Fraud Detection, etc require a non-traditional data set and logic approach - well at least non-traditional from the security administrator perspective. Having the flexibility to "compare" against user-defined fields is key to solving those use-cases. If you find yourself unable to solve a number of “Core” use-cases then it might be time to consider training, external advice or as a last resort a new solution.
• Expected Outcome: What is it that we expect to see from the system? For example (Within “n” Minutes, we should see “x” when “y” occurs.)
• Known False Positive: How are false positives differentiated from known bad activities and how can we tune our systems/data/environment to reduce the number of valid activities we respond to?
• Known Gaps: Relative to the problem-set described what do we expect that this solution will miss? How can we close those gaps?
• Alternative Methods: Within the SIEM or external to SIEM what are alternative ways to address some subset of this problem? Do related solutions already exist?
QA:
• Performance: is the solution Efficient? Does it cause significant system degradation? Have you built “content” to monitor for efficiency?
• Functionality: Is this providing an acceptable solution for the users and owners? Are refinements required?
• Measurements: Technical effectiveness, Resource Utilization Measurements.
• Lab Validation: Were Lab tests meaningful and successful?
Note: You might get the sense from my wording that QA is an ongoing activity, you’d be correct. If you lab has irrelevant data/systems your tests are meaningless. Testing new correlation scenarios against existing data set is invaluable. Knowing how the system is going to respond before you implement into production saves time, effort and headaches.
Operations:
• Feedback: You need a periodic feedback loop to ensure you are in touch with their needs and updating/planning around upcoming requirements.
• Monitor: Changes are inevitable, from process, people, environment to threats and data sets you will need to stay in touch with how your SIEM is supporting the evolving requirements.
• Refine: simple refinements may be applied daily/weekly/monthly.
• Enhance: Do we need to add more/better data sets? Is there better Logic that can be applied? Do new or related use-cases offer better insight?
• Validations: What is the “normal” operation look of this use-case look like and how would you know abnormal behavior of your solution?
Course Summary:
So it should be clear by now that we think SIEM is a great tool, with tons of potential to identify new activities you couldn’t previously consider and to automate “definable” activities and facilitate workflow. It should also be obvious that SIEM requires planning, testing and ongoing operational support to be most effective for you and your organization. This guide and related articles/posts will go a long way to assist you with your efforts. If not, reach out and we’ll find other ways to help you!
Remember that SIEM is a process not just a tool. If you aren't making changes to your SIEM on a daily basis (or having someone make changes for you) you are not getting the most from your SIEM. Threats constantly evolve, your networks/systems/data/users are always being modified, your understanding of your environment is always changing, shouldn’t your detection techniques also be enhanced on a daily basis? The more time you spend on use-cases as identified in this post the more value you'll receive out of your SIEM.
Disclaimer: Not every vendor solves problems in the same manner. Due to technological differences, wildly varying skills of consultants and comprehension of actual problem and/or data you mileage will vary. That said the approach we are documenting here will work with any SIEM and should be used every time you think about solving new problems using your SIEM. It does mean effort has to be applied, but it also means you will have objective measurements of success when it comes to the value your SIEM is providing.
Posts
No comments:
Post a Comment