alan shaffer, mikhail auguston, cynthia irvine, tim levin the 7th oopsla workshop on domain-specific...
TRANSCRIPT
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?
[email protected]@nps.edu(831) 656-3319(831) 656-3319