Microsoft Word Hardware Reconfiguration Methodology V final2

Reaccredidation and recertification

If all the previous steps have been appropriately completed and the changes have been deemed successful, the documentation is objective, accurate, up to date, and provides extensive coverage of events and testing then reaccredidation and recertification should be a rapid process. While the process varies according to organizational policy, the ultimate goal of the process is to determine what has changed and what its impact will be on the system and network. By performing all of the aforementioned steps, these time-consuming verifications are taken out of the loop of IT security personnel and left in the hands of those better able to determine the cause and effect implications of the various system changes that have been made. In addition, once all appropriate evidence has been collected and corroborated from previous steps there should be a high degree of certainty about overall system reliability and stability. The systems should then be deemed judged satisfactory for operational use and given final approval by reaccredidation and recertification officials.

6. Wrap-up

Once the deployment has been successfully completed, reaccredited and recertified it will require a “shakedown” period where hidden bugs not found during laboratory testing or deployment can be worked out. A successful shakedown could take several weeks to several months to complete and to learn about any new undocumented features about the changes implemented. During this time, it is important to document any lessons learned (if any) and examine any last minute changes, tweaks, or modifications that have to be made to accommodate for the effectuated modifications and changes.

5. Conclusion

There is no clear-cut or definitive methodology for carrying out system backups or performing system maintenance. The purpose of this Technical Note has been to propose two methodologies to aid system administrators in these tasks. Different operating systems will require different methodologies. However, because the Navy is interested in deploying Linux-based systems as their new C2 systems aboard the retrofitted Halifax-class frigates only Linux has been examined. The material presented herein is applicable, in general, to both Linux and UNIX-based operating systems.

The first methodology, found in Section 3 examines the various techniques and technical issues surrounding performing quality system backups before testing and deployment of system maintenance. Different maintenance types and their consequences have been examined in Section 4. Here, a system maintenance methodology has been developed to aid in the testing and deployment of various types of system maintenance.

The Navy has expressed their interest in maintaining the same operating system throughout the lifecycle of the C2 system. As such, they will inevitably have to perform maintenance on these operating systems, and when they do, the issues examined herein will be of great use to both their system administrators and other technical personnel whose job it is to provide support and maintenance. Many may not agree with the contents herein, however, this is quite likely the first document of its kind as no other system maintenance methodology could be found for Linux or UNIX in general.

In conclusion, although Linux distributions vary greatly according to their market niches, they all share certain features and similarities. It is based on these similarities and features that the methodologies proposed in sections 3 and 4 have been proposed. Of course, they are open to interpretation and can be changed to suit different requirements and environments, but at their basis, they offer relevant and useful tips and advice. Section 2 provides useful background information concerning system maintenance, operating systems, and the various types of dependencies likely to be encountered.