2.2 Security by default

Reducing vulnerabilities can be achieved by factoring in security from the design phase, and throughout the product development life cycle (for software, hardware, systems, and services). Applying security into design requires an evolutionary, agile approach, that allows practices to adjust to the evolving and expanding threat landscape with millions of new vulnerabilities and malware pieces discovered. This presumes an upgrade of internal processes, resources, and capabilities.

These topics are dealt with by several related concepts, which continue to evolve, such as security by design, security by default, security development life cycle, and trustworthiness. While all are connected to security aware software development, operational management, and threat mitigation practices; there are no agreed common definitions of those within the industry. The terms are often used interchangeably, though they may have different meanings. The GD is offering its contribution towards establishing a common understanding of the concepts, along with some related corporate practices.

2.1 Security by design

Security by design is about designing with security in mind: addressing risks from an early stage and throughout the product development lifecycle. It may be understood as designing with security controls from the beginning.

It applies to the design, development, deployment, and maintenance of software, hardware, and services; and also to system integration, through secure process of integration, and security tools like firewalls or monitoring tools.

Security controls should be implemented at all stages: - Before the product hits the market: through designing the product based on threat modelling and risk assessment, and developing and testing the code/design with security engineers. - After the product has hit the market: by putting in place vulnerability management and disclosure processes, by considering security when the product is being deployed in various environments, and in support and maintenance. - Regular, annual independent vulnerability assessments that assess whether processes are still current, and other checks. Ideally, security controls should focus on prevention rather than detection that identifies security issues post factum.

The process must be comprehensive and inclusive: considering engineering, security, business, and human resources aspects; and involving engineers, security professionals, and C-level management.

Examples

The Cybersecurity Tech Accord, in its first principle, invites partners to commit to ‘design, develop, and deliver products and services that prioritize security, privacy, integrity and reliability, and in turn reduce the likelihood, frequency, exploitability, and severity of vulnerabilities’. In its fourth principle, it invites partnerships among stakeholders across proprietary and open source technologies to improve technical collaboration, co-ordinated vulnerability disclosure, and threat sharing to minimise the amount of malicious code being introduced into cyberspace.

2.2 Security by default

Security by default builds on security by design: delivering the product preconfigured in a secure way. It may be understood as making security settings an opt-out product function.

‘Security by default: 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.’ (Charter of Trust, Principle 3)

Producers take the responsibility of managing security controls and reducing reliance on customers with a presumption that customers will not participate in enabling, managing, and controlling security settings. Certainly, customers may reclaim responsibility and apply security configurations differently, based on their own risk-based decisions.