Security by Design: Principles, Compliance Aspects and Best Practices

Shlomit Cymbalista
Shlomit Cymbalista

7  min read | min read | 13/06/2023

What Is Security by Design

Security by design is the practice of developing software and hardware to prevent security vulnerabilities and mitigate security risks. This is done through measures such as adherence to secure coding practices, robust testing, strong authentication, and continuous monitoring in production.

It is far more effective and less costly to design a system with security in mind from day one than to discover vulnerabilities and patch security holes only after a product is released to the market. Security by design allows organizations to build security into a product from the ground up.

Security by design is becoming especially important for IoT devices, driven by the growing number of vulnerabilities discovered in IoT systems. The number of cyber attacks against IoT systems approximately doubled between 2020 and 2022. A major concern about IoT devices is that they continue to be used when their firmware, software, or third-party components are no longer updated or supported; devices that are secure by design have robust update mechanisms that can address this problem.

In addition, regulations and standards such as NIST, IEC 62443, and new FDA guidelines are mandating security by design principles for certain types of IoT devices. Regulators are placing a special focus on medical devices, and medical device regulations mandate even stricter requirements for these devices. The regulations set a high bar for security and post-market surveillance of IoT devices. It is very difficult to retrofit existing devices to meet these requirements—making security by design a critical task.

How Security by Design Works: From Concept to Delivery

This approach ensures that security is not an afterthought but rather an integral part of the process, from concept to delivery. Let’s discuss each phase in detail:

Concept Phase: Defining Security Requirements

In this phase, the organization identifies the security requirements and objectives of the system or application. This involves assessing the potential risks, understanding the regulatory and compliance requirements, and considering the specific security needs of the organization and its users. Security requirements may include confidentiality, integrity, availability, authentication, and authorization, among others.

Design Phase: Developing a Security Architecture

During the design phase, a security architecture is developed that incorporates the defined security requirements into the overall product design. This involves selecting appropriate security controls and mechanisms, such as encryption, access control, and secure communication protocols. The security architecture should be designed with the principle of “least privilege,” ensuring that users and components have only the minimum access necessary to perform their tasks.

Development: Reviewing and Scanning Software Code

In the development phase, the organization ensures that the software code is written securely, following best practices and secure coding guidelines. This includes performing code reviews, either manually or using automated tools, to identify and fix potential security vulnerabilities. Static and dynamic code analysis tools can be used to scan the code for known vulnerabilities, coding mistakes, and other security issues.

Testing and Validation: Security and Penetration Testing

During the testing and validation phase, the organization performs various security testing activities to ensure that the system or application is secure and meets the defined security requirements. This includes vulnerability scanning, penetration testing, and security audits to identify and address potential weaknesses and vulnerabilities. Security testing should be performed both at the component level and for the entire system, simulating real-world attacks and threat scenarios.

Delivery Phase: Security Training and Technical Support

In the delivery phase, the organization provides security training and technical support to ensure that operations teams can effectively handle security concerns and maintain a secure environment. This may include training on secure deployment, configuration, and maintenance of the system, as well as incident response and management. Ongoing support should also be provided to ensure that the system remains secure as new threats and vulnerabilities emerge, and as updates and patches are released.

Security by Design Regulations and Guidelines

In many countries, and for many types of devices, security by design is becoming a regulatory requirement, and not simply a recommendation. Here are a few important laws and standards that mandate security by design for IoT devices.

Systems Security Engineering (NIST)

The National Institute of Standards and Technology provides reliable security-by-design guidelines, such as NIST SP 800-160. This publication combines established security standards, focusing on engineering practices and techniques. It forces organizations to consider the entire operational life cycle.

The first two chapters define the security-by-design concepts and methods, outlining the core principles that allow organizations to apply them and customize them to the organization’s environment. For example, trustworthiness is a major concept—the document explains the relevant requirements, including safety, reliability, performance, and resilience attributes. The purpose is to consider digital security from the organization’s unique perspective.

The NIST SP 800-160 guidelines apply to all enterprises that take security design seriously and cover all product life cycle stages.

Biden Administration Executive Order on Cybersecurity

President Biden issued an Executive Order (EO) aimed at improving the nation’s cybersecurity by encouraging public and private sectors to collaborate against emerging cyber threats, and in particular, providing an initial strategy for dealing with supply chain attacks.

Affected parties include:

  • Federal executive agencies, which must modernize their security practices.
  • Federal contractors, such as software vendors, who will need to adhere to new cybersecurity standards and share more information on cyber incidents.
  • The private sector, which will likely see a focus on software supply chain security, transparency, and consumer security labeling for software and IoT devices.

PATCH Act

The “Protecting and Transforming Cyber Healthcare Act” or PATCH Act aims to ensure the cybersecurity of medical devices. As more Internet of Medical Things (IoMT) devices join healthcare networks, these networks become more vulnerable to threats such as ransomware attacks.

