Probabilistic Aspects Checking Security in an Imperfect World

Document Sample
Probabilistic Aspects Checking Security in an Imperfect World Powered By Docstoc
					                            Probabilistic Aspects:
                   Checking Security in an Imperfect World


              Chris Hankin1                 Flemming Nielson2              Hanne Riis Nielson2

                                              1 Imperial College London
                                        2   Technical University of Denmark



                                                    KCL 2010



Hankin & Nielson & Nielson (IC & DTU)              Probabilistic Aspects                  KCL 2010   1 / 37
 Motivation
  The classical viewpoint:
      Security policies should be enforced at all times!

  The viewpoint in this paper:
      The enforcement of security policies might be imperfect!

  Example
      An on-line auction house: In some circumstances a buyer might be
      concerned that the seller has a mechanism for secure payment – and
      sellers might want to perform spot checks on buyers before accepting
      bids on expensive items.
         Airport security: In times of heightened security certain high risk
         travellers will be subject to full body scans before allowing them into
         the Departures lounge.

Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects        KCL 2010   2 / 37
 Scene Setting



         Distributed, mobile computations

         Coordination languages
         Design of AspectK as an aspect-oriented extension of KLAIM
                Process-algebraic approach
                Communication via tuple spaces
                Located processes and tuple spaces
                Code mobility and dynamic topology

         Modelling of Access Control policies




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects   KCL 2010   3 / 37
 Rationale and Contribution


         Aspect-oriented programming deals with separation of concerns; in
         particular it provides a more flexible way to deal with modifications in
         security policies than the use of reference monitors.

         A significant issue is how conflicting aspects are treated. The recent
         work by Huth and Bruns and others addresses the problem of policy
         composition using Belnap Logic. We adapt their work to provide an
         expressive language for combining policies defined by aspects.

         We further extend this to support probabilistic advices.




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects       KCL 2010   4 / 37
 Our modelling language: locations


  A distributed process calculus
         processes are located and each location has a memory (tuple space)

  Example
  The on-line auction house pBuy contains (among others):
          object, number, seller, range indicating that seller is offering an
         object with identification number for sale in the price range
         range ∈ {cheap, affordable, expensive}; and
          bid, number, buyer, value indicating a bid from buyer for object
         number at value value.




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects         KCL 2010   5 / 37
 Our modelling language: processes

  A distributed process calculus
       processes are constructed from basic actions using prefixing, choice,
       parallel composition and replication
       the actions may
                output a tuple to a given location
                input a tuple from a given location destructively
                read a tuple from a given location (non-destructive input)

  Example
  A simple process for a buyer, b, might be:

                ∗ (read(object, n, s, r )@pBuy. out(bid, n, b, 100)@pBuy)



Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects                KCL 2010   6 / 37
 Our modelling language: policies
  Policy: [rec if cut : cond]
         cut is the action to be trapped by the policy: it specifies the location
         of the subject and the action,
         cond is a boolean applicability condition used to express whether or
         not the policy applies, and
         rec is a policy recommendation.

  Example
  Only registered buyers may place bids for objects that are up for auction
  and they cannot place bids on behalf of others:
                                                 
               test(object, n, , )@pBuy ∧
              test(buyer, u, )@pBuy ∧ u = b            a deterministic
   Polbuy    if u :: out(bid, n, b, )@pBuy :
                                                  
                                                        two-valued policy
                                                         recommendation
                  true

Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects       KCL 2010   7 / 37
 Two-valued Logic and Probabilistic Two-valued Logic

         In a deterministic system, policy decisions eventually result in either
         granting an action or denying it — use two-valued logic
         In a probabilistic system, policy decisions result in a certain probability
         for granting the action — use probabilistic two-valued logic
                The values are (p, q) where p, q ∈ [0, 1] and p + q = 1
                       p gives the probability for granting the action and
                       q gives the probability for denying the action
                Example: true = (1,0) and false = (0,1)
         The operations on two-valued logic can be extended to probabilistic
         two-valued logic, e.g.
                (p, 1 − p) ∧ (q, 1 − q) = (pq, 1 − pq)
                (p, 1 − p) ∨ (q, 1 − q) = (p + q − pq, 1 − p − q + pq)
                ¬(p, 1 − p) = (1 − p, p)
         We need a new operator ?s that with probability s returns its
         argument and with probability 1 − s gives true:
                ?s (p, q) = ((1 − s) + sp, sq)
