1 / 29

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

SoBeNeT workshop The role of Security in software processes (UP, XP) and software architecture. 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:

april-harmon
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SoBeNeT workshopThe role of Security in software processes (UP, XP) and software architecture

  2. 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. Agenda

  4. Overview of research results in using UML for security Bart De Win, Koen Yskout

  5. 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. Overview • Techniques • Misuse cases (A) • Policy modeling (D) • Security patterns (D) • Methods • CORAS • Model based security • CLASP • Conclusion

  7. Misuse cases

  8. Misuse cases (ctd.) • Textual representation of misuse case details • Modifications 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. Policy modeling

  10. 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. 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. 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. Security Patterns (ctd.)

  14. Overview • Techniques • Misuse cases (A) • Policy modeling (D) • Security patterns (D) • Methods • CORAS • Model based security • CLASP • Conclusion

  15. 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. CORAS (ctd.)

  17. CORAS (ctd.)

  18. Model based security • Goals: • Take security into account during the whole development process • Separation of concernssecurity should be separated from application design • Specification using 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. Model based security (ctd.) SecureUML e.g. secureUML e.g. componentUML

  20. 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. 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. Model based security (ctd.) • Aspect-Oriented Modeling (ctd.) Primary model Template RBAC Aspect model (BankUser, |User) (BankRole, |Role)… Composed model

  23. 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. 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. 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 CLASP (ctd.)

  26. 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 results In 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. 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. 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. 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.

More Related