CSCE 548 Secure Software Development Security Use Cases

CSCE 548 CSCE 548 Secure Software Secure Software

DevelopmentDevelopment

Security Use CasesSecurity Use Cases

CSCE 548 - Farkas 2

ReadingReading

This lecture: – Jan Jürjens, Towards Development of Secure Systems

using UMLsec, http://citeseer.ist.psu.edu/536233.html – Lodderstedt et. al, SecureUML: A UML-Based

Modeling Language for Model-Driven Security, http://citeseer.ist.psu.edu/lodderstedt02secureuml.html

– K. Alghathbar and D. Wijesekera, authUML: a three-phased framework to analyze access control specifications in use cases, http://portal.acm.org/citation.cfm?id=1035438

Next lecture:– Misuse Cases, McGraw: Chapter

CSCE 548 - Farkas 3

Application of TouchpointsApplication of Touchpoints

Requirement and Use cases

Architecture and Design

Test Plans Code Tests andTest Results

Feedback fromthe Field

5. Abuse cases

6. Security Requirements

2. Risk Analysis

External Review

4. Risk-Based Security Tests

1. Code Review(Tools)

2. Risk Analysis

3. Penetration Testing

7. Security Operations

CSCE 548 - Farkas 4

Design FlawsDesign Flaws

50 % of security problemsNeed: explicitly identifying riskQuantifying impact: tie technology issues

and concerns to businessContinuous risk management

CSCE 548 - Farkas 5

SecureUMLSecureUML

Lodderstedt, Basin, and DoserRole-Based Access Control, MACUse UML to specify access control

– Security is “horizontal” to software development

– Ad-hoc and “after-the-development” security integration is error prone, can be costly, and may have negative impact

CSCE 548 - Farkas 6

SecureUMLSecureUML

Model-driven software development integrated with security

Advantages: – Security is integrated during software design, using

high-level of abstraction– Modeling information can be used to detect design

errors and verify correctness

Limitations: need precise semantics of modeling language for security assurance

CSCE 548 - Farkas 7

Unified Modeling Language Unified Modeling Language

Standard way to visualize a system's architectural blueprints

High abstraction levelExtensible syntaxSufficiently precise semantics

UML ElementsUML Elements

Actors Business processes Logical components Activities Programming language statements Database schemasReusable software components

CSCE 548 - Farkas 8

UML DiagramsUML Diagrams

CSCE 548 - Farkas 9

Source: Wikipedia, http://en.wikipedia.org/wiki/Unified_Modeling_Language

UML Specification LanguageUML Specification Language

Object Constraint Language (OCL)– Invariant for classes– Preconditions and post conditions for methods– Guards for transitions in state machines

First –order logic– E.g., context Meeting inv: self.participants ->

includes(self.owner) Stereotypes: sub-typing Tagged values: (tag, value)

CSCE 548 - Farkas 10


RBACRBAC

Intuitive and easy to administerWell established and supported by a large

number of software platformLimitation: expressing access conditions

based on system state Authorization Constraints (Object Constraint Language)


RBAC3

.

.

UUsers

RRoles

PPermissions

. SSessions

User assignment

Permissionassignment

Constraints


Mandatory Access Control

Objects: security classification e.g., grades=(confidential, {student-info})

Subjects: security clearancese.g., Joe=(confidential, {student-info})

Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject e.g., subject can read object only if label(subject) dominates label(object)

CSCE 548 - Farkas 14CSCE 522 - Farkas 14Lecture 17

Mandatory Access ControlSecurity Labels: (A,C) , where

A: total order, e.g., Top-Secret > Secret > PublicC: domain (subset), e.g., subsets of the set {5, 7} are: {5,7}, {5}, {7}, {} and {5,7} {5,7}|{5}|{7}|{}, {5} {5}|{}, {7}{7}|{}, {} {} but {7} NOT {5}

Dominance (): label l=(A,C) dominates l’=(A’,C’) iff A A’ and C C’e.g., (confidential,{student-info}) (public,{student-info})BUT

(confidential, {student-info}) NOT (public,{student-info, department-info})

CSCE 548 - Farkas 15CSCE 522 - Farkas 15Lecture 17

Bell-LaPadula Axioms• Simple-security property: a subject s is allowed to read an

object o only if the security label of s dominates the security label of o• No read up• Applies to all subjects

• *-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s• No write down• Applies to un-trusted subjects only

Model Driven SecurityModel Driven SecurityModel building: standard practice in

software engineering (e.g., MDA)Security policy specification (e.g., RBAC)Difficulties:

– Security models and system design models are disjoint and expressed in different ways

– Security considerations are missing in the middle of development (addressed in early development and final phases)


Model Driven ArchitectureModel Driven Architecture

