Security Pattern Assurance through Round-Trip Engineering

1

Security Pattern Assurance through Round-Trip EngineeringAmnon H. Eden

School of Computer Science & Electronic Engineering University of Essex

2

AbstractCatalogues 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 checking2

3

ContentsMaking design decisions

◦ From requirements to tactics to patternsModelling design decisions

◦ Structure: Codecharts◦ Behaviour: Temporal logic

Enforcing design decisions◦ Tool support

Round-trip engineering

3

4

ExampleRequirement: withstand attacks—————————————1)Make design decision

◦ Tactics: Limit Exposure◦ Pattern: Check Point

2)Codify the decision◦ Structure: Codecharts)◦ Behaviour: Temporal logic

3)Enforce the decision◦ Map pattern to implementation◦ Verify with the Toolkit4

singleAccessPoint

Access

securityPolicy

checkPolicy

Call

checkPoint

Call

triggerAction

Call

counterMeasure

TriggercheckRequest

1

2

3

5

ProjectSecurity Pattern

Assurance through Round-trip Engineering

LENS (Line-funded Exploratory New Starts)

Software Engineering Institute, Carnegie-Mellon University

$125K

5

Abdullah AlzahraniU of Essex

Rick KazmanSEI & U of Hawaii

Amnon H. EdenU of Essex

Gary ChastekSEI

Rob WojcikSEIJungwoo Ryoo

Penn State

6

Making design decisionsRequirements Tactics Patterns

Making design decisions

Modelling design decisions

Enforcing design decisions


7

TacticsFine-grained design objectivesEach contributes to one quality attribute:

◦ Availability◦ Interoperability◦ Modifiability◦ Performance◦ Security◦ Testability◦ Usability

7 (Bass, Clements, Kazman 2012)

8

Tactics hierarchy

8 (Ryoo, Kazman & Laplante 2012)

9

GuideTactics

Patterns: ◦ Single Access Point, Check Point, Roles, Session,

Full View with Errors, Limited View, Security Access Layer, Intercepting Validator, Secure Logger, …

9 http://security.altoona.psu.edu/designguide/

http://security.altoona.psu.edu/designguide/

10

Modelling design decisions:Structure

Codecharts





13

Security patternsCheck Point pattern

◦ Intent A component that intercepts and monitors all incoming

requests. In case of violations then it is responsible for taking appropriate countermeasures

◦ Participants CheckPoint Countermeasure SecurityPolicy

13 (Wasserman & Cheng 2003)

(Schumacher, Fernandez-Buglioni, Hybertson, Buschmann, Sommerlad 2006)

14

Security patterns: structureCheck Point pattern (cont.)

◦ CheckPoint implements a method to check messages according to the current security policy and 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


15

Modelling structure

15 Check Point (Wasserman & Cheng 2003)

Class Diagram

s

16

Modelling structure


2. What’s

this?

3. Is it class “CheckPoint”?1. Which

method calls which?

Class Diagram

s

17

singleAccessPoint

securityPolicy

checkPolicy

Call

checkPoint

Callcheck

Request

counterMeasure

Trigger Call

InternalEntities

SecureActions

Call+

access

Modelling structure


Call(checkRequestcheckPoint,TriggercounterMeasure)

InternalEntities : P CLASS

counterMeasure : CLASS

checkPolicy : SIGNATURE

Trigger : P SIGNATURE

Codecharts

19

Modelling structureCheckPoint encapsulates the security policyMany policies Þ many CheckPoints

19 Check Point (Schumacher et al. 2006)

Common? Unique?One concrete

CP or many?

Class Diagram

s

20 20 Check Point (Schumacher et al. 2006)

CheckPointHierarchy : HIERARCHYaccess, checkRequest : SIGNATURETrigger, SecureActions : P SIGNATUREsingleAccessPoint, counterMeasure : CLASSInternalEntities : P CLASSCall(accesssingleAccessPoint, checkRequestcheckPointHierarchy)Call(accesssingleAccessPoint, SecureActionsInternalEntities)…

CheckPoint2

counterMeasure

Trigger

SingleAccessPoint

CheckPointHierarchy

Call checkRequest

Call

InternalEntities

SecureActions

Call

