Ransomware has emerged as one of the most pervasive cybersecurity threats of the digital age, targeting organizations of all sizes and industries. This malicious software encrypts files and systems, demanding payment to restore access. While businesses often focus on protecting their servers, workstations, and cloud environments, a critical yet overlooked target remains at risk: the mainframe. Traditionally regarded as secure bastions of enterprise data, mainframes are increasingly vulnerable to the evolving tactics of cybercriminals.

In this blog, we explore the fundamentals of ransomware, its implications for mainframes, and why organizations must prioritize mainframe security in their ransomware resilience strategies.

What is Ransomware?

The US Cybersecurity and Infrastructure Security Agency (CISA) defines ransomware as “a form of malware designed to encrypt files on a device, rendering any files and the systems that rely on them unusable.” Attackers then demand a ransom, often paid in cryptocurrency, to decrypt the affected files.

The consequences of ransomware attacks are severe and can include:

• Operational shutdowns: Businesses may be forced to cease operations, as seen in cases where retail chains and public services experience complete downtime.
• Financial losses: Costs include ransom payments, legal fees, lost revenue, and recovery expenses.
• Reputational damage: A ransomware attack can erode customer trust and tarnish an organization’s reputation.
• Compliance risks: For industries with strict regulatory requirements, failing to protect data could result in fines and other penalties.

The myth of mainframe invulnerability

Mainframes are often considered immune to ransomware attacks due to their robust security architecture and isolation from traditional attack vectors. However, this perception is dangerously outdated. Modern enterprise environments integrate mainframes with other systems through interfaces like Microsoft Open Database Connectivity (ODBC) and REST APIs, increasing exposure to ransomware threats.

Consider these facts:

• Proof of concept attacks: Security researchers have demonstrated how ransomware can target mainframes, proving their vulnerability.
• Integration risks: Mainframes often serve as hubs for critical enterprise data. Attackers can leverage compromised systems connected to the mainframe to launch attacks.
• Enterprise traffic: The high volume of data flowing through mainframes makes them attractive staging grounds for distributing ransomware across an organization.

Real-world impacts of mainframe ransomware

Ransomware attacks on mainframes can have devastating consequences. For example, in 2022, Miller County, Arkansas, experienced a ransomware attack where the mainframe was used as a platform to distribute malware across the enterprise. This incident underscores the potential for ransomware to compromise not only the mainframe but also interconnected systems and data.

Organizations relying on mainframes for critical operations in finance, healthcare, retail, and government cannot afford to underestimate these threats. A successful attack could disrupt supply chains, delay financial transactions, or jeopardize sensitive customer data.

Why mainframes must be part of the ransomware strategy

Ignoring mainframes in a ransomware defense plan creates a significant security gap. Here are key reasons why mainframes should be included:

1. Critical role in operations: Mainframes handle some of the most sensitive and mission-critical workloads, making them prime targets.
2. Evolving threat landscape: Cybercriminals are increasingly sophisticated, leveraging automation and AI to exploit vulnerabilities in interconnected environments.
3. High stakes: The potential consequences of a successful ransomware attack on a mainframe extend far beyond data encryption, impacting business continuity and compliance.

Conclusion

Ransomware is no longer a peripheral threat; it’s a business-critical issue that demands comprehensive, enterprise-wide strategies. While mainframes have long been considered secure, their integration into broader enterprise ecosystems makes them vulnerable to ransomware attacks.

By acknowledging the risk and taking proactive steps to secure mainframes, organizations can strengthen their overall ransomware resilience. In the next blog, we’ll delve into how ransomware targets mainframes and explore the tactics cybercriminals use to exploit these systems. Stay tuned.

Learn more about protecting your mainframe from ransomware attacks in the white paper, “Mainframe Under Attack: Essential Measures for Ransomware Resilience.”

Penetration testing (pentesting) is in essence an ethical hack of a system, also known as an authorized simulated cyberattack, which can be categorized into three types: white box (known information about the system), grey box (system partially known), and black box (system fully unknown). Modern-day pentesting is highly regulated and follows structured frameworks, however its origins go back to the mid-1960s when time sharing took off. By the late 1960s, the U.S. Department of Defense (DoD), National Security Agency (NSA), and Central Intelligence Agency (CIA), as well as academia and industry, had come together to assess and confirm the threat that computer penetration posed. By the 1970s, formal “tiger teams” entered the scene with the sole job of pentesting.

Why pentest?

