Aligning Mal-activity Diagrams and Security Risk Management for Security Requirements Definitions

Transcription

1 Aligning Mal-activity Diagrams and Security Risk Management for Security Requirements Definitions Mohammad Jabed Morshed Chowdhury 1, 2, Raimundas Matulevičius 1, Guttorm Sindre 2, and Peter Karpati 2 1 University of Tartu, Estonia 2 Norwegian University of Science and Technology, Norway, jabedmorshed@gmail.com, rma@ut.ee, {guttors,kpeter}@idi.ntnu.no Abstract. [Context and motivation] Security engineering is one of the important concerns during system development. It should be addressed throughout the whole system development process. There are several languages for security modelling that help dealing with security risk management at the requirements stage. [Question/problem] In this paper, we are focusing on Malactivity diagrams that are used from requirement engineering to system design stage. More specifically we investigate how this language supports information systems security risks management (ISSRM). [Principal ideas/results] The outcome of this work is an alignment table between the Mal-activity diagrams language constructs to the ISSRM domain model concepts. [Contribution] This result may help developers understand how to model security risks at the system requirement and design stages. Also, it paves the way for interoperability between the modelling languages that are analysed using the same conceptual framework, thus facilitating transformation between these modelling approaches. Keywords: Mal-activity diagrams, Information system security risk management, Requirement engineering, Risk management. 1 Introduction Nowadays, business critical functions in various organisations depend on information systems (IS). Thus, the significance of security technologies in IS is widely accepted and receiving increased attention. But the security is not free; it requires investment. The return on security investment (ROSI) has become a major concern [5] in many organisations. This involves a risk management process to justify investment for security measures. To support systematic security risk management, security should be addressed and realised at all the stages of IS development. Different modelling approaches (e.g., [3] [4]) have been proposed to cope with security in different development stages. In this work we focus on Mal-activity diagrams [6] to define security requirements. Mal-activity diagrams, henceforth, abbreviated MAD, are proposed as an extension of UML activity diagrams. Their major objective is to describe procedural logic, business process, and workflow. MAD B. Regnell and D. Damian (Eds.): REFSQ 2012, LNCS 7195, pp , Springer-Verlag Berlin Heidelberg 2012

2 Aligning Mal-activity Diagrams and Security Risk Management 133 extend activity diagrams with harmful behaviour of security attackers. A basic way to build a MAD is to draw a normal process first, then add unwanted behaviour by extra concepts, such as Mal-activity, Mal-swimlane and Mal-decision. In [6] MAD were applied to model 46 social engineering scenarios. However, they still lack clear and structured application guidance. In this paper, based on the running example, we align MAD to the domain model of the information systems security risk management (ISSRM) [2] [5]. This yields a grounded and fine-grained reasoning for how MAD can be used to understand system security risks. The analysis is illustrated through a running example gradually establishing guidelines for the application of MAD. The structure of this paper is as follows: Section 2 introduces the ISSRM domain model, which is the basis for analysing MAD. Section 3 illustrates how MAD could be applied for security risk management and how Mal-activity constructs are aligned to the concepts of the ISSRM domain model. Section 4 presents the lessons learnt. 2 The ISSRM Domain Model A domain model (Fig. 1) for IS security risk management (ISSRM) [2] [5] is influenced by and derived from different security risk management standards and methods, security-related standards, security-oriented frameworks (see [2] and [5] for concrete details). We have selected ISSRM to analyse MAD because it has already been successfully applied to analyse other security-modelling languages (see [3] and [4]). In addition, this domain model defines security risk management concepts at three interrelated levels, which help developers identify specific IS security risk management constructs of the analysed language. Fig. 1. The ISSRM Domain Model (adapted from [2] [5]) Asset-related concepts (i.e., business and IS assets, IS assets, and security criterion) explain the organisation s values that need to be protected. The needed protection level is defined as the security needs, typically in terms of confidentiality, availability and integrity. Risk-related concepts (i.e., risk, impact, event, vulnerability, threat, attack

3 134 M.J. Morshed Chowdhury et al. method, and threat agent) define the risk itself and its components. Risk is a combination of threat with one or more vulnerabilities, which leads to a negative impact, harming some assets. An impact shows the negative consequence of a risk on an asset if the threat is accomplished. A vulnerability is a weakness or flaw of one or more IS assets. An attack method is a standard means by which a threat agent executes a threat. Risk treatment-related concepts (i.e., risk treatment decision, security requirement and control) describe how to treat the identified risks. A risk treatment leads to security requirements mitigating the risk, implemented as security controls. 3 Alignment of MAD to ISSRM Our research goal is to understand how MAD help model assets, security risks, and countermeasures during IS development. We approached this goal through three steps. Firstly, we developed a meta-model for Mal-activity diagrams in [1]. The second step was to understand how MAD could be applied to manage security risk and how their constructs correspond to the concepts of the ISSRM domain model. We approach this goal through a running example from online-banking discussed in Section 3.1. Finally, we have recorded the observations and discuss them in Section Running Example The running example describes a correspondence between a bank officer and customer, and how a hacker could potentially harm such a correspondence. We model it using MAD following the steps of the ISSRM process [2] [5]. The ISSRM process consists of six steps. The first step is content and asset identification. Fig. 2 shows a Bank officer s request to the bank Customer to update the home address using the Online banking system. Hence the major business process starts by request to update home address sent by the bank officer and continues to activities executed by Customer, e.g., Open , Agree to update home address, etc. Each business activity requires support from the Online banking system; for example, after the customer opens the (see activity Open ), content is displayed (see activity Display content). The second ISSRM step is security objective determination. In our example these are integrity of the home address updating process and confidentiality of the login name and password. The third ISSRM step is risk analysis and assessment. Fig. 3 introduces a Hacker who sends an with malware to the Customer. If the customer opens the the malware is installed in the Online banking system. Using this Malware, the Hacker is capable to receive customer s login name and password. In the fourth step the risk treatment decision in our case, a decision to reduce risk is made. The fifth step is security requirements definition. In Fig. 4 we introduce activities, such as Enable filtering, Check for malware, and Enable traffic scanner, which potentially reduce the effect of the mal-activities. Finally, the sixth step of ISSRM is security control selection and implementation. 3.2 MAD and the ISSRM Domain Model Our observations are summarised in Table 1.

