Department of Defense - INSTRUCTION DOCUMENT
December 30, 1997 - NUMBER 5200.40 - ASD (C31)
Revised August 07, 2002
Reformatted

• Introduction

• E1 References

• E2 Definitions

• E3 Description

• E4 Management Approach

• E5 Acronyms & Abbreviations

• E6 SSAA Outline

• E7 System Classes

• E8 Components

• Footnotes

DITSCAP ITSEC SYSTEM CLASS DESCRIPTION

E7.1. INTRODUCTION

E7.1.1. Within the Department of Defense, IT systems perform a wide variety of functions to ensure a mission is accomplished and harm is prevented. The information and processes used to perform those functions, regardless of their classification, helps the Department of Defense to operate more efficiently and accomplish its missions. The information and processes shall be afforded an applicable level of protection for confidentiality, integrity, availability, and accountability. Determination of the proper level of protection shall be based on the perceived value of the information and processes. That value is related to the adverse impact, either fiscal, or operational, or both that the loss, alteration, denial of access, or unauthorized access have on DoD missions.

E7.1.2. Security requirements have been established to ensure that information systems provide the required degree of protection. The security requirements are primarily a function of the system mission (operational functions and data processed; etc.), environment (operating and maintenance environment; i.e., the physical and procedural controls for using the system), and architectural concept (stand-alone system, networked and distributed processing; etc.). The degree that systems comply with security requirements produces a level of assurance that the specific information will be protected commensurate with its value to the Department of Defense. The evaluation of information systems to determine the level of assurance requires knowing the ITSEC policy, the way systems permit access to information, and the operational environment for the systems.

E7.1.3. Even though specifics for any given system may, or will differ, these groupings allow one to consider and reuse issues, risks, requirements, solutions, implementations, and analyses from other systems within its class or in related tasks. They provide the ability to compare and contrast systems both within a class or in related tasks. That class structure bounds the security problem and permits security requirements to be grouped to satisfy individual class conditions.

E7.1.4. Technology now provides the Department of Defense with the ability to distribute IT processing locations and access the information processing points from anywhere in the world. It is now possible for one information system to affect other widely distributed systems and the security qualities of confidentiality, integrity, availability, and accountability anywhere in the world. Connection to the communications infrastructure is a prime consideration in evaluating risk. The ITSEC class structure considers a systems security posture as both a single entity and in relationship to other systems.

E7.2. ITSEC CLASSES

E7.2.1. An ITSEC system class is a profile of system characteristics derived from considering how the same characteristics applied to the system's operation data affects community mission outcome. System classes group information systems with others of similar missions, operating environments, architectures, and data. Systems are grouped by their interaction with other systems, the way that users and processes must access different types of data, and the security policies that control access of specific information categories. The intent is to group systems by the amount of risk exposure within the system; i.e., capability to contain risk. Members of a class may share common security policies, requirements, and levels of assurance.

E7.2.1.1. Grouping systems into classes provides many benefits over examining each system on its own merits and determining the individual security requirements to satisfy the specific problem. Examining each system as a single entity is time consuming and resource intensive. Experience has shown that similar systems, information processed, and environment, exhibit similar security requirements to provide an acceptable level of residual risk. Establishing a common set of criteria permits a class repository to be established so that new developments may draw from applicable past experience. That will allow security policy to be determined rapidly and security requirements to be assigned quickly, based on the group or class into which the system falls. This more economical approach supports standardization by grouping systems into categories of similar risk. It also promotes the development of common or reusable security solutions because all systems of a class will share common mission, policy, data, and security requirements. When a new system development begins, or an existing system is to be revised, the class repository may be accessed to obtain the policy and security requirements. This should eliminate the need for lengthy meetings to define the security policy and requirements. The class repository also may provide lessons learned relative to successful security architectures, certification approaches, and tools used. However, it will not delete any of the activities required to determine if the system may be certified. Nor shall system class membership eliminate the system engineering tradeoff decisions between implementation of physical controls and technical countermeasures.

