• United States




Third-party risk: it’s the second hop you should fear

Jun 07, 20185 mins
ComplianceData and Information SecurityRisk Management

Third-party risk is a persistent fear for CISOs and risk compliance officers especially, with GDPR potentially piercing corporate non-disclosure agreements. Loss of sensitive data from a third party is often managed using protective measures like IRM, but protection does not often extend to the second hop.

multiple-exposure image - a businessman, a team at a laptop, and data connections against a skyline
Credit: Thinkstock

GDPR has changed everything now that it is post-May 25, 2018. We can no longer make pro-forma proclamations about being good stewards of others’ data; we will actually be held accountable for losing or misusing data. The fine print in your typical non-disclosure agreement will not protect a company from liability associated with the loss of sensitive data. The buck (or euro) stops at the owner’s desk. What should be the best mitigation strategy for a CISO to deal with this old, but now far more expensive, security problem?

There will be a first offender from an inevitable breach that will be fined by some EU regulator. That’s an easy bet to make. Perhaps Vegas has a betting line on who it may be and how much they are fined, but I don’t think a CISO should be placing any bets. The prudent CISO should be considering a new way to protect data from third-party data losses, the second hop problem. That is, where does your data go when it leaves your hands and gets passed on to another? Are you still liable for what your partner does with your data?

How has third-party risk changed under GDPR?

CISOs have long been familiar with “the third-party problem” because it’s one of the hardest ones to solve. Defined in simple terms, it’s any risk inherent in relationships with others with whom you do business. Those relationships typically involve sharing data of all sorts, much of which is sensitive and typically covered by assurances backed by non-disclosure agreements. Third parties can be just about any entity with whom you must do business, law firms (with whom you share sensitive secrets), marketing and PR firms (who know your inside secrets before they are announced to the public), accounting and financial firms (who peer into your assets, revenues and liabilities), government agencies (whom you report on compliance with law and regulations), software vendors (who supply buggy software), and an endless cadre of companies who provide services for your operations. Managing the risk requires analysis of the professional operations of the third party provider, but little control is available for how they actually operate beyond clauses in a contract that define the legal and financial consequences of their failure to protect your sensitive data. Those legal clauses are now subject to re-interpretation with GDPR. The owner of the data is responsible for any loss due to a breach of the third party’s system.

What’s a CISO to do? Some control is possible using IRM technologies with your partners when sharing data, but this may not be enough.

IRM is hard to get right

IRM, or DRM solutions specific to documents, would seem to substantially solve the problem. Providing protection of data and granting access rights only to the third party requires new processes to share credentials, keys and passcodes with the right people. But people leave and change jobs, and hence keeping vigilance over access controls granted to third party could lead to error that thwarts intended protections, and business communication inefficiencies that will doom the mission of IRM. Protective measures just won’t be used if they aren’t easy to use.

It is far wiser and prudent to incorporate tracking of sensitive data and documents as an added measure of safety when interacting and sharing with third parties. It is, after all, the loss of data from the third party that is at risk – the second hop of a document to an unauthorized fourth party. (The term “third-party risk” must account for the “fourth-party detection.”)

Tracking documents instead of credentials

Consider a DRM-protected document provided to a third-party provider who is also given access to the document, either by a shared secret or by logging the recipients credentials in a centralized repository. Microsoft’s AIP is probably the best example of the latter approach to mitigate the third-party risk of shared documents.

Simple failures are likely to occur. As people change jobs, their credentials will change and failures to open documents sent to others will become commonplace. That thwarts efficiency of ordinary business processes. Worse, shared secrets can be lost or stolen, entirely vacating any protection the owner expected of the technology. In such cases, will the owner be notified? That’s unlikely if the third party was not aware of the loss. The data owner cannot control that. Therein lies the real concern about third-party risks. The data owner cannot manage and control the third-party providers’ own systems and operations, they must take a leap of faith and hope for the best, but now without shuttling the liability to them associated with the fourth party.

Perhaps a better way is to incorporate tracking mechanisms within the document, so that both the data owner and the third party are instantly aware whenever they have suffered a fourth-party violation. Don’t forget that the new GDPR breach disclosure guidelines start the 72-hour clock ticking, and speed of knowing, the minimum time-to-detection, is of the essence.

Tracking mechanisms such as beacons could serve as a mitigation strategy for instant data loss alerting. Beacons are explicitly incorporated as a legal active defense mitigation strategy in the ACDC Act introduced by Rep. Tom Graves, which is being considered by Congress. 

The mere fact that one learns that data has been lost is the most important information to learn from a beacon signal. A beacon signal that informs all parties that a third-party provider lost a crucial sensitive document that was opened beyond its own network is enough to know a breach has occurred. Time is now of the essence to do something about it to comply with GDPR. That’s really all that matters; it’s the second hop a CISO should fear and should want to know about instantly. 

GDPR need not be that scary. And hopefully the prudent CISOs won’t be the first to be fined.


Salvatore Stolfo is a tenured Columbia University professor, teaching computer science since 1979. He is the co-founder and CTO of Allure Security, a DARPA-funded cybersecurity startup specializing in data protection and the prevention of data breaches.

Dr. Stolfo is a people-person. And that makes him unique in a field where folks focus on making machines. As professor of artificial intelligence at Columbia University, Dr. Stolfo has spent a career figuring out how people think and how to make computers and systems think like people. Early in his career he realized that the best technology adapts to how humans work, not the other way around.

Dr. Stolfo has been granted over 75 patents and has published over 230 papers and books in the areas of parallel computing, AI knowledge-based systems, data mining, computer security and intrusion detection systems. His research has been supported by numerous government agencies, including DARPA, NSF, ONR, NSA, CIA, IARPA, AFOSR, ARO, NIST, and DHS.

See his full academic bio at Columbia University for more background.

The opinions expressed in this blog are those of Salvatore Stolfo and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.