security patterns and model driven architecture

The Beginning

Security Patterns and

Model Driven Architecture

UC San DiegoCSE 294

Fall Quarter 2006Barry 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”-- October 8, 2006 New York Times

“U.S. and Europe Agree on Passenger Data”-- October 6, 2006 New York Times

Is AJAX secure?-- October, 2006 SQL Magazine

The Context

Secure Servers

Firewall

EncryptionStrong

PasswordsTheoremProvers

Internet Explorer FederatedSignons

DataViruses andSpyware

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

02040

6080

100

120140160180200

a b c

Series1abc

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

AbstractSourceAttach(Observer

)Detach(Observe

r)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 link2. Practice defense in depth3. Fail securely4. Principle of least privilege5. Compartmentalize6. Keep it simple7. Promote privacy8. Hiding secrets is hard9. Be reluctant to trust10. 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

Example - eBiz

Example – eBiz

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)

UML for Check Point Pattern

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

AuthorizationRole-Based Access ControlMulti-level Security

Reference Monitor Virtual Address Space Access Control Execution Domain

Single Access PointCheck PointSession 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.

Comparing Security Criteria

Comparing Performance

Comparing Cost and Security

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

Where Next?

Basic Boehm Spiral Model

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

Automated Tools Support

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

The Beginning