skip to main navigation skip to secondary navigation skip to content
Board of Governors of the Federal Reserve System
skip to content

Review of Board's Implementation of Software Security Reviews

We began this project as a result of questions raised during our 2004 annual audit of the Board's information security program. During that audit, we noted that the Board's information security program document incorporates procedures for performing software security reviews (SSRs) based on requirements in its Information Security Manual (ISM). Specifically, SSRs are required on single purpose software that is used by business functions with a risk level of moderate or high. Because the 2004 audit identified at least one software package for which a review had not been performed, we conducted additional work.

Our initial scoping work found that limited SSRs have been performed at the Board. We also found that the Board is transitioning from compliance with the ISM to compliance with requirements promulgated by the National Institute of Standards and Technology (NIST). Our work showed that NIST does not specifically require these reviews, although having proper software controls in place is discussed in a number of NIST publications. Based on these factors, we closed this project.

In closing the project, however, we provided a report to the Board's Chief Information Officer (CIO) in which we recommended that the CIO develop guidance to ensure that single purpose software and other software products are evaluated as part of a general support system, as part of an application security review, or on an individual basis as appropriate. The CIO did not concur with our recommendation and concluded that developing specific guidance for reviewing single purpose software would not be cost-effective. Our recommendation was designed to address not only single purpose software, but also other software products–such as mainframe or telecommunications software–that we believe should be analyzed for potential threats and vulnerabilities, and to help ensure that software does not introduce vulnerabilities or circumvent existing controls. These evaluations can also help set configuration requirements which can then be promulgated throughout the Board. We will continue to review the Board's process for establishing, documenting, and evaluating security controls as part of our ongoing FISMA-related work.

Last update: November 6, 2009