Third Party Risk Management (TPRM) is an essential component of any organizational cybersecurity risk management program. This is because TPRM programs help identify and mitigate risks to your organization introduced by external parties, ultimately trying to achieve the reduction of cyber risk provided by third parties.

Running an effective TPRM program is a large undertaking for any organization, and many organizations rely on outside vendors to help perform some, or even all, of the TPRM functions. The challenge, however, is that not all TPRM functions are free of risk themselves. Our research indicates that some functions even introduce the very thing they are designed to suppress: information useful to attackers for compromising your, or even their, organizations.

When setting up your TPRM program, or reviewing outside vendors to perform any function of your TPRM program, you may be missing the critical step of assessing the TPRM program, or vendor itself, for possible introduction of third-party risk.

Is your vendor risk management adding or reducing risk?

The main challenge with adding any new component into your risk management arsenal is that not all solutions solve the security problems’ principle goal in the same way. In TPRM, not all solutions consider the fundamental problem of profiling third-parties: creating a treasure trove of information extremely useful to an unauthorized user.

If the aim of a TPRM program is to pinpoint risk so that it may be addressed, the collection of that risk-insightful data requires protection, lest it fall into the hands of an unauthorized party. The unfortunate reality is that this data is not always protected, not even by the external party employed to collect and assess such data.

Our research indicates some Third-Party Risk Management services and functions may actually provide information needed for third-party attacks.

What common flaws have we seen?

Proper TPRM requires a repository of information to accurately run analytics on and diagnose any inherent risk by using an external party. These repositories and the processes around their use, however, are not always configured or protected in ways that optimally reduce risk to the enterprise.

Over time, we have discovered two common security flaws in such systems and underlying processes: insecure applications and insecure file transfer.

Insecure Applications:

Lack of role-based access. The lack of role-based access allows unauthorized users to gain access to data ripe for a third-party attack. Many times, we see this in antiquated applications that simply do not allow role-based authentication.

In the case of one vendor, for example, we were able to gain access to tax and bank account information for every third-party that had been in contact with any of the hundreds of organizations using the platform. We achieved this by using an old (circa-2000) attack of forcibly browsing — simply changing, or guessing, the URL, to move up a directory level. Once there, access to unauthorized data was achievable.

Lack of secure development. Insecure code provides countless classes of attacks by unauthorized users. Many times, applications are pushed to production without proper security reviews, leaving insecure code in production applications used by third-party risk management vendors.

In a number of software providers, for example, we found debug functionality left “enabled,” allowing for the enumeration of the system, running processes and memory. We were also able to discover client-side controls for administrative access, where an unauthorized user may change a 0 to 1 in the JavaScript to enable the administrative functionality on a given page.

Considering the fundamental problem of securing the profiles of third-parties, the lack of role-based authentication can be avoided through setting clear role-based access controls to all vendors and suppliers working with the organization. Other application security best practices may be adopted through basic implementation of the OWASP Application Security Verification Standard (ASVS) Project.

Insecure file transfer:

Transferring files without proper security also provides opportunities for an unauthorized user. Many times, we see a practice of direct unencrypted emailing of sensitive information during risk questionnaires, or TPRM due diligence.

Too many organizations still request information by unencrypted email, providing the opportunity of sensitive information remaining on the servers. Even though encryption may be an option when received, the information may remain unencrypted on the servers on the receiving end. The use of a secure file sharing platform to reliably and securely transfer sensitive information can simply solve for this security flaw. (This means including a username and password, as well as a multi-factor authentication, not simply sending a link to access information.)

These security flaws have provided access to vendor information such as W-9’s, Bank Account and Wire Transfer data, as well as Statements of Work. Such information is exactly what an unauthorized user needs to change invoicing details — with relevant deliverable information, dates, and points of contact — to fraudulently receive payment to an unauthorized account.

Many organizations use third parties to support their TPRM programs, but unfortunately, these third parties can pose risks themselves.

What’s the irony in assessing third-party risk for third party risk?

The irony of this situation is that the stated intent of TPRM is sometimes undermined by the functions, or vendors, supporting third-party assessments. Flaws may exist in externally used vendor risk systems, and these flaws can act as the perfect map for attackers to discern which vendors do business with which companies; just imagine what this might look like for your organization.

Are you looking for help assessing your third-party risk?

Assessing all vendors for associated and unintentional external vendor risk is one way to help secure your organization from inadvertent relationship risk. Assessing TPRM vendors is no different, especially to ensure that vendor is not introducing the very thing they are selected to suppress: the risk of being an associated third party.

Are you concerned that your TPRM program might possess some of the risks we’ve described in this article? We at Neuvik are here to help.

As we wrap up Cybersecurity Awareness Month, it is an ideal time to consider the vulnerabilities in your cybersecurity operations. Whether it’s planning a thorough review of your vendors on a regular basis or looking to understand the overall cyber risk to your organization, our team at Neuvik is available to help answer questions you might have. You may contact us here.