UMLSec

1
UMLSec
IS 2935 Developing Secure SystemsCourtesy of
Jan Jürjens, who developed UMLsec

• Feb 6, 2006

2
Critical/High assurance Systems Development

• High quality development of critical systems
  (dependable, security-critical, real-time,...) is
  difficult.
• Many systems developed, deployed, used that do
  not satisfy their criticality/security
  requirements, sometimes with spectacular
  failures.
• Many flaws found in design/implementation
• CERT reports
• No coherent and complete methodology to ensure
  security in the construction of large
  general-purpose systems exists

3
Quality vs. cost

• Systems on which human life and commercial assets
  depend need careful development.
• Systems operating under possible system failure
  or attack need to be free from weaknesses/flaws
• Correctness in conflict with cost.
• Thorough methods of system design not used if too
  expensive.

4
Model-based Security

• Goal
• Make the transition from human ideas to executed
  systems easy
• Increase quality/assurance with bounded
  time-to-market and cost.

Requirements
Models
Code
5
Goal Secure by Design

• Consider critical properties
• from very early stages
• within development context
• taking an expansive view
• seamlessly throughout the development lifecycle.
• High Assurance/Secure design by model analysis.
• High Assurance/Secure implementation by test
  generation.

6
Model-based Security Engineering

• Combined strategy
• Verify models against requirements
• Generate code from models where reasonable
• Write code and generate test sequences otherwise.

Requirements
Verify
Models
Code Gen.
Test Gen.
Code
7
Secure by design

• Establish the system fulfills the security
  requirements
• At the design level
• By analyzing the model
• Make sure the code is secure
• Generate test sequences from the model

8
Using UML

• UML
• Provides unprecedented opportunity for
  high-quality and cost- and time-efficient
  high-assurance systems development
• De-facto standard in industrial modeling large
  number of developers trained in UML.
• Relatively precisely defined
• Many tools (specifications, simulation, ).

9
Challenges

• Adapt UML to critical system application domains.
• Correct use of UML in the application domains.
• Conflict between flexibility and unambiguity in
  the meaning of a notation.
• Improving tool-support for critical systems
  development with UML (analysis, ).

10
UML Extension Goals

• Extensions for high assurance systems
  development.
• evaluate UML specifications for weaknesses in
  design
• encapsulate established rules of prudent
  critical/secure systems engineering as checklist
• make available to developers not specialized in
  critical systems
• consider critical requirements from early design
  phases, in system context
• make certification cost-effective

11
The High-assurance design UML profiles

• Recurring critical security requirements,
  failure/adversary scenarios, concepts offered as
  stereotypes with tags on component-level.
• Use associated constraints to evaluate
  specifications and indicate possible weaknesses.
• Ensures that UML specification provides desired
  level of critical requirements.
• Link to code via test-sequence generation.

12
UML - Review

• Unified Modeling Language (UML)
• visual modeling for OO systems
• different views on a system
• high degree of abstraction possible
• de-facto industry standard (OMG)
• standard extension mechanisms

13
Summary of UML Components

• Sequence diagram
• interaction by message exchange
• Deployment diagram
• physical environment
• Package/Subsystem
• collect diagrams for system part
• Current UML 1.5 (released Mar 2003)

• Use case diagram
• discuss requirements of the system
• Class diagram
• data structure of the system
• Statechart diagram
• dynamic component behavior
• Activity diagram
• flow of control between components

14
Dependency
dependency
supertype
subtype
15
UML run-through Class diagrams

• Class structure of system.
• Classes with attributes and operations/signals
• relationships between classes.

16
UML run-through Statecharts

• Dynamic behavior of individual component.
• Input events cause state change and output
  actions.

eventguard/action
eg/a
17
UML runthrough Activity diagrams
For each component or object
Synchronization bar
A special case of State-chart
action state Sub-activity

• Specify the control flow between components
  within the system, at higher degree of
  abstraction than state-charts and sequence
  diagrams.

18
UML run-through Sequence Diagrams

• Describe interaction between objects or
  components via message exchange.

19
UML Deployment diagrams
Logical (connections)

• Describe the physical layer on which the system
  is to be implemented.

20
UML Package

• May be used to organize model elements into
  groups within a physical system

21
UML Extension mechanisms

• Stereotype
• specialize model element using label.
• Adds security relevant information to model
  elements
