From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Least privilege

From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Start my 1-month free trial Buy for my team

Least privilege

“

- [Instructor] When it comes to technology, most of us want convenience. We just want things to work. But convenience and security are often at odds. If you open up every port on a network firewall, you won't get any calls from users about the firewall blocking their applications, but you also won't stop any criminals from waltzing right into your network. So how do you strike the right balance between convenience and security? One way is by following the Principle of Least Privilege. The concept of least privilege means that your users get just enough access to do their jobs and nothing more. It sounds simple, right? In theory, sure. But in practice, not so much. Organizations change over time and so does the access that they give their employees. The earliest employees wear multiple hats, so they're given all the access they need. Their accounts are over entitled. When new employees come on board, their accounts are often cloned using the existing over-entitled accounts as source material. The end result is a violation of the principle of lease privilege. There are a handful of models that you can use to determine how you want to grant subjects access to objects. Three of the most common models are: mandatory access control, discretionary access control, and nondiscretionary access control. You may have heard of role-based access controls, or RBAC. You can make any of these models work within the RBAC model, although each of these three models is a little different. Mandatory access control focuses on granting subjects access to objects based on the data classification of those objects. You frequently see this access control model in the federal space. Objects are assigned a label, like top secret or secret, and then subjects who have been given the same level of clearance are the only ones authorized to access that data. Mandatory access control models grant people access to data on a need-to-know basis. Discretionary access control leaves the decision of who should have access to what up to the resource owner. In this model, access is determined based on a person's identity. Managing access on a person-by-person basis may work for smaller systems, but you can use role-based access controls when you want to apply this model at scale. Nondiscretionary access control takes the human element out of the decision making process. Policy is policy, and the same policy applies to everyone who has been granted access to your app. Another way of thinking of this is in the terms of role-based access controls, except the app only has one role, authorized user. If you have that role, you can log in and access the data. Otherwise, you're out of luck. Privilege doesn't have to be granted on a constant basis though. You can also choose to grant and revoke privilege each time a process within your app is properly executed. This concept is known as run-time privilege. By implementing this additional layer of access control, you could reduce the potential damage an attacker might do if they try to misuse privilege outside of its designed purpose. Another way to minimize privilege creep is to embrace the idea of zero trust. In this approach, you assume everything, and I mean everything, cannot be trusted. When a user or device wants to access a resource, you validate that the access request is appropriate. In this model, the notion of trust but verify becomes never trust, always verify. When you implement access controls in a way that they work without getting in the way, your users may not even realize that those controls are there. When someone does try to circumvent those access controls, whether that someone is an unauthorized outsider or a malicious insider, they'll realize pretty quickly that you've done this least privilege thing right.

Contents