1 / 18

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

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. Agenda. Motivation for Research Contributions of Research

trygg
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 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

More Related