AR 380-19 Information Systems Security

Chapter 3
Automated Information System Accreditation

3-1. Accreditation overview

a. This chapter outlines policies governing the security accreditation of Army AIS and networks. Basic goals include ensuring that accreditation efforts will be appropriate for the system being accredited as well as cost-effective. Accreditation results from the process whereby information pertaining to the security of an Army AIS is collected, analyzed, and submitted for approval.

b. A DAA will be identified for all AIS or networks processing classified or unclassified-sensitive information. Duties of the DAAs include ensuring that-

(1) The requirements of this regulation and other applicable procedures dealing with ISS are followed.

(2) Accreditation statements they issue are based on their review and approval of the system security safeguards.

(3) The safeguards they approve in the accreditation statement are in fact implemented and maintained.

(4) A program of recurring reviews exists for reaccrediting the AIS when significant changes to the system occur.

(5) AIS or networks they accredit do not process data with a sensitivity level beyond the scope of the accreditation.

(6) The security countermeasures selected and applied are sufficient and necessary to counteract the identified risk to the system and cost-effective in relation to other measures that may be equally effective.

(7) Security requirements are incorporated in the planning for system expansion.

(8) A security education and awareness program is in place that meets the minimum requirements of this regulation.

(9) An ISSO or NSO is named for each AIS or network, and given adequate training to carry out the duties of this function.

(10) A security plan is prepared and maintained according to this regulation.

c. Accreditation is the DAA's formal declaration that an AIS or network is approved to operate-

(1) In a particular security mode.

(2) With a minimally prescribed set of technical and nontechnical security safeguards.

(3) Against a defined threat.

(4) In a properly secured area in a given operational environment.

(5) Under stated short- and long-term goals.

(6) With stated interconnections to other AIS or networks.

(7) At an acceptable level of risk for which the accrediting authority has formally assumed responsibility.

d. Accreditation is the official management authorization to operate an AIS or network and is based, in part, on the formal certification of the degree to which a system meets a prescribed set of security requirements. The accreditation statement affixes security responsibility with the accrediting authority. By extension, it also covers AIS that are interconnected or that participate cooperatively in a network.

e. Accreditation addresses the system's perimeter and its boundary. The perimeter surrounds the specified set of equipment and peripherals under the control of the DAA. The boundary encompasses what may be a much larger environment that includes, for example, remote, dial-in users or global network users, who are not controlled by a single DAA. The collection of all potential users of the AIS; that is, users within the system boundary, is used in determining the security mode of operation. Only AIS equipment and peripherals within the perimeter of the AIS must be specifically identified in the accreditation document. However, security requirements for AIS equipment or peripherals accessing the system from outside the AIS perimeter, not controlled by the DAA, will also be addressed in the accreditation.

f. Accreditation must address each operational environment of the AIS. For example, an AIS may operate at one sensitivity level or mode of operation in a standalone mode and connect to a global network in another mode or sensitivity level. The accreditation must clearly establish procedures for transitioning between the two. Multiple operational environments can result in multiple accreditations for a single AIS if different DAAs are involved. Normally, however, a single accreditation addressing all variations is sufficient.

g. AIS which serve only as terminals to larger, clearly defined systems, do not require individual accreditation, but must follow the security requirements of the larger system's accreditation. However, when these AIS are capable of processing data unrelated to the larger systems, they must be accredited before processing such unrelated data.

h. Accreditations completed under the previous regulation (AR 380-380) remain valid until one of the conditions in paragraph 3-6 occurs. Accreditations in progress on the effective date of this regulation will, to the maximum extent possible, comply with this regulation; however, accreditation authorities may make allowances if new requirements cause undue expenditure of resources.

i. There are two general categories of acceptable AIS accreditation within the Army: generic accreditation of centrally fielded AIS, and operational accreditation of AIS that are procured or obtained locally. Centrally fielded systems will be accredited under the generic approach unless HQDA (SAIS-ADS) approves an exception for unusual circumstances. In the latter case, developer preparation of a user's security guide, security certification, and all other portions of paragraph 3-2 (except the actual accreditation statement) are still applicable.

3-2. Generic accreditation

