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

A case for the need of Threat Intelligence in Risk Management

The concept of risk assessment is embedded in our DNA. Our ability to survive as a species is due in part to understanding the potential danger of our environment relative to what's needed to accomplish goals. Whether that goal was to gather food or build the pyramids, we are constantly measuring danger relative to potential rewards. In order to have the best results in the evaluation of risk, one must have the proper information. An example in history is Custar's battle at Little Big Horn. The information Custar received did not accurately account for the number of native American combatants on the field. If Custar had the appropriate information, the risk of his actions may have been too great to continue on his course of action.

While risk assessment is a part of who we are, the implementation of risk management is wrought with issues. The principle among them is bias. Bias is a bane to achieving the proper objective information.

Bias is prevalent throughout the risk management process. From the selection of the risk management team, tool use, and risk impact evaluation, bias tends to shift the perspective of the true impact of risk. The personal experience of the risk managers are used to identify and estimate the likelihood of a risk event. That experience is valuable but it is not objective. It tends to not take into account the changing landscape associated with threat evolution.

Bias serves as a base to distort the fundamental risk equation that information security professionals often use in their risk models.

Risk = Probability * Impact

Traditionally, information security professionals utilize ordinal values to assign the probability variable. Ordinal values are scales (1-5, unlikely-likely) that are widely used because of their perceived simplicity. Unfortunately, it has been proven that people in general are poor at assigning and interpreting ordinal values. The bias of one individual can interpret very likely to mean anywhere between 43% and 99% chance. In a study titled "Psychology of Intelligence Analysis", a veteran CIA officer conducted a study of officers and determined that the phrase "Highly Likely" meant anywhere between 50 to 100%.

How can a group come to a consensus on a decision with such a wide variance in the understanding of the same data?

There needs to be a shift from using gut feelings, intuition, and anecdotal evidence to make risk handling decisions. There has been an emergence of new techniques and tools to facilitate using actual data to support how likely an event that can impact your will occur. One tool that will truly give you a sense of how likely a risk event will occur is threat intelligence.

Gartner defines threat intelligence as "evidence-based knowledge, including context, mechanisms, indicators, implications, and action-oriented advice about an existing or emerging menace or hazard to assets. This intelligence can be used to inform decisions regarding the subject’s response to that menace or hazard."

Threat intelligence is key because it provides real data that drives your ability to determine how probable an event actually is based on your environment and the mitigating controls you have in place. Threat intelligence is capable of providing near real time insight into how adversaries could potentially infiltrate your environment based on data collected from various sources. You are enabled to discover these attacks in their infancy, before an attack campaign is launched against your organization. Threat intelligence provides a quantifiable shift from stating that an event is likely to having a 60% chance of occurrence. 

A properly implemented threat intelligence solution will dynamically identify the threats that are relevant to your environment. The risk manager can then associate the security controls that are in place with the tools, techniques, and procedures utilized by the adversary. The risk manager can then make informed decisions on how the threat landscape can impact your current risk posture. Operationally, threat intelligence can provide indicators that may arm the security team with data need to detect an attack that has already occurred within your environment. 

Information asymmetry is an advantage that the adversary utilizes throughout their campaigns. Effective use of threat intelligence does much to reduce the knowledge gap. Had Custar been more informed about his adversary there may have been a different outcome. Data collected from threat intelligence provides you real perspective on the effectiveness of your controls and your real risk posture. Decision making is buoyed by risk analysis based on threat intelligence that has observed real attacker patterns. Threat intelligence is a key component to improving the maturity of cyber risk programs by providing the quantifiable data that it so desperately needs.  


References:

Hubbard, D. W., & Seiersen, R. (2016). How to measure anything in cybersecurity risk. Hoboken: Wiley.

Richards J. Heuer, Jr., Psychology of Intelligence Analysis (Langley, VA: Center for the Study of Intelligence, Central Intelligence Agency, 1999)

Wait Wait Don't hack me.

I was spinning my wheels on this Ugly Duck challenge for a while trying to figure out what the downloaded file.bin is. When running the file command against it all it comes back with is data. Binwalk returned nothing. All the signatures came back with no match. When opening up the file in a hex editor I got the following:

Eventually I yielded and did some google fu and found that others encountered a similar challenge/file on other CTF. They just were able to take the hint that eluded me. They were able to assume that the Duck in the challenge name referred to Hack5's Rubber Ducky. You can then use The Duck Toolkit to decode the file to get ducky_code.txt and the inject.bin files.

But I wanted to know if there is a way to identify that this file is a rubber ducky script without guessing. So I generated a couple more payloads via the duck toolkit to see how they would display in a hex editor. I thought that it would have as many 00FF bytes as my original sample.

Nope. There are a couple of 00FFs though but not nearly as many. 

