1. Access Control: Part I Chao-Hsien Chu, Ph.D.
College of Information Sciences and Technology
The Pennsylvania State University
University Park, PA 16802
Theory 
Practice
Learning by
Doing
IST 515

2.  Human Body Analogue Security Planning Laws & Regulations
Security Policy
Security & Risk Management
Laws & Regulations
Business Continuity 
Access Control
Cryptography
Security Architecture
Communication Network
Systems Development
Software Security
Database Security
Physical Security
Application Security
Operations Security
Web Security
Computer forensics
Disaster recovery
Vulnerabilities
Threats
Risks

3. Environmental Security
Organizational
Security Policy
Organizational
Design
Security Management
Asset Classification
and Control
Access Control
Compliance
Personnel Security
Awareness Education
Physical and
Environmental Security
System Development
and Maintenance
Communications &
Operations Mgmt.
Business Continuity
Management
Operational

4. Objectives Describe the access control concepts and methodologies.
Identify access control security technologies, tools and measures.
Know the potential risks, vulnerabilities, and exposures.
Describe the auditing mechanisms for analyzing behavior, use, and contents of the information systems.

5. Readings
Stallings, W. and Brown, L., Computer Security: Principles and Practice, Prentice-Hall, Chapter 4. (Required).
Tipton, H. and Henry, K. (Eds.), Official (ISC)2 Guide to the CISSP CBK, Auerbach, Domain 2 (Required).
Sandhu, R. S. and Samarati, P., “Access Control: Principles and Practice,” IEEE Communication Magazine Sept. 1994, pp
NIST, RBAC Case Studies.
Schaad, A., Moffett, J. and Jacob, J., “The Role-Based Access Control System of a European Bank: A Case Study and Discussion,” SACMAT 2001: 6th ACM Symposium on Access Control Models and Technologies, Chantilly, VA.
Evered, M. and Bögeholz, S., “A Case Study in Access Control Requirements for a Health Information System,” Australasian Information Security Workshop 2004 (AISW 2004), Dunedin, New Zealand.

6. Security Principles
Confidentiality prevents unauthorized disclosure of systems and information.
Integrity prevents unauthorized modifications of systems and information.
Availability prevents disruption of service and productivity.
Access Controls are the security features that control how users and systems communicate and interact with one another.
All references are from All in One Book (Shon Harris, 2005)
Three main security principles for any type of security control are: (p124)
Availability: Information, systems, and resources need to be available to users in a timely manner to not effect productivity. (p125)
Fault tolerance and recovery mechanisms are put into place to ensure the continuity of the availability of resources. (p125)
Information has various attributes such as accuracy, relevance, timeliness, and privacy (etc.). (p125)
Integrity: When a security mechanism provides integrity, it protects the data/resource from being altered in any unauthorized fashion. (p125)
Confidentiality: The assurance that information is not disclosed to unauthorized individuals, programs, or processes. (p126)
Because of various levels of data, control mechanisms need to dictate who can access data and what the subject can do with it once it is accessed. (p126)
Some security mechanisms that provide confidentiality are encryption, logical and physical access control, transmission protocols, database views, and controlled traffic flow. (218)

7. Context of Access Control
Authorization
Database
Security
Administrator
System
Resources
Access
Control
Authentication
Authentication
Function
Access
Control
Function
User
Auditing

8. Access Controls Overview
Controlling access to facilities, systems, services, resources, and data is critical to any security program.
Access control is the backbone (central element) of information security
Access controls (AC) are a collection of mechanisms that work together to protect the assets of the enterprise. They help protect against threats and vulnerabilities by reducing exposure to unauthorized activities and providing access to information and systems to only those who have been approved.

9. Access Controls Overview
AC enables management to:
- Specify which users can access the system
- Specify what resources they can access
- Specify what operations they can perform
- Provide individual accountability.
Access controls encompass all aspects and levels of an organization:
- Facilities
- Support systems
- Information systems
- Personnel – management, users, customers, partners, etc.