Model Driven Security Model Driven Security


Model Driven ArchitectureModel Driven Architecture


Source: D. Basin et a., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

Model Driven SecurityModel Driven Security



Model Driven SecurityModel Driven Security

Security modeling language

System design modeling language

Dialect: connection point for integrating security and system models




SecureUMLSecureUML Defines vocabulary for annotating UML-based

models with access control information Abstract syntax: formal definition, e.g., grammar Concrete syntax: notation (UML profile) Host language: a modeling language that uses

SecureUML SecureUML dialect: SecureUML specifications

are refined in the host language – E.g., syntactic elements of the modeling language are

transformed into constructs of the target platform

Need capability to combine sub-expressions fromdifferent languages!


UMLsecUMLsec

Uses extension mechanism of UML and its formal semantics

Relies on work providing formal semantics for UML

Security considerations: need formal semantics to reason about security requirements


UML Diagrams and SecurityUML Diagrams and Security

Class diagrams: static structure of the system– Class: attributes and operations/signals– Relationships between classes

Statechart diagrams: dynamic behavior of individual objects– Events: change in the state or actions– Prevent indirect information flow

Interaction diagram: interactions between objects via messages– Sequence diagrams– Correctness of security critical interactions


UMLsecUMLsec

Security labeling: UML extension construct tag

Need formal semantics of UML diagrams– UMLSec uses a simplified semantics to convey

security information

Secure UML MetamodelSecure UML Metamodel


Source: D. Basin et al., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

Concrete SyntaxConcrete Syntax

UML profile: formalizes the modeling notations of SecureUML– Stereotypes– Tagged values


Other ApproachesOther Approaches


Top Ten Information Security Top Ten Information Security Considerations in Use Case Modeling Considerations in Use Case Modeling

Gunnar Peterson, CTO, Arctec Group, http://www.arctecgroup.net/secusecase.htm

1. Synthesis: architectural tradeoff analysis

2. Stakeholders: capture and documentation of who is impacted by security

3. Pre- and postconditions: must be satisfied for the use case to execute and the system must end in a specified state

4. Exceptional and alternate flows: plan for failure

5. Actors: authorization structure, delegation


Top Ten Information Security Top Ten Information Security Considerations (cont.)Considerations (cont.)

6. Modeling Identity: building, validating, and exchanging identities

7. Relationships: simplicity (includes, extends)

8. Mapping use cases to threat models

9. Architectural decision support: design-level tradeoff analysis

10. Test case development: security assurance measures




AuthUMLAuthUML

Alghathbar and WijesekeraFormal semantics for UML diagrams

– Horn clauses

Additional logic constructs to model – Authorization constraints


authUMLauthUML

This unified framework supports – Derivation of authorization – Verification of consistency of the integrated

security policies– Resolution of conflicting requirement– Application of default policy


Access ControlAccess Control

(s, o, a) Policy neutral AuthUML consists of three phases Policies written as finite collections of Horn

clauses – alertReq(Xs,Xuc)candoUC(Xs,+Xuc),

candoUC(Xs,Xuc)


Use Case ExampleUse Case ExamplePrepare

order

Place order

Write check

Clerk

Purchasing Officer

Manager

Sign check

Copyright: Alghathbar and Wijesekera


ExamplesExamples

Predicate Description

UC_OP(Xuc,Xop) Operation Xop is part of Use Case Xuc

OP_OBJ(Xop,Xobj) Operation Xop belongs to object Xobj.

before(Xop,X’op) Operation Xop must be invoked before X’op.

inUCbefore(Xuc,Xop,

X’op)

Use Case Xuc invokes Xop before X’op.


ExamplesExamples

Predicate Description

conflictingSubject(Xs,X’s) Subjects Xs and X’s conflict with each other.

conflictingUC(Xuc, X’uc) Use case Xop and X’op conflict with each other.

conflictingOP(Xop, X’op) Operations Xop and X’op conflict with each other.

ignore(X,Y,Y’) Ignore a conflict among X,Y and Y’ where X, Y and Y’ are either subjects, operations or Use Cases


Misuse CasesMisuse CasesSoftware development: making software do

something– Describe features and functions– Everything goes right

Need: security, performance, reliability– Service level agreement – legal binding

How to model non-normative behavior in use cases?– Think like a bad guy


Software Vendor AccountabilitySoftware Vendor Accountability

Proper implementation of security featuresLooking for known security flawsPassing third party validationSource code analysis


Checking for Known Checking for Known VulnerabilitiesVulnerabilities

Need toolPossible attacks and attack typesHow the software behaves if something

goes WRONGWhat motivates an attacker?


Next ClassNext Class

Misuse Cases

Documents

CSCE 548 Secure Software Development Security Use Cases