We've heard the fateful story of the Target hackers breaking into company systems using network credentials taken from its refrigeration and HVAC provider. In the worst-case-scenario story, a network security shortcoming was compromised from seemingly one of the unlikeliest of places.

The major data breach served as a glaring example of third-party vulnerabilities and the risk they can introduce to an enterprise. In today's technology ecosystem, it is not just about maintaining internal security but also about weighing risks that could appear outside a company's cybersecurity framework.

With the transition to service providers and using cloud offerings, security concerns began to fall outside the purview of the enterprise and instead fall to workloads and relationship processes. That has led to the rise of vendor risk management problems, according to Jim Hurley, a research director at ISG.

As one of the case studies in Verizon's 2017 Data Breach Digest points out, many third-party entities — as well as some legal and regulatory frameworks — view security obligations related to a company's data as the company's responsibility. Meaning, third-party organizations don't always hold themselves accountable for security shortcomings.

The burden of protecting an internal network often falls to the companies engaging with third parties, adding an extra layer of security difficulty. While an organization might know the intricacies of its network and be able to assess for any suspicious activity, a third-party provider does not offer that level of transparency.

More companies are starting to focus on putting a specific third-party risk management program in place. "Many of the hacks and the data breaches that happen historically, they have actually started [from] a third-party that was not actually fulfilling or executing the minimum amount of information security controls to secure the information of the customer that is hiring them," said Leonel Navarro Segura, information security global practice director at Softtek.

In the past few years, companies have tried to understand why a breach can happen, including what variables can contribute to a breach, according to Navarro. But understanding how third-parties can come into play remains a huge challenge.

Managing the vendor ecosystem

For most companies, the risk of using third-party providers is worth the reward of being able to cut down on internal resource investments and to streamline processes. It is far easier to tap another organization with specialization in an area of technology rather than trying to grow a capability internally.

But third-party integration does not always happen at the code or resource level. Rather, third parties represent a vast ecosystem, a supply chain of technology that makes a company function. But each part of the technology supply chain, from the cloud service providers to the disaster recovery specialist, can introduce risk.

"To build pervasive security across that third-party ecosystem, you not only need to know who those third parties are and what they're doing for you," said Edna Conway, chief security officer, global value chain at Cisco, "you had best understand the leadership and the operational processes utilized in your own enterprise that manage the commercial relationship with those third parties." 

Mitigating third-party risk often comes down to what a company's security expectation is. For example, the security expectation would vary with a cloud service provider depending on whether an organization is employing the service or building it into one of the cloud solutions it offers.

A company could not function with severe security controls. Instead, you want an architecture that is flexible and relationships with senior leaders of every enterprise organization that monitors and uses a service or product in a third-party ecosystem, according to Conway.

"All of the sudden you have a fantastic network with tentacles everywhere who drive pervasive security, flexibly bending as you need to," Conway said. "And rather than building under a CIO, for example, or even a CISO, one system, you leverage the existing systems, tools, processes and humans inside the organization that interact directly with those third-parties."

Understanding who is accountable for ensuring transactions with third-parties remain secure can go a long way toward reducing risk in the enterprise. To some degree, buyers can dictate service terms and conditions as part of the vendor management process.

Within the last three years, companies have started to include specific clauses in contracts that talk about liabilities and security requirements a third party needs to meet and prove, according to Navarro.

Conversations are at least opened now about third-party risk, Navarro said. "It's a win-win for the customer, [the] third party and whole industry if they can start reducing risk."

Even with greater leverage over the supply chain that doesn't absolve an organization of risk. No matter the third-party visibility, companies still retain risk.

"The core issue here for the organization is being able to assess on a relative scale whether the risk is [increasing]," Hurley said. Organizations need to understand where risk is being introduced, as sometimes it has nothing to do with procedural or technical control that information security can bring to bear to minimize actual business risk.

The flaw in the code

Third-party risk, however, does not always stem from subcontractors and members of the vendor ecosystem. Instead, third-party risk can be introduced at the code level, as programmers use open source techniques to streamline application development.

Researchers at Veracode estimate 80% of the code used in software libraries today stems from third-party libraries or components. And when developers share code, they can also share security defects.

Most cloud environments are built around 70-80% open source, according to Justin Somaini, chief security officer at SAP. Nested source code without an identified or vetted origin can introduce another layer of risk.

To help prevent this, SAP does a lot of source code vetting, relying on an internal repository for source code and also conducting a source code "pedigree."

"It's really driving an education to the developers as they're developing faster, using more technologies out there, it only stresses the need for them to be an educated participant in that security conversation," Somaini said.