4/6 Related Quote: "... we should see safety in terms of resilience and not as absence of something (accidents, missed days etc.) but rather as the presence of something."
Here is a proposal to operationalize this for #cybersecurity (in an Amazonian fashion π):
cc: @jeffawilke
5/6 Focus on *input variables* (E.g.: Do we have automated XSS & CSRF prevention controls in all of our WebApp Frameworks so that developers donβt have to worry about those vulnerabilities?) instead of *output variables* (E.g.: Zero XSS & CSRF findings in a PenTest or Scan).
6/6 And move the terminology from security controls to control *mechanisms*. A mechanism is a tool or process where you achieve adoption and more importantly is periodically reviewed to see if it is doing its intended job given what's changed over time & if it can be improved.
2/8 Note: My position is mostly for large enterprises - especially the ones that operate in different sectors/countries (jurisdictions) & thus are subject to multiple compliance mandates & regulations. But, one can philosophically embrace this approach for other enterprises too.
3/8 First up, if you are subject to various compliance regulations and standards, it is best to make sure that your internal security standards account for them all so that you can present a unified set of security requirements to product/engineering. No need to mention "PCI".