• Tagged value
• attach tagvalue pair to stereotyped element.
• Constraint
• refine semantics of stereotyped element.
• Profile
• gather above information.

22
Basic Security Requirements
Secrecy
Information
Integrity
Availability
Information
Information
23
Basic Security Requirements II
Authenticity
Nonrepudiability
Sender
Information
Information
Sender
24
Problems

• Many flaws found in designs of security-critical
  systems, sometimes years after publication or
  use.
• Spectacular Example (1997)
• NSA hacker team breaks into U.S. Department of
  Defense computers and the U.S.electric power grid
  system. Simulates power outages and 911 emergency
  telephone overloads in Washington, D.C..

25
Causes I

• Designing secure systems correctly is difficult.
• Even experts may fail
• Needham-Schroeder protocol (1978)
• attacks found 1981 (Denning, Sacco), 1995
  (Lowe)
• Designers often lack background in security.
• Security as an afterthought.

26
Causes II

• Blind use of mechanisms
• Security often compromised by circumventing
  (rather than breaking) them.
• Assumptions on system context, physical
  environment.
• Those who think that their problem can be
  solved by simply applying cryptography dont
  understand cryptography and dont understand
  their problem (Lampson, Needham).

27
Difficulties

• Exploit information spreads quickly.
• Check the stats at CERT
• Organizations hesitate to share
• NCFTA addresses this
• No feedback on delivered security from customers
• Difficult to expect

28
Previous approaches

• Penetrate-and-patch unsatisfactory.
• insecure
• damage until discovered
• disruptive
• distributing patches costs money, destroys
  confidence, annoys customers)
• Traditional formal methods expensive.
• training people
• constructing formal specifications.

29
Holistic view on Security

• Saltzer, Schroeder 1975
• An expansive view of the problem is most
  appropriate to help ensure that no gaps appear in
  the strategy
• But no complete method applicable to the
  construction of large general-purpose systems
  exists yet (since 1975)

30
Requirements on UML extension

• Mandatory requirements
• Provide basic security requirements such as
  secrecy/confidentiality and integrity.
• Allow considering different threat scenarios
  depending on adversary strengths.
• Allow including important security concepts (e.g.
  tamper-resistant hardware).
• Allow incorporating security mechanisms (e.g.
  access control).

31
Requirements on UML extension

• Provide security primitives
• e.g. (a)symmetric encryption
• Allow considering underlying physical security.
• Allow addressing security management
• e.g. secure workflow
• Optional requirements
• Include domain-specific security knowledge
• Java, smart cards, CORBA, ...

32
UMLsec general ideas

• Activity diagram
• secure control flow, coordination
• Class diagram
• exchange of data preserves security levels
• Sequence diagram
• security-critical interaction

• Statechart diagram
• security preserved within object
• Deployment diagram
• physical security requirements
• Package
• holistic view on security

33
Stereotypes

• Central idea stereotypes
• Add security relevant information to model
  elements of three kinds
• Security assumptions on the physical level of the
  systems e.g., Internet
• Security requirements on the logical structure of
  the system, e.g., secrecy or specific data
  values, e.g., critical

34
Stereotypes

• Security policies that the system parts are
  supposed to obey e.g.
• fair exchange, secure links, data security,
  no down-flow
• First two cases
• Simply add some additional information to a model
• Third one
• Constraints are associated that needs to be
  satisfied by the model

35
UMLsec profile (excerpt)
Stereotype Base class Tags Constraints Description
Internet link Internet connection
secure links subsystem dependency security matched by links enforces secure communication links
secrecy dependency assumes secrecy
secure dependency subsystem call, send respect data security structural interaction data security
no down-flow subsystem high prevents down-flow information flow
data security subsystem provides secrecy, integrity basic data security requirements
fair exchange package start, stop after start eventually reach stop enforce fair exchange
guarded access Subsystem guarded objects acc. through guards. access control using guard objects
36
ltltInternetgtgt , ltltencryptedgtgt ,

• Kinds of communication links (resp. system nodes)
• For adversary type A, stereotype s, have
• ThreatsA (s) ? delete, read, insert, access of
  actions that adversaries are capable of.
• Default attacker

Stereotype Threatsdefault()
Internet encrypted LAN smart card delete, read, insert delete ? ?
37
Requirements with use case diagrams
Customer

• Capture security requirements in use case
  diagrams.
• Constraint
• need to appear in corresponding activity diagram.

