Why Block Attackers at the Network Edge?

by Timothy Chiu, VP of Marketing on August 13, 2020

When it comes to cyber security attacks and detection of attacks, blocking the attack and the attacker is often a tricky issue for enterprises. The biggest issue with blocking an attack is twofold: 1) ensuring that in fact there really is an attack going on, and it’s not a false positive and 2) making sure you’re only blocking the attacker and not any valid users.

For many organizations, any accidental blocking of real users, often means losing out significant revenue in internet sales and transactions. Which is why many organizations err on the side of caution, preferring not to block when an alert is given by a security tool, especially alerts from new tools that haven’t yet gained the trust of the IT professional. Which is why it’s common to see security tools deployed in what’s known as “monitor” mode where they alert to attacks, but don’t proactively try to stop or block the attack.

If you don’t block or stop the attack, and the attack is successful, that means of course your IT organization is going to be responsible for remediation of what ever damage the attack causes. Which leads us to what an IT security organization needs. Security they can trust to deliver alerts without false positives and block attacks before they cause damage.

Let’s assume you can trust the alerts your security solution is providing you (and you should be able to with deterministic security). If we can trust our alerts, then we should be blocking the attacks we are being alerted to by our security system. IT organizations as mentioned are shy to do this in case they accidentally over block and block valid users. So we need to make sure we have as much telemetry about who the attacker is, so when we block we only block the attacker.

Ok, let’s say our security tool gives us considerable telemetry about the attacker (so not only the IP address, but other identifying details like sessionID and XFF headers), then we move to the final decision about blocking the attack, and the headline of this article.

Sponsorships Available

Where do you block the attack? At the network edge (on a network edge security device like a firewall), or at the target of the attack on the application server?

There’s an argument that says if you’re the security tool that’s detecting the attack, you should do the blocking, so that a security tool running on the application server detecting an attack should block the attack. While in theory that sounds great, there’s a couple of problems with this line of thought.

First there’s probably more than one application server in your environment, and while the security on this server detected an attack it’s possible and in fact likely the attacker has attacked other applications and other application servers in your environment, some of which may be legacy, older and forgotten and may not have security installed on them. Second, blocking at the application server only guarantees that particular server is protected, and any other devices (including end-user systems and IoT devices) remain susceptible to the attacker.

Blocking at the network edge if it’s available through integrations between the application security tool and the firewall, makes the most sense to make sure the attacker doesn’t get to any device inside your network.

The safest course of action is of course to do blocking at both locations. That way, if for any reason the firewall and network edge blocking didn’t succeed, you’ve still at least protected the application.

If you can trust your security tool to provide reliable alerts of attacks, definitely block the attacker. Block the attacker as early as you can, to prevent damage occurring inside your network to locations you might not be aware of that the attacker has access.

K2 Cyber Security can help address blocking at the network edge with an application security solution that has the lowest false positives. K2 has integrated with leading firewalls like Juniper’s vSRX and SRX firewalls to provide blocking at the network edge in realtime to ensure only blocker is attacked, and not valid users trying to access the application.

K2 Cyber Security Platform offers two use cases, for additional visibility and vulnerability detection during pre-production (development) penetration testing, while the other is runtime protection for applications in production. In the second use case, K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts. Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge. Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended. There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has minimal false alerts.

Get more out of your application security testing and change how you protect your applications, and check out K2’s application workload security solution.

Find out more about K2 today by requesting a demo, or get your free trial.