Your security information and event management (SIEM) platform might be identifying potential threat vectors or possible entry points without your knowledge. But, at the same time, it’s possible that you’re just getting too many alerts that you don’t know what to do with.
You need the means to contextualize alerts, and that’s where Domain Name System (DNS) intelligence from sources like https://reverse-ip.whoisxmlapi.com/overview can come in. Threat, domain, IP, and passive DNS data can give you more information on the owners of potential indicators of compromise (IoCs). They can also expand your SIEM solution’s capability to spot yet unidentified or publicized threat vectors. Worse, these may already be communicating with or trying to brute-force their way into mission-critical devices in your network.
This post gives three examples that illustrate why SIEM platforms can benefit from ingesting DNS intelligence.
Even Successful Logins Could Be Suspect
Threat intelligence obtained from third parties is certainly a must to boost the capability of any SIEM solution. And it’s also quite normal for SIEM platforms to flag suspicious or malicious IP addresses when their users repeatedly attempt to log in to protected devices and fail. But what happens when a suspicious or malicious IP address user enters the right username-password combination to access a system? Some SIEM solutions may not readily give out an alert.
A SIEM platform that ingests comprehensive threat intelligence, however, might. That said, even if the IP address 86[.]105[.]18[.]116 user enters the right credentials to log in to your customer database, for example, without setting off a SIEM alert, your integrated threat intelligence solution could tell you that the IP address is malicious. It is a reported IoC for in-the-wild exploits targeting vulnerable MS Exchange Servers.
In the scenario above, a threat intelligence-imbued SIEM solution could provide additional protection.
Some Domains Could Be Hiding a Tainted Past
It’s normal for cyber attackers to use several domains in a single campaign, as that increases their chances of breaching security protections while evading instant detection.
Let’s say you saw several communication attempts to the domain qmcy[.]tech in your network logs. Looking at such an instance is worth the effort for security teams that have the time to spare even if they are not alerted to it by their SIEM platform. But what if they don’t since the domain is not tagged malicious?
They may never know that the domain belongs to a registrant whose name coincides with one of the most wanted cybercriminals on the Federal Bureau of Investigation (FBI) list. And that the domain shares ownership details with malicious domains cungong[.]bid and zzzhaoran[.]top.
A SIEM solution that ingests data from a historical WHOIS database could tell security researchers that qmcy[.]tech could have ties to cungong[.]bid and zzzhaoran[.]top, which figured in APT41 or BARIUM attacks. Given the additional context gained from domain intelligence, your SIEM platform could then warn you when domains potentially owned by known threat actors appear in your network logs.
Not All Communication Sources Are Equal
While most SIEM solutions would warn you each time a malicious IP address accesses your network, not all could tell you that it belongs to the same netblock as many malicious IP addresses do.
Feeding IP netblock data contextualized with threat intelligence into your SIEM platform can help you flag IP addresses that may require further investigation.
Supposing the IP address 194[.]147[.]140[.]45 is repeatedly attempting to access one of your critical databases. It’s not likely to cause your SIEM platform to issue an alert since it’s not malicious. But an IP netblock database contextualized with threat intelligence may tell you that the 194[.]147[.]140[.]45 is part of the same netblock that contains at least 20 malicious IP addresses. That said, IP netblock data-fed SIEM platforms can better protect your critical resources.
SIEM platforms perform better when they ingest as much data as possible. Without contextualization enabled by comparisons and cross-examinations with DNS intelligence, some potential threat vectors could have already breached your security without giving out alerts.