ThreatRadar: Finding Order Within the Chaos

Using signature-based or simple logic protections alone are no longer sufficient security measures in today’s threat landscape. Dropping traffic on a port at the firewall is not enough to keep these threats out of the enterprise. Take a look at the most recent big name breaches and they all had one thing in common. They spent big money on traditional security measures. We’ve all known this for years. It’s why we developed Imperva SecureSphere in the first place.
I’d like to take a moment to dive into a particular part of Imperva SecureSphere called ThreatRadar, which helps admins filter out unnecessary noise in their SecureSphere logs, filter known bad traffic before it even touches website infrastructure, as well as create more intelligent and accurate policies. ThreatRadar is a feed that originates in our Application Defense Center (ADC) and aggregates threat data from Imperva partners, Imperva research, and crowdsourcing from thousands of Imperva SecureSphere users to provide a god’s eye, real-time view of the global threat landscape. SecureSphere is able to ingest this intel, allowing the product to make better decisions based on a variety of information that would have otherwise been unavailable.
Simply by enabling ThreatRadar, we’ve seen SecureSphere pre-filter 20-50% of incoming traffic—bad traffic that would otherwise needlessly hit our websites. In fact, Imperva Incapsula reported in 2014 that 56% of all Internet traffic is bot related, an instant major win for filtering if bot traffic is something you don’t need. Potentially more important, that’s 20-50% fewer “security events” that overworked and understaffed security engineers and operations centers have to manage. Eliminating this noise results in:

Less FTE’s required to manage security alerts, since traffic that would otherwise be cluttering the logs/event viewer is pre-filtered
Better visibility into what’s important, since what is remaining after the pre-filtering is more likely to warrant further investigation
An overall improved security posture, since a better ‘signal to noise ratio’ makes everyone more effective and confident
Lower TCO by means of lower storage requirements for Alerts
Less load on (if any) downstream SYSLOG serversLess hardware required to protect the applications

Security guys from the 90’s may remember when we began plugging enterprises into the Internet, a sign of success was when you received some NetBIOS over TCP (NBT) packets from an overseas source. In fact, I bet most firewalls back then had the first 500 records in the logs were dropped NBT packets. Fast forward a few years and admins configured firewall/router policies that frequently dropped that traffic (adding in BOOTP, MSSQL, etc) and set them to drop and not log. It was just considered ‘noise’. Every Internet connect had it (remember those long nights tossing around tcpdump commands and popping the hood on the Matrix). When setting up and running expensive firewalls, DDOS mitigation hardware, and other security devices, it makes sense to find cheap, efficient ways to reduce the load, management footprint, TCO, and sustainability of the security solutions. One common way is to ‘drop and not log’. This common approach is used as a way to reduce the noise of what’s coming in from the Internet. Not every dropped packet is a security risk, so it doesn’t always make sense to carry a lot of unnecessary network traffic to other devices. Plus, it’s considered Best Practice to use a layered approach. An external router or other network hardware was used to drop some ‘noise’. Then, an external firewall would drop some more of the noise. Finally, an IDS/IPS would filter out some more of the noise. In the 2000’s, we added Web Application firewalls into the mix, dropping even more of the noise, filtering attacks that other layers weren’t able to see.
Enter the 2010’s and we have new breeds of attacks, threats, and risks. From hyper-funded cybercriminal gangs, to cybercrime economies, to nation state hacking, to cyber-espionage, the threat actors have evolved over the years to become organizations with resources that parallel the enterprises they’re targeting—namely yours.
And they are incredibly adept at morphing their attacks. Hence the need for a continually updating service. Some of the feeds available in Version 11 and how they can help reduce the noise are:

Feed	Description	How to reduce chaos
Anonymous Proxies	IPs of known open anonymous web proxy servers, allowing attackers to hide their browser session and IP	If you don’t want anonymized traffic, consider dropping without alerting Consider allowing some user actions from anonymous proxies, like browse the site – but block signups or purchases
Comment Spam IPs	IPs of machines that are spamming comments into forums	Consider allowing some user actions from comment spammers, like browse the site – but prevent forum comments or adding reviews
Geo Location	Geographical information about IP addresses (country and state/ city), provided by Incapsula	If you’re unable to do business in certain regions, consider blocking traffic from them Block countries that generate a lot of security alerts but don’t contribute to business
IP Forensics	In the GUI, this feed provides intel on an IP address, like its location, previous offenses against honeypots, historical analysis of the IP reputation, etc.	More information at your fingertips makes tuning much easier when determining if an alert is a false positive
Malicious IPs	Known zombies and malicious IP addresses from various blacklist sources	Block without alerting to filter out the thousands of violations they can generate Use extended IP blocks to reduce noise generated by known bad guys
Phishing URLs	Live fraudulent and “spoof” webpages that mimic well-known banks, email portals, utility providers, and social media sites, as well as webpages used for stealing data, credentials, funds and/or identities	Block any traffic this thread detects, particularly to pages with interactivity like forums or product reviews
TOR IPs	IPs that are acting as The Onion Router (TOR) exit nodes, used regularly to attack systems anonymously	Consider dropping without logging if TOR access is disallowed Consider allowing TOR users access to the homepage, but not signup, login or post If under DDOS attack, block these IPs without alerting, which are frequently used by hacktivists
RFI	URLs and IPs that are hosting malware	Consider blocking without logging
SQLi IPs	IP that have been seen sending SQL Injection attacks, detected by our Community Defense feed	Consider blocking without logging
Scanner IPs	Known malicious web scanners, detected by our Community Defense feed	This group of offenders will generate a lot of buzz, block without alert Consider a long IP block followed action to reduce even further
Bot Protection	New in Version 11, helps mitigate bots, which are responsible for 60% of all Internet traffic	After whitelisting your trusted bots (if any), drastically reduce load on your webservers with this thread

Useful tips and tricks for working with ThreatRadar:

Combine Match Criteria for powerful policy logic:

Make sure to whitelist IPs that are safe, such as partners, your networks, etc:

There is a red ‘Request a Trial’ button and an ‘Emergency Activation’ button on the top right of the ThreatRadar console. It can be used during an emergency for three days of service and you’ll be contacted by the Imperva Support Team (Emergency Activation), or try out the service with a free 30-day trial: