CS294, Yelick Consensus revisited, p1 CS 294-8 Consensus Revisited yelick/294.
The Beginning. Security Patterns and Model Driven Architecture UC San Diego CSE 294 Fall Quarter...
-
Upload
anis-underwood -
Category
Documents
-
view
213 -
download
0
Transcript of The Beginning. Security Patterns and Model Driven Architecture UC San Diego CSE 294 Fall Quarter...
The Beginning
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 ExplorerFederatedSignons
DataViruses and
Spyware
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
Series1a
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
AbstractSourceAttach(Observer
)Detach(Observe
r)Notify()
GetState()SetState()
service()
state
AbstractObserver
Update()
View
Update()
Display()
Initialize()
observers
*
model
1Controller
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
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
Authorization Pattern – cont’d
Consequences Solution is independent of resources to be protected Subjects: processes, users, roles, groups Objects: transactions, memory, devices, files … Access: reading, writing, execution, methods
Authorization Pattern – cont’d
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