So You Got That SIEM. Now What Do You Do? Anton Chuvakin, Principal, Security Warrior Consulting (@anton_chuvakin)
Many organization that acquired Security Information and Event Management (SIEM) tools and even simpler log management tools have realized that they are not ready to use many of the advanced correlation features, despite promises that "they are easy to use" and "totally intuitive."
So, what should you do to achieve success with SIEM? What logs should you collect? Correlate? Review? How do you use log management as a step before SIEM? What process absolutely must be built before SIEM purchase becomes successful?
At this presentation, you will learn from the experience of those who did not have the benefit of learning from other's mistakes. Also, learn a few tips on how to "operationalize" that SIEM purchase you've made. And laugh at some hilarious stories of "SIEM FAIL" of course! As a bonus track, how to revive a FAILED SIEM deployment you inherited at your new job will be discussed.
So You Got That SIEM. NOW What Do You Do? by Dr. Anton Chuvakin
1. So You Got That SIEM. NOW What Do You Do? Dr. Anton Chuvakin SecurityWarrior LLC www.securitywarriorconsulting.com
2. DIRE WARNING: This presentation does NOT mention PCI DSS… …oh wait www.pcicompliancebook.info
3. Outline Brief: What is SIEM? “You got it!” SIEM Pitfalls and Challenges Useful SIEM Practices From Deployment Onwards SIEM “Worst Practices” Replacing a SIEM and Other Tips Conclusions
4. About Anton: SIEM Builder and User Former employee of SIEM and log management vendors Now consulting for SIEM vendors and SIEM users SANS Log Management SEC434 class author Author, speaker, blogger, podcaster (on logs, naturally )
6. SIEM and Log Management LM: Log Management Focus on all uses for logs SIEM: Security Information and Event Management Focus on security useof logs and other data
7. What SIEM MUST Have? Log and Context Data Collection Normalization Correlation (“SEM”) Notification/alerting (“SEM”) Prioritization (“SEM”) Reporting and report delivery (“SIM”) Security role workflow (IR, SOC, etc)
8. What SIEM Eats: Logs <18> Dec 17 15:45:57 10.14.93.7 ns5xp: NetScreendevice_id=ns5xp system-warning-00515: Admin User anton has logged onvia Telnet from 10.14.98.55:39073 (2002-12-17 15:50:53) <57> Dec 25 00:04:32:%SEC_LOGIN-5-LOGIN_SUCCESS:LoginSuccess[user:anton] [Source:10.4.2.11] [localport:23] at 20:55:40 UTC Fri Feb 28 2006 <122> Mar 4 09:23:15 localhostsshd[27577]: Accepted passwordfor anton from ::ffff:192.168.138.35 port 2895 ssh2 <13> Fri Mar 17 14:29:38 2006 680 Security SYSTEM User Failure Audit ENTERPRISE Account Logon Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon account: ANTON Source Workstation: ENTERPRISE Error Code: 0xC000006A 4574
9. What SIEM Eats: Context http://chuvakin.blogspot.com/2010/01/on-log-context.html
10. How SIEM Got Here!? 1996-2002 IDS and Firewall Worms, alert overflow, etc Sold as “SOC in the box” 2003 – 2007 Above + Server + Context PCI DSS, SOX, users Sold as “SOC in the box”++ 2008+ Above + Applications + … Fraud, insiders, cybercrime Sold as “SOC in the box”+++++
11. What do we know about SIEM? Ties to many technologies, analyzes data, requires process around it, overhyped What does it actually mean? Many people think “SIEM is complex” Thinking Aloud Here…
12. I will tell you how to do SIEM RIGHT! Useless Consultant Advice Alert!!
13. The Right Way to SIEM Figure out what problems you want to solve with SIEM Confirm that SIEM is the best way to solve them Define and analyze your use cases Gather stakeholders and analyze their use cases Research SIEM functionality Create requirements for your tool, including process requirements Choose scope for SIEM coverage (with phases) Assess data volume over all Phase 1 log sources and plan ahead Perform product research, vendor interviews, references, peer groups Create a tool shortlist Pilot top 2-3 products in your environment Test the products for features, usability and scalability vs requirements Select a product for deployment and #2 product for backup Update or create procedures, IR plans, etc Create SIEM operational procedures Deploy the tool (phase 1)
18. Popular #SIEM_FAIL … in descending order by frequency: Misplaced expectations (“SOC-in-a-box”) Missing requirements (“SIEM…huh?”) Wrong project sizing Political challenges with integration Vendor deception And only then: product not working
19. What is a “Best Practice”? A process or practice that The leaders in the field are doing today Generally leads to useful results with cost effectiveness P.S. If you still hate it – say “useful practices”
20. BP0 How to Plan Your Project? Goals and requirements (WHY) Functionality / features (HOW) Scope of data collection (WHAT) Sizing (HOW MUCH) Architecting (WHERE)
21. BP1 LM before SIEM! If you remember one thing from this, let it be: Deploy Log Management BEFORE SIEM! Q: Why do you think MOST 1990s SIEM deployments FAILED? A: There was no log management!
23. Graduating from LM to SIEM Are you ready? Well, do you have… Response capability and process Prepared to response to alerts Monitoring capability Has an operational process to monitor Tuning and customization ability Can customize the tools and content
24. BP2 Initial SIEM Use Steps of a journey … Establish response process Deploy a SIEM Think “use cases” Start filtering logs from LM to SIEM Phases: features and information sources Prepare for the initial increase in workload
25. Example LM->SIEM Filtering 3D: Devices / Network topology / Events Devices: NIDS/NIPS, WAF, servers Network: DMZ, payment network, other “key domains” Events: authentication, outbound firewall access, IPS Later: proxies, more firewall data, web servers
26. BP3 Expanding SIEM Use First step, next BABY steps! Compliance monitoring often first “Traditional” SIEM uses Authentication tracking IPS/IDS + firewall correlation Web application hacking Your simple use cases What problems do YOU want solved?
27. Example: Use Case Example: cross-system authentication tracking Scope: all systems with authentication Purpose: detect unauthorized access to systems Method: track login failures and successes Rule details: multiple login failures followed by login success Response plan: user account investigation, suspension, communication with suspect user
34. What is a “Worst Practice”? As opposed to the “best practice” it is … What the losers in the field are doing today A practice that generally leads to disastrous results, despite its popularity
35. WP for SIEM Planning WP1: Skip this step altogether – just buy something “John said that we need a correlation engine” “I know this guy who sells log management tools” WP2: Postpone scope until after the purchase “The vendor says ‘it scales’ so we will just feed ALL our logs” Windows, Linux, i5/OS, OS/390, Cisco – send’em in!
36. Case Study: “We Use’em All” At SANS Log Management Summit … Vendors X, Y and Z claim “Big Finance” as a customer How can that be? Well, different teams purchased different products … About $2.3m wasted on tools that do the same!
37. WPs for Deployment WP3: Expect The Vendor To Write Your Logging Policy OR Ignore Vendor Recommendations “Tell us what we need – tell us what you have” forever… WP4: Don’t prepare the infrastructure “Time synchronization? Pah, who needs it”
40. “Hard” Costs - Money Initial SIEM license, hardware, 3rd party software Deployment and integration services Ongoing Support and ongoing services Operations personnel (0.5 - any FTEs) Periodic Vendor services Specialty personnel (DBA, sysadmin) Deployment expansion costs
41. “Soft” Costs - Time Initial Deployment time Log source configuration and integration (BIG!) Initial tuning, content creation Ongoing Report and log review Alert response and escalation Periodic Tuning and content creation Expansion: same as initial
44. How to Do It? Prepare to run both products for some time Draft the new vendor to help you migrate the data Be prepared to keep the old SIEM or keep the data backups BIG! Migrate SIEM content: reports, rules, views, alerts, etc 40
45. Tip: When To AVOID A SIEM In some cases, the best “SIEM strategy” is NOT to buy one: Log retention focus Investigation focus (log search) If you only plan to look BACKWARDS – no need for a SIEM!
46. Conclusions SIEM will work and has value … but BOTH initial and ongoing time/focus commitment is required FOCUS on what problems you are trying to solve with SIEM: requirements! Phased approach WITH “quick wins” is the easiest way to go Operationalize!!!
47. SIEM Reminders Cost countless sleepless night and boatloads of pain…. No SIEM before IR plans/procedures No SIEM before basic log management Think "quick wins", not "OMG ...that SIEM boondoggle" Tech matters! But practices matter more Things will get worse before better. Invest time before collecting value!
48. And If You Only … … learn one thing from this…. … then let it be….
50. Questions? Dr. Anton Chuvakin Email:anton@chuvakin.org Site:http://www.chuvakin.org Blog:http://www.securitywarrior.org Twitter:@anton_chuvakin Consulting:http://www.securitywarriorconsulting.com
51. More Resources Blog: www.securitywarrior.org Podcast: look for “LogChat” on iTunes Slides: http://www.slideshare.net/anton_chuvakin Papers: www.info-secure.org and http://www.docstoc.com/profile/anton1chuvakin Consulting: http://www.securitywarriorconsulting.com/
52. More on Anton Consultant: http://www.securitywarriorconsulting.com Book author: “Security Warrior”, “PCI Compliance”, “Information Security Management Handbook”, “Know Your Enemy II”, “Hacker’s Challenge 3”, etc Conference speaker: SANS, FIRST, GFIRST, ISSA, CSI, RSA, Interop, many, many others worldwide Standard developer: CEE, CVSS, OVAL, etc Community role: SANS, Honeynet Project, WASC, CSI, ISSA, OSSTMM, InfraGard, ISSA, others Past roles: Researcher, Security Analyst, Strategist, Evangelist, Product Manager
53. Security Warrior Consulting Services Logging and log management / SIEM strategy, procedures and practices Develop logging policies and processes, log review procedures, workflows and periodic tasks as well as help architect those to solve organization problems Plan and implement log management architecture to support your business cases; develop specific components such as log data collection, filtering, aggregation, retention, log source configuration as well as reporting, review and validation Customize industry “best practices” related to logging and log review to fit your environment, help link these practices to business services and regulations Help integrate logging tools and processes into IT and business operations SIEM and log management content development Develop correlation rules, reports and other content to make your SIEM and log management product more useful to you and more applicable to your risk profile and compliance needs Create and refine policies, procedures and operational practices for logging and log management to satisfy requirements of PCI DSS, HIPAA, NERC, FISMA and other regulations Others at www.SecurityWarriorConsulting.com
Gal: “CISO thinks that SIEM opportunity cost is too big; spend $100k on SIEM vs spend $100k to solve a dozen problems”
Figure out what problems you want to solve with SIEMConfirm that SIEM is the best way to solve themDefine and analyze your use casesGather stakeholders and analyze their use casesCreate requirements for a toolChoose scope for SIEM coverageAssess data volume over all Phase 1 log sources and plan aheadPerform product research, vendor interviews, references, peer groupsCreate a tool shortlistPilot top 2-3 products in your environmentTest the products for features, usability and scalability vs requirementsSelect a product for deployment and #2 product for backupUpdate or create procedures, IR plans, etcCreate SIEM operational proceduresDeploy the tool (phase 1)
Maybe inheritedDoes everybody need a SIEM?Do you need a SIEM?Are you ready for SIEM?Do you want a SIEM?
Organizations that graduate too soon will waste time and effort, and won't any increased efficiency in their security operation. However, waiting too long also means that the organization will never develop the necessary capabilities to secure themselves. In brief, the criteria are:Response capability: the organization must be ready to respond to alerts soon after they are produced.Monitoring capability: the organization must have or start to build security monitoring capability such as a Security Operation Center (SOC) or at least a team dedicated to ongoing periodic monitoring.Tuning and customization ability: the organization must accept the responsibility for tuning and customizing the deployed SIEM tool. Out-of-the-box SIEM deployments rarely succeed, or manage to reach their full potential. Just like college… Graduation tips:Satisfy the graduation criteriaUse a LM vendors that has a good SIEMDeploy LM and use it operationallyPeriodic log reviews = first step to monitoringLook for integrated capability
http://ciscomars.blogspot.com/2011/04/guest-post-how-to-replace-siem.htmlOuch! That “Venus” SIEM appliance that we got with routers has finally croaked. That piece of PHP brilliance that pre-pre-previous security engineer wrote has been buried under the thick pile of XML. That managed SIEM provider has annoyed us one last time.What do the above situations have in common? The unfortunate time to replace your SIEM has come. What to expect, apart from copious amounts of pain? This post will shed some light on this conundrum, based on author’s experiences.First, it goes without saying that it is better to choose the right SIEM the first time (e.g. see “On Choosing SIEM” and other posts mentioned below) than to migrate from a SIEM that has been collecting logs (and dust) for a few years. However, you might not have any say in the matter – you might have inherited it, your “evil boss” might have procured the previous SIEM without asking you or you might have built it yourself after a particularly bad hangover… Also, your organization might have simply outgrown the SIEM or your early generation SIEM vendor has not kept up with innovation in the space. In any case, you have a SIEM and you need a new one.
http://ciscomars.blogspot.com/2011/04/guest-post-how-to-replace-siem.htmlLet’s look at the good side of the situation:It is very likely that you learned some super-valuable lessons from your previous SIEM experience (other people have to hire consultants to get to those lessons) and now can avoid the common purchasing process pitfalls (some discussed here, BTW) You have much more confidence while discussing confusing SIEM features with vendors – speaking from your previous SIEM experience (this alone will make your new SIEM purchase process much less painful) You have some semblance of the logging policy across the systems that log into SIEM – that puts you ahead of those organizations who are just getting their first SIEM or log management tool It is possible that you built some operational procedures around SIEM (such as for PCI DSS log review or other purposes) and those would be handy for a new SIEM as well If you have to write an RFP (as I discuss here), the chances are that your new RFP would be MUCH better and more likely to result in a good vendor short list Treat this situation as positive, think “I now know more than 90% of people buying a SIEM, thus my new SIEM project will be a success” A few things to avoid and pay attention to:Suppress that “I’d buy anything but this crap” mentality – think “what problems will a new SIEM solve or solve better?” Avoid taking shortcuts (such as not doing a PoC); you are more knowledgeable, but not prescient… How might a migration process look like? This assumes that you have already selected a new product, tested it in the lab and are ready for production deployment. Prepare to run both products for some time – this might range from a few weeks to months Draft the new SIEM vendor to help you migrate the data; after all, they are getting the prize Potentially, be prepared to keep the old SIEM running (without paying for the support contract, of course) or at least keep the old data backups – this becomes important if complete data migration is impossible due to architecture differences between the new and old SIEMs. Ideally, your log management tool will hold raw log backups and so keeping the old SIEM in operation won’t be needed. One of the biggest migration efforts will be migrating SIEM content: reports, rules, views, alerts, etc. As well all know, such content is not really portable across SIEMs and you should be prepared to simply recreate all the custom content AND all the default content that you used in the the old SIEM and that the new SIEM might lack.
Log management and Security Information and Event Management (SIEM) product selection - how to pick the right SIEM and logging product?Develop log management or SIEM product selection criteria (related writing)Identify key use cases aligning log management and SIEM tools with business, compliance and security requirementsPrepare RFP documents for SIEM, SEM, SIM or log managementAssist with analyzing RFP responses from SIEM and log management vendorsEvaluate and test log management and SIEM products together with internal IT security teamAdvise on final product selectionLogging and log management policyLogging and log management policy - how to develop the right logging policy? What to log?Develop logging policies and processes for servers and applications , log review procedures, workflows and periodic tasks as well as help architect those to solve organization problemsInterpret regulations and create specific and actionable logging system settings , processes and log review procedures (example: what to log for PCI DSS?)Plan and implement log management architecture to support your business cases; develop specific components such as log data collection, filtering, aggregation, retention, log source configuration as well as reporting, review and validationCustomize industry "best practices" related to logging and log review to fit your environment, help link these practices to business services and regulations (example)Help integrate logging tools and processes into IT and business operationsSIEM and log management product operation optimization - how to get more value out of the tools available?Clarify security, compliance and operational requirementsTune and customize SIEM and log management tools based on requirementsContent developmentDevelop correlation rules, reports and other content to make your SIEM and log management product more useful to you and more applicable to your risk profile and compliance needsCreate and refine policies, procedures and operational practices for logging and log management to satisfy requirements of PCI DSS, HIPAA, NERC, FISMA and other regulationsTraining - how to get your engineers to use the tools best?Provide the customized training on the tools and practices of log management for compliance, IT operations, or security needs (example training conducted)Develop training on effective operation and tuning of SIEM and log management tools to complement basic vendor training.
The previous version “SANS Top 5 Essential Log Report” (you can still get it at SANS site) is being updated by the author. Here is the draft that you can use today.1. Authentication and Authorization Reportsa. All login failures and successes by user, system, business unit – must have login success logs, not just failure!b. Login attempts (successes, failures) to disabled/service/non-existing/default/suspended accountsc. All logins after office hours / “off” hoursd. Users failing to authenticate by count of unique systems they triede. VPN authentication and other remote access logins (success, failure)f. Privileged account access: logins, su use, Run As use, etc. (success, failure)g. Multiple login failures followed by success by same account – needs to have correlation for that2. Change Reportsa. Additions/changes/deletions to users, groups – even a trend on user additions across systems would be usefulb. Additions of accounts to administrator / privileged groupsc. Password changes and resets – by users and by admins to usersd. Additions/changes/deletions to network servicese. Changes to system files – binaries, configurations – likely needs a list to rung. Changes in file access permissionsh. Application installs and updates (success, failure) by system, application, user