RightScale Webinar: Security Monitoring in the Cloud: How RightScale Does It

  • Published on
    20-Aug-2015

  • View
    637

  • Download
    3

Transcript

1. Security Monitoring in IaaS How We Do It at RightScale Watch the video of this presentation#rightscale 2. #Your Panel TodayPresenting Phil Cox, Director of Security & Compliance, RightScale Tony Spataro, Senior Security Engineer, RightScaleQ&A Spencer Adams, Account Manager, RightScale James Brown, Security Analyst, RightScale Please use the Questions window to ask questions any time! #rightscale 3. #Agenda Talk about the problem in general State general premise and assumptions Walk through the Why?, How?, and What? Conclusion #rightscale 4. #The problem Folks dont do security monitoring well in the first place Puzzlement about how to actually do security in Cloud andIaaS in particular What do you do when you dont own the hardware or network Vendor cloud washing and sales FUD that is being perpetuated #rightscale 5. #What is Security Monitoring? The ability to collect, analyze, and alert on security relatedsystem and application events System Logs Need a tool First 2 steps Databases The spaceare worthless Applicationsvaries without this Host Networkwidely, and Traffic cost is an issues Dont get too complicated, y oull give up #rightscale 6. #One More: Monitoring is log analysis In this context "monitoring == "log analysis Real question: How does one classify a log entry as"interesting"? Answer: You guessed it -> It depends You need to know your environment and refer back to your Why? answers A couple examples I use: Interactive login to our database server Database access from an unsuspected system Past staff user account access attempts#rightscale 7. #Some starting premises Cloud, and thus IaaS, is a new way to deliverIT If you try to shoehorn old solutions, you will likely fail Security fundamentals in cloud are similar toany other environment There is no secret sauce! Monitoring in IaaS is a subset of monitoring ina traditional enterprise Main difference is visibility into the network#rightscale 8. #As in iRobot, start with "Why?" You need to start the whole process of by asking "Why? Not "How?" or "What? Answer the following question: Why are you implementingsecurity monitoring? Make sure to get buy-in from the entire organization as to this answer, you may be surprised what you hear. Detective Spooner: Why would you kill yourself? Dr. Alfred Lanning: That, detective, is the right question. Program terminated.#rightscale 9. #Our "Why?" This part was easy, as I had done myhomework We wanted To meet compliance requirements: SSAE 16and PCI To have a system that would notify us ifsomething we knew was not supposed tohappen did: Burglar Alarms To be able to look at past events if needed:Forensics No more, no less. #rightscale 10. #Some other Why? I have encountered Determine if folks are taking data via removable media Identify excessive file transfers outbound Identify abnormal print activity Identify abnormal user activity Identify anomalous network traffic Yours will be different and the same as others #rightscale 11. #Considerations for "How?" Once you determine Why?, the next step is to determine anarchitecture, the How? The things we care about and need Need to identify the things that are critical to ensuring you canmeet your Why? Host Intrusion Detection System (HIDS) Application logs System logs Host network traffic Create a network choke point to pass all traffic Performance requirements Etc. #rightscale 12. #Our "How? In our security monitoring environment, we identified thefollowing critical items that needed consideration: Alert latency Bandwidth and data transfer costs Reliability of log stream Deployment models: (A) Local agent & alerting, Central correlation & archive (B) Local agent, Central alerting, correlation & archive (C) Agentless, Central collection, alerting, correlation, & archive #rightscale 13. #More on our "How?" Alert latency: Fire within 3 minutes of minutes of a burglaralarm event Part of our SSAE 16 control Bandwidth: Limit cost by using systems in zones/regions thathave free (ideally) or minimal cost for large bandwidth usage Reliability: Ensure that logs are available in a central store byusing a reliable transport Deploy model: Have use for all three models Help toaccommodate our PCI and SSAE 16 compliance #rightscale 14. #How: Straight from the Source Many cloud workloads are an application of some sort The best burglar alarms come from inside your house Login, logout, lockout, signup Authorization successes and failures Role evolution Resource consumption Work with developers to build monitoring into your application#rightscale 15. #Lastly you decide on the "What?" After identifying "Why?" and "How? This is about finding technology solutions that fit into yourHow? and meet your Why? Vendor Products Open Source Internally Develop Identify limitations of the technologies that are available to you Cost: What can you afford to do? Platform support: Is the desired solution supported by your platform? Product support: What type of product support will you need? Education: Can you get adequate education on the solutions? #rightscale 16. #Our What? OSSEC standalone mode, rsyslog and RELP (Reliable EventLogging Protocol) Local agent, local alerting, central correlation, central archive Allows for more detailed alerting on our Critical servers (e.g., database servers) Commercial CloudPassage product Halo Local agent, central alerting, central correlation, central archive To meet PCI and give additional benefits for PCI compliance Syslog via RELP to a central log collector. OSSEC (servermode) for alerting and correlation Deploy central collectors in locations that meet the "bandwidth cost reduction" requirement Easiest for admin; deployed to all other systems #rightscale 17. #Global OSSEC: Its easy We use RightScale to configure every server to send syslogs tocentral server Use RightScale to scale syslog collectors as needed, andlaunch OSSEC servers as needed Use RightScale to configure Syslog servers to feed the localOSSEC server OSSEC configuration and rules are managed via Git for propersource control We tuned all the noise out prior to rolling into production: Burglar Alarms are our focus Test new rules in Staging, then globally deploy to productionwith a click of a button The beauty of RightScale!#rightscale 18. #Local OSSEC: Its focused One one our SSAE16 controls relies on it Use RightScale to install and configure OSSEC server instandalone mode OSSEC rules: Same as global rules Plus a couple specific to actions we dont expect on the critical servers Also File Integrity Monitoring of certain critical files OSSEC configuration and rules are managed via Git for propersource control Test new rules in Staging, then globally deploy to productionwith a click of a button#rightscale 19. #CloudPassage: Provides added benefits Gives us alerting, plus more for our PCI compliance: Separation of duties Configuration review Malicious process watching Host based firewall management* It is a known and accepted cloud security tool, that PCI auditorsare comfortable with #rightscale 20. #RELP caveats Reliable implies Buffered: extra disk and memory consumption at the source Stateful: extra bandwidth consumption Gotchas RELP is not compatible with TLS encryption, so had to use stunnel Rsyslog versions built into distros are WAY behind Have to tune the memory queues to avoid performance issues 10 MBps logs + rsyslogd memory buffering + network hiccup = log bomb! Needed a lot of testing, since the docs never really said what did and didnt work. imfile plugin (which reads logs from apps that dont natively support syslog protocol) seems buggy when you give it a large file to consume This is PROBABLY fixed in a later version, but havent confirmed yet #rightscale 21. #SSAE16 Control process Working with the auditors we identified certain actions andevents that our customers would care about Need certain functionality on specific systems Need certain functionality for all systems in the platform We wrote custom OSSEC rules #rightscale 22. #Our OSSEC Burglar alarms Focus was the database (imagine that) and systems that directlyaccess the database Decided that implementing specific local alerting on the criticalsystems was the best solution Some examples of these type of alerts: Successful interactive login Integrity of sensitive files Failed login to the database itself Failed DROP commands Etc. There are a number of default OSSEC alerts that are noise inour environment, as we ignore 1002, 5710, 5706, 551, 5402, 17101, 5403, 5901, 5902, 17102 #rightscale 23. #Conclusion Must start with the "Why?" question Ease of administration, especially in a highly elastic IaaSenvironment, is very important Start with things you know are problems: limits false positives#rightscale 24. #Next Steps Contact RightScale (866) 720-02081. Learn: Read Phils blogsales@rightscale.com www.rightscale.com blog.rightscale.com/author/philcoxrs/2. Learn more: Visit our security supportal support.rightscale.com/SecurityThe next big RightScale Community Event! April 25-26 in San Francisco3. Try: Free Edition www.RightScaleCompute.com www.rightscale.com/free Attend technical breakout sessions Get RightScale training Talk with RightScale customers Ask questions at the Expert Bar #rightscale

Recommended

View more >