Back to basics: mainframe security 101

By Dave Constable, Senior Technical Consultant.

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 keeping 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 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 pose a serious 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 that 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.

Data ownership – do you know who owns what data on your system? Ownership is critical to comply 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.

Role-based access control – role-based security to restrict access to authorized users, implementing mandatory or discretionary access control, plays an important role. The problem is, 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.

Approval process – all requests should be subject to some level of approval before being actioned. Different levels of access, 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 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?

Automated systems 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 leavers 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 the automation? Can they subvert the code in order to escalate their own privileges?

JML – redundant accounts and access can provide a means to bypass security controls. Rigorous JML processes should reduce the risk, provided they are followed. But 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 removal or deletion of 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.)?

Recertification – with high numbers of 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 it is they’re being asked to recertify, especially when it comes to 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 have its own recertification process? Are the correct people being asked to re-certify? Is it possible for users to recertify their own access? Is your grey list management process adequate?

Privileged access and accounts – a privileged account is any account that has 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 important. 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 as 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 on?
• 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), change control?

In many cases, a break-glass process or tool can be used to 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 practice increasingly require the use of encryption, which can reduce the risk from both 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 strictly managed and monitored but, with the right key, any attacker can access the underlying data. Conversely, without the right key, even authorized users can’t access the data. 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 the crypto services of z/OS 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 ae 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 to provide additional security?

Getting the basics right

Buildings are only as strong as the foundations they are built upon, and this is the same in mainframe security. You of course need to assess new risks that are 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. Always remember that all of the new mainframe security functions and tools will be meaningless if you don’t have the basics well covered.

About the author
David Constable CISSP, CISA, CISM, CRISC is a Senior Technical Security Consultant for Vertali, “committed to delivering top-tier mainframe security solutions that align with clients’ strategic objectives”. With extensive expertise in RACF and security engineering, he specializes in fortifying client infrastructures against evolving threats through activities security assessments, penetration testing, and remediation.