Module · Enterprise

Network security,
observed from outside.

Continuous observation of exposed services, misconfigurations and the ports that shouldn't answer but do, for every entity in your portfolio. Passive fingerprinting on your full IP range, no noisy probes, no flagged scans.

Presented tool-agnostically, findings describe what is exposed, not how it was found.

At a glance

Network Security at a glance

Coverage

What we observe

Open ports, exposed admin panels, weak TLS, forgotten infrastructure. Everything visible to an unauthenticated attacker.

Scoring

How it's scored

Each observation maps to a published, versioned rubric. Click any score component to see the evidence behind it.

Action

What happens next

Findings route to the entity owner with remediation guidance. Scores update automatically when the fix is observable.

What we observe

  • Internet-facing IP addresses attributed to your organisation
  • Open ports and the services behind them
  • Service versions and their known CVEs
  • Administrative interfaces reachable from the public internet
  • Changes to exposure between scans

What arrives on a finding

  • Severity with the observation that produced it
  • The specific host, port and service
  • Service-level CVE detail where applicable
  • Remediation and an SLA
  • The compliance control the exposure breaks
Worked example

Anatomy of a finding

FindingAdministrative service reachable from the public internet
EvidenceThe host, port and service observed, with the version detected
Why it mattersManagement interfaces are a standing invitation to credential attacks and are rarely intended to be public
Who it affectsThe system owner, and anyone whose data sits behind that service
RemediationRestrict to a private network or VPN, or place behind an authenticating proxy
Network security view showing open ports and exposed administrative interfaces

Passive fingerprinting of internet-facing ports and services

What is assessed

What responds, on what port, running what

Network assessment from outside answers three questions in order: which hosts are reachable, which services respond on them, and what those services appear to be running. Everything else follows from that, including whether a known vulnerability applies.

The findings that matter most are rarely exotic. Exposed remote access (RDP, VPN portals, management interfaces reachable from the internet) is a recurring initial access vector in ransomware incidents, and it is the finding underwriters weight most heavily. Unsupported software is next, because end-of-life means no patches exist at all, which converts every future vulnerability into a permanent one.

Then there are services exposed by accident: a database listening on a public interface, an admin panel on a non-standard port that somebody assumed was obscure enough, a debug endpoint left enabled after a deployment.

Nothing is exploited

Why assessment stops at observation

The module identifies services and versions and matches them against known vulnerabilities. It does not attempt exploitation, and that boundary is deliberate rather than a limitation we would prefer to remove.

Exploiting a service to confirm a vulnerability means interacting with a system you do not own in a way that could disrupt it. On your own estate that is a decision you can make. On a vendor's, an acquisition target's or a tender bidder's, it is not, and the entire value of external assessment is that it works on companies who have not agreed to anything. Exploitation would forfeit that.

So findings are evidence-based rather than proof-based: this service, this version, this known vulnerability, this evidence. That is enough to prioritise and act, and it is honest about what it is.

Reading the findings

Version detection has limits, and pretending otherwise wastes your time

Version-based vulnerability matching produces false positives, and any assessment claiming otherwise is either exploiting or guessing. Backported security patches are the main cause: a distribution maintainer fixes a vulnerability without changing the version string, so the banner reports a version that looks vulnerable and is not.

This is why findings carry evidence and why disputing one is a factual conversation. If a service is patched despite its banner, that is checkable and the finding should go. A platform that cannot accommodate that ends up with security teams ignoring the whole feed.

The corollary is prioritisation. Weight exposure and exploitability over raw counts: an exposed management interface with no authentication matters more than a dozen medium-severity version findings on a host that serves static content. Counting findings measures how hard you looked; acting on exposure is what changes outcomes.

Questions

Common questions

Do you exploit vulnerabilities to confirm them?

No. Services and versions are identified and matched against known vulnerabilities, with evidence attached. Exploitation would mean interacting with systems we do not own, which would make assessing vendors and acquisition targets impossible, and that is the whole point of outside-in assessment.

Does that mean findings can be false positives?

Yes, and the main cause is backported patches: a maintainer fixes a vulnerability without changing the version string. Findings carry their evidence so a dispute is factual, and a finding that is wrong should go.

Which findings matter most?

Exposed remote access and unsupported software. Both are recurring initial access vectors, and both are weighted heavily by insurers for exactly that reason.

Is this the same as a penetration test?

No. A penetration test is deeper, authorised, time-boxed and involves exploitation. This is continuous, needs no authorisation, and observes rather than exploits. They answer different questions and the second does not replace the first.

Do you scan hosts we have not told you about?

Discovery finds internet-facing hosts attributable to the organisation, which is the point, the assets nobody listed are usually the ones nobody patches. Assessment is limited to what is publicly reachable.

How often does it run?

Continuously, with on-demand rescans. A service exposed on Tuesday and closed on Thursday should show as both events, not as a gap between quarterly reports.

Related

Where this connects

Attack surface management →

Discovering the hosts before assessing the services on them.

Cloud security module →

Exposed cloud management interfaces and storage.

Cyber insurance →

Why exposed remote access moves underwriting terms.

Rate your own network first

See what attackers and insurers see. Free for your own organisation.