Security FAQ - Security Frequently Asked Questions

How can we get better at communicating the security properties of our systems? This article suggests vendors publish a Security FAQ - Security Frequently Asked Questions - and communicate the essence of their threat models.

Building trust

The security communication of many services delivers poor information. Customers, users and data subjects are left behind, worried about the security and privacy of systems.

What if instead, vendors provided target audiences with the essential security properties of systems, building trust and loyalty?

How can we achieve this?

Proposing Security FAQ

A good approach is: (1) to threat model our systems, and (2) to present the information from the threat model in a way that’s tailored to the target audience and clearly communicated.

FAQs - Frequently Asked Questions - have come a long way in customer communication. Many people like to read a good FAQ. Let’s communicate our Threat Models as a FAQ!

How to build a good Security FAQ

Security FAQs present security information in a question → answer style.

Questioner / Answerer roles

The document shows as a lively conversation between a questioner and an answerer:

• The questioner (Q) is curious about the service and it’s utility and concerned about the security of the system. They might be users or customers. Their job is to challenge the answerer, explore and learn.
• The answerer (A) has all the information from the vendor and provider. They want to convince the questioner that the service is useful and secure and engineering has done a good job with effective mitigation.

Suggested exploration structure

The FAQ conversation may follow a script:

1. Exploring utility: The conversation starts out with little knowledge about the system. The questioner asks curiously about the utility of the system. A first question might be “What can I do with <service>?”. The answerer explains the key features.
2. Challenging the security of features: The questioner then challenges the security of the features. The first questions can be quite naive and straight to the point, like in “Can everyone access <data>?”. The questioner treats undiscovered knowledge as if no mitigations were in place. The answerer presents core mitigations in place.
3. Challenging mitigations: As it continues, the conversation can build on what came before and go deeper. The questioner challenges mitigations and asks for bypasses and follow-up threats, like in “Could someone guess the credentials?”. The answerer explains how the mitigations are robust.

More suggestions

• Consider and interview target audiences.
• Have a well-crafted threat model inform questions and answers. If none exists, catch up.
• Keep the conversation natural.
• Prune the conversation to keep things relevant. Stick to the most relevant features, threats and mitigations of the system.
• Don't swap questioner/answerer roles.
• Use understandable language.
• Obviously: Include frequently asked questions. 😉

Alternative words

I started out with FAQ TM (Frequently Asked Questions Threat Model) and QATM (Question Answer Threat Model), then considered Security FAQ a better term for this specific use case. Thanks Avi.

Thanks

Thank you, Marcus, Michel, Izar and Avi for your inspiration and feedback! Some feedback was controversial. Still I feel Security FAQ may be a feasible solution between “Trust us. It's secure.” and publishing a TM.

“Nobody ever reads the FAQ 😕 Thats why the same questions get asked so damn frequently” — Avi

“Anyone asking to see a TM [threat model] will not be satisfied by FAQs.” — Izar