Analytics
1/6/2012
10:10 AM
Connect Directly
RSS
E-Mail
50%
50%

Tech Insight: What To Do When Your Business Partner Is Breached

Vendors and contractors play an important role in your business. But what happens when a partner’s systems are compromised? Here are a few tips

A breach in your own organization is bad enough, but a breach at a third-party vendor or contractor that is tightly connected to your organization can be even more frustrating. The key to minimizing the chaos is to work closely with your vendors, contractors, and service providers so that you’ll be able to respond quickly when a compromise happens.

When a compromise occurs at a partner site, the first step is to understand what occurred, assess potential damage, and set a game plan. Verbally discuss the incident with the partner, ask as many questions as you can, and instruct them to send you their official statement in writing. This information will help you craft your own organization’s statement and begin documentation.

During this initial conversation, be sure to document all of the facts as given to you. Email your notes to the vendor and request review and confirmation of accuracy. As the incident progresses, your organization will want as much information as possible to address any questions that arise from other partners, customers, or internal staff. It’s important to get these answers quickly -- and in writing -- for future reference if the matter escalates and legal action is required.

As you’re starting to piece together what occurred, it’s time to understand your organization’s exposure. You’ll need to fully understand what service the partner provides to your organization, the data it possesses, and how you are connected to each other. A breach of a third-party email provider has a different impact than breach of a two-factor authentication vendor. Understanding the total exposure will help you define the risk associated with the breach, the actions you must take, and how fast you must move.

Once the risk is identified, continue to communicate with your vendor and discuss your rights. Continuous communication is critical -- you want your organization to stay top of mind when hundreds of clients begin calling, and that you will get high-priority notification when something new is known. Don’t give up if you leave messages and emails that go unreturned. Your persistence will pay off, just as it does for the salesperson who leaves you 22 messages.

Once you’re in contact, discuss your rights. Hopefully, buried in the contract with your partner, there is language that outlines your rights in the case of a breach or other security incident. These clauses typically include timing for notification of the breach, the right to audit after a security incident, financial penalties, and the right to cancel the contract. Understand these well and use them to your advantage. In most cases, it won’t be necessary to be heavy-handed -- it’s in everyone’s best interest to cooperate and resolve the matter once it has been disclosed. But knowing your rights and options will give you some alternatives if they are needed.

[Sensitive company data is often leaked via Google, Bing, and other search engines -- find it before the bad guys can. See Analyzing Data To Pinpoint Rogue Insiders.]

As more information becomes known, continue to evaluate the risk to your organization. You need as much information as possible before you notify affected parties. This can be tricky -- some in your organization will want to hide it since it wasn’t a breach of your systems, but others will want to send out notifications as soon as possible. Full disclosure is usually the right thing to do -- no matter where the breach occurred -- and the breached partner generally should issue a disclosure, as well.

The trickiest part is timing. Disclose too early and you risk communicating bad or incomplete information. Wait too long and the public will balk at you waiting so long. Typically, it’s a good idea to disclose as early as you can, as long as there’s enough information to identify affected parties and the data affected. This can provide the basis for later communications.

Once the dust has settled and the partner has fixed the immediate problems, it’s time to make sure this doesn’t happen again. Work with the vendor to understand how it’ll prevent this issue from occurring again, how it’ll assess its systems for other potential problems, and how you’ll be informed of the assessment results. Use this incident to insert your organization into your partner’s security processes, and require annual assessment reports or gain the right to audit their operations. At this point, you have some leverage -- use it to your advantage.

Partners are important to your business, but they can also be a liability. Implementing partner risk reviews and vendor management processes can reduce risk and help your organization identify vendors that are less likely to fall victim to a breach. No partner is impenetrable. Knowing the risk associated with each partner, having good communication, and working together to resolve a breach helps everyone -- including customers and other third parties.

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

Comment  | 
Print  | 
More Insights
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-2013-4262
Published: 2014-07-28
svnwcsub.py in Subversion 1.8.0 before 1.8.3, when using the --pidfile option and running in foreground mode, allows local users to gain privileges via a symlink attack on the pid file. NOTE: this issue was SPLIT due to different affected versions (ADT3). The irkerbridge.py issue is covered by CVE-...

CVE-2013-4840
Published: 2014-07-28
Unspecified vulnerability in HP and H3C VPN Firewall Module products SECPATH1000FE before 5.20.R3177 and SECBLADEFW before 5.20.R3177 allows remote attackers to cause a denial of service via unknown vectors.

CVE-2013-7393
Published: 2014-07-28
The daemonize.py module in Subversion 1.8.0 before 1.8.2 allows local users to gain privileges via a symlink attack on the pid file created for (1) svnwcsub.py or (2) irkerbridge.py when the --pidfile option is used. NOTE: this issue was SPLIT from CVE-2013-4262 based on different affected versions...

CVE-2014-2974
Published: 2014-07-28
Cross-site request forgery (CSRF) vulnerability in php/user_account.php in Silver Peak VX through 6.2.4 allows remote attackers to hijack the authentication of administrators for requests that create administrative accounts.

CVE-2014-2975
Published: 2014-07-28
Cross-site scripting (XSS) vulnerability in php/user_account.php in Silver Peak VX before 6.2.4 allows remote attackers to inject arbitrary web script or HTML via the user_id parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Sara Peters hosts a conversation on Botnets and those who fight them.