Financial service industry takes the lead in curing the third party security headache

Conventional third party controls are no longer sufficient to cover the ever-expanding attack surface presented by web and mobile applications developed by service vendors and/or commercial software providers. The current third party controls established in the past 10-15 years were adopted by financial service firms and incorporated into their respective third party governance programs.

[Web app security best practices and the people who love them]

However, the threat landscape is fundamentally different with the proliferation of mobile, web and cloud based applications supported by third parties. The need for third party software security is so essential that a group of security leaders from the highly competitive financial services sector established a working group through the Financial Services Information Sharing and Analysis Center (FS-ISAC) to provide guidance for the rest of the industry on additive controls to address software security. Though the goal of this working group is to help improve security at financial organizations, enterprises of all kinds can and should adopt this new guidance to address the increasing danger posed by third party applications.

Every industry uses third party software to increase employee productivity, deliver the latest technology to their customers and maintain relevancy in evolving markets. In the financial services industry, this has manifested with mobile payments, hip web interfaces, and banks going social, just to name a few. Financial services has long worked to apply effective controls and protect the sensitive data flowing through these slick applications through the Financial Services Roundtable (BITS) or FS-ISAC. Though there are established controls for protecting information from software vulnerabilities of third party service and software providers, what is not established is how to ensure secure software development practices are applied by those third parties that develop software used by banks, mortgage lenders, and insurance companies.

Spearheading the need to address this risk, a group of ten leading financial service firms came together to identify and recommend control types for securing third party software development.

The working group set out to improve information protection for third party software used to process sensitive data, whether the software was developed by third parties using their own methodologies or using commercial products developed for the marketplace. The control types developed are designed to be incorporated with existing vendor governance practices and work in concert with established third party governance controls.

[Best practices for safely moving data in and out of the cloud]

These controls enable enterprises -- regardless of industry -- to assess the maturity of software providers' secure development lifecycle, ensure a process exists to identify and remediate vulnerabilities of significance, and manage risk associated with consumption of open source code in the development process. There are three control types, two of which apply directly to third party firms that develop software and one that addresses supply chain risk for internal development.

Software security is not easy to apply across large and complex enterprises that develop custom software but significant strides have been made by 67 firms that actually measure the maturity of the controls in the software developed process. The body of information available as a result is in the Build Security In Maturity Model (BSIMM) which is also the source for one of the additive controls recommended for third parties by the working group. The working group members believe that applying software security practices is the responsibility of whomever is leading the software product development process whether that is for an internal development project or one supported by a third party. Therefore, the first control type recommended by the working group focused on the maturity of the practices for the third party.

The second control type identifies security vulnerabilities for a specific version of software at a specific time, using binary static scanning, a service offered by select number of vendors. The advantage of this control type is that it identifies security vulnerabilities and shares them with the third party vendor firm who can remediate the flaws and perform another scan to confirm the fix before sharing the results with the financial institution or client firm. The financial institution never requires access to either the source code or the binaries for the security validation, but still receives a summary report of the vulnerabilities detected once it is released by the third party vendor firm. The first control type determines process maturity while the second one determines the risk of specific vulnerabilities detected or a specific version of software produced by the third party.

[Seven essentials for VM management and security]

The third control type provides a software code management process for development teams that use open source code libraries in the development process. It enables firms to choose versions of open source components they wish to promote to their developers based on use and the security risks of each library and ultimately enforce these choices through policy enforcement in the software build process. Several vendors offer this type of capability and a recently introduced vendor offers a full lifecycle management capability for the consumption of open source code libraries.

It is time the rest of the world's largest enterprises follow the lead of the largest financial services organizations and address the security of applications developed by third parties. Each working group delegate organization has adopted these controls within their own security program and seen reduced risk at the application layer. At the FS-ISAC Fall Summit, the working group will release a whitepaper describing the control types and advice for effectively applying these controls based on our own experiences. The guidance offered through the whitepaper will help financial service and other regulated industries apply controls designed specifically to address the risks of building software for the web and mobile channels.

The working group has now contributed to defining new control types specifically designed for third party software development that help companies ensure that effective information protection practices are in place. These control types enable firms to apply effective controls to the development practices of third parties.

The whitepaper will be available on the public section of the FS-ISAC website in mid-November. Software development practices have evolved in maturity and use within the industry. Companies in all industries that capture and process customer information have an explicit obligation to apply effective industry standard practices for information protection and there are now three more practices to consider to more effectively manage information security risk when working with 3rd parties.

Jim Routh is the CISO of Aetna.

This story, "Financial service industry takes the lead in curing the third party security headache" was originally published by CSO.

To express your thoughts on Computerworld content, visit Computerworld's Facebook page, LinkedIn page and Twitter stream.
Related:
Windows 10 annoyances and solutions
Shop Tech Products at Amazon
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.