THEORY

Security Design Principles

In 1975, Jerome Saltzer and Michael Schroeder published "The Protection of Information in Computer Systems," which outlined a series of design principles for secure systems. Most of the principles they proposed have become staples of information security practice. The PDF version of the paper is provided as a link in blackboard. Over the years the principles they proposed in addition of few new ones that were added over the years, provide useful guidelines for practitioners of information security. These principles are explained and summarized below.

Principle of Least Privilege

A subject should be given only those privileges that it needs in order to complete its task, no more and no less. The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions. Limit the access that entities have to resources and what they can do with them. In the case of users, identify who needs access to the system, what they are required to do when using the system, and what they need access to. Then allow them the least privilege needed to do their task(s). Note that this requires identifying all users of the system (human and programmatic), their roles, and the objects they need access to in order to complete their role-based tasks. Individuals or objects with dual roles should use the role with the least privilege granted for tasks that don't require elevated privilege.

The function of a subject should control the assignment of rights, not the identity of the subject. This means that if your boss demands root access to a UNIX system that you administer, (s)he should not be given that privilege unless (s)he absolutely has a task that requires such level of access. If possible, the elevated rights of an identity individual should be removed as soon as those rights are no longer required. Similarly, if a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.

Principle of Fail Safe Defaults

Systems sometimes fail for different reasons. How they fail can determine if an application is secure or not. Knowing that, the system should be designed so that if it fails, it should do so safely (without causing undue risk or harm to individuals, processes, or assets). Where security systems fail, security should not be compromised and undue additional risk should not occur. For example, if a log-in feature of a system were to fail it should not allow users additional security rights, access, or privileges.

For example:

isAdmin = true;

try {

codeWhichMayFail();

isAdmin = isUserInRole( Administrator );

}

catch (Exception ex) {

log.write(ex.toString());

}

If either codeWhichMayFail() or isUserInRole fails or throws an exception, the user is an admin by default. This is obviously a security risk.

One way to support that is to disable or deny by default all rights, access, and privilege not explicitly granted in advance. When processes fail they should issue error messages and terminate, not change their actions or expand their privileges (or the privileges of other processes left running). Failed process task steps should be undone before saving the system state and ending the process. In short, system security should be unaffected by failure of the system or portion of it.

Principle of Economy of Mechanism

Security mechanisms should be as simple as possible. Simpler means less can go wrong and when errors occur, they are easier to understand and fix. This principle simplifies the design and implementation of security mechanisms. If the design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex. Interfaces between security modules are suspect area and should be as simple as possible.

Larger, more complex systems are more likely to have security gaps, simply due to their complexity. Software is logically fragile; every program is likely to have flaws of one kind or another. Reducing the number of applications on a device should reduce the risk that the device has on it software that can be compromised. The simpler a system is, the easier it should be to secure it. Conversely, the more applications you have on your device (the bigger the attack surface or footprint), the more likely it is that it can be compromised. Attack surface area and simplicity go hand in hand.

Principle of Complete Mediation

The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed. This principle ensures that authority is not circumvented in subsequent requests of an object by a subject, by checking for authorization (rights and privileges) upon every request for the object.

This principle restricts the caching of information, which often leads to simpler implementations of mechanisms. Every time that someone tries to access an object, the system should authenticate the privileges associated with that subject. What happens in most systems is that those privileges are cached away for later use. The subjects privileges are authenticated once at the initial access. For subsequent accesses the system assumes that the same privileges are enforce for that subject and object. This may or may not be the case. The operating system should mediate all and every access to an object.

Principle of Open Design

The open design security principle states that the implementation details of the design should be independent of the design itself, which can remain open, unlike in the case of security by obscurity wherein the security of the software is dependent upon the obscuring of the design itself. Security should not depend on keeping its design or implementation secret. Security through obscurity is not a good idea as a knowledgeable user can eventually breach security that depends on attacker ignorance. Avoid security through obscurity.

Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.

For example, the security of an application should not rely upon knowledge of the source code being kept secret. The security should rely upon many other factors, including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls. A practical example is Linux. Linuxs source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.

When software is architected using the open design concept, the review of the design itself will not result in the compromise of the safeguards in the software. The security of a mechanism should not depend on the secrecy of its design or implementation. If the details of the mechanism leaks then it is a catastrophic failure for all the users at once. If the secrets are abstracted from the mechanism, e.g. inside a key, then leakage of a key affects only one user.

