ASD ISM 1627 Block inbound traffic from anonymity networks
What it says
Inbound network connections from anonymity networks are blocked.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBlock connections from anonymous networks to keep the organisation's network secure.
This control is about blocking traffic from networks that let users hide their identity, such as those used for anonymous browsing. If these are not blocked, people with bad intentions could bypass security measures and access sensitive parts of your network, potentially leading to data theft or the spread of malware.
Free. Save your status, tasks and notes.
Why it matters
If inbound traffic from Tor and other anonymity networks isn't blocked, attackers can probe and access services while hiding attribution, increasing breach risk.
How to implement
IT team: Identify anonymity networks that you need to block.
Use network monitoring tools to compile a list of known anonymity networks like Tor or I2P that should be restricted.
IT team: Set up firewall rules to block identified anonymity networks.
Adjust your firewall settings so that any traffic coming from these sources is automatically rejected and cannot enter your network.
System owner: Work with the IT team to understand the implications of blocking anonymity networks.
Communicate to staff why these networks are blocked and provide alternative ways to access allowed content if necessary.
IT team: Regularly update the list of blocked networks.
Stay informed about new anonymity networks or changes in existing ones, and update your firewall rules accordingly to ensure ongoing protection.
Manager: Schedule annual reviews of the blocking strategy with IT and security personnel.
Base these reviews on reports of any incidents involving anonymity networks and adjust strategies as needed to enhance security.
Keep it running
Maintain deny rules for known Tor exit nodes and similar networks using refreshed threat intel lists, and alert on repeated blocked connection attempts.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of blocked anonymity networks: Request the documentation that outlines which networks are restricted from accessing the organisation's systems.
Look at
Networks like Tor or other similar ones on the list.
Good evidence
Is a comprehensive list that is current and includes the last update date.
- Check 2 of 5What an auditor asks for
Ask for
Firewall configuration documentation: Request to see the current settings on the organisation's firewall. Look to see if rules match the list of identified anonymity networks. Good evidence would be clear settings that align with the blocked lists and dates of last modification.
- Check 3 of 5What an auditor asks for
Ask for
Network traffic logs: Request samples of recent logs that show blocked traffic attempts.
Look at
Entries that detail attempted connections from anonymity networks.
Good evidence
Would be logs showing successful blocking actions with timestamps and network details.
- Check 4 of 5What an auditor asks for
Ask for
About staff education records: Request records of staff discussions or training regarding the impact of anonymity network blocking.
Look at
Session records or materials given to employees.
Good evidence
Shows regular staff engagement activities explaining the reasoning behind these controls.
- Check 5 of 5What an auditor asks for
Ask for
Incident reports involving anonymity networks: Request documentation of any security incidents where anonymity networks were involved.
Look at
Details on how the network was blocked or otherwise handled. Good records will confirm quick detection and resolution actions corresponding to the blocked networks.
Mappings
Closest match in ISO/IEC 27001: A.8.9, Configuration management for secure IT systems, which this control supports.
ISO/IEC 27001: 1 mapping
This control supports A.8.9.
ISM-1627 requires inbound network connections from anonymity networks to be blocked. Achieving consistent blocking at gateways and firewalls depends on ISO/IEC 27001:2022 Annex A 8.9 being in place so network/security device configurations (e.g. ACLs, threat-feed updates, rule baselines) are established, implemented, monitored and reviewed. Annex A 8.9 does not mandate anonymity-network blocking, but it is a prerequisite discipline for implementing ISM-1627 reliably and auditable.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.