Reduce the risk by inspecting and restricting unusual network protocols at the perimeter and between internal segments, not just HTTP and HTTPS. Baseline normal protocol use, block unauthorised tunnelling and remote-control traffic, and alert on protocols that carry command, staging or exfiltration data outside approved application flows.
How non-application protocols create risk
Non-application layer protocol become risky when security teams assume HTTP and HTTPS are the only meaningful channels. Attackers and misconfigured tools can hide command traffic, staging, or exfiltration in protocol types that rarely receive the same scrutiny as web traffic, which makes them easier to miss in segmentation, logging, and alerting.
The practical problem is not the protocol name alone, but the trust the organisation places in it. If a protocol is allowed everywhere by default, lacks a business owner, or is not tied to a known workload or service, it becomes a convenient path for tunnelling and remote control.
Normalise what should exist on each segment and treat everything else as suspicious until it is justified. That means baselining protocol use by environment, source, destination, and business purpose, rather than relying on a broad “allowed traffic” assumption.
Controls that reduce exposure
The first mitigation is perimeter and internal segmentation filtering that is broader than web controls. Use deny-by-default or tightly scoped allowlists for protocols that are not required, and restrict them between network zones so unusual traffic cannot move freely once it appears.
Baseline protocol use so the network team can distinguish approved administrative and infrastructure traffic from unexpected tunnels or relay channels. This is where a Firewall Management Guide is useful: rule review, default deny, and logging discipline are the control behaviours that keep “temporary” openings from becoming permanent exposure.
Detection should focus on patterns, not just signatures. Watch for protocols carrying command-and-control beacons, staging payloads, or outbound data that do not match the application flow expected on that segment. In practice, that means pairing port and protocol inspection with egress filtering and traffic analysis, rather than assuming a non-web protocol is benign because it is uncommon.
For teams that need deeper protocol-level context, the Command and Control (C2) Guide maps the traffic patterns that matter, including tunnelling, beaconing, and egress filtering decisions.
What to verify before you rely on the control
Verify that you know which protocols are genuinely required in each environment and which ones are only present because of legacy tooling or accidental exposure. If you cannot explain why a protocol is allowed, you cannot confidently say it is safe.
Also verify that your monitoring stack can actually see the traffic you are trying to control. A rule set without logging, or logging without protocol-aware alerting, often creates a false sense of coverage while the same traffic continues to pass.
At the external boundary, canonical protocol and port references help prevent guesswork. IANA is the right reference point when you need to confirm how a protocol or identifier is supposed to be registered and recognised, and to compare that against what your environment actually permits.
The point is to verify the gap between approved business traffic and observed traffic, then close the gap with policy, inspection, and alerting. If the network is full of “allowed” protocols that nobody actively owns, the control is already weaker than it looks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Restricting unusual protocols depends on secure baseline and configuration control. |
| Recommendation — Baseline allowed protocols and remove unneeded traffic paths from network and host configurations. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Perimeter and segment filtering are boundary protections against unauthorized protocol use. |
| AU-2 — Event Logging | Protocol anomalies are only actionable when the relevant traffic is logged for review. | |
| Recommendation — Enforce boundary controls that restrict and monitor non-approved protocol flows. Log protocol events and review them for unusual command, staging, or exfiltration patterns. | ||
| MITRE ATT&CK | T1095 — Non-Application Layer Protocol | The subject is specifically the abuse of non-application protocols for command and control. |
| Recommendation — Hunt for non-application-layer traffic used for C2 or tunnelling and alert on unexpected protocol use. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest and data-in-transit is protected | Restricting and inspecting protocol flows protects data in transit from covert movement. |
| Recommendation — Protect data in transit by controlling and inspecting the protocols that carry it. | ||
Practitioner Guidance
What to prioritise: Start with the protocols that can move off-segment data quietly, especially those used for tunnelling, remote administration, or embedded command traffic. If you begin with every protocol equally, you will spend time on low-value noise and miss the channels that matter most.
What to measure: Track the number of non-application protocols that are explicitly justified, logged, and monitored per segment. A shrinking set with stable owners is healthier than a large default-allow list that nobody can explain.
Common mistake: Teams often harden web proxies and WAFs while leaving other protocol families under-controlled. That leaves a blind spot where malicious traffic can blend into “infrastructure” behaviour and bypass the controls built for browsers, not networks.
Practitioner takeaway: Reduce risk by treating non-web traffic as a governed allowlist problem, not a background networking detail, because the strongest defence is knowing exactly which protocols should exist and being able to spot everything else quickly.