Perimeter-only controls leave internal east-west traffic largely unobserved and can allow an attacker who gains a foothold to move laterally inside the environment. Mainframes are not isolated islands, they connect to cloud and enterprise systems, so the weak point is often the integration layer. Without internal segmentation, containment becomes much harder and security teams lose precision.
Why perimeter-only protection fails on mainframe-connected traffic
Perimeter controls mainly inspect traffic at the edge. Once a session, host, or application reaches the internal network, east-west flows can escape the same level of scrutiny even though they still carry sensitive commands, data, and trust relationships. That creates a blind spot around the integration layer, where the mainframe exchanges traffic with distributed systems, cloud services, and enterprise middleware.
The failure is structural, not cosmetic. Mainframe environments are often heavily trusted internally, so perimeter-only design can leave internal routes, shared services, and back-end application paths effectively open to misuse. If you want a broader view of how this shifts the security model, the Ultimate Guide to NHIs shows why machine-to-machine trust needs lifecycle and visibility controls, not just boundary defense, and NIST’s Cybersecurity Framework 2.0 reinforces the need to detect, protect, and respond across the full environment.
- Perimeter-only design assumes internal traffic is trustworthy, which is exactly where lateral movement becomes most useful to an attacker.
- The integration layer is usually the weakest point because it bridges legacy systems, application tiers, and cloud-connected services with different trust assumptions.
- Without internal segmentation, security teams lose granularity over who can reach what, so containment becomes broader and slower.
For practitioners, the important distinction is that “protected at the edge” is not the same as “protected in use.” Mainframe traffic often depends on persistent routes, middleware, and shared service paths, so a single perimeter control cannot meaningfully constrain movement once an internal foothold exists.
What attackers gain when east-west traffic is not segmented
When internal mainframe traffic is not segmented, an initial compromise can turn into reachability across adjacent systems. Attackers do not need to break the perimeter again if they can reuse trusted internal channels, pivot through middleware, or abuse overly broad access between application tiers. That is what makes east-west visibility and segmentation so important in environments where mainframes are integrated with modern workloads.
In practice, the risk is not limited to the mainframe itself. The attacker may target surrounding systems first, then use legitimate internal connections to reach transaction processing, data stores, or administrative interfaces. NIST’s Security and Privacy Controls are relevant here because access control, audit logging, and configuration management only work if the internal trust boundary is actually enforced. For integrated environments, OWASP API Security Top 10 is also a useful lens, since exposed service interfaces often become the bridge from a foothold to deeper internal access.
- Unauthorised lateral movement becomes easier because internal paths are often less monitored than perimeter traffic.
- Compromise containment gets weaker when one trusted service can reach many downstream systems.
- Operational triage becomes harder because defenders must separate normal integration traffic from attacker movement.
The practical takeaway is that segmentation needs to match the actual trust graph, not the network map on paper. If a workload can talk to a mainframe, ask whether that connection is necessary, narrowly scoped, and observable enough to support incident containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Perimeter-only failure is an access boundary problem across internal flows. |
| DE.CM — Continuous Monitoring | Internal mainframe traffic needs monitoring beyond the edge to spot lateral movement. | |
| RS.MI — Mitigation | Containment is the core issue once an attacker gains an internal foothold. | |
| Recommendation — Apply access control to constrain east-west paths and revoke unnecessary internal reach. Monitor internal traffic and alert on anomalous east-west mainframe access. Prepare containment playbooks that isolate compromised internal segments quickly. | ||
| CIS Controls v8 | 6 — Access Control Management | Internal segmentation depends on tightly managed authorization paths. |
| 8 — Audit Log Management | East-west mainframe traffic needs logs to make lateral movement visible. | |
| 12 — Network Infrastructure Management | Network segmentation is the direct control that limits lateral movement. | |
| Recommendation — Restrict internal access paths to only the systems and functions required. Centralise and review logs for internal mainframe and integration traffic. Segment network zones so compromised hosts cannot roam through trusted internal routes. | ||
| MITRE ATT&CK | T1021 — Remote Services | Attackers often pivot over trusted internal services after initial access. |
| T1210 — Exploitation of Remote Services | Poorly segmented integration points can be used to expand access laterally. | |
| Recommendation — Hunt for abuse of internal remote services and restrict unnecessary service exposure. Protect and monitor exposed internal services for lateral exploitation attempts. | ||
Practitioner Guidance
What to prioritise: Start with the integration paths that connect the mainframe to enterprise middleware, cloud workloads, and application tiers. Those are the places where perimeter-only assumptions usually fail first, because they combine high trust with broad reach.
What to verify: Confirm that internal traffic is logged, segmented, and restricted by function rather than treated as a flat trusted zone. If a service path can reach a sensitive mainframe function without a clear business reason, that is a containment problem, not just a network design choice.
What good looks like: Legitimate east-west flows are narrow, observable, and easy to revoke during an incident. If defenders can isolate a compromised segment without breaking core business processes, the architecture is doing real work instead of relying on the perimeter as a proxy for trust.
Practitioner takeaway: The question is not whether the perimeter still matters, it is whether internal trust boundaries are strong enough to stop a foothold from becoming full environment reach.
Related resources from NHI Mgmt Group
- What breaks when threat hunting only covers perimeter traffic in hybrid cloud environments?
- What breaks when organisations rely only on perimeter controls for autonomous AI traffic?
- What breaks when AI agent security stops at the perimeter and does not inspect tool execution and MCP traffic?
- What breaks when a Go route is not protected by middleware?
