There is a thought experiment worth doing periodically if you are responsible for a network: imagine you know nothing about it except what is visible from outside. No internal documentation. No architecture diagrams. No knowledge of what services are running or what their purpose is. What can you learn? How long would it take? What would you find that the people who built the network would not expect you to find?

Attackers do this thought experiment in practice. The external view of a network is the starting point for any external attacker, and the difference between what network defenders think is visible and what is actually visible is, consistently and across many different organisations, larger than the defenders expect. Not because defenders are negligent — though negligence occurs — but because networks accumulate exposure the way buildings accumulate history: incrementally, over time, with each addition made for a good reason that did not fully account for its interaction with everything else.

What answers

The first question the external view answers is: what responds? A scan of the address space allocated to an organisation, looking for open ports and responsive services, produces a list of what the network is advertising to the world. This list is not secret — it is, by definition, visible to anyone with a connection and a scanner — but it is frequently unknown to the organisation's security team in its entirety.

The things that respond are not always the things that are supposed to respond. Development systems exposed to the internet because someone forwarded a port and forgot to remove it. Legacy services that should have been decommissioned years ago but are still running because something unknown is still using them. Management interfaces — SSH, RDP, web consoles — reachable from the internet because the original deployment decision was made before the organisation had a policy about this. These things are visible. They are not in the network diagram. They are in the scan.

What banner grabs reveal

Most network services, when connected to, offer identifying information before they require authentication: a banner that typically includes the software name and version. A web server responds with a Server header. An SSH server sends a version string. An SMTP server announces its software and version in the connection banner. These banners exist for debugging and interoperability. They are also a public announcement of what software is running.

The security implications are direct: a version string that corresponds to a known-vulnerable version is a confirmed attack surface, visible without authentication. Banner enumeration is one of the most productive activities in the early stages of an external assessment because it requires no credentials, leaves minimal traces, and frequently yields actionable findings without further investigation.

The gap between diagram and reality

The network diagram represents intent: what was planned, what was provisioned, what is managed. The scan represents reality: what is actually running. The difference between them is not exclusively composed of legacy and mistakes. Some of it is shadow IT — services deployed outside the formal provisioning process. Some of it is infrastructure that is technically managed but whose exposure has not been reviewed. Some of it is things the diagram simply does not show because the person who drew it focused on a different layer of the stack.

Part 2 will look at the inside view: what the logs show, how the external attacker's behaviour appears in the log record, and how to read the gap between external reconnaissance and internal visibility. The external view tells you what is exposed. The internal view tells you whether anyone noticed.

The PING sent from outside your network does not care about your diagram. It cares about what answers. The honest security assessment starts by finding out what answers, and comparing that to what you thought would answer. The gap is the agenda.