#10 Lection

Lecturer: Akhmedova Nozima

 Access control includes next:
 - Identification
 - Authentication
 - Authorization.
 • Authorization is the process of allowing a user who has
successfully authenticated to perform actions on the
system.
 • The concept of authorization is also often used as a
synonym for the concept of access control.
Access control is the determination of an subject’s ability
to work on an object.

Subject can be human, program, process and e.t.c.

Object can be data, source, process and e.t.c.
 There are following models of access control:
 Discretionary access control, DAC;
 Mandatory access control, MAC;
 Role-based access control, RBAC;
 Attribute-based access control, ABAC
 In the system, these models of use do not need to be used
separately from each other, the combination of them can also be
used.
 Discretionary access control (DAC) is a type of security
access control that grants or restricts object access via an
access policy determined by an object's owner group and/or
subjects.
 DAC mechanism controls are defined by user identification
with supplied credentials during authentication, such as
username and password.
 This type of control is discretionary in the sense that
subjects can manipulate it, because the owner of a
resource, in addition to the security administrator, can
identify who can access the resource and with what
authority. In other words, the owner determines object
access privileges.
 In DAC, each system object (file or data object)
has an owner, and each initial object owner is
the subject that causes its creation. Thus, an
object's access policy is determined by its
owner.
 A typical example of DAC is Unix file mode,
which defines the read, write and execute
permissions in each of the three bits for each
user, group and others.
 User may transfer object ownership to another user(s).
 User may determine the access type of other users.
 After several attempts, authorization failures restrict user
access.
 Unauthorized users are blind to object characteristics, such
as file size, file name and directory path.
 Object access is determined during access control list (ACL)
authorization and based on user identification and/or
group membership.
 Pros  Cons
 User-friendly — Users can Low level of data protection —
manage their data and quickly DAC can’t ensure reliable
access data of other users. security because users can
share their data however they
 Flexible — Users can configure
data access parameters without like.
administrators.  Obscure— There’s no
centralized access management,
 Easy to maintain — Adding
new objects and users doesn’t so in order to find out access
take much time for the parameters, you have to check
each ACL.
administrator.
 Granular — Users can configure
access parameters for each piece
of data.
 DAC allows for a lot of flexibility and decreases the load on system administrators
as users can manage access on their own. On the other hand, it doesn’t provide
a high level of security for several reasons:
 If user 1 shares access rights with user 2, there’s no guarantee that user 2 needs
this access to work or won’t steal or corrupt data or grant access to a malicious
user.
 It’s impossible to control information flows inside the network.
 It’s impossible to enforce the principles of least privilege, need to know, and
separation of duties.
 Because of these limitations, DAC can’t be used by organizations that work
with extremely sensitive data (medical, financial, military, etc.).
 At the same time, DAC is a good choice for small businesses with limited IT
staff and cybersecurity budgets. It allows for sharing information and ensures
the smooth operation of the business. This approach, when applied in an
organization with 10 to 20 employees, lacks the complexity and oversight
challenges associated with the use of DAC in organizations with hundreds or
thousands of employees.
 Mandatory access control (MAC) is a model of access
control where the operating system provides users with
access based on data confidentiality and user
clearance levels. In this model, access is granted on
a need to know basis: users have to prove a need for
information before gaining access.
 MAC is considered the most secure of all access control
models. Access rules are manually defined by system
administrators and strictly enforced by the operating
system or security kernel. Regular users can’t alter
security attributes even for data they’ve created.
 With MAC, the process of gaining access looks like this:
 - The administrator configures access policies and
defines security attributes: confidentiality levels,
clearances for accessing different projects and types of
resources.
 - The administrator assigns each subject (user or
resource that accesses data) and object (file, database,
port, etc.) a set of attributes.
 When a subject attempts to access an object, the
operating system examines the subject’s security
attributes and decides whether access can be granted.
For example, let’s consider data that
has the “top secret” confidentiality
level and “engineering project”
security label. It’s available to a set of
users that have “top secret”
clearance and authorization to access
engineering documents. Such users
can also access information that
requires a lower level of clearance. But
employees with lower levels of
clearance will not have access to
information that requires a higher
level of clearance.
 Pros  Cons
 High level of data Maintainability — Manual
protection — An administrator configuration of security levels
defines access to objects, and and clearances requires
users can’t edit that access. constant attention from
administrators.
 Granular — An administrator
