Design Principles for Secure Systems

1
Design Principles for Secure Systems
2
Learn From the Real World

• Real world security decisions based on
• value, locks, and police
• Need good enough locks so that the "bad guys"
  can't break in too often. The terms "good
  enough," "break in" and "too often" are key.
• Assume that the police and courts work, so "bad
  guys" are caught and punished. "Police" in this
  context is any agency that might pursue
  offenders.
• Expected gain from committing a crime must be
  negative. Value is important. Generally we do not
  protect things of little value.

3
Locks

• A constraint on any security mechanism is that it
  by minimally disruptive. Locks must not be
  difficult or annoying to use. If they are, people
  will find ways to circumvent the annoyance and
  thus nullify the security protections.
• Risk management allows recovery from a security
  problem and decreases the need for complex and
  annoying locks. For example, rather than
  installing a complicated locking system for
  automobiles we buy auto insurance to help deal
  with costs that arise in the event of damage or
  theft.

4
Locks and Security

• The environment also influences the type and
  strength of the locks being used as well.
• People pay for security they believe they need.
• Security is scaled with respect to both the value
  of the thing being secured and the threat against
  it.

5
Application to Computer Security

• Authentication and authorization along with
  cryptographic techniques are the locks.
• Confidentiality, Integrity, Availability is the
  value to be protected.
• Audit logs, and computer forensics techniques are
  added to police.

6
Design Principles

• Economy of Mechanism
• Open Design
• Principle of Least Privilege
• Complete Mediation
• Separation of Privilege
• Failsafe Defaults
• Diversity of Mechanism
• Multiple Lines of Defense

7
Economy of Mechanism

• Use simple and straightforward mechanisms
  wherever possible.
• Avoid a lot of extra features. Bells and
  whistles add complication, and that introduces
  errors.
• The simplest mechanism that does the job is the
  best.

8
Open Design

• No security through obscurity. The security of a
  mechanism should not depend on attacker's
  ignorance of how the mechanism works or is built.
  
• This principle is controversial. Showing a design
  or source code to attackers certainly makes their
  task easier. NSA, for instance, refused to
  publish their analysis that the DES encryption
  algorithm is secure. The lack of information,
  however, decreases people's assurance in the
  security of DES.
• Publicizing the design give security researchers
  the opportunity to find and fix the flaws before
  the attackers do.

9
Principle of Least Privilege

• Every program and every user should operate using
  the minimum set of privileges necessary to
  complete the job.
• This limits the damage that can result from an
  accident or error, and it limits the number of
  privileged programs (which could be compromised)
  in the system. It also helps in debugging, is
  good for increasing assurance, and allows
  isolation of small critical subsystems.

10
Complete Mediation

• Complete Mediation. Every access to every object
  is checked.
• Thus, some interfaces must be monitored---the
  interface might be defined in terms of method
  calls or it might be defined in terms of
  individual instructions.
• Example process for user A opens a file user A
  is terminated revoking all his privileges
  process accesses file which has been open for
  days and user privilege is not verified.
  (toattou)

11
Separation of Privilege

• Two keys are better than one. Each privilege
  should require a separate secret.
• Separate passwords for separate objects.
• This allows fine-grained control of access to the
  system, and limits what can be compromised if a
  single secret is revealed.
• Can be overly cumbersome for the user.

12
Failsafe Defaults

• No access by default. It is much better (and less
  prone to error) to define who can have access
  that to directly define who cannot.
• Problem user needs a privilege that was not
  anticipated so his work is delayed while the
  privilege is authorized.

13
Diversity of Mechanism

• Diversity of Mechanism Security mechanisms that
  have the same design or follow similar logic are
  likely to fail in similar ways (hence, at the
  same time or fall to the same trick of an
  attacker). Diverse mechanisms are unlikely to
  share vulnerabilities.
• With diverse mechanisms, the odds are increased
  that no single vulnerability is common to all.

14
Multiple Lines of Defense

• Unfortunately, no security mechanism is totally
  secure. Plan for something to fail and have a
  second (and third) line of defense.
• Example Try to keep the bad guys out (firewall)
  but if they do get in, minimize the harm they can
  do (strict access controls), and if they manage
  to get access, have good audit logs so you can
  track them down and prosecute.