Most organizations know which systems need to be publicly accessible. A website, VPN, customer portal or another business service usually has a clear reason for being reachable from the internet. The bigger problem can be systems that nobody remembers are still accessible.

Infrastructure changes over time. A new server is deployed, a supplier is given remote access, a test environment is made available or external administration is temporarily enabled. The application is later migrated, the supplier changes or the project ends, but part of the old configuration remains. After several years, what an organization believes it has exposed to the internet and what is actually accessible may no longer be the same.

Temporary access can easily become permanent

It does not have to be a server that someone forgot about ten years ago. An administrative interface for a network device, an old VPN service, a test application or remote access that was supposed to be temporary is enough. These systems are often not part of day-to-day operations, so they can remain outside the organization’s focus for a long time. Someone uses the production application every day, while an old service can remain accessible without anyone noticing. Being accessible from the internet is not a security vulnerability by itself. Many services must be publicly available for the business to operate. What matters is whether a particular service still needs to be accessible, whether it is still being used and whether it is securely configured. A VPN that an organization uses every day has a valid reason to be exposed. An administrative interface left open after a supplier intervention probably does not.

Documentation and reality are not always the same

The same applies to test environments. A production application may be regularly maintained while an old test instance remains available on a subdomain long after a project has ended. An organization may keep its servers updated but overlook a network device that has been running for years without significant changes. From the perspective of someone looking for systems from the outside, it does not matter whether something appears in the official IT asset inventory. What matters is whether it can be reached. Even a well-maintained inventory may therefore differ from the actual environment. Documentation can lag behind changes, temporary configurations can remain active and systems that are no longer used can continue operating. These differences between documented and actual exposure are easy to miss until someone has a reason to examine them more closely.

A list of vulnerabilities is not enough

A vulnerability assessment should not end with a list of software versions and detected CVEs. A finding needs to be considered together with the exposure and role of the system on which it was identified. The same vulnerability on an internet-facing system and on a system that is accessible only from a restricted part of the internal network does not necessarily have the same priority for the organization. The same applies to the results of automated tools. A scanner may report a large number of potential vulnerabilities, but that does not mean every finding actually applies to the system or that every finding is equally important. The result may depend on the detected software version, configuration or assumptions that the tool cannot independently verify. Some findings therefore need additional validation before it is possible to determine whether a vulnerability is actually present and how much risk it represents.

Without that analysis, it is easy to fall into a cycle where scanner output becomes the entire remediation plan. The organization fixes what was reported, runs the scanner again and receives another list. The same process then starts again. A new list does not by itself show that the environment is now significantly more secure or that the most important problems were addressed first. Vulnerability management is not an attempt to make every scan return an empty result. It requires distinguishing real and applicable findings from technical noise and deciding what should actually be remediated first.

A system also does not need to contain a known critical vulnerability to present a security problem. An unnecessarily exposed service, an insecure configuration or access that should have been removed long ago can be just as relevant to the security of the environment. This is why an independent security assessment needs to answer more than what a scanner found. It should determine what is actually exposed, validate relevant findings and assess their significance in the context of the specific environment.

AresISEC, through its Vulnerability Assessment service, reviews systems, applications and infrastructure to identify security weaknesses and assess them in the context of the actual environment. The goal is not to produce the longest possible list of findings, but to determine which issues represent relevant risk and what should be addressed first.

Verify what you think you know

A useful first step can be a simple internal review. Compare the systems you believe are accessible from the internet with what is actually exposed. Check for test environments, legacy systems, supplier access and configurations that were originally intended to be temporary. If you cannot clearly explain why a particular system or service is accessible from the internet, it is worth checking whether it still needs to be.

The problem is not a service that needs to be accessible from the internet. The problem is the one nobody can explain why it is still there.

Sources:

• CISA – Internet Exposure Reduction Guidance
• NCSC – Carry out assessments by triaging and prioritising
• NCSC – Vulnerability management