When does a DoD Information System require a re-accreditation
How do you determine when a DoD Information System should have a full re-accreditation?
We are not talking about the obvious:
-3 year expiration
-completely new version and/or overhaul of a system
We are talking about a single client on within an Information System getting an upgraded operating systems, or a firewall being upgraded or the addition of 4 Cisco internetworking devices and a VLAN change.
How do we know what is a basic sustaiment change, a configuration management changed (approved by the Configuration Board members) or a full blown 100,000 dollar re-accreditation.
You would think there was some kind of matrix that could match up modifications to a DoD IS with what actions must be performed. If there is one, I have not seen it.
All we have is high level regs that tell us IA Workforce peons (who must deal with details, schedules and limited funds) almost nothing we don’t already know.
Assessing the IA Impact & Maintaining Situational Awareness:
DoD 8500.2, Information Assurance gives us IA Controls such as
DCII-1, dealing with IA Impact Assessment. Its states, “Changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.” The DoD instruction also tells us the we are supposed conduct comprehensive annual reviews of our systems process, procedures and IA Control status.
How are we supposed to monitor “Changes to the DoD information system?
We know that we are supposed monitor all DoD IS’s to keep track of the baseline. And according to the regs, we are supposed to do this by a configuration management process (DCPR-1, CM Process). That configuration management process is supposed to have a “configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems.”
So Configuration Management gives us oversight on changes to DoD IS but who within the CM process determines whether changes to a system should have a re-accreditation?
IA Control DCCB-2, Control Board tells us that” all information systems are under the control of a chartered Configuration Control Board that meets regularly according to DCPR-1.” Is also tells us that the Information Assurance Manager (IAM) is a member of the CCB.
From my interpretation of these high level statements, the IAM is the subject matter expert who has a lot of say so on the IA impact of modifications to a given DoD IS.
But the question remains.. HOW DO WE KNOW WHAT NECESSITATES A RE-ACCREDITATION?
I did not find anything for that in 8500.2 so I moved on to CJCSI 6510.01, but it only says the same things that 8500.2 says (Configuration Management, CCB, having a baseline). But it did say this:
“Ensure a configuration management (CM) process is implemented and establish appropriate levels of configuration management to maintain the accredited security posture. The security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA..”
Still pretty high level, but we are getting closer since the instruction is telling us: “..security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA“.
I thought that the only way to get more insight is to look at the lower level regulations within specific branches. Air Force’s Certification & Accreditation Program, 33-210, for example talks specifically about reaccreditation. It states, Information system owner (ISO) “Alerts AFNetOps of any changes to the topology or software affecting the security posture of the enclave boundaries so that the gateway package can be reaccredited if necessary. (220.127.116.11.4.)” And in table 3.2. it states “PM/SM/ISO will enter information in EITDR, host an initial stakeholder meeting, and initial security review to determine if a new version is to be created.” It mentions different reaccreditation actions for Networked and Standalone systems. Its goes on say that “if changes will not affect the security posture of the IS, the PM/SM/ISO will annotate the outcome of the meeting and make necessary edits to the C&A package.”
The Army’s AR 25-2, Information Assurance regulation, has an entire section on Accrediation & Reaccreditation (5-5), but offers still no specifics. The Army does have AR 380-19, AIS Information System Security and it is pretty specific (see excerpt below).. but it is now OBSOLETE and replaced by AR 25-5.
All regulation and instructions are inline as far as the need to reaccredit if there is an IA IMPACT, but no specifics on what constitues an “IA Impact”. 8510, DIACAP mentions that the IA posture of an IS must remain acceptable, in order to retain its Authorization to Operate (ATO). If I were the IAM for a day.. I would hang my hat of this important statement.
We have to work with what we have!!
Based on what we have:
Changes in a DoD IS’s IA Controls determine whether or not a system will need a reaccrediation. There is no specifics on what can force a reaccrediation. So we must conclude that there is no “magic bullet” that will instantly create the need for a reaccreditation. In other words, no modifications to a certain hardware or software or certain subsystems or even the changes to network architecture will be the reason for reaccreditation every single time.
Significant changes to IA Controls are the only thing we can really put our finger on.
So lets say that IA Control, DCCS-2, Configuration Specification was changed on an Information System. This IA Control deals with making sure the all IA Enabled and IA Products have the DISA Security Technical Implementation Guides (or equivalent) applied. Maybe an example will help us understand the process of determining reaccreditation: A DoD Information System Owner requests the addition of four new storage devices to the system enclave. Lets say, that these storage devices will have an adverse affect on the security posture of the overall system because they are not in compliance with DCAS-2, Acquisition Standards… so the storage devices have not gone through NSA/Common Criteria. Additionally the storage devices will not be compliant with DCCS which means they will not have security in accordance with DISA/NSA checklists and guidance.
Prior to being implemented or even tested the request for this change should go through the configuration management process where the IAM will tell the Program Manager and System Owner (or is representative) the security impact to the over all system. He or she would have to explain to them that the change may affect the current ATO, because they will now be non-compliant on two (possibly more controls) that were previously compliant. The IAM would also be wise to get in contact with other subject matter experts such as the system administrator and/or IAO would be in charge of implementing and testing the system. The IAM might also contact the Certifying Authority (or representative) to determine if such a change would create the need for a reaccreditation.
One thing the IAM does NOT want to do is simply sign the Program Managers and System Owners up for some changes to the system that would jeapordise the Authorization to Operate. The IAM should do their homework and present the real risk of the modifications to the system owner. CYA is paramount.
Once the IAM determine the impact, and the modification are made:
According to DoD 8500.2, 5.8.5. “ensure that IA-related events or configuration changes that may impact accreditation are reported to affected parties, such as Information Owners and DAAs of interconnected DoD information systems.”
Some older regulations are more specific. AR 380-19, AIS System Security for example:
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.
AR 380-19 has been replaced with AR 25-5 which is pretty high level.