Testing Implementations Of Access Control Systems (New Proposal)

1
Testing Implementations Of Access Control
Systems(New Proposal)
Ammar Masood Graduate Student Arif Ghafoor (ECE)
and Aditya Mathur (CS) Purdue University, West
Lafayette SERC Showcase, June 7-8, 2006 Motorola
Labs, Schaumburg, IL
2
Research Objectives

• To develop, experiment with and study the
  effectiveness of techniques for the generation of
  tests to validate conformance of implementations
  of access control policies (in particular Role
  Based Access Control RBAC with or without
  temporal constraints)

3
Related Work

• R. Chandramouli. M. Blackburn. Automated Testing
  of Security Functions using a combined Model
  Interface driven Approach. Proc. 37th Hawaii
  International Conference on System Sciences, pp.
  299-308, 2004
• J. Springintveld, F. Vaandrager and P.R.
  D'Argenio. Testing timed automata. Theoretical
  Computer Science, 254(1-2), pp. 225-257, 2001
• A. En-Nouaary, R. Dssouli and F. Khendek. Timed
  Wp method testing real time systems. IEEE
  Transactions on Software Engineering, 28(11), pp.
  1023 1038, 2002.
• K.G. Larsen, M. Mikucionis and B. Nielsen. Online
  Testing of Real-time Systems Using UPPAAL. Formal
  Approaches to Testing of Software. Linz, Austria.
  September 21, 2004

4
Proposed Test Infrastructure
5
Challenges

• Modeling
• Naïve FSM or timed automata models are
  prohibitively large even for policies with 10
  users and 5 roles (and 3 clocks).
• How to reduce model size and the tests generated?
  
• Test generation
• How to generate tests to detect (ideally) all
  policy violation faults that might lead to
  violation of the policy?
• Test execution
• Distributed policy enforcement?

6
Proposed Approach

• Express behavior implied by a policy as an FSM.
• Apply heuristics to scale down the model.
• Use the W- method, or its variant, to generate
  tests from the scaled down model.
• Generate additional tests using a combination of
  stress and random testing aimed at faults that
  might go undetected due to scaling.

7
Sample Model
Two users, one role. Only one user can activate
the role. Number of states32.
AS assign. DS De-assign. AC activate. DC
deactivate. Xij do X for user i role j.
8
Heuristics
H1 Separate assignment and activation
H2 Use FSM for activation and single test
sequence for assignment
H3 Use single test sequence for assignment and
activation
H4 Use a separate FSM for each user
H5 Use a separate FSM for each role
H6 Create user groups for FSM modeling.
9
Reduced Models
Assignment Machine
Activation Machine
Heuristic 1
User u1 Machine
User u2 Machine
Heuristic 4
10
Tests Generated
11
Fault Model
12
Claim

• The proposed method for generating the complete
  behavior model and tests guarantees a test set
  that detects all faults in the IUT that
  correspond to the proposed fault model when the
  number of states in the IUT is correctly
  estimated.

13
Future Research

• Modeling
• Handling timing constraints? (timed automata,
  fault model, heuristics)
• Experimentation
• With large/realistic policies to assess the
  efficiency and effectiveness of the test
  generation methods.
• Prototype tool development

14
Schedule

• Month 1 Extend the un-timed Fault Model for
  temporal RBAC
• Months 2-4 Study applicability/extensions in
  existing timed automata test generation
  techniques for complete fault coverage with
  respect to the timed fault model
• Months 5-8 Develop techniques to reduce the
  cost of testing (Number of test cases)
• Months 9-11 Perform a case study to verify the
  efficacy of the finally proposed approach.
• Month 12 Final report.

15
Deliverables

• A methodology for testing access control
  implementations that employ temporal constraints.
• Evaluation of the methodology through a case
  study.
• A set of recommendations on the implementation of
  the methodology as an integral part of the
  software development lifecycle.

16
Budget- Year 1

• Salaries (faculty graduate student) 30,000
• Travel 8,000
• Miscellaneous 2000
• Indirect costs 10,000
• Total 50,000

17
(No Transcript)
18
Sequential Steps to a Verified Implementation