3 ms·

It's simply difficult to secure devices. It's hard the same way engineering is hard. I know it's fashionable to blame the MBAs instead of blame ourselves, but

It's simply difficult to secure devices. It's hard the same way engineering is hard. I know it's fashionable to blame the MBAs instead of blame ourselves, but at the end of it, we're the ones who write insecure code. And I don't think that if you give an engineer an extra week or two to focus on security that you'd end up with a measurably more secure device. Securing something is a different skillset from building it. Pentests are probably the answer.

blacksmith_tb 10y ago
Secure against a dedicated attacker, yes. But telnet listening on port 23 and a conistent default admin password on all your devices is really not that hard to improve on (and that's the sort of device that BrickerBot is killing).
- sillysaurus3 10y ago
  Perhaps. But someone thought it was a good idea to put up a telnet port 23 default-admin-password interface. The point is, if you give that person two weeks to focus on securing the product, I'm not sure they would realize it's a bad idea to do that. People who are bad at security don't realize they're bad at security. Which is why it's probably important to bring in an outside team to break the product. Or to put it another way, if we're not proposing to bring in an outside team to conduct a pentest, what's the alternative?
  - eropple 10y ago
    I've done intentionally insecure things because I simply straight-up did not have time to do them correctly. Shared keys, shared password across an entire infra--lots of stupid things because my deadline wasn't moving and hours counted. The difference, of course, is that I retain control of my stuff and I'm not pushing things out to other people. Pentests are, to be clear, great, and there are plenty of people who Dunning-Kruger their way through security decisions. But time is definitely a factor in this stuff.
    - sillysaurus3 10y ago
      I agree, but think of it this way: imagine a doctor arguing against washing their hands. The analogy is pretty apt. Washing your hands is as effective in reducing disease as pentests are at improving security. So why are we still seeking ways to justify to ourselves that we can do without pentests? It just seems like pentests need to move from "nice" to "necessary." (Part of that is reducing their cost from $60k to $6k.)
      - eropple 10y ago
        The bigger problem with pentests is not the current cost but, as I see it, is that security is inherently and inescapably expensive somewhere in the chain, and that vendors have been getting a free lunch for too long. The viability of security analyses/pentests will go down if your goal is to reduce the cost by an order of magnitude because the people who are any good will find something better to do--and the consumer will still pay through all the bullshit externalities. Security needs to cost to demand talent. The real solution to this problem, I think is that failure to secure needs to cost (whether in monetary or criminal terms) or it isn't relevant to business concerns.
        derefr 10y ago
        I think the parent was arguing that this: > security is inherently and inescapably expensive somewhere in the chain ...is the thing that needs to change. Presumably using more automation (e.g. employing more software like http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/), such that "pen-testing" shifts from being a labor cost to a capital cost.
        eropple 10y ago
        Open telnet servers are a solved problem (taking the solution off the rack is a question of time and, effectively, the willingness to be negligent). The automation exists. It's the hard stuff that is context- and environment-dependent to a degree that it resists automation.
      - 10y ago
  - jxramos 10y ago
    Sounds like a good opportunity for something analogous to UL certification, albeit for security.
nickpsecurity 10y ago
"It's simply difficult to secure devices. It's hard the same way engineering is hard." Put OpenBSD and OpenSSH on them with configuration explained in a good book on the subject. Write your apps in memory-safe language that validates external input. The End [for vast majority of attacks in IoT space]. It's not as hard as you detractors claim. They just don't care.
- pferde 10y ago
  Indeed. It's not hard, it's just more expensive than not doing it at all. And since there is usually no incentive doing it, it is not being done, because not doing it saves money.
  - nickpsecurity 10y ago
    Exactly!

blacksmith_tb 10y ago

Secure against a dedicated attacker, yes. But telnet listening on port 23 and a conistent default admin password on all your devices is really not that hard to improve on (and that's the sort of device that BrickerBot is killing).

sillysaurus3 10y ago
Perhaps. But someone thought it was a good idea to put up a telnet port 23 default-admin-password interface. The point is, if you give that person two weeks to focus on securing the product, I'm not sure they would realize it's a bad idea to do that. People who are bad at security don't realize they're bad at security. Which is why it's probably important to bring in an outside team to break the product. Or to put it another way, if we're not proposing to bring in an outside team to conduct a pentest, what's the alternative?
- eropple 10y ago
  I've done intentionally insecure things because I simply straight-up did not have time to do them correctly. Shared keys, shared password across an entire infra--lots of stupid things because my deadline wasn't moving and hours counted. The difference, of course, is that I retain control of my stuff and I'm not pushing things out to other people. Pentests are, to be clear, great, and there are plenty of people who Dunning-Kruger their way through security decisions. But time is definitely a factor in this stuff.
  - sillysaurus3 10y ago
    I agree, but think of it this way: imagine a doctor arguing against washing their hands. The analogy is pretty apt. Washing your hands is as effective in reducing disease as pentests are at improving security. So why are we still seeking ways to justify to ourselves that we can do without pentests? It just seems like pentests need to move from "nice" to "necessary." (Part of that is reducing their cost from $60k to $6k.)
    - eropple 10y ago
      The bigger problem with pentests is not the current cost but, as I see it, is that security is inherently and inescapably expensive somewhere in the chain, and that vendors have been getting a free lunch for too long. The viability of security analyses/pentests will go down if your goal is to reduce the cost by an order of magnitude because the people who are any good will find something better to do--and the consumer will still pay through all the bullshit externalities. Security needs to cost to demand talent. The real solution to this problem, I think is that failure to secure needs to cost (whether in monetary or criminal terms) or it isn't relevant to business concerns.
      - derefr 10y ago
        I think the parent was arguing that this: > security is inherently and inescapably expensive somewhere in the chain ...is the thing that needs to change. Presumably using more automation (e.g. employing more software like http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/), such that "pen-testing" shifts from being a labor cost to a capital cost.
        eropple 10y ago
        Open telnet servers are a solved problem (taking the solution off the rack is a question of time and, effectively, the willingness to be negligent). The automation exists. It's the hard stuff that is context- and environment-dependent to a degree that it resists automation.
    - 10y ago
- jxramos 10y ago
  Sounds like a good opportunity for something analogous to UL certification, albeit for security.

nickpsecurity 10y ago

"It's simply difficult to secure devices. It's hard the same way engineering is hard." Put OpenBSD and OpenSSH on them with configuration explained in a good book on the subject. Write your apps in memory-safe language that validates external input. The End [for vast majority of attacks in IoT space]. It's not as hard as you detractors claim. They just don't care.

pferde 10y ago
Indeed. It's not hard, it's just more expensive than not doing it at all. And since there is usually no incentive doing it, it is not being done, because not doing it saves money.
- nickpsecurity 10y ago
  Exactly!