Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

12/12/2019
10:00 AM
Robert Bigman
Robert Bigman
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Waking Up to Third-Party Security Risk

You can't rely on the words, intentions, or security measures of others to guard your company, customer and brand.

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."

With a distinguished 30-year career at the Central Intelligence Agency (CIA), including 15 years as CISO, Robert Bigman is a pioneer in classified information protection. He developed technical measures and procedures to manage the nation's most sensitive secrets. His ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mike.gorman
50%
50%
mike.gorman,
User Rank: Apprentice
12/26/2019 | 6:37:40 AM
3rd party vs. XaaS
 I have a hard time calling AWS S3 misconfiguration a third party risk.  They weren't at any fault, the customer misconfigured the service they purchased, when ample documentation is available.  I agree whole heartedly that people need to understand what their risks are in their business relationships, but that starts with being honest with oneself, too.  Every cloud provider I know has a post somewhere of a shared repsonsibility model.  Security configuration of IaaS services, like S3, are definitely the customers'.  Poor training, lack of testing, monitoring, etc. is what leads to most failures.  Even the fabled Target hack that spawned a large amount of the focus on thrid party seems to me to improperly understood.  Fine, your HVAC vendor was hacked, and some malicious actor was able to use their VPN connection.  Why can your HVAC vendor reach your POS systems?  There must have been plenty of steps along the attack chain that could have been detected and the actions stopped, but no, now we all have to fill out a 73 page 3rd party risk questionairre before we can buy or sell anything, to make folks feel better. </RANT>
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.