10. Access Control Elements
Subject - entity that can access objects:
- A process representing user/application
- Often have 3 classes: owner, group, world
Object - access controlled resources:
- e.g. files, directories, records, programs etc.
- Number/type depend on the environment
Access right - ways in which subject accesses an object:
- e.g. read, write, execute, delete, create, search
The basic elements of access control are: subject, object, and access right.
A subject is an entity capable of accessing objects, usually a process. Any user or application actually gains access to an object by means of a process that represents it. A subject is typically held accountable for the actions they have initiated, and an audit trail may be used to associate with a subject and security-relevant actions performed on an object. Basis access control systems typically define three classes of subject:
• Owner: This may be the creator of a resource, such as a file. For system resources, ownership may belong to a system administrator. For project resources, a project administrator or leader my be assigned ownership.
• Group: In addition to the privileges assigned to an owner, a named group of users may also be granted access rights, such that membership in the group is sufficient to exercise these access rights.
• World: The least amount of access is granted to users who are able to access the system but are not included in the categories owner and group for this resource.
An object is any resource to which access is controlled. In general, and object is an entity used to contain and/or receive information. Examples include records, blocks, pages, segments, files, portions of files, directories, directory trees, mailboxes, messages, and programs. The number and types of objects to be protected by an access control system depends on the environment in which access control.
An access right describes the way in which a subject may access an object. Access rights could include the following: read, write, execute, delete, create, search.

11. Example of Access Permissions
No Access/Null
No access permission granted
Read (R)
Read but make no changes
Write (W)
Write to files; includes change capability
Execute (X)
Execute a program
Delete (D)
Delete file
Change (C)
Read, write, execute and delete; may not change file permission
Full Control
All abilities; including changing access control permission

12. Access Control Requirements
Reliable input: All inputs to the access control system must be reliable.
Support for fine and coarse specifications, allowing access to be regulated at the level of individual records in files, and individual fields within records.
Least privilege. Access control should be implemented so that each entity is granted the minimum system resources and authorizations that the entity needs to do its work.
Separation of duty. A practice of dividing the process in a system functions among different individuals so as to keep a single individual from subverting the process.

13. Access Control Requirements
Open and closed policies. The typical class of access control policies are closed policies. However, in some applications, it may also be useful to allow an open policies for some classes of resources.
Policy combinations and conflict resolution. An access control mechanism may apply multiple policies to a given class of resources. In case, if conflict exists, a conflict resolution procedure must be defined.
Administrative policies. Administrative policies are needed to specify who can add, delete, or modify authorization rules.
Dual control. In some cases, a task may require two or more individuals working in tandem.

14. Types of Access Controls
Discretionary
AC Policy
Mandatory
AC Policy
Role-based
AC Policy

15. Types of Access Controls
Discretionary access control (DAC): A system that uses discretionary access control allows the owner of the resource to determine who has access and what privileges they have. Access control is at the discretion of the owner.
Mandatory access control (MAC): The system applies controls based on privilege (or clearance) of a subject (or user) and the sensitivity (or classification) of an object (or data). This model is used in environments where information classification and confidentiality is very important.
Role-based access control (RBAC): Control access based on the roles (functions) that users have within the system and on rules stating what accesses are allowed to users in given roles.

16. Access Control Techniques
Access Control Matrix
Access Control List (ACL)
Capability Table
Content Dependent Access Control
Context Dependent Access Control
Constrained User Interfaces
Rule Based Access Control
Temporal (Time-based) Isolation

17. Access Control Matrix
Is a table of subjects and objects indicating what access right each individual subject has to objects.
A matrix is a data structure that programmers implement as table lookups that will be used and enforced by the operating system.
Objects
File 1
File 2
File 3
File 4
User A
Own
Read
Write
User B
User C
Subjects

18. Access Control List
ACL is a list of subjects that are authorized to access a specific object and it define what levels of authorization is granted.
It was decomposed by column from an access control matrix.
File 1
File 2 A
Own R W  B R  C R W B
Own R W  C R
File 3
File 4 A
Own R W  B W B R  C
Own R W

19. Capability Lists
A capability table specifies the access rights a certain subject processes pertaining to specific objects. A capacity can be in the form of a token, ticket or key.
It was decomposed by row from access control matrix.
User A
User C
File1
Own R W 
File3
Own R W
File1 R W 
File2 R 
File4
Own R W
User B
File1 R 
File2
Own R W 
File3 W 
File4 R

20. Access Control List
ACL specifies a list of users who are allowed access to each object.
Mary:
UserMary Directory: Full control
UserBob Directory: Write
UserBruce Directory: Write
Printer 001: Execute
Bob:
UserMary Directory: Read
UserBob Directory: Full control
Bruce:
UserMary Directory: Null
UserBob Directory: Write
UserBruce Directory: Full control
Printer 001: Execute
Sally:
UserBob Directory: Null
UserBruce Directory: Null
Printer 001: Null

21. Authorization Table Sorting Subjects = Capacity Tables Sorting Objects
Access Right
Object A
Own
File 1
Read
Write
File 3 B
File 2
File 4 C
Sorting
Subjects =
Capacity
Tables
Sorting
Objects =
ACLs

22. Extended Access Control Matrix
Objects
Subjects
Files
Processes
Disk Drives S1 S2 S3 F1 F2 P1 P2 D1 D2
Control
Owner
Read*
Read
Wakeup
Seek
Write*
Execute
Seek*
Write
Stop
Subjects
*: Copy flag set

23. Content Dependent Access Control
Access to an object is determined by the content within the object that related to that subject.
For example, a manager has access to a payroll database, but it will only be allow to access to the records that pertain to his/her own employees, not others. A
All references are from All in One Book (Shon Harris, 2005)
Content Dependent Access Control (170)
With content based access control, access to objects is determined by the content within the object. (170)
Bases access decisions on the sensitivity of the data, not solely on subject’s identity. (172)
This is often used in databases. E.g., the content of the database fields dictates which users can see specific information within the database tables. (170)
Content dependent filtering is used when corporations employ filters that look for specific strings, such as “confidential,” “SSN,” “top secret,” etc. (170)
Context based access control differs from content dependent access control in that it makes access decisions based on the context of a collection of information rather than on the sensitivity of the data. (171)
Bases access decisions on the state of the situation, not solely on identity or content sensitivity. (172)
A system that is using context dependent access control “reviews the situation” and then makes a decision. (171)
For example, firewalls make context based decisions when they collect state information on a packet before allowing it into the network. (171)
A stateful firewall understands the necessary steps of communication for specific protocols. (171)
Stateful: Something that understands the necessary steps of a dialog session. Is an example of context dependent access control. (171) B

24. Context -based Access Control
Context-based access control differs from content-based access control in that it makes access decision based on the context of a collection of information rather than the content (sensitivity of data) within an object.
Firewalls make context-based access decisions when they collect state information on a packet before allowing it into the network.
For example, if no SYN packet has been received, firewalls will not allow the SYN/ACK packet to correlate the connection.
All references are from All in One Book (Shon Harris, 2005)
Content Dependent Access Control (170)
With content based access control, access to objects is determined by the content within the object. (170)
Bases access decisions on the sensitivity of the data, not solely on subject’s identity. (172)
This is often used in databases. E.g., the content of the database fields dictates which users can see specific information within the database tables. (170)
Content dependent filtering is used when corporations employ filters that look for specific strings, such as “confidential,” “SSN,” “top secret,” etc. (170)
Context based access control differs from content dependent access control in that it makes access decisions based on the context of a collection of information rather than on the sensitivity of the data. (171)
Bases access decisions on the state of the situation, not solely on identity or content sensitivity. (172)
A system that is using context dependent access control “reviews the situation” and then makes a decision. (171)
For example, firewalls make context based decisions when they collect state information on a packet before allowing it into the network. (171)
A stateful firewall understands the necessary steps of communication for specific protocols. (171)
Stateful: Something that understands the necessary steps of a dialog session. Is an example of context dependent access control. (171)

25. Constrained User Interfaces
Restrict user’s access abilities by not allowing them to request certain types of access, functions, information or specific system resources.
Three major types of restricted interfaces are:
Menus and Shells. The screen only displays the menu options that the subject is allowed to access.
Database Views. The system only allows the subject to view the database view s/he is allowed to see.
Physically Constrained Interfaces. The system only provides certain key on a keypad or certain touch buttons on a screen that the subject is allowed to access.
All references are from All in One Book (Shon Harris, 2005)
Constrained user interfaces restrict users’ access abilities by not allowing them to request certain functions or information, or to have access to specific system resources. (168)
Limits the user’s environment within the system, thus limiting access to objects. (172)
There are three major types of restricted interfaces: (168)
Menus and shells
The options that a user is given are the commands that they can execute. (168)
A shell is a type of virtual environment within a system; it is the user’s interface to the operating system and works as a command interpreter. (168)
Database views
Are mechanisms used to restrict user access to data that is contained in the database. (168)
Physically constrained interfaces
Can be implemented by providing only certain keys on a keypad or certain touch buttons on a screen. (e.g., atm machine views). (169)

