Operationalizing Threat Intelligence 1 Converted Kyle Wilhoit

Operationalizing Threat Intelligence 1 Converted
Kyle Wilhoit download
https://ebookbell.com/product/operationalizing-threat-
intelligence-1-converted-kyle-wilhoit-54789666
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Operationalizing Threat Intelligence A Guide To Developing And
Operationalizing Cyber Threat Intelligence Programs 1st Edition Kyle
Wilhoit
https://ebookbell.com/product/operationalizing-threat-intelligence-a-
guide-to-developing-and-operationalizing-cyber-threat-intelligence-
programs-1st-edition-kyle-wilhoit-55037194
Operationalizing Dynamic Pricing Models Bayesian Demand Forecasting
And Customer Choice Modeling For Low Cost Carriers 1st Edition Steffen
Christ
https://ebookbell.com/product/operationalizing-dynamic-pricing-models-
bayesian-demand-forecasting-and-customer-choice-modeling-for-low-cost-
carriers-1st-edition-steffen-christ-4269008
Operationalizing Multicloud Environments Technologies Tools And Use
Cases 1st Edition Rajganesh Nagarajan
https://ebookbell.com/product/operationalizing-multicloud-
environments-technologies-tools-and-use-cases-1st-edition-rajganesh-
nagarajan-43259396
Operationalizing Sustainability 1st Edition Pierre Massotte Patrick
Corsi
https://ebookbell.com/product/operationalizing-sustainability-1st-
edition-pierre-massotte-patrick-corsi-5435266

Operationalizing Iconicity Pamela Perniss Editor Olga Fischer Editor
https://ebookbell.com/product/operationalizing-iconicity-pamela-
perniss-editor-olga-fischer-editor-11733824
Operationalizing Machine Learning Pipelines Building Reusable And
Reproducible Machine Learning Pipelines Vishwajyoti Pandey
https://ebookbell.com/product/operationalizing-machine-learning-
pipelines-building-reusable-and-reproducible-machine-learning-
pipelines-vishwajyoti-pandey-44867910
Practitioners Guide To Operationalizing Data Governance Mary Anne
Hopper
https://ebookbell.com/product/practitioners-guide-to-operationalizing-
data-governance-mary-anne-hopper-49972716
Practical Mlops Operationalizing Machine Learning Models 1st Edition
Noah Gift
https://ebookbell.com/product/practical-mlops-operationalizing-
machine-learning-models-1st-edition-noah-gift-34834056
Measuring Technology Maturity Operationalizing Information From
Patents Scientific Publications And The Web 1st Edition Till Albert
Auth
https://ebookbell.com/product/measuring-technology-maturity-
operationalizing-information-from-patents-scientific-publications-and-
the-web-1st-edition-till-albert-auth-5357170

Table of Contents
Preface
Section 1: What Is Threat Intelligence?
Chapter 1: Why You Need a Threat Intelligence Program
Chapter 2: Threat Actors, Campaigns, and Tooling
Chapter 3: Guidelines and Policies
Chapter 4: Threat Intelligence Frameworks, Standards, Models, and
Platforms
Section 2: How to Collect Threat Intelligence
Chapter 5: Operational Security (OPSEC)
Chapter 6: Technical Threat Intelligence – Collection
Chapter 7: Technical Threat Analysis – Enrichment
Chapter 8: Technical Threat Analysis – Threat Hunting and Pivoting
Chapter 9: Technical Threat Analysis – Similarity Analysis
Section 3: What to Do with Threat Intelligence
Chapter 10: Preparation and Dissemination
Chapter 11: Fusion into Other Enterprise Operations
Chapter 12: Overview of Datasets and Their Practical Application
Chapter 13: Conclusion
Other Books You May Enjoy

Preface
The volume of cyber threat events that occur has reached a point at which
the world is talking about numerous attacks against various organizations'
attack surfaces daily. Additionally, the reasoning behind these attacks
ranges from opportunistic to financially motivated to revenge, and even to
support ongoing physical conflicts between nations. It's no longer a
question of if you or your organization will be impacted by a cyber threat
event; it's now a question of when.
This book is written for one purpose, and that is to introduce individuals
and organizations to cyber threat intelligence operations. In this book, we
take you through the process of evaluating the cyber threat intelligence life
cycle and discuss the various motivations, operating processes, and points
to consider when establishing or maturing a cyber threat intelligence
program. During the process, you are introduced to the different phases of
the intelligence life cycle that assist you with understanding your
knowledge gaps, evaluating threats, building a program to collect data
about threats, analyzing those threats, and using the information collected to
make hypotheses that inform strategic decision making about the threats
most organization are facing.
By the end of this book, you will be able to build a cyber threat intelligence
program that focuses on threat actors, campaigns, and actor tools, in
addition to establishing processes and procedures that focus on the analysis
and enrichment of technical data collection about threats that will assist you
or any organization with key decision making around security posture
improvements.

Who this book is for
This book is truly intended to be introductory-level material that can be
applicable to early-in-career professionals who want to approach threat
intelligence as a discipline. Anyone looking to implement basic threat
intelligence collection and enrichment would likely find this book valuable.
This book could also be beneficial to people in roles such as a threat
intelligence analyst, security operations center (SOC) analyst, or incident
responder.

What this book covers
Chapter 1, Why You Need a Threat Intelligence Program, is where you will
learn the fundamentals of what threat intelligence is, how it differs from
data, and what constitutes good threat intelligence.
Chapter 2, Threat Actors, Campaigns, and Tooling, is where we examine
the varying types of threat actors, their behaviors and approaches to
committing attacks, their motivations, and the associated tactics,
techniques, and procedures (TTPs) utilized in their attack chain.
Chapter 3, Guidelines and Policies, is where you will be introduced to the
needs and benefits of the various guidelines, procedures, standards, and
policies that should be introduced into a cyber threat intelligence program.
Chapter 4, Threat Intelligence Frameworks, Standards, Models, and
Platforms, is where you will examine threat models, frameworks, and
standards to help organize, structure, and facilitate sharing, analysis, and the
understanding of threat intelligence data and information with stakeholders.
Chapter 5, Operational Security (OPSEC), covers fundamental
considerations to operational security (OPSEC) when conducting
investigations. While not all-encompassing, these considerations can be
helpful for new threat intelligence professionals. We wrap the chapter up by
examining collections operations.
Chapter 6, Technical Threat Intelligence – Collection, is where you will
examine the second phase of the intelligence life cycle, the collection phase.
We'll look into what collection is, the collection management process, the
role of the collection manager, and the collections operations life cycle.
Chapter 7, Technical Threat Analysis – Enrichment, covers technical threat
intelligence enrichment and analysis, which examines the process of adding
context to threat intelligence data and enhancing or improving that data by
performing actions such as removing false positives or incorrect
intelligence data.

Chapter 8, Technical Threat Analysis – Threat Hunting and Pivoting, is
where we examine hunting and pivoting on threat data from collection
operations to see whether the related malicious activity can be identified.
We will also look into several hunting and pivoting methods, as well as
introducing you to several tools and services that could be used to assist you
with performing these types of operations.
Chapter 9, Technical Threat Analysis – Similarity Analysis, is where we
introduce the concept of using graph theory with similarity grouping, in
addition to introducing you to several similarity grouping tools. Finally, we
introduce you to the concept of using tools to cluster infrastructure or files.
Chapter 10, Preparation and Dissemination, is where we focus on how to
interpret the collected data, evaluate it for intelligence, and identify portions
that should be considered timely, accurate, and relevant threat
intelligence. Special focus in this chapter is placed on interpretation and
alignment, critical thinking and reasoning, tagging, and considerations
relating to threat intelligence.
Chapter 11, Fusion into Other Enterprise Operations, covers key
stakeholders of the organization that would consume the threat intelligence,
why, and for what purpose. This chapter examines the distinct
considerations for using threat intelligence throughout several
organizational units.
Chapter 12, Overview of Datasets and Their Practical Application,
establishes an example threat intelligence collection, analysis, and
production scenario that is used to walk through each of the phases of the
intelligence life cycle to ensure that you get some hands-on practice in each
phase as it applies to the real-world scenario.
Chapter 13, Conclusion, is where we wrap up everything we discussed
previously and highlight how each of the previous chapters is part of the
intelligence life cycle and how they fit into the cyclical process of
operationalizing threat intelligence.
To get the most out of this book

While many of the tools mentioned throughout this book are services
commonly found online, we do utilize several pieces of software. When we
examine software, it's advisable to run the software in virtualized
environments, using software such as VirtualBox. Specifically, in the
instances where we mention software usage, the basic requirements are as
follows:
If you are using the digital version of this book, we advise you to type
the code yourself or access the code from the book's GitHub repository
(a link is available in the next section). Doing so will help you avoid any
potential errors related to the copying and pasting of code.
All of the examples used throughout this book use free-to-use accounts on
commonly available threat intelligence tools, such as RiskIQ's PassiveTotal.
In cases where there is additional paid-for functionality in those tools, such
as advanced search features, we ensure that it's mentioned.
Download the color images
We also provide a PDF file that has color images of the screenshots and
diagrams used in this book. You can download it here: https://static.packt-
cdn.com/downloads/9781801814683_ColorImages.pdf.

