Attack Surface

   Last week I did a national webcast with Capella University.  The topic was the Insider Threat.  But my take on this is a bit different than what's usually said on this subject.  I talked a bit about this topic in my post last week.  You can see my slides here.

   As happens in some (perhaps not enough) InfoSec talks, during the presentation we touched on the topic of Risk Management.  In particular, we were talking about how to help keep honest people honest and good people to do the right thing.

   There are all kinds of "formulas" used to calculate, or more correctly - estimate, risk.

The most common ones basically look at assets and threats.  The assets are things we have like systems, applications and even people.  Threats are things like hackers, phishers, tornadoes, earthquakes, etc.  We consider: those assets that have a vulnerability to some kind of threat; the probability that the event will occur, and; the impact to the asset or organization should the event manifest.

   So, most organizations trying to decrease bad risk (because risk can be good also!) might try to decrease: the probability of the event occurring; the vulnerability to a threat, or; the impact of the event.  And that can work.  But rarely do we think about decreasing the amount of assets we have in the first place!  Less stuff means less stuff to secure, and often, fewer things that can go wrong!

   I first heard about this concept at a conference talk years ago.  Unfortunately, I can't remember what conference nor who the speaker was.  But at least the concept stuck!

   The amount of stuff that we have to secure is often called Attack Surface.  Stephen Northcutt of the SANS Institute did a great article on this in 2007 that he updated in 2011.

   Looking at your environment through this lens opens up all kinds of questions and possibilities.  Why do we have so many applications?  Why do we have so many old and legacy applications?  Do we really need java in our browsers?

   Of course, taken to extremes we may end up with the opposite problem... all our eggs in one basket, single point of failure... pick your cliche.  So, like with so many other things, this is a matter of striking a balance between keeping what's really needed while eliminating what really isn't.

   Have you thought about this before?  What examples can you think of to illustrate this issue?