Overview Paper Spring2009
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Overview Paper Spring2009 as PDF for free.
More details
- Words: 3,134
- Pages: 14
Corsello Research Foundation
Software Security Primitives Access Control Considerations and Types
michael.corsello 1/24/2009
Abstract All forms of software require security mechanisms that are reliable and meet the requirements of the software specification as it changes over time. A primary part of this security will often include access control mechanisms. Access control may be modeled in different ways to provide a balance between simplicity of design, implementation or use and the dynamic needs of the users. While it is most common to leverage existing “off the shelf” security infrastructures, most are lacking in flexibility of implementation.
Michael Corsello
Overview Paper
CSci 283 Computer Security
Introduction All forms of software require security mechanisms that are reliable and meet the requirements of the software specification as it changes over time. Access control is one of the fundamental mechanisms for implementation of such security in computer systems. In simple terms, access control is the set of mechanisms that implement, resolve and enforce operational access to perform actions or access resources. The overall purpose of access control is to ensure that only the permitted actions are performed under the permitted constraints. Access control should prevent illegal actions from being performed in every case, thus guaranteeing a secure system of dependable (though not necessarily correct, that is validation) data. This role of access control includes the restriction of access to ensure malicious data and code are not employed by these same mechanisms. Therefore, it is the responsibility of access control to ensure any security features implemented solely by access control mechanisms sufficiently protect the system from malicious activities possible by way of the access control protected actions. More simply, the computing environment is never trusted or trustworthy and all actions may be malicious so access control should only permit access when adequate resolution has been performed.
Scenario A discussion of access control will include several aspects of access which can be illustrated by a simple scenario. Bill is running the “GryphonFilter” process on the “Cordite” machine at his desk. Bill wants to create a new folder under the existing “Project Files” folder on the “Blitzik” server “Public” share on the network. It is now 11:45 am on Tuesday May 22.
P age |1
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
In this scenario, a real world action is about to be attempted. This action will illustrate several access concepts using some basic constrainable items. Bill is a user of the system The “GryphonFilter” application is running as a process The hosting machine of the process is “Cordite” A requested action is to “create a new folder” The destination of this action is the “Project Files” folder The location of the destination is on another machine, the server “Blitzik” The location of the folder on the destination is a network share “Public” It is currently 11:45 am, Tuesday the 22nd of May when the action is requested A good access control system within a good security model will be capable of addressing each of these pieces of information when determining if the action should succeed.
Access Concepts Before discussing the details of access control mechanisms it is important to understand the entities that exist with respect to resolving the access control actions.
Access Result The most basic construct of access control is the access resolution result. Once all access control rules are evaluated and a result is resolved, that result will simply be a true or false (or access granted / access denied) as to whether the specific access request is granted. In our scenario, once all factors are considered, the access result will simply be whether Bill is allowed to create the folder he wishes to.
P age |2
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Identities An identity is a form of subject that is used in access control. This identity includes user identities (such as Bill in our scenario), machine identities (such as Cordite and Blitzik in our scenario), process or application identities (such as GryphonFilter in our scenario). Overall, an identity allows an access control to determine a context for the resolution of an access control. More specifically, each form of identity may contain separate rules of access that constrain the applicable results for access resolution. One common form of identity is the role or group, which is a logical identity for grouping other identities. In a role, several identities (generally users) are assigned into a role. That role is then assigned to items and verbs. In this manner, all identities associated with the role “get” the items associated with the role. The use of roles is primarily for simplification of management and automation.
Items An item is the object to be secured or upon which an identity will act. These items include things such as files, folders, tables (e.g. in databases), records (database), columns (database), cells (database), classes (e.g. object oriented code), Objects (object oriented instances) and so on. Each of these items will have different types of actions that can be performed on, or with respect to. In some circumstances, identities can themselves also be items and vice versa. Like identity roles, items may be abstractions for the purpose of grouping. For example, a “File System Item” item may be defined as an abstraction for all forms of file system items (files, folders and drive letters / mount points) with identities associated with this abstraction. At resolution time, all individual items associates with this item will realize all the associated verbs and users. Again, this is largely for simplification of management and automation.
P age |3
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Instances versus Entities When examining items, it is important to add a distinction between the conceptual entity (e.g. folder) and an instance of that entity (e.g. “My Documents” folder). Each of these 2 areas can be subject to access control verbs. In general, both will use the same verbs with some distinction. For example, the folder item may have verbs create, retrieve, update and delete. In the context of the conceptual entity (folder): Create means create a folder (create an instance) Retrieve means get a listing of the contents of a folder (for any instance) Update means alter the name of a folder (for any instance) Delete means to delete a folder (any instance) In an instance context, the same verbs have a different meaning: Create means create an item within this folder (any type of legal item, also requires create for that item type) Retrieve means get a listing of the contents of this folder (same as conceptual verb) Update means alter the name of this folder (same as conceptual verb) Delete means to delete the content of this folder Note that these verbs are a notional example to illustrate the differences between instance implied rules and conceptual entity rules. Further note that not all rules HAVE to apply at both levels.
Verbs The actions, which are performed upon or with respect to items, are verbs. In the case of records in a database table, the standard verbs are create, retrieve, update and delete (CRUD). Each of these verbs may be assigned independently or in combination. Due to the operational nature of these verbs, there
P age |4
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
may be requisite linkages between them. For example, it would not make sense to permit delete of a record if retrieve is not permitted in most cases.
Application Implementation Access control within an operating system (OS) is fairly well understood and implemented. While there is considerable room for improvement in OS access control mechanisms, which is out of the scope of this document. The remainder of this document will discuss practical access control implementation within applications. Several security products in the current marketplace provide access control capabilities. These capabilities include simple access control item storage and retrieval, access control item assignment and management, and several additionally perform access control item resolution. While many of these products are quite good at what they offer (e.g. LDAP type products) the externalization and productization of these capabilities introduce their own vulnerabilities, constraints and limitations. In the development of an application of any size or complexity, it is critical that the architect and designers analyze the requirements to determine if these products will indeed meet the overall need of the system. It should be a standard practice to implement a custom security infrastructure sufficient for the business need. This custom infrastructure should only leverage existing infrastructures where it fits with the business requirements.
Application Architecture For a complex system that is constructed of several independent machines hosting parts of the overall system, a custom security infrastructure may be required simply due to the heterogeneous nature of the architecture. In general, for systems that are composed of deployable parts that each are secured separately with their own security rules it is generally beneficial to implement a policy based access
P age |5
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
control mechanism. The implementation of an enterprise distributed system will be best served by a centralized security broker that can perform a resolution of access control while deferring the final business implementation to a pluggable security infrastructure owned by the executing code. While this architecture is partially quite common (web services security with SAML for example), a full implementation of this form of extensible security model is rarely seen.
Scenario Discussion To discuss how an application might implement the access controls of our scenario, a full discussion of the environment for that scenario will be discussed with a resolution on how that scenario may be implemented in code. Architecture In any application that is required to implement access control, the rules of the constraining capabilities will have to define the implementation. For example, in our previous scenario, the overarching system that is hosting the “GryphonFilter” process may be a distributed system that performs all operations internally. In this form of system, the process (in the OS sense) runs as a system process and not as the executing user. This is becoming increasingly common, and actually recommended for web applications. Each component of execution is run under a hosting process (again OS process) that runs as a user that is
P age |6
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
provided with the minimal OS access control permissions to perform all requisite actions. The users that invoke these “virtual processes” are simply running the application code with a security context token following the code execution. Therefore, the representation of the OS level process hosting is quite simple, the host process(es) are secured at the OS level to ensure minimal operational capabilities to prevent hijacking of the host processes from “spilling over” into non-application related capabilities or areas (application deployment hardening). The user experience is virtualized in an internal security implementation that is enforced at the code level. Access Control Requirements In our scenario, the access control requirements require each code module (virtual process area) to define its own access control capabilities. The overarching access control infrastructure must support core capabilities for storing access control data including: User identities Virtual process identities (become permission owners or principals) Process hosts (machines where virtual processes are permitted to be) Scheduled hours of operation (simple calendaring function to denote legal windows of operation) Items (securable “things” that will own verbs) Verbs (operations or permissions that are granted), each verb is specific to the item it is defined under o
Folder as an item, may have a different set of verbs than a file or a database record
o
Overall, the access control infrastructure is the repository for all of these entities
Linkages between these entities: o
P age |7
User permitted processes
Access Control Considerations
Michael Corsello
Overview Paper
o
User permitted hosts
o
User permitted hours of operation
o
User permitted items
CSci 283 Computer Security
Secured by verbs (e.g. Create Folder where create is the verb and folder is the item)
o
Process registered hosts (which machines can this process run from, based upon invocation)
o
Process scheduled hours (when can this process be run)
o
This should be per host, and overall in a narrowing scope
Process items (which items are associated with this process)
This may be per host at an added complexity
Permitted verbs must also be registered against this process if it has partial permission
o
Host items (which items are relevant to a specific host)
This is not always necessary, and is quite complex as network boundaries are addressed
o
Item schedules
o
This is not always necessary and is quite complex
Full connection bindings tie things together to allow finer resolution
This is not always necessary, and is quite complex
Example: Bill (user), GryphonFilter (process), Cordite (host), 0900-1700 everyday (scheduled hours), Folder (item), Create (verb on Folder)
P age |8
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Notice in this requirement we did not address the location of the folder to permit specific restrictions at the “record” or “instance” level, these types of access control are in addition to the above mentioned requirements and are implemented in a separate store. The entity level access control is storage intensive and is best-implemented using roles for a level of abstraction from the user.
Access Control Implementation Many commercial products will provide some portion of the capabilities necessary for this form of implementation. For example, LDAP applications will provide all the necessary facilities for the access control store. However, due to the nature of this form of application there may not be an available LDAP instance to use. In addition, this is a minor portion of the overall architecture, so the use of a commercial LDAP implementation may not be of great cost savings unless it is already in place. For instance level access control, there are few products that offer the needed implementation other than OS level file protection, which requires the host process to run as the user. In this type of enterprise application, this is unrealistic and a custom implementation is needed. Security specific protocols and their implementations, such as SAML, offer a portion of the required capability especially at the system interconnection points. Overall, this class of application will require a custom implementation that may leverage some commercial products provided they are cost effective and secure overall. Each product introduced into a system will generally open up additional attack vectors that are exploitable, which is another course of action evaluation point.
P age |9
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Access Control Resolution Once all the access control data elements are created and stored, the resolution of the rules are what result in the final answer of access being granted or denied. There are several models for this resolution, several of which will be briefly described. Additive Security Resolution One model for resolving access control is by initially providing no access. Therefore, to gain access an explicit grant is required. This is known as the “least privilege” model and is nearly universally recommended. In this model access resolution is performed by enumerating through all access control entities granted to an identity and only permitting access if the proper access control entity is present. In this model, there is no way to revoke access without explicitly removing the granted access control entity. Subtractive Security Resolution The subtractive security resolution model is the exact opposite of the additive model. In the subtractive model access is implicitly granted unless an access control entity is assigned which removes the access. There are few places in practice where a fully subtractive model is preferable to the additive model. Cumulative Security Resolution The final access control resolution model to be discussed in this paper is the cumulative model. In this model, either an additive or subtractive model serves as the primary base model. Then, as resolution proceeds, each access control entity has 2 distinct actions that are bound to an identity either grant or deny. For any given item and verb to be resolved the base permission (granted or denied from the base model) is modified with all the access control entities bound to the identity. In general, there is a fixed model employed for the cascading of overlapping grants and denies in the access control entities applied.
P a g e | 10
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
In the most basic cumulative security system, an additive model serves as the base with access implicitly denied until an access control entity grants access. Then the access control entities are applied as either grant or deny. In this simplistic model approach, as soon as a deny is encountered the access control resolution concludes with an access denied. Only if after full evaluation of all access control entities is complete, and no deny is encountered is access resolution completed. If any grants were encountered, then access is granted, otherwise it is denied. While this is the most simplistic cumulative model, it is quite effective and makes evaluation and management relatively simple. Wherever practical, the additive model should be preferred as it is the simplest to implement and manage. Wherever an explicit deny is required to override a grant, then a cumulative model is justified. These cumulative models come in many varieties with many rules possible (e.g. UNIX and NTFS resolution models). The choice of an appropriate model is critical and error free implementation is challenging for many developers.
Conclusions Access control is a fundamental and complex portion of security implementations in information systems. While there are several models and many more commercial products available, all of them are targeted at the “80% solution” which means in at least 20% of the applications those products are insufficient to meet the requirements. An understanding of the theoretical underpinnings and architecture of access control systems is a prerequisite for any architect of complex systems especially ones based upon distributed computing. As the industry moves toward cloud computing the current technologies are going to become less effective and new mechanisms will be required that are based upon these fundamental tenets.
P a g e | 11
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
References Bishop, M. (2003). Computer Security. Boston: Addison Wesley. contributors, W. (2009, January 23). Access control. Retrieved January 24, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Access_control&oldid=265897332 Demchenko, Y., Laat, C. d., Gommans, L., & Buuren, R. v. (2006, January 24). Domain Based Access Control Model for Distributed Collaborative Applications. Retrieved January 24, 2009, from UAZone.org: http://www.uazone.org/demch/papers/esc2006-rbac-dm-04.pdf
P a g e | 12
Access Control Considerations
Software Security Primitives Access Control Considerations and Types
michael.corsello 1/24/2009
Abstract All forms of software require security mechanisms that are reliable and meet the requirements of the software specification as it changes over time. A primary part of this security will often include access control mechanisms. Access control may be modeled in different ways to provide a balance between simplicity of design, implementation or use and the dynamic needs of the users. While it is most common to leverage existing “off the shelf” security infrastructures, most are lacking in flexibility of implementation.
Michael Corsello
Overview Paper
CSci 283 Computer Security
Introduction All forms of software require security mechanisms that are reliable and meet the requirements of the software specification as it changes over time. Access control is one of the fundamental mechanisms for implementation of such security in computer systems. In simple terms, access control is the set of mechanisms that implement, resolve and enforce operational access to perform actions or access resources. The overall purpose of access control is to ensure that only the permitted actions are performed under the permitted constraints. Access control should prevent illegal actions from being performed in every case, thus guaranteeing a secure system of dependable (though not necessarily correct, that is validation) data. This role of access control includes the restriction of access to ensure malicious data and code are not employed by these same mechanisms. Therefore, it is the responsibility of access control to ensure any security features implemented solely by access control mechanisms sufficiently protect the system from malicious activities possible by way of the access control protected actions. More simply, the computing environment is never trusted or trustworthy and all actions may be malicious so access control should only permit access when adequate resolution has been performed.
Scenario A discussion of access control will include several aspects of access which can be illustrated by a simple scenario. Bill is running the “GryphonFilter” process on the “Cordite” machine at his desk. Bill wants to create a new folder under the existing “Project Files” folder on the “Blitzik” server “Public” share on the network. It is now 11:45 am on Tuesday May 22.
P age |1
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
In this scenario, a real world action is about to be attempted. This action will illustrate several access concepts using some basic constrainable items. Bill is a user of the system The “GryphonFilter” application is running as a process The hosting machine of the process is “Cordite” A requested action is to “create a new folder” The destination of this action is the “Project Files” folder The location of the destination is on another machine, the server “Blitzik” The location of the folder on the destination is a network share “Public” It is currently 11:45 am, Tuesday the 22nd of May when the action is requested A good access control system within a good security model will be capable of addressing each of these pieces of information when determining if the action should succeed.
Access Concepts Before discussing the details of access control mechanisms it is important to understand the entities that exist with respect to resolving the access control actions.
Access Result The most basic construct of access control is the access resolution result. Once all access control rules are evaluated and a result is resolved, that result will simply be a true or false (or access granted / access denied) as to whether the specific access request is granted. In our scenario, once all factors are considered, the access result will simply be whether Bill is allowed to create the folder he wishes to.
P age |2
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Identities An identity is a form of subject that is used in access control. This identity includes user identities (such as Bill in our scenario), machine identities (such as Cordite and Blitzik in our scenario), process or application identities (such as GryphonFilter in our scenario). Overall, an identity allows an access control to determine a context for the resolution of an access control. More specifically, each form of identity may contain separate rules of access that constrain the applicable results for access resolution. One common form of identity is the role or group, which is a logical identity for grouping other identities. In a role, several identities (generally users) are assigned into a role. That role is then assigned to items and verbs. In this manner, all identities associated with the role “get” the items associated with the role. The use of roles is primarily for simplification of management and automation.
Items An item is the object to be secured or upon which an identity will act. These items include things such as files, folders, tables (e.g. in databases), records (database), columns (database), cells (database), classes (e.g. object oriented code), Objects (object oriented instances) and so on. Each of these items will have different types of actions that can be performed on, or with respect to. In some circumstances, identities can themselves also be items and vice versa. Like identity roles, items may be abstractions for the purpose of grouping. For example, a “File System Item” item may be defined as an abstraction for all forms of file system items (files, folders and drive letters / mount points) with identities associated with this abstraction. At resolution time, all individual items associates with this item will realize all the associated verbs and users. Again, this is largely for simplification of management and automation.
P age |3
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Instances versus Entities When examining items, it is important to add a distinction between the conceptual entity (e.g. folder) and an instance of that entity (e.g. “My Documents” folder). Each of these 2 areas can be subject to access control verbs. In general, both will use the same verbs with some distinction. For example, the folder item may have verbs create, retrieve, update and delete. In the context of the conceptual entity (folder): Create means create a folder (create an instance) Retrieve means get a listing of the contents of a folder (for any instance) Update means alter the name of a folder (for any instance) Delete means to delete a folder (any instance) In an instance context, the same verbs have a different meaning: Create means create an item within this folder (any type of legal item, also requires create for that item type) Retrieve means get a listing of the contents of this folder (same as conceptual verb) Update means alter the name of this folder (same as conceptual verb) Delete means to delete the content of this folder Note that these verbs are a notional example to illustrate the differences between instance implied rules and conceptual entity rules. Further note that not all rules HAVE to apply at both levels.
Verbs The actions, which are performed upon or with respect to items, are verbs. In the case of records in a database table, the standard verbs are create, retrieve, update and delete (CRUD). Each of these verbs may be assigned independently or in combination. Due to the operational nature of these verbs, there
P age |4
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
may be requisite linkages between them. For example, it would not make sense to permit delete of a record if retrieve is not permitted in most cases.
Application Implementation Access control within an operating system (OS) is fairly well understood and implemented. While there is considerable room for improvement in OS access control mechanisms, which is out of the scope of this document. The remainder of this document will discuss practical access control implementation within applications. Several security products in the current marketplace provide access control capabilities. These capabilities include simple access control item storage and retrieval, access control item assignment and management, and several additionally perform access control item resolution. While many of these products are quite good at what they offer (e.g. LDAP type products) the externalization and productization of these capabilities introduce their own vulnerabilities, constraints and limitations. In the development of an application of any size or complexity, it is critical that the architect and designers analyze the requirements to determine if these products will indeed meet the overall need of the system. It should be a standard practice to implement a custom security infrastructure sufficient for the business need. This custom infrastructure should only leverage existing infrastructures where it fits with the business requirements.
Application Architecture For a complex system that is constructed of several independent machines hosting parts of the overall system, a custom security infrastructure may be required simply due to the heterogeneous nature of the architecture. In general, for systems that are composed of deployable parts that each are secured separately with their own security rules it is generally beneficial to implement a policy based access
P age |5
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
control mechanism. The implementation of an enterprise distributed system will be best served by a centralized security broker that can perform a resolution of access control while deferring the final business implementation to a pluggable security infrastructure owned by the executing code. While this architecture is partially quite common (web services security with SAML for example), a full implementation of this form of extensible security model is rarely seen.
Scenario Discussion To discuss how an application might implement the access controls of our scenario, a full discussion of the environment for that scenario will be discussed with a resolution on how that scenario may be implemented in code. Architecture In any application that is required to implement access control, the rules of the constraining capabilities will have to define the implementation. For example, in our previous scenario, the overarching system that is hosting the “GryphonFilter” process may be a distributed system that performs all operations internally. In this form of system, the process (in the OS sense) runs as a system process and not as the executing user. This is becoming increasingly common, and actually recommended for web applications. Each component of execution is run under a hosting process (again OS process) that runs as a user that is
P age |6
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
provided with the minimal OS access control permissions to perform all requisite actions. The users that invoke these “virtual processes” are simply running the application code with a security context token following the code execution. Therefore, the representation of the OS level process hosting is quite simple, the host process(es) are secured at the OS level to ensure minimal operational capabilities to prevent hijacking of the host processes from “spilling over” into non-application related capabilities or areas (application deployment hardening). The user experience is virtualized in an internal security implementation that is enforced at the code level. Access Control Requirements In our scenario, the access control requirements require each code module (virtual process area) to define its own access control capabilities. The overarching access control infrastructure must support core capabilities for storing access control data including: User identities Virtual process identities (become permission owners or principals) Process hosts (machines where virtual processes are permitted to be) Scheduled hours of operation (simple calendaring function to denote legal windows of operation) Items (securable “things” that will own verbs) Verbs (operations or permissions that are granted), each verb is specific to the item it is defined under o
Folder as an item, may have a different set of verbs than a file or a database record
o
Overall, the access control infrastructure is the repository for all of these entities
Linkages between these entities: o
P age |7
User permitted processes
Access Control Considerations
Michael Corsello
Overview Paper
o
User permitted hosts
o
User permitted hours of operation
o
User permitted items
CSci 283 Computer Security
Secured by verbs (e.g. Create Folder where create is the verb and folder is the item)
o
Process registered hosts (which machines can this process run from, based upon invocation)
o
Process scheduled hours (when can this process be run)
o
This should be per host, and overall in a narrowing scope
Process items (which items are associated with this process)
This may be per host at an added complexity
Permitted verbs must also be registered against this process if it has partial permission
o
Host items (which items are relevant to a specific host)
This is not always necessary, and is quite complex as network boundaries are addressed
o
Item schedules
o
This is not always necessary and is quite complex
Full connection bindings tie things together to allow finer resolution
This is not always necessary, and is quite complex
Example: Bill (user), GryphonFilter (process), Cordite (host), 0900-1700 everyday (scheduled hours), Folder (item), Create (verb on Folder)
P age |8
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Notice in this requirement we did not address the location of the folder to permit specific restrictions at the “record” or “instance” level, these types of access control are in addition to the above mentioned requirements and are implemented in a separate store. The entity level access control is storage intensive and is best-implemented using roles for a level of abstraction from the user.
Access Control Implementation Many commercial products will provide some portion of the capabilities necessary for this form of implementation. For example, LDAP applications will provide all the necessary facilities for the access control store. However, due to the nature of this form of application there may not be an available LDAP instance to use. In addition, this is a minor portion of the overall architecture, so the use of a commercial LDAP implementation may not be of great cost savings unless it is already in place. For instance level access control, there are few products that offer the needed implementation other than OS level file protection, which requires the host process to run as the user. In this type of enterprise application, this is unrealistic and a custom implementation is needed. Security specific protocols and their implementations, such as SAML, offer a portion of the required capability especially at the system interconnection points. Overall, this class of application will require a custom implementation that may leverage some commercial products provided they are cost effective and secure overall. Each product introduced into a system will generally open up additional attack vectors that are exploitable, which is another course of action evaluation point.
P age |9
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
Access Control Resolution Once all the access control data elements are created and stored, the resolution of the rules are what result in the final answer of access being granted or denied. There are several models for this resolution, several of which will be briefly described. Additive Security Resolution One model for resolving access control is by initially providing no access. Therefore, to gain access an explicit grant is required. This is known as the “least privilege” model and is nearly universally recommended. In this model access resolution is performed by enumerating through all access control entities granted to an identity and only permitting access if the proper access control entity is present. In this model, there is no way to revoke access without explicitly removing the granted access control entity. Subtractive Security Resolution The subtractive security resolution model is the exact opposite of the additive model. In the subtractive model access is implicitly granted unless an access control entity is assigned which removes the access. There are few places in practice where a fully subtractive model is preferable to the additive model. Cumulative Security Resolution The final access control resolution model to be discussed in this paper is the cumulative model. In this model, either an additive or subtractive model serves as the primary base model. Then, as resolution proceeds, each access control entity has 2 distinct actions that are bound to an identity either grant or deny. For any given item and verb to be resolved the base permission (granted or denied from the base model) is modified with all the access control entities bound to the identity. In general, there is a fixed model employed for the cascading of overlapping grants and denies in the access control entities applied.
P a g e | 10
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
In the most basic cumulative security system, an additive model serves as the base with access implicitly denied until an access control entity grants access. Then the access control entities are applied as either grant or deny. In this simplistic model approach, as soon as a deny is encountered the access control resolution concludes with an access denied. Only if after full evaluation of all access control entities is complete, and no deny is encountered is access resolution completed. If any grants were encountered, then access is granted, otherwise it is denied. While this is the most simplistic cumulative model, it is quite effective and makes evaluation and management relatively simple. Wherever practical, the additive model should be preferred as it is the simplest to implement and manage. Wherever an explicit deny is required to override a grant, then a cumulative model is justified. These cumulative models come in many varieties with many rules possible (e.g. UNIX and NTFS resolution models). The choice of an appropriate model is critical and error free implementation is challenging for many developers.
Conclusions Access control is a fundamental and complex portion of security implementations in information systems. While there are several models and many more commercial products available, all of them are targeted at the “80% solution” which means in at least 20% of the applications those products are insufficient to meet the requirements. An understanding of the theoretical underpinnings and architecture of access control systems is a prerequisite for any architect of complex systems especially ones based upon distributed computing. As the industry moves toward cloud computing the current technologies are going to become less effective and new mechanisms will be required that are based upon these fundamental tenets.
P a g e | 11
Access Control Considerations
Michael Corsello
Overview Paper
CSci 283 Computer Security
References Bishop, M. (2003). Computer Security. Boston: Addison Wesley. contributors, W. (2009, January 23). Access control. Retrieved January 24, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Access_control&oldid=265897332 Demchenko, Y., Laat, C. d., Gommans, L., & Buuren, R. v. (2006, January 24). Domain Based Access Control Model for Distributed Collaborative Applications. Retrieved January 24, 2009, from UAZone.org: http://www.uazone.org/demch/papers/esc2006-rbac-dm-04.pdf
P a g e | 12
Access Control Considerations
Related Documents
Overview Paper Spring2009
June 2020 2
Design Paper Spring2009
June 2020 3
Policy Paper Spring2009
June 2020 4
Nynetnews-spring2009
May 2020 4
Overview Of Paper Industry
June 2020 9
Florida Media Quarterly Spring2009
April 2020 3More Documents from ""
Overview Paper Spring2009
June 2020 2
Design Paper Spring2009
June 2020 3
Policy Paper Spring2009
June 2020 4