• Risk management: When a vulnerability is found, it will be accompanied with some kind of scoring; there are scoring systems such as the Common Vulnerability Scoring System (CVSS), but ultimately, any score is usually made up of ease, likelihood, and impact. Based on this score, it can then be grouped into a risk category of Very High, High, Medium, etc. This plugs directly into risk programs and can help direct priorities.
• Security control validation: There is no better way to validate your current controls than to pentest them, which can determine whether they are effective or not and identify strong and weak points within an enterprise. This can also spark other conversations, such as which solutions are out there to help.
• Compliance: Some regulatory standards mandate regular pentesting as part of the effort to be compliant. This shows that due diligence is being demonstrated toward securing their systems.
• Playbook preparation/incident response: Simulating an attack also gives you an opportunity to stress test process and early detection systems. If the simulated attack is detected, it can be challenged against what should happen, e.g., go to the security operations center (SOC) and, once at the SOC, whether the ensuing process was effective at responding to an attack.
• Third-party testing: The next attack is in development somewhere. No doubt, the internal team is very good, but it is very hard to keep up with the experience a third-party pentest team will gain from all the organizations they test. Validation using external pentest teams gives an unbiased evaluation and demonstrates a commitment to keeping the systems protected.
• Awareness: Nothing will get attention quite like the pentesting team breaching the main system of record using a technique that’s very easy and likely to exploit. Not all stakeholders are technical, so putting vulnerabilities into a language that is digestible brings everyone onto the same page. Having a vulnerable posture validated also factors into commercial decisions and budget allocated to remediation.
• Identify vulnerabilities: Knowing where vulnerabilities are in your system means an organization can address them before they are exploited. Depending on how mature the organization’s security journey is, having a list of vulnerabilities can be an effective way to direct remediation efforts.

Mainframe pentesting

We now know why an organization should pentest, so let’s talk about the mainframe and pentesting. Unlike many other platforms in the enterprise, there is no specific toolkit to test the mainframe―most of it will be homegrown tooling. Ultimately, a pentest provider can tailor a bespoke service with you, but I will talk through which services are available for the mainframe and what three mainframe pentests could look like in the context of white, grey, and black box.

Types of mainframe pentesting:

• Network: internal, and external
• Operating system: IBM^® z/OS^®
• IBM Enterprise Content Management System Monitor (ESM) Security Controls (IBM^® RACF^®, Broadcom ACF2, and IBM^® TSS)
• Subsystem-specific:
  • IBM^® CICS^®
  • IBM^® MQ^®
  • IBM^® IMS^™
  • IBM^® Db2^®
  • IBM^® WebSphere Application Server^® (WAS)
• White box example: System access is given with a basic user ID and password for a CICS application. The tester is told how to navigate to the application, and the scope of the pentest is a given CICS application only.
• Grey box example: System access is given with a basic user ID and password (or just the IP address of the mainframe). The tester is given limited knowledge of the system―for example, whether it runs Db2. The tester can use any techniques to take over the system.
• Black box example: A black box test may have several layers, with one team doing a physical breach, a specialized network pentest team or social engineering team getting to the point a mainframe can be accessed, and the mainframe pentest team then taking over. From this point, the tester will attempt to breach the mainframe, from sniffing credentials to brute-forcing, all attack vectors will be tested.

Security assessment versus pentesting

A security assessment is an in-depth collection process of configuration and controls to ultimately report on where improvements can be made. A pentest, however, may daisy-chain together several of these weak points to carry out an attack. An assessment suggests where an organization could be vulnerable, whereas a pentest proves it. An assessment will be comprehensive, while a penetration tester may stop and deem the test a success once they are in. Ultimately, both are important, offer different things, and should be carried out regularly. One blind spot an assessment can present is an instance of three low-risk, misconfigured settings that combine to create a high-risk vector for the penetration tester.

Potential concerns with penetration testing

There are also potential drawbacks to pentesting, and it is important to discuss them.

• Disruption of operations: If not carefully planned, or if the system is not properly understood, it can cause disruption (this is unlikely with an experienced team and a well-planned test).
• Scope limits: If the client limits the scope very tightly, it can miss vulnerabilities in other areas of the system and give a false sense of security (false positive).
• Resources: Specialized resources are very few and far between and finding someone who can test your system can be a challenge.
• Frequency: The period during which the tests are conducted needs to be on a sensible cadence, considering how likely new and evolved threats are to enter the landscape.

The future

Automation and artificial intelligence (AI) will inevitably play a role going forward. As penetration testers gather more data, it can be trained into models to suggest new vectors. AI models themselves will be tested; as models have a goal, this goal can be exploited and “poisoned.” Zero Trust models may be pentested, rather than the system itself, to show that an organization is not giving privilege to any user. Organizations will also adopt continual testing as toolkits are developed. It is inevitable that a solution will enter the market that mimics a long-running started task and constantly checks whether an exploit can be executed.

Summary

While penetration testing should be a cornerstone of improving your security posture, as with most things, it is only effective if action is taken afterward. Pentesting alone is not adequate to keep your system security validated; it should be accompanied by assessments, as well as security products such as real-time alerting and compliance. This is a space that will continue to grow on the mainframe. With regulations such as the European Union’s Digital Operational Resilience Act (DORA) going into effect soon, if you aren’t already pentesting, get ahead of the regulations that are mandating it and start the process yourself.

On February 26, 2024, the U.S. National Institute of Standards and Technology (NIST) finalized the first major update to its Cybersecurity Framework since its inception in 2014. With the original framework being used internationally and translated into 13 languages, version 2.0 is expected to have a big impact. Those already familiar with the original know it is comprised of five key areas: Identify, Protect, Detect, Respond, and Recover. Version 2.0 now has a sixth function that is applicable to all of the original five pillars: Govern. Throughout this blog, I will refer to Cybersecurity Framework 2.0 as “CSF 2.0.”

