![\"Security](\"https:\/\/binaryterms.com\/wp-content\/uploads\/2020\/05\/Security-Design-Principles.jpg\")
<\/p>\nThe security design principles are considered while designing any security mechanism for a system. These principles are review to develop a secure system which prevents the security flaws and also prevents unwanted access to the system.<\/p>\n
<\/p>\n
Below is the list of fundamental security design principles provided by the National Centres of Academic Excellence in Information Assurance\/Cyber Defence, along with the U.S. National Security Agency and the U.S. Department of Homeland Security.<\/p>\n
This fundamental security principle defines that the security measures implemented in the software and the hardware must be simple and small. This would ease the testers to test the security measures thoroughly.<\/p>\n
If the designed security mechanism is complex then it is likely that the tester would get a chance to exploit the weakness in the design.<\/p>\n
So more the design is simple less are the opportunities for the tester to discover the flaws and more the complex is the design more are the chances to exploit flaws in the design.<\/p>\n
When the security design is simple, it easy to update or modify the design. But when it comes to practice, we cannot consider the economy of a mechanism as the best security design principle. Because there is a continuous demand for adding the security features in both hardware, as well as software.<\/p>\n
Adding security features constantly makes the security design complex. What we can do to obey this principle while designing security mechanism is to eliminate the less important complex feature. This principle says that if any user wants access to any mechanism then whether the access is permitted or denied should be based on authorization rather than elimination.<\/p>\n By default, all the mechanism should have a lack of access and the function of a security mechanism is to identify the condition where the access to the security mechanism should be permitted. This means by default access to all mechanism should be denied, unless any privilege attribute is provided.<\/p>\n This principle denies unauthorized access. If there occurs any mistake while designing the security mechanism which grants access based on permission or authorization. That mechanism fails by simply denying access, which is the safest condition.<\/p>\n If there occurs any mistake while designing the security mechanism which grants access based on exclusion. That mechanism fails by simply granting access which can not be considered as the safest situation.<\/p>\n <\/a><\/p>\n Some systems are designed to operate continuously such systems remember access decision. So, there must be an access control mechanism which would check every access occurring on the system.<\/p>\n This principle says that the system should not trust the access decisions it recovers from the system cache. This particular security design principle says that there must be a mechanism in the system that checks each access through the access control mechanism.<\/p>\n However, this is an exhaustive approach and is rarely considered while designing a security mechanism.<\/p>\n <\/a><\/p>\n This security principle suggests that the security mechanism design should be open to the public. Like in the cryptographic algorithm, the encryption key is kept secret while the encryption algorithm is opened for a public investigation.<\/p>\n This principle is followed by the NIST (National Institute of Standards and Technology) to standardize the algorithms because it helps in worldwide adoption of NIST approved algorithms.<\/p>\n <\/a><\/p>\n This security principle states that whenever a user tries to gain access to a system, the access should not be granted based on a single attribute or condition.<\/p>\n Instead, there must be multiple situations or conditions or attribute which should be verified to grant access to the system. We also term this as a multifactor user authentication as this principle says that multiple techniques must be implemented to authenticate a user.<\/p>\n For example, while conducting online money transfer we require user-id, password, transaction password along with OTP.<\/p>\n <\/a><\/p>\n The least privilege security design principle states that each user should be able to access the system with the least privilege. Only those limited privileges should be assigned to the user which are essential to perform the desired task.<\/p>\n An example of considering and implementing this principle is role-based access control<\/strong>. The role-based designed security mechanism should discover and describe various roles of the users or processes.<\/p>\n Now, the least set of privileges should be assigned to each role which is essential to perform its functions. So, the access control mechanism enables each role only those privileges for which it is authorized. The least set of privileges assigned to each role describes the resources available each role can access.<\/p>\n In this way, unauthentic roles are unable to access the protected resources. Like, the users accessing database has privilege only to retrieve the data they are not authorized to modify the data.<\/p>\n <\/a><\/p>\n Following the least common mechanism, a security design principle there should be minimum common functions to share between the different user. This principle reduces the count of communication paths and therefore further reduces the hardware and software implementation.<\/p>\n Ultimately this principle reduces the threat of unwanted access to the system as it becomes easy to verify if there are some unwanted access to the shared function.<\/p>\n <\/a><\/p>\n This security design principle says that the security mechanisms design to protect the system should not interfere with the working of the user every now and then.<\/p>\n As this would irritate the user ad user may disable this security mechanism on the system. Therefore, it is suggested that the security mechanism should introduce minimum hurdles to the user of the system.<\/p>\n The security mechanism should not be designed such that it becomes difficult for the user to access the resources in the system.<\/p>\n <\/a><\/p>\n This security design principle is considered in three circumstances. The first condition, the system that has critical data, processes or resources must be isolated such that it restricts public access. It can be done in two ways.<\/p>\n The system with critical resources can be isolated in two ways physical and logical isolation. The physical isolation is one where the system with critical information is isolated from the system with public access information.<\/p>\n In logical isolation, the security services layers are established between the public system and the critical systems.<\/p>\n The second isolation condition is that the files or data of one user must be kept isolated with the files or data of another user. Nowadays the new operating system has this functionality.<\/p>\n Each user operating the system have an isolated memory space, process space, file space along with the mechanism to prevent unwanted access.<\/p>\n And the third isolation condition is where the security mechanism must be isolated from such that they are prevented from unwanted access.<\/p>\n <\/a><\/p>\n This security design principle is a form of isolation which is designed on the principle of object-oriented principles. Here the processes of the protected system can only access the data object of the system and these processes can only be invoked from a domain entry point.<\/p>\n <\/a><\/p>\n This security designing principle says that the security mechanism must be generated as separate and protected modules and the security mechanism must be generated using the modular architecture.<\/p>\n This principle helps in updating the security mechanism independently without modifying the entire system.<\/p>\n
\n<\/a><\/p>\n2. Fail-safe Defaults<\/h3>\n
3. Complete Mediation<\/h3>\n
4. Open Design<\/h3>\n
5. Separation of Privilege<\/h3>\n
6. Least Privilege<\/h3>\n
7. Least Common Mechanism<\/h3>\n
8. Psychological Acceptability<\/h3>\n
9. Isolation<\/h3>\n
10. Encapsulation<\/h3>\n
11. Modularity<\/h3>\n