Moving Canadian Business Securely To The Cloud
January 22nd, 2016
The final argument against Canadian businesses moving to the cloud is going away in 2016. This year both Microsoft Azure and AWS are going to start delivering services from Canadian soil.
According to Mark Schrutt, Research Vice-President Services and Enterprise Applications at IDC Canada, “60% of Canadian buyers preferred to have IaaS delivered from within Canadian borders”, the moves by Microsoft and AWS direct address this preference.
This lack of Canadian services and concerns around security have been significant blockers for cloud adoption in Canada.
With the geographic concern gone, security concerns remain. But should they?
A quick scan of AWS and Microsoft Azure reference customers will produce a list of big name brands in a number of industries and geographies.
What do Canadian business need to know about security in order to move safely into the cloud?
Shared Responsibility
Security in the cloud is a responsibility shared by the provider and the consumer.
While Microsoft Azure, AWS, Google, and others might not agree on much, they do agree on this basic model.
This is a very straightforward model in its presentation. We start with the view that security is required everywhere, and in order to manage the security aspects of a deployment, we’ll sort various responsibilities into the following areas:
– Physical infrastructure
– Network infrastructure
– Virtualization layer
– Operating system
– Application(s)
– Data
The next step is to then determine who is responsible for the security aspect of each of these areas: the cloud service provider or the consumer (you, the user).
Depending on the service in question, the answer of “who is responsible for this area?” changes.
The security responsibilities for these areas change depending on the type of service you are consuming. The rule of thumb here is the more options and configuration required for the service, the more direct security responsibilities fall to you.
Being a conscientious (a.k.a., rightfully paranoid) security practitioner, you will want to verify that your provider is holding up their end of the bargain (spoiler alert: Microsoft and AWS are). You can do that by visiting the providers site’s on compliance and security (here is Microsoft Azure’s and here is AWS’)
Partial Trust
While the shared responsibility model is simple to understand, it does come with some significant implications. The biggest of those implications is one of trust.
By using a cloud service provider, you are implicitly extending them a high level of trust.
This is something that needs to be taken into account when evaluating risk to your infrastructure and application deployments.
Failure to properly evaluate this risk will leave you and your data unnecessarily exposed.
Physical Access As An Example
The weak point in digital security has always been physical access to the equipment. When you’re dealing with a cloud service provider, you will **never** have physical access to the systems you’re using.
This means you’re relying completely on the provider for physical security of your system. You’re also trusting them not to abuse the privileged position they are in with respect to having physical access.
A reputable cloud service provider will provide documentation (either public or exclusively to it’s clients) about how something like physical access is handled. They will also provide some form of attestation that they are following the process they’ve setup.
This is why it’s important to verify that your cloud service provider is compliant with any frameworks relevant to your business or SOC 1, PCI-DSS, or ISO 27001 (or all of them).
These three frameworks all provide a strong baseline of verifiable security.
Applied Controls
A common misunderstanding about cloud security is that the security controls you’re familiar with in the enterprise data centre disappear.
When you examine and apply the shared responsibility model, you’ll quickly find that these controls still exist but the day-to-day responsibility for their application and management may have changed hands.
Similarly, the location in which they are applied may also have changed.
As a company evaluating your security posture while moving to the cloud, you need to reconsider the security control you use currently on-premises and determine if you still need them applied to your systems, within your direct control, and whether or not your current implementation is appropriate.
Intrusion Prevention
A common enterprise security control is an intrusion prevention. This technology evaluates every network package looking for validity (it is what it said it is, like web traffic) and malicious payloads.
On-premises, an intrusion prevention system is typically run by a network security team and it sits on the networks edge.
In the cloud, this design isn’t efficient.
While a cloud service provider might employ the basic functionality of an intrusion prevention system at the edge of each client’s logical network. They would only check for validity (the customer asked for web traffic, make sure only web traffic is allowed through).
More appropriately, an intrusion prevention engine is deployed directly to a virtual machine or instance. This host-based approach is efficient in the cloud as it allows security to scale linearly with the application.
For intrusion prevention systems, the most efficient deployment choices are polar opposites when comparing on-premises vs. the cloud.
Some controls like network segmentation will be best managed by the cloud service provider while others such as anti-malware and encryption are best handled by you, the user.
The key to successful cloud security is understanding the balance of these responsibilities and ensuring that the cloud provider is fulfilling their responsibilities.
Your Data, Your Responsibility
Regardless of the type of cloud service your using or the distribution of security responsibilities, you need to understand how security works in the cloud and various controls are best applied to your deployment.
The Cloud Security Alliance (CSA) has excellent, vendor neutral guidance on this topic available in their publication, “Security Guidance For Critical Areas of Focus In Cloud Computing v3.0”. And there are more and more well research publications on applying security in the cloud being released everyday.
Now that you have a solid understanding of how security works in the cloud and with the new Canadian delivered cloud services, nothing should hold you back from taking full advantage of the business advantages these great technologies offer.
Questions or comments? You can reach me online at markn.ca or on Twitter where I’m @marknca.
I’m also speaking on the panel, “Concurrent Panel Session: Panel A: Cloud Computing: Seeing Through the Cloud, Privacy and Security Implications in the Digital Age” (2:30 Salon AB) at the 17th Annual Privacy and Security Conference in Victoria, B.C., February 3–5, 2016.
The final argument against Canadian businesses moving to the cloud is going away in 2016. This year both Microsoft Azure and AWS are going to start delivering services from Canadian soil.
According to Mark Schrutt, Research Vice-President Services and Enterprise Applications at IDC Canada, “60% of Canadian buyers preferred to have IaaS delivered from within Canadian borders”, the moves by Microsoft and AWS direct address this preference.
This lack of Canadian services and concerns around security have been significant blockers for cloud adoption in Canada.
With the geographic concern gone, security concerns remain. But should they?
A quick scan of AWS and Microsoft Azure reference customers will produce a list of big name brands in a number of industries and geographies.
What do Canadian business need to know about security in order to move safely into the cloud?
Shared Responsibility
Security in the cloud is a responsibility shared by the provider and the consumer.
While Microsoft Azure, AWS, Google, and others might not agree on much, they do agree on this basic model.
This is a very straightforward model in its presentation. We start with the view that security is required everywhere, and in order to manage the security aspects of a deployment, we’ll sort various responsibilities into the following areas:
– Physical infrastructure
– Network infrastructure
– Virtualization layer
– Operating system
– Application(s)
– Data
The next step is to then determine who is responsible for the security aspect of each of these areas: the cloud service provider or the consumer (you, the user).
Depending on the service in question, the answer of “who is responsible for this area?” changes.
The security responsibilities for these areas change depending on the type of service you are consuming. The rule of thumb here is the more options and configuration required for the service, the more direct security responsibilities fall to you.
Being a conscientious (a.k.a., rightfully paranoid) security practitioner, you will want to verify that your provider is holding up their end of the bargain (spoiler alert: Microsoft and AWS are). You can do that by visiting the providers site’s on compliance and security (here is Microsoft Azure’s and here is AWS’)
Partial Trust
While the shared responsibility model is simple to understand, it does come with some significant implications. The biggest of those implications is one of trust.
By using a cloud service provider, you are implicitly extending them a high level of trust.
This is something that needs to be taken into account when evaluating risk to your infrastructure and application deployments.
Failure to properly evaluate this risk will leave you and your data unnecessarily exposed.
Physical Access As An Example
The weak point in digital security has always been physical access to the equipment. When you’re dealing with a cloud service provider, you will **never** have physical access to the systems you’re using.
This means you’re relying completely on the provider for physical security of your system. You’re also trusting them not to abuse the privileged position they are in with respect to having physical access.
A reputable cloud service provider will provide documentation (either public or exclusively to it’s clients) about how something like physical access is handled. They will also provide some form of attestation that they are following the process they’ve setup.
This is why it’s important to verify that your cloud service provider is compliant with any frameworks relevant to your business or SOC 1, PCI-DSS, or ISO 27001 (or all of them).
These three frameworks all provide a strong baseline of verifiable security.
Applied Controls
A common misunderstanding about cloud security is that the security controls you’re familiar with in the enterprise data centre disappear.
When you examine and apply the shared responsibility model, you’ll quickly find that these controls still exist but the day-to-day responsibility for their application and management may have changed hands.
Similarly, the location in which they are applied may also have changed.
As a company evaluating your security posture while moving to the cloud, you need to reconsider the security control you use currently on-premises and determine if you still need them applied to your systems, within your direct control, and whether or not your current implementation is appropriate.
Intrusion Prevention
A common enterprise security control is an intrusion prevention. This technology evaluates every network package looking for validity (it is what it said it is, like web traffic) and malicious payloads.
On-premises, an intrusion prevention system is typically run by a network security team and it sits on the networks edge.
In the cloud, this design isn’t efficient.
While a cloud service provider might employ the basic functionality of an intrusion prevention system at the edge of each client’s logical network. They would only check for validity (the customer asked for web traffic, make sure only web traffic is allowed through).
More appropriately, an intrusion prevention engine is deployed directly to a virtual machine or instance. This host-based approach is efficient in the cloud as it allows security to scale linearly with the application.
For intrusion prevention systems, the most efficient deployment choices are polar opposites when comparing on-premises vs. the cloud.
Some controls like network segmentation will be best managed by the cloud service provider while others such as anti-malware and encryption are best handled by you, the user.
The key to successful cloud security is understanding the balance of these responsibilities and ensuring that the cloud provider is fulfilling their responsibilities.
Your Data, Your Responsibility
Regardless of the type of cloud service your using or the distribution of security responsibilities, you need to understand how security works in the cloud and various controls are best applied to your deployment.
The Cloud Security Alliance (CSA) has excellent, vendor neutral guidance on this topic available in their publication, “Security Guidance For Critical Areas of Focus In Cloud Computing v3.0”. And there are more and more well research publications on applying security in the cloud being released everyday.
Now that you have a solid understanding of how security works in the cloud and with the new Canadian delivered cloud services, nothing should hold you back from taking full advantage of the business advantages these great technologies offer.
Questions or comments? You can reach me online at markn.ca or on Twitter where I’m @marknca.
I’m also speaking on the panel, “Concurrent Panel Session: Panel A: Cloud Computing: Seeing Through the Cloud, Privacy and Security Implications in the Digital Age” (2:30 Salon AB) at the 17th Annual Privacy and Security Conference in Victoria, B.C., February 3–5, 2016.