Policy Paper Spring2009

Corsello Research Foundation

Software Policies Discussions on policy types, implementation and mechanisms of enforcement

michael.corsello 1/24/2009

Abstract A software policy for securing access to resources can take 2 basic forms: Confidentiality and Integrity. Confidentiality policies restrict access to resources to prevent unauthorized disclosure of information. Integrity policies restrict how information is accessed to ensure the integrity of information to ensure information is not altered in unauthorized ways. These 2 forms of information policy will be discussed in general terms with the concepts of policy and enforcement being of primary focus.

Michael Corsello

Policy Paper

CSci 283 Computer Security

Introduction Information integrity and confidentiality are 2 main concerns for information owners and producers. Given that information is a valuable commodity that is largely intangible the protection of that information resource is quite difficult and subject to “loopholes”. The actual protection of information resources is accomplished through the use of policies and mechanisms that are continually audited to ensure effectiveness. If inappropriate access to information occurs (either through disclosure or alteration) serious effects may be realized including loss of life in extreme cases.

Separation of Mechanism In general terms any policy is a written document, usually formal, that describes and defines what is permitted and what is not permitted with regard to some topic. In terms of computer security policies, these topics are integrity and confidentiality of information. A confidentiality policy would be written to define the legal flow of information between people or organizations within a core organization defining the policy. This policy defines the rules and perhaps the implications of non-compliance but does not perform the enforcement. The enforcement and auditing of the effectiveness of the policy is performed by mechanisms which are separate and independent of the policy itself. If there exists mechanisms that are used to completely enforce the policy in an automated manner, then the policy is fully mapped to the mechanism. It is rare that the policy and mechanism are so well matched. In the real world of information systems it is quite common that a policy (integrity or confidentiality) will be enforced by a combination of automated mechanism and human oversight. This is only partially due to the capability of automated mechanisms and is instead generally due to the lack of adequate technical staff to implement and maintain such mechanisms over time. This is commonly seen in the use of access control mechanisms within “network shares”. It is extremely rare that confidentiality is managed via access control on network shares. In general, it is common that open access is provided to such network locations and an implied “need to know” is conveyed. In these cases, there is no real P age |1

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

physical mechanism implemented to prevent access. In some cases, write access is restricted (more of an integrity constraint) while read access is open to all users.

Confidentiality The primary security policy is that of confidentiality to restrict access to information based upon defined rules governing “need to know”. In the Bell-LaPadula model this is performed via security “classifications” and “compartments” to which each user is granted and each object is defined. While this model theoretically covers all forms of confidentiality of information resources, it is quite hard to physically implement and manage. Additionally, the aspect of trust is of primary concern. Once an information resource moves from one system to another (e.g. a copy operation), the classification information may not be honored in the destination system. This is a classic issue of distributed computing when not all platforms are fully compliant with the same model implementation.

Types of Confidentiality In the protection of confidentiality, it is critical to ensure 2 primary aspects of security: Read

-- prevent unauthorized access to a resource (read-up)

Write -- prevent creation of information with a different access control that may result in unauthorized access to the copied resource (write-down) Both of these 2 types of access are based upon access control which can be implemented via several mechanisms including: Access Control List / Matrix (ACL / ACM)

P age |2

o

Allows “tagging” of objects (information) and subjects (users) with verbs (permissions)

o

Cross-correlation of object and subject tags ensure legal access is permitted

Software Policies

Michael Corsello o

Policy Paper

CSci 283 Computer Security

Easy to create and maintain, but can be a large storage cost for discreet matrices (NxM problem)

Security Classifications / Compartments (MAC labels / lattices a la LaPadula) o

Well-defined model (at least in theory)

o

2-dimensional protection (classification plus compartment)

o

Harder to create and maintain due to complexity of compartments

o

Still can be a storage problem due to large size of tagging index

Role-Based Access Control (RBAC) o

Well-defined model

o

Can be quite simple (grant-only model)

o

Can be quite complex (grant-deny model)

o

Easy to create, can be difficult to maintain (nested roles and grant-deny model)

o

Quite compact for storage

Each of the mechanisms has benefits and limitations and may be used in concert with the other models. For example, a hybrid model of role-based and security classifications may provide an added dimension of confidentiality for both mandatory and discretionary access. This is especially true when classifications and permissions are fixed and compartments and roles are dynamic. The combination of roles and classifications/compartments define both what can be accessed and how it can be acted upon. In this type of hybrid model the access control is primarily via the classifications and compartments, with actions / operations (such as read, write, execute, copy, etc) being defined by the role/permission set granted. Therefore, a subject with the proper classification and compartment may still be denied access without the appropriate role(s).

P age |3

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

Integrity The integrity of information involves a combination of guaranteeing that unexpected or unauthorized changes to information are not possible as well as ensuring that creation and destruction of information is likewise constrained. This relates strongly to the typical database CRUD (create, retrieve, update, delete) model where create, update and delete actually alter the corpus of information stored in the database. The integrity of information is often more critical to an organization than is the control of access to that information. However, as improper access to information is generally a prerequisite for alteration of information the two concepts tend to be strongly related. Additionally, the authentication of the subject acting upon an information base resulting in information changes being made is required to perform auditing of who, when, what and how those changes are made. This form of integrity blends in so tightly with confidentiality that the two concepts are difficult to fully separate.

