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.

The Cyber Insurance Incentive

I stumbled upon a blog (I wish I could find it again) that talked about Marsh's Cyber Catalyst program. Somehow I am late to the game and today is the first time I have heard about it. The Cyber catalyst program is designed to help Cyber insurance providers by giving them a baseline security posture for the insured. The premise is that if a company has implemented a solution from 1 of 17 vendors as of the 2019 list, they will have to pay a lower premium because in theory they should be operating more securely.

From Marsh, the insurers that participate in this program evaluated the submitted solutions over the following criteria:

• Reduction of cyber risk: demonstrated ability to address major enterprise cyber risk such as data breach, theft or corruption; business interruption; or cyber extortion.

• Key performance metrics: demonstrated ability to quantitatively measure and report on factors that reduce the frequency or severity of cyber events.

• Viability: client-use cases and successful implementation.

• Efficiency: demonstrated ability of users to successfully implement and govern the use of the product to reduce cyber risk.

• Flexibility: broad applicability to a range of companies/industries.

• Differentiation: distinguishing features and characteristics.

It's easy to criticize this approach. Below are the problems that immediately come to mind:

• It can be seen as a system that's designed to push companies into buying certain products. 
• Insurer evaluation of products were not readily transparent
• Merely owning a product does not mean you are more secure (poor implementation, management, etc.)
• Vendor solutions selected can often be beyond the price point of smaller organizations

But I have to give props where it's due. The premise is great. All things being equal it does take a step in the right direction of battling information asymmetry between the insurers and the insured. Not fully understanding risk is the principle problem when it comes to finding the right balance between insurers knowing the risk they are taking on and the insured knowing what coverage to select. I also applaud that they are attempting to make these decisions quantitatively and with input from various sources. 

My main issue with the premise is that I don't believe the list of vendors selected to this list will be attainable for all. Once again pushing security into the realms of the haves and have nots. Also the implementation of these solutions will be all over the map leading to a potential false sense of security.  What I think should be pushed for is a focus on people and processes. These will be the foundation for higher degrees of confidence that organizations are operating securely as well as implementing their tooling correctly. 

Effective policy and procedures grow the tent by enabling organizations to use any vendor of their own choice to accomplish similar capabilities of the vendors on the Marsh list.   

In any systems engineering process, there are many steps before vendor evaluation and selection. The Marsh list seems to skip many of those by implying if you have 1 of 17 you are immediately more secure. I contend that before anything else, insurers need to relay to their clients that a formalized and properly implemented security policy will have far more reaching impact than any product. Insurers should quantifiably measure what internal security operations have the most impact in limiting attack surface. This is what they should be pushing for premium discounts. And this is what can be applied to every organization of every time. 

Give a man a security product and he may be secure for a moment? Teach a man how to be secure, and he'll be secure for a lifetime?  hmmm.....I don't know, I'll work it.  

Threat Intelligence Cycle

The concept of threat intelligence has been around for centuries. Its concepts have largely become popularized by the works of Sun Tzu. The "Art of War" is a philosophical compilation of strategies to have positive outcomes when facing an adversary. This adversary can be engaged on a variety of battlefields where there are competitors with conflicting interests including playing fields and boardrooms. The cyber domain is the most modern implementation of a battlefield. One in which your adversaries are largely nameless and faceless. Your adversaries have a wide breadth of skills and the threats they pose to your environment are dynamic by nature and constantly shifting. This is a challenge for one of Sun Tzu's most principle mandates to know your enemy for positive results. 

The application of threat intelligence to the cyber domain is integral to providing deeper insights into your adversaries capabilities and intent. 

Gill and Phythian defined intelligence in the book Intelligence in an Insecure World as:

[an] umbrella term referring to the range of activities – from planning and information collection to the analysis and dissemination – conducted in secret and aimed at maintaining or enhancing relative security by providing forewarning of threats or potential threats in a manner that allows for the timely implementation of a preventive policy or strategy, including, where deemed desirable, covert activities.

Application of Threat Intelligence to your cyber defense enables the shift from a reactionary mindset to a more mature targeted approach. This approach allows defenders to put in place protection mechanisms that takes into account the context of your unique environment. While others may be in a hysteria due to a newly released exploit, you know that you already have controls in place to mitigate any attack attempt.  No longer are you always in the position of being behind the curve in an attack. You are able to predict when an attack can occur and the methods that will be utilized. Putting you in a better position for positive outcomes because intelligence allowed you to know your enemy. 

Cyber threat intelligence is just the application of the threat intelligence cycle that has been used throughout history to the cyber domain. Below is a diagram of the cycle. It is designed to be recursive in nature to depict that it is recursive and each phase supports the others. Integral to the entire process is the mission. Each phase is driven by making sure it adheres to the mission is. It allows the intelligence team to focus on the subject areas that are of critical importance to the organization. That is why it is key to make sure that the mission is clear and disseminated to all of those that are involved in threat intelligence.

Princeton university has a good example of a mission statement and has made it public to make sure everyone knows and understands its directive. The mission is to make information security programmatic and cultural on campus in order to support the University in its mission in teaching and research. It’s clear and concise and they have defined specific activities that are in place to support that mission statement.

That mission statement sets the tone for the very first phase of the lifecycle, Planning and Direction. It is the principle input into what drives the direction of the program. The initial phase outlines the goals and requirements of the threat intelligence program. The contributions that threat intelligence is meant to provide to the organization is defined here. Other inputs include organizational policy makers and feedback from the intelligence dissemination phase. Planning for developing metrics around and monitoring for continuous improvement should be a key component of the initial phase. This direction is then passed to the collections phase.

The collections phase carries out the requirements mandated during the planning phase. This phase creates the systems necessary to collect the data needed to generate intelligence. The sources of this data can be both internal and external to your organization. The decisions made here determine how well the threat intelligence team is able to meet the mandates established by the mission.

Raw data is useless without processing and analysis. The processing phase is designed to convert that raw data to present it into a structured format that allows for efficient analysis. The collection phase gathers from a variety of sources that is not structured in a universal format. It will also filter data that is redundant or irrelevant to your operations.

The Analysis and production phase is where the correlation of structured, collected data occurs. This phase builds the narrative associated with threat behaviors. Data across all of the collected sources is now analyzed to develop a single source, event-oriented report. This report highlights the insights that were derived by the insights of the analysts.

The report is then disseminated to those that consume the threat intelligence. Consumers of threat intelligence operate throughout all levels of the organization. They are the decision makers as well as the implementors. Intelligence could discover information about a prolonged campaign targeting your organization, or it could be a list of IPs that should be blocked by your firewall. Each possibility would drive different activities that are designed to protect your organization.

The phase that is implicitly defined by the diagram is feedback. Each phase should provide feedback for the phase prior to it. Processing and exploitation should inform the collection team if any additional data would be helpful in processing the data. Dissemination should inform the analyst which report formats are most helpful in facilitating decision making. There should be a continuous dialog between the phases to make sure requirements are being met. This allows for adjustments throughout the lifecycle.

Next, I'll go over operationalizing Threat Intelligence. The focus will be on small businesses who may not have the resources for a dedicated intelligence team. 

References:

Liska, A., & Gallo, T. (2015). Building an intelligence-led security program. Amsterdam: Elsevier, Syngress.

Intelligence Cycle and Process. (n.d.). Retrieved March 24, 2020, from https://www.e-education.psu.edu/sgam/node/15

Information Security Office (ISO). (n.d.). Retrieved March 24, 2020, from https://informationsecurity.princeton.edu/about