Chapter Three: Principles of Security Design

Points to be Discussed:
➢ Economy of mechanism ➢ Psychological acceptability
➢ Fail-safe defaults ➢ Isolation
➢ Complete mediation ➢ Encapsulation
➢ Open design ➢ Modularity
➢ Separation of privilege ➢ Layering
➢ Least privilege ➢ Least astonishment
➢ Least common mechanism

By Bereket S.

1
 Introduction
➢ Cyber-security vulnerabilities are rampant (disease of criminal in cybersecurity, out of control).

➢ The majority of commodity computing and communication platforms have been designed to
meet performance and functionality requirements with little attention to trustworthiness.
➢ The transformation from traditional stand-alone computers to highly interconnected,
pervasive, and mobile computing systems, profoundly increases the vulnerabilities of current
systems, and exacerbates the need for more trustworthy computing and communications
platforms.

➢ In addition to security, other factors including performance, size, cost and energy
consumption must all be reasonably accounted for when building a secure system.
➢ These factors are especially important for viability in the commodity market, where client
computing devices have constrained resources but high performance requirements.

2
 Cont.
➢ Despite years of research and development, it has not been possible to develop security
design and implementation techniques that systematically exclude security flaws and prevent
all unauthorized actions.

➢ In the absence of such foolproof techniques, it is useful to have a set of widely agreed design
principles that can guide the development of protection mechanisms.

➢ The National Centers of Academic Excellence in Information Assurance/Cyber Defense,

which is jointly sponsored by the U.S. National Security Agency and the U.S. Department of
Homeland Security, list the following as fundamental security design principles [NCAE13]:

3
 Economy of mechanism
➢ This means that the design of security measures embodied in both hardware and software
should be as simple and small as possible.
➢ The motivation for this principle is that relatively simple, small design is easier to test and
verify thoroughly.
➢ With a complex design, there are many more opportunities for an adversary to discover
subtle weaknesses to exploit that may be difficult to spot ahead of time.
➢ The more complex the mechanism, the more likely it is to possess exploitable flaws.
➢ Simple mechanisms tend to have fewer exploitable flaws and require less maintenance.
➢ In practice, this is perhaps the most difficult principle to honor.
➢ The best that can be done is to keep this principle in mind during system design to try to
eliminate unnecessary complexity.

4
 Fail-safe defaults
➢ This means that access decisions should be based on permission rather than exclusion.
➢ That is, the default situation is lack of access, and the protection scheme identifies conditions
under which access is permitted.
➢ This approach exhibits a better failure mode than the alternative approach, where the default is
to permit access.
➢ A design or implementation mistake in a mechanism that gives explicit permission tends to fail
by refusing permission, a safe situation that can be quickly detected.
➢ On the other hand, a design or implementation mistake in a mechanism that explicitly excludes
access tends to fail by allowing access, a failure that may long go unnoticed in normal use.
➢ Most file access systems and virtually all protected services on client/server systems use fail-
safe defaults.

5
 Complete mediation
➢ Complete mediation means that every access must be checked against the access control
mechanism.
➢ Systems should not rely on access decisions retrieved from a cache.
➢ In a system designed to operate continuously, this principle requires that, if access decisions are
remembered for future use, careful consideration be given to how changes in authority are
propagated into such local memories.
➢ File access systems appear to provide an example of a system that complies with this principle.
➢ However, typically, once a user has opened a file, no check is made to see if permissions change.
➢ To fully implement complete mediation, every time a user reads a field or record in a file, or a
data item in a database, the system must exercise access control.
➢ This resource-intensive approach is rarely used.

6
 Open Design
➢ Open design means that the design of a security mechanism should be open rather than secret.

➢ For example, although encryption keys must be secret, encryption algorithms should be open to
public scrutiny.

➢ The algorithms can then be reviewed by many experts, and users can therefore have high
confidence in them.

➢ This is the philosophy behind the National Institute of Standards and Technology (NIST)
program of standardizing encryption and hash algorithms, and has led to the widespread
adoption of NIST-approved algorithms.

7
 Separation of Privilege
➢ Separation of privilege is defined as a practice in which multiple privilege attributes are required
to achieve access to a restricted resource.
➢ A good example of this is multifactor user authentication, which requires the use of multiple
techniques, such as a password and a smart card, to authorize a user.
➢ The term is also now applied to any technique in which a program is divided into parts that are
limited to the specific privileges they require in order to perform a specific task.
➢ This is used to mitigate the potential damage of a computer security attack.
➢ One example of this latter interpretation of the principle is removing high privilege operations
to another process and running that process with the higher privileges required to perform its
tasks.
➢ Day-to-day interfaces are executed in a lower privileged process.

8
 Least Privilege
