1 / 30

SECURITY REQUIREMENTS MODELS: A SURVEY AND COMPARISON

SECURITY REQUIREMENTS MODELS: A SURVEY AND COMPARISON. Ing. Abel E. Fornaris, Dr. Eduardo Fdez-Medina GSyA Research Group Escuela Superior de Informática Universidad Castilla-La Mancha, Ciudad Real, España. Content. Agenda. Introduction Systematic Literature Review (SLR) development

brooks
Download Presentation

SECURITY REQUIREMENTS MODELS: A SURVEY AND COMPARISON

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. SECURITY REQUIREMENTS MODELS: A SURVEY AND COMPARISON Ing. Abel E. Fornaris, Dr. Eduardo Fdez-Medina GSyA Research Group Escuela Superior de Informática Universidad Castilla-La Mancha, Ciudad Real, España.

  2. Content Agenda • Introduction • Systematic Literature Review (SLR) development • SLR Planning • SLR Results • Results Analysis and Discussion • Conclusions • Acknowledgements

  3. Introduction Security, SRE, SR models. • Security as animportantissue: - Incidence of misuse of assets. Worldwide accessibility of the Internet and the automation of systems. • Interest in security engineering community: - Series of strategies focused on securing the applications. Focused primarily on design and implementation stage. • Model driven approaches suffer the same problem. • Response: • Initiatives such as MDS, however. • Security requirement engineering to produce methodologies, processes, frameworks to integrate security from early phases of development. • They use: • Artifacts, languages, techniques, diagrams; models in general. These can be used in an isolated way too.

  4. Introduction Need for the SLR and objective • Problems with these models: • Too many, covering different security requirements, different notation, hard to learn, no common view. • No SLR found covering these models: • Each author proposes a model. Existing surveys and comparisons not in a systematic way. Many studies related to methodologies, processes and frameworks. • Systematic Literature Review (SLR) proposed: • Identify models and surveys/comparisons amongst them. Need for their integration. • Ultimate objective: • Integrate - create links - propose new model(s), to be part of a model driven development (MDD).

  5. SLR development SLR Planning • SLR questions: • Which artifacts, languages, techniques, diagrams, models in general, are currently used to elicit security requirements from the early stages of secure software development as being part, or not, of the different methodologies, processes and frameworks? • Which studies propose comparisons and surveys amongst them? • Expected results: • Identification and description of the different models used in security requirements engineering, as well as their surveys/comparisons. • Main application areas: • Secure software development and software requirements engineering and also security experts and requirements engineers, MDS researchers.

  6. SLR development SLR Planning - Sources • Sources available in Universidad de Castilla – La Mancha, digital libraries. • Sources used: • Scopus Digital Library • Springer Digital Library • Science@Direct Digital Library • ACM Digital Library • IEEE Computer Digital Library • Basic search string: • “Security AND Requirement AND (Engineer OR Engineering) AND (Model OR Diagram OR Artifact OR Method OR Language OR Technique)”

  7. SLR development SLR Results – Models to specify attacks or vulnerabilities • Attack Trees [Schneier, B. (2000)] • Model with a tree structure. • Used to calculate the risk and cost of potential attacks and their countermeasures.

  8. SLR development SLR Results – Models to specify attacks or vulnerabilities • Abuse Frames [Lin, L., B. Nuseibeh, et al. (2003)] • Represent security threats and derive SR by defining anti-requirements as action to subvert these SR. • Share notation with regular problem frames. • Related to domains: Machine, victim, malicious user. • Critical assets must be defined.

  9. SLR development SLR Results – Models to specify attacks or vulnerabilities • Abuser Stories [Peeters, J. (2005)] • Plain text stories of how attackers abuse the system. These are agile counterparts to abuse cases. • Lightweight, low-effort and informal. • Provide traceability to SR. • Should be written by customers, together with developers.

  10. SLR development SLR Results – Models to specify attacks or vulnerabilities • AsmL, AsmLSec [Graves, M. and M. Zulkernine (2006) and Raihan, M. and M. Zulkernine (2007)] • AsmL is an extended finite state machine-based executable software specification language. • Also used to specify attack scenarios in extensions such as AsmLSec. • AsmLSec based on states, events and transitions.

  11. SLR development SLR Results – Model extensions to specify attacks or vulnerabilities • Misuse Cases [Sindre, G. and A. L. Opdahl (2005)] • Extended UML use case to represent undesirable behavior of the software. • Special “mis-actor”. • Related to use cases using “prevent”, “detect”, “include”.

  12. SLR development SLR Results – Model extensions to specify attacks or vulnerabilities • Mal-Activity Diagrams [Sindre, G. (2007)] • Standard UML activity diagram to capture malicious activities and actors using the same syntax and semantics.

  13. SLR development SLR Results – Model extensions to specify attacks or vulnerabilities • Abuse Cases [McDermott, J. and C. Fox (1999)] • Standard UML use case representing complete harmful actions in the system. • Text details about actors, skills and objective should be stated. • All potential harmful interactions should be specified. Tree structure to specify all possible attacks. • Useful for stakeholders understanding.

  14. SLR development SLR Results – Model extensions to specify attacks or vulnerabilities • UMLIntr [Hussein, M. and M. Zulkernine (2006)] • UML profile to deal with attacks using several stereotyped, tagged artifacts. • Attacks divided in 4 stereotyped packages.

  15. SLR development SLR Results – Model extensions to specify attacks or vulnerabilities • UML State Charts for Security [Zulkernine, Graves, et al. (2007)] • Based on extended finite state machines and some of their important constituents are states, transitions, conditions, actions, and events. Represent system behaviour. • Highlight: Ability to represent complex multiple step attacks. • Easily understandable and communicated

  16. SLR development SLR Results SLR Results - Models to represent security requirements • Security Problem Frames [Jackson (2001), Hatebur, D., M. Heisel, et al. (2006)] • Kinds of patterns to represent threat models and SR from them. • Described by frame diagrams. • Objective: Build a machine to improve environment behavior.

  17. SLR development SLR Results SLR Results - Models to represent security requirements • Barrier Analysis Diagrams [Jennex, M. E. (2005)] • Graphical method of identifying and documenting SR by pointing out threats combined with defense in depth concept. • Uses: The threat, the chain of barriers designed to prevent the threat, and the asset being protected. • Meta-notation to add security details.

  18. SLR development SLR Results SLR Results - Models to represent security requirements • Constraints [Haley, C. B., R. Laney, et al. (2008)] • SR considered in terms of constraints that operationalize as security goals. • Which goals apply to which functional requirements, assets identified.

  19. SLR development SLR Results - Models to represent security requirements • SI* [Zannone, N. (2009) and Massacci, F., J. Mylopoulos, et al. (2010)] • Modeling language based on social modeling language i* to capture SR from the organizational point of view. • Employ basic primitives: actor, goal, task, resource and social dependency between two actors. • Enhances i* with four main notions: Permission, delegation, trust, and supervision.

  20. SLR development SLR Results SLR Results – Models extensions to represent security requirements • Secure Tropos [Mouratidis, H. and P. Giorgini (2007)] • Tropos methodology extension to represent SR as constraints. • Based on i*. Concepts of actor, goal, soft goal, task, resource, security constraint, etc.

  21. SLR development SLR Results SLR Results – Models extensions to represent security requirements • Security use cases [Firesmith, D. G. (2003)] • Standard UML use cases . • Complement misuse cases in order to represent SR.

  22. SLR development SLR Results SLR Results – Models extensions to represent security requirements • UMLSec [Juerjens, J. (2005)] • Extension to several UML artifacts with stereotypes, tags and constraints to represent SR. • 21 stereotypes / 7 with tags, 9 with constraints.

  23. SLR development SLR Results SLR Results – Models extensions to represent security requirements • SecureUML [Lodderstedt, T., D. A. Basin, et al. (2002)] • Stereotyped UML class diagram to represent role based access control. • Defines OMG’s metamodel. OCL for resources, actions and permissions.

  24. SLR development SLR Results SLR Results – Models extensions to represent security requirements • GridUCSec-Profile[Rosado et al. (2010)] • UML profile using stereotyped secure use cases for grid systems. • UML metamodel redefined.

  25. SLR development Results Analysis and Discussion • HLA shows most proposals have aligments somehow. Methodologies as higher level. • Some of these aligned models lack strong formal definition (FD), some still have metamodels, there is hope for transformations in MDA approach. • ScAidentifies“popularity”. Popular models as basis to other analysis. See unpopular too, since they are new. Lack of empirical testing (ET) in “unpopular-new” and “weak” models. Several cases of study and experiment in strong ones. • No general ability to specify constraints (CTR) in models. Problem in model strength. • Popular ones have automated tools (AT), most of the models are not standard-aligned.

  26. SLR development Results Analysis and Discussion • Quality Model for the Security in a Software Product. Part of MEDUSAS project. Paper accepted for RECSI 2010

  27. SLR development Results Analysis and Discussion • Depending on purpose have higher or lower support for attack detection. • Confidentiality, integrity, availabilitypopularly or potentially supported. • Safety potentially included by most models somehow. • Models to directly elicit SR tend to include authenticity. • Non-repudiation and accountabilitynot so widelysupported.

  28. Conclusions …and future work… • Great number of models to elicit SR or to represent attacks/vulnerabilities in order to elicit those requirements. • Each model has its own characteristics and covers certain aspects of security. None of them is a complete solution to all possible scenarios. • Identified the need and viability for an unified, unique model (taking advantage of existing ones) to elicit ALL possible SR in an MDD approach. • Capacity to obtain these model by means of transformations between existing successful models.

  29. Acknowledgements Research lines and projects • MDD applied to datawarehouses. • Define quality and security metrics for datawarehouses. • Secure software development. • Security Requirement Engineering. • Security Patterns. • BPS (Business Process Security). • Mobile Grid Computing. • Product line software security. • All aligned with MDD. • Security Management. • ISSM (Information Systems Security Management) for SME. • MEDUSAS(IDI-20090557), QUASIMODO(PAC08-0157-0668), SEGMENT(HITO-09-138), SISTEMAS(PII2I09-0150-3135), BUSINESS (PET2008-0136).

  30. Thank you… Debate Questions… and Answers… Abel E. Fornaris Security Requirements Models: A Survey and Comparison

More Related