Standards development can take time. But depending on the standardization process, there are several potential components that can contribute to the quality and trustworthiness of a security standard, including: a transparent process, different stakeholders, domain competence, a critical mass of security experts, iterations of reviews, implementation feedback, formal verifications, and an open forum for discussion.
When it comes to security solutions, the default should always be to follow best common practices and reuse commonly agreed, tested and verified solutions. However, new use cases, technologies and threats call for suitable security solutions. These new solutions need to be carefully analyzed and verified to be compliant with the relevant security requirements. This is one area where the standardization process can be helpful. The process of developing open standards provides additional benefits in the case of security standards, which is the topic of this blog post.
In a previous blog post, we looked at the importance of standardization to achieve interoperable systems and services. In this post, we focus on standardization of security technologies as a building block in creating trustworthy interactions within and between systems.
“Standardized security components are therefore necessary building blocks in a Smart Home system, which is not just a collection of standalone home appliances from different providers”.
The many benefits of standardization in terms of interoperability and modularity of hardware and software extends also to security components. This includes security protocols and enablers that allow products and services from different manufacturers and providers to communicate and interact in a secure way. Standardized security components are therefore necessary building blocks in a Smart Home system, which is not just a collection of standalone home appliances from different providers.
Standardization is a collaborative effort, where contributions from a community are reviewed and analyzed, discussed, and adapted based on the community decision. While different stakeholders may compete in different ways inside and outside standardization, there is a common interest among those that make use of a standard to ensure that it complies with the relevant security and privacy requirements of the service it is used in.
In non-security standardization, the interaction between functional entities in the technical solution is often built on the implicit assumption of collaboration between the involved parties and devices; after all, they are intended to interact for a common purpose. The security mindset, however, is the complete opposite: the development of security components is based on the assumption of an adversary, a party that intentionally wants to perform malicious actions on the system, against which there is a need to prevent or at least mitigate.
Therefore, the possible actions allowed by a security standard specification must be scrutinized as potential threats to security or privacy by taking the position of the “devil’s advocate”. Different possibilities are analyzed, also those far from normal operations, to try to produce cases where the security requirements are violated. This often requires a large effort, with special competences in the technology domain as well as in security.
A standard specification is most commonly a paper product. In order to turn this specification into something useful, the specification needs to be implemented. In this process, many properties of the specification will fall out, for example, if it is not sufficiently clear on the details, if there are missing parts, etc. Ideally, more than one person should implement and some tests being made to verify that they all came to the same results, e.g., by comparing output or performing some sort of interoperability test. Since many security vulnerabilities are the result of bugs or implementation errors, feedback from implementations is very valuable input to improve the specification.
“This is a long-term investment for participating companies and research institutes”.
Some SDOs also encourage formal verification for specifications which are difficult to analyze by hand. The use of mathematical models and computer-based tools for proving certain properties can be an important part of the analysis. This may even involve a formal verification of software implementations, such that the same piece of code implementing the standard that was used in the verification proof can also be used in products.
These examples of analysis match well with the development of open standards where the specification is available for researchers to review and comment on the design, and this also gives more confidence in the specification. Defining new security standards is thus a process that can take long time – a number of years is not uncommon – but this is in general beneficial to the quality of the result. This is a long-term investment for participating companies and research institutes.
It is important to note that the security posture of a deployed service cannot be realized through standardization alone. Just ensuring that a particular standard implementation complies with a specific use of an application requires a separate assurance process. On top of this, there are several different measures that need to be taken in protecting a system/network deployment. However, well analyzed, open global security standards are an important foundation in creating a secure system.
About the writers
Göran Selander is a Principal Researcher in the research area Security at Ericsson Research. His research interests are in the field of security for cyber-physical systems. Together with other participants in the SIFIS-Home project he is active in the development of lightweight security standards in the Internet Engineering Task Force (IETF).
Marco Tiloca is a Senior Researcher in the Cybersecurity Unit of RISE Research Institutes of Sweden. His research interests are in the field of network and communication security. In the SIFIS-Home project, he is leading the Work Package “Network and System Security”. Together with other project participants, he is active in the development of lightweight security standards in the Internet Engineering Task Force (IETF), where he is acting as Chair of the CoRE Working Group.