Upload
arielle-holyfield
View
215
Download
2
Tags:
Embed Size (px)
Citation preview
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
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
6
TacticsFine-grained design objectivesEach contributes to one quality attribute:
◦ Availability◦ Interoperability◦ Modifiability◦ Performance◦ Security◦ Testability◦ Usability
(Bass, Clements, Kazman 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
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
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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
(Wasserman & Cheng 2003)
14
Modelling structure
Check Point (Wasserman & Cheng 2003)
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
Check Point (Wasserman & Cheng 2003)
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
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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…
Check Point (Wasserman & Cheng 2003)
23
Modelling behaviour
Check Point (Wasserman & Cheng 2003)
Difficult to represent
global constraints
Limited abstraction
s
Limited tool
support in verification
Sequence
Diagrams
24
Modelling behaviour
Check Point (Wasserman & Cheng 2003)
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
Enforcing design decisions
• Automated verification• The TTP Toolkit
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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!
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
(Wasserman & Cheng 2003)
Manual
Manual
34
Round-trip engineering
verification
modelling
visualization
programming
design tier
Implementation tier
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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
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> <!--Generated using the TTP Toolkit on Tue Nov 27 17:42:25 GMT 2012--></schema>
Modelling formats
Factory Method pattern
Symbolically
(Schema)
Visually(Codechart)
Textually(XML)
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
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)
61
Visualization: Tools
(Ducasse & Lanza 2005; Story et al. 2002; Muller & Klashinski 1988)
Class Blueprints
SHriMP
Rigi
62
Visualization: Tools
Microsoft Foundation Classes (Booch Notation)
(Odenthal & Quibeldey-Cirkel 1997)
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)
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
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
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.