Specific design principles underlie the design and implementation of mechanisms for supporting policies. These principles build on the ideas of simplicity and restriction. Simplicity reduces the potential for inconsistencies within a policy or set of policies. Restriction minimizes the power of an entity. The entity can access only information it needs. [1]

Saltzer and Schroeder [2] describe eight principles on the ideas of simplicity and restriction:

1. Principle of least privilege – states that a subject should be given only those privileges that it needs in order to complete a task.
   • If a subject does not need an access right, the subject should not have it.
   • The function of the subject should control the assignment of rights
     • If specific actions require that a subjects access right be augmented, those extra rights should be relinquished immediately on completion of the action.
   • Requires that processes be confined to as small a protection domain as possible.
2. Privilege of fail-safe defaults – states that, unless a subject is given explicit access to an object, it should be denied access to that object.
   • Requires that the default access to an object be none.
   • If a subject is unable to complete its action or task, it should undo those changes it made in the security state of the system before it terminates so that even if the program fails the system is still safe.
3. Principle of economy of mechanism – states that security mechanisms should be as simple as possible.
   • If a design and implementation are simple, fewer possibilities exist for errors.
   • The checking and testing process is less complex, because fewer components and cases need to be tested.
4. Principle of complete mediation – requires that all accesses to objects be checked to ensure that they are allowed.
   • If the system checks that a user has permission to access a file and then permission is granted to access the resource, the next time the user requests that same file, the system should again check if the subject is still allowed to access the resource. Do not cache the results of the first check!
5. Principle of open design – states that the security of mechanism should not depend on the secrecy of its design or implementation.
   • It should be assumed that attackers know or can find out all the design details of the system through some means and therefore secrecy of the design should not be part of the security.
6. Principle of separation of privilege – states that a system should not grant permission based on a single condition.
7. Principle of least common mechanism – states that mechanisms used to access resources should not be shared.
   • Sharing resources  provides a channel along which information can be transmitted, so this should be minimized.
8. Principle of psychological acceptability– states that security mechanisms should not make the resource more difficult to access than if the security were not present.
   • Configuring and executing a program should be as easy and as intuitive as possible and any output should be clear, direct and useful.
   • If security related software is too complicated to configure, administrators may unintentionally setup the software in a nonsecure manner.

—

[1] Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005

[2] J. Saltzer and M. Schroeder, The Protection of Information in Computer Systems, Proceeding of the IEEE 63 (9), pp. 1278-1308 (Sep. 1975)

Computer security is concerned with three main components:

• confidentiality
  • the concealment of information or resources. keeping information secret.
  • includes concealing the existence of data or information
  • includes resource hiding (concealing configuration or types of systems being used)
• integrity
  • the trustworthiness of data or resources
  • preventing improper or unauthorized change of data or resources
  • considers the content of the information and the the source
    • source of the information will impact on its accuracy and credibility as well as the trust people will place in the information
• availability
  • the ability to use the information or resources desired
    • is the system reliable? unavailable systems are not useful for anyone!

Threats

“A threat is a potential violation of security. The violation need not actually occur for there to be a threat. The fact that the violation might occur means that those actions that could cause it to occur must be guarded against. [1]”

Shirley divides threats into four main classes [2]:

• disclosure
  • unauthorized access to information
• deception
  • acceptance of false data
• disruption
  • interruption or prevention of correct operation
• usurpation
  • unauthorized control of some part of a system

Types of Threats

• Snooping
  • unauthorized interception of information
  • form of disclosure
  • confidentiality services used to counter this type of threat
• Modification or alteration
  • unauthorized change of information
  • form of deception, disruption or usurpation
  • integrity services used to counter this type of threat
• Masquerading or spoofing
  • impersonation of one entity by another
  • form of deception and usurpation
  • integrity services used to counter this threat
• Repudiation of origin
  • false denial that an entity sent or created something
  • form of deception
  • integrity mechanisms used to counter this threat
• Denial of receipt
  • false denial that an entity received some information or a message
  • form of deception
  • integrity and availability mechanisms used to counter this threat
• Delay
  • temporary inhibition of a service
  • form of usurpation
  • availability mechanisms used to counter this threat
• Denial of service
  • long-term inhibition of a service
  • form of usurpation
  • availability mechanisms used to counter this threat

Critical to the study of security is the distinction between policy and mechanism

A security policy is a statement of what is, and what is not, allowed

A security mechanism is a method, tool, or procedure for enforcing a security policy.

Mechanism can be non-technical, such as requiring proof of identity before changing a password; in fact policies often require some procedural mechanisms that technology cannot enforce. [1]

Goals of Security

• Prevention
  • Ensure that an attack fails
  • involves implementation of mechanisms that users cannot override and that are trusted to be implemented in a correct, unalterable way, so that the attacker cannot defeat the mechanism by changing it
  • very cumbersome and interfere with system use to the point that they can hinder normal use of the system
  • Example of a simple prevention mechanism that is widely accepted is passwords
• Detection
  • useful when an attack cannot be prevented
  • can indicate the effectiveness of preventative measures
  • goal is to determine when an attack is taking place and to report it
• Recovery
  • stop an attack and then assess and repair any damage caused
  • complex because they nature of each attack can be unique
  • recovery also involved the follow-up step of identification of the problem and then fixing of the vulnerability
  • restoration from system backups is an example of recovery

Assumptions and Trust

Designers of policies always make two assumptions:

1. The policy correctly and unambiguously partitions the set of system states into “secure” and “nonsecure” states.
2. The security mechanisms prevent the system from entering a “nonsecure” state.

If either assumption is erroneous, the system will be nonsecure. [1]

Assurance

How much can a system be trusted? Have specific tests been taken to ensure that the computer will function properly?

Specification

• A formal statement of the desired functioning of the system
• Can be informal or highly mathematical

Design

The design of a system translates the specifications into components that will implement them. The design is said to satisfy the specifications if, under all relevant circumstances, the design will not permit the system to violate those specifications. [1]

Implementation

Given a design, the implementation creates a system that satisfies that design. If the design also satisfies the specifications, then by transitivity the implementation will also satisfy the specifications. The difficulty is proving that a program correctly implements the design and specifications. A program is correct it its implementation performs as specified. [1]

Operational Issues

Any useful policy and mechanism must balance the benefits of the protection against the cost of designing, implementing, and using the mechanism. This balance can be determined by analyzing the risks of a security breach and the likelihood of it occurring.

Risk Analysis

The level of protection required is a function of the probability of an attack occurring and the effects of the attack should it succeed. If an attack is unlikely, protecting against it has lower priority. If the unlikely attack would cause long delays in an organizations ability to provide service but the likely attack would only be a nuisance, then more effort should be put into preventing the unlikely attack. [1]

Organizational and People Problems

Losses can still occur even with security protection in place. Losses are expected to be less than they would have been without any security measures. One problem is that the extra security can add complexity to operations so this may result in a loss of productivity. It is important to consider then if the reduced losses plus the loss in productivity is less than the loss that would have occurred without the security in the first place.

—

[1] Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005

[2] R.Shirley, Security Architecture for Internet Protocols: A Guide for Protocol Designs and Standards, Internet Draft: draft-irtf-psrg-secarch-sec1-00.txt (Nov. 1994)