Tracking and Enforcing In order to track and enforce changes to integrity of information it is important to know how changes get made (or simply can be made). This can be performed through all the same mechanisms as confidentiality plus the addition of credibility ratings. The concept of a credibility rating is used in a wide range of applications such as white-listing / black-listing resources in network protocols (e.g. IPSec). More evolved credibility ratings are developed over time based upon some finite mechanism (such as a user rating system) or heuristics. In an industrial setting, the ratings may be based upon a tagging infrastructure related to the role-based confidentiality structure where each defined role is tagged with a base rating value. This is related to the Biba model with the ratings “piggybacking” upon the role infrastructure. More advanced models such as conflict of interest (Chinese Wall) and transactional (Clark-Wilson / RDBMS) may require far more specialized infrastructure and management to ensure proper isolation.

P age |4

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

These advanced models generally already provide a blend of integrity and confidentiality but will also require more management of the security infrastructure to enforce. It is due to this exact reasoning that these models are less commonly used.

Transactional Models While the transactional models are gaining in popularity for databases and workflow systems, they are still specialized and are often not mapped to restrict who can perform information altering actions. In this way, these transactional models do tend to be a “pure” integrity model that is blended with confidentiality by securing access to the execution code performing the transaction. Probably the best known implementation of transactional models is that of the relational database management system (RDBMS). This model is expressed in terms of the “ACID” test for: Atomic – transaction either fully commits or none commits (the essence of transactional model) Consistent – the commit of a transaction takes the system from one consistent state to another Isolated – until committed no other transaction can see the state of the current transaction Durable – once committed the result cannot be lost, even in extreme conditions (such as sudden power loss) While most RDBMS applications claim full ACID compliance, there are generally subtleties in their definition of compliance. In general, as computational models move toward a more de-centralized model the transactional model becomes both more attractive and complex. To execute a transaction across many disparate systems with largely incompatible interfaces it may not be possible to “roll back” a partially failed operation. In these modern distributed multi-vendor hosted systems integrity policies may be nearly impossible to guarantee. In fact, in many services based models data inconsistency and “lazy transactions” are the norm.

P age |5

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

The Real World In real world applications and environments there is no silver bullet. Each application will have requirements that dictate what can be realistically enforced via technical mechanisms and which requirements are largely “do as your told” policies. In many cases, the technical implementation of a security model is not the limiting factor it is instead the cost of maintaining the implementation in production. Additionally, with a diminishing talent pool of technically knowledgeable developers it is often necessary to sacrifice technical capabilities for what can be easily integrated “off the shelf” to lessen the requisite skills of the implementers. Unfortunately, our environment has become one of volume and velocity for development of technologies rather than that of completeness or quality. As we move forward with the development of more and more complex systems, security still tends to be a “bolt on” after thought (as is testing) that tends to result in insecure systems that barely meet the operational needs of the end users. This is true across all client bases from industrial applications to defense systems to medical and business applications.

Custom Implementations While “off the shelf” implementations tend to minimize short-term development costs, the requirements emerging from many specialized communities are best realized by custom implementations or at least by abstracted interfaces to replaceable “off the shelf” products. One of the most dynamic area of requirements over the life of a system will tend to be those governing security. Security demands for an application may involve any combination of confidentiality, integrity, auditing and originator controls. When a combination of security demands are needed in a dynamic environment such as mission critical defense applications, there is no “one stop shop” for security implementations. It is not uncommon to be required to implement security for all forms of control on confidentiality and integrity to include aspects such as: Entity-level access (table security)

P age |6

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

Record-level access (row security) Column-level access Cell-level access (field or property per record) Spatial access o

Where a record is defined as existing in the world

o

Where the user is located at restricts access

Temporal access o

When a record is defined as existing in time

o

What time of day is access allowed

Job role access (RBAC) Operation access (execute, read, write, etc) Organizational access (organizational chain of command) o

Additionally may be contract based for “service providers”

Classification access (classification levels and compartments) Discretionary access (user-mode granting of any of the above) There are currently no solutions I have found that enable all of these forms of security access / integrity controls. In the case of any applications requiring such a level of security, a custom implementation is the most cost-effective and may be reused once originally constructed.

Conclusions Software policies are properly a conceptual guideline or formal written policy document that describes what is permitted and/or not permitted as standard operating practices. In conjunction with these policies, some mechanism of auditing and enforcement is generally implemented. The combination of

P age |7

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

policy and mechanism defines the overall security profile for the organization. While there are several models for both confidentiality and integrity that serve as both a mechanism and a physical policy, the combination of these models with written policies and continual physical monitoring is required to ensure compliance is met.

P age |8

Software Policies

Michael Corsello

Policy Paper

CSci 283 Computer Security

References Bishop, M. (2003). Computer Security. Boston: Addison Wesley. contributors, W. (2008, July 30). Computer security policy . Retrieved February 27, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Computer_security_policy&oldid=228880907 Landwehr, C. E. (1981). Formal Models for Computer Security. Computing Surveys , 247 - 278. Wulf, W., & E. Cohen, W. C. (1974). HYDRA: the kernel of a multiprocessor operating system. Communications of the ACM , 337–345.

P age |9

Software Policies