IDG Contributor Network: What your enterprise needs to know about cyber threat i ...

Imagine the following scenario: a large financial institution has heard about recent breaches and thefts that have occurred around the world against similar institutions and wishes to protect itself.

These questions may arise: Who is behind these attacks? What is the motive? What is the attack vector? What vulnerabilities were exploited? Is our environment secure enough? What do we need to do?

This financial institution should probably talk to their cyber threat intelligence team.

Cyber threat intelligence, or sometimes just called threat intelligence (CTI and TI), are increasingly popular terms in the security industry and enterprises in general. You likely have heard them mentioned in conversations with security information and event management (SIEMs), cloud providers, or when buying expensive reports.

But what exactly is threat intelligence? Is it a product, a service or a skill? And why is it so important?

Today, security practitioners have a lot of data they need to turn into actionable information. To do so, you need two things: 1) a good “machine,” which could be a security analyst or an anomaly detection algorithm for example, that takes in data and delivers solid information, and 2) well-informed “consumers” who know what to do with it. This can be the difference between a successful or a failed breach attempt.

For providers of security products and services, CTI is the latest offering to provide you and your enterprise additional protection and value.

Why has CTI become important? Security should be incorporated throughout the R&D lifecycle. However, security does not fall under the expertise of most developers and DevOps engineers. That’s why security practitioners try to add extra layers of defense during the product development process while minimizing the time required for developers and DevOps engineers to implement, but their success rates for implementation are relatively low.

So, with limited security incorporated at the R&D level, the CISO buys more software to do more automated scans, but these are all generic and not customized. There is no one-size-fits-all approach in security. CTI, however, when used properly, creates customization in security, answering such detailed questions as:

Who wants to steal your intellectual property and how will they likely try to do it? Will these the newly published exploits that were published affect your enterprise Will your users experience brute-force attacks soon following a big user-data dump released? If so, what can be done about it? Were other companies in your sectors targeted by advanced persistent threats (APTs)? How can I understand and prevent this attack vector?

These are the types of questions security practitioners likely ask themselves everyday but may not always know how to find the answers. This is where CTI can help.

Cyber threat intelligence is an ongoing cycle process. It is not a serial process, but a parallel one. It must be repeated to keep up-to-date. The process of CTI has some similarity to the process of creating a new product:

1. Define the needs or requirements

The first step is mapping your organization’s needs. Needs are not just question you’re curious about, but gaps that have actionable outcomes to prevent those threats. You need to ask yourself constantly what you would like to achieve by having intelligence.

Here are a few examples:

Protect your company’s IP Know if any malicious actors are targeting you and what can you do to prevent them from succeeding Patch all known vulnerabilities that are relevant to your environment as soon as they’re published

These are just a few examples for requirements from the threat intel team. When you know the desired outcome, they can break it into the right questions and then prepare a collection plan.

2. Data collection

The collection plan includes all the sources that could bring relevant data to the mapped needs, and how you’re going to use them. You need to know many types of data sources and tools to build an effective collection plan.

Examples of sources include: OSINT (open source intelligence), darkweb and underground communities, HUMINT (human intelligence), commercial sources AND your own data from your network, infrastructure and pretty much any system that saves metadata. Sometimes you need data that you don’t have, and this requires sources development skills.

3. Data processing

The data collected comes in different formats. Perhaps it needs decrypting, translation or cleaning. The processing brings out only the important pieces of data, in a usable format.

Here’s how sources in the previous data collection section might be processed:

OSINT These might be related articles from popular websites or academic journals. Once they are found relevant they need to be archived, scanned and indexed so that we could find the relevant pieces quickly. Darkweb and underground communities This information can come in many different types of files. It could be source code, internal emails (text) or JSON files, depending on what you are looking for. These too needs to be archived in a format that allows you to easily find the relevant pieces of data. Data from your infrastructure This includes any kind of log that your systems produces, for example: user activity, network traffic, DNS queries. Each log has its keys. The network traffic log would have a timestamp, IP addresses, protocol, ports, packets, bytes. For each log you need to decide which keys are relevant to you, parse them and once again index and store them. 4. Data analysis

If we take the financial institution example mentioned at the beginning, the analysis process might include gathering pieces of puzzle like: IP addresses that attacked similar organizations, the malware code that was executed on other victims, pDNS logs that are related to past incidents, including IP addresses, times of registration and by who. The analyst will take these pieces and create a picture that can answer where the attacker is coming from, what is their modus-operandi and what is the indication of compromise (IOC).

5. Conclusions, action items, dissemination

This is the part where you take the new knowledge, make it actionable and spread the word. While this is arguably the most critical step, it is also the step that is often not performed, or not performed accurately. Each piece of intelligence has different consumers ― people with different roles in the organization such as the DevOps team, C-level management, the CISO, R&D teams and even HR department. To make the intelligence actionable in their arena, each customer needs it in different formats

Back to our financial institution example. After going through the entire CTI process, analysts may have found that the infamous cybercriminals of the “Lazarus Group” are a potential threat to the organization. They will issue a report to the C-level management, explaining the damage this group has caused other institution such as monetary losses, denial of service from customers, etc. The analysts will issue another report to their IT team containing the IOCs of this group and action items as matter of precaution.

The type of reports and action items the CTI team will be customized to meet each consumer’s information needs:

The C-level wants to know what kind of damage this group could cause them and prepare a contingency plan to handle different scenarios. The DevOps and IT team will get the known IOCs of this group, to be monitored or blacklisted. All company employees will get training for spear-phishing awareness, as this is one of the attack vectors used by the group. Only when each customer