Conventions used
There are a number of text conventions used throughout this book.
Code in text: Indicates code words in the text, database table names,
folder names, filenames, file extensions, pathnames, dummy URLs, user
input, and Twitter handles. Here is an example: "In this example, let's
imagine an incident responder finds an infected host with communication
going to an IP address – 45.9.148.108."
A block of code is set as follows:
#include <windows.h>
#define WIN32_LEAN_AND_MEAN
void filter()
{
return;
}
Any command-line input or output is written as follows:
pe.imphash() == <imphash value>
Bold: Indicates a new term, an important word, or words that you see on
screen. For instance, words in menus or dialog boxes appear in bold. Here
is an example: "FCR Identifier: 1.0."
Tips or Important Notes
Appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book,
email us at customercare@packtpub.com and mention the book title in the

subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our
content, mistakes do happen. If you have found a mistake in this book, we
would be grateful if you would report this to us. Please visit
www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on
the internet, we would be grateful if you would provide us with the location
address or website name. Please contact us at copyright@packt.com with a
link to the material.
If you are interested in becoming an author: If there is a topic that you
have expertise in and you are interested in either writing or contributing to a
book, please visit authors.packtpub.com.
Share Your Thoughts
Once you've read Operationalizing Threat Intelligence, we'd love to hear
your thoughts! Please click here to go straight to the Amazon review page
for this book and share your feedback.
Your review is important to us and the tech community and will help us
make sure we're delivering excellent quality content.

Section 1: What Is Threat
Intelligence?
Section 1 of Operationalizing Threat Intelligence introduces the core
concepts of threat intelligence. This section addresses and answers the
question What is threat intelligence? The chapters throughout Section 1 will
cover everything from defining the purpose of the book to helping you to
understand the importance of prioritized collection requirements. This
section sets the foundation and stage for the more technical Section 2 and
Section 3.
This part of the book comprises the following chapters:
Chapter 1, Why You Need a Threat Intelligence Program
Chapter 2, Threat Actors, Campaigns, and Tooling
Chapter 3, Guidelines and Policies
Chapter 4, Threat Intelligence Frameworks, Standards, Models, and
Platforms

Chapter 1: Why You Need a Threat
Intelligence Program
Today, almost every organization has a digital footprint, and this alone
makes any organization a target of opportunity for threat actors who have
malicious intent.
So, something happened, right? Ransomware? Supply chain attack?
Ransomware because of a supply chain attack? Something worse? Often,
individuals and organizations experience a revelation during times of
concern or crisis that causes them to explore other options. Through the
process of discovery, if you have come across the term threat intelligence
and want to know more about how it can assist in maturing your security
posture or protecting your organization, great! We're glad you made it here
because we're here to help.
Threat intelligence, a mystery to many, is a science to some. The how,
where, when, and why of technical threat intelligence collection and
enrichment is a complex topic, with many facets to explore. The objective
of this chapter is to introduce core concepts related to technical threat
intelligence, including the motivation, models, and methods by which threat
intelligence can be collected and enriched.
Specifically, in this chapter, we are going to cover the following topics:
What is Cyber Threat Intelligence (CTI), and why is it important?
Tactical, strategic, operational, and technical CTI
The uses and benefits of CTI
How to get CTI
What is good CTI?
Intelligence life cycles
Threat intelligence maturity, detection, and hunting models

What is CTI, and why is it
important?
The concept of CTI is as old as war. Understanding a threat actor's
intentions, capabilities, objectives, resources, and thought process leads to a
better-informed defender. Ultimately, the end result of intelligence could be
as simple as updating a firewall block policy with a feed of known malware
Command & Control (C2) infrastructure. Additionally, it could be a
dossier on threat actors targeting your organizational industry vertical.
Ultimately, a better-informed defender can make actionable changes in an
organization's risk profile by better directing all lines of business within an
organization.
Ask any IT security professional what CTI is, and you'll likely get different
definitions. The definition of threat intelligence almost always varies from
organization to organization. This is often due to the differing motivations
within each organization for having a threat intelligence program. We're not
going to wax poetic about the differing threat intelligence definitions, so
instead, we'll focus on the definition as it relates to this book.
If we were to distill down what CTI is, simply put, it is data and
information that is collected, processed, and analyzed in order to determine
a threat actor's motives, intents, and capabilities; all with the objective of
focusing on an event or trends to better inform and create an advantage for
defenders. Many organizations face challenges regarding CTI functions –
such as a flood of alerts generated from an automated API feed. A properly
executed CTI collection and enrichment program can help assist with those
challenges.
Data, information, and intelligence
What to do with threat intelligence

When talking about CTI, it's important to differentiate between data,
information, and intelligence. It's important to understand the distinct
differences between data, information, and intelligence so that you can
store, analyze, and determine patterns more efficiently. As an example, a
URL is a piece of data that contains a domain – the registrant data for that
domain is information, and the registrant being commonly associated
infrastructure with the Threat Actor Group (TAG) APT29 would be
considered intelligence.
Important Note
This is the first time we've used the acronym of TAG. To clarify our
vernacular, a threat actor is a person or entity responsible for malicious
cyber activity. A group of threat actors working in unison is called a TAG
and, often, is identified directly through naming conventions such as
APT29, which was referenced earlier. We'll be covering more on TAG
naming conventions in Chapter 2, Threat Actors, Campaigns, and Tooling.
Data is a piece of information, such as an IP address, malware hash, or
domain name. Information is vetted data, but often lacks the context that is
needed for strategic action, such as an IP address with no malicious/benign
categorization or contextualization. And finally, intelligence is adding a
layer of analysis and context to that information and data and, therefore,
making the intelligence actionable, such as a feed of malware hashes
associated with cybercrime actors operating out of Europe.
To help in adding context, examples of each can be found in Table 1.1:

Table 1.1 – Table demonstrating data, information, and intelligence
The process of converting data into threat intelligence includes a
combination of collection, processing, analyzing, and production, which
will be explored later in the chapter.
Understanding the importance of threat intelligence and the differentiation
of data, information, and intelligence is paramount to a structurally sound
CTI program. Now that we've looked at those important aspects, we're
going to dive into understanding the difference between the different types
of intelligence: tactical, strategic, operational, and technical.
Tactical, strategic, operational, and
technical threat intelligence
When thinking about CTI, it's easy to assume that it is one discipline. On
the surface, an analyst collects data from several sources, analyzes that data,
and synthesizes intelligence, which, ultimately, helps the organization take
action. However, closer inspection reveals there are really four distinct
types of CTI.

Tactical CTI
Tactical CTI is the data and information related to the Tactics, Techniques,
and Procedures (TTPs) used by threat actors to achieve their objective.
Ultimately, tactical CTI is intended to inform defenders, threat detection
and response engineers, incident responders, and other technical teams
throughout the organization in order to motivate an action of some sort.
Unlike strategic CTI, tactical CTI is almost exclusively used by technical
resources. Usually, tactical CTI is consumed directly by those responsible
for defending an organization.
The most common deliverables include targeted reports, threat feeds, and
API feeds of malicious observables. Many of the reports that are generated
focus on the technical details pertaining to a malware family, threat group,
or campaign of activity. Some examples of what might be included in
tactical CTI reports include the following:
To produce tactical CTI, a combination of open source and vendor-provided
intelligence and data is most often used. To create tactical threat
intelligence, the producer should employ an active collection and
enrichment process. Some examples of sources of tactical CTI include the
following:
Targeted industries
The infection vector of the threat actor
The infrastructure used by the attacker
Tools and techniques employed by the threat actor
Malware analysis details
Honeypot log analysis
Internal telemetry data
Scan data (such as Shodan.io)

Next comes strategic CTI.
Strategic CTI
Strategic CTI is often non-technical threat landscape information that is
related to risk-based intelligence and, typically, includes relevant industry
vertical intelligence. Strategic CTI is most often used by senior decision-
makers throughout organizations.
The most common deliverables include reports or briefings. It's common for
the data sources for strategic CTI to be open source and include a wide
variety of sources. Take a look at the following:
Let's move on to operational CTI.
Operational CTI
In an ideal world, CTI would enable preventative action to be taken before
a threat actor compromises an organization. Operational CTI is intelligence
unearthed about possible incoming attacks on an organization. Operational
intelligence is typically technical and strategic in nature and includes
information pertaining to the intent, capabilities, and timing of impending
attacks. This provides insight into the sophistication of the threat actor or
group, helping dictate an organization's next steps. Operational CTI helps
enable defenders to block activity before the activity even takes place, but
due to this, operational CTI is, most often, some of the hardest to generate.
Local and national media
Government policy documents
Industry reporting
Content produced by industry organizations
Social media activity

The most common deliverable for operational CTI is spot reports with
technical indicators and context extracted from other strategic intelligence.
There are many sources that can generate this type of CTI, including the
following:
Next, let's take a look at technical CTI.
Technical CTI
Technical CTI is exactly what it sounds like – technical indicators related to
an actor's tools, malware, infrastructure, and more are used to conduct their
activities. Technical CTI differs from tactical CTI because technical CTI
most commonly focuses on Indicators Of Compromise (IOCs), and
tactical CTI relies on analyzing TTPs.
For example, say tactical threat intelligence indicates that the financially
motivated criminal group FIN7 has attacked the banking industry in the
United States and Europe. Technical threat intelligence would provide the
specific hashes, infrastructure, and other details pertaining to the specific
attack.
Ultimately, technical CTI is intended to inform defenders, threat detection
and response engineers, incident responders, and other technical teams
throughout the organization. The most common deliverables include the
following:
Intercepting the chat logs of threat actor coordination
Social media
Chat rooms and instant messaging rooms (such as Discord or
Telegram)
Underground forums and marketplaces
Public and private forums and message boards