a. Under the generic approach, systems fielded to multiple users are accredited as a single entity prior to fielding. While generic accreditation will lessen the administrative burden for the field users, local ISS officials are still responsible for ensuring that AIS under their purview are operating under the terms of the generic accreditation.

b. The generic accreditation will be applied to AIS fielded under the PEO structure. Additionally, generic accreditations are appropriate whenever a single office or agency is responsible for fielding an AIS to multiple Army users.

c. The generic accreditation will address the projected local operating and risk environments for the system. The using activities should not normally be required to take significant additional steps to accredit the system. If additional security measures are necessary for a particular operating environment, they will be added as a supplement to the generic accreditation by the using command. (See f below.) The following must be accomplished in support of a generic accreditation:

(1) The environment in which the system is to operate must be clearly defined at the beginning of concept development. This facilitates an orderly analysis of the threats to which the system will be exposed, and the subsequent determination of the appropriate security requirements for the system. Environmental factors that influence the security requirements include the users and their level of clearance; source, frequency, and types of input; levels of classification of the data; communications requirements; and physical protection afforded the system.

(2) Security milestones must be established and integrated into the life cycle plan of an AIS. The AIS developer will ensure that users, data owners, system security officers, and accreditation authorities are involved in defining and implementing security requirements, and that a security plan for meeting these requirements is prepared and implemented.

(3) Procurement and acquisition documents must reflect the security requirements and the requirement to comply with DOD 5200.28-STD (as applicable to the proposed mode of operation).

d. During the initial stage of system design, the following must be identified:

(1) The ISSO for the system during pre-deployment. The pre-deployment ISSO will ensure that the provisions of this regulation are met before system fielding. The pre-deployment ISSO is distinct from the using activity ISSO who has purview over system security after the system is operational.

(2) The DAA who will be designated according to paragraph 3-8 of this document.

(3) The sensitivity designation determined from paragraph 2-2a.

(4) The security mode of operations as defined in paragraph 2-2b.

(5) The required minimum evaluation class from DOD 5200.28-STD as determined by the procedures in appendix B.

e. Pre-fielding milestones will include developing the following:

(1) A definition of the security requirements of the system based on the minimum evaluation class and on a detailed risk analysis that addresses all of the projected employment options for the system.

(2) A plan for testing and certifying that the system meets the technical security requirements. This certification testing should normally be part of the overall testing of the system. The DAA will appoint an official to plan, conduct, and approve the certification test. The test report will become an integral part of the accreditation.

(3) An accreditation document, to be fielded with the system either as a separate entity or as a distinct part of the system's documentation, that incorporates the technical certification with the nontechnical security measures and addresses the items contained in the accreditation format in appendix C.

(4) A security SOP for users, operators, and ISSOs that will be fielded with the system either as a separate entity or as a distinct portion of the system's operating manuals. This SOP will provide the user with all required security measures that must be enforced to operate the system at the level of classification and in the mode of operation for which it is accredited. It will incorporate all the countermeasures appropriate for the system and will address as a minimum the physical, personnel, hardware, software, communications, procedural, and emissions security countermeasures upon which the accreditation is based.

f. After the DAA approves, the generic accreditation documentation will be forwarded to the ISSPM of each Army MACOM receiving the system. The MACOM ISSPM, together with the command information manager and command functional user representative, will either accept the generic accreditation as is or, based on their operating environment, prescribe additional measures or procedures to operate the system in their MACOM. Such additional measures will be appended to the generic accreditation to constitute the system accreditation in that MACOM.

3-3. Operational accreditation

Operational accreditation is applicable to all AIS that have not been accredited by a generic accreditation. Operational accreditation is also required for AIS covered by a generic accreditation, if the AIS does not operate within the security bounds of the generic accreditation. Operational accreditation may apply to-

a. A single AIS.

b. A grouping of more than one AIS that shares the following characteristics:

(1) The same DAA.

(2) Common risks and countermeasures to combat these risks as determined by the risk management process.

(3) Common data sensitivity; that is, all CS3, all US2, and so forth, except that AIS with differing data sensitivity may be grouped in a single accreditation provided that 3-3b(1) and (2) apply, and the accreditation documentation includes a clear segregation of the different levels and the security measures applicable to each level.