Hankin & Nielson & Nielson (IC & DTU)      Probabilistic Aspects             KCL 2010   8 / 37
 Probabilistic policy recommendations
  Policy: [rec if cut : cond]
         cut is the action to be trapped by the policy: it specifies the location
         of the subject and the action,
         cond is a boolean applicability condition used to express whether or
         not the policy applies, and
         rec is a probabilistic policy recommendation.

  Example
  In 90% of the cases the buyer will check that the seller offers secure
  payment for objects that are not cheap:
                                                                      
                     ?0.9 false
                   if u :: out(bid, n, b, )@pBuy :
       Pol0.9
                                                                       
          secure
                                                                      
                   u = b ∧ ∃r , s : (test(object, n, s, r )@pBuy ∧ 
                           ¬(r = cheap) ∧ ¬(test(safepay, s)@pBuy))
Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects       KCL 2010   9 / 37
 Four-valued Logic
         Policies might be incomplete or contradictory — use four-valued logic
                true: grant access
                false: deny access
                ⊥: no information
                  : conflicting information
         Belnap logic: two orderings on the four values
                ≤k : least upper bound ⊕ and greatest lower bound ⊗
                ≤t : least upper bound ∨ and greatest lower bound ∧

                                                                       true
                           d                                                d
                            d                                                d
                              d                                                  d
              true            d≤k           false              ⊥           ≤t    d
                      dd                 
                                                                     dd           
                                                                                  
                        d                                              d      
                              d                                            d 
                                ⊥                                      false
Hankin & Nielson & Nielson (IC & DTU)        Probabilistic Aspects                   KCL 2010   10 / 37
 When to grant access?

  How do we map four-valued truth vales into two-valued booleans?
  Overall policy (of this paper):
  An operation should be denied only if there is some evidence to suggest so:

                                        grant(f ) = (f ≤k true)



                        d
                          d
                            d
              true     ≤k   d false
                   dd        
                             
                           d      
                               d 
                                ⊥


Hankin & Nielson & Nielson (IC & DTU)        Probabilistic Aspects   KCL 2010   11 / 37
 Projections from Belnap to Bool

  We define the operations f [⊥ → b] and f [                             → b] as follows:

                                                           b     if f = ⊥
                                   f [⊥ → b] =
                                                           f     otherwise

                                                           b     if f =
                                   f[      → b] =
                                                           f     otherwise

  The functions from Four to Bool that act as the identity on t and f are
  exactly those of the form

                                        g (f ) = f [⊥ → b1 ][           → b2 ]

  for choices of b1 , b2 ∈ Bool. They constitute different ways of obtaining
  gap-free (i.e. not giving ⊥) and conflict-free (i.e. not giving ) formulae.

Hankin & Nielson & Nielson (IC & DTU)           Probabilistic Aspects                      KCL 2010   12 / 37
 Granting



  This suggests defining four pairs of functions

                           grant(f ) = (t = f [⊥ → b1 ][              → b2 ])
                            deny(f ) = (f = f [⊥ → b1 ][              → b2 ])


                                            [ → t]                [   → f]
                                [⊥ → t]   non-blocking             liberal
                                [⊥ → f]    designated             rigorous




Hankin & Nielson & Nielson (IC & DTU)     Probabilistic Aspects                 KCL 2010   13 / 37
 The Liberal Approach



  The liberal approach takes the view that an access should be denied if
  some evidence suggests so; otherwise it should be granted.

  This can be expressed as follows:

                                        grant(f ) = f ≤k t
                                        deny(f ) = f ≥k f

  This seems to correspond to a reference monitor approach where
  operations proceed unless explicitly stopped.




