ASD Essentials IT.PRO-18.2 Restrict Lateral Movement Between and Within Segments to Approved Pathways and Services
What it says
Limit lateral movement between, and within, network segments to explicitly approved pathways and services, based on business requirements and trust levels.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishLimits connections between and within network segments to explicitly approved routes and services matching business need and trust, stopping intruders roaming freely.
Lateral movement means an attacker hopping from one system to the next after getting in. Systems may reach each other only on approved routes and services, whether they sit in different network segments (separate parts of the network) or the same one. To meet this, each route serves a real business need, suits both systems' trust levels and is recorded. Everything else is blocked, such as remote desktop between servers that never need it.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
- Business systems
- User devices (does not apply)
Why it matters
If movement is limited only between segments, or not at all, attackers can hop between systems using remote desktop, remote management and file sharing. One hacked system can then lead to the directory, admin systems and critical services.
How to implement
The network architect should list every needed connection between and within segments in a register, with its service, business need and each end's trust level.
System owners and the security team should explicitly approve each before any rule exists.
Network and cloud teams should block traffic by default at every boundary between segments, and allow only register entries.
Use controls such as firewalls or cloud security groups, and allow remote admin only from approved admin environments.
Server and cloud teams should limit traffic inside each segment using a firewall on each server or per-system network rules (microsegmentation).
Block remote desktop, remote admin and file sharing between neighbouring systems unless approved, and manage these settings centrally.
The security team should test from one system in each segment, trying actions such as remote logins, file copies and unapproved connections.
Test across and within segments, then fix and retest every gap found.
The security lead should set a risk-based review cycle where system owners reconfirm each route's business need and trust levels.
The network team should remove unjustified routes, updating the settings and register together.
Keep it running
The network team sends every new or changed connection through change management into the approved routes register. Treat any connection found outside the register as unapproved: block it or take it through approval. Tighten routes in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems. Start by limiting what internet-facing devices can reach and which systems can reach the directory. Retest after major network changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved routes register and a settings export taken at the same time.
Look at
Whether live rules are missing from the register, or entries lack a business need or trust levels.
Good evidence
The register matches the live settings, and each entry states its business need and trust relationship.
- Check 2 of 5What an auditor asks for
Ask for
Request the rules at sample segment boundaries, with the approval behind each allowed rule.
Look at
Whether boundaries allow by default, or rules are broad, unapproved or ignore trust levels.
Good evidence
Every boundary blocks by default, and each allowed rule traces to an explicit approval.
- Check 3 of 5What an auditor asks for
Ask for
Ask how traffic inside segments is limited, and for firewall settings on sample servers.
Look at
Whether systems in the same segment can reach each other freely, including by remote desktop or file sharing.
Good evidence
Systems within a segment can reach each other only on approved services.
- Check 4 of 5What an auditor asks for
Ask for
Request the latest technical test of these controls, with results and fix records.
Look at
Whether testing never happened, skipped segments or traffic inside them, predates network changes, or left gaps open.
Good evidence
Current testing confirms the controls work in every segment, and every gap found is fixed.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the set review cycle, the latest review records and the change tickets that followed.
Look at
Whether no cycle is set, reviews lapse, or routes marked for removal stay in live rules.
Good evidence
Each scheduled review reconfirms need and trust, and unjustified routes are removed from rules and register.
ASD indicators of good practice (15)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(5)
- NE-1No controls limit lateral movement between or within network segments.
- NE-2Lateral movement is permitted by default across the environment, with restrictions applied only on an exception basis.
- NE-3Approved pathways are not documented.
- NE-4Lateral movement controls have not been validated through technical assessment.
- NE-5Pathways and services are not reviewed after initial approval.
Partially effective(5)
- PE-1Controls limit lateral movement between segments but no controls operate within segments.
- PE-2Restrictions are applied to some pathways, but the default position remains permissive in parts of the environment.
- PE-3Approved pathways are documented but documentation is out of date or incomplete.
- PE-4Validation has been performed but does not cover all in-scope segments, or is out of date.
- PE-5Pathways are reviewed, but findings are not actioned, or the review cycle is not defined by the organisation.
Fully effective(5)
- FE-1Controls limit lateral movement both between and within segments, with deny-by-default applied at each boundary.
- FE-2Pathways and services are explicitly approved based on documented business requirements and trust levels, with all other lateral movement denied.
- FE-3Approved pathways are documented, reflect the current configuration and identify the business requirement and trust relationship justifying each.
- FE-4Lateral movement controls have been validated through technical assessment with results documented and gaps remediated.
- FE-5Pathways and services are reviewed on a regular cycle defined by the organisation, with unjustified pathways removed and the configuration updated to reflect approved changes.
Mappings
Closest match in ISO/IEC 27001: A.8.20, Network and Network Devices Security, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.20.
IT.PRO-18.2 requires lateral movement between and within network segments to be limited to explicitly approved pathways and services, based on business requirements and trust levels. Restricting internal traffic in this way is a specific measure for controlling networks to protect information in systems and applications, as Annex A 8.20 requires. Annex A 8.20 is broader, also covering the security and management of networks and network devices generally.
This control partially overlaps A.8.22.
IT.PRO-18.2 requires lateral movement between and within network segments to be limited to explicitly approved pathways and services, based on business requirements and trust levels. It shares common ground with Annex A 8.22, as restricting traffic between segments is what makes the segregation of groups of services, users and systems effective. Annex A 8.22 requires the segregation itself, while IT.PRO-18.2 also restricts movement within segments, which goes beyond segregating groups.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML1.5.
IT.PRO-18.2 requires lateral movement within and between network segments to be limited to approved pathways by business need and trust; E8-RA-ML1.5 requires privileged users to use separate privileged and unprivileged operating environments, a related separation by privilege level rather than by network segment.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-0520.
IT.PRO-18.2 requires lateral movement within and between network segments to be limited to approved pathways; ISM-0520 requires network access controls that stop unauthorised network devices and IT equipment connecting, supporting it by controlling what can join the network.
This control partially overlaps ISM-1181.
IT.PRO-18.2 requires lateral movement within and between network segments to be limited to approved pathways and services; ISM-1181 requires networks to be segregated into multiple zones by the criticality of servers, services and data, creating the segments that action controls.
This control partially overlaps ISM-1182.
IT.PRO-18.2 requires lateral movement within and between network segments to be limited to approved pathways by business need and trust level; ISM-1182 requires network access controls to limit traffic within and between segments to business needs, a close match except for trust.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.