**Lecture 07 Chapter 01 section 1.4 Fundamental Security Design Principles — Transcript & Summary | SozAI** Source: https://sozai.app/transcript/lecture-07-fundamental-security-design-principles/ Lecture on fundamental security design principles: economy of mechanism, fail-safe defaults, complete mediation, open design, least privilege and more, with examples. ## Key Takeaways - Simplicity and small size reduce vulnerabilities and maintenance cost. - Default-deny with explicit permission is safer than default-allow. - Security should rely on secret keys, not secret algorithms, and be re-verified on every access. - Least privilege and separation of privileges limit the damage of any single compromise. ## What the video covers - Security systems cannot eliminate all vulnerabilities, so design principles guide building strong protection. - The lecture covers 13 fundamental principles, starting with Economy of Mechanism and ending with Least Privilege. - Economy of Mechanism: keep systems simple and small, which eases testing, verification and maintenance and reduces hidden weaknesses. - Fail-safe Defaults: deny access by default and permit only explicitly authorized entities, so failures reject rather than expose data. - Complete Mediation: check every access operation against the current control mechanism, avoiding cached or stale authorization decisions. - Open Design: keep security mechanism designs public for scrutiny, keeping only encryption keys secret (e.g., RSA, DES, AES). - Separation of Privileges: assign distinct privileges to each action or component, exemplified by multi-factor authentication. - Least Privilege: give users and processes only the minimum privileges needed, granted temporally and withdrawn after the task. - Psychological Acceptability: security mechanisms should be acceptable to users so they are not bypassed. - Compartmentalization and boundaries: separate processes and files, distinguishing internal and external boundaries, e.g., restricting financial software to relevant staff. ## Chapters 1. 00:00 Introduction and the need for design principles 2. 01:30 Economy of Mechanism 3. 03:00 Fail-safe Defaults 4. 05:00 Complete Mediation 5. 07:00 Open Design 6. 09:00 Separation of Privileges and Least Privilege 7. 11:00 Psychological Acceptability and Compartmentalization 8. 16:00 Modularity and Layered Protection Answers ## Questions about this video Why does the lecture prefer Economy of Mechanism? Simple, small systems are cheaper, easier to test and verify, less likely to contain exploitable vulnerabilities, and easier to maintain. Complexity creates opportunities for hidden weaknesses and attackers. What is the difference between default-deny and default-allow in the lecture? Default-deny (fail-safe defaults) rejects everyone except explicitly authorized users, so failures block access and are easy to notice. Default-allow lets everyone in except those explicitly blocked, so failures can silently expose data. Why is open design recommended for encryption algorithms? Public scrutiny lets specialists find and report weaknesses, which strengthens the algorithm. Security then rests on secret keys, as with open algorithms like RSA, DES and AES. ## Full Transcript — Download SRT & Markdown 00:01 Speaker A Welcome to another lecture in the Computer and Network Security course. We previously discussed the functional requirements for any security system. 00:13 Speaker A Today, we will talk about the fundamental security design principles. There is no possibility or probability that I can build a system capable of systematically eliminating all vulnerabilities and fully preventing unauthorized actions. Therefore, we are forced to agree on some concepts or 00:37 Speaker A principles. That guide and direct us in building a strong protection system. We have 13 principles. Starting from Economy of Mechanism, Fail-safe Defaults, up to Least Privilege. 00:53 Speaker A Alright, let's start with Economy of Mechanism. Economy means thrift. The meaning of the word economy is that my system should be less costly. Lower cost means it must be simple. It must be small. So, if the initial system I 01:06 Speaker A built was simple and small. What does that lead me to? It leads me to be easier to test. Easier or more accurate in. The verification, less likely to contain exploitable vulnerabilities. 01:20 Speaker A And easier in terms of maintenance. Exactly. Well, it tells me about complexity. If I built a security system but it's complex, what happens? 01:29 Speaker A It says it gives additional opportunities for hidden weaknesses to appear. It gives additional opportunities for eavesdroppers, or attackers, to discover vulnerabilities and exploit them. And it also makes the process, or my maintenance requirements , very high. Exactly. My maintenance 01:48 Speaker A requirements are very high. Well, it tells me. We have something to keep in mind. That we always have a continuous and constant demand. For new hardware features and new software features. If we hadn't taken the Economy of Mechanism into consideration. Our 02:08 Speaker A system would become a very large system . And very complex. Therefore, if I had taken the Economy of Mechanism into account. This would reduce unnecessary complexity. Alright, Fail-safe Defaults . Safe defaults upon failure, it says. 02:27 Speaker A In safe defaults upon failure, I assume that everyone is denied access to data except those I say yes to. Take the data, okay. Permission rather than exclusion. Everyone is prohibited except for those I permit. Not the opposite. Alright, what does this do 02:44 Speaker A for us? It does the following for us. If I said everyone is prohibited, except for those I explicitly authorize . This means if there is a design flaw, what will happen? Simply put, it will reject. The authorization, a rejection 03:00 Speaker A of authorization. Meaning everyone is prohibited from entering the system. Consequently, it is easier to detect. 03:06 Speaker A And our system remains secure. But what if I did the opposite? That everyone is allowed, except for those I explicitly say do not enter. If a failure occurs in the system now, what will happen? 03:20 Speaker A Those I have rejected will be able to enter. Will I discover this? I might discover it, but at a very late time, okay. Because the matter will go unnoticed. Why the matter? It goes unnoticed, because the people with 03:32 Speaker A system access who I would learn about any flaw through are already able to enter the system. So they won't report the failure, and thus this will go unnoticed, leaving our security at risk . Okay, complete mediation, it is not 03:49 Speaker A reliable. What is complete mediation exactly? It tells me every system access operation must be checked based on our current control mechanism. Every login operation must be checked against the latest version of the control mechanism. Therefore, my system should 04:05 Speaker A not rely on access decisions that were fetched in advance or cached—meaning cached an hour ago, five minutes ago, or a day ago. Not a day ago; for every operation, I must re-verify the existing access account to see if the 04:26 Speaker A person has the authorization or not. No shortcuts, no cache, always reload and check. Is it clear why? Because simply put, if I revoked someone's access today and I wasn't using complete mediation, it simply wouldn't happen. 04:43 Speaker A Tomorrow, if they come to their page, that they logged into a day before, they would still have the authorization . And what would they be able to do? 04:52 Speaker A They would be able to perform actions they are no longer permitted to do. Alright. It says every time a user accesses a field, file, record, or any data in the database, what must the system do? Check their access control. 05:11 Speaker A Exactly. However, it says that in real life, sometimes, if a person opens a file, which is a normal file and not a database, what happens to the check? It only happens upon opening. Well, after that, it says that usually, no check 05:27 Speaker A occurs. Overall, complete mediation, if applied to every movement on the device , can be a resource-intensive approach. 05:37 Speaker A Consequently, it is not always used, or it is not used in all cases. Open design, an open design. What does that mean? It means that any security mechanism design we have must be open, not secret. What does that mean? If I 05:55 Speaker A designed an encryption algorithm, should I keep my algorithm open-source or closed-source? It tells me to keep it open-source for the general public, or for specialists. So that anyone can go in and look at my algorithm. They might discover a weak point and report 06:15 Speaker A it to me. And thus I can strengthen the points, strengthening my algorithm. For example, RSA is open-source, DES is open-source, AES is open-source. 06:26 Speaker A Exactly, most of the strong encryption algorithms used globally are open-source algorithms. Well, if the algorithm is open-source, where will my information security come from? 06:38 Speaker A Information security will come from the encryption keys. Exactly, I want to keep the encryption key secret. In this case, an open-source algorithm and an encryption key that is impossible to guess, or a secret that cannot be guessed. At that point, I am able to 06:55 Speaker A create a secure encryption system. Okay , I am able to create. A system that has secure encryption. Now, separation of privileges. What does separation of privileges mean? It tells me that every attribute I have must have a separate 07:10 Speaker A privilege. Specific to it, apart from any other attribute. Meaning I grant a privilege for adding, I grant a privilege. For deleting, I grant a privilege for modifying, I grant a privilege for viewing. Each of them I give a separate privilege. In other 07:24 Speaker A words, every button I have in my system must have a separate privilege, not giving the whole page one privilege. Is that clear? Okay, it gives an example of separation of privilege: Multi-Factor Authentication. For a user to log in, I must ask for a password, 07:39 Speaker A and I must ask for a smart card, okay. To enter our organization. This is an example of what? The login process. We have another example in permissions, for instance, web pages, or permissions for information management software. 07:51 Speaker A That every button I have should have its own separate, specific privilege. Okay. We said that, so what is the benefit? It tells me it reduces the risk or the expected damage. It reduces any effect, no, it reduces the effect 08:09 Speaker A of any security attack that happens to us. Okay, then, Least Privilege. Every user, every process I have must have the minimum amount of privileges necessary to do their work. I have no additional privileges. I have no additional privileges. Only the minimum 08:29 Speaker A amount of. Privileges, because any additional privilege means access to information that is unnecessary and unneeded by them, which could cause me problems now or in the future. Clear? 08:44 Speaker A So, any user, any process, should only have the minimum privileges needed so they can be able to execute the task required of them. Okay, right. It says privileges or the minimum of privileges from a temporal perspective. Okay. It 09:03 Speaker A says anyone we have might be required to do specific tasks. I grant them their privileges only during that time. 09:11 Speaker A Then I withdraw them afterwards? Clear. Meaning, a person I assigned for a period of time to manage a specific file. I grant them the privileges for the file at that time. Upon finishing the execution of the file required of 09:23 Speaker A them, the privileges must be withdrawn. Is that clear? The privileges must be withdrawn from them. Why? Because leaving unnecessary privileges in a certain place can create opportunities for something I call incidents, where two people might edit a file even 09:40 Speaker A though only one person is originally authorized to access this file. Clear? So, Least Privilege must be applied explicitly, correctly, and clearly. If I had to grant an employee or a certain party a privilege for a specific file at some point. After finishing the 10:02 Speaker A necessity that allowed me to give them this privilege, I must withdraw this privilege from them. Okay, the other principle, Least Common Mechanism, or the least common mechanism. I must minimize as much as possible the shared functions, or operations, or common 10:21 Speaker A privileges between different users. Why ? Does it reduce? Any communication path that I do not authorize or is unwanted, okay. Another thing, it reduces the need for software or hardware that every user relies on to access it, clear. And also in the 10:43 Speaker A verification process, this is very important especially in accountability. I am able to know exactly the person responsible for this task, clear. Least common mechanism, its most important thing is that it improves accountability for me and thus reduces the process of who? Any unwanted 11:03 Speaker A exploitation. Well, the next principle is psychological acceptability. We must have psychological acceptance for whom? 11:12 Speaker A For the procedures that I am building. In the end, who will work on them? My employees. Employees are human beings. 11:18 Speaker A If a thing is not psychologically acceptable, what will it do? It will impose problems in the implementation process. Not interfere. It should not interfere excessively with whom? With the employee's work. And consequently, it causes him to have a slowdown in 11:42 Speaker A production. Okay. It must also fundamentally support usability and accessibility. That the system is usable. Which is usability. Which is ease of access. Our security mechanisms must not hinder usability. Hinderance of usability means a decrease in productivity. A decrease in 12:05 Speaker A productivity means a delay in delivering tasks. And that is the required tasks and services. Which in turn delays who? Or which in turn reduces the organization's revenue. And reduces whom. Or forces users to do. To turn off what they call. Turn off the 12:26 Speaker A program that runs our security mechanism. Instead of using it. Things are clear. And that is to try as much as possible for our security mechanisms to be. Transparent, not visible. And not asking the user every minute, do you agree to, for example, scan the 12:42 Speaker A file? The file has been scanned, so do you agree to such, do you agree to such , fine. It is not logical that for every file he has on the flash drive, for example, once I connect the flash 12:50 Speaker A to the device, I ask him, do you agree to scan? No, the scanning process is done transparently, fine. Which reduces the user's obstacles in the work, fine. 13:08 Speaker A Clear. Well, let's talk about something called isolation. Isolation means separation. What is separation, fine. 13:15 Speaker A Isolation means separation. Isolation is simply a security principle. It prevents any unauthorized interaction between systems, between users, between processes, between. Files or with security mechanisms. Yes, clear. Any security ensures that this prevents any unwanted interaction between any two 13:40 Speaker A systems, between any users, between any two processes, and between any two files. Well, tell me, we apply isolation in or in three areas. Well, isolation is important and necessary because simply any interaction I have between any two systems or any two 14:08 Speaker A people may result in unauthorized access, or simply a breach of the system. That we have. Well. How do I separate a public system from critical resources? We talked in the last lecture about something called the Demilitarized Zone. And we said that we 14:32 Speaker A have two boundaries. We have an external, and we have who, which is internal. We talked about internal, and we have. What are external boundaries? 14:41 Speaker A We said, any connection coming from the internet, what should I do? I must block it. Either I send it to a demilitarized zone, so any modification or breach there doesn't affect the rest of the system. Alright. Or, if they are 14:56 Speaker A an authorized person, I let them into our local network. But when they try to access internal data, I need to implement network segmentation. 15:05 Speaker A Consequently, finance personnel go to finance, HR personnel go to HR, and academic personnel go to academics. I mean, that's correct. So, what public systems do we have? Examples of public systems: web servers, public IPs, email servers. Alright. All of these are what 15:20 Speaker A ? Public resources. What about critical resources? Like? The database, alright. The database is a critical resource. 15:26 Speaker A Any breach of our database causes us problems. Alright. Internal applications; internal applications related to the organization cause us issues. For example, an institution provides a service to the public. Only the applications for services provided to the public are visible to users. Are 15:41 Speaker A internal applications visible to users? No. For instance, a university. Is it logical to make the financial software available to students and employees outside the university? Or only to the external staff relevant to the matter? 15:54 Speaker A Only the staff specialized in the matter. Alright. So, we have a public system; I want to isolate it from critical resources. That is the summary of the discussion. Which reduces the risk of unauthorized disclosure or unauthorized modification of data. 16:11 Speaker A Alright. What is critical information? Any data we have that is, as we said, sensitive, and accessing it causes problems. I can perform physical isolation. What does physical isolation mean? Physical isolation is the separation between public information resources and critical information 16:36 Speaker A resources. By placing systems like firewalls and network segmentation. These are systems that perform a real separation of data. In physical isolation, I could actually put citizens 'data on one server and the institution's own data on another server. Alright. Logically, I have a 16:58 Speaker A public system. Add a security layer, and I'll have a secure system. Add another security layer, and we get critical resources. Alright. So, I have more than one layer. I have a public system, which is a layer. Secure protection layers; I have another layer 17:13 Speaker A , which is security. System information . Alright. Now, the second context. We talked about three. We talked about the first, the second. Second context: individual users, processes, and files. 17:28 Speaker A Files and processes belonging to individuals must be separated from any processes or files belonging to other individuals. Unless necessity requires that they communicate with each other. 17:41 Speaker A Alright. It is the final standard. Alright. Every mechanism I have must operate separately. If another security mechanism interferes with it. If one security mechanism modifies its entry logic. And there was interference with a second mechanism, the second mechanism might fail to verify the data 18:05 Speaker A . What does that mean? If I have a security mechanism that simply states that authorized persons one, two, and three can access our existing database. 18:20 Speaker A We had a second security mechanism that stated only four and five. Or perhaps it says, take the same people from the first security mechanism. Bring them to the second one, and they are the ones allowed to enter the second database. 18:34 Speaker A One day, we decided that the second mechanism, instead of being internal, became public. I said, "Only allow the public to enter." Or the security became such that it allowed the public, while the other only allowed private. 18:49 Speaker A In this case, if there was a common share for users or access control between the two. Effectively, our system here has become available to the outside. So, I will repeat it again. I have an internal system, two internal 19:03 Speaker A systems. Right. I have the first mechanism for internal. The second mechanism is also for whom? For internal. The first mechanism allowed internal access to the database. And the second mechanism also allowed internal access to our database. But this second mechanism takes its access 19:20 Speaker A control from here. Right. It takes it from where? From there. If, one day, this decided to open up to the public. 19:29 Speaker A Without informing this one. Without informing this one about what happened here. In this case, we had unauthorized access by the public to the private database we have here, and consequently , we had a failure in our security mechanism; there must also be isolation 19:45 Speaker A between the mechanisms. Is that clear? Okay, encapsulation; a capsule means wrapping. What does wrapping mean? This wrapping is one type of isolation, and we learned its principles from object-oriented programming; every procedure I have must be encapsulated. 20:07 Speaker A All data objects must be encapsulated. And it must only be for the domain it exists in. I have a schema running in the student database, only for students . A financial database, or a schema or procedure running on the financial 20:22 Speaker A program, it only works within the financial program. Any communication between two procedures must be done via a clear, documented, and secure API. So that there is no interference in the operations. Structure. Right. I have a subsystem; every subsystem must have 20:44 Speaker A its own procedure and be protected, okay. Let's talk about modularity. When we talk about a module, what is a module in general, for example, in software, what does a module mean? A group of procedures. A group of functions. A group of routines. That 21:00 Speaker A perform a specific task. That is, who is...What they call. It is shared between users. We have modularity in design. We have it in security. For example, that security functions are separate protected modules. Right. 21:19 Speaker A Security functions must be separate modules. Like, for example, let's talk about encryption. How about encryption? 21:25 Speaker A For encryption, I have a clear mechanism for encryption. I have ciphertext without encryption and an encryption key. Right. Without encryption and an encryption key. This encryption key is plaintext or here we have plaintext. Plaintext is encrypted with a specific encryption key. This 21:41 Speaker A encryption key produces ciphertext. The ciphertext created for me can be decrypted in a certain way. When my cryptographic module is...clear and built correctly, I can take this cryptographic module and generalize it across the systems I have. Consequently , I don't need to rebuild the 22:02 Speaker A cryptographic module for every system. It's clear; for example, I have a system for students, and I have a system for the academic staff, right? I have another system for the administration, right? Should I rebuild the encryption system from scratch 22:21 Speaker A every time I want to encrypt? The encryption system is actually the same for everyone, but the keys differ; the encryption keys differ. Therefore, I build a module based on the protocol, whether the encryption application varies—for students, it's this 22:37 Speaker A encryption key; for academics, it's a second encryption key; and for administration, it's a third encryption key, and things proceed clearly. 22:46 Speaker A Modularity means I build a module for the common functionalities among our systems, put them in a separate file, and everyone calls it, but the difference will be in the inputs and the encryption keys we have, right? 22:58 Speaker A What is the benefit of modularity? This modularity provides security isolation. It gives me protection against the process of forgery. It also allows me to use this technology in other places without having to...completely redesign my system. Now, layering—what does 23:23 Speaker A layering mean? I have layers, and there are overlapping concepts; I have a layer of resources, a second layer where we have...other assets, a third layer, a third asset, a fourth layer, a fourth asset, right? Each layer I have 23:45 Speaker A must protect specific assets. As the layers get deeper, the sensitivity of the asset increases, right? The sensitivity of our asset increases, so we get defense in depth. So, for any snoop or external attacker to reach the sensitive data I have, they must breach 24:05 Speaker A layer one, two, three, four. Is that clear? So, based on their sensitivity, I add layers of protection to the assets. I put a first layer of protection for less sensitive assets, or what I call publicly available ones, a second layer for assets that are not 24:24 Speaker A publicly available but not very sensitive, then a third layer for more sensitive assets, and so on. The more layers—layers are, of course, people, technology, and concepts related to encryption—the clearer it is. Now, " least astonishment," which is our last 24:43 Speaker A principle, for programs...So my program shouldn't shock the user. If, for example, my program finds a virus, I shouldn't just shut down the laptop. 24:58 Speaker A Instead, I display a message saying, "I have detected a virus on your device; this virus will be quarantined or the file will be deleted," rather than the antivirus just finding a virus and shutting down the device. What happened 25:10 Speaker A here? The user was shocked by the issue . They might simply delete my antivirus from the device. Is everything clear this way? So we must have the least astonishment and the least interference in the work of...the users. All right. 25:23 Speaker A These are the 13 criteria for design. Each criterion has its core idea focused on "simple and small," which is ...fail. Safe default, default means no access. The default is to grant no permissions whatsoever. I only provide exceptions for those needing system 25:41 Speaker A access. Complete mediation, for all access, I must perform a full check. Open design, open design. I keep my design open for people. But secrets, encryption keys are what I keep protected. Every permission, button, or action in my system must have separate 25:57 Speaker A authorization. This fifth is least privilege, give users only the minimum access they need. These are our 13 criteria. Thank you very much. We will continue in the next lecture, God willing. There is a very, very, very important concept in the process of 26:15 Speaker A potential risk analysis. Take care, everyone. Yeah. Topics: security design principles least privilege fail-safe defaults complete mediation open design economy of mechanism separation of privileges computer security network security access control Study this video - [Flashcards from this video](https://sozai.app/tools/flashcard-maker/?from=transcript&id=90891) - [Quiz on this video](https://sozai.app/tools/quiz-generator/?from=transcript&id=90891) - [Crossword from this video](https://sozai.app/tools/crossword-maker/?from=transcript&id=90891) - [Word search from this video](https://sozai.app/tools/word-search-maker/?from=transcript&id=90891) - [Study guide from this video](https://sozai.app/tools/study-guide-maker/?from=transcript&id=90891) Free, made by AI from this transcript. No signup. --- This is the markdown twin of https://sozai.app/transcript/lecture-07-fundamental-security-design-principles/ — the same content, without the markup. Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back. Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/