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.
How the US Chooses Which Zero-Day Vulnerabilities to Stockpile
Ricardo Arroyo, Senior Technical Product Manager, Watchguard Technologies,  1/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3906
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 contains hardcoded credentials in the WCF service on port 9003. An authenticated remote attacker can use these credentials to access the badge system database and modify its contents.
CVE-2019-3907
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores user credentials and other sensitive information with a known weak encryption method (MD5 hash of a salt and password).
CVE-2019-3908
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores backup files as encrypted zip files. The password to the zip is hard-coded and unchangeable. An attacker with access to these backups can decrypt them and obtain sensitive data.
CVE-2019-3909
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 database uses default credentials. Users are unable to change the credentials without vendor intervention.
CVE-2019-3910
PUBLISHED: 2019-01-18
Crestron AM-100 before firmware version 1.6.0.2 contains an authentication bypass in the web interface's return.cgi script. Unauthenticated remote users can use the bypass to access some administrator functionality such as configuring update sources and rebooting the device.