E7.2.1.2. The ITSEC class decision process shall begin by considering the impact of the IT system on other systems. It shall then consider system user interaction, mission, and data types. To consider the impact on other systems, the risk of the specific system to other systems must be accessed. That approach to ITSEC evaluation and C&A focused on infrastructure, shall determine the universal risk to other systems, not just the specific system under consideration.

E7.2.1.3. Table E7-1 provides a form for determining the ITSEC class for a system. It resolves several security discriminating characteristics for a system by first considering the same characteristics for the operation and data associated with the system. This shall be done with direct consideration of the infrastructure where the system is connected. The characteristics for the system shall be chosen to be adequate to accommodate the operation, the data, and associated infrastructure considerations. The characteristics include; interfacing mode, processing mode, attribution mode, accessibility factor, accuracy factor, and information categories. Specific alternatives are selectable for each characteristic shown in table E7-1.
 

E7.2.1.4. The selections for each characteristic will associate systems with similar security requirements for C&A. The concept of class implies that systems and associated C&A activities may be grouped. Classes permit the comparison of systems and use of previous experience from systems in the same or similar classes.

E7.2.2. Interfacing Mode. The interfacing mode categorizes interaction. The question concerns containment of risk; e.g., if a problem were to occur with the operation, data, or system, what would be the risk to other operations, data, or systems with that it interacts, respectively. The interactions of systems may be through either physical or logical relationships. Those relationships are referred to as benign, passive, or active.

E7.2.2.1. Benign. Connotes free of interaction; i.e., no physical or logical relationships. All relationships are restricted to a closed community.

E7.2.2.2. Passive. Connotes limited to indirect interaction, and may or may not have physical relationships, but with tightly controlled logical relationships. An example is a terminal with receive only sessions. (The passive case permits lower-level protocols to support passive interactions.)

E7.2.2.3. Active. Connotes direct interaction, with both physical and logical relationships. The active case may allow multiple interactive sessions with multiple operations, systems, infrastructures, or data.

E7.2.3. Processing Mode. The processing mode distinguishes the way processing, transmission, storage, or data is handled. It reflects the use of the system by one or more different sets of users or processes. The alternatives are; dedicated level, compartmented level, system high level, and multi-level. Each of the modes exhibit unique security qualities.

E7.2.3.1. Dedicated Level. Connotes processing, transmission, or storage is within a single information category. (All users and processes have a valid security clearance for all processes and data, and all users or processes have the same need to know. Access controls are equal for all users and processes.)

E7.2.3.2. Compartmented Level. Connotes that processing, transmission, storage, or data is handled across different information categories with single-level access by individual users or processes at any "given time." (All users and processes have a valid clearance for the most restricted information processed in the system, and a valid need-to-know for the information that the user or process will have access. Access controls are different for each user and process.)

E7.2.3.3. System High. Connotes that processing, transmission, storage, or data while actually across different information categories, is handled as if it were in a single information category or processing domain. (All users and processes have valid security clearance to all processes and data. All users and processes may not have the same need to know. Access controls are equal for all users and processes.)

E7.2.3.4. Multilevel. Connotes that processing, transmission, storage, or data is handled across different information categories with "simultaneous" access by individual users or processes. (All users and processes may not have the same clearances or need to know. Access controls are different for each user and process.)

E7.2.4. Attribution Mode. The attribution mode distinguishes the degree or complexity of accountability required to establish authenticity and nonrepudiation. Four alternatives are; are, rudimentary, selected, and comprehensive.

E7.2.4.1. None. Means no processing, transmission, storage, or data carries the ability to attribute them to users or processes.

E7.2.4.2. Rudimentary. Means the most basic processing, transmission, storage, or data carries the ability to attribute them to users or processes.

E7.2.4.3. Selected. Means some processing, transmission, storage, or data carries the ability to attribute them to users or processes.

E7.2.4.4. Comprehensive. Means all or almost all processing, transmission, storage, or data carries the ability to attribute them to users or processes.

E7.2.5. Mission-Reliance Factor. The mission-reliance factor relates the degree that the success of the mission relies on the operation, data, infrastructure, or system. The criticality of the mission in a broader context is independent of that factor and is used separately. Four alternatives selectable are; none, cursory, partial, or total.

