Two Formal Approaches for Testing Security Policies

1
Two Formal Approaches for TestingSecurity
Policies
Wissam Mallouli and Prof. Ana Cavalli Tarot
Summer School June 26, 2008
TELECOM Management SudParis Evry (France)
2
Content

• Introduction problem statement
• Ambient Assistive Living, problem statement
• Background and related works
• Service Provision Architecture
• Centralized vs. Distributed approaches
• Proposed Architecture
• Abstract Service Model ASM
• Service Selection Engine SSE
• Architecture, Knowledge base ontologies
• Reasoning constraints and methods
• Service framework development and validation
• OSGi-based ASM service
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

• Introduction
• Problem Statement Security as a critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

3
Security as a critical issue
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives

• Need to define a security policy
• A security policy is a set of rules that
  regulates the nature and the context of actions
  that can be performed within a system, according
  to specific roles.
• If the one of rules in the security policy is not
  respected, all the system can be vulnerable.
• Checking if a system implements its security
  policy
• Generating proofs
• Injecting the policy within the system
  implementation
• Testing methods
• etc

4
Security vs. Functional
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Security Requirements
Functional Requirements
How to manage different formal languages to test
the IUT ??
2 Approaches active and passive
Formal Specification
Formal Specification
LTS FSM EFSM TFSM
PDL Ponder Or-Bac Nomad
5
Content

• Introduction problem statement
• Ambient Assistive Living, problem statement
• Background and related works
• Service Provision Architecture
• Centralized vs. Distributed approaches
• Proposed Architecture
• Abstract Service Model ASM
• Service Selection Engine SSE
• Architecture, Knowledge base ontologies
• Reasoning constraints and methods
• Service framework development and validation
• OSGi-based ASM service
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

6
Active Testing
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
IUT
Active Tester
Verdict PASS,FAIL
Formal Specification
Formal Specification ??
Test Suites
Automatic test generation based on formal
descriptions
7
Conformance Testing
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives

• Check if the implementation of a system conforms
  to its specification

I
O
System (Spec)
I
O1O???
System (Imp)
8
Types of errors
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
9
Passive Testing
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
IUT
Trace Collection
Passive Tester
PO
Verdict PASS,FAIL, INCONC.
System Specification ??
System, User
10
Content

• Introduction problem statement
• Ambient Assistive Living, problem statement
• Background and related works
• Service Provision Architecture
• Centralized vs. Distributed approaches
• Proposed Architecture
• Abstract Service Model ASM
• Service Selection Engine SSE
• Architecture, Knowledge base ontologies
• Reasoning constraints and methods
• Service framework development and validation
• OSGi-based ASM service
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background
• Active Testing Approach
• Previous Work
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project (Optionally)
• Conclusion perspectives

11
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Active Testing Solution Overview
Security Requirements
Functional Requirements
Formal specification (without security)
Formal Language
Formal specification (with security)
test Scenarios
System Implementation
Execution
11
12
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Security Rules Classification

• A security policy is a set of rules that
  regulates the nature and the context of actions
  that can be performed within a system
• Actions atomic, decomposable
• Context timed, without time constraints
• 3 classes
• Basic security rules (atomic, without time)
• Security rules with decomposable activities
  (decomposable, without time)
• Security rules with time constraints

12
13
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Previous Work
Solution Overview
Security Requirements
Functional Requirements
Formal specification
Formal Language
EFSM Specification
Or-BAC
(without security)
Access Control Security Rules
SDL
Formal specification (with security)
test Scenarios
System Implementation
Execution
13
14
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Previous Work
Solution Algorithms

