What does security by default mean?

Security by Default is an underlying principle of Security by Design. It outlines the duty for developers to require no configuration or additional cost of users to ensure that their information is safe. While security by design is centralized on the idea that security must be constantly integrated into all aspects of the design process, security by default is focused specifically on the customer experience of the product, and defines their safety and privacy as a right rather than a luxury.

Both of these ideas go along with the movement to shift cybersecurity left – putting the responsibility on developers early on rather than treating the risks as they come up later, either among other development teams or on the user-facing side. Forcing users to configure their own security settings can lead to various complications and accidental security breaches. Not everyone has the same technological skillset as software engineers! Most users will not be security experts, and aside from that products pushed out by the tech industry can often be complicated and confusing in their permissions, settings, and options. Although there are some codified systems that developers are required to follow, security by default is more of a philosophy than a rule book. There are no specific compliance standards to adhere to. It should be thought of as a continuous and dynamic process that is balanced with product usability and efficiency of development.

Learn what Security by Default means for users, why it is so important in our complex technological landscape, what are some common mistakes that developers make regarding this subject, and how to implement security by default in practice.

Overall, security by default can be cost effective and efficient when implemented correctly. Holistic security planning vs. addressing problems as they come up is shown to exponentially decrease the cybersecurity-related monetary burden on a company. Boehm's curve provides a good visual to display this concept. The farther into the development process you get, the more costly and complicated it becomes to fix ingrained security risks.

Not to mention, configuring apt security settings for the user can build brand recognition and trust among consumers, which is vital for any company to be successful in the market. Yet another market incentive outside of the social responsibility to protect those using your product. To break it down a bit more, let’s look at how security by default comes into play in each of the major components of a tech product: the Hardware, Operating System, and Data Storage.

In terms of hardware, which is the physical makeup of the product, engineers should tailor these building blocks to be difficult for bad actors to bypass or disable. This is more relevant to companies making physical products like computers. On the operating system end, which manages the cooperation between hardware and software, security by default means implementing protections like automatic updates, ensuring the integrity of the core processes, firewalls, etc. This serves as the body of security by default, and is often the most important component for developers to consider. Without security by default in operating systems, it is much easier for attackers to hijack user accounts and impose malicious software. Finally, in terms of data storage, user information both in transit and at rest needs to be encrypted and controlled. This ensures that their personally identifiable information and other sensitive content is not released or used in cyber attacks.

Some common mistakes involving security by default include a lack of continuous evaluation of a products’ features, providing a hardening guide rather than default security configurations (which is a guide users must follow themselves in order to make their account/product more secure), not properly limiting who has access to sensitive information, bad default passwords, not implementing automatic updates of the product, etc.

Let’s see an example of this in action. Dev Eloper, a software engineer, has failed to properly configure user settings ahead of time, leading to a security breach. Instead of automatically installing updates when they are available, Dev designed his app to require that the user manually update it or turn on automatic updates. When the newest update rolls around, one that improves the backend software, some of his users don’t notice, or aren’t sure what the update is for and therefore don’t install it.

Here's what the back-end python code might look like:

What his users don’t initially realize is that Dev originally used an outdated open source package in his code, which is a mistake that the newest update is meant to fix. Obviously, though, this is not the only mistake since now users are continuously being exposed to his open source vulnerability since he failed to make his application secure by default. He should have programmed the app to update automatically, or at least configure the user settings to start with automatic updates rather than having that be a feature the user turns on themself.

As a result, bad actors were able to infiltrate some of his users’ accounts and expose their personal information, like emails, full names, and birthdays! Oh no, Dev!

Luckily, here are some best practices that can prevent mistakes like the one Dev Eloper just made. Specifically relevant to the example above is automatic updates and explanations of new tooling. Automatic updates prevent vulnerabilities like outdated software and code bugs, and explaining to users what updates and new features are doing makes them more likely to trust the security features. Especially with some updates being known to depreciate older technology, transparency is essential. Knowledge is a powerful tool! Having users understand the updates you are making to ensure their safety benefits everyone, and reduces the need for things like hardening guides.

The concept of ‘least privilege’ is also important in security by default. On the administrative and back-end level, company employees should only be given access only to what they absolutely need for their job function. For example, someone working as an assistant for an insurance company should not be able to see specific users’ protected health information (see our PHI lesson for more details). Authorization of each individual is also vital, and prevents attackers from entering spaces they shouldn’t be in under the guise of an authorized employee. For example, multi-factor authentication and single sign on (SSO) can ensure that each back-end employee is who they are claiming to be.

Another security by default measure is eliminating default passwords. Default credentials expose users to vulnerabilities because they are often well documented publicly, and make it much simpler for a hacker to break into an account through brute force. Automated tools and bots can be implemented by hackers to try common default passwords across thousands of devices with ease and efficiency. Products should be designed with strict password measures in mind – such as length, special characters, individuality, etc.

Speaking of, another key best practice is accountability and transparency. Secure logging, CVE (Common Vulnerabilities and Exposures) identification, risk assessments, and static and dynamic security testing are all great ways to keep track of security issues and stay honest with customers. Backlogs allow developers to identify trends in any security issues, find where they are coming from, and understand how to most effectively mitigate them in the future. Along with this is tailored risk assessments, which are security measures focused on each unique system and its needs. Plus, being transparent about the CVEs and balancing risk with usability builds user trust and helps the company determine which settings should be default in the process.

Some other general best practices include finding a balance between appealing to the customer and ensuring application features are secure, for example limiting integration points with other systems to what is necessary. This helps to minimize the attack surface and leave fewer potential loopholes for attackers to exploit. Developers should always use open source software responsibly (see our OWASP Top 10 Open Source learning path for more), use memory safe programming languages like C#, Rust, Ruby, Java, Go, and Swift, and be taught secure default practices by overseers.

Ensuring that users are set up automatically with the correct security settings keeps your them protected, builds trust with customers, and decreases the cost of fixing issues once they are already embedded in complicated workflows. Not to mention, it is important to take responsibility of maintaining security off of the user and place it onto the companies releasing tech products.

Learn more about making security a priority early on in the development process and taking responsibility off of the user here:

• Another step beyond secure passwords, Personal access tokens
• Understanding what CWEs are and how to use them
• Learn about the damage that can be caused by outdated open source packages