Streamlining Software Risk AssessmentsFS-ISAC Issues White Paper on Best Practices
Financial institutions lack best practice guidance on how to assess the risks posed by software, including cloud-based applications.
But a new white paper from the Financial Services Information Sharing and Analysis Center offers insights on a streamlined approach to assessing software risks. FS-ISAC is an information-sharing body for the financial services industry, one of several established to help protect the United States critical infrastructure.
The paper, "Appropriate Software Security Control Types for Third Party Service and Product Providers," should prove helpful to banking institutions and insurers that are struggling with software vendor management issues, says Jim Routh, chief information security officer for health insurer Aetna. He's a member of the FS-ISAC's Third Party Software Security Working Group, which developed the white paper.
"The mid-sized banks and insurance companies are relying on conventional controls for vendor management, and they just aren't effective at addressing software security," Routh says. "This white paper intends to address that gap."
A software vendor that builds a security compliance model based on the risk assessment guidance and security controls outlined in the white paper could use the same model for multiple customers, Routh explains.
"If a particular vendor is selling to 100 different customers and that vendor has to have different requirements for all of its customers, then that's not scalable," Routh says. "So the intent here is to establish control types so there is a consistent use of controls across the industry."
A New Model
In addition to Aetna, the FS-ISAC working group that developed the white paper includes representatives from Morgan Stanley, Thomson Reuters, Citibank, Capital One, Goldman Sachs, RBS Citizens Bank, JPMorgan Chase, GE Capital, Fidelity and the Depository Trust & Clearing Corp.
The white paper relies heavily on modifications of the Building Security in Maturity Model. That assessment model, developed by 67 firms from various sectors, including financial services, telecommunications, retail, insurance, healthcare and energy, was released in March 2009; it has been vetted by numerous software companies, Routh says.
"BSIMM over the years has proven that software security controls that are effective apply to third-party software development just as they do to internal software development," he says. "But here, we are trying to be a little more prescriptive about the controls to add to a third-party governance program, and to help vendors apply those controls."
The new FS-ISAC working group, in its white paper, provides a questionnaire and assessment process. "So the vendor could go through this assessment for one FI [financial institution] and not have to go through it again for a different institution," Routh says. "And this framework is available and shared with FIs and any industry partner that wants to use it."
The paper outlines three recommended controls for third-party service providers: a risk assessment, a post software release analysis and restricting use of open-source code libraries.
The working group recommends a single risk assessment and questionnaire for each software vendor that can be shared among banking institutions, Routh says. Then, as new versions of the software are released, the paper recommends the use of an automated scanning control, known as binary static analysis, he adds.
This scanning control involves analyzing vulnerabilities for a specific software version once it hits the market, Routh says. Two independent vendors should conduct the binary static analysis and then share their results with the software provider, the paper recommends. The results of this analysis should be summarized in a report available to any organization requesting it, Routh explains.
Finally, the white paper calls for the use of another security control to address open-source software components, Routh says. "It's a policy management framework; essentially a way of identifying and restricting the use of open-source code libraries," he says.
Industry Adoption Is Critical
The success of this control model will hinge on the number of organizations that participate, Routh adds. Getting buy-in across the financial services industry will be the hard part, he acknowledges.
"We all recognize there is a need for the implementation of controls, but the mechanics of how we do that is where there's probably a little more variance," Routh says. "The current controls and assessment processes that are used by financial self-service firms [such as banking institutions] do a good job for IT management, but the software security controls have kind of lagged."
Al Pascal, a fraud expert and analyst with Javelin Strategy & Research, says the guidance from FS-ISAC fills a need. The financial services industry must encourage software vendors to enhance their security, he stresses.
Financial institutions deliver "dynamic products and services, which may involve relying on vendors that are not accustomed to the secure coding practices typical of the financial industry, the constant barrage by cybercriminals against an attack surface that is growing as more services are brought online, and a regulatory regime that is holding the banks ultimately responsible for security failings," Pascal adds.