82-10-41 Identifying Information Security Threats

Previous screen
Timothy R. Stacey
Ronald E. Helsley
Judith V. Baston
Payoff
The success of an enterprises information security risk-based management program is
based on the accurate identification of the threats to the organization's information systems.
This article presents a structured approach for identifying an enterprise-specific threat
population, which is an essential first step for security planners who are involved in
developing cost-effective strategies for addressing their organizations' information security
risks.

Introduction
In a compliance-based information security program, the information systems are designed
and required to comply with a pre-determined, comprehensive set of security controls.
Recently, it has been shown that this type of security program leads to the incorporation of
expensive safeguards, some of which may be irrelevant to todays changing information
system architectures and threat populations. Simply, an enterprise will waste significant
money on the implementation of inappropriate security controls because it uses a
compliance-based information security program. The government has recognized this area
of potential waste and has mandated that government information systems institute risk-
based information security programs.
The migration from a compliance-based to a risk-based information security program
shifts the responsibility to and places a significant additional burden on the local security
practitioner. The adoption of a risk-based information security program requires the
enterprise to become cognizant of the threats to its information systems and to respond with
safeguards and protection mechanisms appropriate to its set of threats. In addition, the
enterprise must continually review its security posture because of changing technologies
and the dynamic threat population. Thus, it is critical that the enterprise adopt a structured
methodology to determine the pertinent threats, to re-evaluate residual vulnerabilities, and
to identify new threats.
In the NASA community, government directives, such as the Office of Management
and Budget Circular A-130, and NASA Agency directives have placed the responsibility
for the cost effective protection of information systems directly with the “owners”(i.e.,
managers) of the facilities. To provide guidance and support, the NASA centers have
provided security handbooks, such as Johnson Space Centers Automated Information
Systems Security Manual, JSCM-2410.11. These handbooks mandate sets of security
requirements that, if implemented, provide “...a common and adequate baseline ...” and
“... provide adequate AIS security protection, meet the intent of Federal and Agency
guidelines, and be consistent with good business practices.”

The Changing Role of the Information Security Practitioner

In a cost-containment era, it is the information security officers responsibility to ensure that
the information systems are protected adequately, yet cost effectively. The security
practitioner is now responsible for accurately assessing the current risk levels and, when
necessary, recommending cost effective risk reduction strategies. The security practitioner
can also be held liable for failure to exercise due diligence in protecting the systems. To
 perform these tasks, the security practitioner must understand the threats to the
Previous screen
organizations's information systems.

Five High-Level Threat Categories

For the past several years, information systems professionals at Rockwell Space
Operations have employed a set of five high-level threat categories:

· Personnel and administrative.

· Network.

· Hardware.

· Software.

· Environmental and physical security.

Within these categories, 21 threats were identified, which were used in weighing the
security posture of the information systems as illustrated in Exhibit 1. From that point,
approximately 450 recommended safeguards were keyed to those threat categories.
Information systems personnel were interviewed to determine their systems level of
compliance to the recommended safeguards. Based on the five threat categories, a security
posture was subjectively determined, additional safeguards to be implemented were
identified to reduce risk, a management-level briefing was prepared, and all findings were
presented.

Legacy Threat List

Threat Category Threat

Personal/Administrative Threat Terroist Actions/Civil Disorder
Activity for Personal Gain
Malicious Acts by an Individual Employee
Tampering with or Destruction of Hardware And/or Related Components
Theft of Hardware and/or Related Components
Theft of Resources
Network Threat Essential Communication Line/Equipment
Failure
Masquerading as an Authorized User
Sniffing
Spoofing
Wiretaping or Eavesdropping
Hardware Threat Essential Hardware Failure
Software Threat Programmer/Operator Error
Essential Software Failure
Malicious Software Invasion
Unauthorized access or Execution Privileges
Environmental/Physical Security Threat Theft or Equipment Tampering
Loss of stable Electrical Power
Facility or Equipment Fire
Natural Disaster
Temperature/Humidity Extremes
Previous screen
Threat Category Threat

Personal/Administrative Threat Terrorist Actions/Civil Disorder

Activity for Personal Gain
Malicious Acts by an Individual Employee
Tampering with or Destruction of Hardware
And/or Related Components
Theft of Hardware and/or Related Components
Theft of Resources

Network Threat Essential Communication Line/Equipment

