Cloud Security Perspectives and Insights

Enhancing EBS Security in Oracle Cloud - Part 4

Paul Toal
Distinguished Solution Engineer - Cyber Security

Welcome to the fourth article in my series on “Enhancing EBS Security on OCI”. We are moving along quite nicely and have covered a lot of ground. After discussing the risks and threats in the first article, the following two articles looked at three of these risks and how you can mitigate them.

So far, we have looked at some of the preventative controls that offer protection for EBS. In this article, we are going to take a break from preventative controls (don’t worry, we’ll come back to them) and shift our focus to look at some of the detective controls you need to consider for your EBS application.


After all, it is critical that you know your EBS application (and the underpinning platform it sits on) is running well, and that, if you do have an issue, that you can quickly identify the root cause and resolve it. Of course, security monitoring isn’t just about availability. Making sure that your configuration has not changed is also crucial. Any change to your configuration, whether malicious or by mistake can have a potential impact. Therefore, monitoring configuration drift is an important operational aspect of EBS (and any enterprise application). I am sure that i’m not telling you anything new at this point.

We know that EBS teams regularly spend more than half of their effort on keeping the lights on, with 75% of end-user issues being reported by end-users themselves. Not a great user experience! We also know that it can be time consuming to diagnose issues in enterprise applications like EBS. For many organisations that currently run EBS, or any critical Oracle technology or apps, they will most likely be using Oracle Enterprise Manager (OEM) and the comprehensive set of management packs available to monitor EBS when it is deployed on-premise.

Of course, when moving EBS to the Cloud it is possible to continue using OEM. There are a few options for how you might do this:

  1. Leave OEM on-premise and point it at your EBS deployment in the Cloud. If you have a data centre exit strategy or similar, then this will not be the most attractive option for you.
  2. You could also move your OEM to the Cloud. There are two different approaches for doing this.
    1. You can, of course, spin up some compute and install OEM just as you would do for an on-premise installation.
    2. A more attractive approach might be to use of the OCI OEM Marketplace image, which will give you a pre-installed installation of OEM, ready to use. This is a much quicker and simpler approach than doing your own installation.



However, in-line with our earlier discussion around move and improve vs lift and shift, EBS monitoring is one of the areas where improvements and simplification can be obtained as part of a move to Cloud for EBS.

You also need to be aware that you are not just monitoring EBS and its associated components such as database, but you also need to monitor the Cloud platform that it is running on. i’m not talking about the operating system (OS) here. Yes, you need to monitor that, but I count that in ‘associated components’ above. No, what i’m referring to is the Cloud platform itself. Administrators of the Cloud platform are the users who can make changes such as spinning up new compute nodes, changing networks, adding firewall rules etc. Yes, the IAM policies within your Cloud platform will ensure that users are only authorised for the access they require, but you should still have sufficient monitoring in place to check that, firstly, you have configured your policies correctly, secondly, that administrators aren’t doing things they shouldn’t, or third, ensuring that administrator credentials haven’t been compromised and being used by a malicious actor.

Therefore, if we divide up our monitoring requirements, we can see two distinct areas:

  1. EBS stack – Everything associated with the EBS application itself, including OS, database, middleware, application, user experience etc.
  2. Cloud Platform – The monitoring of the infrastructure that all of the EBS

Let us look at the EBS stack first and how the Cloud can help us ‘move and improve’ our monitoring. One approach is Oracle Management Cloud (OMC). This is 100% cloud native management and monitoring platform, with deep integrations for Oracle technology, including OCI, Oracle Database, and Oracle applications such as EBS. OMC works by ingesting all the data you need into one place, eliminating silos. It then analyses, using machine learning capabilities, to optimise EBS. Smart automation then allows you to remediate issues.


