A method defines a systematic process for problem solving including the required aids and resources. The transfer of method knowledge from the developers to other users requires a certain level of maturity and documentation of the method. Based on a method for security requirements elicitation from business processes (SREBP), we demonstrate how approaches from method engineering can be used to refine methods and improve transferability and maturity of method descriptions. The contributions of the paper are (1) to show how a component-based method view can be applied in method refinement, (2) the actual refinement process for SREBP integrating work procedure, cooperation principles and notation, and (3) initial experiences and lessons learned from refining SREBP.
Security engineering plays an important role in lowering the risk of intentional harm
to valuable assets (such as preventing and reacting to malicious harm, misuse, threats
and security risks) [
There are several studies, which tries to target the above problem by enforcing
security mechanisms. For instance, the UMLsec approach [
A method for security requirements elicitation from business processes (SREBP)
is suggested in order to support identification of the security criteria and the guided
derivation of the security requirements from the business processes [
The scope of this paper is to report on experiences and lessons learned from refining the SREBP method with concepts from method engineering. In general terms, a method defines a systematic process for problem solving, which encompasses the required aids and resources. Many technology and engineering disciplines use methods as a way to capture proven practices and to provide guidance for specific tasks. In computer science and business information systems, methods also address the development processes of various kinds of models, e.g. business process models or enterprise models, and the analysis and transformation of models. Development of methods is a complex process as methods should be grounded in solid experiences, and iteratively refined in many application cases in order to reach a sufficient maturity level. In particular when method knowledge is transferred from the developers of a method to new method users, both the method documentation and the method as such need to have a high level of maturity and detail.
Using a component-based method view proposed by Goldkuhl et al. [
The paper is structured as follows: Section 2 discusses the experienced challenges when transferring knowledge about SREBP. In Section 3 we introduce the SREBP method and the principles of the method engineering. In Section 4 we present the refinement of SREBP following the method development process. Section 5 discusses the observations. Finally conclusions and future work are given in Section 6.
Work presented in this paper is based on the project “Improvement of IT-Security in Enterprises based on Process Analysis and Risk Patterns (ITSE)” which has university partners from three different countries: Estonia, Latvia, and Germany. The main goal of the project is to transfer the SREBP method to the practice of small and mediumsized enterprises (SME), including the creation of a set of guidelines. To illustrate its usefulness and completeness, SREBP will be used by all three university-partners in their regions. For this purpose, knowledge how to use the SREBP method has to be transferred from the SREBP developers (University of Tartu) to the other two university partners. The process of knowledge transfer was jointly designed by all partners and includes several steps: 1. Scientific publications about SREBP are provided to offer first information about the general idea and basic concepts; 2. A tutorial is developed by Tartu University encompassing not only SREBP as such but basic concepts from IT security and security engineering; 3. A joint workshop is organized which consists of teaching the actual tutorial, discussing the scientific publications and selecting pilot cases to apply SREBP; 4. During the pilot cases, the SREBP developers serve as coaches for the method users; based on the results from workshop and pilot cases, SREBP is refined and documentation is enhanced; 5. The refined SREBP version serves as basis for eliciting IT security requirements in actual SME cases.
When writing this paper, step 4 was still on going and step 5 was under preparation. However, the workshop on SREBP (step 3) resulted in some lessons learned and requirements to be taken into account during method improvement: • Terms and concepts used in SREBP need to be documented in more detail to avoid ambiguity and misunderstandings. An example is the term “business asset”, which from an IT security perspective includes any resource or information to be protected. Whereas from an economics perspective only those resources are considered, which can be valued and reflected in the balance sheets. • The prerequisites for using SREBP need to be made explicit. This includes both the competences that users should have (e.g., knowledge about IT security and process modelling) and the information, which should be included in the process models (e.g., resources and IT components accessed, processes to be represented). • Whether or not the SREBP activities have to be performed in always the same order. What other different sequences make sense. An example is whether always the general view on value creation areas is needed first or SREBP can immediately start by analysing a specific process. • SREBP uses four “business perspectives” which are also part of many existing enterprise or process modelling methods. But at closer inspection these are different from other approaches. Thus they need detailed explanation.
This section summarises the background for our work, which consists of SREBP and its basic features. It also introduces relevant work from method engineering. 3.1
As illustrated in Fig. 1, the SREBP method [
(i) Identify business assets: During this activity the central artefact (or artefacts) considered in the value chain is identified. The enterprise’s value chain can either have a single artefact used in all the processes or comprised of multiple artefacts in each operational business process.
(ii) Determine security objectives: The activity addresses determining of key security objectives – confidentiality, integrity and availability – for identified business assets. Here confidentiality describes a property of being made disclosed to unauthorised individuals, entities or processes. Integrity is a property of safeguarding the accuracy and completeness of the business asset. And availability describes the property of being accessible and usable upon demand by an authorised entity.
Security requirements elicitation. In [
Application of the pattern within each contextual area consists of three steps. The
first step is pattern identification in business process diagram. Pattern identification
potentially could be performed using hierarchical level matching, business
perspective matching, structural similarity and semantic similarity methods [
The research area of method engineering offers a rich body of knowledge how to
systematically develop, introduce and adapt “methods”. Methods often are considered
as prescriptive since they are supposed to provide guidance for problem solving or for
performing complex tasks. This requires that a method would include what activities
to perform, how to perform them (procedure), what results (artefacts) to develop, and
how to capture these results (notation) [
Different conceptualizations of the term “method” and related terms have been
proposed. If there is a close link between procedure, notation, and concepts, the term
method component is used [
For the purpose of refining SREBP, a component-based method view is
considered favourable since SREBP includes several activities, which potentially can
be performed in different order or even are optional in certain situations. The method
conceptualisation proposed by Goldkuhl et al. [
Perspective: every method describes the procedure for the modelling process from a particular perspective, which influences what is considered important when developing a model. This perspective often is related to the aims and purpose of the method. The case discussed in Section 2 showed that transferring knowledge about SREBP could be eased by making improvements in the method or its documentation. This section first performs an analysis of SREBP using Goldkuhl’s conceptualization and then identifies what refinements of SREBP are made based on the analysis results. The approach used in this section for analysing SREBP with respect to potential refinements is to check (a) whether the elements identified by Goldkuhl are defined for SREBP and (b) where the different elements were documented and if the documentation was detailed enough. Observations are listed in Table 1. Method element Perspective Framework
The first observation made during SREBP analysis is that there is no single SREBP document, which would contain all elements recommended by Goldkuhl et al. in an integrated way. This is not really surprising because SREBP was not developed with this method conceptualization in mind. The perspective of SREBP is explicitly defined in several publications and tutorial. Hence the focus on IT security requirements elicitation from business processes is made clear.
The framework defining the way of using method components in combination with each other and potential alternative sequences so far only is implicitly defined. In all examples showing the use of SREBP and in the overall description, the typical flow of activities is represented without commenting on alternatives. Here, dependencies between steps and possibilities to adapt according to different situations have to be made clear. Method components were not explicitly defined, but the method shows several clearly separable steps, which obviously could be considered as “components”: the analysis of the overall value creation areas, the analysis of a business process and the use of security patterns – to name the most obvious examples. For each of these potential components, there foremost is a description of the procedure and in most case a way to represent the results of the steps, which often is not an explicitly defined notation but more a representation of results “by example”. The important concepts are mentioned and discussed in the scientific publications but not exposed in the description of the procedures.
The cooperation principles are not documented at all in the written SREBP material. However, discussion with the method developers showed that they have a clear picture regarding the required competences and what roles need to be established and filled during analysis. This knowledge has to be made explicit. 4.2
Perspective. The major goal of the SREBP method is to identify the enterprise’s assets, determines their security objectives, and elicits security requirements in order to reason on and ensure the security during the execution of business process. The method integrates security in processes to facilitate business analyst in understanding and deriving the security requirements from the business process models.
Cooperation. Typically security engineering requires a close collaboration between the business analyst (i.e., the specialist of the business domain) and security analyst (i.e., the specialist of the security domain). Being experts in business domain, business analysts have limited or no expertise in security engineering. They have to rely on the best security practices, information security standards, or security experts.
Business analyst introduces business context to security analyst. On one hand business analyst as an expert of business domain, describes organisation’s work-flow. On another hand the goal of security analyst is to understand what business values are described in the business model. In other words security analyst (through collaboration with business analyst) identifies what business assets are, what security objectives (in terms of confidentiality, integrity, and availability) should be taken into account, and what are the IS assets to support the identified business assets.
Once the security requirements are derived from the business process models, they can be used to annotate the original business process model. The artefact that is returned to the business analyst is the business process model annotated with security requirements. But the feedback could also include security risk models. Another cooperation might be on security requirements trade-off analysis. However this activity is not emphasised in the SREBP method.
Method components. Refinement of the SREBP method components is
illustrated in Table 2. In the first column this table includes all the major concepts
used in the SREBP method. Majority of these concepts, like business asset, security
criterion, information systems (IS) asset, security risk, and security requirements are
taken from the domain model for the information systems security risk management
(a.k.a., ISSRM) [
These diagrams should express the use of data objects, data flows and data stores.
Identified from the value chain Identified by understanding importance of the business assets Identified when analysing the business process diagrams Identified from the business process diagrams by instantiating the security risk-oriented patterns Identified from business process diagram by applying the security risk-oriented patterns and by instantiating pattern security parts Artefact used to guide security risk requirements derivation from the business process diagrams. The patterns describe recurring security risks that arise within business processes. To mitigate the risks, the patterns recommend security requirements.
Identified in the business process diagram using security risk oriented patterns Derived from the business process model and the result of security risk-oriented pattern application.
Notations
BPMN
BPMN
Initially documented
textually, later refined
graphically depending on
various security model
notations
Security risk-oriented
BPMN [
In the second column of Table 2 we define the procedures used to identify the relevant concepts. Hence the business analyst creates value chain and business process diagrams as the part of the organisations business process management. The asset-related concepts are identified from the value chain and business process diagrams, and security risk-related and risk treatment-related concepts are defined using the security risk-oriented patterns.
The third column presents the notations used to represent concepts. A notable set
of concepts is expressed using the textual language, which is supported with the
targeted graphical notations. Since SREBP is meant to consider business processes,
majority of the notations are BPMN or security risk-oriented BPMN [
Framework. In Fig. 3 the relationships between the individual SREBP method components are described. Hence, the Business Process Diagrams expands separate actions represented in the Value Chain diagram. The Business Assets are elicited from the Value Chain. As described above the security analyst in cooperation with business analyst determines Security Objectives each identified Business Asset. IS Assets support Business Assets, which are also refined when considering the Business Process Diagrams. When applying Security Risk-oriented Patterns, Pattern Occurrences are found in Business Process Diagrams. Pattern Occurrences result in Security Model, which is extracted from Business Process Diagram based on the used Security Risk-oriented Pattern. Security Requirements are derived from the Security Model and they define the security constraints on the Assets.
Fig. 4 presents a high level SREBP process. As discussed in Section 3.1, the SREBP method consists of two stages. In the first stage one needs identify business assets and determine security objectives. In the second steps, the main activities include (i) identification of the patterns, (ii) extraction of security model based on the pattern occurrences, and (iii) derivation of the security requirements.
During the first step, one performs activities (like hierarchical level matching,
business perspective matching, structural similarity and semantic similarity matching
[
Method analysis and method refinement described in Section 4 resulted in some observations, which will be discussed in this section. One observation concerns the suitability of Goldkuhl’s method conceptualization. The general impression was that the method conceptualization by Goldkuhl et al. proved to be suitable and applicable. The method developers perceived the conceptualization and its way to decompose a method into different elements as helpful in the overall refinement process. The elements were used as a “checklist” for investigating what potential improvements and refinements are possible and could make sense. However, two elements of Goldkuhl’s method view needed specific explanation. The term „perspective” had a tendency to confuse the method developers due to the more philosophical interpretation Goldkuhl et al. use in their work. An interpretation of perspective as the „purpose” of the method helped to avoid this confusion. Furthermore, the term “framework” was conceived as misleading as it could be interpreted as conceptual framework of the notation used. Thus, we clarified framework as giving an overview to method components and their inter-dependencies.
For the purpose of method knowledge transfer, in particular the “cooperation principles” and the “concepts” within a “method component” were considered as very valuable since speaking the same language (i.e. using the same concepts with an agreed-on meaning) and explicitly stating requirements with respect to the competences of the method users showed to be crucial for transferring the knowledge. SREBP previously primarily was used in a team at Tartu University who had been cooperating during many years. In such a situation, there is much implicit knowledge shared by the team members, which needs to be made explicit when transferring knowledge to outsiders. In this context, explanations of important concepts help to avoid misunderstandings. Furthermore, SREBP method users have to be expected to have at least a basic level of knowledge in IT-security and process modelling.
In Section 4.2 we have refined or intend to refine the SREBP method following the requirements listed at the end of Section 2. We acknowledge the need to provide more detailed explanations of the SREBP terms and concepts. We have started this process in Section 4.2, how due to the limited space he we include only limited explanations. A separate technical report needs to be prepared to clarify these terms. Next, we highlight the procedures and prerequisites needed to execute the SREBP method. For example, we stress that the business process diagrams need to be prepared in the way so that the used data and data stores would be represented in these diagrams. Finally, some activities of the SREBP method should be always executed in the same order (e.g., see Fig. 3). But some activities especially when analysing different contextual areas (e.g., see Fig. 4), could be executed in different order or even skipped from the analysis if the specific contextual area is outside the scope. 6
Based on lessons learned from transferring knowledge about the SREBP method from
method developers to new method users, the paper investigated refinement potential
of SREBP and proposed changes in SREBP. The basis for identifying refinement
potential was a decomposition of SREBP using a proven approach from method
engineering, Goldkuhl et al.’s [
Future work in this area primarily has to focus on evaluating (a) the refined SREBP version as such in real-world cases and (b) the suitability of the documentation of the refined SREBP for knowledge transfer to new method users. The former is directed to the quality of SREBP to elicit security requirements whereas the latter addresses completeness and understandability of SREBP usage and its prerequisite. Thus, we started method transfer and method usage activities within the ITSE project.
This paper of the Baltic-German University Liaison Office is supported by the German Academic Exchange Service (DAAD) with funds from the Foreign Office of the Federal Republic Germany.