T e c h n i c a l R e p o r t N
O2014/ 01
An Architecture for Adaptive Information
Security in Cloud Applications
Thein Tun and Armstrong Nhlabatsi and Niamul Khan and Arosha
Bandara and Khaled Khan and Yijun Yu and Bashar Nuseibeh
29 April, 2014
Department of Computing
Faculty of Mathematics, Computing and Technology
The Open University
Walton Hall, Milton Keynes, MK7 6AA
United Kingdom
Information Security in Cloud Applications
Thein Tun1, Armstrong Nhlabatsi2, Niamul Khan2, Arosha Bandara1,Khaled Khan2, Yijun Yu1, and Bashar Nuseibeh1,3
1The Open University, UK 2Qatar University, Qatar
3Lero, Ireland
{t.t.tun;a.k.bandara;y.yu;b.nuseibeh}@open.ac.uk {a.nhlabatsi;niamul.khan;k.khan}@qu.edu.qa
Abstract. With the increasing popularity of networked mobile devices, many users depend on cloud infrastructures for both data storage, and application services. Mobile users operate in highly dynamic contexts, resulting in an information security environment where the assets, their values, and attack scenarios can easily change from one situation to an-other. This creates a significant run-time challenge of determining na-ture, ownership and vulnerabilities of information assets, and the extent to which security requirements are being satisfied. This paper proposes an architecture for adaptive information security, which enables cloud services to be responsive to the changing user requirements in a dynamic context. Components of on the client side of the cloud services monitor the user context and infer the likely user requirements for security. Com-ponents on the server modify the services offered to the user according to the monitored context and inferred requirements, based on organisa-tional policies. Security policies are enforced both on the client and the server sides. We illustrate the proposed architecture by re-engineering an open-sourced file sharing system called *ownCloud*, so that its services are adaptive to the dynamic security contexts.
1 Introduction
With the popularity of mobile and ubiquitous computing infrastructure, such as the cloud, the technical and social contexts in which software applications are expected to operate are increasingly dynamic. As a result, the assets, their values, and attack scenarios can easily change from one situation to another. This increases the challenge of finding out what the information assets are, who their owners are, where in the system vulnerabilities lie, and the extent to which the security requirements are satisfied [1].
In such dynamic environments, information security has to be highly context-sensitive: software applications must adapt to the changing contexts and respond quickly and appropriately to ensure that the requirements for information secu-rity are not violated. We call this notion Adaptive Information Secusecu-rity. Follow-ing the existFollow-ing work on requirements engineerFollow-ing,security requirements mean
requirements related to the protection of critical assets from threats and attacks by means of risk assessment and countermeasures [1]. Similarly, context means the structure and properties of the environment that the software depends on when satisfying the requirements [2, 3].
This paper suggests that there are three prerequisites for adaptive informa-tion security in the context of cloud computing: (1) understanding user security requirements for cloud applications; (2) traceability between security require-ments, design and implementation of some cloud services; and (3) adaptive se-curity design for dynamic contexts. Sese-curity requirements engineering entails understanding user information security requirements for cloud applications by providing representation and elicitation techniques for uncovering such ments. The recovery and maintenance of traceability between security require-ments and design, both at the design time and runtime, is fundamental to ensur-ing that user requirements for information security are satisfied as the context changes. Policy-based approaches provide an effective mechanism for implement-ing adaptive security in cloud applications.
Towards this end, this paper proposes an architecture for implementing adap-tive information security in cloud applications. In this architecture, the adapadap-tive security is achieved by dividing the responsibilities between the components on the client and the server sides. Client-side components focus on monitoring the changes in the user contexts and requirements that warrant modification of the system behaviour. Server-side components provide adaptive mechanisms for en-forcing security, both on the client and the server sides. A key element of this architecture is that it does not assume a green field development where cloud applications are developed from scratch. In fact, it assumes that the cloud ap-plications are already developed, and possibly deployed, but they need to be adaptive in order to ensure security in a dynamic context.
Whilst cloud computing services can adopt different models, such as Infras-tructure as a Service (IaaS), Platform as a Service (PaaS) and Application as a Service (AaaS), security challenges need to be addressed in each layer of such a service stack. The focus of our work, namely the requirements for informa-tion security, adaptainforma-tion, software design, and the traceability between require-ments and design, is mostly related to AaaS because this is where cloud service providers have greatest responsibility for security.
The rest of this paper is structured as follows. Section 2 discusses the key re-search questions in our broader rere-search agenda, and relates them to the existing research. Section 3 explains the proposed architecture for adaptive information security. A demonstration of the proposed architecture with the case study of
ownCloud is detailed in Section 4. Discussion and conclusion, as well as, an agenda for future work can be found in Section 5.
2 Background
This section discusses the aim and research questions we are investigating, and relate them to relevant existing research work.
2.1 Research Questions
The broader aim of our work is to develop a tool-supported approach to elicit and relate information security requirements to design and implementation, in order that cloud applications are able to adapt to dynamically changing contexts whilst maintaining security. Several research questions need to be addressed in order to achieve the aim. These questions include: How can requirements for adaptive information security be elicited for cloud applications? What kinds of traceability between static (design time) models and dynamic (runtime) models can be analysed and used to in order to support security analysis and adaptation? How can users monitor the extent to which their requirements are being satisfied as cloud services and applications evolve? What is the infrastructure needed for adaptive assurance mechanisms to work effectively in the cloud? What is the best way to assure users about the security of their data?
In order to investigate these questions, this paper proposes an adaptation architecture for cloud applications which will enable us to investigate those and related questions.
2.2 Related Work
Security vulnerabilities in cloud applications can be introduced or removed at any stage of the development lifecycle: from requirements to design to imple-mentation. As such, there is a range of research work examining security in cloud applications from different perspectives. In this section, our review focuses on requirements engineering, traceability between requirements and design and implementation, as well as
Security Requirements. Several requirements engineering approaches to sys-tem security have been surveyed by Nhlabatsi et al [4]. Rushby [5] discusses the difficulties of expressing security requirements. Liu et al [6] present a systematic process to analyse security requirements in a social and organi-sational setting. Crook et al [7] introduce security requirements as negative requirements, or anti-requirements. These are requirements of a potential malicious (or at least intentional) attacker of a system. Lin et al [8] extend these ideas by considering various patterns of anti-requirements, known as “abuse frames”. Lamsweerde [9] refines anti-goals in order to identify obsta-cles to security goals, and generate countermeasures. Haley et al [3] propose an argumentation framework to reason about security requirements, which is applied to an ATM system in [10]. In our recent work on security require-ments [11], we have shown that publicly available catalogues such as Com-mon Attack Pattern Enumeration and Classification (CAPEC) and ComCom-mon Weakness Enumeration (CWE) provide a rich source of anti-requirements. However in existing requirements engineering approaches, support for the elicitation and analysis of requirements for information security of cloud ser-vices and applications is limited. For instance, it is not yet known how dy-namic contexts of cloud applications can be described, and how requirements
and contexts of cloud applications can be related. A method for analysing adaptive information security requirements and assessing the degree of their satisfaction is still need for both cloud service providers and users.
Traceability. Traceability from requirements to design is the key for under-standing an evolving system and making necessary changes in response to user requests [12]. The notion of invariant traceability, where the traceability between the design and requirements holds even when the system undergoes changes have been shown to be effective [13, 14]. Work of invariant trace-ability has been demonstrated on the mission critical crypto protocol in the design of the SSL handshake protocol [15]. Although high-level frameworks for relating requirements and architecture have been proposed [16], it is still an unanswered question as to how the information security requirements and the run-time configuration of software components can be related. Indeed, the question of how to recover traceability links between information secu-rity requirements and static design for cloud applications and services is an open research question.
Adaptation. Adaptation in the face of changing contexts requires concrete mechanisms by which a system can change its behaviour in response to changes in its operating environment. Policy-based approaches are ideally suited to supporting these adaptation needs because they separate the imple-mentation of functional components of a system from its run-time behaviour. The functional components of the cloud system include those involved in access control, auditing, identity management and authentication [17] and policy rules are used to modify the behaviour of these components based on the context.
Policy-based management techniques in networks and distributed systems [18], particularly in cloud applications [19], suggest some interesting approaches to satisfying security requirements in dynamic operating environments. There is a need to maintain the system security by monitoring the context of a system, and dynamically switching to a satisfactory configuration through dynamic policy enforcement. Current access control policy languages and enforcement mechanisms are typically regarded as separate from the system design and requirements. Furthermore, existing approaches to access con-trol policies generally focus on a priori analysis. For cloud applications, a posteriori analysis is essential for assuring users about the security of their data.
In addition to mechanisms for adaptation, there is also a need for require-ments engineers to be able to express the requirerequire-ments for adaptation. For instance, Whittle et al [20, 21] have proposed a new requirements language called RELAX, which supports a fuzzy logic-based approach to analysing uncertainty in adaptive systems. Our work on adaptation requirements [22] highlights the need for a self-protection mechanism in order to enforce the continuous satisfaction of information security.
In summary, the increasing use of cloud application and services in dynamic contexts will generate vast amounts of user data, access to which needs to be
specified, controlled, and monitored. Existing approaches to requirements engi-neering, traceability and adaptation are not fully adequate in addressing these challenges.
3 Adaptive Information Security (AIS) Architecture
The proposed architecture for adaptive information security (Fig. 1) envisages that the cloud services, provided by a server, are accessed by users using mobile and other computing devices. The Applications box inside User Device repre-sents the client software used to access cloud services, whilst the Services box insideCloud Server represent the stack of cloud services such as AaaS and IaaS. These two boxes by themselves would constitute typical cloud applications with little or no adaptation capabilities. Our proposal is to integrate some additional components in order to make those existing cloud applications adaptive to chang-ing security context.Fig. 1.Proposed Architecture for Adaptive Information Security
In the AIS architecture, user and organisational requirements for information security, as well as the user context, drive the adaptation. As the user interacts with applications, the AIS Monitor components attempt to infer the likely user context and the security requirements, and modify the application behaviour according to the adaptation strategy provided by the server. TheAIS Controls
components on the server make use of the inferred security requirements and context from the user device in order to evaluate the security policies and the adaptation strategy needed in a specific context.
3.1 AIS Monitors
Components inAIS Monitors are mostly related to the user requirements, con-text and the traceability with the design. More specifically:
Context Monitor. This component logs and infer the likely user context that may be relevant to the security requirements. For example, on the user device of Adam’s, it frequently logs Adam’s location, and infers whether he is in office or not (Fig. 1). Depending on the applications and the device used, the log information may include the user location, user activities on the device, date and time, as well as ephemeral information such as the battery life and network bandwidth available. The frequency at which the information is collected may also depend on the device capacities and the organisational information security goals.
Date & Time GPS Wifi SSID Activities · · · Inferred Context
140125 12:33 12.856231, -0.126567 secure-corp Angry Birds · · · User in office
140125 12:50 12.856243, -0.126563 secure-corp PowerPoint · · · User in office
140125 14:28 12.856220, -0.126522 secure-corp Skype · · · User in office
140125 20:13 51.205230, -0.585510 hello-home Angry Birds · · · User at home
140126 10:02 51.205230, -0.585510 hello-home VPN, MS Word· · · User working from home
140127 11:24 12.856243, -0.126563 secure-corp MS Outlook · · · User in office
Fig. 2.AIS Monitors: Data collection
Fig. 2 shows an example log thatAIS Monitors may keep. In this log, vari-ables such as data and time, GPS co-ordinates, names of the Wi-Fi routers the device is connected to, as well as the applications the user is running on the device. These are the variables that can be observed on the user device, and based on these observations, the context of the user may be inferred (namely the “labels” of the observations).
We envisage that there are two steps in this inference process. First, since there could be several variables which may or may not be relevant to the labels, the relationship between the observed variables and the labels has to be tested. Linear relation between two numeric variables can be tested, for example, using sample correlation coefficient. Performing such a test pairwise on the variables and labels give us some ranking of variables, thus allowing less correlated variables to be removed from the next step. In this second step, the labels can be estimated using ranked variables. For instance, for linear numeric values, linear regression can be applied. For variables with categorical and ordinal values, similar appropriate techniques can be used. Therefore, the AIS architecture proposes using statistical machine learning approaches to inferring user context from logged information. The context here is specific to individual users, and the best predictor variable may be different for different users.
Requirements Monitor. Based on the inferred user context, this component identifies the likely security requirements of the user. For example, when
Sara shares a document with Adam, the implicit security requirement is the document should not be disclosed to others (Fig. 1). The relationship between the user context and the requirements has been described asW, S⊢
R, whereW represents the user context,Srepresents the software behaviour andRrepresents the requirements [2]. Therefore, given some user contextc∈
W, theRequirements Monitor will identify a subset of security requirements sr⊆Rsuch that every member ofsrneeds to be satisfied in the context of c. If there is more than one requirement in sr, possible conflicts may have to be managed. For instance, when Adam is at home, it may be difficult to determine whether he is working or not, thus leading to a condition when two contradictory printing policies are both applicable.
We envisage the development of a requirements modelling language that sup-ports important concepts specific to characteristics of cloud-based applica-tions, such as the context and their relationship to individual requirements. The language should be able to describe critical security concerns about protecting assets, including what these assets are and where they reside and who has access to them, and in what form – as well as protecting assets from changing threats in a dynamic environment. Such a language should be capable of describing the inferred context and the associated security requirements, as well as their relationship to the design of cloud services.
Application Adaptor. This component modify the application behaviour on the user device when the server “pushes” certain changes to the devices. At the basic level, this component will enforce appropriate access control on the user device. For instance, if Sara revokes the sharing of document with Adam, the revocation should be enforced on the device as well. With richer client-side technology, such as Ajax (Asynchronous JavaScript And XML), it can deploy new features, restrict certain features on the user device. The server may push appropriate printer settings for certain files (Fig. 1) that should not be shared outside the work environment. The precise technology used here will depend on the hardware platform, the operating system and the programming languages used.
3.2 AIS Controls
Components inAIS Controls are mostly related to the adaptation of cloud ser-vices and policy-based security control.
Service Adaptation Engine. This component determines whether changes to the service behaviour is needed on the basis of the context and security requirements it gathered from the user device. For example, when Adam accesses the shared document outside the office environment, and when the requirement is to prevent disclosure, this component can push changes to the printer settings on Adam’s user device.
Policy Engine. This component of theAIS Architecturedefine the policies for adaptive security and enforce those policies. Towards this end, it is necessary
to develop a new expressive policy language designed for specifying adap-tive information security policies. These policies will make explicit several constraints that are hitherto difficult to describe. For instance, these poli-cies will state the dynamic contexts and adaptation strategies, assets and threats and how assets should be protected from threats, and location-based preferences are and their relationships to generic policies. This can build on existing work on policy languages that model security properties of dynamic, distributed systems. Whilst policy analysis and refinement can ensure that policies correctly reflect the users security requirements, the highly dynamic contexts in which cloud services are used mean that the policies might not capture all possible security threats. Therefore, it is necessary to augment the policy-based adaptive information security system with runtime mon-itoring and feedback mechanisms that will give users assurance that their security requirements are being met.
Policy DB. This represents the database of rule-based access control policies, which are extended with contextual information. For instance, the rule for printing documents may now also depend on who owns the the documents and where the document is being printed.
3.3 Reverse- and Forward-Engineering of Traceability
The AIS Architecture assumes that many of the cloud applications have been developed without any adaptive security measure in mind. Therefore, it may be necessary to reverse-engineer some of the existing implementation in order that the AIS Architecture is integrated with them.
TheTraceability component will provide design-time and runtime ity between requirements and implementation through design. The traceabil-ity may be developed either in a forward-engineering fashion (top-down), on the basis of requirements and design, which are both well documented, or in a reverse-engineering fashion which links implementation artefacts (code, policies) to design and requirements. Furthermore, the recovered traceability between the design and code needs to be maintained as they evolve. This live traceability between the design and code is essential for policy enforcement, adaptation and assurance. The traceability component entails developing techniques for design-time and run-design-time traceability between security design of the cloud service and requirements for information security.
4 A Case Study: ownCloud
ownCloudis a Dropbox-like cloud service for storing, syncing and sharing various types of files, such as documents, music and calendar [23]. It is an open source software system that runs on multiple platforms. AlthoughownCloud has imple-mented important security mechanisms, such as the use of https for client-server communication and a database-driven access control for file sharing, its secu-rity mechanisms are not currently adaptive to user context. Our wider aim is to
fully implement the AIS architecture and integrate it with theownCloud imple-mentation. In this section, we focus on the reverse-engineering of theownCloud
implementation, and integration of a policy engine withownCloud.
4.1 Reverse Engineering Access Control Model of ownCloud
ownCloud is implemented in a combination of PHP and JSON (JavaScript Ob-ject Notation), and a relational database (MySQL in this case).
As the first step, we identified that user files are stored inside thedatafolder on the server. Looking for how permissions for user and shared files are managed for files within a directory, we found that the permission values of files for the users are stored in thepermissionstable (Lines 102–104 in Fig. 3).
Fig. 3.permissions.php showing where file permissions are stored in the database
For example, the tupleh2, ttt23,31isays that the user with useridttt23has permission 31 on the file with fileid 2. Declarations in constants.php reveal what permission 31means (Fig. 4). In effect, the owner of the file has Create,
Read,Update,DeleteandShare permissions on the file. We then examined what happened when a file is shared between two users ofownCloud.
We found thatownCloud uses a table called shareto store which user has shared which file or folder with which other user (Fig. 5). It is interesting to note that the column permissionsin this table allows users to specify what sort of permission they want to give to the sharee. In the example in Fig. 5, it is 17, meaning Share and Read. However, there is no user functionality for users to specify such fined-grained permissions when they share a file with another user. Permissions are set to17by default.
/** * CRUDS permissions. */ const PERMISSION_CREATE = 4; const PERMISSION_READ = 1; const PERMISSION_UPDATE = 2; const PERMISSION_DELETE = 8; const PERMISSION_SHARE = 16; const PERMISSION_ALL = 31;
Fig. 4.Declarations of permissions in constants.php
In summary, it is clear that ownCloud uses discretionary access control, driven by a relational database. We observe two limitations with this approach. First, this design makes it difficult to define rule-based policies for managing access control, which many organisations tend to use. For instance, if a professor wishes to grant read-only access to a file to a group of students, then professor has to do that for every student in the group. Second, the access control model used here does not consider any contextual factor that may be relevant when deciding whether or not to grant access by a user to a file. For example, in the current design ofownCloud, it is difficult to write a policy that says that Adam should not be able to read the file Sara shared with him when he is not in the office environment. The next section demonstrates how we have re-engineered the access control model of ownCloud so it supports rule-based access control with contextual attributes.
Fig. 5.Snapshot of thesharetable inownCloud
4.2 Integration of XACMLight with ownCloud
The discretionary access control implemented in ownCloud has limited expres-siveness for access control policies. Therefore, we consider the use of the
eXten-sible Access Control Markup Language (XACML) instead. XACML is a stan-dard supporting any semi-structured access control policies complying with the XACML schema [24].
XACMLLight[25] is an engine that can evaluate any requests from the clients to form a proper response according to the root policy expressed in the XACML. Currently it is implemented as an Apache Axis2 web service in Java that allows both Policy Decision Points (PDP) and Policy Administration Points (PAP) controls. Through the PDP, a request tuple (Subject, Resource, Action, En-vironment) provided from the client can be returned with a (Permit | Deny) decision, using the XACML root policy which is also configured through the PAP service invocations.
SinceXACMLLightis a generic web service for XACML, we have customised it to support the policy driven rule-based access control system to integrate with the existing code of ownCloud that uses a database to manage the access permissions. The integration steps are briefly described as follows:
– EnablingXACMLLightfor WSDL service interfaces.By default, the lat-estXACMLLightv2.2 engine does not expose the adaptable WSDL interface for consumption as it is assuming the (constant) original interface. On the other hand, the XACML policy are to be adaptable to the semi-structured context parameters that we intend to consume. Therefore, we have to change all the two occurrences of theuseOriginalwsdlvariable fromtruetofalse in theservices.xmlconfiguration file inside theauthz.aarbinary archive deployed to ApacheAxis2’srepository/servicesfolder [26]. After these changes, theXACMLLightengine is enabled for more flexible runtime WSDL changes;
– Interfacing XACMLLight with ownCloud.Since ownCloud is implemented in PHP, we used theNuSOAP PHP framework for Web Services [27] to sim-plify the XACMLLight interface as a nested array structure of native PHP when preparing the request and parsing the response SOAP messages. The latest NuSOAP framework v1.123, however, overwrites the SOAP Action in the deployed web service and does not handle the nest array structures when passed in as native parameters. To facilitate a smooth integration, we fixed these bugs in NuSOAP to encode any nested array into an SOAP message understood byXACMLLightPDP and PAP message operations. As a result, theXACMLLightengine can be invoked directly from the adaptedownCloud
code, implemented in PHP;
– Replacing the access control code in ownCloud.Whenever the access control code such asgetFileDirectoryInfois called insideownCloud, we change its implementation to invoke the XACMLLight service instead. The soap message generation on a dynamically generated WSDL is performed by simply providing the nested array structure. The following code listing (Lines 1-17) shows how this is done programmatically.
1 <?php
2 require_once(’lib/nusoap.php’); 3 $ns="http://localhost/nusoap";
4 $wsdl="http://localhost:8080/axis2/services/PdpService?wsdl"; 5 $client=new nusoap_client($wsdl,’wsdl’);
6 $param=array(’parameters’=>array(
7 ’Subject’=> array(’AssignedDoctor’=>’Assigned Doctor’), 8 ’Resource’=> array(’MedicalRecord’=>’Medical Record’), 9 ’Action’=> array(’ReadRecord’=>’Read’),
10 ’Environment’=> array(’isOnDuty’=>true)));
11 $wsa =’http://schemas.xmlsoap.org/ws/2004/03/addressing’; 12 $soapAction = ’http://gryb.info/schemas/xacml/wsdl/getDecision’; 13 $r = $client->call(’getDecision’, $param, $wsa, $soapAction); 14 if ($r[’Response’][’Decision’]==’Permit’)
15 ... 16 17 ?>
Here Lines 6-10 prepares a nested array that is corresponding to the structure of an XACML PDP request, and Line 14 uses the returned decision (also parsed as an array) to construct a runtime condition for access control. After integrating the context monitor part, it would enable to build the $paramarray dynamically according to the credentials and other contextual circumstances in further developments.
As such, we have integrated the ownCloud and XACMLLight policy engine to communicate with each other by sending request and getting response as SOAP messages.
5 Discussion, Conclusion and Future Work
5.1 Discussion
Cloud applications are increasingly accessed from a range of mobile and comput-ing devices. As a result, the user context has become highly dynamic, together with the security threats and the value of assets that need to be protected. Many of the cloud applications need to be re-engineered in order that they support adaptive information security.
Towards this end, we have proposed an architecture for implementing adap-tive information security. The architecture focuses on learning the user context and security requirements from the user device. The adaptation and security mechanisms on the server use the context and requirements to identify appro-priate security and adaptation behaviour for the device. The adaptation is highly tuned to the specific conditions and requirements of the individual users.
We have used the open source system for file sharing, calledownCloud, as a case study to illustrate our architecture. We have reverse-engineered the access control model ofownCloudto reveal that it uses a database-driven discretionary access control model. We have re-engineered ownCloud so that it uses XACM-LLight for defining and enforcing rule-based access control policies that can be extended with contextual attributes.
5.2 Conclusion
The novelty of the proposed architecture lies in the fact that it calls for an engi-neering approach based on requirements engiengi-neering, traceability management
and policy-based security and adaptation. Traceability from user requirements and context, to the design and implementation of cloud services appears to be a promising line of research for adaptive information security in cloud applications.
5.3 Future work
One important line of future work emerging from this architecture is to inves-tigate how quantitative data about the usage of cloud applications and services could feed into the requirements elicitation process. This is particularly signif-icant because users of cloud applications could be distributed over several geo-graphical areas, and the data about their usage of cloud services and application makes up a significant amount of data available to requirements engineering. One promising research issue is how AI learning techniques could be used to infer candidates for security requirements from the usage data.
Another important area of research following from the proposed architecture is the issue of legal compliance. Currently, legal compliance of information secu-rity requirements, policies and implementation are done partly manually. This issue will become increasingly important, and automated support to alleviate the manual labour involved in the task will be needed. The compliance mechanisms for user requirements may provide an impetus to the development of tools for checking legal compliance of cloud services and applications.
Acknowledgement
This publication was made possible by the support of a grant (NPRP 05-079-1-018) from the Qatar National Research Fund (QNRF). The statements made herein are solely the responsibility of the authors.
References
1. Salehie, M., Pasquale, L., Omoronyia, I., Ali, R., Nuseibeh, B.: Requirements-driven adaptive security: Protecting variable assets at runtime. In Heimdahl, M.P.E., Sawyer, P., eds.: IEEE International Requirements Engineering Confer-ence , Chicago, IL, USA, September 24-28, 2012, IEEE (2012) 111–120
2. Jackson, M.: Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley Longman, Boston, MA, USA (2001)
3. Haley, C.B., Laney, R.C., Moffett, J.D., Nuseibeh, B.: Security requirements engi-neering: A framework for representation and analysis. IEEE Trans. Software Eng.
34(1) (2008) 133–153
4. Nhlabatsi, A., Nuseibeh, B., Yu, Y.: Security requirements engineering for evolving software systems: A survey. International Journal of Secure Software Engineering (IJSSE)1(1) (2010) 54–73
5. Rushby, J.: Security requirements specifications: How and what? In: Requirements Engineering for Information Security (SREIS), Indianapolis, IN. (2001)
6. Liu, L., Yu, E.S.K., Mylopoulos, J.: Security and privacy requirements analysis within a social setting. In: IEEE International Conference on Requirements Engi-neering, 8-12 September 2003, Monterey Bay, CA, USA. (2003) 151–161
7. Crook, R., Ince, D.C., Lin, L., Nuseibeh, B.: Security requirements engineering: When anti-requirements hit the fan. In: 10th Anniversary IEEE Joint International Conference on Requirements Engineering (RE 2002), 9-13 September 2002, Essen, Germany, IEEE Computer Society (2002) 203–205
8. Lin, L., Nuseibeh, B., Ince, D.C., Jackson, M.: Using abuse frames to bound the scope of security problems. In: IEEE International Conference on Requirements Engineering, 6-10 September 2004, Kyoto, Japan, IEEE Computer Society (2004) 354–355
9. van Lamsweerde, A.: Elaborating security requirements by construction of in-tentional anti-models. In: 26th International Conference on Software Engineering (ICSE 2004), 23-28 May 2004, Edinburgh, United Kingdom. (2004) 148–157 10. Nuseibeh, B., Haley, C.B., Foster, C.: Securing the skies: In requirements we trust.
IEEE Computer42(9) (2009) 64–72
11. Franqueira, V.N.L., Tun, T.T., Yu, Y., Wieringa, R., Nuseibeh, B.: Risk and argu-ment: A risk-based argumentation method for practical security. In: RE 2011, 19th IEEE International Requirements Engineering Conference, Trento, Italy, August 29 2011 - September 2, 2011, IEEE (2011) 239–248
12. Ramesh, B., Jarke, M.: Toward reference models of requirements traceability. IEEE Trans. Software Eng.27(1) (2001) 58–93
13. Wang, Y., McIlraith, S.A., Yu, Y., Mylopoulos, J.: Monitoring and diagnosing software requirements. Autom. Softw. Eng.16(1) (2009) 3–35
14. Yu, Y., J¨urjens, J., Mylopoulos, J.: Traceability for the maintenance of secure software. In: th IEEE International Conference on Software Maintenance (ICSM 2008), September 28 - October 4, 2008, Beijing, China, IEEE (2008) 297–306 15. Bauer, A., J¨urjens, J., Yu, Y.: Run-time security traceability for evolving systems.
Comput. J.54(1) (2011) 58–87
16. Nuseibeh, B.: Weaving together requirements and architectures. IEEE Computer
34(3) (2001) 115–117
17. Peterson, G.: Don’t trust. and verify: A security architecture stack for the cloud. IEEE Security & Privacy8(5) (2010) 83–86
18. Sloman, M.: Policy driven management for distributed systems. J. Network Syst. Manage.2(4) (1994) 333–360
19. Takabi, H., Joshi, J.B.D., Ahn, G.J.: Security and privacy challenges in cloud computing environments. IEEE Security & Privacy8(6) (2010) 24–31
20. Whittle, J., Sawyer, P., Bencomo, N., Cheng, B.H.C., Bruel, J.M.: RELAX: a language to address uncertainty in self-adaptive systems requirement. Requir. Eng.15(2) (2010) 177–196
21. Whittle, J., Sawyer, P., Bencomo, N., Cheng, B.H.C., Bruel, J.M.: RELAX: Incor-porating uncertainty into the specification of self-adaptive systems. In: 17th IEEE International Requirements Engineering Conference, Atlanta, Georgia, USA, Au-gust 31 - September 4, 2009, IEEE Computer Society (2009) 79–88
22. Salifu, M., Yu, Y., Nuseibeh, B.: Specifying monitoring and switching problems in context. In: 15th IEEE International Requirements Engineering Conference, RE 2007, October 15-19th, 2007, New Delhi, India, IEEE (2007) 211–220
23. Online: ownCloud. http://owncloud.org/
24. OASIS: eXtensible access control markup language (XACML) specification, ver-sion 2.0. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2. 0-core-spec-os.pdf
25. Online: Xacmllight. http://xacmllight.sourceforge.net/
26. Online: Apache axis2. http://axis.apache.org/axis2/java/core