5 ms·

> Create a culture of writing and deploying secure code. How? That may sound glib, but this is really just asking everyone to try, right? I would guess that t

> Create a culture of writing and deploying secure code. How? That may sound glib, but this is really just asking everyone to try, right? I would guess that the vast majority of security mistakes stem from ignorance not apathy, and that most coders are trying. Relying on people trying clearly isn't working because there's simply too much to know and it requires too constant of attention. I think we actually do need better tooling, in terms of things like using type systems to flag sensitive data and automatically suggesting a threat modeling report include that item. The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms?

alexnewman 9y ago
Every big bug I have seen has been known by a developer and not ticketed and triaged. Apathy, sometimes, ignorance more often, lack of organization, almost always
- SomeStupidPoint 9y ago
  Anecdata will vary, but my experience has been those bugs get filed, marked "not important", and PMs have no way to sift the security impactful dozen out of hundreds to thousands of small defects in a large product's backlog. (And sometimes that backlog gets deleted, disappearing knowledge of those bugs.) I'm hoping we'll eventually be able to flag bugs with the types involved, and let systems automatically look for combinations that have a set of types that could be dangerous. My point was that it's not enough to focus on good intentions -- or culture -- you have to talk about mechanisms and technologies if you want a reliable system. Because the parts, humans in this case, are highly unreliable in isolation.
module0000 9y ago
You can't control humans unfortunately. Humans write code, and some of them will care more about the quality of work than others do. These people will at some point work above/below/with you, and their mistakes will cause you some sort of inconvenience. My mother taught medical school, and she had a saying... "What do you call the least qualified idiot who passes my class?", the answer is "Doctor". There are good coders and bad coders, and unless we start somehow forbidding the bad(but still good enough to get hired) ones to work with/for us - this isn't going to change.
- diroussel 9y ago
  If one developer can introduce a bug, that is life. But if it can go undetected by the compiler, unit tests, code review, component tests, acceptance tests, mutation testing, static analysis, pen test, etc, then maybe the process can be improved. It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.
  - IncRnd 9y ago
    > It may not be cost effective, but then it's still not a lone developer problem. It's a management decision. That's one way of looking at the issue. Another way is that this is a way for an individual developer to stand out above his or her peers.
mtgx 9y ago
I think it's less about the culture and it's more about the big language developers making their languages safe by default for 90% of the developers using them. The "culture" aspect may come in when you're encouraging people to use languages such as Rust over C++, rather than something like "always follow this 50-point security checklist no matter what language you use".
- IncRnd 9y ago
  Product design, protocols, cryptography, regulatory restrictions, and so many other aspects have nothing to do with the language. Not every vulnerability stems from missing range or bounds checks. I mean this is the best way possible, but your answer shows that even people on HN don't understand what goes into securing a product.
IncRnd 9y ago
We've created the beginnings of this type of culture at my employer. More and more, developers reach out to the security team to point out their security conscious thoughts on how to improve new features or the existing codebases. But, this took over a decade. It certainly didn't happen overnight. The inception for this is in training, a security team that markets itself, and in constant communication with managers. Key to this is that devs don't set the direction of their coding projects, which is where many security teams get it wrong. The C-level on down to team managers set the direction. They need to be sold on the security team and the strategic value of their output. Just like passing functional tests, passing security tests needs to be part of a minimum viable product in a way that doesn't stop shipment of products. > The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms? Because, in 2017 developers need to understand more about security than they did just 3 years ago. Universities really haven't kept up with this. The reason you can't push security off to tooling, other than the minimal low-hanging fruit, is that human ingenuity is required. Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.
- SomeStupidPoint 9y ago
  > Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. That's my point -- why doesn't my IDE auto-generate a template threat assessment report to share with security as part of my code review process? ...why does it rely on me understanding the possible threats, rather than clearly expressing what data I use and letting security set flags on what I should watch? That sounds like a lack of tooling -- because there's not a technical reason.
  - IncRnd 9y ago
    >> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. > Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. I don't think you read prior to replying. Type signatures are orthogonal to the purpose of code. Just because a call is made to XTS don't convey that disk encryption is used. That is the issue that you glossed over. An IDE only has enough information to threat model an application correctly if it had enough information to write the application in the first place.