Hankin & Nielson & Nielson (IC & DTU)      Probabilistic Aspects   KCL 2010   14 / 37
 Composing Policies



  One possibility would be to set comb(pols ; polt ) = pols as would be useful
  for modelling capability lists; another would be to set
  comb(pols ; polt ) = polt as would be useful for modelling access control
  lists. In distributed systems it is unclear which is best. We therefore adopt
  the more flexible approach of setting

                                   comb(pols ; polt ) = pols ⊕ polt

  as it lets distributed policies carry equal weight in determining access
  rights.




Hankin & Nielson & Nielson (IC & DTU)       Probabilistic Aspects     KCL 2010   15 / 37
 Decomposing Policies




  For every policy pol there exists policies polin , polread and polout such that

                                 [[pol]] = [[polin ⊕ polread ⊕ polout ]]

  where polc only contains literals of the form [rec if cut : cond] and where
                                                  −
                                                  →
  cut is a c action, i.e. cut is of the form :: c( λ )@ .X .




Hankin & Nielson & Nielson (IC & DTU)        Probabilistic Aspects         KCL 2010   16 / 37
 Probabilistic Four-valued Logic


         The values are (p1 , p2 , p3 , p4 ) where pi ∈ [0, 1] and
         p1 + p2 + p3 + p4 = 1
                defines the probability distribution over (⊥, true, false, )
                Example: true = (0,1,0,0) and false = (0,0,1,0)
         The operations of four-valued logic are extended to probabilistic
         four-valued logic, e.g.:
                (p1 , p2 , p3 , p4 ) ⊕ (q1 , q2 , q3 , q4 ) =
                (p1 q1 , p1 q2 + p2 (q1 + q2 ), p1 q3 + p3 (q1 + q3 ), 1 − . . .)
         We need to redefine ?s that with probability s returns its argument
         and with probability 1 − s gives true:
                ?s (q1 , q2 , q3 , q4 ) = (sq1 , (1 − s) + sq2 , sq3 , sq4 )




Hankin & Nielson & Nielson (IC & DTU)         Probabilistic Aspects                 KCL 2010   17 / 37
 Examples using Probabilistic Four-valued Logic
  In 90% of the cases the buyer will check that the seller offers secure
  payment for objects that are not cheap:
                                                                   
                                  ?0.9 false
                               if u :: out(bid, n, b, )@pBuy :
             Pol0.9
                                                                                
                secure         u = b ∧ ∃r , s : (test(object, n, s, r )@pBuy ∧ 
                                        ¬(r = cheap) ∧ ¬(test(safepay, s)@pBuy))


  In 20% of the cases the buyer is insistent on the ability to perform
  monthly installments on expensive items but is willing to make use of
  whatever payment scheme is offered in the remaining 80% of cases.
                                                                      
                                 ?0.2 false
                              if u :: out(bid, n, b, )@pBuy :
          Pol0.2
                                                                                      
             monthly          u = b ∧ ∃r , s : (test(object, n, s, r )@pBuy ∧        
                                        (r = expensive) ∧ ¬(test(monthly, s)@pBuy))

Hankin & Nielson & Nielson (IC & DTU)          Probabilistic Aspects          KCL 2010    18 / 37
 Example: Combining policies
  The overall policy for a buyer

                                        Pol0.9 ⊕ Pol0.2
                                           secure   monthly



         If the action does not match the policy evaluates to (1, 0, 0, 0)
         meaning that it does not apply
         If the action does match and if the conditions of the two actions are
         satisfied, then
                Pol0.9 evaluates to (0, 0.1, 0.9, 0)
                   secure
                Pol0.2
                   monthly evaluates to (0, 0.8, 0.2, 0).
         The combined policy evaluates to (0, 0.08, 0.18, 0.74) meaning that
                in 8% of the cases the action is granted,
                in 18% of the cases it will be denied and
                in 74% of the cases the two policies give conflicting information.