access

CheckPointHierarchy : HIERARCHY

Codechart

Schema

Modelling structure

21

Modelling structure: Codecharts Methods, sets, signatures Precise criterion of correctness

◦ Communication; verification; automation, … Variations become evident

21 Check Point (Wasserman et. al 2003) Check Point (Schumacher et al. 2006)

securityPolicy

checkPolicy

checkPoint

Call

Call+

CheckPointHierarchy

Call

singleAccessPoint

Call

checkRequest

counterMeasure

Trigger Call

InternalEntities

SecureActions

access

counterMeasure

Trigger

SingleAccessPoint

Call checkRequest

Call

InternalEntities

SecureActions

access

22

Modelling design decisions:Behaviour

Codecharts





23

Security patterns: behaviourCheckPoint checks if msg conforms to the

policy.◦ If no, triggers a countermeasure◦ If yes, allows msg to proceed to the intended

recipientCountermeasure reacts to an access

violation when triggeredClient receives granted/denied access

message…


24

Modelling behaviour


Difficult to represent

global constraints

Limited abstraction

s

Limited tool

support in verification

Sequence

Diagrams

25

Modelling behaviour


Limited to FSAs

Problematic

integration

Statecharts

26

Modelling behaviour

W (CheckPoint.denyAccess Þ à CounterMeasure.triggered)

W (CheckPoint.denyAccess Þ Client.fail U Client.idle)

W (CheckPoint.grantAccess Þ (à Client.succeed) U Client.idle)

26 Check Point (Wassermann & Cheng 2003)

Availability

Temporal

Logic

27


• Automated verification• The TTP Toolkit





28

Check Point: implementationJava Authentication & Authorization Service

(JAAS)Java implementation of Pluggable

Authentication Module (PAM) ◦ Information security framework◦ Originally developed for Solaris operating system◦ Other implementations: PAMLinux

Used: Apache Web server◦ validate each HTTP request according to a

configured activation sequenceImplements the Check Point pattern

28

29

Security patterns: structureApparent similarity…

29

Check Point Pattern

JAAS

30

Enforcing structureAssignment of constants to variables

30 Check PointAssignme

nt

31

Enforcing structure: verification

31

Amnon H. Eden

Change to CP

32

Enforcing structure: automation

32 Check PointAssignme

nt

Result

33

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

35


verification

modelling

visualization

programming

design tier

Implementation tier





36

Forward, reverse, & round-trip

36 (Eden, Gasparis, Nicholson & Kazman, forthcoming)

design tier

Implementation tier

Forward Engineering

Reverse Engineering verification

modelling

visualization

programming

design tier

Implementation tier

37 37

Modelling: detaileddesign tier

Implementation tier

verification

modelling

visualization

programming

38

Implementation

38 Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

39

Modelling: abstract

39 Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

40

Code analysis

40 Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

41

Verification

41 Java 3D

Successful

design tier

Implementation tier

verification

modelling

visualization

programming

42

Modelling patterns

42 www.lepus.org.uk

design tier

Implementation tier

verification

modelling

visualization

programming

http://www.lepus.org.uk/

43

Verifying patterns

43 Factory Method in Java 3D

(structural conformance to)

Java 3D Implements

Factory Method

design tier

Implementation tier

verification

modelling

visualization

programming

44

Implementation: evolve

44

Carelesschange

design tier

Implementation tier

verification

modelling

visualization

programming

45

Verification (again)

45

design tier

Implementation tier

verification

modelling

visualization

programming

46

Visualization

46 Package java.util.logging

design tier

Implementation tier

verification

modelling

visualization

programming

47

Modelling: evolve

47

design tier

Implementation tier

verification

modelling

visualization

programming

48

<?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> </schema>

Modelling formats

48 Factory Method pattern

Symbolically

(Schema)

Visually(Codechart)

Textually(XML)

http://www.lepus.org.uk/templates/classz.xsd

49

Sidebar: Codecharts

50

DesiderataAutomatically verifiableModelling & visualizationFormal & practicalElegant & parsimoniousVisual & symbolicObject-orientedScalableGeneric

50 LePUS3 Vocabulary (Eden & Nicholson 2011)

Binary Relation & TOTAL Predicate

