Security Pattern Assurance through Round-Trip Engineering

1. Amnon H. EdenSchool of Computer Science & Electronic Engineering University of Essex Cyberpatterns 2013,9 July 2013, Abington, Oxfordshire Security Pattern Assurance through Round-Trip Engineering

2. Abstract Catalogues of security patterns record object-oriented design practices that have proved to promote security. Our research project facilitates making, modelling and enforcing design decisions involving security patterns: • Making design decisions, by creating a guide for the transition from requirements to tactics and from tactics to patterns • Modelling design decisions, by capturing the constraints that each security pattern imposes clearly, precisely and with minimal effort • Enforcing design decisions, by developing tools for fully automated conformance checking We conclude with a round-trip software engineering tool supporting these activities

3. Contents • Making design decisions • From requirements to tactics to patterns • Modelling design decisions • Structure: Codecharts • Behaviour: Temporal logic • Enforcing design decisions • Verification • Tool support • Round-trip engineering

4. 1 Example Requirement: withstand attacks————————————— • Make design decision • Tactics: Limit Exposure • Pattern: Check Point • Model the decision • Structure: Codecharts) • Behaviour: Temporal logic • Enforce the decision • Map pattern to implementation • Verify with the Toolkit 2 3

5. Requirements  Tactics  Patterns Making design decisions Modelling design decisions Enforcing design decisions Round-trip engineering Making design decisions

6. Tactics • Fine-grained design objectives • Each contributes to one quality attribute: • Availability • Interoperability • Modifiability • Performance • Security • Testability • Usability (Bass, Clements, Kazman 2012)

7. Tactics hierarchy (Ryoo, Kazman & Laplante 2012)

8. Guide for secure design • Tactics • Patterns: • Single Access Point, Check Point, Roles,Session, Full View with Errors, Limited View, Security Access Layer, Intercepting Validator, Secure Logger, … http://security.altoona.psu.edu/designguide/

9. Project • Security Pattern Assurance through Round-trip Engineering • LENS (Line-funded Exploratory New Starts) • Software Engineering Institute, Carnegie-Mellon University • $125K Rick KazmanSEI & U of Hawaii Abdullah AlzahraniU of Essex Jungwoo RyooPenn State Rob WojcikSEI Gary Chastek SEI Amnon H. EdenU of Essex

10. Codecharts Making design decisions Modelling design decisions Enforcing design decisions Round-trip engineering Modelling design decisions:Structure

11. Security patterns • Check Point pattern • Intent • Intercepts and monitors all incoming requests • Takes appropriate countermeasures in case of violations • Participants • CheckPoint • Countermeasure • SecurityPolicy (Schumacher, Fernandez-Buglioni, Hybertson, Buschmann, Sommerlad 2006) (Wasserman & Cheng 2003)

12. Security patterns: structure • Check Point pattern (cont.) • CheckPointchecks messages according to the current security policy; triggers countermeasures or allows the message to proceed to the intended recipient • Countermeasure provides actions that can be triggered in order to react to an access violation • SecurityPolicy implements the rules that determine whether a request is granted (Wasserman & Cheng 2003)

13. Modelling structure Class Diagrams Check Point (Wasserman & Cheng 2003)

14. Modelling structure Class Diagrams 3. Is it class “CheckPoint”? 1. Which method calls which? 2. What’s this? Check Point (Wasserman & Cheng 2003)

15. Call(checkRequestcheckPoint,TriggercounterMeasure) Modelling structure Codechart counterMeasure :CLASS checkPolicy :SIGNATURE Trigger :P SIGNATURE InternalEntities :P CLASS Check Point (Wasserman & Cheng 2003)

16. Modelling structure (2) Class Diagrams • CheckPoint encapsulates the security policy • Many policies Þ many CheckPoints Common? Unique? One concrete CP or many? Check Point (Schumacher et al. 2006)

17. Modelling structure (2) Codechart Schema CheckPointHierarchy :HIERARCHY CheckPoint2 CheckPointHierarchy :HIERARCHYaccess, checkRequest:SIGNATURETrigger, SecureActions:P SIGNATUREsingleAccessPoint,counterMeasure :CLASSInternalEntities :P CLASS Check Point (Schumacher et al. 2006) Call(accesssingleAccessPoint, checkRequestcheckPointHierarchy)Call(accesssingleAccessPoint, SecureActionsInternalEntities)…

18. Modelling structure (3) • Java Authentication & Authorization Service (JAAS) • Java implementation of Pluggable Authentication Module (PAM) • Information security framework • Other implementations: PAMLinux Codechart • Used: Apache Web server • validate each HTTP request according to a configured activation sequence JAAS

19. Modelling structure: Codecharts • Methods, sets, signatures • Precise criterion of correctness • Communication; verification; automation, … • Variations become evident Check Point (Wasserman et. al 2003) Check Point (Schumacher et al. 2006)