a. Certification is a technical evaluation of AIS security features completed to support accreditation. Certification verifies that the AIS performs the security functions that support the mode of operation and security policy for the system.

b. Technical personnel, appointed by the DAA, conduct a certification test under a certification plan to determine whether the system adequately meets its prescribed security requirements.

c. Certification primarily addresses software and hardware security measures, but must also consider procedural, physical, personnel, and emissions security to the extent that these measures are employed to enforce security policy.

d. Using products or systems listed on the NCSC EPL does not negate the requirement for certification, but can greatly reduce the testing required for certification approval. In many cases, using EPL products can reduce the certification effort to one of establishing that the product is installed and implemented according to the specifications of the EPL rating.

e. Certification is a key element of generic accreditation. To support realism and thorough testing, the security certification testing will normally be done as part of the overall system testing. However, security-relevant test objectives will be identified as separate events. Although the individuals who accomplish the certification may be members of the developer's staff, they should be allowed to exhibit independence and objectivity. Where practical, individuals who complete the certification will be independent from the developer's staff.

f. The DAA, or a person appointed by the DAA, approves the results of the certification. For generic accreditations, the certification testing and approval must be a separate, distinct event in the accreditation process.

g. Certification is also applicable to operational accreditation. Normally the ISSO preparing the accreditation will supervise its accomplishment.

h. The extent of the certification effort will vary with the security mode of operation of the system.

(1) For dedicated mode, the certification will focus on the physical, procedural, and personnel security measures that ensure all users have the appropriate clearance, access approval, and need-to-know for all data on the system. Since the system is not required to separate users and data with technical security measures, the certification effort will not be extensive.

(2) For systems high (or partitioned) mode, the certification must cover the same factors as for the dedicated mode, but must also establish that the hardware and software reliably separate users from any data for which they do not have a need-to-know (or formal access approval).

(3) For multilevel mode, the certification will address the above factors, but must focus on providing a strong assurance that the system software and hardware can reliably separate users from data on the system for which they are not properly cleared.

3-5. The accreditation process

a. The time and manpower expended in the accreditation process must be proportional to the system size, criticality, mode of operation, data sensitivity, and number of users. For example, the process described in this paragraph, while applicable in a broad sense, may be significantly streamlined if the accreditation addresses small computers or other AIS operating in the dedicated mode. The format at appendix C is an outline for preparing the security plan, that evolves into the accreditation documentation. The depth of treatment for each element of the format can and should vary with the factors noted in this paragraph.

b. The accreditation process that leads to either generic or operational accreditation involves completing the following steps:

(1) Begin developing a security plan. (See app C for format, although certain elements will not be applicable initially.) Refine the plan throughout the accreditation process.

(2) Determine accreditation goals and objectives. Include a review and validation of the need for the subject operations.

(3) Define the proposed operations, including a definition of the key security features forming the basis of the accreditation and identification of the security mode of operation.

(4) Conduct a risk management review which will identify risks and countermeasures. (See chap 5.)

(5) Select the security countermeasures, beyond the minimum security requirements, which are required based on the risk management review.

(6) Conduct a certification (according to a certification plan) to establish that the AIS performs the security functions that support the mode of operation and security policy for the system.

(7) Develop a security guide that provides security instructions for users, operators, and the ISSO.

(8) Modify the security plan as appropriate, add necessary attachments, and forward to the DAA for approval. See figure 3-1 for a sample accreditation authority approval statement.

c. Documentation associated with the formal accreditation describes the system in detail and must be protected to the degree that its compromise would jeopardize the security of the information contained in the system. Documentation that reveals system vulnerabilities will be handled with particular care. As a minimum, the documentation will be handled as "for official use only." (See AR 340-17, exemption categories 2 and 5.) Accreditation documents should be written so they do not reveal vulnerabilities requiring the documents to be classified higher than secret.

d. Documentation will be forwarded to the accreditation authority in sufficient time to be acted upon before operation of the system or the expiration of any existing accreditation.

3-6. Reaccreditation

a. All AIS, except those designated as nonsensitive, will be formally reaccredited within 3 months after any of the following occurs:
(1) Addition or replacement of a mainframe or significant part of a major system.

(2) A change in sensitivity designation (para 2-2a).

(3) A change in security mode of operation (para 2-2b).

(4) A significant change to the operating system or executive software.

(5) A breach of security, violation of system integrity, or unusual situation that appears to invalidate the accreditation.

(6) A significant change to the physical structure housing the AIS that affects the physical security described in the accreditation.

(7) Three years has elapsed since the effective date of the existing accreditation.

b. Reaccreditation will include the same steps accomplished for the original accreditation; however, those portions of the documentation that are still valid need not be redone.

3-7. Accreditation records

Copies of AIS accreditation or reaccreditation documentation will be maintained by the appropriate accreditation authority or his or her representative.

3-8. Designated accreditation authorities

a. For operational accreditation, the DAA will be appointed as follows:
(1) Critically sensitive one (dedicated SCI, no network connections). MACOM commanders are the accreditation authorities for CS1 systems that process SCI and operate in the dedicated mode, provided these systems do not include connection to common-use networks such as Automatic Digital Network (AUTODIN) or DDN. General officers authorized to authenticate correspondence for MACOM commanders can sign accreditation statements on their behalf. A copy of each accreditation statement will be furnished to HQDA (DAMI-CIC-AS), WASH, DC 20310-1055. The DCSINT, DA, is the accreditation authority for systems not under the purview of a MACOM.

(2) Critically sensitive one (systems high SCI, no network connections). The DCSINT, DA, is the accreditation authority for CS1 systems that process SCI in the systems high-security mode, provided they are not connected to common-use networks.

(3) Critically sensitive one (partitioned/multilevel or network connection SCI). The Director, DIA, is the accreditation authority for all CS1 systems that process SCI and are not covered by 3-8a(1) or (2). This provision does not apply to Army telecommunications centers accredited by the Commander, USAISC, according to guidance from the Director, DIA.

(4) Critically sensitive one (SIOP-ESI). The Director, Joint Staff, is the accreditation authority for systems processing SIOP-ESI data. Requests for accreditation will be prepared according to MJCS 75-87 and forwarded through HQDA (DAMI-CIC-AS), WASH DC 20310-1055.

(5) Critically sensitive two. MACOM commanders and the Administrative Assistant to the Secretary of the Army (acting as the HQDA MACOM) are the accreditation authorities for CS2 systems. For systems operating in the dedicated, systems high, or partitioned mode, MACOM commanders and the AA to the Secretary of the Army may further delegate, in writing, accreditation authority to general officers or senior executive service personnel within their commands or agencies. Such delegation may be by name or by established position titles. Approval of HQDA (SAIS-ADS) is required before a CS2 system in the multilevel mode can be accredited.

(6) Critically sensitive three. MACOM commanders and the AA to the Secretary of the Army are the accreditation authorities for CS3 systems. For systems operating in the dedicated, systems high, or partitioned mode, MACOM commanders may further delegate, in writing, the accreditation authority to personnel at the minimum rank of colonel, GM-15, or GS-15 who are occupying a position of command or principal staff officer at an installation or general officer command. Such delegation may be by name or by established position titles. For systems operating in the dedicated, systems high, or partitioned mode, the Administrative Assistant to the Secretary of the Army may delegate accreditation authority to personnel in the minimum rank of colonel, GM-15, or GS-15.

(7) Unclassified sensitive one and unclassified sensitive two. Individuals authorized to accredit CS systems are also authorized to accredit US1 and US2 systems. Additionally, MACOM commanders and the AA to the Secretary of the Army may delegate, in writing, accreditation authority to other personnel who are in the minimum rank of lieutenant colonel, GM-14 or GS-14. Such delegation may be by name or established position title.

b. For generic accreditations, DAAs will be appointed as follows:

(1) The Director, DIA for CS1 systems processing SCI that-
(a) Operate or are projected to operate in the partitioned (compartmented) or multilevel security mode, or require connection to a common-use network such as AUTODIN or DDN, regardless of security mode.

