A THREAT-BASED DEFINITION OF IA AND IA-ENABLED PRODUCTS

Philip Campbell Mark Schaefer, retired Mayuri Shakamuri Sandia National Laboratories c/o Philip Campbell Sandia National Laboratories P.O. Box 5800, MS 0672 Sandia National Laboratories P.O. Box 5800, MS 0672 Albuquerque, NM 87185-0672 P.O. Box 5800, MS 0672 Albuquerque, NM 87185-0672 USA Albuquerque, NM 87185-0672 USA USA

Abstract - This paper proposes a definition of “IA and IA-enabled products” based on threat, as opposed to “security services” (i.e., “confidentiality, authentication, integrity, access control or non-repudiation of data”), as provided by Department of Defense (DoD) Instruction 8500.2, “Information Assurance (IA) Implementation.” The DoDI 8500.2 definition is too broad, making it difficult to distinguish products that need higher protection from those that do not. As a consequence the products that need higher protection do not receive it, increasing risk. The threat-based definition proposed in this paper solves those problems by focusing attention on threats, thereby moving beyond compliance to risk management. (DoDI 8500.2 provides the definitions and controls that form the basis for IA across the DoD.) Familiarity with 8500.2 is assumed.

Index Terms — DoDI 8500.2, IA and IA-enabled products,

threat, threat-based model

I. INTRODUCTION

Everyone would like to defend everything at the highest possible level. But even in the best of all possible worlds this is not possible, and in our fixed-resources world this is even less possible. The higher cost required for higher defense of one part of a system requires a lower cost and thus lower defense for some other part of the same system. There is no way to cut corners here and still end up with a square.

The Department of Defense (DoD) Instruction 8500.2 “Information Assurance (IA) Implementation” [2] provides the definitions and controls that form the basis for IA across the DoD. Among the definitions provided by 8500.2 are definitions for “IA Product” and “IA-Enabled Product” (referred to collectively in this paper as “IA and IA-enabled products,” one of which is an “IAE”). These products are the ones that “provide security services (e.g., confidentiality, authentication, integrity, access control or non-repudiation of data)” ([2], page 20). They are required to be “evaluated”—an expensive and long process—and special attention is focused on their configuration and implementation. IAEs represent the subset of a system that requires the highest attention, the subset that is most important to the IA of the system.

Unfortunately the definition of IAEs that 8500.2 provides is too broad. It is difficult to find anything in the non-IAE subset. Because everything is an IAE everything requires the highest attention and everything is most important. As a result, “highest attention” collapses to normal attention and “most important” collapses to normal importance, and the IA that IAEs are intended to provide is lost.

This paper proposes an alternative definition based on

threat. This alternative definition distinguishes the products that require the highest attention from those that do not, thereby enabling IA.

In the body of this paper current definitions and relevant material are presented first followed by a statement of the problem. This is followed by new definitions based on threat.

II. THREAT-BASED DEFINITIONS

A. Current Definitions and Relevant Material The following are the relevant definitions as they appear in

DoDI 8500.2: E2.1.29. A Product. Product or technology

whose primary purpose is to provide security services (e.g., confidentiality, authentication, integrity, access control or non-repudiation of data); correct known vulnerabilities; and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. Examples include such products as data/network encryptors, firewalls, and intrusion detection devices (reference (a)). ([2], page 20)

E2.1.30. IA-Enabled Product. Product or

technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems (reference (a)). ([2], page 20)

The following are the IA Controls in 8500.2 that mention

IAEs:

• DCSR-3 ([2], page 85), DCSR-2 ([2], page 93), and DCSR-1 ([2], page 100) require the use of IAEs at the high robustness level for Classified systems, at the medium level for Sensitive systems, and at the basic level for Public systems, respectively.

• DCAS-3 ([2], page 205), DCAS-2 ([2], page 93), and DCAS-1 ([2], page 100) require that IAEs be “evaluated” (e.g., via CCEVS).

• DCCS-2 ([2], pages 54 and 65), and DCCS-1 ([2], page 76) require that a configuration specification be used for the “newly acquired IA and IA-enabled

products that require use of the product’s IA capabilities.”

Elsewhere in 8500.2 we read about “… all incorporated IA

products, and IA-enabled IT products that require use of the product’s IA capabilities” ([2], page 34), which echoes DCSR’s use of the word “require.” Other passages in 8500.2 about IAEs do not help us distinguish them from non-IAEs:

• The NSA Director is responsible for the creation of Common Criteria “Protection Profiles” for IAEs ([2], page [5]).

• IA Officers are responsible for configuration of IAEs ([2], page 9).

• System Administrators are responsible for the configuration and operation of and any IA-relevant changes to IAEs ([2], page 10).

• A Common Criteria “Security Target” is the basis for evaluation of IAEs ([2], page 24).

• “DISA and NSA support the Defense IA program through the development and dissemination of security implementation specifications” for IAEs ([2], page 35).

