Choice Architecture in Product Security : Architecting secure choices

I recently came across the concept of choice architecture in a book (The Creative Problem Solver). This bIog explains how this concept can be used in product security as well. It covers the points below.

  • 🎯 What is choice architecture
  • 🎯 Example of Schipol airport in Amsterdam
  • 🎯 Tools of choice architecture
  • 🎯 Choice architecture in Product Security

What is choice architecture

It means that the way in which choices are designed and presented to a consumer impacts their decision making. It stems from the idea that our decisions are influenced by the way that choices are presented. The term “choice architecture” was coined by Richard Thaler and Cass Sunstein in their book Nudge: Improving Decisions about Health, Wealth, and Happiness.

Example of Schipol airport in Amsterdam

Schiphol international airport was trying to reduce urinal spillage in the men’s toilet in order to reduce cleaning cost. An ingenious economist who worked for Schiphol International Airport came up with an idea to etch an image of a black house fly onto the bowls of the airport’s urinals, just to the left of the drain. The result: Spillage declined 80 percent. It turns out that, if you give men a target, they can’t help but aim at it.

Tools of choice architecture

Behavioural scientists have grouped the elements of choice architecture in different ways. For example, Thaler, Sunstein, and John P. Balz have focused on the following “tools” of choice architecture:

1) Understanding defaults :

Defaults are defined as the choices that people must take active steps to avoid.

2) Expecting error

When it comes to errors, we can expect humans to err on nearly anything. Choice architects should take this in consideration when designing choices.

3) Understanding mappings

This refers to exploring the different ways that the presentation of information about choices is done. One way to do this better is to make the information about various options more comprehensible by transforming the details into a language which is understood by intended consumers easily.

4) Giving feedback

If a consumer selects the least favorable or unintended choice, there should be an instant or short time frame feedback mechanism to inform them of the same.

5) Structuring complex choices

When the choices become complex in number and in nature it becomes hard to choose. Choice architects should be cognizant about this and design the choices accordingly.

6) Incentives

Choices should be designed considering cost and incentives related to the choice provided for the consumer. Consider factors like below

Who uses it ?

Who Chooses ?

Who Pays ?

Who profits ?

Choice architecture in Product Security

Concept of choice architecture and its tools can help security professionals to design and recommend choices in a way so that engineers are more inclined to use them.

Below are some ideas on reusing these tools in product security space.

1) Understanding defaults

  • When developers need to select a secure library or secure container image or secure solution, provide them with a default option first. They must take active steps to select other options.
  • Certain security config should be enabled by default but changing it may need some steps or discussion or review etc.

2) Expecting error

  • Do not create roadblocks or harsh consequences even if wrong security choices are made by engineers. Analyze choices and find a way to handle the errors gracefully.

3) Understanding mappings

  • Provide comprehensive description or details with each proposed security solution or choice so that it is easier for engineers to understand them and make a choice.

4) Giving feedback

  • In case an engineer decides to go with a choice which is not preferred there should be feedback (instant or time bound) suggesting the possible implication of choosing the same.
  • It can be applied to choosing a library / framework / secret storage mechanism or even toolings.

5) Structuring complex choices

  • Wherever choices start getting complex, talk in the language of business and engineers and explain the choices in their language so that they can navigate easily and make the decision with least confusion.
  • Do not overload engineers with choices.
  • Have good documentation or inbuilt measures to provide a minimum number of safe choices in preferred order. Example – If a developer needs to store a secret, guide them with some preferred choices ranked in the order of risk.

6) Incentives

  • Security controls do not need to be the costliest one but should be aligned with the risk appetite so consider the cost and incentive in mind when suggesting the control choices to engineering.

Appreciate your feedback in improve this and suggesting more ideas.