Earlier this month as part of the Virtual Oracle Developer Meetups, we were very fortunate to have Oracle Ace, Martien van den Akker present on the subject of the magic of correlations in SOA, BPM, and Oracle Integration Cloud. Martien not only presents to the Oracle community but also is very active on the Oracle community sites (community.oracle.com and Cloud Customer Connect) sharing his wealth of knowledge. When it comes to the tough questions about Oracle middleware tech on these platforms, you stand a good chance that Martien will be the one answering your question.
This insightful presentation not only addressed the traditional Oracle Integration approach using SOA and BPM but also contrasted the capabilities as provided by Oracle Cloud. Martien was generous enough to allow us to record the presentation and share it (below), along with the demo resources from:
With the impact of Covid19 on the Meetup community really hitting, the Oracle Developer Meetups across Europe have got together and gone on-line. We’re several events in now, whilst Lucas Jellema (AMIS) and Rolando Carrasco (SPS) are leading the charge with a great series of sessions focusing Oracle Cloud Native services complete with practical labs.
Today was one of my sessions, whilst I only co-hosted, we got to hear a great presentation with a heart warming story which in this challenging times seems all the more appropriate. Christian McCabe (Steltix) and Filip Huysmans (Contribute) presented on how a multinational hackerthon spanning South Africa to Belgium was put together to only help children of Christel House (a charity who work to provide education to those who would not normally get access to it). Not only was the hackerthon engineered to given the students a chance to learn and experience software development in a pretty realistic context, it also provided the school with some software to help their everyday activities, in this case managing books in their library.
The hackerthon yielded a lot of successful outcomes (Steltix wrote about it here), but, what was really interesting is that whilst working with the school, children and interns (from both Steltix and Contribute) took a lot lessons away as well.
Finally we should thank Geertjan Wielenga who facilitated and supported the development of the hackerthon.
If you want to know more about the virtual meetups then check our meetup page (https://www.meetup.com/Oracle-Developer-Meetup-London) for both virtual events, and when things change so we can all be a lot closer and be sharing pizza again.
A couple of years ago I got to discuss some of the design ideas behind API Platform Cloud Service. One of the points we discussed was how API Platform CS kept the configuration of APIs entirely within the platform, which meant some version management tasks couldn’t be applied like any other code. Whilst we’ve solved that problem (and you can see the various tools for this here API Platform CS tools). The argument made that your API policies are pretty important, if they get into the public domain then people can better understand to go about attacking your APIs and possibly infer more.
Move on a couple of years, Oracle’s 2nd generation cloud is established an maturing rapidly (OCI) and the organisational changes within Oracle mean PaaS was aligned to SaaS (Oracle Integration Cloud, Visual Builder CS as examples) or more cloud native IaaS. The gateway which had a strong foot in both camps eventually became aligned to IaaS (note that this doesn’t mean that the latest evolution of the API platform (Oracle Infrastructure API) will lose its cloud agnostic capabilities, as this is one of unique values of the solution, but over time the underpinnings can be expected to evolve).
Any service that has elements of infrastructure associated with it has been mandated to use Terraform as the foundation for definition and configuration. The Terraform mandate is good, we have some consistency across products with something that is becoming a defacto standard. However, by adopting the Terraform approach does mean all of our API configurations are held outside the product, raising the security risk of policy configuration is not hidden away, but conversely configuration management is a lot easier.
This has had me wondering for a long time, with the use of Terraform how do we mitigate the risks that API CS’s approach was trying to secure? But ultimately the fundamental question of security vs standardisation.
Mitigation’s
Any security expert will tell you the best security is layered, so if one layer is found to be vulnerable, then as long as the next layer is different then you’re not immediately compromised.
What this tells us is, we should look for ways to mitigate or create additional layers of security to protect the security of the API configuration. These principles probably need to extend to all Terraform files, after all it not only identifies security of not just OCI API, but also WAF, networks that are public and how they connect to private subnets (this isn’t an issue unique to Oracle, its equally true for AWS and Azure). Some mitigation actions worth considering:
Consider using a repository that can’t be accidentally exposed to the net – configuration errors is the OWASP Top 10. So let’s avoid the mistake if possible. If this isn’t an option, then consider how to mitigate, for example …
Strong restrictions on who can set or change visibility/access to the repo
Configure a simple regular check that looks to see if your repos have been accidentally made publicly visible. The more frequent the the check the smaller the potential exposure window
Make sure the Terraform configurations doesn’t contain any hard coded credentials, there are tools that can help spot this kind of error, so use them. Tools exist to allow for the scanning of such errors.
Think about access control to the repository. It is well known that a lot of security breaches start within an organisation.
Terraform supports the ability to segment up and inject configuration elements, using this will allow you to reuse configuration pieces, but could also be used to minimize the impact of a breach.
Of course he odds are you’re going to integrate the Terraform into a CI/CD pipeline at some stage, so make sure credentials into the Terraform repo are also secure, otherwise you’ve undone your previous security steps.
Minimize breach windows through credentials tokens and certificate hanging. If you use Let’s Encrypt (automated certificate issuing solution supported by the Linux Foundation). Then 90 day certificates isn’t new.
Paranoid?
This may sound a touch paranoid, but as the joke goes….
Just because I’m paranoid, it doesn’t mean they’re not out to get me
Fundamental Security vs Standardisation?
As it goes the standardisation is actually a dimension of security. (This article illustrates the point and you can find many more). The premise is, what can be ensured as the most secure environment, one that is consistent using standards (defacto or formal) or one that is non standard and hard to understand?
The second part of a two part article about the sort of things an Ace Associate or anyone else in a Technology Advocacy programme such as the Ace & Groundbreakers could approach social media has been published.
You can check part 1 (http://www.oraworld.org/home/ – page 15) along with other articles in the 19th edition of OraWorld covering subjects as diverse as Open World, Apex and Spam (read and you’ll understand).
I’d like to thank my colleagues, particularly James Neate for the inspiration behind this article.
A few weeks ago Oracle announced a new tool for all Oracle cloud users including the Always Free tier. Cloud Shell provides a Linux (Oracle v7.7) environment to freely use ( (within your tenancy’s monthly limits) – no paying for VM or using your limited set of VMs (for free-tier users) or anything like that.
As you can see the Shell can be started using a new icon at the top right (highlighted). When you open the shell for the 1st time, it takes a few moments to instantiate – and you’ll see the message at the top of the console window (also highlighted). The window provides a number of controls which allows you to expand to full screen and back again etc.
The shell comes preconfigured with a number of tools, such as Terraform with the Oracle extensions, OCI CLI, Java and Git, so linking to Developer Cloud or GitHub for example to manage your scripts etc is easy (as long as you know you GIT CLI – cheat sheet here). The info for these can be seen in the following screenshots.
In addition to the capabilities illustrated, the Shell is set up with:
Python (2 and 3)
SQL Plus
kubectl
helm
maven
Gradle
The benefit of all of this is that you can work from pretty much any device you like. It removes the need to manage and refresh security tokens locally to run scripts.
A few things to keep in mind whilst trying to use the Shell:
It is access controlled through IAM, so you can of course grant or block the use of the tool. Even with access to the shell, users will need to obviously have to have access to the other services to use the shell effectively.
The capacity of the home folder is limited to 5GB – more than enough for executing scripts and a few CLI based tools and plugins – but that will be all.
If the shell goes unused for 6 months then the tenancy admin will be warned, but if not used, then the storage will be released. You can, of course, re-activate the Shell features at a future date, but of course, it will be a blank canvas again.
For reasons of security access to the shell using SSH is blocked.
The shell makes for a great environment to manage and perform infrastructure development from and will be a dream for Linux hard code users. For those who like to be lazy with a visual IDE, there are ways around it (e.g. edit in GitHub) and sync. But power users will be more than happy with vim or vi.
The first part of a two part article about the sort of things an Ace Associate, or anyone else in a Technology Advocacy programme such as the Ace & Groundbreakers could approach social media has been published. Go check it out (http://www.oraworld.org/home/ – page 15) along with other articles in the latest edition of OraWorld covering subjects as diverse as Open World, Apex and Spam (read and you’ll understand).
I’d like to thank my colleagues, particularly James Neate for the inspiration behind this article.
To varying degrees, most techies are aware of the security vulnerabilities identified in the OWASPTop 10 (SQL Injection, trying to homebrew Identity management etc), although I still sometimes have conversations where I feel the need to get the yellow or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.
This, later attack Is not a new risk, as you can see from the following links, been recognised by the security community for some time (you can find academic papers going back 10+ years looking at the security risks for Yum and RPM for example).
But software is becoming ever more pervasive, we’re more aware than ever that maintaining software to the latest releases means that known vulnerabilities are closed. As a result, we have seen a proliferation in mechanisms to recognise the need to update and deploying updates. 10 years ago, updating frameworks where typically small in number and linked to vendors who could/had to invest in making the mechanisms as a secure as possible – think Microsoft, Red Hat. However we have seen this proliferate, any browser worthy of attention has automated updating let alone the wider software tools. As development has become more polyglot every language has its central repos of framework libraries (maven central, npm, chocolatey ….). Add to this the growth in multi-cloud and emphasis on micro deployments to support microservices and the deployment landscape gets larger and ever more complex and therefore vulnerable.
When it comes to development, we have had coding standards for almost as long as we have been coding. We tend to look at coding standards for purposes of helping to promote good quality code and reduce the likelihood of bugs and so on. But they also help with readability, making it easy to navigate a code base and so on. This is sufficiently important that there is a vast choice of tools to help us ensure we align with good practices.
That readability etc, when it comes to code interfaces lends to making it easier to use an interface as it promotes consistency and as Don Norman would say avoids ‘cognitive load‘, in other words, the effort involved in performing actions with the interface. Any Java Developer will tell you, want to print out an object (any object) you get a string representation using the .toString() method and direct it using the io packages.
That consistency and predictability are important not just for code if you look at any API best practises documents you’ll encounter directly or indirectly the need to use conventions that drive consistency – use of singular or plural for the name of entities, application of case – camel case, snake case etc. Good naming etc and we’ll see related things appear together in the documentation. Products such as Apiary and SwaggerHub include tooling to help police this in our API design work.
But what about policies that we use to define how an API Gateway handles the receipt and routing of API invocations? Well yes, we should have standards here as well. Some might say, governance gone mad. But gateways are often shared services, so making it easy to see and logically group APIs together at very least by using a good naming convention will help as a minimum. If API management is being administered in a more DevOps fashion, then information security professionals will probably want assurance that developers are applying policies in a recommended manner.
This year’s UKOUG TechFest 19 conference is over. The first time in a number of years where the user group conference hasn’t been a combined Tech, Apps and JD Edwards event. I have to admit that I was a little concerned with the separation of Tech and Apps as some of the tech stack overlaps for the two groups – for example, Integration Cloud.
That said, the situation being what it was, I got involved with the committee for planning the event including inheriting the stream lead responsibilities for Dev (in the sense of modern development e.g. microservices etc) and what had been historically referred to as middleware (Integration Cloud, Digital Assistant, Helidon, WebLogic) with a lot of support and input from Mark Simpson, Grant Ronald and Susan Duncan.
From my perspective, I don’t think there was a concern (and this isn’t an attempt at being self-congratulatory) as the hard graft is done by the UKOUG office staff.
As the number of people was smaller, we had a smaller venue rather than the ICC in Birmingham or the ACC Convention Centre in Liverpool – which actually worked out well. The problem of the ICC and particularly the ACC is that main community spaces had been very large as a result atmosphere suffered. This time the Grand Hotel in Brighton was really busy and vibrant as a result.
We had a good blend of sessions covering traditional integration, low code, cloud, microservices, API, UI with people from customers, partners and Oracle travelling in from all over Europe and the US to participate and present.
In terms of my presentations and the ones, I managed to see, I’d particularly recommend checking out in the UKOUG library …
or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.
That consistency and predictability are important not just for code if you look at any 
This year’s 
