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)

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

P age |2 Software Policies

Michael Corsello Policy Paper CSci 283 Computer Security

o 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