Operationalizing Threat Intelligence for the Small Business -- Processing

In this post, I highlighted the different phases of Threat Intelligence. It all sounds well and good on

paper and for companies that have dedicated cyber security resources. Here is where I dive into some tips for the Planning phase. And this post talks Collection. Today, we are going to go over the aspects associated with Processing and Exploitation. 

Processing and Exploitation

The first thing that I have to note is that once you have selected all of you collection sources you have to make provisions to store that data. Take care in projecting how much physical storage needs to be available for your particular use case. In the planning phase, you should have decided how long you will need to store your data based on your requirements. As you are analyzing your collection sources you can begin estimating how much data is gathered over a set period of time. Be sure to account for periods where there may be a surge of traffic due to peaks in business. There are some robust storage platforms that are available that are open source reducing your costs to the required hardware if you design an on premises solution. You can also leverage the cloud to provide this service if their capabilities align with your requirements.

Before you can begin to analyze the data you are collecting it must be sorted. Your collection sources can be from a variety of technologies that do not have a uniform output. They can also provide redundant information or superfluous details that are not relevant to your objectives. To assist with sorting it would be helpful to have a framework that helps define where things should go and then allows you to prioritize where to spend your time. One example is the Cyberkill Chain I referenced previously. The kill chain is a graphic representation depicting that as you move to the right of the chain the more impactful the breach. Collection sources that indicated that someone is conducting recon on your network may be useful in an after action analysis but may be overwhelming for proactive defensive activities. Data collected that belongs in the Command and Control section of the kill chain is an indicator that you are under active attack and may require an all hands on deck incident response approach. 

Software is going to be needed to facilitate the sorting. Thus begins the discussion of introducing a dedicated threat intelligence management platform (TIP/TIMP). A common question is: Can a SIEM serve as the threat intelligence platform? And my typical answer is: "It depends". For me, it's a nuanced conversation that can have several factors that influence my answer. Some SIEM solutions have TIMP functionality/plugins built into them. I plan to do a blog post dedicated to this conversation at a later time. But for now let's just speak of the TIMP conceptually in terms of functionality. 

The TIMP platform allows for automation of the processing and exploitation phases of the threat intelligence lifecycle. The data from your collection phases is aggregated and categorized with the goal of enabling you to respond more quickly to threats. When deciding on your solution you must go back to your requirements. An example is if you plan on processing structured and unstructured data sources your TIMP solution options may change. This will drive the solutions that are available to you. Commercial TIMP platforms tend to be expensive. There are some open source solutions that are available but may need more investment in time/resources for implementation and maintenance. 

Some Open source Platform Options:

• MISP
• Alienvault OSSIM/OTX
• ThreatConnect Open
• YETI
• Threat_Note

A nice compiled list can be found here: https://github.com/hslatman/awesome-threat-intelligence

MISP Screenshot                                  

I would recommend platforms that have a large community support that is active for those that have questions/issues. MISP and Alienvault are platforms that I personally have the most experience with and can easily grab plugins that may be needed for unique use cases. The platform should also be able to handle common threat intelligence sharing frameworks such as STIXX or TAXII. The decision you make for a TIMP should enable the analyst by providing actionable intelligence to produce knowledge designed to improve your ability to detect and respond to attacks.

Operationalizing Threat Intelligence for the Small Business -- Collection

In this post, I highlighted the different phases of Threat Intelligence. It all sounds well and good on

paper and for companies that have dedicated cyber security resources. Here is where I dive into some tips for the Planning phase. This post is all about Collection.

Collection

This phase is where you are to gather all of the raw data that supports the entire program. I believe that next to the planning phase, collection is the most critical portion of the Threat Intelligence Program. Wrong decisions made here can have adverse impacts to the rest of the threat intelligence lifecycle. An attempt to collect too much information will overwhelm the rest of the lifecycle making it impossible to achieve your goals. Collecting the wrong information will impede analysis and cause you to come to the wrong conclusions. 

But don't fret about making the wrong decisions, that's why the process is cyclical. You can make mistakes, get feedback from later phases, and then course correct. Each iteration is a chance to learn, evolve, and improve. So mistakes are good, use them to make your program better.

When making your collection decisions, I believe it is important to do so with specific goals in mind. Many will argue...convincingly... that you should collect as much as you can so that if you need to go back and filter through the data later you have that option. The drawback to this approach is that there is a cost associated with all this collection in both time and resources. I believe the greatest cost is the expense associated with getting caught in the muck and mire of too much data. Analysis paralysis. Instead, if you are looking for specific types of threats and their potential attack vectors you can make targeted decisions related to what you are collecting.

So the obvious question now is: "What attacks should I be looking for? How will I know what data is associated with it?"

A common source that can point you in the right direction is the Cyber Kill Chain.

