Cloud Computing: Let's Clear the Air

In this whirlwind tour of Cloud Security, Mark Stanislav will start with a general overview of today's information security concerns and needs. He will include with this overview a broad definition of the current cloud lexicon and terms.

Digging further, Mark will cover indepth the security concerns facing modern corporations, organizations and governments. He will follow this up with a brief overview of how these entities address the security concerns they face on a daily basis.

Transcript

1. CLOUD COMPUTING Let’s Clear the Air...
2. ME Senior Linux System Administrator for MNX Solutions; MSP in Monroe Built/taught Linux curriculum for Eastern Michigan University Previously the cloud computing subject matter expert for ePrize Deployed multi-cloud provider scalable infrastructure to handle Super Bowl advertising traffic for two digital promotions in 2010 Hold the Certificate of Cloud Security Knowledge (CCSK) from the Cloud Security Alliance Present at events on configuration management & scalability in cloud computing and other elastic infrastructure
3. GIANT MISCONCEPTION When someone says they are ‘going to the cloud’ that may not mean they are utilizing ‘cloud computing’ if that was true... Everything outside of your own data closets and on- site data centers would be cloud computing cloud still means Internet... Going to ‘the cloud’ may just mean ‘I am not using a server I can physically see 24x7 anymore’
4. Cloud Computing Involves... On-demand self-service Broad network access Resource pooling Rapid elasticity Measured Service
5. On-demand self-service “A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.” Consider an API (Application Programming Interface) or web console that allows you, the consumer, to take resources as you desire them without calling a company and asking for a quote to get something in two or three days
6. Broad network access “Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).” The cloud should be accessible without regard to your method of access. The consumer should determine the use-case and scope of network access to services, not the provider.
7. Resource pooling “The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction.” Consumers want resources; they don’t want hardware. A cloud provider should provide as much or little resource allocation as the consumer requests -- whichever resource they want.
8. Rapid elasticity “Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.” Adding more cloud resources should not be an arduous process for the consumer. Further, the provider should allow the consumer to dictate circumstances which automatically add resources to meet demand before an absence of resource can occur
9. Measured Service “Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service. Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.” Consumers in the cloud should pay for what they are using in a more structured manner than traditional resource service models. For instance, if I have a ‘server’ in the cloud, I only pay for it when it’s turned out; not a monthly flat fee.
10. Typical Cloud Confusion Utilizing virtualization and providing it to a consumer is not necessarily a cloud service. You will often see virtualization as a means-to-an-end to provide multi-tenant infrastructure for cloud service but it is not required to be a cloud computing service A lot of things are (by definition) cloud computing because of Software as a Service (SaaS).Basically any piece of software that you can access on the Internet which performs a task that may otherwise occur on your desktop (e.g. GMail, Dropbox) Many people are talking about Infrastructure as a Service (IaaS) when referring to cloud computing, but this is not the only part of the cloud
11. Software as a Service (SaaS) “The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser.” GMail is a SaaS offering because it provides you an application to interact with e-mail systems without having to have an e-mail client on your personal device; merely a web browser Dropbox provides online storage through a web interface that you can upload/share/download files. They also have a desktop client to synchronize. If you had to use the desktop client, it wouldn’t be a SaaS anymore. The online storage offered is a component of IaaS.
12. Platform as a Service (PaaS) “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider.” Microsoft Azure can provide you the ability to run your application on their cloud infrastructure without having to buy a server or worry about setting up a web server PHPFog combines a caching engine, load balancer, application server, and database server into one service that allows you to deploy your PHP application without the hassle of managing those components
13. Infrastructure as a Service (IaaS) “The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications.” Generally people reference this in terms of deploying an Operating System such as Linux or Windows onto a provider’s multi-tenant hardware. This is often accomplished using virtualization technology. Can also be related to online storage; you don’t control the hard drive or necessarily the location but you control what data you put online. Because it’s just a resource and not “software”, it’s IaaS not SaaS.
14. Typical Cloud Deployments Private Cloud: Your resources look like traditional cloud computing due (elastic, on-demand, etc.) but usually deployed on-site or heavily controlled and segregated from other people Public Cloud: Your resources are being placed within the same hardware, network, and storage as other people.You have little control to say where the data is or how the underlying aspects of your environment are created and managed. Hybrid Cloud: Some resources are public, some are private.
15. To Put This Another Way... IaaS PaaS SaaS You don’t control anything except how you use a service and what data you put into the service. Someone else controls the OS, network, hardware, storage, etc. You don’t necessarily interact with a software package but a building block to which you can architect software from or manage software that you will integrate with to provide functionality. You don’t control the hardware, network, or storage but you do get to say how much of it you leverage and the software on top of the stack you want.
16. Fear and Loathing in the Cloud “Cloud Computing is unproven” Cloud computing at its core are old services provided in a new way If you run a web site on a cloud provider, you’re not somehow less safe than if you were to use a traditional ‘shared hosting’ web provider. Your data, network traffic, and applications are still being placed on the same resources as hundreds of other people. We’ve all been using Hotmail, Yahoo! Mail, and other SaaS offerings for years now. There have been security issues but generally related to singular accounts rather than the entire service offering.
17. Fear and Loathing in the Cloud “Amazon Web Services doesn’t meet industry requirements” ISO 27001 SAS 70 Type II PCI DSS Level 1 HIPPA Amazon Web Services are... ...compliant.
18. Fear and Loathing in the Cloud “If I go to the cloud, my data will be stolen” Sharing storage does not mean that your data is available just because someone else has bits on the same hard drive Sharing networking does not mean all of your traffic is viewable by other tenants of the network in a passive way (or even through common network attacks) Virtualization is actually a fantastic security mechanism inherently due to the implementation of separation of resources you probably didn’t have at your last web hosting provider
19. Fear and Loathing in the Cloud “I can’t trust XYZ provider’s people” Cloud computing means that people at a company have access to your servers, network, storage, and potentially your data Colocation, dedicated hosting, shared hosting, virtual private servers and all other off-site hardware and software means that.... See above. The situation does not change. I’d trust Amazon with my data before a random data center in Michigan who has been around a few months.
20. The cloud can be nasty, though. Consider this scenario: A criminal has access to 10,000 stolen credit cards Aforementioned criminal posses basic programming skills API calls are sent to create 20 ‘server instances’ per credit card at 10 different cloud providers Criminal now has 2 million servers to conduct attacks, distribute piracy, spam people, or attempt to dilute available resources for potential legit customers
21. Bot-nets used to take effort! Old bot nets were handfuls of Grandparent’s slow computers running 56k modems on AOL and infected with spyware New bot nets can be created on-demand with sizes being determined by the number of cloud computing (IaaS) providers who accept a credit card/PayPal account and will automatically provide resources without even so much as a phone call Cloud bot nets allow criminals to rent high-capacity computing resources on amazing network connections with no existing ‘infections’ needed
22. It’s not all bad, though. Companies such as Rackspace or Amazon are well staffed and trained to deal with cyber criminals by deploying fraud and abuse detection systems to help react quickly to negative situations It’s easier for a large cloud provider to shutdown rogue accounts, block stolen credit cards, and provide law enforcement with evidence than a Mom-and-Pop web hosting provider or a random teenager’s computer that has been infected with a trojan Some providers like Amazon require account creation to involve simple additional hoops such as phone call verification to an automated service; not a fix but it definitely makes would-be criminals work harder
23. Cloud Security Practices Cryptography everywhere you can... Data that is sitting on random disks across data centers you don’t know the location of should be encrypted so that if hard drive(s) were stolen, your data would still be reasonably safe Transport encryption (SSL/TLS) should be applied for any sensitive traffic between cloud servers to each other as well as cloud servers to general end-users (e.g. webmail users utilizing your SaaS) No customer PII, PHI, or otherwise sensitive information should be accessible in a cleartext format without previously having to enter a passphrase or utilize a private key to decrypt said information
24. Cloud Security Practices Audit your resources against either traditional compliance standards (PCI, HIPPA, SOX, etc.) or with your company’s own guiding practices Ensure strong network filtering when able to do so. Amazon for instance allows a network-based inbound firewall ruleset; stack that with a host- based firewall on each instance to ensure no gaps exist if one fails Utilize multi-factor authentication at an account level (Amazon has token integration) and also at your service level (IaaS, SaaS) Ann Arbor-based Duo Security for Linux/Juniper/Cisco MFA
25. Cloud Security Practices Try to mitigate the sensitive information you store in the cloud; keep that data in-house/on-site if at all possible Implement host-based intrusion detection systems (OSSEC, Tripwire) Use strong passwords on all accounts and try to reduce password reuse Ensure the cloud provider you utilize meets industry standard compliance for required certifications relevant to your business Discuss legal concerns with your counsel or the cloud provider before jumping in and looking back realizing it’s too late to be proactive
26. Other Cloud Practices Have detailed documentation on how your cloud infrastructure is setup so that if you had to migrate from one provider to another, you wouldn’t have to scramble to figure out how to Configuration management tools (Puppet, Chef, CFEngine) can allow for rapid deployment of infrastructure by treating components (services, software, configuration) as code and allowing it to be versioned and managed easily If you have a server in the cloud that cannot fail, you probably need to re-think how you’ve deployed your infrastructure or application Treat your IaaS as ephemeral and plan for failure; be resilient!
27. Does this all sound familiar? Cloud practices are not very different in most cases than regular information security practices Cloud computing is still the same technology that we’ve been securing just with new applications and some bells & whistles Don’t complicate cloud security practices with fancy new products: stick to standard cryptography, strong passwords, separation of privilege, multi-factor authentication, and limit your stored sensitive data Face your fears in your existing environment before going to the cloud! Things will not magically change by going to a IaaS, PaaS, or SaaS.
28. What should I do differently? When our source-code is hidden there’s typically a harder time to exploit it; that doesn’t mean it’s necessarily safe! When our servers are on-site, there’s typically a harder time to exploit them; that doesn’t mean they are necessarily safe! Implement the best practices you should be already doing and don’t skimp on follow-through; be aggressive with your security. Going from a data center cage that you have keys to into a cloud provider’s cluster of computing resources does take a leap of faith so be ready to let go of some safety-nets you’re used to.
29. Why NOT to go to the cloud... If you’re PCI DSS Level 1, it’s not impossible to do so in the cloud but you’re going to have to find the right QSA :) 2013 is next PCI council revision; things may change then If you don’t architect for failure, that’s exactly what you will have Some companies did have AWS failures recently on a grand scale; other companies survived the AWS outage... If you fail (architecture or security) plan on being in the news quickly; it’s very popular to bash the cloud!
30. References/Appendix http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf http://cloudsecurityalliance.org/ http://aws.amazon.com/security/ http://www.duosecurity.com/ http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf http://sites.google.com/site/detroitcloudgroup/ http://clouddevday.com/
31. Thank You! Questions? mark.stanislav@gmail.com @markstanislav uncompiled.com