{"id":37313,"date":"2020-09-24T18:00:00","date_gmt":"2020-09-24T18:00:00","guid":{"rendered":"https:\/\/www.darkreading.com\/threat-intelligence\/solving-the-problem-with-security-standards-\/a\/d-id\/1338944"},"modified":"2020-09-24T18:00:00","modified_gmt":"2020-09-24T18:00:00","slug":"solving-the-problem-with-security-standards","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/solving-the-problem-with-security-standards\/","title":{"rendered":"Solving the Problem With Security Standards"},"content":{"rendered":"
<\/div>\n
<\/header>\n

More explicit threat models can make security better and open the door to real and needed innovation.<\/span><\/p>\n

Security people love compliance programs. Really! It’s why we have so many of them.<\/p>\n

No. OK, we hate compliance programs. Even when I try to tell jokes about compliance programs, I hate them.<\/p>\n

The reason I hate compliance programs is because they’re lists of things we need to do, and many times, those things don’t seem to make a great deal of sense. In threat modeling, I talk about the interplay between threats, controls, and requirements, and I joke that “a requirement to have a control absent any threat” is why we hate compliance programs (not joking).<\/p>\n

So I enjoyed it when Anton Chuvakin recently offered this advice to security teams in an article called “Data Security and Threat Models<\/a>“: “Don’t deploy security controls\u200a \u2014 \u200awhether data security or others\u200a \u2014\u200a unless you know what problem you are solving.” This reminded me of work that I started several years back and never published (until now<\/a>), because other work took priority. It is about the threat model that underlies the PCI standard.<\/p>\n

I had to reverse engineer this threat model from the standard as it then stood. Another way to say this is that the Payment Card Industry Data Security Standard (PCI-DSS) is a way to answer the question “What are we going to do?” \u2014 which is one of the key parts of threat modeling. But other aspects \u2014 such as the answers to “What are we working on?” and “What can go wrong?” \u2014 are left as an exercise for the reader.<\/p>\n

And let me tell you, dear reader: that was a lot of exercise, on the order of weeks! It was painful work. To state the obvious, there are some real head-scratchers in there, and all who go through PCI audits have their own. There were times I got angry. There were times when I was confused. What’s more, there’s literally no reason I should have had to do that work. I assume that the PCI folks work with an explicit list of problems they wish to address in their standard. If so, they should publish the list.<\/p>\n

Having done that work, I am somewhat happy to share the result. I sincerely hope to never have to do such work again. But I would like to echo and amplify what Chuvakin said: “Explicit threat models do make security better.” We should demand threat model documents from those who craft or promulgate standards.<\/p>\n

When I say a threat model document, I mean answers to what I call “The Four Questions:”<\/p>\n