Hankin & Nielson & Nielson (IC & DTU)      Probabilistic Aspects          KCL 2010   19 / 37
 Language Design
  The syntax of the workflow language

       N ∈ Net                      N ::= N1 || N2 | l ::pol P | l ::pol T
       P ∈ Proc                     P ::= P1 | P2 |                  ai .Pi | ∗P
                                                                       i
                                              −
                                              →                          −
                                                                         →            −
                                                                                      →
       a ∈ Act                      a ::= out( ) @                 | in( λ ) @ | read( λ ) @
                                                              −
                                                              →
       T ∈ Tuplespace               T   ::= ε | T             l
         ,   λ   ∈ Loc                  ::= u | l                  λ       ::= | !u


  Note:

         policies are distributed over the net
         each locality has exactly one policy

Hankin & Nielson & Nielson (IC & DTU)      Probabilistic Aspects                      KCL 2010   20 / 37
 Language Design

  The syntax of policies

     pol ∈ Pol                 pol      ::= [rec if cut : cond]
                                          | pol φ pol | ¬pol | true | false
     cut ∈ Cut                 cut ::=       :: at
                                              −→−
                                                →            −→
     at ∈ Actt                   at      | in( tλ ) @ | read( tλ ) @
                                        ::= out( t ) @
                                           −
                                           →
     rec ∈ Rec     rec ::= 1 = 2 | test( t )@ | ¬rec | true | false
                         | rec φ rec | ?x rec
                                           −
                                           →
     cond ∈ Cond cond ::= 1 = 2 | test( t )@ | true | false | ¬cond
                         | cond1 ∧ cond2 | cond1 ∨ cond2 | ∃x : cond
      t , tλ   ∈ Loct              t    ::=    |               tλ     ::=   λ   |


Hankin & Nielson & Nielson (IC & DTU)         Probabilistic Aspects                 KCL 2010   21 / 37
 Language Design: Semantics




  Markov Decision Process
      non-determinism arises because of the non-determinism of the
      underlying language: selection of tuples, the choice construct and
      parallelism
         probabilities arises because of the probabilistic policies




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects         KCL 2010   22 / 37
 Language Design: Markov Decision Processes
  We formulate the semantics as a one-step reduction function
  ⇒: Net → P=∅ (D(Net))

  A probability distribution on nets is a function µ : Net → [0, 1] such that
  ΣN∈Net µ(N) = 1.

  To take proper account of the congruence we shall say that a probability
  distribution µ is well-formed whenever it satisfies the property
                         µ(N) > 0 ∧ µ(N ) > 0 ∧ N ≡ N ⇒ N = N
  Since Net is countable we can write probability distributions in the form
     pi
     i Ni , subject to Σi pi = 1 and Ni ≡ Nj ⇒ i = j. This denotes the
  probability distribution µ given by µ(N) = Σi|Ni =N pi .

  We shall write N → ipi Ni whenever one non-deterministic step in the
  evaluation of N might produce the probability distribution ipi Ni where
  Ni is chosen with probability pi .
Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects     KCL 2010   23 / 37
 Structural Congruence


  Associative and commutative (wrt |) equivalence relation which is a
  congruence (wrt |).


                            l ::pol P1 | P2 ≡ l ::pol P1 || l ::pol P2
                                 l ::pol ∗P ≡ l ::pol P | ∗P
                                   l ::pol P ≡ l ::pol P || l ::pol 0



                                            N1 ≡ N2
                                        N || N1 ≡ N || N2




Hankin & Nielson & Nielson (IC & DTU)     Probabilistic Aspects          KCL 2010   24 / 37
 Matching Input Patterns




                                       −
                                       →−
                                        →                  − −
                                                           → →
                     match( !u,         λ
                                   ; l, l )        = match( λ ; l ) ◦ [l/u]
                                −
                                →      →
                                       −                   − −
                                                           → →
                       match( l, λ ; l, l )        = match( λ ; l )
                            match( ; )             = id
                             match( · ; · )        = fail   otherwise




