Re: Security Test Cases for Testing

["Dana Epp" <dana () vulscan com>]

I've always found that its much easier to write security tests once you know
the threats that you are susceptible to, which can be typically defined
during threat modelling at design time before you even write a line of code.
And then again midway during development, and finally on completion of
development. I think that in many cases the idea of test-driven development
(kind of like how extreme programming is done) but focused on security could
make a significant impact on the test harnesses, and the quality of the code
being produced because tests are continually being produced as the product
matures. More importantly, as bugs are found these new security tests can
ensure than the bug does't reappear down the road when others are
refactoring the code.

Which has me thinking about some of the automated tools out there that I
just haven't had experience with yet. Has anyone here worked with Cenzic's
Hailstorm? I looked at this about a year ago and thought it was interesting,
but focused on web apps (which I don't do much of). Anyone know of something
similar for stand alone apps? How about kernel components?

Would love to know what tools are being used elsewhere.

---
Regards,
Dana M. Epp
[Blog: http://silverstr.ufies.org/blog/]


----- Original Message ----- 
From: "Kenneth R. van Wyk" <[EMAIL PROTECTED]>
To: "Gene Spafford" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, December 19, 2003 6:06 AM
Subject: Re: [SC-L] Security Test Cases for Testing


> On Wednesday 17 December 2003 20:12, Gene Spafford wrote:
> > We label too many surprises as security problems.  The fact that we
> > are employing ill-designed software in the first place is the
> > security problem.
>
> I couldn't agree more.
>
> The initial posting in this thread presumed that all testing is done
during/
> after the implementation, however.  What about "testing" during design?
> Naturally, testing during the design--and I'm including requirements &
> specifications phases here in a broad sense--is going to be very different
> than running tools that detect SQL insertion, XSS, buffer overruns, etc.,
in
> source code.  I've seen some design-time testing methodologies and tools
> (e.g., formal methods for proving safety-critical designs against logic
> flaws), but it's certainly an area that isn't as practiced as
> implementation-time testing.
>
> Cheers,
>
> Ken van Wyk