(b) Have received special approval from DIA for a generic accreditation. Normally, this will only apply to tactical systems being fielded in identical configurations at a large number of sites. DIA may require additional measures, such as configuration control.

(2) The DCSINT, DA, for CS1 systems not covered by 3-8b(1).

(3) The DISC4 for CS2 and below AIS in the multilevel security mode.

(4) The applicable PEO, with concurrence from HQDA (SAIS-ADS), for CS2 or CS3 systems in the dedicated, systems high, or partitioned security mode. When a generic accreditation is appropriate and the AIS is not being fielded through the PEO structure, a general officer or member of the senior executive service who has responsibility for fielding the system may be appointed as the DAA.

(5) The applicable PM or equivalent for systems processing unclassified sensitive data.

c. If a generic accreditation is appropriate and the DAA is not readily apparent from the above guidance, HQDA (SAIS-ADS) may be contacted for assistance in determining the DAA.

3-9. Special provisions for systems processing intelligence data (RCS: CIA 1003).

a. CSI AIS or networks that process SCI or WNINTEL data are subject to this regulation, DIAM 50-4, and, for contractor operations, DIAM 50-5 or their successors.

b. CSI accreditations with a DAA within the DA will be prepared and processed under this regulation. Documentation will be forwarded through command channels to the appropriate DAA. Accreditation documentation for CSI systems processing SCI will include the written concurrence of the local supporting special security officer and a statement of hostile threat from the local counterintelligence support activity.

c. AIS that process SCI and are accredited within the DA will be supported by an INSCOM security assessment as described in paragraph 2-30 of this regulation. The request for support will be submitted prior to system operation, and a copy of the request will be included with the accreditation documentation. Completing of the assessment before accreditation, while highly desirable, is not required.

d. Accreditation for all CSI systems with DIA as the accreditation authority will be prepared and processed according to DIAMs 50-4 and 50-5 or their successors.

e. To comply with Director of Central Intelligence reporting requirements. MACOMs and the AA to the Secretary of the Army (acting as the HQDA MACOM) will maintain data and submit an annual report as directed by HQDA (DAMI-CIC-AS) on all CSI accreditations and all systems processing WNINTEL data in their command or activity (RCS: CIA-1003). Data maintained for the report will include the following (separated by SCI and WNINTEL):

(1) The number of standalone AIS accredited in each mode and the number operating without accreditation, if any.

(2) The number of AIS accredited as a network in each mode and the number operating without accreditation, if any.

(3) The number of AIS (of the total number above) operating at a level of trust as specified in DOD 5200.28-STD by division and class (for example, C2, B3, and so forth).

3-10. Interim approval to operate before accreditation

a. A DAA may grant interim approval to operate before an operational accreditation is issued, provided the following conditions are satisfied:
(1) A security survey has been performed and measures to prevent compromise, loss, misuse, or unauthorized alteration of data are deemed adequate. Specific limitations on operations may be necessary during the period of interim approval.

(2) Applicable COMSEC (chap 4) and TEMPEST (AR 380-19-1) requirements have been met.

(3) A firm schedule to accomplish the accreditation is established and agreed to by the DAA.

b. Interim approval may not be granted for periods longer than 90 days. One additional 90-day extension may be granted, but the total length of an interim approval will not exceed 180 days.

c. Interim approvals will not apply to a generic accreditation.

Figure 3-1. Sample format of an accreditation statement

SUBJECT: Automated Information System (AIS) Accreditation Commander (name) 1. Reference AR 380-19, chapter 3, dated (date) Subject: Information Systems Security. 2. Having reviewed the security measures which have been implemented and planned in the areas of security management, software, hardware, procedures, communications, personnel, and physical security, operation of the (computer, room, building, and address) and its associated peripherals is considered to be within the bounds of acceptable risk. 3. Accordingly, accreditation is granted to store and process (insert sensitivity level from paragraph 2-2a) information in the (insert security mode from paragraph 2-2b) security mode. 4. A reaccreditation is required immediately if any event listed in paragraph 3-6, reference 1, occurs. (Signature block) Authentication by accreditation authority