What to Be Aware Of? Will all your log and context data be going to the MSSP? Does MSSP have skills to analyze your site-specific logs? Can you still take a peek at your original logs? Do you need to call for that? Can you access them directly? Cloud SIEM?
Build Risks Ongoing maintenance will KILL you No support, apart from you Does it pass the “bus test”? Handling log volume Will it scale with you? Advantages
Open-Source Tools to the Rescue! Log collection Syslog-ng, kiwi, Snare, LASSO, Apache2syslog, logger, etc Secure centralization Stunnel, ssh, OpenSSL Pre-processing LogPP Storage MySQL or design your own file-based storage Analysis – a tough one! OSSEC and OSSIM for [some] intelligence Swatch, logwatch, logsentry, other match-n-bug scripts
Example: How to Deal with A Trillion Log Messages? How to analyze a trillion (~1000 billions) of log messages for some specific goal? Hundreds of terabytes (1/2 of a petabyte …) of data Which tool to pick? “Sorry, buddy, you are writing some code here!” See loganalysis list or my blog for details about this case
Risks “Cash and carry” – pay and get a tool you need to use now Skilled staff needed to get value out of a purchase Requirements not met Vendor longevity
Questions to Discuss With Your Vendor Are you collecting and aggregating 100% of all log data from all data sources on the network? Are your logs transported and stored securely? Are there packaged reports that suit your needs? Can you create the needed reports to organize collected log data quickly? Can you set alerts on anything in the logs? Are you looking at log data on a daily basis? Can you prove that you are? Can you perform fast, targeted searches for specific data? Can you contextualize log data (comparing application, network and database logs) when undertaking forensics and other operational tasks? Can you readily prove that security, change management,and access control policies are in use and up to date? Can you securely share log data with other applications and users?
Combined Strategies: Often the Best… Buy + Build: great idea – enhance vendor tools with internal custom development OR combine vendor tools with open-source tools (build, then buy or the opposite) Buy + Outsource: split the work with an MSSP team and retain more control Combined approaches mitigate some of the risks, but at a cost (see TANFL principle )
Build + Buy: Surprisingly Effective! Capture buy advantages: Support Ongoing improvement Routine log analysis tasks done by vendor! Capture build advantages: Build analysis you want Present the data you want to the people that need it Critical SIEM tasks done by you!
Finally, How to Choose? Breadth/depth of project requirements Just how unusual you are? Unique needs or volumes Size of organization Available resources Money, development talent Organization culture and management support Deployed hardware and software Run any Tandem?
So, You Decided to Acquire a SIEM What’s next? What do you want, specifically? How to choose a product? How not to screw it up? How to make sure that it goes smoothly, now and later? How to be happy with your SIEM?
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
SIEM or LM Project Lifecycle Determine the need Define scope of log management Select and evaluate the vendor Run proof of Concept – POC Deploy (in phases) Run the tool Expand deployment
1. Determine the Need 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: Define the need in general “We need, you know, ‘do SIEM’ and stuff” Questions: Real-time? Platform? Appliance? Service? Correlation? Indexing? RDBMS vs files? Volume of logs? Agents? Collectors? Connectors? Users? Youruse cases?
Case Study A – Just Buy a SIEM! Medium-sized financial company New CSO comes in from a much larger organization “We need a SIEM! ASAP!” Can you spell “boondoggle? Lessons learned: which problem did we solve? Huh!? None?
2. Define scope WP3: 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! WP4: Assume you will be the only user of the tool “Steakholders”? What’s that? Common consequence: two or more simiilartools are bought
Case Study B: “We Use’em All” At SANS Log Management Summit 200X… 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!
3. Initial vendor selection WP5: Choose by price alone Ignore hardware, extra modules, training, service, support, etc costs “OMG, this tool is 30% cheaper. And it is only twice as bad.” Advanced version: be suckered by the vendor’s TCO and ROI “formulas” WP6: Choose by relationship or “PowerPoint power” “We got it with the latest router purchase…”
4. Vendor evaluation and POC WP7: Don’t ask for and don’t check references “Our environment is unique” WP8: Don’t do a POC “We can save time!” “We can just choose the best product, right?” “The vendor said it works just peachy” WP9: If doing a POC, let vendor dictate how OR ignore what the vendor says “Windows? Sure, we will test on Windows!” “Proof of concept!? Why prove what we already know!”
Case Study C: Performance-Shmerformance Retail organization deciding between two log management products, A and B Vendor A: “We scale like there is no tomorrow” Vendor B: “We scale like we invented scaling” Q: “Can you prove it?!” A: Results: Vendor A claims 75,000 MPS, dies at 2300 (!) Vendor B claims 75,000 MPS, runs at 85000 (!!)
5. Deployment WP10: Expect The Vendor To Write Your Logging Policy OR Ignore Vendor Recommendations “Tell us what we need – tell us what you have” forever… WP11: Unpack the boxes and go! “Coordinating with network and system folks is for cowards!” Do you know why LM projects take months sometimes? WP12: Don’t prepare the infrastructure “Time synchronization? Pah, who needs it” WP13: Ignore legal team Pain …
Case Study D: Shelfware Forever! Financial company gets a SIEM tool after many months of “evaluations” Vendor SEs deploy it One year passes by A new CSO comes in; looks for what is deployed Finds a SIEM tool – which database contains exactly 53 log records (!) It was never connected to a production network…
6. Running the Tool WP14: Deploy Everywhere At Once “We need log management everywhere!” WP15: “Save Money” on Vendor Support Contract “ We Have to Pay 18% for What?” WP16: Ignore Upgrades “It works just fine – why touch it?” WP17: Training? They said it is ‘intuitive’! “’A chance to “save” more money here? Suuure.”
Case Study E: Intuitive? To Me It Isn’t! A major retailer procures a log management tool from an integrator A classic “high-level” sales, golf and all “Intuitive UI” is high on the list of criteria The tool is deployed in production Security engineers hate it – and don’t touch it Simple: UI workflow doesn’t match what they do every day
7. Expanding Deployment WP18: Don’t Bother With A Product Owner “We all use it – we all run it (=nobody does)” WP19: Don’t Check For Changed Needs – Just Buy More of the Same “We made the decision – why fuss over it?” WP20: If it works for 10, it will be OK for 10,000 “1,10,100, …, 1 trillion – they are just numbers”
Case Study F: Today - Datacenter, Tomorrow … Oops! Log management tool is tested and deployed at two datacenters – with great success! PCI DSS comes in; scope is expanded to wireless systems and POS branch servers The tool is prepared to be deployed in 410 (!) more locations “Do you think it will work?” - “Suuuuure!”, says the vendor Security director resigns …
Conclusions – Serious! Turn ON logging! Learn about SIEM and log management Read NIST 800-92 and other industry document; do the research! Read some of the stuff I wrote on SIEM too Match what you need with what they have Not doing it as a key source of PAIN Plan carefully – and plan your planning too Work WITH the vendor – not ‘against’, not ‘without’, not ‘for’
Final Word Final word: do big IT projects have “shortcuts” to easy and effortless success – what are they? The answer is … NO!
Questions Dr. Anton Chuvakin Email:email@example.com Google Voice: 510-771-7106 Site:http://www.chuvakin.org Blog:http://www.securitywarrior.org LinkedIn:http://www.linkedin.com/in/chuvakin Consulting: www.securitywarriorconsulting.com Twitter:@anton_chuvakin
More on Anton 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, 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, Consultant
Security Warrior Consulting Services Logging and log management policy 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 Content development Develop of 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 More at www.SecurityWarriorConsulting.com