RE: Security Testing

The first thing you are going to need is some kind of control over each application requirements document. In every requirements document, there is going to need to be a high-priority, un-deferable requirement for zero high-risk security exposures, and some definition of what is meant by that - secure from anonymous people, secure from users, secure from people who have read the source, etc. This is probably the most crucial step, and will save you boatloads of money. If it's not in the requirements, then it won't always happen in engineering, which means it won't get caught until QA or some external audit, at which point the application may need to be shut down and fixed, or possibly re-architected. Making it a priority from the start, which means putting a line in the actual requirements document, is the signal that management "buys-in" to the security idea.

Next I would recommend that you have (at least) one of your engineers be the "security architect". This is the guy who is going to have to know all about web application security exploits, and safe web application coding techniques to avoid them - this means he goes to black hat & defcon & reads all the whitepapers and *definitely* subscribes to this list. To get your money's worth, find somebody this appeals to on the dev team, don't give it to somebody who thinks "Oh geez, I have to learn all this HTTP nonsense". Like most architecture people, he is going to need decent people skills cause he is going to be in the business of telling the other engineers what they are doing wrong and getting them to do things right.

Suggestions that engineers should not test the security of the code are well-intentioned but misguided. Having the engineers write test-drivers for their code is an excellent practice and can ensure higher productivity and fewer bugs. This is true for the security area as well, where an engineer who understands web application security exposures *and* who knows how the application works could quickly write tests for crucial issues. While some would say that developers might be motivated to cover up security issues, my experience with development (admittedly limited to working with highly-motivated world-class engineers) is that you are far more likely to have product managers and engineering directors (i.e. those with substantial bonuses on the line) try to cover up or defer issues than you are to have engineers do so. But rather than blindly trust in the engineering pride-of-ownership, we should institute some checks and balances.

This means the QA staff should also be testing for security weaknesses. At least one person on the QA staff should also have a good understanding of web app security, and a knowledge of how to exploit web app bugs. Because of the requirements document, security bugs that are found by QA should be high priority and as non-deferable as possible (this is another one of those places where management commitment comes in). The QA staff should be aided by automated web-app security testing tools, and get some training in how to use them.

For best results, a periodic external security audit is a good safety net that can help catch things missed by the internal staff.

I guess the biggest point is, don't take those who say "only QA should do security testing" literally - in particular, don't make security a non-issue until it gets to QA. Security should be a requirement, a design goal, a bunch of functional items, there should be engineering tests for it if possible, strong QA testing of it, and occasional external review. Starting security in QA is definitely a bad idea.

I don't think any of the previous posters would disagree with these points either - this is just a more verbose answer.

Good luck with your CMM program!

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Phil

> -----Original Message-----
Received on Mon Mar 3 16:05:46 2003