0% found this document useful (0 votes)
25 views22 pages

Netwrk Security

The document defines access control as a process that regulates system resource usage based on security policies, distinguishing between authentication (verifying identity) and authorization (granting permissions). It discusses various access control models, including Discretionary Access Control (DAC) and Role-Based Access Control (RBAC), emphasizing the importance of least privilege and role hierarchies. Additionally, it outlines the basic elements of access control, such as subjects, objects, and access rights, and highlights the need for auditing and compliance in security management.

Uploaded by

Jaydeep Jayswal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
25 views22 pages

Netwrk Security

The document defines access control as a process that regulates system resource usage based on security policies, distinguishing between authentication (verifying identity) and authorization (granting permissions). It discusses various access control models, including Discretionary Access Control (DAC) and Role-Based Access Control (RBAC), emphasizing the importance of least privilege and role hierarchies. Additionally, it outlines the basic elements of access control, such as subjects, objects, and access rights, and highlights the need for auditing and compliance in security management.

Uploaded by

Jaydeep Jayswal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 22
Access Control Definition * RFC 4949 defines computer security as: “Measures that implement and assure security services in a computer system, particularly those that assure access control service.” * NIST IR 7298 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” Authentication vs. Authorization Authentication — Are you who you say you are? — Restrictions on who (or what) can access system Authorization — Are you allowed to do that? — Restrictions on actions of authenticated users Authorization is a form of access control Classic view of authorization... — Access Control Lists (ACLs) = Capabilities (C-lists) — Access Control implements a security policy that specifies who (or what in the case of a process) may have access to each specific system resource and the type of access that is permitted in each instance. Access Control Principles + Authentication: Verification that the credentials of a user or other system entity are valid. + Authorization: Granting of a right or permission to a system entity to access a system resource o determines who is trusted for a given purpose. + Audit: An independent review and examination of system records and activities in order to o test for adequacy of system controls o ensure compliance with established policy and operational procedures o detect breaches in security 0 totecommend any indicated changes in control, policy and procedures. es Security administrator 2 igure 41 ‘Authentication, Access control Relationship Among Access Control and Other Security Funetions O 5 “system resources Access Control * The central element of computer security. * The principal objectives of computer security are o to prevent unauthorized users from gaining access to resources, © to prevent legitimate users from accessing resources in an unauthorized manner, o and to enable legitimate users to access resources in an authorized manner Subjects, Objects, and Access Rights |The basic elements of access control are: subject, object, and access right. Chi s yee Subject Object aj rated ate ( tity) if s oi pat he Bs Describes the way accessing A resource to in which a subject objects. Held which access may access an accountable for Becontrolied object | \__allactions \ ee ———s Could include: | Three classes Entity used to + Owner contain + Read * Group and/or * Write * World receive * Execute information * Delete 7 * Create | * Search Subjects & Objects * A subject is typically held accountable for the actions they have initiated © an audit track may be used to record the association of a subject with security relevant actions performed on an object by the subject. * Owner: This may be the creator of a resource, such as a file. E.g. a project administrator or leader may be assigned ownership. + Group: a named group of users may also be granted access rights, E.g. membership in the group is sufficient to exercise these access rights. a user may belong to multiple groups. + 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 + An object is a resource to which access is controlled. o entity used to contain and/or receive information. o Eg. records, blocks, pages, segments, files, portions of files, directories, directory trees, mailboxes, messages, and programs Discretionary Access Control (DAC) * Traditional method of implementing access control * Scheme in which an entity may enable another entity to access some resource © i.e. applied by operating system or a database management system * Often provided using an access matrix (Lampson's Access Control Matrix) © One dimension consists of identified subjects that may attempt data access to the resources © The other dimension lists the objects that may be accessed * Each entry in the matrix indicates the access rights of a particular subject for a particular object UNIX File Access Control UNDG fesare administered bythe OS sing nodes (dene) * 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; each file is controlled by exactly one inode * 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 * May contain files and/or other directories * Contains file names plus pointers to associated inodes UNIX File Access Control Unique user identification number (user |D) Member of a primary group identified by a group ID Belongs fo a specific group (a) Traditional UNIX approach (minimal access control list) 12 protection bits @ 9 of the protection bits 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 Traditional UNIX File Access Control “Set user ID"(SetUID) « Any program that is owned by, and SetUID to, the “superuser” potentially granted unrestricted access to the system to any user executing that program “Set group ID"(SetGID) e System temporarily uses rights of the file owner/group in addition to the real user’s rights when making access control decisions e Enables privileged programs to access files/resources not generally accessible Sticky bit e When applied to a directory it specifies that only the owner of the file in the directory can rename, move, or delete that file Superuser (root) « |s exempt from usual access control restrictions e Has system-wide access Figure 4.5 UNIX File Access Control user: iw = <1 masked § US@F:joe:rw- entriss group mask: :rw- (b) Extended access control list When a process requests access to a file: Step 1 selects the ACL entry that most closely matches the requesting process. ACL entries are looked at the order: owner, named users, groups, & others. Only a single entry determines access. Step 2 checks if the matching entry contains sufficient permissions. A process can be a member of more than one group; so more than one group entry can match. If any of these matching group entries contain the requested permissions, one that contains the requested permissions is picked (the result is the same no matter which entry is picked). If none of the matching group entries contains the requested permissions, access will be denied no matter which entry is picked. Role-Based Access Control (RBAC) Traditional DAC systems define the access rights of individual users and groups of users. In contrast, RBAC is based on: © Roles that users assume in a system (instead of their Identity) © Role is ajob function within an organization. A role will have specific access rights to one or more resources. o Assign Access Rights to Roles (instead of individual users.) o Users assigned to different Roles according to their Responsibilities. o Users-to-Roles are Many-to-Many. The set of Users changes frequently (dynamic), and the assignment of a user to one or more roles may also be dynamic. The set of Roles is relatively static, with only occasional additions or deletions. The set of Resources and the specific access rights associated with a particular role are also likely to change infrequently (relatively static). Users Roles Resources Access rights are assigned to Roles instead of individuals ih} Users are assigned to Roles. (statically or dynamically, Based on responsibilities) Users to Roles are Many-to-Many Q Users may change frequently Often, Roles are static ARole has specific access rights INAA Figure 4.6 Users, Roles, and Resources Best practice for using RBAC RBAC allows to © Segregate duties within a team and © Grant only the amount of access to users that they need to perform the jobs. Instead of giving everybody (group) unrestricted permissions on a resource, you can allow only certain actions at a particular scope. Planning the access control strategy, it’s a best practice to grant users the least privilege to get their work done. o Each role should contain the minimum set of access rights needed for that role. Arole assignment consists of three elements: o Security principal, (object that represents a user, group, service principal) o Role definition, (collection of permissions.) o Scope, (set of resources that the access applies to) . an Typically, Relates individual users to roles mR tee & fw Roles & * Typically there are many more users u | % many User: than roles + Each entry is either blank or marked + Auser may be assigned multiple roles + Arole contains the minimum set of access rights. we) KK) + Auser is assigned to a role that e enables him/her to perform only |e what is required. + Multiple users may be assigned to the same Role. + has the same structure as the DAC access control matrix, with roles as subjects Figure 4.7 Access Control Matrix Representation of RBAC Abstract models of RBAC functionality | RBAC, Role: A named job function within the Consolidated model organization that controls this computer system. (authority & responsibility) BAG, HDAC, Permission: An approval of a particular Rete ierercita Ronetraiits: mode of access to one or more objects. (access right, privilege, authorization). RBAC) Base model +Session: A mapping between a user and an activated subset of the set of roles (a) Relationship among RBAC models to which the user is assigned. *Temporary one-to-many relationship ena Hierarchy + Least privilege: Only needed roles (WA) User Assignment (PA) Permission +One user may have multiple roles, and Assignment multiple users may be assigned to a single role (many-to-many). tuser_sessions +Flexibility and granularity: the many-to-many relationships between users and roles and between roles and permissions (not found in conventional DAC schemes). constrains, contains the four + Without this flexibility and (b) RBAC models | types of entities in an RBAC, granularity, there is a risk that a system: “ user may be granted more access to resources than is needed “without the role hierarchy and Figure 4.8 A Family of Role-Based Access Control Models. Table 4.3 Scope RBAC Models Models Hierarchies Constraints RBACy No No RBAC, Yes No RBAC, No Yes RBAC, Yes Yes BAC, contains the minimum functionality for an RBAC system IRBAC, includes the RBAC, functionality and adds role hierarchies, which enable one role to inherit permissions from another role BAC, includes RBAC, and adds constraints, which restrict the ways in which the components of a RBAC system may be configured RBAC;, contains the functionality of RBAC,, RBAC,, and RBAC, An example of a diagram of a role Hierarchy Director Project Lead 1 Project Lead 2 Production Quality Production Quality Engineer 1 Engineer 1 Engin cer 2 Engineer 2 Engineer 1 Engineer 2 Engineering Dept Figure 4.9 Example of Role Hierarchy Role hierarchies reflect the hierarchical structure of roles in an organization. Aline between two roles implies that the upper role includes all of the access rights of the lower role, Typically, job functions with greater responsibility have greater authority to access resources Role hierarchies make use of the concept of inheritance to enable one role to implicitly include access rights associated with a subordinate role. Constraints - RBAC Provide a means of adapting RBAC to the specifics of administrative and security policies of an organization A constraint is c defined relationship among roles or a condition related to roles. Types: Auser can only be assigned to one role in the set (either during a session or statically) Any permission (access right) can be granted to only one role in the set Separation of duties and capabilities (no collusion among individuals, roles have non-overlapping permissions) + Dictates that a user can only be assigned to a particular role if itis already assigned to some other specified role + Eg. can be used to structure the impl. of the least privilege concept + Setting a maximum number with respect to roles. E.g. Constraint ‘the maximum number of users that can be assigned to a given role the number of roles that a user is assigned to, ‘the number of roles a user can activate for a single session OBIECTS Fite1 File Files Fite 4 SUBIECTS User 8 (a) Access matrix ~ Bae (©) Capability lists for Bes of part (ay File File2 Files cis (by Access control Hist fo files of part (a) Table 4.1 Authorization Table for Files in Figure 42 | Subject | Access Mode Object [a Own Filed A Read Filet A Write Filet A Owe File A Read Filed | A ‘Write File3 B Read Filet 8 Own File2 a Read File2 B Write File2 B ‘Write File3 B Read Filed c Read File! c Write File? [ie Read File 2 c c c

You might also like