A service dependency modeling framework for Policy-based response

A service dependency modeling frameworkfor Policy-based response enforcementNizar Kheir1,2, Herve Debar1, Frederic Cuppens2, NoraCuppens-Boulahia2, Jouni Viinikka1

1Orange Labs - Caen - France2Telecom Bretagne - Rennes - France

DIMVA 2009

Need for a Policy-based Response

� Multiple adjustment variables for Information Systems:� Performance, Convenience, Reliability, Security, . . .

� Multiple trade-offs between these variables:� Sacrifice convenience for a higher security.� Privilege Performance over Reliability . . .

� Static design-time adjustements need dynamic run-time adaptation.

� Express dynamic trade-offs using dynamic access control policies.� Implement dynamic access control rules.� Use of the Organization Based Access Control Model (Or-Bac).

A Service Dependency Modeling Framework – p 2 research & development Orange Labs

OrBac overview - Policy Derivation

1. Dynamic policy rules using contexts:� Sr(Prohibition, User, Login, Internal Host, not Working Hours).

2. Simple policy definition using component abstractions:� Empower (Bob, User).� Consider (telnet, Login).� Use ([email protected], Internal Host).

3. Dynamic context evaluation/activation.� Hold (Bob, telnet, [email protected], not Working Hours).

Concrete Policy Activation

Is Prohibited (Bob, telnet, [email protected])


OrBac overview - Threat Response

� Alert recuperation:� Alert (Source, Target, Description)

� Mapping between alert attributes and concrete policy components:� map Subject(Source, Subject)� map Action(Target.Service, Action)� map Object(Target, Object)

� Checking Threat Contexts:� map Context (description, Th Context)

� Activating appropriate threat contexts:� Hold (Subject, Action, Object, Th Context)


Problem Statement

Alert (Src, Trgt, Descr) ⇒ {Sr (Decision, Subj, Act, Obj)}*

� Challenges of a Policy Decision Process:� How to find suitable Policy Enforcement Points (PEPs) ?� How to decide about PEPs’ capabilities ?� How to propose appropriate configurations for each selected PEP ?

� Proposal: Build mappings between service and access control layers.

U

BA

D

U

C

ES e r v i c e p l a n

F W

C o n f i g

A C L

A p p l i . F WA c c e s s c o n t r o l

p l a n

A


Outline

1 � Policy-based Response

2 � A Service Dependency Framework (SDF)� Dependency Model Architecture� Dependency Model Framework

3 � Use of the SDF

4 � Conclusion


Properties Expected from the SDF

� The Service Dependency Framework Specifies:� Data provided by antecedent services ⇒ Formal service interfaces.� Paths through which data is accessed ⇒ Topology representation.� When this Data is required ⇒ Modeling service workflow.� Why this Data is required ⇒ Dependency Impact representation.

� Formal definition of the SDF ⇒ Use of formal semantics.

� Modularity and Extensibility ⇒ components with specific interfaces.

Use of the Architecture Analysis and Design Language (AADL)

AADL fulfills all those requirements through the modeling of service archi-tectures and interactions.


SDF: Modeling services

� Abstract components with specific interfaces.� Interfaces are typed with data sets.

– Implementation of elementary service –system Service NamefeaturesRFi : requires data access data Set ri ;PFj : provides data access data Set pj ;end Service Name;

R e q u i r e s d a t a a c c e s s

P r o v i d e s d a t a a c c e s s

. . .

S e r v i c e _ n a m e

. . .

P F 1 P F 2 P F m

R F 1 R F 2 R F n

� Dependencies are represented as inter-service connections.

system implementation Dependency Model.AsubcomponentsA: system dependent;B: system antecedent;connectionsconst AB: data access B.PF1 → A.RF1;end Dependency Model.A;

R e q u i r e s d a t a a c c e s s d a t a _ S e t _ r 1

P r o v i d e s d a t a a c c e s s d a t a _ S e t _ r 1

. . .

BP F 1

. . .

A

. . .

R F 1

. . .


Case study: Service definitionpackage serviceDBpublic– NFS service definition –system NFSfeatures

P mb: provides data access dataDB::mBox;end NFS;– LDAP service definition –system LDAPfeatures

P a: provides data access dataDB::Account;end LDAP;– POP service definition –system POPfeatures

mb Owner: requires data access dataDB::Account;R mb: requires data access dataDB::mBox;P mb: provides data access dataDB::mBox;

