Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Technology

Why "Designed For Security" Is a Dubious Designation 58

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."
This discussion has been archived. No new comments can be posted.

Why "Designed For Security" Is a Dubious Designation

Comments Filter:
  • by Anonymous Coward on Wednesday April 15, 2015 @05:33PM (#49481497)

    OpenBSD proves the claim to be wrong.

    • Re: (Score:3, Insightful)

      by 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 r

  • by Anonymous Coward

    Despite a few discovered problems over the years, for the most part, OpenBSD's security reputation holds up quite well, especially in comparison with other projects and products, open and proprietary.

  • The phrase "designed for" is irrelevant. It does not matter what something is "designed for". The important part is the implementation. "Designed for security" is not the same as "secure".

    • Moreover, "designed for security" is just a meaningless marketing term. It's a catch phrase, but it doesn't actually mean much, apparently.

      You can't just say "I'm making the most secure thing evar" and have that mean anything unless you've spent a LOT of time and effort making it so. You can't just throw something together and think you've made something secure.

      And if you make this big bold claim, and then trip on your own dicks, you look like idiots.

      My general rule would be to treat a claim like "designe

    • by rtb61 ( 674572 )

      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 m

      • That is your definition of what "designed for security" means. There is no authority to confirm or deny the correctness. There could be other "definitions". See how useless the phrase is? It is just market speak.

        • by rtb61 ( 674572 )

          What definition? I was just formulating an element of designed for security and not the totality of it, just one rule. Design is not a definition, design is a continual process (now that is a definition, well, only in part ;) ).

          • Designed for security needs to follow the KISS principle, keep it simple stupid.

            In your opinion. Other people may have other opinions. Since there is no authority different people may use the same phrase and have different opinions about it.

  • Systems submitted for evaluation under TCSEC B2 and better had to be designed for security - layering, TCB minimization, ... were all mandated in addition to support for trusted MAC functionality. When I am designing for "SECURITY" I want to simplify the critical protocols so that they can be described by a state machine and then implement them in silicon.

    • by Anonymous Coward

      This!

      I'm not an electrical engineer and wouldn't know the first thing about moving an algorithm to silicon. But I always code things like parsers and protocol stacks using explicit state machines. It's the only way you'll have a chance at being able to proof the correctness of each step. Of course, explicit state machines can be buggy too, and it takes practice to write them in a manner that makes them easily reviewable. But you really have no chance in hell of shaking out complex bugs from a mess of functi

    • by Burz ( 138833 )

      When I am designing for "SECURITY" I want to simplify the critical protocols so that they can be described by a state machine and then implement them in silicon.

      It would be interesting to see a Xen hypervisor implemented in silicon, as that is what Amazon EC2 and Qubes OS base their security on. Qubes doesn't even use kernel-based permissions for its single-user desktop model; It gives you the means to control dom0 and everything else resides in VMs.

  • by GoodNewsJimDotCom ( 2244874 ) on Wednesday April 15, 2015 @06:40PM (#49481845)
    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.
    • by Anonymous Coward

      If you're afraid of peer review, you have no goddamn business desigining secure devices or software.

      It's better to be hacked to pieces by someone who will tell you how you've been hacked than to be hacked by someone who will keep everything a secret, to be sold to the highest bidder.

    • by Kardos ( 1348077 )

      It sounds like your approach to security is to risk manage it, like the car companies in Fight Club. Doing "some security stuff" and then keeping quiet and crossing your fingers hoping that nobody takes an interest does not inspire confidence. If a recreational hacker can defeat your security on a whim just to show off, you don't stand a chance against actual criminals who will quietly break your security and then proceed to exploit you for everything they can and for as long as they can.

      > Maybe you are

  • SRW Iron https://www.srware.net/en/soft... [srware.net] is touted to be a secure browser [Warning: Demands Java after install]. I don't think it is.
    In fact, playing around with FF shows that the problem isn't the browser, but the reliance on 3rd party cookies as 1 example of the way websites are constructed.
    If you load FF's Lightbeam and check all the 3rd party sites, block access to them, they often stop the parent website from operating properly or at all. Typically, Google and most banking sites won't work without 3r

  • is how I assume all hackers (regardless of hat color) would read "Designed for Security."

  • by hlee ( 518174 ) on Wednesday April 15, 2015 @07:57PM (#49482221)

    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.

  • All it takes is one guy with a grudge to undo you.

    Exactly. Just like when Larry Ellison said that there weren't any holes in Oracle....

  • "Designed for security products don't just have to be good. They have to be beyond reproach" Bullshit. The term is used to designate that at least some minimal amount of effort was used to make the program secure, but not only is a perfect unhackable program impossible but you also get what you pay for. No one expects the $29.99 piece of software with that label to magically have better security than the DoD.
  • I was just embroiled in a dispute with someone who is selling security related software that refuses to address key issues with their security model. I think the situation is probably similar here, software engineers that have the best of intentions but simply lack the expertise to properly execute. Most programmers are engineers who are perfectly capable of building out a working system. However, when it comes to security related software, it's not good enough for something to just work, you have to be

  • The list of products designed to be security enhanced that turned out to be anything but seems to get longer by the day.

    It took me about four tries to parse that one properly.

    Designed for security products don't just have to be good

    That one could've used some quote marks too.

    Captain Pedantic, away!

    That is to say: I am Captain Pedantic (metaphorically speaking) and I will now go away.

  • The default login for Windows 8.1 is your Microsoft email / cloud account and password. So anyone watching you type in your password has access to your cloud account.

    I don't understand why Microsoft is not given more flack for this decision.

    Your alternatives is to not use their cloud, or use 4 digit PIN or a series of screen swipes, but they don't support a local password. If you understand how to set it up, you can supplement the PIN/swipe with a USB key, but it is not a visable user option and you ha
  • Expecting any software to be "beyond reproach" is completely unrealistic. All software has bugs; some of them will be exploitable.

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...