January 11th, 2005, 01:45 PM
Application Level Security Testing
I hope I am not repeating earlier questions... I have tried to search through the forums, but nothing seemed to be appropriate. It's a tricky concept to word, however, so I may be duplicating the idea referred to by a different phrase.
My challenge is thus: I work for a software testing department for a software company. We produce software that goes to end users, middle-tier operators and our own internal teams.
While our IT department handles our network-level security (rather efficiently) at all tiers, our produced applications get a fairly cursory test from a security perspective.
Most sites/books/tutorials/etc deal expressly with network-level security testing (with possibly the exception of web forms)... it would appear that application-level testing is a new and growing specialisation within the field. I am aware that there are tools specifically designed to test applications fro security flaws, but I have also been assured that they are not worth teh disk space they occupy.
Would anyone have any further comments, or sources that I might peruse for more information on this shard of security testing?
January 11th, 2005, 04:07 PM
Here are some general guidelines taken from my own internal testing process. I have sanitized them just a bit but this should get you going (hopefully).
1) Define application components - Example: Web front end IIS6.0, PHP enabled middleware, Oracle9is backend server farm.
2) Define the scope of use. Who will use this app? Is this an internet accessible application? What kind of data is accessible?
3) Map the mechanics of the application. User inputs, server data returned, etc..
4) Using the above information, develop and attack vector list (tainted input attacks, literal parsing of commands, etc.)
5) Have several team members (if available) design attack vectors independently. Meet and consolidate all ideas. This can include enumeration of step 1 without actually finding out. In other words, you may want to see if someone can map out your setup. This would be a bad thing given the right circumstances.
6) Carry out testing.
7) Produce a management report with a technical add on. All bases are covered this way.
8) Determine if fixes are required or additional external testing is required.
9) Repeat the process if necessary.
Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden
January 11th, 2005, 04:17 PM
edit: well there goes my post :P
January 12th, 2005, 08:09 AM
Thank you very much, that is exceedingly helpful
January 13th, 2005, 08:20 AM
Unfortunately the type of testing thehorse13 suggested will lead to poor results. Even more unfortunate is the fact that the type of testing thehorse suggested is likely to be the best availible to you.
For an organization just switching to formal devlopment model I would suggest Boehm's V&V waterfall model. This will break your product down into smaller steps (feasability, plans & requirements, broad design, detailed design, actual code, integration, implementation, and upkeep) with each step have a validation (does the right thing) and verification (does the thing right) phase. Incorporated into this of course will be a test suite at each step, so at the code level, all you need to worry about is code level bugs, not design flaws and test accordingly... etc etc.
Remember, a security flaw is nothing more that a system operating in a leveragable manner outside the design scope, if the design has not been verified and validated... an infeasable amount of testing is required to uncover all the potential problems.
Ideally the test suite will be included into the products specifications and will include test data and techniques that will exercise all of the product's paths with testing outputs correctly predicted.
This will save your company heaps of money, project time, and result in a better product.
It might be beneficial to your career to do some more research on this and get a meeting with someone higher up.
January 13th, 2005, 09:08 AM