Frid

ay O

ctob

er 2

8, 2

005SoBeNeT workshop

The role of Security in software processes (UP, XP) and software architecture

2

Frid

ay O

ctob

er 2

8, 2

005

SoBeNeT in a nutshell

IWT SBO project (2003-2007) Context: availability of security components Goal: to enable the development of secure application

software 4 Research tracks:

Programming and Composition Software engineering Tamper and analysis resistance Shielding and interception

3

Frid

ay O

ctob

er 2

8, 2

005

Agenda

13:30h Overview of research results in using UML for security (Bart De Win)

14:00h UP and security: overview of UMLSec (Jan Jürjens)

15:00h Break

15:15h XP and security: writing abuser stories -- interactive session (Johan Peeters)

16:45h Security in software architectures -- interactive session (Wouter Joosen)

17:20h Workshop wrap-up

Frid

ay O

ctob

er 2

8, 2

005

Overview of research results in using UML for security

Bart De Win, Koen Yskout

5

Frid

ay O

ctob

er 2

8, 2

005

Introduction

Importance of security in the software development process UML as industrial standard

Covers significant part of development lifecycle UML 2.0 (support for behavioral semantics, components) No formalization

Overview of what support is available/being proposed to address security within UML Only one, but an important vehicle Selection is world-wide, not SoBeNeT-restricted Part of survey effort

Different goals: Representation Realization (automatic) Verification Traceability

In this presentation we identify rather than assess

6

Frid

ay O

ctob

er 2

8, 2

005

Overview

Techniques Misuse cases (A) Policy modeling (D) Security patterns (D)

Methods CORAS Model based security CLASP

Conclusion

7

Frid

ay O

ctob

er 2

8, 2

005

Misuse cases

8

Frid

ay O

ctob

er 2

8, 2

005

Misuse cases (ctd.)

Textual representation of misuse case detailsModifications to std. use case template:

Reinterpretation: actor, basic and alternative paths Introduction: exception paths, capture points,

triggers, related business rules, prevention and detection guarantee, stakeholders and threats

Although different template proposals are similar, no standard template yet

9

Frid

ay O

ctob

er 2

8, 2

005

Policy modeling

10

Frid

ay O

ctob

er 2

8, 2

005

Policy Modeling (ctd.)

Support for constraint specification using OCL, e.g. Separation of Duty:

context User inv:

let M : Set = {{accounts_mgr,purchase_mgr}, }

in M->select{m|self.role->intersection(m)->

size->1)->isEmpty

11

Frid

ay O

ctob

er 2

8, 2

005

Policy Modeling (ctd.)

Verification Detection of conflicting constraints and

identification of missing constraints Prior to deployment By means of USE tool

• Test scenarios are automatically generated• Can be used to analyze modifications on the fly• Authorization editor

12

Frid

ay O

ctob

er 2

8, 2

005

Security patterns

Application of the idea of design patterns to security A security pattern represents a proven design solution to a

security problem Usefulness of design patterns has been well established Relevant for architectural as well as for detailed design

Opportunities and challenges Can have a huge impact on SSE Watch application area Quality control is essential

13

Frid

ay O

ctob

er 2

8, 2

005

Security Patterns (ctd.)

14

Frid

ay O

ctob

er 2

8, 2

005

Overview

Techniques Misuse cases (A) Policy modeling (D) Security patterns (D)

Methods CORAS Model based security CLASP

Conclusion

15

Frid

ay O

ctob

er 2

8, 2

005

CORAS

Risk Analysis of Security Critical Systems Consists of:

Integrated methodology UML profile Knowledge base Tool

Five step methodology (iterative) Identify context Identify risks Analyze risks Evaluate risks Treat risks

Designed for heavy analysis

16

Frid

ay O

ctob

er 2

8, 2

005

CORAS (ctd.)

17

Frid

ay O

ctob

er 2

8, 2

005

CORAS (ctd.)

18

Frid

ay O

ctob

er 2

8, 2

005

Model based security

Goals: Take security into account during the whole development

process Separation of concerns

security should be separated from application design

Specificationusing security metamodels or templates, or inline

Realization: binding and generation Transformation to code/deployment descriptor Template instantiation enriched model

Verification: formal foundation needed

Examples: SecureUML, AOM, UMLsec

19

Frid

ay O

ctob

er 2

8, 2

005

Model based security (ctd.)SecureUML

e.g. secureUML

e.g. componentUML

20

Frid

ay O

ctob

er 2

8, 2

005

Model based security (ctd.)

SecureUML (ctd.) Modeling the policy

Transformation from modeling language to code, deployment descriptors, …

• E.g. generate an EJB system, a .NET system, …

21

Frid