IoMT devices often lack strong authentication and rely on vulnerable software, making it crucial to improve their security. The PATCH Act focuses on providing cybersecurity governance for medical device manufacturers but also affects healthcare organizations. Both device manufacturers and healthcare systems must address insecure legacy IoMT devices.

EU Cyber Resilience Act

On September 15, 2022, the European Commission published the EU Cyber Resilience Act (CRA) regulation proposal. The CRA emphasizes cybersecurity throughout the entire product life cycle and mandates documentation of cybersecurity risks, vulnerability monitoring and mitigation, and incident reporting.

ENISA, the European agency for cybersecurity, will oversee future developments. The regulation aims to increase cybersecurity levels in digital products and provide better information and access for users.

Additional Regulations

FDA Guidance for Cybersecurity and Medical Devices
The FDA’s draft guidance on medical device cybersecurity provides recommendations for device design, labeling, and documentation required for premarket submissions, to ensure medical devices are resilient to cybersecurity threats.

Code of Practice for Consumer IoT Security & UK IoT Security by Design
On January 27, 2020, the UK Government announced plans to introduce laws to protect IoT device users from cyber attacks. The new laws focus on the first three recommendations from 2018 Secure by Design report.

Safety by Design Framework in Australia
The Australian Safety by Design framework addresses online risks and harms from social aspects of digital technology usage. It covers a range of digital products and services, defining clear responsibilities for providers, which include implementing specific technical measures.

Security by Design Principles and Best Practices

Secure the Software Supply Chain

Programmers increase security risk whenever they add third-party libraries or use external APIs in a device. Any third-party component, whether embedded into a device or integrated with it, should be carefully vetted to ensure it is secure. Continuous vigilance is needed to ensure third-party partners are not compromised by attackers.

Apply the Principle of Least Privilege

Least privilege ensures that service accounts only have the minimum access required to complete their tasks. This can be important for IoT and other devices that connect to corporate networks and central cloud services. IoT devices should have only the exact permissions they need for their role, to limit the risk of an exploit, lateral movement, and privilege escalation if a device is compromised.

Deploy Code and Memory Integrity Checks

IoT devices should be able to run autonomous integrity checks, to protect memory and code integrity. For example, a device should be able to determine if its software is out of date or if malicious code is running on the device. Some compliance standards are already adding this requirement (see for example FBI Private Industry Notification PIN # 20220912-001).

Avoid Security by Obscurity

A device or system should remain safe even when malicious actors gain access to the code. Security should not rely on obscurity or secrecy – for example, on the assumption that attackers do not know the underlying implementation, or do not know a certain password or credential. This is because in many cases, or the lifetime of a system, attackers or malicious insiders can gain access to this information.

Devices built with security by design should never use hard-coded credentials. They should also avoid giving authenticated accounts full access to the entire system. Secrecy of credentials becomes harder to maintain over time, and attackers can easily obtain credentials via social engineering.

How We Can Help

‘Security by design’ is an ideal. In practice, many IoT devices were not designed with security in mind. Until now, it was very difficult to “retrofit” security into a non-secure IoT device without completely redesigning it. Sternum is the first solution that can take traditional IoT devices and bring them to the level of security and compliance of secure-by-design development.

Sternum is an IoT security and observability platform. Embedded in the device itself, it provides deterministic security with runtime protection against known and unknown threats; complete observability that provides data about individual devices and the entire device fleet; and anomaly detection powered by AI to provide real-time operational intelligence.

Sternum operates at the bytecode level, making it universally compatible with any IoT device or operating system including RTOS, Linux, OpenWrt, Zephyr, Micirum, and FreeRTOS. It has low overhead of only 1-3%, even on legacy devices.

Here is how Sternum can help you improve IoT security to meet regulatory requirements:

  • Agentless security – integrates directly into firmware, making it a part of the core build This ensures that the solution cannot be externally compromised and leveraged as a point of failure, making the device ‘secure by design’.
  • Automatic mitigation of known and zero-day threats – prevents 96.5% of attacks in benchmark (RIPE) security tests. Its vulnerability-agnostic approach makes it equally effective in dealing with known and zero-day threats. This not only improves security but can also cut security patch management costs by as much as 60%.
  • Supply chain protection – relies on binary instrumentation, making it able to protect all running code. This extends to 3rd party and operating system libraries, effectively preventing all supply chain exploit attempts.
  • Protection of isolated devices – does not rely on external communication to secure devices, making it equally effective for connected and isolated devices.
  • Live attack information with zero false positives – real-time alert system notifies about all blocked attacks, providing – for each – detailed logs and attack path analysis. The deterministic nature of EIV’s integrity checks ensures that all alerts are always valid.
  • Streamlined compliance – helps meet the latest cyber regulations for IoT devices (IEC 62443, FDA, NIST, etc) and the most current FBI recommendations for Internet of Medical Things (IoMT) endpoint protection.

‍Learn more about Sternum IoT security >>  | ‍Learn more about Sternum IoT observability >>

JUMP TO SECTION

Enter data to download case study

By submitting this form, you agree to our Privacy Policy.