Two topics that repeatedly come up when discussing the security of embedded devices are regulation and standardization. The rise of the Internet of Things, which is driving new levels of connectivity across a greater array of previously non-connected devices, has directed a lot of public attention to this topic. Many highly-publicized vulnerabilities and attacks have showed us how connected devices can be used to cause harm not just to the network they are on, but to the Internet in general, or to real-world physical infrastructure and people. This has caused regulators to turn their attention to this area, resulting in an active IoT regulation initiatives across the globe. Private and public standard organizations are also engaged in the effort, and are trying different approaches in order to close the IoT security gap.
While these initiatives are critical, the companies that take part in the IoT ecosystem are increasingly challenged to keep track of the requirements in the relevant standards and regulations, which vary greatly and are constantly evolving. To our knowledge, no comprehensive analysis exists of IoT cybersecurity standards and regulations, at least not something that’s publicly available. We are aware of efforts by government organizations to put together surveys of the relevant documents and publications, and there is a useful report by IoTSF that we mention below.
In this article, we attempt to provide a systematic view of the landscape, and while the examples we provide are only the tip of the proverbial iceberg, we try to establish the structural principles behind it. We also review the ways that automated tools can help achieve compliance.
Regulations vs. standards
To begin with, what's the difference between regulations and standards?
Regulation is normally imposed on vendors by governments. Which regulation is applicable depends on the territory and the industry where the vendor operates. Regulation can carry penalties - from financial fines to personal responsibility, to mandatory participation of the company in a cybersecurity program, as we'll see in some examples later. Regulation is typically poor on technical detail - it tends to leave that to the technical standards which it references.
Standards are developed by varied bodies including private companies, industry alliances, or government organizations. They are not mandatory in themselves but can be enforced through regulation. For example, medical devices sold in any given state are typically subject to standards according to the regulation in that state. Standards can also be mandated by customers – for example, as part of a tender’s requirements. In other cases, compliance to a standard is on an opt-in basis, with vendors using compliance to a standard as a stamp of quality and as a means to differentiate themselves from competitors.
Compliance with relevant regulations may be a necessary condition for participation in some markets (as in the medical or automotive industries). In other cases, regulation is not necessary to enter the market, but financial penalties can apply if the vendor is found in violation. Either way, vendors carry the responsibility for identifying which regulations and standards apply to their products or markets, and this can be a difficult task. As a starting point, we recommend an excellent resource that was put together by the IoT Security Foundation (IoTSF)—this report describes some of the most prominent regulators in the IoT cybersecurity field. It also provides a handy list of penalties that major regulators can impose.
In general, cybersecurity regulation is codified by law, which is created by local governments and legislators. Because of that, it takes a long time to develop, and has a slow update cycle. Because its subject matter tends to evolve far more quickly, regulation tends to avoid going into technical details, relegating that to technical standards.
Beyond territorial and industry distinctions, there are some regulations that address specific topics of concern. For example, there are safety, privacy, and child protection regulations. Each type of regulation can have a cybersecurity angle.
Below, we review some examples of prominent embedded device cybersecurity regulations.
The US Food and Drug Administration (FDA) is involved in the regulation of cybersecurity in medical devices. It published guidance for sellers of medical devices and software which is used for treatment purposes. The regulation is made binding by a combination of US federal and state laws.
From a threat analysis perspective, the FDA is mostly concerned with patient harm, and can overlook security issues in the device if they are unlikely to result in someone getting hurt. Its guidance concerns the security process, including documentation, incident handling, and procedures for suppliers to notify their customers (and the FDA itself) about security incidents. The guidance includes one major technical aspect: the need to support ongoing software updates on medical devices.
The Federal Trade Commission is responsible for ensuring fair trade practices in the US. Its involvement in cybersecurity is not direct, though it has made an impact on cybersecurity enforcement due to its mandate to prosecute companies which use misleading marketing. It so happens that some embedded device companies did just that, marketing their devices as highly secure while actually overlooking basic security measures, such as changing the default passwords. The FTC has stepped in and sued several high-profile embedded device manufacturers in the past, including TRENDnet, D-Link, Asus, and recently Tapplock.
When suing a manufacturer, the FTC may seek financial penalties, but its main goals—which are usually enforced through a court settlement—are for the company to stop their misleading marketing practices, provide their customers with technical support, and establish a cybersecurity program, which includes a periodic audit by an independent company. While those steps are definitely beneficial to the security of the manufacturer's product, it's easy to see that they also incur considerable costs.
In California, Senate Bill 327 recently came into effect, making some headlines. This may be the first cybersecurity regulation for regular consumer products in the US. The bill itself is very short and easy to read; we've analyzed it in a previous blog entry. It essentially contains two alternative security measures: the requirement for unique passwords on devices which support remote authentication, or a mechanism to reset the password on first use.
More cybersecurity regulation that applies to embedded devices is expected to mature over the next few years, as regulators are concerned about the state of IoT cybersecurity.
- The European Union has the EU Cybersecurity Act, which is expected to mandate cyber-security measures while using ENISA standards for the technical details.
- Similarly, in the US, the IoT Cybersecurity Improvement Act is expected to put cyber-security requirements into effect while using NIST standards for the technical parts.
- In the UK, the Code of Practice for Consumer IoT Security is coming into effect; this is a regulatory document with a brief security standard describing 13 foundational measures, including procedural and technical steps. This is expected to be combined with a labelling scheme, which the vendors would have to apply to provide transparency to customers.
- In the automotive field, the United Nations Economic Commission for Europe (UNECE) World Forum for Harmonization of Vehicle Regulations (WP.29) document is expected to create a common cybersecurity standard, mostly for non-US vendors.
- In the medical field, the International Medical Device Regulators Forum (IMDRF) is working on a document called "Principles and Practices for Medical Device Cybersecurity", which is similar in structure to the FDA guidance but is aimed for worldwide use.
Standards are created by private organizations (such as UL or ISA), industry alliances and organizations (such as OWASP or IoTSF), or government organizations (such as NIST or ENISA). The detail levels vary widely between standards: some contain just a dozen of high-level, general requirements, while others contain hundreds of highly detailed requirements.
Like regulations, standards can apply to a specific industry vertical (such as automotive, medical, consumer or industrial); but standards can also apply to a technology stack or a specific protocol such as Bluetooth or TLS.
We cannot provide a comprehensive review of the standardization landscape. The Vdoo platform contains explicit mappings of security requirements for around 40 standards we consider the most influential and immediately pressing, enabling automated compliance validation for the mapped requirements. We actively track over 60 additional cybersecurity standards that apply generally to embedded devices, and dozens of other relevant standards that are limited to specific industry verticals such as medical, industrial, automotive and others.
Below, we discuss some of the key standards in more detail.
The FIPS 140-2, "Security Requirements for Cryptographic Modules" is an old standard, officially last published in 2002. However, the standard has implementation guidance documents which have changed over time, with updates up to several times a year.
This standard was meant for cryptographic modules, but over its lifespan it has become widely influential in the entire embedded industry and even outside it, as a yardstick for proper cryptography and security design. This is a also a US standard, enforced only on government purchases, but it has been influential worldwide, being translated to Japanese and becoming adopted into the ISO/IEC 19790 and 24759 documents, which have since evolved independently, and are now the basis for FIPS 140-3.
The standard is technically detailed, coming in at around 300 normative requirements, and many hundreds of pages if you count its appendices (and without including a plethora of other NIST documents it cites). Certification for FIPS 140-2 is an explicit and formal process, with specially certified laboratories used for verification. All certified modules are published on the program website.
The standard is now superseded by FIPS 140-3, with certification continuing until September 2021.
This standard was published in 2020 and replaces the previous FIPS-140-2. It is now based on two ISO/IEC documents, ISO/IEC 19790:2012 and ISO/IEC 24759:2017. Officially this standard applies in the US and Canada to cryptographic modules purchased by the US government, but we can expect it to be widely influential just like its predecessor.
The differences from FIPS 140-2 can be summarized as a list of technical changes. We will not go into it here, since there are many summaries on the Internet. Procedurally, the major change is the use of ISO/IEC standards, which have to be acquired separately.
NIST SP 800-171
We'll mention this as another important NIST standard. It was published in February 2020, with previous versions in 2015 and 2016. This is also originally a US only standard, but it is getting traction around the world. While originally aimed at enterprise organizations deploying general purpose PCs, connected devices, and mobile phones, this standard is influential in the embedded industry.
The standard's detail level is medium; it addresses procedural as well as technical issues with over a hundred requirements each weighing in at a few paragraphs. For further detail, this document refers to multiple NIST standards by relevant area.
The standard's importance comes from its influence on procurement. Compliance is required by the US Department of Defense, and this applies to contractors and sub-contractors, recursively affecting the entire supply chain.
The 62443 is an important and complex family of related standards. We will reserve a full discussion of it for a future blog entry, and only touch on the basics here for comparison with other standards.
Separate versions of this standard are promoted by the commercial ISASecure organization and another by the International Electrotechnical Commission (IEC). The standards are aimed at Industrial Automation and Control Systems (IACS). The most important documents are IEC 62443-4-1, "Secure product development lifecycle requirements", 62443-4-2, "Technical security requirements for IACS components", and 62443-3-3, "System security requirements and security levels", and their ISA counterparts.
These documents roughly divide the requirements, of which there are several hundreds of varying detail, into three types: procedural, device-level, and whole system-level (i.e. a network of interconnected devices). Other related documents contain auxiliary materials. Certification for the standards is provided by a worldwide network of laboratories. Compliance is not enforced by regulation, to the best of our knowledge, but may be required in specific markets.
Underwriters Laboratories (UL) are a US-based company dealing with certification for a great variety of technical subjects. The 2900 family of standards is one of its cybersecurity efforts, specifically aimed at network-connected products. The family includes a base standard (2900-1) and several derivatives by topic: industrial (2900-2-2), medical (2900-2-3), and one for cryptographic modules (2900-3-1).
The standards are divided about evenly between technical and procedural requirements, with a low to medium level of detail. So far there is no enforcement for compliance that we know about; however, the UL 2900-1 standard is recognized by US FDA as a cybersecurity standard which can be used to achieve compliance to FDA guidance for medical devices.
For certification to this standard, vendors have to approach one UL's worldwide network of certification laboratories.
Challenges with compliance
Compliance with standards is a difficult subject. Here are some of the challenges that companies seeking compliance typically face:
- Understanding the compliance types: There are several types of compliance with varying levels of rigor and proof.
Some standards offer official self-certification—typically, this works by the standards organization offering a questionnaire on its website that a vendor can fill and publish, or just offer it to customers as part of their sales process.
Yet other standards have an official certification process, where the standards organization, a laboratory specially certified for that task, or an independent organization such as a pen-testing team goes over the product and creates a certificate of compliance.
Some standards require official certification, yet it's common practice for vendors to simply declare themselves "compliant" because they used a standard as part of their design or product definition, without passing official certification; for examples, many embedded vendors claim to use "NIST-compliant cryptography" without providing the details. This is usually completely unofficial.
- Choosing the relevant standards: This task can be non-trivial. As we've mentioned before, in some cases there isn't a choice: compliance to a standard may be mandated by regulation, it can a condition to entry in some markets, or it may be demanded by customers. Otherwise, standards are simply used by different vendors to distinguish themselves when competing in a market; in such a case, the vendor should consider the costs and benefits of compliance to each of the standards that come into play in the market.
- Achieving certification: With most standards, certification is a lengthy and costly process. The vendor typically needs to get help from an experienced external consultant or a certification laboratory who walk them through the process. Even the very first stage of assessing the overall effort and costs of the compliance process—the creation of the initial gap report—can take considerable time and effort. The vendor has to prepare documentation, examine and possibly change their organizational processes, and make adjust their product's software (and often hardware) in order to ensure compliance. Then, the actual certification process can still take time, with multiple iterations of Q&A and testing between the vendor and the lab. And once the vendor is done and receives the prized certificate, they still have to go through additional work to maintain that certificate—as it expires in several years, in many cases—or repeat certification, every time they create a new version or a derivative product. It's unsurprising that compliance is considered a costly and exhausting process.
Automating the compliance process
We've reviewed some of the benefits of using automated tools for cybersecurity verification in general, and for compliance to standards in particular, in a previous blog entry. Here, we'll focus on automating compliance to standards in fairly typical setting for larger vendors—where compliance with multiple standards, and over a wide range of products or even product lines, is necessary.
First of all, companies should adopt a consistent set of security requirements for their internal use. These requirements should be written in uniform language, and understandable to stakeholders in the company, such as the engineering teams who are expected to implement them. This can be challenging, because as stated above, the standards themselves use a variety of different detail levels and terminology. Some requirements appear in similar form across multiple standards, but some can even be contradictory. To resolve this, we recommend creating an internal database of security requirements. After choosing the relevant standards, break them into individual requirements, and then translate them to internal security requirements in a language suitable for engineering teams. Maintain an explicit mapping or reference to the original requirements to let you trace requirements back to the original standard and vice-versa.
Now, automation can be applied to the unified set of requirements. A one-time investment is needed to write automated testing or scanning code for every requirement that can be tested technically (some requirements refer to procedure and documentation and do not lend themselves well to automation). However, once this investment is complete, the scanners can be reused as needed across multiple product lines and multiple versions. Once the scanners run on a device's code or firmware image, the scanner output (positive, negative or N/A results) can be used as evidence for compliance.
This can create a gap report for a given standard in a matter of minutes, when applied to any new device or firmware version. For optimal gain, automated scanning should be part of the CI/CD (Continuous Integration / Continuous Development) workflow, enabling ongoing compliance status tracking across versions. This provides immediate information about whether a fix helps solve a security issue, or when a change introduces a security regression. Compare this to the manual security verification process, where establishing the security status of a new version of a device can take days or weeks do properly.
These ideas can help streamline the compliance process across a vendor's range of products and devices, reducing costs and shortening the product time-to-market. The Vdoo platform helps device vendors to implement these concepts, with a consistent and easy-to-understand set of requirements mapped to the compliance requirements of over 40 major standards, with more coming.