Toward a Security Domain Model for Static Analysis and Verification of Information Systems

1. Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin The 7th OOPSLA Workshop on Domain-Specific Modeling October 21-22, 2007 Toward a Security Domain Model for Static Analysis and Verificationof Information Systems

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 -> (Value + Time), access: Variable -> 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 -> High ) && some n: Value | st1.vars = st.vars ++ ( x1 -> n) && st1.stmt = s2 && ) && st1.pred_state = st ) …

14. 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) => s.access[stm.source] = Low } } Violating Program (s1) ReadHigh (x1); (s2) if (x1 > 3) then (s3) WriteHigh (x1); else (s4) WriteLow (x1); (s5) Stop; violation here Security Property Example 1 • A WriteLow statement does not write a value from a high source

15. 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 < 0) then (s5) PutHigh (2, x1); (s6) PutLow (2, x2); (s7) if Full=1 then (s8) WriteLow (0); else (s9) WriteLow (1); (s10) Stop; violation here 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)

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 Kemmerer’s 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@nps.edu(831) 656-3319