In cloud computing one can distinguish the following delivery models:
Fig. 8.1.2/1: Figure from : 1
Software as a Service (SaaS)
A software deployment model. It allows application and service providers to remotely host application and made them available to customers on demand, over the Internet. This model offers improved operational efficiency and reduced costs. Saas is becoming the most popular delivery model for meeting the needs of enterprise IT services. However, most enterprises are still uncomfortable with the SaaS model due to lack of visibility about the way their data is stored and secured.
Infrastructure as a Service (IaaS)
The model IaaS changes the way developers deploy their applications. To run the application in the classic way, companies have to invest in their own data centers or managed hosting companies or colocation services and then hire operations staff to get it going. In the IaaS model they can just go to a IaaS providers (e.g. Amazon Web Services), get a virtual server running in minutes and pay only for the resources they use. IaaS abstracts the hardware beneath and allows users to consume infrastructure as a service without bothering anything about the underlying complexities. The cloud has a compelling value proposition in terms of cost, but out of the box IaaS only provides basic security (perimeter firewall, load balancing, etc.) and applications moving into the cloud will need higher levels of security provided at the host.
Platform as a Service (PaaS)
PaaS is one layer above IaaS on the stack. This model abstracts everything including OS, middleware, etc. Application can be written without any information about what is going on underneath the service. This offers an integrated set of developer environment that a developer can use to build their applications and it offers developers a service that provides a complete software development lifecycle management, from planning to design to building applications to deployment to testing to maintenance. Everything other than that is out of the view of the developer. The disadvantage of PaaS is that, these features can be used by a hacker to leverage the PaaS cloud infrastructure for malware command and control and go behind IaaS applications.
Security issues that should be carefully considered as an integral part of the SaaS application development and deployment process:
Data security
In the classical approach, sensitive data is stored ”in house” and is only subject to physical, logical and personnel security and access control policies. However, in the SaaS model, data is stored outside the companies physical boundaries. It follows that the SaaS vendor must provide additional security checks to ensure data security and prevent leaks due to security vulnerabilities in the application or through malicious employees. Commonly used protections include strong encryption techniques for data security and finegrained authorization to control access to data.
The attacker can exploit one of the following weaknesses to execute an attack:
Network security
In this deployment model, sensitive data is obtained from the company, processed by the application and stored at the SaaS vendor end. Thus, all data exchanges must be secured in order to prevent leakage. Commonly used protections are strong network encryption techniques such as Secure Socket Layer (SSL) and the Transport Layer Security (TLS). Despite the use of these techniques, the attacker can:
Data locality
The consumers use the SaaS applications and process their business data. However, the customer doesn’t know where the data is actually located. In many case this might be an issue. Companies have to comply with data privacy laws in various countries and in some of them the locality of data is of utmost importance. For example in many EU and South America countries, certain types of data cannot leave the country because of potentially sensitive information. It follows, that a secure SaaS model must provide reliability to the customer on the location of his data.
Data integrity
One of the most critical elements of any system. In the classical approach data integrity of databases is ensured using transaction that follow the ACID (atomicity, consistency, isolation and durability) paradigm. In standalone systems with one database, data integrity can be achieved easily. In distributed systems with multiple databases the task is a bit more complex.
However, it can be done using a global transaction manager and using 2phase commit protocol as per XA standard.
Everything becomes more complicated when entering the world of Cloud computing. SaaS applications are multi-tenant and hosted by a third party. Usually, the application exposes theit functionality via XML based APIs.
The challenge with web services is transaction management. HTTP (Hyper Text Transfer Protocol) does not support transactions or guaranteed delivery, so the only option is to implement these at the API level. There exist immature standards like WS-Transaction and WS-Reliability to manage data integrity but not many vendors implement them. Most web service APIs are also without any support for transactions. Moreover, Saas applications may have different levels of availability and SLA (service-level agreement). This further complicates management of transactions and data integrity across multiple applications. The lack of integrity controls at the data level could result in security problems.
Data segregation
Clouds are multi-tenant, which also means that multiple users can store their data at the SaaS. Usually, data of various users will reside in the same location. Thus, intrusion of data of one user by another becomes possible in this environment. This data leak can be done either by hacking (exploiting a vulnerability in the application) or by injecting client code into the SaaS system. It is obvious that, the boundary between data of different usersm must be ensured not only at the physical level but also at the application level.
Otherwise, the attacker can:
Data access
In the SaaS model, a small business can use a cloud provided by some other provider. Usually, this small organization have its security policy based on which employee can have access to a particular set of data. The security policies may entitle some considerations wherein some of the employees are not given access to certain amount of data. Thus, the SaaS model must be flexible enough to incorporate the specific policies put forward by the organization. The model must also be able to provide organizational boundary within the cloud because multiple companies will be deploying their business processes within a single cloud environment.
Authentication and authorization
Most companies, if not all, store data on Lightweight Directory Access Protocol (LDAP) servers. Active Directory (AD) seems to be one of the most popular implementations of this protocol. With SaaS, the software is hosted outside of the corporate firewall. Thus, user credentials are stored in the SaaS providers databases and not as part of the corporate IT infrastructure. This means SaaS customers must remember to remove/disable accounts as employees leave the company and create/enable accounts as come onboard. In essence, having multiple SaaS products will increase IT management overhead. A possible solution is to provide delegated authentication process to the customer and use their internal LDAP/AD server (so that companies can retain control over the management of users).
Data confidentiality
In the cloud computing model users usually share or store their own information on remote servers owned or operated by others and accesses through the Internet or other connections. It may lead to the following confidentiality issues:
Web application security
The SaaS model allows users to manage activities from central locations rather than at each customers site, enabling customers to access application remotely via the Web. SaaS security issues are not different than with any other web application technology, however one of the problems is that traditional network security solutions such as network firewalls, network intrusion detection and prevention systems, do not adequately address the problems in the cloud environment. Web applications introduce new security risks that cannot effectively be defended against at the network level, and do require application level defenses.
Data breaches
Clouds are becoming a high value target. Once the cloud environment is breached, data of all cloud users may be potentially under attack. Moreover, insiders have access to this data but it can be accessed in a different way (do not have direct access to databases). However, it does not reduce the risk of insider breaches which can be a massive impact on the security. The SaaS providers employees have access to a lot information and a single incident could expose information from many customers.
Vulnerability in virtualization
Virtualization is one of the main components of a cloud and it poses major security risks. The main issue is to ensure that different instances must be run isolated from each other on the same physical machine. This task is not met completely in todays scenario. Current VMMs (Virtual Machine Monitor) are not perfect isolated and many bugs have been found in all popular VMMs that allow escape from the sandbox. Virtual machine monitor should be root secure, meaning that no privilege within the virtualized guest environment permits interference with the host system.
Availability
The SaaS provider must ensure, that the service is available all the time. This multi-user architecture must support a load-balanced farm of application instances, running on a variable number of servers. Thus, resiliency to hardware/software failures, as well as to denial of service attacks, needs to be built from the ground up within the application. Moreover, attackers may use wrong designed or configured authentication systems and perform targeted DoS attacks by using several incorect authentications.
Backup
The SaaS provider needs to ensure that all sensitive data is regularly backed up to facilitate quick recovery. Providers must also use strong encryption schemes to protect the backup data and prevent accidental leakage of sensitive information.
Identity management and sign-on process
Identity management (IdM) is a way to deal with identifying individuals in a system and controlling their access to the resources in that system. Usually, SaaS vendor use one of the following models:
In the PaaS model, the provider gives access to users to build applications on top of the platform. However, any security below the application level (e.g. host and network intrusion prevention) are still scope of the provider. Moreover, he has to offer strong assurances that the data remains inaccessible between applications. The provided development environment tends to be more extensible than SaaS, at the expense of customer-ready features. This also concerns security features and capabilities, where the built-in capabilities are less complete, but there is more flexibility to layer on additional security.
In this deployment model, the adversary will likely attack visible code, including but not limited to code running in user context. The adversary can attack the infrastructure and perform extensive black box testing. The vulnerabilities of cloud are not only associated with the web applications but also vulnerabilities associated with the machine-to-machine Service-Oriented Architecture (SOA) applications, which are increasingly being deployed in the cloud.
IaaS gives the developer better control over the security of his system. However, the security can be compromised using security holes in the virtualization manager. In theory, this issue can be addressed but in practice there are plenty of security problems. Another issue, is the reliability of the data that is stored within the providers hardware. Thus, it is important to the owner to retain the control over his data, regardless of its physical location.
The security responsibilities of both the provider and the consumer greatly differ between cloud service models. Amazons Elastic Compute Cloud (EC2) infrastructure as a service offering, as an example, includes vendor responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. The consumer, in turn, is responsible for the security controls that relate to the IT system including the OS, applications and data.