Zero Trust, Part 3: Is Zero Trust Challenging to Adopt?

As described in a previous post, Zero Trust seems like an initiative that is more appropriate for a new system or application, but not something one would hope to achieve on a system that has been in use for decades. For example, Mainframe has years of use around it, a security strategy already in place, and getting to Zero Trust would be difficult where starting from scratch was a viable approach. 

But, in fact, one could argue that Mainframe was an original ‘Zero Trust’ platform. You see, originally, when the mainframe system was developed, everyone had access to everything. After all, only the experts were on the system and “regular user” access was very limited. This changed as use expanded, and became core to the mainframe security model when a tool called Access Control Facility 2 (ACF2) was developed. ACF2 took a different approach, one of Zero Trust: it started with no access, and required access to systems and resources to be explicitly granted to each user. It established an original Zero Trust model. This became the best practice on the mainframe and has been the method of security on the mainframe ever since.

Of course today, most mainframe systems have hundreds of thousands of IDs and associated entitlements that have been defined over the years. IDs relate not only to humans but also to applications and other entities that need integration with the mainframe. These entitlements are central to security on the mainframe, as they grant access to mainframe resources. Without these entitlements, our businesses would grind to a halt. So, how is one to address or perhaps return to  ‘Zero Trust’ on the mainframe if we need, from a business perspective, to preserve our access?

As we stressed in the earlier post, it isn’t necessary to start from scratch, resetting all the Identity and Access Management (IAM) credentials, and literally start from zero. We emphasized that Zero Trust is more of a philosophy that influences our way of approaching security as a whole. So, there is no need to remove every ID and entitlement and start fresh to achieve Zero Trust.  Instead, we should find ways to ensure that we manage security, especially with our IAM tools, with a mindset and practices of Zero Trust:

“Verify every user, enforce least privilege and assume breach. Never trust, always verify.”

And indeed, this is the concept in a nutshell, to follow this high level guideline in how you manage security on the mainframe. Central to security management on any platform, and of course a key principle of Zero Trust is the practice of the Principle of Least Privilege. Not only is it a best practice, but it also is a codified requirement to meet several security standards and regulations, including PCI-DSS, NIST 800-53, CIS and others.  Here the goal is to ensure that each resource has access granted only to those that have a direct business need to access that resource and only at the level required to complete the task.

Obviously understanding which users have which entitlements and which are necessary for their job is the task here. That is often done at an annual review, where attestation is leveraged to query users as to whether they need the accesses currently granted.  But, least access is serving Zero Trust, so we need to include validation. In this case, we can check the attestation against actual usage, confirming the need for entitlements. If an entitlement hasn’t been used in a year or more, perhaps it isn’t actually needed, or required for the business. By leveraging ‘clean up’ tools, we can analyze the External Security Manager database for entitlements and determine which are being used, and against which IDs. They can even be automated, eliminating any entitlements that have not been used for a long time. This helps in achieving Zero Trust, in that it helps us verify every user and assume that they do not need entitlements they don’t use.

We can further deliver a Zero Trust environment for the mainframe by utilizing a tool that is well established, especially outside of mainframe, and should be equally commonplace on the mainframe: multi factor authentication. This technique adds a ‘layer’ on top of the typical ID and password challenge for users. By using this additional authentication method, a mainframe with thousands or even millions of IDs can be rapidly managed in a Zero Trust manner, as it requires each user be verified, all without breaking, eliminating or changing entitlements.

Finally, we can make significant improvements in mainframe security by simply assuming we may be breached. This sounds simple enough, but many mainframe owners assume that their mainframe is secure, just because it is a mainframe. While it is inherently very secure, the mainframe, as any other platform, is only as secure as the people and practices make it. So, assuming the possibility of breaches on the mainframe will bring a cautious and contemplative approach that helps realize Zero Trust. For example, monitoring users helps in the assumption that you will be breached, and monitoring users, critical system  configurations and sensitive data can help by alerting you to unusual activity on the mainframe. 

So, while mainframes may seem beyond the approach of ‘Zero Trust’, they are, in fact, built on Zero Trust principles. It is best practice as well as good, modern mainframe security practice to achieve a pattern of Zero Trust. Fortunately, there are valuable tools to assist in protecting the crucial assets that run our business, and deliver a pattern of Zero Trust. In upcoming posts, we will explore several of these tools and practices such as multi factor authentication, monitoring of users, clean up of entitlements and managing privileged users.