Failure
Masquerading as an Authorized User
Sniffing
Spoofing
Wiretapping or Eavesdropping

Hardware Threat Essential Hardware Failure

Software Threat Programmer/Operator Error

Essential Software Failure
Malicious Software Invasion
Unauthorized access or Execution Privileges

Environmental/Physical Security Theft or Equipment Tampering

Threat Loss of stable Electrical Power
Facility or Equipment Fire
Natural Disaster
Temperature/Humidity Extremes

However, working with the five threat categories raised areas of concern. Although a
quasi-analytical approach in determining the perception of a systems security posture was
attempted, the analyses became increasingly subjective. In reviewing the list of threats,
several anomalies were noticed, which could have questioned the validity of the overall
findings. The specific areas of concern included:

· The threat categories were composed of a differing number of threats (i.e., personnel
and administrative had six threats, software had four threats, and hardware had only
one threat).

· The level of detail of the threats seemed too uneven (e.g., masquerading as an
authorized user versus activity for personal gain).

· Some common threats appeared to be missing (e.g., personnel losses).

· Most of the recommended safeguards mapped to the same threat category (i.e., the
majority mapped to personnel and administrative).

· The number of safeguards recommended (and mapped) to the threat categories was
vastly different between threat categories (i.e., personnel and administrative had 254
recommened safegaurds, software had 149 recommended safeguards, and hardware
had 123 recommended safeguards).

· The categories seemed to be composed of threats with vastly different anticipated

frequencies.
 Thus, a complete and balanced list of the threats from which the information systems
Previous screen
could be protected must be developed. This article describes the process, in step form, used
to formulate an enterprises threat list.

Step 1—Define Terms For Consistency

To identify the threat population, the terms: threat, threat agent, and threat event must be
consistently defined. Threat can be defined in several ways, including: the potential for
harm; any circumstances or set of circumstances with the potential to cause harm to an
automated asset; or an event or method that can potentially compromise the integrity,
availability, or confidentiality of automated information systems. The process described in
this article uses the last definition.
A threat agent is an individual or entity, real or perceived, that may initiate, enhance, or
otherwise support a threat occurrence. Derived, from the preceding definitions, a definition
of a threat event is the manifestation of a threat. Simply, a threat becomes the “what” (i.e.,
what can potentially compromise an automated information system?). The threat agent
becomes the “who” (i.e., who can cause the automated information systems to be
compromised?). Finally, the threat event becomes the “how.” For example, if a threat is
exercised by an agent, how, by what mechanism exactly, will the automated information
systems be compromised? Using the preceding definitions, the task of identifying the threat
population can begin. Exhibit 2 illustrates the first attempt of creating a comprehensive
threat list. This list should be made up of these elements:

· The list should contain a limited number of threats (i.e., between six and 12 to facilitate
management-level presentations).

· The list should use access permission as a major criterion (i.e., insider versus badged
outsider versus outsider).

· The list should use motivation as a criterion (i.e., malicious versus accidental).

Although the threats noted in Exhibit 2 comply with the previously discussed
definitions of threat, these observations are also evident:

· Some of these threats appear too general (e.g., theft, hardware failure, and software
failure), and others seem too specific (e.g., unauthorized access to files by an insider).

· The list seems incomplete (e.g., power failure or fluctuation and sniffing appears to be
missing).

· A single threat has several threat agents (e.g., disaster may have been caused by natural
or human actions).

· Some threats could be manifested in many, seemingly contradictory ways, requiring

vastly differing protections (e.g., unauthorized access to the system by an outsider
could result from trespassing and obtaining physical access--tampering or physically
damaging--to system assets, trespassing and obtaining system access by logging-on
from within the facility, access across a network, and access by a dial-in modem).

After reviewing the threat list for the first time, the following should be reconsidered:

· The treat agents.

 · All the differing ways in which a threat may be manifested.
Previous screen
· All the prime safeguards for the prevention, detection, and recovery for each type of
threat manifestation.
Based on the above concerns, lists of threats developed by acknowledged experts
should be consulted for comparison purposes. Then, this first-pass list could be condensed
to develop an optimum list applicable to the enterprise under review.
Threat List: First Attempt

