What Makes a Good Security Policy? Properties of Security

What Makes a Good Security Policy? The characteristics of a good security policy are: 1. It must be implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods. 2. It must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible. 3. It must clearly define the areas of responsibility for the users, administrators, and management. Basic Properties of Security (Basic Principles of Security):

What Makes a Good Security Policy?


The characteristics of a good security policy are:

1. It must be implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods.

2. It must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible.

3. It must clearly define the areas of responsibility for the users, administrators, and management.

Basic Properties of Security (Basic Principles of Security):

Confidentiality: Let X be a set of entities and let I be some information. Then I has the property of confidentiality with respect to X if no member of X can obtain information about I. Confidentiality implies that information must not be disclosed to some set of entities. It may be disclosed to others. The membership of set X is often implicit – for example, when we speak of a document that is confidential. Some entity has access to the document. All entities not authorized to have such access make up the set X.

Integrity: Let X be a set of entities and let I be some information or a resource. Then I has the property of integrity with respect to X if all members of X trust I. In addition to trusting the information itself, the members of X also trust that the conveyance and storage of I do not change the information or its trustworthiness (this aspect is sometimes called data integrity). If I is information about the origin of something, or about an identity, the members of X trust that the information is correct and unchanged (this aspect

is sometimes called origin integrity or, more commonly, authentication). Also, I may be a resource rather than information. In that case, integrity means that the resource functions correctly (meeting its specifications). This aspect is called assurance. As with confidentiality, the membership of X is often implicit.

Availability: Let X be a set of entities and let I be a resource. Then I has the property of availability with respect to X if all members of X can access I. The exact definition of "access" varies upon the needs of the members of X, the nature of the resource, and the use of the resource. If a book-selling server takes up to 1 hour to service a purchase request, that may meet the client's requirements for "availability." If a server of medical information takes up to 1 hour to service an anesthetic allergy information request, that will not meet an emergency room's requirements for "availability."

Policy can be expressed in:

- Natural language, which is usually imprecise but easy to understand;
- Mathematics, which is usually precise but hard to understand;
- Policy languages, which look like some form of programming language and try to balance precision with ease of understanding.

Security Mechanism:

Security Mechanism is a method, tool, or procedure for enforcing a security. A security mechanism is an entity or procedure that enforces some part of the security policy. If there is a conflict in policies, discrepancies may create security vulnerabilities. A security mechanism is an entity or procedure that enforces some part of the security policy. Mechanisms may be

- Technical mechanism enforces the policy inside the system. For example, mechanism that enables a password to authenticate user before using the computer.

- Procedural mechanism enforces the policy outside the system. For example, mechanism that sensor's a disk containing a game program obtained from an unreliable source.

Consider a scenario; suppose a university’s computer lab has a policy that prohibits any student from copying another student’s homework files. The computer system provides mechanisms for preventing others from reading a user’s file. Suppose, Anna fails to use these mechanisms to protect her homework files, and Bill copies them. A breach of security has occurred, because Bill has violated the security policy. If the policy said students has to read-protect their homework files, then Anna did breach security, as she didn’t do this.

Example: In the preceding example, the policy is the statement that no student may copy another student's homework. One mechanism is the file access controls; if the second student had set permissions to prevent the first student from reading the file containing her homework, the first student could not have copied that file.

Security policies are often implicit rather than explicit. This causes confusion, especially when the policy is defined in terms of the mechanisms. This definition may be ambiguous - for e.g., if some mechanisms prevent a specific action and others allow it. Such policies lead to confusion, and sites should avoid them.

The difference between a policy and an abstract description of that policy is crucial to the analysis that follows. A security model is a model that represents a particular policy or set of policies. A model abstracts details relevant for analysis. Analyses rarely discuss particular policies; they usually focus on specific characteristics of policies, because many policies exhibit these characteristics; and the more policies with those characteristics, the more useful the analysis. There is a result that says no single nontrivial analysis can cover all policies, but restricting the class of security policies sufficiently allows meaningful analysis of that class of policies.

Goals of Security:

