Richard Bejtlich can pack more depth into a tweet than most people can in a 2,000 word article:
Q: What happens when you try to prevent an attack by professionals?
A: You lose. So, fast detection & response is best refuge.
Security is a loser's game where you aren't trying to win per se but rather trying to avoid losses; however losses still happen. Good engineering practice means designing for failure and security mechanisms are no different.
In any SDLC security will at some point review the design and implementation against some target state, threat model and/or risk assessment. The output of this is a set of security countermeasures that the security team recommends.
But there is a critical step to iterate on here - the security mechanisms did not come down on stone tablets from Moses or something, they'e just code and in many cases built by the exact same team, and they are just as susceptible to failure as anything else in the system. So once the design and implementation is updated with the countermeasures, the target state review, threat model and risks assessment must loop through another iteration to determine any new issues.
Did I say the security countermeasures are just as susceptible to failure as anything else in the system? Actually, not quite so, I would say that security countermeasures are more susceptible to failure than other parts of the system. The reason is simple: complexity - security people rail against complexity from dawn to dusk, but in any system you will have to look long and hard to find anything more complex than Kerberos, X.509, crypto implementation, Key management, and other security countermeasures.
Security countermeasures are complex in design, implementation and testing. So the design must factor in the failures of the secuirty countermeasures themselves. This brings us back to Richard Bejtlich's detection and response guidance. Let's take an example of an access control system, much time will be spent on architecture and design of the authentication protocol, whether SSO is offered, what identity token(s) in use, how does it map to authorization, what level of granularity is authorization granted on, where is the session managed, and a myriad of other issues. However, a fundamental underlying assumption in these discussions is that the access control system can not be bypassed, but designing for failure means assuming that it can be.
Access control design tries to answer the question - who has access to what? Implicit in any access control design should also be attempting to answer the question - who accessed what? The different assumptions in these two questions is the difference between night and day. Answering who has access to what presumes the access controller can manage this relationship. Answering who accessed what is about recording events in context. And this is where detection services come in - its not solely an identity or appsec question to answer, but identity and appsec have roles to play here. There are ways to accomplish this either within and/or outside the access control system that give improved visibility into the system's use. The app, identity, and access control layers all contain context that is not possible to get solely from network monitoring (which is state of the art for most companies today).
Its surprisingly often that people building access control systems either
a) focus on the runtime but do not factor in the back end monitoring services
b) assume that it won't be bypassed
Neither of these will meet the determined opponent test. Locating log event sensors App and access control layers (and/or related subjects/objects) offers concrete improvements for what gets reporting to the log, some initial effort to design the log events messages can simplify the approach of for example rehydrating the transaction history to see the chain of events that preceded a failure of some sort.
About 400 years back, Yamamoto Tsunetomo had a great post on this:
“There is something to be learned from a rainstorm. When meeting with a sudden shower, you try not to get wet and run quickly along the road. But doing such things as passing under the eaves of houses, you still get wet. When you are resolved from the beginning, you will not be perplexed, though you will still get the same soaking. This understanding extends to everything.”
So Protection and Detection are not necessarily separate things. When designing a countermeasure such as access control the mindset should be that this protective countermeasure (and/or the subjects/objects it protects) must itself be backstopped with a margin of safety to report out any failures through logging events, and any protection mechanism should be armed with the same sort of detection services.
I think this is captured well in the security fundamental: "Protection is ideal, but detection is a must."
Posted by: Daniel Miessler | March 19, 2012 at 02:30 PM