<body><pre>
Security Properties
Andrew Myers, Cornell

Outline
-- What is computer security
   Prevent bad things from happening. 
     (Security Goals: confidentiality, integrity, availability, 
      access control, etc) 
   Versus an adversary.
     (Not a random source)
   Attack Examples: Worms, Virus, (Keywords: hotmail 98, 99 attacks),
		    USS Yorktown(divide by zero), Insider attacks(50:1,
		    outsider attacks)
   Remark: System diversity helped to limit the damage

   Vulnerbility/Attack
   Threat/Threat Model (characterizes possible attacks, overengineering)
   Trusted Computing Base (system components dependent on for security)

-- Security vs. Fault tolerance
   Attacks vs. Faults(non malicious)
   Reliability is just one aspect of the spectrum of security goals
     - ( Failstop failure = system halts )
     - Byzantine failure = arbitrarily bad
   Weakest link counts

-- Assumptions and abstraction
   - (No physical access to hardware; no code modification during
      execution)
   - Assumptions are vulnerabilities (and sometimes not known!)
   - Assumptions arise from abstraction (security analysis only
     tractable on a simplification/abstraction of actual system;
     abstration hides details, making assumption that it's not
     important)

-- Risk Management
   Cost-benefit vs. expense : it interferes with intended use
   (functionality, efficiency, cost)
   Preventing may be infeasible / Deterrence may be sufficient

-- When to enforce security
   - Before execution (analyze, reject, rewrite)
   - During execution (monitor, log, halt, change)
   - After exection (roll back, restore, audit, sue, call police)

-- Policy vs. Mechanism
   What is protected from what, vs. How it's being done.
   So we want to know what need to be protected, and what mechanisms
   we may have.
   -- Something with value
   -- Information with impact on real world
   -- Different mechanisms required for different properties
      1) Integrity
	 Enforcement: Access Control, Digital Signatures
      2) Confidentiality (Secrecy)
	 Enforcement: Access Control, Encryption
      3) Privacy, Anonymity
	 Prevent misuse, or prevent connection between identity of
	 actor and actions(keep either secret)
      4) Availability
      5) Nonrepudiation
	 Convince a 3-party that an event occured.

-- Q: Is security = correctness?
   A: No
      Specification usually focus on functionality not security.
      Classic specification languages don't talk about security
      properties (e.g. Hoare logic)
      Security not preserved under refinement
      e.g.
	 public \in Integer	(spec)		looks secure
	 public := secret	(impl)		doesn't, reveal secret

-- Safety vs. Liveness
   Security properties enforced by run-time monitoring are safety
   properties. Can stop a program if it tries to do bad.
   But some require liveness (availability, information-flow
   confidentiality) that run-time monitoring may interfere. Can't
   stop program.
   - Safety properties (nothing bad EVER happens)
     Amenable to purely run-time enforcement
     -- Access control
     -- Memory/Type safety
   - Liveness properties (something good eventually happens)
     Can't be enforced purely at run time, the tactic is to
     restric to a safety property problem.

-- Security Property Landscape
   System does exactly what it is required to do, but no more. 
</pre></body>