Prevention is to prevent the attackers from violating security policy. Prevention means that an attack will fail. Typically, prevention involves implementation of mechanisms that users can not override and that are trusted to be implemented in a correct ways so that the attacker can't defeat the mechanism by changing it.

Detection is to detect attackers’ violation of security policy. So it occurs after someone violates the policy. The mechanism determines that a violation of the policy has occurred (or is underway) due to attack, and reports it. The system must then respond appropriately. Detection is most useful when an attack can't be prevented.
Recovery is to stop attack and to assess and repair any damage caused by attack. With recovery, it should be such that the system continues to function correctly, possibly after

a period during which it fails to function correctly, due to attacks.

For example if the attacker deletes a file, one recovery mechanism is to restore the file from backup tapes.

Protection State:

The state of a system at any instance is defined by the collection of the current values of all memory locations, all secondary storage, and all registers and other components of the system. The subset of this collection that deals with protection defines the protection state of the system. Access control matrix model is the most precise model used to describe a protection state.

Consider a set of possible protection states P. Suppose there is a subset Q of P consists exactly those states in which system is authorized to reside. So, whenever the system state is in Q, the system is supposed to be secure. When the system state is in P-Q, the system is not secure. So enforcing security means that the system state is always from the subset Q. Any operations like reading, writing, altering and execution of data or instruction cause the change in state of the system i.e., state transition occurs. We are concerned with only those state transitions that will lead to the authorized states.

Access Control Matrix Model:

Access to protected information must be restricted to people who are authorized to access the information. The computer programs, and in many cases the computers that process the information, must also be authorized. This requires that mechanisms be in place to control the access to protected information

Access control matrix model is the simplest framework for describing a protection system. It defines the right of users over files in matrix.

- Set of objects O; the set of all protected entities that are relevant to the protection state.
- Set of subjects S; set of active objects such as processes and users
Now the access control matrix model designated by a matrix A defines the relationship between these entities with the rights drawn from a set of rights R in each entry of , where , , and . The subject s has a set of rights over the object o. The set of protection states of the system is represented by the triple (S, O, A)

For example:

file1 file2 process1 process2

Process 1 read, write read read, write, write own execute, own

Process 2 append read, own read read, write execute, own

Access Control List(ACL)

Access Control List is the easier way to represent access control matrix and it is most commonly used implementation of access control matrix. The ACL permits any given user to be allowed or disallowed access to any object. The columns of an ACL show a list of users attached to protected objects. One can associate access rights for individuals and resources directly with each object.

Assumptions and Trust:
All security policies and mechanisms rest on assumptions specific to the type of security and the environment in which it is to be employed.

As policies are to define the issue of security, they have to define security correctly for the particular site. For example, a web site has to be available, but if the security policy does not mention availability, the definition of security is inappropriate for the site. Also, a policy may not specify whether a particular state is “secure” or “non-secure.” This ambiguity causes problems. Hence proper assumptions should be made before defining a concrete policy.

As mechanisms are to enforce policy, they must be appropriate. For example, cryptography does not assure availability, so using cryptography in the above situation won’t work. Trusting the mechanisms work requires several assumptions;

- each mechanism is designed to implement one or more parts of security policy,

- the union of mechanisms implements all aspects of the security policy,

- the mechanisms are implemented correctly,

- the mechanisms are installed and administered correctly

e security mechanisms may be secure, precise, or broad. Let P defines set of all possible states.


Secure Precise Broad
Possible States (P)
Secure States (Q)
Reachable States (R)
Set Q be the set of secure states, as specified by the security policy. Let R be the set of some reachable states that a system can enter ( ).

Then a security mechanism is;
- secure if all the reachable states, R are in the set of secure states Q, i.e. .
- precise if all the reachable states are secure and all the secure states are reachable, i.e.
- broad if some reachable states are non secure states, i.e. there are states r such that and .

Assurance:
Assurance is a measure of how well the system meets its requirements; more informally, how much we can trust the system to do what it is supposed to do. It does not say what the system is to do; rather, it only covers how well the system does it. System specification, design and implementation can provide a basis for determining “how much” to trust a system. This aspect of trust is the assurance. It is an attempt to provide a basis for supporting how much one can trust a system.
Specification is a statement of the desired functioning of the system. Specifications arise from requirements analysis, in which the goals of the system are determined. The specification says what are the requirements and what the system must do to meet those requirements. It is a statement of functionality, not assurance, and can be very formal (mathematical) or informal (natural language). The specification can be high-level or low-level (for example, describing what the system as a whole is to do vs. what specific modules of code are to do).

