Society of Payment Security Professionals - Payment Security Blog

Think Outside the Dodecahedron

Abbott Mead Vickers BBDO, a UK-based advertising agency, coined the term “Think outside the dodecahedron” for The Economist. It’s a catchy slogan because it makes you think about thinking outside the box. It is like innovating thoughts on innovation. A creative reminder that makes you think.

This is how we need to view compliance. I dislike it when people speak in absolutes. They are so certain about themselves when there are so few certain things in this world. But flexibility does not create controversy, it does not polarize, and so fewer people write about it. Also, the understanding of flexibility is a luxury to those who understand something well enough to overcome the mental roadblocks imposed by rigid misunderstandings and misinterpretations.

Compliance != Security

The first thing people need to remember is that the terms compliance and security are not interchangeable. They are distinct items that often overlap but have the potential for being mutually exclusive. Compliance is a predetermined baseline minimum level of security or adherence to a set of principles. Security on the other hand is a spectrum of risk tolerance that one has towards a specific item. People who confuse compliance and security will forever be frustrated. Many times people ask, “well why doesn’t the PCI standard cover this thing?” or “why are frame-relay connections considered private networks?” They simply are and it is one of the rules of compliance that you need to learn. That being said, compliance is not entirely rigid either.

Live Free or Die Trying

In fact, both security and compliance involve risk. You cannot take the approach of an auditor and try to adhere to every requirement as it is listed in the standard. Instead, you need to understand the intent of each requirement and work towards achieving compliance under that intent.

For example, many times people want to meet the exact wording of every requirement but section 10 (audit logging) becomes a problem. For example, it states that you should log “all access”. Audit logging requires tracking of all individual access, all actions taken by administrators, and creation and deletion of system level objects. Some of these actions are almost impossible without the use of a keystroke monitor on each computer.

Instead you should understand the intent of requirement 10 and the work to map what you have back to the interpreted requirement.

Try Hard(er)

So just do it. Think outside the dodecahedron. Innovate and inspire. But whatever you do, please do not stay rigid and grim. There are far too many cynical people in this world and we do not need another.

If you have questions, ask. If you don’t know, research. If you cannot find it anywhere else than talk with your adviser (acquirer, processor, QSA, etc.)