Security right from the start

The principle of Security by Default is focused on considering security to be built in and up and running from the start. This means including security considerations  into a design of a product and  the underlying processes and even when formulating policies for an organization at large instead of security being an add-on feature at the end of the process before going to production.

The rapid increase in digitization today, especially accelerated by the pandemic situation, has led to a tremendous increase in the attack surface. Therefore, there is a need to consider the Security by Default principle as a fundamental need to ensure adequate levels of security in society.

The Charter of Trust aims to increase cybersecurity levels in  society via collaboration between its member companies across industries and associated partners and has defined 10 Principles to achieve this goal. One of the 10 Principles is the principle of security by default. The Charter Taskforce on Security by Default has been working on this principle for the past three years , compiling baseline requirements and creating explanatory documents on what it means to adopt security by default.

Security by Design vs Security by Default

The concept of “Security by Design” is quite familiar. It means to include security features and capabilities into products and services when designing and producing those products and services. “Security by Design” is a basic requirement and has improved the security of products and services tremendously.

The concept “Security by Default” goes a step further: The security and capabilities of a product or service are active from the beginning. This means that no explicit activation is necessary since this can be forgotten or neglected in some cases. It is especially helpful and necessary in devices used by people not that familiar with security features, e.g. in IoT devices like smart bulbs or smart watches.

Furthermore, “Security by Default” aims at maintaining the security properties during operation and over the lifetime of a product or service. One of the basic requirements for achieving “Security by Default” is therefore that the security properties must be tested accordingly, i.e. under real operating conditions.

Design vs reality

“Security by Default” can really make a difference if security features are sufficient, enabled and productive for the lifetime of a product or service. The need for Security by Default as stated above can be seen in the incident that happened in 2019, where a feature was found in a series of connectivity chips used to connect billions of IoT devices like medical devices or smart meters. An attacker could use this feature in operation to gain control over the machine hosting it. Although these chips had several security features, they had not been sufficient to prevent attacks during operation. You can read about this here.

Charter of Trust drives Security by Default

CoT’s Principle 3 states: “Adopt the highest appropriate level of security and data protection and ensure that it is preconfigured into the design of products, functionalities, processes, technologies, operations, architectures, and business models.”

How do we work to achieve this?

To cover the broad spectrum of topics under security by default, we as a taskforce defined our scope of what we thought was essential to cover under Security by Default and would bring us nearer to the goal of increasing security levels. We therefore split the work into three phases and the taskforce members from companies collaborate to define baseline requirements for security by default. The three phases are:

• Phase 1: Products, Functionalities and Technologies
• Phase 2: Processes, Operations and Architectures (Ongoing)
• Phase 3: Sharing of best practices for adoption of Security by Default

We finalized Phase 1 last year and have nearly finished Phase 2, so we are about to start the final phase. Stakeholders from different industries helped us get different perspectives on Security by Default while defining the scope and the baseline requirements to ensure that these requirements can truly be baseline and can be adopted across industries.

Taskforce resources / results so far

• Baseline Requirements for phase 1 – Products, Functionalities and Technologies
• Explanatory document along with mapping to global standards to facilitate the adoption of the baseline requirements
• Charter of Trust Blogpost on Security by Default
• Podcast on Security by default

Outlook

With the Charter of Trust set out to increase cybersecurity in the society through collaboration between industry partners and exchange with political stakeholders, the taskforce is fully committed in executing this vision. The taskforce will soon publish the results for phase 2 on processes, operations and architectures with the baseline requirements and an explanatory document.

The next steps include moving to phase 3 focusing on  best practices to adopt Security by Default requirements from the member companies and getting the message across to different stakeholders in society and supporting a dialogue with stakeholders on these crucial topics. This will include several ways of sharing best practices, e.g. a webinar series with a panel format including an external audience, and articles and case studies showcasing where the requirements have been successfully adopted.