The myth of defense in depth in the modern technology landscape

 

  Analysts always offer an interesting spark to conversations, don't they?  I had a Twitter exchange with Neil MacDonald of Gartner earlier this morning that got me thinking again on the concepts of defense in depth in the way that we've been thinking about it in IT Security for the past 20 years or so.  So just what is the state of defense in depth in the landscape of today's modern technology?  I think to understand the avenue I'm coming down I should explain that I've been doing security (that is, implementing security measures in corporate environments) since about 1997 - which is a little before all this became cool and hip as far as the niche of "InfoSec" goes.  You see, there are two parts to the idea of defense in depth - there is the concept and the implementation.  It's easy to talk about the concepts behind defense in depth - but to implement them effectively in today's technology landscape ...well that may be an entirely different cup of tea.

 

 Neil mentioned mentioned the loss of control of devices, applications, and systems - as organizations race toward a service or utility-based technology model (a la "cloud computing") this makesdefense in depth more critical than ever to security.  Let me clear some air - I don't disagree in concept. The problem of course is that concept is not real-life implementation.  Allow me to explain more in-depth here...

 

  Remember just a few years ago, before the prevalence of web applications, when you had to perform some serious hacker-ninja stuff to get at the enterprise treasures?  The attacker would need to penetrate a firewall, find an exploit against a listening port/socket, exploit an operating system-specific, processor-specific protection mechanism accounting for 32-bit or 64-bit architectures and maybe then you didn't cause enough noise to be able to get a foothold on the system and look around before getting caught.  In this case, defense in depth worked (or should have worked) brilliantly if implemented with the right technical aptitude because of the notion that somewhere along the way you would encounter a technical roadblock that would either stop you dead, or trip a sensor that would alert the security teams to your presence.

 

  While the above case can work as a flawless example if you have a firewall, network IPS, system-level IPS, good patch-management, and a half-decent enterprise centralized logging and analysis system it all falls apart when we go to what we've got today in many organizations.  Attempt to implement defense in depth for web apps where a single SQL injection will compromise an entire enterprise database without tripping a single bell.  Sure, you can have that same firewall, network and system-level IPS and be up-to-date on patches ...but that SQL injection sneaks in because it's been obfuscated by a creative attacker and your SQL database is necessarily exposed to the Internet.  Game over.

 

  Another example of where defense in depth fails the modern enterprise is data.  There simply are no good, effective tools for protecting data as it traverses systems within your organization and as it leaves your control.  Yes, we as an industry are trying like mad to address the problems, and data loss prevention mechanisms and other strategies are being deployed en-masse but it's still largely a bloody battlefield littered with the corpses of some of the largest enterprises out there that have lost a laptop (or desktop, yikes!) containing a spreadsheet which had all of their employee data.  How does all that traditional approach to defense in depth help in this scenario?  The old implementation of defense in depth is inept, inadequate, and simply put - past its shelf life.

 

  As a concept, defense in depth is still absolutely necessary but it needs to be re-thought to accommodate for the evolutions and revolutions in technology and business practice over the last decade.  Everything from how we hire employees, to how we manage data, to how devices connect to our networks and how we authorize packets between our private internal (if there is such a thing anymore) networks and our clouds and our partners must be analyzed and given a defensive posture.  Design adjustments must be made with minimalist principles - remember "least privilege" from back in the old days?  It's more important than ever now... and it should be the first principle in designing anything.  An application that accesses a database should get the minimal amount of exposure, with the minimal amount of users, with the minimal amount of data in the minimal amount of network access ...and so on.

 

  So, is defense in depth a myth, as my title here suggests?  If you're coming at it from the implementation perspective like I am - then the answer is yes.  I see many in the industry continuing to apply the same defense in depth principles that served back when the technology landscape was completely different - and failing miserably without understanding why.  I think the principles of defense in depth are timeless but when your enterprise landscape lacks depth (see graphic) then they are harder to apply in the traditional sense and are relegated to a mythical status.

 

  With that, I'm fairly convinced we have an uphill battle in information security.  The threat landscape is changing faster than we can adapt to it, the enterprise is becoming more shallow in nature (flattening, for you network folks), and defense in depth is becoming a myth.  Don't let it become a myth you tell your kids one day.

Comments
geoff brunkhorst(anon) | ‎01-10-2012 04:40 PM
any time your defense in depth is 'layered on top of' the application, you'd don't have depth... you have brittle layers on top of a soft gooey middle. Or put another way... once you 'Allow Port 443' inbound or 'port 80' outbound, you need to look at 8 to 10 more layers of 'depth' to your defense strategy. Your simple example of SQL injection is effectively stating that once you get past the Web App layer, you have complete access to the database. All your examples above of 'depth' excluded _the_app_. That in and of itself decries a lack of depth. No app sec layer, no strong typing, no data access analysis. etc. Defense in depth is by nature multi modal. If all your 'depth' are 'network' or 'perimeter, or 'applied to,' not 'built within' then you have a serious gap. Once you expose an app, then you need to add several other layers of security to that 'system' (app sec requirements, log monitoring, code review, static testing, dynamic testing, WAF, vuln management of all middleware, access management, change management, etc.... just for the app. So, I don't agree that defense in depth is failing us. Just that 'old school thinking' (firewalls, AVs, and MS patches) is not deep enough anymore.
Armorguy(anon) | ‎01-10-2012 06:36 PM

Raf,

 

You are trying to have your cake and eat it too here...

 

Defense in depth, I would submit, is the only practical and effective way of defending systems and data in today's environment.  That, as you allude to, depends mightily on designing, deploying, and monitoring it correctly which is hella hard work.

 

But just because people mess it up doesn't mean it's a myth.  I just means their implementations are "sub-optimal".

 

Headlines like you're using here make me ragey because the truth is we need defense in depth (for a classic military example look here: http://en.wikipedia.org/wiki/Maginot_Line ).  Saying it's "dead" or a "myth" is not helpful.  The key thing we all can do to help (and your employer can/should be a key player in this field) is helping folks who are trying to make it work to actually get it to work.

 

"Defense In Depth.  Do It. Do It Well. Or The Kittens Will Get It."  I will license that to HP for a small discount in my TippingPoint renewal.  :)

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author(s)


Follow Us
Community Announcements