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 Security issues must be dealt with in all phases of software development Secure patterns/models Secure patterns/models Secure coding practices Secure coding practices Secure development procedures Secure development procedures During deployment and maintenance phases During deployment and maintenance phases

3. On the flip side… Is computer security possible? 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. 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 A standard constraint language Expressive power Expressive power Pairs with UML Pairs with UML Accessible to developers and programmers at each level 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 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) 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) 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 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 Conversion between use cases and OCL expressionsRoussev

10. Where we are What we have: OCL OCL UML UML Set of rules that ensure consistency in secure diagrams Set of rules that ensure consistency in secure diagrams Ever-expanding corpus of secure coding practices in every phase of software development Ever-expanding corpus of secure coding practices in every phase of software development A tool which generates a fault-revealing graph 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 Useful for expressive power Can formulate constraints which are security- related Can formulate constraints which are security- related Object Management Group

12. What we have, part 2 UML Visual expressive power Visual expressive power Class interaction and sequences are defined in a meta-model Class interaction and sequences are defined in a meta-model Object Management Group

13. What we have, part 3 Current rules Restrict operation access Restrict operation access Define compositions Define compositions Maintain multiplicity 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 As provided by both industry and academia Guidelines for each phase in development 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 faultsat 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 The OCL is a useful middle man for both design and testing secure systems Design Document - Use Case - UML Model extract Constraint c 1 Context Account::create() Inv:oclSet={Teller} Inv.oclSet -> includes(source.type) Trace Implementation verify

20. Process 1. Create Unit Tests. 2. Instrument the source code so message paths (and associated objects) can be traced. 3. Execute the tests and record objects and message paths. 4. Construct directed acyclic graphs for every trace. 5. 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. 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. 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. 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. 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 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. 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; 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; 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. 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. 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. 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. Our approach will trace object-method calls, therefore we will focus on the interaction between components.

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. 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 Account::create() Inv:oclSet={Teller} Inv:oclSet={Teller} Inv.oclSet -> includes(source.type) Inv.oclSet -> 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. Conclusion: Putting it all together The OCL is a useful component in secure system design The OCL is a useful component in secure system design The OCL is flexible, available, and powerful The OCL is flexible, available, and powerful Constraints can be validated Constraints can be validated A debugging utility that allows us to trace execution A debugging utility that allows us to trace execution Build a graph for inspection Build a graph for inspection Check the graph for constraint inconsistencies Check the graph for constraint inconsistencies