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.

• Before You Begin:
• Calculate how much $$$ you can invest in security.
• Arrange your team (You need a PM, QA, Coder, and a Security Expert. One person may double duty or you may have a consultant. You probably already have someone in house that can be your security resource.)

The Kindle shares highlights

The Amazon kindle recently added a feature that shares "Popular Highlights" with other people. If many people highlight the same passage, then you'll see the passage highlighted on your own Kindle. If you select it, you'll see a popup showing a message like "11 other people highlighted this part of the book".

On one hand, this is a possible privacy violation. I don't see anything wrong with it yet, but it's exactly the sort of thing that makes me uncomfortable. Kindle shares your highlights this way by default, although you can turn off this feature.

On the other hand, it's a fascinating new way to read - something you can't get from paper. While reading, it encourages you to slow down and pay attention to what other people have found interesting. Likewise, if there is something that you think other readers should pay attention to, you are encouraged to highlight it for them. It's like a 21st century of a book club (where a group of friends read the same book and talk about it), but you are sharing your thoughts with the entire world.

I've read three books since Amazon published this feature (actually, since I've noticed this feature - not all books have highlights).

The first two are fictional novels, Nation by Terry Pratchett and Pirate Latitudes by Michael Chrichton. The thing I noticed in these books is that the highlights don't make sense - the passages aren't necessarily witty or insightful.

However, there does seem to be a rare word involved. For example, in Pirate Latitudes, the highlight (11 people highlighted it) started at the word "uxorial". I suspect that the reason those 11 people highlighted the passage is because they did not know the meaning of the word (I certainly didn't).

Do people highlight vocabulary words? Or is it an accident? The Kindle contains a built-in dictionary. Once you move the cursor to the word in order to see the definition, it's easy to accidentally highlight the word as well.

Highlight should be more meaningful for non-fiction books. The third book I've read recently is Ayaan Hirsi Ali's Nomad. This is a book critical of Islam and which promotes the values of the Enlightenment. It is political and controversial. I know that as I read it, I highlighted several sections I thought were interesting.

For example, she relates a story where as a translator were a 7-year old Somali kid beat up another kid at school. Her story told of the conflict she had as a translator that required not only translating the language but also the culture. The Somali family felt that the other kid (Mark) started the fight because he hurled insults at their kid (Mohammed). The school was adamant that Mohammed started the fight, because he threw the first punch. This is an incomprehensible cultural divide: Somali parents teach their kids to fight, to defend themselves from insults with violence. Western school teaches kids not to fight, to ignore insults.

I was interested by this anecdote, so I highlighted it.

But there were no Popular Highlights in this book from Amazon. This is probably because the book is so new, it's only been out a couple days. Maybe I should have put off reading it for a few months, to see what highlights others might be interested in.

Or, maybe I'll skim it again in a year, to see what other people have highlighted. This would be an awesome feature for Amazon: to allow me to browse a book based on the highlights they've got on their servers, so I don't have to flip through the pages myself.

So, for the last three books, the "Popular Highlights" feature has been a bust, but I have great hope for it in the future.

You don't have executive buy in

When to fix low-priority items

There are two classes of security problems you need to fix.

The first is the "high priority" bugs, the ones with such severe consequences that you must fix them, even if they cost a lot to fix.

The other is the "low cost" bugs, one that cost so little to fix that, that it's worthwhile fixing them anyway even when they have no practical threat.

Programmers do this all the time. They fix "warnings" in their code simply to silence the warning-checker, even though there is no real problem with the code they've written.

Managing the process needs to be light-weight as well. Instead of individually tracked issues for every bug fixed by the programmer in this manner, there should probably be a single bug in the tracking database with the report. The programmer is given a budget of time to fix as many of the warnings they can, then at the end, report the number that they fixed.

Does buying a WAF solve the problem?

SDL is never done

Once 

Security bugs as functionality bugs

Security bugs aren't bugs.

A "bug" is when the software accidentally crashes. A "security bug" is when a hacker makes your software crash. If there were no hackers, there will be no "security bugs".

This is why support organization don't respond to security bugs, because they ask "are you a customer?", and the hacker says "no", so they respond "it's not a bug, only things customers report are bugs".

It's a light-bulg that needs to go off in everybody's mind, CEO, program manager, customer support, QA testers, engineers: some security problems are "bugs" or "features".

To start with, you can think of a "security bug" just like any other bug or feature request.

But that's not the entirety of secure development. There are things you would do for security that you would never do for normal bugs/features.

Temporary SDL

The first incident creates a temporary SDL: how do you fix the bug that caused the first incident.

After that incident is over, now go back and create your real SDL.