ISOMORPHIC Predicate

signatureVariable

SignatureSet

Variable

class Variable

Class Set

Variable

Hierarchy Variable HIERARCHY

SETVARIABLE

Unary Relation

si gnat ur eConst ant

Si gnat ur eSet

Const ant

cl ass Const ant

Cl ass Set

Const ant

Hi er ar chy Const ant

HI ERARCHY SET

CONSTANT

& ALL Predicate

51

Inspiration: blueprints

51

52 52 Check Point (Schumacher et al. 2006)

CheckPointHierarchy : HIERARCHYaccess, checkRequest : SIGNATURETrigger, SecureActions : P SIGNATUREsingleAccessPoint, counterMeasure : CLASSInternalEntities : P CLASSCall(accesssingleAccessPoint, checkRequestcheckPointHierarchy)Call(accesssingleAccessPoint, SecureActionsInternalEntities)…

CheckPoint2

counterMeasure

Trigger

SingleAccessPoint

CheckPointHierarchy

Call checkRequest

Call

InternalEntities

SecureActions

Call

accessCodecha

rt

Schema

Visual & symbolic

53

Parsimony“Each Scene Graph State class defines a factory method that creates and returns the respective Scene Graph Object”

53 Java 3D (Eden et al. 2013)

54

Scalability

54 Java 3D API

Inherit

sceneGr aphObj ect

Member

NodeHr c

Inherit

NodeComponentHr c

Create

Create

Produce

cr eat eRet ai ned

cr eat eRet ai ned

Inherit

Produce

Inherit

sceneGr aphObj ectSt at e

NodeComponentSt at eHr c

cr eat eNode

NodeSt at eHr c

cr eat eNode

sceneGr aphObj ect

Ret ai ned

Inherit

Member

Member

Inherit

NodeRet ai nedHr c

NodeComponentRet ai nedHr c

Ot herCl asses

OTHERHI ERARCHI ES

55

bean

Inherit

GeneratedFrom

Inherit

Inherit

Return

Inherit

j avax. ej b.EJ BObj ect

remoteInterface

Abstract

Abstract

BusinessMethods

EjbCreate

EjbPostCreate

BusinessMethods

j avax. ej b.EJ BHome

homeInterface

homeImp

J avax. ej b.BeanCl asses

Create

Abstract

CreateAbstract

Abstract Abstract

Inherit

CallCall

“Every bean [class] obtains an EJBContext object, which is a reference to the container

“The home interface extends the ...javax.ejb.EJBHome interface

“A home [interface] may have many create() methods, … , each of which must have corresponding ejbCreate() and ejbPostCreate() methods in the bean class. The number and datatype of the arguments of each create() are left up to the bean developer”

“When a create() method is invoked on the home interface, the container delegates the invocation to the corresponding ejbCreate() and ejbPostCreate() methods on the bean class

An implementation for the bean’s home interface is generated by the container.”

Genericity

55 (Monson-Haefel, 2001, Enterprise JavaBeans)

Implemented

User-defined

56

Formal methodA method is formal if it has a sound

mathematical basis which provides the means of precisely defining—◦ Specification◦ Implementation◦ correctness

A (formal) specification language: ◦ Set Syn (syntactic domain) ◦ Set Sem (semantic domain)◦ Relation Sat between them

56 (Guttag, Horning & Wing 1982; Wing 1990)

57

Definitions

57 (Wing 1990)

58

Definitions

58 (Eden & Nicholson 2011)

59

Semantics

59 (Eden & Nicholson 2011)

60

Sidebar:Visualization

61

Inspiration: maps

61 London, England

62

Visualization: Tools

62 (Ducasse & Lanza 2005; Story et al. 2002; Muller & Klashinski 1988)

Class Blueprints

SHriMP

Rigi

63

Visualization: ToolsMicrosoft Foundation Classes (Booch Notation)

63 (Odenthal & Quibeldey-Cirkel 1997)

64


64 Package java.util (Gasparis 2010)

JBuilder 7

65


65 Package Java3D 1.5 (Maniati 2008)

Fujaba Tool Suite 5

66


66 Package java.util (Gasparis 2010)

NetBeans 6.1

67