end POP;end serviceDB;

N F S

P _ m b

L D A PP _ a

P O Pm b _ O w n e r

R _ m bP _ m b


SDF: Service topology

� Shows data paths through virtual connections between servicecomponents.

� Three service dependency types:

� User-sidedependency:

A

B

1

U 2

3

� Service-sidedependency:

U A

B

1 - 3

2

� Proxy-sidedependency:

A

1

U

2

3

B


Case study: Service topology

� AADL graphical representation:

P O P P a c k a g e

P O Pm b _ O w n e r

R _ m bP _ m b

N F SP _ m b

L D A PP _ a

U s e r

R _ m bP _ m b

P _ m b

� AADL textual representation:package Poppublic System POPfeatures

P mb: provides data access dataDB::mbox;end POP;private system implementation POP.instancesubcomponents

User: system user;Ldap: system serviceDB::Ldap;

NFS: system serviceDB::NFS;Pop: system dependent.instance;

connectionsdata access Ldap.P a→ Pop.mb Owner;data access NFS.P mb→ Pop.R mb;data access Pop.P mb→ User.R mb;

end POP.instance;end Pop;


SDF: Service dependency modes

� A dependency mode expresses a service operational phase where agiven dependency is required.

� It is associated with an appropriate service interface.

� Dependency mode transitions show dependency sequencing.

� Three dependency sequencing aspects:

� Stateless sequencing:

i + 2D e p

i + 1D e pi

D e p

� Statefull sequencing:

iD e p

i + 1D e p i + 2

D e p

� Alternativesequencing:

i + 2D e p

i + 1D e p i

D e p


SDF: Dependency Impact

� Dependency failures alter normal transitions between dependencymodes.

� A failed dependency can never be satisfied.� The dependent service may switch to another dependency mode.

� Use of the AADL Guard Transition constructs to constrain modetransitions.

modesA: initial mode; B: mode; C: mode;T1: A -[C1.transit]→B;T2: A -[C1.Failure transit]→ C;annex Error Model {**Guard Transition ⇒(Iface A[Failed]) applies to T2;Guard Transition ⇒(Iface A[Error Free]) applies to T1;**};

B

AC

E r r _ F r e eF a i l e d

A

B

CN o r m a l

F a i l u r e

E r r _ F r e e

F a i l e d


Case study: Modes and Impacts

� AADL textual representation:package Poppublic

. . .system implementation op State.Idleend op State.Idle;system implementation op State.Request

modes LDAP: initial mode;NFS: mode;Idle: mode;T1: LDAP-[C1.transit]→ NFS;T2: NFS-[C2.Fail transit]→ Idle;

annex Error Model {**Guard Transition ⇒ (mb Owner[Error Free]) applies to T1;Guard Transition ⇒ (R mb[Failed]) applies to T2; **};

end op State.Request;end Pop;

� AADL graphicalrepresentation:

I d l e

R e q u e s t

L D A P

N F S

E r r _ F r e e

F a i l e d


Outline




4 � Conclusion


SDF: Dependency Model Framework

S e r v i c e d e p e n d e n c y d e s c r i p t i o n s

4

1 2

E x p l i c i t d e p e n d e n c i e sO S A T E t o o l

*

M o d e l t r a n s l a t i o n a n d v a l i d a t i o n

M u l t i - f i l e s X M L m o d e l

O S A T E s u p p o r t f o r A A D L X M L I n t e r c h a n g e r e p r e s e n t a t i o n

3

J a v a b a s e d Q u e r y i n t e r f a c e

+ d e p S t a t e I d : i n t

# P a r e n t S t a t e : d e p S t a t e

# A n t S e r v i c e : S e r v i c e

# R e q u i r e d D a t a : D a t a

# R e q u e s t e t : S e r v i c e

# F a i l u r e T r a n s : S e r v i c e

d e p S t a t e

+ C h e c k P a t h ( ) : b o o l e a n

+ c h k C o n s t r a i n t ( ) : b o o l e a n

+ g e t F a i l u r e T r a n s ( ) : d e p S t a t e

+ a d d H i s t o r y ( ) : b o o l e a n

1

*

I t e r a t i v e m o d e l

c o n s t r u c t i o n

M o d e l a c c e s s

A A D L o p e r a t i o n a l m o d e l A A D L I m p a c t t r a n s i t i o n s


Case study: Resulting AADL Model

w e b m a i l p a c k a g e

