1. 2 catalogues of security patterns record object-oriented design practices that have proved to...

1

Security Pattern

Assurance

through

Round-Trip EngineeringAmnon H. Eden

School of Computer Science & Electronic Engineering University of Essex

Cyberpatterns 2013, 9 July 2013, Abington, Oxfordshire

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 checking

We conclude with a round-trip software engineering tool supporting these activities

3

ContentsMaking design decisions

◦ From requirements to tactics to patternsModelling design decisions

◦ Structure: Codecharts◦ Behaviour: Temporal logic

Enforcing design decisions◦ Verification◦ Tool support

Round-trip engineering

4

ExampleRequirement: withstand attacks—————————————

1)Make design decision ◦ Tactics: Limit Exposure

◦ Pattern: Check Point

2)Model the decision◦ Structure: Codecharts)

◦ Behaviour: Temporal logic

3)Enforce the decision◦ Map pattern to implementation

◦ Verify with the Toolkit

singleAccessPoint

Access

securityPolicy

checkPolicy

Call

checkPoint

Call

triggerAction

Call

counterMeasure

TriggercheckRequest

1

2

3

5

Making design decisions

Requirements Tactics Patterns


Modelling design decisions

Enforcing design decisions


6

TacticsFine-grained design objectivesEach contributes to one quality attribute:

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

(Bass, Clements, Kazman 2012)

7 (Ryoo, Kazman & Laplante 2012)

Tactics hierarchy

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

ProjectSecurity Pattern

Assurance through Round-trip Engineering

LENS (Line-funded Exploratory New Starts)

Software Engineering Institute, Carnegie-Mellon University

$125K

Abdullah AlzahraniU of Essex

Rick KazmanSEI & U of Hawaii

Amnon H. EdenU of Essex

Gary ChastekSEI

Rob WojcikSEIJungwoo Ryoo

Penn State

10

Modelling design decisions:Structure

Codecharts





11

Security patternsCheck Point pattern

◦ Intent Intercepts and monitors all incoming requests Takes appropriate countermeasures in case of violations

◦ Participants CheckPoint Countermeasure SecurityPolicy

(Wasserman & Cheng 2003)

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

12

Security patterns: structureCheck Point pattern (cont.)

◦ CheckPoint checks 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


13

Modelling structure

Check Point (Wasserman & Cheng 2003)

Class Diagram

s

14

Modelling structure


2. What’s

this?

3. Is it class “CheckPoint”?

1. Which method calls

which?

Class Diagram

s

15

singleAccessPoint

securityPolicy

checkPolicy

Call

checkPoint

Callcheck

Request

counterMeasure

TriggerCall

InternalEntities

SecureActions

Call+

access

Modelling structure


Call(checkRequestcheckPoint,TriggercounterMeasure)

InternalEntities : P CLASS

counterMeasure : CLASS

checkPolicy : SIGNATURE

Trigger : P SIGNATURE

Codechart

17

Modelling structure (2)CheckPoint encapsulates the security policyMany policies Þ many CheckPoints

Check Point (Schumacher et al. 2006)

Common? Unique?One concrete

CP or many?

Class Diagram

s

18 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 (2)

19

Modelling structure (3)

JAAS

Java Authentication & Authorization Service (JAAS) Java implementation of Pluggable Authentication

Module (PAM) ◦ Information security framework◦ Other implementations: PAMLinux

Used: Apache Web server◦ validate each HTTP

request according to a configured activation sequence

Codechart

20

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)

securityPolicy

checkPolicy

checkPoint

Call

Call+

CheckPointHierarchy

Call

singleAccessPoint

Call

checkRequest

counterMeasure

TriggerCall

InternalEntities

SecureActions

access

counterMeasure

Trigger

SingleAccessPoint

Call checkRequest

Call

InternalEntities

SecureActions

access

21

Modelling design decisions:Behaviour

Codecharts





22

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…


23

Modelling behaviour


Difficult to represent

global constraints

Limited abstraction

s

Limited tool

support in verification

Sequence

Diagrams

24

Modelling behaviour


Limited to FSAs

Problematic

integration

Statecharts

25

Modelling behaviour

W (CheckPoint.denyAccess Þ à

CounterMeasure.triggered)

W (CheckPoint.denyAccess Þ Client.accessFail U

Client.idle)

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

Client.idle)Check Point (Wassermann & Cheng 2003)

Availability

Temporal

Logic

26


• Automated verification• The TTP Toolkit





27

Enforcing structure

Java 3D

Successful

28

Security patterns: structure

Apparent similarity…

Check Point Pattern

JAAS

29

Enforcing structure

Assignment of constants to variables

Check Point

Assignment

30

Enforcing structure: verificationHypothesis:

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!

Amnon H. Eden

Change to CP

31

Enforcing structure: automation

Check Point

Assignment

Result

32

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

34


verification

modelling

visualization

programming

design tier

Implementation tier





35

Forward, reverse, & round-trip

(Eden, Gasparis, Nicholson & Kazman, forthcoming)

design tier

Implementation tier

Forward Engineering

Reverse Engineering verification

modelling

visualization

programming

