A Method for Validating Software Security Constraints

1
A Method for Validating Software Security
Constraints

• Filaret Ilas
• Matt Henry
• CS 527
• Dr. O.J. Pilskalns

2
Motivation

• Security issues must be dealt with in all phases
  of software development
• Secure patterns/models
• Secure coding practices
• Secure development procedures
• During deployment and maintenance phases

3
On the flip side

• Is computer security possible?
• Some argue that until computers can fix
  themselves dynamically, then systems will always
  be vulnerable.
• Furthermore, computers are incapable of handling
  the infinite variety of attacks however,
  software may implement limited repairing schemes
  which require small amount of programmer
  assistance (debugging, etc.)

4
Why its important

• Design-level vulnerabilities are the hardest
  defect category to handle, but theyre also the
  most prevalent and critical.
• Software Security Testing, IEEE Security and
  Privacy Sep/Oct 2004, pgs 81-85
• Attacks come in every level, from source code
  bugs to design flaws.

5
Why its important, contd

• We need to ensure that the secure pattern/model
  is consistent with the implementation.

6
Why OCL?

• A standard constraint language
• Expressive power
• Pairs with UML
• Accessible to developers and programmers at each
  level

7
Why OCL? contd

• Expressive power includes existential and
  universal quantification
• Can provide a regulatory scheme for securing
  system components
• Allows the designer to check violations easily
  (i.e., if constraints are not followed in test
  cases)

8
A solution

• Thanks to the OCLs expressive power, we can
  generate constraints that consist of universal
  statements.
• For example, we can ensure that only a specified
  number of instances are created (i.e.,
  connections, clients, administrators, etc.)

9
Background

• Some tools/extensions that already exist
• OCSL (Object Security Constraint Language)
• Allows for a security-driven development
  extends OCL syntax, but with a focus on security
• Medina, et.al.
• USE (UML Specification Environment) implements a
  test/validate process that allows a snapshot
  diagram to be constructed and given properties
  are validated
• Gogolla, et.al.
• Conversion between use cases and OCL expressions
• Roussev

10
Where we are

• What we have
• OCL
• UML
• Set of rules that ensure consistency in secure
  diagrams
• Ever-expanding corpus of secure coding practices
  in every phase of software development
• A tool which generates a fault-revealing graph

• What we need
• a tool that helps us determine whether software
  meets the security requirements of the original
  model

11
What we have, part 1

• OCL
• Useful for expressive power
• Can formulate constraints which are
  security-related
• Object Management Group

12
What we have, part 2

• UML
• Visual expressive power
• Class interaction and sequences are defined in a
  meta-model
• Object Management Group

13
What we have, part 3

• Current rules
• Restrict operation access
• Define compositions
• Maintain multiplicity
• All of these help to keep the UML model
  consistent in terms of security
• Paired with a constraint checking tool, may
  verify whether or not these rules are followed
• Pilskalns, Williams, Aracic, Andrews

14
What we have, part 4

• Secure coding practices
• As provided by both industry and academia
• Guidelines for each phase in development

15
What we have, part 5

• Fault-finding method
• After execution of successful and fault-revealing
  unit tests, can generate graphs that show the
  differences
• Graphs can be transformed into UML Sequence
  Diagrams
• Can use Sequence Diagrams to reveal faults at a
  higher level
• Pilskalns, Wallace

16
Security management

• Rather than deal with each attack individually,
  and at each level, we propose a method which
  could effectively secure a system at the highest
  level, and (depending on the security model)
  reduce the risk at lower levels.

17
What we need

• An automated tool that helps us effectively
  validate secure OCL constraints of a system

18
Our approach

• This approach is similar to using
  reverse-engineered UML Sequence Diagrams. The
  approach relies on visual analyses of traces of
  object-method calls. Tests reveals if there exist
  any security flaws in the code execution. The
  approach verifies whether the security
  constraints specified in the design phase hold
  for a set of test cases.

19
Our approach, contd

