1
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
2

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
3
1
Requirement:
withstand attacks
—————————————
1)Make design decision
◦ Tactics: Limit Exposure
◦ Pattern: Check Point
2)Model the decision
◦ Structure: Codecharts)
◦ Behaviour: Temporal logic
singleAccess
Point
Access
checkPoint
Call
check
Request
trigger
Action
Call
counter
Measure
T rigger
Call
2
checkPolicy
security
Policy
3)Enforce the decision
◦ Map pattern to implementation
◦ Verify with the Toolkit
4
3
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
Requirements  Tactics  Patterns
5

Fine-grained design objectives

Each contributes to one quality attribute:
◦
◦
◦
◦
◦
◦
◦
6
Availability
Interoperability
Modifiability
Performance
Security
Testability
Usability
(Bass, Clements, Kazman 2012)
7
(Ryoo, Kazman & Laplante 2012)

Tactics

Patterns:
◦ Single Access Point, Check Point, Roles, Session, Full
View with Errors, Limited View, Security Access Layer,
Intercepting Validator, Secure Logger, …
8
http://security.altoona.psu.edu/designguide/

Rick Kazman
SEI & U of Hawaii

LENS (Line-funded Exploratory
New Starts)

Software Engineering Institute,
Carnegie-Mellon University
Jungwoo Ryoo
Penn State

Amnon H. Eden
U of Essex
9
Security Pattern Assurance
through
Round-trip Engineering
Abdullah
Alzahrani
U of Essex
Rob Wojcik
SEI
$125K
Gary Chastek
SEI
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
Codecharts
10

Check Point pattern
◦ Intent
 Intercepts and monitors all incoming requests
 Takes appropriate countermeasures in case of violations
◦ Participants
 CheckPoint
 Countermeasure
 SecurityPolicy
11
(Wasserman & Cheng 2003)
(Schumacher, Fernandez-Buglioni,
Hybertson, Buschmann, Sommerlad
2006)

Check 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
12
(Wasserman & Cheng 2003)
Class
Diagrams
13
Check Point (Wasserman & Cheng 2003)
Class
Diagrams
1. Which method
calls which?
3. Is it class
“CheckPoint”?
2. What’s
this?
14
Check Point (Wasserman & Cheng 2003)
Codechart
Call(checkRequestcheckPoint,TriggercounterMeasure)
singleAccess
Point
access
counterMeasure :
CLASS
Call
counter
Measure
checkPoint
T rigger
Call
check
Request
Call +
Trigger : P SIGNATURE
I nternal
Entities
Call
check
Policy
security
Policy
checkPolicy : SIGNATURE
Secure
Actions
InternalEntities : P CLASS
15
Check Point (Wasserman & Cheng 2003)

CheckPoint encapsulates the security policy

Many policies Þ many CheckPoints
One concrete
CP or many?
17
Check Point (Schumacher et al. 2006)
Class
Diagrams
Common?
Unique?
SingleAccess
Point
access
Call
Codechar
t
counter
Measure
T rigger
Schem
a
CheckPointHierarchy : HIERARCHY
Call
check
Request
CheckPoint
Hierarchy
CheckPoint2
CheckPointHierarchy : HIERARCHY
I nternal
Entities
access, checkRequest : SIGNATURE
Trigger, SecureActions : P SIGNATURE
singleAccessPoint, counterMeasure : CLASS
InternalEntities : P CLASS
Call(accesssingleAccessPoint,
checkRequestcheckPointHierarchy)
Call(accesssingleAccessPoint, SecureActionsInternalEntities)
…
18
Check Point (Schumacher et al. 2006)
Secure
Actions
Call

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
19
JAAS
Codechar
t

Methods, sets, signatures

Precise criterion of correctness
◦ Communication; verification; automation, …

Variations become evident
singleAccess
Point
access
SingleAccess
Point
access
Call
Call
counter
Measure
checkP oint
T rigger
Call
check
Request
C all
check
P olicy
C all+
I nternal
Entities
20
Secure
Actions
Check Point (Wasserman et. al 2003)
secur ity
P olicy
counter
Measure
T rigger
Call
check
Request
C all
C heckP oint
H ier ar chy
I nternal
Entities
Secure
Actions
Check Point (Schumacher et al. 2006)
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
Codecharts
21

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

