4 ms·

Surely not! I'm just saying I'm not surprised too much.

by janci 5y ago

jrockway 5y ago
I think there's a mismatch between security and software engineering. Software engineers are paid to make things work, but the point of security is to make things not work (for attackers). So there is that fundamental mismatch which leads to a lot of strife, I think. (The real answer, of course, is that the software needs to do two things instead of just one. It needs to permit authorized users AND deny unauthorized users. One is not more important than the other, both must work perfectly. But when testing it, you're mostly happy when you, the authorized user, are allowed to log in, and so tend to forget about the "what if the assertion is malformed" case.) I think it's funny because engineers are always portrayed as being grumpy and that they hate everything, but if you look at how they handle errors or security, they seem like the type of people that like everything and always imagine the happy path ;)
- 1cvmask 5y ago
  You framed the issue perfectly. A mismatch of competing incentives. That seems to be a problem everywhere beyond just security. it seems that bonuses should be tied to security as well. Then maybe software engineers would be incentivized to build things securely. A clawback of bonuses for security vulnerabilities might be an interesting idea? Or better yet bigger bonuses if there are no breaches.
  - yourapostasy 5y ago
    > A clawback of bonuses for security vulnerabilities might be an interesting idea? Or better yet bigger bonuses if there are no breaches. Agency problem. Those who decide budgets and project timelines get the upside in such a bonus scheme, while whose who implement get the downside. Clawback bonuses, and the engineers not only get blamed, they get laid off to make the quarterly numbers for the management who want to make up for lost bonuses. I suspect the solution lays in the spec complexity. Haven’t thought of this much, so my wrongthink knee jerk reaction is make a set of reference test harnesses part of the SOT of the spec, and that is the first step towards more robust implementations. Would like to hear how others have approached this problem space.
  - scrose 5y ago
    All this would accomplish is engineers feeling less like they should report issues with systems.
- stouset 5y ago
  I've often made this comparison. Software engineering seems primarily focused on making it work correctly, security engineering is about making it fail correctly. But I also think that latter part should be just given more weight in software engineering in general. A simple example is regex: most people tend to think about writing regexes that positively match expected input, but this generally results in expressions that match things it shouldn't. Writing them is generally easier and more straightforward when you think about not matching what they shouldn't!
  - jcranmer 5y ago
    That's a good point, but I'd actually go a step further and argue that we need to think more generally about actually defining when things should fail. This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. See, for example, the tag soup parsing of HTML (which was eventually standardized in HTML5), or the insanity that is trying to parse email messages.
    - mooreds 5y ago
      > This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. Isn't this Postel's law in practice? https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle There's a competitive advantage in handling bad input, right? I'm not saying it should always be the primary consideration and certainly not in security situations, but I think that competitive pressures are how we arrived at this situation.

Surely not! I'm just saying I'm not surprised too much.

by janci 5y ago

Surely not! I'm just saying I'm not surprised too much.

I think there's a mismatch between security and software engineering. Software engineers are paid to make things work, but the point of security is to make things not work (for attackers). So there is that fundamental mismatch which leads to a lot of strife, I think. (The real answer, of course, is that the software needs to do two things instead of just one. It needs to permit authorized users AND deny unauthorized users. One is not more important than the other, both must work perfectly. But when testing it, you're mostly happy when you, the authorized user, are allowed to log in, and so tend to forget about the "what if the assertion is malformed" case.) I think it's funny because engineers are always portrayed as being grumpy and that they hate everything, but if you look at how they handle errors or security, they seem like the type of people that like everything and always imagine the happy path ;)

1cvmask 5y ago
You framed the issue perfectly. A mismatch of competing incentives. That seems to be a problem everywhere beyond just security. it seems that bonuses should be tied to security as well. Then maybe software engineers would be incentivized to build things securely. A clawback of bonuses for security vulnerabilities might be an interesting idea? Or better yet bigger bonuses if there are no breaches.
- yourapostasy 5y ago
  > A clawback of bonuses for security vulnerabilities might be an interesting idea? Or better yet bigger bonuses if there are no breaches. Agency problem. Those who decide budgets and project timelines get the upside in such a bonus scheme, while whose who implement get the downside. Clawback bonuses, and the engineers not only get blamed, they get laid off to make the quarterly numbers for the management who want to make up for lost bonuses. I suspect the solution lays in the spec complexity. Haven’t thought of this much, so my wrongthink knee jerk reaction is make a set of reference test harnesses part of the SOT of the spec, and that is the first step towards more robust implementations. Would like to hear how others have approached this problem space.
- scrose 5y ago
  All this would accomplish is engineers feeling less like they should report issues with systems.
stouset 5y ago
I've often made this comparison. Software engineering seems primarily focused on making it work correctly, security engineering is about making it fail correctly. But I also think that latter part should be just given more weight in software engineering in general. A simple example is regex: most people tend to think about writing regexes that positively match expected input, but this generally results in expressions that match things it shouldn't. Writing them is generally easier and more straightforward when you think about not matching what they shouldn't!
- jcranmer 5y ago
  That's a good point, but I'd actually go a step further and argue that we need to think more generally about actually defining when things should fail. This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. See, for example, the tag soup parsing of HTML (which was eventually standardized in HTML5), or the insanity that is trying to parse email messages.
  - mooreds 5y ago
    > This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. Isn't this Postel's law in practice? https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle There's a competitive advantage in handling bad input, right? I'm not saying it should always be the primary consideration and certainly not in security situations, but I think that competitive pressures are how we arrived at this situation.