26. Rule Based Access Control
Uses specific rules that indicate what can and cannot happen between a subject and an object. Before a subject can access an object, it must meet a set of predefined rules.
For example, “if the user is accessing the system between Monday and Friday and between 8 AM and 5 PM, and if the user’s security clearance equals or dominates the object’s classification, then the user can access the object.”
Not necessarily identity based.
Traditionally, rule based access control has been used in MAC systems as an enforcement mechanism.
Many routers and firewalls use rules to determine which types of packets are allowed into a network or rejected.
All references are from All in One Book (Shon Harris, 2005)
Rule based access control uses specific rules that indicate what can and cannot happen between a subject and an object. (167)
Before a subject can access an object in a certain circumstance, it must meet a set of predefined rules. (167)
Rule based access control is not necessarily identity based—rules apply to all users across the board, no matter what their identity is. (The DAC model is identity based). (167)
Traditionally, rule based access control has been used in MAC systems as an enforcement mechanism of the complex rules of access that MAC systems provide; today, rule based access is used in other types of systems and applications as well (e.g., routers and firewalls). (167)

27. Temporal (Time-based) Isolation
Time based access controls are those mechanisms employed at a given time for a predetermined duration.
If a request is made for access or privileged use of information or services not in the defined time window, the process is denied.
For example, if the access control specified only process confidential data in the morning, then any request of processing confidential data in other times is denied, although it was requested by an authorized person.

28. Access Control Function
From a logical or functional point of view, a separate access control module is associated with each type of object, as shown in Figure 4.5. The module evaluates each request by a subject to an object to determine if the access right exists. An access attempt triggers the following steps:
A subject S0 issues a request of type  for object X.
The request causes the system (operating system or an access control interface module) to generate a message of the form (S0, , X) to the controller for X
The controller interrogates the access matrix A to determine if  is in A[S0, X]. If so, the access is allowed, if not the access is denied and a protection violation occurs.
Figure 4.5 suggests that every access by a subject to an object is mediated by the controller for that object, and that the controller's decision is based on the current contents of the matrix. In addition, certain subjects have the authority to make specific changes to the access matrix. A request to modify the access matrix is treated as an access to the matrix, with the individual entries in the matrix treated as objects. Such accesses are mediated by an access matrix controller, which controls updates to the matrix. The model also includes a set of rules that govern modifications to the access matrix, such as those shown in Table 4.2 in the text. These include means of accessing, transferring, granting, and deleting access rights; and with who can create and delete subjects and objects. The ability of one subject to create another subject and to have 'owner' access right to that subject can be used to define a hierarchy of subjects. For example, in Figure 4.4 on the previous slide, S1 owns S2 and S3, so that S2 and S3 are subordinate to S1.

29. UNIX File Concepts UNIX files administered using inodes
control structure with key info on file
attributes, permissions of a single file
may have several names for same inode
have inode table / list for all files on a disk
copied to memory when disk mounted
directories form a hierarchical tree
may contain files or other directories
are a file of names and inode numbers
Now define some basic concepts concerning UNIX files and directories.
All types of UNIX files are administered by the operating system by means of inodes. An inode (index node) is a control structure that contains the key information needed by the operating system for a particular file. Several file names may be associated with a single inode, but an active inode is associated with exactly one file, and each file is controlled by exactly one inode. The attributes of the file as well as its permissions and other control information are stored 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. Each directory can contain files and/or other directories. A directory that is inside another directory is referred to as a subdirectory. A directory is simply a file that contains a list of file names plus pointers to associated inodes. Thus, associated with each directory is its own inode.

30. UNIX File Access Control
Owner
Group
Other
Most UNIX systems depend on, or at least are based on, the file access control scheme introduced with the early versions of UNIX.Each UNIX user is assigned a unique user identification number (user ID). A user is also a member of a primary group,and possibly a number of other groups, each identified by a group ID. When a file is created, it is designated as owned by a particular user and marked with that user’s ID. It also belongs to a specific group, which initially is either its creator’s primary group, or the group of its parent directory if that directory has SetGID permission set. Associated with each file is a set of 12 protection bits. The owner ID, group ID, and protection bits are part of the file’s inode. Nine of the protection bits specify read, write, and execute permission for the owner of the file, other members of the group to which this file belongs, and all other users. These form a hierarchy of owner, group, and all others, with the highest relevant set of permissions being used. Figure 4.6a from the text shows an example in which the file owner has read and write access; all other members of the file’s group have read access, and users outside the group have no access rights to the file. When applied to a directory,the read and write bits grant the right to list and to create/ rename/ delete files in the directory. The execute bit grants to right to search the directory for a component of a filename. The remaining three bits define special additional behavior for files or directories. Two of these are the “set user ID”(SetUID) and “set group ID”(SetGID) permissions. The final permission bit is the “Sticky”bit.