E7.2.5.1. None. Means that the mission is not dependent on the specific aspect; i.e., the operation, data, infrastructure, or system.

E7.2.5.2. Cursory. Means that the mission is dependent on the specific aspect; i.e., the operation, data, infrastructure, or system, is cursory.

E7.2.5.3. Partial. Means that the mission is partially dependent on the specific aspect; i.e., the operation, data, infrastructure, or system.

E7.2.5.4. Total. Means that the mission is totally dependent on the specific aspect; i.e., the operation, data, infrastructure, or system.

E7.2.6. Accessibility Factor. The accessibility factor relates the degree that the operation, data, infrastructure, or system needs to be available from a security perspective. Here, availability concerns are those that relate to security risks; i.e., non-tolerable operational impacts, and does not include those that are only performance concerns. Four alternatives are selectable; reasonable, soon, ASAP, or immediate.

E7.2.6.1. Reasonable. Means that the specific aspect; i.e., the operation, data, infrastructure, or system, must be available in reasonable time to avoid operational impacts.

E7.2.6.2. Soon. Means that the specific aspect; i.e., the operation, data, infrastructure, or system, must be available soon (timely response) to avoid operational impacts.

E7.2.6.3. ASAP. Means that the specific aspect; i.e., the operation, data, infrastructure, or system, must be available as soon as possible (quick response) to avoid operational impacts.

E7.2.6.4. Immediate. Means that the specific aspect; i.e., the operation, data, infrastructure, or system, must be available immediately (on demand) to avoid operational impacts.

E7.2.7. Accuracy Factor. The accuracy factor relates the degree that the integrity of operation, data, infrastructure, or system is needed from a security perspective. Here, integrity concerns are those that relate to security risks; i.e., non-tolerable operational impacts, and does not include those that are only performance concerns. Three alternatives are selectable; not-applicable, approximate, or exact.

E7.2.7.1. Not-Applicable. Means that the degree of integrity for a specific aspect; i.e., the operation, data, infrastructure, or system, is irrelevant as to operational impacts.

E7.2.7.2. Approximate. Means that the degree of integrity for a specific aspect; i.e., the operation, data, infrastructure, or system, must be approximate in order to avoid operational impacts.

E7.2.7.3. Exact. Means that the degree of integrity for a specific aspect; i.e., the operation, data, infrastructure, or system, must be exact in order to avoid operational impacts.

E7.2.8. Information Category. The mission of each system will determine the information that is processed. The mission and information will influence the environment and security requirements applicable to each information category. Information categories are defined by their relationships with common management principles and security requirements promulgated by the security policy for each information category. Processing, transmission, storage, and data of more than one category of information shall not create a new category but shall instead inherit and shall satisfy all the security requirements of the assigned categories. Each of the identified categories may carry additional restrictions or special handling conditions; e.g., NATO-releasable or NOFORN. The information categories are defined as follows:

E7.2.8.1. Unclassified. This category of information includes all information that is not classified and is not sensitive as defined in paragraph E7.2.8.2. below.

E7.2.8.2. Sensitive Information. This category includes information, the loss misuse, or unauthorized access to or modification that could adversely affect the national interests or the conduct of federal programs, or the privacy that individuals are entitled under 5 U.S.C. 552a (reference(l)), but that has not been specifically authorized under criteria established by an E. O. or an Act of Congress to be kept secret in the interest of national defense or foreign policy. Systems that are not national security systems, but contain sensitive information are to be protected in accordance with the requirements of the Pub. L. 100-235 (reference(b)). In many cases, it may be useful to further characterize the sensitive information by determining the subcategory. This may indicate additional national, DoD, Service, or Agency requirements that are imposed by processing that type of information. The subcategories are:

E7.2.8.2.1. Privacy Act. This category includes all information covered by reference (l) and also includes medical, pay, personnel information, etc. Information may be either classified or unclassified. Privacy Act information requires handling according to a common sensitivity. Privacy Act information usually requires system and information access control.

E7.2.8.2.2. Financially Sensitive. This category includes financially and contractually sensitive information. Information may be either classified or unclassified. Financially sensitive category information requires handling according to a common sensitivity, and may require special assurance mechanisms such as two-person verification of transactions. Financially sensitive category information requires system and information access control.

