How to work with the Threat Intelligence Cycle to improve your Security posture
“Let’s talk about” is a series I have planned for a while, it will cover topics which are quite old but I find myself explaining them quite…
Threat Intelligence is and if not should be, a core capability of your Security operation. In the modern day and age, security events are everywhere. Especially true if you think about the cloud environment. With cloud you introduce a huge edge to you environment, users can come from everywhere and communication is global.
The Threat Intelligence cycle of analytics is a simple flow to follow to make more sense of Threat Intelligence and the security events you receive.
- Analytics for Threat Intelligence (TI)
In the area of Threat Intelligence your TI team can get easily overwhelmed with reports, there is just so much information out there, some are duplicates and some are not relevant for your environment and operation. You need to make a sense of that data, as value comes directly from the applicability of the data. - Security Analytics (SA)
same goes for Security Analytics, to some extent of course. Security events come in different flavour, your SIEM or SOAR tool should help you doing the correlation and to provide you with the basic enrichment already, so that’s good, this covers a huge part of the dismantling and enrichment . Understanding the cycle though, you should realize that there is maybe more out there, you should analyse the event and follow the enrichments, meaning if a 3rd party source reported a indicator as malicious you should always check and ask why.
Taking a look at the different steps in a bit more detail.
Dismantle
This is the basic extraction of data out of a stream of data. You can be inspired by how a SIEM or SOAR would do it, but to be honest to the biggest extend it means running regex over a large data set and getting the different indicators out. You can take a look at my Indifetch.py on GitHub for inspiration how to automate this task.
In the TI area you want to make sure that you take out all indicators, if indicator of compromise or not, from the current report in front of you. A software version mentioned in the report might not be the most obvious one you think about in TI, but later if another team needs to make a decision if and in which ways this could affect your company, knowing about this is a great way to start. The Threat hunting team will love you for this.
You want to end up with a list of all those indicators, maybe even marking them as IOC, so you can move them to detection rules or lists to contribute to the overall threat detection and threat hunting, and even if it is only as additional information so you can create more advanced response processes based on those.
Enrichment
We did dismantling first, because enriching indicators is much easier than erniching full reports, you can take your list of indicators and run them through any form of internal and external enrichment. This helps you to understand if a certain indicator is actually malicious.
As an example, a report might include a certain content delivery network (CDN) as being used by the attack, but you may find this IP address as not being malicious at all, based on this enrichment you would not mark this indicator for firewall blocking.
There are (at least) two ways of enrichment
External / 3rd Party enrichment
Palo Alto Networks AutoFocus or Unit42 as well as X-Force Exchange, Alienvault, RiskIO, Virustotal and others are great source to get the 3rd party enrichment done. The sources will tell you more details about an indicator and give a rating, but you always need to remember and check how much you trust a certain source. Rating the reliability is key.
Not to underestimate are also sources like CVE and vendor reports. Knowing the exact version number of a software affected by a certain vulnerability might be the difference between irrelevant and a security breach.
Internal enrichment
It can start with the infamous configuration management database (CMDB), if you have one… not an empty one. Getting details about the machine in question, especially in the SA field, is a great start. What runs on a system, who is the owner. That is enrichment data of security events you should not neglect.
Also the purpose of a machine. A DNS server doing DNS stuff sound like an intended usage, the same server doing teamviewer traffic not so much.
Finally it needs to come together
Analytics
So what you do is to take a look at all input you got from the first two steps and make a decision.
The first and most basic decision you can take is to further dismantle and enrich. Let’s say you came across a proof of concept of a certain attack. There is more valuable data to dismantle and enrich. You want to make your investigation as tight as possible, keep in mind you are not doing this for you, you want to have someone to be informed so they can make an educated decisions.
There is also the hard decision of “when to stop”, yes you can easily enrich yourself to death, so to speak, you will always find more data, more details or simply drift of in exciting articles. There comes the art of experience, knowing your environment and company, you will learn where to focus and where to slack off.
Shape your thinking with some simple questions
– Could I act on this information
– Does the information reflect how the attack could play out
– Is my list of indicators actionable already
Last, use this step to verify your capabilities to detect (in TI) or to prevent (in SA) the certain indicators you have got.
All in all, I would recommend every Analyst to walk through this steps, especially if you are preparing are get new into a job. This analytical cycle is more or less the very basic of the tasks, besides the technical writing and the sharing and distribution of tasks.
If you are a SOC manager, make sure your folks know this and train this once in a while. I understand that it becomes less of a habit in a high frequency environment, but I would consider it good hygiene.
Talk to you soon again, until then be excellent to each other