Waking Up to Third-Party Security Risk

One misconfiguration can compromise nearly all of an entire country's financial data in the new realm of third-party risk management. Witness the attack on Capital One, a financial services giant that exposed hundreds of millions of people's sensitive financial data because of a poor security configuration in a third-party service, Amazon Web Services. That attack could happen to any company today; most have no inventory of their third-party risk and are prime targets for hackers.

Third parties — including partners, suppliers, and cloud hosting services — that are directly linked to your networks are one of your largest risks for a damaging security breach. A 2018 study by the Ponemon Institute found that almost 60% of companies surveyed had suffered a data breach caused by third parties or vendors in the last year.

What's causing more third-party risk? First, the way both internal and external (customer-facing) applications are built today is very different than a decade ago. Today, applications are composed of multiple smaller services: microservices. These may be for simple internal tasks — delivering a feed of alert data — or for complicated services delivered via a software-as-a-service. All services connect, internally and externally, via APIs. When popular finance websites, for example, load on your browser or in mobile apps, the results you see are built by dozens of third-party services for specialized capabilities like calling a news feed or a share price, or pulling location data.

Additionally, web applications, middleware, and other code increasingly are built with third-party code components. Popular JavaScript libraries may be used by millions of sites even though the maintainers of the library are not well known. Third parties may also be tenants or customers for a cloud hosting service or a SaaS service. According to a survey of IT and security pros by Tripwire, 60% of organizations have suffered a container security incident. What does this mean? Hackers see multitenancy and services that share space or resell services to multiple customers as a viable path to a breach. 

Worse, increasingly, services are nested. A third-party SaaS service is composed of multiple additional third-party services and libraries. Called Nth-party services, we are now in an era of exceptionally hard-to-measure and, more importantly, hard-to-manage risk. Any critical information deployed to major cloud hosting services or SaaS applications, or on shared networks, may be exposed to the risks of every other user of those services and networks.

How to Protect Yourself from Third-Party Risk
You cannot rely on the words, intentions, or security measures of others to guard your company, customers, and brand against this growing risk. Protecting your critical IT infrastructure and applications requires a multitiered approach.

Step 1: Protect Your Own Infrastructure
Assume that protecting your own infrastructure is now a 24/7 task. This means vigilance must be continuous. Firewalls, antivirus, and all other security controls must be properly updated and configured all the time. Smart security teams should continuously test their controls and networks for security weaknesses.

The best tool for this testing is found in breach-and-attack-simulation (BAS) platforms that tap frameworks of known attacks, such as those from MITRE, and allows teams to run round-the-clock simulated attacks. Good BAS systems are highly tunable, allowing security teams to not only test against the entire playbook of known exploits but also to create compound exploits focused on the tools and software that their organization uses in its own infrastructure.

Step 2: Demand Others Protect Their Infrastructure
Demand that third-party organizations certify they are running similar protections against their own infrastructure as a condition of partnership, purchase, or granting access to your data. This is even better than requiring proper compliance and certifications, such as SOC 2. The certifications represent a snapshot in time that may not reflect the current reality.

With regard to risk from third-party libraries and open source code, it is critical that organizations actively audit, monitor, and validate this code. This is an extra step. Running static code analysis against open source libraries takes time and effort, for example. Fortunately, a growing number of services are checking and certifying open source code. So rather than run the testing yourself, you can probably pay for one of those services.

An additional step: Require third-party partners or customers to maintain a database of all known third-party connections and exposures. This may sound cumbersome, but in reality, it is good security hygiene both for you and your service providers, or for the platforms you use. Few companies today can produce this information. But if they could, it would allow them to not only do a better job of proactively guarding against attacks but would also help them identify the source of a breach more quickly.

Step 3: Test More Because We Can't Go Back
This new way of running our technology infrastructure is beneficial in key ways: It allows teams to build applications faster and scale more quickly, and it prevents us from slipping back into the old practices of fewer and more brittle connections. A breach can happen quickly, doing millions of dollars of damage before the attack is stopped. With third-party risks, an ounce of prevention is better than many pounds of cure.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Criminals Hide Fraud Behind the Green Lock Icon."