Security patterns and model driven architecture

Security Patterns
and
Model Driven Architecture
UC San Diego
CSE 294
Fall Quarter 2006
Barry Demchak

Papers to Review
 Using Security Patterns to Model and Analyze
Security Requirements (Betty Cheng et al, Michigan
State University) [~2000]
 A Study of Security Architecture Patterns
(Rosado et al, University of Castilla-La Mancha) [2006]
 Integration of Security Patterns in Software
Models based on Semantic Descriptions (Diego
Ray, University of Malaga) [2003]

The Big Problem
 Security requirements and solutions
 “The application should do blah-blah, blah-blah,
and blah-blah. It should do them like this: blah-
blah-blah.”
 And it should be fast, reliable, and secure.
 Security is a value, not an engineering goal
 Security is a non-functional requirement
 Irregular and haphazard application of
security measures leads to insecure systems

Evidence of the Problem
 “Thousands of Brits fall victim to data theft”
-- October 10, 2006 New York Times
 “Medicare and Medicaid Security Gaps Are
Found”
 “U.S. and Europe Agree on Passenger Data”
 Is AJAX secure?
-- October, 2006 SQL Magazine

Preview – the Players and their Parts
 Cheng – Pattern definition
 Rosado – Pattern enumeration and
evaluation
 Ray – Future directions

Patterns
 Patterns are a tool for managing complexity
 Describe technical solutions in context of business
problems
 Patterns are prescriptive – tell you what to do
 Each pattern represents a decision that must be made
and considerations that go into that decision
 Patterns facilitate communication
 Form common vocabulary among experts and non-
experts
 Patterns are a tool to capture expertise
 Patterns can increase the degree of corporate
knowledge capture and transfer

What is a Pattern?
A pattern for software architecture describes a
particular recurring design problem that arises
in specific design contexts, and presents a
well-proven generic scheme for its solution.
The solution scheme is specified by
describing its constituent components, their
responsibilities and relationships, and the
ways in which they collaborate.
[POSA96]

MVC
 Context & Problem
 Application data needs to be maintained and
presented via the user interface
 Multiple different output formats need to be supported
 Multiple different forms of input need to be supported
 How to establish consistency?

MVC
 Solution:
 Introduce separate components for storing and
processing of data (model), data presentation (view),
and for handling input (controller)
 The model represents the functional core; it registers
dependent components (views and controllers) and
notifies them about data changes
 The view retrieves data from the model and displays it
 The controller translates user input into events for the
model; it may also change the UI to mirror data
changes

MVC: Example
0
20
40
60
80
100
120
140
160
180
200
a b c
Series1
a
b
c
a b c
60 30 10
50 30 20
80 10 10
a = 63%
b = 23%
c = 14%
Model
View
Controller
adapted from [M05]

MVC
 Structure:
Model
AbstractSource
Attach(Observer)
Detach(Observer)
Notify()
GetState()
SetState()
service()
state
AbstractObserver
Update()
View
Update()
Display()
Initialize()
observers
*
model
1
Controller
Update()
HandleInput()
Initialize()

 Behavior:
MVC
:View:Model:Controller
Service()
Update()
HandleInput()
Notify()
GetState()
Display()
Update()
GetState()

 Consequences:
 Decoupling of application data from
presentation and input mechanism
 Consistency of user interface and underlying
data model
 Increase of structural and dynamic complexity
 Potential loss of performance
MVC

Pattern Information
 Analysis patterns [Fowler: Analysis Patterns]
 Design patterns [Gamma et al: Design
Patterns]
 Specification patterns [Dwyer et al: 2nd
Workshop on Formal Methods in Software
Engineering (1998)]

Cheng’s Approach – The Problem
 Security patterns lack comprehensive
structure that conveys essential information
essential to security engineering
 Security cannot be verified

The Solution
 Investigate alternate templates for security
patterns
 Enable verification of requirements by adding
formal constraints to patterns

Security Patterns
 Capture and convey information to facilitate
“security engineering”
 “Security” is subjective and environment-
dependent
 Extending normal patterns to security comes
up short: behavior, security constraints, etc
 Check essential security properties

Objectives
 Communication of security-specific
knowledge in context of concrete application
 Verification using UML formalization
framework (Hydra) -> Promela (SPIN) ->
Minerva

Design Patterns – a launching point
 Pattern Name and Classification
 Intent
 Also Known As
 Motivation
 Applicability – altered
 Consequences - altered
 Structure
 Participants
 Collaborations

Changed Fields
 Applicability – added application-level, host-
level, or network-level security
 Consequences – added set of consequences:
accountability, confidentiality, integrity,
availability, performance, cost, manageability,
usability

