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.