Overview
For AIS applications, a functional architecture that identifies the following has been developed and is maintained: – all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface – user roles required for access control and the access privileges assigned to each role (See ECAN) – unique security requirements (e.g., encryption of key data elements at rest) – categories of sensitive information processed or stored by the AIS application, and their specific protection plans (e.g., Privacy Act, HIPAA) – restoration priority of subsystems, processes, or information (See COEF).
Threat
Information systems without proper architectural documentation may be difficult to troubleshoot in a timely manner. Additionally, continuity of operations is seriously degraded when system architecture is undocumented. Having complete and accurate functional documentation for an AIS application architecture ensures all unique aspects are captured.
Guidance
1. Each Component shall identify standard and unique characteristics of their AIS applications to develop a functional architecture that identifies the following:
a. All external interfaces, the information being exchanged, and the protection mechanisms associated with each interface;
b. User roles required for access control and the access privileges assigned to each role (See ECAN);
c. Unique security requirements (e.g., encryption of key data elements at rest);
d. Categories of sensitive information processed or stored by the AIS application, and their specific protection plans (e.g., Privacy Act, HIPAA); and
e. Restoration priority of subsystems, processes, or information (See COEF).
2. Components shall maintain and keep current their functional architecture documentation through disposal.
DoD classifies this control in the subject area of “Security Design and Configuration” with a impact of “Medium”.