Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin

The 7th OOPSLA Workshop on

Domain-Specific ModelingOctober 21-22, 2007

Toward a Security Domain Model for Static Analysis and Verification

of Information Systems

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

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)

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

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

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.

October 22, 2007 7

Security DM Approach

ManuallyExtract

ManuallyExtract

Pag

e 1

Domain Model(Alloy)

- Invariant Model - Implementation Model

Implementation(Ada, Java, C++, …)

Security Policy(natural language)

Base Program(IML)

Security Properties

(Alloy)

DM-Compiler(IML→Alloy)

Alloy Analyzer

Execution paths that

violate security

properties

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)

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

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 signaturesabstract sig Variable { } abstract sig Statement

{…}abstract sig Value { } abstract sig Stmt_type

{ }abstract sig Level { } sig DirectFile {…}sig State {…} sig Time { }

October 22, 2007 11

Domain Model (DM)• Invariant Model (cont.)

– Alloy signaturessig 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 }

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

October 22, 2007 13

Domain Model (DM)• Implementation Model (cont.)

– Example base program statement (s1)ReadHigh (x1);

– Compiled DM specificationone sig s1 extends Statement {} { type = ReadHigh

destination = x1source = noneaccess = 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 ) …

October 22, 2007 14

Security Property Example 1

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

October 22, 2007 15

Security Property Example 2

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

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

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)

October 22, 2007 18

Thank youThank you

Questions or Comments?Questions or Comments?

abshaffe@nps.eduabshaffe@nps.edu(831) 656-3319(831) 656-3319