I really enjoyed being part of this panel. I felt we had a good mix of experience and some really interesting conversations.
There’s a long and important blog post from Matt Miller, “Mitigating speculative execution side channel hardware vulnerabilities.”
What makes it important is that it’s a model of these flaws, and helps us understand their context and how else they might appear. It’s also nicely organized along threat modeling lines.
What can go wrong? There’s a set of primitives (conditional branch misprediction, indirect branch misprediction, and exception delivery or deferral). These are built into gadgets for windowing and disclosure gadgets.
There’s also models for mitigations including classes of ways to prevent speculative execution, removing sensitive content from memory and removing observation channels.
Last week, in “Threat Modeling: Citizens Versus Systems,” I wrote:
I think that was a right call for the first project, because the secondary data flows are a can of worms, and drawing them would, frankly, look like a can of worms.
Many organizations don’t disclose them beyond saying “we share your data to deliver and improve the service,” those that do go farther disclose little about the specifics of what data is transferred to who.
Today, via Bruce Schneier, we see that Paypal has disclosed the list of over 600 companies they might share your data with. He rightly asks if that’s unusual. We don’t know. My instinct is that it’s not unusual for a financial multi-national.
I’m standing by the questions I asked; the first level of categories in the Paypal list may act as a good third level for our analysis. It will be interesting to see if others use the same categories. If they don’t, the analysis process is magnified.
Their categories are:
- Payment Processors
- Customer Service outsourcing
- Credit reference and fraud agencies
- Financial products
- Commercial partnerships
- Marketing and public relations
- Operational services
- Group companies
- Commercial partners
It’s unclear to me how 6 (“Commercial partnerships”) differs from 10 (“Commercial partners”). I say this because I’m curious, not to point and laugh. We should cut Paypal some slack and appreciate that this is a new process to handle a new legal requirement. I’m also curious if 12 (“agencies”) means “law enforcement agencies” or something else.
Visualization from How PayPal Shares Your Data.
Recently, we shared a privacy threat model which was centered on the people of Seattle, rather than on the technologies they use.
Because of that, we had different scoping decisions than I’ve made previously. I’m working through what those scoping decisions mean.
First, we cataloged how data is being gathered. We didn’t get to “what can go wrong?” We didn’t ask about secondary uses or transfers — yet. I think that was a right call for the first project, because the secondary data flows are a can of worms, and drawing them would, frankly, look like a can of worms. We know that most of the data gathered by most of these systems is weakly protected from government agencies. Understanding what secondary data flows can happen will be quite challenging. Many organizations don’t disclose them beyond saying “we share your data to deliver and improve the service,” those that do go farther disclose little about the specifics of what data is transferred to who. So I’d like advice: how would you tackle secondary data flows?
Second, we didn’t systematically look at the question of what could go wrong. Each of those examinations could be roughly the size and effort of a product threat model. Each requires an understanding of a person’s risk profile: victims of intimate partner violence are at risk differently than immigrants. We suspect there’s models there, and working on them is a collaborative task. I’d like advice here. Are there good models of different groups and their concerns on which we could draw?
I have a new Perspectives article at ISACA, Reasonable Software Security Engineering. It talks about the how, why and where you need to ground a software security engineering program.