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.

1. Security Monitoring in IaaS
How We Do It at RightScale
Watch the video of this presentation
#rightscale

2. #
Your Panel Today
Presenting
• Phil Cox, Director of Security & Compliance, RightScale
• Tony Spataro, Senior Security Engineer, RightScale
Q&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 don't 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 don't 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
• Don't get too
complicated, y
ou'll 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 didn't work.
• imfile plugin (which reads logs from apps that don't 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-0208
1. 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 Francisco
3. 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