Thou shalt have no other gods before the ANSI C standard 1617
My personal preference, on either side of the issue, starts with scenario analysis. The "what might someone (attacker, defender) try and do" questions. For a very early e-commerce web site one question I asked the team members was "would you purchase a House Pictures using this site" and "would you purchase a shirt using this site."
But the attackers and defenders will come up with their own (often never explained) scenarios. Formalizing this and sharing it across the group seemed to help. You hope that both sides will, from time to time, say things like "WOW, was THAT ever a sneaky (attack, defense).
Yes, and that it what I had in mind with the short phrase ;-)
Thou shalt have no other gods before the ANSI C standard 1618
I'm one of those a.f.c. posters, and have never suggested such a thing. Your point is exactly correct though, and should be part of the test plan...
Thou shalt have no other gods before the ANSI C standard 1619
Trevor L. Jackson, III Actually, no, that's not what I had in mind. What I had in mind is that testing is not a very effective way of buttessing the security of...
Agree. It helps to make the process "fun" and "exciting".
Agree, but also think "random" attacks are helpful, and can often be automated. My wife calls this the "monkey on the keys" phase. By this she means feeding the system under test random, and intentionaly malicious when you know what that means, input via whatever means the system can accept input. It also means doing things like "accidentally" bumping the circuit breaker that takes a string of disk drives offline, etc. etc.
Agree, and will again suggest "honeypot" testing as a helpful addition.
Alt Folklore Computers Newsgroups