3 ms·

Given his experience, I'm surprised that the author is surprised that companies don't know how much time they spend on hardening. Nobody gets paid to do that un

by esafak 1y ago

Given his experience, I'm surprised that the author is surprised that companies don't know how much time they spend on hardening. Nobody gets paid to do that unless necessary for compliance; companies prefer to build features, and don't track this stuff. Don't even think about asking them to quantify the benefit of hardening. https://www.wiley.com/en-us/How+to+Measure+Anything+in+Cybersecurity+Risk%2C+2nd+Edition-p-9781119892304 https://www.wiley.com/en-us/How+to+Measure+Anything+in+Cyber...

actionfromafar 1y ago
It is pretty unknowable.
- 1over137 1y ago
  How do you figure? You could seat a 2nd programmer next to the first and have him watch and measure with a stopwatch. Expensive, but doable.
  - actionfromafar 1y ago
    I more meant that the benefit of hardening is almost impossible to quantify. Heck we have a hard time quantifying the benefits of the features.
mathattack 1y ago
I'm huge into measurement, and quantifying this has stumped me. It's one of the few areas I'm willing to surrender and say "Let's just pick a % of time to put on it." It's bad to say "Let's give it to folks who are underutilized or have capacity" because those are rarely the people who can do it well. All I can come up with is the hardening % should be in proportion to how catastrophic a failure is, while keeping some faith that well done hardening ultimately pays for itself. Philip Crosby wrote about this in manufacturing as "Quality is Free" https://archive.org/details/qualityisfree00cros https://archive.org/details/qualityisfree00cros
gregw2 1y ago
re: "Nobody gets paid to do that" There should be at least some large-company corporate incentive to measure "Bugs vs features"; the former is OpEx and the latter is CapEx, right? (I've been at places where Finance and IT aligned to put 3 mandatory radio-button questions in JIRA which Finance used to then approximate development expenditure as CapEx vs OpEx. You were also invited as a manager to override the resulting percentages for your team once every period)

by esafak 1y ago

actionfromafar 1y ago

It is pretty unknowable.

1over137 1y ago
How do you figure? You could seat a 2nd programmer next to the first and have him watch and measure with a stopwatch. Expensive, but doable.
- actionfromafar 1y ago
  I more meant that the benefit of hardening is almost impossible to quantify. Heck we have a hard time quantifying the benefits of the features.

mathattack 1y ago

I'm huge into measurement, and quantifying this has stumped me. It's one of the few areas I'm willing to surrender and say "Let's just pick a % of time to put on it." It's bad to say "Let's give it to folks who are underutilized or have capacity" because those are rarely the people who can do it well. All I can come up with is the hardening % should be in proportion to how catastrophic a failure is, while keeping some faith that well done hardening ultimately pays for itself. Philip Crosby wrote about this in manufacturing as "Quality is Free" https://archive.org/details/qualityisfree00cros https://archive.org/details/qualityisfree00cros

gregw2 1y ago

re: "Nobody gets paid to do that" There should be at least some large-company corporate incentive to measure "Bugs vs features"; the former is OpEx and the latter is CapEx, right? (I've been at places where Finance and IT aligned to put 3 mandatory radio-button questions in JIRA which Finance used to then approximate development expenditure as CapEx vs OpEx. You were also invited as a manager to override the resulting percentages for your team once every period)