I was having an email conversation with Nick Sivo from Loopt where he contrasted network and web application security in such a way I found very insightful.
"I should mention that many of our hires have come straight out of school. I think it's quite
possible people who have worked in industry for a while have picked up security knowledge, but it would be useful if it were covered in school as a requirement. I think that the biggest problem with web-app security is that it hasn't yet reached the point where a few very knowledgeable people can secure something. This, I think, *has* happened on the network side.
I can hire 1-2 (we're small) people to configure all of my networking equipment to be secure. It's also possible to verify that things are configured appropriately in a finite amount of time. There are still risks like buffer overflows in IOS or IIS, but those seem to be few and infrequent. Most importantly, developers don't need to even think about the network issues, except in rare and well defined cases when they need access rules changed.
On the web-app side, a developer can't really introduce a buffer overflow or a network bug, because they're using C# and don't access things at that low a level. They can't do much to affect network security accidentally. However, they all need to be aware of, and can greatly influence web-app security. 1-2 people can't secure our web application alone. It has to be a joint effort. Even though we use ASP.net, stored procedures (with no dynamic SQL), and some self-built hardening modules (ASP.net plugins that run for every request), I can't be sure I've got even most things covered. A developer can forget to encode something, or forget to check input, or use an exponentially expensive regex to validate user input. For an application to be really, really secure, each developer needs to be able to look at their code and think of all the attack vectors (new ones are discovered weekly). It's nearly impossible to achieve that."
Nick is onto something here. Network security can be handled by a handful of (market-available) people at most any normal enterprise. Web application security on the other hand touches so many others (that isn't widely market-available) that has a drastic impact on over all security. One mistake by any person and bam... well... you know the rest. Imagine that, if an organization REALLY wants to improve their webappsec, they'll still have a hard time because the skill-set isn't yet out there. This will take time, but its coming....
6 comments:
this has to do with the maturity of the industry and the social, individual, and instructional capital surrounding it.
when webappsec has the equivalent of groupstudy (social), jon postel (individual), and ccna bootcamp (instructional) - then you'll know it's at a similar level of maturity.
Agreed on one of those fancy Gartner technology curve charts I'm sure it's on the lower part of the up-curve.
As a guy slightly more involved in the network, I can say that those observations seem correct. Just some more tidbits of thoughts...
- When I look at web app sec, it is one thing to scan a site with WebScarab, another thing to have a few ways to poke at XSS/SQL Injection, but to then convey solutions on a code level takes more knowledge than it would to change a config on a network device.
- I agree with ntp on the maturity too, that helps.
- But in relation to both of those points, networking devices won't be changing as rapidly as code techniques. We could get really flippin good about securing php and maybe even javascript...but by then what will everyone be using? We have to start all over much quicker. And let's face it...so many designers/developers like creating new stuff and playing with new stuff, not shoring up yesterday's products. :\ (unfair generalization, I know!)
There is a large lack of senior people in this industry at the moment. When I use the term "senior" I mean the ability of someone to take a web application and REALLY understand the risk and security issues within that application, without using some automated tool.
One worrying aspect about all these new people starting to do web security is their lack of development experience or knowledge. When I started doing network vuln research, you needed to know the low-level languages and c (not c++, that was for the weird kids). Todays post grads have very little experience to how most common dev shops work, hence they don't know where most corners are cut and security issues introduced
Webappsec still needs time to mature, but you are right, it's getting there
mistake #1 differentiating application security from "network" security. Those of us who have done security for a while know that layer 7 is defensible within the R&R's of netsec. What gets called "web application firewalls" nowadays, we used to call HTTP Proxies.
mistake #2 calling it "webbapp security" at all. Just because its in vogue to tunnel everything through port 80 nowadays doesnt make application programming special, or really different at all. Application security, or secure programming is not so new.
Just my grumpy 2 Yen.
1) Separating distinct disciplines like nework security, web application security, A/V, authentication, encryption, OS security, etc. helps make the problem sets easier to understand and address. Few people have really good cross disciplinary skills to tackle several of these problems effectively. And as for HTTP proxies, terminology changes over time. Today there are not 3 ways to deploy WAFs. Reverse proxies, web server software modules, and out-of-band network devices.
2) "Application security, or secure programming is not so new." I'd agree with you about 90% or the core fundamentals. However, the web development environment has significantly changed the landscape with regard to new attacks and attack variants... new solutions and solution implementations. Not to mention the sheer scale out there. CAPTCHA is a good example of defending against bots. XSS and the aspects of DOM trust across domains is certainly a new concept as well.
Post a Comment