Security Challenges in Cloud Application Development

In a cloud environment, an enterprise cannot necessarily use the same tools and services they deployed internally for security, such as a Web application fi rewall. For example, a company that has deployed a Web application fi rewall (WAF) as another level of security for a legacy app when exposing it to the Web no longer has that option as the ownership and control of infrastructure at various levels changes

in case of cloud. The CSA’s cloud application security guidance noted that IaaS

vendors have started to offer cloud application security tools and services, including WAFs, Web application security scanning and source code analysis. The tools are specifi c to either the provider or third party, the report noted. It will be wise to explore all possible APIs that might provide strong logging which in turn help as leverage for security-related activity [ 18 ].

Having seen various issues in general, it is time now to look at security in par- ticular with the service model point of view, that is, the issues which are inherent and affect across various service models.

3.3.1

Challenges in Case of PaaS

3.3.1.1 Privacy Control

This is the fi rst step in securing private data before sending it to the cloud. Cyber laws and policies currently exist which disallow and impose relevant restrictions on sending of private data onto third-party systems. A cloud service provider is just another example of a third-party system, and organisations must apply the same rules of handling third-party systems in this case. It is already clear that organisa- tions are concerned at the prospect of private data going to the cloud. The cloud service providers themselves recommend that if private data is sent onto their sys- tems, it must be encrypted, removed or redacted. The question then arises “How can the private data be automatically encrypted, removed, or redacted before sending it up to the cloud service provider?”; that is, “How can the whole process be auto- mated?”. It is known that encryption, in particular, is a CPU-intensive process which threatens to add signifi cant latency to the process.

Any solution implemented should broker the connection to the cloud service and automatically encrypt any information an organisation does not want to share via a third party. For example, this could include private or sensitive employee or cus- tomer data such as home addresses or social security numbers, or patient data in a medical context. Security engineers should look to provide for on-the-fl y data pro- tection by detecting private or sensitive data within the message being sent up to the cloud service provider and encrypting it such that only the originating organisation can decrypt it later. Depending on the policy, the private data could also be removed or redacted from the originating data but then reinserted when the data is requested back from the cloud service provider.

3.3.1.2 Traceability and Audit

As an organisational requirement, in order to monitor the fi nancial consumption of a rented or a paid for technology or service, the fi nancial department needs to keep track of the units of usage and audit trail. The cloud service providers themselves provide this information on most occasions, but in the case of a dispute, it is impor- tant to have an independent audit trail. Audit trails provide valuable information about how an organisation’s employees are interacting with specifi c cloud services, legitimately or otherwise.

The end-user organisation could consider a cloud service broker (CSB) solution (such as CloudKick , CloudSwitch , Eucalyptus ), as a means to create an indepen- dent audit trail of its cloud service consumption. Once armed with his/her own records of cloud service activity, the security engineer can confi dently address any concerns over billing or to verify employee activity. A CSB should provide report- ing tools to allow organisations to actively monitor how services are being used. There are multiple reasons why an organisation may want a record of cloud activity, which leads us to discuss the issue of governance [ 19 ].

3.3.2

Challenges in Case of SaaS

3.3.2.1 Governance: Applying Restrictions and Exit Strategy

Being a third-party service, cloud resources need to have controlled and accounted access. Governance in cloud computing is when an organisation wants to prevent rogue (or unauthorised) employees from misusing a service. For example, the organ- isation may want to ensure that a user working in marketing part of the application can only access specifi c leads and does not have access to other restricted areas. Another example is that an organisation may wish to control how many virtual machines can be spun up by employees, and, indeed, that those same machines are spun down later when they are no longer needed. So-called rogue cloud usage must also be detected, so that the employees setting up their own accounts for using a cloud service are detected and brought under an appropriate governance umbrella.

Whilst cloud service providers offer varying degrees of cloud service monitor- ing, an organisation should consider implementing its own cloud service gover- nance framework. The need for this independent control is of particular benefi t when an organisation is using multiple SaaS providers, that is, HR services, ERP and CRM systems. However, in such a scenario, the security engineers also need to be aware that different cloud providers have different methods of accessing infor- mation. They also have different security models on top of that.

That points to the solution provided by a cloud broker, which brokers the differ- ent connections and essentially smoothes over the differences between them. This means organisations can use various services together but only have to interact with a perfectly confi gured CSB application. In situations where there is something

relatively commoditised like storage as a service, they can be used interchangeably. This solves the issue of what to do if a cloud provider becomes unreliable or goes down and means the organisation can spread the usage across different providers. In fact, organisations should not have to get into the technical weeds of being able to understand or mitigate between different interfaces. They should be able to move up a level where they are using the cloud for the benefi ts of saving money.

3.3.2.2 Data Encryption

As discussed earlier, when moving data onto a third-party infrastructure, secrecy can be one of the factors for security. This applies to storage infrastructure service as well. Most of the companies are now moving for a cloud-based storage solution, and this calls for an important aspect of secrecy, encryption. Encryption can be handled in many ways. It must also be noted that encrypting data is a CPU-intense process. Many organisations prefer to handle encryption in-house; that is, they pre- fer to generate own keys and decide on a particular encryption algorithm to further increase confi dentiality. Cloud storage provider also provides the encryption facility at the consumer end with unique and dynamically generated consumer-specifi c encryption keys. The latest trends suggest that organisations are making use of CSBs to accomplish this task. It is interesting to note that many organisations prefer providers whose data centres are accessible and have better traceability than others where it is diffi cult to track the data being sent onto cloud.

3.3.3 Challenges Relating to SaaS, PaaS, IaaS

3.3.3.1 Using API Keys

Many cloud services are accessed using simple REST [ 20 ] Web services interfaces. These are commonly called “APIs”, since they are similar in concept to the more heavyweight C++ or Java APIs used by programmers, though they are much easier to leverage from a Web page or from a mobile phone, hence their increasing ubiquity. In order to access these services, an API key is used. These are similar in some ways to passwords. They allow organisations to access the cloud provider. For example, if an organisation is using a SaaS offering, it will often be provided with an API key. This is one security measure employed by the provider to increase accountability; that is, if in case something goes wrong, then that can be easily tracked as every application instance running would have a unique API key (which is associated with a particular user credential) and the source application for the cause of the mistake would also bear an API key. Hence, the misuse of a correct application can be only through misuse of API keys, and it becomes important to protect them.

Consider the example of Google Apps. If an organisation wishes to enable single sign-on to their Google Apps (so that their users can access their email without

having to log in a second time), then this access is via API keys. If these keys were to be stolen, then an attacker would have access to the email of every person in that organisation.

The casual use and sharing of API keys is an accident waiting to happen. Protection of API keys can be performed by encrypting them when they are stored on the fi le system, by storing them within a hardware security module (HSM) or by employing more sophisticated security systems such as Kerberos [ 21 ] to monitor single sign-on.