Thread by @laraghavan

1/8 Now that the poll has closed, I'd like to disclose that I'm with the minority (No) on this one. Rationale summarized in this thread 👇

#pci #training #appsec #swsec

cc: @shehackspurple @bilcorry @robertauger @cigitalgem

https://twitter.com/laraghavan/status/1377092227562827783

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".

4/8 Compliance is usually the lowest bar for security. If PCI becomes well-known & the yardstick internally, getting stuff prioritized might get tricky. E.g.: If PCI wants you to move to <NextGen Blah> only after 2 years, but you'd rather do it now (for various reasons).

5/8 I've seen folks use "PCI Compliance" as a stick for training and other AppSec controls. Please don't. More in this thread:

https://twitter.com/laraghavan/status/1377437330445754369?s=20

6/8 Consider the vuln. highlighted in this tweet:

https://twitter.com/shehackspurple/status/1377079591823544322

At your scale, it is best to solve CSRF at the framework layer in an automated fashion. When done right, devs don't even have to know/worry about this. Don't let PCI dictate what you train your devs on.

7/8 Side-bar: Acknowledge that training is a VERY ineffective control - especially at your scale, complexity and churn. You need multiple checks and balances via processes and tools/technologies to ensure that your devs. don't shoot themselves in the foot.

8/8 As a community, we have a healthy disdain for compliance based "push" of security products. Do we feel the same way about training?