From an EBS perspective, it provides a whole bunch of capabilities. It starts with the initial discovery. From a single click, OMC can automatically discover your entire EBS application landscape, including the app and database tiers, concurrent manager service, workflow engine, and forms system. It has topology awareness, so understands the relationships between the different components. Once EBS has been discovered, OMC provides end-to-end monitoring, including application instrumentation, metrics and log data. Pre-built EBS dashboards including health and concurrent manager dashboards provide you with a high-level information such as:

  • Status of all entities and any current alerts
  • Monitoring of jobs’ progress
  • Transactions failures, DB errors, Middleware error
  • CPU/memory resource usage across all nodes in the application
  • Distribution of job failures by failure type



Of course, you can drill-down from the dashboard to enable rapid root cause identification and analysis. You can also customise the existing, or build your own dashboards. In addition, OMC also provides real user experience testing and monitoring to identify metrics like response times. You can test a wide range of factors including transactions, pages, and jobs. You can test from different geo-locations, and you can baseline response times using machine learning. All of this will help you discover application bottlenecks and performance degradation before end users do, so you can take corrective action before that degradation becomes a business issue.

Machine learning plays a powerful role within OMC, especially around KPI monitoring, where machine learning automatically builds baselines of metrics to keep an eye on everything going on in your application.

Finally, OMC can actually help you to de-risk your move and improve journey. You can use OMC to build a pre-migration baseline, looking at what is normal (e.g. performance, behaviour, and seasonality) and what the growth patterns look like. You can then compare that to a post-migration analysis, so that you can compare your Cloud vs your on-premise baseline. Utilising OMC to de-risk your move and improve allows you to:

  1. Define on-premise performance baseline using OMC Application Performance Monitoring and Infrastructure Monitoring. This will inform your SLAs.
  2. Understand on-premise resource needs using IT Analytics to inform your Cloud sizing.
  3. Compare your lifted application performance against the on-premise baseline to help justify the move
  4. Ongoing maintenance of the moved IaaS estate to help maximise value.

That takes care of the EBS monitoring. Now we need to consider the Cloud Platform monitoring. This is where you need to start looking at capabilities such as a Cloud Access Security Broker (CASB). These are optimised for cloud environments and give you a number of security capabilities.

One option available to you is Oracle CASB. This is another 100% cloud native application with tight integration with Oracle Cloud. For your EBS environment in the Cloud, it provides some key security controls:

Enforce security policy to meet your compliance needs

How do you know that your Cloud platform meets your security policy and compliance needs? You might have configured a tightly secured platform initially, but is it still secure? Are you monitoring for, and can you answer questions like:

  • Are your SSH keys for your compute instances been rotated regularly?
  • Has anyone changed the network configuration of your EBS environment?
  • Have the firewall rules been changed?
  • Has someone changed a storage bucket to make it public when it should be private?
  • Has MFA been enabled for all power users?

These are the types of questions that Oracle CASB provides you an answer to using a combination of rich out-of-the-box policies, as well as a powerful policy engine for creating your own policies.

Detect mis-use of admin privileges with machine learning

What are your administrators doing within your Cloud environment is an important question any auditor will want to know. In addition to the above policy-driven monitoring, Oracle CASB uses powerful machine learning to build baselines of user’s (i.e. administrators) behaviour. It then identifies discrepancies from that baseline. This will allow you to identify authorised administrators potentially doing dangerous activities, but it will also enable you to identify scenarios such as account compromise. If an administrator is logging in from a strange location compared to their normal access, or at a strange time, CASB would notice that and raise an appropriate alert that feds into your existing SOC.

As I mentioned at the outset, monitoring is crucial to ensuring the availability and security of your applications. Multiple considerations need to be taken into account to ensure that you are looking at your monitoring requirements holistically.

From Oracle’s perspective, we have a strong set of capabilities, optimised for Oracle applications, infrastructure and Cloud. Why wouldn’t you be using Oracle to monitor Oracle. After all, we know Oracle best.

I hope you liked this article and found it useful. If so, then stay tuned for the next exciting instalment.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.