Threat
Improper use of Enterprise equipment for non-Enterprise Purposes.
Unauthorized Access to files by an insider.
Unauthorized Access to the system by a badged outsider.
Unauthorized Access to the system by an outsider.
Physical Abuse (malicious destruction of hardware) by insiders or outsiders.
Accidental, undesired, or unauthorized modification by an insider.
Theft.
Software failure.
Hardware failure.
Disater (i.e., Fire, nature, terrorism, etc.).

Threat

Improper use of Enterprise equipment for non-Enterprise Purposes.

Unauthorized Access to files by an insider.
Unauthorized Access to the system by a badged outsider.
Unauthorized Access to the system by an outsider.
Physical Abuse (malicious destruction of hardware) by insiders or outsiders.
Accidental, undesired, or unauthorized modification by an insider.
Theft.
Software failure.
Hardware failure.
Disaster (i.e., Fire, nature, terrorism, etc.).

Step 2—Research and Review Existing Threat Lists

Once working definitions of threat, threat agent, and threat event have been determined,
they should be reviewed to ensure consistency with the threat lists produced by recognized
experts. The definitions should then be tested and modified as appropriate.

Step 3—Compile An Exhaustive List of Potential Threat Events

Once the threat lists have been identified and reviewed, they should be combined to ensure
completeness and to eliminate obvious redundancies. Then, a complete set of threat events
should be compiled.
In combining the threats lists, the reference to the origin of each threat should be
maintained. Then, the threats should be sorted, and those threats that are clearly redundant
removed. The resultant list contains a mixture of threats (i.e., what), threat agents (i.e.,
who), and threat events (i.e., how). Each item should then be analyzed to create a list of
threat events. Each threat could be translated into one or more threat events. In practice, the
threats should be translated into how they might actually be manifested. In addition, the
threats need to be regionalized to remove specfic threats that occur in nature and that are not
 applicable to internal information systems. After this process, the definition of threat can be
Previous screen
revise: a threat is an event or method that can potentially compromise the integrity,
availability, or confidentiality of the organization's automated information systems, which
are located in a specific geographical location.

Step 4—Breakdown the Threat Events Into Their Components

That Actually Affect the Organization's Information Systems
Functionality
Once the list of potential threat events has been created, each threat event should be
examined and, where necessary, the threat events should be broken down into the actual
components that threaten the functionality of the information systems. Because the goal is
the protection of an organization's information systems, each threat event should be
assigned safeguards for each of the protection strategies: prevention, detection, and
recovery. This process is the “when” component. When should a system be protected from
the occurrence of a threat event--before, during, or after the threat event occurs?
Assignment of safeguards for each of the protection strategies is not initially possible. For
example, in the environmental area, because the weather cannot be controlled, hurricanes,
thunderstorms, and the like cannot be prevented. However, on closer examination, the
adverse effects of these natural occurrences can be prevented. Safeguards can be put in
place to combat the components (i.e., rising water, falling water, power interruptions, and
fire) of these natural occurrences. Therefore, the threat events are further broken down into
their controllable components. Moreover, even though the destruction of an organization's
physical assets cannot be prevented, the interruption of the information system's
functionality can be prevented through the use of scheduled outages, switch-over
contingency plans, and hot sites. Surprisingly, the cost of the physical information
processing assets has dropped significantly over the last several years, and the cost of the
duplication of processing facilities may be lower than the cost of “hardening” existing
facilities. This precipitates a change in traditional protection philosophy. Rather than
focusing on the protection of physical assets, the focus should be on the protection of the
information system's functionality and on its adverse effect to the enterprise.
Therefore, the threat definition must be revised to include the concept of protecting the
functionality rather than just the physical assets that define information systems. The
revised definition of threat is: an event or method, which can potentially compromise the
functionality (in terms of: integrity, availability, or confidentiality) of an information system
(located in a specific geographical region). Exhibit 3 is a list of 79 threat events that reflects
the revised definition of threat obtained after completing step 4.
Threat Event

Unauthorized software modification by an insider

Disruption of service due to a network attack
Unauthorized data modification by an outsider
Unauthorized network configuration changes due to a network attack
Unauthorized data collection
Destruction of property (i.e., bombing, sabotage, vandalism)
Voice communication interruption due to equipment failure
Capturing packets (sniffing)by an insider
Disruption of service (i.e., civil unrest, bomb threats)
Computer hard disk crashes
Capturing packets (sniffing)by an outsider external to the LANs
Tampering with communications links by an insider
Media failure—CD ROM
 Capturing packets(sniffing) by an outsider within the LANs
