In the 1990s, the UK’s Co-operative Bank ran adverts with a rather effective tagline, “The Co-operative Bank—why bank with one that isn’t?” It stands to reason, right? The same ought to apply to your computing platform. Shouldn’t we simply expect it to maintain confidentiality? Surely the platform to which we entrust our sensitive information is going to respect our privacy? That the applications the platform runs are, in effect, impervious to penetration and hacking?
A great deal of intellectual effort is being brought to bear on this reasonable demand. And it is achievable. It just takes some work.
Along those lines, the Confidential Computing Consortium launched in 2019 to incubate technology for data security. IBM® is a founder member. The consortium promotes adopting hardware-based Trusted Execution Environment standards and technology, to protect both the data and the applications the data is processed by. So far, so good. What is perhaps surprising is that such environments don’t seem to exist already. We’re back to ‘The confidential computer—why use one that isn’t?’
I can, however, offer you some reassurances. If the data you’re most immediately concerned about is that data traditionally held within modern IBM mainframe databases built on z/OS, with a well-maintained security posture, with pervasive encryption and logical protection … okay, I’m going to confidently assert that your data may be in the best possible pair of safe hands.
It’s both exciting and unnerving that our data world is changing so quickly. As the Confidential Computing Consortium notes, “The ability to protect data and code while it is in use is limited in conventional computing infrastructure” – meaning traditional x86 and nascent cloud platforms. So the question is, how do you feel about your data not staying within the safe hands I mentioned about, as it spans technologies and clouds?
We need to change our perspective, and our mindset. This means taking a wider view of the technology needed to fully protect our enterprises and data, one that encompasses many aspects of the ‘defence in depth’ framework of security. Much of this has already been addressed to some extent by various overlapping forms of technology. As both the threat vectors and technology have evolved, however, many security responses are being driven deeper and deeper towards the hardware heart of systems. You’d build a castle on good footings, wouldn’t you, as well as ensuring strong walls, multiple defensive measures and so on?
So we should look a little deeper into the scope of fully protecting our data, encompassing as this does the data itself and its wider holding environment wherever that might be. Protection must be complete as the data moves out for processing, and as it’s being processed through code and hardware. We need protection of any keys required, and we need data and code integrity and confidentiality, availability and recoverability, and attestability; that is, where the data and code came from is trusted. We need to assert that unauthorised access cannot happen, not simply that it won’t happen.
We need a method of accountability for every aspect of the operation, at any reportable instant. If something goes wrong, physical or logical recovery must be instant, granular and accurate.
If you are deploying your enterprise mainframe cloud on IBM Z®Linux, all your confidentiality concerns become super-focused. This is hardly surprising, given there won’t be a single component that isn’t either inherently valuable or sensitive, or is itself protecting important sensitive data – and adding value to the data that you may be serving to your customers.
Today’s reality is this: security attack standards and responses are being further defined at a remarkable pace, our data is at risk on many fronts, hardware defences are of primary importance with software a complementary part of the whole – and IBM Z is ready.
IBM mainframe technology means we can protect data at rest, in flight and in use, secured within hardware and software Trusted Execution Environments. The Secure Enclave defined in the hardware and firmware protecting our private and sensitive information includes the most secure-hardened Hardware Security Modules anywhere, together with the CPACF crypto accelerator on-chip running on EAL 5 certified machines. Above this layer, PR/SM and LPAR hypervisor code have been continuously improved since the late 1980s, building to the recently announced Secure Execution for Linux – itself a hardware-based Trusted Execution Environment – allowing many hundreds of KVM type guests to be perfectly isolated within crypto-domains.
Protection above these layers is provided with IBM Hyper Protect suites for authenticated launch deployment to a cloud, and more. Trusted-Platform enhancements in the form of Enterprise Key Management and Trusted Key Entry are available to further secure our data. What’s more, if logical corruption strikes, we have the cyber-resilience of granular recovery from IBM Safeguarded Copy.
As the lawyers say, good fences make for good neighbours. For a Zero Trust mandated environment, where the ‘Linux Anywhere’ freedom demands managing client data with the highest trust possible, we need to look at a platform with the highest security available.
As Trust standards develop, as processing capabilities accelerate, as clients rightly demand protection from even the most demanding of cyber attacks, IBM Z can be certifiably secure. In many ways, the future has finally caught up with the capabilities of the IBM mainframe. When organizations have defined their future, Z is ready, whatever security and protections that future may demand. The confidential computer: why use one that isn’t?
Andy Coulson has collaborated with the GSE UK organisation for many years. An IBM Redbook author, a presenter on mainframe security and technology, and more recently a vlogger on the ‘Mainframe in 5 Minutes’ YouTube channel, he is passionate about the technology that lies within all things mainframe. Andy works for IBM UK, although wishes to point out that all views expressed are his own, not necessarily those of IBM or GSE.