BCN-T1-NET-001Tier 1 · CriticalNetwork

Internet-Exposed Remote Administration Services

SSH, RDP, SMB, or equivalent management protocols reachable from the public internet.

Remediation SLA: 24 hours
Tier: 1 · Critical
Domain: Network
Escalation: CISO and executive sponsor notified at 48 hours

What this finding is

A remote administration protocol — most commonly SSH (22), RDP (3389), SMB (445), VNC (5900), or Telnet (23) — accepts connections from arbitrary internet addresses. The service may be fully patched and correctly configured; the finding is about reachability, not about a software defect. Exposure of an authentication surface to the entire internet is itself the condition being flagged.

Why it is Tier 1

Internet-facing administration ports are continuously enumerated by commodity scanning infrastructure, and a newly exposed RDP host typically receives credential-stuffing traffic within hours. These services are the single most common initial-access vector in ransomware intrusions, and the path from successful authentication to full administrative control is direct. Tier 1 applies regardless of patch level, because the exposure grants an attacker unlimited offline-speed attempts against your authentication.

Most common misclassification

Teams frequently downgrade this to Tier 3 when the service is patched and uses key-based authentication. Patch state does not change the tier: the finding is the exposure of an authentication surface, and it stays Tier 1 until reachability is removed.

How to detect it

1Run an external port scan from outside your own network — cloud-internal scanning misses exposure created by public load balancers and NAT rules.
2Query internet-wide scan data (Shodan, Censys) for your registered netblocks and cloud-assigned addresses to see what attackers already see.
3Audit cloud security groups and network ACLs for ingress rules with a 0.0.0.0/0 or ::/0 source on administrative ports.
4Review edge firewall and port-forward rules for legacy entries created for time-limited access and never withdrawn.

How to remediate it

Steps are ordered. The first step is the one that reduces exposure fastest, which is not always the one that closes the finding.

1Remove the ingress rule. This is almost always the correct fix and it is available immediately — do not begin with hardening the exposed service.
2Place administrative access behind an identity-aware proxy, a bastion with session recording, or a zero-trust access broker.
3Where a VPN is the chosen control, enforce phishing-resistant MFA on it — a VPN with password-only authentication reproduces the original problem one hop back.
4Restrict any residual exposure to an explicit source allowlist of known egress addresses, and set a documented expiry on each entry.
5Review authentication logs for the full exposure window before closing the finding — treat successful logins from unrecognised sources as a suspected incident.

How to verify the fix

An external scan of the address returns filtered or closed on the affected port, and the ingress rule is absent from the infrastructure-as-code definition rather than only from the live console.