Design architects the system to meet the specifications. The design of a system translates the specification into the components that will implement them. The design is said to satisfy the specification if the design will not permit the system to violate those predefined specifications.

Typically, the design is layered by breaking the system into abstractions, and then refining the abstractions as we work our way down to the hardware. An analyst also must show whether the design matches specifications or not.

Implementation is the actual coding of the modules and software components. These must be correct (perform as specified), and their aggregation must satisfy the design. Thus, implementation creates a system that satisfies the design. This leads that implementation will also satisfy the specifications.

Operational Issues with Security:

Security does not end when the system is completed. Its operation affects security. A “secure” system can be breached by improper operation (for example, when accounts with no passwords are created). The problem is how to assess the effect of operational issues on security.

Cost-Benefit Analysis: This weighs the cost of protecting data and resources with the costs associated with losing the data. If the data or resources cost less, or are of less value, than their protection, adding security mechanisms and procedures is not cost-effective because the data or resources can be reconstructed more cheaply than the protections themselves.

Similarly other considerations are the overlap of mechanisms’ effects (one mechanism may protect multiple services, so its cost is amortized), the non-technical aspects of the mechanism (will it be impossible to enforce), and the ease of use (if a mechanism is too cumbersome, it may cost more to retrofit a decent user interface than the benefits would warrant).

Risk Analysis: Risks are events or conditions that may occur, and whose occurrence, if it does take place, has a harmful or negative effect. A risk analysis involves identifying the most probable threats to a system and analyzing the related vulnerabilities of the system to these threats. The risk analysis also should determine the impact of each type of potential threat on various functions or units within the system.

What happens if the data and resources are compromised? This tells us what we need to protect and to what level. Cost-benefit analyses help determine the risk here, but there may be other metrics involved (such as customs).

Laws and Customs: These constrain what you can do. E.g. Encryption use can be unlawful. Laws restrict the availability and use of technology and affect procedural controls. Hence any policy and any selection of mechanisms must take into account legal considerations. Customs involve non-legislated things, like the all the employees are to provide their DNA samples in a company for authentication purpose. That is legal for the company, but it is not socially acceptable, as an alternative to a password. Thus society/customs distinguish between legal and acceptable practices.

Human Issues with Security:
Organizational Problems:
With the organizational problems, the question is of who is responsible for security. The key here is that those responsible for security have the power to enforce security. Otherwise there is confusion, and the architects need not worry if the system is secure because they won’t be blamed if someone gets in. This arises when system administrators, for example, are responsible for security, but only security officers can make the rules. Preventing this problem (power without responsibility or vice versa) is tricky and requires capable management. What’s worse is that security is not a direct financial incentive for most companies because it doesn’t bring in revenue. It merely prevents the loss of revenue obtained from other sources.

Lack of resource is another common problem. Securing a system requires resources as well as people. It requires time to design a configuration that will provide a sufficient level of security, to implement the configuration, and to administer the system.

People problems:
People problems are by far the main source of security problems. Outsiders are attackers from without the organization; insiders are people who have authorized access to the system and, possibly, are authorized to access data and resources, but use the data or resources in unauthorized ways. It is speculated that insiders account for 80-90% of all security problems, but the studies generally do not disclose their methodology in detail, so it is hard to know how accurate they are. Social engineering, or two-faced, is quite effective, especially if the people gulled are inexperienced in security (possibly because they are new, or because they are tired).

The Security Life Cycle: Threats

Policy

Specification

Design

implementation

Operation and Maintenance

The considerations discussed till now appear to flow linearly from one to the next as shown in figure above. In addition, each stage of the cycle feeds back to the preceding stage, and through that stage to all earlier stages. Thus each stage affects all the ones that come before it. Feedback from operation and maintenance is critical, and often overlooked. It allows one to validate the threats and the legitimacy of the policy.

You May Also Like...

Socialize with Us