We determined whether Defense Cash Accountability System (DCAS) general controls including those related to security management, access controls, contingency planning, configuration management, and segregation of duties were operating effectively. DoD uses DCAS to process and report its disbursement and collections of funds between the U.S. Treasury and DoD.
DCAS general controls administered by the Defense Finance and Accounting Service (DFAS) did not operate effectively.
- Business Enterprise Information Services (BEIS) Office personnel did not properly approve and train Information System Security Officers or review compliance with the service level agreement1 (Security Management);
- DCAS authorizing officials did not review user permissions for continued appropriateness of user access, including permission for users with access to sensitive financial data (Access Controls);
- BEIS Office personnel did not coordinate or update the DCAS Information System Contingency Plan, and they did not update the Business Continuity Plans, Disaster Recovery Plans, and Continuity of Operations Plans to correct deficiencies identified during internal contingency plan testing (Contingency Planning); and
- BEIS Office personnel did not control developer access to DCAS source code in the test environment, track authorized system changes made to DCAS, or properly identify DCAS emergency changes,2 and document what those actions were and how they should have been implemented (Configuration Management).
These controls did not operate effectively because BEIS Office personnel did not follow the DCAS Access Control Policy, ensure comprehensive procedures existed, or train DFAS staff effectively. As a result, DCAS had an increased risk that users accessed DCAS without authorization or correct level of privileges. In addition, the control weaknesses identified could circumvent segregation of duties3 controls, which were operating as intended.
Without proper controls, DCAS is vulnerable to availability interruptions and lost or incorrectly processed data. Losing the capacity to process, retrieve, and protect electronically maintained data can significantly affect DoD’s ability to accomplish its mission. DoD could consequently suffer financial losses, expensive recovery efforts, and inaccurate or incomplete information.
The Director of BEIS and Other Systems, DFAS, should clearly identify user access privileges, properly coordinate the DCAS contingency plan, remove access in a timely manner from terminated developers, develop a formal Information Assurance training policy, develop procedures to require Information System Security Officers to obtain and retain DoD-required certifications, and develop a process to review service provider compliance with the Service Level Agreement.
Management Comments and Our Response:
Comments from the Director, Information and Technology, DFAS, responding for the Director of BEIS and Other Systems, DFAS, addressed the recommendations to comply with certification requirements, review compliance, provide training on policy and system access, develop and document procedures on approved users, fix discrepancies, and update the Vulnerability Management Plan. However, the Director partially addressed the specifics of the recommendations to provide training on monitoring responsibilities, implement policy for training plans, incorporate lessons learned into the contingency plan, remove system access in a timely manner, and monitor changes in DCAS. We request additional comments to this report by December 12, 2016.
1 A Service Level Agreement is a formal contract between all parties which defines their roles and responsibilities, a description of the service environment, service levels and costs, compliance and remedies for noncompliance, and period of performance.
2 An emergency change is defined as a critical system discrepancy that prohibits the application or system from running successfully, causes significant errors, affects critical data accuracy, or compromises security.
3 Work responsibilities should be segregated so that one individual does not control all critical stages of a process. For example, while users may authorize program changes, programmers should not be allowed to do so because they are not the owners of the system and do not have the responsibility to see that the system meets user needs.