[WEB SECURITY] The Möbius Defense, the end of Defense in Depth

Pete Herzog pete at isecom.org
Wed Jul 8 13:47:03 EDT 2009

Hi Paul (and the webappsec listeners),

> You certainly did a good job of keeping the entertainment value up, I 
> will most likely nick some of your ideas for presentations in the future.

Please speak highly of us when you present with Playmobile then. I 
really can't ask for more.

I'll be releasing the notes soon as I'm halfway done writing them but 
we have so much going on that it's taken longer than I wanted it to.

> But I want to challenge your claim of "the end of defence in depth". I 
> think we agree on the definition - it's layered security. We accept that 
> we'll never get one layer perfect, so we introduce multiple layers to 
> deal with this. The analogy to military defense in depth is just an 
> analogy, the layers aren't the same.

"Layered security" is one of the definitions I have found for network 
DiD. There are a few.  That should show you that people who are new to 
network security or merely users of network security will have trouble 
getting a straight answer about network DiD. Personally, I liked the 
military definition and parts of it really could be directly adapted. 
Too bad the phrase got completely re-defined for network security use.

> Looking at your example of SQL injection against a web server, I'd 
> challenge a couple of things. Firstly, a firewall and database 
> encryption are not defences against this kind of attack, so it's no 
> surprise that they don't help. As for the WAF, you quickly dismiss this, 

But you do agree it meets the definition of DiD as layered security, 
right? I think that's part of the problem. When you back a security 
model and find it is flawed like that it's time to question why. I'm 
sure you and many people on this list have had that palmface moment 
when they see multiple firewalls lined linearly on the network or AV 
on EVERYTHING as interpretations of "layered security". In the first 
example the layer is taken literally and in the other it's taken 
logically and both wrong. My point is that this set up is perfectly 
correct by definition with multiple levels of defense and it still was 
not good. You say so yourself. Looking at this matter with fresh eyes, 
you will see that the problem isn't so much that it's the wrong 
controls for the interaction but rather WHERE the interaction takes 
place. Suddenly, the SQL server is its own perimeter. (Logically we 
can say it's part of the perimeter.) This isn't because the logical 
layers don't make sense but because the interaction is directly 
between the external user and the DB abusing the trust relationship 
with the web server.

> as being subvertible by encoding attacks. I'm not a WAF expert, but I 
> expect any decent WAF would not be so easily fooled. Sure, it's possible 
> to bypass the WAF in some circumstances, but then that's exactly the 
> point of defence in depth - no one layer is perfect.

One does not need to be a WAF expert to see that the WAF described 
here is a defense for the user / web server access interaction not the 
webserver / DB trust interaction. The only control the DB has in place 
is encryption, what we call Confidentiality in the OSSTMM. 
Unfortunately that control is likely to protect only against physical 
theft, from a different vector and a different Channel (again an 
OSSTMM term). However, since it's on a server, people not informed 
like you, me, and the webappsec listeners, typically confuse that 
control in that way with network defense.

So again, if I accept your definition of DiD, this network is layered 
correctly with a variety of controls even but still not good enough. 
But the idea of layering failing here is NOT because one control is 
not perfect but because one control is often not useful as a single 
control or too narrow to cover all Channels (any of physical, 
wireless, telecommunications, human, or data networks channels). Is 
this because the definition you provided of DiD is wrong or because 
DiD for network security is wrong?

ISECOM is saying you need multiple, varied controls to improve the 
protection of interactive points for each available Channel and vector 
to the target. There are no true waves, layers, depths, heights, or 
whatever you want to call it.

> I'd see several layers of defence against this kind of attack:
> 1) Train developers to code in a way that avoids SQL injection (but some 
> may occur anyway)

You train coders to create interactive code that is not fallible to 
malicious or accidentally detrimental interactions. They do this by 
either putting controls on interactive points within their code or by 
not having those interactive points. But that does not make them a 
control any more than the coach who trains the football defensive line 
is actively involved in the blocking of a pass at game time.

Preparation, education and training are no part of any definition of 
defense I've encountered. They can help assure proper deployment, 
proper maintenance, and appropriate skill levels but not actual defense.

> 2) Conduct testing to catch any vulnerabilities that exist (but some may 
> be missed)

Testing is Offensive. Not to be picky but it's not a defense and no 
offense will pass for security unless it's in the elimination of the 
threat. Again, this is maintenance to make sure your defenses and your 
operations work as you want them to.

> 3) Use a WAF to protect any vulns that remain (but the WAF won't catch 
> everything)

Okay, I agree with this as a theory. Any device which performs one or 
more controls on the network channel is an actual defensive 
operational control. Depending if it's a blacklist, whitelist, anomaly 
detector, etc. will matter as to its effectiveness to a certain class 
of attack but it's still providing one or more controls.

> 4) Configure the database to minimise the impact of an injection attack 
> (but you'll still be able to get somewhere with an attack)

Configuration isn't a control. It's like training except instead of 
training flying monkeys you're training the application with 
instruction code. Your configuration will either close interactive 
points in the application by limiting the commands allowed or by 
adding controls like Authentication to filter or limit the 
instructions and authorization acceptable to respond to.

> 5) Logging, backups, insurance, etc. (but this just helps you recover - 
> if you need this, there's been an impact already)

You mention 4 operational controls here. Logging is a weak form of 
Alarm and Non-repudiation. Insurance is a form of Indemnification. 
Back-ups are a weak form of Continuity. That's pretty good stuff. 
Alarm and Continuity are Process controls which don't interact with 
the attacker but Indemnification does. Indemnification is classified 
as an Interactive Control and only works when the attacker interacts 
with the network (otherwise if there's no attack then it could be 
insurance fraud). Insurance pay-outs usually only work though if you 
have 2 additional controls: Nonrepudiation (prove when and what the 
attacker is/was) and Integrity (proving the state of the 
system/data/network really changed). Of course you might just be able 
to find a very lenient and generous Insurance Company who will take y 
your word for it.

Combined with the Authentication control from the WAF and you've 
already placed 5 different controls (out of a max variety of 10) which 
will protect various interactive points (hard to say in your 
theoretical situation because insurance usually covers more than just 
the one server but maybe the back-ups are only of the DB).

> And I'd say for a high-security site, all of these are worth doing. Not 
> for every site, sure - for a message board, a WAF would not be justified 
> and penetration testing would be a luxury more than a must have.

I don't see why you can't have multiple controls for EVERY site no 
matter what you do. Especially if you hold other people's information, 
habits, messages, or whatever because you are responsible for what 
happens to them there as much as a store owner is responsible for a 
person slipping on a wet floor in their store. The testing, 
configuration, and training (the NOT controls) are, to some degree, 
always a requirement because a mis-used or poorly placed operational 
control can just add to an attack surface rather than help one.

> You've probably had a ton of messages along these lines, but I'd love to 
> hear your thoughts.

It's all good. Questions give me the chance to re-examine our work 
from other perceptions.

The biggest problems with DiD for network security are 1) the unclear 
definition for those new to security, 2) the fact that the modern 
network has no real perimeter as threats can be introduced anywhere 
there is an interactive point from any vector meaning a lack of 
layers, 3) the fact that it's a zero-sum game where each attack either 
succeeds or fails at once according to the controls chosen, and 
4)logical depth whether classified as time, channel, or vector, 
doesn't matter when the defenses operate all at once in that instance 
because either that attack works or it doesn't. Hence why we came up 
with the new model, the Möbius Defense.


Pete Herzog - Managing Director - pete at isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.isestorm.org

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list