Hankin & Nielson & Nielson (IC & DTU)       Probabilistic Aspects             KCL 2010   25 / 37
 Checking Formals to Actuals



                                    −
                                    →               − → −
                            −
                  check( α, → ; α , α ) = check( → ; α ) ◦ do(α; α )
                            α                       α
                          check( ; ) = id
                           check( · ; · ) = fail otherwise

               do(u ; l)        =       [l/u]           do(!u ; !u )     =   [u /u]
                do( ; l)        =       id               do( ; !u)       =   id
              do(X ; P)         =       [P/X ]             do(l ; l)     =   id
               do(c ; c)        =       id                 do(· ; ·)     =   fail otherwise




Hankin & Nielson & Nielson (IC & DTU)            Probabilistic Aspects                KCL 2010   26 / 37
 The Meaning of Policies



                if
         [[[rec  cut : cond]]](l :: a) =                                               
                   case check( extract(cut) ; extract(l :: a)) of
                                                                                   
                
                               fail : ⊥                                              
                                                                                      
                                       [(rec θ)] if [(cond θ)]                     
                                θ:
                                         ⊥          if ¬[(cond θ)]

                    [[pol1 φ pol2 ]](l :: a) = ([[pol1 ]](l :: a)) φ ([[pol2 ]](l :: a))
                              [[¬pol]](l :: a) = ¬([[pol]](l :: a))
                               [[true]](l :: a) = t                [[false]](l :: a) = f




Hankin & Nielson & Nielson (IC & DTU)      Probabilistic Aspects                      KCL 2010   27 / 37
 Semantics



                       pi                                             pi
           N→          i    Ni                  N≡M             M→    i    Mi          i   Mi ≡ Ni
                       pi                                                  pi
   N || M →            i    Ni || M                              N→        i    Ni

                   −
                   →
   ls ::pols (out( l )@lt .P + Q) || lt ::polt T
                                            −
                                            →
     → p ls ::pols P || lt ::polt T          l
                             −
           q l ::pols (out(→)@l .P + Q) || l ::polt T
                              l
                s                  t                t
                                                      −
                                                      →                              −
                                                                                     →
               if (p, q) = grant([[pols ]](ls :: out( l )@lt ) ⊕ [[polt ]](ls :: out( l )@lt ))




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects                        KCL 2010   28 / 37
 The Airport Scenario

  The security policy depends on the current security threat:
    1 In general, one is only permitted to pass through to the Departures
      lounge if the travelling documents have been checked and one passes
      through a standard scanner.
     2 In times of heightened security, the airport might want to subject
       certain high risk travellers to full body scans before allowing them
       into the Departures lounge – since this delays the flow of passengers,
       the airport only subjects a certain proportion of this category of
       travellers to the full check.
     3 It might also be the case that, in such circumstances, some
       proportion of passengers might be subjected to a manual frisking,
       regardless of their profile.



Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects   KCL 2010   29 / 37
 The airport scenario - the data
          traveller, name, profile records that name is a potential traveller and
         profile is one of:
                unchecked: documents have not yet been inspected
                low: documents are in order and the traveller is from a low risk group
                high: documents are in order and the traveller is from a high risk group;
          passenger, name records that name has been allowed to proceed to
         the departure lounge;
          scan, name, gate records that name has passed through a
         walkthrough scanner at gate;
          fullscan, name, gate records that name has been subjected to a full
         body scan at gate;
          frisk, name, gate records that name has been manually frisked at
         gate; and
          threat, level with level ∈ {normal, severe} records the current
         security threat level
Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects              KCL 2010   30 / 37
 The Airport Scenario - policy 1


  In general, one is only permitted to pass through to the Departures lounge
  if the travelling documents have been checked and one passes through a
  standard scanner.



                                                                                     
                     (test(traveller, t, low)@Port ∨ test(traveller, t, high)@Port) ∧
                    test(scan, t, g )@Port                                           
  Poldefault       
                    if g :: out(passenger, t)@Port :
                                                                                      
                                                                                      
                        true




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects          KCL 2010   31 / 37
 The Airport Scenario - policy 2

  In times of heightened security, the airport might want to subject certain
  high risk travellers to full body scans before allowing them into the
  Departures lounge – since this delays the flow of passengers, the airport
  only subjects a certain proportion, fs, of this category of travellers to the
  full check



                                                                                      
                      ?fs false
                     if g :: out(passenger, t)@Port :
  Polfs
                                                                                       
     security
                                                                                      
                     ∃p : (test(traveller, t, p)@Port ∧ p = high ∧                    
                            test(threat, severe)@Port ∧ ¬(test(fullscan, t, g )@Port))



Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects           KCL 2010   32 / 37
 The Airport Scenario - policy 3


  It might also be the case that, in in the case of heightened security, some
  proportion (say fr ) of passengers might be subjected to a manual frisking,
  regardless of their profile.



                                                                                   
                      ?fr false
                     if g :: out(passenger, t)@Port :
  Polfr
                                                                                    
                                                                                   
     manual          ∃p : (test(traveller, t, p)@Port ∧                            
                            test(threat, severe)@Port ∧ ¬(test(frisk, t, g )@Port))




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects           KCL 2010   33 / 37
 The Airport Scenario - combining the policies

                        Polfs,fr
                           airport      Poldefault ⊕ Polfs            fr
                                                        security ⊕ Polmanual



  In the case of severe security threat and a passenger with high security
  profile:

         the three policies will evaluate to the probabilistic four-valued truth
         values (0, 1, 0, 0), (0, 1 − fs, fs, 0) and (0, 1 − fr , fr , 0) respectively.
         The combined policy evaluates to

                              (0, 1 − fs − fr + fs · fr , 0, fs + fr − fs · fr )

         The action will be granted in 100(1 − fs − fr + fs · fr )% of the cases.
         The action will be denied in 100(fs + fr − fs · fr )% of the cases.

