[WEB SECURITY] The Möbius Defense, the end of Defense in Depth
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
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