Information Security

Access Control

Mehmood ul Hassan
 Access Control

• Way of limiting access to a system or to physical

resources
• In computing, access control is a process by
which users are granted access and certain
privileges to systems, resources or information
 Access Control

• Process by which use of system resources is

regulated according to a security policy and is
permitted only by authorized entities (users,
programs, processes, or other systems)
according to that policy
 Access Control

• Prevent unauthorized users from gaining access

to resources
• Prevent legitimate users from accessing
resources in an unauthorized manner
• Enable legitimate users to access resources in
an authorized manner
 Access Control Fundamentals
• Access control
– who is allowed to do what?
– Traditionally, “who” is a person
– Traditionally, “what” consists of an operation
(read,write,execute, …) performed on a resource (file,
directory, network port, …)
– A policy specifies who is allowed to do what
 Access Control Fundamentals

• A system can protect itself in two ways

o It can limit who can access the system
o It can limit what people can do once they
access the system
 Access Control Fundamentals
• Identification
– Stating who I am Username
• Authentication
Passwords
– Verifying the identification of a subject
• Identification can be public information
but authentication should be private and
protected
• Authorization
– Assigning rights and permissions, which allows
someone to carry out its tasks
 Access Control Fundamentals
• Audit
– An independent review and examination of system
records and activities in order to
• Test for adequacy of system controls
• To ensure compliance with established policy and
operational procedures
• To detect breaches in security
• To recommend any indicated changes in control,
policy and procedures
Access Control Fundamentals
 Access Control Fundamentals
• User: person;
• User identity (principal): name used in the system,
possibly associated with a user;
• Process (subject) running under a given user identity
• Objects are things on which an action can be performed
• ‘Principal’ and ‘subject’ are both used to denote the
active entity in an access operation

• Subjects operate on behalf of human users or

principals
 Access Control Fundamentals
• User enters username and password

• If the values entered are correct, the user is

“authenticated”

• We could say: “The machine now runs on behalf of

the user”

• Log on creates a process that runs with access rights

assigned to the user

• Typically, the process runs under the user identity

of the user who has logged on
 Reference Monitor
• Reference Monitor is a guard for each object
that examines each request for the object and
decides whether to grant it
• The reference monitor bases its decision
o Principal making the request

o The operation in the request

o An access rule that controls which principals

may perform that operation on the object
 Reference Monitor
o Requirements

o Source of the request

o Authentication

o The access rule

o Authorization
 Reference Monitor
• It must be impossible to bypass

• It must be tamperproof

• It must be properly implemented

 Authorisation
• Reference monitor decides whether access is
granted or denied

• Reference monitor has to find and evaluate the

security policy relevant for the given request

• “Easy” in centralized systems

• In distributed systems,
– how to find all relevant policies?

– how to make decisions if policies may be missing?

 Types of Access Control

• Discretionary Access Control (DAC, IBAC)

• Mandatory Access Control (MAC)
• Originator Controlled Access Control
(ORCON or ORGCON)
• Role Based Access Control (RBAC)
• Attribute Based Access Control (ABAC)
 Types of Access Control

• Discretionary Access Control (DAC, IBAC)

– Individual user sets access control to allow or
deny access to an object
– Also called identity based access control

– Based on identity of subject and object

Types of Access Control
Let's say you have a shared folder on your company's
network that contains sensitive financial information.
With DAC, you can control who has access to that folder
and what level of access they have.
You might set up the following permissions for the folder:
• John, who is the financial analyst, has full access to the folder
because he needs to be able to create, read, modify, and delete
files.
• Sarah, who is the marketing coordinator, has read-only access to
the folder because she doesn't need to modify or delete any files,
but she does need to be able to view them for marketing
purposes.
• Dan, who is the IT support specialist, has no access to the folder
because he doesn't need to see the financial information and
doesn't have a business need to access it.
 Types of Access Control
