Cloud security what to expect (introduction to cloud security)
•
7 likes•1,515 views
This presentation is based on slides taken from Cloud Security Alliance CCSK training slides.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (17)
Similar to Cloud security what to expect (introduction to cloud security)
Similar to Cloud security what to expect (introduction to cloud security) (20)
Recently uploaded
Recently uploaded (20)
Cloud security what to expect (introduction to cloud security)
- 2. • Moshe Ferber, 37, lives in Modiin (+2). • Information security professional for over 15 years. • Managed the security department for Ness Technologies. • Founded 2Bsecure cloud services, Israel based MSSP (currently owned by Matrix). • Shareholder at Clarisite – Your customer’s eye view • Shareholder at FortyCloud – Make your public cloud private • Member of the board at Macshava Tova • Certified instructor for the Cloud Security Alliance 2
- 3. Introduction to cloud computing IaaS Security
- 4. Introduction to cloud computing IaaS Security PaaS & IaaS security Logical controls
- 6. 6 Broad Network Access Rapid Elasticity Measured Service On-Demand Self-Service Resource Pooling
- 7. 7
- 8. Public Cloud Private Cloud Community Hybrid Cloud Deployment Models 8
- 9. 9 • The lower down the stack the cloud service provider stops, the more security capabilities and management consumers are responsible for implementing and managing themselves. SaaS IaaS PaaS SecurityResponsibility Provider Customer
- 10. • . 10 SaaS IaaS PaaS ProviderCustomer All Guest and App security App Security Contractual controls Infrastructure & Application security Platform Security Infrastructure Only
- 11. 12
- 12. Introduction to cloud computing IaaS Security PaaS & PaaS Security Logical Controls
- 13. How IaaS Is No Different You still have to manage the host’s security •Patches •Configuration Management •Log Management •Host Based IDS if appropriate •Host Based Firewall if appropriate •AV if you have to •Crypto-key management •In other words, just like normal 14
- 14. How IaaS Is Different No Control/Visibility of the Network •Flat network •No outbound firewalling •No NIDS/NIPS •Firewalling limited to Layer 4 •Limited WAF options •Limited to no DLP options •Limited commercial SSL termination options •Only 1 IP per instance 15
- 15. Your Provider What you get from the Provider • Selection of Operating Systems • Open Source – Linux in particular • Most also provide access to Windows • IP Address • SAN Access • Basic Firewalling • API for provisioning and management What you don’t get from the Provider • Multiple IPs per host (usually) • Layer 7 firewalling • NIDS/NIPS • Any sort of IDM • Patching or systems management • It’s all up to you! 16
- 17. • There are many different types of security credentials: Username/password for logging into the web interface. Access keys for REST/query (web) API. X.509 certificates for SOAP (programmatic) access (like the command line interface). Host keys for accessing instances. Account ID for bundling and sharing images. 18
- 18. Load from secure image Pre-install software packages Transfer security credentials Scan and harden on the fly Policy across different providers Virtual Machine
- 19. Storage Hardware Hypervisor OS DB Application Users Taken from: www.privatecore.com Storage level encryption Relevant: IaaS , PaaS, SaaS, Control by: provider Keys: At Provider Protect from: Hardware theft OS/Volume level encryption Relevant: IaaS , Control by: Consumer Keys: consumer Protect from: provider, hardware DB level encryption Relevant: IaaS , PaaS Control by: consumer / provider Keys: both Protect from: provider, breaches Complex Simple
- 20. Storage Hardware Hypervisor OS DB Application Users Taken from: www.privatecore.com File level encryption (IRM) Relevant: Specific file types only Control by: Consumer Keys: Consumer Protect from: any illegal access App level encryption Relevant: IaaS , PaaS Control by: Consumer Keys: consumer Protect from: provider, breaches Proxy level encryption Relevant: SaaS Control by: consumer Keys: Consumer Protect from: provider, breaches Complex Simple
- 21. Amazon CAI
- 22. Moshe Ferber, CCSK Tel. +972-52-8342313 moshe@onlinecloudsec.com
- 23. • Cloud Security Alliance CCSK courseware • Cloud Security Alliance research. • Jim Reavis, Cloud Security Alliance CEO. • The NIST Definition of Cloud Computing • NIST Cloud Security Architecture (Draft) • ENISA Cloud Computing risk assessment • Securosis Blog and Research database
- 24. • Moshe Ferber • http://www.linkedin.com/pub/moshe-ferber/0/58a/828
Editor's Notes
- The first of the essential characteristics is “Broad Network Access,” which basically means the computing resources are available through pretty much any mechanism desired. These may include: Standard clients, like mobile phones, laptops and desktop computers, both internal and external to your corporate network. Traditional software services, like applications and middleware. Since the cloud provides similar capabilities to what a company would build themselves, any cloud-resident resources would need to be accessible from computing resources (both internal and external) to the organization. There shouldn’t be any restrictions in terms of access via cloud-based software services either.
- In terms of what you buy when you look at cloud services, the types of offerings tend to broken up into three different levels. We’ll go through each distinction in some detail. These offerings tend to be describe as the SPI stack. S for Software as a Service. P for Platform as a Service. And I for Infrastructure as a Service. Now the cloud stack is clearly evolving and we are seeing a lot of overlap and less clear distinction between the layers of the stack. So first, let’s get a feel for the standard definitions of each layer in the stack and then we can use some examples to show the blurring that is happening now.
- Public Cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services. This tends to be what most organizations view as the “cloud.” Basically a big set of computers in the sky that can be spun up or decommissioned instantly to support almost any kind of applications. Private Cloud. The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or a third party, and may exist on-premises or off- premises. Any infrastructure you are responsible for managing can be termed a “private cloud.” Thus your existing data center, given some of the essential characteristics of cloud infrastructure (brad network access, rapid elasticity, etc.) is sort of a private cloud. Of course, there is a lot of work to be done to turn a traditional existing data center into a private cloud facility, but it’s definitely a direction many organizations are moving towards. Community Cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, or compliance considerations). There are many affinity groups (organized by vertical, geography, size, etc.) that tend to have very similar computing requirements. A community cloud can bring leverage and economies of scale to these environment, driving down the cost of delivering the IT service and likely increasing capabilities. The community cloud may be managed by the organizations or a third party and may exist on-premises or off-premises. Hybrid Cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds). Why have one, when you can have two for twice the price? OK, that may be a little facetious, but hybrid models are real and provide both a shorter term migration plan (so you can support your existing data centers/private cloud, while moving some or all of your infrastructure to another cloud platform).
- The statement says it all. The lower in the stack the provider stops, the more the customer has to do. So IaaS stops low in the stack, thus the customers are responsible to secure the systems and applications. PaaS is in the middle and may offer some level of security within the platform, but the customer would still be required to make the API calls within the application. SaaS is a bit of a different animal because the provider is responsible for the entire solution (from cradle to grave). Thus the onus is upon them to protect any information within their service. As you can imagine, data security is very important to the SaaS providers, since a breach or failure could result in the proverbial “run on the bank” and put the entire business in danger.
- The statement says it all. The lower in the stack the provider stops, the more the customer has to do. So IaaS stops low in the stack, thus the customers are responsible to secure the systems and applications. PaaS is in the middle and may offer some level of security within the platform, but the customer would still be required to make the API calls within the application. SaaS is a bit of a different animal because the provider is responsible for the entire solution (from cradle to grave). Thus the onus is upon them to protect any information within their service. As you can imagine, data security is very important to the SaaS providers, since a breach or failure could result in the proverbial “run on the bank” and put the entire business in danger.
- IaaS essentially hands you an operating system with the basic networking configured and that’s it. The provider takes care of the underlying infrastructure such as networking and HVAC etc., but you are responsible for everything else. This is exactly just like if you were in your own datacenter or rented cage. You have to patch, manage configurations, worry about IDS, AV, crypto keys etc. Essentially it’s life as usual.
- Almost no provider offers anything but flat networks. This means that if you need a N-Tier architecture, you’re going to have to fake it. Most providers also only provide inbound firewalling and no outbound firewalling. Similarly most providers don’t offer any sort of NIDS/NIPS capabilities which becomes hard to implement yourself due to the flat network constraints. And due to lack of outbound network filtering, DLP becomes tricky as well. Commercial WAF is still pretty limited, though it’s generally trivial to implement something like mod_security on an instance in the cloud. On a similar vein SSL termination is generally limited to open source unless you want to buy that as a specific feature from your IaaS provider. Also most providers only allow one IP per instance, so that restricts the ability to use protocols like HSRP/VRRP for hosting multiple SSL sites on a single instance (unless you use wildcard certs, of course). Note: Amazon offers non-flat networks and outbound firewalling as part of their VPC (Virtual Private Cloud) offering. Given that VPC also now allows direct internet access to VPC resources it seems likely that all those feature will eventually be available across all of the AWS options.
- By default you don’t get a lot though the larger providers offer lots of add on services. In essence though, you get a selection of open source operating systems and many offer windows as well. You get an IP address, some sort of access to storage and some basic firewalling. Finally most also provide some sort of API access to automate the provisioning and de-provisioning of systems and storage. You don’t however generally get the ability to have more then one IP per host (AMZN does offer NAT services, so it looks like two, but really it’s only one). Firewalling is limited to Layer 4 so no protocol analysis or Layer 7 filtering at all. IDS/IPS is limited to what you can implement on the host side. Most providers have no IDM/IAM ability (though AMZN just released this as a beta product, it’s focused on backend infrastructure not on OS level pieces). Also no patching/systems mgmt. As noted earlier, you get a bare OS the rest is up to you.
- In addition to managing the security of the virtual machines themselves there are several related components that need managing as well: The API/Cloud Console credentials. Given the centralized control that this access gives you, you really want to ensure these are kept protected Host SSH/RDP keys. Firewall. Just like any other system, only open up the ports and protocols necessary to make things work. Network Zones. Just like with traditional networks, segment resources appropriately. Make use of the available network firewalls. Location Zones. Distribute the resources across multiple data centers and multiple physical regions when possible. Just because it’s cloud doesn’t mean that it’s not subject to failures.
- The key is to differentiate all the credentials. Students tend to get confused between the different types, so here is a shortcut: The username and password are for the web interface and to manage your account. Access keys are for web-based management and sign the requests, like using ElasticFox or making REST queries between instances. X.509 certificates are for SOAP (vs. REST) requests and embedding management functions into software. Host keys we covered. Your account ID is your “canonical” ID for everything in AWS.