Automated Verification of UMLsec Models for … · of UMLsec Models for Security Requirements ......

Automated Verification

of UMLsec Models for Security RequirementsJan Jürjens and Pasha Shabalin

Software & Systems Engineering

TU Munich, Germany

[email protected]

http://www.jurjens.de/jan

Jan Jürjens, TU Munich: Automated Verification of UMLsec Models 2

Secure Systems Development

High quality development of security-

critical systems is difficult.

Many systems developed, deployed,

used that do not satisfy their criticality

requirements, sometimes with

spectacular attacks.


Quality vs. Cost

Correctness in conflict with cost.

Thorough methods of system design

not used if too expensive.


Towards Solution

Increase quality with bounded

investment in time, costs. Idea:

• Extract models from artefacts arising in industrial

development and use of critical systems (UML

models, source code, configuration data).

• Tool-supported theoretically sound efficient

automated critical analysis.

�Model-based Security Engineering


Model-based Development

Requirements

Models

Code

Verify

Codegen. Testgen.

Combined strategy:

• Verify models againstrequirements

• Generate code frommodels wherereasonable

• Write code and generate test-sequences otherwise.


The UMLsec Profile [Jur02]

Recurring security requirements, adversaryscenarios, concepts offered as stereotypes with tags on component-level.

Use associated constraints to evaluatespecifications and indicate possibleweaknesses.

Ensures that UML specification providesdesired level of critical requirements.

Link to code via test-sequence generation.

Challenge: Automated verification !


Tool-support: Pragmatics

Commercial modelling tools: so far mainly

syntactic checks and code-generation.

Goal: sophisticated analysis. Solution:

• Draw UML models with editor.

• Save UML models as XMI (XML dialect).

• Connect to verification tools (automated

theorem prover, model-checker …), e.g.

using XMI Data Binding.


UML Processing

M D RM O F

[U M L 1 .4 ] U M L 1 .4

M y U m l

M y A p p

3 : ge n e ra te

J M I

1 : 0 1 -0 2 -1 5 .x m l (U M L 1 .4 M e ta m o d e l)

2 : in s ta n tia te

4 : M yU m l.x m i


CSDUML Framework: Features

Framework for analysis plug-ins to access UML models on conceptual level over various UI’s.

Exposes a set of commands. Has internal state(preserved between command calls).

Framework and analysis tools accessible and available at http://www4.in.tum.de/~umlsec .

Upload UML model (as .xmi file) on website. Analyse model for included criticalrequirements. Download report and UML model with highlighted weaknesses.


Usage


Tool Interfaces


Exposing Commands

callgetCommands

collectparameters

callexecuteCommand

systemchange

Frameworkcall

Initialise

Tool can createthe command list


Formal semantics for UML

Diagrams in context (using subsystems).

Model actions and internal activities explicitly.

Message exchange between objects orcomponents (incl. event dispatching).

For UMLsec: include adversary model arisingfrom threat scenario in deployment diagram.

Use Abstract State Machines (pseudo-code; extending [BorCavRic00]).


Automated Security Analysis

Following Dolev, Yao (1982): To analyze system, verify against attacker model from threat scenarios in deployment diagrams who

• may participate in some protocol runs,

• knows some data in advance,

• may intercept messages on some links,

• injects messages that it can produce in some links

• may access certain nodes.


Cryptographic Expressions

Exp: term algebra generated by Var Keys Data and

• _ :: _ (concatenation) and empty expression ℇ,

• { _ } _ (encryption)

• Dec ( ) (decryption)

• Sign ( ) (signing)

• Ext_( ) (extracting from signature)

• Hash( _ ) (hashing)

by factoring out the equations and

(for K Keys).

U U

∈


Adversary: Example Scenario

A BAdversary

m(x)

Adversary

knowledge:k-1, y,

m(x)

x

return({z}k)

[argb,1,1 = x]

{z}k, z

return({y::x}z)


Translation to Model-Checker

Spin (Holzmann): automated verification of finite-state reactive systems given as statetransition systems (Promela code) againstproperties in Linear Time Logic (LTL).

For complex cryptographic data types: usedynamic types (defined by building type graphfrom diagram).

Behavioral specification, adversary modeltranslated to Promela, security requirement to Never-claim.


Example

Variant of TLS

(SSL) proposed

at IEEE Infocom

1999.

Goal: send secret

protected by

session key using

fewer server

resources.

≪datasecurity≫

{secrecy=s}

{adversary=default}

≪Internet≫


Man-in-the-Middle Attack


Applications

Common Electronic Purse SpecificationSecurity architecture for German bankBiometric authentication protocol for German

TelekomAnalysis of SAP access control configurations

for German bankTelematic automobile emergency application of

German car companyElectronic signature architecture of German

insurance companyElectronic purse for Oktoberfest


Conclusions

Tool-supported Model-based Security

Engineering using UML:• formally based approach to secure

software engineering

• automated tool support• integrated approach (source-code,

configuration data)

• increase quality with bounded costs, time-to-market.


Resources

Jan Jürjens, Secure Systems Deve-lopment with UML, Springer 04

Tutorials: Nov.: SISBD (Malaga), ISSRE (Rennes).

Spring School: May 2005, Carlos IV Univ.Madrid

Workshops: WITS05@POPL05, CSDUML05

More information (papers, slides, tool etc.): http://www.umlsec.org


Challenge

Advanced tool support. For example:• consistency checks

