Question: I've asked a few questions relating to schemes for various security-related functions, and posited schemes to accomplish those goals. In the responses, I see a conflict between two fundamental principles of IT security; "defense in depth" (make an attacker break not one, but many layers of information security) and "Complexity is the enemy of security" (the KISS principle).

The question IMO is obvious; when does one of these two take priority over the other? You can't have both in the extreme; adding layers necessarily increases complexity of the system, while simplifying security typically "thins" it. There's a spectrum in between "ideal" complete simplicity and "ideal" infinite depth, and thus a balance to be struck. So, which of these, when they conflict, is generally to be preferred in the design of an information security scheme?

Answer: 
"Defense in depth" is usually pushed out of a feeling of paranoia. You implement layers upon layers of defense in response to panicky rants from upper management.

"Low complexity" is usually promoted in order to reduce costs and delivery times. You reduce complexity so as to meet the deadlines imposed from upper management.

Often, "upper management" will insist on both aspects at the same time. It is then your job to notify them of how irksome and pesky details like the Laws of Physics may prevent or slow down the simultaneous fulfillment of both goals.

Ultimately, this is not a technical decision; this is about *economics*. Risk analysis ought to put a price on intrusions, and thus assess how much money defense in depth may save in the long run, by containing damage resulting from a successful attack. Similarly, increased development costs and delays will be given their own financial estimate. It is up to the decision-makers to balance these costs as it best suits their strategy; the important point being that this is a matter of *policy*, not of *technology*.
This is a good question. I think that you can have both defense in depth and simplicity without contradiction.

Defense in depth is redundancy is security controls (defense mechanisms). One control can fail but it is much less probable that two or more will fail at the same time.

As for simplicity, it depends on what area you are targeting. If you're talking about applications, systems, processes you are trying to protect, there's no controversy. They should be as simple as possible and still be able to accomplish the task at hand (I know this is easy to say but difficult to do).

If you mean simplicity in security controls, I agree with AJ Henderson that they should be as simple and as independent as possible (the same principle as in the paragraph above). The only problem is related to the number of these security controls; zero is definitely more simple than three. Here you should consider the probability and impact of the "problem" you're trying to protect against. The higher the risk (probability x impact) the more security controls you should deploy. But there is probably a break point in number of controls (like three) where the ratio of added value vs cost gets very low.