4 Aligning Mal-activity Diagrams and Security Risk Management 135 Fig. 2. Content and Asset Identification Fig. 3. Risk Analysis

5 136 M.J. Morshed Chowdhury et al. Asset-related Concepts. The ISSRM asset represents something of value for the organisation. The business asset is defined as the information, process, or skill that is essential for the business. Activity diagrams are used to show the (business) workflow by combining together constructs, like: Activity, Decision and ControlFlow. We map these constructs to the ISSRM business asset. In addition we recognise that data (e.g., Login name and password) could be important to business participants. Thus, implicitly we can identify such data as an ISSRM business asset, too. The ISSRM IS asset is an IS component that supports a business asset. The Swimlane construct (e.g., Online banking system) holds the constructs (i.e., like Activity and Decision) that are needed to support execution of business workflows. Thus we align all these constructs (i.e., Swimlane, Activity, Decision and ControlFlow) to the IS assets. So, we consider Activity, Decision, ControlFlow and Swimlane as IS asset. We find no construct that would help representing the ISSRM security criterion. However the diagram gives an implicit understanding (see Table 1) of such criteria regarding the business assets. Fig. 4. Security Requirements Definition Risk-related Concepts. An ISSRM threat agent is characterised by expertise, available means and motivation to harm the IS, and the ISSRM attack method are means by which a threat agent carries a threat. In MAD, Mal-swimlane is used to define malicious actor (e.g., Hacker) that will harm the system by malicious activities (e.g., Send with malware), i.e., the Mal-activity constructs that are combined using Mal-decision and ControlFlow constructs. We align Mal-swimlane to the ISSRM threat agent and process defined by combining Mal-activity constructs, to the ISSRM attack method. In

