computer security and access control, Slides of Computer science

Download computer security and access control and more Slides Computer science in PDF only on Docsity!

Information Security

Chapter 2

Toolbox: Authentication, Access

Control, and Cryptography

Charles P. Pfleeger

Information Security

Chapter 2 :

Access Control

Charles P. Pfleeger

Access Control

• the details of basic access control paradigm;

✓ Subjects are human users,

 often represented by surrogate programs running on behalf of the users.

✓ Objects are things on which an action can be

performed, for examples:

 Files, tables, programs, memory objects, HW devices, strings, data fields, network connections, and processors.  So too are users, or rather programs or processes representing users, because; − the OS (representing the system administrator) can act on a user, for example, − allowing a user to execute a program, halting a user, or assigning privileges to a user.

✓ Access modes are any controllable actions of

subjects on objects, including, but not limited to;

 read, write, modify, delete, execute, create, destroy, copy, export, import, and so forth.

Access Control

Access Policies;

• Access control is a mechanical process,

easily implemented by a table and computer

process;

✓ A given subject either can or cannot access a

particular object in a specified way ;

 Underlying the straightforward decision is a complex and nuanced decision of which accesses should be allowed,  these decisions are based on a formal or informal security policy.

✓ A policy also simplifies establishing access

control rules, because;

 they just reflect the existing policy.

 Access control rules are derived from higher-

level security policy.

Tracking

• Sometimes administrators need to revisit

the access policy to determine whether it is

working as it should;

✓ Has someone been around for a long time and so has

acquired a large number of no-longer-needed rights?

✓ Do so many users have access to one object that it

no longer needs to be controlled? Or;

✓ should it be split into several objects so that

individuals can be allowed access to only the pieces

they need?

• Administrators need to consider these kinds of questions on occasion;

✓ to determine whether the policy and implementation

are doing what they should;

• For more, See Chapter 10 ;

Granularity

• By granularity we mean the fineness or specificity of access control;

✓ At one end you can control access to;

 each individual bit or byte, each word in a document,  each number on a spreadsheet,  each photograph in a collection;  That level of specificity is generally excessive and cumbersome to implement.

✓ The finer the granularity;

 the larger number of access control decisions that must be made,  so there is a performance penalty.

✓ Typically a file , a program , or a data space is the

smallest unit to which access is controlled;

 So, note that applications can implement their own access control, for example;  a DBMS can have access to a complete DB ,  but it then, carves the DB into smaller units and parcels out access.

Access Log

 If a user misuses objects, − the access log shows exactly which objects the user did access.  In the event of an external compromise , −the audit log may help identify how the attacker gained access and which data items were accessed ,  These data for after-the-fact forensic analysis have been extremely helpful in handling major incidents.

Limited Privilege

• Limited privilege is the act of restraining

users and processes so that any harm they

can do is not catastrophic;

✓ is a way to constrain that exposure,

 we seek a midpoint that balances the need for some access against the risk of harmful, inappropriate access.

• Limited privilege is a management concept ,

not a technical control;

✓ The process of analyzing users and determining

the privileges they require is a necessary first

step to authorizing within those limits ;

✓ After establishing the limits,

we turn to access control technology to enforce those limits.

Implementing Access Control

Reference Monitor

• Reference monitor : access control that is always

invoked , tamperproof , and verifiable ;

• In Anderson’s formulation for computers; ✓ access control depends on a combination of HW and SW that is; − always invoked, − validates every access attempt; − immune from tampering; − assuredly correct. ✓ Anderson called this construct a reference monitor ; − A reference monitor is a notion, not a tool you can buy to plug into a port;  It could be embedded in an application to control the application’s objects,  part of the OS for system-managed objects, or  part of an appliance.

Implementing Access Control

Reference Monitor

• There are several models of how access

rights can be maintained and implemented

by the reference monitor;

✓ Access Control Directory, ✓ Access Control Matrix and its substructures;

 Access Control List,

 Privilege List,

✓ Capability, ✓ Procedure-Oriented Access Control, ✓ Role-Based Access Control. The basis of access control systems implemented today.

• Quite apart from the mechanical implementation of the access control matrix or its substructures.
• related more specifically to the objective of access control: ✓ relating access to a subject’s role or ✓ the context of the access.

• The OS must maintain all file directories , under commands from the owners of files;
• The obvious rights to files are the common; ✓ read, write, ✓ execute familiar on many shared systems, and ✓ permitting that user to grant and revoke access rights.
• Figure 2 - 9 shows an example of a file directory;

Access Control Directory

Figure 2 - 9 : Directory Access Rights

Access Control Directory

• This approach is easy to implement

because;

✓ it uses one list per user,

✓ naming all the objects that user is allowed to

access.

• However, several difficulties can arise;

✓ First , the list becomes too large if many

shared objects, such as;

─ libraries of subprograms or ─ a common table of users, are accessible to all users, ─ The directory of each user must have one entry for each such shared object, even if the user has no intention of accessing the object, ─ Deletion must be reflected in all directories.

Access Control Directory

• A third difficulty involves pseudonyms ;  Owners A and B may have two different files named F, and they may both want to allow access by S; ─ Clearly, the directory for S cannot contain two entries under the same name for different files, ─ S has to be able to uniquely identify the F for A or B; o One approach is to include the original owner's designation as if it were part of the file name, with a notation such as A:F (or B:F). − Another approach is to allow S to name F with any name unique to the directory of S;  F from A could be called Q to S.  This action opens up the possibility that one subject, S, may have two distinct sets of access rights to F,  Lead to a problem of revoke access.

Access Control Directory

 In this way, allowing pseudonyms leads to multiple permissions that are not necessarily consistent ;  Thus, the directory approach is probably too simple for most object protection situations.

• Figure 2 - 10 illustrates an ambiguous access rights in

the access control directory;

Figure 2 - 10 : Ambiguous Access Rights