➢ This means that every process and every user of the system should operate using the least set of
privileges necessary to perform the task.

➢ A good example of the use of this principle is role-based access control.

➢ The system security policy can identify and define the various roles of users or processes.

➢ Each role is assigned only those permissions needed to perform its functions.

➢ Each permission specifies a permitted access to a particular resource (such as read and write
access to a specified file or directory, connect access to a given host and port).

➢ Unless a permission is granted explicitly, the user or process should not be able to access the
protected resource.

9
 Cont.
➢ More generally, any access control system should allow each user only the privileges that are
authorized for that user.

➢ There is also a temporal aspect to the least privilege principle.

➢ For example, system programs or administrators who have special privileges should have those
privileges only when necessary;

✓ when they are doing ordinary activities the privileges should be withdrawn.

✓ leaving them in place just opens the door to accidents.

10
 Least Common Mechanism
➢ Least common mechanism means that the design should minimize the functions shared by
different users, providing mutual security.

➢ This principle helps reduce the number of unintended communication paths and reduces the
amount of hardware and software on which all users depend, thus making it easier to verify if
there are any undesirable security implications.

11
 Psychological Acceptability
➢ This implies that the security mechanisms should not interfere unduly with the work of users,
while at the same time meeting the needs of those who authorize access.
➢ If security mechanisms hinder the usability or accessibility of resources, then users may opt to
turn off those mechanisms.
➢ Where possible, security mechanisms should be transparent to the users of the system or at
most introduce minimal obstruction.
➢ In addition to not being intrusive or burdensome, security procedures must reflect the user’s
mental model of protection.
➢ If the protection procedures do not make sense to the user or if the user must translate his
image of protection into a substantially different protocol, the user is likely to make errors.

12
 Isolation
➢ Is a principle that applies in three contexts.
➢ First, public access systems should be isolated from critical resources (data, processes, etc.) to
prevent disclosure or tampering.
➢ In cases where the sensitivity or criticality of the information is high, organizations may want to
limit the number of systems on which that data is stored and isolate them, either physically or
logically.
➢ Physical isolation may include ensuring that no physical connection exists between an
organization’s public access information resources and an organization’s critical information.
➢ When implementing logical isolation solutions, layers of security services and mechanisms
should be established between public systems and secure systems responsible for protecting
critical resources.
➢ Second, the processes and files of individual users should be isolated from one another except
where it is explicitly desired.
13
 Cont.
➢ All modern operating systems provide facilities for such isolation, so that individual users have
separate, isolated process space, memory space, and file space, with protections for preventing
unauthorized access.

➢ And finally, security mechanisms should be isolated in the sense of preventing access to those
mechanisms.

➢ For example, logical access control may provide a means of isolating cryptographic software
from other parts of the host system and for protecting cryptographic software from tampering
and the keys from replacement or disclosure.

14
 Encapsulation
➢ Encapsulation can be viewed as a specific form of isolation based on object-oriented
functionality.

➢ Protection is provided by encapsulating a collection of procedures and data objects in a domain

of its own so that the internal structure of a data object is accessible only to the procedures of
the protected subsystem, and the procedures may be called only at designated domain entry
points.

15
 Modularity
➢ This in the context of security refers both to the development of security functions as separate,
protected modules and to the use of a modular architecture for mechanism design and
implementation.

➢ With respect to the use of separate security modules, the design goal here is to provide
common security functions and services, such as cryptographic functions, as common modules.

➢ For example, numerous protocols and applications make use of cryptographic functions.

➢ Rather than implementing such functions in each protocol or application, a more secure design
is provided by developing a common cryptographic module that can be invoked by numerous
protocols and applications
16
 Cont.
➢ The design and implementation effort can then focus on the secure design and implementation
of a single cryptographic module and including mechanisms to protect the module from
tampering.

➢ With respect to the use of a modular architecture, each security mechanism should be able to
support migration to new technology or upgrade of new features without requiring an entire
system redesign.

➢ The security design should be modular so that individual parts of the security design can be
upgraded without the requirement to modify the entire system.

17
 Layering
➢ Layering refers to the use of multiple, overlapping protection approaches addressing the people,
technology, and operational aspects of information systems.

➢ By using multiple, overlapping protection approaches, the failure or circumvention of any

individual protection approach will not leave the system unprotected.

➢ Layering approach is often used to provide multiple fences between an adversary and protected
information or services.

➢ This technique is often referred to as defense in depth.

18
 Least Astonishment
➢ Least astonishment means that a program or user interface should always respond in the way
that is least likely to astonish the user.

➢ For example, the mechanism for authorization should be transparent enough to a user that the
user has a good intuitive understanding of how the security goals map to the provided security
mechanism.

19