6 Aligning Mal-activity Diagrams and Security Risk Management 137 addition we observe that in MAD the malicious actor could use some means (e.g., Malware), which are defined as Mal-swimlane. Thus we align the Mal-swimlane construct to the concept of ISSRM attack method, too. Although we are able implicitly to define the vulnerabilities of the modelled system (see Table 1), we have not found any Mal-activity construct to represent the ISSRM vulnerabilities. Asset Table 1. Alignment Between MAD and ISSRM Domain Model ISSRM domain model Mal-activity diagram Example Asset Business asset Risk Risk treatment IS asset - Process described using Activity, Decision and ControlFlow constructs. - Objects used to perform activities (implicit) - Swimlane; - Activity, Decision (connected using ControlFlow constructs) - request to update home address, Open , Agree to update home address, Enter login name and password, and Update home address; - Login name and password. - Online banking system; - Validate user, Register , Display , Load website, Validate user, Is valid?, Redirect..., and Send error message. Security criterion Integrity of the message sending process; Confidentiality of login name and password. Risk Impact Mal-activities Silent installation of malware, Capture/Send login name and password Event Vulnerability No scanning, No installation controls, No controls for outgoing traffic. Threat Combination of constructs Hacker Sends an with malware and that represent a Threat agent Receives login name and password. and Attack method Threat agent Mal-Swimlane Hacker Attack method - Process described using Mal-activities, Mal-decision, and ControlFlow - Mal-Swimlane - Send an with malware and Receive login name and password; - Malware. Risk treatm. Risk reduction. Security requirement MitigationActivity, MitigationLink Enable filtering, Check for malware, Enable traffic scanner. Control Swimlane Security module The ISSRM impact is a negative consequence of a risk that harms two or more assets (at least one business and one IS asset). In MAD we can express the ISSRM impact using Mal-activity constructs that belong to the Mal-swimlane, characterised as the ISSRM attack method. For example, in Fig. 3 Mal-activity Silent installation of malware shows how the Online banking system (an ISSRM IS asset) is harmed by illegal installation of malware; Mal-activity Capture login name and password illustrates how this risk harms the business asset, i.e., the login name and password; finally Mal-activity Send login name and password to hacker specifies negation of the ISSRM security criterion, i.e., the Confidentiality of login name and password.

7 138 M.J. Morshed Chowdhury et al. Risk Treatment-related Concepts. In MAD the MitigationActivity construct is understood as a countermeasure (i.e., ISSRM security requirement). The Swimlane (e.g., Security module in Fig. 4) holding the MitigationActivity constructs implements the countermeasures. Thus, we align such a Swimlane to the ISSRM controls. 4 Lessons Learnt This paper has shown how the ISSRM domain model could guide application of MAD. Our analysis has a certain level of subjectivity to interpret the language constructs regarding the ISSRM concepts. To mitigate this threat other examples could be analyzed by other people (e.g., practitioners, if they are willing to use MAD). Our study results in the alignment of the Mal-activity constructs to the ISSRM domain model. This has shown several limitations of MAD to address security risk: MAD do not provide guidelines on how to use its constructs. For example, Activity addresses both the ISSRM business asset and IS asset; Mal-activity represents both the ISSRM impact and attack method; and others. MAD are unable to specify some ISSRM concepts, like security criterion, vulnerability, event, and risk. Although risk and event constructs could be expressed using other constructs, constructs for security criterion and vulnerability should be introduced. Anyway, the ISSRM process helps developers understand (not represent) these concepts, at least implicitly. MAD is not the only language assessed for the IS security risk management. The ISSRM domain model has been used to evaluated Secure Tropos [4], misuse cases [3], and KAOS extensions to security [5]. We envision that after analyzing a number of security languages it will be possible to facilitate model transformation and interoperability between different security languages that are analysed using the ISSRM domain model. This would allow representing IS using different perspectives and ensuring IS sustainability through different development stages. Acknowledgement. This research is partly funded by an ETF grant (contract number ETF8704, Estonian Science Foundation). References 1. Chowdhury, M.J.M.: Modeling Security Risks at the System Design Stage: Alignment of Mal-activity Diagrams and SecureUML to the ISSRM Domain Model. Master Theses (2011), 2. Dubois, E., Heymans, P., Mayer, N., Matulevičius, R.: A Systematic Approach to Define the Domain of Information System Security Risk Management. In: Nurcan, S., Salinesi, C., Souveyet, C., Ralytė, J. (eds.) International Perspectives on Information Systems Engineering, pp Springer, Heidelberg (2010) 3. Matulevičius, R., Mayer, N., Heymans, P.: Alignment of Misuse cases with Security Risk Management. In: 3rd International Conference on Availability, Reliability and Security, pp IEEE Computer Society, Washington (2008)

8 Aligning Mal-activity Diagrams and Security Risk Management Matulevičius, R., Mayer, N., Mouratidis, H., Dubois, E., Heymans, P., Genon, N.: Adapting Secure Tropos for Security Risk Management in the Early Phases of Information Systems Development. In: Bellahsène, Z., Léonard, M. (eds.) CAiSE LNCS, vol. 5074, pp Springer, Heidelberg (2008) 5. Mayer, N.: Model Based Management of Information System Security Risk. Doctoral Thesis, University of Namur (2009) 6. Sindre, G.: Mal-Activity Diagrams for Capturing Attacks on Business Processes. In: Sawyer, P., Paech, B., Heymans, P. (eds.) REFSQ LNCS, vol. 4542, pp Springer, Heidelberg (2007)