• Mandatory Access Control (MAC)
– System mechanism controls access to object,
and individual cannot alter that access
– Also known as rule based access control

– Based on authorization not identity

Types of Access Control
Let's say you work for a government agency that deals with
highly classified information, and your organization uses
MAC to control access to this information.
Each user has a security clearance level, which determines
the level of access they have to the classified information.
The clearance levels are based on factors such as the
user's job role, the sensitivity of the information they
handle, and the level of risk associated with their access.
In this example, users might have clearance levels ranging
from "Top Secret" to "Secret" to "Confidential.“
In MAC, the access controls are mandatory, which means
that users do not have the discretion to change them. The
access controls are enforced by the system itself, rather
than by the user
 Types of Access Control
• Originator Controlled Access Control
(ORCON or ORGCON)
– Originator of information controls who can access
information
– The owner has no control over who accesses the info

– Allows the originator/ creator to control

dissemination of info
 Types of Access Control

Secretary
Defense
 ORCON
• Problem: organization creating document
wants to control its dissemination
– Example: Secretary of Agriculture writes a memo
for distribution to her immediate subordinates,
and she must give permission for it to be
disseminated further. This is “originator
controlled” (here, the “originator” is a person).
 Requirements
• Subject s ∈ S marks object o ∈ O as ORCON
on behalf of organization X. X allows o to be
disclosed to subjects acting on behalf of
organization Y with the following restrictions:
1. o cannot be released to subjects acting on
behalf of other organizations without X’s
permission; and
2. Any copies of o must have the same restrictions
placed on it
 DAC Fails
• Owner can set any desired permissions
– This makes 2 unenforceable
 MAC Fails
• First problem: category explosion
– Category C contains o, X, Y, and nothing else. If a
subject y ∈ Y wants to read o, x ∈ X makes a copy o′.
Note o′ has category C. If y wants to give z ∈ Z a copy,
z ∈ Z must be C
– Suppose a member w of an organization W wants to
provide access to a document d to members of
organization Y, but the document is not to be shared
with members of organization X or Z. d cannot be in
category C
– a new category C′ containing o, Y, W.
 MAC Fails
• Second problem

– MAC classification, categories centrally controlled, and

access controlled by a centralized policy

– ORCON controlled locally

 Solution
• The owner of an object cannot change the access
controls of the object
• When an object is copied, the access control
restrictions of that source are copied and bound to
the target of the copy
– These are MAC (system controls the accesses)
• The creator (originator) can alter the access control
restrictions on a per-subject and per-object basis
– This is DAC
Role Based Access Control (RBAC)
• Access depends on function, not identity
– Example:
• Ahmed, bookkeeper for Math Dept, has access
to financial records.
• He leaves.
• Ali hired as the new bookkeeper, so he now
has access to those records
– The role of “bookkeeper” dictates access, not
the identity of the individual
 Definitions
• Role r : collection of job functions
– trans(r): set of authorized transactions for r
• Active role of subject s: role s is currently in
– actr(s)
• Authorized roles of a subject s: set of role is
authorized to assume
– authr(s)
• canexec(s, t) iff subject s can execute
transaction t at current time
 Axioms
• Let 'S' be the set of subjects and 'T' the set of
transactions.
• Rule of role assignment:
(∀s ∈ S)(∀t ∈ T) [canexec(s, t) → actr(s) ≠ ∅].
– If s can execute a transaction, it has a role
– This ties transactions to roles
• Rule of role authorization:
(∀s ∈ S) [actr(s) ⊆ authr(s)].
– Subject must be authorized to assume an active role
(otherwise, any subject could assume any role)
 Rule of Role Assignment
The first rule, "if a subject can execute a transaction, it
has a role," implies that in RBAC, roles are associated
with transactions. This means that each transaction in
the system is associated with one or more roles, and
only users who have been assigned those roles can
execute those transactions. This helps to ensure that
only authorized users are allowed to access the
resources and perform the operations associated with
each transaction.
 Rule of Role Authorization