Venturing outside of 8500.2, NSTISSP #11 (National

Security Telecommunications and Information Systems Security Policy) specifies the “evaluation and validation requirements” ([2], page 34) for IAEs. The Information Assurance Technical Framework (IATF) provides a “common reference guide for selecting and applying adequate and appropriate” IAEs ([2], page 32). IAEs are not even mentioned in FIPS 200 [4], for example, or in NIST 800-53 [5], and DIACAP discusses them only in the context of “DIACAP validation of a DoD IS [information system] that consists of a single IA-enabled product or solution” ([3], page 22). Like the passages from 8500.2 shown above, these are no help in distinguishing IAEs from non-IAEs.

The FAQ for NSTISSP #11, on the other hand, almost provides an answer: ‘Whether a component is considered an IA/IA-enabled IT component depends heavily on the nature of the architecture in which it is being placed…if the component is “cognizant” of the security policy and makes security decisions or implements security features, it is considered to be an IA/IA-enabled IT component’ ([1], Question II, 7 (see also Question III, 3)). The FAQ presents the clarifying example of an operating system that is an IAE in one architecture because in that architecture it is “required” to enforce access but a non-IEA in a second architecture because in that architecture it is being used as a dumb terminal and is thus not “responsible” for enforcing access. What the FAQ does not tell us is (1) how it is determined that access enforcement in the first instance is “required” and (2) whether enforcing access in the second instance makes the OS an IAE. That is, the FAQ does not describe how to distinguish the required provision of security services from what could be called the gratuitous provision of those same services (e.g., the requirement of a password to change a parameter in a “commercial-off-the-shelf” (COTS) component in the system). An answer is suggested below

B. Problem Statement

The definitions as they appear in DoDI 8500.2 (and as

shown above, including guidance from NSTISSP) suggest that the answer to all of the following questions is Yes:

• Authentication: Passwords provide authentication, so are all software programs that uses a password IAEs?

• Confidentiality: Encrypting data at rest on a laptop provides confidentiality, so are all of the operating systems on such laptops IAEs?

• Integrity: TCP/IP, for example, provides transmission integrity, so is TCP/IP an IAE?

• Access Control: Discretionary access controls provide access control, so are all operating systems with discretionary access controls IAEs?

• Non-Repudiation: Mail applications provide a sender address, which provides non-repudiation, so are all mail applications IAEs?

Like any definition, the definition of IAE must dichotomize

the world: it must separate something from everything else. In this case, the definition of IAE must separate IAEs from non-IAEs. But given the questions above, it is not clear that the definition of IAE helps us make that distinction and this suggests that the definition is of no value. It is significant that 8500.2 does not provide a name for, or even refer to, the products that are non-IAE.

C. New Definitions

The word “require” from IA Controls DCSS-2 and DCSS-1,

quoted above, suggests the following new definition:

Definition: Let IAEs be those products that provide at least one security service required by the system’s threat model, and let non-IAEs be those products that do not provide any security services required by the system’s threat model, even if the latter provide non-required security services.

This new definition is not so much “how [IAEs] will be used,”

to borrow the phrase from the NSTISSP #11 FAQ passage shown above, but rather why they will be used.

For example, suppose that we have a network that has one interface to another network. Suppose that there is a firewall, at that interface, that filters the packets crossing that interface. And suppose further that there are also firewalls in the operating systems on all of the networked computers inside the network, each of which also filters packets. Which of these are IAEs and which are non-IAEs? There are four cases, as shown in Table 1 below.

TABLE 1 IAE CASES

Case Interface firewall is an IAE OS firewalls are IAEs 1 No No 2 No Yes 3 Yes No 4 Yes Yes Which case applies depends upon the intent of the system

design. That is, if we come upon the network described above, we are unable, by looking at the system design alone, to determine whether neither the interface firewall nor the OS firewalls are IAEs (which is Case 1 in Table 1), the OS firewalls alone are IAEs (Case 2), the interface firewall alone is an IEA (Case 3), or both the interface firewall and the OS firewalls are IAEs (Case 4). We need to find out what the system design requires, and that necessitates review of the system threat model. (This example is revisited below.)

Of course, non-IAEs should adopt generally-accepted, good engineering practices, including defense-in-depth, and can provide gratuitous security services (i.e., security services that are not required by the system’s threat model), all without becoming IAEs. In this definition, as in the NSTISSP guidance, whether a given security service provided by a given product in a given system is required or not required depends upon the role that the service is being asked to play in the given system and cannot be determined by examination of the product itself. However, unlike the NSTISSP guidance, the definition here points to the threat model as the basis for determining whether a product that provides a security service is an IAE or a non-IAE.

1) Threat Model Every system has a threat model, even if that model is

implicit. A threat model partitions the set of all possible threats into three subsets—call them sets A, B, and C:

• Set A contains the threats that are not expected to be mounted against the system;

• Set B contains the threats that the system is designed to counter; and

