Re: [WEB SECURITY] definition of "web application security"?

[Pete Herzog <lists@xxxxxxxxxx>]

> I don't think this is a feasible place to go; by pursuing this course of
> logic you end up with few actual applications, because any network
> application will use the OS network transports which aren't part of the
> application, or likewise the GDI/X (or equivalent).

What the applications require, if they require, is part of an 
applications environment. An application is not a service is not the 
kernel and is not a protocol. However, contemporary use of the word 
web does put those together and more which is why it is so important 
for a consultant to be very specific on what exactly is getting 
tested. Otherwise, you end up with some of the crap that is getting 
passed off as web application security where clearly the consultant is 
hiding behind the present ambiguity of the terminology.

> > However, vulnerabilities don't enhance threats 
> > but rather they degrade the effectiveness of the 
> > separation or the controls used.  
>
> I disagree strongly with this; for the classic example scenario of fire
> (a threat), the presence of flammable materials (a vulnerability)
> clearly enhances both the probability and impact of the threat
> occurring.  The same is true for most tech vulnerabilities.

What you're saying now is that a vulnerability enhances probability 
and impact but I disagree. That risk was always there. The minute you 
put up a flammable structure that risk of burning down exists.

Fire is a great example of a physical, living threat. Add flammable 
walls and you have security with a built-in weakness-- flame. So where 
flame becomes the threat that can remove the walls, it does not make 
non-flammable materials suddenly flammable (unless they also have a 
built-in weakness). All things have a temperature level at which they 
get damaged and if fire reaches that level then fire as a threat will 
be successful. But the probability of it burning does not suddenly 
spike with the introduction of flame because that probability always 
existed at that temperature level. What you mean is that the "when" 
part of probability is more immediate with the introduction of flame 
at that temperature as a threat.

> > If you can see security as a separation then 
> > it is an absolute. 
>
> But security is rarely a separation.  For example, the primary goal of a
> firewall is to allow traffic through (obviously in a controlled way),
> not to separate.  Separation is an absence of functionality.

I never said anywhere a firewall was meant to separate. I agree it's 
not. However some internal networks are physical separations. Working 
at Intel, 10 years ago, we kept the lab network on a completely 
separate segment from the internal network although in the same 
building. They didn't even touch the same hardware. Recently I've seen 
the same being done between wireless for one network and Ethernet for 
another so they didn't touch. In this case, separation was not the 
absence of functionality but rather a different set of 
requirements/priorities.  Same can be said of an intranet web 
application versus an external one.

> > In network security you can apply controls 
> > and create an environment which requires 
> > no process cycle-- no identifying 
> > vulnerabilities or implementing more 
> > controls because it will be done.
>
> Again, I disagree. I don't think that in all my years in IT, I have ever
> seen a static environment.  Flawless products don't exist; patches are
> periodically released.  Functionality is constantly enhanced in the
> applications, the infrastructure and the controls that protect them.
> New controls are developed.  And all change requires some degree of
> analysis and review.

Static is not what I said and you're basing your answer now not on 
research but on your experience which, like mine and most others, has 
focused on popular and commercial stuff that is not built to control 
an environment. Most let the environment be open and then they add 
controls here and there to make things safer. Highly controlled 
network environments are not static either but rather they are highly 
productive environments since the only support needed is new installs 
and physical hardware fixes or upgrades. The only reason why we don't 
see them much is because they need decisive planning at onset and in 
most commercial businesses the time is not put in for this and 
restructuring is too costly and takes too much time (or know-how) to 
bother with it. It's like with SELinux- the biggest complaint isn't 
that's it's too hard to maintain but that it's too hard to set-up.

You are right that flawless apps don't exist and all apps grow in 
functionality but with the right environment where you don't have to 
put out little fires all the time you can actually focus on getting 
applications to upgrade for functionality when YOU want to upgrade 
them not because you have to patch them right away.

-pete.




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

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

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

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA