Who is responsible for software safety? Nobody is no longer an option

Bob Brennan, CEO, Veracode

Regulation. While many see it as a dirty word, when you take a look around, regulation has historically only been implemented when addressing public safety, or when industries have failed to self-regulate on their own, leading to unstructured chaos. In the early 1900's, Upton Sinclair's “The Jungle,” exposing unsanitary practices in the Chicago meatpacking industry, was a call to action to better protect our food. Sixty years later, in 1965, Ralph Nader's “Unsafe At Any Speed” led to sweeping regulation and reform in the auto industry.

In both instances, the food and automotive industries failed to self-regulate, paving the path for the government to step in. Today, we're seeing that same potential of unstructured chaos in our financial institutions, with an onslaught of cyber attack after cyber attack hitting the world's largest banks, and ultimately, consumers.

In the wake of recent attacks, many are wondering how the largest banks in the United States could possibly have security holes for cyber attackers such as organized cybercriminals and nation states to infiltrate. And we have every right to think this way, as it can be easy to forget that these large banks and other corporations have vast internet-facing surface areas susceptible to cyber threats.

The top financial institutions in the U.S. leverage tens of thousands of third-party software vendors, all running independently but interconnected, that at any moment can become a point of entry for cyber attackers that tirelessly search every facet of a company's web perimeter looking for potential weak spots. And as we've recently learned, those weak spots are often created by third-party websites that haven't undergone the same high level of security scrutiny as the company's internally developed applications.

Still, there are financial czars like Benjamin Lawsky, New York State's first superintendent of financial services, who want answers.

Mr. Lawsky recently sent a letter to dozens of banks looking to better understand their third-party vendors' information security risks, stating that “it is abundantly clear that, in many respects, a firm's level of cybersecurity is only as good as the cybersecurity of its vendors.” But it's doubtful that banks will be able to supply a satisfactory answer – not because of lacking concern or interest, but because they simply cannot know without having a scalable and systematic approach to addressing third-party vendor risk.

To elaborate, the process for software vendor security is currently dominated by the manual collection of unaudited questionnaires (yes, questionnaires!) about the vendor's internal security practices. These questionnaires are generally filled out at the time of purchase of a software product and rarely are readdressed, even years after the software is introduced. With thousands upon thousands of vendors, it easy to see how the process can become muddled and inefficient.

Yet despite the cumbersome logistics, banks should not be able to transfer blame. They have a responsibility to know the ins and outs of whom they are doing business with. So what are banks to do now that they can no longer say “it was my vendor?” There are really only two options: regulate or be regulated.

Perhaps this requires a new set of guidelines and best practices. It would make sense. Why should banks be any different then hospitals, car manufacturers, or food producers? Lawsky's call to action sets the wheels in motion, but banks can avoid potentially unwelcome regulations as long as they take a candid look at their own software landscape through self-regulation. As software is bought, it should be regularly audited for vulnerabilities by an independent third party, and not be deployed until critical vulnerabilities have been addressed.

To self-regulate banks would have to find a way to ensure a truly secure digital ecosystem from the ground up. They would need to insist on independent third-party audits of their vendor software. Since most applications are now built from reusable open source components, they would also need to verify that their applications don't contain critical vulnerabilities such as Shellshock and Heartbleed.

To highlight how big an issue this is, nine out of 10 third-party applications get an F when they are independently audited for security threats. A model system would enable an enterprise to – at a glance – understand which of its vendors is not systematically addressing the cybersecurity of their products and prioritize them for further inspection and remediation.

So how do banks avoid the same regulation once driven from “The Jungle” and “Unsafe At Any Speed”? By demanding that their third-party software applications undergo the same level of security scrutiny as their in-house software. It is now up to banks to pick up on this call-to-action themselves – via self-regulation -- or continue to deal with the pressing questions of concerned officials like Benjamin Lawsky and, ultimately, new laws that may require more transparency and impose financial penalties for non-compliance.