Adventures in Threat Intelligence Gateway Health Checks: Part 1
POSTED AUGUST 27th, 2019 // BY CORY SCHMIDT
As a Solutions Engineer at Threater, one of the things I like to do is check in from time to time with current customers, to ensure they’re happy with our Threat Intelligence Gateway solution, their solution is up-to-date, elicit any feedback or ideas they may have, walk through new features, and make sure they’re getting the most out of their Threater Threat Intelligence Gateway (TIG). I call these my “TIG Health Checks.” As a security professional, I understand that no matter how automated our Threat Intelligence Gateway devices are, it’s always a good practice to stay on top of what policies are being used, and tweak them as needed to best suit the dynamic network security needs of the organization. Never was that more apparent than on a recent health check I performed for one of our customers.
It all started as a fairly routine health check…I joined with the customer on a web meeting, had them share their screen with me, and together, we logged into their Threat Intelligence Gateway and the accompanying cloud-based management dashboard, what we call the Global Management Center (GMC). One of the first things I noticed was that they had not yet updated to our latest firmware release, so I helped them download the file and update their device. Once updated, I offered to give them a refresher on GMC, and walked them through some of the new features included in the latest release. These new features included new dashboards and reports providing more visibility into their threat intelligence-driven blocking efforts and a new malicious domain blacklist that enhances our secure DNS filtering, providing enhanced protection against ransomware, phishing, and malware attacks.
Threat Intelligence Gateway Policy Review SEEMs Normal…
Next, we reviewed their current policy configurations. I quickly noticed that they did not have a policy set for “country blocking” on either inbound or outbound network traffic. Understanding that network connections from certain countries have a higher probability of being malicious, and that this organization’s operations were regionally-focused (ie: they didn’t really need to connect to organizations in other countries) this was a bit of a yellow flag.
While it is common to be fairly open on outbound traffic, unless an organization operates globally, it should be more restrictive on its GEO-IP policies for inbound traffic. With that in mind, I recommended this policy change to them. Next, I reviewed their threat intelligence policies for both reputation feeds and blacklists. These generally looked in good order and I saw no major issues or concerns. Just to be thorough, at this point, we switched over to the Threat Intelligence Gateway’s connection logs, to see what information about their network security posture we could find.
Heyo! We found something VERY interesting.
Discovering Outbound Russian Network Connections from Log Data
While reviewing the logs, we first noticed inbound network traffic originating from Russia. While not pleasant to see, it’s not uncommon as there are plenty of bots and network scanners out there that probe any network they can find. That said, the customer was already quite convinced that they should start blocking Russia (at least!) on their inbound policy. As we continued to review the logs, we found something even more troubling! Outbound traffic, going TO Russia! While a connection to a Russian IP is not by itself malicious, given the customer’s business profile, the outbound connections to Russian servers clearly were cause for concern about a potential malware infection, such as communications with a command & control server.
Needless to say, our customer was shocked. Together, we configured the Threater Threat Intelligence Gateway with a policy to block both inbound and outbound traffic to Russia, which solved the problem of outgoing connections. Our customer now had some investigation to do, to determine the cause of those connections and to discern whether they were malicious.
Key Takeaway: Dynamic Threat Environments Require Frequent Network Security Health Checks
My big takeaway from this experience was that it validated the importance of periodic health checks on network security policies and the importance of using every available network security tool or feature that you have available…such as country-blocking!
Periodically checking network security policies like firewall rules, access control lists, blacklists, and whitelists–as well as making sure you are taking full advantage of the options to reduce your attack space–is critical in today’s environment in which both access to networks and the cyber threat landscape are highly dynamic. This is not only a best practice but it’s also more critical in the dynamic world we live in in terms of access to networks in general and the threat environment. Without a health check, the customer would not have turned on the country-blocking capabilities of their Threat Intelligence Gateway.
If you are interested in learning more about how the Threater Threat Intelligence Gateway can increase your access to threat intelligence and strengthen your network security defenses check out our Threat Intelligence Solutions.