on their specific viewâi.e. business process modeling, security model- .... like the WS-SecurityPolicy in Web Servicesâor may be declared business secrets.
Towards Modeling and Transformation of Security Requirements for Service-oriented Architectures Sven Feja1 , Ralph Herkenh¨oner2 , Meiko Jensen3 , Andreas Speck1 , Hermann de Meer2 , and J¨org Schwenk3 1
Computer Science Department, Christian-Albrechts-University of Kiel, Germany {sven.feja|andreas.speck}@email.uni-kiel.de 2 Faculty of Informatics and Mathematics, University of Passau, Germany {rhk|hdm}@fim.uni-passau.de 3 Horst G¨ ortz Institute for IT-Security, Ruhr University Bochum, Germany {Meiko.Jensen|Joerg.Schwenk}@ruhr-uni-bochum.de
Abstract. The design of secure network-based systems is a very important aspect of the software development processes. For process design and composition, the emerging model-driven software development approach discloses new challenges. Existing approaches often only focus on their specific view—i.e. business process modeling, security modeling, code generation—neglecting interoperability with and reusability of other approaches. This is a position paper, pointing out the need for combining process and security modeling of distributed services. Such an approach should cover code generation for service-oriented architectures, encapsulation of security modeling for processes, and security and privacy requirement specification.
1
Introduction
For the future Internet, we expect a massive increase in the presence of service networks. Thus, the task of realizing truly interoperable services will increase in complexity. In particular, requirements on reliability and security have to be taken into account. The model-driven software development approach provides an appropriate solution by specifying a service or the business processes behind. Using an abstract modeling language is much easier compared to expressing and fulfilling the same requirements in common programming languages directly. Typical approaches on model-driven software development are business process modeling (e.g. BPMN), code generation (e.g. by using UML) and security modeling (e.g. UMLsec). Apart from modeling and code generation for the pure functionality of a service, which has matured during the last years, the modeling of non-functional requirements still suffers from several teething troubles. In particular, embedding security requirements into a business process model has some open issues yet. For
that reason, semantical deviations between the business view and the security view of the same service arise. This may lead to unsafe service behaviors or even service failure.Thus, an open issue is granting semantic consistency between the different views of a business process and its related services, enabling a secure and reliable development, deployment and usage of such services. In this paper, we discuss the possibilities of embedding security requirements into business process models, along with a transformation to automatically derive and deploy the appropriate security enforcement mechanisms into the generated process system. Here, Web Services—in particular WS-BPEL-based service composition—provide a well understood approach for deriving services from process models.
2
Concept Overview
Security issues are, as explained above, very important for every developed software solution. But despite the chosen kind of software development, at the moment there is only an unsatisfying support to include these properties from the beginning of the overall software development process [1]. The model-driven software development, which enables the development of model-driven architectures, uses models as first class artifacts to generate software. But if we assume models as being the starting point of software development, then it should be possible to state security requirements at this level already. Our concept focuses on the model-driven software development as overall process. Therefore, we intend to extend that process with the possibility to specify security requirements for the underlying (process) models. Figure 1 depicts this extension of the overall process. The left side of Figure 1 shows the modeling and transformation of a process model. The right side gives an overview of the main contribution of our concept—how a security model can be used to extend the model-driven software development process. The three main parts are explained in the following. Technically, these capabilities have to be delivered by the development environment and development tools used, respectively. 2.1
Security Modeling
The modeling of security properties is based on the given security requirements as described in section 2.3. To include such properties in models, it is important to have a look at the possible types of models. There are many kinds of models like process models or workflows. Each of them has its own semantic and graphical definition. Therefore, a generic definition of security requirements is useful. This generic security model, which consists of a graphical and a semantical part, has to provide adapters for each type of model. Hence, each adapter defines how a security property is visualized for a concrete type of model. The technique to use generic models as overall definition is a common approach [2] and reduces the effort of defining security properties for each kind of model on its own.
Fig. 1. An overview of the general approach
Besides the application of transformations, one main task of the development tools is the representation of models in general. A closer look on these models discloses that the combination of the predefined model elements and the new security elements is possible. If we assume that a model gets extended with more and more functional and non-functional properties, the complexity of these models—which are rather complex by themselves—grows rapidly. In order to reduce this complexity, a development tool should be able to deliver different views for each stakeholder (see also [3]). A view can show only the important aspects and elements of a model which are intended to be viewed and edited. 2.2
Security Transformations
Apart from the possibility to clearly state the security requirements of a business process, another major purpose of the security modeling approach presented here is the ability to automatically generate appropriate security realization implementations from the model specification. These transformations take the given business process model and security model as input, generating a technical process description that can directly be deployed to an appropriate runtime environment, and already contains appropriate security enforcement techniques like data encryption and digital signature application. The intended target technology for this approach is the Web Services platform. The major advantage of this technology—especially regarding security—is that it provides a clear separation of concerns. For instance, a business process model can be transformed into an appropriate WS-BPEL process description,
which is ready-to-run itself—this actually has already been done, see e.g. [4]— and there is no need to cope with security issues so far. Once security requirements are stated, they can be expressed using WSSecurityPolicy documents that describe the security properties required for a Web Service at a technical layer. These security policies can then be linked to the service descriptions (WSDL) of the WS-BPEL process, automatically enabling the contained security assertions at the messaging layer (cmp. [5]). Thus, the security processing can be enabled and disabled by adding or removing a link to the WS-SecurityPolicy document within the service descriptions. The rest is done by the middleware framework. For the purpose of security model transformation the obvious transformation output is a set of WS-SecurityPolicy documents, annotating the service descriptions that are involved in the WS-BPEL process description. This output can be generated from the security model by iterating over the given model annotations, determining the involved Web Service endpoints between the security property’s start and end elements in the process model, and specifying an appropriate WS-SecurityPolicy for each of them. Once the full security model transformation is in place and covers all major security properties (e.g. confidentiality, data integrity, access control etc.), the task of enabling a security property for a given business process model can easily be performed by the process designer, the rest being performed by the security modeling tool. 2.3
Security Requirements
In the stage of business process design the security requirements are formulated taking into account known security issues. These requirements are closely related to the functional requirements, and often influenced by legal principles and rules—e.g. for the capital market (like SOX and BaselII) and for privacy and data protection (data protection laws)—and satisfy the security demands of the given processes and their regulatory framework. Commonly, security requirements are elaborated as security properties within policies, regulating the protected processes. These policies may be known publicly— like the WS-SecurityPolicy in Web Services—or may be declared business secrets for internal process management only. Independent from whether a policy is published or not, only a strict enforcement of its constraints enables the intended protection effects. Thus, policy decision and enforcement must be integrated within the security management. There are several security requirements a business process possibly must be aware of. Well-known elementary requirements are related to integrity, confidentiality, authenticity, and availability. More complex requirements demand access control, non-repudiation and responsibility definitions for automated data processing systems (e.g. required for data protection issues). In order to handle all these requirements and to ensure their achievement by given security properties, evaluating IT security is a proper instrument (cmp. [6]). A security model already containing all used security properties is a good
candidate for becoming a basis of such an evaluation. Thus, integrating the necessary formal argumentation into the security model enables security and data protection audits on the same model used for the software development.
3
Related Work
In this section, we discuss some related approaches, covering model analysis, transformation, and application for service-oriented architectures. In the model-driven software development the new application is defined with models. One possible kind are business models, which describe on a high abstraction level the desired behavior of the system. In [4] this business model is an event-driven process chain (EPC). This EPC is transformed in an executable workflow in BPEL. However, that approach is only an example for a special kind of model which transformation tasks need to be done in order to generate a software application. But for other types of models similar approaches exist to derive a software solution out of models. The quality of a software, which is developed with a software development process like the model-driven process, depends on the quality of its underlying models. To reduce the complexity of large process models techniques like Model Checking can be used. But this technique firstly was not intended to be use on the abstraction level of process models and workflows. However, that requirement could be achieved with the Temporal Logic Visualization Framework [7]. The framework enables the process modeler to specify functional requirements for process models as graphical rules instead of textual ones. A well-known approach for modeling of security properties is the UML extension UMLsec. The intended purpose of UMLsec is secure system development, and it allows modeling of common security properties, providing mathematical formalisms for security analyses. Examples for such a security analysis can be found in [8] and in [9]. Moreover, UMLsec is extensible for user-defined properties that are required within rather uncommon contexts (e.g. the responsibility property is required for privacy). Also, it adapts well the requirements of process modeling. For example, there is an approach using UMLsec for describing security properties related to data protection within the process model of biobanks [10]. However, when it comes to Web Services, the usage of BPMN or EPC process models often is preferred to UML, strengthening the need for a generic security model as described in Section 2.1. The idea of using a model-driven approach for enabling security properties for the particular target platform of Web Services can also be found in [11], to our knowledge the first approach of this kind. Nevertheless, that approach was limited to a particular process model and did not provide a full evaluation on the topic. Additionally, it did not cover other applications of a security model than code generation, as discussed in Section 2.3.
4
Conclusion and Future Work
The presented idea of a general security model that annotates any business process model has serveral advantages. At first, it enables modeling security requirements on a formal basis, helping in specification and verification of security requirements. Second, the ability to generate ready-to-run implementations that automatically stick with the security requirements specified in the model makes it much easier to embed security into a business process system.Finally, the approach enables the use of the security model in formal proofs on security-related properties on generated implementations. Nevertheless, such an approach must be able to exclude unnecessary information, preventing overinformation in regard to the different views. Thus, our future work focuses on definition and realization of a generic security model to be used for any kind of process modeling language, which would enable these advantages.
References [1] Charfi, A., Berbner, R., Mezini, M., Steinmetz, R.: Management Requirements of Web Service Compositions. In: WEWST. (2007) [2] Melnik, S.: Generic Model Management: Concepts and Algorithms. Springer Berlin Heidelberg (2004) [3] L¨ ubke, D., L¨ uecke, T., Schneider, K., G´ omez, J.M.: Using event-driven process chains for model-driven development of business applications. International Journal of Business Process Integration and Management (IJBPIM) (2008, to appear) [4] Stein, S., K¨ uhne, S., Drawehn, J., Feja, S., Rotzoll, W.: Evaluation of OrViA Framework for Model-Driven SOA Implementations: An Industrial Case Study. In: 6th International Conference on Business Process Management. (2008) [5] Gruschka, N., Luttenberger, N., Herkenh¨ oner, R.: Event-based SOAP Message Validation for WS-SecurityPolicy-enriched Web Services. In: Proceedings of the 2006 International Conference on Semantic Web & Web Services. (2006) [6] Weiß, S., Weißmann, O., Dressler, F.: A Comprehensive and Comparative Metric for Information Security. In: IFIP International Conference on Telecommunication Systems, Modeling and Analysis 2005 (ICTSM2005), Dallas, TX [7] Feja, S., F¨ otsch, D.: Model Checking with Graphical Validation Rules. In: 15th IEEE International Conference on the Engineering of Computer-Based Systems (ECBS 2008), Belfast, NI, GB, IEEE Computer Society (April 2008) 117–125 [8] Best, B., J¨ urjens, J., Nuseibeh, B.: Model-Based Security Engineering of Distributed Information Systems Using UMLsec. In: ICSE ’07: Proceedings of the 29th international conference on Software Engineering, Washington, DC, USA, IEEE Computer Society (2007) 581–590 [9] J¨ urjens, J., Schreck, J., Bartmann, P.: Model-based security analysis for mobile communications. In: ICSE ’08: Proceedings of the 30th international conference on Software engineering, New York, NY, USA, ACM (2008) 683–692 [10] Herkenh¨ oner, R.: Process Modeling for Privacy-conformant Biobanking: Case Studies on Modeling in UMLsec. In: Proceedings of the 6th International Workshop on Security Information Systems, Portugal, INSTICC Press (2008) 3–12 [11] Nakamura, Y., Tatsubori, M., Imamura, T., Ono, K.: Model-Driven Security Based on a Web Services Security Architecture. In: SCC ’05: Proceedings of the 2005 IEEE International Conference on Services Computing. (2005)