As promised, we recorded all of the day’s presentations and we’ve published them on TechNet:

Keynote Address by Scott Charney, Corporate VP, Microsoft Trustworthy Computing

Threat Modeling at EMC and Microsoft by Danny Dhillon of EMC and Adam Shostack of the Microsoft SDL team (of course)

Mitigations Unplugged by Matt Miller, Microsoft Security Science team

Concurrency Attacks on Web Applications by Scott Stender and Alex Vidergar of iSEC Partners

Fuzzed Enough? When it’s OK to Put the Shears Down by Jason Shirk, Dave Weinstein and Lars Opstad, Microsoft Security Science team

Real World Code Review – Using the Right Tools in the Right Place at the Right Time by Vinnie Liu of Stach & Liu

In addition to the presentations, we also recorded some short interviews (about 10 minutes long) with each of the speakers. If you’re just looking for a quick summary of a particular talk, these interviews are the place to start:

Threat Modeling at EMC, Danny Dhillon

Threat Modeling at Microsoft, Adam Shostack

Mitigations Unplugged, Matt Miller

Concurrency Attacks on Web Applications, Scott Stender and Alex Vidergar

Fuzzed Enough? Jason Shirk and Dave Weinstein

Real World Code Review, Vinnie Liu

I hope at least 96% of online readers will be able to directly apply this material to their products, just like the show attendees. Please post back and let us know, either way. And let us know what you’d like to see for next year. We have big plans to build on our success and make SDL Sessions 2.0 even bigger and better than the first.

While genetics is concerned with the observation of specific sections of DNA, genomics is about studying the entire genome of an organism, something that has only become practically possible in recent years. In forensic genetics, which is the technology behind the large national DNA databases being built in several countries including notably UK and USA (Wallace’s outstanding article lucidly exposes many significant issues), investigators compare scene-of-crime samples with database samples by checking if they match, but only on a very small number of specific locations in the genome (e.g. 13 locations according to the CODIS rules). In our paper we explore what might change when forensic analysis moves from genetics to genomics over the next few decades. This is a problem that can only be meaningfully approached from a multi-disciplinary viewpoint and indeed our combined backgrounds cover computer security, bioinformatics and law.

(Image from Wikimedia commons, in turn from NIST.)

Sequencing the first human genome (2003) cost 2.7 billion dollars and took 13 years. The US’s National Human Genome Research Institute has offered over 20 M$ worth of grants towards the goal of driving the cost of whole-genome sequencing down to a thousand dollars. This will enable personalized genomic medicine (e.g. predicting genetic risk of contracting specific diseases) but will also open up a number of ethical and privacy-related problems. Eugenetic abortions, genomic pre-screening as precondition for healthcare (or even just dating…), (mis)use of genomic data for purposes other than that for which it was collected and so forth. In various jurisdictions there exists legislation (such as the recent GINA in the US) that attempts to protect citizens from some of the possible abuses; but how strongly is it enforced? And is it enough? In the forensic context, is the DNA analysis procedure as infallible as we are led to believe? There are many subtleties associated with the interpretation of statistical results; when even professional statisticians disagree, how are the poor jurors expected to reach a fair verdict? Another subtle issue is kin privacy: if the scene-of-crime sample, compared with everyone in the database, partially matches Alice, this may be used as a hint to investigate all her relatives, who aren’t even in the database; indeed, some 1980s murders were recently solved in this way. “This raises compelling policy questions about the balance between collective security and individual privacy” [Bieber, Brenner, Lazer, 2006]. Should a democracy allow such a “driftnet” approach of suspecting and investigating all the innocents in order to catch the guilty?

This is a paper of questions rather than one of solutions. We believe an informed public debate is needed before the expected transition from genetics to genomics takes place. We want to stimulate discussion and therefore we invite you to read the paper, make up your mind and support what you believe are the right answers.

After Interop Las Vegas you may have seen our analysis of the data that we collected and delivered in our NOC view.  I thought I’d recreate the same data for NY and do a short comparison.

1) Like in Vegas, uptime for the network 100%.  This is no small feat considering that we introduced a new wrinkle in NY, taking down the primary NOC while the education portion of the show was still going on.  This was a forced failover to the backup systems, and it went flawlessly.  I’d like to give a little credit to EM7 on the 100% uptime as it caught a failover to battery power that allowed AC to be restored before a series of critical equipment would have gone down.

2) Again like Vegas, the average monitored device in the show network didn’t even hit 10% CPU utilization.  Still lots of computing overhead availabe in the show network.

3) The NY show network wasn’t nearly as busy as in Las Vegas, sustaining an average of only 27Mbps of usage (versus 56 Mbps) in Vegas.

4) Power consumption for the network and NOC in NY clocked in at 445kwh per day, about 25% less than the Las Vegas show.  This wasn’t because the equipment was any more power efficient, but instead because the show was smaller and therefore there was less network gear.

5) Finally, a stat we didn’t track too carefully in Las Vegas, but that I find interesting.  During show hours the wireless network average 1,100 users attached.  That’s a lot of people and a lot of wireless devices.

The good news is there was nothing too unexpected in the data, overall the smaller show led to a smaller number of tickets and smaller consumption of resources across the board.  We hope to have the opportunity to work with the InteropNet team again next year and take a look at this data year-over-year for each show.

The problem is that (Chris’ analysis is) completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning

As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart’s “impractical” comment to be, um, misinformed.

Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be “secure”, but to provide knowledge for decision making.  Using it as a “hammer” to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards “security” as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the data owners risk tolerance.  This risk tolerance changes sometimes, and that’s OK.

To that extent, I appreciate (and I’m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it’s worth noting (and Stuart’s example is indicative of this point) that risk analysis does not create rationality in the analyst, either.  If one is being so “security minded” as to ignore the risk tolerance of the business owner - we’re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn’t own the data, the agitated Italian does).

But let’s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

At first glance, I don’t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just ‘listing the threats’).  But what is key here is that Chris’ approach is consistent and defensible.  Less generous risk geeks and CSO’s I know would have no little difficulty with Stuart’s approach.  But to particularly answer Stuart’s main objection (impracticality) I would offer that with practice, Chris’ work is probably quicker and easier than Stuart’s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).

Finally the irony of Stuart’s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We’ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris’, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.

Experts say the precipitous drop-off in spam comes from Internet providers unplugging McColo Corp., a hosting provider in Northern California that was the home base for machines responsible for coordinating the sending of roughly 75 percent of all spam each day.

Certainly this won't last:

Bhandari said he expects the spam volume to recover to normal levels in about a week, as the spam operations that were previously hosted at McColo move to a new home.

"We're seeing a slow recovery," Bhandari. "We fully expect this to recover completely, and to go into the highest ever spam period during the upcoming holiday season."

But with all the talk of massive botnets sending spam, it's interesting that most of it still comes from hosting services. You'd think this would make the job of detecting spam a lot easier.