Sourcing technical threat intelligence comes from a litany of locations, for
example, consider the following:
To wrap up, in the following table, let's examine the distinct differences
when comparing and contrasting each intelligence type, their respective
audiences, and length of intelligence value:
Feeds or reports including malicious hashes, infrastructure, and other
file attributes
Changes to a system infected with specific malware; for example,
registry modifications
Confirmed C2 infrastructure
Email subject lines
Filenames or file hashes
Information security industry blogs and white papers
Malware analysis
Industry trust groups
Threat feeds

Table 1.2 – A table comparing intelligence types
Within each of the CTI types, there is often a conversation about Subject
Matter Expertise (SME) and relative team function. In the following
section, we're going to explore the concept of SME within each CTI type.
Subject matter expertise
The concept of SME is a common conversation among threat intelligence
circles. When setting up a threat intelligence program, it's important to
consider the possible positives and negatives associated with dividing
relative team functions among three broad SME focus areas: vulnerability
and exploitation, cyber (criminal and nation-state), and brand:

Table 1.3 – Intelligence SME types
While CTI functions employing subject matter experts don't fit every team
structure, it's an important consideration to take into account when
constructing a team focused on CTI. In the following section, we're going to
dive into the importance of CTI and its relative uses and benefits to an
enterprise.
The uses and benefits of CTI
I think it can wholeheartedly be stated anywhere within this industry that
CTI is important to everyone as it provides contextual information that
allows for strategic decision-making. This context allows it to be used by
almost any level of analyst or researcher throughout any organization. Its
use is not limited to some elite subset of intelligence analysts who claims to
know every move of a TAG. Key judgments can be formed from contextual
intelligence at any level of employment; from a Security Operations
Center (SOC) analyst implementing a firewall policy change after
receiving intelligence that a URL is serving a web shell that is known to be
associated with several TAGs or even a C-level executive making informed
strategic decisions to improve the security posture of their organization.
However, to utilize threat intelligence, several key factors need to exist for
it to be useful. First, it needs to be timely in the sense that the delivery of
information is provided to a key decision-maker before a key event so that a
judgment can be formed around its context. Second, the intelligence must
be actionable, that is, the intelligence provided should allow for that key
judgment to be realized and a decision made that allows the individual or
organization to make a decision based on its delivery. Third, intelligence
should be relevant. By actionable, we're referring to the ability to take any
action based on the intelligence itself. Finally, intelligence must be
delivered in a format that has the lowest barrier to entry for consumption by
an organization. This means that any individual or organization that wishes
to benefit the most from the existence of CTI must incorporate it into their
processes and procedures or even develop security automations around it.

The context of the threat provided by the intelligence is where its value
truly lies, as it assists any individual or organization with prioritization,
which is one of the most important benefits of threat intelligence. No matter
what security role you play in an organization, your role will benefit from
the context that threat intelligence provides, as this will allow you to
prioritize your key decision-making around the data your organization is
consuming.
For example, let's consider this paradigm. Organizations that are only now
beginning to look at implementing some form of threat intelligence
program into their security organization often start by identifying free data
feeds or online services that contain some form of security information,
usually in the form of a threat data indicator or IOC. While this is a great
start in the collection of data and information that could be used to create
threat intelligence, without the context surrounding this information and the
appropriate indoctrination by people, processes, and technologies, this
approach usually leads to just more information and the encumberment of
your human workforce.
With all of this extra information, the burden is just added to your analyst to
decide what to review and prioritize and what to ignore. This approach can
lead to operational misses, such as incidents that could have been prevented
if the appropriate prioritization were placed on the information you were
receiving from your threat data feed. CTI can assist in providing context
around this information that you receive and give you key insights into the
TAG's TTPs. This will assist in informing your decision-making and help
you prioritize your actions based on the contextual intelligence provided.
Now that you're aware of the uses and benefits of CTI, let's explore how to
get CTI.
How to get CTI
Getting information about threats is relatively easy; either you're creating
data through internal product telemetry, you're collecting from a data feed,
or you're doing both. Data and information that can be used as a foundation
for threat intelligence is just a Google search away. This kind of search will

