How to build software products that are “Secure by Default”

Third up in our series about the global move to make software more secure: Secure by Default. What’s it all about and how will it affect you and your team? Let’s get into it.

Keen to read the first and second post in this three-part series too?

What is Secure by Default?

Imagine you’ve just bought a brand new home — the type where you’re the first person to live there, ever. The paperwork completed, you excitedly head over to look around your new digs and plan where your favorite chair will go.

How surprised would you be if you noticed that none of the windows closed and the front door didn’t have a lock on it?

We expect these things to be built in as standard. You wouldn’t think to add them as a specific line item in advance. But, your house is more secure from day one because of these features being in place.

Those expectations we have about what is provided “out of the box” are known as our default expectations. 

Secure by Default is a set of these expectations: the features or functions that make a product or service secure, by default. So out of the box, without any additional work or cost, they’re resilient against cyber attacks. 

The impact of configurable products

Based on the definitions above, it's logical then that in a Secure by Default product, we have to consider security carefully when we give our customers the chance to change configurations.

Every configuration change or choice they make has the potential to change the security risk of the product.

Secure by Default isn’t about taking away all people's options for the sake of keeping them safe — it's more about creating balance in terms of what risks we do and don't expose people to if they use products as they come.

Creating Secure by Default products means being more thoughtful about how they're configured when people buy them — effectively, how secure (or not) is this thing if someone uses  it exactly as it is, without making any configuration changes themselves?

It doesn't mean that a Secure by Default product can't be configured exactly how the user wants it to be. What it does mean is that we have a responsibility to give our users and customers the details they need to make informed choices about what configurations they change and how they change them, particularly if a change they make could have impacts on their security.

The move towards Secure by Default means it's becoming more and more important for people who create products (including UX people) to learn about and understand the security implications of the choices they make and how those choices are presented to users.

Five common tactics for making your product Secure by Default

If you’re thinking about embracing Secure by Default, there are a number of easy steps you can take that can help.

Eliminate default passwords

Ever had an issue with a device and just googled for the default admin password? Many of us have default passwords that are well-known, easily found, and require changing on initial setup (which often doesn’t happen). Eliminating the use of default passwords can help mitigate this risk.

Single sign-on (SSO)

Many organizations use SSO as a way to centralize the control of their accounts and make sure they have visibility over who uses what in their team. It also helps onboard and offboard people more securely, and providing SSO helps companies continue that good security pattern and use their own, predefined authentication systems.

Secure logging

If something goes wrong, logging is an essential ingredient in your response. You can’t investigate without logs. Enabling logging by default allows every customer to respond if things go wrong.

Forward-looking security over backwards compatibility

This one may be easier said than done, we know — here’s looking at those of you who have to support dozens of old devices and browsers. However, if you have the ability to: stop supporting older, insecure browsers and devices. Prompt your users to update, upgrade, or patch before they continue. The more old technology we have to support, the harder it gets to stay secure in every situation.

Track and reduce hardening guide size

You can think of the need for hardening guides — documents or how-to guides that show you how to configure something securely — as an anti-pattern. An anti-pattern is a commonly used process that has more bad consequences than good ones, despite initially appearing to be a good solution to a problem.

If you need hardening guides, then chances are the default configuration of your product is insecure and the user experience of your configuration is not helping users make good, secure decisions. When you spot a need for a guide, use that as your requirements for a refactor instead.