31. Role-Based Access Control
User
Role
Object
Role-Based Access Control
Many to
one
Many to
one
One to many
One to many
Traditional DAC systems define the access rights of individual users and groups of users. In contrast, RBAC is based on the roles that users assume in a system rather than the user's identity. Typically, RBAC models define a role as a job function within an organization. RBAC systems assign access rights to roles instead of individual users. In turn, users are assigned to different roles, either statically or dynamically, according to their responsibilities. RBAC now enjoys widespread commercial use and remains an area of active research.
The relationship of users to roles is many to many, as is the relationship of roles to resources, or system objects, as shown here in Figure 4.7 from the text. The set of users changes, in some environments frequently and the assignment of a user to one or more roles may also be dynamic. The set of roles in the system in most environments is likely to be static, with only occasional additions or deletions. Each role will have specific access rights to one or more resources. The set of resources and the specific access rights associated with a particular role are also likely to change only infrequently.

32. RBAC Models

33. Define Users to Roles Relationship
(Many to Many)
Roles R1 R2 Rn U1 X U2 U3 U4 U5 U6 Um …
Users …

34. Define Roles to Resources Relationship
(Many to Many)
Objects R1 R2 Rn F1 F2 P1 P2 D1 D2
Control
Owner
Read*
Read
Wakeup
Seek
Write*
Execute
Seek*
Write
Stop
Roles …
*: Copy flag set

35. NIST RBAC Model
In 2001, NIST proposed a consensus model for RBAC, and has been adopted as ANSI INCITS The main innovation of the NIST standard is the introduction of the RBAC System and Administrative Functional Specification, which defines the features required for an RBAC system in three categories:
• Administrative functions: provide the capability to create, delete, and maintain RBAC elements and relations
• Supporting system functions: provide functions for session management and for making access control decisions
• Review functions: provide the capability to perform query operations on RBAC elements and relations
The NIST RBAC model comprises four model components (Figure 4.11): core RBAC, hierarchical RBAC, static separation of duty (SSD) relations, and dynamic separation of duty (DSD) relations. The elements of core RBAC are the same as those of RBAC0 described in the preceding section: users, roles, permissions, and sessions. The NIST model elaborates on the concept of permissions by introducing two subordinate entities: operations and objects. Hierarchical RBAC includes the concept of inheritance described for RBAC1, that greatly simplifies the task of defining permission relationships. SSD and DSD are two components that add constraints to the NIST RBAC model. The constraints are in the form of separation of duty relations, used to enforce conflict of interest policies that organizations may employ to prevent users from exceeding a reasonable level of authority for their positions. See text for more details.

36. RBAC Administration for a Bank
The Dresdner Bank has implemented an RBAC system which is system wide and in which the determination of access rights is compartmentalized into three different administrative units for greater security. Roles within the organization are defined by a combination of official position and job function, and form a role hierarchy in which one role is superior to another if its position is superior and their functions are identical. This makes it possible to economize on access rights definitions.
When a user invokes an application, the application grants access on the basis of a centrally provided security profile. A separate authorization administration associated access rights with roles and creates the security profile for a use on the basis of the user's role. A user is statically assigned to up to 4 roles, and selects a given role for use in invoking a particular application. The user/role information is provided to the Authorization Administration, which creates a security profile for each user that associates the User ID and role with a set of access rights. A role may be used to access several applications. Thus, the set of access rights associated with a role may include access rights that are not associated with one of the applications the user invokes. All of these ingredients are depicted here in Figure 4.12.
Some figures about this system are of interest. Within the bank, there are 65 official positions. These positions are combined with 368 different job functions provided by the human resources database. Potentially, there are 23,920 different roles, but the number of roles in current use is about This is in line with the experience other RBAC implementations. On average, 42,000 security profiles are distributed to applications each day by the Authorization Administration module.

37. To be Continued
This is the end of part I of the lecture. Please continue to review part II.