present you with lots of sources that provide threat data in the form of feeds
that you can utilize to begin the evaluation and intelligence enrichment
processes. One important thing to note, though, is that this information is
not CTI but threat data feeds. Once you have it in place, you will still need
to go through the process of considering whether the information is
credible, actionable, and timely as well as considering how you will work it
into your internal standard operating procedures or security automations.
Right now, I want to walk you through the process of gathering some
technical information from an open source resource published on the
internet. This will give you an introduction if you are starting your journey
from scratch.
Some of the most common indicator types that individuals and
organizations are seeking some type of context and reputation for are URLs,
domains, and IP addresses. These indicator types are riddled throughout the
logs of any corporate ecosystem, and nobody with any kind of digital
footprint is doing business without accessing some form of these. Domain,
URL, and IP address reputation intelligence can assist internet users to
determine whether the internet endpoint is safe, suspicious, or even
malicious, essentially allowing the individuals or the corporation to protect
themselves against any known malware source, its delivery mechanisms, or
any malicious content on the web.
Let me introduce you to a free web-based service called urlscan.io. Their
mission is to allow anyone to analyze unknown and potentially malicious
websites easily and confidently. According to their website
(https://www.urlscan.io), the following is true:
When a URL is submitted to urlscan.io, an automated process will browse
to the URL like a regular user and record the activity that this page
navigation creates. This includes the domains and IPs contacted, the
resources (JavaScript, CSS, etc) requested from those domains, as well as
additional information about the page itself. urlscan.io will take a
screenshot of the page, record the DOM content, JavaScript global
variables, cookies created by the page, and a myriad of other observations.
If the site is targeting the users of one of the more than 400 brands tracked

by urlscan.io, it will be highlighted as potentially malicious in the scan
results.
The urlscan.io service itself is free, but they also offer commercial products
for heavy users and organizations that need additional insight.
To begin utilizing urlscan.io, simply navigate to their website and type the
URL you are seeking a reputation for into the form field at the top of the
page, as referenced in Figure 1.1. Then, click on Public Scan to begin the
process:
Figure 1.1 – The urlscan.io landing page
Once you click on Public Scan, urlscan.io goes through the process
described earlier to initiate some form of reputation determination regarding
the site you are seeking questions about. It will provide you with the results
of its analysis and even a verdict that you can utilize for decision-making.
Examples of malicious urlscan.io results can be seen in Figure 1.2, along
with all the additional observable information produced during the scan of
the URL:

Figure 1.2 – The urlscan.io results for a malicious domain
You can clearly see in the results of the URL scan that urlscan.io believes
this domain contains some form of malicious activity specifically targeting
Credit Agricole, a financial services company based out of France. You
can see in the results of the scan that there is a large amount of data and
information produced about the URL that can be collected and utilized as a
part of creating your CTI.
If you click on the Indicators tab on the website, you will be presented
with Figure 1.3:

Figure 1.3 – The Indicators tab on urlscan.io
The results of the URL scan allow us to provide you with a small
demonstration of how data can be transitioned into information that can be
utilized as the foundation for CTI. In the following list, you will find a
sampling of indicator data from the URL scan along with the indicator
types:
In this example, the URL indicator was the first piece of data that was
utilized to start an operation investigation for this use case. Through the
utilization of urlscan.io, it was determined that the associated indicators
could be tied to the initial data. Often, this is called pivoting and is part of
the hunting and enrichment process that we will describe, in detail, in later
URL:
https://www.dorkyboy.com/photoblog/templates/smokescreen/sty
les/js/mdddss/lmmnodejs/
DOMAIN: dorkboy.com
IP ADDRESS: 174.136.24.154
HASH: 1c8399c9f4f09feb8f95fe39465cc7e70597b0097ad92da954
db82646ec68dc3
HASH: 7b0da639a2ad723ab73c08082a39562aa3a2d19adb7472f1
dbb354c5fd0b4c20

chapters. This hunting and enrichment process provides us with information
we can then utilize to create our threat intelligence. Finally, based on the
result set, we can see that the URL is malicious and that the threat actor
performing the malicious activity is specifically targeting the financial
services industry in France. Further investigation would show that the URL
points to a phishing kit deployed on a compromised website, which is being
utilized to collect account credentials.
Based on all the information provided here, you can see that in the right
context, strategic decisions about the URL can be made to protect your
users or harden your security posture.
Important Note
It is important to note that in the preceding example, the URL is specifically
malicious in this instance – this does not always mean that the domain
should be categorized as the same. Often, legitimate domains are
compromised, and threat actors upload kits meant to target specific brands
and will specifically socially engineer users to the deep URL within the
domain. Once a compromise has been identified, the domain owner will go
through the process of cleanup to eliminate the malicious URLs in the
domain. Malicious categorization contains a timeout and revaulation period,
ensuing the verdict is accurate and any initial malicious categorization
should expire or be reevaulated.
Almost any organization can retrieve and receive CTI, but that doesn't
necessarily mean that the intelligence is actually usable and good. In the
following section, we're going to take a deep dive into what constitutes
good CTI.
What is good CTI?
Almost anyone can generate threat intelligence. However, not everyone can
generate good threat intelligence. In order to generate threat intelligence
that is considered good and is useful, there are five key traits to consider in
combination with the Admiralty, source, and data credibility ratings. When

combining all of these key concepts together, the end result should generate
timely, accurate, and useful threat intelligence.
Let's look at the traits of good CTI.
The five traits of good CTI
When thinking of CTI in general, there are five key traits that can be
distilled down to illustrate what constitutes good CTI.
Those five traits include the following:
There are many methods available to ensure the accuracy, completeness,
reliability, relevance, and timeliness of intelligence. However, one tried and
true method for ensuring those are met is a framework called Admiralty.
Accuracy: Is the intelligence correct in every detail? This is a key
concept ensuring that only accurate intelligence is retained.
Completeness: How comprehensive is the intelligence? Completeness
helps ensure all related intelligence is gathered and collected.
Reliability: Does this intelligence contradict other trusted sources?
Reliability means that a piece of information is reliable and doesn't
conflict with another piece of information or data in a different source
or system. When data or intelligence conflicts from two sources, that
intelligence then risks becoming untrustworthy.
Relevance: Do you really need this intelligence, that is, in terms of the
geographical location and/or nature of the business your organization is
in? Looking at relevance establishes a need for intelligence. If irrelevant
intelligence is being gathered, time is being wasted along with the
possible pollution of current or future collected intelligence.
Timeliness: Is the intelligence up to date? Simply put, intelligence that
isn't timely can lead to analysts making the wrong decisions based on
historical or incorrect intelligence. Timeliness ensures decisions aren't
made with stale information.

Admiralty ratings
The Admiralty System or NATO System is a method for evaluating and
rating collected intelligence. It consists of a two-character notation that
evaluates the reliability of the source and the assessed level of data
credibility of the intelligence. Employing Admiralty ratings to collect
intelligence is an important data quality and source reliability assessment
tool.
Source ratings
Understanding the reliability of an intelligence source (automated, semi-
automated, or human) is paramount when considering onboarding an
intelligence source. A source rating should be applied to intelligence that is
collected and analyzed.
Applying a source rating is an important process in CTI as it serves as a
historical ledger of activity of the source of the intelligence, making it
easier for perusal in the future. When examining source ratings, sources are
classified in order of decreasing reliability, with A being the most reliable:

Table 1.4 – Data and intelligence source reliability scale
Source ratings play an important part in any CTI program. Source ratings
help establish a baseline trust rating for any source – whether that is data or
human in scope. In the following section, we're going to discuss an
additional part of CTI: data credibility ratings.
Data credibility ratings
Within CTI, it's important to trust but verify the data sources of threat
intelligence. Assigning a credibility rating to threat intelligence helps to
establish the fundamental accuracy of an organization's CTI program.
Additionally, when employed, credibility ratings help establish a profile of
the intelligence that is being collected. And finally, data credibility, while
somewhat subjective, helps eliminate confirmation bias by seeking
independent source validation.

Data credibility ratings measure the levels of corroboration by other
sources. When examining source ratings, the credibility is classified in
order of decreasing credibility, with 1 being confirmed by independent
sources:
Table 1.5 – Data credibility ratings
Data credibility ratings help a CTI organization judge the credibility of the
data they are ingesting. While data credibility ratings play a crucial role in
CTI, fusing the data credibility rating with source ratings makes for a great
combination to assess data and intelligence accurateness, reliability, and
trustworthiness.
Putting it together
In principle, it should be easy to apply Admiralty codes to threat
intelligence, but in practice, it's more difficult. The question that often
arises is, ultimately, what data and intelligence can we trust?
While that answer will vary, one method to consider employing is from a
paper titled The Admiralty Code: A Cognitive Tool for Self-Directed
Learning, written by James M. Hanson at the University of New South

Wales (2015;
https://www.ijlter.org/index.php/ijlter/article/download/494/234).
Using Table 1.5, it's easy to start applying source and credibility ratings to
collected CTI:
Table 1.6 – The Admiralty code for evaluating data credibility
Using the preceding table as an example in which to apply to threat
intelligence, an information security industry threat intelligence blog would
be considered B1, which is usually reliable and confirmed and can, thus, be
considered credible.
A second example would be intelligence from a little-known independent
researcher on their personal blog with no independent confirmations. This
intelligence could be rated F3, or the source cannot be judged, and the
credibility of it would be possibly true, requiring additional investigation.
Employing Admiralty ratings in conjunction with intelligence life cycles in
a CTI program is a generally accepted mechanism to enable a CTI program.
Let's move on to threat intelligence life cycles next.
Intelligence cycles
Within the field of CTI, there are several intelligence life cycles that can be
considered for implementation. In many cases, the most widely used
models are the threat intelligence life cycle and the F3EAD cycle. Each
model provides its own distinct benefit, and the application of each model

depends on the organization's needs. However, implementing one of these
models is paramount, as it provides consistent, actionable, reliable, and
high-quality threat intelligence.
The threat intelligence life cycle
The threat intelligence life cycle is a process and concept that was first
developed by the United States Central Intelligence Agency (CIA).
Intelligence is the product of a process that includes collecting data,
analyzing it, adding context, and finally, delivering that intelligence as a
product of some sort. Following this life cycle will give your organization a
structured, repeatable way of delivering consistently accurate and timely
intelligence. The threat intelligence life cycle is a five-step process, which
is meant to be followed in order, starting with planning and direction:
1. Planning and direction
2. Collection
3. Analysis
4. Production
5. Dissemination and feedback
Let's examine the threat intelligence life cycle in greater detail:

Figure 1.4 – The threat intelligence life cycle
When analyzing the threat intelligence life cycle, it's best to look at each
stage individually to better understand how the stage fits into the overall
threat intelligence life cycle. So, let's examine each stage in closer detail.
Planning and direction
Generally speaking, the first phase of the threat intelligence life cycle
begins with planning and setting the direction for what intelligence will be
collected and analyzed, as well as for what purpose. Objectives and
direction are derived based on Prioritized Intelligence Requirements
(PIRs), Prioritized Collection Requirements (PCRs), and Essential
Elements of Information (EEIs).
Collection

In response to the PIRs, PCRs, and EEIs, data collection can begin. Data
can be collected from several sources, ranging from humans to open source
and public locations, all the way to messaging apps such as Telegram.
Often, this data is collected both manually, by an analyst, and en masse, via
automated means. Data processing takes place after the data is gathered; it
should be stored, organized, and normalized in such a way that makes the
data easy to analyze. Since the collection phase typically ends up generating
a lot of data, the processing stage includes the systematic way to store
intelligence in a centralized location, such as a Threat Intelligence
Platform (TIP).
Analysis and production
After the data has been centralized in a standardized way, we begin the
process of analyzing and making the data into intelligence that is
deliverable in some format. For example, the analysis could include
deduplication, Admiralty scoring, pivots, and enrichment. Production could
include turning the intelligence into some sort of deliverable format, such as
a report for higher executives.
Dissemination and feedback
Finally, after the intelligence has been analyzed and produced, it should be
disseminated with feedback sought. Additionally, after a thorough review of
the intelligence, decision-makers will likely take actions based on the
intelligence. The entire process is then reviewed, and feedback is sought
from internal and external key stakeholders and consumers of the
intelligence.
Typically, using the threat intelligence life cycle in your organization is a
strategic decision, which when used in unison with the second, more
tactical life cycle, F3EAD, can be a great complement to adopt. Let's
examine the F3EAD life cycle in greater detail.
F3EAD life cycle

The F3EAD cycle is an alternative intelligence life cycle that can be
considered for application within a CTI organization. While this life cycle is
typically used in militaries worldwide involved in kinetic operations, the
F3EAD life cycle can just as easily apply to CTI. F3EAD is more tactical in
its approach, as opposed to the more strategic threat intelligence life cycle,
which can be viewed in six individual stages:
1. Find
2. Fix
3. Finish
4. Exploit
5. Analyze
6. Disseminate
When used in unison with the threat intelligence life cycle, both operational
and strategic objectives can be more holistically accomplished:

Figure 1.5 – The F3EAD life cycle
Now, let's examine Figure 1.5 in detail.
Find

The find stage is the who, what, when, why, and where of CTI. In this stage,
a tactical target of intelligence is defined, located, and collected. As an
example, an incident responder would find suspicious information across
several endpoints.
Fix
The fix phase effectively transforms the data and intelligence gained from
the find phase into evidence that can be used as a basis for action within the
next stage. An example of activity in the fix stage includes an incident
responder correlating multiple IOCs across a cluster of infected endpoints
within the enterprise.
Finish
The finish stage is the action phase. In this stage, an action is taken based
on the first two stages, find and fix. Let's use the preceding example: after
the incident responder isolates the suspicious endpoints that were grouped
together, they are taken offline and wiped.
Exploit
The exploit stage deconstructs the intelligence from the first three phases
and develops after-actions and next steps. An example of this stage includes
a malware reverser that statically reverses the engineering samples
identified on the infected endpoint by the incident responder. The malware
reverser can then assist in deploying organization-wide mitigation methods.
Analyze
The analyze stage is the fusion stage. It includes folding the intelligence
that has been identified into the broader web and context of intelligence. An

example of this would be the aforementioned reverse engineer entering
malware intelligence and data from reversing efforts into a TIP.
Disseminate
As the result of the previous stage, the results are disseminated to both
tactical consumers (for example, SOC) and strategic consumers (for
example, CISO). For example, this could include the malware reverse
engineer passing the isolated malware activity to the SOC for further
blocking across the organization.
When the threat intelligence life cycle and F3EAD are used in unison, like
two large cogs, the enterprise can truly benefit from each unique approach.
One way of visualizing these cycles working together includes looking at
both cycles as cogs in a larger threat intelligence cycle. The interfaces
between the threat intelligence life cycle and F3EAD are at the collection
and analysis phases and F3EAD's find and analyze phases.
While there are many intelligence life cycles that could be implemented
inside a CTI function, and there's no one-size-fits-all implementation, we've
shared two prominent models that are easily adaptable to CTI. In the next
section, we're going to examine a very important implementation
consideration: the maturity and hunting models.
Threat intelligence maturity,
detection, and hunting models
In the context of CTI, there are many maturity and hunting models for
organizations to consider. In particular, there are three maturity models that
are widely leveraged that will be discussed in this chapter. Each model
approaches different core problems using the Threat Intelligence Maturity
Model (TIMM) by looking at the organization's overall intelligence
maturity relative to a CTI program's adoption. Then, there's the threat
Hunting Maturity Model (HMM), which addresses and defines an
organization's hunting maturity rating. Finally, there's the detection maturity

model, which is used to address an enterprise's ability to detect malicious
behavior and will help an organization rate its attack detection capabilities
and relative maturity.
While not all organizations have the relative capabilities to hunt through
their data or have established CTI practices, it is important to rate and track
the maturity of your threat intelligence program, its detection capabilities,
and determine the organization's ability to hunt through data, if applicable.
TIMM
First published by ThreatConnect, the TIMM is intended to enable an
organization to rate the maturity of a CTI function within an enterprise.
Each level is distinct, starting at the least mature, or level 0, and going all
the way to the most well-defined CTI program at maturity level 4:
Let's examine each maturity level in detail:
Maturity level 0: Organization is unsure where to start.
Maturity level 1: Organization is getting accustomed to threat
intelligence.
Maturity level 2: Organization is expanding threat intelligence
capabilities.
Maturity level 3: Organization has a threat intelligence program in
place.
Maturity level 4: Organization has a well-defined threat intelligence
program.

Figure 1.6 – Maturity levels
Maturity level 0 – organization is unsure
where to start

Maturity level 0 is defined by an organization that doesn't have any threat
intelligence program or experience in threat intelligence. Usually, threat
intelligence programs start their life as threat collection programs.
Typically, at this level, the organization has no staff that is solely dedicated
to CTI, and it is likely that any staff dedicated to threat hunting is not
formalized in any fashion.
A great starting point to mature from level 0 includes collecting, storing,
and aggregating organizational log data from endpoints, servers, or any
connected device. Ideally, aggregation can occur in a systemic and
formalized way, such as with a Security Information and Event
Management (SIEM) tool.
Maturity level 1 – organization is getting
accustomed to threat intelligence
Maturity level 1 is when the organization starts becoming accustomed to
threat intelligence. Organizations at this level are typically starting to
understand the vast nature of the threat landscape. Organizations have basic
logging, with logs often being sent to a SIEM tool. Often, analysts suffer
alert fatigue due to the lack of resourcing, the lack of alert tuning, event
overloading, or a combination of all of those factors.
Analysts operating at level 1 will typically block and alert based on
triggered rule alerts from a system such as an Intrusion Detection System
(IDS), sometimes enabling analysts to perform rudimentary hunting.
Analysts at level 1 usually leverage a centralized SIEM. In level 1, analysts
are typically trying to tune alerts to make analysis more easily accessible.
From a human capital perspective, organizations at level 1 will sometimes
have limited cybersecurity staff performing threat hunting and intelligence.
While an organization rated as level 1 is still maturing and is reactionary in
its approach, a great starting point to mature from level 1 to level 2 includes
automating and tuning alerts in a SIEM or similar environment on top of
considering an additional headcount that's necessary for scaling a threat
hunting organization.

Maturity level 2 – organization is
expanding threat intelligence capabilities
Organizations finding themselves at maturity level 2 will find that they are
maturing in their CTI capabilities. Most often, level 2 is where you will see
organizations draw contextual conclusions based on the intelligence they're
generating. Typically, organizations operating at level 2 are collaborating to
build processes that can find even the most basic indicator's role in the vast
landscape of a criminal cyber attack, for example. To facilitate this level of
automation, CTI teams use scripts or a TIP.
Teams operating at level 2 will often find themselves ingesting data feeds
that are both internal and external from a litany of threat intelligence
providers and data. Teams at level 2 will often start the shift from a reactive
approach (for example, blocking indicators on a firewall from an active
incident) to a proactive approach (for example, proactively blocking
indicators from a high-fidelity enriched feed from a threat intelligence
provider). In many organizations, there might be one or two full-time
analysts dedicated to a CTI function.
Organizations looking to mature from level 2 to level 3 should be focusing
on security automation. Security orchestration should also be a focus area
during the maturation process within level 2. Both automation and
orchestration can be done in a combination of ways, including analysts
creating custom scripts and tools to help automate their key workflows. One
primary key to mature to level 3 includes the ability of the CTI team to
create their own intelligence.
Maturity level 3 – organization has a
threat intelligence program in place
Maturity level 3 is a level that many organizations won't reach, and that's
perfectly fine. Not all organizations will have the same level of funding and
resourcing available to achieve level 3. Maturity level 3 is defined by a

team of security analysts or threat intelligence analysts with semi-
automated workflows that are proactively identifying threat activity
possibilities. It is common for this team to have incident response and
forensics functionality in addition to CTI capabilities.
Processes and procedures have been thoroughly developed in level 3, and
analysts working in the CTI function are typically tracking malware
families, TAGs, and campaigns. A TIP is a commonplace finding at
organizations at maturity level 3, which gives analysts the capability to
store and analyze intelligence over a long period of time. Security
orchestration might be in place for level 3, but it is likely not fully
integrated into end-to-end security operations.
Workflows designed at level 3 should allow full intelligence integration into
a SOC, detection engineering, incident response, and forensics functions.
This enables these business functions to make proactive and reactive
decisions based on intelligence provided by the CTI team. Analysts should
focus on adding context to indicators identified as opposed to merely
focusing on individual indicators of maliciousness. This, in turn, is the
process of a level 3 maturity team creating their own intelligence versus
merely consuming others' intelligence. Analysts should find themselves
asking questions, such as what additional actions are related to this
indicator?
Organizations that are maturing from level 3 to level 4 should focus on
integrating orchestration, incident response, and intelligence enrichment
into all security operations. Businesses that have reached maturity level 4
should also focus on deriving strategic value from the threat intelligence
they're generating versus just tactical intelligence generation.
Maturity level 4 – organization has a well-
defined threat intelligence program
Maturity level 4 is a step that many organizations strive to achieve, but few
actually do. Due to a combination of funding, staffing, and inexperience,
many organizations struggle to reach level 4 maturity. Organizations at level

4 maturity have stable threat intelligence programs with well-defined,
formalized processes and procedures with automated and semi-automated
workflows that produce actionable intelligence and ensure an appropriate
incident response. Organizations operating within level 4 often have larger
organizational functions, with mature procedures to provide intelligence to
a litany of internal service owners, such as the organizational incident
response function.
Organizations in level 4 will continue using the TIP mentioned in previous
levels, with CTI teams beginning to build a security analytics platform
architecture that allows your analysts and developers to build and run their
own tools and scripts tailored to the unique organizational requirements.
Teams operating at level 4 utilize automation as much as possible, such as
leveraging the API feeds of a targeted attacker activity that's automatically
ingested into a TIP. The CTI analyst can vet the intelligence and pass it to
security operations for blocking.
A primary differentiator in level 4 is the amount of organizational buy-in
for CTI functions. CTI functions at level 4 enable business decisions at the
highest levels, including both strategic decisions and tactical decisions.
Now that we've covered the TIMM, let's examine an additional model to
consider for implementation: the threat HMM.
The threat HMM
Organizations are quickly starting to learn the importance and benefit of
threat hunting. The best foundation for beginning threat hunting is to follow
a standard model that not only measures maturity but also ensures a
systematic process is being followed by analysts themselves. Before we can
discuss the concepts related to the threat HMM, first, we need to approach
the question of what is threat hunting?
Threat hunting can be best described as the process of proactively and
systematically hunting through organizational logs to isolate and understand
threat activity that evades an enterprise's compensating security controls.
The tools and techniques that threat hunters employ are often varied, with

no single tool being the silver bullet. The best tool or technique almost
always depends on the threat the analyst is actively hunting.
It is important to note that hunting is most often done in a manual, semi-
automated, or fully automated fashion, with the distinct goal of enabling
detection and response capabilities proactively by turning intelligence into a
detection signature.
The threat HMM was developed by David Bianco and describes five key
levels of organizational hunting capability. The HMM ranges its levels of
capability from HMM0 (the least capable) to HMM4 (the most capable):
Let's examine each HMM level.
HMM0 – initial
The first level is HMM0, which can best be described as an organization
that relies primarily on automated alerts from tools such as IDS or SIEM to
detect malicious activity across the organization. Typically, organizations in
HMM0 are not capable of hunting through their enterprises proactively.
Feeds may or may not be leveraged in HMM0, and they are typically
automatically ingested into monitoring systems, with little to no enrichment
applied. The human effort in HMM0 would primarily be to resolve alerts
generated from detection tools.
Data sourcing in HMM0 is usually non-existent or limited, meaning that,
typically, organizations do not collect much in terms of data or logs from
HMM0: Initial
HMM1: Minimal
HMM2: Procedural
HMM3: Innovative
HMM4: Leading

their enterprise systems, severely limiting their proactive hunting
capabilities.
HMM1 – minimal
An organization operating in HMM1 still primarily relies upon automated
alerting to drive its detection and response capabilities and processes.
Organizations in HMM1 are primarily differentiated by their sources of
collection. In HMM0, we learned that organizations had limited internal
data sources (for example, endpoint logs), with no structured way of
looking through those logs. HMM1 organizations find themselves
collecting, at the very least, a few types of data from across the enterprise
into a central collection point, such as a SIEM.
Analysts in HMM1 are able to extract key indicators from alerts and reports
and search historical data to find any recent threat activity. Because of this
search capability and limited log collection, HMM1 is the first level where
true threat hunting happens despite its limited nature.
HMM2 – procedural
Organizations in HMM2 find themselves with the capability to follow
procedures and processes to perform basic hunting across enterprise
datasets (for example, endpoint logs). Organizations in HMM2 often collect
significantly more data from across the enterprise, such as firewall logs,
endpoint logs, and network infrastructure logs.
It is likely that organizations in HMM2 won't have the maturity to define
new workflows or processes for themselves, but they are capable of hunting
both historically and, in some cases, proactively.
HMM2 is typically the most common level witnessed among organizations
that employ active programs.
HMM3 – innovative

Many hunting procedures found throughout enterprises focus on the
analysis techniques of clustering similar behavior (for example, detecting
malware by gathering execution details such as Windows Registry
modifications and clustering activities identified elsewhere across the
enterprise). Enterprises in HMM3 find themselves not only proactively
hunting through a litany of internal log data sources, but they are also
performing a grouping and clustering of activity. This clustering or
grouping of activity involves identifying similar clusters of threat activity to
proactively block, monitor, or further assess. Additionally, organizations
operating in HMM3 often have highly skilled threat hunters who are adept
at identifying nefarious activity across information systems or networks.
Typically, analysts in HMM3 leverage grouping and clustering to identify
new threat activities that are bypassing traditional security controls.
Analysts performing in HMM3 can identify nefarious activity while sorting
through a needle in a haystack. Traditionally, automated alerts are highly
tuned, with very little noise being produced.
As the number of hunting workflows and processes develops and increases,
scalability issues that might pop up will be solved in HMM4.
HMM4 – leading
Enterprises in HMM4 are leading the way in terms of defining procedures
that organizations in HMM0–HMM3 generally follow. Organizations in
HMM4 are advanced in terms of log collection, alert tuning, and the
grouping/clustering of malicious activity. Organizations in HMM4 have
well-defined workflows for detection and response purposes.
Automation is heavily employed in HMM4, clearly differentiating it from
HMM3. Organizations in HMM4 will convert manual hunting methods
(such as pulling WHOIS information for a domain being used as part of C2
infrastructure) into automated methods (such as automatically enriching
domain intelligence with WHOIS information). This automation saves
valuable analyst time and provides the opportunity for analysts to define
new workflows to identify threat activity throughout the enterprise.

The detection maturity model
Ryan Stillions published the Detection Maturity Level (DML) model in
2014, but it is still useful today to measure organizational maturity. At its
core, DML is a detection model intended to act as an assessment
methodology to determine an organization's effectiveness of detecting threat
activity across information systems and networks. DML is used to describe
an organization's maturity regarding its ability to consume and act upon
given CTI versus assessing an organizations' maturity or detection
capabilities.
It's important to note there is a distinction between detection and
prevention. As its name implies, the detection maturity model deals directly
with detection versus prevention.
The DML consists of nine maturity levels, ranging from eight to zero:
The lowest of these levels is the most technical with the highest being the
most technically abstract, disregarding level zero, of course.
Let's examine the detection maturity model in greater detail.
DML-8: Goals
DML-7: Strategy
DML-6: Tactics
DML-5: Techniques
DML-4: Procedures
DML-3: Tools
DML-2: Host and network artifacts
DML-1: Atomic indicators
DML-0: None or unknown

DML-8 – goals
Being the most technically abstract level, determining a threat actor's goals
and motivations is often difficult, if not impossible, in some circumstances.
The threat actor could be part of a larger organization that receives its goals
from a source higher up in the operation. Additionally, the goals might not
even be shared with the individual that has a hands-on keyboard. If the
goals are criminal in nature, it is often hard to determine the motivation of
the attacker.
In some cases, goals are easy to determine, such as ransomware, which,
typically, has a very clear motivation and goal. Many times, determining a
goal is merely guessing at what the attacker's true goals were based on the
behavior and data observations of lower DMLs (for example, stolen data,
targeted victims, and more).
DML-8 is, typically, what C-level executives are most often concerned
with, with who did this, and why? being an extremely common question
when called into a board room.
DML-7 – strategy
DML-7 is a non-technical level that describes the planned attack. Usually,
there are several ways an attacker can achieve its objectives, and the
strategy determines which approach the threat actor should follow. Threat
actor strategies vary based on goals and intent, such as a shorter-run
criminal attack. Determining a threat actor's strategy is often partially
speculative in nature, with observations drawn from behavioral and data
observations over a period of time. A good example of this type of
observational information being built over time includes the threat actor
known as Sofacy. Sofacy has been tracked for years throughout the security
industry, with new and unique attacks and new tool development occurring
routinely. Watching this actor evolve over time can help inform an analyst
of the attacker's intent, but without evidence, there is a degree of estimation.

Random documents with unrelated
content Scribd suggests to you:

50
32)1216800(38025
96
256
256
80
64
160
160
and √38025 = 195 Ans.
As the diameters of yarns vary as the square root of their counts,
it follows that the diameters will always bear a certain relation to the
yards in 1 lb. If this relation is once obtained, it becomes easy to
calculate the diameter of any yarn on this principle.
Taking the diameter of a 32’s yarn from the table, viz. 156, it will
be found that this is equal to the square root of the yards in 1 lb.,
less 5 per cent.
Example.
840
32
1680
2520
26880 yds. in 1 lb. of 32’s.
√26880 = 164
8 = 5 per cent.
156 = diameter of 32’s.
The number of ends and picks per inch required to make plain
cloths of equal firmness from different counts may be at once seen
from the table of diameters, as one-half the number given as the
diameter is required.
Thus if a plain cloth with 78 threads per inch of 32’s is taken as
the standard, and it is required to make a cloth of equal firmness,
with 60’s yarns, the number of threads per inch required would be

106½. In 20’s yarns about 62 threads would be required. In 16’s
yarns 55 threads per inch, and so on.
In twills, or other regular weaves, the following rule will give the
number of threads per inch required of any count:—
Rule.—As the sum of the ends and intersections in the pattern is
to the ends, so is the diameter to the number of threads required.
Example 1.—How many threads per inch are required to make a perfectly
balanced “2 and 1” twill cloth, with 24 yarns, warp and weft?
There are 3 ends and 2 intersections in the pattern; therefore
3 ends + 2 intersections = 5;
and as 5 : 3 ends 135 diameter : x
3
5)405
81 threads per inch required.
Example 2.—How many threads per inch are required to make a perfectly
balanced “3 up, 2 down, 2 up, 2 down twill” with 44’s yarns?
In this pattern there are 9 ends and 4 intersections; therefore
as 9 + 4 : 9 183 diameter of 44’s : x
or, as 13 : 9 183
9
13)1647(126 threads per inch required
13
34
26
87
78
9
One of the most useful purposes to which a knowledge of this
principle can be put is in changing the weave of a fabric, to find the
threads per inch of a given count of yarn required to keep the same
firmness as in a sample cloth.
It must be remembered that the word “firmness” is here used as
implying that the space between the threads bears the same relation

to the diameters of the threads in both cases, or, if the given cloth is
perfect, the proposed one will also be perfect.
Suppose it is desired to make a “two and two” twill of the same
“firmness” as a plain cloth made with 103 threads per inch.
The yarns being the same, the number of threads per inch
required will be as the ends plus intersections in a given number of
ends in both patterns.
In the above question the given cloth is plain, with 103 threads
per inch, and the proposed cloth is a “two and two” twill. Taking the
same number of threads in each case, we get—
Ends + Intersections in
proposed twill cloth.
Ends + Intersections
in given plain cloth.
4+2 : 4+4 103 : x
or 6 : 8 103
8
6)824
Ends required in twill cloth = 137⅓
It must not be forgotten that it is necessary to take an equal
number of ends of each pattern in this class of calculation. In more
complex patterns it is often advisable to take the number of ends
which is the L.C.M. of the ends in the two patterns in order to get a
complete number of intersections in each case.
Another Example.—If a “two and two” twill cloth is made with 137 threads per
inch, and it is proposed to make a cloth with the same counts of yarns in a “5 up,
2 down, 1 up, 2 down” twill, how many threads per inch are required to keep the
same firmness?
In 40 ends of the proposed cloth there are 16 intersections, and in 40 ends of
the sample cloth there are 20 intersections.

