How to Give Security Advice

While creating the DNC’s Device and Account Security Checklist, I read a lot of documents that purport to give people advice on how to secure their personal or organization’s data. A great deal of that advice is not great, and a lot of it is actually wrong. When security advice is wrong, it diverts the readers’ attention to actions that will not keep them safe. It makes them less safe.

The authors of these misguided security guides make a series of common mistakes. For example, many guides are a dumping ground for all possible advice to a wide spectrum of audiences. That means the guides are needlessly long and cover attacks ranging from the most common to the improbable. Some advice lacks technical merit, meaning it won’t help stop attacks at all.

Lest you think this problem is new, consider this Microsoft document from 2009 titled “So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users” which talks about some of the reasons users have historically not heeded security advice. It’s worth your time to read it.

For more background to help you understand the advice below, check out a related Twitter thread here.

With that out of the way, here is my advice for people who are writing security guides. Thanks to Sean Sposito, Michael Kaiser, and Eric Gross for their input!

Before you begin!

Before you start writing advice, think about what you are trying to accomplish, and how. Most advice lacks some of the following elements, reducing its effectiveness.

Define the threat model

1. You don’t have to detail every aspect of the threat model in the document itself, but you should detail the Audience, the Adversaries, and the Assets you want to protect. Yes, I just coined the AAA rule of security advice!
2. Don’t focus on spy-movie threat models. Just because something is possible, does not make it probable. Too much security advice intended for the general public contains advice that mostly applies to actual spies.

Select a narrow audience

1. Segment your audiences into well-defined, smaller groups. When you address multiple groups at the same time, you may help none of them. For example, separate advice for end-users at home from company staff. Why? Because company staff may have company-issued devices, or specific company protocols to follow. Or if your advice is meant for 99% of US citizens, don’t lump in advice best suited for reporters working in hostile regimes.
2. You may need to create and maintain multiple similar documents, but you must prioritize capturing the imagination and attention of the reader over your desire to reduce the number of documents. The default is that few people will read your doc, and even fewer will take action. You have to work hard to overcome that fact.

The Structure

Now that you have a threat model and a narrow audience, you can start writing the main document. The following points will help you avoid the most common pitfalls.

Keep it short

1. Keep the document short so people don’t zone out or think about coming back to it when they have more time. They’ll rarely have more time later.
2. Prioritize. Stack rank the advice. Put the most important control at the top.
3. Use the 80/20 rule. List the top advice that will bring the most value. Don’t add advice that will not help most readers.
4. Kill the bloat. Resist the temptation to put all possible advice into one doc. Each piece of advice should fight to remain! The advice should directly relate to what the target users are trying to protect. Many pieces of advice will feel good to include, but will fail the AAA test. If so, cut it! You will be uncomfortable cutting deeply, but you can add that advice back later if there is evidence it would have helped the majority of your target audience. (Spoiler alert: it probably won’t!)

Focus on action

Some of this advice is overlapping, but I include this level of detail to overcome our instincts to create guides that do not focus on action.

1. Use a proper checklist where the reader either completed the task or not. No wiggle room. I like having an explicit checkbox for the reader to track their work. That also forces you to make it actionable.
2. Give discrete action items that the readers can achieve. Separate each step when possible.
3. Detail the work. Don’t say “Turn on 2FA on all your services”. Instead, list all the specific services you want them to secure (Facebook, Twitter, your primary bank, etc.). The more specific you can be, the less the reader has to think about, increasing the odds that they complete the tasks.
4. Remove vague advice, and include only actionable steps. For example, don’t say “Enable strong spam filters”. Instead, supply links to the specific steps the reader must take from the top 2–5 vendors. Make advice granular so users take action immediately with the least amount of friction. If you, the person writing the advice, can’t find concise vendor implementation guides, is your advice really going to help the readers?
5. Give platform specific advice. Advice may differ in platforms like Windows, Chromebooks, Linux, and OS X, or iOS and Android. For example don’t tell Windows Home users to use full disk encryption when Microsoft does not offer that feature in that OS. Give advice on what platform features should be enabled, or disabled.
6. Remove “Don’t” advice. Commands like “Don’t” are often signs that you are not creating a checklist, but are writing general principles that people won’t adhere to in practice. Don’t do that! :-) “Don’t” advice feels good to write, but in general will not work.

A word for technology vendors

If you are a vendor writing documentation to teach users or administrators how to secure your product, your document should be short. If it is not, the product may not be “safe by default”. In many cases, the checklist you give your customers is a roadmap of the failure to make security the default, and you should revisit those decisions.

