5.4 Implement and manage authorization mechanisms
- Role Based Access Control (RBAC)
- Rule-based access control
- Mandatory Access Control (MAC)
- Discretionary Access Control (DAC)
- Risk based access control
There are different models for access control in an organization. The specific control chosen depends on the needs of the organization, the type of data being protected, and the type of users. An organization may implement multiple access control models.
Access Control permissions usually relate to being able to read, write, delete, and/or modify a file, and list contents of a folder. Additional, more extensive permissions, can apply to a database (such as the ability to read, write, delete, or modify entries in a database, create tables in a database, or create users in the database).
The permissions can apply to the entire system or granularly to specific files.
MAC – Mandatory Access Control
- Each user has certain permissions on the system
- The user cannot grant his permissions to other users
- For example, if a user has read access to a file, the user cannot grant another user with read access to the file
- The user cannot modify any of the permissions on the file
DAC – Discretionary Access Control
- A user has certain permissions
- The user can grant his permissions to other users
- For example, if a user has read access to a file, the user can grant another user with read access to the file
- An example of when DAC is better than MAC: a project manager has access to files related to his projects; the project manager grants access to other members of the team. The project manager does not have to contact an IT person to obtain access for members of his team.
- An example of when MAC is better than DAC: an intelligence analyst needs to grant a co-worker access to classified documents; the analyst should not be able to do so; the individual requesting access must have a need-to-know basis and appropriate security clearances, which need to be verified by a central authority
ABAC – Attribute-Based Access Control
- Each user has certain attributes (for example, the user’s role in the organization, age, security clearance, department, etc.)
- Each resource has certain attributes (for example, the contents, department, owner, etc.)
- When the user attempts to access the resource, the system uses the user’s attributes and the resource’s attributes to determine whether to provide access.
- ABAC is more complicated because the system requires many rules to decide whether to permit/deny a user. If a rule does not exist, then the default action is to deny the access. It might take a substantial amount of work to set up all the rules.
Role-Based Access Control
- Permissions are not assigned to individual users or to objects
- Permissions are assigned to operations/actions (known as roles)
- A user can be assigned to a specific role; the user inherits the permissions assigned to the role
- The organization can define the operations and actions that are relevant to their organization. For example:
- Sales person (can access sales data)
- Accountant (can enter data into the accounting system)
- Accounts payable clerk (can approve invoices and issue payments)
- Sales person (can access sales data)
Rule-Based Access Control
- Permissions are not assigned to individual users or objects
- Instead, a set of rules exist; the rules may permit or deny specific actions depending on the attributes
- Each time an action is attempted, the system evaluates the action against the set of rules
- The rules do not consider who is attempting the action, only what the action is
Conditional Access
- We can use AI to make more complicated access decisions when a user needs to access a resource. This might also be called Risk Based Access Control.
- Some factors that the AI might consider
- User role. Does the user have permission to access this resource?
- IP address. Where is the user currently located?
- Device type. Is the user attempting to access the resource from a smartphone, a corporate device, or a personal device?
- Application type. What application is the user attempting to access?
- Risky sign in behavior.
- User role. Does the user have permission to access this resource?
- AI and machine learning can gather data over time to create a threat assessment that can more accurately predict whether access to a resource is legitimate.
Privileged Access Management
- Privileged Access Management determines whether a user account can access a privileged resource
- We might create a set of privileged user accounts for use by administrators. An administrator might have a privileged account in additional to his normal user account.
- We can apply the same AI rules to privileged accounts that we did to regular accounts.
Some more ideas about access control
- Permission – what you can do with an object (read, write, execute)
- Right – ability to act on a system, such as modify settings. Permissions and rights are usually interchangeable.
- Privilege – a combination of rights and permissions granted to a user.
- Implicit Deny – users are normally denied rights to everything unless they are specifically granted access.
- Access Control Matrix – a table with subjects (a user), objects (a file) and privileges. When a subject takes action on an object, we check the matrix to see if he has permission.
- Capability Table – a table that shows us a list of subjects and what objects each subject has permission to access or modify
- Constrained Interface – a constrained interface is where an application an restrict what a user can see or do based on their permissions. We might want to hide functions that a user doesn’t have access to – they shouldn’t even know that those functions exist.
- Content-Dependent Control – restricts access to data based on the content within the object
- Context-Dependent Control – requires a user to engage in specific activity before showing additional data. For example, restricting access based on the date/time
- Need to Know – subjects are only granted access to data based on a need to know – we only give you access to data that you need to perform your job, even if you have the clearance or right to see the data