Then as 40 + 16 : 40 + 20 137
or 56 : 60 137
60
56) 8220 (146·8 threads. Ans.
56
262
224
380
336
440
If it is required to make a cloth with the same number of threads
as a sample cloth, and to change the pattern and keep the same
firmness, it is necessary to change the counts on the following
principle:—
Rule.—As the sum of the ends and intersections in the sample
cloth is to the sum of the ends and intersections in the proposed
cloth, so is the square root of the counts in the sample to the square
root of the counts in the proposed cloth.
Example.—If a plain cloth has been made with 36’s yarns, and it is proposed to
make a “two and two” twill with the same number of threads per inch, find the
counts required to keep the same “firmness.”
Ends + Inters.
in sample cloth.
Ends + Inters.
in proposed cloth.
or 4 + 4 : 4 + 2 √36 : √x
8 : 6 6 :
6
8)36
4½
And 4½2 = 20·25 counts required.
This may be proved correct by referring to the table of diameters
on page 335, where it will be seen that a plain cloth with 82½
threads per inch of 36’s is “perfect,” and a “two and two” twill with
82½ threads of 20¼’s counts is equally perfect.

To change the Counts, the pattern and threads per inch
remaining the same.
If a sample cloth has 78 threads per inch of 32’s yarn, and it is
proposed to make a cloth of the same weave with 55 threads per
inch, what counts of yarn are required to keep the same “firmness”?
This is simple enough. The diameters of yarns vary as the square
root of their counts, and therefore as the threads in one cloth are to
the threads in another, so will the square root of the counts in one
be to the square root of the counts in the other.
Threads in
sample.
Threads in
proposed cloth.
Counts in
sample.
78 : 55 √32 : √x
or as 782 : 552 32
6084 : 3025 32
32
6050
9075
6084) 96800 (15·91, or 16’s nearly = counts required
6084
35960
On referring to the table of diameters (p. 335), it will be found
that a plain cloth with 78 threads of 32’s is “perfect,” and that a plain
cloth with 55 threads of 16’s is also perfect. Therefore the above
calculation is correct.
To change the Threads per Inch, the counts and
pattern remaining the same.
If a sample has 78 threads per inch of 32’s, and it is proposed to
weave a cloth of the same pattern, but with 60’s yarns, find the
number of threads per inch required to keep the same firmness.
This is simply a continuation of the previous statement.

If the two counts are known, the number of threads will vary as
the square roots of the counts; thus—
Counts in sample. Counts in
proposed cloth.
Threads in sample.
√32 : √60 78 : x
or as 32 : 60 782 : x2
6084
60
32)365040
11407½
√11407 = 106.8 threads required.
The above may be proved correct by referring to the table of
diameters. A plain cloth with 78 threads per inch of 32’s is “perfect,”
and so is a plain cloth with 106½ threads per inch of 60’s.
The same principle must be employed if the warp and weft are of
different counts, or if the threads per inch are not equal in warp and
weft.
Example.—A sample cloth is made with 78 ends per inch of 32’s and 91 picks
per inch of 44’s. How many picks will be required to keep the same firmness, if the
weft only is changed to 60’s?
Counts in sample. Counts in
proposed cloth.
√44 : √60 91 : x
or as 44 : 60 912 : x2
8281
60
44)496860
11292 = x2
and √11292 = 106½ ∴ picks per inch required = 106½
One advantage gained by a knowledge of the principle of cloth
“balance” is that the number of picks per inch which a given pattern
or weave will take can easily be obtained by calculation. This is of
great advantage to designers for Jacquard weaving, as it often