New Fields
 Behavior – illustrate behavior and interaction
using UML state and sequence diagrams
 Constraints – global conditions that have to
apply
 Related Security Patterns – how it relates to
other security patterns
 Supported Security Principles – how it relates
to each of the ten principles identified by
Viega and McGraw

Viega and McGraw Principles (aside)
1. Secure weakest link
2. Practice defense in depth
3. Fail securely
4. Principle of least privilege
5. Compartmentalize
6. Keep it simple
7. Promote privacy
8. Hiding secrets is hard
9. Be reluctant to trust
10. Use community resources

Patterns, Classifications & Principles

Process for Using Security Patterns

Example – Faulty UML State Diagram

Example - eBiz
 Requirement: Unauthorized access to system
should not be possible, and it triggers a
counter-measure

Analysis of Security Properties
 Checked Authorization, Check Point, and
Single Access Point
 Instantiated constraints using LTL -> SPIN
 Iteratively verified/improved – errors
visualized using Minerva as UML showing
counterexamples

Checkpoint Properties
 CHK1 – unauthorized access leads to counter-
measure: □(p→(◊q))
 (CP.grantaccess == 2)→(CM.triggered == 1)
 CHK2 – integrity or confidentiality are
uncompromised after denial: □(p→(qUr))
 (CP.grantaccess == 2) →((ERG.success == 0) U
(ERG.waiting == 0)
 CHK3 – granted access leads to notify: □(p→(◊q)Ur)
 (CP.grantaccess == 1) →((ERG.success == 1) U
(ERG.waiting == 0)

Cheng Summary
 Proposed revised template for security
 Combine previous UML formalizations with
security patterns to produce rigorous analysis
 Result: Reduction of error-prone post-design
security modifications

Cheng Futures
 Incorporate security beliefs into templates
 Investigate how application domain affects
security patterns
 Use of timing information in specifying
security patterns

Rosado’s Approach -- The Problem
 Unsecure systems are everywhere, and are
especially acute with connected systems
 Security should be considered at all stages of
system design and at all architectural levels
 There is no comprehensive methodology for
designing security-sensitive systems
 Requirements difficult to model
 Secure development expertise is rare

The Solution
 Security patterns encapsulate accumulated
knowledge of secure systems design
 Can be understood and used by non-security
professionals
 Degree of security in a pattern can be
measured

The Security Pattern Template
 Intent
 Context
 Problem
 Description
 Solution
 Consequences
 Known Uses
 Related Patterns

The Security Pattern Template
(vs Cheng et al)
 Intent
 Context
 Problem
 Description
 Solution
 Consequences
 Known Uses
 Related Patterns
 Also known as
 Structure
 Participants
 Collaborations
 Supported security
principles

Patterns Presented
 Authorization
 Role-Based Access Control
 Multi-level Security
 Reference Monitor
 Virtual Address Space Access Control
 Execution Domain
 Single Access Point
 Check Point
 Session

Patterns Presented
Authorization
Role-Based Access Control
Multi-level Security
 Reference Monitor
 Virtual Address Space Access Control
 Execution Domain
Single Access Point
Check Point
Session Limited View
Full View with Errors

Authorization Pattern
 Intent: Who is authorized to access resource
 Context: Active entities request resources
whose access must be controlled
 Problem: Access to secure objects needs to
be explicitly protected

Authorization Pattern – cont’d
 Description: distinguish between active
entities (subjects) and passive resources
(protection objects)
 Solution: Subject class, Object class, Rights
class, and the relationship between them

 Consequences
 Solution is independent of resources to be protected
 Subjects: processes, users, roles, groups
 Objects: transactions, memory, devices, files …
 Access: reading, writing, execution, methods

 Known uses: access control in Unix,
Windows, Oracle
 Related patterns: RBAC is a specialization

Role-Based Access Control Pattern
 Intent: Control access based on role
 Context: Access based on job or task
 Solution: Extends Authorization so users are
assigned roles, and roles have rights

Multilevel Security Pattern
 Intent: Access under multiple levels of security class
 Solution: Each subject ∈ some class, each resource ∈ some
class, instances used to add levels of security
 Consequences: Facilitates admin work for classification,
maintenance of classification can be costly

Reference Monitor Pattern
 Intent: All authorizations are fulfilled when process needs
resource
 Context: Multiprocess environment petitioning resources
 Consequences: If all petitions are intercepted, rules can be
observed. Implementation depends on resource, and
performance suffers

Virtual Address Space Access Control Pattern
 Intent: Control access by processes to specific memory using
predefined access types
 Context: Processes must share memory in controlled way;
each process executes in own address space
 Solution: Divide memory into segments, assign descriptors and
allowed access types

Execution Domain Pattern
 Intent: Define process environment indicating accessible
resources the resource access privileges
 Problem: Restrict process to use specific resources to prevent
destruction that could interfere with other processes
 Consequences: Resource mapped into address space, domain
implementation not restricted, complex and needs hardware

Session Pattern
 Intent: Provide environment where user rights can be restricted
and controlled
 Description: Repository for global information access
 Consequences: Session has privileges necessary to perform
task, but insufficient to cause collateral damage

Single Access Point Pattern
 Intent: Simple interface for communications with external
entities
 Solution: Single point of control (mediator) can coordinate
policy implementation through Check Point pattern
 Consequences: Can capture information, carry out
authorization, and prevent undesirable data modification

Check Point Pattern
 Intent: Check requests and take countermeasures
 Solution: Analyze requests and messages, combines with
Single Access Point pattern, applies current security policy
 Consequences: Benefits confidentiality if operating properly
and attacks can be detected. Complex checking slows system.

Rosado’s Futures
 Define method to specify flexible security
architectures that can be easily adapted to
systems with different security requirements
 Guarantee security using security patterns

Ray’s Approach – The Problem
 Security and reliability not considered during
initial stages of software development
 Not part of standard procedures in
development or maintenance of software

The Solution
 Create framework for semantic description
and management of security properties and
patterns
 Given security requirements, define
mechanisms to automate analysis of security-
enhanced models
 Define mechanism to guarantee that
subsequent changes preserve security
properties and patterns

Security Awareness
 25 Years Ago: What is Security??
 15 Years Ago: Security is a value-added
service
 Lately: Security must be built in

Development Processes
 Security requirements are often identified
independently for each system component
 Interdependencies are poorly understood
 Big trouble
 Pervasive computing
 Ambient intelligence
 Mobile services
 Deploy isolated countermeasures (PKI, IDS, firewalls,
symmetric encryption, etc)
 No development process identifies security
requirements apriori

The Causes
 Security is a non-functional requirement
 Security is both technical and social
 Developers often lack background or interest
in security
 No consistent way of representing security at
different levels of software description

Add-on Security
 Usually a point solution
 Different implementations of the add-on
security cannot be compared (as to security
properties)
 Security mechanisms not congruent with
system security requirements

Where Are We Now?
 UML-based
 Business process engineering
 SecureUML integrates role-based access
control policies into model-driven software
development process
 UMLsec proposes extending UML for security
modeling, but addresses only a few security
issues
 Integrate UML into Tropos (ERP) methodology

More UML …
 Use cases can describe special scenarios, but abuse
cases are more instructive
 UML Precise Group (PUML) investigating improving
semantics
 SEMPER (Secure Electronic Marketplace in Europe)
studying e-commerce frameworks
 COPS (Commercial Protocols and Services) studying
infrastructure for market transactions
 CASENET design and analysis of security protocols
studying requirements specification during application
development

Where Next?
 Use of formal methods in software
engineering process
 Develop formally proven solutions
 Assist software engineers regarding gathering
security requirements, integrating proven
solutions, and validating against requirements

Integrated Security Engineering
 Security solution
 Adaptation to
context
 Analysis of
consequences
 Coherence

Semantic Modeling
 Security protocol as a series of semantic properties
to be fulfilled
 Level of security: confidential
 Authentication is needed
 … etc
 Enables
 Semantic categorization of patterns and libraries
 Fitting patterns and libraries to context
 Ferret out unhealthy interactions
 Validate correctness of new patterns

Comparison of Approaches
 Cheng et al
 Improvement of attribute classifications of security
patterns
 UML + security patterns = rigorous analysis
 Rosado
 Exposing security patterns for common use
 Classifying characteristics of security patterns
 Ray
 Semantic description of security patterns
 Full development cycle supported by automation
 Guarantee that protocols are maintained across
development cycle

Other Threads
 Dr. Dobbs Journal
 Scott Ambler on difficulty of marrying agile
with security
 Microsoft Systems Journal
 November edition has 6 major stories
 Threat modeling
 Extending SDL – Documenting and Evaluating
the Security Guarantees of Your Apps

Bottom Line
 Are today’s security patterns sufficient to
guarantee secure systems?
 Is security a cross-cutting issue?
 How do we create secure-by-architecture
designs?
“For interesting research, head towards chaos”
– Ingolf Krueger, 2005

Security patterns and model driven architecture

More Related Content

What's hot

Viewers also liked

Similar to Security patterns and model driven architecture

More from bdemchak

Recently uploaded

Security patterns and model driven architecture

Editor's Notes