The debate over whether security is better or worse in the cloud rages on. The vendors say they have the security expertise and protections most companies can neither afford nor effectively implement. Others say that’s nonsense, how can a vendor with less knowledge of customers’ risk profile provide better security?
And, following the Edward Snowden revelations, many CIOs are feeling let down by cloud suppliers who promised them encryption keys would be kept safe from the prying eyes of governments.
It’s no surprise that even those esoteric cloud services that don’t make the headlines can be exploited. Imperva is now warning that database-as-a-service (DBaaS) is a worrying new attack vector.
“In databases, most of the vulnerabilities discovered are privilege escalation related, meaning that you have to have access to the database first, and then you can exploit a vulnerability,” explains Barry Shteiman, director of security strategy at Imperva.
“While on-premise database are isolated, with DBaaS, anyone including a hacker can open an account and have a database sitting on the same infrastructure as retailers and any customer that you can imagine. They already have the login/user account to the server solved – which makes the vulnerabilities in the cloud much more viable as an attack vector.
“Once a hacker compromises a DBaaS, the breach may include any customer data that resides on that infrastructure, which makes the problem exponential.”
As proof this form of attack is genuinely concerning, Shteiman points to the breach of MongoHQ, a MongoDB cloud services provider, from October this year. It reported “attackers were able to use the impersonation feature to access the MongoHQ accounts database, and used connection information to access some customer databases directly”.
It appeared an attacker was on the hunt for social media logins and financial data in customer databases. This was serious business. The FBI was brought in to work alongside forensic experts to determine what went wrong. Employee support applications were completely shut down.
How had the attacker breached the cloud database provider? A simple login leak, resulting from “a credential that had been shared with a compromised personal account”. Once the hacker had that credential for the support application, they were able to use an “impersonate” feature to act as if they were a logged in customer, meaning they could access databases. This kind of illicit acquisition of administrative privileges is precisely the threat Shteiman is worried about.
“Cloud infrastructure introduces collision. All of a sudden different customers share the same infrastructure, which means that any potential breach to either the service provider or one of its customers, may affect all of the service users,” he adds.
The killer line from MongoHQ in its advisory was this: “We still recommend being paranoid.” That’s good advice for all IT chiefs considering moving databases, or anything else for that matter, to the cloud.
Are you a security expert? Try our quiz!
Oracle's huge AI, Cloud investment in Japan will meet growing local demand and address digital…
People who create sexually explicit ‘deepfakes’ of adults will face prosecution under a new law…
Protest at cloud contract with Israel results in staff firings, in addition to layoffs of…
Microsoft warns of Russian influence campaigns have begun targetting upcoming US election, albeit at a…
Microsoft to avoid an EU investigation into its $13 billion investment in OpenAI, after EC…
As President Biden 'considers' request to drop Julian Assange extradition, US provides assurances to prevent…
View Comments
I agree that “Cloud infrastructure introduces collision. All of a sudden different customers share the same infrastructure, which means that any potential breach to either the service provider or one of its customers, may affect all of the service users,” and you need to think twice before storing regulated or sensitive data on public cloud systems.
In many popular public cloud environments, my Data is NOT under my control, NOT in a computer within in my organization and potentially NOT in a country or location that I know about. My Data may NOT even be stored or processed in a compliant way in an accepted country, by a 3rd party and/or cloud provider. I may not have information about who can access my data, maybe administrators or other tenants. I may be sharing disk, memory and other infrastructure components with parties that I don’t know about.
They maybe stealing my data. Therefore I think that all sensitive data should be encrypted or tokenized before it is sent to the cloud.
Below are a few words of guidance from the payment card industry, PCI SSC. The guidance is applicable for all sensitive data that is sent to the cloud.
If you outsource to a public-cloud provider, they often have multiple data storage systems located in multiple data centers, which may often be in multiple countries or regions. Consequently, the client may not know the location of their data, or the data may exist in one or more of several locations at any particular time.
Additionally, a client may have little or no visibility into the controls protecting their stored data. This can make validation of data security and access controls for a specific data set particularly challenging.
In a public-cloud environment, one client’s data is typically stored with data belonging to multiple other clients. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually.
I recently read an interesting report from the Aberdeen Group that revealed that “Over the last 12 months, tokenization users had 50% fewer security-related incidents (e.g., unauthorized access, data loss or data exposure than tokenization non-users”. The name of the study is “Tokenization Gets Traction”.
Ulf Mattsson, CTO Protegrity