Principles¶
There are numerous principles and best practices related to security. They span many areas of this material as well, and together they help form a comprehensive approach to the design, development, and deployment of secure systems.
Saltzer and Schroeder principles¶
Although computing looks quite different today than it did in 1975, many general principles still hold. Below are design principles published by Saltzer and Schroeder from that time.
Economy of mechanism: A security measure should be as simple as possible. Simplicity helps in understanding whether the mechanism works as intended. In addition, implementation is simpler, making reliability and correctness easier to verify.
Fail-safe defaults: Security mechanisms should align with the security policy in a positive sense, meaning that they should reject all actions except those explicitly permitted. Mechanisms should not attempt to define and block harmful behaviour, as this approach is prone to error. Harmful behaviour continually evolves. Many modern mechanisms violate this principle, for example antivirus software and intrusion detection systems when they rely on recognising characteristics (so called fingerprints) of malicious activity.
Complete mediation: All operations on all objects in a system should be checked to ensure that they are in accordance with the security policy. This means, for example, verifying that a subject has the rights to perform an intended operation, and is properly identified and authenticated.
Open design: The security of a mechanism should not depend on keeping its design secret. Security often requires that mechanisms can be examined, their flaws corrected, and their correctness verified without compromising their effectiveness. The opposing view, security by obscurity, is more vulnerable because it limits scrutiny and does not eliminate insider threats.
Separation of privilege: Security mechanisms that require authorisation from multiple subjects before an operation (e.g. in banking) are more reliable than those where authorisation from a single party is sufficient. Naturally, requiring multiple participants may reduce availability.
Least privilege: Operations performed by subjects should be carried out with the minimum necessary rights. For example, if only reading information is required, there should be no rights to write or delete it. This principle helps ensure that faulty programs cause as little damage as possible.
Least common mechanism: It is advisable to minimise the sharing of resources and mechanisms between different parties. This principle is important especially in multi-user systems, where shared memory, disk space, or processors may allow confidential information to leak between users.
Psychological acceptability: Security measures should be inherently easy to use, so that users follow them naturally. When a user’s mental model of security goals matches the mechanism or measure used, the likelihood of errors decreases.
NIST principles and overview¶
National Institute of Standards and Technology (NIST) defines security principles for system design. They are organised into broad groups: Security architecture and design, which includes organisations, structures, and interfaces; Security capability and intrinsic behaviours, referring to what security fundamentally is; and Life cycle security, which relates to processes and governance.
Some NIST principles are directly based on the Saltzer and Schroeder principles. Newer principles relate to the complexity of modern systems and emphasise, for example, modular design, layering, compartmentalised dependencies, and developing security alongside other system updates. The principles also recognise that not all parts of even a secure system are equally secure. In such cases, less secure components benefit from a hierarchical trust structure, where failures in some parts do not compromise the entire system. According to the inverse modification threshold principle, the components most critical to security should be the most strongly protected against unauthorised modification and tampering.
The NIST principles also recognise that modern systems are interconnected. Networks should use trusted communication channels. These should implement secure distributed composition, meaning that when two systems implementing the same policy are combined, the combined system should at least maintain that same policy. The principle of self-reliant trustworthiness states that a secure system should maintain its security even if connections to other system components are lost.
The NIST principles define what kinds of mechanisms are acceptable in real, operational systems. In particular, security measures should be cost-effective, high-performing, usable, and acceptable to users. These characteristics aim to ensure that security supports the primary function of systems rather than becoming an end in itself.
In addition to principles, NIST outlines three security architecture strategies. A reference monitor is an abstract security mechanism that enforces the system’s security properties. Defence in depth describes an architecture built from multiple overlapping security measures. (It can also be called layered security.) Isolation is a strategy in which components are physically or logically separated to minimise disturbances or data leakage.
Both NIST and Saltzer and Schroeder emphasise that principles of architecture and security measures are only guidelines, and applying them requires expertise in the problems they address. Deviating from principles does not automatically lead to problems, but such deviations must be recognised to ensure that any resulting issues can be properly mitigated.
Two collections of security principles have been discussed above. The NIST collection is based on several other principle lists and takes into account phenomena that Saltzer and Schroeder had not yet encountered in the 1970s. Below, the principles are structured differently in the form of a concept map. Sources include not only the NIST collection but also the document Cybersecurity Curricula 2017 and two books: Rick E. Smith: Elementary Information Security (2012) and Paul van Oorschot: Computer Security and the Internet (2020). From these, 10 top-level principles have been derived, marked in orange in the map. There are 30 additional principles. The whole is divided into seven categories intended to make the concepts easier to understand and remember (marked in light green). Even the largest category contains only seven principles.
Note on the accessibility of the concept map.
Several of the highest-level principles are collected under the class Apply in your mind…. These mind-sets are such that you must have adopted them into your thinking, but it is still good to be able to identify them by names. One of them consists of three points of view that require mutual balancing: risks, costs and policy. Combining this with adversarial thinking leads to the principle of making sure that the protections are stronger than the attacker. This is obvious but must be remembered especially when choosing cryptography.
Organize your work contains two high-level principles dealing with the life cycle of the system to be designed. In a sense they could be labeled as start and re-start. The risk-cost-policy node, too, can be seen from the administrative point of view.
As a class the mind-set is clearly at the highest level and the administrative class is close to it together with the minimizing class, where the principles are targets to minimize in the design. Actually, the class is named Make smaller, which is a simplified form of “Minimize under the constraints of all other principles”. One of the main principles belongs here: Minimize the attack surface. All other minimizations can be seen as realizations of this. Even minimal surprise reduces situations where attacks are possible. Minimizing the number of shared facilities is originally the well-known principle of “least common mechanism”. Its motivation is that such minimization also reduces opportunities for unintended communication or interference between processes or users. The word facility is used because it is more general than mechanism and may more easily bring into mind also variables and files besides code.
The fourth level is the “architectural” class Use structures, which still has two high-level principles. They could be roughly labeled as depth and width. The layers have a little more to do with depth and the modules with isolation, but they are separate structural aspects.
The only remaining high-level principle belongs to the class Allow less, which is about restrictions or throttling and is mostly very different from Make smaller. The restrictions in Allow less are mainly about access to resources within the system under design, and they stem from the high-level principle Verify before trusting. There are several variations of this principle, refining the original idea of “complete mediation” from Saltzer and Schroeder. The other principles in this class also have several phrasings. We used privileges in two of them to show the similarity in name but to emphasize the difference in meaning. The principle of reluctant allocation is useful in avoiding denial-of-service situations. It could be also viewed as a minimization target, but then it should be rephrased clumsily to something like “Minimize the urge to allocate resources”.
There are two classes without any orange nodes: Do more and Include specials. Both classes deal with adding some properties that serve security and are quite remote from the ordinary functioning of the system. Each class is based on a single source: Include specials is from the Cybersecurity Curricula 2017 and Do more stems from van Oorschot. Include specials – apart from identification – may complicate the functionality quite a lot but all items have a good motivation. Two principles at Do more are extra outside ordinary functions but essential for future (“clean up” and “make logs”). The remaining one, Do cross-checks is extra “inside”, meaning more work during the ordinary functioning. It combines van Oorschot’s two quite detailed principles of independent confirmation and request-response integrity. The former complements Verify before trusting in (less trusted) situations where there is reason to be more doubtful, and the latter reminds that one such situation occurs when you get a response to your request. Cross-check is due to make sure the response matches the request. These ideas are familiar to those who design protocols, but highlighting them may be useful for others.
Finally, it is worth noting that the focus here has been on creating secure systems rather than using them securely. The concepts are also more abstract than practical security mechanisms or best practices such as:
|
|
or even creating and following policies. However, many of these are fairly direct consequences of design principles. And of course, the production environment and working practices of system designers and developers must themselves be secure—precisely through practices such as those listed above.
Latent design conditions (advanced)¶
More and more cyber-physical systems are connected to other systems and the Internet. Such large-scale connections are inherently complex, and the security-critical nature of some systems highlights additional principles. One such principle concerns latent design conditions, which in cyber security arise from earlier decisions made during the construction and modification of systems. These often remain hidden or overlooked and only become visible when certain events or configurations coincide, potentially in undesirable ways—for example, revealing a vulnerability when systems are interconnected. A problem that was previously hidden may now manifest not only in information security but also on the physical side of cyber security, for example as a safety issue. Integrating security at the design stage is not always possible. Therefore, when integrating legacy systems into new networked environments, attention must be paid to latent design conditions and efforts made to mitigate their effects.
Precautionary principle (advanced)¶
The participatory data economy leads to a wide range of products and services, with increasing concerns about privacy and potential misuse of data. This brings the precautionary principle into focus, meaning the assessment of potential harmful effects before technology is widely deployed. Designers must continuously evaluate the security and privacy implications of their choices and extend this analysis throughout the entire lifecycle of systems. This applies to all types of extensively networked systems and infrastructures on which society increasingly depends. The rapidly intensifying discussion in the 2020s around artificial intelligence and its regulation (leading, for example, to the EU AI Act) is a good example. Over long lifecycles, systems tend to gradually evolve in ways that change their use or purpose from what was originally intended (this is known as function creep). The broader societal impacts of such developments should also be assessed. For example, surveillance cameras intended to improve traffic flow and safety might gradually evolve into systems for monitoring people’s movements.