Principle of Separation of Privilege

The principle of separation of privileges states that a system should not grant permission based on a single condition. In other words: more than one condition must be verified in order to gain access. This principle is restrictive because it limits access to system entities. Thus before privilege is granted two or more check should be performed. An example, a company check for anything over $50,000 must be signed by two officers of a company.

Separation of privilege removes a single point of failure. It requires multiple conditions to grant privilege and two or more system components work together to enforce security.

Principle of Least Common Mechanism

The principle of least common mechanism states that mechanisms used to access resources should not be shared. The security principle of least common mechanisms disallows the sharing of mechanisms that are common to more than one user or process if the users and processes are at different levels of privilege. For example, the use of the same function to retrieve the bonus amount of an exempt employee and a non-exempt employee will not be allowed. In this case the calculation of the bonus is the common mechanism.

This principle is also restrictive because it limits sharing of resources. Sharing resources provides a channel along which information can be transmitted. Hence, sharing should be minimized as much as possible. If the operating system provides support for virtual machines, the operating system will enforce this privilege automatically to some degree.

Principle of Psychological Acceptability

Security mechanisms should not make the resource more difficult to access than if the security mechanism were not present. A security principle that aims at maximizing the usage and adoption of the security functionality in the software by ensuring that the security functionality is easy to use and at the same time transparent to the user. Ease of use and transparency are essential requirements for this security principle to be effective. Security mechanisms should not make the resource more difficult to access than if the security mechanism were not present.

This principle recognizes the human element in computer security. If security-related software or systems are too complicated to configure, maintain, or operate, the user will not employ the requisite security mechanisms. For example, if a password is rejected during a password change process, the password changing program should state why it was rejected rather than giving a cryptic error message. At the same time, programs should not impart unnecessary information that may lead to a compromise in security. In practice, the principle of psychological acceptability is interpreted to mean that the security mechanism may add some extra burden, but that burden must be both minimal and reasonable.

Example, when you enter a wrong password, the system should only tell you that the user id or password was wrong. It should not tell you that only the password was wrong as this gives the attacker information.

Reference:

OWASP Development Guide Security by Design Principles

QUESTIONS

For the scenarios/examples 1 through 9, identify the most appropriate security design principle that applies to it and also explain your choice of principle that applies to the example with reasons. Each question is 10 points each.

1. Launch codes for Titan II nuclear missiles were stored in this safe. The two-person launch team had to work together to unlock the codes and launch the missile; neither could launch the missile independently.

2. This is the rationale behind Unix sudo and Windows User Account Control, both of which allow users to temporarily apply administrative rights to perform a privileged task instead of being continuously enabled.

3. Even the US National Security Agency, which resisted open crypto designs for decades, now uses the Advanced Encryption Standard (AES) to encrypt classified information. Unlike the previous encryption standard the US government adopted, AES was refined using an open process that published the results of the tests and analyses that led to its selection.

4. A classic example arises when two weakly shielded audio cables are bundled together: a loud signal on one might leak into the other, creating noise or even broadcasting the other cable's signal. Similar covert channels might arise when separate processes execute with shared CPU, RAM, or I/O resources.

5. Passwords fail this principle: users have been harangued for decades about picking hard to guess passwords, not sharing them, not using the same one in multiple places, and so on. User surveys and security breaches repeatedly illustrate that many people don't follow those recommendations.

6. A retail store keeps its back door closed and locked to prevent thefts. An outsider cant enter a store via an emergency exit, and insiders may use it only in emergencies. panic lock allows the door to open during an emergency.

7. A system operator should not perform security administration functions

8. An authentication mechanism that requires both biometric and token recognition systems.

9. Viruses cause havoc because, any program or script that is downloaded or received as email attachment, runs with the privileges of the user that runs them. Or worse the privileges of the application.

10. A bluetooth Device A wants to establish a key with another bluetooth device B

Mechanism 1: they agree upon a common trusted CA, get certificates from this CA and for example, use STS protocol to establish a key

Mechanism 2: they use a physical channel (e.g., an audio channel) to establish a key.

Which of the two mechanisms above adheres better to the principle of economy of mechanism?