Cybersecurity cannot be a product: we tackled it the wrong way

For a long time cybersecurity was seen as a marginal problem. It was not a topic for the board of directors, it was not a topic for a structured budget, it was not even really a mature market.

When security was a craft

Security was done with few tools, a lot of technical skill and an almost artisanal ability to read systems. Reverse engineering, debugging, traffic analysis, code study, understanding architectures. There were no big platforms promising total protection. There were people trying to understand how things really worked, where they broke and why.

The paradox is that, even with fewer tools, the approach was often closer to the substance than it is today.

The main problem, back then, was the lack of awareness. Many companies did not understand the risk. An exposed database, a badly published service, a reused credential, a flat network with no segmentation: everything was perceived as a technical detail, not as a strategic problem.

Then it became a market and a product

Then something changed.

With the rise of public incidents, ransomware, data breaches and media attention, cybersecurity finally entered the language of companies. The market opened up, businesses started buying solutions, asking for services, demanding reports, dashboards, monitoring, certifications, compliance.

It was a necessary shift, but also a deeply ambiguous one.

Because the moment security became a market, it was turned above all into a product.

• For every risk, a license.
• For every attack, a platform.
• For every fear, a dashboard.
• For every technical variant, a new commercial module.

The result is that many genuinely offensive, architectural and analytical skills were absorbed into a system integration mindset. People who could have taken systems apart, thought like attackers and designed better defenses were often turned into expert installers, configurators or intermediaries for solutions made by others.

This is where cybersecurity took a questionable direction.

Security cannot be a product

Because security cannot be reduced to a product. It is not an appliance, it is not a piece of software, it is not a SOC running 24 hours a day, it is not a portal full of charts, it is not an automated report.

All of these tools can be useful. But only if they come after a good architecture.

The central point is that 90% of security is decided in the architecture.

Monitoring, patching, detection and incident response are important, but they come after. Tools for control, containment and reaction are not the heart of security.

A concrete case: VPN access for third parties

A concrete example makes the point clearer:

I am working on publishing an on premise product for a client, installed inside a company's internal infrastructure, which has to expose a critical service to the Internet and allow controlled external access.

When the owner asked "is it safe to publish it", the sales side immediately answered that it depends on how much you have invested in the latest security technologies, which is frankly disarming.

The most immediate solution, proposed by the integrator on site, is to give VPN access to external parties (including agents on devices over which there is not the slightest control).

At first glance it seems like an easy, normal, correct choice. In reality it can be extremely risky.

Giving VPN access to third parties often means bringing them too close to the internal network. Even with segmentation, dedicated subnets and firewall rules, it remains a delicate surface. You have to manage identities, devices, revocations, stolen credentials, MFA, logging, responsibilities, temporary access and privilege levels.

Another frequent strategy is the "isolate and monitor" one: you expose the service, separate it a bit, add logs, alerts, maybe some security product, and you sit and watch.

But monitoring does not mean protecting.

If the software is not under your own control, if patching depends on third parties, if the service is opaque and if the exposed surface is wide, monitoring becomes an elegant form of waiting. You observe the problem, but you do not really reduce it.

A correct architecture: no critical services exposed on the Internet

A correct architectural approach should start from a different principle: no internal critical service should be directly exposed on the Internet.

How we tackled the problem ( Note, we are leaving out the whole part about isolation inside the internal infrastructure, we are focusing only on the exposure of services and access ).

Traffic coming from the Internet arrives first at Cloudflare, with the proxy active and origin lockdown. The real address of the infrastructure is not published directly and access is restricted through firewall and security groups.

From there the traffic is forwarded to a public VPS with Nginx. But Nginx must not be treated as a simple reverse proxy. It has to become a decision point ( and this excludes 99% of the noise ).

The request is evaluated based on several signals: geographic origin, ASN, user agent, accept language, rate limit, behavioral patterns, consistency of the request and other indicators. From these elements a trust score is built IN THE PROXY.

If the trust score is high and the request carries a valid session cookie generated by a previous session, the traffic can be forwarded to the real backend.

But the real backend, in this design, is not a public machine, it is the application VM inside the internal infrastructure (isolated as it is). It has no direct exposure on a public IP and receives traffic only through an encrypted WireGuard tunnel from the VPS.

If the trust score is medium, the request should not access the backend directly. It can be subjected to additional validation: previous session cookie, correct credentials, 2fa and consistency of the request profile. Only if all these elements are valid is the traffic taken to the real backend.

If the trust score is low, or if session cookie, valid credentials, 2FA or behavioral consistency are missing, the request must not touch the real backend. It must end up in a honeypot.

The honeypot, in this case, can be a fake login page with no connection to the real service. It serves to hold suspicious traffic, collect signals, slow the attacker down and protect the backend. After a certain number of failed attempts, the IP can be automatically blacklisted in the various neighboring "systems".

The point is not to build a scenographic maze. The point is to prevent untrusted traffic from reaching the critical system.

The conceptual flow therefore becomes:

• The Internet goes through Cloudflare.
• Cloudflare hides the origin and restricts access.
• Nginx evaluates the request and computes a trust score.
• Only consistent and already recognized requests can reach the real backend.
• Intermediate requests are subjected to further validation.
• Suspicious requests end up in a honeypot.
• The real backend stays in the internal network.
• The database is accessible only from the application VM, with limited privileges and controls on queries.

The results: attack surface reduced before the products

With this architecture you obtain several important results.

• The production server is not directly exposed.
• The DNS does not point to the office or the internal servers. *
• The real address of the private infrastructure stays hidden.
• No generic VPN access is granted to external parties.
• Suspicious traffic does not reach the backend directly, forcing me to rely on the vendor's fast patch releases.
• The honeypot absorbs and identifies malicious attempts and lets me manage automated cascading hardening.
• The application VM exposes only what is needed.
• The database is unreachable and sits "under several layers".
• The user has no useless complications or disruptions in daily use.
• The attack surface is reduced drastically. ( 99% of the online noise is outside my infrastructure, only national or neighboring traffic reaches it, with a first level session credential pass, authenticated by 2fa on the proxy, which knows the application's credentials )

• Never publish the IP addresses of your internal infrastructures in DNS. Handing an attacker even a single IP of your public subnet means giving them your "home address": from there they can start reconstructing your exposed surface. If you do not provide this starting point, you stay much harder to locate, becoming 1 out of 2³² IPv4 addresses.

Cybersecurity is a design discipline

This is how security should be conceived: not as a sum of tools, but as a design.

Not because it eliminates every risk, but because it drastically reduces the chances of systemic error. Every component has a limited role. Every step has a function. Every access is conditioned. Every layer reduces the implicit trust in the previous one.

The problem is that today whoever actually designs these architectures is often considered just an integrator. An operational figure. Someone who "sets up the machines", "configures the services", "does the deploy".

It is a huge mistake.

Whoever decides how a service is published is doing security or creating the flaw. Whoever decides how a network is segmented is doing security or creating a problem. Whoever decides how a backend is isolated is doing security or exposing it to risks. Whoever decides how to reduce disclosure, privileges and attack surfaces is doing security.

Often far more than whoever watches alerts on a dashboard.

Cybersecurity must go back to being a design discipline. It must go back to dealing with architecture, not just product. It must stop confusing monitoring with protection, compliance with robustness, the dashboard with understanding.

If the architecture is missing, everything else is just a more expensive way to stay vulnerable.