How to Manage Third-Party Risk in a World of Breaches

Third-party risks are unavoidable in vendor relationships. Without proper Third-Party Risk Management (TPRM), it's impossible to onboard vendors without exposing your organization to cyber threats.

The 2013 Target data breach is an important example of how a small vendor can expose the data of a large organization. What began with an HVAC subcontractor ended with the exposure of over 40 million customers.  

Today, every organization is trying to build effective third-party risk management (TPRM) framework, yet only 16% report they can effectively mitigate the digital risks caused by vendor relationships.

To learn how to effectively manage third-party risks so that you can confidently onboard new vendors, read on.

Why is Third-Party Risk Management Important?

Ultimately, it's an organization's board of directors and senior management who are responsible for managing third-party relationships. The identification and control of associated risks should be held to the same standard as activities that were handled from within the organization.

Sadly, this is not the status quo despite the numerous risks that arise from third-party relationships over the vendor life cycle. Yes, some risks arise from the underlying activity itself and would exist regardless of outsourcing.

However, other potential risks arise or are heightened by the involvement of a third-party. Failure to manage these risk can leave organizations exposed to regulatory action, financial action, litigation, reputational damage, and can impair the organization's ability to gain new or service existing customers. This is why third-party risk management is so important.

What are Common Risks Introduced by Third-Parties?

Not all of the following risks are applicable to every third-party relationship, nor is this an all-inclusive list. That said, most third-party business relationships will introduce some combination of the following:

• Security risk: The risk of exposure or loss resulting from a cyber attacks, security breach or other security incident. This risk is often mitigated by performing due diligence before onboarding new vendors and ongoing monitoring over the vendor lifecycle.
• Operational risk: The risk a third-party will cause disruption to the business operations. This is generally managed through contractually bound service level agreements (SLAs). Depending on the criticality of the vendor, you may opt to have a backup vendor in place to ensure business continuity. This is common practice for financial institutions.
• Legal, regulatory and compliance risk: The risk a third-party will impact your organization's compliance with local legislation, regulation or agreements. This is particularly important for financial services, healthcare and government organizations as well as their business partners.
• Reputational risk: The risk arising from negative public opinion caused by a third-party. Dissatisfied customers, inappropriate interactions and poor recommendations are only the tip of the iceberg. The most damaging events are third-party data breaches resulting from poor security controls.
• Financial risk: The risk a third-party will have a detrimental impact on the financial success of your organization. For example, your organization may not be able to sell a new product due to poor supply chain management.
• Strategic risk: The risk your organization will fail to meet its business objectives because of a third-party vendor.

Learn how to reduce the impact of third-party breaches.

Mitigating Email Spoofing and Phishing Risks

Phishing is a common and successful form of social engineering, particularly spear phishing combined with email spoofing.  

Phishing is when an attacker attempts to gain unauthorized access to sensitive data or login credentials by tricking a victim into providing it to them via email, phone or text message.

Spear phishing is when these attempts are targeted at a particular person.

One of the most successful forms of phishing is spear phishing paired with email spoofing.

Email spoofing is when an attacker takes advantage of poor email security and forges the sender address to make it look like the email is coming from a trusted party.

Vendors who have inadequate SPF, DKIM and DMARC settings are particularly high risk.

Imagine you have a vendor who has access to your CRM and has poor email security.

An attacker could spoof their domain, sending an email to your staff requesting a new account be created in your CRM. Your employee complies thinking it is actually the vendor and this results in the exposure of your customers' personally identifiable information (PII).

The best way to prevent this is to prevent this type of attack is to ensure the email never reaches the victim's inbox.

For this to happen, you need to be able to authenticate your vendors' emails against various sources to ensure it comes from who it says it does.

The three most common methods of email authentication are:

• Sender Policy Framework (SPF): SPF verifies the email originated from a server trusted by the sender’s domain. SPF alone can only authenticate the source of the message and not the original author. There is nothing stopping an attacker from setting up their own mailbox and domain, with an SPF record that authorizes the attacker's IP address to send an email on behalf of that domain.
• DomainKeys Identified Mail (DKIM): DKIM verifies the email originated from the sender’s organization. A valid DKIM signature only verifies that the DKIM signature was created by the sender's organization. It does not mean the email is not spoofed. An attacker could easily create a valid DKIM signature for a domain she controls while spoofing the domain.  
• Domain-based Message Authentication, Reporting & Conformance (DMARC): DMARC specifies how to handle SPF and DKIM validated email. Combined with SPF and DKIM, DMARC allows you to authenticate that an email is legitimate because SPF validates the email was sent from a trusted source and DKIM validates that it originated from the sender's organization.

All these mechanisms rely on DNS to function, which means you should also check if vendors have DNSSEC enabled to prevent DNS Spoofing, also known as DNS Cache Poisoning.

Mitigating Data Exposure and Man-in-the-Middle Risks

A vendor's website is often a good representation of their overall security posture.

Unencrypted websites and those without proper SSL configuration can leak customer data or have it intercepted by a man-in-the-middle attack.

Furthermore, web servers running vulnerable software or code are indicative of ineffective server-hardening and maintenance processes.

We recommend looking at the following independently verifiable attributes of a vendor's website:

• SSL encryption details: Including whether SSL is enabled, enforced and is site wide. This can also include cipher suite, encryption strength and expiration date.
• Software type and version: Without obfuscation, an anonymous person on the Internet can learn what software is running on a website, including what version. This allows them to scan for known vulnerabilities, like those listed on CVE, and probe for potential attack vectors.
• Server headers: Many web servers advertise information about themselves to the Internet. Like software, failure to obscure these headers can reveal sensitive information.
• Cookie settings: Even the way a website handles cookies can show signs of overall data security. Allowing cookies to travel across unencrypted connections can lead to exposure of credentials and authentication tokens. Additionally, failure to mark cookies as HttpOnly allows them to be exploited by client-side scripts which can then be used to impersonate a user on the website.

These complicated security details are likely to be overlooked by vendors. An unsettling possibility, given the level of sensitive data access commonly required in third-party relationships.

Mitigating Open Port Risks

The principle of least privilege would suggest that a vendor should have as few ports as possible open to the Internet, in order to minimize the potential attack surface.

For a web server, ports 80 and 443 would be typical, however, when extraneous ports are left open, numerous risks can arise, including that of ransomware through worms such as WannaCry and Petya which exploited the EternalBlue vulnerability in Microsoft SMB ports (135-139, 445).

Other dangerous ports to look out for are:

• Telnet (23): An open telnet port usually means an active telnet server. The problem is telnet is extremely insecure and should never be used in the enterprise.
• FTP (21): FTP is an unencrypted file transfer protocol, which means the information passed through it is susceptible to man-in-the-middle attacks. SFTP and many other options now exist to replace it.
• MSSQL (1433, 1434): Databases should never be exposed to the Internet directly. All database manipulation must happen through carefully controlled front-ends. Direct database access from outside a vendor's network should require a VPN connection.
• MySQL (3306): Exposed databases can be misconfigured to allow anonymous access to any and all data contained within. Whether Linux or Windows, these database ports should be disallowed to the internet.
• SSH (22): SSH is an encrypted protocol and there are times when it is appropriate to expose the the Internet, butfor the most part it should be limited to gateway servers used by authenticated users to hop to another system within a network. Exposing remote administration ports to the Internet can lead to system compromise in the event of weak, blank or default passwords, botched permission sets or vulnerabilities in software.
• LDAP/AD (389): If directory information is exposed to the Internet, it should be passed over an encrypted connection (636), but is generally not exposed to the Internet at all. Without careful consideration, it can lead to a massive leak of corporate structure, user account names and other directory information.

At the very least, open or dangerous ports are something that your vendor risk team should ask a vendor about.

Without empirical evidence, you're leaving it up to your vendors word which is a poor way to measure the risk of new and existing vendors who are involved with transferring sensitive information across the Internet.

Read our full post on open ports here.

How to Measure Third-Party Risks With Security Ratings

None of these factors by themselves tell much of a story, but when aggregated together they can provide context about how important security is to a vendor.

Security ratings take in this data and quantify it, providing a score in the form of a letter grade or numeric score.

This score can be used to compare one vendor to another, aid in decision-making, and speed up the due diligence process.

Think of security ratings as a data-driven, objective, and dynamic measurement of an organization's security posture.

Security ratings provide technical team members with itemized details about the risks each vendor poses while providing non-technical stakeholders with an understandable score they can understand.

Additionally, they fill the gaps left in traditional methods of third-party risk assessment, such as penetration testing, on-site visits, and security questionnaires. Not only are these methods immensely time-consuming, they only offer a point-in-time assessment of a vendor's risk profile.  

These are large gaps that had to be filled in traditional third-party risk management programs.

Just as credit ratings remove subjectivity and the point-in-time assessment of credit risk by providing an independent, objective and quantitative assessment of credit worthiness, security ratings do the same for cybersecurity risk.

The real benefit of security ratings over traditional third-party risk management processes is that they are automatically generated and updated frequently.

As long as a third-party has your data, it should be being assessed. If you work in the financial services industry, it's likely a regulatory requirement.

Assessments should continue throughout the vendor relationship to ensure your expectations of risk aren't misplaced as a new attack vectors opened up after initial assessments.  

UpGuard is one of the most popular security ratings platforms. We generated our ratings through proprietary algorithms that take in and analyze trusted commercial and open-source threat feeds, and non-intrusive data collection methods to quantitatively evaluate vendor risk.

Our security ratings range from 0 to 950 and are composed of a weighted average of the risk rating of all your vendor's underlying domains in addition to the ratings of their vendors.

Particularly, UpGuard security ratings can help you understand your vendor's security controls (or lack thereof), allowing you to focus on the highest risks first.

Additionally, you can require a vendor meet certain technical controls in order to handle your data. For example, you may require:

• Email Protection: Require that vendors implement sufficient controls to mitigate the risk of email spoofing and phishing
• Website encryption: Require vendors to use SSL and encryption best practices to prevent man-in-the-middle attacks
• Port management: Require vendors to not have specific ports open, especially those for databases and file transfers.

By using UpGuard Vendor Risk, you'll be able to quickly see which controls are missing and independently verify that they've been implemented before you onboard the vendor.

Don't Forget About Vendor Questionnaires

In addition to monitoring the externally observable security controls, it's important to ask your vendors about their internal data handling practices and procedures.

A good vendor risk assessment questionnaire template can help streamline the discovery of risks. Here are a few examples you could include:

• Do you store data in the cloud? If so, what steps do you take to protect that data?
• How many copies of the data will the vendor keep? Will all of them be secure?
• Will copies of the data be stored on laptops or other workstations and mobile devices?
• Will the data ever be transmitted over an unencrypted connection?
• How is access to customer data segregated for employees of the vendor?

This is just the beginning, get our free risk assessment questionnaire template here or read our guide on the top vendor questionnaires.