The discipline of “Intelligence” is often assumed to be practiced only by governmental agencies. However, in the field of cybersecurity, it is applied more than you think. Common practices in an ordinary SOC environment, such as; alert triaging, incident investigation, penetration testing, and threat intelligence, are all different forms of intelligence production.
Despite that, we are applying these principles so often, few of us are aware of how structured intelligence cycle works. By applying this knowledge, we could better orient ourselves in times of uncertainty (like an investigation), define more pinpointed objectives, and get better results from our engagements. Now, let’s take a look at how this process works.
Point of View
When someone is talking about intelligence, there is a good chance that they are talking about espionage (a.k.a spying). Espionage is closely related to intelligence however they are far from being the same thing. It is the main reason why this discipline is seen as somewhat mysterious by people. However, there is nothing mysterious about it. Intelligence is only a method for gaining the best value out of available information towards a specific purpose.
Step-1: The Question
Every cycle starts with a question. Answering questions is the main objective of the intelligence cycle. In the case of a SOC some of these questions are;
- Is this event a false-positive or not? (Triage Analyst)
- What are the risks that this IT infrastructure contains? (Penetration tester)
- What are the cyber threats our company is facing? (CTI Analyst)
- What was the entry point of this attack? (DFIR, Tier 2 Analyst)
Definitions are essential. They shape our perceptions about the problem at hand. So we shall redefine the problem until we are sure we fully understand what is needed. Let us redefine questions from above.
Example 1: Triage Analyst
- Question: Does this event truly represent a malicious behavior?
While triaging alerts, context is crucial. For the sake of simplicity lets say that event is “Failed Login Attempt”. Now lets consider what could make a failed login attempt malicious. It could be an attacker taking a guess. But it could also be an employee mistyped her password. In such cases, it is really helpful to have some norms defined in advance. It is actually same as defining what is not malignant. That way you can easily detect deviants that has more probability of being malicious. Lets continue by defining norms for this event.
An employee would:
- Not attempt to login more than five times in a row.
- Login within work hours.
- Connect from a corporate network or VPN.
These are all assumptions and may not apply to all businesses out there. But as you can see it is now very easy to define which attempts are malicious and which are not. Therefore our question becomes into;
- Is this ‘failed login attempt’ recurrent (>5) or out of business hours or coming from outside of our corporate network?
Now we are getting a crystal clear picture of what is needed. Now let’s move on to step two.
EXERCISE: Try to redefine other questions we have mentioned above in Step-1.
Step 2 : Intelligence Requirements
This can be summarized as:
Knowledge that is needed to answer the question.
You see this is also easier to define now; because we’ve already redefined our question and we exactly know what we need.
- Q: Is this ‘failed login attempt’ recurrent (>5) or out of business hours or coming from outside of our corporate network?
- IR-1: Count of failed login attempts to the same account.
- IR-2: Time of the event.
- IR-3: Source of the event.
An additional step would be prioritizing these requirements. For example, depending on your business environment, the time of login could be a more reliable indicator than source of login or vice versa. These are called Priority Intelligence Requirements.
Step 3: Sources of Information
This is simply where you will get the knowledge you require.
- Q: Is this ‘failed login attempt’ recurrent (>5) or out of business hours or coming from outside of our corporate network?
- IR-1: Count of failed login attempts to the same account.
- SI: Log files (Active Directory, auth.log, etc)
- IR-2: Time of the event.
- SI: Timestamp field of logs
- IR-3: Source of the event.
- SI: Source IP field of logs
- IR-1: Count of failed login attempts to the same account.
Step 4: Collection and Analysis
First, three stages of this cycle is called “Planning Phase”. We are essentially defining what we are looking for, where to find it, and how to get it. After this, there comes collection and analysis phases. Depending on the type of information sources and the mission objective, methods for collection and analysis may be different. These will not be elaborated in this article since our main focus is planning.
Step 5: Reporting and Briefing
The task of an intelligence analyst is not only filling knowledge gaps it’s also ensuring that stakeholders have a realistic perception of threats. You need to build these perceptions by the wording in your report and briefs. Inflated perception of threats is as dangerous as deflated ones. They may cause resources to be misallocated and impair organizations defensive posture. In the worst case, stakeholders decide the intelligence apparatus is irrelevant and dismiss it altogether. So ringing the bell every time something appears may not be a good idea.
