Why "Designed For Security" Is a Dubious Designation

itwbennett writes The list of products designed to be security enhanced that turned out to be anything but seems to get longer by the day. In just the latest instance, reported by Wired last week, the crowd-funded privacy-enhancing home router Anonabox had to be recalled after an independent researcher discovered serious security flaws in the product. But security experts caution that the real problem may be bigger than vulnerabilities hidden in application code: "Designed for security products don't just have to be good. They have to be beyond reproach," explains John Dickson, a Principal at the Denim Group. "All it takes is one guy with a grudge to undo you."

Comments

OpenBSD proves the claim to be wrong.

[Anonymous Coward]

OpenBSD proves the claim to be wrong.

Re:OpenBSD proves the claim to be wrong.

[Anonymous Coward]

Probably because OpenBSD isn't designed for security. They have their priorities straight: portability, standardization, correctness, proactive security and integrated cryptography.

Most "designed for security" products reverse the order of things. Start with a set of cryptographic solutions, sprinkle on some magic security dust, hack on it until it appears to work (i.e. "correctness"), and toss standards and portability concerns out the window. Even though those latter two things give you a fixed point of reference to shoot for when it comes to correctness (whether or not the reference itself is flawed).

Security is a process, not a product. I would note that "proactive security" is another way of saying bug mitigation--sandboxing, address randomization, stack smashing detection, etc.

Rule #1, don't taunt happy fun hackers

[GoodNewsJimDotCom]

I've found that the more you tout that you have good security, the more recreational hackers come out of the wood work who would otherwise have no interest in your product other than you make it sound like a challenge. If you want good security, do your encryption, do your trip wires, keep important stuff server side, etc etc, but don't brag about it. Bragging about security on the Internet is like putting on a white karate outfit with a black belt and strutting all around the low income parts of town. Maybe you are secure in your components or your not, but don't go looking for people to try and break you.

So how do you develop relatively secure software?

[hlee]

Here's what works in most practical systems with a little effort:
- Threat model. Sequence diagram of all external communication between all servers and clients. Apply STRIDE analysis. May be take a step back to see if you can simplify the workflow.
- Assurance model. State diagram of system. Capture success and error states. Unit tests for each case.

Add to that third party oversight:
- Static analysis tools.
- Third party verification.

I assume you're not developing mission critical systems that control functions in a nuclear power station, or even a car breaking system. Rather you're looking at consumer or enterprise level systems that involve some confidential, and possibly credit card information. Short deadlines and budget constraints mean you can't spend forever coming up with a solid specification or even do extensive analysis.

Re:"Designed For"

[rtb61]

Designed for security needs to follow the KISS principle, keep it simple stupid. Only allow it to do what you need it to do, zero flexibility. Keep the device as simple as possible, not one feature beyond what is absolutely necessary to it's designed function. This is the most important rule in designing for security. Your lock should only open able one way, the way you choose. The whole idea of bios/os/application is the first thing that has to go, great for general computing but for secure computing to many ways of doing things you didn't intend for it to do.

Break down the overall function into their broad elements and separate and secure each element and provide fixed encrypted communications pathways between each element. At least with completely separate hardware and operating applications between each element, parallel processing will be far more efficient and far less processing capability will be required.

The more complex, the harder to secure, the simpler the easy it is to secure.