Program Monitoring
Ulfar Erlingsson  Microsoft Research

Execution Monitoring Fundamentals
  - programs and properties from traces
     -- look at execution as a sequence of runtime
	event
     -- do something on each event

     -- programs as sets of execution traces

     -- allow traces that satisfiy security policy

     -- enforcement mechanism M is a concrete mechanism
	that deterimines the set of traces S

     -- EM focus on one execution trace
	- can often approximate desired policy
	- closely related to safety

     -- Defitions
	 P : security policy, predicate on sets of executions
	 S : target system, set E of executions
	 S satisfied P: P(E) = true

     -- EM truncates program once violations is found, and violations
	must be detected after a finite amount of time

     -- Buchi automata for a property of a program, safety or liveness
	property

     -- EM <> Safety Properties
	- use bounded moemory only
	- must control the system

     -- EM can do acces control, can do D-availabitlity
	Can't do informaion flow, liveness/availability

  - security poclicy as security automata
      Security Automata, just regular Buchi automata with all states
      accepting. As all stats are accepting states, it's deterministic.

      Chinese Wall security policy (MLS can't solve)

  - inlined reference monitors

Monitoring machine code execution
  - software fault isolation
  - buffer overflow and mitigations

Advanced IRMs & future work
  - low-level actions and event synthesis
  - static analysis, alternate remedies, etc
      better than EM: security via static analysis
      but hard to prove program properties, one way is
      to write program in a way that facilitates proving
      certain properties about it.