20. Codecharts Making design decisions Modelling design decisions Enforcing design decisions Round-trip engineering Modelling design decisions:Behaviour

21. Security patterns: behaviour • CheckPoint checks if msg conforms to the policy. • If no, triggers a countermeasure • If yes, allows msg to proceed to the intended recipient • Countermeasure reacts to an access violation when triggered • Client receives granted/denied access message • … Check Point (Wasserman & Cheng 2003)

22. Modelling behaviour SequenceDiagrams Limited abstractions Difficult to represent global constraints Limited tool support in verification Check Point (Wasserman & Cheng 2003)

23. Modelling behaviour Statecharts Limited to FSAs Problematic integration Check Point (Wasserman & Cheng 2003)

24. Modelling behaviour TemporalLogic W (CheckPoint.denyAccessÞ à CounterMeasure.triggered) W (CheckPoint.denyAccessÞ Client.accessFailU Client.idle) W (CheckPoint.grantAccessÞ (à Client.succeed)U Client.idle) Availability Check Point (Wassermann & Cheng 2003)

25. Automated verification The TTP Toolkit Making design decisions Modelling design decisions Enforcing design decisions Round-trip engineering Enforcing design decisions

26. Enforcing structure Successful Java 3D

27. Security patterns: structure Apparent similarity… Check Point Pattern JAAS

28. Enforcing structure Assignment of constants to variables Assignment Check Point

29. Enforcing structure: verification • Hypothesis: AJAVA(JAAS)CheckPoint • Proof: • Straightforward, with some reasoning, e.g. • át1,t2ñÎForward át1,t2ñÎCall • If a method creates an instance of x then it calls a c’tor of x • … • Trivial but tedious!

30. Enforcing structure: automation Result Assignment Check Point

31. Enforcing behaviour: verification • Wasserman & Cheng (2003): • Technique: model checking • Tools: • MINERVA (Campbell et al. 2002): check consistency of UML • HYDRA (McUmber & Cheng): UML  Promela • SPIN (Holzman 1997): Model checker • Systems tested: small examples Manual Manual (Wasserman & Cheng 2003)

32. Making design decisions Modelling design decisions Enforcing design decisions Round-trip engineering Round-trip engineering

33. Forward, reverse, & round-trip (Eden, Gasparis, Nicholson & Kazman, forthcoming)

34. Modelling: detailed

35. Implementation Java 3D

36. Modelling: abstract Java 3D

37. Code analysis Java 3D

38. Verification Successful Java 3D

39. Modelling patterns www.lepus.org.uk

40. (structural conformance to) Verifying patterns Map design to implementation Java 3D Implements Factory Method Factory Method in Java 3D

41. Implementation: evolve Carelesschange

42. Verification (again)

43. Visualization Package java.util.logging

44. Modelling: evolve

45. Modelling formats <?xml version=”1.0” encoding=”ISO-8859-1”?> <?xml-stylesheet type="text/xsl" href="http://www.lepus.org.uk/templates/classz.xsl"?> <schema xmlns="http://www.lepus.org.uk/classz" title="Factory Method" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.lepus.org.uk/classz http://www.lepus.org.uk/templates/classz.xsd"> <description>The Factory Method design pattern</description> <declarations> <declare> <variable value="Factories" /> <variable value="Products" /> <type value="HIERARCHY" exponent="1" /> </declare> <declare> <variable value="factoryMethod" /> <type value="SIGNATURE" exponent="0" /> </declare> </declarations> <formulas> <formula> <predicatesymbol value="Isomorphic" /> <relationsymbol value="Produce" transitive="false" /> <superimposition> <variable value="factoryMethod" /> <variable value="Factories" /> </superimposition> <variable value="Products" /> </formula> </formulas> <!--Generated using the TTP Toolkit on Tue Nov 27 17:42:25 GMT 2012--> </schema> Textually(XML) Visually (Codechart) Symbolically (Schema) Factory Method pattern

46. Sidebar: Codecharts

47. Desiderata • Automatically verifiable • Modelling & visualization • Elegant & parsimonious • Formal & practical • Visual & symbolic • Object-oriented • Scalable • Generic LePUS3 Vocabulary (Eden & Nicholson 2011)

48. Inspiration: blueprints

49. Codechart Visual & symbolic Schema CheckPoint2 CheckPointHierarchy :HIERARCHYaccess, checkRequest:SIGNATURETrigger, SecureActions:P SIGNATUREsingleAccessPoint,counterMeasure :CLASSInternalEntities :P CLASS Check Point (Schumacher et al. 2006) Call(accesssingleAccessPoint, checkRequestcheckPointHierarchy)Call(accesssingleAccessPoint, SecureActionsInternalEntities)…

50. Parsimony “Each Scene Graph State class defines a factory method that creates and returns the respective Scene Graph Object” Java 3D (Eden et al. 2013)