…
22
Check Point (Wasserman & Cheng 2003)
Sequenc
e
Diagrams
Limited
abstractions
Difficult to
represent global
constraints
Limited tool
support in
verification
23
Check Point (Wasserman & Cheng 2003)
Statecharts
Limited
to FSAs
Problematic
integration
24
Check Point (Wasserman & Cheng 2003)
Temporal
Logic
W (CheckPoint.denyAccess   CounterMeasure.triggered)
W (CheckPoint.denyAccess  Client.accessFail U Client.idle)
W (CheckPoint.grantAccess  ( Client.succeed) U Client.idle)
Availability
25
Check Point (Wassermann & Cheng 2003)
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
•
Automated verification
• The TTP Toolkit
26
Successf
ul
27
Java 3D
Apparent
similarity…
Check Point
Pattern
JAAS
28
Assignment of
constants to
variables
29
Assignment
Check Point

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
Result
31
Assignment
Check Point

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
32
(Wasserman & Cheng 2003)
Making design decisions
design tier
Modelling design decisions
Enforcing design decisions
modelling
Round-trip engineering
verification
visualization
programming
Implementation tier
34
design tier
design tier
modelling
Forward
Engineering
Reverse
Engineering
verification
programming
Implementation tier
35
Implementation tier
(Eden, Gasparis, Nicholson & Kazman, forthcoming)
visualization
design tier
modelling
verification
programming
Implementation tier
36
visualization
design tier
modelling
verification
programming
Implementation tier
37
Java 3D
visualization
design tier
modelling
verification
programming
Implementation tier
38
Java 3D
visualization
design tier
modelling
verification
programming
Implementation tier
39
Java 3D
visualization
design tier
modelling
verification
programming
Implementation tier
Successf
ul
40
Java 3D
visualization
design tier
modelling
verification
programming
Implementation tier
41
www.lepus.org.uk
visualization
design tier
(structural conformance to)
modelling
verification
visualization
programming
Map design to
implementation
42
Factory Method in Java 3D
Implementation tier
Java 3D
Implements
Factory Method
design tier
modelling
verification
programming
Implementation tier
Careless
change
43
visualization
design tier
modelling
verification
programming
Implementation tier
44
visualization
design tier
modelling
verification
programming
Implementation tier
45
Package java.util.logging
visualization
design tier
modelling
verification
programming
Implementation tier
46
visualization
<?xml version=”1.0” encoding=”ISO-8859-1”?>
<?xml-stylesheet type="text/xsl"
Textually(
href="http://www.lepus.org.uk/templates/classz.xsl"?>
<schema xmlns="http://www.lepus.org.uk/classz"
XML)
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" />
Symbolically
<type value="SIGNATURE" exponent="0" />
(Schema)
</declare>
</declarations>
<formulas>
<formula>
value="Isomorphic" />
Factory
Method
pattern
47 <predicatesymbol
<relationsymbol value="Produce" transitive="false" />
Visually
(Codechart)
48

Automatically verifiable

Modelling & visualization

Elegant & parsimonious

Formal & practical

Visual & symbolic

Object-oriented

Scalable

