Between a Rock and an Outsource Vendor
It is one thing to scrutinize 3rd party software development vendors on their security practices, selecting the best vendor. But what if you wonder what to do about your long-established software development vendor relationships? And what if you heavily rely on your vendor because you outsourced most, or perhaps all, of your software development some time ago?
Implementing a security program with software development vendors in existing relationships is not so easy. Demanding secure practices that are not in the vendor contract or necessarily part of product advantage sets the stage for ruined partnerships. But your company is still responsible for security issues that result from your vendors. There are positive steps that can be taken to create a "win-win" situation for company, vendor, and customer.
A Fine Mess
For many companies, utilizing outsource vendors makes sense for cost savings and leveraged skillsets. The vendors become an extension of your own product teams and company; a veritable part of the company. In companies that specialize in devices for controlled environments, outsourcing makes even more sense. For instance, take specialized devices for healthcare. A healthcare company focuses on special-purpose hardware devices as their market strength while their software vendor provides the custom applications needed to support them. Over time, companies that outsource their software development create strong, integrated relationships with their vendors. Creating value, specialization, and flexibility enhance a partnership that solidifies with each product release.
But times change. Customers want more Internet based software, often integrating related products in the marketspace. Dashboards that unite data from your device and competitors bring value with consolidated views and decision making features. Adding a mobile application increases product reach as users want even more mobility. Now, you are no longer a device manufacturer but a data integrator with more demand for programming solutions. You are not alone with companies like agricultural equipment manufacturer John Deere and Xerox that are now in the data marketspace as much as the hardware realm.
So what is the problem? When the contracts were created with your software development vendor, security was not nearly as much a concern. Then, your software was not at as much risk because of your limited demand for applications with Internet exposure. Like many, you consider the software vendor so integrated into the company business model that very few programmers are kept to oversee the vendor; those left are really architects that identify software product
requirements. In fact, you refer to the vendors as "part of the team". But a vendor is separate from your company. And companies, especially vendors, rely on signed contracts as the rules of business. The same contracts that may have few (or worst case, any) security requirements. The bottom line is that a deeply imbedded vendor may not be inclined to add security. And nobody really wants to rock the partnership boat. What do you do?
Regulation Makes it Worse
In the case of regulated industries, like healthcare, insurance, banking, aerospace, working for the government, etc., regulation applies to you AND your vendors. With security laws in 47 US states, it’s hard NOT to be regulated. When a security breach happens, the primary company and not as much the vendor are held accountable. Increasingly, companies that outsource cannot simply expect that vendor practices are not important and that only a secure end product is what counts. Through regulations like FISMA and HIPAA, the underlying systems, policies, and processes that create software are under scrutiny. And the pattern for assessing security value is echoing into the general software industry, too.
Let the Best Vendor Win?
Choosing the best vendor for company criteria was the original reason you are in the current software development vendor partnership. Why not reassess that partnership for more than just business value, but also for security value too? If the current vendor cannot or is unwilling to include security, then off with their heads and another one will take their place!
But it is not that easy. Aside from the business hit and upheaval of ending a long-term vendor relationship, many development vendors are sometimes not savvy on security. According to a study by Veracode, a leader in code-based application security, only 38% of vendor applications comply with enterprise-defined security policies and only 10% comply with commonly accepted security standards like OWASP. Many vendors want to practice more secure application development, but the efforts must integrate with the enterprise's security programs and relevant Federal and local laws; with many vendors offshore in countries like India or Ukraine, knowing regulatory requirements is very difficult.
The Man in the Mirror
The Santa Fe Group, a leading strategic consulting company on vendor risk, cites that issues in consistent enterprise policies, procedures, and governance are a major source in client-vendor gaps for ensuring software security. That means security starts within a company and is conveyed to vendors. In many cases, the vendors may have some security practices mastered, but most will need direction from. . . you, the company.
How can a vendor be expected to provide secure software development if its employer company does not have or practice security methodologies itself? The security policies, practices, and methods of the company become the criteria for vendor success. Otherwise, the vendor defines "secure enough" and the company has to accept the assurance for lack of anything better. In addition, many methods to assess vendors are lackluster because the underlying security efforts within the company evaluating them are weak.
According to a study by Veracode, a leader in code-based application security, enterprises with a structured security program are key with 45% of vendor applications becoming compliant within a short time period. The security program starts not with the vendor but the company. Change starts with the company examining itself in a mirror - and defining a security program.
Bootstrapping a Risk Management Framework
Let's face it, for better or worse, your vendor is integrated as part of your company and that should be the focus of your security program efforts. Approach any security changes as across the entire enterprise without singling out any software development vendors. Make the changes incremental, focusing on the most valuable and less disruptive approaches.
Here are guides on how to bootstrap a risk management framework (mileage varies by security program level of maturity and that of your vendor):
Begin an Information Security Practice - Security starts with establishing an environment of security awareness that is not an afterthought and built into efforts. Create an initiative with a mission to integrate security practices throughout the enterprise, with the vendor included. This act gives context to future changes, gives vision on an end-state for whatever process framework you choose, and will tell soon enough if your vendor is willing to participate. But to start, keep the mission simple.
Do Risk Assessments - Start with a Security Gap Analysis to identify the key security practices that are (or not) being done and the software applications most affected. Focus on the critical practices and applications for reducing risk levels. Thereafter, perform risk management assessments regularly so they become a triage tool and guide for security efforts.
Set Security Requirements - For software outsourcing, identify security practices or mitigations to known vulnerabilities that put your software at risk and make them security requirements along with normal feature requests. In the beginning, this approach is a stop-gap to addressing specific security flaws, but over time can be adjusted to include coding standards, risk assessment methods, and security tools as part of a repeatable process. Draw on ready security flaw lists like the OWASP Top 10, CWE/SANS Top 25.
Introduce Audit and Accountability Controls - Everybody knows that they are responsible for ensuring secure software, but proving it is the next step. Introduce review gates throughout the software development, testing, and release process where vendor and enterprise understand the security risks found and agree on next steps.This step includes using security tools to actively scan code for flaws, developers using techniques for secure code, and a conscious effort to manage security as an aspect of the development process. The Microsoft Secure Development Lifecycle (SDL) is a good example. This aspect of the vendor relationship is not easy - it requires integrating new processes, tools, and oversight into the normal development cycle, but it need not be burdensome.
Training, Awareness, and Measuring Success – Finding and fixing security risks each development cycle can be an infinite loop if nothing is learned from previous efforts. There needs to be an ongoing effort to educate all sides on preventing security risks and monitor whether it is working. Introduce coding standards, encourage discussion groups, and eventually reward vendors and enterprise employees for measures that reduce security risk.
The Rising Tide
Information security in increasingly becoming an issue of software quality, impacting customers directly. The recent Target, Marshalls, eBay and Verizon data breaches in 2014 alone are causing changes in the quality of software security. Government laws like the Affordable Care Act (ACA) and FISMA will affect private sector security. The suggestions in this article will gradually introduce and improve vendor, as well as enterprise, security.
By working collaboratively with your existing vendors and implementing security mechanisms that are also software quality improvements, there is the promise of cost savings and stronger products. In the end, including security in your products means not just expecting trustworthy development from your vendors, but also leading what you want security to be within your enterprise as well.
Some companies wonder what to do if a vendor doesn’t wish to adopt their security practices. What if a company conveys security is a business value, while introducing a paced and reliable means of achieving it, and a long-established vendor says no? Employees that resist change and following corporate vision are eventually asked to leave the company. Vendors are “team members” aren’t they?
~ Kenneth Silsbee
Kenneth Silsbee is an independent Information Security and Technology Consultant with over 20 years of experience in IT, over 14 years in Information Security, 6 years as a software consultant, and contributions to two start-up companies. He specializes in building Information Security programs and works with clients in HIPAA, FIPS/FISMA, and PCI.
