May 18, 2015 By Brian Foster 2 min read

If security professionals are to have any chance of successfully containing advanced threats, they must automate the infection validation processes. The attack vectors are seemingly endless and there are simply too many alerts — many of which are false positives — to investigate and analyze manually. In my last post, I talked about how automation can be achieved via an intelligent decision-making system (IDMS). Let’s look at what it takes.

IDMS for Automated Infection Validation

An IDMS begins with a big data infrastructure such as a Hadoop cluster and massive amounts of raw data. You can subscribe to intelligence feeds and have them load into the system, along with data from your own security and other network tools. Security information and event management (SIEM) tools can help in this regard, as well as tools like Splunk, but they only get you partway there. These tools allow a human to run queries off the data you’re gathering, but the queries don’t make a decision for you as to what threats are present on the network, the risks they pose and how they should be addressed.

The decision-making aspect requires massive algorithms that essentially tell the system, “If this, then that.” But it is never that simple. In reality, the algorithms are more like, “If x exhibits y behavior for more than z time, set n variable to q.” In order to write these algorithms, data scientists must work closely with security threat experts to understand the variables, their relationship and the desired outcomes.

Most importantly, an IDMS requires a software system that sits on top of the big data infrastructure and determines whether a device on the network is infected. This decision-making component must be built by developers, who also put algorithms built by the data scientists into this system’s code infrastructure.

The system is now ready to perform automated infection validation, but it will never be “done.” The algorithms are massive programs that are works in progress, changing to accommodate an evolving threat landscape. Security threat researchers, developers and data scientists must continually evaluate and tweak the algorithms, building additional systems that will automate the continuous learning of the models.

Worth the Effort

The process of building and maintaining an IDMS is not easy. It requires very specialized skill sets and is resource-intensive — and those resources are not easy to come by. Data scientists are in short supply, and few enterprises can afford them or additional security experts. But that doesn’t change the need for automated infection validation and investigation.

I know from talking to enterprises that organizations are attempting to build an IDMS with various levels of success. A recent Ponemon Institute survey seems to concur, with 41 percent of respondents claiming to use some automated tools to capture intelligence and evaluate the true threats in a sea of alerts.

I’m curious to hear from others. Is this something you’re trying to build today? If so, how are you addressing the challenges and what successes have you had?

More from Threat Intelligence

Strela Stealer: Today’s invoice is tomorrow’s phish

12 min read - As of November 2024, IBM X-Force has tracked ongoing Hive0145 campaigns delivering Strela Stealer malware to victims throughout Europe - primarily Spain, Germany and Ukraine. The phishing emails used in these campaigns are real invoice notifications, which have been stolen through previously exfiltrated email credentials. Strela Stealer is designed to extract user credentials stored in Microsoft Outlook and Mozilla Thunderbird. During the past 18 months, the group tested various techniques to enhance its operation's effectiveness. Hive0145 is likely to be…

Hive0147 serving juicy Picanha with a side of Mekotio

17 min read - IBM X-Force tracks multiple threat actors operating within the flourishing Latin American (LATAM) threat landscape. X-Force has observed Hive0147 to be one of the most active threat groups operating in the region, targeting employee inboxes at scale, with a primary focus on phishing and malware distribution. After a 3-month break, Hive0147 returned in July with even larger campaign volumes, and the debut of a new malicious downloader X-Force named "Picanha,” likely under continued development, deploying the Mekotio banking trojan. Hive0147…

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today