5 ms·

> the most egregious offenders are software developers Blame always rises. Management knows that any product without extensive review is going to be bad. They

> the most egregious offenders are software developers Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it.

nobody9999 6y ago
>Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it. I get that a variety of pressures are put on developers to add features and ship quickly. But whether it's corporate development done internally (e.g., LOB applications), a web app or a SaaS offering, not designing security into the software is a disaster waiting to happen. So many times I've seen businesses have their crown jewels ripped off due to poorly implemented/weak or non-existent security practices in application design/development. Even when the infrastructure is reasonably well secured, with defense-in-depth, including strong authn/authz, separation of duties, as well as strong security processes and policies in place, software that lacks designed-in security can render all of it useless. Whether that's because the software doesn't/can't integrate with the security tools in use (often requiring applications to run with much higher privilege than they should) or because little or no thought was given to secure coding mechanisms or access controls. I absolutely understand that there are always security trade-offs, regardless of where in a multi-layered infrastructure/management/application environment. And it's always important not to expend resources beyond what's appropriate for the assets being secured. That said, application software is the most frequent culprit in enabling compromises (followed closely by poor security implementation in the infrastructure and a lack of policy/process in securing it -- usually through ignorance/incompetence). My argument is not that developers are stupid or ignorant, but that security isn't baked-in to their design decisions as a guiding principle. And that often leads to insecure software and/or sloppy/insecure integration of security after the fact. If more developers thought about security as a feature rather than an inconvenience to be given little thought or just lip service, that would make a big difference. Edit: Clarified verbiage and fixed typos.
- HexagonalKitten 6y ago
  Show me a single project where the functional specs were complete when given to the developers and external concerns didn't dictate any implementation details. All of the projects I've been on have had changing specs, right up to and through release. I love the architecture weenie role. It's tons of fun. But eventually you need to build something and only with experience do you discover the first set of complications, then marketing starts promising features and you've got the next, and management refuses to allocate more time. Did you do something wrong at step 1 by building a prototype before knowing it would be perfect? And if so, how could you know that and what would you do to get there? I write the code, and tag releases, but I don't determine what ships. I, and 95% of us, are not engineers and even those who are have abrogated their responsibility to make the bridge stand - we're all just building individual struts because someone told management that things done in a vacuum will all fit together properly in the end. So I agree I guess, but don't at the same time.
  - nobody9999 6y ago
    >So I agree I guess, but don't at the same time. I suppose I do too. While a lack of designed-in security is often the (sometimes disastrous) result, I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep. If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) and given the same value as other development concepts, developers would incorporate those concepts from the start, rather than having to bolt them on (or not) later on. As such, it's more about lack of knowledge/focus/value placed on security in software design/development. Given the value of data that being secured with software, good security practices should be, if not just as integral, to software development as performance or UX design, it should at least be a consideration before prototyping.
    - HexagonalKitten 6y ago
      > I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep. It probably depends on what your team is good at. I tend to work in fairly security conscious teams. They check the length of buffers, don't rely on anything from the user, etc. So most of our issues tend to be from our architecture being drastically changed to integrate our solution into something else, or vice versa. Stuff is dropped on us, opaque libraries and internal code, and entirely new goals created around the big stuff, data persistence, key management, and so on. But when I had an actual stable product that could not get spec changes (it was custom hardware) we knew from the beginning how the project would go and how all of the pieces would fit and it went together cleanly. But, it turns out many embedded engineers don't (didn't maybe, it was a while ago) program as defensively because they're used to owning the entire scope. If they put a value somewhere they expect it to be there, unmolested, when they want it. That project was full of buffer overflows and bad crypto. > If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) Yeah. I'm not sure how but it does tend to be lacking. Everyone probably needs a different hook. For me it was quality. How could I say my software does X if you have a way to break it?

nobody9999 6y ago

>Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it. I get that a variety of pressures are put on developers to add features and ship quickly. But whether it's corporate development done internally (e.g., LOB applications), a web app or a SaaS offering, not designing security into the software is a disaster waiting to happen. So many times I've seen businesses have their crown jewels ripped off due to poorly implemented/weak or non-existent security practices in application design/development. Even when the infrastructure is reasonably well secured, with defense-in-depth, including strong authn/authz, separation of duties, as well as strong security processes and policies in place, software that lacks designed-in security can render all of it useless. Whether that's because the software doesn't/can't integrate with the security tools in use (often requiring applications to run with much higher privilege than they should) or because little or no thought was given to secure coding mechanisms or access controls. I absolutely understand that there are always security trade-offs, regardless of where in a multi-layered infrastructure/management/application environment. And it's always important not to expend resources beyond what's appropriate for the assets being secured. That said, application software is the most frequent culprit in enabling compromises (followed closely by poor security implementation in the infrastructure and a lack of policy/process in securing it -- usually through ignorance/incompetence). My argument is not that developers are stupid or ignorant, but that security isn't baked-in to their design decisions as a guiding principle. And that often leads to insecure software and/or sloppy/insecure integration of security after the fact. If more developers thought about security as a feature rather than an inconvenience to be given little thought or just lip service, that would make a big difference. Edit: Clarified verbiage and fixed typos.

HexagonalKitten 6y ago
Show me a single project where the functional specs were complete when given to the developers and external concerns didn't dictate any implementation details. All of the projects I've been on have had changing specs, right up to and through release. I love the architecture weenie role. It's tons of fun. But eventually you need to build something and only with experience do you discover the first set of complications, then marketing starts promising features and you've got the next, and management refuses to allocate more time. Did you do something wrong at step 1 by building a prototype before knowing it would be perfect? And if so, how could you know that and what would you do to get there? I write the code, and tag releases, but I don't determine what ships. I, and 95% of us, are not engineers and even those who are have abrogated their responsibility to make the bridge stand - we're all just building individual struts because someone told management that things done in a vacuum will all fit together properly in the end. So I agree I guess, but don't at the same time.
- nobody9999 6y ago
  >So I agree I guess, but don't at the same time. I suppose I do too. While a lack of designed-in security is often the (sometimes disastrous) result, I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep. If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) and given the same value as other development concepts, developers would incorporate those concepts from the start, rather than having to bolt them on (or not) later on. As such, it's more about lack of knowledge/focus/value placed on security in software design/development. Given the value of data that being secured with software, good security practices should be, if not just as integral, to software development as performance or UX design, it should at least be a consideration before prototyping.
  - HexagonalKitten 6y ago
    > I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep. It probably depends on what your team is good at. I tend to work in fairly security conscious teams. They check the length of buffers, don't rely on anything from the user, etc. So most of our issues tend to be from our architecture being drastically changed to integrate our solution into something else, or vice versa. Stuff is dropped on us, opaque libraries and internal code, and entirely new goals created around the big stuff, data persistence, key management, and so on. But when I had an actual stable product that could not get spec changes (it was custom hardware) we knew from the beginning how the project would go and how all of the pieces would fit and it went together cleanly. But, it turns out many embedded engineers don't (didn't maybe, it was a while ago) program as defensively because they're used to owning the entire scope. If they put a value somewhere they expect it to be there, unmolested, when they want it. That project was full of buffer overflows and bad crypto. > If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) Yeah. I'm not sure how but it does tend to be lacking. Everyone probably needs a different hook. For me it was quality. How could I say my software does X if you have a way to break it?