I have discussed in previous articles how many customers I talk to who are looking at ‘lifting and shifting’ E-Business Suite (EBS) from running in on-premise data centres, into the Oracle Cloud. There are a number of benefits of adopting a lift and shift approach versus upgrading to SaaS. And for some customers, upgrading to SaaS isn’t an option. However, these have been discussed at length in other articles, so I won’t cover them here. If you are interested, you will find such articles here, here, here, and here.
What I do notice (and spend a lot of time talking about) is the different risks that a cloud-based deployment of an enterprise application like EBS has, and how additional security controls should be considered to reduce these risks.
Therefore, I have decided to write a series of articles on how you can “Enhance EBS Security in OCI”, looking at the different risks and the mitigating controls that should be adopted, of course, highlighting how Oracle technology and cloud services can help along the way. What I am essentially talking about is changing from a ‘lift and shift’ to a ‘move and improve’ strategy.
This is the first article in this series and will cover an overview of the different risks. Before I start, it’s worth reminding you of the mutual shared security responsibility model that is applicable to all Cloud environments, irrespective of which Cloud provider you use.
You will no doubt have seen similar versions of this a hundred times, but it’s a reminder that when you are moving an enterprise application into the Cloud, you are mainly using Infrastructure (IaaS) and possibly some Platform (PaaS) services. It isn’t a SaaS model and therefore a significant proportion of the security responsibility will rest with you, the customer.
I’m not going to focus in this article on why security is important and the impact of a security failure. There are plenty of news articles covering data breaches and data misuse stories for you to be clear on the importance of security and what happens when that security fails. Instead, I’m going to focus on the threats and risks. First, let’s understand where the threats are coming from. In short, everywhere…
We see external threats, where attackers are typically trying to steal or manipulate your data or take your application offline to affect its availability. It’s not just threats from the outside though; the internal threat is also significant. We see authorised users stealing data, but also authorised users, especially privileged users, being the target of social engineering attacks, or account takeover. After all, if an attacker is going to gain any account via social engineering, why not go for the highly privileged accounts! In addition, we see threats coming outside of the application, for example, through the network or the hardware. Coupled with the top-down threats highlighted above, such as malware or code injection attacks, these all make your data and your applications vulnerable.
Of course, not all of these are unique challenges to your enterprise application in the Cloud. A lot of these same threats occur when your application is on-premise. The level of risk will depend on how up to date and comprehensive your existing security controls are. I see too many examples of organizations where that isn’t the case. One of the interesting benefits of the cloud is that, in many cases, aging infrastructure, unpatched software, complex networks, mean that moving your application into the cloud makes it more secure than it was on-premise.
So, what are the attack vectors that you need to think about when you move your application? I have put them into 8 main areas.
Let’s look at the first attack vector, Infrastructure Attack, meaning that the attack looks for weaknesses in the cloud infrastructure itself. This is a very broad topic in itself, but can include attacks such as hypervisor breakout, network compromise, and storage compromises. Of all the attack vectors above, this is the one where the cloud provider security responsibility plays a key role in the mitigation of these risks.
Oracle has built its 2nd generation, Oracle Cloud Infrastructure (OCI) with security at its core. Deep customer isolation, strong networking isolation, operational segregation, and demonstrable compliance are just some of the areas where OCI stands out. You can read much more about OCI security here.
However, even within the Infrastructure Attack vector, it’s not all down to the Cloud provider. As a customer, you are responsible for configuring much of the security within your Cloud environment, in areas such as networking, firewalls, and OS security (including patching). Within these areas, the Cloud provider can help by providing easy to use tooling that enables you to configure the security controls properly, and not making the tools difficult to use, risking the chance that you may configure them incorrectly and leave risks un-mitigated.
Taking a joint, shared security responsibility for your enterprise application deployment will ensure that you are minimising the risk of an attack on the infrastructure.
Look out for the next article, where I will look at user authentication and authorisation,