Quick Definition:
“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.
An example of an unexpected block
Here’s a scenario you can probably relate to. You’re at your desk and get a message from a friend with the name of the restaurant you’re meeting at after work. Since you have a few minutes before your next meeting, you quickly go to the restaurant’s website to check out the menu to see what culinary delights lie ahead. (Our recommendation is almost always to go with a dish that involves a lot of cheese, for what it’s worth.) You click to go to the restaurant’s website, but suddenly your food daydreaming comes to a halt as you find the website blocked by your security tools.
Annoyed? Of course you are. This is annoying for everyone. But it’s in that annoyance we (and we do mean all of us) can easily confuse the idea of “false positives” with “unexpected blocks.”
The difference between unexpected blocks and false positives
Let’s pick back up with our restaurant website example. The restaurant website is blocked, and you think to yourself, “This is just a local neighborhood restaurant around the corner from my house! There’s no way it’s actually dangerous. This security is overactive and this has to be a false positive on a safe website.”
Frustratingly, these types of unexpected blocks are not always false positives.
“Unexpected blocks” is an umbrella term for three scenarios:
- Mistakes in cyber intelligence, aka, false positives
- Misunderstood indicators
- Dangerous traffic
Another way to think of this is how every square is a rectangle, but not every rectangle is a square. Every false positive is an unexpected block, but not every unexpected block is a false positive.
Unexpected blocks should not automatically be treated as “safe”
Since one of the options for the cause of an unexpected block could be a compromised site, clearly your first reaction should not be to automatically allow that connection.
Let’s dive into two examples of how an unexpected block could actually be enforcement of malicious traffic: multi-homed servers and CDNs.
Unexpected blocks from multi-homed servers
Threat actors love to attack sites on multi-homed servers, which are responsible for hundreds of websites and/or software subsystems. When they successfully get into a site, they can then use privilege escalations to get ‘root’ access to that server, which then allows them to compromise every website on it.
Threat intelligence providers often categorize a multi-homed IP as malicious with very high confidence levels. Often these intelligence providers are so sure they give their score with 100% confidence that the traffic is malicious on these.
If you’re still wondering about our ill-fated menu perusing from earlier, this example of an unexpected block could very well be what happened to that local restaurant’s website. If that restaurant’s website is hosted by a multi-homed IP, it’s very possible that the traffic to and from that IP is malicious due to a compromise on another site hosted on that multi-homed server. And while that blocking of your local restaurant’s website was absolutely unexpected in this scenario, it shouldn’t be categorized as a “safe” or, even, a “false positive.”
For example, it is entirely conceivable that a malicious attacker has co-opted traffic transfer to be able to sniff online payment information (such as your credit card, expiration date, and CVV code) that you might key in while visiting that site, or potentially any other site hosted on that multi-homed server for that matter. Or, if the site has a login, and you’ve keyed in your username and password, the attacker may have visibility into that information as well. If you re-use that username and password combination on other sites, then an attacker could easily compromise those other systems as well.
Unexpected blocks from CDNs
Another top reason behind unexpected blocks is the reliance on content delivery networks (CDNs). These are top targets for threat actors because they know most organizations cannot enforce blanket bans on CDNS, because doing so would render many day-to-day business functions inoperable. Once a malicious actor compromises a CDN – or the content residing on it – it’s not a matter of “if” the end user of that CDN is compromised, but rather “when.”
Threat actors have become incredibly savvy in their attacks and finding themselves steps ahead of threat detection tools and technologies. This is why once a CDN is compromised, the malicious actor can deploy and serve up malware that’s often undetectable. Signature inspections against payloads, attachments, and executables are no longer sufficient in the modern threat landscape as zero-day holes (sometimes but not always attributable to unpatched software) are being exposed faster and faster.
Mitigating Unexpected Blocks
Ultimately the decision to allow an unexpected block through requires human intervention and making educated decisions on just how risky the traffic in question is, and how much risk the organization is willing to take on.
Using “Allow” lists for known good traffic
Threater has a few mechanisms in place to help mitigate an unexpected block that is deemed, after investigation, to be a false positive (aka, “safe” traffic that might get labeled by intelligence sources incorrectly as dangerous). The primary mechanism with Threater Enforce is through the use of our “Allow” lists. And because of our unique architecture, we do not place limits on the amount of allowed list intelligence, effectively making room for as many Allow lists of any size as needed.
Threater also provides all customers with our own curated Allow lists with known good IPs in them to help mitigate false positives as well. Assuming the customer has those lists enabled, this is another layer in reducing false positives.
Of course, our Enforce software logs all allow and block decisions that are available via exportable RFC-compliant syslogs. This allows for downstream analysis in other security tools in case an unexpected block was allowed through but turned out to be malicious after all.
GreyNoise partnership
Threater has also partnered with GreyNoise, one of the top threat intelligence providers in the world, to obtain access to their “Rule it Out” (RIOT) dataset. This dataset is the world’s largest known-good business-system list of tens of millions of IPs that are (typically) safe to allow.
Hopefully this quick summary has helped you understand the subtle differences between unexpected blocks and false positives.
Of course, if you have questions about unexpected blocks, false positives, or anything else (even restaurant recommendations!)…we’re here to help.
This is the first post in a series about unexpected blocks. Be sure to check out Part 2 where we dive into the human element of unexpected blocks.