Figure 1. NIST v2.0

What is the purpose of the Govern function?

Govern will establish and then continue to monitor an organization’s cyber risk management strategy, expectations, and policy.

It is broken down into the following categories:

• Organizational context
• Risk management strategy
• Cybersecurity supply chain risk management
• Roles, responsibilities, and authorities
• Policies, processes, and procedures
• Oversight

Is the Govern addition the only change?

The short answer is “no.” While the five functions stay largely the same, there are other new changes, as follows:

• Implementation examples: CSF 2.0 now includes examples of how to implement the controls. While it is quite prescriptive, it is not granular. An example here might be the implementation of multi-factor authentication (MFA), but not which MFA factors should be used; that would still be at the discretion of the internal team.
• Clarity: While the original framework was digestible, it still used technical language. CSF 2.0 simplifies things, which will hopefully help all stakeholders better understand the controls.
• Govern function: Yes, the Govern function is new, however, a lot of it has come from re-shaping previous controls in the original framework.
• Updated Respond and Recover functions: Respond and Recover have gone through a big overhaul, with notable changes around communication and testing.
• Profiles: Profiles and community profiles did exist in CSF1.1, however they now have been re-vamped for CSF 2.0. The community can now provide examples of how CSF 2.0 can be applied to certain use cases such as financial, car manufacturing, etc. NIST also provides templates for organizational profiles, allowing side-by-side comparison for gap analysis.

What do mainframe security teams need to do?

Some good news: If you implemented CSF 1.1, all that hard work will not have been in vain and will map into CSF 2.0. There will be gaps that require some changes to be made, so the first thing to do is a gap analysis. NIST provides a host of resources and help in this area. This gives you an opportunity to bring all stakeholders together and, with the new simplified language, should make the process more streamlined than before. Bolstering the Respond and Recover functions could be possible pain points, however all of this leads to a tighter security posture.

Summary

Six years after the introduction of CSF 1.1, we have received a major update from NIST. SCF 2.0 does look quite different from v1.1, but a lot of the work has already been done if you have CSF 1.1 in place. A gap analysis is going to be the first step for any organization. If investment in Respond and Recover is needed, this will not only help you prepare for other regulations, such as the EU’s Digital Operational Resilience Act (DORA), but also improve your organization’s overall security posture. As far as I can see, everybody wins!

Do you trust what you’re eating? I can rest easy; in the U.S., I have the Food and Drug Administration regulating my food supply. Do you trust the product you just purchased? If I I’m in the EU, I have confidence because of the CE mark. Do you trust your bank/supermarket/airline is secure? I shouldn’t need to because they follow established security frameworks. This is a long-winded way to say that throughout our lives, we trust regulations and standards to ensure our safety, and cybersecurity is no different. In this blog we are going to look at what security frameworks are, why we need them, how to choose a framework, and, finally, balance things out by looking at the potential downsides of security frameworks.

Why do companies need cybersecurity frameworks?

Short answer: To improve the organization’s security posture in the following ways.

• Standardization: A common language and set of measures ensures that requirements are well-understood and consistent. Frameworks provide best practices and guidelines that are platform-agnostic to implement cybersecurity measures.
• Risk management: A framework provides a structured approach to risk management. It will usually begin with a discovery phase followed by an assessment of the finding. This in turn cascades down into resource (be that time or money) allocation to ensure the most significant threats are mitigated.
• Compliance requirements: While many industries have specific regulatory requirements for cybersecurity, non-industry-specific frameworks will align with standards of the regulatory bodies to ensure compliance.
• Resources/Skills gaps: Implementing effective cybersecurity controls is no small task. When you add skills shortages (or a complete lack of skills) to the mix, you may wonder where to start. Frameworks offer guidance based on risk, helping to ensure your implementation plan is as effective as possible.
• Continuous improvements: The threat landscape is always changing—the next exploit is currently in development somewhere. Frameworks provide the structure to ensure you stay secure and are continuously updated to keep pace with the latest threats for maximum effectiveness.
• Interoperability: Similar to standardization but slightly different, cybersecurity measures span the wider digital ecosystem to ensure that collaboration and communication can be facilitated between internal stakeholders and with vendors and auditors.
• Awareness/Visibility: The frameworks themselves raise awareness about cybersecurity and promote best practices.

How do you choose a framework?

Depending on your business sector or organizational status, which framework you follow may already be mandated. For example, a company that is publicly traded will need to comply with the Sarbanes-Oxley Act (SOX), so it may use the Control Objectives for Information and Related Technologies (COBIT) framework to achieve this. For US government agencies, the National Institute of Standards and Technology (NIST) regulations must be followed. What if you are not mandated to follow a certain framework? Then you focus on a framework that can help you address one of more of the following:

• Risk:
  • Encompasses risk identification, analysis, evaluation, treatment, and monitoring.
  • Facilitates ongoing monitoring and reporting of compliance efforts.
  • Helps the organization prioritize effort based on risk.
