A private cloud poses few fresh problems, but going to a public cloud has three major risk factors for a firm.
In my last column, ‘Clouds on the horizon' (SC, March), I discussed the growth of cloud computing in the UK and the business reasons driving it. With all of the media hype about how great cloud computing is, it is interesting that there are also statements that security is the number one concern. But, what does that mean for information security practitioners? If business units want to use cloud computing, our responsibility is to determine whether clouds are secure.
A good place to start is infrastructure security – specifically, network-level security of a company.
Looking at this network level of infrastructure security, it is important to distinguish between public clouds (shared among multiple entities or customers) and private clouds (single provider and single-user entities). With private clouds, there are no changes in risk specific to this topology to be considered. While your IT architecture may change with a private cloud, there will probably be no significant changes to your network topology. Security considerations you have today apply to private cloud too.
However, changes to an infrastructure security's network level brought about by using a public cloud do involve changes, specifically, how your network topology interacts with the network topology of your cloud provider(s). There are three significant risk factors.
The first is ensuring confidentiality and integrity of your data in transit to and from your cloud provider(s).
Second, ensuring proper access control (authentication, authorisation and auditing) to whatever resources you are using at your cloud provider. Since subsets of resources are exposed to the internet, an organisation using a public cloud now faces a significant increase in risk to its data.
Third, ensuring availability of internet-facing resources, in a public cloud, that are being used by your organisation, or have been assigned to you by your cloud provider(s).
None of these three risk factors is new. What is new in this case is that the risk level associated with each increases significantly. That increase in risk is due to several factors. Resources and data previously confined to a private network are now exposed to the internet and to a public (shared) network belonging to a third party cloud provider.
Your organisation's direct ability to control – or even influence security controls to mitigate the increase in risk of the three factors above – is diminished. Your ability to audit the operations of your cloud provider's network is probably non-existent. And you can forget any real-time monitoring, such as on your own network (eg decreased access to relevant network-level logs data and ability to conduct investigations and gather forensic data).
Your reliance on network security has grown, as an increased amount of data and/or some increased number of personnel are dependent on network security to ensure the availability of cloud-provided resources, while the three risk factors must be acceptable to the organisation.
So, although your network topology might not have changed, there are significant differences with the use of a public cloud, starting with operational control. Who operates the network and the security devices protecting it? What access do you have to the information derived from those security devices? With use of public cloud, these relationships change.
Operational control then leads to a significant second difference: with public cloud computing, where are the trust boundaries? And who defines them?
Other factors that impact on network-level security need to be considered. For example, what does the service level agreement with your cloud provider look like? And, what is the organisational burden of these changes on your own personnel?
All of these factors have a significant impact on providing assurance.
Those are just some of the network-level considerations that IS professionals should be thinking about in connection with public cloud computing. In my next column, I will move up the “stack” to host-level considerations.