« OWASP Helsinki | Main | Speaking at OWASP Twin Cities »

Comments

Andy Steingruebl

I'll mail them the same question I'm going to ask here...

One of the nice things about a website is that you can tailor your defenses more appropriately to the current threat model knowing that at last theoretically you'll have the option to update your defenses for new threats a a later date, thus deferring investment. You don't always have this choice when you ship client software since you don't have a single place to update.

That said - its a hard balancing act without lots of monitoring where to spend the resources up front to get it "right" and or future-proof and where to spend just enough for now and wait for threats to materialize.

Unlike architectures, scalability, and even functionality security can be an all/nothing proposition. You don't always get a second chance, once the data has been breached you're done for. This makes determining the right security investment a lot tricker under this sort of agile model...

Johan Peeters

I agree, there is no putting the genie back in the bottle. This is not unique to security. Examples spring to mind such as the electronic payment network failing on a busy pre-Christmas Saturday due to overload. You cannot undo that.
These kinds of system characteristics therefore need to be dealt with based on the expected cost of a mishap. Expected cost is defined as the cost of the failure or breach if it were to occur times the probability of an occurrence. I will not deny that both terms are difficult to estimate, but that is not a reason not to do it - just as plans are never executed exactly as they were drawn up, they are still useful. As you become more experienced in making estimates, the more accurate they are likely to be and therefore the more useful, especially if you feed back data on actual incidents into your estimating.

The comments to this entry are closed.