Your SlideShare is downloading. ×

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

589

Published on

Are you overwhelmed by the plethora of cloud security vendors and not sure how to get started with security monitoring in a cloud environment? …

Are you overwhelmed by the plethora of cloud security vendors and not sure how to get started with security monitoring in a cloud environment?

Find out how we at RightScale use security monitoring in the cloud to achieve compliance, send critical alerts, and collect forensic data.

In this webinar, we will:

- Guide you through the framework we used to define our goals for security monitoring, decide how we wanted to do it, and then select which tools to use.
- Share practical insights on how to successfully do security monitoring in a cloud environment.
- Realign the focus to be on delivering results instead of implementing technology for technology's sake.

Join RightScale's Director of Security & Compliance Phil Cox and Senior Security Engineer Tony Spataro to learn directly from the team responsible for the security architecture and regulatory compliance for one of the most complex cloud-based deployments on the planet.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
589
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
30
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Telcos built point-2-point networks for their customers
  • 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 and IaaS 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 related system and application events • System Logs • Need a tool • First 2 steps • Databases • The space are worthless • Applications varies without this • Host Network widely, 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 deliver IT • If you try to shoehorn old solutions, you will likely fail• Security fundamentals in cloud are similar to any other environment • There is no secret sauce!• Monitoring in IaaS is a subset of monitoring in a 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 implementing security 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 my homework• We wanted • To meet compliance requirements: SSAE 16 and PCI • To have a system that would notify us if something we knew was not supposed to happen 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 an architecture, the “How? • The things we care about and need• Need to identify the things that are critical to ensuring you can meet 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 the following 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 “burglar alarm” event – Part of our SSAE 16 control• Bandwidth: Limit cost by using systems in zones/regions that have free (ideally) or minimal cost for large bandwidth usage• Reliability: Ensure that logs are available in a central store by using a reliable transport• Deploy model: Have use for all three models – Help to accommodate 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 your “How?” 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 Event Logging 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 (server mode) 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: It’s easy• We use RightScale to configure every server to send syslogs to central server• Use RightScale to scale syslog collectors as needed, and launch OSSEC servers as needed• Use RightScale to configure Syslog servers to feed the “local” OSSEC server• OSSEC configuration and rules are managed via Git for proper source 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 production with a click of a button • The beauty of RightScale! #rightscale
    • 18. #Local OSSEC: It’s focused• One one our SSAE16 controls relies on it• Use RightScale to install and configure OSSEC server in standalone mode• OSSEC rules: • Same as global rules • Plus a couple specific to actions we don’t expect on the critical servers • Also File Integrity Monitoring of certain critical files• OSSEC configuration and rules are managed via Git for proper source control• Test new rules in Staging, then globally deploy to production with 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 auditors are comfortable with #rightscale
    • 20. #RELP caveats• “Reliable” implies… • Buffered: extra disk and memory consumption at the source • Stateful: extra bandwidth consumption• Gotcha’s • RELP is not compatible with TLS encryption, so had to use stunnel • Rsyslog versions built into distro’s 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 haven’t confirmed yet #rightscale
    • 21. #SSAE16 Control process• Working with the auditors we identified certain actions and events 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 directly access the database• Decided that implementing specific local alerting on the critical systems 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 in our 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 IaaS environment, is very important• Start with things you know are problems: limits false positives #rightscale
    • 24. #Next Steps Contact RightScale (866) 720-02081. Learn: Read Phil’s blog sales@rightscale.com www.rightscale.com blog.rightscale.com/author/philcoxrs/2. Learn more: Visit our security supportal support.rightscale.com/Security The 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

    ×