CCT 092: A Deep Dive into Authorization Mechanisms and Access Control Models for the CISSP Exam (CISSP Domain 5.4)

What happens when ransomware strikes a big corporation like Clorox? Imagine the chaos and the panic that ensues - not to mention, the significant impact on revenue and leadership. That’s where we kick off our conversation with Sean Gerber, who delves deep into the Clorox ransomware attack and why having a strong resiliency plan is imperative. We also shed light on the importance of authorization and discretionary access controls in maintaining organizational security.

We navigate the complex world of role-based access controls (RBAC), discussing how it can efficiently handle access permissions and even prevent fraud within an organization. But it’s not a bed of roses; role explosion and initial setup overhead are just a couple of issues when adopting RBAC. Moving forward, we unpack different types of access controls, their advantages, and challenges - think attribute-based, mandatory, and risk-based controls. You'll be surprised by their impact on enterprise security.

Wrapping up, our attention shifts towards CISSP cyber training and how it bolsters your chances of acing the CISSP exam. We share stories of triumph, tips, and tools to help you succeed. Whether you're a cybersecurity professional or just interested in staying one step ahead of cyber threats, this episode is bursting with insights and discussions that you simply can't ignore. So, forget your regular playlist; it's time to plug into some serious cyber talks!

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

TRANSCRIPT

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started. Good morning everybody. This is Sean Gerber with CISSP Cyber Training, and I hope you all are having an outstanding morning this morning. Maybe you're just getting started. It is going to be outstanding. Yes, today is an amazing day. We're going to be talking about the 5.4. We're going to be getting into CISSP domain 5.4 as it relates to the CISSP, and we're going to be focused on discretionary access controls and all of those wonderful tools. It is going to be amazing. I hope you all are excited about that. I know I am. We're just coming back from the Thanksgiving holiday here in the United States. We're in this mode of just very full probably way too full than I'm supposed to be and we're just getting ready to go back to work. It's awesome. It's an awesome day. I wanted to, before we get started on discretionary access controls and the various pieces that are tied to that. When it comes to the CISSP and domain 5.4, I wanted to share with you all an article that I saw actually, I saw it last week and it was a bit shocking, to be honest. It was the Clorox ransomware attack. I'm not sure if you all saw this in the news. I may have mentioned it in one of my podcasts, but Clorox is a company in the United States that is a cleaning company. They deal with bleaches and wipes, sanitizing wipes and so forth. They were hacked back in August I believe August or September of this last year of 2023. In the process of doing so, they were down for quite a substantial amount of time. They were down probably close to four to six weeks when it was all said and done. Much of it was due to just this ransomware attack that occurred. We've talked about this in the past. You need to really have some sort of resiliency plan built into your cybersecurity plan because in the event that you do get a ransomware attack, you want the ability for your business to continue operating in the event something bad were to happen. What happened was they had this meeting with Clorox and their investors and the board and all these kind of people, but basically what they were saying that they had a huge dent in their revenues and they dropped revenues by 500 million and then cut the valuation of their company by close to $3 billion. That's a pretty substantial hit for any company in general. Because of doing that, they decided that they were going to let go their CISO basically my role that I do with another company. In the process of doing so, this gentleman, this lady by the name of Amy Bognak she decided to leave. They're saying that the interesting part about all this is that there's a lot of nuances around them. Having a requirement for a CISO on their board or to have cybersecurity knowledge on their board. The board itself didn't really take ownership around it. They more or less told them that it's time to leave. It's interesting just how this happened. Just because of the situation, the CEO got a pay raise, the board got a pay raise. They really didn't address the overall cybersecurity problem. This is in Forbes, so I recommend you go check it out. It highlights a challenge that CISOs and security professionals are going to need to work through, in that, if something bad were to happen, how are you going to deal with it? In many cases, the CISO is the one that's usually responsible, not to say that that's not the case and that shouldn't be the case, I think it should be. However, in many cases with relation to the boards and with some of the leadership within organizations, they do not understand the risks that they're taking on and they also just want to placate some of their shareholders. Again, the devil's in the details and the truth is somewhere in the middle. Basically meaning this article from Forbes talks about how the board seems to have come across a little bit shady and it also talks about how the CEO may have been a little bit not in the most up and up, but it doesn't really highlight Amy's role, the CISO, in this article as well. So the challenge is is I think that blame can go both ways. It would just be a good, interesting article for you all to read, to get is you're getting into cybersecurity to really truly understand some of the risks that you're getting into? Again, positive is is there's lots of opportunities out there for you in the cybersecurity world, but there are so are situations where, if something bad were to happen, you may be the person left holding the bag, and some people are okay with that, some people are not and it's an interesting it doesn't for all security positions. It's mainly for those higher level security positions. But as you strive to be the CISO for a company, just know you may have to deal with this at some point in time. All right, so let's roll right into this. Authorization, as you're dealing with these different types of controls, is the process by which you're giving someone permission to do something within your computer system device, your environment, you're authorizing them to do this activity, and it is an extremely important role when you're dealing with security in your organization. Now, one thing that we talk about in CISP, cyber training and you're going to understand this with security in general is you need to have some level of framework implemented within your organization, and this framework will help keep the you basically allowing you to maintain these different milestones and occurring getting to where you need to go in your cyber security plan. And there's different authorization mechanisms that you're going to need to understand as it relates to the various security policies and the models that are implemented within your organization. So we talk about a security policy. That's the defined document that you will have stating what an individual can or cannot do. You may also define in this security policy things that may be the expectation or what what may happen to them if they do not follow those specific aspects. So first we're going to roll into is what we call discretionary access controls. These the types of controls where resource owner has the authority to decide who can and who cannot access the resources. So this is the first topic discretionary access controls. This is a user centric approach that's designed specifically to manage the permissions on these resources. Now, it does involve the getting permissions to read, write, execute. You may have download. All those aspects are tied to this, and I've seen this with SharePoint environments. You may have a SharePoint environment or a teams environment that is built and you will then set the access controls, the read, writes and so forth, to ensure that someone can utilize these controls and these tools efficiently. And so that is when we get into discretionary access controls. Now, some characteristics around this a DAC DAC is. It basically comes into every object, such as a file, a file folder, that each of them has their own specific owner. Now, that's a key factor. You have to ensure that if you're working through the DAC characteristics, you provide a owner or you work to strive to get an owner for all of these various aspects within your organization. So I'll give you an example of a SharePoint site. You have a SharePoint site that's set up. You have Bill is the owner of that SharePoint site. Bill leaves the company. Now no one actually owns this SharePoint site and now, with controls Bill put in place, people are familiar, aren't aware what they should or should not have. So when you don't have an owner, it can get very squirrely very quickly. So it's important for you to ensure that you do have some level of ownership on each of these sites that is directly responsible for providing the permissions, and that they have the ability and the decision rights to do so. Now one thing we talk about is permissions propagation, or they've also talked about it with permission creep, and this is where permissions will continue to go beyond what they originally were planned to do. And one aspect that comes into permission propagation is the fact that if, let's say, for example, user A shares a document with user B and then all those rights to modify that document go with it to user B, well, if user B has been given access rights or the ability to grant more users access, user B can also grant these rights to user C. So an example where this happens a lot is an individual who's the owner will set up the user rights for document A and they'll just go. You know what? I don't have time for this, let's just go and make it open to everybody, thinking, hey, more accessibility is great, I don't have to worry about it, we'll just give it to everybody, or give it to Bill, because Bill has full access. But they don't really think about as the fact that Bill shared it with 15 other people and now 15 other people have the same level of access that Bill does. So it's just something that you have to consider when you're working with various documents, that you are putting the proper permissions in these documents, that you want it specifically for an individual. You have to watch out for the document moving and propagating to someplace else. No one thing to also think about is this is where you have document level protections or data loss prevention tools that are put in place that are focused only at the document level. So, for example, if you have a Word document and you want to avoid this propagation problem, you then would put some level of controls on this specific document so that if it does get propagated somewhere, those controls will go with it. So that's a really important factor that you need to consider is if this risk exists. You know this risk exists and you know that I have to have elevated privileges for many people within my organization, because the fact is that I don't know, maybe they all need to touch it and I'll need to edit it somehow. Then you may want to look at investing in a document or a data loss prevention type tool. So you also want to consider ease of management for the end users. So this is a big factor, then, that, whatever the end user is gonna be, if you make this more complicated, the more complicated you make it, it will cause users to try to circumvent the controls you have in place. Seen it time and again if you have those controls and you put them really hard on people, then people start going well, how do I get around this so that I can do my job? Many times, they're not doing this just to get around the system. They really truly want to protect the data within their organization. Many people do. However, they want to be able to do their job and when it becomes too complex and too complicated, they will do things to try to get around those controls you have in place. Now you also want to be very granular. These permissions that you assign need to be very specific and very to the point. Again, like I mentioned earlier, if you get too permissive, you have a lot of problems where the documents go everywhere. If you get too granular, then people will try to bypass or get around the controls you currently have in place. We talked about, when you're dealing with those types of discretionary access controls, some key considerations you need to be aware of. Obviously, risk of misconfiguration. This is due to the fact that the discretionary nature. There's risk that they can accidentally or potentially intentionally give away more permissions than are intended, which will result in the next consideration of potential data leakage, because the data will be going somewhere and it can inadvertently be exposed. You may not understand where it's going and then it, within a year, two years, six months depends All of a sudden this document will come back to life and people will. It'll start getting forwarded around, it will come to you and you may go. Well, how did this data, how did this document leave my organization? The next one is administrative overhead. Large organizations rely heavily on discretionary access controls because it can help things keep on track, but because of that it does have they go everywhere. There can run into audit challenges, especially if your organization is dealing with audits routinely from a financial institution or maybe a data records type of activity. You may have audits that you have to rely on or you may be subject to various audits within your organization. The other thing with discretionary access controls, there is a lack of central oversight. So if you don't have one person who can control the access, then these things can get into a lot of sprawl. A lot of growth can happen with these data and it can go everywhere. So you need to have some level of central oversight. But data access controls does not lend itself to do well in this space. And then there is a lot of dependency on user awareness. Effective DAC relies heavily on users being aware and knowledgeable about their security best practices. So this means you need to have some sort of solid training program that is in place to help teach your employees. So now we're gonna roll into role-based access controls. Role-based access controls is a systematic approach where access rights are based on the role within your company. Now this ensures that the users are the only ones who have access to that need this for their role, for their job. This model is kind of an abstract and it decouples user permissions from the individual users. So now it's based on Sean's role as a CISO or Bill's role as a security analyst. It is specifically the permissions around that individual role. So Basically what it means is that if Sean leaves the company and Sean goes to company X or you know, not even company, let's go Sean leaves, his role is a CISO and Sean goes to working as a security analyst within a company, my credentials, my user rights, would change based on my specific role. So as a CISO, I have no control of or anything. I don't have any rights. Now, if I go to become a security analyst, yes, I have rights and I would have the ability to maybe manage the system better and so therefore my rights and my credentials would increase. This happens a lot, not necessarily from a CISO going to a security analyst role, because I don't mean it this way, but it would go from a higher level position to one that is more along, daily run and maintain type of position. That doesn't typically happen, it's usually from the daily run and maintain to a CISO type role. Well, the flip side is that if I go from a run and maintain position to a CISO role. I'm taking those credentials with me. Well, now, as the CISO, I don't need those credentials and so therefore they come with me and now I have all these rights that I should not have. And that's where the role based access controls really are an important factor. Now we're dealing with the characteristics around RBAC, and you'll see the term on your CISSP. It's called RBAC Romeo, baker, alpha, charlie. That's role based access controls. You'll see that term, rbac, used, and so you need to be aware of what does that mean? And there's because you will also get confused with there's role based access and then another one I'm going to get into that starts with an R as well, and you may get kind of confused between the two. So you got to make sure you keep that the acronym in the back of your mind and understanding it. So when you're dealing with the characteristics around RBAC, there the roles can be hierarchical right, so a higher level role can inherit permissions from a lower level role, just like I mentioned with the security analyst. And again, that's an important factor because this happens a lot within a company where you will have specific access and or individuals will, and they will move from one role to the next role and they take their credentials with them, which is credential creep. Now, this thing you got to watch out for from a consistency and uniformity perspective, is that you need to ensure that these access permissions are there are for specific users and that they are removed once that individual leaves that specific role they're in, because they don't want them taking that with them. One thing to runs into and you'll see in audits a lot is that an auditor will come in and they'll start checking out all the different roles within your company and who has access to these various data and this is where they will find a lot of gaps is go well, sean is supposed to only have access to y, but he has access to x, y. Is that the case? And this is where you'll see a lot of findings as it relates to audits. Now, when you're dealing with centralized management for the each of this, this can be done. Permissions can be managed centrally with role based access, which is also makes it much easier to implement change across a large user spectrum. So that's a positive. That goes with role based access, and in it I've seen that work well. I've also seen it where individuals don't have good granular role based access and so then you can't do much with it. So it's it's. You need to make sure that you set up within your organization at the beginning some level of access controls and you're going to use a level of both. You'll have times you'll just use discretionary. There'll be times when you use the role based. There'll be times when you use the risk base. There's gonna be various ways that you're going to use these different management tools. Now, when you're dealing with various considerations as it relates to role based access, organizational roles will evolve and change. The company may have it the role set up specifically in a way now, but within six, eight months that may change dramatically and if that does, you're going to have to go back and modify your RBAC. As it relates to what, what's happening within these various roles within the company, there's also a thing is a role explosion and if not man properly manage, you can get excessive creation of roles which makes it extremely hard to manage. So you may go, the person that sets all this up goes. Well, you know what, instead of having two roles, we want 30, because they have various aspects. Each role is nuanced, each role is specific. You may have that and you go, oh, let's do that. That's a really bad idea, because then it becomes so complex it's darn near impossible to change and to manage. You need to ensure we call it SOD, or segregation of duties, and you'll see this on the CISSP, potentially, where it may say SOD and that's a segregation of duties. I'm saying that multiple times so you get it because it it caught me off guard. This is to prevent a conflict of interest and fraud. You'll see this in the financial industry, where, if you have money transfers that have to occur when Sean clicks, hey, I'm going to send a thousand dollars to Sean's bank account, it has to go to another person in their role to approve or disprove that, and that's works really well if you're dealing with money transfers or with people that have the ability, within their organization, to make drastic changes. Segregation of duties is a really good system. Now, if you don't have that in place, you need to really try to implement it. The problem is, though, is the more levels of bureaucracy you add to your organization, it slows down the ability to be agile, to be able to move quickly, so you need to consider what are the specific roles in which you need segregation of duties. It doesn't need to be on every specific role. Now there's also an initial setup overhead when you're dealing with our back. It requires a thorough understanding of your organization and its functions, which can be very time consuming initially. So you need to go through all of that there. You need to have the permissions should be reviewed periodically. All of those things should be in place that you make that they align to your security policies that are within your company. So it's just. It's really important now when you get into really large organizations. This can be very good, but it also can be challenging to implement. I'm not really giving you a good advice on this because you're going to have to. When you get in your own security environment and your own role in security, you're going to need to truly understand what is available to you. Now we're going to get into rule-based access controls. Now we talked about role-based. Now we're going to get into rule. So rule is R-U-L-E versus role R-O-L-E. Yeah, right now you're going to think, oh my gosh, what am I going to do? Because there's too many of these? Yes, you're correct, there are too many. But when you get in here the CISSP you may see this acronym of R-U back, not our back. That's rule based access controls. You may say R with a little, u, b, a, c. That's rule based access controls. Now these are based. These are this is where access is allowed or denied on resources based on a set of established rules, and this can often be used in environment where you have firewalls, and this can be another combination of other access control mechanisms for more of a layers level security. Rule based access controls are, in most cases, very automated, which are great. They're awesome because you don't have a person that's having to click yes, I approve. You can have the robot do this for you and this is where the system will make decisions based on these predefined set of rules read, write, execute. All of those pieces can be to set up via the robot and the scripts that are allowed to make that happen. Now, the downside with some of this is is that the decision is extremely binary, which means it's either approve or deny. There's no gray area in the middle, which, when you have an individual that's approving this, that gray area can become helpful because you're like oh yeah, I know what you're doing, sure, let's approve it, whereas a rule based access control will say doesn't matter, you didn't meet my criteria, it is denied. So it's important that you do. You do understand when do you want to put in place rule based access? Now the rules are defined and we're getting into some of the characteristics of it that the rules defined as an objective criteria rather than the individual user identities that are tied to it. So because of it, it does help alleviate the problem of well, yeah, you know what I know, bill Bill's a great guy. Book needs this for his role. Yeah, approved. It helps reduce some of that. Now, again, like we mentioned before, it does reduce the flexibility that you may have if you have some gray area, but it will allow you to speed up and advance your access allowments allowance faster because of it. Specifically, again, these are all set up with a pre established rule that's in place. Now they can be used to grant access based on certain conditions, context, resources, you name it. They can be done specifically along those lines. Now, the other aspect is it does provide an automated enforcement and this is due to its rule based nature and the access decisions are generally enforced automatically by the system without requiring manual intervention. Now some things to consider is you have complexity, there's conflicting rules. You know all of these aspects can come into play. You may have a rule that doesn't work well with another rule and now you have conflicting pieces of this. You have a very complex rule that it is supposed to go ABCDE and before it goes to F it's got to do I don't know 10 jumping jacks and move on to the next. It's the complexity if you can get out of hand. And the other part that gets into this is because when it becomes so complex let's say, bill is the person who set up this very expensive not expensive, but very elaborate rule based access controls will now bill you know who's having problems in the organization leaves the company and then he takes all that knowledge with him. So then when you go back and figure out, why is this always breaking? It's because of the rule that bill put in place. So you need to really make sure that you don't make you make it as complex as needed and no more. You also need to. It does provide, or it can add, some performance concerns. So extensive rule checking can have an impact on the performance of your systems because it's going through all of these checks before it will allow something. The other thing is you need to have some level of regular rule review to ensure that it's being updated and it remains relevant to your organization. So rules are great. It helps out a lot, but you just need to keep in mind that it needs to be modified and looked at. Next one is attribute based access controls, or a back. Now, a back is a flexible, finely grained access control that allows you to evaluate variety of attributes. This could be users, the user itself, could be actions, resources, environment. All of those things can be looked at and granted. Access can be granted or denied based on the variations of your policies that you have. Now. This can be extremely granular. So, again, like it says, attribute based, that can be very tight, can be very specific and that, like, for an example, you may have an access control that is in one users department and then at a specific time, a specific day, and then it will go ahead and work. Then on other times and other days of the week it does not work. So that's getting very, very granular based on the attribute that is being defined. A lot of times these can be set up on a policy so that you have specific policies that are set up where this rule will be implemented. One example might be that you are allowing, you have traders, and these traders are supposed to communicate with an outside entity on a Thursday. Well, you will have, based on the attribute, you will allow this group of traders, through an active directory group, to communicate to this outbound organization on Thursday, and that's allowed. The challenge is, with this again, can be very if you someone who set it up, does not remember why they did it. It can be challenging when things break, but this is based on a specific attribute that is needed to be happening. The nice part is there's also real-time evaluations. These often decisions can often be made in real-time, which allows the values for each of these requests to be fulfilled very quickly. Now one of this it doesn't allow I actually did not notice that. I did some research on this but it can utilize the complex Boolean logic which is basically your and or not type of values. You see this a lot in AWS that, based on the policies you have, it will support this Boolean type logic. So, if you want to go, if this condition is met and this condition is met, but not this condition, allow it to occur. That is typically the attribute based access controls. Now this comes back to some of the things to consider when you're doing this again is managing the attributes. That can be a challenge and the person who did it. If they're not here with the company, that doesn't really help you a whole lot. Policy complexity the more complex you make your policy, the more challenging it can be when things break Again. Much like the A-Back. Is you're dealing with or with? Are you rule-based access controls? See, there's a lot of these. It can run into performance concerns as well, because the more complex you make it, the more it can have tasks or resources that you currently have. Auditability it does with high granularity. The flexibility comes a challenge of auditing this. So if you're trying to audit what's actually occurring, if it does step one, two, three, four, skip to 10, go back to 11, go to 12, and it does all these different attributes, it can be very challenging for an auditor to really truly understand what is happening within your environment and then it'll take initial implementation overhead. This is defining and implementing the right attributes and policies. That can be very time consuming and require a deep understanding of your organizational data flows and their access needs. So, mandatory access controls, mandatory access controls. These are a rigid set of controls that mandate access permissions based on security labels, and they're often called security classification. Now you'll get into security labels, such as confidential, secret, top secret. These are specific characteristics that are tied with your mandatory access controls, which basically means is that if you're going to clearance that someone has access to secret, someone has access to top secret. That's only what they're allowed to gain access to. Now this can be done through various permissions through the mandatory access controls, and these permissions are based on assigned labels that they may have, such as clearances and so forth. There is the ability to downgrade or upgrade with the clearances, which basically means is that if you have access to secret, you can get access to top secret, and if you have access to top secret means you can get access to secret. However, moving data between those two buckets can be problematic. There is a process and you should have a process to do that, but you need to follow that specific program and process, and that's a little bit different conversation and topic, but bottom line is that you need to have those things in place if your company is going to be dealing with mandatory access controls. Some key things to think about with Mac and, like you're dealing with, secret and top secret is the rigidity of it. Those are some things to work through. It isn't as easy to like we mentioned before to move data from secret to top secret. That is a huge process and it should be a very painful process. You do not want it to be easy to do because then you lose the ability to maintain that level of control. So they can be the implementation of them can be very complex. It can be very hard. They you have to start that at the beginning, from the time you do some level of data Classification. You need to do mandatory access controls from the beginning and it's not a good idea to try to implement that somewhere down the road. There's going to be some substantial training requirements tied to deploying Mac within your environment and it can cost be very expensive, because when you're dealing with, let's just say, secret and top secret systems, you want them to be separated. You do not want them to be integrated, because then the ability to transfer data between one and the other becomes too easy to do. The next one is a risk based access controls. Now, risk based access controls are adaptive controls that evaluate the potential risk and access in real time. What's going on within your organization Now when you're dealing with a company depends on the organization. But risk based control access controls are really good because you can understand the overall risk to your organization. So it can have. It assesses basically the contextual and the environmental factors to decide if a request is safe or additional verification is needed. It could deals with data, reputation, ip location, you know, I should say internet protocol, ip location, behavior patterns and so forth. So it can be very, very helpful. Now, some of the characteristics around it is it gives you contextual analysis. It allows you to determine where did this login attempt occur? Was this in Bangkok, thailand, or was it in the United States? If you're operating out of Bangkok, bangkok makes sense. If you're operating out of the United States, that would make sense. But if you're operating out of the United States and the login occurs in Bangkok, I don't have anybody travels to Bangkok. Why would that be? So? It gives you some sort of contextual analysis around that. It does do some level of behavioral profiling which basically will flag if user deviates from a specific plan, such as if you're access accessing sensitive files late at night. This could trigger a higher risk score and because of that higher risk score, then it puts you on a watch list or maybe even denies the access altogether. It has also adaptive authentication which, depending on this risk score, the system might require additional authentication methods, maybe like a one time password, otp or some sort of biometric verification saying, hey, you know what? This seems a bit fishy. I want you to verify who you are through utilizing some sort of multi-factor authentication. It can be integrated with threat intelligence to be able to understand the current threats and the vulnerabilities better, as you're kind of working through your organization, and then it can help you, allow you to do real-time decision-making. Risk assessments can be done in real-time, making these decisions the most current data and context available to you. One thing to consider when you're doing these is that there has to be continuous learning and updates. There's also false positives. This can happen real quickly where you may have a risk in place. The robot flags that there's a problem, but when it comes right down to it, there isn't. It's just the way it was being used Looks like a risky situation. So you can have a lot of opportunity costs wasted trying to understand where all these false positives are. There's also privacy concerns as well is that, depending upon its watching behaviors and patterns, can potentially lead to privacy concerns if it is not properly vetted within your privacy folks. All of these things are available within countries that have a high privacy issues. They are. You just have to make sure that you go through the traps. You walk through the process to ensure that it's been approved by the necessary individuals within your organization and outside of your organization to allow it to happen. And then integration complexity Our back can lead to existing systems, ensuring they have a diverse environment, and that can be very, very challenging. And then, lastly, user experience. With these types of adaptive authentication mechanisms, it can have some sort of experience impact on the individuals and it can cause some challenges in regards to that. The last thing we're going to talk about is non discretionary access controls. This refers to a centralized access control where decisions about who can access resources are made by a centralized authority. So it's often a security team will say, yes, you can gain access, or no, you cannot. This is based on company wide policies, job function or other overarching criteria that may be put in place. So, as you're looking at that and considering this, this centralized decision making is this central in single entity that does this could be a security officer, who it could be as a security architect. Someone's actually making those decisions for your organization. This can be role based or task based, and it's often designed based on the job, roles or specific tasks within your company. This is very audit friendly because you now know what's happening. There's an individual that's actually approving these rights as they go forward, and it can provide be very dynamic. In some organizations they may they may have this setup so that it's a very automated, dynamic process as well. So I'll say, for example, if insecurity it's everything's automated up to the point where it comes to me or it comes to somebody else within my organization and then by the time it's gone through all those processes, it in most cases you would probably approve it because of the fact that it's done a lot of checks in between. It does it's less reliance on the resource owners. So now I don't have to wait on individuals who are maybe not in that don't approve it. It can be very helpful in that regard. Now, on the downside, it can provide a bottleneck. These sometimes can lead to delays in granting or evoking access, especially within a large company, or if somebody like myself wants to take a vacation someday. You need to have processes in place, done how to allow these approvals to continue in the event that someone is leaving your company. If not carefully managed, roles might be too broadly defined, leading to excessive access. Regular reviews are needed and required and should happen routinely, to ensure that these things remain appropriate. You're going to run into user frustration, where users might feel the lack of autonomy and may get frustrated with trying to get approval. I've seen this happen where somebody's going hey, this person who's the the approval person, isn't approving this fast enough, and so therefore, there's delays and it can cause to a lot of frustration with individuals. Scalability concerns, again. As your organization grows, it can be very challenging to scale this out in a way that is effective for a large number of users and resources, works great in a small environment, but does not work so well in a large environment. And then, when you're dealing with the nondiscretionary access controls, they focus on maintaining organizational consistency, and integrity is an important factor what they do, but it can be problematic when you're dealing with specifically, a large organization. Okay, that is all I have for today. Again, we talked about a lot of different things as we're going through all of this, right? So we talked about discretionary access controls and how important those are within your organization. We talked about role based access controls. That's our back. We get went into a rule based access control, which is are you back and then we will roll into attribute based access controls. Finally, onto mandatory access controls and then risk based access controls and with the last and final one was the nondiscretionary access controls. So all of those we've covered in today's CISSP cyber training podcast Amazing, I know, it's totally amazing, right? Okay, I'm going to get up and wake up and it's pretty cool. So if you have any questions, head on over to CISSP cyber training. Got some great products over there for you. Also have some a lot of free stuff that's available to you as well, and you'll have. If you go on to my blog, you'll be seeing this podcast. The video of it will be posted out there as well. So there's a lot of great stuff available for you in your studying endeavor to get access to the CISSP and to pass the dog on CISSP exam. Just had an individual mind Just passed, just gave me, sent me an email yesterday going she passed and she's pretty fired up about that. So that's pretty cool. All right, I hope you guys have a wonderful day and we will catch you on the flip side, see ya.