This is Part 3 of a series about unexpected blocks. The first installment, “The Truth About Unexpected Blocks,” explains the difference between unexpected blocks and false positives, and the second, “Embracing the Human Element,” dives into the decisions security teams need to make when they encounter unexpected blocks.
Definition: “unexpected blocks” vs. “false positives”
“Unexpected blocks” is an umbrella term for false positives, misunderstood indicators, and blocked malicious traffic on a site you weren’t expecting to be blocked. While many use the terms “false positive” and “unexpected block” interchangeably, false positives are only one kind of unexpected block, and thus the connection shouldn’t be allowed to automatically pass through.
What to look for when encountering unexpected blocks
Let’s put it out there: encountering an unexpected block is frustrating for pretty much everyone: for the user trying to access a site and for the security teams who have to answer the frustrated user’s question and then assess whether or not that connection should be allowed through or not. Unfortunately, if you implement security measures for your network, unexpected blocks are a fact of life, and shouldn’t all be treated as traffic to be automatically let through.
And while it’s easy to assume AI can handle these types of decisions, there does ultimately need to be a human involved in this process (in the world of machine learning, this is known as Human-in-the-Loop, or HITL). It’s important to remember that AI can help calculate risk, but must not assume it.
Handling unexpected blocks (new feature announcement!)
After an unexpected block occurs, the security team needs to decide whether or not to allow that traffic through. They need to answers to questions to find out just how risky that traffic is, such as:
- Where is the traffic from, and where is it going to?
- What services is it running on? (remember that multi-homed servers and CDNs are two common culprits)
- Why was this flagged as malicious traffic?
In order to help expedite this process, Threater has announced a new feature in the Threater portal to help teams handle unexpected blocks on ports 80 and 443 (where most unexpected blocks are found).
Using this feature, Threater customers can now easily run a report for a time frame when the unexpected block occurred and then see which policy and list blocked the traffic along with the following information about the unexpected block:
- Country
- ASN
- Reverse DNS
- WHOIS
- WHOIS.Extended
From this information, your security teams can assess if the traffic was most likely a false positive that was erroneously blocked, or perhaps traffic that was unknowingly compromised due to living on a multi-homed server or CDN.
Sometimes, some of the expanded data might conflict. One example might be that country and ASN information might be different across various sources the IP appears on. The fact that there are conflicting data points is actually data in and of itself to consider, since conflicting data could be a sign of active compromise. All of this information is important and helpful to assess when determining whether or not to allow traffic through.
If you determine the traffic is an acceptable risk to take, you can now click to allow that traffic through by adding it to an Allowed List directly from that same Unexpected Blocks tab, along with notes for potential future investigations, and an expiration date for that allowance.
A decision around unexpected blocks isn’t one security teams should take lightly. However, making this process and data more accessible empowers those decision makers to assess the information against their organization’s acceptable risk tolerance.
To learn even more about our new Unexpected Blocks feature, please watch this video demo that dives in even more!
