List of fundamental security design principles:

1.    Economy of mechanism 
2.    Fail-safe defaults.
3.    Complete mediation 
4.    Open design 
5.    Separation of privilege 
6.    Least privilege 
7.    Least common mechanism 
8.    Psychological acceptability
9.    Isolation

10.   Encapsulation 
11.    Modularity 
12.    Layering 
13.    Least astonishment

Brief Explanations:

1. Economy of mechanism:

Economies of mechanisms dictate that embodied security measures should be as simple, and as small as possible, both in hardware and software. The core principle of designing a simple security mechanism is to avoid unnecessary complexity. 

2. Fail-safe Defaults:

The idea of fail-safe defaults means that access decisions should be driven by permission rather than exclusion. In other words, access is denied by default, and the protection scheme establishes conditions under which access is allowed.

The advantage of this approach is that it shows better failure modes than the alternatives.

3. Complete mediation:

In a complete mediation, every access must check with the access control mechanism. It is not recommended that systems rely on access decisions retrieved from caches.

4. Open design:

An open design for a security mechanism means that the design should be transparent rather than secret. As an example, while encryption keys must be secret, encryption algorithms should be open to public scrutiny.

5. Separation of Privilege:

In the separation of privilege Obtaining access to restricted resources requires multiple privilege attributes.
For example, with multifactor authentication, a user must verify his or her identity with more than one method, such as using a password and a smart card

6. Least privilege:

Each process and every user of the system should operate with the least amount of privileges necessary to accomplish the task.

7. Least common mechanism:

According to the least common mechanism, the design should minimize the functions shared by users while providing mutual security

8. Psychological acceptability:

A psychologically acceptable security system would not interfere with the work of users, while still meeting the requisites of those who authorize access

9. Isolation:

Isolation is a principle that applies in three contexts.
Firstly, public access systems should be separated from critical resources (data, processes, etc.) to prevent disclosure or tampering.
Second, individual users' processes and files should be isolated from one another, unless this is explicitly requested.
Last but not least, security mechanisms should be isolated so that they cannot be accessed.

10. Encapsulation:

 
Encapsulation can be stated as some specific form of isolation centered on object-oriented functionality. 
It means the protection is provided by enclosing the collection of data and procedures in its domain and made only accessible to its internal calls within that system.
And these procedures are called only at designated domain entry points.
 

11. Modularity:

With the use of separate security modules, We aim to provide common security functions and services, such as cryptography, as common modules.

For example, Cryptographic functions are used in a variety of protocols and applications.

The development of a common cryptographic module that can be invoked by a variety of protocols and applications provides a more secure design than implementing these functions in every protocol or application

12. Layering:

Multi-layered protection refers to multiple, overlapping protection approaches that address the people, technology, and operational aspects of information systems.

By using this approach, protection failure at any point in the stack of functions will not expose and affect the whole system.

Multiple barriers are often used between a piece of protected information or service and an opponent. This method is commonly referred to as defense in depth.

13. Least astonishment:

In this principle, a program or user interface should always respond in a way that will be least likely to surprise the user.

For example, authorization mechanisms should be transparent enough to the user that he or she has a clear understanding of how the security goals map to the available security mechanisms.