Previous screen Tampering with system components (i.e., protocol converters) by an insider
Media failure—tapes
Eavesdropping by wiretap by an outsider
Tampering with system components (i.e., routers, bridges, gateways) by an insider
Media failure—diskettes
Subnet penetration (spoofing) by an outsider
Tampering with system components (i.e., cluster controllers) by an insider
Media failure—DASD platters
Personnel death
Tampering with system components (i.e., front-end processors) by an insider
System component failures—external disk drive
Labor strike
Tampering with system components(i.e., data servers) by an insider
System component failures—tape drives
Personnel illness
Tampering with system components(i.e., application servers) by an insider
System component failure—network components
Personnel vacation
Data modification due to unlimited network analyzers) by an insider
System component failures—CPUs
Extended leave
Misrouting (via network analyzers)by an insider
System Component Failure—Cabling
Password disclosure by an insider
Hardware component maintenance errors
Unscheduled shutdowns due to O/S failure
Unauthorized logon by an insider
DPI equipment damage due to accidental chemical or equipment explosions
Application logic errors
Improper use of resources by an insider
Disruption of service due to accidental chemical or equipment explosions
Application design errors
Unauthorized copying of software programs for internal and external use by an insider
Falling water(i.e., plumbing and roof leaks, Fire sprinklers)
Application implementation errors
Data theft (unauthorized viewing or coping) by an insider
Rising water
Application input errors
Physical hardware theft by an insider
Smoke damage
Viruses
Software theft by an insider
Heat (flame)
Worms
Rerouting of messages by an outsider
Heat (high operating temperatures)
Trojan Horses
Physical hardware theft by an outsider
Unscheduled shutdowns (hosts) due to storms
Logic bombs
Data theft (unauthorized viewing or copying)by an outsider
DPI equipment damage due to power fluctuations (i.e., lighting strikes, brown outs)
 Faulty freeware
Previous screen Unauthorized consumption of resources (this includes network resources) by an outsider
DPI equipment failure due to power fluctuations(i.e., lighting strikes, brown outs)
Faulty shareware (software)
Piggybacking
Equipment shutdown due to power loss
Failure due to unauthorized vendor modifications
Inadvertent disclosure of sensitive information
Broken sessions due to non-terminated sessions
Errors from COTS maintenance
Inaccurate or dated information

Unauthorized software modification by an insider

Disruption of service due to a network attack
Unauthorized data modification by an outsider
Unauthorized network configuration changes due to a network attack
Unauthorized data collection
Destruction of property (i.e., bombing, sabotage, vandalism)
Voice communication interruption due to equipment failure
Capturing packets (sniffing)by an insider
Disruption of service (i.e., civil unrest, bomb threats)
Computer hard disk crashes
Capturing packets (sniffing) by an outsider external to the LANs
Tampering with communications links by an insider
Media failure - CD ROM
Capturing packets (sniffing) by an outsider within the LANs
Tampering with system components (i.e., protocol converters) by an insider
Media failure - tapes
Eavesdropping by wiretap by an outsider
Tampering with system components (i.e., routers, bridges, gateways)
by an insider
Media failure - diskettes
Subnet penetration (spoofing) by an outsider
Tampering with system components (i.e., cluster controllers) by an insider
Media failure - DASD platters
Personnel death
Tampering with system components (i.e., Front-end Processors) by an insider
System component failures- external disk drive
Labor strike
Tampering with system components (i.e., data servers) by an insider
System component failures-tape drives
Personnel illness
Tampering with system components (i.e., application servers) by an insider
System component failure - network components
Personnel vacation
Data modification due to unlimited network analyzers)by an insider
System component failures-CPUs
Extended leave
Misrouting (via network analyzers)by an insider
System component failure - cabling
Password disclosure by an insider
Hardware component maintenance errors
Unscheduled shutdowns due to O/S Failure
Unauthorized Logon by an insider
DPI equipment damage due to accidental chemical or equipment explosions
Application logic errors
Improper use of resources by an insider
Disruption of service due to accidental chemical or equipment explosions
Application design errors
Unauthorized copying of software programs for internal and external use
by an insider
Falling water (i.e., pluming and roof leaks, fire sprinklers)
Application implementation errors
Data theft (unauthorized viewing or copying) by an insider
Rising water
Application input errors
Physical hardware theft by an insider
Smoke damage
Previous screen
Step 5—Assign Safeguards to the Threat Events For Each
Protection Strategy
Once the threat events have been identified, a set of safeguards for each protection strategy
(i.e., prevention, detection, and recovery) related to each threat event should be assigned.
In so doing, each protection strategy has different levels of safeguards. For example, there
might be a safeguard that is extremely effective in preventing a threat event but is
expensive, and another safeguard may be not quite as effective but cheaper to implement.
Thus, for each threat event, nine safeguards should be assigned: three for prevention, three
for detection, and three for recovery.
To assign these safeguards, a Threat Event / Protection Worksheet, like the one in
Exhibit 4, should be constructed.

