Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin

1
Toward a Security Domain Model for Static
Analysis and Verificationof Information Systems

• Alan Shaffer, Mikhail Auguston, Cynthia Irvine,
  Tim Levin
• The 7th OOPSLA Workshop on
• Domain-Specific Modeling
• October 21-22, 2007

2
Agenda

• Motivation for Research
• Contributions of Research
• Security Domain Model Approach
• Implementation Modeling Language (IML)
• Domain Model (DM)
• Security Property Example Implementations
• Results Conclusions
• Ongoing Work

3
Motivation for Research

• High assurance secure computer system evaluation
  requires verification through rigorous processes
  and formal methods
• Evaluation must include correspondence between
  security specifications and program
  implementation
• Need exists for an abstract framework for
  expressing security policies
• This research presents an approach to
  verification of security for programs represented
  in a specialized Implementation Modeling Language
  (IML), using a formal security Domain Model (DM)

4
Contributions of Research

• Implementation Modeling Language (IML)
• Notation to support basic information processing
• Abstract representation of an existing
  implementation
• Domain Model (DM)
• Alloy-based framework for describing security
  properties and a security policy
• Generic Invariant Model
• Program State, and information flow and control
  flow tracing
• Security properties
• Generated Implementation Model
• Base program semantics, in terms of State
  Transitions
• Define security properties and constructs for
  identifying access control covert channel
  vulnerabilities
• Demonstrate ability of Alloy Analyzer to identify
  security vulnerabilities in example base programs

5
Tools Used

• Alloy Alloy Analyzer tool
• Alloy specification language for describing
  abstract models
• Alloy Analyzer used for checking Alloy models and
  assertions (model finder, not model checker)
• RIGAL
• Compiler construction language developed at
  University of Latvia (1987)
• Compiler written to generate Domain Model from
  security properties and base program

6
High-Assurance Program Verification

• Common Criteria 3.1 Development (ADV) class
  relationships
• Security objectives for a TOE (target of
  evaluation) must correspond to system design and
  code implementation, through development levels

Source Common Criteria for Information
Technology Security Evaluation, Part 3, September
2006.
7
Security DM Approach
8
Implementation Modeling Language (IML)

• Abstract specification for high-level imperative
  language programs, in a pseudocode-like
  representation
• Base program represents a model of implementation
• Defines constructs for basic information
  processing by the DM
• Statement types
• Read Write
• ReadLow(variable) ReadHigh(variable)
• WriteLow(source) WriteHigh(source)
• DirectFile access
• GetLow(key, variable) GetHigh(key, variable)
• PutLow(key, source) PutHigh(key, source)

9
Implementation Modeling Language (IML)

• Statement types (cont.)
• Assignment
• variable constant
• variable variable
• Clock statement
• GetClock(variable)
• Control statements
• if condition then statement else statement
• while condition do statement
• Stop

10
Domain Model (DM)

• Invariant Model
• Specifies base program concepts generic to DM
• State
• Statement type/structure
• Error messages
• Security Properties
• Information flow and control flow tracing
• Alloy signatures
• abstract sig Variable abstract sig Statement
  
• abstract sig Value abstract sig Stmt_type
• abstract sig Level sig DirectFile
• sig State sig Time

11
Domain Model (DM)

• Invariant Model (cont.)
• Alloy signatures
• sig State
• stmt Statement,
• vars Variable -gt (Value Time),
• access Variable -gt Level,
• direct_file DirectFile,
• current_clock Time,
• pred_state lone State,
• err_msg lone Error
• abstract sig Statement
• type Stmt_type,
• destination lone Variable,
• source, key lone (Variable Value),
• access lone Level, -- for Read/Write only

12
Domain Model (DM)

• Implementation Model
• Specifies base program semantics as state
  transition Alloy predicate
• Separate instance of transition predicate
  generated by DM-Compiler for each base program,
  as opposed to generic interpreter
• Reduces significantly Alloy state space and
  analysis time

13
Domain Model (DM)

• Implementation Model (cont.)
• Example base program statement (s1)
• ReadHigh (x1)
• Compiled DM specification
• one sig s1 extends Statement
• type ReadHigh
• destination x1
• source none
• access High
• Compiled transition predicate (partial)
• fact trans
• all st1 State - InitialState some st State
  
• ( st.stmt s1
• ( st1.access st.access ( x1 -gt High )
• some n Value st1.vars st.vars ( x1 -gt
  n)
• st1.stmt s2
• ) st1.pred_state st )

14
Security Property Example 1

• A WriteLow statement does not write a value from
  a high source

• Alloy Assertion
• assert correct_access1
• all s State Property1 s
• pred Property1 s State
• let stm s.stmt
• (stm.type WriteLow and
• stm.source in Variable)
• gt s.accessstm.source Low

• Violating Program
• (s1) ReadHigh (x1)
• (s2) if (x1 gt 3) then
• (s3) WriteHigh (x1)
• else
• (s4) WriteLow (x1)
• (s5) Stop

15
Security Property Example 2

• A low source does not attempt to write to a Full
  DirectFile after high has written to it (assumes
  DirectFile capacity is 2)

• Alloy Assertion
• assert correct_access2
• all s State Property2 s
• pred Property2 s State
• let stm s.stmt
• not (stm.type PutLow
• s.direct_file.full Full
• s.direct_file.last_written_by High)

• Violating Program
• (s1) ReadHigh (x1)
• (s2) ReadLow (x2)
• (s3) PutLow (1, x2)
• (s4) if (x1 lt 0) then
• (s5) PutHigh (2, x1)
• (s6) PutLow (2, x2)
• (s7) if Full1 then
• (s8) WriteLow (0)
• else
• (s9) WriteLow (1)
• (s10) Stop

16
Results Conclusions

• Timing Results
• Alloy Analyzer 4.0 running under Windows Vista
  Business, with 1.73 GHz Pentium M processor, 1 GB
  memory
• Example base program 1 330 ms to find
  counterexample
• Example base program 2 6 sec to find
  counterexample
• State search space analysis
• DM-Compiled Implementation Model requires
  consideration of states
• (c c v v)v s
• Can improve search space by merging linear
  sequences of non-Read statements
• (c c v v)v r
• Alloy arithmetic operation limitation

17
Ongoing Work

• Covert Channel model
• Based on Kemmerers Shared Resource Matrix (SRM)
• Implement logic for timing channel analysis
• Dynamic Slicing
• Covert channel analysis by examining control
  dependencies on variables for each execution path
• Parameterized Security policy
• Verify base programs against a variety of
  information flow security policies, e.g., BLP,
  Biba, etc.
• Trusted Subject implementation
• T.S. security policy
• Management of multiple policies (meta-policy)

18
Thank youQuestions or Comments?abshaffe_at_nps.e
du(831) 656-3319