Introduction

to
Information
Security
 Introduction to Information Security

User Authentication Access Control Operating System

Storing passwords System security planning

Cracking passwords Types of Access Control Operating system hardening
Rainbow Tables and salting UNIX/LINUX Access Control Operating system patching
Token‐based Authentication Logging and backup
Access Control Definitions 1/2

NIST 7298 defines access control as:

“The process of granting or denying specific requests to:

(1) obtain and use information and related information processing

services
(2) enter specific physical facilities”
Access Control Definitions 2/2

RFC 4949 defines access control as:

“A 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 Principles

• In a broad sense, all of computer security is

concerned with access control

• RFC 4949 defines computer security as:

“measures that implement and assure security

services in a computer system, particularly those that
assure access control service”
Access Control & Security Functions

 The question is how big is it? Password is 8 Bytes + hash is 128 bits

 (8 Byte + 16 Byte) x 948 = 1.4x1017 Bytes = 146 TB (approx.)

 Instead of generating this huge amount of data we can u

Subjects, Objects, and Access Rights
General Requirements of Access Control
Access Control Policies

• Discretionary access control (DAC) • Role‐based access control (RBAC)

• Controls access based on the • Controls access based on the roles
identity of the requestor and on that users have within the system
access rules (authorizations) stating and on rules stating what accesses
what requestors are (or are not) are allowed to users in given roles
allowed to do
• Mandatory access control (MAC)
• Controls access based on comparing
security labels with security
clearances
Discretionary Access Control (DAC)
Discretionary Access Control (DAC)
Example of DAC: Access Matrix

Figure 4.2 Example of Access Control Structures

Example of DAC: Access Control List
File 1 A B C User A File 1 File 3
Own R Own Own
R R W R R
W W W
• • •

File 2 B C User B File 1 File 2 File 3 File 4

Own Own
R R R R W R
W W
• • • •

File 3 A B User C File 1 File 2 File 4

Own R Own
R W W R R
W W
• • •

File 4 B C
Own (c) Capability lists for files of part (a)
R R
W
•

(b) Access control lists for files of part (a)

Figure 4.2 Example of Access Control Structures

Example of DAC: Capability lists
File 1 A B C User A File 1 File 3
Own R Own Own
R R W R R
W W W
• • •

File 2 B C User B File 1 File 2 File 3 File 4

Own Own
R R R R W R
W W
• • • •

File 3 A B User C File 1 File 2 File 4

Own R Own
R W W R R
W W
• • •

File 4 B C
Own (c) Capability lists for files of part (a)
R R
W
•

(b) Access control lists for files of part (a)

Figure 4.2 Example of Access Control Structures

Example of Authorization Table
Role‐Based Access Control
Role‐Based Access Control Matrix
Hierarchies in RBAC
Constraints in RBAC
Constraints in RBAC
Constraints in RBAC
How does RBAC work?

• Administrators assign access permissions to roles

• Then, roles can be assigned to individual users

• Users may have one or several roles (each with different access rights)

• Administrators can simply update roles or access permissions

• By assigning users (or removing users from) to the appropriate roles

23
The Limitations of RBAC

• RBAC provides static access control configurations.

• It fails to provide a flexible mechanism by which users/entities can express their requirements.

• Limitation #1: Role Explosion

• RBAC is limited to defining access permissions by role

• An ever‐increasing number of users requires an exponentially increasing number

of roles to accommodate various permission combinations

24
The Limitations of RBAC

• Limitation #2: Toxic Combinations

• Various roles assigned to a given user could contain conflicting data.

• One user may have a role allowing him to create a purchase order, and
another allowing him to approve it.

25
The Limitations of RBAC

• Limitation #3: Management Nightmares

• Between growing numbers of users, and exponentially more roles

• Administrators have to constantly be on top of changes to users and to

roles, and ensure that role assignment combinations are current,
accurate, and not conflicting with other roles a user might be assigned.

26
The Limitations of RBAC

• Limitation #4: Lack of Context

• Due to the static nature of Role Based Access Control, RBAC is unable to
model policies that depend on contextual details:
• Time‐of‐day, location, relationship between users, etc.

• RBAC has no way of determining the relationships between users and

using that information to make policy decisions.

• At its best, RBAC was originally designed to answer just one question:
What access does a user have based on their assigned role(s)?

27
The Limitations of RBAC

 Today, defining authorization policies based on a user’s role is not good

enough.
 The context surrounding that user, their data, and the interaction between
the two are also important to provide access to
• the right user,
• at the right time,
• in the right location,
• and by meeting regulatory compliance.
 That means evolving an existing Role Based Access Control model to an
Attribute Based Access Control (ABAC) model.

28
Evolving RBAC with ABAC
 Attribute Based Access Control allows an enterprise to extend existing roles using attributes and
policies.

 By adding context, authorization decisions can be made based on:

• Role of the user

• Who or what that user is related to
• What that user needs access to
• Where that user needs access from
• When that user needs access
• How that user is accessing that information

 For example, a policy may be written as follows:

• “Doctors can view medical records of any patient in their department and update any patient record
that is directly assigned to them, during working hours and from an approved device.” 29
Attribute based access control

 Similar to RBAC in the sense that it also adopts a policy driven approach.

 Uses attributes of subjects, objects, and the environment (instead of

roles).

More suitable in adapting to dynamic access

requirements in e‐Health

30
Attribute based access control

Attributes

Action

User

Subject
Authorization Yes/No
Object Decision
Context

Policy

31
Mandatory Access Control (MAC)
Mandatory Access Control (MAC)
UNIX File Access Control
UNIX files are administered using inodes (index nodes)

• Control structures with key information needed for a particular file

• Several file names may be associated with a single inode
• An active inode is associated with exactly one file
• File attributes, permissions and control information are sorted in the
inode
• On the disk there is an inode table, or inode list, that contains the inodes
of all the files in the file system
• When a file is opened its inode is brought into main memory and stored
in a memory resident inode table

Directories are structured in a hierarchical tree

• May contain files and/or other directories

• Contains file names plus pointers to associated inodes
Protection bits in an inode
inode
inode
Contents
Permissions and Users
Permissions and Users
UNIX File Access Control
(DEMO)

ss

ss

ss
c la

c la

cla
 Unique user identification number (user ID)

er

up

er
wn

ro

th
O

O
 Member of a primary group identified by a group ID rw- r-- ---
user: :rw-
 Belongs to a specific group group::r--
other::---
 12 protection bits
(a) Traditional UNIX approach (minimal access control list)
 Specify read, write, and execute permission for the
owner of the file, members of the group and all other
users

 The owner ID, group ID, and protection bits are part of the
file’s inode