Sample Threat/Event Protection Worksheet

Step 6—Assign A Threat Agent to Each Threat Event

Once the safeguards have been assigned for each threat event, additional threat events may
be identified based on the threat agent that may be responsible for the actual threat event.
During the assignment of safeguards to the threat events, certain threat events have vastly
differing applicable safeguards depending on who (i.e., the threat agent) was responsible
for initiating the event. If this is the case, the threat events should be duplicated as separate
line items and a threat agent assigned to each event. Therefore, each threat agent must be
cosidered and identified for each threat event. The worksheet shown in Exhibit 4 can be
expanded to accommodate threat agents. The result is a new worksheet, Sample Threat
Agent / Event / Protection Worksheet, as shown in Exhibit 5. In addition, the threat
definition should be revised to reflect the role of the agent. Thus, the definition of threat is
modified: an event or method, which when initiated by an agent, which can potentially
compromise the functionality(in terms of: integrity, availability, or confidentiality) of an
information system (located in a specific geographical area).

Sample Threat Agent/Event/Protection Worksheet

Threat events can be initiated by humans. In addition, a distinct set of events triggered
by insiders can be found, and a distinct set of events triggered by outsiders can be found.
Although some threat events may be identical, they are differentiated by the types of
safeguards proposed to protect the information systems. Moreover, there is a collection of
threat events that require the same safeguards regardless of whether they arre initiated by
insiders or outsiders. Upon completion of the above worksheet shown in Exhibit 5, six
threat agents are identified:

· Human (nonspecific).

· Human (insider).

· Human (outsider).

· Hardware.
 · Software.
Previous screen
· Environmental.

Step 7—Assign the Security Concern to Each Threat Event

Once the threat agents have been identified, the security concern (i.e., Integrity,
availability, and confidentiality) may be assigned to the threat events. These are the
concerns that would be compromised by the occurrence of each threat event. This is the
“why” component. The question arises as to why should the occurrence of a threat event be
a concern. Each threat event ought to compromise an information system in one (and only
one)way (in terms of: integrity, availability, and confidentiality). The worksheet should be
expanded to accommodate the security concern, as shown in Exhibit 6.

Sample Threat Agent/Event/Protection Worksheet

Step 8—Combine the Threat Event List and Assign the Threat
Names
Once the safeguards have been assigned to the threat events and the threat agents have been
identified, the threat events should be combined based on similar safeguards, agents, and
security concerns. Now, the threat name can be determined. The objective is to combine
similar threat events, where applicable, to reduce the total number of threat events in the
list. Three discriminators can be used in identifying threat events that are candidates for
combining into a single, higher-level event. These discriminators are: the safeguards,
which may be employed in protecting the information systems functionality from the event
(both in preventing, detecting, and recovering from the incident);the agents, which may
cause the incident, and the security concerns (i.e., integrity, availability, or confidentiality),
which may be compromised because of the event.
Once the threat events list is reduced, it is time to collect and group the threat events and
determine the threat name. The major ancillary benefit of this exercise is the development of
a preferred set of safeguards.

Conclusion
This article has described a structured approach to identify a threat population, which
should aid organizations in their quest for cost-effective solutions to their information
security vulnerabilities. These threats are identified by determining the threat events,
protections, security concerns, and threat agents. This should be an eight step process.

Author Biographies
Timothy R. Stacey
Timothy R. Staceyis employed by Science Applications International Corporation, a
division of Rockwell Space Operations Company, Houston, Texas.
Ronald E. Helsley
Ronald E. Helsleyis employed by AlliedSignal Technical Services Corporation, a
division of Rockwell Space Operations Company, Houston, Texas.
Judith V. Baston
Judith V. Baston is employed by Rockwell Space Operations Company, Houston,
Texas.