This is written from the perspective of a software developer and project manager, who often needs to deal with sensitive data in apps that I am involved in creating.
Defense In Depth is not necessarily at odds with the principle of simplicity. Simplicity is difficult, and it's not what you'd think. Simplicity doesn't necessarily mean lack of effort.
It can (and in this case, I think it usually means) not using complex, home-grown mechanisms when established practices/tools exist.
It can also mean keeping your systems simple to reduce the attack surface area, or make them less attractive targets by not storing the type of data that people want to steal.
There is a true art, as well as science in finding the right balance of simplicity vs. functionality, but in my experience, when it comes to simplicity, simplicity in some aspects is one of the keys to defense-in-depth.
The essence of what I'm going to try to get at here is that the amount of time you spend defending your application should be proportional to the sensitivity of the data contained within, and the size of the attack surface area.
Here are two ways that simplicity adds to defense in depth by subtracting something.
- Carefully deciding whether you should store sensitive data in the first place
- One of the most blindingly obvious truths about protecting sensitive data is that if you don't have sensitive data, you don't need to protect it.
- When developing systems/software, the most basic thing you can do to increase relative the security of your system is to do so by limiting the sensitive data in the first place.
- By deciding not to store unnecessary sensitive data, you are making it simpler, but exercising defense-in-depth by considering defense as a part of your initial requirements gathering phase
- Reducing the attack surface area
- Similar to the above, but this time looking at features. Every single user input control - text-box, drop-down list, etc, is a potential "window" that, if unprotected, can be an entry point for an attacker. If you're failing to validate input or failing to sanitize output, that control may be vulnerable to any number of well-known attacks. As a developer, I can tell you that when creating large, complex sites/forms, it's easy to miss a validation control here or validate something incorrectly there.
- The business might want a fancy interface that has all sorts of bells and whistles, but the benefit of having that interface/feature should be weighed against the cost of securing it, and the downside of the increased attack surface area.
Also, keeping security simple doesn't necessarily mean limiting your defenses to fewer defenses. Keeping security simple simply means don't make it harder than necessary. Ways you can keep security simple and still have defense-in-depth include:
- Having secure defaults. Establish your normal defenses. You can have fifty layers of defenses, but if you know what your baseline is, you are still keeping it simple by just following the normal routine.
- Using established best practices. Similar to the above, for almost every type of I.T. activity, there is already an established set of best practices. Simply following those instead of coming up with wild schemes of your own keeps things simple.
- Using established, trusted tools. Of course, no tool is foolproof, but if you're adding layers of defense, using established tools instead of coming up with your own or using lesser-known, unsupported tools keeps things simpler in the long-run. You'll have better documentation, a wider user community for support, and greater likelihood that when there's a problem, it'll get patched quickly.
Defense-in-depth is about layers of security. Keeping each layer as simple as possible is the key to applying the principle of keeing it simple to a defense-in-depth strategy.