• Control:
  • Provides a high-level strategy for the cybersecurity team.
  • Platform-agnostic set of security controls.
  • Easy-to-digest current state of the organization.
• Program:
  •  Covers the whole organization.
  • Assesses the organization’s current state in a single place.
  • Measurable.
  • Brings the whole organization into a common language from technical team to executives.

Are there downsides to using a framework?

If a piece of work is improving the security posture, ultimately there is no downside to it, however that doesn’t mean it can’t be critiqued. There is a common misconception that if you have a followed a security framework, then you are completely secure. While you are better protected than you were before, your security posture must still be validated with assessments and penetration tests (pentests).

Organizations are complex places, and a one-size-fits-all approach can lead to both over-investment and under-investment in certain areas if they have not been properly risk assessed. While it is expensive to implement a framework, it’s also costly to maintain it going forward, which can leave an organization vulnerable if they do not invest in both implementation and continuous maintenance.

Examples of popular frameworks

• NIST CSF (Cyber Security Framework)
• CIS Controls
• ISO/IEC 27001
• Payment Card Industry Data Security Standards (PCI DSS)
• General Data Protection Regulation (GDPR)

Summary

Security frameworks provide organizations with structured guidelines and methodologies that align with industry standards, best practices, and regulatory requirements. Choosing which framework to implement is no small task and requires a significant financial investment and time commitment. Ultimately, adhering to a framework will improve the security posture of the organization, but do not become a victim of a false sense of security. Following the framework alone does not make you secure—you must also conduct security assessments and penetration testing to ensure agility in the face of continuously evolving threats.

Let’s kick this off by taking a step back and asking the question, “Why implement cybersecurity?” Compliance? Yes. Regulation? Yes. Continuous operation? Yes. You get the idea, but the common factor among all of these is ensuring that the business continues to function and that its data is protected. A business function can have downtime, but as long as the data is protected, there is still a valid business function to resume. If a business loses its data, then it can quite literally cease to exist—and that is before the regulatory bodies have begun to impose fines and penalties. Let me conclude the last three sentences in a more concise manner: the root reason for cybersecurity is to protect the business’ data. This blog post will cover what personally identifiable information (PII) is and the processes for discovering, protecting, and testing that business-sensitive data.

What is PII?

In terms of cybersecurity, data is often referred to as PII—information held by a company that could be used to identify an individual. PII is the focus of many cybersecurity strategies because its loss or mismanagement can draw steep financial penalties. The strategy is a little bit more complex than this, however. While security strategies should certainly focus on PII, any and all data that could lead to failure of a business operation should also be managed in the same manner.

Data discovery and classification

Now comes the fun part—implementation. This can be done manually, but it is quite time-consuming and complex. The reality is, to be effective, automation is required. The typical steps for data discovery and classification are:

1. Define all data sources that need to be classified, such as:
   1. a. All datasets, cataloged and non-cataloged, on all volumes defined to the LPAR
   2. b. All UNIX filesystems
   3. c. Any databases: IBM^® Db2^®, IBM^® IMS^™, virtual storage access method (VSAM), SQLite, etc.
2. Work with the compliance team to define classification labels, such as:
   1. a. Public data
   2. b. Private data
   3. c. Internal data
   4. d. Confidential data
   5. e. Restricted data
3. Work with the compliance team to define filters that will automatically detect potential data types, such as a credit card number, and load them into your automation solution
4. The following steps will now become your normal, continuous process:
   1. a. Scan the system to find any unclassified data
   2. b. If the data matches a filter, auto-define that classification and send for approval; if no filter is matched, classify as unknown and send for manual review
   3. c. Periodically check a compliance sample to ensure the method is compliant with the set of controls

How to protect your data and validate the protection

The level of protection applied to data should be directly correlated to the classification. Using an external security manager (ESM) like IBM^® RACF^®, ACF2^™, or Top Secret to protect the data makes a lot of sense as it can then be built into roles, identity access management, and the organization’s privileged access solution. The ESM can also be further utilized to categorize data, with the use of level ranges , which can directly correlate to classifications (e.g., everything over 100 is restricted data). To validate the protections put in place, regular security assessments and penetration testing (pentesting) will find any vulnerabilities.

Test data

One of the failures often found by the BMC Mainframe Security Services pentest and assessment team is that sensitive data has been copied for testing. The solution to this issue is to obfuscate production data when it is used for testing. When we talk about obfuscating data, it is not as simple as using a cipher offset of 1 to change every a to b and 1 to a 2. The data must behave the same as live data (for example, phone numbers need to reflect the location of the original phone number and a postal code needs to reflect the same area) for testing to be successful. Since generating test data is a continual requirement, using a software solution is the most sensible solution as part of your development lifecycle.

Summary

Finding out where your sensitive, PII, and organization-critical data is located is a key part of your security approach and must become part of your organization’s everyday strategy. Not only is it best practice, it is also part of many compliance frameworks. Following a discover, classify, and protect lifecycle will continually improve your organization’s security posture. When this process approaches maturity, it will put the organization in a strong position to explore implementing pervasive encryption. Further processes that should be brought into scope include roles matched to classification, as well as certain classifications of data accessed through privileged access only.

