In my experience, a tiered approach is useful. The higher up you are in the
policy framework, the more general and time-enduring the content should be.
The farther you progress down the framework to a more detailed level, the
more perishable the content will be, out of necessity. The reason that
At 12:34 PM -0400 5/23/07, McGovern, James F (HTSC, IT) wrote:
> If one can produce a metric, scorecard or other terms attractive to
> modern IT executives, it is certainly more attractive than engineering
> practices they don't understand.
A good metric would be what development process was used
All,
My last two posts to Cigital's blog covered whether or not to build your
security standards specific to a technology-stack and code-centric or to be
more general about them:
http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e
2%80%9cspecificity-knob%e2%80%9d/
And
h
Peter, I think I agree with your comments at some level but disagree at
another. Your comment about using languages and tools is spot on yet the reason
no one is actually approaching it from this fashion is that you can't make
money off it. For example, if we all jumped in and make the GNU C com
[snip]
>
> Good to see that folks are expanding the criteria in terms of
> what it scans for, but criteria as to how it integrates is
> also equally useful.
>
On the contrary I find the idea of evaluating tools by "what they scan
for" very disturbing. It shows a continuing belief that soft
I think my thinking was a little different. I would also expect criteria that
shows how it integrates into the entire lifecycle. For example, scanning source
code that is already extracted is a little different than scanning a PVCS
repository. Likewise, taking a list of vulnerabilities and under
SC-L,
Saw this via Gunnar Peterson's blog (http://1raindrop.typepad.com/
1_raindrop/2007/05/common_attack_p.html)... Check out Mitre's first
draft of CAPEC, the Common Attack Pattern Enumeration and
Classification database (http://capec.mitre.org). It complements the
existing CVE (http:/