• The OCL is a useful middle man for both design
  and testing secure systems

Trace
Design Document - Use Case - UML Model

• Constraint c1
• Context Accountcreate()
• InvoclSetTeller
• Inv.oclSet -gt includes(source.type)

extract
verify
Implementation
20
Process

• Create Unit Tests.
• Instrument the source code so message paths (and
  associated objects) can be traced.
• Execute the tests and record objects and message
  paths.
• Construct directed acyclic graphs for every
  trace.
• Verify that the security constraints specified in
  the design phase hold for each graph.

21
1. Create Unit Tests

• Unit tests provide coverage of the code used in a
  specific test case. There will be unit tests
  provided for both secure and non-secure code
  execution.

22
2. Instrument the source code

• The instrumentation process inserts tracking code
  that records the method execution calls between
  objects, so message paths (and associated
  objects) can be traced.

23
3. Execute the tests and record objects and
message paths.

• During the execution, the instrumented byte code
  is traversed using the unit tests. Each unit test
  generates an object-method trace through the code.

24
4. Create graphs

• Construct directed acyclic graphs for every trace

25
5. Verify consistency

• Make sure the security constraints specified in
  the design phase hold for each graph.

26
What we can do

• Our tool allows assessing the following types of
  security constraints
• Operation access check if an object is allowed
  to use operations provided by another object
• Composition check if the life span of an object
  doesnt exceed the life span of the container
  object
• Multiplicity checks if the number of instances
  of an object doesnt exceed the maximum number of
  instances allowed to complete a task.
• This is a good place to start

27
Experimental results

• The assessing module was tested successfully on
  simplified version of Banking System. The
  communication between the system and its
  components Teller and Customer is done using
  messages. Any request for a certain service is
  managed by the Transaction Manager.

28
Experimental Factors

• The purpose of using the Banking example is not
  to implement a fully functional banking system,
  but to check if the security constraints
  specified in the design phase hold. Therefore we
  will focus on the object interaction rather than
  purely coding the tasks specific for any
  component.
• Our approach will trace object-method calls,
  therefore we will focus on the interaction
  between components.

29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
Validating Operation Access

• First of all we will check for the operation
  access constraints. In the paper Security
  Consistency in UML Designs the author is
  proposing a few operation access constraints
  which we will test in the following use cases.
• We have the following constraint
• Context Accountcreate()
• InvoclSetTeller
• Inv.oclSet -gt includes(source.type)
• It will grant access to the Account.create()
  method only for instances of the Teller object.

33
Graph Representation

• Every object-method call will be represented in
  the direct acyclic graph with two vertices
  corresponding to the entry point and return. The
  links between vertices correspond to the order of
  the method calls. Each vertex contains the
  following information id, location and method.
• We can easily point out the vertices
  corresponding to the create() method call. The
  order the methods are called is preserved in the
  graph, therefore we can search backward in the
  graph to see if there is any instance of the
  Teller object responsible to make the create()
  call. We find out that the create() method is
  called by the Teller.transfer() method. In this
  situation we conclude that the system might be
  secure regarding this operation access
  constraint.

34
Graph Representation,part 2

• Every object-method call will be represented in
  the direct acyclic graph with two vertices
  corresponding to the entry point and return. The
  links between vertices correspond to the order of
  the method calls. Each vertex contains the
  following information id, location and method.
• We can easily point out the vertices
  corresponding to the create() method call. The
  order the methods are called is preserved in the
  graph, therefore we can search backward in the
  graph to see if there is any instance of the
  Teller object responsible to make the create()
  call. We find out that the create() method is
  called by the Teller.transfer() method. In this
  situation we conclude that the system might be
  secure regarding this operation access
  constraint.

35
ConclusionPutting it all together

• The OCL is a useful component in secure system
  design
• The OCL is flexible, available, and powerful
• Constraints can be validated
• A debugging utility that allows us to trace
  execution
• Build a graph for inspection
• Check the graph for constraint inconsistencies