occurs that a design is made and the cards cut for a pattern which
will not admit of the required number of picks of the given counts
being put in the cloth, which a slight alteration in the ground weave
would have rendered possible.
To alter the Weight.—If the weight of a cloth is required
to be altered, and the same firmness kept, the threads per inch and
counts can be found on the same principle.
If a cloth is made heavier it must be done by using coarser yarns
and fewer threads; it cannot be done by using more threads, and
preserve the same “firmness” or “perfection.”
Suppose a sample piece of cloth weighing 10 lbs. is made with
93 threads of 45’s, and it is proposed to make a piece of the same
length and width, but weighing 15 lbs. To find the threads per inch
and counts of yarn to keep the same firmness.
The weights of two cloths will vary as the square roots of the
counts if they are of the same perfection.
Therefore—
Weight of
proposed cloth.
Weight of
sample.
As 15 lbs. : 10 lbs. √45 : √x counts
or 152 : 102 45 to x
225 : 100 45
100
225)4500(20’s counts required
450
0
To find the threads per inch required of the above counts—

Weight of
proposed cloth.
Weight of
sample.
15 : 10 93
10
15)930(62 threads required.
90
30
30
Then to make a piece of the same perfection or firmness as the
sample piece, and to alter the weight from 10 lbs. to 15 lbs., the
counts must be changed from 45’s to 20’s, and the threads per inch
from 93 to 62.
To prove this is correct take a piece 20 inches wide, 102 yards
long, 93 threads per inch both in warp and weft of 45’s yarns.
The weight of this sample piece will be—
20 × 102 × 93
840 × 45
= 5 lbs. of twist;
and as there is the same weight of weft, the total weight of the
piece will be 10 lbs.
Now calculate the weight of a piece of the same length and width
with 62 threads per inch of 20’s yarns:—
20 × 102 × 62
840 × 20
= 7½ lbs. of twist;
and with the same quantity of weft, the total weight of the piece will
be 15 lbs.
This proves the calculation to be correct so far as altering the
weight goes.
To see if both cloths are of the same firmness, the table of
diameters may be referred to. It will there be seen that a plain cloth
with 93 threads per inch of 45’s yarn is “perfect,” and also that the
altered cloth with 62 threads of 20’s is equally perfect.

It thus proves the principle of the calculation to be correct.
A lighter cloth may be made, and the same firmness kept. The
formula is the same in both cases. If a cloth is made lighter it must
be done by using finer counts and more threads. It cannot be done
by using fewer threads, as the firmness could not be kept and the
required weight obtained.
In altering the weights of cloths some allowance would have to
be made for the difference in milling-up with different counts of
yarns and numbers of threads. If a cloth is made heavier, thicker
yarns would be used, and the warp length to give a certain length of
piece would be different in the sample to the altered cloth. But this
is a comparatively small matter, which can be adjusted with a slight
alteration in the basis of the structure.

INDEX
ANTISEPTICS, 32
Automatic looms, 198
BACKED cloths, with weft, 255;
with warp, 257
Barley-corn patterns, 235
Beaming, press, 47
—— tension, 47
Beating up the weft, 72, 85
——, character of motion in, 72, 73
——, distance moved by slay whilst the crank moves through
given
angle in, 74
——, eccentricity of slay’s movement in, 72;
cause of, 74
——, effect of altering position of crank-shaft in, 83;
of reversing direction of crank in, 84
——, force of slay in, 78, 82
——, position of crank in, 72
Becks, size mixing, 30

Brake, 95
CALCULATION for two or more fold yarns, 308
—— of contraction for different weaves and counts, 326
—— of cost of a piece, 325
—— of counts of yarn from weighing given length, 329
Calculation of diameter of yarn, 336
Calculation of number of threads of given counts required to
make a
firm cloth in any weave, 341
—— of quantity of warp and weft in a piece, 311–313
—— of reeds and setts, 310
—— of weaving wage, 324
—— of weight of a given length of any counts, 330
—— to make a cloth of equal firmness to given cloth when
changing
weave, 338
—— to preserve firmness and alter weight, 343
—— to preserve firmness when changing threads per inch, 341
—— to preserve same firmness when changing counts, 341
Card-cutting machine, 190
—— repeater, 191
Casting out, 285
Checks produced by re-arranging twills, 241
Circular-box motion, 115
Clearer guide, 8
Clipped or sheared cloths, 254

Coiling motions. _See_ Taking-up
Combined twills, 226
Cop winding machine, 6
Cording plan for hand loom, 50
Cords, 245
Corkscrew twills, 257
Counts of cotton yarns, 307
Counts of two or more unequal threads twisted together, 308;
and weight of each required in given weight of resulting
thread, 309
Cover on cloth, 86, 87
Crapes, 248
Crimp cloth, 249
DAMASK or twilling Jacquards, 168–172
Design, transferring from sketch to point paper, 281
Detached figures, spots, arrangement of, 278–281
Development of pattern, 282–285
Diagonals, fancy, produced by combining unequal twills, 240
—— figured, 289
Diameters of cotton yarns, 335
Diapers, 233
Dice checks, 234
Direction of twist in yarns, effect of, 304
Dobbies, timing of movements in, 129
—— undermotions for, 130, 131

Dobby, the Blackburn, 127;
knife motion for, 127;
character of shed in, 129
——, the Keighley double-lift, 123;
method of pegging for, 126;
double jacks in, 126;
character of shed in, 125;
made positive, 129
Double cloths, 259
—— bound by passing back pick over face end, 261
—— bound by passing back end over face pick, 262
—— plain clothes, figuring, 263;
bound together, 266
—— shed Jacquard, 157
—— twill cloth figuring, 300
—— warp face, 257
Double weft face, 255
Double-beat slay, 135
Doup heald, 173
Draft, arranging on point paper, 227
—— the V, 230; patterns produced by, 230–233
Drawing-in, 3
Drills, 224
Drop-box motion, Diggle’s, 107
—— in pick-and-pick loom, 116;
connected to Jacquard, 120
—— Whitesmith’s, 112
—— Wright Shaw’s, 109

Drum winding machine, 13, 14
EDLESTON harness, 166
—— —— designing for, 294
Extra warp, figuring with, 250;
reeding of, 252
—— —— and extra weft combined, 255
—— weft, figuring with, 252
—— figure on mock leno ground, 254
FANCY effects produced by warp and weft pulling each other out
of
straight line, 249
Fast reeds, 91
Figured design, 278
—— leno designing, 295
Firmness of cloth, 333
GAUZE, plan of, 173
“Gloy,” 33
Grey warps, preparation of, 2
HAND-LOOM, 48
Hattersley weft-replenishing device, 214
Heck of warping mill, 22
Honeycomb designs, 242
Huck patterns, 250

JACQUARD card cutting, 142, 190
—— damask or twilling, 168–172
—— damask, Tschorner and Wein, 172
—— double-shed, 157
—— for cross-border, 155
—— for leno weaving, 181
—— harness, bordered pattern, Norwich tie, 151;
London tie, 153
—— centre pattern or point tie, 154
—— Edleston’s, 166;
designing for,167, 294
—— for all-over pattern, 139
—— London tie, 150
—— Norwich tie, 144, 150
—— machine, origin of, 137
—— sizes of, 150
—— difference in character of shed between single and
double-lift, 137, 144–148
—— double-lift, single-cylinder, 144;
principle of, 145
—— double-lift, double-cylinder, 146;
advantages of, 144
—— single-lift, 138
—— open-shed, 158
—— pressure harness, 161–166
—— split harness, 160
Jeans, jeanettes, 220

KEIGHLEY dobby, 123
Kenyon’s undermotion for dobbies, 131
LACE and leno stripes, 269
Lags, pegging of, 126
Lappet loom, 193
—— wheel, construction of, 195
Lappets, 192
Leno checks, 268
—— crossovers, 175
Leno effects, 266
—— full cross, 181
—— Jacquards, designing for, 185
—— double-lift, 186
——, imitation of, 186
—— net or lace, 176
—— selvedge, 132
—— weaving in dobbies, 174–180;
use of slackener in, 174;
arrangement of staves and pegging plan, 175–178;
shaking motion for double-lift dobbies, 178;
arrangement of slackeners for two doups, 180
Letting-off, 106
Linen yarns, counts of, 307
List of prices for weaving, New Uniform, 314–322;
Chorley, 322
Loose reeds, 92

MARKING mechanism in slashing frame, 35
Marseilles quilts, 298
Mildew, 32
Mitcheline, 299
Mock lenos, 243
Mono-coloured warps, preparation of, 3
Multi-coloured warps, preparation of, 5
NET lenos, 267
Northrop weft-replenishing device, 210
OSCILLATING tappets, 61
PADDED cloths, 258
Patterns produced by combining alternate picks of twills, 240
—— by combining equal twills, 226;
unequal twills, 240
—— by drafting, 227
Patterns by fancy drafts, 238
—— by re-arrangement of simple twills, 236;
and of combined twills, 237
Pegging plan making, 228
Pick-and-pick loom, 116
Pick, force of, 69
Picking, over pick, 68, 69
—— under pick, 71

Pile fabrics, warp, 189
—— weft, 270–277
Piqués, 258
Pirn winding machine, 15
—— —— —— disc, 17
Plain cloth, 218
—— draft for weaving, 219
—— number of threads possible in, 218
—— ornamentation of, 218
Plushes, 189, 275
Point draft, 230
Point paper, selection of, for different proportions of warp and
weft, 290
—— use of, 219
Power-loom, tappet shedding motions in, 51–68
Preparatory processes, 1
Presser roller, expanding, 27
Pressure harness, designing for, 292
—— harnesses, 161–166
Primary movements in weaving, 48
—— timing of, 85–87
Protector, loose reed, 91
—— stop rod, 92
REEDS and setts, 310
Ribs and cords, 245

Roller top motion for plain cloth, 62;
3 staves, 64;
4 staves, 64;
5 staves, 65;
7 staves, 66
SACK weaving, 259
Satin draft, 229
—— weaves, 222
Satin, principle of construction of, 224
Scotch dressing, 42
Section blocks, expanding, 27
—— tappets, Woodcroft’s, 59, 60
Sectional warping, 23
Selvedge motion in sateen loom, 134, 135
Set figures, arrangement of, 278–281
Shading, 283
Shedding motions, power-loom, 51–68
Silk yarns, thrown or net, numbering of, 307
Sines and cosines, table of, 81
Singleton’s stop-motion, 19
Size mixing, 28
—— —— for light sizing, 30
—— —— for fine counts, 31
—— —— for medium sizing, 31
—— —— for heavy sizing, 32
Sizes of patterns woven in Jacquards, 285

Sizing, 28
—— ball, 43
—— materials, 28
——, slashing frame, 33;
slow motion in, 37
—— frame, slasher, marking motion in, 35, 36
—— —— frictional winding motion in, 39
—— machines, hot air drying in, 38
—— ——, automatic supply of size to, 40
Slubbings, 8
Solid coloured borders in dhooties, 303
Split harness, designing for, 292
Splits, motion for, 132
—— Shorrock and Taylor’s motion for, 133
Spreading the warp, 85
Spun silk yarns, counts of, 307
Stitching-thread used to bind extra warp and extra weft, 252,
253
Stocks and bowls, 67
Stop motion, weft fork, 93
—— ——, in beam-warper, 19
—— rod, 92
Striped designs, 288;
calculation of reed for, 288
TABBY weave, 218

Taking-up motion, negative, 101;
screw and worm wheel, 103
—— positive, 95;
Pickles’, 99;
new system, 104
Tappets, calculation for lift of, 52
——, construction of, 53
——, effect of treadle-bowl on, 57
—— for plain cloth, 50, 51, 53
—— for twills, 56, 58
—— oscillating, 61
—— positive, 59
——, speed of, 87–91
—— Woodcroft’s, 59
Terry cloth, 187
—— loom, 187
Testing yarns, 329
Three-ply, four-ply cloths, 263
Toiletings, 297
Traverse motions, heart cam, 9, 10;
mangle wheel, 11 cloths, 258
Trial section, 25
Twaddell’s hydrometer, 30
Twills, 219
—— combined, 226
Twisting-in, 3

Twofold yarns, cotton, worsted, silk, 308
UNDERMOTIONS, 130, 131
Undermotion, Kenyon’s, 131
V-CREEL, 18, 23
V-reed, 24
Velvet, common, 270
—— cords, 276
—— E1, 273
—— fast pile, 273
——, figured, 301
—— twill back, 274
Velvets, velveteens, 270, 277;
definition of, 272
WARP line, 85
Warping, beam, 18
Warping mill, 21
——, sectional, 23
Weaving wage calculations, 324
Weft, preparation of, 6
——, wet, 6
—— fork, 93
—— pile fabrics, 270
Weft-replenishing devices, automatic, 198–217

—— ——, patents for, 209
—— ——, Northrop, 210
—— ——, Hattersley, 214
Winding coloured yarn, 14
—— drum, 14
—— from cops to warpers’ bobbins, 6
—— from ring spools to warpers’ bobbins, 6
—— from throstle to warpers’ bobbins, 6
Woodcroft’s section tappets, 59, 60
Worsted yarns, 307
Wrapping yarn, 330
YARN balance, Staub’s, 331
—— twist of, 305
Yorkshire dressing, 5, 47
THE END
PRINTED BY
WILLIAM CLOWES AND SONS, LIMITED
LONDON AND BECCLES

*** END OF THE PROJECT GUTENBERG EBOOK COTTON WEAVING
AND DESIGNING ***
Updated editions will replace the previous one—the old editions
will be renamed.
Creating the works from print editions not protected by U.S.
copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.
START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK
To protect the Project Gutenberg™ mission of promoting the
free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.
Section 1. General Terms of Use and
Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.
1.B. “Project Gutenberg” is a registered trademark. It may only
be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.
1.E. Unless you have removed all references to Project
Gutenberg:
1.E.1. The following sentence, with active links to, or other
immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project

Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:
This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and
with almost no restrictions whatsoever. You may copy it,
give it away or re-use it under the terms of the Project
Gutenberg License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country
where you are located before using this eBook.
1.E.2. If an individual Project Gutenberg™ electronic work is
derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.
1.E.3. If an individual Project Gutenberg™ electronic work is
posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.
1.E.4. Do not unlink or detach or remove the full Project
Gutenberg™ License terms from this work, or any files

containing a part of this work or any other work associated with
Project Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute
this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.
1.E.7. Do not charge a fee for access to, viewing, displaying,
performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.
1.E.8. You may charge a reasonable fee for copies of or
providing access to or distributing Project Gutenberg™
electronic works provided that:
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Operationalizing Threat Intelligence 1 Converted Kyle Wilhoit

More Related Content

Similar to Operationalizing Threat Intelligence 1 Converted Kyle Wilhoit (20)

Recently uploaded (20)

Operationalizing Threat Intelligence 1 Converted Kyle Wilhoit