While shifting to the public cloud has big benefits for companies, Soteryan’s Salim Neino warns that it can also open up a back door to their data and undo the good work done securing on-premises data centres.
At the end of last year Oracle’s controversial CTO, Larry Ellison, said: There’s “no way a ‘normal’ person would move to AWS… you’ve got to be willing to give up tons of reliability, tons of security, tons of performance… Nobody, save maybe Jeff Bezos, gave the command, ‘I want to get off the Oracle database.’”
While clearly aimed at Amazon’s move to dump Oracle databases in favour of their own AWS databases, he does raise an interesting spectre. Oracle databases have been around for a long time, the technology is well developed and users are familiar with their operation and have built working practises around them. AWS databases are a new proposition, one that IT departments are not so familiar with. This is similar to some of the issues companies are likely to come across when they move over to public cloud.
By moving to a public cloud environment, you’re introducing a completely new infrastructure and framework, alongside a combination of new factors that can happen to substantially increase your risk. Ellison’s point in some ways was borne out by reports of security issues around Amazon’s Route 53 DNS service, where companies using the service found they were inadvertently exposing their assets. The point being this is just one example of Amazon security issues.
We’re not saying that moving to public cloud is a bad thing, or in anyway trying to suggest companies don’t move the public cloud. There’s nothing wrong with it, and companies are definitely heading in the right direction. The issue is that it’s just insecure if you don’t have the right guidance. It can be a very treacherous path to go down. Undisciplined or ill-informed use of cloud architectures can be very dangerous.
A prime example of this being number of controversies around “leaky S3 buckets”, that were highlighted after their introduction in 2017. Many people will remember the controversy surround WWE when it was accused of leaking personal details on fans. Instead of discovering a breach had happened, it was revealed that the issues had arisen because an admin had left the database set to public when it should have been set to private.
The harsh reality is that it’s really easy to mess up what you don’t know because you didn’t build the platform.
With cloud infrastructure, you’re adopting someone else’s (Google’s, Microsoft’s or Amazon’s) infrastructure and their policies and procedures. These may well be solid, but they are going to work differently to the policies you have set up for your own on-premises data centres.
This introduces a lot of risk, because of new systems and assumptions you have made that may not be true, such as around the systems’ vulnerabilities and design flaws. Amazon acknowledge this with the AWS shared responsibility model which sets out that AWS will ensure the integrity of the infrastructure, it’s the responsibility of the company itself to understand the threats to their data and ensure they have the right defences in place to fully protect it.
At the moment everyone is moving so fast towards public cloud and adopting it because it works and it’s good, but we’re ignoring the security portion. While many companies already claim to have done security reviews of the infrastructure from an internal perspective, they really need to be getting external specialists to do that design review and analyse those risks – and that also includes third-party applications that you’re purchasing that run in the same cloud system. This is still a relatively new area, and internal skillsets are very likely to fall short when it comes to having the depth of understanding necessary to really be able to evaluate risks.
If you as a company haven’t done your due diligence effectively, then you are potentially opening up a back door to your data and sitting on a ticking time bomb.