w e b m a i l

u s e r

w e b m a i l

R e q u e s t

I m a p P o pI d l e

I M A P P a c k a g e

I M A P

I d l eL D A P

N F S

P r o x y

R e q u e s tI m a p

P r o x y

I m a p

U s e r

L D A P

N F S

P r o v i d e s

a c c o u n t a c c e s s

P r o v i d e s

m b o x a c c e s s

r e q u i r e s

m b o x a c c e s s

p r o v i d e s

m b o x a c c e s s

POP Package

P O P

I d l e

L D A P

N F S

R e q u e s t

P o p

U s e r

L D A P

N F S

P r o v i d e s

a c c o u n t a c c e s s

P r o v i d e s

m b o x a c c e s s

P r o v i d e s

w e b a c c e s s

P r o v i d e s

m b o x a c c e s s

r e q u i r e s

m b o x a c c e s s


Case study: webmail DFSM

R e q u e s t

I d l e

WebP o p I m a p

L d a p

N F S

E r r _ F r e e

I m a p P r o x y

L d a p

N F SE r r _ F r e e

F a i l _ t r a n s i t

E r r _ F r e e

F a i l _ t r a n s i t


Outline




4 � Conclusion


Process description

� Input: Concrete response rule Sr(Decis., Subj , Act, Obj).

1. Get Service ’Sdep’ implementing Act.2. Build abstract DFSM for Sdep.3. Derive concrete DFSM using transitive closure with Sr as input.4. Select minimal set of dependency states with:

1. Case of permission: At least one access path is set.2. Case of prohibition: No access path is set.


Model simulation - Response proposals

� The Or-Bac based response policy described as:

– The abstract response rule –Sr (prohibition, att Source, victim Serv, target Data, attack Threat)– The Or-Bac Hold fact which transforms alerts into contexts –Hold (Subject, Action, Object, Th Context) :-

alert (Source, Target, description) &map Subject (Source, Subject) &map Action (Target.Service, Action) &map Object (Target, Object) &map Context (description, Th Context).

� Attacks tested using this model:

� Reconnaisance attack against the webmail service.� Brute Force attack against the webmail service.� Arbitrary code execution against the POP service.� Arbitrary code execution against the IMAP service.


Summary of the email test bed

U s e r W e b

W e b m a i l

I m a p P r o x y

P O P N F S

I M A P

L D A P

S e r v i c e p l a n

M o d S e c u r i t y

X i n e t d

s l a p d . c o n f

/ e t c / e x p o r t sA c c e s s c o n t r o l

p l a n


Model outcomesA l e r t ( I P , w e b m a i l , - , R e c o n n a i s s a n c e a t t a c k )

I m a p P r o x y

P o p

P r o h i b i t i o n ( I P , w e b m a i l , a n y )

W e b

P r o h i b i t i o n( I P , w e b , m a i l _ a p p l i )

M o d e S e c u r i t y : secru le reques t_ur i " " \

r e m o t e _ a d d r " @ s t r e q " w e b m a i l

I P d e n y

- a - R e c o n n a i s s a n c e a t t a c k

A l e r t ( I P , I m a p , - , a r b i t r a r y c o d e )

L d a p

P r o h i b i t i o n ( I P , I m a p , a n y )

I m a p P r o x y

P r o h i b i t i o n( I P , I m a p P r o x y , a n y )

X i n e t d : serv i ce {no access = }

- c - A r b i t r a r y C o d e E x e c u t i o n

Imap IP

A l e r t ( IP , Pop , - , a r b i t r a ry cod e )

N F S

P r o h i b i t i o n ( I P , P o p , a n y )

L d a p

P r o h i b i t i o n( P o p _ s e r v , L d a p , - )

/ e t c / e x p o r t s : rm \

- d - A r b i t r a r y C o d e E x e c u t i o n

P r o h i b i t i o n( P o p _ s e r v , N f s , a n y )

( r w , s y n c , r o o t _ s q u a s h )/ h o m e / n f s / m b o x I P < p o p >

A l e r t ( - , w e b m a i l , C h a r l i e B o x , B r u t e F o r c e a t t a c k )

P r o h i b i t i o n ( a n y , w e b m a i l , C h a r l i e B o x )

W e b

P r o h i b i t i o n( a n y , w e b , m a i l _ a p p l i )

- b - B r u t e F o r c e a t t a c k