• Set C contains the remaining threats. The system does not need to defend against the threats in

set A; the system designers accept the risk of not defending against the threats in set C; but the system needs to defend against the threats in set B. That is, the system needs to be designed to defend against the threats in set B: the design requires that certain items provide security services in order to defend the threats in set B.

In light of the threat model description, the table from the example above is reproduced below, with an additional column explaining each of the four cases in that example.

TABLE 2

IAE CASES REVISITED

Case Interface firewall is an IAE

Network firewalls are IAEs

Explanation

1 No No

Set B does not contain a “firewall threat” (meaning a threat against which a firewall could defend the system).

2 No Yes

Set B does not contain a firewall threat from the network interface but set B does contain a firewall threat from the internal network.

3 Yes No

Set B contains a firewall threat from the network interface but set B does not contain a firewall threat from the internal network.

4 Yes Yes

Set B contains a firewall threat from the network interface and set B contains a firewall threat from the internal network.

IAEs require more resources to evaluate and to configure,

than non-IAEs, it must be presumed. Does the new definition then allow an unscrupulous, lazy, or foolhardy system designer to claim that no security services are required and thus no IAEs are needed for a system that actually does require security services and actually does need IAEs? Based on the new definition described above, a system designer is able to do this. But in order to support this claim, the system designer must convince the higher IA authorities that set B for the system of concern is empty. If everyone is convinced that set B is empty, then everyone is convinced that there is no need for security services, and thus, by agreement, there is no need for IAEs. With this agreement in place, the system designer is indemnified against accusations of providing inadequate system protection, as well accusations of being unscrupulous, lazy, or foolhardy. Instead, this new definition allows the system designer greater opportunity to exercise fiscal responsibility.

2) E2.1.29 Retrofitted with the New Definition The following are the definitions of IA and IA-enabled

products from DoDI 8500.2, modified to incorporate the new definition above:

E2.1.29. IAE. (An “IAE” is either an “IA Product” or an

“IA-Enabled Product,” as defined below.) Any product or technology that provides security services required for the defense of the system based on the threat model for the system. If an IAE fails to provide its required services, then, even if there are additional measures in place, the system can be said to have failed to defend itself. Security services include confidentiality, authentication, integrity, access control and non-repudiation of data. An

IAE can correct known vulnerabilities and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. (A non-IAE may provide security services but these security services are not required for the defense of the system based on the threat model for the system.)

E2.1.29.1. IA Product. Product or technology that

does not provide functionality besides required security services. Examples include such products as data/network encryptors, firewalls, and intrusion detection devices (reference (a)).

E2.1.29.2. IA-Enabled Product. Product or technology

that can provide functionality besides required security services. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems (reference (a)).

The new definition of IAEs allows these products to be

distinguished from non-IAEs, and this frees up resources dedicated to the protection of the latter so that those resources can flow to the protection of the former, based on the threat model of the system.

III. CONCLUSIONS

This paper presents a definition of IA and IA-enabled

products that allows them to be distinguished from other products, based on a threat model for the system in which the products are used. The significance of this new definition is that it allows protection to be placed where it is needed, thereby enabling IA.

This new definition suggests more research on threat models. Threat models for particular systems should be developed for the use of those systems in adjusting the protection provided by IAEs for those systems. This research should then lead to generic threat models that could function as initial models for particular systems and to mapping between model features and particular IAEs.

This new definition is foundation for revisiting the question of how IAEs should be evaluated and configured. For example, what are the alternatives to an evaluation against a Common Criteria Protection Profile? And what are the cost/benefit ratios for those alternatives? Similarly, what are the alternatives to configuration guides from DISA and NSA? And what are their cost/benefit ratios? And finally, what attention should be paid to non-IAEs?

IV. REFERENCES

[1] Committee on National Security Systems, Frequently

Asked Questions, March 24, 2005, National Policy Regarding the Evaluation of Commercial Products. http://www.naiap-ccevs.org/faqs/nstissp-11.

[2] Department of Defense Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003.

[3] Department of Defense Instruction 8510.01, “DoD Information Assurance Certification and Accreditation Process (DIACAP),” November 28, 2007.

[4] Federal Information Processing Standards Publication, “Minimum Security Requirements for Federal Information and Information Systems, FIPS 200, March 2006.

[5] NIST Special Publication 800-53, Revision 3, “Recommended Security Controls for Federal information Systems and Organizations,” August 2009.

V. VITA

Philip Campbell graduated from the University of New

Mexico in 1997 with a Ph.D. in computer science. He has been a Member of Technical Staff at Sandia National Laboratories since 1983.

Mark Schaefer graduated from UCLA with a Master's Degree in electrical engineering. He has been a Member of Technical Staff at Sandia National Laboratories since 1976.

Mayuri Shakamuri graduated from New Mexico Tech in 2008 with a Masters degree in computer science. She has been a Member of Technical Staff at Sandia National Laboratories since 2009.