Digging into the cloud security arguments of the Capital One data breach
In this guest post, Dob Todorov, CEO and chief cloud officer, HeleCloud, sets out why it is wrong to declare cloud not fit for business use in the wake of the Capital One data breach.
In two separate statements last week, Capital One announced a data breach involving a large amount of customer data, including credit card information and personal information, stored on the Amazon Web Services (AWS) Simple Storage Service (S3).
The data breach, understandably, sparked a flurry of media interest, resulting in a broad set of statements and interpretations being communicated from many different individuals. Yet, one claim that received an unfair amount of momentum around the Capital One data breach was that it highlights cloud is not secure enough to support businesses.
Here it is important to separate fact from opinion. The truth is, security incidents (including data and policy breaches) happen every day, both in the cloud and conventional datacentre environments. While some get detected and reported on, like the recent Capital One or British Airways breaches, most incidents, unfortunately, go unnoticed and unaccounted for.
The cloud provides businesses with an unprecedented level of security through the visibility, auditability, and access control to all infrastructure components and cloud-native applications.
Cloud is secure and fit for business
With more than fifty industry and regulatory certifications and accreditations, it is worth calling out the AWS public cloud platform for an unrivalled level of security standards – far beyond that offered by any on-premise solution. So, what went wrong for Capital One?
Such a powerful and natively secure platform still requires organisations to architect solutions on it, configure it and manage it securely. While the security of the cloud is the responsibility of platform providers like AWS, security in the cloud is the responsibility of the users.
For example, based on the available information, it appears that while Capital One had encrypted its data within an AWS S3 bucket to protect confidentiality using the default settings, it made the false assumption that this would protect the personal information against any type of unauthorised access.
What’s more, it appears that specific AWS S3 access control policies were not configured properly, thus allowing either anonymous access from the internet or by using an application with wider than required access permissions. Having the right access policies in place is crucial to protecting resources on AWS S3.
Diary of the Capital One data breach
While the data breach was uncovered by Capital One in July 2019, the data was first accessed by an unauthorised source four months earlier, in March 2019. Given the visibility that AWS provides, including real-time monitoring, Capital One should have detected and contained the incident in real-time. Such capabilities do not exist outside the AWS platform, so having the capabilities and not using them is unacceptable.
In a statement released by the firm, Capital One recognised the limitations of their specific implementation and confirmed the mistakes and omissions made were due to the configuration of the AWS platform.
Such mistakes would have led to a similar outcome event if their systems were in conventional datacentres. The firm stated: “This type of vulnerability is not specific to the cloud. The elements of infrastructure involved are common to both cloud and on-premises datacentre environments.”
Rooting out the weakest link
When it comes to security, businesses are only as strong as the weakest link in the system. The root cause can vary from the configuration of technologies to processes that support insecure practices, to something as simple as human error due to a lack of knowledge, skills, experience.
Of course, there are also cases where humans have deliberately caused incidents for economical gain. However, whether in the cloud or on-premises, all aspects must be taken into consideration and no area left ignored or underinvested when architecting for system security.
Five steps to a secure cloud
To ensure that this does not happen, there are five security and compliance principles that experts insist every business follows. Firstly, all security and compliance efforts require a holistic approach – people, processes and technologies.
Each of these three areas plays a significant part in the processing and protection of data, thus all three must be considered when evaluating your level of security.
This brings us on to the second principle: minimise human impact. Whether deliberate or accidental, most security breaches within businesses are caused by humans. Businesses should invest in more automation to improve the security of systems.
Thirdly, detection is extremely important. Not knowing that an incident has occurred does not eliminate its impact on the business or customers. Sadly, many remain unaware of the incidents that have taken place within their businesses.
The fourth principle seems simple but is often overlooked: security is an ongoing requirement, one that requires maintenance for the whole life span of a system. Lastly, encryption is not always the answer to data protection. Encryption helps to solve a very specific problem: confidentiality. Simply encrypting data, regardless of the algorithms and keys used, does not necessarily make the system more secure.
Cloud is both a very powerful and secure IT delivery platform. To ensure that they are benefiting from these capabilities, businesses must configure their chosen cloud platform to their needs.
Despite cloud skills still not being at the levels they need to be in the UK, many specialist partners exist to ensure that the businesses have the knowledge and experience needed to become more secure than anywhere else via the cloud.