Schellman becomes The First ISO 42001 ANAB Accredited Certification Body!

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

How to Manage Access Risk Regarding Third-Party Service Providers

Cybersecurity Assessments

In the legendary Lord of the Rings series, leaders from different societies create a fellowship of nine different people tasked with saving Middle-Earth. The idea wasn’t originally to send nine, and there were obvious reservations about trusting some of the Fellowship with such a serious mission. (Looking at you, Pippin.)

In the end, they all play their important and heroic parts, but there were plenty of doubts. Similarly, there are different risks where businesses depend on third parties for services. What’s more, these third-party service providers are present in almost every business segment or function—your hosting providers, software development, software maintenance services, etc.

No matter what you use them for, there are important considerations to make before inviting a service provider into your operation, and as cybersecurity experts and assessors for over two decades now, we’re going to provide some tips on how to manage the risks specific to granting access so that your organization remains secure despite any necessary outsourcing.

What are Third-Party Service Providers?

Before we get into their risks, we should confirm who we’re talking about.

Third-party providers are any external organization that performs a service or provides/maintains a product for you. To do that, you must grant them certain access to data, which could potentially have security, reputational, business, and legal consequences if something goes wrong—that, we’ll get into later.

Examples of Third-Party Service Providers and Their Functions

For the sake of applied perspectives, here are five of the more common scenarios where third-party service providers are in use and require that associated access:

Infrastructure as a Service (IaaS)

  • Data Centers (Equinix, Rackspace)
  • Hosting providers (AWS, Azure)
  • Facilities management

Software as a Service (SaaS)

  • Communications (Slack)
  • CRM (HubSpot)
  • Software development and version control (GitHub)
  • Databases (MongoDB Atlas, ElastiCache, HANA)

Platform as a Service (PaaS)

  • Orchestration of deployment (AWS Beanstalk, Azure App Service)

Software Development

  • Customized development of websites
  • Back-end application services for changing reporting

SIEM Services

  • General notification of events
  • Incident response services

Risk and Attack Vectors Affecting Your Service Providers

Your third-party providers remain vulnerable to advancing cyber-attacks just like anyone else—especially those with remote access.

In today’s world, remote access to an environment is how business gets done. Unfortunately, it’s also often a common entry point for attackers. It becomes an even greater concern when third-party service providers use the same credential for different customers.

Now, we understand that unique accounts are a logistical hurdle for your third-party service providers to create and maintain. Still, if you’re using external organizations that require remote access to your environment, you must confirm that their access credentials are unique to your organization—have your third-party service providers speak to how they generate and protect these access controls along with the means to identify the unauthorized use of them.

Why? Let’s put this into Lord of the Rings terms.

Imagine that Gandalf used the same secret phrase to open up every door in Middle Earth. In this scenario, that means that if anyone else learned one secret phrase, all other magical doors would not keep closed for very long. Now let’s apply this to the real world—if an attacker compromises the passphrase your third party used for another organization and it’s the same credentials they use for you, that means that attacker now also has a free chance at an access control to your environment.

How Vendor Compliance Reports Can Help

The good news is that your third-party vendors are businesses with customers to satisfy, and as part of that, they may have been required to achieve compliance with a chosen security standard.

This isn’t exactly a slam dunk for you quite yet—a compliance report represents an effort to demonstrate information security, but you need to make sure that those efforts made by your vendor were on the systems and services relevant to the work they do for you:

  • For example, if your third party has a SOC 2 report, how well do the services covered apply to the work they will be doing and does this correlate to your business needs?
  • If they instead comply with PCI DSS, it’s a little easier to discern since that standard includes an Attestation of Compliance and responsibilities matrix that delineates the responsibilities of each organization. 

If your third-party service provider does not have any kind of compliance report/certificate and you would like more assurance, you can request they adhere to a relevant standard as evidence that they apply safeguards for your data, credentials, and environment. 

2 (More) Ways You Can Better Protect Third-Party Access to Your Data and Systems

But the responsibility of security isn’t just on your third-party service providers that require access to your environment—there are further steps you can take to better secure against the inherent risk of granting that access.

Security-wise, this might seem simple—according to the principle of least privilege, the only access you should give is what’s necessary to accomplish the task. To drive that point further, there are different levels of administrative access that can be leveraged. For example:

  • A database administrator requires full access to the database, but do they require full administrative access to the operating system?
  • Software developers may need full administrative access in the development/test environments but they should be limited to a very diminished role in production with only read-only access to logs.
  • A helpdesk technician may need rights to install or modify software on a system but should not be able to edit the system’s security policy. 

Here are two things you can do to maintain a secure environment while granting (the right) access to your third parties.

1. More Thoroughly Classify Your Data to Inform Your Access Permissions.

 

Beyond having logical access to systems or services, intentionally or because of function, you’ll also likely need to grant certain third-party service providers access to data.

While a hosting provider would require no access to the data (so the logical restrictions would not apply), software developers may require sample data to vet their offering and perform testing, though they wouldn’t require “live” or “actual” data.

Tricker situations occur when a service provider performs administrative tasks like patching or network management. In these scenarios, access to data is difficult to prevent should that access be compromised.

That’s why it’s important to address the value of data based on its function within your organization and the relevant legal considerations. The theft of PII, credit card data, and proprietary data is a very real and ongoing threat, and segmenting these types of data out more clearly to control access to them is worth more than you think.

2. Periodically Review What Access is Necessary

 

At the start of all your third-party engagements, you’ll ask, “What access is necessary?” Take care to document a detailed answer so you can confirm access granted is in direct alignment with the work being done. Don’t be afraid to drill down to a very specific situation—consider that access may be necessary between 0900 and 1700 but not enabled at any other times. (Controls do exist that can limit access to specified timeframes.)

This review also should not be a one-time event. Make it a routine check to reevaluate all access provided to third-party service providers—the time period for that review should be commensurate to the access held by the service provider. It can even be included as a part of risk assessments.

Moreover, while it’s common for access needs to change over time as additional services are rendered or to troubleshoot an issue, any granted extra access should be tied to a tight timeframe.

Next Steps for Securing Your Third-Party Providers

When the Fellowship set out from Rivendell to destroy the One Ring and save Middle Earth, there were some reservations about some of the members sent in support of the quest and whether they were qualified and ready. Out here in the real world, you may also harbor the same kind of reservations regarding granting third parties access to your environment or data, and those qualms are valid.

But as you’ve just learned, there are some things that both you and your service providers can do to better protect yourselves and the shared items. By identifying the right privileges necessary for the work and the access to data, you’ll be more prepared to limit any fallout should a breach occur.

For more help in boosting your cybersecurity, check out our other resources that can provide areas of focus:

About Sully Perella

Sully Perella is a Senior Manager at Schellman who leads the PIN and P2PE service lines. His focus also includes the Software Security Framework and 3-Domain Secure services. Having previously served as a networking, switching, computer systems, and cryptological operations technician in the Air Force, Sully now maintains multiple certifications within the payments space. Active within the payments community, he helps draft new payments standards and speaks globally on payment security.