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.
--

Phase 5: The Release

• PM - Hand off product to Marketing/Distribution 
• PM - Edit SDLC to learn from the process, attempt to make less "top 20" mistakes next time ("The second time, get it right the first time.") The SDL is always evolving. Agile development is about solving bugs that happen accidentally, the SDL has to always change because the hackers are adapting all the time. These are not accidents. This isn't something you do just

Phase 4: The Sanity Check

• QA - Classic functionality test
• QA - Verify the known bugs have been patched (Defense in Depth: Test the patch to verify it fixes what it needs to and doesn't break new things. Essential to not have coders verify their own work to solve most problems.)
• SE - Sign off for release OR send back to coder for Phase 3

Phase 3: The Static Analysis

• Coder - Manual code check of the list (Here you decide what of the automated tool scans needs to be fixed.)
(Zero warnings effect - fix the 100/213 low one line code bugs because the cost of fixing them is very low and the benefit of having no warnings is high. coders do this with code warnings in the compiler all the time. Makes better code management. SO here you're fixing the High Impact and the Low.
Ask your coder "Do you understand what SQLi is?" Coder managers need to fix the coders. Can't assume that it's obvious to everyone.
• Unit test in isolation (This works if there are units. How do you unit test if you have no units?)
• Coder - Remediate the security holes in the code

Phase 2: The Gauntlet

• QA - Run automated security tools that search code for common bugs (This first pass saves the coders time and the results provide accountability.FIx your org)
• 20 Common Bugs list (QA checks for low hanging fruit tailored from sources like OWASP, SANS, and the personal expertise of Errata Security research in the field) (This is the list for things you DONT need to worry about and ones you do. Always be afraid of SQLi, even if you don't have a website proper))
REAL PEOPLE dealing with the huge false positive results.
• QA- Pass the results to the Coder.

Phase 1: The Template

• SE - Choose the template that fits the software (Errata Security has 10 templates for a secure software checklist. This is going to tell you what to do) (Templates answer BOTH code bugs and human bugs)
WHAT IS THE SOLUTION? Decide here if you're just going to use an appliance instead. We don't suggest this as an easy fix. Security is a process not a product.
• PM - Build the Requirements document from the template. 

Phase 0: The Incident

• Receive email notice of security breach. ("security@domain.com" and triage) (ALTHOUGH YOU PROBABLY DONT EVEN HAVE THIS, and even if you do you you're getting false positives)
• Activate Incident Response plan. 
• Put out the fire. (The best thing to do is to assign ONE person to put to the update. There is a difference between how you put out your first fire and how you put out fires from then on. After your first one, your CEO should not be getting involved. You will handle your first incident very badly. Your PR department is going to deny it. This is bad, but always happens. You will make mistakes we wont anticipate.)
The next question is, if we got hit with an SQLi how to stop SQLi from ever happening again.