The concept of patterns as way of capturing and expressing tried-and-true solutions to recurring problems was first formalised by Christopher Alexander in his book about urban planning and architecture [1
], in which he attempted to explain and classify common recurring problems in designing and building physical structures, using a specific, structured language. A decade and a half later, the concept was successfully applied to software engineering by Gamma, Helm, Johnson and Vlissides (also known as the Gang of Four, or simply GoF) in their influential “Design Patterns: Elements of Reusable Object-Oriented Software” [2
], which was followed by “Pattern-Oriented Software Architecture” (known as POSA) by Buschmann et al. [3
]. These seminal software engineering pattern works, along with the original inspiration of the Alexandrian pattern concept, laid the foundations for pattern semantics and structure. Building upon their success, the pattern community has grown and expanded into the fields of software security and security engineering. In software security, Cloud SaaS (Software as a Service) security pattern is one of the most important areas being actively studied given its popularity and adoption rates.
In recent decades, the Cloud security pattern has been involving in response to ever-increasing number of security attacks, vulnerabilities and exploits. As such, the concept of security is quickly shifting from an often-overlooked afterthought to a mandatory design requirement. In order to realise this requirement, the Cloud SaaS community is in overwhelming need for structured information about best security practices and security knowledge, to help them design and develop secure Cloud SaaS. So far, there is some research [4
] on security patterns, and they tend to address a specific security area (e.g., OWASP [11
] web development security guideline where the focus is only on how to develop a secure code and how to prevent cyber attacks) and do not cover many important aspects, such as privacy and governance. Moreover, there is a lack of structured and united information about security best practices and security knowledge that SaaS developer can use as a guideline for developing Cloud SaaS application from the ground up.
In this paper, we aim at providing a complete list of security patterns applied to Cloud SaaS application. The patterns cover four important areas of Cloud security including system security, communication security, data security and privacy. Furthermore, based on the security patterns we defined, we produce a security best practices and security knowledge guideline [15
] for Cloud SaaS developer. In addition to that, we look at the security solutions in Amazon Web Service (AWS) and Azure and map our defined patterns to the solutions offered by both Cloud services providers. It is worth noting that this paper is an extended version of the paper published in the IEEE CloudTech 2018 [16
]. The extension focuses on security pattern solutions and detailed discussion on solutions in AWS and Azure, which are absent in the published paper [16
The paper is organised as follows. Section 2
is about our proposed methodology used to define the Cloud security patterns. Section 3
presents the security patterns in Cloud SaaS. We provide a high level classification of the security pattern and a complete list of patterns in each class/category. Section 4
presents the pattern expression and structure. The solutions to each security pattern identified in Section 3
are also presented in this section. Section 5
is about a case study of AWS and Azure. Section 6
presents related work and we conclude this paper in Section 7
2. Cloud Security Pattern Definition Methodology
In this section, we present our proposed methodology used to define and classify the security patterns in Cloud SaaS. As shown in Figure 1
, we divide the whole process into five steps: from security requirements identification to security pattern classification in step 5. In each step, existing guidelines may be used. For example, security and risk assessment is conducted based on OWASP [11
2.1. Security Requirements in Cloud SaaS
The first step of the process focuses on defining the security requirements in Cloud SaaS. We study all the possible security requirements covering different aspects from data and system security to communication security and privacy. Our ultimate goal is to list all the security requirements needed for building the secure, trust and legal compliance Cloud SaaS application. Concerning legal requirements, we analyse different data processing requirements (e.g., the role and responsibility of data processor or personal data usage control) under the scope of GDPR [17
]. The outcome of this step is a general Cloud security checklist (see Table 1
) for SaaS application. This high-level security requirements are then used for assessing security and risk in Cloud SaaS.
2.2. Security and Risk Assessment
Security and risk assessment is an explicit study to identify security vulnerabilities and risks in Cloud SaaS. The main goal is to study the required security and identify improvements to secure the systems and to ensure that necessary security controls are integrated into the design and implementation of a Cloud SaaS project. The outcome of this task is a properly completed security assessment documentation outlining any security risk that might have. This security and risk assessment report is then used for analysing and extracting the security features in Cloud SaaS.
2.3. Security Features Identification
Security feature refers to a specific security protection against attack. There are different kinds of attacks designed to target system, resources or user. Thus, different security features are required in order to be able to cope with these attacks.
Since Cloud applications and services are delivered through the Internet, Cloud computing faces various kinds of external security risks, such as denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks. In addition, and particularly in the public Cloud where data is hosted by the Cloud Service Provider (CPS), trust, confidentiality, and privacy are also important issues. To identify the security features, we take the security and risk assessment defined in the second step as the inputs. The by-product is a complete list of required security features.
2.4. Security Pattern Definition
The definition of security pattern in Cloud SaaS is based on the required security features defined in step 3. We also examine the existing security patterns in the traditional systems. The idea is to find out whether or not the patterns in other system can be used in Cloud SaaS environment. We look at three important security areas for pattern definition: (1) communication security; (2) data security and (3) system security.
For each defined pattern, they have the following structure.
Security problem. Define the potential problem and their consequence if there is no security implementation to address it.
Context and use cases. Identity in which context and use cases that this security issue may happen.
Security solution. This provides solution to address the security issue. Our proposed security tactic principles are.
Resisting attack. This is the prevention technique where the designed solution should resist to any attack that might happen during application service. For example, a solution for an application to resist an unauthorised access is to have a strong access control model and system (e.g., multi-factor authentication).
Detecting attack. This technique allows system to detect attacks and react early to minimise the risk and serious consequence as the result of the attack.
Recovery. In case the system can not prevent attack, the fast recovery solution should be in place in order to minimise the disruption of service.
2.5. Security Pattern Classification
After defining the security patterns, we arrange and classify them into different categories depending on their problem domain. For example, communication security pattern, data security pattern or system security pattern. In general, the patterns are grouped together if they are related in problem and context. We also define the relationship of crossed categories patterns.
4. Pattern Expression and Structure: Security Patterns and Solutions
Security patterns are generally expressed as templates, following a certain structure. We structure the patterns, like in GoF [2
], featuring sections, such as “Problem”, “Context”, “Solution”, “Related Patterns”, “Consequences”, “Known Use”, and “References”. However, to keep it short, in this paper we present only “Problem”, “Context”, and “Solution”. The detailed features of all the patterns can be found at [15
Problem is a statement relating to the security issue for a given pattern.
Context is about the security context, in which context the security issue occurs.
Solution is about the solutions to address the defined security pattern.
4.1. Compliance and Regulatory
In this category, there are seven patterns.
4.2. Identification, Authentication and Authorisation
There are 8 patterns in this category.
Problem. How to simply, yet securely authenticate physical users of Cloud-based applications?
Context. Authentication of humans by machines is a problem of balancing usability and security. The combination of the traditional three factors something the user knows (secret password), something the user has (physical possession) and something that is an unique trait of the user (biometrics) provide high level of security, each imposing a different burden on the part of the user. Passwords have been the main authentication factor through the history of computing and there is a large body of knowledge pointing out to the deficiencies in the treatment of passwords by users. Physical tokens are often used as a second authentication factor.
Solution. While presenting all three authentication factors at the same time remains the most secure option, this level of security is often not required in the typical Cloud application scenarios. In order to mitigate the vulnerabilities associated with passwords, multi-factor systems often include authentication levels based on the access scenarios, sensitivity level and the associated risk of the operations that the user wishes to perform; e.g., in a banking application, a user may authenticate with a fingerprint on their mobile device (2 factors) to access their accounts for viewing, but a large money transfer may require an additional input of a password or pin.
Federation (Single Sign-On)
Problem. How to authenticate users without the burden of setting up and securely maintaining a user database?
Context. Management of the user identities is often a burdensome task and in SaaS applications it often consumes a lot of time if done right.
Solution. Reusing existing user sign-in and sign-on features developed and maintained by third parties is an effective way to outsource authentication tasks to a third party. While the technical solutions employed by the third parties are often state-of-the-art, such outsourcing bears inevitable risks of privacy protection of the users, especially when the federated entities are social networks.
Problem. How to control human or machine user access to Cloud APIs?
Context. Access to Cloud API endpoints often needs to be given on per-use or basis to achieve certain security levels. Using user credentials directly every time does not allow such levels of control.
Solution. Access tokens are cryptographic secrets issued to API users, allowing them to programmatically access API endpoints. Access tokens enable fine-grained temporal and functional control, enabling access only to specific functions at the specified time. The lifetime of tokens is easily controlled, so their issuing and revocation can easily be automated.
Problem. How to establish identity of parties in a Cloud communication channel?
Context. In a Cloud environment, multiple physical and logical components connect and exchange information. Without proper authentication between communicating parties, man-in-the-middle attacks are possible.
Solution. Using two-way authentication to allow both entities in a communications link to authenticate each other.
Secure User Onboarding
Problem. How to securely perform initial registration of Cloud application users?
Context. When new device or user gains access to system for the first time, they need to be securely onboarding the system. If it is not handled properly, we place users, devices, data and the network at risk.
Solution. Define a secure onboarding process for new device or user who wants to access the system for the first time. The process must consist of at least the identity establishment and validation.
Identity and Access Manager
Problem. How to securely and effectively manage a user database and provide authentication and authorisation functionality in a Cloud application?
Context. In Cloud context, it is important to establish user identity and also control access to system’s resources in order to protect system and resources from unauthorised or malicious users.
Solution. A proper tool should be used to define and manage the roles and access privileges of individual application users and the circumstances in which users are granted (or denied) those privileges.
Problem. How to continuously prove the identity of the user when they perform sensitive operations?
Context. In current Cloud environment there is no continuous control over user activities once user is authenticated. If an attacker is able to hack an account, he can do whatever he wants on both user and system resources. Controlling user activities during usage session is important in some use cases (e.g., smart home, healthcare) in order to prevent or minimise the damage that might happen as the result of account hacking. With continuous control, system can react on time to the abnormal activities done or being done by user.
Solution. The solution is to develop the intelligent usage control tools monitoring the usage activities of user from the start till the end of usage session. The tools must work in the background and be intelligent enough to detect any abnormal activities and prevent user from making further damage if abnormal activities are detected.
Access Control Clearance
Problem. How to enforce access and usage control policies for different types of authentication?
Context. In general, the access and usage control of data are governed by policies in which it defines who can do what in which circumstance. However, ensuring user respects what is defined in policy is a challenge. For example, if policy states that user needs to notify data owner before accessing or using it, it is an obligation to ensure that notification message reaches data owner before data is released or made accessible to user.
Solution. The key solution to policy enforcement is to develop the policy enforcement point (PEP) acting as the intermediary between policy decision point (PDP) and client application. PEP forwards request from client to PDP system and retrieves access and usage control decision from PDP. PEP is also responsible for enforcing policy by executing obligation if needed.
4.3. Secure Development, Operation and Administration
In this category, there are five patterns.
4.4. Privacy and Confidentiality
There are 4 patterns in this category.
4.5. Secure Architecture
There are 7 patterns in this category.
In Section 5
, we discuss in detail the solutions in AWS and Microsoft Azure to our defined security patterns. The idea is to map each defined pattern to the solutions provided in AWS or/and Microsoft Azure.
We produced an official documentation and guideline of security patterns for Cloud SaaS. Each pattern is represented by an icon (see Figure 3
) and accompanies by texts in which the detailed description of pattern and its associate solution are provided. All the documents are hosted on a webpage and are accessible at [23
6. Related Work
There is a significant number of security pattern research in software engineering [8
]. However, that research focused on general topic and not particularly on the Cloud. Moreover, they limit themselves to very narrow topics, such as authentication and authorisation security or threat and ignore some other security issues that they think are not significant, for instance, resources management. In our work, we focus on all the aspects of security in Cloud SaaS. We cover data and system security and privacy, which is normally overlooked given its complexity. Below are some most relevant research to our work.
Yoder and Barcalow [76
] presented a collection of seven patterns for application security, treating authentication and authorisation security aspects. The authors are motivated by the usual lack of security perspective in the early phases of the software design and attempt to solve this problem by providing design guidelines that make it easier to implement security details later in development. Some patterns, proposed by the authors, are described more on the architectural level while the others are more design-oriented. The authors provide also a pattern language defining relations between the presented security patterns. In this paper, the authors proposed the general patterns applied to software application and not specifically for Cloud SaaS. Moreover, there are many missing patterns that are not addressed in this paper, such as privacy and confidentiality, data management and governance, threat detection and resources management. These distinguish this work from ours.
Focussing on confidentiality, integrity and non-repudiation security aspects, Braga et al. [70
] developed a pattern language “Tropyc”, consisting of nine design patterns “for cryptographic software”. The authors first introduced a “Generic Object- Oriented Cryptographic Architecture”, a simple system of two template classes representing two sides in a communication channel with two helper classes representing encryption and decryption transformations. Based on this foundation and addressing four “well established cryptographic objectives”, they went on to develop four basic patterns: Sender Authentication, Information Secrecy, Signature and Message Integrity and their further derivatives. This research focuses mainly on authentication, data integrity and end-to-end security including secure management of digital signature and secret information management. Unlike our work where we address all the aspects of security from data and system to privacy, this paper addresses only a small aspect of security issues and most importantly it is not about Cloud.
] identifies eight enterprise security patterns, attempting to cover topics like data authenticity and data ownership, access control and authentication, risk assessment and management, communication with third parties, secure provision of data, as well as awareness of own vulnerabilities and threats. Using a brief form giving motivation and problem statements, followed by a description of the forces governing the problem and a proposed solution with consequences, the author employs a series of questions and answers to provide guidance in development and enforcement of prudent security policies in an enterprise. The work of Romanosky covers more security aspects compared with the work of Yoder and Braga. However, Romanosky’s work is not specifically for Cloud.
Kienzle et al. [77
] published a catalogue of 30 patterns. They made one of the first attempts at security pattern classification, distinguishing between 16 “structural” and 14 “procedural” patterns. The structural patterns describe architectural and design aspects of the elements of a secure system, providing recipes for implementation of security mechanisms. They deal with security aspects, such as authentication and authorisation, web application session management, encryption of data in transit and at rest, sandboxing and need-to-know principle implementation, least privilege principle and secure transaction. This is very close to ours; however, the difference is that authors works on general software security pattern and not for Cloud. Although there are similarity and common security issues between Cloud and non-cloud application, Cloud application has more and specific security issues compared with non-cloud application, for instance, economic durability.
The book on security patterns by Schumacher et al. [78
] represents a culmination of the work done to its date and the synthesis of the individual efforts of not just its large consortium of authors, but the security pattern community in general [72
]. This large volume showcases about 70 patterns, classified using well-developed pattern taxonomy units: enterprise security and risk management, identification and authentication, access control, accounting, firewall, secure internet applications and cryptographic key management. In addition to being a pattern repository, this work includes four introductory chapters explaining the pattern approach in general, an overview of security foundations followed by an overview of the history, the concept and the scope of security patterns. Similar to the work of Kienzle et al. [77
], Schumacher et al. [78
] provide a rich documentation on security patterns for general information system, but not for Cloud SaaS.
Eduardo Fernandez-Buglioni, one of the stalwarts of the pattern movement and a credited co-author of [78
], published his own catalogue of security patterns [79
], integrating and systematising own earlier publications. Similar in organisation and volume, but decidedly different in classification, pattern names and their presentation, the work makes extensive use of UML component, class and collaboration diagrams. Patterns are classified by their usage areas: identity management, authentication, access control, (operating system) process management, secure execution and file management, secure OS architecture and administration, networking, web services and web service cryptography. Similar to previous work, there are many missing security patterns in Eduardo’s work, such as data governance and privacy and confidentiality. Moreover, these patterns are not defined specifically for Cloud SaaS.
Langer et al. [12
] work on Cloud security patterns to improve end user security and privacy in public Clouds. The authors developed several Cloud security patterns for common critical situations in the Cloud in the three fields of data storage in the Cloud, user privacy protection and data minimisation, and authentication of stored and processed data. The authors focus mainly on how to protect data in public Clouds, many security patterns, such as communication, secure architecture and data governance are not considered in this paper.
Oracle technical report [80
] on "Securing SaaS at Scale" highlights some security challenges in Cloud SaaS, such as security and compliance, user management and monitoring and data residency and regulatory. However, in the report only high level and general discussion on the matters are provided. Moreover, no solutions to the highlighted issues are provided in the report. In addition, other security issues, such as secure development, operation and administration and secure architecture of Cloud SaaS are not discussed in the report. These differentiate their work from our work in this paper.
Remark: There is no attempt so far to fully document the security patterns for Cloud SaaS application, a security best practices and security knowledge documentation that SaaS developer can use as a guideline for developing Cloud SaaS application from the ground up. We put our effort in studying, defining and documenting the security patterns for Cloud SaaS. Among the 8 most relevant papers presented in this section, only 6 [70
] work on security patterns for general software (non-cloud application) and only 2 papers [12
] address security patterns for Cloud-based application. However, the the authors in the 2 papers do not cover all necessary security patterns in Cloud compared with our work. In our work, we provide richer patterns and cover more security aspects.
The security patterns have gone through their entire “hype-cycle" [81
] and are now considered mature and well explored from the perspective of the pattern classification and their application. New areas and specialisations, such as security patterns arising from the specifics of Cloud computing environments are steadily coming into researchers’ focus. In this paper, we address this new area, the Cloud. We identify the Cloud SaaS security patterns for different security aspects, from data and system security to privacy. We provide a complete list of patterns and their solutions applicable to Cloud computing environment, and to the best of our knowledge, there is no attempt so far to fully study and document them. There are, of course, some research literature focusing on security pattern; however, they address only the selected topics, such as authentication, authorisation or threat and ignore some other security issues that they think are not significant, for instance, resources and operation management and governance. In addition, and what make our work in this paper different from previous work is that we produce an official security best practices and security knowledge documentation [15
] that SaaS developer can use as a guideline for developing Cloud SaaS application from the ground up. Another contribution that also distinguishes our work from previous work is the study of AWS and Azure security solutions. The main goal is to map each pattern to the solutions available in AWS and Azure.
Although most of security solutions are available in AWS and Azure, there are still some remaining issues that need to be addressed, such as, processing purpose control and effective data lifecycle management in distributed environment (e.g., when data is shared between Cloud back-ends system). Our future work will be around these issues. In addition, we plan to include Google Cloud solutions to our security patterns documentation.