The second rule, "a subject must be authorized to assume
an active role," implies that in RBAC, each subject must
be authorized to assume the active roles associated with
the transactions they want to execute. This means that
the system administrator must explicitly authorize each
user to assume each role associated with the transactions
they are allowed to perform. This ensures that users
cannot assume roles that they are not authorized to
perform, which helps to prevent unauthorized access
and misuse of system resources.
 Axiom
• Rule of transaction authorization:
(∀s ∈ S)(∀t ∈ T)
[canexec(s, t) → t ∈ trans(actr(s))].
– If a subject s can execute a transaction, then the
transaction is an authorized one for the role s has
assumed
Rule of transaction authorization

When a user assumes a particular role, they are

granted a set of permissions that allows them to
perform certain operations on the resources
associated with that role. The canexec(s, t)
condition in the rule indicates that subject s is
authorized to execute transaction t, which means
that s has been assigned the appropriate roles to
access the resources associated with t.
 Containment of Roles
• Trainer can do all transactions that trainee can do (and
then some). This means role r contains role r′ (r > r′ ).
So:
(∀s ∈ S)[ r′ ∈ authr(s) ∧ r > r′ → r ∈ authr(s) ]

this rule is related to the concept of containment

of roles in the Role-Based Access Control
(RBAC) model. Containment of roles refers to the
relationship between roles, where a role can
contain another role as a subset. In the context of
RBAC, this relationship can be used to specify
that users who are assigned to a higher-level role
 Separation of Duty
• Let r be a role, and let s be a subject such that
r ∈ auth(s)
• meauth(r) is the set of roles that s cannot
assume because of the separation of duty
requirement
• Separation of duty:
(∀r1, r2 ∈ R) [ r2 ∈ meauth(r) →
[ (∀s ∈ S) [ r1∈ authr(s) → r2 ∉ authr(s) ] ] ]
 Separation of Duty
This rule is related to the concept of separation of duty in the Role-
Based Access Control (RBAC) model. Separation of duty is a
security principle that involves dividing a task or function into
multiple parts and assigning those parts to different people or
roles, in order to prevent any single person or role from having
too much control or access to sensitive resources.
the rule ensures that if a subject is authorized to assume a particular
role, they are not also authorized to assume any other roles that
conflict with that role due to separation of duty requirements.
This helps to prevent conflicts of interest and limit the potential
for abuse of privileges or access to sensitive resources
Attribute Based Access Control (ABAC)
• Access depends on policy
– Also known as policy-based access control
– Access rights are granted through the use of
policies which combine attributes together.
o Type of attributes
• user attributes
• resource attributes
• Object
• environment attributes etc.
 ABAC
ABAC is a dynamic model that allows for more
granular access control based on specific
attributes. This allows organizations to define
policies that take into account the unique
requirements of each user and resource, and to
adjust access control decisions in real time based
on changing conditions.
 Activity 1
Scenario 1: A university wants to restrict access to
its student records system, which contains
sensitive information such as grades, transcripts,
and personal data. Which access control model
would you recommend?
RBAC would be a good fit for this scenario, as it
would allow the university to define roles for
different types of users (e.g. faculty, staff,
students) and assign permissions based on those
roles. For example, faculty members might be
allowed to view student grades, while students
would only be allowed to view their own grades.
 Activity 2
Scenario 2: A hospital wants to control access to
its electronic health records system, which
contains confidential patient information such as
medical histories, diagnoses, and treatment
plans. Which access control model would you
recommend?
Scenario 2: ABAC would be a good fit for this
scenario, as it would allow the hospital to define
policies based on specific attributes such as the
patient's medical history, the healthcare
provider's role, and the sensitivity of the data
being accessed. For example, a doctor might be
allowed to view a patient's entire medical history,
while a nurse might only be allowed to view
basic information such as vital signs.
Other types

https://en.wikipedia.org/wiki/Attribute-
based_access_control