My Issues with Application Security

Before I begin this post let me preface it with saying I believe in Application Security, however, I have some major issues with it in its current incarnation.

First off what is application security? Application security is finding flaws in the design and implementation of software written for all computer devices. This is a huge field and one that I find interesting because it boils down to a cat and mouse game. You as a the security tester need to know more than the developer and other attackers to find flaws before them.

So what are the issues? I think the main issues are:

• Relationships between security researchers and software vendors


• The FUD that is generated by security vendors


• The immaturity of the industry


• The direct conflict between good software and good security


• Very few holistic views are taken with software

The first two issues have been touched on by many people and I think are getting better. If you want to know more search on "full-disclosure", "RFP", "security bullshit", etc... I am really not wise enough to speak on these things so I am leaving it to the brains of the world.

However, I think I can speak on the last three as it is something I have spent time thinking on and analyzing what people do. Granted I am sure there are other people who have been looking into these issues longer than I.

The immaturity of the industry

Application security really has only been around for roughly 15 years which isn't that long in the whole scheme of things. There are many people who know a lot of information about computers and how those things can be used maliciously which is cool from a geeky stand point. However, I often hear people say why isn't company "X" finding all the security bugs. Well why isn't the same company "X" finding all the functionality bugs? Because it is impossible. However, if you look into functionality testing they have planned ways of testing most functionality to minimize the number of bugs being shipped. Why doesn't security have this? Currently from what I have seen there are a few common ways of testing for security things:
1) Use an automated scanning tool
2) Do code reviews
3) Do a penetration test
4) Focus on specific bugs (i.e. focus on XSS, buffer overflows)
5) A combination of all of these

Now, doing a combination is the best of the choices from this list. However, it is missing two main issues. Which is testing is still ad-hoc and two it doesn't get at the root of the problem why can't we make tools that make it harder for devs to make simple mistakes that cause stupid shit like XSS. Very few security testers I have met have done things like corner cases, boundary testing, equivalence class testing, etc... I guess overall most security testers look for the big bug and sometimes rush through the "boring" stuff. On top of that I find most security testers lack the majority of skills that the true hackers have (great coding skills, love of deep technical knowledge and the most important skill a very malicious view of the world).

The direct conflict between good software and good security

There is a direct conflict between easily used software and good security. Why? Because a lot of security involves putting up road-blocks for attackers and programs are not smart enough to figure out if the user is dumb or malicious :). I am guility of offering a software solution to a security problem and in my mind I am thinking "god, this will blow ass for normal users." For a great example look at Vista sure it might be more secure than other OSes but the pain threshold of this OS is very high. Another example is OpenBSD which is pretty secure by default. Is it easier to setup than a Fedora, CentOS, Ubuntu linux install? Nope it is tougher. This means that the business needs to weigh the security implications against the usability of the product.

Now, there is a caveat to all of this. There are two types of security bugs in my mind. There are the low-hanging fruit like: XSS, Sql Injection, CSRF, Buffer overflows, etc.. that boil down to poor input validation and output encoding. Then there are the nasty bugs that usually stem from very poor design decisions. This point only really affects the design level issues. If there is validation or encoding issues those are just bugs, it just takes someone who is malicious of how to spin it to their advantage to take control ;).

Very few holistic views are taken with software

This I believe is an issue with the majority of software developed and not just security. It is rare to find a developer who has read up on usability, user-centered design, understands security, knows about internationalization, business & business decisions, psychology, how to write good copy, project management, testing and how to write decently maintainable code and probably 100 other things I am forgetting to mention ;). This is because just by itself writing good code is fucking hard. I don't mean it is mentally challenging to write the code but making sure you cover all the corner cases and it is well documented and has decent test cases covering the code it takes a lot of grunt work that most people are just too lazy to do (yes I am rather pessimistic :D). But this is something that I think is at the center of new methodologies like agile, ALT.Net, etc.. More of the newcomer developers and smaller businesses do cover a lot of these issues because they "get it." It seems that the bigger companies don't currently get this though, probably because they have a lot of older grumpier people who don't want to change and normal grunts who don't believe all of these things fit into their job description. So, what impact does this have on application security? Quite a bit. If someone understood all of these things some of the security issues I believe would be gone. Good usability re-enforces good security, good coding practices minimizes a lot of the low hanging fruit security bugs, etc..

Well I guess my main point in this article is to express some (although not all) of my frustrations with the current state of application security. I think it will be interesting to look back in 5-10 years if I am still in the industry and see what problems still exist and what new ones there are!