Stuff to follow up on

2 main points to follow up on:
One) The cost of doing secure code. How much real information can we get here? How can we know?
Two) PR. The reputation microsoft has about the SDL is that it's too hard and not for them. How do we make people feel that they ARE the target audience? Who IS the target audience?

Stories about real companies that have had X vulnerability.

Compiler is important, but the highest warning level is quick and cheap. The other tools like static analysis is not as cheap.

Existing code: you know it solves the problem and you may not even know how to do it yourself. Most of the world is visual basic coders. Visual Basic SQL Query is a good example to do.

SECURITY BUGS as FUNCTIONALITY BUGS. First figure out how you fix functionality bugs. Who are your resources? How does Support handle a security bug report? "Are you a customer? No, what do we care then?" The lightbulb in the organization has to go off that says this WILL effect the org, even if it isn't now. Be aware that the security community has a process that they all use for disclosure. The support team needs to be familiar with this and know what to expect. They tell you, and then a couple months later, they release it to the online community and you need to be ahead of that PR wise. Security bugs are bugs even if the customer never is effected or experiences it.


WAF- it doesn't stop the good hackers, but maybe all you care about is stopping the kiddies. security is a tradeoff.
CLOUD
policy as a fix?
Bruce Shneier said security is a process not a product

What about threat modeling? Huge documents that just says "everything outside is external." The threats might be complicated but they're also common

There are synergies with PCI/HIPAA but those don't make you secure and this isn't that.

How long? How much?
tradeoffs?

writing your own bug tracking system, build it and you save money on training

automated nightly builds

http://tacticalwebappsec.blogspot.com/2010/05/bsimm2-and-wafs.html
dre said...
"How can you ensure that your DAST tool has been able to enumerate and test out a high percentage of your site's content?"

You use tools such as FilesToUrls.exe from HP or PTA from Fortify.

Really, you just take the FilesToUrls.exe tool and perform a list-driven assessment. Then you need to follow it up with a workflow-driven assessment or similar, especially if the app has dynamic behavior (e.g. ajax, js libs, swfs, et al).

"QA teams are typically in a great position in the SDLC phase to potentially catch a large number of defects, however they are typically not security folks and their test cases are focused almost exclusively on functional defects"

You use tools such as PTA from Fortify, Watcher WebSecurityTool from Casaba, or Ratproxy to monitor their functional tests. You share test cases, test harnesses, and other information.
May 27, 2010 3:53 PM

http://www.infosecramblings.com/2010/05/25/secure-coding-ask-dont-tell/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+InfosecRamblings+%28Infosec+Ramblings%29
Thought #1: Ask, Don't Tell
I recently attended a class provided by my employer called Adaptive Leadership. One of the tenets of this class is that is often more productive to ask than to tell. What does that mean?
When we tell somebody to do something or give specific instructions, they have no investment in the outcome.
However, if we ask the right questions and lead their thoughts down the right path, we give them the opportunity to invest in the outcome. If we do this well, we then have somebody who has convinced themselves that this is the right thing to do, whatever that right thing may be.
--