alexnewman 9y ago

Every big bug I have seen has been known by a developer and not ticketed and triaged. Apathy, sometimes, ignorance more often, lack of organization, almost always

SomeStupidPoint 9y ago
Anecdata will vary, but my experience has been those bugs get filed, marked "not important", and PMs have no way to sift the security impactful dozen out of hundreds to thousands of small defects in a large product's backlog. (And sometimes that backlog gets deleted, disappearing knowledge of those bugs.) I'm hoping we'll eventually be able to flag bugs with the types involved, and let systems automatically look for combinations that have a set of types that could be dangerous. My point was that it's not enough to focus on good intentions -- or culture -- you have to talk about mechanisms and technologies if you want a reliable system. Because the parts, humans in this case, are highly unreliable in isolation.

module0000 9y ago

You can't control humans unfortunately. Humans write code, and some of them will care more about the quality of work than others do. These people will at some point work above/below/with you, and their mistakes will cause you some sort of inconvenience. My mother taught medical school, and she had a saying... "What do you call the least qualified idiot who passes my class?", the answer is "Doctor". There are good coders and bad coders, and unless we start somehow forbidding the bad(but still good enough to get hired) ones to work with/for us - this isn't going to change.

diroussel 9y ago
If one developer can introduce a bug, that is life. But if it can go undetected by the compiler, unit tests, code review, component tests, acceptance tests, mutation testing, static analysis, pen test, etc, then maybe the process can be improved. It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.
- IncRnd 9y ago
  > It may not be cost effective, but then it's still not a lone developer problem. It's a management decision. That's one way of looking at the issue. Another way is that this is a way for an individual developer to stand out above his or her peers.

mtgx 9y ago

I think it's less about the culture and it's more about the big language developers making their languages safe by default for 90% of the developers using them. The "culture" aspect may come in when you're encouraging people to use languages such as Rust over C++, rather than something like "always follow this 50-point security checklist no matter what language you use".

IncRnd 9y ago
Product design, protocols, cryptography, regulatory restrictions, and so many other aspects have nothing to do with the language. Not every vulnerability stems from missing range or bounds checks. I mean this is the best way possible, but your answer shows that even people on HN don't understand what goes into securing a product.

IncRnd 9y ago

We've created the beginnings of this type of culture at my employer. More and more, developers reach out to the security team to point out their security conscious thoughts on how to improve new features or the existing codebases. But, this took over a decade. It certainly didn't happen overnight. The inception for this is in training, a security team that markets itself, and in constant communication with managers. Key to this is that devs don't set the direction of their coding projects, which is where many security teams get it wrong. The C-level on down to team managers set the direction. They need to be sold on the security team and the strategic value of their output. Just like passing functional tests, passing security tests needs to be part of a minimum viable product in a way that doesn't stop shipment of products. > The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms? Because, in 2017 developers need to understand more about security than they did just 3 years ago. Universities really haven't kept up with this. The reason you can't push security off to tooling, other than the minimal low-hanging fruit, is that human ingenuity is required. Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.

SomeStupidPoint 9y ago
> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. That's my point -- why doesn't my IDE auto-generate a template threat assessment report to share with security as part of my code review process? ...why does it rely on me understanding the possible threats, rather than clearly expressing what data I use and letting security set flags on what I should watch? That sounds like a lack of tooling -- because there's not a technical reason.
- IncRnd 9y ago
  >> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. > Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. I don't think you read prior to replying. Type signatures are orthogonal to the purpose of code. Just because a call is made to XTS don't convey that disk encryption is used. That is the issue that you glossed over. An IDE only has enough information to threat model an application correctly if it had enough information to write the application in the first place.