Attacks/Breaches
3/9/2014
08:35 PM
Connect Directly
RSS
E-Mail
50%
50%

Tech Insight: How To Protect Against Attacks Via Your Third-Party Vendors

Third-party business connections often provide attackers easy, unfettered access to bigger, richer networks

The security of third-party vendor relationships is coming under increased scrutiny given that the source of the Target breach was identified as a HVAC service provider who had remote access into the Target network. While details are still scarce, it's clear that a connection used to allow access for billing can be enough for an attacker to turn an innocuous entry into a data breach that, like for Target, can cost untold millions.

As businesses grow, they are forced to rely on third parties to provide services that require a trust in the provider to protect their networks and data at the same or greater level. Unfortunately, this is rarely the case. Security firm Trustwave analyzed 450 data breaches in 2013 that showed nearly two-thirds were related to third-party IT providers.

With the increasing reliance on business-to-business connections, companies must protect themselves from the threats posed by allowing "trusted" third parties access to areas of their networks. While trust can be made in a vendor to provide the services it is committing to, it's a blind leap of faith to assume it will take the same precautions in protecting the information and access to your network it is trusted with.

Businesses need to protect themselves and treat the vendors accessing their networks as untrusted entities and put in the controls to protect themselves and monitor all activity sourced from the vendors.

The following are tips that have come from my experience as a security consultant, as well as countless conversations with companies that must allow access to third-party vendors and the vendors themselves.

The first is that all vendors that require access must have detailed security policies that are regularly reviewed, updated, and enforced. A policy is nothing but a useless piece of paper (or wasted electrons) if it isn't maintained and enforced. The policies need to be readily available for review and supporting documentation of the security controls should be available to the contracting business.

Policies aren't enough by themselves. Validation of the effectiveness of those policies and security controls must be performed on a regular basis. A combination of penetration testing and risk assessment needs to be performed at least annually, if not more often. If the third-party vendor is not already doing part of this, a business may consider including part of it in its regular testing. As a security consultant, I regularly find myself testing a network or Web application at the request of the organization that is going to be using it as part of its business with a particular vendor.

When remote access is required for business partners, vendors, and consultants, that access needs to be tightly segmented and isolated as much as possible from the rest of the production network. Granular controls should be in place that restricts third-party access to only those resources that absolutely need to be accessed to conduct business.

In the case of Web applications, they need to be locked down, isolated, and monitored. Web applications, in particular, are a common weak link when the expectation is that they're only to be accessed internally. A thorough security review should test to ensure the applications do not suffer from common injection flaws and other issues that could allow a malicious attacker to gain deeper access into the network.

Corporate security teams have become excellent at locking down their perimeters, but too often their internal networks are ripe for exploitation. Third-party access into the network is an almost immediate win for an attacker, who can then breach the vendor's network or steal its credentials. VPNs, Web applications, and remote desktop (i.e., Citrix, MS-RDP) must be monitored rigorously to identify anomalies that could indicate an attacker has gained access. This monitoring needs to extend down into the Web and remote desktop applications that are being accessed by the vendor.

In addition to policies and controls, businesses need to have an agreement in writing that states any breach will result in immediate notification to its partners. This will put the business on notice to be extra vigilant in monitoring for suspicious activity. Assistance can be provided, if needed, and information should be shared to help other partners identify potential indicators of compromise. A post-mortem should also be required to help all parties understand where the initial vector of attack occurred and the techniques used during the breach, and ensure that the issue and any similar ones are taken care of quickly.

At the end of the day, it's important to remember that your data is your responsibility. Connections from third parties should be considered untrusted, and appropriate security controls and monitoring need to be in place to protect your data. Signed service level agreements and "cyber" insurance aren't going to keep you out of the headlines when a breach occurs, and it's not going to help the individuals whose data was lost and sold in the underground carding market.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
johnhsawyer
100%
0%
johnhsawyer,
User Rank: Moderator
3/27/2014 | 6:09:05 PM
re: Tech Insight: How To Protect Against Attacks Via Your Third-Party Vendors
McDaveX,

Thank you for the comment. I'm not sure if we'll ever know the full extent of the "remote access" that the HVAC vendor had into the Target network. In one article I've read, it mentioned 3 different web applications. At least 2 of them had the capabilities to upload documents. I do agree that access to a web application is different than having access to Microsoft Remote Desktop or Citrix, but that doesn't prevent vulnerabilties in those web applications from exposing the internal Target network to attack.

I'm not sure how much experience you have with web application security, but I can provide you several examples of penetration tests that I've performed during my day job at InGuardians where the flaws in the web applications led to full compromise of the target companies' internal networks. Some of those successes were due to SQL injection vulnerabilities and a couple were insecure file upload mechanisms that led to code execution on the web server. From there, it was just a matter of pivoting through systems until the crown jewels were in hand -- Domain Admin access, password hashes for all users, RDP into Exchange and SQL servers that held intellectual property and sales data, source code repositories, etc.

Since neither of us were involved in the Target investigation, we're left speculating on what "remote access" the vendor really had and whether or not that access may have had vulnerabilities that could have allowed for deeper compromise. With the right skills, "remote access" to a website is all you need.

-jhs
JasonSachowski
100%
0%
JasonSachowski,
User Rank: Author
3/27/2014 | 6:57:48 AM
Know You Vendor (KYV) is essential
I think the overall message in this article of having enhanced due diligence over our third-party relationships is essential.  Similar to how we follow the concept of Know Your Customer (KYC) before doing business with a client, we must follow the concept of Know Your Vendor (KYV) as a critical element of ongoing Business Intelligence.
McDaveX
0%
100%
McDaveX,
User Rank: Strategist
3/11/2014 | 3:08:42 PM
re: Tech Insight: How To Protect Against Attacks Via Your Third-Party Vendors
Slightly confused here - I thought the whole "HVAC vendor had remote access" thing had been completely debunked, weeks ago, and all they had access to was a billing portal?

That's like saying I have "remote access" to amazon.co.uk because I can log into their website...
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5700
Published: 2014-09-22
Multiple cross-site scripting (XSS) vulnerabilities in Baby Gekko before 1.2.2f allow remote attackers to inject arbitrary web script or HTML via the (1) id parameter to admin/index.php or the (2) username or (3) password parameter in blocks/loginbox/loginbox.template.php to index.php. NOTE: some o...

CVE-2014-0484
Published: 2014-09-22
The Debian acpi-support package before 0.140-5+deb7u3 allows local users to gain privileges via vectors related to the "user's environment."

CVE-2014-2942
Published: 2014-09-22
Cobham Aviator 700D and 700E satellite terminals use an improper algorithm for PIN codes, which makes it easier for attackers to obtain a privileged terminal session by calculating the superuser code, and then leveraging physical access or terminal access to enter this code.

CVE-2014-3595
Published: 2014-09-22
Cross-site scripting (XSS) vulnerability in spacewalk-java 1.2.39, 1.7.54, and 2.0.2 in Spacewalk and Red Hat Network (RHN) Satellite 5.4 through 5.6 allows remote attackers to inject arbitrary web script or HTML via a crafted request that is not properly handled when logging.

CVE-2014-3635
Published: 2014-09-22
Off-by-one error in D-Bus 1.3.0 through 1.6.x before 1.6.24 and 1.8.x before 1.8.8, when running on a 64-bit system and the max_message_unix_fds limit is set to an odd number, allows remote attackers to cause a denial of service (dbus-daemon crash) or possibly execute arbitrary code by sending one m...

Best of the Web
Dark Reading Radio