sets user access rights and Scalability — MAC doesn’t
object access parameters scale automatically.
manually.  Not user-friendly — Users
 Immune to Trojan Horse have to request access to each
attacks — Users can’t new piece of data; they can’t
declassify data or share access configure access parameters for
to classified data. their own data.
 MAC is used by the US government to secure classified
information and to support multilevel security policies and
applications. This access control model is mostly used by
government organizations, militaries, and law enforcement
institutions. It’s reasonable to use MAC in organizations that
value data security more than operational flexibility and costs.
Implementing MAC in a private organization is rare because of
the complexity and inflexibility of such a system.
 A pure MAC model provides a high and granular level of
security. On the other hand, it’s difficult to set up and maintain.
That’s why it’s common to combine MAC with other access
control models.
 Role-based access control (RBAC) is a method of restricting
network access based on the roles of individual users within
an enterprise.
 RBAC ensures employees access only information they need
to do their jobs and prevents them from accessing
information that doesn't pertain to them.
 A role in RBAC language typically refers to a group of people
that share certain characteristics, such as:
 Departments
 Locations
 Seniority levels
 Work duties
 With a role defined, you can assign permissions. Those might involve:
 Access. What can the person see?
 Operations. What can the person read? What can the person write?
Can the person create or delete files?
 Sessions. How long can the person stay in the system? When will the
login work? When will the login expire?
 All RBAC systems work like this. But the National Institute of
Standards and Technology defines four subtypes of RBAC in case
you need a bit more flexibility.
 Flat:All employees have at least one role that defines
permissions, but some have more than one.
 Hierarchical: Seniority levels define how roles work together.
Senior executives have their own permissions, but they also have
those attained by their underlings.
 Constrained: Separation of duties is added, and several people
work on one task together. This helps to ensure security and
prevent fraudulent activities.
 Symmetrical: Role permissions are reviewed frequently, and
permissions change as the result of that review.
 These roles build upon one another, and they can be arranged
by security level.
 Level 1, Flat: This is the least complex form of RBAC.
Employees use roles to gain permissions.
 Level 2, Hierarchical: This builds on the Flat RBAC rules, and
it adds role hierarchy.
 Level 3, Constrained: This builds on Hierarchical RBAC, and
it adds separation of duties.
 Level 4, Symmetrical: This builds on the Constrained RBAC
model, and it adds permission reviews
 Attribute-based access control is a model that evolved from RBAC.
This model is based on establishing a set of attributes for any element
of your system. A central policy defines which combinations of user
and object attributes are required to perform any action.
 Someone logs into your computer system. What can that person do?
ABAC protocols answer that question via the user, the resource
attributes, or the environment.
 As the administrator of a system using ABAC, you can set permissions
by:
 User. A person's job title, typical tasks, or seniority level could
determine the work that can be done.
 Resource attributes. The type of file, the person who made it, or the
document's sensitivity could determine access.
 Environment. Where the person is accessing the file, the time of day,
or the calendar date could all determine access.
Unlike in RBAC, in ABAC you can even use attributes that aren’t yet registered
in the system but will appear during the work process.
 This approach is suitable for a company of any size but is
mostly used for large organizations. ABAC requires more time
and effort than RBAC at the deployment and configuration
stage, as security administrators need to define all attributes of
the system. At first, you need to assign attributes to each
system component manually.
 But once you’ve created policies for most common job positions
and resources in your company, you can simply copy them for
every new user and resource. This is similar to how a role
works in the RBAC model, but in the ABAC model, attributes
can be modified for the needs of a particular user without
creating a new role. Attributes make ABAC a more fine-
grained access control model than RBAC.
 The XACML policy language is as expressive as a naXACML is a standard that
defines a declarative fine-grained, attribute-based access control policy language,
an architecture, and a processing model describing how to evaluate access
requests according to the rules defined in policies. Vendors may implement ABAC
through XACML.
 XACML is structured into 3 levels of elements: PolicySet, Policy, Rule.
 A policy set can contain any number of policy elements and policy set elements. A
policy can contain any number of rule elements.
 Policies, policy sets, rules and requests all use subjects, resources, environments,
and actions.
 A subject element is the entity requesting access. A subject has one or more
attributes.
 The resource element is a data, service or system component. A resource has one
or more attributes.
 An action element defines the type of access requested on the resource. Actions
have one or more attributes.
 An environment element can optionally provide additional information.
 The XACML policy language is as expressive as a natural language. For
