Dear Dr. RMF,
I have a boundary for a web application. My SISO wants to move another web application into this approved boundary. The move is because both have similar operating characteristics, security and privacy requirements, and reside in the same environment of operation. As the SCA for the receiving boundary, what official documentation is required to make the migration official? The moving web application is already in the process of sending me the SSP, STIGs, PIA, etc. What I am more concerned with the changing of my boundary what is required to make the move official? I am being told that no re-adjudication is required for my boundary. I was told my boundary can officially be adjudicated during the annual assessment. Right now, my boundary’s ISSO is drafting an SSP and was told to write a brief security assessment. Once those two items are done, then “poof” the move is complete. I can’t find in NIST SP or DODI 8510.01 what the correct process is.
RMF Boundary Changes,
Thank you for contacting Dr. RMF with your RMF question.
You are absolutely correct. There is plentiful information from DoD and NIST about establishing system boundaries, but precious little about boundary adjustments. That said, I’ll try to be as helpful as I can.
The short answer to your specific situation is that you should treat it as any other change management action, i.e., it should be thoroughly reviewed by the Change Control Board (CCB) of the receiving boundary before any further action takes place. As a part of that review, the CCB should determine if this constitutes a “major change” that should go before the Authorizing Official for a final decision before moving forward. My sense with something like this is that the answer would be YES, so the AO should be engaged early in the process. Since in your case the SISO is the proponent of the change, AO approval is pretty likely.
Once approved, merging the documentation for the two systems will be a major part of the activity. That of course includes producing a consolidated hardware/software inventory, system diagram, etc. The CCB should also ensure that technical compliance such as STIG checklists, ACAS scans, etc., are completed on the consolidated system. Even something as seemingly simple as the name and acronym of the merged system needs to be carefully considered. If you are merging a system called “Apple” into a the boundary of system called “Banana”, is it reasonable to continue calling the merged system “Banana”, or is this likely to create confusion?
Also, if the system being “merged into” the consolidated boundary has its own ATO, or even a partially completed eMASS record, those need to be properly “decommissioned”. If the system being merged also has its own DITPR number (and APMS registration in the case of an Army system), a decision needs to be made about whether to keep those separate or merge them as well.
All things considered, one system boundary is better than two, at least in terms of the RMF level of effort, i.e., cost, so as a citizen and taxpayer, I hope the process goes well for you.
Do you have an RMF dilemma that you could use advice on how to handle? If so, Ask Dr. RMF! BAI’s Dr. RMF is a Ph.D. researcher with a primary research focus of RMF.
Dr. RMF submissions can be made at https://rmf.org/dr-rmf/.