Section 7.1 General Principles and Techniques
Access controls seek to provide tools for identification, authentication, authorization, and accounting with regard to a particular resource. While individual controls may provide multiple parts, it is still important to understand what each part represents:
Identification: The act of identifying an actor or something that is used to identify an actor. This could be as simple as a drivers license or as complex as a cryptographic signature that can only be made by the bearer of a private key. Example: A delivery driver presenting an employee badge.
Authentication: This step occurs when an identity is confirmed through the use of a specific process. This could be the process through which the private key is used or perhaps another biometric process such as reading a fingerprint. In either case the authentication is the method by which we verify identity. Example: Examining the delivery driver’s badge.
Authorization: Authorization is when an actor is given permission to access a resource. In casual conversation we may assume that authorization is a foregone conclusion once an actor has progressed this far, but in actuality authorization relies on the previous steps being completed and may in fact fail. A system may have identified who someone was through authentication with a username and password, but that user is not set up to have access to a resource. In this case the authorization step would fail. To continue with our delivery driver example: Allowing the delivery driver to pick up a package.
Accounting: Finally accounting is the process through which a record of access to the resource is recorded. Accounting may be a log of users who have signed in an log of what resources they each accessed. In a similar vein, with the delivery driver: A record of the driver’s visit is written in the sign-in book at the front desk.
Subsection 7.1.1 Least Privilege
The principle of least privilege states that an actor should only be given access to resources as necessary and with the permissions necessary to complete their task. These resources may be processes, programs, or even user accounts. This principle reduces an attack surface and helps stop the spread of malware as a single compromised account will not have access to all of the resources.
Least privilege is also an important concept for compliance purposes. For example, laws may require and audit of all accounts that have Internet access. By limiting accounts that have Internet access to only the accounts of actors that require Internet access to complete their tasks, it makes it easier to be in compliance.
Subsection 7.1.2 Multi-factor Authentication (MFA)
Multi-factor authentication is a technique that requires actors to provide two or more pieces of information to be used as identification. Some examples of identification would be usernames and passwords, token codes, a physical token, or biometric data. Typically it is suggested to use "something you have and something you know" for example the code in an SMS message to your phone (you have your phone) and a password (you know your password).
There are many popular products for MFA, most of which are based on the time based creation of a code. Google Authenticator and Authy are each phone applications which generate codes from a cryptographic seed which is synced with the verifying system. RSA IDs generate similar codes on a dedicated hardware device.
1
play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en_US&gl=US2
authy.com/Subsection 7.1.3 MAC, DAC, RBAC, and ABAC
There are several different authorization models that can be used.
Subsubsection 7.1.3.1 MAC
Mandatory Access Control (MAC) requires all objects (files, directories, devices, etc.) to have a security label that identifies who can access it and how. This is a particularly stringent form of access control which requires a great deal of effort to implement and maintain, but results in a high level of security.
Subsubsection 7.1.3.2 DAC
Discretional Access Control (DAC) simplifies things by allowing owners of objects to determine which permissions groups/users should be given to that object. This offers great flexibility and ease of implementation, but can result in a less secure environment if the owner of the object is compromised.
Subsubsection 7.1.3.3 RBAC
Role-Based Access Control (RBAC) builds off of DAC uses a core set of roles within a system to determine who has different levels of access to objects. RBAC is a common and flexible model which can be intelligently used to implement DAC or MAC.
Subsubsection 7.1.3.4 ABAC
Attribute-Based access control (ABAC) is a newer model that builds off of RBAC and uses more general attributes instead of just roles. ABAC can determine who has different levels of access to objects based on the attributes of the object, the user, the action, or even an external context.
These attributes can be used together in any way that can be codified into a rule. For example, "Give Fred read access to non-classified documents in this folder from 9:00AM to 5:00PM."
| Factors | DAC | MAC | RBAC | ABAC |
|---|---|---|---|---|
| Access Control to Information |
Through owner of data |
Through fixed rules |
Through roles |
Through attributes |
| Access Control Based on |
Discretion of owner of data |
Classification of users and data |
Classification of roles |
Evaluation of attributes |
| Flexibility of Accessing Information |
High | Low | High | Very high |
| Access Revocation Complexity |
Very complex | Very easy | Very easy | Very easy |
| Support for Multilevel Database System |
No | Yes | Yes | Yes |
| Used in |
The initial Unix system |
The U.S. Department of Defense |
The ATLAS experiment in CERN |
The U.S. Federal government |
3
Khalaf, Emad. (2017). A Survey of Access Control and Data Encryption for Database Security. journal of King Abdulaziz University Engineering Sciences. 28. 19-30. 10.4197/Eng.28-1.2. Reproduced under license: CC BY-NC 4.0
You have attempted 1 of 1 activities on this page.