design tier

Implementation tier

36

Modelling: detailed

design tier

Implementation tier

verification

modelling

visualization

programming

37

Implementation

Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

38

Modelling: abstract

Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

39

Code analysis

Java 3D

design tier

Implementation tier

verification

modelling

visualization

programming

40

Verification

Java 3D

Successful

design tier

Implementation tier

verification

modelling

visualization

programming

41

Modelling patterns

www.lepus.org.uk

design tier

Implementation tier

verification

modelling

visualization

programming

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

42

Verifying patterns

Factory Method in Java 3D

(structural conformance to)

Java 3D Implements

Factory Method

design tier

Implementation tier

verification

modelling

visualization

programming

Map design to

implementation

43

Implementation: evolve

Carelesschange

design tier

Implementation tier

verification

modelling

visualization

programming

44

Verification (again)

design tier

Implementation tier

verification

modelling

visualization

programming

45

Visualization

Package java.util.logging

design tier

Implementation tier

verification

modelling

visualization

programming

46

Modelling: evolve

design tier

Implementation tier

verification

modelling

visualization

programming

47

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

Factory Method pattern

Symbolically

(Schema)

Visually(Codechart)

Textually(XML)

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

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

48

Sidebar: Codecharts

49

DesiderataAutomatically verifiableModelling & visualizationElegant & parsimoniousFormal & practicalVisual & symbolicObject-orientedScalableGeneric

LePUS3 Vocabulary (Eden & Nicholson 2011)

Binary Relation

& TOTAL Predicate

ISOMORPHIC

Predicate

signatureVariable

SignatureSet

Variable

class Variable

Class Set

Variable

Hierarchy Variable

HIERARCHY SET

VARIABLE

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

50

Inspiration: blueprints

51 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

52

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)

53

Scalability

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

54

“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 classAn implementation for the bean’s home interface is generated by the container.”

Genericity

(Monson-Haefel, 2001, Enterprise JavaBeans)

Constants

Variables

bean

Inherit

Generated

FromInherit

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

Call

Call

55

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

(Guttag, Horning & Wing 1982; Wing 1990)

56

DefinitionsSpecification DÎSyn

◦ A contract between designers and implementers

Specificand pÎSem◦ a program in a given programming language

Semantic abstraction function A◦ a homomorphism mapping programs into equivalence

classes

Abstract satisfies relation ASat◦ = » � …

Satisfies relation Sat Ì SemSyn◦ Formalizes: “p satisfies D” (“D is a specification of p”)

Sat(D,p) ASat(A(p),D)(Wing 1990)

57

Definitions (cont.)Specification DÎCodecharts

◦ A Codechart

Specificand pÎL◦ A (Java/C++/C#/…) program

Semantic abstraction function AL : L F*

◦ LÎ{JAVA, CPP, CSHARP, …}Abstract Satisfies relation

◦ (semantic entailment)

Satisfies relation:

Sat(D,p) AL(p)D

(Eden & Nicholson 2011)

58

Semantics A finite structure is a pair F=áU,Rñ

◦ U (the universe of F) a finite set of primitive entities

{int, Object, Object.clone(), Collection, MyClass. . .}

◦ R a finite set of (unary & binary) relations over U

{Class, Method, Signature, Inherit, Abstract, Call, . . .}

◦ : SignatureClass Method superimposition operator

Let F* stand for the domain of finite structures

F finite structure, D Codechart

F D iff:

1. Each atomic term t in D interprets to an entity t in F

2. Each term in the form sigcls (superimposition) in D interprets to an entity such that—

— If sigÎSignature, clsÎClass and there exists mthÎSignature s.t. ásig,mthñÎSignatureOf and ásig,clsñÎMember then sigclsmth

— If sig={s1,…sn}, clsÎClass then sigcls{s1cls,…sncls}

— If sig=Signature, clsÎ{c1,…cn} then sigcls{sigc1,… sigcn}

— …

3. For every formula f in D,

— If f is in the form tÎR then tÎR

— If f is in the form át1,t2ñÎR then át1,t2ñÎR

…

(Eden & Nicholson 2011)

59

Sidebar:Visualization

60

Inspiration: maps

London, England

61

Visualization: Tools

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

Class Blueprints

SHriMP

Rigi

62


Microsoft Foundation Classes (Booch Notation)

(Odenthal & Quibeldey-Cirkel 1997)

63


Package java.util (Gasparis 2010)

JBuilder 7

64


Package Java3D 1.5 (Maniati 2008)

Fujaba Tool Suite 5

65


Package java.util (Gasparis 2010)

NetBeans 6.1

66


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

NetBeans 6.1

67

Visualization: Toolkit

Package JGraph (Eden & Nicholson 2011)

68


Package java.io

72


Java Authentication & Authorization (JAAS)

73

Future directions

74

Enforcing behaviour: Runtime verification Enforce 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

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”. Forthcoming

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

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


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.

1. 2 catalogues of security patterns record object-oriented design practices that have proved to...

Documents

design decisions structure

design decision tactics

edudesignguide slide

check point wasserman

finegrained design objectives

security pattern assurance

requirements tactics

single access point