L d a p : access to dn.base = " " by dn.base = " "c n = c h a r l i e , o u = a c c o u n t s , d c = t e s t b e d c n = I m a p , o u = a c c o u n t s , d c = t e s t b e d n o n e

I m a p P r o x y

P o p L d a p

I m a p L d a p

P r o h i b i t i o n ( P o p _ s e r v , L d a p , A c c o u n t _ C h a r l i e )

P r o h i b i t i o n ( I m a p _ s e r v , L d a p , A c c o u n t _ C h a r l i e )

P r o h i b i t i o n( I m a p P r o x y , I m a p , C h a r l i e _ B o x )

P r o h i b i t i o n( m a i l _ a p p l i , I m a p P r o x y , C h a r l i e _ B o x )

P r o h i b i t i o n( m a i l _ a p p l i , P o p , C h a r l i e _ B o x )

L d a p : access to dn.base = " " by dn.base = " "c n = c h a r l i e , o u = a c c o u n t s , d c = t e s t b e d c n = P o p , o u = a c c o u n t s , d c = t e s t b e d n o n e


Model outcomes

A l e r t ( I P , w e b m a i l , - , R e c o n n a i s s a n c e a t t a c k )

I m a p P r o x y

P o p

P r o h i b i t i o n ( I P , w e b m a i l , a n y )

W e b

P r o h i b i t i o n( I P , w e b , m a i l _ a p p l i )

M o d e S e c u r i t y : secru le reques t_ur i " " \

r e m o t e _ a d d r " @ s t r e q " w e b m a i l

I P d e n y

- a - R e c o n n a i s s a n c e a t t a c k

A l e r t ( I P , I m a p , - , a r b i t r a r y c o d e )

L d a p

P r o h i b i t i o n ( I P , I m a p , a n y )

I m a p P r o x y

P r o h i b i t i o n( I P , I m a p P r o x y , a n y )

X i n e t d : serv i ce {no access = }

- c - A r b i t r a r y C o d e E x e c u t i o n

Imap IP

A l e r t ( IP , P o p , - , a rb i t r a r y c o d e )

N F S

P r o h i b i t i o n ( I P , P o p , a n y )

L d a p

P r o h i b i t i o n( P o p _ s e r v , L d a p , - )

/ e t c / e x p o r t s : rm \

- d - A r b i t r a r y C o d e E x e c u t i o n

P r o h i b i t i o n( P o p _ s e r v , N f s , a n y )

( r w , s y n c , r o o t _ s q u a s h )/ h o m e / n f s / m b o x I P < p o p >

A l e r t ( - , w e b m a i l , C h a r l i e B o x , B r u t e F o r c e a t t a c k )

P r o h i b i t i o n ( a n y , w e b m a i l , C h a r l i e B o x )

W e b

P r o h i b i t i o n( a n y , w e b , m a i l _ a p p l i )

- b - B r u t e F o r c e a t t a c k

L d a p : access to dn.base = " " by dn.base = " "c n = c h a r l i e , o u = a c c o u n t s , d c = t e s t b e d c n = I m a p , o u = a c c o u n t s , d c = t e s t b e d n o n e

I m a p P r o x y

P o p L d a p

I m a p L d a p

P r o h i b i t i o n ( P o p _ s e r v , L d a p , A c c o u n t _ C h a r l i e )

P r o h i b i t i o n ( I m a p _ s e r v , L d a p , A c c o u n t _ C h a r l i e )

P r o h i b i t i o n( I m a p P r o x y , I m a p , C h a r l i e _ B o x )

P r o h i b i t i o n( m a i l _ a p p l i , I m a p P r o x y , C h a r l i e _ B o x )

P r o h i b i t i o n( m a i l _ a p p l i , P o p , C h a r l i e _ B o x )

L d a p : access to dn.base = " " by dn.base = " "c n = c h a r l i e , o u = a c c o u n t s , d c = t e s t b e d c n = P o p , o u = a c c o u n t s , d c = t e s t b e d n o n e


Conclusion

� A definition of a Service Dependency Framework which provides:� Formal classification of dependencies using formal semantics.� Abstraction of model components to simplify the representation of

complex architectures.� A modular and extensible framework.

� A systematic process which uses service dependencies to providecandidate responses.

� Response selection based on minimum configuration changes.


Thank you

Questions ?


A service dependency modeling framework for Policy-based response

Documents

Transcript of A service dependency modeling framework for Policy-based response