To be truly effective, security needs to be built-in from the ground up. Hardware needs to be designed to resist physical attacks, and provide secure storage to other components. Operating systems need to take advantage of hardware security features, and applications need to use the right operating system security features.
Secure by Default is about taking a holistic approach to solving security problems at root cause rather than treating the symptoms; acting at scale to reduce the overall harm to a particular system or type of component. Secure by Default covers the long-term technical effort to ensure that the right security primitives are built in to software and hardware. It also covers the equally demanding task of ensuring that those primitives are available and usable in such a way that the market can readily adopt them.
We work with hardware, firmware and software vendors to develop technologies that mitigate the latest threats, and ensure that they result in a device that is no less usable than before.
Secure by Default principles
To start, it’s important to understand that Secure by Default isn’t a set of requirements or an assurance scheme. There’s no compliance badge or logo for products meeting a set of requirements. It’s more like an ethos or a philosophy. Product developers who adopt some of the principles of the philosophy will have a much easier time of securing their products in the face of new threats. Users can have confidence that products that were designed to be Secure by Default will fare much better in the long term, and have better usability as a result, than products where security is an afterthought.
The Secure by Default principles we prescribe are:
security should be built into products from the beginning, it can’t be added in later;
security should be added to treat the root cause of a problem, not its symptoms;
security is never a goal in and of itself, it is a process – and it must continue throughout the lifetime of the product;
security should never compromise usability – products need to be secure enough, then maximise usability;
security should not require extensive configuration to work, and should just work reliably where implemented;
security should constantly evolve to meet and defeat the latest threats – new security features should take longer to defeat than they take to build;
security through obscurity should be avoided;
security should not require specific technical understanding or non-obvious behaviour from the user.
Secure by Default in context
These principles can be applied in a wide variety of scenarios, and it’s not always obvious how to interpret them in any one in particular. The NCSC has a set of whitepapers which help explain some approaches to building products which align with these principles, and we'll be adding to these papers over time. They currently cover:
These aren’t the only scenarios in which Secure by Default principles apply, and we’d encourage you to think about how your particular sector would interpret these principles.
How can I get involved?
If you’re a product developer, it’s important to understand the wider ecosystem in which your product exists. What are the latest hardware features you can take advantage of in software? What are the latest threats it’s important to mitigate? And how can you ensure security is thought of in all aspects of your products development?
If you’re an organisation or consumer looking to buy secure products, ask your vendors how their products meet the Secure by Default principles. If you can recognise where these principles are being violated, this will ensure that your investments are likely to remain secure, despite changing threat landscapes in which they sit.
Security by Design
As part of the Government’s National Cyber Security Strategy, The Department for Digital, Culture, Media & Sport (DCMS) and the NCSC have jointly published a review to improve the cyber security of consumer Internet of Things (IoT) products and associated services.
The review addresses key risks related to consumer IoT and proposes a draft Code of Practice for IoT manufacturers and developers, including thirteen practical steps to address bad practices within the industry.
The guidelines within the Code of Practice include:
1. Ensuring that IoT devices do not contain default passwords.
2. Defining and implementing vulnerability disclosure policy.
3. Ensuring software for devices is regularly updated.
The report also includes a number of other measures, including a proposal for developing a voluntary labelling scheme. These recommendations will continue to be developed in conjunction with industry, academia, consumer organisations and international governments.
The Secure by Default Partnership Programme (SbDPP)
The SbDPP is a programme we run to encourage adoption of the latest security technologies, generate feedback for developers, and provide case studies to other organisation who may be considering deploying the same technologies. Please see the Secure by Default Partnership Programme pages for more details of this programme and how to take part, or for more details on the case studies that have been produced by this programme.