Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Threat Intelligence

02:00 PM
Adam Shostack
Adam Shostack
Connect Directly
E-Mail vvv

Solving the Problem With Security Standards

More explicit threat models can make security better and open the door to real and needed innovation.

Security people love compliance programs. Really! It's why we have so many of them.

No. OK, we hate compliance programs. Even when I try to tell jokes about compliance programs, I hate them.

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

Related Content:

When Security Goes Off the Rails

The Threat from the Internet—and What Your Organization Can Do About It

New on The Edge: h2c Smuggling: A New 'Devastating' Kind of HTTP Request Smuggling

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

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?" — which is one of the key parts of threat modeling. But other aspects — such as the answers to "What are we working on?" and "What can go wrong?" — are left as an exercise for the reader.

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.

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.

When I say a threat model document, I mean answers to what I call "The Four Questions:"

  • What are we working on?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good job?

For a standards body, those questions get slightly tweaked:

  • What's your model of the systems your standard protects?
  • What can go wrong?
  • What must people do about it to become compliant?
  • Did you do a good job? (Why are these the meaningful threats? The best controls? Was your approach sane? Are you precisely aligned with other standards where feasible?)

That last point: Every time a standard uses slightly different words, all the compliance analysts in the world must re-evaluate their controls to see if they match. Divergence is expensive. If we lived in a world in which we could treat those differences as an opportunity to accumulate small advantages because we judge the consequences of programs, then we would appreciate those differences as an evolutionary force. But we sadly do not live in that world.

Explicit threat models made security better. The threat model that underlies a defensive standard ought to exist before the standard. There is certainly work to take it from "internal use" quality to release quality. But publishing it allows us to move from compliance to engineering.

This morning, I was talking to some rocket scientists. (OK, not really. They were aerospace engineers.) They emphasized to me that their folks are really, really good at engineering, at tackling a problem and solving it. But they get bogged down in compliance checklists. If we shared our threat models with them, they could create new solutions that work in their unique environment. In that, they're not unique. There are a lot of great engineers out there. There are a lot of unusual problems.

Specifying why we care is not opening the door to reinvention of the wheel. It's not an argument for ignoring the catalog of tested ways to manage problems. But it would be a great step toward opening the door to real and needed innovation.

Adam is a leading expert on threat modeling. He's a member of the BlackHat Review Board, and helped create the CVE and many other things. He currently helps many organizations improve their security via Shostack & Associates, and helps startups become great businesses as an ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-07
Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by XML External Entity (XXE) injection. An authenticated attacker can compromise the private keys of a JWT token and reuse them to manipulate the access tokens to access the platform as any desired user (clients and administrators).
PUBLISHED: 2021-05-07
Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by incorrect access control where password revalidation in sensitive operations can be bypassed remotely by an authenticated attacker through requesting the endpoint directly.
PUBLISHED: 2021-05-07
Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by incorrect access control that can lead to remote privilege escalation. PAXSTORE marketplace endpoints allow an authenticated user to read and write data not owned by them, including third-party users, application and payment term...
PUBLISHED: 2021-05-07
Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by an information disclosure vulnerability. Through the PUK signature functionality, an administrator will not have access to the current p12 certificate and password. When accessing this functionality, the administrator has the opt...
PUBLISHED: 2021-05-07
Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by a token spoofing vulnerability. Each payment terminal has a session token (called X-Terminal-Token) to access the marketplace. This allows the store to identify the terminal and make available the applications distributed by its ...