The problem with defence in depth

Defence in Depth is arguably the most time tested principle in security and applies to physical security as well as online. It builds on a concept of a hardened "core" where one places their "crown jewels." This core is then surrounded by castle walls and moats, with ever increasing generality of defence.

It's a great concept, but comes at a price. Just as the area covered is wider from layer to layer, so is the cost associated with protecting against more plentiful, and less and less specific threats. A firewall typically acts as the last line of defense on the enterprise perimeter, but has to protect against a great many varieties of threats, while a server room door has to "only" be concerned with physical access.

Another flaw in the Defence in Depth design is its inherent difficulty to implement vis-à-vis the three basic tenets of security: confidentiality, integrity and availability. Why? Because most forms of defence create increasing confidentiality, but make integrity more difficult to implement and manage. Any increase in defence, of course, makes availability that much harder to provide to the users.

A difficulty that I myself encountered many times is the applicability of Defence in Depth to my "layer 8" problem, the users. If users are not trained properly, if they are not aware of information protection needs, methods, and the "why?" of it, they become a liability, rather than an asset, towards data security. If you are like me, you find the need to increase our moat to user ratio on an ongoing base harder to design, implement, manage, and pay for. Many of us just say "this is reality" and define our demarcation line as a physical device, such as a router, an access point, a firewall or a webserver. There are potentially two things wrong with doing so:

1. We are basically saying "we are a target just waiting to be attacked"

2. We allow most barbarians (in the form of rogue traffic, networks and devices) to hit our gates

If we continue to do so, we will have approached a mathematical certainty of being hacked, or at least DDoS'ed out of the net. I really prefer NOT to draw analogies here to the real world, and we all know which those are.

Not only is the problem above big enough to cause some to lose sleep, but imagine what happens when we move to a cloud topology. There we have nothing but moats and walls and front doors. These front doors can be any browser, on any device, anywhere in the world. How do you protect yourself against that?

Like any solution that might involve our entire user set, which may include internet users, rather than pure corporate users, any solution must be:

1. Easy to teach (ie close to zero learning curve)

2. Easy to implement

3. Applicable to the widest range of platforms possible

4. Have a small delivery and storage footprint

5. Easy to manage and maintain

Not asking for much, am I?

Knowing how rapidly threats involve "in the wild", I also want a tool that does not go the normal route of "blacklisting". I am more and more convinced that we need tools, in our world of security, that no longer compare bad signatures or behavior to a database (which is how most antivirus and firewalls, for example, act) and we need to go the "whitelist" route. I will write about that in the future. Yes, I want a tool that will be controlled by me and allow me to choose which domains can be accessed, and under what (time or other) conditions can such an access occur. Let's add those to my "dream list":

6. White list based

7. Conditional access

To make matters even more interesting, I want control over certain user functions. (We want, after all, to reduce the number of barbarians and the number of roads leading to our castle, don't we?) We want to make sure that the people that request a resource are authorised to even request it.

For example, I would like some files to be able to be read and written, but not printed. Or that I be able to control launching certain tools, such as IM or browsers from within the session. And finally, I want a bullet proof audit trail. Why? SoX, GLBA and HIPAA, to name but a few.

8. Selective access to file functions

9. Audit trail