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: Apprentice
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-6651
Published: 2014-07-31
Multiple directory traversal vulnerabilities in the Vitamin plugin before 1.1.0 for WordPress allow remote attackers to access arbitrary files via a .. (dot dot) in the path parameter to (1) add_headers.php or (2) minify.php.

CVE-2014-2970
Published: 2014-07-31
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-5139. Reason: This candidate is a duplicate of CVE-2014-5139, and has also been used to refer to an unrelated topic that is currently outside the scope of CVE. This unrelated topic is a LibreSSL code change adding functionality ...

CVE-2014-3488
Published: 2014-07-31
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.

CVE-2014-3554
Published: 2014-07-31
Buffer overflow in the ndp_msg_opt_dnssl_domain function in libndp allows remote routers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted DNS Search List (DNSSL) in an IPv6 router advertisement.

CVE-2014-5171
Published: 2014-07-31
SAP HANA Extend Application Services (XS) does not encrypt transmissions for applications that enable form based authentication using SSL, which allows remote attackers to obtain credentials and other sensitive information by sniffing the network.

Best of the Web
Dark Reading Radio