If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Application Level Security Testing

Hi,

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?

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.

--TH13

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

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.

We already have quite a complex formal testing structure within the company... unfortunately not as far up the development path as we would like, but we're wading against the twin tides of the legacy system and internal politics. I'm pretty sure a similar battle is waged around testing teams the world over

Our internal structure is similar to the waterfall system, with a few refinements made to suit our end product environment... the testing that I am personally involved in occurs at around the integration stage. I'm just looking for techniques (and tools) that specifically approach testing from the perspective of security (I'm sorry for the confusion... in my head it sounded clear in my original post, but having re-read it I realise otherwise).

thehorse13's suggestion of a component-based approach sounds like it could be quite effective. I'm busy badgering our poor abused developers for as much information as possible to map the communication pathways between the components and the mechanical responses... hopefully I can find a few cracks to drive a wedge into

User inputs and the like are already pretty well covered by our general testing. Perhaps I can add a little SQL injection and the like to our web forms, but I suspect that the devs already test for such 'common' tricks.

I like the idea of the black box enumeration. I'm curious as to how much information we can find from outside... might have a few nasty surprises waiting there.