I. Introduction
 A. Who
------------------------------------------
Instructor: Gary T. Leavens
            HEC 329
            Leavens@ucf.edu
            407-823-4758

Course web page:
  http://www.cs.ucf.edu/~leavens/CIS6614/
------------------------------------------
 B. subject matter
  1. what is security?
   Did you lock your apartment when you left this morning? Your car?
   Do you use the same key for your apartment and your car?
   Do you use a password manager to track your online passwords?
   Do you use two-factor authentication?
   What is some software that you rely on in your daily life?
   Is there software that UCF relies on?  NASA?
   What does it mean for software to be secure?
   What is a good everyday analogy for security?
  2. security bugs
   Is there a difference between (normal) bugs and security bugs?
   What are some false reasons people have for feeling secure?
  3. approaches to preventing security bugs
   Is it possible to completely prevent security bugs?
   What do analgous situations in everyday life teach us?
   When is the best, least expensive, time to find and prevent
   security bugs?
   What are worse times to prevent bugs and why are they worse?
   What approaches to preventing security problems are in use?
   How much do these approaches cost?
   Which approaches give assurance that no new security problems
      will happen in the future?
   Why is that?
   Which of these approaches prevents bugs at the best time?
   a. prevention terminology
What's the different between static and dynamic properties?
------------------------------------------
        STATIC VS. DYNAMIC PROPERTIES

Def: A *property* of a program is a
     logical statment about all its possible
     executions.
     
Def: A *static property of a program P* is




Def: A *dynamic property of a program P* is





Def: *Static Analysis* aims to




------------------------------------------
   Does static analysis differ from (human) code inspection?
   How static analysis different than testing? Runtime assertion checking?
   b. Soundness and completeness
------------------------------------------
        SOUNDNESS AND COMPLETENESS

Def: A static analysis is *sound* iff




Def: A static analysis is *complete* iff




------------------------------------------
------------------------------------------
     MORE ON SOUNDNESS AND COMPLETENESS

Soundness means:
    analysis says no bugs
       ==> no bugs!


Completeness means:
    no bugs
       ==> analysis says no bugs
------------------------------------------
------------------------------------------
SOUNDNESS AND COMPLETENESS CONTRAPOSITIVES

Logical rule [contrapositive]:
       A ==> B  <==>  not B ==> not A

So...

Soundness:
    there is a bug
       ==> analysis doesn't say no bugs

Completeness:
    analysis says there are bugs
       ==> there are bugs
------------------------------------------
   c. limitations and incompleteness
------------------------------------------
     GOEDEL'S INCOMPLETENESS THEOREM

Thm: Goedel (1931): There is no formal
     theory that contains all of arithmetic
     that is both consistent and complete.

Multiplication is the key capability.

Turing undecidability (1937):
     impossible to have an effective
     procedure that precisely decides if a
     program halts on a given input.

Rice's theorem:
     Every non-trivial property of programs
     is undecidable

Practical result for static analysis:
   + Analysis can be sound or complete
     but not both,
     Usually we settle for sound analysis.

   + Err on the safe side
     e.g., type checkers can say:
        - program has no type errors
        - found these type errors

     Q: What don't they say?

   + Loops and recursion are key problems
    
   + Use safe approximations

------------------------------------------
   d. static analysis
------------------------------------------
         STATIC ANALYSIS TECHNIQUES

Basic idea:
 - compute with (safe) abstractions
   of all executions

Goals:
  - little or no input from programmers


  - correctness

  - efficient (at compile time):
     - time
     - space



------------------------------------------
        What's not a goal?
   e. main ideas of static analysis
------------------------------------------
      MAIN IDEAS OR THEMES

- conservatism:
   "Err on the safe side!"

- efficiency from approximation:
   "Trade precision for efficiency!"

------------------------------------------
        What does safety mean?
        What does it mean to be conservative when taking money for a trip?
        What's an example of the first idea from type checking?
        Suppose we're interested in numerical precision
            (error estimation),
            what's an example of the second idea in this case?
------------------------------------------
           PRECISION AND RECALL

def: the *precision* of an analysis is
     the fraction of



def: the *recall* of an analysis is
     the fraction of 



Example:
  Suppose a program has 10 vulnerabilities
  and a tool identifies 8 places
  but only 6 of those are actual ones

  The precision is

      recall is

------------------------------------------
        What is the goal for precision?  For recall?
        Can we do that?
        Which is worse for analysis of security vulnerabilities:
           poor precision or poor recall?
 C. Plan of course (syllabus)
	Would you make any changes to the plan?
 D. Objectives
  1. summary
  2. details
------------------------------------------
        OBJECTIVES

- [Strategize] plan a strategy to
   to assure software safety
   
- [Design] Design a set of mitigations
   to the likely and important threats

- [Implement] Implement a tool to support
   a secure development process

- [Evaluate] Evaluate the adequacy of
   a threat model and mitigations

------------------------------------------
 E. How I'll run the course
  1. overview
  2. red tape
 F. summary
	any other questions about the course?