38
fair exchange

• Ensures generic fair exchange condition
• Avoid cheating
• Constraint
• after a start state in activity diagram is
  reached, eventually reach stop state.
• Cannot be ensured for systems that anattacker
  can stop completely.

39
fair exchange

• Customer buys a goodfrom a business.
• Fair exchange means
• after payment,customer iseventually
  eitherdelivered good orable to reclaimpayment.

Pay may be provable
40
ltltsecure linksgtgt Example

• Ensures that physical layer meets
  securityrequirements on communication.
• Constraint
• for each dependency d with stereotype s in
  ltltsecrecygtgt , ltltintegritygtgt betweencomponents
  on nodes n, m, have a communication link l
  between n and m with stereotype t such that if
  s ltltsecrecygtgt have read ? ThreatsA (t). if
  s ltltintegritygtgt have insert ? ThreatsA (t).

41
ltltsecure linksgtgt Example

• Given default adversary type, is ltltsecure linksgtgt
  provided ?

42
ltltsecure linksgtgt Example

• Given default adversary type, constraintfor
  stereotype ltltsecure linksgtgt violated
• According to the Threatsdefault(Internet)
  scenario
• (read is in Threatsdefault(Internet)),
• ltltInternetgtgt link does not provide secrecy
  against default adversary.

43
ltltsecure dependencygtgt

• Ensure that ltltcallgtgt and ltltsendgtgtdependencies
  between components respectsecurity requirements
  on communicated datagiven by tags secrecy,
  integrity and high.
• Constraint
• for ltltcallgtgt or ltltsendgtgt dependency from C to D
  (and similarly for secrecy)
• Msg in D is secrecy in C if and only if also in
  D.
• If msg in D is secrecy in C, dependency is
  stereotyped ltltsecrecygtgt.

44
Example ltltsecure dependencygtgt

• ltltsecure dependencygtgt provided ?

45
Example ltltsecure dependencygtgt

• Violates ltltsecure dependencygtgt Randomgenerator
  and ltltcallgtgt dependency do not givesecurity
  level for random() to key generator.

46
ltltno downflowgtgt

• Enforce secure information flow.
• Constraint
• Value of any data specified in secrecymay
  influence only the values of dataalso specified
  in secrecy.
• Formalize by referring to formal behavioral
  semantics.

47
Example ltltno down-flowgtgt

• ltltno downflowgtgt provided ?

48
Example ltltno down-flowgtgt

• ltltno downflowgtgt violated partial information on
  input of high wm() returned by non-high rx().

49
ltltdata securitygtgt

• Security requirements of data markedltltcriticalgtgt
  enforced against threatscenario from deployment
  diagram.
• ConstraintsSecrecy of secrecy data
  preserved.Integrity of integrity data
  preserved.

50
Example ltltdata securitygtgt
Variant of TLS (INFOCOM99) ltltdata securitygtgt
against default adversary provided ?
51
Example ltltdata securitygtgt
Variant of TLS (INFOCOM99) Violates secrecy
of s against default adversary.
52
ltltguarded accessgtgt

• Ensures that in Java, ltltguardedgtgt classes only
  accessed through guard classes.
• Constraints
• References of ltltguardedgtgt objectsremain secret.
• Each ltltguardedgtgt class has guardclass.

53
Example ltltguarded accessgtgt

• Provides ltltguarded accessgtgt Access to MicSi
  protected by MicGd.

54
Does UMLsec meet requirements?

• Security requirements ltltsecrecygtgt ,
• Threat scenarios Use Threatsadv(ster).
• Security concepts e.g. ltltsmart cardgtgt .
• Security mechanisms e.g. ltltguarded accessgtgt.
• Security primitives Encryption built in.
• Physical security Given in deployment diagrams.
• Security management Use activity diagrams.
• Technology specific Java, CORBA security.

55
Security Patterns

• Security patterns use UML to encapsulate
  knowledge of prudent security engineering.Example
  
• Does not preserve security of account balance.

56
Solution Wrapper Pattern

• Technically, pattern application
  istransformation of specification.
• Use wrapper pattern to ensure that no lowread
  after high write.
• Can check this is secure (once and for all).

57
Secure channel pattern problem

• To keep d secret, must be sent encrypted.

58
Secure channel pattern (simple) solution

• Exchange certificate and send encrypted data over
  Internet.