The Cyber Kill Chain is a framework created by Lockheed Martin. It is meant to describe the methodologies used by attackers to compromise, persist, and exfiltrate data from a company. As a defender, the earlier in the chain you are able to detect an attack the greater your chance at having success as a defender. By taking a look at their methods and common ways of execution, you will begin to get an understanding of the artifacts that are left as they are executing the attack.

An example is an attacker is attempting to use commonly used passwords to log into your website. The attacker has done recon to discover your website is not using Multi-factor authentication. They have weaponized a tool to try many different passwords that are commonly used to see if they can gain privileged access. A collection source could be to gather application log data that tracks all failed logon attempts. Perhaps it also logs the IP address that the attempts are coming from as well as date and times. You have now identified a source of data that can be further analyzed that will provide you a lot of intelligence that you can now operationalize to take specific actions.

The Cyber Kill Chain or the Mitre ATT&CK framework are good sources to use for a threat based program.

The previous scenario is an example of an internal source that can be used for threat intelligence. A common misconception is that Threat Intelligence needs to be a feed from external sources that aggregates data that you can use in the protection of your networks. These feeds can be very expensive and vary greatly in their usefulness. Threat Intelligence data collection does not need to be something that carries great cost. There are many internal sources of valuable data that is already specific to your environment. There are also open source and affordable options that can be incorporated into your Threat Intelligence program.  Here are a small sample of examples of data sources that could support the collection phase of your program:

Internal

• An Asset discovery tool (Zabbix, AssetTiger, Snipe-IT)
• GRC Tools (Eramba)
• Application Logs
• Netflow data

External

• Shodan
• Open Threat Exchange (OTX)
• CVE Details
• RiskIQ Community Edition

Whatever you decide for your collection sources it is important to track them and the types of data collected from them. This helps analysis further in the cycle by understanding the enablers and constraints. This will also allow you to track your capabilities relative to your requirements. If you are collecting data that is redundant you can remove them to improve processing.

The goal of this post is to highlight that there are many collection sources that exist within your environment. Much of the data you need is at your fingerprints. By understanding attacker methodologies that are outlined by various frameworks, you can get tips about which techniques are relevant to you and the tools that are already at your disposal to best thwart attacks. 

Operationalizing Threat Intelligence for the Small Business -- Planning

In this post, I highlighted the different phases of Threat Intelligence. It all sounds well and good on
paper and for companies that have dedicated cyber security resources. But it can be daunting to an organization with limited resources to execute all of the phases defined in the Threat Intelligence process. Attackers are counting on this mindset. This is why the small to medium business are frequent targets of malicious actors looking to profit on your vulnerabilities. They know that their attack attempts will probably go unnoticed because the IT professional running the network also has 5 other responsibilities that take priority....up until the moment of the breach. The attackers also know that you probably don't have a number of sophisticated tools to automatically detect and respond to breach attempts.  

But here's the thing. You don't need to have sophisticated tools. A lot of what you need already exists within your network. Anything that is missing can be readily available via free or open source tools. This goal of this entry is to walk you through each phase of the Threat Intelligence Lifecycle and discuss processes and tools that an organization of any budget can implement to enhance their visibility into the tools, tactics, and procedures utilized by those looking to infiltrate your network. 

Planning and Direction

This phase is completely free! But it is also the most important step so maybe not completely free because you do need to define the goals of your threat intelligence program and what metrics you can put in place to determine its effectiveness. Should your threat intelligence aid your vulnerability management? Are you looking to improve your incident response capabilities? Maybe you are just looking to justify your security spending. Threat intelligence can support the business in a number of ways by providing real data that will provide direction to your efforts.

While it may sound cheesy, I am a fan of mission statements. A brief synopsis that encompasses all of your goals while driving the future endeavors of your program. The mission statement provides a guiding light whenever you may be stuck deciding what you should do next. It is the principle to look towards when trying to find ways to optimize the program. It is a reflection of your security program and organization as a whole. The mission statement is persistent in the face of changes to the organizational and threat landscape. 

A goal is just a dream if you can't measure it

I think someone smart said something like this once. After you have established your mission and set your goals, you need to be able to measure your progress towards obtaining that goal. So what does a good metric look like? In the example of attempting to aid your vulnerability management, perhaps you have recently conducted a vulnerability assessment on your environment. The vulnerability assessment spits out a 300 page document that states that 150 of the vulnerabilities are high. The problem with vulnerability scans is that they don't provide any context. You may have 100/150 that have mitigating controls. The other 50 may or may not have any active exploits being used in the wild. Threat Intelligence will provide you the additional insight to understand that out of those remaining 50, 15 of them are actively being exploited. Now you can prioritize your efforts and track your progress in remediating vulnerabilities specific to your environment. You now have laid the groundwork for a vulnerability intelligence program.

In the next post I will focus on the collection phase which I believe, next to planning, to be the most important phase of the process. I'll talk about viable sources of data that already exist within your environment and make suggestions for how to optimize what you collect and iteratively scaling up your capabilities by making smart choices.