Learn more about how to prevent breaches and compliance violations in the BMC e-book, “Top 7 Security Priorities for Mainframe Leaders.”

Bridging the gap between “legacy” (I prefer the term “time-honored,”which gives the mainframe the respect it has earned) systems and the enterprise was once considered an arduous task. It was the can kicked down the road, the last platform to integrate on the program manager’s schedule. With the array of solutions available on the market today, integrating the mainframe with your enterprise’s IT service management (ITSM) or security operations center (SOC) has never been simpler.

While this blog post could just as easily cover general mainframe enterprise integration, when it comes to security, the two main integration points are ITSM and the SOC. Many would argue a third, equally valid integration point would be the JML (joiners, movers, leavers) solution and they would be right. I will touch on it later.

Just in case ITSM and SOC are new terms to you, I’ll define them. ITSM is the practical implementation of the ITIL^® framework. BMC Helix and ServiceNow are two examples of ITSM solution vendors; a few practical examples might be the portal where you request your new laptop or raise a change for your weekend go-live. The SOC is a 24×7 staffed security function that detects and responds to cyberattacks in real time.

Maximize your mainframe

With 80 percent of enterprise data residing on mainframe, imagine all the insights that could be yielded by including the platform in the enterprise’s centrally driven processes. From benchmarking the number of major incidents that occur following changes to how often a security incident makes its way to the SOC, there are a lot of business process that take a fork when it comes to the mainframe.

Currently, when we interact with our organization’s ITSM and request an item from the catalog, we don’t necessarily know which platform that request is for—we just request the application. There is no reason the mainframe cannot be maximized in this way. Platform-agnostic interfaces and standardized protocols are available for the mainframe and should be utilized. In essence, this can be summed up simply: If an integration is difficult or introduces toil, the chance of integration greatly decreases in favor of platforms that can be integrated.

ITSM

In principle, there are two ways the mainframe interacts with enterprise ITSM: as a request to the mainframe from ITSM or request to ITSM from the mainframe. Let’s first look at the ITSM tool sending a request to the mainframe. To put this in perspective, I will make this use-case-based—a privileged access request.

The user logs on to the ITSM solution and chooses privileged access from the catalog. In the request form, their mainframe ID is automatically filled out by making a REST call to the privileged access management (PAM) solution. The projects they can request are also populated in a drop-down list generated as part of the same initial REST call. The user selects their project and enters an ITSM change reference. If the change reference is approved, the user’s request can now be submitted. Upon managerial approval, the access will be granted through the ITSM tool based on the change window.

This example demonstrates a fully audited privileged access request linked to a change reference. Now, any actions executed on the mainframe side should also include the ITSM change reference for audit investigations or forensic analysis. Users only have to learn one system, which results in greater accuracy and less training overhead. The end-to-end auditing will also satisfy auditors in terms of controls.

The second use case is the mainframe sending a request to ITSM. There are events that happen on the mainframe that need to initiate a workflow, such as an alert to be investigated or a call to action. The use case to be highlighted here is suspicious behavior where it is known that no breach occurred. It should not be considered innocent behavior if a user tries to view a sensitive dataset but is denied. Automatically raising a ticket in ITSM from your real-time threat detection and alerting solution that notifies the security team to investigate is a sensible next action.

The third use case for ITSM and the mainframe is JML. Access can be requested as part of the catalog. There is therefore no reason, in theory, that the ITSM solution cannot make the call to take action on the JML request.

SOC

There are several major benefits to bringing your mainframe into scope of the enterprise SOC: comprehensive monitoring, early threat detection, improved incident response, better compliance, centralized management, and trend analysis.

There are two approaches to sending alerts to the SOC. The first is to send all security events and write indicators of compromise (IOCs) and indicators of attack (IOAs). The second is to use a product with out-of-the-box intelligence and work with the mainframe security team to write any site-specific alerts. Any data sent to the SOC needs to be usable—for the mainframe, this often means record enhancement, i.e., an employee name or IP address—so it’s vital to make sure SOC members have everything they need. Once alerts have already been sent to the SOC, the next step is making sure the SOC know what to do after they receive them. This can be anything from following a comprehensive playbook all the way to the on-call process for the mainframe security team.

Conclusion

Integrating the mainframe with enterprise ITSM and the SOC is a crucial step for any organization that has a mainframe, even if they’re currently migrating away from it. Bridging this gap will deliver greater insights into the platform behind the organization’s crucial workloads while improving compliance, reducing the risks associated with specific skills shortages, and bolstering the overall cybersecurity posture while reducing the attack surface.

Learn about seven ways your organization can take an enterprise approach to mainframe security in our E-book, “Top 7 Security Priorities for Mainframe Leaders.”

The mainframe has been around a while. Mainframe security came a little later, but to put it into context, IBM^® RACF^® (Resource Access Control Facility) was introduced in 1976. What else happened in 1976? Jimmy Carter won the U.S. presidential election, Concorde took its first commercial flight, and VHS video tapes were launched to compete against Sony’s Betamax. So, what does RACF, which pre-dates most high-end tech companies, have to do with a security risk? The short answer is potential technical debt. Technical debt—accrued by delaying necessary work in the name of expediency—is part of working in IT, but when it comes to security, it can lead to vulnerabilities. Without due process, housekeeping, and continual service improvement there is the potential for decades worth of mismanagement in privileged access being given to users.

