TechLetters Insights. Rules to be enforced in technologies "by design"

As early as in 1973 a Council of Europe document explored data security requirements for hardware and software developers. Specifically, directed to “the manufacturers of hardware and software”, to consider the “technical facilities to be installed, within the limits of the present state of computer technology, in order to guarantee the security of the information”. That is perhaps among the earliest legal considerations of IT technology design, and something regarded today as “state-of-the-art”. Similarly, the need to consider security in the design of systems was also expressed in a 1972. This influential work is worth quoting: “the reason that it is difficult to provide technical security in contemporary computer systems is that the technical foundation (i.e., design) of the hardware and software is totally inadequate to withstand malicious attack … Unless security is designed into a system from its inception, there is little chance that it can be made secure by retrofit“. Is this wisdom adopted 50 years later?

Today we may read about the next breach, a data leak, or a cyberattack, on a daily basis. However, today the technology landscape is very different than in the 1970s. The “rules and standards” aspect significantly evolved. For example, security is considered as a crucial design requirement. At the same time, technology policy is regarded as a topic as serious as other policy or law areas.

By-design approach applied to different realms

What would be the implications of a systematic regulatory approach to technology design? Clearly, a regulatory “by design” approach positions technology as a regulated area. The basic consequence is that the design becomes a matter of compliance. But the devil is in the details. What area is considered? What are the requirements? What is the actual meaning of the by-design approach with respect to the considered realm?

Concerning the potential ‘subjects’ of a by-design approach, this assessment started by mentioning security by design (SbD) – by far the first and the longest developed approach of the kind. However it is important to note that the by-design approach may be applied to a variety of legal or moral dimensions. The approach can be considered for areas such as security, privacy, human rights, ethics, transparency, but also beyond-IT, to safety of machinery, or safety of products. One may imagine others. Synergistic links are also possible, for example the considerations of ethics, fairness, or human rights in artificial intelligence.

Some of the by-design approaches may apply to moral dimensions or concepts (i.e. ethics, fairness, etc.), which may necessitate referring to some preconceived sets of values. Hence the considerations of values-sensitive design, values in design, consideration of values on the design phase for technology systems. Ultimately in some cases, by-design approach of ingraining certain values (like those motivated with human rights, either grounded in European law or beyond) could have the potential of advancing human rights. However, this cannot be understood in an overly simplistic manner because moral and social dimension, and technologies are distinct.

Data Protection by Design

Data protection by design (DPbD) as defined in the General Data Protection Regulation is of special importance. This by-design approach is formally codified in the laws. Based on this mandate, the European Data Protection Board issued guidelines as to how to understand the DPbD considerations and needs in more practical ways, keeping in mind compliance. GDPR DPbD considers that “appropriate measures” must be applied to ensure the “effective implementation of the data protection principles”; the principles come from the GDPR. The guidelines specify that: “technical and organizational measures and necessary safeguards can be understood in a broad sense as any method or means that a controller may employ in the processing. Being appropriate means that the measures and necessary safeguards should be suited to achieve the intended purpose, i.e. they must implement the data protection principles effectively”. In other words, the EDPB instructs that the DPbD is to be translated into practice (“effectively”). The guidelines also clarify that: “technical or organisational measure and safeguard can be anything from the use of advanced technical solutions to the basic training of personnel. Examples that may be suitable, depending on the context and risks”. Again, this highlights that the GDPR DPbD should be operationalised and realised in practice. However, it should be noted that the GDPR “does not require the implementation of any specific technical and organizational measures”. It is the data controller who is to decide about the actual, deployed measures.

An integral component of DPbD is the data protection impact assessment (DPIA) process that can support DPbD. This is clearly communicated by the EDPB. DPbD and DPIA can be considered holistically, including on the architectural design layer of the system. Specifically, the two can “reinforce each other”. DPIA can contribute to reviewing the quality of DPbD.

Security by design

The NIS directive considers requirements that would contribute to the security design of products or services, stipulating how the elements of “security and privacy by design” may be understood, mentioning that “in accordance with the principles of security and privacy by default and by design…”, “end-to-end encryption, should be promoted and, where necessary, should be mandatory”. The proposal therefore considers that end-to-end encryption may be viewed as an integral (and precise) realisation or component of security/privacy by design as applied to communication security.

