Software Infrastructure for Electronic Commerce Computer Security Principles

1
Software Infrastructure forElectronic
Commerce Computer Security Principles

• Professor Fred B. Schneider
• Dept. of Computer Science
• Cornell University

2
Goals

• Develop a framework for thinking about computer
  security.
• Introduce the vocabulary used by practitioners.
• Understand what existing computer security
  technology can and cannot accomplish.

3
Security Pre-Cyberspace

• Security is all about ...
• value
• locks
• police and courts
• Locks must be good enough to prevent the bad
  guys from breaking in too often.
• Some bad guys are caught.
• Police and courts convict often enough to
  discourage break-ins.

4
Locks in the real world

• Must not be annoying or they wont be used.
• All locks arent the same. They are
• Scaled for what they are protecting.
• Scaled for their environment.
• Police and courts are central---not the locks!
• We expect security breaches.
• Tracking down the bad guys is whats central.
• Locks reduce temptation and reduce workload on
  police and courts.

5
The big picture

• People only pay for security that they think they
  need.
• need is based on personal experience others
  experiences.
• People avoid annoying locks by buying insurance.
• Risk avoidance versus risk management.
• Externalities is a wrinkle!
• Security is holistic
• Security is only as strong as the weakest link.
• Making any link stronger than the weakest link
  doesnt much improve security.

6
Security In Cyberspace

• Terminology
• vulnerability Weakness that can be exploited to
  cause damage.
• attack Method of exploiting a vulnerability.
• threat Motivated capable adversary who will
  mount attacks.
• All systems have vulnerabilities.
• We must understand the threats and defend against
  attacks they can mount.

7
Cyber threats

• Operator/user blunders.
• Hackers driven by intellectual challenge (or
  boredom).
• Insiders employees or customers seeking revenge.
• Criminals seeking financial gain.
• Organized crime seeking gain or hiding criminal
  activities.
• Organized terrorist groups or nation states
  trying to influence national policy.
• Foreign agents seeking information for economic,
  political, or military purposes.
• Tactical countermeasures intended to disrupt
  military capability.
• Large organized terrorist groups or nation-states
  intent on overthrowing the US government.

8
What do we protect in cyberspace?

• Attacks compromise
• Secrecy (confidentiality) causing improper
  disclosure of information.
• But what constitutes a secret, anyway?
• Integrity causing improper alteration of
  information.
• Availability causing service outages.

9
Security In Cyberspace (cont)

• Security is all about ...
• value
• locks
• police and courts
• Locks authorization or access control
  mechanisms.
• Locks have keys.
• Keys are authentication mechanisms
• something you have, know, or are.
• Police and courts same as before.
• Need authentication for audit information.

10
Computer Security Gold Standard

• Authentication
• Authorization
• Audit
• (N.B. Au is the chemical symbol for Gold.)

11
Lock Design

• Security mechanisms are an integral part of your
  systems software.
• Difficult to improve or to change.
• Technical details are boring.
• We discuss principles that underlie all
• Assurance Principles.
• Functionality Principles.

12
Lock Design Assurance

• Economy of Mechanism Use small and simple
  mechanisms where possible.
• Consequences
• Fewer errors in implementation because simpler.
• Easier to analyze for yourself.

13
Lock DesignAssurance Principles

• Open Design Security of a mechanism should not
  depend on an attackers ignorance of the design.
• A. Kerckhoffs Principle (1883) The security of a
  cryptosystem must not depend on keeping the
  algorithm secret.
• No security by obscurity.
• Consequences
• Increased assurance if many critics.
• Reduced cost of recovering from key compromise.

14
Lock DesignAssurance Principles Open Design?

• Open Design is controversial.
• With open design
• Attackers job is easier because design is
  available.
• Analysis tends to concentrate on certain main
  code. Vulnerabilities off the beaten path
  remain.
• Flaws are not always revealed.

15
Lock DesignFunctionality Principles

• What should the lock do?
• Must distinguish policy
• from mechanism.
• Desire mechanisms that implement many policies.

certificate revocation lists
digital signatures
access control lists
capabilities
public key cryptosystem
16
Some Security Policies

• Discretionary access control
• Owner controls access to objects.
• E.g, Windows NT PropertiesSecurityPermissio
  ns
• Does not rule out trojan horse attacks.

17
Some Security Policies

• Mandatory Access Control
• Allows a subject to
• Read less-classified document.
• Write more-classified document.
• Requires declassification!

top secret
secret
classified
unclassified
18
Some Security Policies

• Clark-Wilson Commercial Policies
• Well-formed Transactions
• E.g. double-entry bookkeeping
• E.g. log all shipments
• Separation of Duty
• E.g. auditor vs controller

19
Lock DesignFunctionality Principles

• Principle of Least Privilege A
  task/process/user is accorded the minimum set of
  privileges needed to get the job done.
• Consequences
• Limits Damage that can result from attack or
  error.
• Limits number of programs that can be compromised
  to effect an attack.
• Helps with debugging.
• Example super-user or admin privileges.

20
Lock DesignFunctionality Principles

• Corollary of Principle of Least Privilege
• Complete Mediation Every access to every object
  is checked.
• Some implicit assumptions
• Some interface is being monitored.
• Mediation mechanism cannot be compromised.

21
Lock DesignFunctionality Principles

• Corollary of Principle of Least Privilege
• Failsafe Defaults Access decisions are based on
  the explicit presence of permissions rather than
  their absence of explicit prohibitions.
• Safe way to tolerate administrative oversight.

22
Lock DesignFunctionality Principles

• Corollary of Principle of Least Privilege
• Separation of Privilege Each lock should
  require a separate key.
• Consequences
• Allows fine-grained control and therefore
  supports PoLP with higher fidelity.
• Can be a sys admin nightmare.

23
Where to Deploy Locks

• Axiom Every system has vulnerabilities!
• Consequently
• Employ multiple lines of defense.
• this is just Separation of Privilege!
• Employ diversity of mechanism.
• diverse mechanisms are unlikely to share
  vulnerabilities.

24
Deployment Strategies

• Isolationism Keep everyone out.
• Cyber-security (hard) reduced to physical
  security (easy).
• But no sharing of information or services.

25
Deployment Strategies

• Exo-security Keep bad guys out.
• Firewalls.
• Code signing.
• Perimeter defense but no internal defense
• Insider attacks possible.
• B2B e-commerce difficult.
• Precludes foreign code/extensible systems.

26
Deployment Strategies

• Pervasive Security Prevent anyone who gets in
  from doing damage.
• Need PoLP mechanisms.
• Must manage access rights---admin nightmare.
• Retaliatory Security Let anyone in recover
  from any damage.
• Need audit
• Intrusion detection.
• Need recovery.

27
Intrusion Detection

• Monitor for
• Activity/code that matches attack behavior.
• Activity that does not match normal behavior.
• Flawed in theory.
• Useful in practice.

28
In summary

• Q Whats security all about?
• A Value, locks, police courts!
• Vulnerabilities allow Attacks by Threats
• Gold Standard authentication,
  authorization, audit.
• Policy versus Mechanism!
• Important Principles
• Economy of Mechanism (Keep it simple)
• Open Design (Keep it public)
• Complete Mediation (Keep holding the reins)
• Least Privilege (Keep the reins tight)