Generic
49
Unary Relation
& A LL
Predicate
Binary Relation
& T OT AL Predicate
I SOMORPHI C
Predicate
s i gnat ur e
Cons t ant
Si gnat ur e
Set
Cons t ant
c l as s
Cons t ant
Cl as s
Set
Cons t ant
Hi er ar c hy
Cons t ant
signature
Variable
Signature
Set
Variable
class
Variable
Class
Set
Variable
Hierarchy
Variable
HI ERARCHY
SET
CONSTANT
HI ERARCHY
SET
VARI ABLE
LePUS3 Vocabulary (Eden & Nicholson 2011)
50
SingleAccess
Point
access
Codechar
t
Call
counter
Measure
T rigger
Schem
a
Call
check
Request
CheckPoint
Hierarchy
CheckPoint2
CheckPointHierarchy : HIERARCHY
I nternal
Entities
access, checkRequest : SIGNATURE
Trigger, SecureActions : P SIGNATURE
singleAccessPoint, counterMeasure : CLASS
InternalEntities : P CLASS
Call(accesssingleAccessPoint,
checkRequestcheckPointHierarchy)
Call(accesssingleAccessPoint, SecureActionsInternalEntities)
…
51
Check Point (Schumacher et al. 2006)
Secure
Actions
Call
“Each Scene Graph
State class defines a
factory method that
creates and returns the
respective Scene Graph
Object”
52
Java 3D (Eden et al. 2013)
s c eneGr aph
Obj ec t
St at e
Member
I nherit
Member
s c eneGr aph
Obj ec t
Member
I nherit
I nherit
c r eat e
Node
Produce
NodeSt at e
Hr c
NodeComponent
St at eHr c
53
c r eat e
Ret ai ned
Java 3D API
I nherit
Create
NodeRet ai ned
Hr c
Produce
Ot her
Cl as s es
I nherit
I nherit
Node
Hr c
c r eat e
Node
s c eneGr aph
Obj ec t
Ret ai ned
c r eat e
Ret ai ned
NodeComponent
Hr c
Create
NodeComponent
Ret ai nedHr c
OTHER
HI ERARCHI ES
Constants
A bstract
A bstract
j av ax . ej b.
EJ BHome
j av ax . ej b.
EJ BObj ec t
I nherit
I nherit
A bstract
home
I nterface
From
J av ax . ej b.
BeanCl as s es
A bstract
A bstract
Create
Generated
A bstract
I nherit
home
I mp
Create
remote
I nterface
Business
Methods
I nherit
I nherit
Return
Ejb
Create
bean
EjbPost
Create
Business
Methods
Call
Call
Variables
54
(Monson-Haefel, 2001, Enterprise JavaBeans)
“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.”

A 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
55
(Guttag, Horning & Wing 1982; Wing 1990)

Specification 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  Sem×Syn
◦ Formalizes: “p satisfies D” (“D is a specification of p”)
Sat(D,p) ≝ ASat(A(p),D)
56
(Wing 1990)

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
57
(Eden & Nicholson 2011)

A finite structure is a pair F=áU,Rñ
◦
U (the universe of F) a finite set of primitive entities

◦
R a finite set of (unary & binary) relations over U

◦
{ int, Object, Object.clone(), Collection, MyClass. . . }
{ Class, Method, Signature, Inherit, Abstract, Call, . . . }
: Signature×Class ↛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 sig cls (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 sig cls≝mth
— If sig={s1,…sn}, clsÎClass then sig cls≝{s1 cls,…sn cls}
— If sig=Signature, clsÎ{c1,…cn} then sig cls≝{sig c1,… sig cn}
—…
3. For every formula f in D,
— If f is in the form tÎR then tÎR
58
— If f is in the form át1,t2ñÎR then át1,t2ñÎR
…
(Eden & Nicholson 2011)
59
60
London, England
SHriMP
Class Blueprints
Rigi
61
(Ducasse & Lanza 2005; Story et al. 2002; Muller & Klashinski 1988)
Microsoft
Foundation
Classes
(Booch Notation)
62
(Odenthal & Quibeldey-Cirkel 1997)
JBuilder
7
63
Package java.util (Gasparis 2010)
Fujaba Tool
Suite 5
64
Package Java3D 1.5 (Maniati 2008)
NetBean
s 6.1
65
Package java.util (Gasparis 2010)
NetBean
s 6.1
66
Package Java3D 1.5 (about 1,200 classes) (Maniati 2008)
67
Package JGraph (Eden & Nicholson 2011)
68
Package java.io
72
Java Authentication & Authorization (JAAS)
73

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)
74
design tier
modelling
verification
visualization
programming
Implementation tier
75
Codecharts

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
Research 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
Runtime 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.