Furthermore, SbD is explicitly included in the EU Cybersecurity Act, which considers that security should be incorporated “at the earliest stages of design and development”, and that “security should be ensured throughout the lifetime of the ICT product, ICT service or ICT process by design and development processes”. Such content is only included in the recitals (i.e. not the legally binding part). No articles of the Act refer to SbD, except when it comes to setting up a certification scheme that would include the requirement of “ICT products, ICT services and ICT processes are secure by default and by design”.

AI design considerations

The EU Artificial Intelligence Act explicitly considers design requirements for AI systems, specifically by stating that “high-risk AI systems should be designed and developed…”. Other similar expressions unambiguously indicate that AI must be designed with certain preconditioned standards. For example, risks must be properly identified and mitigated by the design, support for accountability (logging) must be built-in, as well as for transparency, human oversight, accuracy, or cybersecurity.

It is imaginable that practical AI by-design considerations could be implemented using similar streamlining like in the case of DPbD or SbD. That means: legal, technical, and organisational measures. Obviously this would require resources, such as staffing.

Additional considerations of the by-design approach

To properly apply a by-design strategy requires a number of phases. The most high-level view may involve the identification of needs or risks in a particular application, using the particular approach (i.e. security, privacy, human rights, etc.). The by-design approach can be applied to many areas. For example, security by design principles and considerations can be identified for the web, Internet of Things, machine learning, cloud computing, or automotive settings. Human rights design considerations motivated by e.g. international laws, can likewise be applied to networking protocols. Similar considerations could be devised for data protection, etc.

Regulation can be viewed as “technology of governance”. Clearly, once design requirements are mandated by law they become a matter of compliance that must be translated into actual technical/engineering requirements. While direct translation may encounter challenges, lawmakers must ensure that any design requirements remain flexible and adaptable to guarantee being future-proof. In this sense the approach pursued by the GDPR seems to be especially well apt. Specifically, it refers to the “state of the art”, which implies measures being current, and not stipulated by law statically. Indeed, direct stipulation of technical details would be counterproductive. For example, a security-by-design regulation statically designating password security requirements would be nonoptimal, as the state-of-the-art recommendations may change. In the past, the thinking in this case included requirements such as the minimum password length, alphanumeric character composition, and the need for frequent password changes. Such requirements evolved. Passwords still must be created with care, but the requirement of frequent changes is today considered counterproductive. The advice is reversed to: not changing a good password regularly, unless this is justified by e.g. a breach. This example shows that a potential legal requirement of specific password needs could become obsolete with respect to domain expertise. Instead, if the requirements are suitably general, and ‘pluggable’ via external interpretations (like opinions of the EDPB or the ENISA), the approach is more flexible. In the vein of the password example – detailed requirements for “good” password policy were never issued on the level of EU regulations. In 2009 ENISA advised a regular password change policy. This advice was updated in 2020 to only change the passwords if they are found to be breached. Such a change therefore did not require a cumbersome full legislative initiative that would take years.

Advantages of by-design

Among the evident advantages of the by-design approach is the inclusion of thinking about the risks and the mitigations in the early phases of development. By placing the consideration in the design phase, it is possible to avoid future risks or breaches, identify risks early and address them prior to the product reaching the consumer. By-design approaches tend not to be strictly defined. This elasticity is a strength as it allows an adaptive approach, for example conformance to the state of the art in technology. Although in all fairness, this point may also be seen as a type of weakness: making it more difficult to comply with the obligations, when it is unclear what are the legal requirements to be enforced. It is difficult to agree with such a view. Enforcement is based on something concrete. The enforcement of DPbD/SbD demonstrates this.

