Fight ‘Shiny Object Syndrome’ with Mainframe Security 101

With continuous innovation and new functionality developed for mainframe security, many organizations can lose sight of the basics, which means they may never achieve a Zero-Trust security stance. 

The mainframe continues to evolve as a critical piece of the enterprise IT jigsaw, with new features, hardware, and tooling that keep it relevant. Innovation is especially evident in security, with new ways emerging to combat today’s advanced threats. Unfortunately, this innovation can be a double-edged sword, with the same advances that can make our lives easier, but they are also being used to threaten and attack our systems. 

Pervasive encryption (PE), multi-factor authentication (MFA), and file integrity monitoring (FIM) are just a few of the weapons now available in the mainframe security arsenal. But we must ensure we don’t fall foul of “shiny object syndrome” and forget the basics: the solid foundations of mainframe security that we have to get right. So, what do we mean by the basics? 

Authentication

Let’s start with logging on or connecting to the mainframe. Accountability is one of the principles of the CIA Triad, a model that can be used as the basis for developing security systems. Accountability can only be assured if you can be sure that whoever or whatever is accessing your system is who or what they say they are. You need to consider the following:

• Are your password rules strong enough (case sensitive, special characters, etc.)?
• How often do you require a password to be changed?
• Have you implemented the RACF encryption algorithm KDFAES?
• Is your password history long enough? Can a user cycle through their password history to re-use an old one?
• Do you use MFA? This can be a strong control, but you need to consider how it’s used. If you use a VPN, does that use MFA? Do you use MFA when authenticating to your desktop environment? Think about your processes and the impacts on users.

Access management

PE and FIM shift the security focus further towards Access Management. The insider threat allied with phishing and ransomware poses a severe risk; no amount of encryption will prevent someone with valid access to your data from editing, copying, or selling it to the highest bidder. They may even re-encrypt it using their own key. FIM cannot fully protect against the programmer who slips their own code into a program library via the approved change process as part of an upgrade. There are various issues to consider in access management.

1. Data ownership—who owns what data on your system? Ownership is critical to complying with regulations, policies, and controls. Clear ownership allows individuals to understand who has access to their data and under what conditions. Data owners also need to understand the criticality of the data and who should or shouldn’t have access. They understand how data is used and should ensure it’s being used and managed correctly. The effectiveness of your JML and approval processes depend on them.

2. Role-based access control—Is role–based security, which restricts access to authorized users by implementing mandatory or discretionary access control, in place? The problem is that while intended to simplify managing permissions when granting access to resources and applications, RBAC isn’t always implemented or configured properly, which can lead to unforeseen security risks. Challenges can include role proliferation, permission creep leading to a highly complex web of permissions, and serious maintenance overheads. 

3. Approval process – Are all requests subject to some level of approval before being actioned? Different access levels, or access to sensitive functions/data, require different approvals. The key issue is identifying the correct individual or individuals to approve such requests: approvers need to understand why the user needs access, how long access is required, and what the user intends to do with the access. They should also ensure access is removed when no longer required and review audit reports to ensure the user has only done what was indicated. Approval isn’t about seniority; it’s about understanding the data, the requirements/restrictions for access, and the risks involved in giving access. Questions to answer include:

• Are the correct approvers in place for the resources in question? 
• Are approvers regularly reviewed?
• Can approvers delegate? If so, do they delegate to appropriate nominees with the right level of knowledge?

4. Automated systems– Are these helping?  They can complicate issues, as there may not be a physical approver, with the system itself making an approval decision. In these instances, other factors need to be considered, including:

• Is manual approval still required, especially for privileged access or deletions identified by a leaver’s process?
• Is the principle of Least Privilege followed when access is granted, especially when new resource profiles are created?
• Are manual sanity checks applied? For example, would an approved delete for an account associated with a system task be checked before being actioned? 
• What failover processes are in place? 
• Who supports automation? Can they subvert the code to escalate their privileges?

5. JML – redundant accounts and access can provide a means to bypass security controls. Rigorous JML processes should reduce the risk, provided they are followed. However, JML processes are often forgotten or left for a period of time, especially when it comes to leavers. Managers may think that getting a new team member up to speed fast with all accesses in place is a higher priority than removing access that’s no longer required. Tying in JML processes with HR systems can help but can lead to other issues, especially around removing or deleting generic or system accounts. There may also be the fear that removing access or an account may cause something else to fail. Areas to consider include:

• Are JML processes defined and documented? 
• Do managers know their responsibilities around JML?
• Is compliance to process measured and reported on? 
• What’s the scope of your JML (users, access, approval processes, ownership, etc.)?

6. Recertification—With many users and profiles, recertification of mainframe access can be tricky and time-consuming. There may also be issues when resource owners don’t understand what they’re being asked to recertify, especially regarding business transactions (in CICS, IMS, etc.). However, this is a key control that safeguards your data. 

You should, therefore, run recertification campaigns regularly: annually as a minimum, bi-annually for privileged accounts and access. There are various issues to consider here. For example, is the scope of your recertification process inclusive enough? Is privileged access included, or does it have its own recertification process? Are the correct people being asked to re-certify? Is it possible for users to recertify their access? Is your grey list management process adequate? 

7. Privileged access and accounts – a privileged account is any account with some form of privileged access, be it a system or personal account. That access may not be permanent, but whilst in place, that account can be classed as privileged. Privileged access can be permanent or temporary access to any data or resource of a critical or sensitive nature. The level of access is also essential. You cannot assume that access that can change data, such as Update/Alter, is always privileged, and there will be instances where Read access can be just as privileged as Update or Alter. Issues to consider include:

• How many accounts do you have with privileged access? 
• Is privileged access recertified regularly? 
• What do you consider privileged accounts? Do you include application/business accounts or just Infrastructure? 
• Are your privileged accounts behind a break-glass process? 
• Is the usage of such accounts logged, monitored, and alerted? 
• And what compensating controls are in place around the activities access is used for? Segregation of duties, automation, command verifier policies, etc. (if you use z/Secure), and change control?

Often, a break-glass process or tool can help manage privileged access. But this can create its own concerns: Are the correct people approving the requests? Does the process meet the principle of least privilege or grant higher access than is required, ‘all or nothing’? Is the user being granted access audited correctly?

Encryption

Regulations, standards, and best practices increasingly require encryption, which can reduce risk from internal and external threats. However, risks still need to be addressed.

Key management – data may be encrypted both in transit and at rest, and access to data is strictly managed and monitored. Still, an attacker can access the underlying data with the correct key. Conversely, even authorized users can’t access the data without the correct key. Questions to answer include: where and how are keys generated? How are keys distributed? How often are keys changed/rotated? Are keys backed up? Are old keys archived in case they are required for recovery later? Is the key management process audited?

ICSF and cryptographic services – ICSF works with RACF and crypto hardware to provide z/OS crypto services and allows applications to request cryptographic functionality. The issues that matter here are: – Are the key datasets protected correctly (CKDS, PKDS, TKDS)?
– Are the datasets backed up, and are the backups protected?
– Is key usage audited?
– Who has access to the ICSF Panels?
– Are the keys protected – CSFKEYS profiles in RACF?
– Are the ICSF API’s Services and Panels protected – CSFSERV profiles in RACF?
– Do you have key store policies in the XFACILIT class that provide additional security?

Getting the basics right 

Buildings are only as strong as the foundations they are built upon, which is the same in mainframe security. You, of course, need to assess new risks coming to the fore and make plans to protect against them – but not to the detriment of any other aspect of security that may seem less important. Remember that all the new mainframe security functions and tools will be meaningless if you don’t cover the basics well.