67 Package Java3D 1.5 (about 1,200 classes) (Maniati 2008)

NetBeans 6.1

68

Visualization: Toolkit

68 Package JGraph (Eden & Nicholson 2011)

69


69 Package java.io

73


73 Java Authentication & Authorization (JAAS)

74

Future directions

74

75

Runtime verificationEnforce behavioural design decisions

◦ Specified in LTL, Statecharts, sequence diagrams, …A.k.a. runtime monitoring Technique:

◦ Monitor program’s execution / read execution trace◦ Determine conformance to specifications◦ Violations trigger actions

Languages & tools◦ EAGLE (Barringer, Goldberg, Havelund & Sen 2003)◦ Parameterized RuleR (Barringer, Rydeheard & Havelund

2010)◦ PathExplorer (Havelund & Roşu 2001)◦ MOP (Chen & Roşu 2007)75

76

Thank you

verification

modelling

visualization

programming

design tier

Implementation tier

BibliographyCodecharts www.lepus.org.uk A.H. Eden, J. Nicholson. Codecharts: Roadmaps and

Blueprints for Object-Oriented Programs. Wiley-Blackwell, 2011

A.H. Eden, E. Gasparis, J. Nicholson, R. Kazman (2013). “Modeling and Visualizing Object-Oriented Programs with Codecharts”. Formal Methods in System Design, 43(1), 1–28

A.H. Eden, E. Gasparis, J. Nicholson. “LePUS3 and Class-Z Reference Manual”. University of Essex, Tech. Rep. CSM-474 (2007).

Toolkit www.ttp.essex.ac.uk A.H. Eden, E. Gasparis, J. Nicholson, R. Kazman.“Round-Trip

Engineering with the TTP Toolkit”. Forthcoming77

http://www.lepus.org.uk/

http://www.lepus.org.uk/ref/book/

http://www.lepus.org.uk/ref/book/

http://lepus.org.uk/ref/refman/refman.xml

http://www.ttp.essex.ac.uk/

BibliographyResearch project http://security.altoona.psu.edu/designguide J. Ryoo, R. Kazman, A.A.H. Alzahrani, A.H. Eden. “Designing

for Security Using Tactics, Patterns, and Automated Verification”, in preparation

Tactics Bass, L., Clements, P., & Kazman, R. (2012). Software

Architecture in Practice, 3rd ed. (3rd ed.). Addison-Wesley Professional.

J. Ryoo, R. Kazman, and P. Laplante, “Revising a Security Tactics Hierarchy through Decomposition, Reclassification, and Derivation”, The 6th Int’l Conf. Software Security & Reliability, Wash. D.C., 2012

Catalogues Schumacher, M., Fernandez-Buglioni, E., Hybertson, D.,

Buschmann, F., Sommerlad, P. (2006). Security Patterns: Integrating Security and Systems Engineering. Wiley

Wassermann, R., Cheng, B. H. C. (2003). “Security Patterns.” Presented at the Pattern Languages of Programs—PLoP 2003

78

http://security.altoona.psu.edu/designguide/

http://security.altoona.psu.edu/designguide/node/18

http://security.altoona.psu.edu/designguide/node/18

BibliographyRuntime verification Barringer, H., Goldberg, A., Havelund, K., & Sen, K. (2003).

Eagle monitors by collecting facts and generating obligations. Tec. Rep. CSPP-26, U. of Manchester, Dept. of Computer Science.

Barringer H, Rydeheard D, Havelund K. Rule systems for run-time monitoring: from EAGLE to RULER. J. of Logic & Comp. 2010, 20(3)

Havelund K, Roşu G. Monitoring java programs with java PathExplorer. ENTCS. 2001, 55(2)

Chen F, Roşu G. Mop: an efficient and generic runtime verification framework. SIGPLAN Not. 2007, 42(10)

Formal methods Guttag J., Horning J., Wing J. “Some Notes on Putting Formal

Specifications to Productive Use.” Science of Computer Programming 2, no. 1 (October 1982): 53–68.

Wing, Jeannette M. “A Specifier’s Introduction to Formal Methods.” Computer 23, no. 9 (1990): 8–23.

79

Security Pattern Assurance through Round-Trip Engineering

Documents