FinSvcs Working Group (FS-ISAC) Takes on Open Source Components

Applications are becoming the primary security threat vector. Since applications are constructed from 3rd party components, there continues to be a tremendous amount of industry effort and impetus behind managing open source components effectively. Many different initiatives have expanded their focus to ensure proper governance of components, including:

• Updated specifications like OWASP and PCI
• Industry analysts including Gartner
• Community efforts like the Trusted Software Alliance

And now we can add the Financial Services / Information Sharing and Analysis Center (FS-ISAC) to the list. The FS-ISAC started the Product & Services Committee working to identify appropriate security control types for third party service and product providers. This effort is due to the fact that the application represents the "new perimeter". The working group references Gartner research that states “since enterprises are getting better at defending perimeters, attackers are targeting IT supply chains.”. The report continues to state, "recent breach reports such as Verizon’s Data Breach Investigations Report underscore the vulnerability of the application layer, including third party software. This new perimeter of third party software must be addressed."

The report addresses three suggested control types that should be implemented based on the new supply chain reality:

1. vBSIMM process maturity assessment
2. Binary static analysis
3. Policy management and enforcement for consumption of open source libraries and components

Sonatype is pleased to be referenced in the FS-ISAC report as a preferred vendor for Control Type 3. The working group contrasted the Sonatype approach with existing vendor solutions in the third control type section:

Attend our upcoming FS-ISAC webinar featuring Jim Routh from Aetna, a member of the FS-ISAC Product & Services Committee who will talk about the primary drivers for these recommendations and more about the recommend solution. I've highlighted an overview of my take on their key recommendations.

Why is Control Type 3 Needed?

The FS-ISAC explains the importance of the control type by stating:

• "It (Control Type 3) is included as a control because it represents how the supply chain is feeding internal software development processes within financial institutions today."
• "Open source code is available freely and reviewed by many independent developers, but this does not translate into software components and libraries free from security vulnerabilities."
• "The more these open source components are shared, the more widespread the vulnerabilities become. Therefore, it is essential to have a control to protect the flow of open source components into the development process."

Sonatype completely agrees with these statements as our research shows that the average application now consists of 90% components - that's not to say that 90% of applications use components - 90% of each application is made up of components!

Key FS-ISAC Recommendations

Here are the key working group recommendations that I teased out from the article, along with some additional considerations:

"… a combination of using controlled internal repositories to provision open source components and blocking the ability to download components directly from the internet is necessary for managing risk."

• Sonatype's take: A repository manager that supports security, licensing and architecture policies is the foundation for managing access to trusted components. But you can't stop with the introduction of a golden repository - you need policies for the release management process that helps manage the build promotion and staging process. And you should extend your governance approach across the entire application lifecycle - for both development and production.

"Financial institutions should consider options in this control type to apply policies to the consumption of open source components and to specify methods for creating and managing an inventory of open source libraries in use within the application portfolio."

• Sonatype's take: To keep pace with the volume, variety, complexity and release cadence of components, the policy approach requires automation. And we aren't talking about an automated approval workflow, we are talking about automating actions that enforce stage-appropriate behavior across the entire software lifecycle. This approach frees your human resources to optimize policies and address exceptions.

"Firms should also encourage use of mature versions of software that are patched and not yet obsolete by applying policies and enforcing them using the best methods available."

• Sonatype's take: To accomplish this effectively, developers and architects need component intelligence that is version specific. They need security, licensing and architecture guidance integrated directly in the tools that they use, and they need actionable guidance, including the ability to migrate to new component versions.

"It is time to apply resiliency controls to the consumption process that will reduce the requirements to fix old versions with vulnerabilities after they have been deployed. Controls should encourage deployment of current versions that have been determined to be resilient."

• Sonatype's take: Developers have lacked the information necessary to easily select the right components. This limitation has resulted in downstream issues that elongate the development process. It's too much to ask the developers to research all of the components and the component dependencies, and if you institute an approval laden process, the developers will bypass the process to make their deadlines. Developers need component intelligence integrated into the IDE so that they can select optimal components from the start - components that meet your security, licensing and architecture policies.

"Providing more information to architects and developers is the responsibility of the information security staff. The information should improve the understanding that policy management applied early in the lifecycle will both cost less effort and speed up time to market in the long run."

• Sonatype's take: Numerous studies confirm that fixing flaws late in the development process or in production is extremely costly. Current application security solutions exacerbate this problem because results are delivered late in the process. The developers weed through an extensive list of "possible" vulnerabilities after or during the QA process, which creates resistance and ill will. The FS-ISAC working group has it right - the information security staff has to provide information to the architects and developers, in a way that is easily understood and consumed. Most importantly, the guidance has to drive action, it can't be limited to a potential list of vulnerabilities.

You can download the entire FS-ISAC report here.