Worthy Security Goal

Some security risks cannot be mitigated with technical means only. Maybe a new approach is needed?

Product Liability, wow, what a difficult set of challenges to overcome!

As a security person, I'm being stretched to consider all kinds of topics these days. I'm good with that. Among my scattered chunks of background, I have several years as a Motorcycle Safety Instructor.

Incongruous you say? Safety and Security have a kinship. We bikers know that risk is something that can be mitigated, to a point. Risk remains, and it's our job as safety pro's to limit impact and help the organization, the rider, steer a reasonably secure, er, safe course.

Business is risk. No one goes into business who is truly risk-averse. Stick yer capital in a bond if you want to make money with little risk.

Which brings me back to product liability. Product designers have learned that there are safety issues, liability issues, with all designs. There are limits to the safety improvements you can make.

So how do you stop product tampering? Let's talk about a mobile phone design--how do you stop someone from rooting your embedded device design?

You can't. You don't. You shift gears from tamper resistance to tamper evidence. And that is the message.

You may not be able to prevent a hacker from munging your system. Can you make signs of tampering very evident? Would a tool like tripwire spot altered binaries? Do you include hashes with your software distributions?

No, nothing I can do can wash away all the security risks with all the IT systems we're paid to protect; in much the same way that no amount of training I might provide you will remove all risk from riding a motorcycle. Instead, let's focus on forcing a quick alert if, maybe WHEN the attack occurs?

It's my hope you'll consider the terms, 'tamper-proof' and 'tamper-evident' and respond with your thoughts below. How do you provide tamper-evident when tamper-proof becomes impossible?