Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
4/1/2015
10:15 AM
Hardik Modi
Hardik Modi
Partner Perspectives
Connect Directly
Twitter
RSS
100%
0%

Application of Threat Indicators: A Temporal View

Better outcomes will be achieved when we're applying temporal considerations to threat indicators.

A tremendous amount of energy is being spent on the harvesting, curation, distribution, and sharing of threat indicators and associated intelligence in the enterprise space.

The emergence of sharing groups and platforms, standards such as STIX/TAXII, reports of discovery of threat activity based on shared intelligence points, and multiple government mandates related to threat information sharing all point to the rapid maturity cycle that this space is experiencing. And while the process of delivering intelligence to enterprises requires continued focus to ensure incremental benefit for each new participant in the network, the systematic application of such intelligence is necessary to achieve the security outcomes we're all looking for. In this post, I'm going to explore the temporal nature of the application of indicators.

To put some definitions in place, I refer to the application of indicators (IP addresses, URLs, domains, MD5 hashes) to future activity as the prospective application of threat indicators. Correspondingly, the application of indicators to historical data such as log management and SIEMs is known as the retrospective application of threat indicators. Both of these techniques have value but occasionally in strikingly different ways, and this distinction is worthy of examination.

Prospective application is typically done in or near real time, such as when a data loss prevention (DLP) solution might look for IP theft in embedded content or for a specific user-agent string or signing certificate for SSL sessions. A match can result in a rapid response on the part of the enterprise, either automated through the security product or via the incident-response process.

Optimizing Value

But for all the virtues of the prospective process, by the time your sharing platform delivers indicators based on observations made elsewhere, it's likely that the specific malware or command-and-control infrastructure has already been used against you. Therefore, there's limited value in continuing to scan for indicators that are ephemeral such as file hashes or IP addresses. This is the conundrum that David Bianco talks about in his "Pyramid of Pain" theory.

However, there is considerable value in being able to look backward through the retrospective application of indicators. Typically, stored historical data isn't quite as rich, and there are trade-offs that have to be made in terms of the nature and duration of the data that gets stored. For example, your options on the network range from full-packet capture to simple firewall logs, and from hours to eternity. Modern security operations centers that "assume breach" are always interested in learning about recent encounters with the adversary, so the fact that a specific hash was observed in an email to a key executive a week ago is a clear signal that a campaign has begun or resumed.

As you venture into the world of threat intelligence and indicator sharing, you'll want to consider optimizations. This is true across the spectrum, whether you happen to be a producer, distributor, or consumer of threat intelligence, or even the provider of the technology that enables the operationalization of data. Enterprises should be evaluating their providers with these objectives in mind -- for example, demanding the ability to apply rich indicators to historical events.

Better outcomes will be achieved when we're applying temporal considerations to threat indicators that are distributed and operationalized. 

Hardik Modi is Director of Threat Research at Fidelis Cybersecurity. He has over 15 years of experience in network and security product design and research. At Fidelis, he leads the Threat Research Team, responsible for threat intelligence that powers Fidelis XPS Advanced ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
kate25
50%
50%
kate25,
User Rank: Apprentice
3/18/2018 | 12:47:23 PM
Thanks
Thanks, Hardik Modi for sharing this your point of view.

I go through this article but I have little bits of confusion on Threat Indicators.
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Inside North Korea's Rapid Evolution to Cyber Superpower
Kelly Sheridan, Staff Editor, Dark Reading,  12/1/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25465
PUBLISHED: 2020-12-04
Null Pointer Dereference. in xObjectBindingFromExpression at moddable/xs/sources/xsSyntaxical.c:3419 in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25461
PUBLISHED: 2020-12-04
Invalid Memory Access in the fxProxyGetter function in moddable/xs/sources/xsProxy.c in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25462
PUBLISHED: 2020-12-04
Heap buffer overflow in the fxCheckArrowFunction function at moddable/xs/sources/xsSyntaxical.c:3562 in Moddable SDK before OS200903.
CVE-2020-25463
PUBLISHED: 2020-12-04
Invalid Memory Access in fxUTF8Decode at moddable/xs/sources/xsCommon.c:916 in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25464
PUBLISHED: 2020-12-04
Heap buffer overflow at moddable/xs/sources/xsDebug.c in Moddable SDK before before 20200903. The top stack frame is only partially initialized because the stack overflowed while creating the frame. This leads to a crash in the code sending the stack frame to the debugger.