When we're talking about logical or technical controls, usually we're thinking about something that is running on a computer. This can be hardware, this can be software, and in fact, can be something that's Cloud-based, doesn't even need to be on our network. When we're talking about security models, these are logical concepts and one that we may be very familiar with practically is discretionary access control, DAC. Here, the asset owner always decides who has access to an asset. If you create a file, you are the asset owner typically, and you decide who has access to a system or service. As an asset owner, how you influence that access is what we're looking at right now with discretionary and mandatory access control. With discretionary, the first model we look at, the owner directly controls access. This is very commonly what you would see on a shared drive. On the share drive as the document creator, you can right-click the File, click "Properties," go to Permissions, and you can change the permissions directly. You are managing access. Does that work well? Well, I would say in large organizations rarely, mostly because the use is inconsistent. Human beings may remember going through some policy process training, but not use it in a way that is consistent. I would say that's one of the big problems here. They may not be capable technically to do this, they may not understand the implications of their actions, or they may be inconsistent in their actions. Both very common problems with this model. But the benefit of this model, is that it is very fast, very cheap, very low cost in terms of administrating the mode, l effectively the owner is doing it themselves. The opposite of this model, or most then is mandatory access control. The asset owner is still determining who has access but they don't do it themselves. Instead, they ask some central function to manage the process for them. The downside of this is it adds cost because now you need a team of people to implement these changes and also it makes things slower. It adds latency. But this is very useful in high-security environments. I would say you see mandatory access control usually in a military-type environment. Here when the asset owner wants to make a change to who can access that file on a shared drive, they have to make a request through the central function, the security function, and the security function now we'll check what's being requested. Is it appropriate? Is the request correct? Are the permission sensible maybe? Are the privileges sensible? Then do the implementation. It does add cost and delay but it also means that by default, your outcomes are a lot more likely to be consistent. Because you've got one specialized team of people making these changes, actually enforcing this. The last of our control types then is role-based access control. Here, your role determines what you can access. This works well where you have multiple individuals in a single role. Just think, for example, of a help desk environment where you have maybe 200 employees, 10 of them are managers, 190 of them are help desk agents. With role-based access control, with that really simple example, you would need two roles, one for the manager and one for the help desk agent. That would give you a security template for 200 users. That can be pretty powerful. Simply in theory. In practice, it's never usually that straightforward. Usually, what we see are far more roles in organizations, it's never just two roles in an organization. If you have 500 people, maybe you have 500 roles. Maybe there isn't a saving there in terms of time and energy. But also commonly what happens is even if you do have multiple examples of a role, so 190 help desk agents, as I suggested, what happens very quickly is you get exceptions. Maybe you take 10 of those agents who work on a project and therefore need a different permission structure. Or two of the managers are involved in additional finance responsibilities, which means again they need some change. What you see is this role-based access control as a starting point for organizations but very rarely is it comprehensively and consistently enforced. There's usually lots of exceptions. What we see commonly is a blended approach, lots of discretionary access control, from role-based access control, and maybe also some rules as well. Some rules about allowing and denying access based on time or where you're based. If you're outside of the corporate network maybe you can't access some things. Maybe if you're in some territories, you can't access certain things. This is leading us towards the concept of an access control list. An access control list is a really simple form of control. In its simplest form, an access control list is a text file. It will have a statement saying something like allow or deny, or permit and deny, and then some logical condition, allow this network address, access to another network address, or deny one network address access to another. By default, most access control lists have what we call an implicit deny. If there are no entries in the list, the default is nothing is allowed. An implicit deny, the access control list is empty, then everything is denied. Usually, it's like a brick wall and you have to create holes in it by adding access control rules. We have the idea of an allow list or deny list. An allow list, we're specifying specifically what is allowed. This is the idea of an implicit deny, by default nothing is allowed we specify individual things that are allowed. This is commonly what we see with network devices. As we move into Chapter 4, we'll start to talk about things like routers, switches, firewalls, and they use these allow lists. This wouldn't be a useful process, usually for Internet access. Could you imagine trying to specify every single site that people are allowed to access? I've seen organizations do this and you end up with lists of thousands of websites that people are allowed access to. Because it's so fluid, it's a very high maintenance list to maintain. More common with something like Internet access then is a deny list, a list that says what is blocked. For example, with web-filtering, maybe we block criminal activity sites as a category, or maybe we block a gambling website. We don't want people accessing those websites from school or from work. Maybe we'd have these access control lists in our home. We have firewalls and routers, and web-filtering, which we've just discussed but we will dive much deeper into when we talk about networking in our networking chapter. All of these controls are great but as we've said throughout, any control needs monitoring to make sure that it's providing the benefit that's intended. Also to make sure that we understand what the environment is, what's happening out there. We need some form of checking. It's not enough to have the logs, we need to monitor and audit those logs as well.