So in my search to figure out what that is I happened upon this gem. Apparently every of the 0x00FF translates to a 255 ms delay. Which corresponds with the DELAY commands in the ducky_code.txt file. 

The more you know!

Preparing for an Incident.

When talking incident response the standard process that is followed in handling an
incident is outlined in the following stages:

• Preparation
• Identification
• Containment
• Eradication
• Recovery

Preparation is not only the first phase but it is the most crucial phase. Preparation determines
the effectiveness of your incident response capabilities.  In practice, preparation is not only the
first step but its essence is also woven throughout the entire process. Preparation is also the
phase where implicit critical functions of effective incident handling are explicitly stated. Proper
preparation will dictate the maturity of your incident response team and its business impact can
be quantifiably measured.  

The focal points of preparation are:

• Policy
• Responsibilities
• Communication
• Tools
• Training

Policy

In order for an incident response plan to be effective the very first step is to obtain backing from the top
of the organization. This backing will insure that the organization as a whole will support the incident
response plan and provide the necessary time and resources to maximize its ability to be successful.
Executive support initially manifests itself in the form of policy that is signed off by the organization’s
leadership. A good policy protects the mission of the incident response team by giving it the necessary
authority to accomplish it. The policy provides a written set of principles, rules, or practices that dictates
how the organization will respond to an incident.

Defining the policy can be a daunting process due to there being many realms in information security that
could be impacted by an incident. Acceptable use, employee termination, data archival, access control,
and password management are just a small sample of how the tentacles of incident response my spread.
The policy can impact multiple departments that may have competing needs due to their own individual
mandates. Creating an overarching policy that that meets legal, regulatory, and operational requirements
may take a significant investment in time and resources. But it is a necessary step in order to understand
how the entire organization functions to help facilitate implementing an effective incident response team.

Responsibilities

The process of creating a policy begins to draw into focus the different roles that will be needed to
support the incident response process. Traditional incident roles such as a security manager and analysts
tend to be clear. Cross functional support from other departments is integral to the success of the team’s
ability to remediate incidents. These departments navigate the ramifications of the incident around legal,
compliance, and public relations concerns.

The identified roles should have their responsibility explicitly defined for the incident response process.
The roles will have different responsibilities depending on which phase of the incident response process
the organization is currently executing.  

Communication

The analysis that is conducted throughout policy development helps facilitate defining the communication
channels and processes that should occur during an incident. One of the common missteps that occur
during development of an incident response plan is neglecting to identify a key stakeholder in the handling
of an incident.

Laws and regulations may dictate the outside entities that your organization must communicate with in
the event of an incident. The communication plan should identify those entities and define the procedures
of notification. Special attention should be paid to vendors, customers and service providers when
developing a plan.

The communication plan should also set clear guidelines for when to involve law enforcement and who
will coordinate between the organization and agencies. The primary reason why a security incident does
not lead to criminal charges is that the organization did not handle the incident and communication with
law enforcement correctly. The person(s) designated as the lead contact should communicate with law
enforcement in clear and consistent manner that corresponds to the procedures defined by the
organization and law enforcement.

Tools

A key component of the policy creation process is defining the capabilities of the incident response team.
Clearly defining the responsibilities of your incident response team is integral in setting the organization
up for success. Some services may be handled internally while others may be outsourced.  The tools that
are implemented are designed to be in line with defined capabilities.

Each phase of the incident response plan will have tools associated with it. The detection and analysis
phase will have tools to streamline incident reporting, capture network traffic, and conduct behavioral
analysis. Incident containment and recovery phase will have tools to limit network/system access and
facilitate restoration of services within the defined recovery time windows. Post incident tools can be used
to update organization’s threat intelligence and update knowledge base.

Training

Once the tools and procedures have been defined, all staff that is to be involved in the incident response
process will need to be trained regularly. Training can take shape in many different forms. The key is to
make the training relevant and encompassing of different scenarios. Tabletop exercises that involve all
of the relevant departments is one of the most effective ways to fine tune the incident response process.
A tabletop exercise is a simulated exercise where participants gather to discuss incident processes. It
provides flexibility that is difficult to obtain with live exercises and is inclusive to all the roles within the
organization.  Tabletop exercises allow for the organization to identify gaps that may exist. They also
allow an organization to apply lessons learned in a controlled environment.

Regular practice allows for your company to perform at maximum efficiency during a live incident.

A popular Sun Tzu quote is “know yourself and you will win all battles.” Knowing yourself comes with
extreme care being taken during the preparation phase and conducting deliberate practice to discover
weaknesses. A mature and effective incident response team is not created via a canned technological
solution or any other magic bullet. They are built with meticulous attention paid to preparing to execute
the detection, containment, and post incident activities.   

Reference:
Computer Security Incident Handling Guide https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf