Security is an important issue with any connected device.
It can be costly to add necessary security features once a product has been launched, or even late in development. On the other hand, leaving security issues unaddressed can have worse consequences.
“As a user of something I paid money for, I don’t want to have to think about how this device might cause me trouble later on,” says DornerWorks embedded engineer Raymond Smith. “If I have a system at home that I’m relying on to protect my family or my house and it gets hacked, or if it gets compromised, or if my usage data gets leaked out to someone, those are all things that as a user I wouldn’t want.”
As a device and firmware developer, these are the types of issues that DornerWorks engineers like Smith try to prevent, reducing risk and adding confidence to each project.
Security by Design starts with a robust process, which first needs to consider two important areas:
Without understanding these implications, you could potentially leave vulnerabilities in your design that won’t be noticed until later on. With contextual knowledge, it is easier to choose the right components, for example, that can reduce risks and mitigate cyberthreats.
Those who fail to consider security from the beginning potentially leave room for vulnerabilities. It can be difficult, or even impossible in some cases, to go back and add those security features in later.
“If you want the ability to update a device over Wi-Fi but those components aren’t already built into the device firmware, then you’re going to have a hard time getting those updates out,” Smith says.
A separate hardware encryption and key storage device (often referred to as a Trusted Platform Module (TPM) or a secure element) is typically used in devices that need strong security around firmware updates.
“If you have a device that is initially designed to connect to a service over Wi-Fi, but it was not initially designed to securely store certificates and private keys for validating updates, and it was released that way, it would be extremely difficult (likely prohibitively difficult) to provide a way to go back to those devices and manually add a separate hardware encryption and key storage device to the original device, and then update the firmware to use that new encryption device for accessing the certificates and keys,” Smith says.
If the device can receive updates but lacks sufficient security features, your network may be forced to maintain multiple configurations, with some devices that are unsecured and in some devices that are secured.
“That’s additional maintenance cost,” Smith says. “All of those things could potentially lead to additional costs If you don’t design them in from the beginning.”
There are different implementations of Security by Design as a set of principles, depending on market, technology and desired outcomes. However they may be ordered, many of those principles remain the same. Here are seven of the most important:
The Principle of Minimizing Attack Surface Area holds that in order to minimize attack surfaces, developers should ask what their system is supposed to do, as well as what it isn’t. It’s also important to understand your attackers, or anyone who might potentially compromise your system.
These pieces of knowledge will help you maximize your ability to detect attacks and minimize the potential for service disruptions or compromises.
“In general, the more potential points of compromise, then the more likely it is somebody’s going to find one of them,” Smith says.
Once development is complete, there should be a way to audit and test the system to make sure the components are working together as intended. Using the security by design mindset, these testing and auditing features are planned for up front.
The Principle of Least Privilege is how you put users on a “need to know” basis, allowing certain access permissions, and keeping others shut out of sensitive data stores. This ensures that users have the privileges they need to do their jobs, and only those permissions, lessening the potential damage of a malicious hack.
The Principle of Least Common Mechanism advises against sharing system mechanisms among users or programs that do not require them. When those mechanisms are shared, the potential for unintended and uncontrolled information flows is increased, as is the risk for data breach.
The first objective of the Principle of Separation of Duties is to prevent conflict of interest (real or apparent), wrongful acts, fraud, abuse and errors. This principle ensures that individuals don’t have conflicting responsibilities, and helps detection of control failures like security breaches, information theft and circumvention of security controls.
The essence of Defense in Depth is planning on the eventuality that any security system you put in place is going to fail, and therefore the best approach is one that enables you to know when those failures occur, and layer security measures where necessary, from the front door of your office to the server cabinets that hold your customer data and IP.
In line with Defense in Depth, the Principle of Failing Security also depends on the eventuality that your system will fail, hence a need to design systems that can fail without leaving systems open to attack. In order to do this, developers can base access decisions on permission rather than exclusion. The default situation should block access until the conditions of a preset protection scheme are met.
The Principle of Open Design holds that security should not depend on the secrecy of the design or the implementation. A system that relies on a novel language or method so unusual that no one can currently understand it can and may still be cracked open, in which case the attacker has immediate and full access to the system. This does not mean that the source code of your products should be made public, but that your security measures should not rely on the ignorance of potential attackers.
By ensuring a single user, process, or failure can’t bring down your whole system, and that sensitive information is protected by cryptographic systems rather than obscurity, these principles can limit the potential damage of cyber-attacks.
If you are implementing your system on a widely used platform like Amazon Web Services (AWS) or Microsoft Azure, there are both proprietary and Open Source resources that can help guide you towards the principles of security by design.
For web applications the Open Web Application Security Project (OWASP) offers similar guidance to follow, using 10 principles:
The Cyber Security Principles offered by the UK National Cyber Security Centre, are loosely aligned with stages at which an attack can be mitigated:
Secure product design is important to you and your customers, and that’s why it’s important to us. Schedule a meeting with our team to discuss your next secure product or adding security to an existing system. We will help you map out a plan that turns your ideas into reality.
