The Protection of Information in Computer Systems Part I. Basic Principles of Information Protection

1
The Protection of Information in Computer
SystemsPart I. Basic Principles of Information
Protection

• Jerome Saltzer Michael Schroeder
• Presented by
• Bert Bruce

2
Overview

• Focus of paper on multiple user computer system
• User authority
• Who can do something to something
• Who can see something
• Privacy social
• Concern here is controlling access to data
  (security)

3
Security Violations

• Unauthorized release of information
• Unauthorized modification of information
• Unauthorized denial of use of information

4
Definitions

• Protection control access to information
• Authentication verify identity of user

5
Categories of Protection Schemes

• Unprotected
• Typical batch system
• Physical isolation (computer room)
• All or Nothing
• User totally isolated in the system
• No sharing of resources
• Typical of early TS systems (Dartmouth BASIC)

6
Categories of Protection Schemes

• Controlled Sharing
• OS puts limits on access
• TOPS-10 file system w/ WRX control
• User-programmed Sharing Controls
• Like OO files w/ access methods
• User control access as he likes
• Claims UNIX has this?

7
Categories of Protection Schemes

• Putting Strings on Information
• Trace or control information after released
• File retains access status even when others have
  it
• Overriding question on these schemes is how
  controls can change over time
• How is privilege changed?
• Can access privilege be modified or revoked on
  the fly?

8
Design Principles

• Since we cant build software without flaws, we
  need ways to reduce number and severity of
  security flaws
• What follows are 10 Design Principles to apply
  when designing and creating protection mechanisms
• They were true in 1975 and remain relevant today

9
Design Principles

• 1. Economy of Mechanism
• KISS Principle
• Easier to implement
• Allows total inspection of security mechanism

10
Design Principles

• 2. Fail-safe Defaults
• Default case should be to exclude access
• Explicitly give right to access
• The reverse is risky
• i.e. find reasons to exclude
• You may not think of all reasons to exclude

11
Design Principles

• 2. Fail-safe Defaults (cont.)
• Easier to find and fix error that excludes
  legitimate user
• He will complain
• Wont normally see error that includes
  illegitimate user
• He probably wont complain

12
Design Principles

• 3. Complete Mediation
• Check every access to objects for rights
• All parts of the system must check
• Dont just open the door once and allow all
  access after that
• Authority may change
• Access levels in security mechanism may change
  over time

13
Design Principles

• 4. Open Design
• Dont try security by obfuscation or ignorance
• Not realistic that mechanism wont be discovered
• Mechanism should be public
• Use more easily protected keys or passwords
• Can be reviewed and evaluated without
  compromising the system

14
Design Principles

• 5. Separation of Privilege
• 2 keys are better than one
• No one error or attack can cause security
  violation
• Similar to nuclear weapons authority process
• Not always convenient for user

15
Design Principles

• 6. Least Privilege
• Programs and users should run with least feasible
  privilege
• Limits damage from error or attack
• Minimize potential interaction among privileged
  programs
• Minimize unexpected use of privilege

16
Design Principles

• 6. Least Privilege (cont.)
• Designing this way helps identify where privilege
  transitions are
• Identifies where firewalls should go
• Analogous to the Need to Know principle

17
Design Principles

• 7. Least Common Mechanism
• Minimize mechanisms shared by all users (e.g.
  shared variables)
• Shared data can be compromised by one user
• If always shared, all users need to be satisfied
• Example shared function should be run in users
  space rather than as system procedure

18
Design Principles

• 8. Psychological Acceptability
• Design for ease of use
• Then it will be used and not avoided or
  compromised for users convenience
• Model the mechanism so the user can easily
  understand
• Then he will use as intended

19
Design Principles

• 9. Work Factor
• Make it cost more to compromise security than it
  is worth
• Automation can make this principle difficult to
  follow
• Work factor may be difficult to calculate
• Perhaps Public Key Encryption falls into this
  category

20
Design Principles

• 10. Compromise Recording
• Note all security breaches (and then change
  plan?)
• E.g. note each file access time
• Not very practical, since cant tell what data
  has been taken or modified

21
Summary

• No security system is perfect at best we
  minimize the vulnerabilities
• Technology may advance but engineering design
  principles which were good in 1975 remain
  relevant today

22
Technical Underpinnings

• The remainder of the section discusses some high
  level technical details
• Some of these were not common in 1975 but have
  become so
• E.g. most modern processor architectures have
  relocation and bounds registers and multiple
  protection bits

23
Authentication Mechanisms

• Passwords
• Little has changed since then
• Still easy to guess or snoop
• Biometric or physical electronic key can still be
  snooped
• Bidirectional authentication is better
• Defeats snooping
• Im not aware us usage in computer systems today

24
Shared Information Protection Schemes

• List-oriented
• Who is authorized?
• Need to do look-up
• Slow if lots of accesses
• Ticket-oriented
• User has a token that grants access
• Like key to a lock
• Need technology to deter forged tickets
• Like todays certificates

25
Shared Information Protection Schemes

• List-oriented
• Often used at the human interface
• E.g. login
• Ticket-oriented
• Most often used at the file access level