ASD Essentials IT.PRO-09.2 Block Outbound Connections to Known Malicious and Untrusted Destinations Using Threat Intelligence
What it says
Block outbound network connections to known malicious or untrusted destinations.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBlocks systems from connecting out to websites and servers known to be dangerous or untrusted.
Computers and servers often connect out to the internet. The organisation blocks connections to places known to be dangerous, such as a phishing site or an attacker's server. It also blocks untrusted places, such as brand-new or poorly rated websites. To meet this, blocking covers every route out. Block lists draw on several current threat sources and update on a set schedule. The organisation also blocks types of website it judges too risky.
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 1
- Boundary services
- Identity services (does not apply)
- Phase 2
- Critical processes and services
- Privileged environments (does not apply)
- Phase 3
- Business systems (does not apply)
- User devices (does not apply)
Why it matters
Without outbound blocking, a click on a phishing link reaches the attacker's site. Malware on a hacked server or internet-facing device can contact the attacker and send data out. Attackers also use unblocked routes out and new servers not yet on block lists.
How to implement
The network security team should put outbound blocking on every route out, such as internet gateways, remote access and cloud connections, starting with internet-facing systems.
Limit internet-facing services and devices to the destinations they need.
Network engineers should block known malicious IP addresses on all ports, unneeded outbound protocols and web requests made straight to IP addresses.
Force name lookups (DNS) through a service that blocks bad sites, and stop encrypted lookups that bypass it.
The threat intelligence lead should feed the block lists from several current sources of known bad sites, such as security vendor feeds and ASD advisories.
Automate updates on the set schedule, and alert on any failed update.
The head of security and risk owner should approve which website categories to block, such as brand-new, low-reputation and proxy sites that hide browsing.
Network staff enforce them with the threat lists, and owners revisit them as risks change.
Owners of critical systems should list the outbound destinations each one needs.
Remove direct internet access that bypasses blocking, and allow only approved destinations where practical, including in the cloud.
Keep it running
The network security team keeps blocking current. Block lists update on the set schedule, and each unblock needs a recorded approval and review date. Repeated blocks from one server or internet-facing device are investigated as a possible hack. Follow ASD's priority order: internet-facing systems first, then critical systems. Filtering browser traffic alone misses servers and malware, so check every network change and new cloud service for unfiltered routes out.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for a list of every route out, and diagrams showing the blocking on each.
Look at
Whether some systems or routes out, such as cloud servers or internet-facing devices, have no blocking.
Good evidence
Every route out from in-scope systems passes through outbound blocking.
- Check 2 of 5What an auditor asks for
Ask for
Ask the team to show test connections to known malicious sites from sample systems.
Look at
Whether any test gets through, such as by IP address, an outside DNS service or an unusual port.
Good evidence
Every test connection is blocked, whatever the system, protocol or route.
- Check 3 of 5What an auditor asks for
Ask for
Request the threat feed list, import history and when a recent advisory's sites were blocked.
Look at
Whether advisory sites were missed or blocked late, or updates are manual, single-source or failing unnoticed.
Good evidence
Several feeds update automatically on the set schedule, so advisory sites are blocked within it.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the approved category list and each filter's reputation and site-age settings.
Look at
Whether categories, reputation or site age go unused, or high-risk categories are allowed with no recorded reason.
Good evidence
Every filter enforces the approved categories, reputation and age checks, and each exception has an expiry.
- Check 5 of 5What an auditor asks for
Ask for
Ask which outbound destinations each critical service needs, and request its outbound rules.
Look at
Whether critical servers or cloud components reach the internet directly, bypassing the blocking.
Good evidence
Critical systems have no unfiltered route out, and their outbound rules match their documented needs.
ASD indicators of good practice (9)
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(3)
- NE-1No controls are deployed to prevent systems from establishing outbound connections to known malicious or untrusted destinations.
- NE-2Blocking decisions are not informed by current threat intelligence.
- NE-3Destination categorisation is not used.
Partially effective(3)
- PE-1Controls to prevent outbound connections being established are deployed but cover only a subset of in-scope systems or egress paths.
- PE-2Threat intelligence is used to inform block decisions for outbound connections, but updates are infrequent, manual or limited to a single source.
- PE-3Categorisation is in place, but the categories blocked do not reflect the organisation’s risk position.
Fully effective(3)
- FE-1Controls are deployed and applied across in-scope systems, egress paths, services, and network boundaries.
- FE-2Blocking decisions draw on current threat intelligence, with destination lists updated on a cycle defined by the organisation.
- FE-3Destination reputation, category and age are considered alongside threat intelligence, with category-based blocking aligned to the organisation’s risk position.
Mappings
Closest match in ISO/IEC 27001: A.8.20, Network and Network Devices Security, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.20.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked. Egress filtering of this kind is a specific measure for controlling networks to protect information in systems and applications, contributing directly to Annex A 8.20. Annex A 8.20 is broader, covering the security, management and control of networks and network devices as a whole.
This control partially overlaps A.8.23.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked. It shares common ground with Annex A 8.23, since blocking known malicious websites is a core web filtering measure for reducing exposure to malicious content. IT.PRO-09.2 applies to all outbound connections rather than only web traffic, while Annex A 8.23 covers wider management of access to external websites.
This control supports A.8.7.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked. This supports Annex A 8.7 by stopping systems from reaching malware distribution and command and control infrastructure, limiting both infection and the impact of any malware that does run. Annex A 8.7 covers malware protection more broadly and requires user awareness, while IT.PRO-09.2 is one network-level measure that also addresses threats other than malware.
ASD Information Security Manual: 4 mappings
This control partially overlaps ISM-0958.
IT.PRO-09.2 requires outbound connections to known malicious or untrusted destinations to be blocked; ISM-0958 requires an organisation-approved list of domain names or website categories for all HTTP and HTTPS traffic through gateways, an approved-list approach to that blocking.
This control partially overlaps ISM-0963.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked; ISM-0963 requires web content filtering of potentially harmful web-based content, which overlaps on web traffic but filters content rather than destinations.
This control partially overlaps ISM-1171.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked; ISM-1171 requires web content filters to block attempts to access websites by IP address instead of domain name, one specific outbound blocking rule for web traffic.
This control partially overlaps ISM-1236.
IT.PRO-09.2 requires outbound network connections to known malicious or untrusted destinations to be blocked; ISM-1236 requires web content filters to block malicious domains, dynamic domains and domains that can be registered anonymously for free, a specific web case of that.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.