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.

Anyway, thanks again for the comments. Some inspirational stuff