Bizix GroupChecking status…
Home/Insights/Article

Blocking at the edge: what IPS/IDS with ML threat scoring does and does not do

A firewall opens ports. An IPS inspects what comes through them. What edge blocking with ML threat scoring stops, what it misses, and why logs matter.

“We have a firewall” is the most common answer we hear when asking a business about its security posture, and it is roughly as reassuring as “we have a front door”. A firewall decides which ports are open. It says nothing about what comes through the ones that are.

A firewall is a door, not a guard

A stateful firewall permits or denies connections based on addresses and ports. That is necessary and it is not nothing, but almost every service a business exposes, whether a web application, a mail gateway, a VPN concentrator or a remote desktop gateway, requires a port to be open, and the attacks that matter arrive through those open ports as legitimate-looking traffic.

An intrusion detection system, or IDS, inspects the traffic itself. An intrusion prevention system, or IPS, inspects it and drops what it decides is hostile before it reaches the target. The difference between the two is whether the system is allowed to act. Detection produces alerts that someone must read; prevention produces blocks that happen whether anyone is watching or not.

Where the machine learning sits

Classical IPS relies on signatures: patterns of known exploits, known malware command-and-control traffic, known bad addresses. Signatures are precise and cheap to evaluate, and they remain the backbone of any serious deployment. Their weakness is that they only catch what has already been catalogued.

ML threat scoring sits alongside the signature engine rather than replacing it. Models trained on large volumes of traffic learn what normal looks like for a given protocol, source or time of day, and assign a risk score to flows that deviate: a source that is enumerating paths on a web server, a client attempting logins at a rate no human produces, a connection whose timing and sizing resembles beaconing to a control server. Scores feed into the same decision pipeline as signatures, and above a threshold the flow is dropped at the edge, before it reaches a server and before the server has to spend any effort on it.

The practical effect is that a large share of the noise, the scanners, the credential-stuffing bots, the automated exploit attempts against products the business does not even run, never makes it past the edge. What remains is a much smaller and more interesting set of events for a human to look at.

What edge blocking actually stops

In our experience, an IPS with well-maintained signatures and behavioural scoring reliably stops:

  • automated exploitation of known vulnerabilities in exposed services
  • brute-force and credential-stuffing attempts against login endpoints
  • outbound connections from an already-compromised host to known control infrastructure
  • scanning and reconnaissance that precedes a targeted attack
  • volumetric noise that would otherwise fill logs and consume capacity

That last point is underrated. A quieter environment is easier to defend because the real signal is visible.

What it does not stop

An IPS does not stop a user handing their password to a convincing phishing page. It does not stop a contractor with a legitimate account doing something they should not. It does not see inside encrypted traffic unless it is deliberately placed in the path with the keys, which brings its own trade-offs. It does not patch the vulnerable application; it buys time until someone does. And it does not fix a flat internal network where one compromised laptop can reach every server.

The honest framing is that edge blocking removes a whole category of attack cheaply and continuously, so that the remaining budget of human attention can be spent on identity, patching, segmentation and backups, which are where the serious incidents are actually decided.

Log hygiene is a security control

The detection side of the system is only as good as what is done with its output. A few practices make the difference between logs that help and logs that are noise.

Keep the logs off the device that generated them, so a compromised host cannot edit its own history. Keep them for long enough to reconstruct an incident, which typically means months rather than days. Normalise time, because an investigation across three systems with three clocks is miserable. Tune aggressively, since an alert that fires a thousand times a day is an alert nobody reads. And test the pipeline: send a known-bad event through and confirm it arrives, is stored, and is visible to the person on call.

None of this is glamorous, and all of it is the difference between “we were breached in March” and “we were breached in March and we know exactly what was taken”.

Where Bizix fits

Bizix runs managed Australian hosting with its own IPS/IDS layer, enriched by machine-learning threat models, that blocks at the edge before traffic reaches customer systems. It is operated around the clock and backed by the logging discipline described here, and we are candid with customers about the controls it does not replace.