In 2022, the French Data Protection Authority issued fines for data protection breaches in design of systems. In one case, a technical inadequacy has been identified in the design that accepted weak passwords (of length of six characters; in 2022, inadequate by any standard). In the second case a data protection infringement of article 32 (security of processing; which may be considered as elements of SbD, but could also be read in light of DPbD) was identified in the use of an obsolete hashing function MD5, and that the password hashes were not ‘salted’. Those points clearly refer to concrete technological details. Even if SbD/DPbD are not thoroughly referenced, it may be undeniably concluded that design conformance to the latest security guidance or standards is mandatory, and that it will be subject of enforcement. Clearly, such a conclusion would implicate thinking in by-design ways. If only due to the fact that the infringements referred, in practical ways, to the actual technical designs of the systems. By-design approaches can be applied both to technology and policies, in fact the two can reinforce each others, but to be effective, the policies and legal requirements must be able to be translated to practise; this is possible in the case of e.g. DPbD, which aside from SbD is likely the most mature such an approach. These two practical enforcement cases highlight this.

Of a particularly advantageous point, inclusion of security/privacy in the design phase can form a competitive advantage. Furthermore, regulation of technology design may help upholding fair market competition rules. Can DPbD contribute to this? Data protection requirements for market participants are sometimes presented as making “an equal level playing field for every provider”, a fact often voiced by supporters of ePrivacy Regulation. Finally, a proper approach in technology design regulations may contribute to building consumer and public confidence in the technologies, improving public trust. That is especially important in a situation of rapid technological change (like in IT). Consumers may be more inclined to adopt new solutions if they are convinced that the risks are tackled. That is the essence of a by-design approach.

However, the potential disadvantages need also be considered.

Disadvantages of by-design

Among the biggest disadvantages of a by-design is that such approaches are often not precisely defined. This point on the need for clarity was already addressed previously. There may arise issues of other nature.

Concretely, from time to time lawmakers consider enacting regulations of security systems such as encryption, like, the regulatory desire to access decryption keys, which potentially could be deployed technically. Such requirements would undoubtedly impact the design of security of systems, in particular here – encryption. However, such interference may result in the actual weakening of the security level . So while it would be a regulatory design requirement, for example motivated with child safety considerations, the net result of mandating such design weakness may be far from evident, and could back-fire.

The previous example stresses that many aspects must be considered. Regulations mandating design requirements must be well crafted.

A by-design regulatory vehicle may introduce conceptual and practical obstacles of another nature. For example, considering the realities of software engineering, the differences between the classic waterfall (i.e. fixed phases of design-development-deploy done in a sequence) and the more modern agile (i.e. continuous development in short bursts) paradigm are on a fundamental layer. Those conceptual and practical differences are important but such details may be lost from sight in settings grounded in thinking focused on simplistic aspects where for example it is “assumed” that only one “general” development model exists, which would result in designing an approach having in mind specific, certain modes, only – like, only the waterfall approach. Meanwhile, the agile process considers achieving a minimum viable product early, which may challenge a way of thinking that any deliverable product should be “complete”. That is: with all the core functions, designed and implemented, with risks considered and mitigated. This example highlights that standards and good practices must keep pace with the realities. Likewise, regulations should be sufficiently general to allow flexibility.

In practice, this is a challenge to technologies, rather than laws. The issue can be overcome, as demonstrated in many realms from finance to medical settings. Continuous development and rolling releases are a matter well known, for example in standards setting organisations like the W3C or the IETF. Appropriate security and privacy review processes (a critical aspect of security/privacy) has been developed over the years, and now an adequate review process is in place.

In business settings, consideration of costs is critical. So a potential disadvantage of regulatory technology “prescriptions” may be the related compliance costs. The need to deploy solutions and appropriate technical choices incurs costs, if only due to the needs of setting up devoted teams composed from sufficient numbers of people, or contracting external consultants. That said, smart regulators could devise ways of offsetting costs. For example, by incentivising the paradigm changes, as it is fundamentally a cost-benefit calculus for firms.

Summary

In the case of technology there is also another important, holistic, issue. Technologies (especially IT) may develop rapidly, especially as compared to the pace of policy and regulatory development. Pure principled approach, such as publishing reports, guidelines, or advisories is very informative. However, to be effective there must be a way to translate principles into practice.

To achieve actionable results, the principles considered must be backed by appropriate laws. Better still if the laws mandate a flexible approach to technology design. This is, in essence, the by-design approach. By mandating that problems and risks must be identified and mitigated in the design process of a product, service, or a feature, and that good standards should be designed from the ground up, it is possible to arrive at a better value for the economy, and qualities for the consumer.