Security Pattern Assurance through Round-Trip Engineering
description
Transcript of 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
Round-trip engineering
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/
10
Modelling design decisions:Structure
Codecharts
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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
14 (Wasserman & Cheng 2003)
15
Modelling structure
15 Check Point (Wasserman & Cheng 2003)
Class Diagram
s
16
Modelling structure
16 Check Point (Wasserman & Cheng 2003)
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
17 Check Point (Wasserman & Cheng 2003)
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
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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…
23 Check Point (Wasserman & Cheng 2003)
24
Modelling behaviour
24 Check Point (Wasserman & Cheng 2003)
Difficult to represent
global constraints
Limited abstraction
s
Limited tool
support in verification
Sequence
Diagrams
25
Modelling behaviour
25 Check Point (Wasserman & Cheng 2003)
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
Enforcing design decisions
• Automated verification• The TTP Toolkit
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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
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
33 (Wasserman & Cheng 2003)
Manual
Manual
35
Round-trip engineering
verification
modelling
visualization
programming
design tier
Implementation tier
Making design decisions
Modelling design decisions
Enforcing design decisions
Round-trip engineering
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
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> <!--Generated using the TTP Toolkit on Tue Nov 27 17:42:25 GMT 2012--></schema>
Modelling formats
48 Factory Method pattern
Symbolically
(Schema)
Visually(Codechart)
Textually(XML)
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
Visualization: Tools
64 Package java.util (Gasparis 2010)
JBuilder 7
65
Visualization: Tools
65 Package Java3D 1.5 (Maniati 2008)
Fujaba Tool Suite 5
66
Visualization: Tools
66 Package java.util (Gasparis 2010)
NetBeans 6.1
67
Visualization: Tools
67 Package Java3D 1.5 (about 1,200 classes) (Maniati 2008)
NetBeans 6.1
68
Visualization: Toolkit
68 Package JGraph (Eden & Nicholson 2011)
69
Visualization: Toolkit
69 Package java.io
73
Visualization: Toolkit
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
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
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