Symantec (my employer) was not compromised.

The “intentional” point is that there is a big difference between what your browser says is “valid” and other things that are discussed on this blog and others… But yeah, it’s a sisyphean point of little value.

My gut tells me that September 2011 month is curiously lined up with the death of Diginotar. I wouldn’t be surprised if either “top mgmt” finally asked questions, or if security managers finally bit the bullet and pushed the information upward.

Considering how busy “top mgmt” is with everything else, I’d personally say some of both of my gut feelings are correct…

Everything that I’ve seen so far on Continuous Deployment, and evidence from the continuing security and privacy problems at sites that use it, points towards it adding to security problems, not minimizing them.

I wrote about this almost two years ago:

http://swreflections.blogspot.com/2010/03/continuously-putting-your-customers-at.html

The problems with Continuous Deployment today are the same as they were then. Passing a set of automated tests isn’t enough to prove that a system is secure – at least not with the kinds of tests that we have available to us today.

There are so many pitfalls and potential fallacies when we approach security in what appears to us as a logical or formal way that the agnostic machine-learning approach may be the best that we know to date.

Sounds reasonable, but: how often do we really know probabilities in information security, how often do we know them beforehand, and how often do our design decisions change probabilities in a perfectly predictable way? My answer – which I would be happy to see corrected with sufficient evidence – to these questions is: almost never. If we are honest with ourselves, more often than not we have not the slightest idea whether applying a security mechanism/control/measure will make us more secure in the end or not. Add password authentication to a service – congratulations, you just increased the risk of your users losing their “web password” in a breach.

I’d love to see more risk modeling, but I firmly believe that we are incapable of doing it with a rather small number of exceptions.

To me threat modelling fills a valid purpose if used correctly, namely to deal with known and established threats. There are a plethora of possible threats depending on what type of system, or process you are analyzing, implementing or developing.

Assuming you have a pre-established database of threats it can be a most excellent way of ensuring that you’ve appropriately dealt with these potential issues when developing a new system, or implementing a new process.

The use of a threat database can “force” developers, and management alike, to address problems that occur in real life and that really should be avoided. It’s a way of ensuring that you’ve covered common pitfalls for your particular type of system, or process.

The threat modelling does not, and should not, deal with probabilities, those are dealt with in the risk analysis when you attempt to factor in things such as vulnerabilities, threat-agents (motivation, resources etc). The threat model’s purpose is to ensure you’ve erected a solid foundation.

That’s part of the reason of why I don’t agree with the article. I also think the author is careless with the usage of the various words involved giving rise to even more confusion as to what we are actually talking about.

If the author had spent a few sentences on defining the terminology it would have helped; I still think his basic argument is incorrect.

If we actually modeled the threats, their motivations, and their current techniques; what is likely, rather than playing the “what if” guessing game, threat modeling might be useful. Although such a change would make threat modeling reactive, the evidence we have suggests that’s the best we can do.

The best collection may be about data that are not themselves released, but are instead rolled up into aggregated or summarized data which are then most cogently analyzed.

I can see many of the “security reports” from WhiteHat, MSFT, Veracode and so on having precisely this characteristic.

Meanwhile, there are some collections of data that are released with comparatively little analysis, but are quite fine-grained. An example here would be DatalossDB (and perhaps OSVDB as well – I am not as familiar with it).

Maybe we need two award – best data source (which would include collection and disbursement) and most cogent analysis of data collected by the analyst.