A 2015 IBM report on the cost of corporate data breaches found that the average cost of a breach was $3.79 million (£2.4 million), that breaches were up by a quarter since 2013, and amazingly the per capita cost has increased by over 10 per cent.
As a consequence of both the increasing volume and the growing interest of media outlets in cybercrime, enterprises are grappling with the question of how to secure their applications, data, and users in the cloud.
However, their ability to understand and consider these threats, and create suitable defenses and responses, is hampered by a number of cloud security myths - with security generally accepted as the number one barrier to adopting cloud.
To debunk cloud security myths, each organisation needs to explore the following statements:
1. Cloud is insecure
The perception that there are more breaches in the cloud, or that public clouds are attacked more than private clouds, is not supported by research. In fact, malware is more likely to attack non-cloud systems than those in the cloud.
Reading any of the annual reports on data breaches shows that they happen to systems regardless of their location – on-premise or cloud. The route that hackers generally take is not to attack a Cloud API, but to attack the Human API through social engineering.
On the technology side, ever since virtualisation became ubiquitous, hackers have tried to break hypervisors and VLANs – but these are robust technologies used on-premise, as well in all clouds, and they are practically impossible to crack. If there was a related exploit, then it would apply to all non-cloud and cloud platforms.
Then there is “tenant terror” – the phobia of sharing a platform. Public clouds inherently use multi-tenant resource pooling to share compute, storage, and network amongst non-related tenants. These mechanisms are over a decade old, constantly improving, and are widely accepted by even the most risk-averse government organisations. However, also bear in mind that even the risk-averse organisations that don’t use resource pooling still have breaches – people remain the biggest, weakest point, not technology. Organisations are as much at risk from their own staff in single-tenant environments – many breaches are due to either staff credentials being compromised or rogue staff activities.
Public clouds are often also perceived as insecure because they are “outside the firewall”, but being inside the firewall in the age of the borderless network, and the reduced efficacy of perimeter firewalls, means that whether you are in public or in private, if you are on the network then you have an attack surface regardless of location.
2. Cloud security is simple
Cloud security can be perceived as simple (not to a beginner, but to someone familiar with cloud mechanisms) because, thanks to self-service, an organisation can control their own public cloud security policy without relying on cloud service provider staff.
Security policies such as identity and access management are all self-service. In fact, compared to the often organically grown and opaque enterprise security systems, the transparency of cloud security can be beguiling.
However, cloud controls are not the only important facet for cloud security – visibility is probably more crucial. Where this gets difficult is in achieving a view across non-cloud and cloud systems, made more vital if these systems interact. This leads to an approach of “let’s make cloud security simple by buying a product.”
The problem with this solving-security-by-product approach is that the complexity has gone up, not down, by the introduction of a new tool that might be aligned with old practices that are incompatible with cloud complexity. A fool with a tool is still a fool.
3. I’m safer with on-premise
Perimeter security defenses, such as firewalls that allow/block network traffic based on protocols, haven’t been enough on their own for a number of years now. Yet people still persist with the thinking that they are safe behind their firewalls. People and process discomfort with the cloud can also naturally lead to a “let’s deploy on-premise because it’s safer because we know what we are doing” approach.
However, if you read any data breach report from the past few years, the facts completely contradict this thinking – breaches happen mostly via human hacking (to steal their credentials), not network hacking. Thus the location of your applications and data does not defend you from hacking.
Nonetheless, this idea can be true if your cloud security capabilities are truly lacking. If you let people in the organization access root account credentials, if your organisation doesn’t apply OWASP application security (the same whether on cloud or not), and if you don’t study, learn, and apply the latest cloud security practices – then yes, it’s probably safer on-premise. But this is a reflection on the organisation’s cloud security capabilities, not the cloud itself.
4. I’m not in control of my data with cloud
Data sovereignty is a classic myth in that it’s a mix of truth and fantasy with vocal protagonists from all sides. Plus it comes in several sizes and colours. You have to read the legal details to truly understand it, but it’s not just as simple as which region your data lives in but also the headquarter location of the cloud provider that runs the cloud in your region. American cloud providers are currently fighting legal battles in the US that relate to US authorities forcing US cloud companies to hand over data held outside the US. Although there are already legal agreements in place to allow this to happen anyway.
If you must have your data in specific regions, then you can get that location by picking a specific cloud service provider – as the leading public cloud players are now truly global in their data center locations. However, if they don’t have the location you need, then a regional cloud provider might work better for you – but you will have another provider to manage and a different service experience to deal with. Also beware of the regional providers that play on the sovereignty myth.
When it comes to storage, the resource pooling nature of public clouds is interesting - because one piece of your data might be replicated three times in one location, and then replicated again in another site another three times within the same region. You don’t control this replication, it’s an inherent availability mechanism that one would think was good for security (and it is), but...
People who believe the “I’m not in control of my data” myth will see this replication mechanism as a security downside and worry that faceless cloud administrators will be harvesting their data for ill-gotten-gain. To comfort such people, point them at the data-at-rest and in-transit encryption methods used, for which the cloud service provider doesn’t have the keys, and to the provider’s standard operating procedures for accessing customer information.
5. My cloud service provider is totally responsible for cloud security
The allure of cloud certifications proudly displayed on public cloud service provider websites lulls some organisations into a false sense of security. Certifications are good things but they are merely a snapshot in time. They have to be there, but you will always need more.
Thankfully, the shared responsibility model has brought clarity to who is responsible for what in the cloud, but when it comes to accountability the buck stops at the customer organisation. And when it’s cloud security, it should be the Chief Security Officer not the cloud service provider.
For the pieces that the cloud service provider is responsible for, like the infrastructure, this is their bread-and-butter and they thus invest huge amounts of talent and money in doing the right things and in doing them better than everyone else. Security is no exception.
For the pieces that the customer organisation is responsible for, like the applications, data, and users that consume the cloud, the organisation has to put the right people, processes, and technology in place to be capable and responsible for their part of the security equation.
And, to reiterate, the customer organisation’s Chief Security Officer is where the buck stops for everything.
Chief security officers need to bust these myths
The great management thinker, Peter F. Drucker, once said, “Management is doing things right; leadership is doing the right things.”
To lead with cloud security, an organisation’s Chief Security Officer needs to foster open debate to uncover and deconstruct these cloud security myths, and others, which are distinctive to their organisation.
Cloud security effectiveness is ultimately based on blasting through the myths and establishing an organisation’s unique appetite for risk, and from there – developing appropriate capabilities to ensure that the risks are effectively managed.
Sarah Lahav, CEO of SysAid Technologies