Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin The 7th OOPSLA Workshop on Domain-Specific Modeling October 21-22, 2007 Toward a Security Domain."— Presentation transcript:

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 Verification of Information Systems

2 October 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 7 Security DM Approach

8 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 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 October 22, 2007 14 Security Property Example 1 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; A WriteLow statement does not write a value from a high source violation here

15 October 22, 2007 15 Security Property Example 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 < 0) then (s5)PutHigh (2, x1); (s6)PutLow (2, x2); (s7)if Full=1 then (s8)WriteLow (0); else (s9)WriteLow (1); (s10)Stop; A low source does not attempt to write to a Full DirectFile after high has written to it (assumes DirectFile capacity is 2) violation here

16 October 22, 2007 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 October 22, 2007 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 October 22, 2007 18 Thank you Questions or Comments? abshaffe@nps.edu (831) 656-3319


Download ppt "Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin The 7th OOPSLA Workshop on Domain-Specific Modeling October 21-22, 2007 Toward a Security Domain."

Similar presentations


Ads by Google