example, consider the following sentence:
 Jane Doe wants to view a confidential document at work during regular
business hours.
 A sentence like this includes four grammatical building blocks:
 – a subject
 – an action
 – a resource
 – the environment in which the request is made
 Each of these “building blocks” can be described using attributes:
Term Definition Examples

Subject Who or what is demanding access to an Roles, group memberships, the

information asset. department/company to which the user
belongs, management level,
certifications or competencies, user ID

Action Action the subject wants to perform. Read and write are common values.
More complex scenarios, like a bank
transfer, may use multiple attributes such
as “action type=transfer” and
“amount=$500”.

Resource The information asset or object impacted For banking, the resource may be “debit
by the action. account=<your account number>.” In law
firms, a resource could be a document
and an attribute could be “case matter =
100.”
Environment The context in which access is Current time, location from where access
requested. is requested, client type (PC,
smartphone, etc.), type of
communication channel (I.E. protocol or
encryption strength)
 Now let’s define the authorization requirements for Jane Doe’s
organization, which we will call The Organization. The
Organization has the following authorization requirements:
 Any person must have the same clearance level or higher as the
classification of the document he or she is requesting to view,
must also be working on that project, be a current employee, and
have finished the appropriate training.
 Only senior personnel with a top-secret clearance can edit records
that are classified as top secret or below, if they are working on
the project the record is part of, are a current employee, and have
finished the appropriate training.
 Junior personnel cannot view top-secret information between
20:00 and 6:00.
Short name Namespace Category Data type Value range

role com.organization.user Subject String Junior, senior

actionId com.organization.action Action String View, edit

objectType com.organization.object Resource String Record

clearance com.organization.user Subject String None, secret, top-

secret
classification com.organization.recor Resource String None, secret, top-
d secret
status com.organization.user Subject String Current, terminated

training com.organization.user Subject String X, Y, Z

training com.organization.recor Resource String X, Y, Z

d
project com.organization.recor Resource String A, B, C, D…
d
project com.organization.user Subject String A, B, C, D…

employeeId com.organization.user Subject String Alice, Bob, Carol…

recordId com.organization.recor Resource String 123,456,789…

d
 Now we need to write our authorization requirements into
attribute-based rules.
 Original requirement: Any person must have the same
clearance level or higher as the classification of the document he
or she is requesting to view, must also be working on that
project, be a current employee, and have finished the
appropriate training.
 Attribute-based rule:
A user with role==”junior” OR role==”senior” AND
user.clearance>=record.classification can actionId==”view” on
objectType==”record” if classification==”secret” AND user.project
== “record.project” AND status==”current” and record.training is
in user.training
 Original requirement: Only senior personnel with a top-secret clearance can edit
records that are classified as top secret or below if they are working on the project
the record is part of, are a current employee, and have finished the appropriate
training.
 Attribute-based rule:
 A user with the role==”senior” can actionId==”edit” if user.project
==record.project AND user.clearance>= record.classification AND
status==”current” and training == “training”
 Original requirement: Junior personnel can edit a record if their clearance is
greater than or equal to the classification of the record, if they are working on the
project the record is part of, are a current employee, and have finished the
appropriate training.
 Attribute-based rule:
 A user with the role==”junior” can actionId==”edit” if user.project==record.project
AND user.clearance>=record.classification AND user.status==”current” AND
user.training==record.training
Characteristic RBAC ABAC

+
Flexibility (For small and medium-sized +
organizations)

Scalability - +

Easy to establish roles and

Hard to establish all the policies at
permissions for a small company,
Simplicity the start, easy to maintain and
hard to maintain the system for a big
support
company

Support for simple rules + +

Support for complex rules + +

Support for rules with dynamic

- +
parameters

-
Customizing user permissions (Every customization requires +
creating a new role)

Granularity Low High

 In computer science, an Access Control Matrix or Access
Matrix is an abstract, formal security model of protection state
in computer systems, that characterizes the rights of each
subject with respect to every object in the system. It was first
introduced by Butler W. Lampson in 1971.
 It is a table in which each row represents a subject, each
column represents an object, and each entry is the set of access
rights for that subject to that object.
 The two main approaches in the field of authorization are the
Access control list (ACL) and the Capability list (C-list), both of
which are derived from Lampson’s use control matrix.
 OS Accounting Accounting Insurance Payroll
program data data data

Bob rx rx r - -

Alice rx rx r rw rw