• Integrating Basic Security Rules
• W. Mallouli, J-M. Orset, A. Cavalli, N. Cuppens
  and F. Cuppens, A Formal Approach for Testing
  Security Rules, the 12th ACM symposium on access
  control models and technologies (SACMAT'07), SAP
  Labs, Sophia Antipolis, France, June 20-22, 2007
• Integrating Security Rules with Decomposable
  Activities
• W. Mallouli and A. Cavalli, Testing Security
  Rules with Decomposable Activities, the 10th IEEE
  High Assurance Systems Engineering Symposium
  (HASE'07), Dallas, Texas, November 14-16, 2007

15
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Testing Methodology

• A methodology based on the ISO9646 standard
• Definition of testing architecture
• Description of the system behavior using a formal
  language SDL (ObjectGEODE)
• Characterization of test purposes and test
  generations (security oriented objectives)
  (SIRIUS)
• Execution

16
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Case Study A Weblog

• A weblog is a website where entries are written
  in chronological order and displayed in reverse
  chronological order.
• Blogs provide commentary or news on a particular
  subject such as food, politics, or local news
  some function as more personal online diaries.
  The ability for readers to leave comments in an
  interactive format is an important part of many
  blogs. (Wikipedia)

17
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Weblog Formal Specification
18
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Weblog SDL Specification
State Input Predicate Task Output State
19
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Specification Verification

• Model Checking
• Exhaustive simulation
• Absence of deadlocks and livelocks
• Guided simulation

20
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Security Policy Definition

• 3 possibles roles administrator, blogger and
  visitor
• An administrator can do any thing
• A blogger can only read and write but not delete
• A visitor can only read
• To write or delete, the user has to be
  authenticated

21
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Security Policy Specification in Or-BAC

• Obligation (Website, visitor, Authentication, _ ,
  input AddPostReq)
• Permission (Website, admin, Deleting Comment,
  Comment, _ )
• Prohibition (Website, visitor, Adding Comment,
  Comment, _ )

22
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Rules Integration (2/3)

• Permission (Website, admin, Deleting Comment,
  Comment, _ )

23
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Rules Integration (3/3)

• Prohibition (Website, anonymous, Adding
  Comment, Comment, _ )

24
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Rules Integration (1/3)

• Obligation (Website, visitor, Authentication, _ ,
  input AddPostReq)

25
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Initial Specification / Secure Specification
26
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Test Objectives Determination

• Written in SDL
• Combinative choice
• Ex An administrator tries to add a content, the
  activity is permitted and the content is added.
• 17 test objectives that represents 95 of the
  specification transitions.

27
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Basic Security Rules
Test Cases Generation

• Using SIRIUS test generation tool
• A tool based on Hit-or-Jump algorithm that allows
  to avoid combinative explosion
• BFS (Breath First Search)
• Quick generation (3s) and short scenarios (7
  transitions)
• Test scenarios can be provided in TTCN ou MSC
  standard. gt Portability

28
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Solution Overview
Security Requirements
Functional Requirements
Extended Timed Automata
Formal Language
NOMAD
(without security)
IF
Formal specification (with security)
test Scenarios
System Implementation
Execution
29
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Timed Automata Supported by IF Language

• A Extended Timed Automata is a 7-tuple
  M(I,O,S0,S,u,c,T) where
• I is a non empty set of input symbols
• O is a non empty set of output symbols
• S is a non empty set of states
• S0 ? S is the initial state
• u is a vector denoting a finite set of variables
• c is a vector denoting a finite set of clocks
• T is a set of transitions
• A transition t is a 6-tuple t (s,q,i,o,G,A)
  where
• s is the current state
• q is the next state
• i ? I is an input symbol
• o ? O is an output symbol
• G is a guard on the current values of the
  variables and clocks
• A is a sequence of actions over the variables
  and clocks

A Timed Automata is an automaton with variables,
clocks and guards
30
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Time Progress in Timed Automata

• A timed behavior of a system can be controlled
  through clocks or timers.
• The time can move forward in some states. IF
  implements the notion of urgency in the
  transitions.
• Eager the transition has priority over the time
• Delayable the time has priority over the
  transition.
• Lazy the transition and the time have the same
  priority.
• Transitions take zero time to be executed
  (instantaneous transitions).

31
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Timed Automata Example
input A, Var11, set Ck0, output X
S0
S1
when Ckgt6, input B, Var1, output Y
when Cklt10, input B, output X
When Ckgt10, input A, set Ck0,output Y
input C, Var1lt4 , output X
S2
S3
input C, Var1gt3 , output Z
32
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Nomad Language

• Non atomic actions and deadlines
• A formalism well adapted to specify security
  rules with time constraints
• Specification of permissions, prohibitions and
  obligations concerning non atomic actions using a
  combination of deontic and temporal logics
• A set of modalities defined in specific contexts

33
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Nomad Language Formula Definition

• If A is an action then start (A) (starting A),
  and done(A) (finishing A) are formulae.
• If a and ß are formulae then a, (a?ß) and (aß)
  are formulae.
• If a is a formula then Od (a) (a was true d units
  of time ago if dlt0, a will be true after d units
  of time if dgt0) is a formula too.
• If a is a formula then Oltd (a) (within d units of
  time ago, a was possibly true if dlt0, a is
  possibly true within a delay of d units of time
  if dgt0) is a formula.
• If a and ? are formulae then (a?) is a formula
  whose semantics is in the context ?, the formula
  a is true.

34
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Nomad Language Rule Definition

• If a and ß are formulae, R (a ß) is a security
  rule where R denotes one of the following deontic
  operators P, F,O
• P (a ß) means that it is permitted to execute a
  when context ß holds
• F (a ß) means that it is prohibited to execute
  a when context ß holds
• O (a ß) means that it is mandatory to execute a
  when context ß holds

35
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Nomad Language Actions Definition

• We define an atomic action with the same concepts
  of Timed Automata actions
• a variable assignment
• a clock setting
• an input action
• an output action
• a process creation
• a process destruction
• If A and B are actions, then (AB) is a
  non-atomic action.

36
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Nomad Language Example of Security Rules

• P (start (input ReqWrite (user, file.doc))
• Olt-30min done (output AuthOK (user))
• done (output DisconnectOK (user)))
• O (start (output DisconnectOK (user))
• Olt-30min done (input (user))
• done (output DisconnectOK (user)))
• F (start (output AuthOK (user))
• Olt-0.01s done (output AuthOK (user))
• done (output DisconnectOK (user)))

37
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Security Rules Sub-Classification

• Basic Security Rules with atomic actions
• R (start(A) Od done(B)) or
• R (start(A) Oltd done(B)) where
• A and B are atomic actions
• Basic Security Rules with non-atomic actions
• General Security Rules
• Example
• R (start(A) start (B) Oltd done(C) ? Oltd done
  (D) )

38
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• F (start(A) Olt-d done(B))

B
B, set Ck0
provided not active Ck, A
S0
S1
S0
S1
when Ckgtd-1, A
provided active Ck, when Ckgtd-1, A
A
B,A
S0
B
B, set Ck0
B, set Ck0
S2
S3
S2
S3
Initial System
Secure System
39
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integ. of Basic Security Rules Algorithm 1
40
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• F (start(A) O-d done(B))
• First Intuition

B
B, set Ck0
provided not active Ck, A
S0
S1
S0
S1
when Ck?d, A
provided active Ck, when Ck?d, A
A
B,A
S0
B
B, set Ck0
B, set Ck0
S2
S3
S2
S3
Initial System
Secure System
41
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• F (start(A) O-d done(B))

B, set Ck0
provided not active Ck, A
S0
S1
when Ck?d, A
provided active Ck, when Ck?d, A
S0
B, set Ck0
B, set Ck0
S2
S3
Secure System
42
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• F (start(A) O-d done(B))

43
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• F (start(A) O-d done(B))

Process rhp(T)
B, fork rhp(gckd)
B
S0
S1
S0
S1
S0
when gck?c, A
when gck?c, A
when gckT, cT
A
B,A
S0
B, fork rhp(gckd)
B
B, fork rhp(gckd)
S2
S3
S2
S3
Initial System
Secure System
44
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integ. of Basic Security Rules Algorithm 2
45
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• O (start(A) O-d done(B))

Process rhp()
B, fork rhp()
B
S0
S1
S0
S1
S0
A
B,A
set ck0
A
B, fork rhp(), A
B, fork rhp()
B
S2
S3
S2
S3
when ckd, A
wait
Initial System
Secure System
46
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integ. of Basic Security Rules Algorithm 3

• O (start(A) O-d done(B))

47
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Basic Security Rules

• O (start(A) Olt-d done(B))

Process rhp(T)
B, wait_A, fork rhp()
S0
S1
S0
B, wait_A, fork rhp(), A, If (wait_Agt0) wait_A--
A, If (wait_Agt0) wait_A--
set ck0
B, wait_A, fork rhp()
S2
S3
when ckd-1, if(wait_Agt0), A
wait
when ckd-1, if(wait_A0), _
Secure System
48
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integ. of Basic Security Rules Algorithm 4
49
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integ. of Rules with Decomposable Actions

• F (start(f) Oltd done(abcde))

if (vtrue) d,e, set Ck0
S2
S4
a
d,e
vtrue
ET1
ST1
S0
S1
S7
S6
b
c
IT2
IT1
f
If(cond) f
vfalse
if (vfalse) d,e
OT1
S5
vfalse
OT2
S7
S8
cond (vfalse) or (provided not active Ck) or
(Ckgtd-1)
50
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration of Complex Security Rules
51
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
More details

• Paper under submission Integration of Timed
  Security Policies within a Formal TEFSM
  Specification
• Correctness proof

52
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Case Study Travel Application

• Internal service used by France Telecom company
  to manage missions' corresponding to traveling
  of its employees.
• A potential traveler can connect to system to
  request for
• travel ticket
• hotel reservation
• during a specific period
• specific objective (called mission)
• This request can be accepted or rejected by
  his/her hierarchical superior
• In the case of an acceptance, the travel ticket
  and hotel room are booked by contacting a
  specific travel agency.

53
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Functional Specification of Travel Application
54
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Functional Specification of Travel Application
55
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Security Specification Results

• F (start (output req_create_mission(t))
• Olt-2min done (output req_create_mission(t)))
• P (start (output req_proposition_list(t,m))
• Olt-10min done (output req_proposition_list(t,m)
  ))
• O (start (output req_validation())
• Olt-10080min done (output req_validation())
• done (input recv_validate_notification())
• done (input recv_unvalidate_notification()))

56
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Integration Results
57
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Test Generation Results

• Using TestGen-IF tool
• Based on Hit-or-Jump algorithm
• Partial accessibility graph
• Avoid combinative explosion
• Test cases in a standard language

58
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Testing Security Rules with Time Constraints
Tests Execution

• Instantiation of the generated test cases
• TCL language
• Tclwebtest tool
• tclwebtest is a tool to build automated tests for
  web applications. It provides a simple API for
• Issuing http requests
• Dealing with the results and assume specific
  response values
• Takes care of the details such as redirects and
  cookies

59
Content

• Introduction problem statement
• Ambient Assistive Living, problem statement
• Background and related works
• Service Provision Architecture
• Centralized vs. Distributed approaches
• Proposed Architecture
• Abstract Service Model ASM
• Service Selection Engine SSE
• Architecture, Knowledge base ontologies
• Reasoning constraints and methods
• Service framework development and validation
• OSGi-based ASM service
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background and Related Work
• Active Testing Approach
• Testing Basic Security Rules
• Testing Security Rules with Decomposable
  Activities
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project
• Conclusion perspectives

60
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Passive Testing Basics
IUT
Trace Collection
Passive Tester
PO
Verdict PASS,FAIL, INCONC.
System Specification
System User
61
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Model Based Passive Testing
Security Requirements
Functional Requirements
Formal specification (without security)
Formal Language

• FSM
• EFSM
• Timed FSM

Formal specification (with security)
Trace Analysis Verdict
Execution Trace
System Implementation
62
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
Security Requirements
Functional Requirements
Formal specification (without security)
Formal Language
Nomad
Formal specification (with security)
Trace Analysis Verdict
Execution Trace
System Implementation
63
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
Execution Trace
Pre-processing Module
IUT
Verdict
Test Engine
Syntax Checking Module
Nomad Security Specification
Security Test tool
64
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing

• Applied to an industrial Case Study
• SAP R/3 Audit System
• SAP Audit system permits to
• store all the events and transactions that occur
  during a period of time
• to give the system administrators an overview
  about the users' activities within the system.
• It provides a set of files that contain detailed
  information about every activity undertaken by
  system users.

65
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
SAP Case Study

• 13 rules have been selected to be specified in
  our formalism
• 2 Obligations
• 3 Prohibitions
• 8 Permissions

66
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
SAP Case Study Results (1/3)

• Trace file of the Audit application (25000 lines)

03.04.2005,102025,600,HACKERW,FK02,S826-01,AU3,T
ransaction FK02 Started
Date
heure
Message
User ID
Terminal
Client
Message ID
Trans. code
67
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
SAP Case Study Results (2/3)

• Modifications in the Audit File

68
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Nomad Based Passive Testing
SAP Case Study Results (3/3)

• The system checks its security policy

69
Content

• Introduction problem statement
• Ambient Assistive Living, problem statement
• Background and related works
• Service Provision Architecture
• Centralized vs. Distributed approaches
• Proposed Architecture
• Abstract Service Model ASM
• Service Selection Engine SSE
• Architecture, Knowledge base ontologies
• Reasoning constraints and methods
• Service framework development and validation
• OSGi-based ASM service
• Conclusion perspectives

• Introduction
• Problem Statement security as critical issue
• Background and Related Work
• Active Testing Approach
• Testing Basic Security Rules
• Testing Security Rules with Decomposable
  Activities
• Testing Security Rules with Time Constraints
• Passive Testing Approach
• Model Based Passive Testing
• Nomad Based Passive Testing
• POLITESS Project
• Conclusion perspectives

70
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Politess Project
Specification/Abstraction System Security Policy
Test generation
Deployment
Monitoring
71
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Conclusion

• The security testing is still complex
• Automatic test generation for security rules
  (permissions, prohibitions, and obligations)
• Monitoring of Deployed System
• Still many unexplored fields

72
Introduction .I Background .II Active Testing
Approach.III
IV. Passive Testing Approach V. Politess
Project VI. Conclusions perspectives
Questions ???