E7.2.8.2.3. Proprietary. This category includes information provided by a source or sources under the condition that it not be released to other sources. This information may require system or information access control.

E7.2.8.2.4. Administrative and/or Other. This category includes DoD information associated with housekeeping activities, information marked For Official Use Only, and unclassified information that does not fall into any of the other information categories.

E7.2.8.3. Collateral Classified. This category includes all classified information not included in the Compartmented and/or Special Access Category.

E7.2.8.4. Compartmented and/or Special Access Classified. This category includes all information that requires special access and a security clearance. Examples include sensitive compartmented information, Single Integrated Operations Plan-Extremely Sensitive Information, and special access programs.

E7.2.9. Each of the identified categories may carry additional restrictions or special handling conditions; e.g., NATO-releasable or NOFORN.

E7.3. SECURITY REQUIREMENTS

E7.3.1. Successful implementation of secure systems depends on defining security requirements early. All ITSEC disciplines (COMPUSEC, COMSEC, EMSEC, physical, and personnel) must be considered in the requirements definition process to arrive at a complete set of requirements. This permits the program manager, the user representative, and the DAA to evaluate cost versus risk tradeoffs successfully and assign security requirement implementation to hardware or software components, or procedures.

E7.3.2. While all systems share a common set of minimum security requirements, some systems will inherit additional requirements based on their mission and function. Additionally, some systems, based on mission and function, may need a higher level of assurance that security requirements have been implemented successfully. That is a basic distinction among the classes.

E7.3.3. When a system is identified with a class of similar systems, the class repository may be accessed for a common set of ITSEC requirements. This eliminates the need for the program manager of each system to develop the security requirements independently from myriad security instructions and directives and forward them to the DAA for approval. The question then remains, how will these requirement sets be developed?

E7.3.4. The approach is twofold.

E7.3.4.1. Existing systems will be analyzed to determine their classes. Those systems that have been accredited may be used as "models" for others of the class. Their ITSEC requirements, high-level architectures and approved solutions may be documented in a common repository. When a new system is required in that class, or a legacy system needs to be upgraded, the class repository will provide valuable support.

E7.3.4.2. An independent requirements definition process needs to collect all ITSEC requirements into a common database. Then the requirements need to be reviewed to remove conflicts and duplications to produce a clean, and complete set of requirements. Those requirements may be allocated to each security class. The result will be an agreed on consistent set of security requirements for each class. Again, users of that class will have the economy of a readily obtainable requirements set.

E7.4. DETERMINATION OF SYSTEM CLASS

E7.4.1. A key step in the use of system classes is first to prepare an accurate description of the system being considered. While the details of the system may not be clear at the outset of development, its outlines and boundaries should be understood. It is important to know what is not part of the system as well as what is part of the system. The system description shall include those items in figure E7-1.
 

E7.4.2. These questions define the boundaries of the system compared to those that this system may interact. That description shall be sufficiently clear and comprehensive to provide an unambiguous definition of when the system may be certified and accredited. If information or understanding about the system is insufficient for that system description to be written, the DITSCAP is not ready to begin.

E7.4.3. Determining the applicable system class is essential to development of the minimal security requirements necessary for the certification and eventual accreditation of the system. By determining the applicable class, the security engineer automatically develops the minimum set of security requirements for the system being analyzed. The various system classes also are associated with specific DITSCAP activities that must be performed. As a result, early in system development the minimum set of security requirements as well as the DITSCAP activities are known to the program manager, the DAA, the user representative, and the CA.

E7.4.4. A system class is determined by first selecting the applicable entries for the first three columns of table E7-1. Next the first three entries are resolved to reflect the most applicable value for the fourth column so that the system will adequately support the needs defined in the first three columns. That will result in a system with the minimum security requirements required in the context of its associated operation, data, and infrastructure. Future DITSCAP application guidance will give further instruction with specific examples and rules in selecting the applicable alternatives for each characteristic as it applies to each system aspect. For example, a completed system class chart could look like the following.