6 ms·

It's a good list, but like most (all?) of these lists it doesn't offer too much advice on organizational best practices. IMO a security program which cannot ju

It's a good list, but like most (all?) of these lists it doesn't offer too much advice on organizational best practices. IMO a security program which cannot justify its own worth to others in the organization is incomplete. Most security professionals I've met (and I've been one of them, too) assume that security is or should be everyone's top priority. They struggle to deal with people for whom security is just one of many competing concerns.

bitexploder 5y ago
I think recognizing that security is just one of the many engineering challenges in building software is important. It must always be prioritized and budgeted like any technical debt. It can’t be ignored, but it is rarely the supreme concern for most software. We do a lot of turn key security engineering for our customers and it’s always about prioritizing the right concerns, both from an implementation perspective and from an organizational perspective. Another thing a lot of folks struggle with is knowing where your product is and where the security fights should be at a given product and organization scale. Risk assessment and threat modeling are huge for creating such a prioritization. Whether it’s formal and in depth or informal depends again on where things are. Beyond these concepts, well engineered software simply has less security defects, so focusing on quality and managing technical debt often means less security debt as well. It’s down to being an immature practitioner to think security concerns are always the primary ones. I think it’s a hard skill to master though, so I am not saying that with great judgement, someone should be a champion for security at most organizations and advocate for it. I think using empathy and curiosity goes a long way to maturing as a practitioner, but it took me many years of practice.
- gsoltis 5y ago
  I agree, it is absolutely a matter of judgment and is heavily dependent on the stage and specific threats a particular organization faces. It is difficult to balance product velocity with the need to protect a growing "something to lose" that the company is accumulating. I think one of the best things we can do as security professionals is to identify or work to create security measures that have outsized ROI and advocate for those. Using battle-tested software is one, as are, I believe, measures like MFA.
  - andrewstuart2 5y ago
    I'd also submit that one of the most important things is recognizing that ROI requires a net positive return. It's not just the time required to implement a control, you also have to factor in the opportunity cost of the increased friction. I've seen way too many times infosec organizations completely ignoring that the loss outweighs the actual risk. Hyperbolic analogy, but like forbidding driving delivery routes to avoid a parking ticket.
jollofricepeas 5y ago
Yep, this. OMG THIS! There are three things that most security types don’t understand: 1. Security is a small component of risk. Impact (in dollars) x Likelihood = Risk 2. Cybersecurity insurance can change the risk equation dramatically 3. It is possible for a security remediation to kill/harm more people than the underlying insecure system that the fix is being applied to Once you realize that security is a risk problem then you’re able to quantify that problem in dollars. Lives affected can be used as a metric too but dollars are the magical language that everyone can understand.
- kenniskrag 5y ago
  > Cybersecurity insurance can change the risk equation dramatically Do they check if you implement best practices in security? I could imagine, that this will have an impact on the premium.
  - windowsworkstoo 5y ago
    Yes and the audits around this change arbitrarily each year and you will be denied coverage if you are doing something otherwise competent but miss their particular flavour of the year
- austinjp 5y ago
  Fully agree that impact x likelihood = risk, although I'd extend it beyond dollars. Impact can include reputation, health, etc. Certainly these could be measured using cash-value as a proxy, but this risks chasing the wrong metric. I also recognise that "when a measure becomes a target it ceases to be a good measure", and cash as the bottom line risks increasing this tendency. Too idealistic, probably :)
  - faeyanpiraat 5y ago
    Corps don’t care about your health, they care about you being healthy enough to bring in the dough. And when you accept this fact, you can skip lamenting about all sorts of ethical questions and just know that everything will be a monetary decision in the end.
raesene9 5y ago
My reading of this list is that it's not designed to be a starting point for a full security programme, but a starting point for small organizations who don't even have a security function yet. In an ideal world, every company would have dedicated resource for this and a well targeted/justified programme of work, but I think there's quite a few where responsibility falls on the CTO and there lists like this can be useful.
- aahortwwy 5y ago
  This list and others like it are for sure useful, but the CTO of a smaller organization still needs to be able to: - Prioritize items on this list relative to each other. - Prioritize items on this list relative to other work. - Communicate the reasons for that prioritization to other members of leadership, at least.