ay O

ctob

er 2

8, 2

005

Model based security (ctd.)

Aspect-Oriented Modeling (AOM) primary model + aspect models (e.g. security) Specification: using templates

• class diagram, sequence diagram, OCL constraints

Realization: instantiation of the templates + composition with primary model

• Add new classes, extend existing classes, …

Verification: • After composition

• During composition: evolving proof obligations

22

Frid

ay O

ctob

er 2

8, 2

005

Model based security (ctd.)Aspect-Oriented Modeling (ctd.)

(BankUser, |User)(BankRole, |Role)

…

Primary model

Template RBAC Aspect model

Composed model

23

Frid

ay O

ctob

er 2

8, 2

005

Model based security (ctd.)

UMLsec Extension of UML for recurring security requirements

• Stereotypes, tags and constraints

• Superimposed on functional diagrams

Formal foundations support verification and generation Specification details are hidden from the developer Tool support is available

More details: see next presentation

24

Frid

ay O

ctob

er 2

8, 2

005

CLASP

Comprehensive Lightweight Application Security Process

Designed by Secure Software, IBM, WebMethods Set of security-related activities (24) to be included in

the software development process Role-based approach Tools: vulnerability root-causes, template sheets,

RUP plug-in

25

Frid

ay O

ctob

er 2

8, 2

005

CLASP (ctd.)

Institute security awareness program Monitor security metrics Specify operational environment Identify global security policy Identify resources and trust boundaries Identify user roles and resource

capabilities Document security-relevant requirements Detail misuse cases Identify attack surface Apply security principles to design Research and assess security posture of

technology solutions Annotate class designs with security

properties

Specify database security configuration Perform security analysis of system

requirements and design Integrate security analysis into source

management process Implement interface contracts Implement and elaborate resource

policies and security technologies Address reported security issues Perform source-level security review Identify, implement and perform security

tests Verify security attributes of resources Perform code signing Build operational security guide Manage security issue disclosure

process

26

Frid

ay O

ctob

er 2

8, 2

005

Conclusion

Spectrum of results is available Main challenges:

Improving the application scope Industrial validation of results Quality control of point solutions Formalization to enable verification and automatisation Integration of resultsIn summary, need for a secure SW development methodology

& process Our future focus:

Integration of SoBeNeT results Point solutions for architecture and detailed design Coherent set of activities

27

Frid

ay O

ctob

er 2

8, 2

005

References

Misuse cases G. Sindre and A. Opdahl, Eliciting security requirements with misuse

cases, Requirements Engineering, 10, pp. 34-44, 2005. Policy Modeling

P. Epstein and R. Sandhu, Towards a UML based approach to Role Engineering

E. Shin and G.-J. Ahn, UML-based representation of RBAC G.-J. Ahn and E. Shin, RBAC contraint specification using OCL K. Sohr, G.-J. Ahn and L. Migge, Articulating and enforcing

Authorization policies with UML and OCL, Workshop on Software Engineering for Secure Systems 2005, May 2005.

28

Frid

ay O

ctob

er 2

8, 2

005

References

Security patterns J. Yoder, J. Barcalow, Architectural patterns for Enabling Application

Security, Workshop on Programming Languages for Patterns (PLoP), 1997. The Open Group, Security Design Patterns, Technical Guide, 2004. Security pattern website, http://www.securitypatterns.org D. Kienzle and M. Elder, Security Patterns for Web Application Development,

Technical Report, 2002. Model based security

J. Jürjens, Secure Systems Development with UML, Springer, 2005. T. Lodderstedt, D. Basin, J. Doser, SecureUML: A UML-Based Modeling

Language for Model-Driven Security, UML 2002. D. Basin, J. Doser, T. Lodderstedt, Model Driven Security: from UML Models

to Access Control Infrastructures, ACM Transactions on Software Engineering and Methodology, to appear.

E. Song, R. Reddy et al, Verifiable Composition of Access Control and Application Features, 10th ACM Symposium on Access Control Models and Technologies, June 2005.

29

Frid

ay O

ctob

er 2

8, 2

005

References

CORAS R. Fredriksen, M. Kristiansen, B. Gran, K. Stølen, T. Arthur

Opperud, T.Dimitrakos. The CORAS framework for a model-based risk management process. In Proc. Computer Safety, Reliability and Security (Safecomp 2002), LNCS 2434, pages 94-105, Springer, 2002.

CORAS project homepage: http://coras.sourceforge.net

CLASP J. Viega, Security in the software development lifecycle, http://www-

128.ibm.com/developerworks/rational/library/content/RationalEdge/oct04/viega/.

Secure Software Inc. The CLASP Application Security Process, Technical report, 2005.