The nature of all computer systems security relies upon systems
access and how privileges are granted to a given user object or
application program to system subject. Most security models are
designed around the Subject, Object and User permission. Regardless
of weather or not we are considering local Operating System or Client
and Server interactions, these models are usually only concerned with
Subjects (files and folders), Objects (Applications and programs) and
Users. Some incorporate procedures as well (transactions).
Every computer regardless of operating system maintains a set of “Rings”
with respect to system and application access and program execution.
Windows 7, Linux and Unix clones all utilize these divisions with
respect to applications running on x86 based hardware. These modes
allow the system to differentiate between a program and a device
driver and the kernel at the hardware layer. Thus if a device driver
fails it would not take the kernel with it and if a program fails it
would not corrupt drivers or the kernel; in theory this is an
excellent model; in practice programs often take the kernel when they
fail due to improper programming techniques.
with respect to system and application access and program execution.
Windows 7, Linux and Unix clones all utilize these divisions with
respect to applications running on x86 based hardware. These modes
allow the system to differentiate between a program and a device
driver and the kernel at the hardware layer. Thus if a device driver
fails it would not take the kernel with it and if a program fails it
would not corrupt drivers or the kernel; in theory this is an
excellent model; in practice programs often take the kernel when they
fail due to improper programming techniques.
Discretionary access control (DAC) is defined by the TCSEC as the “Absence of MAC”. Where every object has an owner and that object may also be read by the system or other users.ii
All Unix implementations and Linux distributions utilize DAC as the
standard permissions mechanism within the file system; where each
directory may only be readable or writable depending upon the parent
directory and it's applied or inherited permissions. The superuser or
administrator may modify group memberships and object ownerships.
Users are limited by group memberships on the system to which objects
they may manipulate or where they may create or destroy objects by
their assigned permissions. Examples of this are how a user must be a
member of the “Wheel” group if they wish to use the command “su -” to become root.
The root user would usually assign that membership to other users that may also be admins from time to time. Most access-matrix and AAA models are based upon the DAC standard with some minor modifications involving the use of
Access control lists which reside on an object or AAA standards
include Radius and TACACS and TACACS+ models.
Access control lists which reside on an object or AAA standards
include Radius and TACACS and TACACS+ models.
The level of systems access at the OS level is usually determined by the security model implemented by the operating system in question.
Mandatory Access Control is the result of the adoption and Implementation of the “Bell-La-Paullda” confidentiality modeliii and BIBA integrity modeliv and can be considered a derivative work of the Lipnerv security model usually implemented on a system in addition to DACvi.
The modern definition of MAC also includes considerations for
integrity in addition to security where the Subject, Object and
access matrix is primarily determined by a policy applied to the
system in question; where read and write object rights are inherent
in the subject label; Again this was originally defined in the TCSEC
standard as “Multi-Level Security” designed to address sensitive data classifications and their manipulat within classified systems; however it's most prolific modern implementations are SELinux and AppArmor. The primacy of purpose for MAC is to ensure that a given subject cannot write to an object of a
higher classification or that a given object may not be read by a
given subject of a lesser classification. Again the administrator may
only change an object security label or a subjects clearance, they do
not have object access; administration and operations of MAC on-top
of DAC increase the operational and maintenance complexity of any
system that uses either of these options. Essentially employing MAC
ensures that data on the system will maintain it's integrity and
security according to the security policy. Pre-configured polices
often exist for standard server configurations including Oracle
database services, Apache – tomcat web services and other
standard server configurations. MAC is very complex in nature and
increases troubleshooting overhead for applications by a great deal;
it's notorious for breaking oracle installations or preventing apache
from serving web pages correctly; however these common errors are
usually the result of a lack of planning on the administration's
part.
integrity in addition to security where the Subject, Object and
access matrix is primarily determined by a policy applied to the
system in question; where read and write object rights are inherent
in the subject label; Again this was originally defined in the TCSEC
standard as “Multi-Level Security” designed to address sensitive data classifications and their manipulat within classified systems; however it's most prolific modern implementations are SELinux and AppArmor. The primacy of purpose for MAC is to ensure that a given subject cannot write to an object of a
higher classification or that a given object may not be read by a
given subject of a lesser classification. Again the administrator may
only change an object security label or a subjects clearance, they do
not have object access; administration and operations of MAC on-top
of DAC increase the operational and maintenance complexity of any
system that uses either of these options. Essentially employing MAC
ensures that data on the system will maintain it's integrity and
security according to the security policy. Pre-configured polices
often exist for standard server configurations including Oracle
database services, Apache – tomcat web services and other
standard server configurations. MAC is very complex in nature and
increases troubleshooting overhead for applications by a great deal;
it's notorious for breaking oracle installations or preventing apache
from serving web pages correctly; however these common errors are
usually the result of a lack of planning on the administration's
part.
Illustration 2vi
|
Role Based Access Control is yet another security model; it has been
formalized as a standard by the NIST.viii RBAC is a newer standard than MAC or DAC and is implemented by using a centralized directory service such as Active Directory, or Novell eDirectory or specialized permissions and roles stored within a database or directory service. RBAC relies on user objects being assigned roles that may have associated transaction or session
permissions which are queried when subject access requests occur.
Thus a user is limited in what they may accomplish within a given
environment by their assigned roles and the authorizations that those
roles have and the subjects they are attempting to work with
including which transactions they may be attempting as well as the
subjects and the transaction based assigned permissions. Again an
administrator must assign roles to user objects (subjects);
permissions to resources, including transaction permissions as well
as session permissions they may even have to assign role activation
constraints. Active Roles is a product that assigns roles based
administration and offers a predefined transaction permission
framework for active directory. Generally speaking RBAC is the most
complex of the three security models and requires the greatest amount
of effort for both the implementation in an organization and the
maintenance required. The complexity of RBAC is offset by it's
granularity, you may specify at a very granular level what a given
user may accomplish with a given object, subject and transaction;
it's employed primarily by the Military and Banking sectors.
formalized as a standard by the NIST.viii RBAC is a newer standard than MAC or DAC and is implemented by using a centralized directory service such as Active Directory, or Novell eDirectory or specialized permissions and roles stored within a database or directory service. RBAC relies on user objects being assigned roles that may have associated transaction or session
permissions which are queried when subject access requests occur.
Thus a user is limited in what they may accomplish within a given
environment by their assigned roles and the authorizations that those
roles have and the subjects they are attempting to work with
including which transactions they may be attempting as well as the
subjects and the transaction based assigned permissions. Again an
administrator must assign roles to user objects (subjects);
permissions to resources, including transaction permissions as well
as session permissions they may even have to assign role activation
constraints. Active Roles is a product that assigns roles based
administration and offers a predefined transaction permission
framework for active directory. Generally speaking RBAC is the most
complex of the three security models and requires the greatest amount
of effort for both the implementation in an organization and the
maintenance required. The complexity of RBAC is offset by it's
granularity, you may specify at a very granular level what a given
user may accomplish with a given object, subject and transaction;
it's employed primarily by the Military and Banking sectors.
Web Services Security is the extension f Integrity and confidentiality
to the world of Web 2.0 standards including XML and SOAP transactions by utilizing
signatures, encryption and tokens of XML and related services including the creation
and use of the WS-Security lawyer on top of the standard certification layer of
trust currently used to deliver SSL based HTTP transactions using SOAP and XML.x
Level | Security Model as applied |
OS | DAC |
Local Users and Applications | MAC |
CLIENT / Server | MAC/AAA |
Web Services | WS-Security |
Generally security models are layered upon one another, this layering process is refereed to as “Hardening” and a system may be hardened depending upon it's sensitivity and classification. The greater the risk within the system the more hardening and “due care” are required.
The following Tables will compare and contrast the limitations at given
levels of each of these models:
levels of each of these models:
OS Level | Complexity | Goal | Limitations | Benefits |
DAC | Low | Limit acces to system files | Administrator has access to everything | Standard file permissions on Windows and UNIX |
AAA | Medium | Authorize an individual using a trusted third party server | Requires a dedicated directory server | Group permissions on shared drives facilitate simple file management. |
Access-matrix | High | Authorize a user or group to a specific object | Requires planning on the administrators part. Can limit object from administrator access Time intensive Complicates troubleshooting | Can limit object from administrator access |
Client Server | Complexity | Goal | Limitations | Benefits |
DAC | Low | Limit acces to system files | Administrator has access to everything | Standard file permissions on Windows and UNIX |
MAC | High | Limit access to objects by security clearence labels (Integrity and Authenticity) | Requires a lot of planning | No one user of a lesser clearance may read an object of a greater clearance No one subject of a greater clearance may write to an object of a lesser clearance |
RBAC | High | Limit systems use and transacations by pre-defined job roles | Great administrative Overhead Requries dedicated expertise on site Time intensive Complicates troubleshooting | Can prevent fraud in Banks. Limits the “Area of potential destruction” that an unwitting subject may engage in. |
OS Level | Complexity | Goal | Limitations | Benefits |
DAC | Low | Limit acces to system files | Administrator has access to everything | Standard file permissions on Windows and UNIX |
AAA | Medium | Authorize an individual using a trusted third party server | Requires a dedicated directory server | Group permissions on shared drives facilitate simple file management. |
Access-matrix | High | Authorize a user or group to a specific object | Requires planning on the administrators part. Can limit object from administrator access Time intensive Complicates troubleshooting | Can limit object from administrator access |
Client Server | Complexity | Goal | Limitations | Benefits |
DAC | Low | Limit acces to system files | Administrator has access to everything | Standard file permissions on Windows and UNIX |
MAC | High | Limit access to objects by security clearence labels (Integrity and Authenticity) | Requires a lot of planning | No one user of a lesser clearance may read an object of a greater clearance No one subject of a greater clearance may write to an object of a lesser clearance |
RBAC | High | Limit systems use and transacations by pre-defined job roles | Great administrative Overhead Requries dedicated expertise on site Time intensive Complicates troubleshooting | Can prevent fraud in Banks. Limits the “Area of potential destruction” that an unwitting subject may engage in. |
iN.A. (Wikimedia, n.d.) Ring (Computer Security) [Online]
World Wide Web, Avaialble from: http://en.wikipedia.org/wiki/Ring_%28computer_security%29 (Accessed on May 12th 2011)
World Wide Web, Avaialble from: http://en.wikipedia.org/wiki/Ring_%28computer_security%29 (Accessed on May 12th 2011)
iiN.A. (DoD, December 26 1985) DEPARTMENT OF DEFENSE STANDARD TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA [Online]
World Wide Web, Available From: http://www.iwar.org.uk/comsec/resources/standards/rainbow/5200.28-STD.html (Accessed on May 12th 2011)
World Wide Web, Available From: http://www.iwar.org.uk/comsec/resources/standards/rainbow/5200.28-STD.html (Accessed on May 12th 2011)
iiiTipton, F. Harold; (Taylor and Francis, 2009) Official (ISC)2 Guide to
the CISSP ISBN: 978-1-4398-0959-4 P685
the CISSP ISBN: 978-1-4398-0959-4 P685
ivTipton, F. Harold; (Taylor and Francis, 2009) Official (ISC)2 Guide to
the CISSP ISBN: 978-1-4398-0959-4 P691
the CISSP ISBN: 978-1-4398-0959-4 P691
vTipton, F. Harold; (Taylor and Francis, 2009) Official (ISC)2 Guide to
the CISSP ISBN: 978-1-4398-0959-4 P691
the CISSP ISBN: 978-1-4398-0959-4 P691
viN.A. (DoD, December 26 1985) DEPARTMENT OF DEFENSE STANDARD TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA [Online]
World Wide Web, Available From: http://www.iwar.org.uk/comsec/resources/standards/rainbow/5200.28-STD.html (Accessed on May 12th 2011)
World Wide Web, Available From: http://www.iwar.org.uk/comsec/resources/standards/rainbow/5200.28-STD.html (Accessed on May 12th 2011)
viiWalsh,
Dan (RedHat Magazine, 2007) Whats new in Selinux for Red Hat
Enterprise 5 [Online] World
Wide Web, Available from: http://magazine.redhat.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/
(Accessed on May 13th 2011)
Dan (RedHat Magazine, 2007) Whats new in Selinux for Red Hat
Enterprise 5 [Online] World
Wide Web, Available from: http://magazine.redhat.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/
(Accessed on May 13th 2011)
viiiN.A. (NIST, October 10th 2007) RBAC standards page [Online]
World Wide Web, Available from: http://csrc.nist.gov/groups/SNS/rbac/standards.html
(Accessed on May 12th 2011)
World Wide Web, Available from: http://csrc.nist.gov/groups/SNS/rbac/standards.html
(Accessed on May 12th 2011)
ixN.A. (Microsoft Inc, December 2009) Understanding Management Role
Groups [Online] World Wide Web,
Available from:http://technet.microsoft.com/en-us/library/dd638105%28EXCHG.140%29.aspx
(Accessed on May 12th 2011)
Groups [Online] World Wide Web,
Available from:http://technet.microsoft.com/en-us/library/dd638105%28EXCHG.140%29.aspx
(Accessed on May 12th 2011)
xAlonso, Gustavo (Swiss Federal Institute of Technology, ETHZ, 2009) Security Web Services [Online] PDF Document, Available from: www.systems.ethz.ch/education/past-courses/fs09/web-services-and-service-oriented-architectures/slides/8-WS-SOA-Security.pdf (Accessed on May 12th 2011)
No comments:
Post a Comment