Software testing.

ecksor

How many software testing/QA people read this forum?

How often does security figure in your testing plans, and how do you test for security? Good testers appear to be a rare breed, but I'm sure there's some method to it Seriously, resources, comments, pointers or any general discussion on security testing would be welcome.

MiCr0

i work in software integration into a live network enviorment
does that count?

ecksor

Yes, you may now read the second paragraph of my post.

MiCr0

Originally posted by ecksor
How often does security figure in your testing plans, and how do you test for security? Good testers appear to be a rare breed, but I'm sure there's some method to it Seriously, resources, comments, pointers or any general discussion on security testing would be welcome.

we use 3 differnet levels of testing
function
system
network integration (i do this)

i terms of testing security we check that you can only have real values and check password length etc.
just generally good sysadmin stuff
keep up to date with patchs
verify access permissions
proper passwords
stuff like that

more as i think of it*

MiCr0

* this may get completely re-written when i'm more awake

Trojan

Not 100% relevant to testing, but here ya go anyway.

This /. article mentions this presentation on secure programming and Open BSD.

Wheelers presentation is here.

Al.

[edit]Fix url[/edit]

Gunn4r

I am in testing and have been for almost 5 years. I have done all types from manual to automated / stress / load etc. In the 5 or so companies I have worked for I have seen two scenarios with regard to security:

1) One company had their own risk management department who examined all software produced for security problems, this was due to the sensitivity of the data.

2) Most places this is overlooked unless you have good testers who take initiative (seeing as you asked I am guessing you are one of them). In a nutshell good testers should raise sec. issues where they see them although this is somewhat dependant upon whether or not the person has more than just a passing interesting in security (.ie know what to look for / try)

ecksor

I do security QA, but mainly by code review, and I'm usually successful in finding vulnerabilities and other bugs in the code I'm given to review. I'm essentially investigating testing techniques to figure out if there are scenarios where they can give extra assurance, of where they can help me satisfy other constraints (I wish I was better at finding vulnerabilities in applications I don't have source for, for example).

logic1

I've been doing QA for the last year or so.

We usually don't have access to any source for products but are in contact with the Dev teams.

There's a method used for all QA work including security.

Each product will have a Design requirements Document a Product Requirement Document and several other documents. Each area or feature within that product then has it's own set of documentation detailing how each "feature" should operate and the error conditions and routines which have been established.

We then run through the test cases for each feature of the client, stepping through each area until all requirements and features have been satisfied logging bugs as we go.

After you have finished with the test cases you progress to Ad Hoc testing for as long as resources allows. Ad Hoc testing has ranged from simple checks on the client to sniffing and packet analysis for each packet sent and received on a bank of control pcs.

If the documentation isn't written up it can be quite difficult to find bugs in a client with no access to source but IMHO familiarity with a piece of software will go a long way in helping find out it's pitfalls.

We try to install all software we test onto our personal work PCs aswell as our test PCs and I find often you find bugs through every day use of the software outside of test cases etc...

.logic.