Identifying Information Security Threats Timothy R. Stacey Ronald E. Helsley Judith V. Baston Payoff

Transcription

1 Identifying Information Security Threats 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 riskbased 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 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

2 perform these tasks, the security practitioner must understand the threats to the 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 Personal/Administrative Threat 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 Masquerading as an Authorized User Sniffing Spoofing Wiretaping or Eavesdropping Hardware Threat Software Threat Essential Software Failure Malicious Software Invasion Unauthorized access or Execution Privileges Environmental/Physical Security Threat Loss of stable Electrical Power Facility or Equipment Fire Natural Disaster Temperature/Humidity Extremes Threat Terroist Actions/Civil Disorder Essential Communication Line/Equipment Failure Essential Hardware Failure Programmer/Operator Error Theft or Equipment Tampering

3 Threat Category Threat Personal/Administrative Threat Network Threat Hardware Threat Software Threat Environmental/Physical Security 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 Essential Communication Line/Equipment Failure Masquerading as an Authorized User Sniffing Spoofing Wiretapping or Eavesdropping Essential Hardware Failure Programmer/Operator Error Essential Software Failure Malicious Software Invasion Unauthorized access or Execution Privileges Theft or Equipment Tampering 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.

4 Thus, a complete and balanced list of the threats from which the information systems 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.

5 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

6 applicable to internal information systems. After this process, the definition of threat can be 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

7 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., 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)

8 Faulty freeware 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

9 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.

10 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.

11

12

13