DORA Regulation
17 active rules checking EU Digital Operational Resilience Act (2022/2554) compliance for financial entities, plus DORA-NET-033, which is registered but not evaluated. DORA establishes uniform requirements for the security of network and information systems supporting business processes in the financial sector.
| Rule ID | Severity | DORA Reference | Category | Summary |
|---|---|---|---|---|
| DORA-NET-001 | HIGH | Art. 9(3)(a) | Insecure Protocols | Unencrypted protocol detected |
| DORA-NET-002 | CRITICAL | Art. 7(1) | Deprecated Protocols | Deprecated or broken protocol detected |
| DORA-NET-010 | CRITICAL | Art. 9(4)(b), Art. 9(4)(c) | Overly Permissive | Any-to-any unrestricted traffic |
| DORA-NET-011 | CRITICAL | Art. 9(4)(c) | Overly Permissive | Overly broad source address |
| DORA-NET-012 | CRITICAL | Art. 9(4)(c) | Overly Permissive | Overly broad destination address |
| DORA-NET-013 | CRITICAL | Art. 9(4)(c) | Overly Permissive | All ports or wide port range allowed |
| DORA-NET-014 | HIGH | Art. 9(2) | Overly Permissive | All protocols (ANY) allowed |
| DORA-NET-020 | CRITICAL | Art. 9(4)(c) | Network Segmentation | Direct internet-to-internal access |
| DORA-NET-021 | CRITICAL | Art. 9(4)(c) | Database Exposure | Database ports exposed from broad source |
| DORA-NET-030 | CRITICAL | Art. 9(4)(c) | Remote Access | Remote admin from external without VPN |
| DORA-NET-031 | HIGH | Art. 9(4)(c) | Administrative Access | Admin protocols from broad sources |
| DORA-NET-032 | HIGH | Art. 9(4)(c), Art. 28(5) | Third-Party ICT | Third-party ICT access from overly broad source |
| DORA-NET-033 | CRITICAL | Art. 9(4)(c) | Financial Messaging | Financial messaging infrastructure ports exposed (not evaluated) |
| DORA-NET-034 | CRITICAL | Art. 9(4)(c) | Container Exposure | Container/orchestration APIs exposed |
| DORA-NET-035 | CRITICAL | Art. 9(4)(c) | Risky Service Exposure | High-risk service from broad source |
| DORA-NET-036 | MEDIUM | Art. 9(2) | DNS and Covert Channels | DNS as covert channel from internal segment |
| DORA-NET-037 | CRITICAL | Art. 9(4)(b) | ICS/SCADA Isolation | ICS/SCADA protocol ports permitted |
| DORA-NET-038 | MEDIUM | Art. 9(2) | Rule Documentation | No application name or business justification |
The Severity column, like the Rules tab, shows the worst-case severity a rule can emit. Some rules emit a lower severity in less exposed cases:
- DORA-NET-011 and DORA-NET-012 are CRITICAL for an
anyor /16-or-wider address, and HIGH for a /17 to /20. - DORA-NET-013 is CRITICAL when all ports are permitted, and HIGH for a range of more than 100 ports.
DORA-NET-033 (not evaluated)
DORA-NET-033 would flag financial messaging infrastructure ports reachable from a broad, public or any source. There are no verified default ports for it: TCP 7777-7780, which an earlier version used, are not documented SWIFT ports. The check therefore needs a user-configurable port list, which netbobr does not have yet. Until then the rule is registered but never fires. The Rules tab shows it as "Not evaluated" with no toggle, and it is excluded from rule counts.
ICMP flows
ICMP has no ports, so an ICMP flow never triggers DORA-NET-013 ("all ports or wide port range"). The address rules still apply.
L2TP (UDP 1701)
DORA-NET-002 fires on any rule that permits UDP 1701, even when IKE (UDP 500) and NAT-T (UDP 4500) are permitted as well. With L2TP/IPSec, L2TP packets travel inside ESP (IP protocol 50), or inside UDP 4500 with NAT-T, so a firewall never needs to permit cleartext UDP 1701. A rule that does permit it allows unprotected L2TP sessions. For L2TP/IPSec, permit only UDP 500, UDP 4500 and ESP.
ICS/SCADA protocols
DORA-NET-037 fires for any flow that permits Modbus (502), S7comm (102), EtherNet/IP (44818) or BACnet (47808), including traffic within a single subnet. This is by design: these protocols have no authentication or encryption, so every rule that permits them deserves review. Confirm that the path stays inside a dedicated, segmented OT network.