• mechanical analysis of complicated

requirements on model level (bindings to model-checkers, constraint solvers,

automated theorem provers, …)• code generation

• test-sequence generation• configuration data analysis against UML.


Implementing Tools

• Define the set of commands

– have parameters

• Tool State preserved between

commands

• Commands are not interactive

– receive parameters

– execute

– deliver output


Tool-support: Concepts

Meaning of diagrams stated informally in (OMG 2003).

Ambiguities problem for

• tool support

• establishing behavioral properties (safety, security)

Need precise semantics for used part of UML, especially to ensure security requirements.


Using UML

UML: unprecedented opportunity forhigh-quality and cost- and time-efficientcritical systems development:

• De-facto standard in industrial modeling: large number of developers trained in UML.

• Relatively precisely defined (given the user community).

• Many tools (drawing specifications, simulation, …).


Tool-support: Tool Binding

Several possibilities:

• General purpose language with

integrated XML parser (Perl, …)

• Special purpose XML parsing language

(XSLT, …)

• Data Binding (Castor; XMI: e.g. MDR)


Default Wrappers


Command Parameters

Media-independent functionalityBut each mode can have own list of commands


The Class Diagram

Association

name : string

AssociationEnd

name : string

Class

name : stringinitialValue : string

Attribute

name : string

Operation

name : string

OperationParameter

1

-parameters

*1

-operations

*

1

-attributes

*

1

-associationEnd1

1

-class1

-associationEnds

*

name : string

Stereotype

1

-stereotypes

*

1

-associationEnd2

1


The Statechart Diagram

FinalState

InitialState

SimpleState

name : string

State

StateMachine

Transition

1

finalState

*

1

states

*

1

initialState

11 outgoing0..1

1

incoming *

target

1

incoming

*

source

1

outgoing

*

name : string

Trigger

name : string

TriggerParameter

expression : string

Guard

expression : string

Effect

1

trigger

0..1

1

effect

0..1

1

guard

0..1

1

parameters*

1


The Deployment Diagram

Com ponentInstance

LinkLinkEnd

N odeInstance

nam e : string

identifier : in t

O bject

1

*

1

linkEnd1

1

1

*

linkEnds

*

nodeInstance

1

«instance»

nam e : s tring

C lassD iagram ::C lass

1

linkEnd1

1

nam e : s tring

Stereotype

1

-stereotypes

*

A ssociationEnd A ssociation

object

1

associationEnds

*

1

associationEnd1

1

1

associationEnd2

1


Relevant UMLsec Fragment

• Class Diagrams

– Classes with Attributes and Operations

– Logical Associations between Classes

• Statechart Diagrams

– Dynamic behaviour of each class

• Deployment Diagram

– Objects as Class instances

– Connections and their physical properties


Cryptography primitives

• Cover

– Guards

– Effects

– Expressions, including Initial Values

• Use only plain ASCII text

• Keep complexity down where possible


Message parameters

• How to represent various data types?

– Without additional work for the

model developer

– Avoiding the “type flaw” attacks

• Dynamic types

– Each message carries its type

– Message processing based on runtime type,

no on static type specified in the UML model


Encoding UML Model

• Class Diagram

– Variables, messages, logical links

• Statechart Diagram

– Promela procedure “proctype” construction

following UMLsec semantics

• Deployment Diagram

– Instantiate Class procedures

– Create communication channels


Encoding Adversary

• Additional Promela procedure

• Accesses all communication channels

• Generic functionality in a loop

– Read

– Delete

– Write

• Restrict accordingly to the model


Encoding security requirement

• <<secrecy>> – marked variable

– The initial value shall not be recovered by the

intruder

• Promela “never claim” construction

– Invariant for the whole execution time


Example: TLS Variant


Vision

• Simple independent tools

• Media-independent

• Easy to use

– Simple developer interface

• Easy to maintain

– Simple architecture

[joint work with TUM UMLsec

group, in part. Pasha Shabalin]


Concept

• Set of plug-in tools

– Tool exposes predefined interfaces

– Tool can use framework interfaces

• Tool implements a set of commands

– Each command has parameters

• Framework = common code

– UML model management

– Other services


viki Tool

• Works in GUI and/or Text mode

• Implements interfaces

– IVikiToolCommandLine

• Text output only

– IVikiToolGui

• Output to JPanel + menu, buttons, etc

• Exposes set of commands

– Automatically imported by the framework


Framework Interfaces

IMdrContainer

use and control the MDR repository

ITextOutput, ILogOutput

render textual information

IAppSettings

store / retrieve tool settings


Adversaries

Model classes of adversaries.

May attack different parts of the system

according to threat scenarios.

Example: insider attacker may intercept

communication links in LAN.

To evaluate security of specification,

simulate jointly with adversary model.


Cryptography

Keys are symbols, crypto-algorithms are

abstract operations.

• Can only decrypt with right keys.

• Can only compose with available

messages.

• Cannot perform statistical attacks.


Execution Semantics

Behavioral interpretation of a UML subsystem:

(1) Takes input events.

(2) Events distributed from input and link

queues between subcomponents to

intended recipients where they are

processed.

(3) Output distributed to link or output queues.

(4) Apply adversary model.

Automated Verification of UMLsec Models for … · of UMLsec Models for Security Requirements ......

Documents

Transcript of Automated Verification of UMLsec Models for … · of UMLsec Models for Security Requirements ......