What is privileged access management (PAM) and why should it be part of your security strategy?

PAM is also termed “elevated access” and “breakglass,” among other names. PAM does exactly what it says—it manages privileged access. Applying PAM to your enterprise means removing all permanent access to anything considered privileged and instead implementing a process around granting privileged access to users on a temporary basis. This can be as simple as an email approval from a manager and an administrator manually giving and revoking access; users requesting access through a web portal which triggers a managerial approval request; or having your ITSM call a piece of software that grants and removes access. PAM should be part of your security strategy because it implements a least-privileged approach and works toward zero trust, resulting in fewer accidental changes due to permanent privileged access being removed and providing an audited approval trail of privileged access usage.

Defining privileged access in your organization

The National Institute of Standards and Technology (NIST) defines a privileged user as “A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.” Would it therefore be fair to assume that any access that is classified as a security-relevant function should be controlled via PAM and the job is done? Maybe, but mainframe controls are very granular, so we can therefore go a bit further.

First, each role needs to be approached differently. For example, your database administrator cannot have the same criteria as the security engineer. A good rule of thumb is that any access that can risk the integrity of business data or any access that can risk business operational continuity should be considered privileged. One thing to keep in mind when segregating privileged and non-privileged access is that a lot of breaches and outages happen entirely accidentally by non-malicious employees who simply have privileged access, which makes mistakes catastrophic.

Implementation

There are two notable parts to implementing PAM in the enterprise. One is very obviously the technical, but not to be overlooked is the political. You are going to be changing the way potentially thousands of people work and may have done so for decades. There can be pushback around the idea of lack of trust and productivity. Ultimately, the message is simple: Follow best practices and PAM should not be a hindrance. As for the technical part, the roles identified with a lot of privileged access make the most sense to bring under PAM first. The organization must decide how they will action PAM requests, whether manually or through a software-based solution. Before any access is moved under PAM, it is imperative that comprehensive training is done to roll out on the sandpit system and pre-production it before going live.

Periodic reviews and access reduction

Once PAM has been implemented and is live for a suitable period, it is time to begin regular reviews. If anyone has not elevated their ID using PAM for a period deemed appropriate by the site, then they should no longer have the right to request it as it is evidently not required by them. The access given when the user selects privileged access should also be reviewed—if the sysprog’s privileged group is not using certain access over a set period, then it can be deemed not used and removed. Caution should be exercised here, as there can be caveats.

Joiners, movers, and leavers

Using privileged access is part of many roles on the mainframe, and one often-overlooked aspect is implementing it into the joiners, movers, and leavers (JML) process of the organization. If a role requires privileged access, anything that is required in order to request it should be actioned at the point of user creation and again when the user changes roles or leaves an organization.

Summary

To conclude, PAM should be part of your least-privileged strategy while you constantly work towards zero trust. As access becomes much harder to abuse, it is a very quick and effective way to flush out malicious behavior because PAM can help identify it by quickly checking whether the events are being actioned while elevated and cross-refencing the approval to understand the work being carried out. A PAM solution can also help keep a system compliant while simplifying the audit process around access controls.

Learn seven ways to take an enterprise approach to securing the mainframe in the white paper, Top 7 Security Priorities for Mainframe Leaders.

What is security hardening?

Security hardening is the business process of reducing vulnerability to an internal or external attack by examining all vectors. This should be a continuous process that falls under the scope of attack surface management (ASM), but organizations have neglected the process on the mainframe for so long that they’re in need of a starting point.

Where to start?

Let’s say you have just started your new job as the mainframe security team lead and have been informed there is an audit coming up. Your first question is probably, “Could I see the results of the last pentest (a.k.a. penetration test), please?” All too often the answer is, “What pentest? The mainframe is out of scope.”

Let’s clarify one thing—the mainframe is not out of scope and should never be deemed as such. The organization’s most valuable data is stored on the mainframe and security of the platform should be a top-tier priority.

To kick off your new security hardening program, you’ll first need to assess your landscape and understand the current state of the system. This means having a third party perform a full-detail security assessment, which is the quickest way to understand the state of your system and includes the operating system, network, Unix system services (USS), external security manager (ESM), and all subsystems. While a pentest will confirm whether it’s possible to breach your system, an assessment is more valuable, providing an industry-scored vulnerability rating that can be indexed to help guide your priorities as you begin hardening the mainframe.

It’s important to note that the assessment should be performed by an external organization. Conducted with automated tooling and a bigger view of the ecosystem, it will be far more in-depth than an internally performed review.

Next steps

Now that you have your assessment, it’s time to analyze the report and work with the organization that performed the assessment to help build a remediation plan:

• At the top of your list should be any easily exploitable high-impact assets, such as un-protected authorized program facility (APF) libraries. Yes, there is a risk in making changes, however the threat here is more likely to be human and, based on job role, you can quickly identify who should have access to these datasets. If the risk team is blocking changes, another quick win is to use a privileged access manager and put the access behind a manager-approved auditable change record.
• Next, organize all other remediation tasks into a continuous service improvement plan, which is a rolling process. If ten years’ worth of manpower is required to carry out this work, your organization needs to adopt a pragmatic approach. This may mean expanding the team, but at the bare minimum, every vulnerability should be logged in a risk register and shared, with sign-off from the compliance team.
• Now it’s time to breathe. The dust has settled, you know where the vulnerabilities are and have an approved plan to remediate them. Sadly, for any security professional, the bad actors are also aware of this, and the mainframe is still vulnerable to a never-ending list of complex attack vectors.

An agile and ASM approach to mainframe security that ensures the mainframe adheres to the National Institute of Standards and Technology (NIST) cybersecurity framework is essential to addressing the continuously evolving attack landscape. While this approach will include software solutions, you can still start your security hardening immediately with a rolling security assessment that will validate remediation and a pentest that will confirm it.

In Summary

Mainframes need to be secure—there is no debate. The good news is that, with a focused approach and organizational investment, there is no reason this can’t be achieved. Once the storm has calmed and you’ve begun the hardening process, it’s important to start thinking more laterally, and with 95% of breaches being human error, you should never underestimate in the value of education.

It may seem difficult to find a starting point in the process, but by following the above steps, you can begin a continuous process of hardening the mainframe and protecting your organization from costly and damaging breaches.

Download this E-book to learn seven ways you can take an enterprise approach to mainframe security.

The cost of weak mainframe security just got a lot steeper. Following a series of high-profile, massive data breaches in Australia, the nation’s government has just passed new legislation increasing maximum penalties for allowing such incidents more than twentyfold—to $50 million or more. Australian businesses are on notice: effective mainframe threat protection, detection, and response is now a top priority. As it should have been all along.

While numerous large Australian companies have suffered major data breaches in recent weeks, including Energy Australia, Telstra, G4S, Costa Group, MyDeal, and Dialog, two especially large incidents drew intense focus from both customers and lawmakers.

In September 2022, Australian telecommunications giant Optus disclosed a breach of the personal data of ten million of its customers—or roughly 40 percent of the entire population of Australia. The stolen data included not only names, addresses, phone numbers, and email addresses, but also especially sensitive information such as birthdates, passport numbers, and driver’s license numbers.

The $1 million ransom being demanded by hackers is only the beginning of the company’s problems, as possible class action lawsuits loom. As one local attorney noted, “This is potentially the most serious privacy breach in Australian history, both in terms of the number of affected people and the nature of the information disclosed.”

Just weeks later, health insurer Medibank Private suffered a breach that compromised the medical information of 9.7 million people—some of which was subsequently released on the dark web. In addition to customers’ names, birth dates, and passport numbers, the hackers revealed information on medical claims filed by these individuals, including sensitive procedures such as miscarriages and terminated pregnancies.

As private personal data continued to flow through porous enterprise defenses and into the hands of hackers, Australian legislators decided that they’d seen enough.

The soaring cost of a mainframe data breach

The recently passed Privacy Legislation Amendment (Enforcement and Other Measures) Bill 2022 represents more than a merely incremental increase in fines. Since 1988, companies allowing serious or repeated privacy breaches have faced a penalty of $2.2 million. Starting now, they can be forced to pay whichever is greater of:

• $50 million
• Three times the value of any benefit obtained through the misuse of information
• Thirty percent of the company’s adjusted revenue in the relevant period

Attorney General of Australia Mark Dreyfus justified the increased penalties given the role that lax mainframe security played in allowing such breaches to occur, saying, “Unfortunately, significant privacy breaches in recent weeks have shown existing safeguards are inadequate. It’s not enough for a penalty for a major data breach to be seen as the cost of doing business.”

And regulatory fines are only part of the cost of a mainframe data breach. According to IBM, additional post-attack expenses typically encompass investigations; crisis management; communications with customers, regulators, and lawyers; business costs including downtime, lost customers, and reputational damage; and legal expenses.

How BMC helps customers avoid data breaches—and the resulting penalties

Most mainframe organizations are already well aware of the urgency of strengthening data protection. In the latest BMC Mainframe Survey, 67 percent of respondents cited security and compliance as their top priority, a six-point increase over last year. Much work remains to be done; 80 percent of respondents reported that a security audit had identified vulnerable user accounts, while 34 percent found that their mainframe had been accessed in an unauthorized manner.

BMC helps customers strengthen mainframe data protection with solutions including BMC AMI Security, which leverages artificial intelligence and automation to continuously detect and respond to threats on the mainframe. Automated protection, detection, and response capabilities scan databases for suspicious activity in real time and halt malicious actions even before systems are compromised. To accelerate incident response, BMC AMI Security correlates data across multiple systems and translates it into common security terms for clear, actionable intelligence. Integration with leading security information and event management (SIEM) tools and BMC Helix enables real-time visibility so security and IT operations (ITOps) teams can see all actions occurring on the mainframe with a timeline of actions to quickly investigate security incidents.

