"...the use of FOSS does not pose risks that are fundamentally different from the risks presented by the use of proprietary or self-developed software. However, the acquisition and use of FOSS necessitates implementation of unique risk management practices."

Federal Financial Institutions Examination Council

Infrastructure Open Source Software (OSS), including middleware, database packages, and the Linux operating system, is increasingly being deployed by financial institutions. Many OSS packages are selected and incorporated directly into custom applications by developers, thus bypassing traditional purchasing channels and their attendant legal, standards, and technical review processes. Because of this, Information Technology (IT) management is often unaware of the OSS running in their data centers, and sometimes support and maintenance measures are not in place for OSS running in production applications.

With the advent of regulatory structures such as the Basel II accords, the reliability of computing systems is increasingly subject to regulatory scrutiny. Not having adequate support and maintenance measures in place creates a significant compliance risk for financial institutions. This article describes these risks and outlines best practices for an anti-failure program that brings systems depending on OSS packages into compliance while reducing overall operational risk.

Open Source Proliferation

Strategic, forward-thinking IT organizations within financial services typically depend on custom business systems for competitive advantage.Unlike later-adopter organizations, these companies invest beyond the traditional portfolio of off-the-shelf applications, creating custom business systems to enhance their position in the marketplace. In these organizations, time to market and innovative functionality can mean the difference between success and failure of a new product or service. Tighter budgets and outsourcing pressures compound these competitive demands.

In these types of high pressure environments, elite development teams naturally seek out innovative OSS to accelerate time to market and enhance application functionality. OSS packages often evolve more quickly and incorporate more cutting edge features than vendor-controlled, standards-bound software implementations. Some of the reasons development teams choose OSS include:

• Increased flexibility in how problems are fixed, new features are added, and other packages are integrated
• Innovative features: increasingly, OSS has moved beyond commodity implementations, such as Linux, to represent the cutting edge of innovation, such as Java/J2EE technology, where developer-driven innovations have outpaced the vendor-driven standards process
• Reduction of vendor lock-in: developers don't have to wait for vendors to add new features or release a new version
• Worldwide technical community: OSS packages often have a wide universe of users to draw upon for information, instruction and even sub-contractor labour; community hubs such as SourceLabs SWiK amplify the utility of these communities
• Investment protection: OSS provides the same or better level of openness and investment protection than proprietary software
• Ready availability from the Internet: anyone can download and use OSS packages or application components

Because of these factors OSS will continue to proliferate, particularly within organizations that create custom software critical to the operation of their business.

Under the Policy Radar

In most financial service organizations, purchasing software invokes well-documented processes intended to protect licensee organizations from operational and legal risk. Virtually every financial services institution has a policy in place that dictates that no unsupported software can be used. Traditional purchasing procedures are critical to the enforcement of that policy. Because OSS is readily available from the Internet, it bypasses these safeguards. Larger packages, such as database management systems and application servers, are difficult or impossible to deploy in the datacenter without oversight from IT operations, and thus their deployments by large financial institutions are still relatively rare.

In contrast, framework packages, component libraries, applications, and tools can easily be embedded in custom software by application development teams without oversight of central IT organizations and attendant operational risk safeguards. These policy breakdowns and compliance failures often come to light only when systems fail, are compromised, or exhibit performance anomalies. Typical trigger events that bring unsupported OSS to light include:

• Load testing during staging: as an application is subjected to load for the first time, components degrade or fail
• Upgrade of a component: unforeseen failures due to inadequate testing procedures or accountability in the OSS community
• Internal maintenance breakdown: to maintain confidentiality and insulate themselves from legal risk, organizations often maintain their own customized internal version; as the time and personnel cost becomes untenable, systems relying on this forked component are placed increasingly at risk

Special Issues Relating to OSS

Due to the current regulatory environment, issues of systems reliability affect financial services firms more acutely. Increasingly, banks and other organizations are required to demonstrate adequate attention to the operational risk inherent in their computing systems.

The reasons for IT project and business failures include several that are typical of unsupported OSS projects. These reasons include:

• The use of technology in a way or at a scale that hasn't been attempted before
• Lack of measurement and tracking systems, leading to an inability to identify that failure looms or is occurring

While these risks are not new to most IT leaders, the legal and regulatory environment surrounding the financial services industry creates a new urgency as failure to address these risks may result in prosecution and incarceration. The effects of system failure in financial services can be enormous. While many are hidden from public view, some failures can border on the spectacular. Because of this type of exposure, the Basel Committee on Banking Supervision has stipulated allocation of capital to underwrite all operational risks.

While regulatory agency-stipulated timetables for implementing the Basel II accords varies by jurisdiction and type of institution, one of the key risks that must be assessed, tracked and offset with capital is the risk related to business disruption or systems failures. Institutions without adequate software support and maintenance measures in place may face higher capital reserve requirements in order to meet Basel II recommendations.

Managing Operational Risk

No computing system is without risk, and due to its inherent transparency, OSS software has less risk for failure than most commercial software. With strong anti-failure measures in place, IT organizations can take advantage of innovations and the cost and productivity advantages of OSS while reducing operational risk.

Critical elements of an effective anti-failure program include:

• Enforce existing support policies
• Make compliance easy: use tested OSS which the organization recognizes as known, supported and maintained
• Create and foster a culture that values data-driven software testing: testing approaches such as CERT7 Certification provide tests that can be adapted to approximate production environments
• Measure support providers' effectiveness: OSS enables free market competition for support services; leverage this development by comparing service offerings and testing responsiveness and value

The program should also establish appropriate oversight for appropriate risk. Key factors to assess include whether the sytem: i) is accessed by customers or business partners; ii) is revenue bearing; iii) is manipulating critical data; and iv) its requirements for availability .

For enterprise IT organizations considering use of OSS in production applications, SourceLabs provides stacks, or combinations of OSS infrastructure software that have been tested and certified to work well together and be dependable under production conditions.

Conclusion

OSS offers financial services firms substantial advantages, and the right policies allow companies to realize the advantages of OSS without increasing operational risk. Due to regulatory compliance requirements, financial institutions need to ensure that OSS usage is covered by their software risk management policies. Reliable support is critical to the successful integration of OSS. Support vendors, such as SourceLabs, who provide pre-tested stacks and production-grade support options can help mitigate the risk of using OSS by financial services institutions.

This article is based on the SourceLabs White Paper Special Considerations For Financial Services Firms Using Open Source.