Tuesday, April 15, 2008

Engineering

In a Wired column last month, Bruce Schneier nicely describes the security mindset and completely misrepresents engineering. The heart of his column:

Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.
The description of engineering is catchy, but false. Good engineering involves thinking about how things can fail, designing to prevent failures, planning on how to mitigate the damage caused by failures, building in warnings of impending failures, and calculating usage limits to avoid failures. Engineers have to figure out how to make sure the bridge won’t fall down when trucks drive across it, or when the wind blows, or when a support fails. Engineers also have to figure out how to make sure that structures and systems will withstand the threats that security consultants warn them about. Security consultants, on the other hand, tend to worry only about problems that are deliberately caused by people, rather than the full range of problems. Thinking about security certainly contributes to good engineering, but too much of a focus on security leaves us vulnerable to nature (Katrina), entropy (crumbling infrastructure), and accidents (40,000 highway deaths a year). The cult of security says that if people didn’t cause the problem, then people don’t have to solve the problem. Engineers know better.

1 comment:

irilyth said...

Seems to me like the right way to say what Schneier is trying to say is that engineering is about making things work, but engineers in fact do a lot of security (by his definition) as well as a lot of engineering. When the engineers realize that the bridge will fall down if trucks drive across it, that's security, but then making the bridge stronger is engineering.

By those definitions, it seems entirely fair to say that security consultants entirely do security, and not engineering at all, and that this is why they're so useless. It's much easier to point out problems than to solve them, especially if your sole goal is to find problems (and not ultimately to find problems in service of accomplishing some other goal).