But what if it doesn’t work?
April 26, 2006 by PingGiving security talks can be tough.
At a typical gathering of security folks, just about any proposal for a new design that intends to improve security will be met with lots of questions of the form “But what about [some attack]? Or [some other attack]? Or what if [something] goes wrong?” And i’m discovering that the same thing happens at other venues too — it happened at a talk i watched at CHI, which i’m attending this week.
There’s nothing wrong with checking to make sure all the bases are covered. But sometimes there’s the implication behind such questions that, if there’s any kind of attack that still remains feasible, the proposal as a whole has failed.
The standard way to protect yourself against the endless stream of “what if” questions is to be clear about exactly which attacks you’re preventing and not preventing. In security terminology, you’ve got to show your threat model.
A surprisingly common type of question is “But what if part of what you’re actually proposing doesn’t work properly?” The assumption is that all we care about, for each software component, is whether we have to trust it or not. If we still have to trust it — if a bug in it can still break our system — it doesn’t matter what we’ve done to change it.
I argue that it does matter. Every system has got to have some trusted parts. Changing what those parts do, even it doesn’t directly eliminate an attack, makes a difference by affecting our ability to prevent attacks. Simplifying software components is valuable for security — it reduces the amount of trust we have to place in each component, and reduces the amount of work we have to do to verify that the component is correct.
The answer to “But what if it doesn’t work?” is “Maybe it won’t — but now we have a much better chance of being sure that it does work.”
David Hopwood wrote:
May 3rd, 2006 at 10:07
From a purely research point of view I probably agree, because we should remain open to new ideas and approaches.
From a practical point of view, especially if we are including the prospect of public or industry adoption, I am more leary. It is difficult to convince people of the need for change, to introduce new paradigms, to implement and distribute systems, and especially to get companies to buy in to new developments and deploy them along with supporting policies and staff. Given the overhead costs, it is only worth pushing out ideas that make a substantial step in eliminating risks…just making it incrementally easier to do things right might not be enough. One issue is the direct costs involved in all of the above, but the greater concern is that having adopted a particular technology the players involved will likely be less enthuistic to adopt the next one…which may be MUCH better.
It is probably also that it is a knee-jerk reaction to what appears much too common in the security literature - people proposing new systems that address current problems without much analysis of the new avenues of attack that the system opens up. Often the newly proposed system is just as attackable…it just blocked a particular current attack.
May 3rd, 2006 at 11:40
I agree that change always leads to costs that have to be considered (including the reluctance to change again that you mentioned — good point). So there is a threshold of improvement that has to be exceeded for the change to be worth it.
Preventing a specific attack is only one kind of improvement, though. Simplifying a system’s trust assumptions can also be a significant improvement, even though such a move seems less often seriously considered.