Tag Archives: SaaS

Oracle API CS vs OCI API approach to securing gateway configuration

02 Tuesday Jun 2020

Posted by in API Platform CS, APIs & microservices, General, Technology

≈ Leave a comment

Tags

, , , , , , , , , ,

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?

…. For Dummies

23 Wednesday Sep 2015

Posted by in Books, General, Oracle

≈ Leave a comment

Tags

, , , , , , , ,

It seems to becoming the done thing to license the use of the ‘For Dummies’ brand and publishing books (or are they large booklets) on a specific subject. These can then often be picked up as print freebies at conferences. I saw a couple at the Oracle Cloud Event today – though I’d share the ebook versions here:

Mitigating Risks of Cloud Services

08 Monday Dec 2014

Posted by in General, Technology

≈ Leave a comment

Tags

, , , , , , , ,

As previously blogged there are risks with using cloud that differ from self hosting solutions. SaaS, PaaS and all the other XaaS offerings aren’t a panacea. Hopefully you won’t become the next Sony as the provider keeps you patched etc. But if you’re using a SaaS provider that goes bust or you get into litigation with your provider, as result losing access to your data. It could be potentially be months whilst the lawyers sort things out. A horrible situation that no one wants to find themselves in. But how to mitigate such risks?

Any half decent SaaS provider should give directly the means to get a view of all your data through a generic or custom report (s), or will should make available the means for providing an export of your data. The later approach may well come with a cost. If your SaaS solution has a lot of data in place – for example a multinational’s HR solution you may want to just target the extract of deltas. This means extra donkey work and someone to ensure it is happening. How frequently that should depend upon your business needs through an agreed Recovery Point Objective and the tolerance to potential data loss as you can assume you’ll lose everything from the last snapshot. If you have middleware in front of your SaaS service you can have a wiretap to reduce the risk here.

Your net position is in the event of a loss or possibly a prolonged service outage (remember even Amazon have had multi-day failures & not all SaaS solutions follow good cloud practise of being able to fail to secondary centres) is that you have your data and can atleast cobble something together to bridge the gap. Unless you SaaS vendor is offering you something very unique then they’re probably going to have competitors that are more than likely to be glade to help you import the data into their solution for you.

All this for a case of paranoia? Well actually you can have harvest a raft of other benefits from taking full data extracts – for example reconciliation with a view to managing data quality – statistics from Experian show the value of resolving discrepancies. This is to say – that you might find data errors between systems as a result things like edge scenarios such as handling errors in the integration layer. To illustrate the point, let’s assume that your web sales channel is via a SaaS provider and you’re receiving the sales into your on premise ERP for fulfilment and accounting. By taking every week all transactions in the SaaS solution you can identify and discrepancies and reconcile any issues between the sales solution, your finance and fulfilment capabilities to ensure what you have sold is what you have accounted for.  If we’re talking about solutions that impact your financial accounting, then for atleast US declarations it maybe necessary to perform such reconciliation in support of Sarbanes Oxley (SOX) requirements.

Add to this a richer data set can be added to your Big Data or Data Warehouse environments allowing you to gain potentially further insights into your activities.

When you are running a hybrid of on premise and cloud solutions or event just cloud but a mix of vendors don’t just think about you application data, but consider whether audit and web traffic information can be retrieved from the vendor – there maybe value in feeding that data into a solution such as Splunk which may then find a pattern of misuse or attack that may not show up with just the monitoring data from your on premise solutions.

The final point I should make, is don’t assume your service provider will let you at the data as described – look at your contracts before any payment or act of agreement. Ideally such checks should be part of your service due diligence activities (along with ESCROW) etc. There are SaaS providers who will consider the data as their property not yours even when the data might be about your employees.

Single Vendor Cloud

20 Thursday Nov 2014

Posted by in General, Oracle, Technology

≈ 1 Comment

Tags

, , , , , , , , , ,

The recent outage of Microsoft Azure, raises some interesting questions. This isn’t the first big vendor cloud service outage, Amazon AWS and others have had their moments. Of course this had lead to the recommendation that to ensure your service has continuity that a DR arrangement with a different provider be in place. This works with Platform as a Service. But what we have been seeing is move from PaaS up the value stack to vendors offering their own rich ecosystem to build on – from Amazon SQS to Oracle’s latest announcement Oracle Internet of Things platform.

These solutions, can be built with open standards etc but ultimately when used create vendor lock-in as no one else will have an equivalent capability with the same APIs. So how do you mitigate these outages, or even the risk of such an outage? Well Oracle do claim you can actually run all their cloud capabilities on premise. But is that practical? As cloud is adopted organisations are going to wind back their hardware capital outlay, after all that is one of the value points of cloud.

So where does that leave us? Accepting the risk and trying to mitigate the risks in our own commercial agreements? What about the fact in an IoT solution where you’re event stream processing and using period on period comparisons to set thresholds which means the likely data loss from an outage will have both ‘echos’ as you period analysis has holes in data plus false thresholds as the data hole will skew the data when that period is being used for period comparison.

Difficult questions with no obvious answers, other than you mitigate you things commercially and push Microsoft and others to make things more robust – time for Netflix Chaos monkey?

Evaluating SSL certificates for SaaS

29 Tuesday Jul 2014

Posted by in General, Technology

≈ Leave a comment

Tags

, , , , ,

So when looking at SaaS solutions one of the things we consider is the strength of the SSL certificate, and when using a small provider who the Certificate Authority as commercial authorities will provide insurance for a breach which can go to paying some of the cleanup costs (assuming the breach isn’t from negligence).

So how to evaluate SSL certificates in terms of robustness (i.e. cryptographic strength) after all some people will talk. About 128 bit certificates and others such as Google mention 2048 which on the surface don’t seem comparable.

So the bit length is to do with the cryptographic algorithm used of which there are several such as AES, 3DES and so on. No I’m no expert on this so I won’t presume to explain the pros and cons of the different algorithms, there are other resources on the web for that (such as this document).

The point I have been working towards is that NIST (National Institute of Standards and Technology)(aside from being a good resource on security) have tables  that recommends the size of the key used to help build the certificate (the document is here and tables 1 & 2 contain the key details, more here). The tables shown below takes into account the algorithm (therefore a comparator on key size) but also a recommended growth in key size.

 

NISTTable2 NISTTable

 

An alternative representation of the same information can be found here and the 1st table here.

So why grow a key size well one of the factors in driving key size is that as computing power increases the time and effort to brute force crack of a key shrinks. So every time the key size increases so does the effort to brute force the cracking of the key.

This leads to secondary consideration – that of the certificate life i.e. how long the certificate is valid for. This is in effect to potentially greatest period of exposure based on the fact that someone may brute force your certificate and then simply listen to the traffic so you never know of the compromise. Obviously you can revoke the certificate at any time.

Finally remember the need and level of security should be informed by assessing the data being transferred (in motion). Data security should also be considered for data at rest I.e being stored (data loss from a data store is likely to be far more damaging).