AfterBites - 160 Illustrations of Transitive Trust

The article:

 Number of Banks Affected By Heartland Breach: 160 and Growing
(February 6 & 12, 2009)
According to the Bank Information Security website, nearly 160
financial institutions have acknowledged that they were affected by
the Heartland Payment Systems data security breach. Banks in 40 US
states as well as in Canada, Bermuda and Guam have reported that
some of their customers' cards were exposed. It is not known how
many card accounts were compromised; Heartland says it processes 100
million transactions a month.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9127822&source=rss_topic17
http://www.bermudasun.bm/main.asp?SectionID=24&SubSectionID=270&ArticleID=40389&TM=28150.45
http://www.theregister.co.uk/2009/02/12/heartland_data_breach_latest/
http://www.bankinfosecurity.com/articles.php?art_id=1200&opg=1

One of the underlying realities of computer security is the problem of transitive trust.

Put simply, transitive trust means:

• if A trusts B
• and B trusts C
• A trusts C and probably doesn't know it

I explain the whole problem of transitive trust in terms of delegation of action in episode 1 of the rear guard security podcast. It's the gigantic problem inherent in virtually all security-critical networked activity; it's such a big problem that most of us ignore it. Because, it's so hard to deal with that it's basically a show-stopper: you can hardly do anything on a network at all if you're taking machine-to-machine trust into account.

But, as critical applications become increasingly interdependent, it'll be a bigger and bigger problem. Two things are going to exacerbate it: outsourcing and Web2.0 applications. The explanation for outsourcing is simple: critical data is going to reside in more places, and access to crucial databases is going to be opened up to external entities. Attackers no longer need to directly attack hard targets, they can go after providers of services that might also be authorized to touch the data. I'm especially worried about this when I think of the ever-expanding number of administrators who touch some aspect of a transaction. A bank no longer needs to only worry if their systems people are trustworthy - they have to worry if their SAN provider's network manager is security-competent, or their help desk outsourcer's DBA's home machine has a trojan horse. Etc. Web2.0 applications will present the same problem, only inverted from the user's perspective. Users may come to trust a site as not being a vector for downloading trojan horses, but if any of the sites that provide linked ads or plugin applications has been compromised, the user's trust is misplaced. Malware downloaders are already taking advantage of that kind of vector for attacks; it'll just get worse when mashups become increasingly seamless-looking and integrated.

Basically, transitive trust attacks work because trust relationships increase the attack surface of the target. The attack surface is now the target PLUS anyone who talks to the target. It's nothing new; it's the way it's always been.

In other venues, I've been fairly critical of the notion of "risk management" and transitive trust is why. It's silly to imagine that we can somehow assign a meaningful likelihood to something going wrong, when most organizations treat trusted third parties as trustworthy. (Trusted != Trustworthy) As you increase the amount of trust you place in others, your attack surface expands geometrically, your overall security goes down, and the likelihood you'll become front page news goes up. It's that simple.

Whenever I point something like this out, someone asks "what's the alternative?"   Sorry, but... when it comes to transitive trust, I don't know of one.