Obscure Dependencies Can Hurt Us

All security – be it physical or information – is a weakest link problem: you are only as secure as the weakest link.

In information security, this translates to your least secure system, vendor or employee.

Developments in recent years have made is painfully clear that technology dependencies that are obscure and not well understood hurt us. Here are three examples that should convince even the skeptics that the unfamiliar is often our worst enemy:

Example #1: RSA/EMC compromised, SecurID two factor authentication weakened

SecurID is the de facto strong authentication technology for high security installations.  RSA is the well-respected security company that invented the technology.  SecurID is the ubiquitous, behind-the-scenes magic that has “just worked” for years.  Yet, some things aren’t as secure as you think (and as they should be).  Given RSA’s heritage and the widespread use of their security products in high security installations, one would have thought that any centralized datastore containing a single point of vulnerability would be secured to the extreme – and certainly not vulnerable to an attack that started with phishing emails to “low level employees.”  And yet it was, and RSA had to physically replace millions of tokens.  Military contractors and unknown others were actively attacked.

Lesson: Understand dependencies and single points of vulnerability/failure, be they inside your firm or with a vendor/partner.  Do not assume a high level of security because it “should” be – trust but verify.

Example #2: A nail in the coffin for Certificate Authorities

Certificate Authorities (CA) are the black magic behind the scenes that make the comforting little lock icon appear in “secure” web pages.  For as long as we’ve been browsing the web, the advice has been that the lock means the page is secure.  But the system that makes that work is a house of cards.  Comodo and DigiNotar were tricked/compromised to various degrees resulting in valid but fraudulent certificates in the wild.  In other words, people saw the lock when browsing a malicious site.  Not good.  While the problems with the CA system have been known for years in the security community, 2011 was the year that the cracks in the system became Wall Street Journal material.  (Interesting side-note, the oldest and largest CA, VeriSign, exited the business in 2010).

Lesson: Some of the foundational technology we depend on isn’t as secure as we may think.  Understand your exposure and have monitoring and contingency plans in-place.  Sometimes the unthinkable does happen.

Example #3: Bad guys have learned to attack these obscure dependencies.

SecurID and Certificate Authorities are both common denominators for numerous high-value systems that attackers are interested in.  Other targets include high-profile repositories of “interesting stuff” like software repositories, “app stores” and Cloud service providers.  Humans – the ultimate common denominator – remain vulnerable to social engineering attacks.  These common dependencies were targeted heavily in 2011 and will continue to be targeted in 2012 and beyond.

Lesson: No technology, technique, service provider, or employee is infallible.  Security is all about risk management: understand your exposure, manage to acceptable levels, and actively account for residual risk either by accepting it or transferring it.   Have monitoring and contingency plans  in-place for the full range of contingencies.