The purpose of this Web page is to provide you with guidance about assigning IA controls. Properly assigning IA controls is an important part of protecting the information that is vital to your mission. Before assigning IA controls, you should already know the information system type, the Mission Assurance Category (MAC), and the Confidentiality Level (CL) for the Video Teleconference Facility (VTF). To properly assign IA controls, you must first decide which ones are applicable, not applicable (NA), or inherited. You should also decide whether the IA control baseline for your information system (IS) needs to be augmented.
Applicable IA Controls
According to Department of Defense Instruction (DoDI) 8510.01, Department of Defense (DoD) Information Assurance Certification and Accreditation Process (DIACAP), identifying applicable IA controls for an IS is a critical activity in the DIACAP. First, it is important to identify the baseline IA controls, which are the minimum set of IA controls that must be addressed to achieve adequate security for an IS. Baseline IA controls are prescribed by DoDI 8500.2, IA Implementation, based on MAC and CL.
Not Applicable IA Controls
It is also necessary to determine which IA controls are not applicable (NA) for your VTF. NA IA controls are those that do not impact the IA posture of the IS as determined by the Designated Accrediting Authority (DAA). What is or is not applicable to a VTF can depend on what is inside the accreditation boundary, the information system type, classification level, and the type of connectivity, etc.
Accreditation Boundary
For example, IA control PESL-1 (Screen Lock) may be NA if there is no personal computer in the accreditation boundary.
Information System Type
For example, EBCR-1 (Connection Rules) is NA for a stand-alone IS, since it does not connect to anything outside its accreditation boundary.
Classification Level
For example, IAKM-3 (Key Management) could be NA for an unclassified IS. PECS-2 (Clearing and Sanitizing) may also be NA unless you are dealing with a classified IS.
Type of Connectivity
The Video Teleconference (VTC) Security Technical Implementation Guide (STIG) notes whether each IA vulnerability can be considered applicable or NA for information systems that use ISDN and/or IP. The VTC STIG is available at: http://iase.disa.mil/stigs/stig/index.html
The VTC STIG Security Checklist is available at: http://iase.disa.mil/stigs/checklist/index.html
The ISDN VTC Baseline IA Controls list gives some guidance on what IA controls might be NA for your ISDN VTF. Download the ISDN VTC Baseline IA Controls list (MS Excel, 58KB)
Remember, if an IA control is NA, it must be listed as such in the Scorecard and in the Plan of Action and Milestones (POA&M). In the POA&M, also provide the reason why the control is not applicable.
Inherited IA Controls
It is also very important to determine which IA controls are inherited. According to DoDI 8510.01, section 6.3.1.2.3., inheritance refers to situations where IA controls along with their validation results and compliance status are shared by two or more systems for the purposes of C&A. Through inheritance, an existing IA control and its compliance status extends from an originating information system (IS) to a receiving IS. Inheritance eliminates the need for the receiving systems to duplicate testing and documentation of inherited IA controls.
Which controls can be inherited?
Whether an IA control is inherited may depend a lot on your accreditation boundary and whether the controls are separately accredited under another information system. For more information about your VTF�s accreditation boundary, click HERE.
The general rule is that if a control that is applied to your VTF is being provided by an accredited resource that is not within your accreditation boundary, you might be able to inherit that control.
Here are some examples of situations in which you should be able to inherit controls:
- The technical controls that are applied to your system are provided by resources that are within a separately accredited information system
- The configuration management, contingency planning, incident response, personnel security, security and awareness training, and other controls applied to your VTF are the same across your organization and/or they are separately accredited as a part of another information system
- The physical and environmental security controls of the facility where your VTF is located are separately accredited as a part of another information system
- Etc.
Also for example purposes, you can download a list of
IA controls (MS Excel, 44KB) that you may be able to inherit from the DECC. Which IA controls on this list you can or cannot inherit from another system will depend on your situation.
eMass
If you are using eMass, you can only inherit controls from another IS if that IS gives those controls to be inherited. A child system can inherit the IA controls that are inherited to it by the accredited parent system.
Which controls can NOT be inherited?
On the other hand, if a control is provided by resources that are within your VTF accreditation boundary, or if the external resource that is providing the control does not have a current, valid accreditation, then it can NOT be inherited.
Here are some examples of situations in which you would NOT be able to inherit controls:
- The technical controls (such as identification & authentication, auditing, account management, boundary protection, etc.) that are applied to your system are provided by resources that are inside your accreditation boundary
- The controls are not provided by resources from an accredited information system that is outside your accreditation boundary
- The contingency planning, configuration management, physical and environmental, system backup, and other controls that are applied to your VTF are only applicable to your VTF
- Etc.
Remember, a resource that is inside the accreditation boundary of another accredited information system cannot be considered to be within the accreditation boundary of your information system.
DISA-Owned Sites & Inherited Controls
If your VTF is funded and owned by DISA, even if it is located in a remote location, your VTF is a part of the DVS accreditation boundary. In this case, any controls that you manage locally cannot be inherited. For example, physical and environmental, contingency planning, incident response, auditing, and other controls that only pertain to your VTF and your local site.
Inherited Controls in the DIACAP Package
Once you document your accreditation boundary and select your IA control baseline, and you are sure of which IA controls are being provided by accredited resources outside your accreditation boundary, you should be able to see which IA controls are inherited and start making your DIACAP package.
As shown in Figure E3.A2.F1 in Enclosure 3 of DoDI 8510.01p, you need to indicate on the DIACAP Scorecard which controls are inherited.
According to section 6.3.1.4., the DIACAP Implementation Plan (DIP) contains the IS�s assigned IA controls, including inherited IA controls. So if your DAA requires a DIP, you should indicate in the DIP which controls are inherited.
According to section 6.3.2.4., inherited weaknesses are reflected on the IT Security Plan of Action and Milestones (POA&Ms). If the IA control is inherited, cite the originating IS in the POA&M. Remember, if that originating IS does not have a current and valid accreditation, the control cannot be inherited.
Inherited Controls and IA Assessment Results
According to section 6.3.2.2., for inherited IA controls, validation test results and supporting documentation are maintained by the originating IS and are made available to the Certifying Authority (CA) of receiving IS's on request.
Augmenting IA Controls
According to DoDI 8510.01, if necessary, baseline IA control sets can be augmented with additional IA controls to address special security needs or unique requirements of the information system (IS) to which it applies (e.g., cross security domain solutions, health information portability, privacy, etc.). Augmenting IA controls originate from a Mission Area (MA), a DoD Component, a Community of Interest (COI), or a local system. Augmenting IA controls must neither contradict nor negate DoD baseline IA controls, must not degrade interoperability across the DoD Enterprise, and may not be used as a basis for denying connectivity of systems that have met the DoDI 8500.2 baseline IA controls for Mission Assurance Category (MAC) and Confidentiality Level (CL) of the gaining IS. Procedures for implementing augmenting IA controls are the responsibility of the originator.
More Information about Assigning IA Control
For more information about assigning IA controls, please consult your organization's policy and IA personnel.