Hankin & Nielson & Nielson (IC & DTU)       Probabilistic Aspects                  KCL 2010   34 / 37
 Conclusion


  Highlights:
      Probabilities are introduced in the sub-language for policy
      recommendations rather than in the actual primitives of the
      programming language.
         Four-valued logic has been used for obtaining a compositional
         specification of the policies.
         Policy recommendations are expressed using aspects in order to
         obtain a flexible specification that can be changed as the need arises
         to revise the security policy.




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects     KCL 2010   35 / 37
 Future work


  A logic for reasoning about policies
  There is at most 10% chance that a buyer actually places a bid without
  checking that the seller supports safe payment for non-cheap objects, and
  without checking that the seller offers monthly installments for expensive
  objects.
  Expressed in a probabilistic variant of ACTL:

                 ∀b, n, v . P≤0.1 (true C U{b::out(bid,n,b,v )@pBuy} ∃r , s.
                            (test(object, n, s, r )@pBuy∧
                            ¬(r = cheap ⇒ test(safepay, s)@pBuy)∧
                            ¬(r = expensive ⇒ test(monthly, s)@pBuy)))




Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects            KCL 2010   36 / 37
 Future work

  A logic for reasoning about policies
  There is some threshold probability tr above which, at times of heightened
  security, it is not possible for a passenger to get into the Departures lounge
  without having been through a full body scanner (if a high risk traveller)
  or being manually frisked.

          ∀g , t. P≤tr (true C U{g ::out(passenger,t)@Port} ∃p.
                    (test(traveller, t, p)@Port ∧ test(threat, severe)@Port∧
                    ¬(p = high ⇒ test(fullscan, t, g )@Port)∧
                    ¬(test(frisk, t, g )@Port)))


  We might aim to minimise fs and fr such that 1 − fs − fr + fs · fr ≤ tr .



Hankin & Nielson & Nielson (IC & DTU)   Probabilistic Aspects        KCL 2010   37 / 37

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:14
posted:10/7/2011
language:English
pages:37