sublimefire 5y ago
An interesting parallel is how these similar issues are solved in other engineering domains. In civil engineering you have heavy regulation and accountability. If a building falls then the engineer is responsible and she could get a jail sentence. To prevent buildings from falling there are regulations around minimum requirements, audits, material quality, etc. Regulation in software "does not exist" as the actual threat is minimal. If your program crashes then nobody dies ('m not talking about rockets). Therefore it always looks like security people always have temper tantrums as there is no meaningful quantifiable risk. In our org we ended up asking pentesters to get into the systems instead of just giving us an automatically generated report that contains links to CVEs. If they cannot use existing risks to get into the system then that risk is trivial.
- berkay 5y ago
  Good point. There are also some software solutions (picus security, etc.) that tests your validates whether your environment is exposed due to specific CVEs. It's a good way to prioritize which vulnerabilities that you should tackle first.

bitexploder 5y ago

I think recognizing that security is just one of the many engineering challenges in building software is important. It must always be prioritized and budgeted like any technical debt. It can’t be ignored, but it is rarely the supreme concern for most software. We do a lot of turn key security engineering for our customers and it’s always about prioritizing the right concerns, both from an implementation perspective and from an organizational perspective. Another thing a lot of folks struggle with is knowing where your product is and where the security fights should be at a given product and organization scale. Risk assessment and threat modeling are huge for creating such a prioritization. Whether it’s formal and in depth or informal depends again on where things are. Beyond these concepts, well engineered software simply has less security defects, so focusing on quality and managing technical debt often means less security debt as well. It’s down to being an immature practitioner to think security concerns are always the primary ones. I think it’s a hard skill to master though, so I am not saying that with great judgement, someone should be a champion for security at most organizations and advocate for it. I think using empathy and curiosity goes a long way to maturing as a practitioner, but it took me many years of practice.

gsoltis 5y ago
I agree, it is absolutely a matter of judgment and is heavily dependent on the stage and specific threats a particular organization faces. It is difficult to balance product velocity with the need to protect a growing "something to lose" that the company is accumulating. I think one of the best things we can do as security professionals is to identify or work to create security measures that have outsized ROI and advocate for those. Using battle-tested software is one, as are, I believe, measures like MFA.
- andrewstuart2 5y ago
  I'd also submit that one of the most important things is recognizing that ROI requires a net positive return. It's not just the time required to implement a control, you also have to factor in the opportunity cost of the increased friction. I've seen way too many times infosec organizations completely ignoring that the loss outweighs the actual risk. Hyperbolic analogy, but like forbidding driving delivery routes to avoid a parking ticket.

jollofricepeas 5y ago

Yep, this. OMG THIS! There are three things that most security types don’t understand: 1. Security is a small component of risk. Impact (in dollars) x Likelihood = Risk 2. Cybersecurity insurance can change the risk equation dramatically 3. It is possible for a security remediation to kill/harm more people than the underlying insecure system that the fix is being applied to Once you realize that security is a risk problem then you’re able to quantify that problem in dollars. Lives affected can be used as a metric too but dollars are the magical language that everyone can understand.

kenniskrag 5y ago
> Cybersecurity insurance can change the risk equation dramatically Do they check if you implement best practices in security? I could imagine, that this will have an impact on the premium.
- windowsworkstoo 5y ago
  Yes and the audits around this change arbitrarily each year and you will be denied coverage if you are doing something otherwise competent but miss their particular flavour of the year
austinjp 5y ago
Fully agree that impact x likelihood = risk, although I'd extend it beyond dollars. Impact can include reputation, health, etc. Certainly these could be measured using cash-value as a proxy, but this risks chasing the wrong metric. I also recognise that "when a measure becomes a target it ceases to be a good measure", and cash as the bottom line risks increasing this tendency. Too idealistic, probably :)
- faeyanpiraat 5y ago
  Corps don’t care about your health, they care about you being healthy enough to bring in the dough. And when you accept this fact, you can skip lamenting about all sorts of ethical questions and just know that everything will be a monetary decision in the end.

raesene9 5y ago

My reading of this list is that it's not designed to be a starting point for a full security programme, but a starting point for small organizations who don't even have a security function yet. In an ideal world, every company would have dedicated resource for this and a well targeted/justified programme of work, but I think there's quite a few where responsibility falls on the CTO and there lists like this can be useful.

aahortwwy 5y ago
This list and others like it are for sure useful, but the CTO of a smaller organization still needs to be able to: - Prioritize items on this list relative to each other. - Prioritize items on this list relative to other work. - Communicate the reasons for that prioritization to other members of leadership, at least.

sublimefire 5y ago

An interesting parallel is how these similar issues are solved in other engineering domains. In civil engineering you have heavy regulation and accountability. If a building falls then the engineer is responsible and she could get a jail sentence. To prevent buildings from falling there are regulations around minimum requirements, audits, material quality, etc. Regulation in software "does not exist" as the actual threat is minimal. If your program crashes then nobody dies ('m not talking about rockets). Therefore it always looks like security people always have temper tantrums as there is no meaningful quantifiable risk. In our org we ended up asking pentesters to get into the systems instead of just giving us an automatically generated report that contains links to CVEs. If they cannot use existing risks to get into the system then that risk is trivial.

berkay 5y ago
Good point. There are also some software solutions (picus security, etc.) that tests your validates whether your environment is exposed due to specific CVEs. It's a good way to prioritize which vulnerabilities that you should tackle first.