The Contents

This is the section you have been waiting for! But again, most security advice guides lack deep thinking in the topics listed above, and so the actual content is lacking.

Stay on target

Do not include off-topic advice. If your goal is to help people avoid phishing attacks, don’t include tips on how to secure paper documents. (I’ve recently seen this exact mistake!)

Just the facts

1. Evaluate the advice against an honest assessment of how the attacks actually work in practice, especially for the targeted audience. Do people and systems really get compromised this way? (Really??) Every piece of advice should raise the cost of attack to the adversary. That means the advice should slow or stop the attack, or make it louder (easier to detect). Too much security advice stems from a surprising misunderstanding of how successful attacks work. You should be able to cite examples of attacks that would have been prevented had the victim followed your advice, perhaps with press clippings. For corporate networks, a good way to do that is to cite the Verizon DBIR or similarly respected reviews of attacks.
2. All US federal government advice should tie back to the NIST CSF. If we’re going to ask organizations to use the CSF, there should not be other advice that is separate from the CSF. Call out specific CSF control objectives (like PR.AC-1 or DE.CM-4). This point may be challenging, but if you put yourself into the shoes of an overworked IT professional, it’s not realistic to track n sets of input into the security program and priorities.
3. Advice should be focused on the current attacks, not theoretical attacks. Some advice tries to be future proof, but that is not possible. That would require knowledge you don’t have, and it will make the list too long. Focus on the major pain points people and organizations have experienced in the past year.
4. Be clear about how the attacks work, and the potential impact, but do not engage in FUD (Fear, Uncertainty, and Doubt). For example, don’t give Halloween candy tampering advice when that kind of attack does not happen in practice. Advice for highly improbable events is toxic.

Give actionable advice instead of “impossible advice’’

“Impossible advice” is a term for advice that sounds good, is probably common, but is not informed by how humans work. Impossible advice often requires:

• Omniscience: “Don’t interact with suspicious emails”. What does “suspicious” mean? If it was so obvious what that meant, some automated system would have blocked it.
• Users not using technology the way it was designed: “Don’t click on malicious links!”. But the web is literally nothing but links, so telling people to not click is impossible.
• Infinite vigilance. Common phrases include “Be aware of…”, “Be on the lookout for…”, and “Keep your guard up…”. But you cannot be vigilant all of the time. This advice feels good, and shows up in almost all security advice, but it’s impossible to attain. Eliminate it.
• Immunity to trickery and cognitive bias manipulation. Many attacks include exploitation of the way the human mind works, like a sense of urgency, or an order from a superior. Overcoming teams of dedicated human adversaries and their tricks is impossible.

Deliver the hard advice

1. Be bold! If you believe that a core element in successful attacks is understaffed teams running on-prem servers (like Active Directory), tell those organizations that they need to move to qualified managed services (like Azure AD, Okta, etc.). Such advice may take some time and money, but will give outsized benefits by cutting off entire classes of attack. Will your advice lead to a minor, short term, and tactical improvement? Or will it lead to a dramatic cost to the attackers? If your advice isn’t rooted in attacker economics, it’s too tactical.
2. Call out root causes when you can. When you give advice, ask yourself if the technology in question is “safe by design”, or if it should be fixed to make your advice unnecessary. For example, when you tell people to keep your phones up to date, that’s because some auto-update systems don’t work well. So in addition to telling the users to update, create a list of places where the vendor has shipped a product that is not secure by design. Too many products are unsafe at any speed, and we need to do more to hold them accountable.

When you are done

Just kidding. You are never really done given how much the technology and threat landscape change every few weeks. But there are a few things you should do as you consider pushing your advice documents out.

1. Do lots of QA. When you have a strong draft document, sit down with a member of the community you are seeking to help. Ask them to read the document and to take action. Do not help them, but instead watch them and take notes. You will start to get a feel for how well actual people respond to your advice. The results will likely be disheartening but don’t give up! Go back to the top of this list and iterate. The entire process will take more time than you expect.
2. Focus on the bias to action. Reread the advice objectively to see if it has a bias towards “education” and “awareness” for the reader, or a bias to action. We don’t need people to be “aware”. We need them to take action.
3. Review it aggressively on a regular basis. The world of cybersecurity moves fast in some ways, and slowly in others. Has the threat landscape changed? If so, change the advice. Look for opportunities to retire entire segments of your advice.

Good luck!

Twitter: boblord