Even before a threat has been identified, BMC AMI Security performs continuous policy scanning to uncover configuration vulnerabilities so mainframe teams can proactively close security gaps. Granular reporting provides detailed insight into threat events, suspicious activity, and regulatory compliance risks, while real-time alert and audit trails help improve adherence to standards including the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), and General Data Protection Regulation (GDPR).

The newly passed Australian privacy law is only the latest move by legislators and regulators worldwide to increase the cost of lax data protection—and it won’t be the last. As mainframe teams in Australia and elsewhere seek to strengthen the security of this business-critical platform, they’ll need to leverage the full power of automation, artificial intelligence, and integration to stay one step ahead of hackers. BMC can help. To learn more, explore BMC AMI Security.

The days of siloed mainframe security—or a lack thereof—are over. Once upon a time, assumptions about the inherent security of the platform led to a certain amount of complacency in many organizations, even as they worked overtime to protect other types of systems from rising threats. Now, mainframe leaders recognize the vulnerability of critical mainframe data, and they’re moving quickly to ensure that the right protections are in place. Just as importantly, they understand that this effort must take place in an enterprise-wide context, as part of a unified set of security strategies and processes across distributed and mainframe systems.

In a recent session at BMC Exchange, our premier customer-focused event, Mark Banwell, Senior Director of Product Management at BMC, explored the journey to extend enterprise-wide Zero Trust security to the mainframe. Highlights of his presentation follow.

Zeroing in on Zero Trust

The urgency of strengthening mainframe protection comes through loud and clear in the results of the 2022 BMC Mainframe Survey, in which the overall focus on mainframe security jumped to 67 percent from 61 percent the previous year. A full one-quarter of participating mainframe leaders named managing security across the enterprise as their top priority, as alignment of security strategies across platforms gains increased emphasis. Today, that means evolving to a Zero Trust model.

In simple terms, Zero Trust means eliminating implicit trust of users or devices, and instead continuously validating every stage of digital interaction between human or machine identities and the systems they seek to access. Offering dramatic reductions in both risk and cost, Zero Trust has quickly become the definitive strategy for organizations to meet their security and compliance goals.

As organizations seek to extend Zero Trust to their mainframe as part of an enterprise-wide approach to security, many turn to BMC to discuss their business use cases, explore their implementation options, and design a Zero Trust journey that aligns fully with the rest of the organization. This process encompasses five areas of the enterprise ecosystem: data, people, workloads, devices, and networks.

Data

Ensuring the security and integrity of mainframe data is a clear priority—and in most cases, there’s considerable work to be done. In fact, in 15 years of performing the security assessments and penetration tests with which these engagements begin, BMC has never found an environment without significant security issues to be addressed. In many cases, BMC services teams work with customers to improve their security architecture, remediate any areas that need remediation, and use BMC tools to recover any data that has been corrupted or encrypted by a bad actor.

People

A core principle of Zero Trust is least privilege: users should be allowed only the minimum level of data access required to perform their job function. Most organizations already have a role-based access system that defines these privileges for users on distributed systems. By using a BMC connector to integrate this system with the mainframe, you can accelerate your Zero Trust implementation while ensuring consistency across platforms.

In addition to limiting data access, Zero Trust call for a real-time threat detection and response capability. This includes identifying bad actors using stolen credentials—or malicious insiders using their own credentials—to try to elevate their privileges and access unauthorized data. BMC enables organizations to monitor system and user activity;, spot suspect behavior as it happens; deliver this information to the security operations center (SOC); and address the threat in real time. When user behavior raises concerns but falls short of an immediate threat, real-time tracking can be activated to help audit and investigate this activity in order to determine an appropriate response.

Workloads

System activity can also signal a potential security issue. BMC command center products provide mainframe teams with real-time capture, enrichment, and analysis of operating system and subsystem data to help them understand what’s happening—or what’s happening that shouldn’t be—in the mainframe environment. Integration with leading security information and event management (SIEM) tools helps security responders and operations teams shut the window of opportunity for attackers before it’s too late.

Devices

Zero Trust applies to identities of all types—including both human and machine accounts. Managing the thousands upon thousands of digital certificates used to verify device and service accounts across the enterprise can be a major challenge, and even one expired or misconfigured certificate can increase the risk of a breach or service outage. BMC now makes it possible to automate digital certificate management on the mainframe with the same Venafi tool already being used on most distributed platforms to enable efficient, consistent Zero Trust for machine identities across the mainframe.

Networks

Just as least privilege limits the amount of data a user can access, network micro-segmentation limits the systems and data that can be reached—another key element of the way Zero Trust shrinks the attack surface. BMC enables a unified approach to network micro-segmentation across mainframe and distributed systems by providing a two-way interface between the mainframe and the Illumio Zero Trust segmentation platform. Even if a breach does occur, the hacker or malware is unable to move laterally to other mainframe or distributed systems.

To learn more about bringing the mainframe into enterprise-wide Zero Trust, including the role of automation and analytics, stream the replay of the entire BMC Exchange session here.