Sam rwx rwx r rw rw

Accounting rx rx rw rw r
software
 Access control matrix has all relevant info
 But how to manage a large access control (AC) matrix?
 -Could be 1000’s of users, 1000’s of resources
 -Then AC matrix with 1 000 000’s of entries
 -Need to check this matrix before access to any resource is
allowed: Hopelessly inefficient
 To obtain acceptable performance, split AC into manageable
pieces;
 Two ways: by column or by row
 ACL: store access control matrix by column
 Example: ACL for insurance data is in red
OS Accounti Accounting Insuranc Payroll
ng data e data data
program
Bob rx rx r - -
Alice rx rx r rw rw
Sam rwx rwx r rw rw
Accountin rx rx rw rw r
g software

 ACL (insurance data)= {(Bob, ---), (Alice, rw), (Sam, rw),

 (Acc prog, rw)}
 Store access control matrix by row
 Example: Capability for Alice is in green
OS Account Account Insuranc Payroll
ing ing data e data data
program
Bob rx rx r - -
Alice rx rx r rw rw
Sam rwx rwx r rw rw
Accounti rx rx rw rw r
ng
software

 C-list (Aice) = {(OS,rw), (Acct prog, rw), (Acct data, r), (Insur data,
rw), (payroll data, rw)}
 Two resources: Compiler
and Bill file (billing info)
 Compiler can write file
Bill
 Alice can invoke
compiler with a debug
filename
 Alice not allowed to
write to Bill
 With Capabilities, easier to prevent problem
 Must maintain association between authority and intended
purpose
 Capabilities make it easy to delegate authority
 C-list (Alice) = {(OS,rw), (Acct prog, rw), (Acct data, r), (Insur
data, rw), (payroll data, rw)}
 ACLs
 Good when users manage their own files
 Protection is data-oriented
 Easy to change rights to a resource
 Capabilities
 Easy to delegate
 Easy to add/delete users
 Easier to avoid the confused deputy
 More difficult to implement
 Classification apply to objects
 Clearances apply to subjects
 US Department of defense uses 4 levels of
classifications/clearances
 TOP SECRET
 SECRET
 CONFIDENTIAL
 UNCLASSIFIED
 This Model was invented by Scientists David Elliot
Bell and Leonard .J. LaPadula.Thus this model is
called the Bell-LaPadula Model. This is used to
maintain the Confidentiality of Security. Here, the
classification of Subjects(Users) and Objects(Files) are
organized in a non-discretionary fashion, with respect
to different layers of secrecy.
 It has mainly 3 Rules:
 SIMPLE CONFIDENTIALITY RULE: Simple Confidentiality Rule
states that the Subject can only Read the files on the Same Layer of
Secrecy and the Lower Layer of Secrecy but not the Upper Layer of
Secrecy, due to which we call this rule as NO READ-UP
 STAR CONFIDENTIALITY RULE: Star Confidentiality Rule states
that the Subject can only Write the files on the Same Layer of
Secrecy and the Upper Layer of Secrecy but not the Lower Layer of
Secrecy, due to which we call this rule as NO WRITE-DOWN
 STRONG STAR CONFIDENTIALITY RULE: Strong Star
Confidentiality Rule is highly secured and strongest which states
that the Subject can Read and Write the files on the Same Layer of
Secrecy only and not the Upper Layer of Secrecy or the Lower Layer
of Secrecy, due to which we call this rule as NO READ WRITE UP
DOWN
 This Model was invented by Scientist Kenneth J. Biba.
Thus this model is called Biba Model. This is used to
maintain the Integrity of Security. Here, the
classification of Subjects(Users) and Objects(Files) are
organized in a non-discretionary fashion, with respect to
different layers of secrecy. This works the exact reverse
of the Bell-LaPadula Model.
 It has mainly 3 Rules:
 SIMPLE INTEGRITY RULE: Simple Integrity Rule states that
the Subject can only Read the files on the Same Layer of
Secrecy and the Upper Layer of Secrecy but not the Lower
Layer of Secrecy, due to which we call this rule as NO READ
DOWN
 STAR INTEGRITY RULE: Star Integrity Rule states that
the Subject can only Write the files on the Same Layer of
Secrecy and the Lower Layer of Secrecy but not the Upper
Layer of Secrecy, due to which we call this rule as NO WRITE-
UP
 STRONG STAR INTEGRITY RULE
Thank you for attention!