We have established that Zero Trust is an approach to security that can and should be applied to the Mainframe. Yet too often, Mainframe is overlooked as a security concern, as many assume that it is naturally secure, because, well, it's a Mainframe.
Now, this is certainly flattering for the platform, and to be honest, the Mainframe’s reputation for security is well deserved. But, it is not invulnerable, and nothing about it is ‘naturally’ secure. Like all systems, it is only as good as the people and processes that support it. It is trivial to manage your Mainframe security in such a way that leaves it open to easy access. Of course, like any system that uses passwords and IDs, it is vulnerable to phishing attacks. It goes without saying that anyone that has your ID and password is, effectively, YOU. If YOU happen to be a privileged user, one with access to the enterprise’s most valuable assets, then bad things can happen.
What kind of Bad Things? Examples of Mainframe breaches are, as you can imagine, are well-guarded secrets, but they do get reported. Luxottica had their Mainframe breached and employee data stolen, and the notorious co-founder of Pirate Bay was found to have hacked the Mainframes that supported Swedish Nordea Bank among others. Of course, we imagine that these breaches are the result of malicious attacks, and indeed the Ponemon/IBM Cost of Breach Report found that just over half of breaches were the result of malicious attacks. But nearly 20% of these malicious attacks are due to lost or stolen credentials, something all platforms, including Mainframe, are susceptible to.
So Mainframe is not invulnerable to attacks, but managed correctly, the Mainframe is a highly securable platform. Vigilance is necessary, and as mentioned in an earlier post, Mainframe’s are increasingly being utilized to support broader, hybrid apps, and therefore being exposed to a broader set of threats than ever before.
Therefore, we imagine that Zero Trust and in fact all modern security approaches would be standard practice on the Mainframe. But, we find it increasingly commonplace for Security and IT leaders to simply assume that Mainframe is secure, and that it is exempt from rules and policies applied elsewhere. For example, most of us are familiar with the use of multi-factor authentication when accessing company IT assets. Email frequently requires a code to be sent to a user’s mobile device in order to authenticate and gain access. Yet for the vast majority of Mainframes, multi-factor authentication is not used, and many Mainframe customers don’t even know the technology is available, even though it is often built into the security system right on their own Mainframe!
This raises an important point: Mainframe is simply a server platform. Sure, it's strange to some, nevertheless, Mainframe is a server platform with its own vulnerabilities and challenges. Yet, there are practices that have been adopted for other platforms over the years that equally apply, but are not commonplace in Mainframe. Multi-factor Authentication is a case in point: Why is email found to be so sensitive as to protect behind a second factor, yet the Mainframe, with likely the most critical and sensitive data in the entire company, is not deemed critical enough for that same technique?
In order to adopt Zero Trust on the Mainframe, we simply need to update security practices and modernize security controls on the Mainframe. Let’s examine these practices surrounding the key to Mainframe security: Identity and Access Management. How do we modernize Identity and Access Management on the Mainframe?
Obviously, a first step is to address a legacy ‘vulnerability’: ID and Password. Due to memory and technology limitations in its early days, IDs and Passwords were limited to 7 or 8 characters. Today, it is best practice to have longer passwords, and typically more convenient to have more flexible IDs. Of course, changing these requirements can often mean changing the critical applications on our Mainframe, and this can be challenging. Therefore, adopting multifactor authentication is a method to bring increased security to Mainframe, while also reducing the impact to the underlying applications. Most apps have passphrase support or can even support appending additional factors to the login screens, and quickly we can modernize logins to crucial Mainframe applications and data.
Of course, even with this, we have some sets of users that have entitlements to the most important data and apps on the Mainframe. Like on other platforms, we call these ‘privileged users’. Most are familiar with ‘privileged user management’ tools, but few are utilized on the Mainframe (you will hear this alot!). Some of these tools also support Mainframes, using a ‘vaulting’ methodology. Essentially, this is issuing a user an ID that has privileges needed to do the task. These are issued temporarily to a user, who logs in with those credentials to perform some task on the Mainframe. The downside of such a system is that logs of these user's activity on the Mainframe will be against the shared ID, rather than the individual user ID, which means extra steps to trace the activity from the ID to the actual users. Instead, one can use an available ‘elevation’ model that simply adds additional entitlements to the existing user ID for temporary access to critical systems. When the job is done, the user ID is returned to ‘normal’ entitlements. In this way, any misuse or theft of an ID is limited to the reduced entitlements, as higher privilege is not available 24 x 7. Automating these elevated privileges can be associated with approved Change control and other tasks to really integrate this critical control within the enterprise.
Every enterprise sets internal security policies around a comprehensive set of behaviors, activities and controls. Typically, these include extensive guidance on what and how to protect resources and data, across all managed devices. So, following these policies depend critically on understanding the underlying data on the device and how it is accessed and utilized. This is true of the Mainframe as well: one should be aware and have detailed knowledge of what and where sensitive data exists, so that the proper access rules are applied to stay in compliance with those policies. It really isn’t sufficient to say ‘on the Mainframe’ when asked where sensitive data resides on the Mainframe, but it is a common response! Having a clear understanding of the location of sensitive data, and an associated set of controls in place around that data is a fundamental capability of ensuring Zero Trust.
Our new Zero Trust mentality suggests we assume that our Mainframe will be breached. Detecting breaches can be frustratingly difficult, but having indicators of compromise ready, acting as early warning systems is a best practice regardless of platform. Monitoring security events is commonplace on other platforms, and is certainly available for the Mainframe. In this case, it goes beyond simple ‘logs’ and instead includes behaviors and critical operating system monitoring. Rather than simply log SMF records, it’s critical to monitor z/OS operating system configuration files, security files and other critical records. Monitoring individual users is important for understanding and detecting Insider Threat, as is careful monitoring of access to sensitive data. Finally, sharing these findings by incorporating Mainframe security events into the ‘bigger picture’ of an enterprise view, typically within a SIEM such as Splunk, is necessary to gain true enterprise security visibility. By incorporating continuous monitoring, we are prepared for, and thinking about breaches, supporting our preparations around Zero Trust.
One final area of attention for Zero Trust on the Mainframe is ensuring that unused accounts and associated entitlements are limited. Least Access is fundamental to most security associated regulations and best practices, but most IDs and entitlements are associated with users. These users are not static, and change roles fairly frequently, such that Least Access for one role may no longer be Least Access for other roles. Reducing these entitlements is necessary, but can often be disruptive, if those entitlements are needed again later. Understanding which are no longer needed, and being able to quickly recover if they are needed later is an important and labor saving capability that again is central to Zero Trust.
These tasks all represent a series of activities that are performed around identity and access on the Mainframe, and are linked together: each relies on the other and improves the security posture in an incremental fashion. They aren’t sequential nor are they dependent on each other, but collectively they represent a ‘lifecycle’ of managing Mainframe security, and ensuring a posture of Zero Trust:
In our next few posts, we will do a deeper dive into each of these activities and best practices for managing Mainframe Security in a Zero Trust fashion.