|
|
|
TABLE OF CONTENTS
This report presents the results of the Federal Deposit Insurance Corporation (FDIC) Office of Inspector General’s (OIG) audit of system controls over the Risk-Related Premium System (RRPS). The RRPS, a major application,[ 1 ] is the FDIC’s system of record for the risk assessment classification of financial institutions and is housed in the FDIC’s Virtual Supervisory Information on the Net (ViSION) Application.[ 2 ] The RRPS contains examination and supervisory action information that is considered highly sensitive and is not available to the public. The objective of this audit was to determine whether the RRPS application provides the appropriate level of confidentiality, integrity, and availability through the use of effective management, operational, and technical controls. Appendix I describes in detail our objective, scope, and methodology. BACKGROUND The FDIC maintains the Bank Insurance Fund (BIF) and the Savings Association Insurance Fund (SAIF) by assessing depository institutions an insurance premium twice a year. The premium amount is based on the balance of assessable deposits held during the preceding two quarters and on the degree of risk the institution poses to the insurance fund. The FDIC’s risk-based premium system assesses higher rates for institutions that pose greater risks to the BIF or SAIF. To assess premiums, the FDIC places each institution in one of nine risk categories using a two-step process based first on capital ratios and second on other relevant information such as the results of:
The RRPS calculates assessment rates based on data from such sources as Call Reports; Thrift Financial Reports; examination data from the FDIC, Office of the Comptroller of the Currency (OCC), Federal Reserve Board (FRB), and Office of Thrift Supervision (OTS); and input from FDIC personnel. In accordance with guidelines approved by the FDIC Board of Directors, the Division of Insurance and Research (DIR) uses this information to determine the assessment rate for each institution. Appendix II contains an overview of the RRPS. DIR performs the assessment process twice a year. During this process, DIR assigns and updates the assessment risk classifications for all financial institutions. The financial institutions receive quarterly assessments based on the assessment ratings. At the completion of each assessment period, DIR meets with the Division of Information Technology (DIT) to discuss RRPS changes that may be needed as a result of possible revised legislative requirements or new system capabilities. When system changes are made, the RRPS is retested prior to the next assessment period. DIR is responsible for the RRPS; however, the Division of Supervision and Consumer Protection (DSC) has the majority of RRPS users (about 2,000). Application Control Guidance The Federal Information Security Management Act of 2002 (FISMA), Public Law 107 347, requires each federal agency to develop, document, and implement an agency-wide information security program to provide security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other sources. Under FISMA, the National Institute of Standards and Technology (NIST) is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for federal agency operations and assets. NIST issued Special Publication (SP) 800-53, Recommended Security Controls for Federal Information Systems, which states that security controls are the management, operational, and technical safeguards and countermeasures prescribed for an information system which, taken together, should adequately protect the confidentiality, integrity, and availability of the system and its information. SP 800-53 defines these security controls as follows.
System Certification and Accreditation (C&A) NIST 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, states that agency officials must have the most complete, accurate, and trustworthy information possible on the security status of their information systems in order to make timely, credible, risk-based decisions regarding whether to authorize operation of those systems. The information and supporting evidence needed for security accreditation are developed during a detailed security review of an information system, typically referred to as security certification. Security certification is a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of a security certification are used to reassess the risks and update the system security plan, thus providing the factual basis for an authorizing official to render a security accreditation decision. The steps performed in the C&A process are dependent on the level of risk defined as low-, moderate-, or high-impact in an operating system. The FDIC has developed a C&A process to validate that the security controls implemented in an information system are commensurate with the risks throughout the FDIC computing environment. In July 2004, the FDIC performed a low-impact C&A for the RRPS which, according to NIST guidance, entails only a documentation review of the controls. Beginning in 2005, the FDIC planned to perform a moderate-impact C&A, which includes extensive testing of key management, operational, and technical controls, for all of its major systems, including the RRPS. The C&A for the RRPS began in August and will be completed by December 2005. RESULTS OF AUDIT The management, operational, and technical controls for RRPS provide reasonable assurance of adequate security. The confidentiality, integrity, and availability of the system and associated data were maintained through a combination of sound controls, including:
Although key application controls generally operated as intended, we identified the following deficiencies in the security plan, software configuration management, and access reviews that could affect the security of the RRPS.
As a result of these deficiencies, the RRPS is exposed to the following risks:
Collectively, these deficiencies pose risks to the confidentiality, integrity, and availability of the RRPS; however, the risks are at least partially mitigated by the ongoing C&A process. FINDINGS AND RECOMMENDATIONS FINDING A: SECURITY PLANCondition: The RRPS security plan, dated March 29, 2005, adequately addressed the RRPS system security controls. However, some of the plan’s elements need to be more fully explained. The results of our assessment of the RRPS security plan based on NIST SP 800-18, Guide for Developing Security Plans for Information Technology Systems, are summarized in Table 1. Table 1: Coverage of Elements in the RRPS Security Plan
During our fieldwork, we provided DIR with the security plan exceptions noted in this report. The ISM, in coordination with DIT personnel, immediately began addressing our concerns. Cause: The deficiencies noted in the RRPS security plan were similar to those identified in a previous Independent Security Review conducted in 2003. The DIR Information Security Manager (ISM) responsible for RRPS did not verify and ensure that all of the previously identified deficiencies had been corrected before the March 29, 2005 security plan was approved. Criteria: A security plan for an information system helps to ensure that agreed-upon security controls planned or in place are fully documented. In addition, the security plan provides a complete description of the information system, including supporting documentation such as the key documents that support an organization’s information security program. Office of Management and Budget (OMB) Circular A-130, Appendix III, requires that agencies prepare security plans for their general support systems and major applications. OMB outlines the minimum controls that must be described in system and application security plans and requires that security plans comply with NIST standards. NIST SP 800-18 states that the purposes of system security plans are (1) to provide an overview of the security requirements of the system and description of the controls in place or planned that meet those requirements and (2) to delineate the responsibilities and expected behavior of all individuals who access the system. NIST SP 800-53, control number PL-1, Security Planning Policy and Procedures, states that the organization develops, disseminates, and periodically reviews/updates: (1) a formal, documented, security planning policy that addresses purpose, scope, roles, responsibilities, and compliance; and (2) formal documented procedures to facilitate the implementation of the security planning policy and associated security planning controls. Further, SP 800-53, control number PL-3, System Security Plan Update, states that the organization should review the security plan for the information system to address system/organizational changes or problems identified during the plan implementation or security control assessments. NIST SP 800-37 states that security plans should be updated and approved prior to the assessment of security controls during the C&A process. FDIC Circular 1310.3, Information Technology Security Risk Management Program, dated July 6, 2005, states that the divisional program manager is responsible for preparing a security plan that documents the management, operational, and technical security controls intended to protect information assets. The circular incorporates guidance included in NIST publications. Effect: The RRPS security plan does not fully address the requirements described in NIST SP 800-18. Therefore, there is a risk that not all appropriate security controls for RRPS have been considered and implemented to protect the confidentiality, integrity, and availability of the system and the data it processes. The deficiencies we identified in the security plan could result in the following:
The risks posed by the deficiencies in the security plan are heightened because of the changing control environment affecting RRPS. As a result of the FDIC’s reorganization and transformation, key RRPS personnel have departed, and the status of the remaining personnel and contractors is uncertain. Keeping policies, procedures, and system documentation as current and complete as possible is critical in ensuring the adequacy of controls for system operations in a changing environment. RECOMMENDATION
CORPORATION COMMENTS AND OIG EVALUATION On September 13, 2005, the Director, DIR, provided a written response that is presented in its entirety in Appendix V of this report. DIR agreed with the recommendation and provided a copy of the revised security plan. The revised security plan adequately addressed the deficiencies summarized in Table 1 of this report. DIR also indicated that the security plan will be modified when: (1) NIST or OMB update requirements for major application security plans, (2) RRPS application controls or procedures are modified, and/or (3) internal reviews or external security audits require modifications. The security plan is expected to be approved by October 14, 2005. The actions taken and planned by management are responsive to the recommendation. The recommendation is resolved but will remain undispositioned and open until we have determined that agreed-to corrective action has been completed and is effective. FINDING B: SOFTWARE CONFIGURATION MANAGEMENT Condition: The RRPS project team did not develop an SCM plan in accordance with FDIC and NIST guidelines. Specifically, the RRPS Project Team did not develop an SCM plan in accordance with the FDIC’s SCM plan guidance. The March 29, 2005 RRPS security plan referenced the RRPS Maintenance Manual, dated November 2002, as the source for maintaining and updating software configuration. The Maintenance Manual contains project documentation references, points of contact, system description, and the process for handling change requests. However, as indicated in Table 2 on the next page, the Maintenance Manual does not adequately address required plan elements specified in FDIC guidelines. Appendix IV provides a detailed description of the SCM plan elements as described in the FDIC’s Software Configuration Management Guidebook, dated July 22, 2003. Table 2: SCM Plan Elements Not Addressed in the RRPS Maintenance Manual
The RRPS Project Team is using two SCM tools in the absence of a formal SCM plan--StarTeam for the software residing on the servers and Endevor for the software residing on the mainframe. However, only two StarTeam capabilities had been implemented at the time of our review--software documentation and a change request facility. The following key StarTeam capabilities have not been implemented:
Key features of Endevor have been implemented to control changes and access to the RRPS software residing on the mainframe. Cause: The RRPS Project Team indicated that factors such as the recent DIT reorganization and contract consolidation efforts affected the completion of the SCM plan for RRPS. As a result, work on both the SCM plan and StarTeam implementation was delayed until June 2005. Criteria: An SCM program ensures that the integrity of the system software is maintained during a system’s life cycle. Key components of an SCM program include developing an SCM plan and using automated tools to track and control software changes. NIST SP 800-53, CM-2, Baseline Configuration, calls for organizations to develop, document, and maintain a current baseline configuration of an information system and an inventory of the system’s constituent components. CM-2 also indicates that an organization should update the baseline configuration as an integral part of information system component installations and should employ automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration. CM-3, Configuration Change Control, states that an organization should document and control changes to an information system. Information system changes should be approved by appropriate organizational officials in accordance with organizational policies and procedures. FDIC Circular 1320.4, FDIC Software Configuration Management Policy, dated July 8, 2003, states that an SCM plan should be developed and implemented for all applications no later than December 31, 2003. The circular includes specific responsibilities and guidance for preparing and implementing the plan. The system development representative (project manager) is responsible for preparing the SCM plan. The circular requires that application SCM plans and SCM tools comply with the procedures described in the Software Configuration Management Guidebook, dated July 22, 2003. Effect: DIT recently completed an organizational transformation that resulted in consolidating the number of application support contractors. The current RRPS contractor was not named as one of the four remaining contractors. As a result, the current contractor may not be supporting RRPS in the future. In addition, DIT has downsized and has lost many personnel, including an FDIC RRPS project manager. To facilitate the reassignment of responsibilities, current and explicit RRPS software configuration management processes must be in place to ensure that system documentation and SCM procedures are understood by new FDIC or contractor personnel. Without an SCM plan, the RRPS could be exposed to unauthorized changes, errors, and omissions that could damage critical data and cause system failures. More specifically, without implementing StarTeam, which contains key features needed for controlling software changes, the RRPS could experience the following:
RECOMMENDATION
CORPORATION COMMENTS AND OIG EVALUATION On September 18, 2005, the Director, DIT, provided a written response to the draft report that is presented in Appendix VI of this report. DIT agreed with the recommendation and stated that the SCM plan template was changed on July 29, 2005. DIT has drafted a new RRPS SCM plan using the updated template. In addition, four of the five StarTeam capabilities identified in the audit will be activated in StarTeam and included in the SCM plan for RRPS. A separate document addressing the workflow control for the approval process will be prepared. The actions taken and planned by management are responsive to the recommendation. The recommendation is resolved but will remain undispositioned and open until we have determined that agreed-to corrective actions have been completed and are effective. FINDING C: ACCESS REVIEWS Condition: The ISM responsible for RRPS reviewed access rights for 21 system administrators involved in the development and production of mainframe applications. However, the ISM did not periodically review the access rights for the majority of RRPS users. DSC has about 2,000 users, and at least 465 users had both read and edit capabilities. During the audit, we asked DSC Regional Managers to review their staffs’ continued need for read and edit capabilities for the RPPS. The feedback we received from 5 DSC regional offices indicated that 75 of the 465 users no longer required the edit capability. The results indicated that 72 of the 75 users no longer needed access because of role changes and that 3 users were no longer employed at the FDIC. The access reviews by DSC Regional Managers are summarized in Table 3. Table 3: Access Reviews by DSC Regional Managers
Cause: DIR’s ISM had not established the roles, responsibilities, and procedures for performing periodic access reviews of RRPS users as required by FDIC Circular 1360.15 and the RRPS security plan. Criteria: User access to the RRPS should be granted based on the user’s need to perform assigned duties and should be terminated when no longer required. NIST SP 800-53 states that an effective information security program should include periodic assessments of risk, including the magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems that support the operations and assets of an organization. Also, SP 800-53, PS-5, Personnel Transfer, states that an organization should review access authorizations when individuals are reassigned or transferred to other positions within the organization and should initiate appropriate actions such as closing old accounts, establishing new accounts, and changing system access authorization. SP 800-53, PS-4, Personnel Termination, states that an organization should terminate system access when employment is terminated. FDIC Circular 1360.15, Access Control for Automated Information Systems, requires the ISM to review the assignment of user rights to sensitive information systems within his/her specific division or office. The RRPS security plan states that the ISM should review RRPS user access rights semiannually to determine whether users need them to perform their responsibilities. Effect: Without periodic reviews of users’ access rights, there is a risk that improper disclosure and/or unauthorized changes to RRPS data could be made by individuals no longer needing the read/edit capability. However, this access risk has been mitigated because: (1) DSC users’ read and edit access is limited to the banks assigned to their respective Case Managers;[ 6 ] (2) Case Managers are required to manually record any changes that are made and to provide comments in the RRPS about the changes; and (3) after the caseload[ 7 ] is reconciled, the Case Managers send the hardcopy logs and management reports semiannually to the Assistant Regional Director for approv`al. RECOMMENDATION
CORPORATION COMMENTS AND OIG EVALUATION DIR agreed with the recommendation and provided a copy of the procedures in the revised security plan. The revised security plan included the roles, responsibilities, and procedures for conducting periodic reviews of all RRPS user access rights. As stated earlier, the security plan is expected to be approved by October 14, 2005. Management’s planned action is responsive to the recommendation. The recommendation is resolved but will remain undispositioned and open until we have determined that agreed-to corrective action has been completed and is effective.
Objective The audit objective was to determine whether the RRPS application provided an appropriate level of confidentiality, integrity, and availability through the use of cost-effective management, personnel, operational, and technical controls. Scope This audit is one of three audits being performed as part of an overall review of the RRPS process. The results of the other audits, Audit of FDIC Assessments and Designated Reserve Ratio Determinations (Assignment No. 2005-032) and Audit of the FDIC’s Risk-Related Insurance Premium System (Assignment No. 2005-033), will be issued in separate reports. This audit covered the period from January 1, 2005 through June 30, 2005 and included the data upload for the financial institutions’ December 31, 2004 Call Reports. Methodology To accomplish our objective, we determined whether the input, output, and processing controls minimized the risks of errors, omissions, and unauthorized access. Specifically, we:
We performed audit work in DIR’s Washington, D.C., office and DIT’s Virginia Square office. We performed the audit from April through July 2005 in accordance with generally accepted government auditing standards. Internal Controls We performed an assessment of the RRPS internal controls, including the control environment, risk assessment, control activities, information and communications, and application monitoring. As discussed in the audit report, we identified control weaknesses. Most significantly, as a result of the FDIC’s restructuring and transformation activities, key FDIC and contractor personnel have departed. This loss of continuity could have a negative impact on the control environment and control activities. Keeping policies, procedures, and system documentation as current and complete as possible is critical in ensuring the adequacy of controls for system operations in a changing environment. Performance Measures In relation to the FDIC’s Insurance Program, the FDIC’s 2005 Annual Performance Plan states that the RRPS will be enhanced consistent with the improvements that are implemented for the ViSION application (which houses the RRPS). The RRPS has been enhanced and is undergoing additional enhancements consistent with the performance goal in the 2005 plan. Reliance on Computer-based Data As part of our audit objective, we assessed the reliability of the data in the RRPS system. Specifically, we compared the data in RRPS to the data received from external sources as part of the data integrity tests performed (see Appendix III). We did not compare system data to internal source data because that comparison was performed under another audit assignment. For purposes of this audit, the data was sufficiently reliable to support our audit conclusions.
* The accuracy of the data input into RRPS was not tested as part of the data integrity tests in this audit because (1) the other systems that RRPS obtains data from included built-in edit checks and (2) we are testing the accuracy of data input into RRPS by DSC personnel as part of a separate, ongoing audit.
This table presents the management response on the recommendations in our report and the status of the recommendations as of the date of report issuance.
b Dispositioned – T | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
